Claude Codeのサンドボックスは、権限ルールの強化版ではありません。別の層です。 denyやallowのルールは「エージェントに何を許すか」を決めます。サンドボックスが決めるのは「ルールが漏れたとき、被害がどこまで届くか」。この2つを同じ層だと考えていると、ルールを書き足すことが対策のすべてになり、漏れた日に守るものがなくなります。
この記事は、Claude Codeにコマンド実行を任せている人と、これから無人運用まで進めたい人に向けて、実行環境の隔離を3段——Bashサンドボックス、Dev Container、クラウド実行——で整理します。権限ルールの設計そのものは、先に4層モデルの記事にまとめてあります。今回はその最後の層、「エージェントの外側」の話です。
Claude Codeの権限設定4層ガイド｜denyを厚くするだけでは守れないClaude Codeの権限設定を「渡さない・許す・止める・外側で強制」の4層で設計する方法を解説します。allowルールのワイルドカード警告や--restrictedフラグなど直近の公式アップデートを根拠に、hooksによる禁止だけでは塞げない穴と、各層の使い分けを実運用の構成で整理します。www.tentspace.net
なぜ権限ルールだけでは足りないのか
私はSNS運用のRoutineをClaude Codeの無人実行で回していて、破らせたくない操作はhooksのBashガードで実行前にブロックしています。この構成は機能していますが、ルールで守る方式には構造的な弱点が1つあります。ルールは書いた通りには効かず、実装された通りに効くことです。
以前の記事で、2.1.260で修正された「書いたdenyが効かない3つの穴」——括弧入りパスの無視、コンパイル不能パターンによる検査の停止、変数代入に隠したコマンド置換——を取り上げました。あのときの結論は、要するにdenyルールは書いたら検証する、というものでした。ただ、公式チェンジログを追い続けると、話はもう一段深いところにあると分かってきます。
修正履歴が示す、ルールが漏れる3つの形
直近2リリースだけでも、権限ルールの適用範囲に関する修正が続いています。一次情報は公式チェンジログです。
Claude Code公式チェンジログRelease notes for Claude Code, including new features, improvements, and bug fixes by version.code.claude.com
2.1.268（2026-09-10）: symlinkされたディレクトリに権限ルールが適用されない不具合の修正。 パスのルールは、シンボリックリンクを経由すると別の表記になります。人間には同じ場所でも、ルールの照合では別物。パス表記の正規化が絡む漏れは、2.1.250〜251のsymlink差し替え追従、2.1.260の括弧入りパスに続いて、私が数えた範囲でこれが3度目です。
2.1.269（2026-09-11）: ! で始まるdeny/askルールが、それを書いたsettingsソースの外まで効いていた不具合の修正。 以後は自分のソース内だけに適用されます。これは逆向きの漏れで、書いた範囲より広く効いていました。狭く漏れる穴だけでなく、広く漏れる穴もあるわけです。
同じく2.1.269: Edit() のdenyルールと書き込みパス検査が、Bashの tee が書くファイルに適用されていなかった不具合の修正。 Bash(tee:*) を許可していると、その許可が作業ディレクトリ外への書き込みまで覆っていました。編集ツールを閉じても、別の経路が同じ結果に到達できたことになります。
3つに共通するのは、ルールの文法を正しく書けていても防げなかった点です。漏れは書き方ではなく、パスの正規化、適用範囲の解決、ツール間の経路といった実装の継ぎ目で起きています。修正が続いていること自体は健全ですが、裏を返せば、いま書いてあるルールにも未発見の継ぎ目があると考えて運用する方が安全です。
ここが今回の出発点です。ルールは検問であって、壁ではない。検問はすり抜けられる前提で、すり抜けた先に壁を置く。それが実行環境の隔離です。
実行環境の隔離は3段ある
Claude Codeの実行環境を隔離する方法は、守る範囲の狭い順に3段に整理できます。この3段構成は、クラスメソッドの検証記事の整理がそのまま使えます。
クラスメソッド: Claude Codeの実行環境隔離を3段で整理なぜ実行環境の隔離が必要なのかまずご説明し、次に具体的な隔離手法を3つご紹介。最後にはじめの一歩もご提案します。dev.classmethod.jp
| 段 | 隔離の単位 | 守る範囲 | 導入の重さ |
|---|---|---|---|
| Bashサンドボックス | コマンド実行 | ファイルアクセスとネットワーク | 設定のみ |
| Dev Container | プロジェクト | 開発環境ごと | コンテナ定義が必要 |
| クラウド実行（Claude Code on the web） | セッション | 手元のマシン全体 | 環境の初期設定が必要 |
1段目はBashサンドボックスです。 Claude Codeが実行するコマンドを、OSレベルの仕組みでファイルアクセスとネットワークの面から制限します。導入は設定だけで済むので、ローカルで対話的に使うなら最初に入れる壁はここです。1点だけ注意があり、サンドボックス内で失敗したコマンドをサンドボックスの外で再試行する動きを許すと、壁の意味が薄くなります。前述のクラスメソッド記事は sandbox.allowUnsandboxedCommands を false にしてこの再試行を止める設定を推奨していて、私も同じ判断です。壁は、例外の通用しない壁であるほど設計が単純になります。
2段目はDev Containerです。 コマンド単位ではなく、プロジェクトの開発環境ごとコンテナに隔離します。依存パッケージのインストールもビルドもコンテナの中で完結するので、npmの依存を大量に触るプロジェクトでは、侵害されたパッケージが動いても手元のマシンには届きにくくなります。ネットワーク制御には、公式リポジトリの .devcontainer にあるファイアウォール設定の参照実装（init-firewall.sh）が使えます。許可した宛先以外への通信をコンテナ側で落とす構成です。
3段目はクラウド実行です。 Claude Code on the webでは、セッションそのものがAnthropic管理の隔離されたコンテナで動きます。リポジトリは起動時にcloneされ、環境は使い捨て。ネットワークの到達範囲は、環境を作るときにポリシーとして選びます。手元のマシンにはそもそも何も触らせないので、守る範囲としては最も広い壁です。
Claude Code公式: Claude Code on the webRun Claude Code sessions in the cloud from your browser, phone, desktop app, or terminal, move them with --cloud and --teleport, and auto-fix pull requests.code.claude.comどの段を選ぶか——作業の形で決める
3段は排他ではなく、作業の形で使い分けるものです。私の判断軸は3つあります。
1つ目、その作業は手元のマシンで動く必要があるか。 ローカルのファイルを対話的に編集する日常の開発なら、Bashサンドボックスを常時有効にするのが基本線です。導入コストがほぼゼロで、日々のコマンド実行に壁が入ります。
2つ目、依存の出入りが激しいか。 警戒すべき主戦場は、侵害されたnpmパッケージのような供給連鎖側にあります。npm install を頻繁に走らせるプロジェクト、初見のOSSを検証する作業は、コマンド単位の壁よりプロジェクト単位のDev Containerが向きます。マルウェアはClaude Codeのコマンドとしてではなく、依存のインストールスクリプトとして動くからです。
3つ目、人が見ていない時間に動くか。 無人の定時実行は、事故に気づく人間がその場にいません。私は日次のRoutineをクラウドの使い捨て環境で回す形にしています。手元のマシンと認証情報を実行環境から物理的に切り離せるので、無人運用との相性で選ぶならここです。
ひとつ補足すると、この3段はどれも「実行環境」の壁で、公開や課金のような外部への副作用は守ってくれません。私の運用では、SNSへの公開回数の上限をエージェントの外側、サーバー側のストレージに置いています。実行環境の隔離と、副作用の上限は別の壁。この使い分けは権限4層の記事に書いた通りです。
壁は外側しか守らない——持ち込むものの棚卸し
3段のどれを選んでも、効き目を決める変数がもう1つあります。壁の内側に何を持ち込むかです。先のクラスメソッド記事の言葉を借りれば、壁はその外側しか守りません。コンテナで完全に隔離しても、その中に本番の認証情報を持ち込めば、侵害されたパッケージから見える場所に置いたことになります。
私が棚卸しに使っている問いは3つです。
- 認証情報: この環境から読めるトークン・APIキー・認証済みCLIはどれか。その作業に本当に必要か。読み取り専用や範囲を絞ったキーへ差し替えられないか。
- コード: リポジトリ全体を渡す必要があるか。特に、別プロジェクトの秘密が同じホームディレクトリから読める配置になっていないか。
- 依存: この作業でインストールされるパッケージはどこまで信頼できるか。インストールが走る場所は壁の内側か。
隔離を強くする方向の議論は「壁を増やす」に寄りがちですが、実務で効くのは持ち込むものを減らす側です。壁が1枚でも、内側に秘密がなければ盗まれるものがありません。逆に壁が3枚あっても、全部の内側に同じトークンを置いたら、壁は1枚と同じです。
まとめ——ルールの次に、壁を1枚
権限ルールの修正履歴は、「ルールは実装の継ぎ目で漏れる」ことを繰り返し示しています。だからルールを書くのをやめるのではなく、漏れた先を用意しておく。整理すると次の順番です。
- 権限ルールとhooksは今まで通り書く。ただし壁ではなく検問として扱う
- ローカル作業にはBashサンドボックスを有効化し、サンドボックス外での再試行は止める
- 依存の出入りが激しい作業はDev Containerへ、無人運用はクラウド実行へ寄せる
- どの壁を選んでも、内側に持ち込む認証情報・コード・依存を先に棚卸しする
ルールを1行足すより、壁を1枚立てて持ち込みを1つ減らす方が、守れる範囲は広いことが多いです。denyの網を編み続けている人ほど、一度この順番で見直してみてください。