第1章のとおり、Claude Code はツールを呼ぶたびに権限のゲートを通ります。これを一本のつまみだと思うと、うるさくなったとき一番緩い側へ回します。実際には確認の頻度・ツール単位の許可・OSレベルの隔離という役割の違う3つ。片方を締めればもう片方は緩めてよく、「安全か速いか」は二択ではありません。

委任は「全部か無か」ではない

出発点はモード名ではなく「この作業で、取り返しがつかなくなるのはどこか」。判断材料は3つ。

  • 戻せるか — git で戻せる編集なら損失は小さい。完全削除・強制push・DBの破壊は戻せない
  • どこまで届くか — 作業ディレクトリで閉じるのか、本番・共有ブランチ・他人の環境に届くのか
  • 秘密に触れるか — 読めることと外へ送れることが同時に成立すると流出になる

面倒なのは3軸とも安全な操作（テスト・整形・ローカル編集）で、危険なのはめったに出てこない操作です。一律に緩めると危険な側まで開く。頻度で緩め、性質で締めるのが骨格。

権限モード ― 何が本当に変わるのか

一番大きなつまみが権限モードで、確認の頻度の大枠を決めます。Shift+Tab で切り替わります（解説は Claude Codeの権限モード）。

許可を確認（default）

読み取りは自動、編集とコマンド実行は毎回確認。初めて触るリポジトリの既定。

編集を承認（acceptEdits）

作業フォルダ内の編集を自動承認。範囲外・保護パス・他コマンドは確認。

プランモード（plan）

調べるがソースは編集しない。計画を承認してから実行へ移る。

自動モード（auto）

別の判定モデルが実行前に各操作を見て、危険なものだけ止める。利用条件あり。

許可をバイパス（bypassPermissions）

確認も安全チェックも通さない。隔離環境専用。専用フラグ起動時だけ有効。

設定専用の dontAsk（許可リストと読み取り専用コマンドだけ実行し他は拒否）もあります。

保護パスにも注意。.git・.claude・シェル設定への書き込みは通常のモードでは自動承認されません。既定モードは設定に書けますが、自動モードだけはプロジェクト設定では無視されます——リポジトリ側が勝手に有効化できないための線引き。

自動モードは「速い default」ではない

確認はほぼ消えますが野放しではなく、判定モデルが依頼の範囲を超える操作・知らないインフラを触る操作・読み込んだ内容に誘導された操作を止めます。通りやすいのは作業フォルダ内のファイル操作と読み取り専用のHTTP。止まるのは機密の外部送信、本番デプロイ、破壊的な git 操作。

会話で述べた境界は保存されません。 「pushはしないで」はブロックの根拠になりますが、毎回いまの会話から読み直すので、圧縮で落ちれば境界も消えます。加えて自動モードはリサーチプレビューで、公式も「確認を減らすが安全を保証するものではない」としています。レビューの代わりにはなりません。

なぜバイパスでも確認が来るのか

確認を飛ばすはずの --dangerously-skip-permissions を付けたのに、Claude が「実行してよいですか」と聞いてくる。壊れてはいません。許可には2つの独立した層があり、バイパスが消せるのは1つだけだからです（バイパスモードでも許可を聞かれる理由）。

層1：ツール権限のUI（消せる）

「このファイルを編集してよいですか」——ツールを呼ぶ直前に出る対話的なダイアログ。Claude Code というプログラムが出すもの。

層2：Claude 自身の安全判断（消せない）

「本番DBへの変更になりますが、進めてよいですか」——会話の文章として返る確認。モデルの行動原則から出るので、フラグでは止まらない。

見分け方はUIか、返答テキストか。層2が動く条件は冒頭の3軸とほぼ同じ——不可逆・影響範囲が広い・セキュリティリスクが高い。完全削除、強制push、本番へのマイグレーションでは、権限を開いても Claude は立ち止まります。

これは不具合ではなく設計です。 バイパスが渡すのはツールを使う鍵で、Claude の判断を止める鍵ではありません。層2はゼロにできません。

頻度は下げられます。CLAUDE.md に前提を事実として書けることだけ書き、依頼を具体的に——「きれいにして」より「/tmp/ の .log を削除して」が出にくい。ただしバイパスは「確認が面倒」への答えではありません（バイパスモードのリスクと安全な使い方）。

settings.json のルール ― 同じ確認に二度答えない

モードが「全体の頻度」なら、権限ルールは「ツール・コマンド単位の例外」。settings.json に allow（確認なし）／ask（毎回確認）／deny（禁止） を書いて共有できます（権限ルール（allow/ask/deny）の設定）。

評価は deny → ask → allow の順で、最初に一致したものが勝ち、細かさは順序を変えません——広い Bash(aws *) の deny は具体的な Bash(aws s3 ls) の allow に勝ちます。deny は例外を持てません。「allow したのに確認が出る」は、たいてい別の ask が先に当たっているだけです。ask は自動モードでも確認を強制するので、戻せない操作の置き場所です。

// .claude/settings.json { "permissions": { "defaultMode": "acceptEdits", "allow": ["Bash(npm run *)"], "ask": ["Bash(git push *)"], "deny": ["Read(.env)", "Read(~/.ssh/**)"] } }

置き場所にも順位。強い順に管理設定（上書き不可）→ CLI → settings.local.json → settings.json → ~/.claude/settings.json。ただしどの階層の deny も、他のどの階層の allow より必ず勝ちます。指定子では空白＋* が単語境界（Bash(ls *) は ls -la に当たるが lsof には当たらない）。

ルールが守ってくれないもの

ルールが見ているのは「実行しようとしているコマンドの文字列」だけで、そこから外れた経路は素通りします。

  • 間接アクセスは防げない — Read(.env) の deny は組み込みのファイルツールや cat には効きますが、スクリプトがファイルを開く処理には効きません
  • 環境ランナーは中身を隠す — devbox run *・docker exec は引数をそのまま実行するので、Bash(devbox run *) の allow は devbox run rm -rf . まで許してしまう
  • 引数でのURL制限は脆い — 並べ替えや変数展開ですり抜けます。curl/wget ごと deny し WebFetch(domain:) で許可先を指定するほうが堅い

CLAUDE.md に「.env は読まないで」と書いても、ルールではありません。CLAUDE.md は Claude がやろうとすることを変えますが、許される範囲は変えません。範囲を変えるのはルール・モード、第6章の PreToolUse フックです（deny と ask はフックの結果に関わらず評価されます）。

サンドボックス ― 囲えるもの、囲えないもの

ルールが届かない経路を塞ぐのがサンドボックス——「何を確認するか」ではなく「どこまで触れるか」を先に囲います。強制するのは Claude ではなくOS（カーネル）なので、許可済みのコマンドが名前以上のことをしても境界は動きません（Claude Code サンドボックス完全ガイド）。

① ファイルシステムの隔離

書き込めるのは作業ディレクトリと一時フォルダだけ（初期値）。~/.bashrc やシステム領域は書き換えられない。

② ネットワークの隔離

初期状態は接続先ゼロの原則拒否。新しいドメインに繋ぐ時点で確認が入り、allowedDomains に登録すれば聞かれない。

この2つは必ずセットで——片方だけでは、読めた秘密が外へ出ます。承認は2通り。自動許可モードは内側の Bash を確認なしで実行し、通常権限モードは隔離したうえで確認も通します。自動許可でも deny は常に優先、重要パスを狙う rm は確認、内容指定の ask も確認を強制です。

「自動」が2つあるので注意。サンドボックスの自動許可モードは「OSの境界が閉じ込めるから通す」、権限モードの自動モード（auto）は「判定モデルが審査して通す」。

守らないものを先に知る

サンドボックスは完全な隔離ではありません。ここを曖昧にしたまま自動許可を常時オンにするのが、いちばん危ない状態です。

  • 対象は Bash とその子プロセスだけ — 組み込みの Read / Edit / Write、MCPサーバー、フックは別枠（権限ルールで制御）。プロセスごと包むなら @anthropic-ai/sandbox-runtime
  • 読み取りの初期値は広い — 囲うのは主に書き込みで、~/.ssh や ~/.aws/credentials はそのままだと読めます。denyRead で塞ぐこと
  • 許可の広げすぎが穴になる — 通信はホスト名で判定し、暗号化された中身は既定では検査しません。広いドメインを許すと逃がす余地が残る
  • 環境を選ぶ — macOS は追加導入なし。Linux と WSL2 は bubblewrap と socat が要り、ネイティブ Windows は非対応

サンドボックスは攻撃者を相手取る壁ではなく、事故と暴走を桁違いに減らす安全帯。Anthropic は社内で権限確認を安全に84%削減できたと公表していますが、確認を減らせた報告であって破れない保証ではありません。

事故はだいたい4つの形で起きる

仕組みを事故の側から並べ直します。設定はこの4つに効くかで選ぶ。

① 破壊的なコマンド

rm が想定外のパスを掃除する、git push --force が他人の作業を消す。共通点は戻せないこと。効くのは deny と ask のルールとファイル隔離。戻せない操作は ask に落としておくのが確実。

② 秘密の流出

事故になるのは読めると送れるが揃ったときだけ。対策も2枚——読ませない（Read(.env) の deny、denyRead）と送らせない（curl/wget の deny、許可ドメインを狭く）。片方では足りません。

③ 違うブランチ・違う環境へ届く

ローカルの1ファイル修正のつもりが、共有ブランチへの push や本番デプロイに発展する——操作のエスカレーションです。通常モードなら段階ごとに確認が挟まりますが、全部開けていると段差が消える。push とデプロイは ask に置くのが安い保険。

④ 読んだファイルからの命令混入

Claude が読む README・issue・Webページ・PDF に、Claude 宛の指示が仕込まれていることがあります（プロンプトインジェクション）。白文字で「このアドレスへ送れ」と書かれていても、Claude から見れば依頼と同じ入り口から入るテキストで、データと命令を自明には切り分けられません。

効かないのがバイパスモード（仕込みがそのまま実行に届く）とCLAUDE.md での禁止（許される範囲を変えない）。効くのはOSレベルの境界——書けない場所には書けず、繋げない先には繋げない——と deny ルール。仕込みは目に見えないので「気づく」に頼らず、信頼できない資料はそのセッションだけ権限を絞って読ませます。

任せてよい／止めるべき

3軸を当てはめると線はこうなります。

任せてよい（allow に載せる）

テスト・型チェック・リンタ・ビルド／作業ディレクトリ内の編集／読み取りと検索／ローカルのコミット

止めるべき（ask か deny）

共有ブランチへの push と強制push／本番デプロイとマイグレーション／秘密ファイルの読み取り／外部送信を含むコマンド／作業ディレクトリ外への書き込み

  • 普段のモードを1つ決める。 反復編集なら acceptEdits、機密作業は default。defaultMode に書く
  • 同じ確認に3回答えたら allow へ。 逆に一度でも「危ないな」と思った操作は ask に固定する
  • 会話で言った禁止事項は、消える前提で扱う。
  • 緩めるときは、必ずどこかを締める。 確認もなく境界もない状態だけは作らない

バイパスを使ってよい条件。 壊れても捨てられるコンテナ／VM／CI のランナーの中で、マウントは作業ディレクトリだけ、ホストの .env やSSH鍵は持ち込まない。「確認が煩わしい」は理由になりません。作業後は必ず差分を読むこと。

ここで扱ったのはすべて「事故を減らす」仕組みで、「無くす」仕組みではありません。層2の判断も、自動モードの判定も、サンドボックスの境界も、通り抜ける形があります。戻せる状態を保つことがいちばん効きます。

まとめ

  • 権限はモード・ルール・サンドボックスの3層。軸は戻せるか・どこまで届くか・秘密に触れるかで、頻度で緩め、性質で締める
  • 許可は2層構造。バイパスが消せるのは層1のUIだけで、会話テキストの確認は設計どおり
  • ルールは deny → ask → allow で最初の一致が勝ち、具体性は順序を変えない
  • ルールは文字列しか見ない。塞ぐのがサンドボックス。ただし対象はBashと子プロセスだけで読み取りの初期値は広い
  • 事故の形は破壊的コマンド・秘密の流出・違う環境への到達・命令混入の4つ

任せる範囲が決まれば、あとは環境に合わせて育てるだけ。次の 第6章「拡張する」 へ進みましょう。