すでにAuto Modeを有効にしている場合、サンドボックスを別途設定する必要はありますか？
必要があり、両者は互いに代替できない。Auto Modeが制御するのは「このツール呼び出しを実行すべきかどうか」で、クラシファイアがその動作内容をどう判断するかに依存する。サンドボックスが制御するのは「そのコマンドが実行後にどのファイルシステムパスとネットワークドメインに到達できるか」で、OSレベルで強制される境界に依存する。この2層はそれぞれ異なるリスクをカバーしている：Auto Modeが見逃した動作でも、サンドボックス境界が十分厳格であれば、実際の被害を安全な範囲に封じ込められる可能性がある。逆に、サンドボックス境界をどれだけ厳しく設定しても、子プロセスを生成しないツールタイプ（Read、Edit、WebFetch、MCP呼び出し）は管理対象外であり、これらは完全に権限ルールに依存して管理される。一方の層だけを有効にすることは、もう一方の層の攻撃面をそのまま露出させることに等しい。
サンドボックスのauto-allowモードと権限レイヤーのAuto Modeは名前がよく似ていますが、同じものの2つの呼び方ですか？
違う。これは公式ドキュメントが特に明確にしている点だ。サンドボックスのauto-allowモードがBashコマンドを毎回の確認なしで実行させるのは、そのコマンドがすでにサンドボックス境界に封じ込められているからだ——それが何か有害なことをしようとしても、実際に到達できる範囲は限られている。権限レイヤーのAuto Modeがツール呼び出しを毎回の確認なしで実行させるのは、クラシファイアがその動作内容を審査し、安全だと判断したからだ。
この2つは同時に、かつ独立して動作できるが、「確認する」ことの代わりとなるメカニズムは完全に異なる——一方は範囲外のアクセスを阻止する硬い境界であり、もう一方は内容に対する柔らかい判断だ。両方の名前に「auto」が含まれているからといって同じ層が管理していると思い込むと、自分の実際の保護範囲を誤判断しやすい。
--dangerously-skip-permissionsを使うと、サンドボックスも一緒にスキップされることになりますか？
いいえ、そこがこのフラグが誤解されやすい点だ。--dangerously-skip-permissionsが制御するのは権限レイヤーだ——これはすべてのツール呼び出しの承認要件を取り除き、保護対象パスのチェックすらスキップし、確認の代わりとなるものは何もない。しかしサンドボックスは権限レイヤーとは完全に独立した別のメカニズムであり、それが有効かどうかはあなた自身のサンドボックス設定（例えばsandbox.enabled）に依存し、このフラグを追加したかどうかとは直接関係がない。
これはまた、見落とされがちなリスクを示している：権限レイヤーをスキップし、かつサンドボックス設定を別途有効化または強化していない場合、2つの防御が同時に破られることになり、どのツール呼び出しもフィルタリングされず、実際に到達できるファイルシステムやネットワークの範囲にも境界がまったくない状態になる。このフラグの名前には「dangerously」という言葉がそのまま入っている——使う前に、サンドボックスの層が独立して機能を保っているかを必ず確認すること。
セキュリティの専門家ではありませんが、自分の自動化パイプラインがこの落とし穴に陥っていないか確認したいです。最も簡単な確認方法は何ですか？
最初からすべての設定キーを覚える必要はない。まず一つだけやってみるといい：現在Claudeに自動実行を許可しているツールのリストを見つけ、そのリストの中でBash、PowerShell、あるいは類似のコマンドラインツールを呼び出す項目について、サンドボックスがそれを明確で安全なディレクトリ範囲に制限しているか、それともシステム全体へのアクセスがデフォルトで開かれているままかを確認する。答えが「サンドボックス設定は特に調整していない」であれば、おそらく現在は権限レイヤーだけに依存して守っている状態であり、実際のサンドボックス範囲は想定よりもかなり広い可能性がある。
設定を確認した後は、安全なテスト環境を用意し、「ツール呼び出しは許可されているが、触れるべきでないパスやドメインに触れようとする」状況を意図的に再現し、それが実際にサンドボックスによって止められるかを観察してみるとよい。このテストは、どんな設定ドキュメントを読むよりも、自分の本当の防御線がどこにあるかを教えてくれる。
「Auto Modeをオンにしたから、大きな問題は起きないはずだ」——この一言の裏には、よくある誤解が潜んでいる。「Claudeが行動してよいかどうか」と「Claudeが行動した後に何に触れられるか」を、同じものとして管理していることだ。これらは実際には完全に独立した2つの防御層であり、一方は「このツール呼び出しに事前承認が必要かどうか」を決め、もう一方は「承認された後、そのコマンドが実際にどのファイルやネットワークドメインに触れられるか」を決める。この2つの層を混同することは、チームがClaude Codeの自動化パイプラインを設定する際に最もよく犯す、そして最も実害につながりやすい間違いだ。
公式ドキュメントはこの2層の分業を明確に定義している：権限ルール（permission rules）は、あらゆるツールが実際に実行される前に評価され、Bash、Read、Edit、WebFetch、MCPなどほぼすべてのツールタイプに適用され、「このツール呼び出しがそもそも実行を許可されるべきか」を決める。それに対してサンドボックスは、OSレベルで強制される境界であり、Bash、PowerShell、Monitorといった子プロセスを生成する類のコマンドにのみ適用され、「そのコマンドが実際に実行される際、どのファイルシステムパスとネットワークドメインに到達できるか」を決める。
この2つは、強制の仕方も異なる。権限の判断はコマンドが実行される前に、コマンド文字列そのものと、Auto Modeにおいては別のクラシファイアがそのコマンドの安全性についてどう判断するかに基づいて行われる。一方でサンドボックス境界は、実行中のプロセスに対してオペレーティングシステムが直接強制するものであり、これはモデルが何を「実行しようと選んだか」に関係なく機能する。つまり、承認されたコマンドがその名前から予想される以上のことをした場合でも、サンドボックス境界はそれでも有効に働く——それが監視しているのはモデルが何を選んだかではなく、そのプロセスが実際に何に触れたかだけだ。
コミュニティ記事「Claude Code Permission Modes in 2026」（著者：jsmanifest）は、直接的な失敗事例を示している：ある設定がrun_commandというツールの呼び出しを許可したが、Bashサンドボックスを安全なディレクトリツリーに制限することを忘れていた——結果として、エージェントはrm -rf /のようなコマンドを何の抵抗もなく実行できてしまった。ここでの重要な点は、「このツールの呼び出しを許可する」ことと「そのツールがシステムのどの部分に到達できるか」は、完全に別々の設定項目であり、前者を許可したからといって後者が絞られているとは限らないということだ。
同じ記事は、もう一つの本番環境での事例も記録している：あるチームがコードレビューのワークフローにPromptモード（毎回確認を求める方式）を設定し、npm audit fixのリクエストを承認したが、サンドボックスの設定では/node_modulesがroot権限で読み書き可能としてマウントされていた。権限審査のこの層は問題なく通過したが、サンドボックス分離のこの層は、パッケージインストール時に発生しうる悪意ある挙動を、あるべき範囲内に封じ込めることができなかった。この事例が示しているのは、権限レイヤーをどれだけ丁寧に設定しても、サンドボックス境界がそれに整合していなければ、防御は同じように回避されてしまうということだ。
Claude Codeの公式ドキュメントは、比較表でこれを直接示している：/sandboxが制御するのは「Bashコマンドが実行後に何にアクセスできるか」であり、毎回の確認プロンプトの代わりとなるのはサンドボックス境界そのもの（auto-allowモードの場合）だ。一方、Auto mode（権限モードの一種）が制御するのは「各ツール呼び出しが実行されるかどうか」であり、確認プロンプトの代わりとなるのは、その動作内容を審査するクラシファイアだ。そして--dangerously-skip-permissionsも同様に「各ツール呼び出しが実行されるかどうか」を制御するが、確認プロンプトの代わりとなるものは何もない——保護対象パスのチェックすらスキップされ、どのモードでも自動承認されない少数の動作だけが制限され続ける。
ドキュメントはまた、サンドボックスのauto-allowモードと権限レイヤーのAuto modeが、互いに代替可能ではない2つの独立したメカニズムであることを強調している。auto-allowがBashコマンドを確認なしで通過させるのは、サンドボックス境界がすでにそれを封じ込めているからだ。Auto modeがツール呼び出しを確認なしで通過させるのは、クラシファイアがその動作内容を安全と判断したからだ。両者は同時に、かつ独立して動作できるが、それは同時に、一方の層が緩く設定されていても、もう一方の層が自動的に補ってくれるわけではないことも意味する。
実際に設定を調整するなら、公式ドキュメントが示す対応関係は非常に具体的だ。ファイルシステム側では、sandbox.filesystem.allowWriteが作業ディレクトリ以外のパスへのサブプロセスの書き込みアクセスを許可し、sandbox.filesystem.denyWriteとdenyReadが特定のパスへのアクセスを封鎖する。これらは権限レイヤーのEdit許可ルールやRead／Edit拒否ルールとは別に設定されるが、最終的にはサンドボックスの実際の設定にマージされる。ネットワーク側では、サンドボックスのallowedDomains／deniedDomainsがBashコマンドが到達できるドメインを制御し、これも権限レイヤーのWebFetch(domain:...)許可／拒否ルールとは別の設定群だ。つまり、「このパスに書き込めるかどうか」という同じ問いが、権限ルールとサンドボックス設定の両方から同時に影響を受けており、実際の境界がどこにあるかを知るには両方を確認する必要がある。
その理解は正確ではない。サンドボックス境界の強制力が確かに硬いのは事実だ——それはOSレベルの制限であり、モデルが何を選んだかではなく、プロセスが実際に何に触れたかだけを見る。これは、承認されたコマンドが予想以上のことをしても、サンドボックスが境界を越えたアクセスを止められることを意味する。しかしサンドボックスがカバーするのはBash、PowerShell、Monitorといった子プロセスを生成するツール群だけであり、Read、Edit、WebFetch、MCP呼び出しといった他のツールタイプは、完全に権限ルールのレイヤーに依存して管理されている。2つの層はそれぞれ異なる攻撃面をカバーしており、どちらも欠かせない——「サンドボックスが十分厳格なら権限ルールは気にしなくていい」という単純化された考え方は成立しない。
各設定キーの名前を覚えることよりも、まず自分自身に2つの問いを立てる方が実用的だ。Claudeがあるツールの呼び出しを承認された場合、そのツールが実際に実行時に到達できるファイルシステムの範囲は十分に狭いか。そしてサンドボックス境界をどれだけ厳しく設定しても、あるツールカテゴリ（例えばMCP呼び出し）がサンドボックスを完全に迂回し、権限ルールだけに依存して管理されていないか、そしてその権限ルール自体が十分に絞られているか。どんな自動化パイプラインも本番投入する前に、この2つの問いそれぞれについて実際にテストしておく価値がある——許可された動作が触れるべきでないものに意図的に触れようとさせ、それが本当にブロックされたかを自分の目で確認することだ。設定を書いたから機能するはずだと仮定してはならない。