AIエージェントにシェルを渡すと、テストの実行から依存パッケージの追加まで、人手を介さずに作業が進むようになりました。
その裏で増えたのが、「このコマンドを実行してよいか」という確認です。
Anthropic のエンジニアリングブログは、中身を見ずに許可してしまう「承認疲れ」が安全性を下げると指摘し、サンドボックスで社内の確認回数が84% 減ったと報告しています。
確認は減らしたいけれど、安全は手放したくない、と感じたことはないでしょうか？
その両立のために各社が用意しているのが、エージェントの実行環境を隔離するサンドボックスです。
サンドボックスは「動いたあと」を閉じ込める
サンドボックスとは、エージェントのコマンドを OS の囲いの中で実行し、触れるファイルと通信先を限る仕組みのことです。
混同しやすいのが、どのツールやコマンドを使わせるかを決める権限設定です。
Claude Code の公式ドキュメントは、この2つを別々の層として説明しています。
権限ルールは、コマンドが動く前に、その文字列を見て通すかどうかを決めるものです。
一方のサンドボックスは、動いているプロセスそのものを OS が制限する仕組みで、許可したコマンドが名前以上のことをしても境界は保たれます。
受付の名簿確認が権限設定、建物の壁がサンドボックス、と考えると分かりやすいでしょう。
入口で止めそこねても、壁の外には出られないという二段構えになるわけです。
OpenAI の Codex の公式ドキュメントも、境界を決めるのはサンドボックス、越える前に尋ねるかを決めるのは承認ポリシー、と分けて説明しています。
承認ポリシーの側、つまりどこで人に尋ねるかの設計は、ヒューマン・イン・ザ・ループの記事で整理しました。
動く前に止める側には、名前で判定する権限ルールのほかに、ツールの実行直前に自前のスクリプトで判定を差し込むフックという手段もあります。
フックが止められるものと止められないものは、別の記事で整理しました。
なお、モデルの入力と出力を検査するガードレールは、さらに別の層です。
ガードレールの置き方は、こちらにまとめました。
閉じ込める対象は「ファイル」と「ネットワーク」
囲う対象は、大きく分けてファイルとネットワークの2つです。
Claude Code の場合、コマンドが書き込めるのは作業ディレクトリ・セッション用の一時ディレクトリ・明示的に追加したディレクトリに限られます。
ネットワークは外側のプロキシを通り、既定で許可済みのドメインは無く、新しい宛先ごとに確認が出る仕組みです。
囲いを作るのは OS の機能で、macOS では Seatbelt、Linux と WSL2 では bubblewrap が使われています。
大事なのは、片方だけでは役に立たないことです。
Anthropic は、ネットワークを隔離しなければ SSH 鍵などを外へ送り出せ、ファイルを隔離しなければ囲いを抜けてネットワークに手が届く、と説明しています。
ファイルとネットワークは、必ずセットで閉じるのが基本です。
乗っ取りの入り口として代表的なのが、外部の文章に紛れ込ませた指示です。
その仕組みは、こちらの記事にあります。
もう一つの落とし穴が、読み取りの範囲です。
既定の読み取り範囲は一部を除いてコンピュータ全体で、~/.aws/credentials や ~/.ssh も読めてしまいます。
Claude Code の v2.1.187 以降は sandbox.credentials で、読ませないファイルと消しておく環境変数を指定できるようになりました。
公式ドキュメントの例から該当部分を抜き出すと、次のとおりです。
{
"sandbox": {
"enabled": true,
"credentials": {
"files": [
{ "path": "~/.aws/credentials", "mode": "deny" },
{ "path": "~/.ssh", "mode": "deny" }
],
"envVars": [
{ "name": "GITHUB_TOKEN", "mode": "deny" }
]
}
}
}組み込みの拒否リストは無く、書いたファイルと変数しか守られない点にも注意が必要です。
壁をどこに立てるかで、隔離の強さが変わる
囲いを置く場所は、ひとつではありません。
Claude Code の環境比較ページによると、コマンド単位の囲いが対象にするのは Bash・PowerShell・Monitor のコマンドとその子プロセスだけです。
MCP サーバーやフックは、ホスト上でそのまま動くと明記されています。
プロセスごと囲う sandbox runtime、コンテナ、仮想マシンと外側へ行くほど、ファイル操作のツールや MCP サーバーも内側に収まっていきます。
独自のカーネルを持つ仮想マシンが最も強い分離で、信頼できないコードを扱うときの選択肢とされています。
承認を丸ごと省く --dangerously-skip-permissions は、必ずコンテナ・仮想マシン・sandbox runtime の中で動かす、というのが同じページの指示です。
壁の位置を、最初からタスクの定義に書き込む流れも出てきました。
Google が 2026年9月20日に公開した、エージェントの実行基盤 AX の v0.3.0 がその一例です。
リソース上限つきのサンドボックスで信頼できないコードを動かす Task や、外向きの通信を許可リストの宛先に絞る Gateway を、マニフェストとして宣言する形をとります。
README には安定版までに大きな破壊的変更が入る見込みとあり、本番投入はまだ待ったほうがよさそうです。
権限設定だけでは防ぎきれない場面
権限と囲いを重ねる意味は、実例を見るとよく分かります。
2026年9月20日に報告された Claude Code の Issue #95615 は、その典型例です。
バージョン 2.1.278 で permissions.deny に Bash を書いてツールごと禁止しても、Monitor ツール経由でシェルのコマンドが実行されたという内容です。
一方、Bash(touch:*) のようなコマンド単位の拒否は Monitor にも効いたと報告されています。
報告者の言葉を借りれば、弱く見える書き方が効き、強く見える書き方が効かないという逆転です。
2026年9月22日時点で、この Issue はオープンのままでした。
権限ルールは名前や文字列で判断するため、同じことができる別の入り口から漏れてしまうのです。
名前で止める権限と、プロセスを囲うサンドボックスは、守る場所が違うと考えておくと、設定の穴に気づきやすくなります。
もう一つは、取り込むコードそのものが差し替わる問題です。
AIR Security は 2026年9月17日、プラグインのコミット固定を、ハッシュと同じ名前のブランチで迂回できる脆弱性「Plugin4Shell」を公表しました。
同社によれば、Claude Code は 2.1.179、Codex は 0.146.0 で修正済みで、GitHub Copilot は未修正だそうです。
Claude Code のプラグインはフックや MCP サーバーを含められるので、コマンド単位の囲いだけでは拡張の動きまで閉じ込められません。
最後に
サンドボックスは、コマンドを OS の囲いで動かし、ファイルと通信先を限る仕組みでした。
権限設定が「動く前に名前で止める」のに対し、サンドボックスは「動いたあとを閉じ込める」という役割分担です。
コマンド単位の囲いで足りなければ、無人で回すならプロセスごと、信頼できないコードなら仮想マシンと、壁の位置を用途で選ぶことになります。
設定に手を入れる前に、何が壁の内側で何が外側かを一度書き出しておくのが近道だと、今の私は考えています。
以上です。
コメントを残す