複数のエージェントを使う
ai-jailです。ポリシーファイル1つ、どんなコマンドでも、プロセス全体が中に入ります。インストール。
最終確認日は2026年10月15日です。他社製品は変化が速いため、それらに関する記述にはすべてベンダー自身のドキュメントへのリンクを付けています。
要点
6つの状況に、答えを1つずつ。根拠はこのページの残りで示します。
Claude Codeしか使わない
Anthropic自身のsandbox-runtimeもプロセス全体を包みます（ベータ）。ai-jailはそれに空のホームと閉じたネットワークを加えます。カードを見る。
エージェント自身のサンドボックスとプロンプトを使いたい
そのまま有効にしておいてください。ai-jailの中でも動きます。両方使う。
ツールごとのポリシー、実行時の承認、署名付きの監査証跡が欲しい
そこではnonoが先を行きます。代わりに、ポリシー言語とスーパーバイザーが要ります。ラッパーを比べる。
コードから、ツール呼び出し1回ずつサンドボックスに入れる
zeroboxにはそのためのSDKがあります。読み取りは開いたままで、2026年5月以降リリースがありません。ラッパーを比べる。
コードをまったく信用していない
使い捨ての仮想マシンです。このページのツールはどれも、カーネルをホストと共有します。Docker、コンテナ、VM。
壁はどこにあるか
執筆時点で、Claude Codeのサンドボックスの対象はシェルコマンドとその子プロセスです。ファイル操作ツールのほうは許可システムで制御され、ドキュメントにはMCPサーバーとフックはホスト上で制約なしに動くと書かれています。ai-jailはエージェント自体を壁の中で起動するので、エージェントが起動するものもすべて中に入ります。
↔ 横にスワイプすると図全体を見られます
Codexも、自分が起動するコマンドをサンドボックスに入れ、codexプロセス自体は外に残します。ドキュメントによると、MCPサーバーは独自のプロセスやトランスポートを使い、サンドボックスの外で動きます。
許可プロンプトは別の種類の保護
プロンプトが尋ねる相手は人間で、人間は急かされたり騙されたりします。サンドボックスが尋ねる相手はカーネルで、答えは毎回同じです。
↔ 横にスワイプすると図全体を見られます
人間を外すモード
執筆時点で、以下のエージェントにはいずれも、確認を求めなくなるモードがあります。プロンプトがなくなれば、残る保護はサンドボックスだけです。それも、有効にしてあればの話です。
| エージェント | モード | ベンダーの説明による動作 |
|---|---|---|
| Claude Code | auto | すべてが実行され、別のモデルがあなたの代わりに操作を審査します。ドキュメントはこの分類器を操作ごとの制御であり、隔離の境界ではないと説明しています。 |
| Claude Code | bypassPermissions、または--dangerously-skip-permissions | すべてがチェックなしで実行されます。ドキュメントは、隔離されたコンテナやVMの中だけで使うよう求めています。 |
| Codex CLI | 承認ポリシーnever | エージェントは一切確認を求めません。サンドボックスモードは引き続き適用されます。承認とセキュリティを参照してください。 |
| Codex CLI | danger-full-access、または--yolo | サンドボックスが無効になります。--yoloでは承認もなくなります。 |
並べて比べる
ここに書いた内容はすべて、執筆時点の各製品のドキュメントに基づいています。私たちが読んだドキュメントに答えがなかった項目は、セルにそう記しています。
| Claude Codeのサンドボックス | Codex CLIのサンドボックス | Gemini CLIのサンドボックス | ai-jail | |
|---|---|---|---|---|
| エージェント全体を包むラッパーで加わるもの | ||||
| 壁の中に入るもの | Bash、PowerShell、Monitorのコマンドとその子プロセス。claudeプロセス、ファイル操作ツール、MCPサーバー、フックは外です。 | エージェントが起動するコマンド。codexプロセスは外です。ドキュメントによると、ローカルとリモートのMCPサーバーは独自のプロセスやトランスポートを使うため、こちらも外です。 | CLIのプロセス全体。security.toolSandboxingを使うと、シェルと書き込みツールだけになります。 | プロセスツリー全体。エージェント、ファイル操作ツール、MCPサーバー、フック、すべてのコマンドが入ります。 |
| デフォルトで有効か | いいえ。/sandboxかsandbox.enabledで有効にします。依存するものが足りないと、警告を出してサンドボックスなしでコマンドを実行します。sandbox.failIfUnavailableを設定すれば、そうなりません。 | はい。デフォルトのモードはworkspace-writeです。 | -s、GEMINI_SANDBOX、tools.sandboxのいずれかで有効にします。 | ai-jail経由でエージェントを起動すれば、常に有効です。設定が不正な場合は起動を拒否します。 |
サンドボックス内のコードはデフォルトで~/.sshを読めるか | はい。ドキュメントによると、デフォルトでは~/.aws/credentialsや~/.ssh/などの認証情報ファイルを読めます。拒否ルールはオプトインです。 | Linuxでは読めます。ファイルシステム全体が読み取り専用でマウントされるためです。権限プロファイルで**/.env*のようなパスにdenyルールを追加でき、OpenAI自身の強化設定ではそうしています。macOSのデフォルトは記載なし。 | macOSのデフォルトプロファイルpermissive-openは、広い範囲のファイル読み取りを許可します。より厳しいプロファイルはオプトインです。 | いいえ。エージェントには新しい空のホームディレクトリが渡されます。--sshはオプトインです。 |
| 環境変数 | サンドボックス内のコマンドは、デフォルトで親の環境を認証情報ごと引き継ぎます。sandbox.credentialsで拒否またはマスクできます。 | 記載なし | 記載なし | ターミナル、ロケール、ツールチェーン用の変数だけの最小限の許可リストに加えて、起動したハーネス自身のAPIキー。このキーはログイン情報と一緒にデフォルトでコピーされ、--no-agent-stateで止められます。ほかの変数は--envで名前を指定して追加します。 |
| モデルが使える抜け道 | モデルはdangerouslyDisableSandboxを付けてコマンドを再試行でき、その場合は通常の許可フローを通ります。allowUnsandboxedCommands: falseでこれを無効にできます。 | on-requestポリシーでは、ワークスペース外の編集やネットワークのために、エージェントがサンドボックスの外に出る許可を求めます。 | 記載なし | ありません。ポリシーはエージェントの起動前にあなたが決めます。プロジェクト側の.ai-jailファイルは、ポリシーを厳しくできても緩めることはできません。 |
| どのエージェントでも使えるか | Claude Codeのみ | Codexのみ | Gemini CLIのみ | どんなコマンドでも使えます。ポリシーファイル1つで、すべてのエージェントに対応します。 |
| ネットワークの扱い | ドメイン単位の許可リストを持つプロキシ。新しいドメインが出てくると確認を求め、各コマンドにも個別の承認が要ります。プロキシはクライアントが送るホスト名を信頼するため、ドメインフロンティングで回避されうることは、ドキュメントにも書かれています。 | workspace-writeではデフォルトで無効。設定1つで有効になり、オプションのプロキシでドメイン単位の許可と拒否のルールを追加できます。ドキュメントによると、このプロキシはMCPサーバーへの接続、Web検索、ブラウザをフィルターしません。 | デフォルトのプロファイルはネットワークを許可します。より厳しいプロファイルやプロキシ付きのプロファイルはオプトインです。 | 3つのモードがあります。デフォルトは閉じていて、例外は両プラットフォームでの既知のエージェント自身のAPIホストと、ツールチェーンが有効なLinuxでの固定のパッケージレジストリ一覧です。この一覧にはgithub.comが含まれるので、HTTPS経由のgit cloneが動きます。--no-networkは両方を閉じます。--allow-hostは指定したホストとそのサブドメインを足し、Linuxではネットワーク名前空間、macOSではseatbeltのendpointルールが強制します。経由するプロキシは各名前を一度だけ解決し、検査したアドレスに接続します。--networkはすべてを開けます。フィルターはTCPのみで、パス単位のルールはなく、確認を求めることもありません。リスト外のホストは拒否され、--audit-logがその試みを記録します。許可したホストは丸ごと信頼されます。Linuxでは--forward-portがホストのループバックのポート1つをサンドボックスに中継し、そこを通るものにルールはありません。 |
| 組み込みサンドボックスのほうが優れている点 | ||||
| コマンドごとの承認 | あり。許可モード、planモード、分類器モデル、組織で管理するポリシーがあります。 | あり。承認ポリシー、カテゴリ別のルール、オプションのレビュー用エージェントがあります。 | 記載なし | なし。ai-jailは個々のコマンドを見ることも、確認を求めることもありません。 |
| プロジェクト内の保護されたパス | あり。.git/hooks、.git/config、.claudeの設定、.mcp.json、シェルのrcファイルなどは読み取り専用のままです。 | あり。書き込み可能なルートの下にある.git、.agents、.codexは読み取り専用です。 | 記載なし | 組み込みではなし。プロジェクト全体が書き込み可能で、.git/も含まれます。ホスト側のgitはそこにあるものを信頼します。パスのマスクや拒否は、--maskとdeny_pathsで自分で指定します。.git/が問題になる理由。 |
| 秘密情報をエージェントから隠したまま使う | 認証情報のマスク機能を使うと、本物の秘密情報をプロキシ側で注入できます。実験的な設定が必要です。 | 記載なし | 記載なし | あり。2.2から--secret KEY=hostで使えます。サンドボックスにはプレースホルダーが置かれ、プロキシは本物の値をそのホスト宛てのリクエストだけに入れます。対象は、そのホストに向けてプロキシへ平文のHTTPを送るクライアントで、HTTPSトンネルには触れません。マスクされたファイルは空のファイルのままです。 |
| プラットフォーム | macOS、Linux、WSL2。ネイティブのWindowsとWSL1には非対応。 | macOS、Linux、WSL2、ネイティブのWindows。 | macOSのSeatbelt、DockerまたはPodman、gVisor、LXC（実験的）、ネイティブのWindows。 | LinuxとmacOS。WindowsではWSL2のみ。 |
| インストール | エージェントに同梱。Linuxではbubblewrapとsocatが必要です。 | エージェントに同梱。 | エージェントに同梱。コンテナ系のバックエンドにはDockerかPodmanが必要です。 | 別のバイナリ。Linuxではbubblewrapが必要です。 |
出典：Claude Code sandboxing、Claude Code sandbox environments、Codex approvals and security、Codex permissions、Codex Linux sandbox、Gemini CLI sandbox、Antigravity terminal sandbox、Antigravity permissions、nono security model、zerobox README。
その他のエージェント、1枚ずつ
両方使う
既知のエージェントなら何も開ける必要はありません。ログイン情報はデフォルトでマウントされ、フィルタ付きプロキシはモデルのAPIホストと、Linuxではパッケージレジストリを通します。ツールがもっと必要なときは、--allow-hostでホストを足すか、ネットワーク全体を開けます。
cd ~/Projects/my-appai-jail claudeai-jail --network claudeai-jailは既知のエージェント自身のAPIホストを知っていて、デフォルトで許可します。Linuxではパッケージレジストリも同様です。明示的な--allow-hostのリストはそのデフォルトに足されるので、APIホストは許可されたままです。ログイン情報はデフォルトでマウントされ、--no-agent-stateでログアウト状態の実行になります。すべてのフラグはConfigureに。
↔ 横にスワイプすると図全体を見られます
エージェント自身のチェックが引き続き担うこと
許可プロンプト、許可と拒否のルール、planモードはエージェントというプログラムの一部なので、ジェイルの中でも外と同じように動きます。あなたなら承認しなかったはずのコマンドを、ここで止められます。
その下でai-jailが保証すること
エージェント、そのMCPサーバー、そのフックは、何を承認しようと、あなたのホームディレクトリ、鍵、シェルのトークンを見ることはありません。唯一の例外はエージェント自身のログイン情報とAPIキーで、サインイン済みで始まるようデフォルトでマウントされます。エージェントが読めるものは、自身のAPIホストと許可したホストには送れるので、プロジェクト内のシークレットはマスクしてください。
Docker、devコンテナ、仮想マシン
これらも良い選択肢で、仮想マシンのほうが境界として強くなります。違いは、何をビルドし、何を更新し続ける必要があるかです。
| 得られるもの | かかるコスト | |
|---|---|---|
| Dockerコンテナ | 専用のファイルシステム、プロセス一覧、ネットワーク。エージェントに見えるのは、あなたがマウントしたものだけです。 | イメージのビルドと保守が必要で、ツールチェーンをもう一度インストールすることになります。Dockerソケットをマウントすると、そのコンテナはホストのroot相当になります。 |
| devコンテナ | コンテナと同じ隔離。エディタが理解でき、チームで共有できるファイルに定義を書きます。 | 同じくイメージの保守が必要です。加えて、この形式に対応したエディタかツールが要ります。 |
| 仮想マシン | 専用のカーネル。この中で最も強い境界で、悪意があると考えるコードにはこれが適切です。 | 最も重い選択肢です。ゲストOSをインストールして更新し、メモリを割り当て、プロジェクトをコピーする必要があります。 |
| ai-jail | 1つのコマンドを囲むサンドボックス。マシンにすでにあるコンパイラやランタイムを使います。イメージもデーモンもrootも要りません。 | カーネルをホストと共有するので、カーネルやドライバの脆弱性を突く攻撃は守備範囲の外です。仮想マシンよりは弱い境界です。 |
ai-jail自身のドキュメントは、これを「有用な層であり、使い捨てのVMの代わりではない」と位置づけています。脅威モデルを読む。
評価する人へ：ほかのラッパーとプラットフォーム
代替を検討する人のために、オープンソースのラッパー2つとランタイムプラットフォーム1つを、それぞれの出典付きで。
ラッパーとプラットフォームの詳細を表示
エージェントのランタイムプラットフォーム
NVIDIA OpenShellは別のカテゴリです。常駐するゲートウェイが各エージェントに専用のコンテナかMicroVMを与え、ネットワークの手前にポリシーエンジンを置きます。ai-jailは1つのコマンドを包み、それと一緒に終了する1つのプロセスです。以下は執筆時点、まだ1.0リリース前だったOpenShellのドキュメントに基づいています。
| OpenShell | ai-jail | |
|---|---|---|
| サンドボックスを動かすもの | Docker、Podman、Kubernetes、KVMのいずれかで動くゲートウェイデーモン。エージェントは同梱のコンテナイメージの中で動きます。 | バイナリだけです。エージェントは、マシンにすでにあるコンパイラやランタイムを使って、あなたのプロジェクトに対して動きます。 |
| ネットワーク | デフォルトで拒否。ルールはプログラム、ホスト、ポートで照合し、オプションでメソッド、パス、MCPツールも検査できます。拒否されたエンドポイントは運用者側から承認できます。 | 無効、ホスト単位のフィルタ付き、全開の3つ。フィルターは名前空間の柵とCONNECTプロキシで、ホストとポートは見えますが中身は見えません。許可したホストは丸ごと信頼されます。--forward-portで中継したホストのループバックのポートも同じく丸ごと信頼され、ルールはありません。 |
| 認証情報 | ゲートウェイが仲介してリクエストごとに注入し、サンドボックスのディスクには決して書きません。 | 環境にそのまま置かれます。ハーネス自身のログイン情報はデフォルトで読み書き可能でマウントされ、--envや--env-from-fileで渡したものは中のすべてから見えます。--no-agent-stateを付けるとログアウト状態での実行になります。ツールの認証情報（--github、--aws、--kube、--gcloud、--docker-config）はオプトインの読み取り専用マウントで、読み取り専用でも使用は防げないとドキュメントに明記されています。 |
| 隔離の上限 | MicroVMドライバなら本物の仮想マシンの境界が得られ、サンドボックスは停止、再起動でき、ワークスペースも保持できます。 | カーネルをホストと共有し、設計上は使い切りです。悪意のあるコードには使い捨てのVMを使うよう、自身のドキュメントに書いてあります。 |
| macOS | Docker DesktopのLinux VMの中で動きます。macOSのホストはポリシーの対象外です。 | ホスト上で生成するネイティブのseatbeltプロファイル。 |
| テレメトリと安定性 | 匿名のテレメトリがデフォルトで有効で、オプトアウトできます。ポリシーの形式はまだ変わり続けています。 | テレメトリはありません。新しいバージョンは古いバージョンが書いた設定を必ず読め、テストがそれを保証します。2026年9月に独立した2つのソースコード監査がリポジトリで公開され、その結果が2.4.0の修正につながりました。 |
ai-jailのリポジトリにある比較文書docs/openshell-comparison.mdは双方向に書かれていて、ホストの許可リストはそこから生まれました。
併用についての質問
エージェント自身のサンドボックスとプロンプトは切るべきですか？
プロンプトとルールは残してください。個々のコマンドを審査するのはそちらの役目で、ai-jailはそれをしません。エージェントのOSサンドボックスは、Linuxでは事情が違います。入れ子のbubblewrapサンドボックスに必要なシステムコールをai-jailがブロックしており、この組み合わせが動くとはドキュメントに書かれていません。ジェイルの中でエージェントが「サンドボックスを利用できない」と報告しても、ジェイル自体は機能しています。
ai-jailはDockerより安全ですか？
境界としては同じ種類です。どちらもカーネルをホストと共有し、どちらも仮想マシンではありません。ai-jailはすべて閉じた状態から始まり、イメージもデーモンもrootも要りません。コンテナは指示されたものをマウントし、Dockerソケットをマウントすればホストのroot相当になります。悪意があると考えるコードには、使い捨てのVMを使ってください。
ホストの許可リストは、エージェント自身のものと何が違いますか？
エージェントのプロキシは、サンドボックス内のプログラムが自分で使うことを選ばなければ効きません。ai-jailでは柵がカーネルです。Linuxではサンドボックスが専用のネットワーク名前空間を保ち、出口はプロキシだけです。macOSではseatbeltのルールがプロキシのポートへの外向き通信だけを許可します。そのため、
http_proxyを無視するプログラムはどこにも届きません。UDPは対象外なので、Linuxではサンドボックス内のDNSが失敗し、macOSではシステムのリゾルバに柵がかかりません。接続の中身も検査しないので、許可したホストは丸ごと信頼されます。--networkや--browserとは併用できません。Claude Codeしか使いません。それでもai-jailは必要ですか？
執筆時点で選択肢は3つあります。組み込みサンドボックスはシェルコマンドをカバーします。Anthropicの
@anthropic-ai/sandbox-runtimeはベータ版のリサーチプレビューで、プロセス全体を包みます。ai-jailもプロセス全体を包みます。ホームディレクトリと環境変数を閉じた状態から始まり、後でほかのエージェントを試すときにも同じポリシーを使えます。Anthropicによるサンドボックス環境の比較も参照してください。エージェントを檻の中に
ai-jailは単一のバイナリで、デーモンもroot権限も要りません。いつものコマンドの前に1語足すだけです。
brew tap akitaonrails/tap && brew install ai-jailai-jail claude