7月29日、CircleCIが「What is an AI sandbox? A developer's guide」と題した記事を公開した。AIコーディングエージェントが生成したコードを安全に実行するための「AIサンドボックス」の仕組みと、開発ワークフローへの組み込み方を詳しく解説した内容で、実際のインシデント事例や具体的な数値、分離メカニズムの比較まで幅広くカバーしている。
なぜ今、AIサンドボックスが必要か
AIコーディングエージェントが日常的に使われるようになり、事故の報告も増えてきた。
Claude Codeのクリーンアップコマンドがホームディレクトリごとファイルを削除した事例（GitHub issue #10077）や、Replitのエージェントがコードフリーズ中に本番データベースを削除した事例（The Registerの報道）は、いずれもエージェントが「人間がレビューしきれない速度で本物のシステムに対して本物のコマンドを実行した」ことによる失敗だ。
サンドボックスはその失敗を「局所的な損害」に収める境界線である。
AIサンドボックスとは何か
AIサンドボックスは、エージェントが実行するコードをホストマシンや本番環境から切り離した、隔離された実行環境だ。エージェントはファイルシステム、シェル、必要なツールを持つ作業空間を得るが、その外側——ホストの認証情報、他のプロジェクト、本番システム——には手が届かない。
単なるDockerコンテナとの違いも明確に述べられている。標準的なコンテナはホストのカーネルを共有するLinux名前空間による分離であり、コンテナエスケープが起きればホストマシンに到達できる。AIサンドボックスはその上にさらに強い層——専用のゲストカーネルを持つ軽量VMなど——を加えることで、コンテナ自体を突破されても境界が維持される。
承認疲れという現実のコスト
「ドラマチックな事故」より開発者が日々感じるコストは別のところにある。サンドボックスなしでエージェントを安全に動かすには、ほぼすべてのアクションで許可を求めさせるしかない。この承認疲れが積み重なると、開発者は反射的に「Yes」を押すようになり、それこそが重大な失敗を招く入り口になる。
サンドボックスがあれば、爆発半径が最初から限定されているので、エージェントは確認なしに動ける。CircleCIの記事が紹介する事例として、Anthropicは自社でのClaude Code利用においてパーミッションプロンプトが84%減少したと報告している。Cursorも同じアプローチで開発者への割り込みが40%減少したと述べている。いずれもCircleCIの記事内で言及されている数字であり、各社の公式統計として独立に検証したものではない点は留意しておきたい。
分離メカニズムの比較
サンドボックスの実装には複数の手法があり、起動速度と分離強度のトレードオフが異なる。
| 仕組み | 起動時間 | 分離強度 |
|---|---|---|
| 標準コンテナ | ミリ秒 | 弱い（ホストカーネルを共有） |
| gVisor | ミリ秒（元記事も同様の表記） | 中程度（ユーザー空間カーネルがsyscallを仲介） |
| Firecracker microVM | 約125ms以内 | 強い（専用ゲストカーネル） |
| Kata Containers | 約150〜300ms以上 | 強い（VMレベルの分離） |
| V8 isolates | 5ms以内 | 弱い（同一OSプロセス内の分離） |
gVisorの起動時間については、元記事でも標準コンテナと同じ「ミリ秒」オーダーと記述されており、Firecracker（約125ms）やKata Containers（約150〜300ms）が「数百ミリ秒」レンジであるのに対し、gVisorは標準コンテナに近い起動速度を維持しつつ分離強度を上乗せする位置づけとなっている。
カーネルまたはVMレベルの分離は、テキストマッチングに依存するコマンドブロックリストを推論で迂回されるリスクに対して有効だ。セキュリティ研究者は、設定が甘い環境や分離が弱い環境で高性能モデルが想定外の経路を見つける事例を示している。「エスケープを不可能にする」わけではなく、リスクを大幅に低減するものと理解しておくべきだ。
ワークフローの中でどこに位置するか
AIエージェントを使った開発には2つのループがある。
- 内側ループ（inner loop）：自分のマシン上での書く・実行・確認・修正のサイクル。AIサンドボックスはここで機能し、「コードが安全に実行できるか」を担う。
- 外側ループ（outer loop）：プッシュ後のCI/CDパイプライン。エンドツーエンドテスト、セキュリティ・コンプライアンスチェック、リリース判断を担う。
サンドボックスは「実行の安全性」を確保するが、「リリースに値するか」の判断はCIと人間のレビュアーの責任だ。CircleCIの2026年版「State of Software Delivery」レポートによれば、日次ビルドアクティビティは前年比59%増、メインブランチの成功率は5年ぶりの低水準まで下落している。AIが生成するコードの量が増えるほど、パイプラインの重要性は増す。
ツール選定より先にやること
Claude CodeやCursorはすでにネイティブのエージェント分離機能を搭載しており、多くのコーディングツールはデフォルトでサンドボックスを提供するか、組み込みオプションとして持っている。記事は「ツール選定より先にまず既存環境の監査を」と勧める。その上で重要な3点を挙げている。
- スコープが最大のレバー。使い捨てのサイドプロジェクトと本番の認証情報が入ったリポジトリでは、与えるべき権限が全く異なる。
- 永続的な環境よりエフェメラル（使い捨て）を選ぶ。実行後に破棄される環境は、セッションをまたいで状態を持つ環境より被害が少ない。
- ラベルの裏を見る。「sandboxed」と書かれていても、それがカーネル・VMレベルの分離なのか、テキストマッチのコマンドブロックリストなのかは別の話だ。
チームレベルでは、個々の開発者が設定するより、「安全な方法がデフォルトになっている状態」をゴールデンパスとして整備することが本質的な問いになる。
詳細はWhat is an AI sandbox? A developer's guideを参照していただきたい。
