「Claude Codeの権限は絞ってあるので大丈夫」という説明を、中小企業の導入担当者から聞くことがある。だが公式ドキュメントを読み込むと、Claude Codeの安全機構は単一の仕組みではなく、役割の違う複数の壁の積み重ねでできていることが分かる。一つを設定しただけで残り全部が守られるわけではない。何がどこまでを担当しているかを整理する。

全体像：役割の違う4つの壁

Claude Codeの公式ドキュメントによると、安全機構は次の4つに分かれている。

仕組み何を守るか誰が判定するか
許可ルール（allow/deny/ask）Bash・ファイル読み書き・WebFetch・MCPなど、ほぼ全ツールの呼び出し可否Claude Codeが自前のルールで判定
フック（PreToolUse）許可ルールでは表現しきれない独自の判断（特定ファイルへの書き込み拒否など）自社で書いたスクリプト
サンドボックスBashコマンドとその子プロセスが触れるファイル・通信先OSのレベル（macOSのSeatbelt、Linux/WSL2の専用パッケージ）
auto modeの分類器確認プロンプトを省略していいかどうかの自動判定許可ルールとは別に動くAIの分類モデル

この4つは「後の仕組みが前の仕組みを補完する」関係にあって、順番に効く。まず許可ルールのdenyが先に効き、それを通過したものだけがフック・サンドボックス・auto modeの判定に進む。どれか一つを厚くしても、別の壁の穴はふさがらない。

適用条件と例外——見落としやすい3点

denyは常に勝つが、勝つのはその許可ルールの中だけ。 許可ルールはdeny→ask→allowの順で評価され、拒否ルールは他のどんな許可設定があっても覆らない。ユーザー設定でdenyしたものを、プロジェクト設定でallowしても効かない。ただし、この「常に勝つ」はあくまで許可ルールという1つの壁の中の話で、サンドボックスやauto modeとは別軸の仕組みだという点を混同しないほうがいい。

サンドボックスが守るのはBashだけ。 ファイルの読み書きに対するdenyルールは、Claude自身が呼ぶReadやEdit、Bash経由のcatやsedのようなコマンドには効くが、Pythonスクリプトなどが自分でファイルを開く場合は対象外になる。OSレベルで全プロセスの通信・ファイルアクセスを縛りたいなら、許可ルールとは別にサンドボックスを有効にする必要がある——両者は同じものの二重設定ではなく、守備範囲が異なる別レイヤーだ。

auto modeの信頼設定は、あえてプロジェクト単位の設定ファイルからは読まれない。 auto modeがどこを「社内で信頼できる場所」と見なすかを決めるautoMode.environmentは、個人の設定（~/.claude/settings.json）と組織の管理設定からしか読み込まれず、リポジトリに含まれるプロジェクト設定は対象外になっている。これはリポジトリ自体やビルド手順が「ここは信頼できる」という設定を勝手に書き込んで、分類器の判断を歪める余地を塞ぐための設計だ。

自社で何を設定すべきか

3つの壁それぞれに役割があるとわかると、導入時に確認すべき順番も見えてくる。

まず、消してはいけない操作は許可ルールのdenyで塞ぐ。以前紹介した本番のTerraformインフラを丸ごと消してしまった事故のような取り返しのつかない操作は、auto modeの分類器任せにせず、denyで確実に止める層を持っておくのが筋がいい。分類器の判定はプロンプトの書き方次第で揺れうるが、denyルールは分類器より手前で機械的に効く。

次に、8月14日からPro/Max/Teamプランで既定になったauto modeを使う場合は、autoMode.environmentを初期状態のまま放置しない。何も設定しなければ「自社のリポジトリと現在の作業ディレクトリ」以外はすべて未知の外部として扱われる仕様なので、自社のドメインやクラウドのバケットを自分で書いて教えておかないと、日常業務のたびに引っかかる。逆に、pushやPR作成の前に必ず人の目を通したいなら、会話の中で「レビューまでpushしないで」と伝えるだけでは文脈が圧縮されて消えることがあるので、permissions.askにルールとして書いておくほうが確実だ。

最後に、プロンプトインジェクションのような自分の判断力を乗っ取られる攻撃への備えとしては、サンドボックスの出番になる。Claudeの意思決定そのものが操られた場合でも、OSレベルの壁があれば被害の範囲を縮められる。逆に言えば、承認ダイアログに出ているコマンドが実際に実行されるコマンドと食い違っていた不具合のように、許可ルールの実装自体にバグが見つかることもある——ここは「AIの判断」ではなく「ハーネス側の実装」の問題で、ベンダーの修正を待つだけでなく、自社でもサンドボックスのような独立した壁を重ねておく理由になる。

「権限は絞ってある」を安心材料にする前に、絞ってあるのがどの壁なのかを自社で把握しておく。これもハーネスの考え方——AIの判断力そのものではなく、構造で安全を担保するという発想の一部だ。自社の運用でこの3層をどう組めばいいか整理したい場合は、パイロット・構築のフェーズで一緒に詰められる。まずは30分の無料診断から相談してほしい。