はじめに
Claude Code（Anthropic が提供する AI 開発エージェント CLI）を使っていて、コマンド実行時に OS レベルで動作を制限する「サンドボックス」という機能があることを知りました。
「サンドボックスがあるから安全」と聞くと、なんでも守ってくれる魔法の箱のように感じていたのですが、Claude Code 自身に質問しながら掘り下げていくと、サンドボックスが担当している範囲と、担当していない範囲がはっきり分かれていることが分かりました。
この記事では、macOS で使われている「Seatbelt」という仕組みを入り口に、
- サンドボックスは具体的に何を防いでいるのか
- 逆に何を防げないのか
- 防げない部分は誰が（何が）カバーしているのか
について自分がインプットした内容を整理します。
認識が間違っている！って箇所があったらぜひコメントください！
サンドボックスとは何か？
まず前提として、Claude Code には「built-in sandboxed Bash tool」という仕組みがあり、ターミナルコマンド（Bash ツール）を実行する際、そのコマンドとその子プロセスを OS レベルで隔離された環境 の中で動かしている、ということを知りました。
ここで自分が最初に誤解しかけたのが、「サンドボックス = Claude Code の動作すべてを守ってくれるもの」というイメージです。
実際には対象になるのはあくまで Bash ツールとその子プロセス だけでした。
ファイルの読み書き（Read/Edit/Write）は別の権限システムで、画面操作（Computer use）はまた別の枠組みで守られている、と教えてもらって、範囲を勝手に広く捉えていたことに気づきました。
- macOS: OS 組み込みの「Seatbelt」というフレームワークを利用（追加インストール不要）
-
Linux / WSL2:
bubblewrap（ファイルシステム分離）とsocat（ネットワーク中継）を使用
どちらも目的は同じで、「万が一 AI が意図しない操作をしても、被害の範囲を限定する」ことだそうです。
参考: Claude Code 公式ドキュメント - Sandboxing
Seatbelt が防いでくれること
Seatbelt は、ざっくり言うと 「どこにアクセスできるか」という境界線を引く 仕組み、というのが自分の理解です。
| 制限対象 | 具体的にできること |
|---|---|
| ファイルシステム | 許可したディレクトリ以外への書き込みをブロック |
| ネットワーク | 許可していないドメインへの通信をブロック |
| 認証情報 | 設定すれば特定のファイルへのアクセス拒否や環境変数のマスクが可能（※デフォルトでは保護されないものもある。後述） |
たとえば「~/projects の中だけ書き込み OK、それ以外は禁止」といった設定ができ、AI が誤って関係ないファイルを壊すリスクを抑えられる、という説明にはなるほどと思いました。
Seatbelt が防いでくれないこと
ここが今回一番学びになったポイントです。
Seatbelt は境界線を引くだけで、その境界の中で「何が行われるか」の中身までは判断しない ということを知りました。
公式ドキュメントにも、下記のように書かれていました。
The operating system enforces the sandbox boundary on the running process, so it holds regardless of what the model chose to run and even if an allowed command does more than its name suggests.
「OS はサンドボックスの境界を実行中のプロセスに対して強制するため、モデルが何を実行したかに関わらず、また許可されたコマンドが見かけ以上のことをしていたとしても、その境界は保たれる」という一文で、まさに「境界の中身までは判断しない、あくまで境界そのものを機械的に守るだけ」ということが明言されていました。
1. 許可した範囲の中身の妥当性
たとえば ~/projects への書き込みを許可していれば、Seatbelt はその中で「正しいファイルを書いているか」「変な内容を書いていないか」までは基本的にチェックしないそうです（denyRead/denyWrite のような個別の除外ルールを別途設定すれば、許可範囲の中でもさらに絞り込むことは可能とのこと）。
あくまで「アクセスできる場所」を制限する仕組みであって、コマンドの意図や書き込む内容の妥当性までは判断しない、という切り分けを初めて理解しました。
2. 暗号化された通信の中身
デフォルトでは、サンドボックスが使う 組み込みのネットワークプロキシ は通信先ホスト名の許可リストで制御するだけで、TLS 通信の中身までは検査しないそうです（終端・検査させる設定は実験的機能として別途用意されているとのこと）。
許可したドメイン（例: api.github.com）への通信であれば、その中に何のデータが乗っていても「正当な通信」として扱われる、というのは少し意外でした。
つまりドメイン単位の粗いフィルタであり、情報漏洩を細かく防ぐ仕組み（DLP）ではない、と理解しています。
3. 許可済み認証情報の誤用
これは特に「知っておいてよかった」と思ったポイントです。
~/.aws/credentials や ~/.ssh/ のようなファイルは、デフォルトのままだと読み取りが許可されている場合がある ことが公式ドキュメントに明記されていました。
Default read behavior: read access to the entire computer, except certain denied directories. Note that this default still allows reading credential files such as
~/.aws/credentialsand~/.ssh/.
保護したい場合は sandbox.credentials や filesystem.denyRead で明示的に除外設定をする必要がある、とのことでした。
また、次の記述の通り、組み込みの拒否リストは存在せず、明示的に設定したファイル・変数だけが制限される仕組みなので、読み取りを許可した認証情報を使って実際に何をするか（どの API を叩くかなど）までは、サンドボックスの制御対象外だそうです。
There is no built-in credential deny list, so only the files and variables you list are restricted. The setting affects sandboxed Bash commands only.
4. Bash 以外のツール
ファイルの読み書き（Read/Edit/Write）や画面操作（Computer use）は、そもそも Seatbelt の対象外でした。
これらは別の仕組み（後述の権限承認システム）で守られている、という住み分けを知りました。
5. サンドボックス自体の脆弱性
この built-in Bash sandbox は、独自のカーネルを持つ「仮想マシン（VM）」のような強い分離ではなく、ホスト OS の Seatbelt 機構を使って Bash コマンドと子プロセスのファイル・ネットワークアクセスを制限する、比較的軽量な仕組みだと知りました。
OS のサンドボックス機構自体に脆弱性が見つかる可能性もゼロではないため、「絶対に破られない壁」ではなく、多層防御の一部と捉えるべき、という説明に納得しました。
では「中身の判断」は誰がしているのか？
Seatbelt が見ていない「中身の妥当性」は、実は 複数のレイヤーが役割分担 してカバーしている、ということが今回一番の発見でした。
ポイントは、これらが一直線に並んだ順番というより、「実行前 にチェックする層」と「実行中 に効く層」に分かれていることです。
【実行前】AI がツール利用を提案
↓
【実行前】Hooks（PreToolUse）… 機械的な禁止パターンで先に拒否できる
↓
【実行前】権限ルール・権限モード … コマンド内容を見てユーザーに確認を求めるか判断
↓
【実行前】ユーザーの最終承認 … 提示された内容を見て実行してよいか判断
↓
【実行中】OS サンドボックス（Seatbelt 等）… Bash 実行中、ファイル・ネットワークの境界を強制
これとは別に、「危険な操作をする前に確認を取る」「rm ではなくゴミ箱に移動する」といったルールを、AI がユーザーの設定ファイル（Claude Code では CLAUDE.md）から読み取って自分で気をつける、という層もあるそうです。
ただしこれは OS レベルの強制ではなく、モデルの推論に依存する柔らかい防御 であり、上図のような確定的な境界ではなく、AI の挙動を誘導するものだと理解しました。
Hooks（フック）
ツール実行前（PreToolUse）などのタイミングで、任意のチェック処理を挟み込める仕組みです。
「このパターンのコマンドは機械的に拒否する」といったルールを追加でき、権限プロンプトが出るより前に動作するとのことでした。
権限承認システム
Bash コマンドを実行する前に、コマンドの内容（rm -rf なのか ls なのか）を見て、ユーザーの設定に応じて実行前に確認を求めるかどうかを決める仕組みです。
ここがメインの防御ラインだと理解しています。
最終的にはユーザーの承認
Hooks や権限ルールを通過したとしても、最終的に「実行してよいか」を判断するのはユーザーである、という点が印象に残りました。
AI が提案した変更やコマンドを確認し、実行を承認するかどうかが、人間による最後のチェックポイントになるようです。
OS サンドボックス（実行中の境界）
ここまでの層をすべて通過して Bash コマンドが実際に実行される段階になって、はじめて Seatbelt のような OS レベルのサンドボックスが働きます。
コマンドの意図が正しいかどうかではなく、「実行中にアクセスできる場所」を機械的に制限するのがこの層の役割、というのが自分なりの理解です。
まとめ
- built-in sandboxed Bash tool（Seatbelt など）は、Bash コマンド実行中に「どこにアクセスできるか」という境界を守る仕組み
- 「何をするか」という中身の妥当性は、実行前の別レイヤー（Hooks・権限承認システム・ユーザーの最終承認）や、AI 自身の自己抑制（絶対ではない）が担当している
- デフォルト設定を過信せず、
~/.aws/credentialsのように保護されていない場合があるファイルは明示的に設定を見直したほうがよさそう - 単一の仕組みで完全に安全になるわけではなく、多層防御 の考え方で成り立っている
「サンドボックスがあるから安心」で思考停止せず、それぞれの層が何を守り、何を守っていないのかを知れたのは今回大きな学びでした。
同じように「サンドボックスって結局何なん？」と思っていた人の参考になれば嬉しいです。