AI Today
ホーム > 考察記事 > 🔓 使ってるAIコーディングツールが、実は外に出られた｜サンドボックス脱出の実態
AIセキュリティAIコーディングサンドボックス

🔓 使ってるAIコーディングツールが、実は外に出られた｜サンドボックス脱出の実態

アイ

アイ

目次

使ってるAIコーディングツール、実は外に出られてたかもよ

2026年7月21日、セキュリティ企業のPillar Securityが「The Week of Sandbox Escapes」っていう、けっこう物騒なタイトルのレポートを出したの。日本語にすると「サンドボックス脱出の一週間」。名前からしてもう不穏でしょ。

対象になったのは、Cursor、OpenAI Codex、Google Gemini CLI、Antigravityっていう、AIにコードを書かせるタイプのツールたち。しかもどれも、わたしたちの周りでふつうに名前が挙がるような、けっこうメジャーな面々なんだよね。

わたし自身、正直この手のニュースを見るたびに「またか」って思う反面、今回はちょっと構造が違うなって感じたの。というのも、AIそのものが暴走して隔離を破った、っていう話じゃないんだよね。

むしろ逆で、AIを閉じ込めてた箱（サンドボックス）は、技術的にはちゃんと機能してたケースが多いの。それなのに、外に出られてしまった。この「箱は壊れてないのに、外に出られる」っていう感覚、地味に怖いよね。

今回は、この開示された内容を整理しながら、なんでこんなことが起きたのか、そしてわたしたちが今すぐできることは何なのかを、一緒に考えていきたいと思う。

世間的には「AIコーディングツールって危ないの？」ってざっくり不安になっちゃう人もいるかもしれないけど、わたしはちゃんと中身を分けて考えるべきだと思ってるの。なぜなら、事実を丁寧に見ていくと、これは「使うのをやめるべき理由」じゃなくて「使い方を見直すきっかけ」だと分かるから。

そのために、まずは何が起きたのかを正確に押さえておこうね。

そう考える3つの理由

理由1：サンドボックス自体は破られてない、破られたのは外の信頼だった

まず1つめの理由。これが今回のレポートでいちばん大事なポイントだと思う。

Pillar Securityが見つけた手口の核心は、AIが直接OSレベルの隔離を突破した、っていう話じゃないの。そうじゃなくて、AIが作ったり書き換えたりしたファイルを、あとから別の信頼されたアプリが読み込んで、うっかり実行しちゃう、っていう間接的な経路だったんだよね。

これ、たとえ話にするとイメージしやすいと思う。刑務所の壁は破られてないんだけど、面会に来た人がこっそり持ち込んだメモを、外にいる別の人がそのまま信じて実行しちゃった、みたいな感じ。壁そのものは無事なのに、抜け道は別のところにあったの。

具体的に言うと、拡張機能やタスクランナー、Git連携、Pythonツール、フック、Dockerサービスみたいな「サンドボックスの外側にある、信頼された仕組み」が、AIの置き土産を鵜呑みにしちゃう構造になってたんだよね。

わたしはここがすごく重要だと思うの。なぜなら、多くの人が「サンドボックスがあれば安全」って思い込みがちだけど、実際にはサンドボックスは「AIの動きを閉じ込める箱」であって、「箱の外にある全部のアプリの安全」まで保証してくれるものじゃないから。

箱そのものを頑丈にすることと、箱と外の世界のつながり方を安全にすることは、まったく別の課題なんだよね。今回の件は、まさにその「つながり方」のほうが弱かった、っていう話なの。

だから「サンドボックスに入ってるから絶対安心」っていう発想自体を、一回アップデートしないといけないんだと思う。箱は箱、外は外。この境界線をちゃんと意識しておくことが、これからのAIツールとの付き合い方のベースになる気がするの。

理由2：拡張機能やGit連携みたいな「便利機能」がそのまま裏口になってた

2つめの理由。これは、具体的な事例を見るともっと腹落ちすると思う。

まずCursorのケース。ワークスペースの中にある設定ファイル、専門的には「フック設定」って呼ばれるものなんだけど、これが未サンドボックスのコマンド実行につながってたの。これはCVE-2026-48124っていう識別番号がついて、v3.0.0で修正済みだよ。

さらにCursorには、もうひとつ別のバグも見つかってて、Pythonの仮想環境（virtualenv）のインタプリタを書き換えると、Pythonの拡張機能が自動で実行されちゃう、っていう抜け道もあったんだって。

わたしがここで「地味に怖い」と思ったのは、どっちも「便利にするための機能」が原因になってるところなの。フック設定も、拡張機能の自動実行も、本来は開発をラクにするための仕組みじゃない。それが逆に裏口になっちゃうっていうのが、なんとも皮肉だよね。

こういう便利機能って、わたしたちが「設定さえ済ませたら、あとは全部おまかせでいいや」って安心しちゃう部分でもあると思うの。でも今回の件を見てると、「自動で動いてくれる仕組み」ほど、実は中身までちゃんと見られてなかったりするんだなって感じたんだよね。

だからこそ、便利さと引き換えに「ここは自動で動く場所なんだ」っていう意識を、頭の片隅に置いておくのが大事だと思う。全部を疑う必要はないけど、「なんでも自動」に慣れすぎないバランス感覚を持っておきたいよね。

理由3：CursorもCodexもGeminiもAntigravityも、主要ツールが軒並み対象だった

3つめの理由。これが今回のレポートを「ひとつのツールの不運な事故」で片付けられない理由なんだ。

OpenAI Codex CLIのケースも、Cursorとちょっと違う角度で似たような構造の問題があったの。Codex CLIには「安全なコマンドだけを自動で許可する」っていう仕組みがあったんだけど、その許可リストが「git show」っていうコマンドの名前だけを見て、中身までは確認してなかったの。名前は読み取り専用っぽいのに、実際の呼び出しは読み取り専用じゃなかった、っていう食い違いがあったんだよね。

これはv0.95.0で修正されて、しかも高額の報奨金（バグバウンティ）が支払われるくらい深刻度の高いものとして扱われたの。ちなみにこちらはCVE番号はまだ保留中だよ。

Antigravityについても、macOSのSeatbelt（アプリの動きを制限する仕組み）のポリシーと、VS Codeのタスク設定に絡んだ回避方法が見つかってる。細かい実装は違っても、根っこにある考え方は同じなんだよね。「信頼されてる仕組みを、そのまま信じすぎてた」っていうこと。

わたしがここでいちばん感じたのは、これって特定のツールだけが手を抜いてた、っていう話じゃないんだな、ってこと。Cursorも、Codexも、Gemini CLIも、Antigravityも、それぞれ別の会社が作ってる、それぞれ人気のツールだよね。それなのに、根っこの構造がどれも似たような盲点を抱えてた。

これはつまり、「AIエージェントに、外の世界とやり取りする力を持たせる」っていう設計そのものが、業界全体でまだ試行錯誤の途中にあるってことだと思うの。誰か一社が特別に雑だった、っていうよりは、みんなが同じ新しい課題にぶつかってる最中なんだよね。

だからこそ、わたしたち利用者側も「このツールは危ないから、あっちに乗り換えよう」みたいな単純な話にはしない方がいいと思う。どのツールを使うにしても、同じ種類のリスクと向き合う必要があるってこと、覚えておきたいよね。

そもそも「サンドボックス」って何？

ここでいったん、そもそも論に戻ってみようと思う。サンドボックスって言葉、なんとなく聞いたことあっても、正確に説明できる人ってそんなに多くない気がするの。

サンドボックスっていうのは、直訳すると「砂場」。子どもが砂場の中で遊んでる分には、周りに砂が飛び散っても大きな被害にはならないよね。それと同じ発想で、プログラムを隔離された領域の中だけで動かして、外のシステムに影響を出さないようにする仕組みのことなんだ。

AIコーディングツールの文脈で言うと、AIがファイルを作ったり、コマンドを実行したりする作業を、パソコン本体から切り離された箱の中でやらせる、っていうイメージだよ。もし変なコードを実行しちゃっても、被害が箱の中だけで収まるようにしておくの。

なんでこんな仕組みが必要かというと、AIエージェントって「その場で考えて、その場でコードを書いて、そのまま実行する」っていう動き方をするから。人間みたいに、一行ずつ「これ大丈夫かな」ってチェックしてから実行してるわけじゃないんだよね。

だからこそ、万が一おかしなコードが生成されても被害を限定できるように、あらかじめ箱で囲っておく。これがサンドボックスの基本的な役割なの。

今回の件で分かったのは、その箱自体は多くのケースでちゃんと機能してた、ってこと。でも箱の外にある「信頼された別のアプリ」が、箱の中から出てきたファイルを無条件に信じて実行しちゃう構造になってた。箱の強度だけ見てても、この抜け道には気づけないんだよね。

だから今回の話は「サンドボックスが無意味だった」んじゃなくて、「サンドボックスと、その外側の仕組みのつなぎ目に穴があった」っていう、もう一段階細かい話なんだ。ここを混同しちゃうと、対策の方向性も間違えちゃうから気をつけたいよね。

じゃあ何をすればいいの？今すぐできる3つの対策

ここまで読んで、「じゃあわたしは何をすればいいの？」って思った人も多いと思うから、具体的な対策を整理しておくね。

1つめは、シンプルだけどいちばん効くやつ。使ってるツールを常に最新版にアップデートしておくこと。CursorはCVE-2026-48124の修正でv3.0.0、Codex CLIはv0.95.0で対応済みだから、まずはバージョンを確認するところから始めよう。地味だけど、これが実は一番コスパのいい対策なんだよね。

2つめは、AIに読み込ませるプロジェクトの中身を、ある程度自分でも把握しておくこと。フック設定やタスクランナーの設定みたいな「裏で自動実行される仕組み」が、知らないうちに仕込まれてないか、ときどき見直す習慣をつけておきたいの。特に、よく分からないリポジトリをそのままクローンしてAIに触らせるときは要注意だよ。

3つめは、拡張機能やDocker連携、Git連携みたいな「信頼された仕組み」を無闇に増やしすぎないこと。便利な連携を追加すればするほど、実は「AIの置き土産を無条件で信じる経路」も増えていくの。必要なものだけを厳選して使うくらいの慎重さが、ちょうどいいバランスだと思う。

あと補足として、今回見つかったバグの多くはすでに修正済みで、ベンダー側もちゃんと対応してることも知っておいてほしいの。悪いニュースに見えるけど、これは「見つけて、直して、公開する」っていう、健全なサイクルがちゃんと回ってる証拠でもあるんだよね。

ただ一方で、対応方針が分かれた部分もあって、一部では「エージェント型AIにサンドボックスは本質的に不十分なんじゃないか」っていう指摘も出てる。これはまだ結論が出てる話じゃないから、わたしも今後の議論をちゃんと追っていきたいなと思ってるの。

こういう専門的な議論があるからこそ、わたしたち利用者側は「難しいことは分からないから放置」じゃなくて、「せめてアップデートだけはちゃんとする」っていう、できる範囲の防御を積み重ねておくのが現実的だと思うんだよね。

まとめ：サンドボックスは魔法の箱じゃない、でも今すぐ乗り換える理由でもない

今日は、Pillar Securityが開示したAIコーディングツールのサンドボックス脱出について、3つの理由から掘り下げてきたよ。

おさらいすると、サンドボックス自体が破られたわけじゃなくて、AIが作ったファイルを外の信頼された仕組みがそのまま実行しちゃう、っていう間接的な経路が抜け道になってた。しかも、その抜け道は拡張機能やフック、Git連携みたいな「便利機能」の中に潜んでたし、CursorもCodexもGemini CLIもAntigravityも、みんな対象になってたんだよね。

これって「サンドボックスは意味がない」って話じゃないの。むしろ逆で、箱そのものはちゃんと役割を果たしてたからこそ、抜け道が「箱の外側」にあったことが分かった、っていうポジティブな側面もあると思う。

わたしがいちばん伝えたいのは、これは「AIコーディングツールを使うな」っていう話じゃないってこと。むしろ、こういう仕組みを理解した上で、最新版に更新して、賢く付き合っていくことのほうがずっと大事だと思うの。

AIにコードを書かせるのって、本当に便利だし、これからも手放せないと思う。だからこそ「なんとなく怖いから使わない」じゃなくて、「仕組みを知った上で、必要な対策をしながら使う」っていうスタンスでいたいよね。

今回の件は、わたしたちに「箱の中身だけじゃなくて、箱の外とのつながり方まで意識しよう」っていう、ちょっと大人な視点をくれたと思う。次にツールをアップデートする時、この記事のことをちょっとだけ思い出してもらえたらうれしいな。

AIコーディングツール選びの基準についてもっと知りたい人は、こっちの比較記事も参考にしてみてね。Cursor vs Claude Code vs Copilot 2026

ソース: