--restrictedは「Claude Codeにサンドボックスが搭載された」ということと同じなのか?
違う。公式ドキュメントはこの点を明確にしている。--restrictedは、見知らぬリポジトリのレビューや範囲の狭いCIタスクの実行に適した、有用な低権限の出発点だが、オペレーティングシステムレベルのサンドボックスでは「ない」。これが行っているのは、Claude Codeというアプリケーション自体がアクセスできるツール、ファイル範囲、設定の出所を縮小することであり、OSレベルでプロセス全体、ネットワーク接続、認証情報へのアクセスを隔離しているわけではない。
もしあなたの状況が「この入力はまったく信頼できず、しかも任意のコードを実行できる必要がある」というものであれば、公式が推奨するのは、プロセス全体を強化されたコンテナやVMの中に置き、Claude Code自身のサンドボックス制御を別のレイヤーとして追加適用することだ。--restrictedはこのプロセスの一部にはなり得るが、「信頼できない入力を隔離する」という役割を単独で担うことはできない。
なぜ「ユーザー、プロジェクト、ローカル設定が無視される」ことと「MCPサーバーは影響を受けない」ことを別々に扱い、一緒に締め付けないのか?
これは、この2種類の設定がそもそも異なる性質を持っていることを反映している。ユーザー、プロジェクト、ローカルという3層の設定ファイルは、主に「その人やそのプロジェクトが普段どうClaude Codeを使っているか」という個人的な好みや慣習だ。これらを無視することで、このセッションが別のプロジェクトで身についた習慣的なルールをうっかり引き継がないようにできる。一方MCPサーバーは「外部システムへの接続点」であり、それが存在すべきかどうかは、通常今のタスクが実際にある外部サービスに接続する必要があるかどうかに関わる問題であり、「個人の慣習」とはまったく異なる次元の問題だ。
もし--restrictedがMCPサーバーまで自動的にクリアしてしまえば、内部ツール(例えば読み取り専用の社内ナレッジベースMCPサーバー)に本当にアクセスする必要がある、範囲の狭いタスクにとっては手足を縛られることになり、別の方法でそれを戻さなければならなくなる。「個人設定をクリアすること」と「MCP接続を維持するかどうかを決めること」を2つの独立した決定に分ける(後者は--strict-mcp-configによって能動的にトリガーする必要がある)ことで、ユーザーはタスクの実際の必要性に応じてそれぞれを調整でき、全か無かを強いられることがない。
--restrictedを純粋な読み取り専用のリポジトリレビューに使いたい場合、実際にこれらのオプションをどう組み合わせればよいのか?
最も直接的な組み合わせ方は、ツールリストとMCP設定の両方を同時に明示的に宣言することであり、単に--restrictedをオンにして自動的に読み取り専用になることを期待するのではない。実務ではこのような組み合わせになる。--restricted --tools "Read,Grep,Glob" --strict-mcp-config --mcp-config ./restricted-mcp.json——--toolsで読み取り系のツールのみを明示的に列挙し、コマンドを実行したりファイルを編集したりするツールは含めない。--strict-mcp-configは、自分で用意した、内容が空か本当に必要なサーバーのみを含むMCP設定ファイルと組み合わせ、他の出所からのMCPサーバーが予期せず関与しないようにする。
もしこのレビューの過程で本当に編集が必要だとわかった場合、より保守的なやり方は、範囲が非常に狭いファイル編集ツールを別途追加し、保護されたファイルへの承認メカニズムを維持することであり、--restricted全体の効果を緩いBash権限に丸ごと置き換えて、それでもこのセッションは「低権限」だと自分に言い聞かせることではない。コマンドを実行するツールを一度復元してしまえば、それはもう--restrictedが本来維持しようとしていた低権限の状態ではなくなっている。
もしチームに既に組織管理の設定(managed settings)がある場合、--restrictedを使う際に特に気をつけるべきことは何か?
最初に確認すべき最も重要な点は、管理設定が--restrictedによって回避されないということだ——つまり、もしあなたの組織が既に管理設定を通じて特定のセキュリティポリシー(bypassPermissionsの無効化、特定の高リスクツールの制限など)を強制している場合、それらのポリシーは--restrictedセッション内でも引き続き有効だ。--restrictedが組織の既存の防御を意図せず弱めてしまう心配はない。
しかし逆に注意すべき点もある。--restrictedが無視するのはユーザー、プロジェクト、ローカルの3層だ。もしチームが特定のセキュリティ関連のカスタムルール(追加のdenyルールなど)を管理設定ではなくプロジェクトレベルの設定ファイルに書く習慣があるなら、それらのルールは--restrictedセッション内では無視される——つまり、特定のリスクを補強するためにプロジェクトレベルのルールに依存していた場合、--restrictedによってその補強が一時的に無効になってしまう可能性があるということだ。こうしたルールを管理設定の層に格上げすべきかどうかを別途確認し、どのような起動方法でも継続して有効になるようにする必要がある。
Claude Code 2.1.248(2026年8月27日)は、--restrictedという起動フラグと、それに対応する環境変数CLAUDE_CODE_RESTRICTED=1を新たに追加した。このモードの位置づけは明確だ。オペレーティングシステムレベルのサンドボックスではなく、デフォルトで権限を最小限に絞り、どの機能を一つずつ戻すかを自分で決められる起動設定であり、まだ信頼関係を築いていない、見知らぬコードベースを扱う際に特に適している。
--restrictedを有効にすると、組み込みのコマンド実行・コード実行ツール(Bashなど)とWebFetchが、--toolsで明示的に名指ししない限りデフォルトで削除される。同時にユーザー、プロジェクト、ローカルという3層の設定ファイルを無視し、ファイルツールのアクセス範囲は起動時の作業ディレクトリ(および--add-dirで追加したディレクトリ)に限定され、権限確認を完全にスキップするbypassPermissionsモードも拒否される。
1つ目の誤解は、「設定ファイルが無視される」ことが「すべての設定が無効になる」ことを意味しない、という点だ。組織が管理する設定(managed settings)、そして--settingsで明示的に指定した設定ファイルは、依然として有効だ。「ユーザー、プロジェクト、ローカル設定が無視される」ということだけを見て、このセッションが完全にクリーンだと思い込み、背後で管理設定が動いていないかを確認しなければ、実際の権限範囲を見誤る可能性がある。
2つ目の誤解は、MCPサーバーの扱いが他のツールとは異なるという点だ。--restricted自体は既存のMCP設定を自動的にクリアしない。外部のMCPサーバーが一切関与しないことを保証する必要がある場合は、別途--strict-mcp-configを追加し、自分で用意し内容を確認したMCP設定ファイルと組み合わせる必要がある。--restrictedを単に有効にしただけでは、MCPという経路も一緒に締め付けられるわけではない。
もしこれまでやってきたことが、Bashのワイルドカードルールの見直しと絞り込み(例えば範囲が広すぎるBash(git *)をより正確なルールに変更するなど)であれば、それは「コマンド実行ツールが既に存在する」という前提のもとで、そのツールが実行できるコマンドを制限するものだ。--restrictedが対処するのは、それよりも一段階前の問題だ——このセッションにおいて、コマンド実行・コード実行ツール自体がそもそも存在すべきかどうかというもので、デフォルトの答えは「存在しない」に変わる。あなたはそれを戻すかどうかを能動的に決める必要があり、デフォルトで存在した状態からルールで範囲を絞り込んでいくのとは逆のアプローチだ。
より堅実な始め方は、まず実際に動いているバージョンを固定することだ(インストール方法やインターフェースによって異なるバージョンを指している場合があるため、まず--versionが実際に何を出力するかを確認する)。それから、本番環境の認証情報を含まない、範囲の小さいディレクトリから始めるべきであり、便利だからといってホームディレクトリやモノレポのルートから直接起動すべきではない。--add-dirはファイルツールが到達できる範囲を直接拡大するため、追加するディレクトリ一つひとつについて、まずなぜ必要なのかを明確にする価値がある。単純な読み取り専用のコードレビューのシナリオでは、--tools "Read,Grep,Glob"を明示的に列挙し、サーバーを一切含まないMCP設定ファイルと組み合わせる方が、まず有効化してから事後に確認するよりも明確だ。