AIエージェントのサンドボックスの違いと選び方

こんにちは、こんばんは、おはようございます。

Algomaticでエンジニアをやっている灯里（@akari_iku）です。

普段は、企業向けAI研修の設計、デモやツールの開発、AI利用のガバナンス整備をやっています。

つまり「AIにどこまで任せるか」を、教える側と決める側の両方携わっている人間です。

本記事は 『Algomaticアドベントカレンダー 第2弾 - Algomaticの現在地をみんなで紹介しよう！』 の4日目です。

メンバーそれぞれが自分の仕事や関心領域を語るリレー企画で、Algomaticがいま何をやっているのか、どんなメンバーがいるのかを知っていただけたら幸いです。

昨日の記事はこちらです。

note.com

主要なAIコーディングエージェント（Claude Code・Codex CLI・Gemini CLI・Grok Build）は、いずれもサンドボックス機能を同梱するようになりました。本記事では4社の実装を比較し、Qwen CodeやGLMなど周辺のオープンソース・モデル勢の位置づけも整理したうえで、「AIを用いた開発では、何から何を守りたいか」で選ぶための判断軸を紹介します。

• 各社がサンドボックスを同梱し始めた

• 「ハーネス」とは何か

• なぜサンドボックスが要るのか

• 各社のサンドボックスはどう違うか

Claude Code: OSネイティブ + プロキシ強制

• Codex CLI: 承認モードとサンドボックスが対になった設計

• Gemini CLI: OSネイティブとコンテナの二本立て

• Grok Build: permissionsとsandboxの分離

• 比較からわかる3つの構図

サンドボックスはモデルではなくハーネスの持ち物

• サンドボックスは「安全機能」ではなく「自律性の解放装置」

• 実装は同じ「枯れた境界」に行き着いている

• どの箱で走らせるか

複数のモデルを併用する場合

• OSごとの対応状況

• まとめ

• 参考

一緒に働く仲間を募集しています！

各社がサンドボックスを同梱し始めた

AIコーディングエージェントの使われ方は、この1年で大きく変わりました。1コマンドずつ確認して承認していたのは過去の話で、いまはループで回して放置し、結果だけを見る運用が当たり前になりつつあります。実行されるコマンドを1つずつ見ている人は、いまや少数派になりました。見ていないところで誤ったrmやビルド設定の破壊が起きたとき、誰が止めるのか。

その答えとして、2025年から2026年にかけて、主要なエージェントCLIは軒並みサンドボックス機能を標準装備するようになりました。ただし「サンドボックス」という名前は同じでも、中身は各社でかなり違います。まず主要な提供元を一覧にします。表の「型」は本記事での分類で、境界を自前で持つか、フォーク元から継承しているか、他社ハーネスに間借りしているか、を表しています。

なお、本記事の調査は2026年8月時点のものです。この分野は動きが速く、特にGrok Buildは2026年5月にベータ公開されたばかりの製品のため、利用時は必ず各公式ドキュメントで最新の仕様を確認してください。

「ハーネス」とは何か

本題に入る前に、この記事で繰り返し使う「ハーネス」という用語を整理します。Hugging Face（機械学習モデルの共有プラットフォームを運営する企業）が公開したエージェント用語集では、次の式で説明されています。

Agent = Model + Harness

つまり、モデル（LLM本体）ではない部分は全部ハーネスです。Claude Codeという製品のうち、モデルを除いたすべて、つまりツール定義、実行ループ、承認UI、そしてサンドボックスがハーネスにあたります（もっと狭く、モデルを呼んでツール実行を処理し、いつ止めるかを決める実行ループだけを指す使い方もあります。本記事では「モデル以外の全部」という広いほうの意味で使います）。

そして、ハーネスがエージェントの行動を制御する手段には強制力の階段があります。

• システムプロンプト・ツール定義: モデルに「こうしてほしい」と頼む。CLAUDE.mdのような指示ファイルやSkillsもこの層。保証はない

• hooks・permissions: プロセス内でツール呼び出しを機械的に許可・拒否する。書いたルールの範囲では確実に働くが、許可済みのfindからexec rmを呼ぶような想定外の経路は塞ぎきれず、エージェントと同じプロセス・同じOS権限の中で動く

• サンドボックス: OSカーネル（OSの中核。どんなプログラムも、ファイルや通信へのアクセスは必ずここを通る）が強制する境界。モデルもハーネス自身も信用しない前提の、プロセスの外側の線

この記事で扱うのは3段目です。1〜2段目との違いは、エージェントの賢さに関係なくOS側で止まる点にあります。サンドボックス自体にも脆弱性が見つかることはあるので万能ではありませんが、抜け道を探す難易度の桁が変わります。

なぜサンドボックスが要るのか

そもそもなぜこの境界が必要なのでしょうか。理由は挙げればきりがありませんが、大枠は3つです。

1つ目は、未検証の出力がいきなり「本番」で実行されるようになったことです。

人間が書いたコードでさえ、検証環境で試してから本番に出すのが一般的なプロセスです。ところがエージェントは、モデルが生成したコマンドを、あなたの作業マシンで直接実行します。そこには本物のファイルも、本物の認証情報もあります。

従来のLLMは間違えても、出てくるのは変な文章や変なコードで、人間が採用しなければそこで終わりでした。いまは検証も採用判断も挟まずに、間違いが「実行されたrm」という形でファイルシステムに現れます。サンドボックスは、この実行場所を「本番」から切り離す仕掛けです。

検証と本番を分けるという規律そのものは、ITの世界で昔から変わっていません。実行する主体が人間からAIに広がったことで、その規律の重要性が一段上がった、ということです。

2つ目は、prompt injection（プロンプト経由の指示汚染）です。

エージェントはWebページやREADMEといった、信頼できないテキストを日常的に読み込みます。そして、そこに悪意のある指示が埋め込まれていても、素直に読み込んでしまいます。

「秘密情報へのアクセス」「信頼できない入力」「外部への送信」の3つが揃うと深刻な事故になります。Simon Willison氏（Djangoの共同作者で、近年はLLMのセキュリティやprompt injectionについて多く発信している開発者）はこれをlethal trifecta（致命的な三点セット）と呼びました。サンドボックスによるネットワーク制御は、この3本目の脚を細くする装置です。許可した送信先を経由した持ち出しまでは防げないため万能ではありませんが、injectionが成立する条件を大きく削れます。

3つ目は、承認疲れです。

すべてのコマンドを人間が承認する運用は続きません。承認を求められ続けた人間は、内容を確認せずにYesを連打し始めます。安全のための承認プロセスが、形骸化によって逆にリスクになるわけです。

サンドボックスは「自動承認しても壊れない範囲」をあらかじめ作ることで、人間の注意力を本当に重要な判断に集中させます。

ここまでの3つに共通するのは「信頼できない実行主体を隔てたい」という要求で、これ自体はOSが何十年も取り組んできたテーマです。コンテナやmicroVM（コンテナより強い隔離を提供する軽量な仮想マシン）まで含めた隔離技術の仕組みそのものは、同僚の藤崎さんがOSの観点から掘り下げているので、あわせて読んでいただくのがおすすめです。本記事は「製品として何が提供されていて、どれを選ぶか」の側を扱います。

tech.algomatic.jp

各社のサンドボックスはどう違うか

先ほどの表のうち、境界を自前で持っているのはClaude Code・Codex CLI・Gemini CLI・Grok Buildの4つです（継承・間借り組については後述します）。この4社が同じ問題にどう答えたかを、順に見ていきます。

Claude Code: OSネイティブ + プロキシ強制

Claude Codeのサンドボックスは、macOSではSeatbelt（sandbox-exec機構）、LinuxではbubblewrapというOSネイティブの仕組みを使い、コンテナなしで動作します。ファイルシステムの隔離では、明示的に許可したディレクトリ以外へのアクセスを制限します。特徴的なのはネットワーク制御で、サンドボックス内の通信はすべてプロキシ経由に強制され、許可されたドメイン以外へのアクセスを遮断します。

さらにAnthropicはこのサンドボックス実装をsandbox-runtime（srt）というオープンソースパッケージとして切り出して公開しています。ハーネスから境界の部品だけを取り出して、任意のプロセスに掛けられるようにした形です。

srtはコマンドひとつで任意のプロセスをサンドボックス内で実行できるため、挙動を手元で確かめるのも簡単です。実際にインストールして遮断の挙動を試した例は、azukiazusaさんの記事が詳しいのであわせて参照してください。

azukiazusa.dev

Codex CLI: 承認モードとサンドボックスが対になった設計

OpenAIのCodex CLIは、macOSではSeatbelt、LinuxではClaude Codeと同じbubblewrapに、seccomp（システムコールを制限するカーネル機能）によるネットワーク遮断を重ねた構成です。当初はLandlock（ファイルパス単位のアクセス制御を行うカーネル機能）を使っていましたが、現在はbubblewrapがデフォルトになり、Landlockは設定で選べる旧方式として残っています。設計として特徴的なのは、承認モードとサンドボックスが最初からセットになっている点です。read-only（読み取りのみ）、workspace-write（作業ディレクトリ内のみ書き込み可、デフォルト）、danger-full-access（制限なし）という3段階で、「どこまで自動で任せるか」と「どこまで届くか」を一緒に選ばせます。

デフォルトのworkspace-writeでは、作業ディレクトリの外への書き込みやネットワークアクセスは、ユーザーの承認なしには実行されません。詳細は公式のAgent approvals & securityを参照してください。

実装の中身を実際に検証した調査としては、Simon Willison氏の記事が詳しいです（英語。調査時点の実装はLandlockで、bubblewrapへの移行はその後です）。

simonwillison.net

また、Codex CLIは主要ハーネスで唯一、Windowsネイティブのサンドボックス実装を持ちます。

2026年8月時点では実験的な位置付けです（他社のWindows対応はWSL2やコンテナ経由になります）。

Gemini CLI: OSネイティブとコンテナの二本立て

GoogleのGemini CLIは、環境変数GEMINI_SANDBOXで方式を選ばせるアプローチです。macOSではsandbox-exec（Claude Codeの節で触れたSeatbeltと同じ機構です）、それ以外ではDocker・Podmanによるコンテナ隔離を選べて、公式のサンドボックスイメージも配布されています。OSネイティブの手軽さとコンテナの再現性、どちらを取るかをユーザーに委ねる設計です。

Gemini CLIのサンドボックス機能は、以前こちらのブログでも解説しています。

tech.algomatic.jp

Grok Build: permissionsとsandboxの分離

2026年5月にベータ公開されたxAIのGrok Buildは、あとから参入しただけあって、概念の整理が最もはっきりしています。permissions（そのツールを呼び出してよいか）とsandbox（承認された実行がどこまで届くか）を明示的に別のレイヤとして分離し、サンドボックスはoff・workspace・devbox・read-only・strictの5段階プロファイルで選びます（書き込み先を限定するworkspaceから、読み取り範囲まで絞るstrictまで。デフォルトはoff）。

中身はmacOSがSeatbelt、LinuxがLandlockで、Linuxではseccompによる子プロセスのネットワーク遮断や、bubblewrapによる読み取り拒否も組み合わせます。**/*.pemや.envのような機密パスをカーネル強制で読み書き禁止にするdenyリストなど、具体の詰め方も細かいです（仕様は公式リポジトリのサンドボックス文書にまとまっています）。

先ほどの「強制力の階段」で言えば、2段目と3段目の区別をそのまま製品仕様にした形と言えます。

比較からわかる3つの構図

ここまでを並べると、単なる機能比較を超えた構図が見えてきます。

サンドボックスはモデルではなくハーネスの持ち物

Qwen CodeはGemini CLIから派生したプロジェクトで（公式リポジトリに「Gemini CLI v0.8.2を基にした」と明記。現在は独立して開発）、サンドボックスもフォークしたから付いてきた機能です。逆にZ.AIのGLMシリーズはAnthropic互換APIを提供してClaude Codeなどに「モデルだけ差し替え」で乗る戦略のため、自前の境界を持たず、ホスト側ハーネスの境界を借ります。

この構図が最もはっきり見えるのがGoogleです。同じ会社が、ハーネスであるGemini CLIにはサンドボックスを同梱し、モデル単体のGemmaには何も付けずに公開しています。つまり境界はモデルの賢さとは別のレイヤで、ハーネス側から供給されているわけです。

これは信頼の分離という面白い状況も生みます。GLMをClaude Codeに接続して使う場合、コードを書くモデルの提供者と、あなたのマシンを守る境界の提供者は別の会社になります。

サンドボックスは「安全機能」ではなく「自律性の解放装置」

4社（Claude Code・Codex CLI・Gemini CLI・Grok Build）は、いずれもサンドボックスを承認モードとセットで提供しています。これは偶然ではありません。境界がないとき、安全を担保するのは人間の承認だけで、その承認は疲れによって形骸化します。境界を先に引いておけば、「この範囲内なら自動で実行してよい」と言えるようになります。

「なぜサンドボックスが要るのか」で3つの理由を挙げましたが、製品の作り手にとって一番切実なのは、3つ目の承認疲れだったのでしょう。同梱の狙いは防御のためだけではなく、承認なしで任せられる範囲を広げて、エージェントの自律性を製品として成立させるためでもあるわけです。

実装は同じ「枯れた境界」に行き着いている

実装の中身を見ると、macOSでは4社すべてがSeatbeltという同じOS機構に行き着いています。LinuxはClaude CodeとCodex CLI（当初のLandlockから移行）がbubblewrap、Grok BuildがLandlockと分かれますが、いずれもLinuxカーネルが長年提供してきた隔離機構の再利用です。新しい隔離レイヤを発明した会社は1社もありません。

新発明を避けた理由は、実装コストや性能など各社それぞれでしょう。ただ結果として、冒頭で紹介した藤崎さんの記事の結論「目新しい隔離レイヤより、枯れた境界を素直に組むことを信用する」と同じ場所に、各社の製品判断も着地しています。

どの箱で走らせるか

では実際にどれを使えばよいのでしょうか。迷ったら「とりあえずDocker」になりがちですし、それで困らない場面も多いです。ただ、そもそもコンテナを立てる必要があるのか、は一度考えたいところです。開発するもの・要件・規模によっては、もっと摩擦の少ない選択肢で足りることもありますし、多くはないものの、Dockerでは足りない場面もあります（素のDockerは外向きの通信を制限しませんし、コンテナはホストとカーネルを共有するため、本当に信用できないコードの実行にはmicroVMのようなより強い隔離が使われます）。「どのサンドボックスが優秀か」ではなく、何から何を守りたいかから逆算するのが実用的です。

ホスト破壊への備えだけなら、同梱サンドボックスが最適で６７す。

追加のセットアップなしで有効化でき、誤った削除や上書きのようなうっかり事故は、体感の摩擦がほぼないままここで止まります。

外部への送信が必要なら、ネットワーク制御の実装を見てください。

通信を全部塞げるなら話は簡単ですが、Web検索やMCPサーバーの利用など、外部への通信を残す必要がある場合は「どう絞るか」が問題になります。すべての通信をプロキシに通す方式（Claude Code）は出口が1か所に集まるため監視や遮断を足しやすく、許可ホスト名のリストで絞る方式（Grok Build）は設定が単純で見通しが良い、という違いがあります。ただしどちらも、許可した送信先を経由した持ち出しまでは防げません。持ち出し対策は箱の選定だけで完結する話ではなく、秘密情報をエージェントの届く場所に置かない、といったシステム全体の設計とセットで考える必要があります。

チームの共通基盤にするなら、コンテナに軍配が上がります。

同梱サンドボックスは個人の対話セッションに最適化されています。メンバー間で同一の実行環境を保証したい、CIに組み込みたい、テストを毎回クリーンな環境で走らせたい、という要件には、Docker・devcontainer（エディタと連動して開発環境ごとコンテナ化する仕組み）の再現性が必要です。テストの実行をAIエージェントに任せる場合も、クリーン環境の要求はエージェントの箱にそのまま引き継がれるので、結論は変わりません。

他人の書いたコードを走らせるなど、実行主体そのものを信用できない場合は、より強い隔離の領域です。

microVMなどが該当しますが、ここは本記事のスコープ外です。隔離の強さの違いは、冒頭で紹介した実行基盤の記事が詳しいです。

複数のモデルを併用する場合

もうひとつ無視できないのが、複数モデルの併用です。設計やレビューはこのモデル、実装はあのモデル、という使い分けは珍しくなくなりました。

併用したいのはあくまでモデルですが、各社の主力モデルは自社のハーネス越しに使うことが多いため、モデルを3つ使うとハーネスも3つ、ひとつのリポジトリに3つの境界が持ち込まれます。しかもその3つは方式も強度も設定方法もバラバラです。「こちらのツールでは止まる操作が、隣のツールでは素通りする」状態は、守る側から見れば穴と同じです。

併用が日常なら、境界をハーネス任せにせず、外側に1つ引くほうが筋が良いと考えられます。手段は2つあります。ひとつはDocker・devcontainerのような共通の箱に、どのエージェントも入れて走らせる方法。もうひとつは、srtのような単体のサンドボックスツールで、どのハーネスにも同じ制限を掛ける方法です。srtが「境界の部品」として単体公開されているおかげで、後者の使い方が現実的になっています。

この「外側に1つ」という需要は製品側にも見えていて、Docker自身が、AIエージェント専用の隔離実行環境であるDocker Sandboxes を出しています。microVMベースの使い捨ての箱にエージェントごと入れて走らせるもので、まさにこの節で書いた発想の製品化です。

OSごとの対応状況

最後に、OSごとの現実を整理します。「どの箱が使えるか」はOSによってかなり変わります（2026年8月時点の調査です）。

Windowsユーザーとしての実感を書いておくと、OSネイティブのサンドボックスをWindowsで使えるのは、現時点で実質Codex CLIとだけで、それも実験的な位置付けです。Claude Codeは本体こそWindowsで動きますが、サンドボックス機能は対象外で、使いたければWSL2（Windows Subsystem for Linux 2）かDockerを経由することになります。Gemini CLIもWindowsではDocker路線で、Grok Buildも本体はWindowsで動くもののサンドボックスの実装はmacOS・Linux向けです。

つまりWindowsでは、ここまで書いてきた「とりあえずDockerの前に一度考えよう」という話が、考えた結果それでもDockerに落ちがちです。選択肢が揃うまでは「素直にDockerを立てる」がWindowsの現実解だと思っています。

まとめ

• 主要なAIコーディングエージェント（Claude Code・Codex CLI・Gemini CLI・Grok Build）は、いずれもサンドボックスを同梱するようになった

• サンドボックスはモデルではなくハーネスの持ち物。フォークすれば継承され（Qwen Code）、モデル単体には付いてこない（GLM・Gemma）

• 同梱の狙いは防御だけではなく、承認疲れを解消して自律性を製品として成立させること

• 実装はmacOSのSeatbeltをはじめ、枯れたOS機構の再利用に落ち着いている

• 選定は「何から何を守りたいか」で決める。個人利用は同梱サンドボックス、チーム基盤はコンテナが出発点

• 複数モデルの併用が日常なら、境界はハーネス任せにせず外側に1つ引く（共通の箱に入れるか、srtのような単体ツールで揃える）

参考

• Claude Code Docs - Choose a sandbox environment

• openai/codex - linux-sandbox

• Sandboxing in the Gemini CLI

• xai-org/grok-build

• Qwen Code Docs - Sandbox

• Simon Willison - The lethal trifecta

一緒に働く仲間を募集しています！

ここまで読んでいただきありがとうございました！

Algomaticでは、「AI革命で人々を幸せにする」をミッションに、変化の速い領域でも学びや試行錯誤を続けられる仲間を募集しています。

もし少しでもご興味をお持ちいただけましたら、カジュアル面談に足を運んでいただけるとうれしいです！