Claude Code CLAUDE.mdのセキュリティ設計と権限管理例

CLAUDE.mdはセッションのたびに読む“方針メモ”としては優秀ですが、危険なコマンドや機密ファイルへのアクセスまで任せる場所ではありません。
Claude Codeを仕事で使うなら、方針はCLAUDE.md、強制は permissions・hooks・sandbox に分けるのが軸になります。

実際、モノレポで frontend だけ触っている間は軽く進むのに、backend 配下のファイルを読んだ途端に追加ルールがオンデマンドで効き始め、承認ダイアログの出方が変わる場面があります。
『Claude があなたのプロジェクトを記憶する方法』にある読み込み順を踏まえると、この挙動は整理して設計したほうが事故を防げます。

一方で、既定の read-only のまま何でも承認制に寄せると、テスト実行のたびに手が止まりがちです。
テスト実行だけ先に許可すると作業テンポは改善することが多い一方で、command-matching の抜けや複合コマンドでは承認が期待どおり動作しないことがあります。
したがって、allow にする場合はパターンの網羅検証を行い、hooks（PreToolUse など）や隔離（sandbox／Dev Container）で補完する運用が推奨されます。

この記事では、最小権限・信頼境界・オンデマンド読み込み・Defense in Depth の4原則に沿って、既存のCLAUDE.mdからセキュリティ方針と実行制御を切り分ける方法を具体例で整理します。
読後には、危険コマンド、機密ファイル、未信頼リポジトリに対する多層防御を、自分の設定へそのまま落とし込める状態を目指します。

CLAUDE.md はセキュリティ設定ファイルではない

CLAUDE.mdをセキュリティ設定ファイルとして扱うと、まず設計が崩れます。
ここに書くべきなのは、プロジェクト全体で共有したい方針や前提です。
たとえば「基本はTypeScriptで実装する」「テストは npm test か pytest -q を使う」「破壊的変更は事前に意図を言語化する」といった、会話の土台になる情報です。
逆に、厳格な実行制御や毎回必須のブロック処理を押し込む場所ではありません。
CLAUDE.md はセッション開始時に読まれる永続的な文脈の共有レイヤーであり、アクセス制御の本体は別にあります。

この切り分けを曖昧にすると、CLAUDE.md がすぐ肥大化します。
実務では、プロジェクト共通方針、代表的なテストコマンド、要約した禁止事項だけに寄せたほうが保守しやすくなります。
たとえば「本番DBへ直接変更しない」「git push は人間が最終判断する」「機密ファイルは読みに行かない」のような短い原則は向いています。
一方で、rm の細かな禁止パターン、日々変わる運用手順、個人のエディタ設定、ローカル端末だけの事情は外に出したほうが崩れません。
長くなったら @docs/testing.md や @.claude/domain/backend.md のように import して分割し、頻繁には必要ない知識は skills 側へ逃がす、という設計が素直です。

私も最初は CLAUDE.md に「rmは禁止」とだけ書けば十分だろうと考えました。
実際に試すと、危険コマンドを自分から積極的に提案する挙動は目に見えて減ります。
ただ、そこで止まるわけではありません。
ツール実行レベルでの絶対的なブロックにはならず、あくまで「そう振る舞おうとする文脈」が強まる程度だと感じました。
だからこそ、危険操作を本当に止めたい場面では、会話上のお願いではなく settings.json の permissions、PreToolUse hooks、sandbox や Dev Container まで含めて受け持たせる必要があります。

既定の権限モデルは strict read-only で、編集やテスト実行、コマンド実行のような追加操作には明示許可が必要です。
書き込み範囲も、起動したフォルダとその配下に制限されます。
つまり土台の安全装置は CLAUDE.md ではなく、権限モデルと実行環境の側にあります。
CLAUDE.md はその上で「このプロジェクトでは何を優先するか」を短く共有する場所だと捉えると、役割がぶれません。

レイヤーごとの役割マップ

方針レイヤーと強制レイヤーを混ぜないために、役割を短く並べると次のようになります。

この整理で見ると、CLAUDE.md に書くべき内容は自然に絞れます。
たとえば「テストは npm test と pytest -q を優先」「git push や本番反映は人間承認前提」「秘密情報を含む .env や鍵ファイルは扱わない」といった一段抽象化した原則です。
反対に、「Bash(git push:*) は ask」「rm -rf は hook で deny」「docker は sandbox の対象」といった制御ロジックは settings.json か hooks に置くほうが筋が通ります。

モノレポでは分割の考え方も効きます。
共通の CLAUDE.md には全体方針だけを書き、backend 固有の制約は @backend/CLAUDE.md や .claude/rules/ に寄せるほうが文脈のノイズが減ります。
frontend を触っているのに backend の詳細ルールまで毎回読み込ませる構成だと、会話の前提が散っていきます。

CLAUDE.mdの読み込みタイミングとセッション内での効き方

CLAUDE.md の挙動を理解するうえで見逃せないのが、読み込みタイミングです。
プロジェクトの CLAUDE.md は ./CLAUDE.md または ./.claude/CLAUDE.md に置けて、起動時には親ディレクトリ側の CLAUDE.md が読み込まれます。
さらに、サブディレクトリ内の CLAUDE.md は、その配下のファイルを読んだときにオンデマンドで入ってきます。
前述のモノレポで frontend だけ触っている間は軽く、backend のファイルを開いた瞬間に追加ルールが効き始めるのはこのためです。

この性質は便利な反面、CLAUDE.md を万能ルール帳として使う発想とは相性がよくありません。
会話が長くなるほど、セッション冒頭で読んだ指示は相対的に古い文脈になります。
実務でも、前半では守れていたルールが後半で薄くなる場面は珍しくありません。
だから、守ってほしい方針は短く保ち、必要な場面でだけ注入したい詳細は .claude/rules/ や import 先に分ける設計が効きます。
コミュニティでは約500行以内に抑える運用がよく採られていますが、感覚としてもそのあたりを越えると「全部読ませる」発想が破綻し始めます。

書く内容の目安を具体化すると、共通 CLAUDE.md にはプロジェクトの目的、主要ディレクトリの役割、代表的なテストコマンド、要約済みの禁止事項だけを置くのが安定します。
たとえば「変更後は npm test または pytest -q を選んで実行」「破壊的なシェル操作は提案前に代替案を出す」「本番系資格情報には触れない」といった粒度です。
そこに「この週だけ有効な運用」「個人の端末事情」「頻繁に変わるCIの細部」まで入れると、更新のたびにノイズが増えて、結局読まれないファイルになります。

実行制御を担う設定は別レイヤーへ渡したほうが、一貫性も高まります。
たとえば settings.json でテストコマンドだけ先に許可し、git push は ask に回し、危険コマンドは PreToolUse hook で止める構成なら、CLAUDE.md が多少薄れても安全側に倒れます。
高権限の自律実行をさせる場面では、sandbox や Dev Container で環境ごと囲うほうが明快です。
Claude Code セキュリティが触れている Windows の WebDAV や \\* のような広いパス許可への注意も、まさにこの「文脈ファイルではなく実行境界で守る」という発想につながります。

要するに、CLAUDE.mdはセッションの最初に読む設計図のようなもので、鍵や扉そのものではありません。
方針、テストコマンド、要約した禁止事項を短く置き、詳細は @path/to/import で分け、実際の拒否や承認は permissions・hooks・sandbox に任せる。
この役割分担にすると、ルール逸脱もファイル肥大化も同時に抑えやすくなります。

まず押さえたい4つの設計原則

最小権限（Least Privilege）

最初の判断軸は、「読めるけれど、勝手には変えない・実行しない」状態から始めることです。
Claude Codeは既定で strict read-only に寄っていて、編集やコマンド実行には明示許可を求める設計です。
Claude Code 。
つまり初期状態は不便なのではなく、未信頼な入力を前提にした安全側の出発点と見るのが自然です。

この原則に立つと、permissions の設計も迷いにくくなります。
たとえば最初から enable all のような広い許可に寄せるのではなく、npm run test や pytest -q のように、日常的に繰り返す確認コマンドだけを allow へ足していく形です。
前のセクションで触れた通り、テスト実行だけを事前許可すると流れが整いますが、そこから先の権限まで一気に開放する必要はありません。
git push、ネットワーク経由の取得、破壊的な Bash は ask か deny に残しておくほうが、事故の入口を狭く保てます。

実際に未信頼のサンプルリポジトリをそのまま開いたとき、この設計の意味は体感でわかります。
ファイルを読むだけなら進む一方で、少し踏み込んでコマンドを走らせようとすると承認ダイアログが細かく挟まりました。
しかもネットワークアクセスは明示許可なしには通らず、外に出る操作だけがきちんと引っかかるので、「まず閉じておいて、必要な操作だけ開ける」ほうが運用の筋が良いと整理できます。
承認が多いと面倒に見えますが、未信頼な URL・リポジトリ・MCP を前提にするなら、その摩擦こそが境界線として機能します。

信頼境界（Trust Boundary）

次に意識したいのが、どこから先を未信頼として扱うかです。
ローカルの自分のコード、チームで管理しているリポジトリ、外部 URL、コミュニティ配布の設定ファイル、MCP サーバーは、同じ「コンテキスト源」に見えても信頼度が揃っていません。
とくに外部 URL と未検証リポジトリ、出所のはっきりしない MCP は、読み込んだ時点でプロンプトやツール実行の入口になります。

そのため、未信頼な URL・リポジトリ・MCP は既定で閉じるのが基本です。
開くとしても、permissions で広く通すのではなく、sandbox や Dev Container のような隔離環境を併用し、さらに hooks で危険な操作を機械的に検査する構成に寄せます。
CLAUDE.md に「外部コードは慎重に扱う」と書くだけでは境界線になりません。
境界線は、どのディレクトリに書けるか、どのコマンドを通すか、ネットワークへ出られるかで切る必要があります。

この考え方は、MCP を足す場面でも同じです。
MCP は『Model Context Protocol』として便利ですが、外部サービスへつながる窓口でもあります。
知らないサーバーをまとめて有効化するより、必要なものだけスコープを絞って追加するほうが自然です。
コミュニティで共有される設定例には便利なものが多いものの、そのまま開放すると、意図しないデータ参照や長大な出力を持ち込む入口が増えます。
信頼境界を先に引いておけば、「便利そうだから全部つなぐ」という設計を避けられます。

MCP を使用して Claude Code をツールに接続する - Claude Code Docs

Model Context Protocol を使用して Claude Code をツールに接続する方法を学びます。

code.claude.com

オンデマンド読み込み（On-demand Context）

文脈も権限と同じで、最初から全部読ませないほうが安全です。
Claude があなたのプロジェクトを記憶する方法では、親ディレクトリの CLAUDE.md は起動時に読み込まれ、サブディレクトリ内の CLAUDE.md はその配下のファイルに触れたときにオンデマンドで読み込まれると説明されています。
この挙動を前提にすると、ルートには全体方針だけを置き、詳細ルールはサブディレクトリや .claude/rules/ に分ける設計が合っています。

ここでの狙いは、初期セッションを軽く保つことだけではありません。
未信頼な情報を一気にセッションへ流し込まない、という意味でも有効です。
たとえば外部から持ち込んだサンプル群や検証用ディレクトリに独自の CLAUDE.md を置く場合でも、その領域へ触れるまでは読ませない構成なら、普段の作業文脈まで汚さずに済みます。
モノレポで frontend と backend の規約が分かれているときも、必要になった瞬間だけ追加ルールが入るので、常に全ルールを背負うより会話が散りません。

.claude/rules/ を領域別に分ける発想も、この延長線上にあります。
ルートの CLAUDE.md に広く効く原則だけを書き、backend だけで必要なレビュー観点や、特定のテスト手順だけを別ファイルへ逃がす形です。
毎回必須ではない知識まで冒頭で読ませると、セッション前半からノイズが増えます。
必要なときに必要な文脈だけ入れるほうが、ルールの密度を保ちやすく、未信頼な入力が混ざったときの影響範囲も小さくできます。

Defense in Depth

1つの仕組みで守ろうとせず、複数の層で役割を分けるのが実運用では欠かせません。
Claude Code のベストプラクティスが CLAUDE.md を短く保ち、毎回必須の動作は hooks に寄せるよう案内しているのも、この整理に沿っています。
実際の設計は、CLAUDE.md で方針を伝え、.claude/rules/ で領域別ルールを足し、permissions で通す操作を絞り、hooks で決定論的に検査し、sandbox や Dev Container で環境ごと隔離する、という重ね方になります。

この順番には意味があります。
CLAUDE.md は「こう振る舞ってほしい」という宣言、rules は「この領域ではこう動く」という補助線です。
そこに permissions が「そもそも何を実行できるか」を決め、hooks が「実行前後に何を確認するか」を強制します。
さらに sandbox や Dev Container が「仮に通っても外へ出にくい場所」に閉じ込めます。
どれか1つが崩れても、他の層で止まる余地を残す構造です。

たとえば .env や秘密鍵を読ませたくないなら、CLAUDE.md に禁止事項を書くより、permissions の deny と PreToolUse hook の両方で塞ぐほうが筋が通ります。
危険な rm -rf や git push --force を避けたい場合も同様で、方針だけに頼るのではなく、hooks で機械的にブロックする層が必要です。
CLAUDE.md 単体は便利なメモリですが、防御の中核にはなりません。
未信頼な URL・リポジトリ・MCP を前提にするなら、1枚の指示書ではなく、文脈・権限・実行・環境の4方向から絞る構成が実務向きです。

CLAUDE.md に書くべき内容、書かないべき内容

CLAUDE.md に向いているのは、プロジェクト全体でぶれずに共有したい「薄くて広い」情報です。
たとえば、どのディレクトリでも守る設計原則、やってはいけないことの要約、公式のテストやビルドの入口コマンド、レビューやコミット規約の要点はここに置く価値があります。
Claude Code の。
会話のたびに読む前提のファイルなので、細部まで詰め込むより、「このリポジトリでは何を優先し、まず何を打てば検証できるか」が一目で分かるほうが効きます。

たとえばテストコマンドなら、npm test、npm run build、pytest -q のように、そのプロジェクトでの標準形をそろえて書くのが実務向きです。
ここで大切なのは、派生コマンドを網羅することではなく、「まずこの入口から入る」という共通認識を作ることです。
レビュー規約も同じで、コミットメッセージの粒度や、レビュー時に確認する観点を短くまとめ、詳細なテンプレートや例外規定は別ドキュメントに逃がしたほうが保守しやすくなります。
CLAUDE.md は規約集の本体ではなく、案内板に近い位置づけです。

禁止事項も、ここでは要約に留めるのがちょうどいい落としどころです。
たとえば「本番データを直接編集しない」「無断で git push しない」「秘密情報を生成物に含めない」といった原則は有効ですが、危険コマンドを1つずつ列挙して厳密に止めようとすると、役割がずれていきます。
前述の通り、実行の強制やブロックは permissions や hooks の担当です。
CLAUDE.md に書くのは「何を避ける文化か」の宣言までで十分です。

私自身、最初は CLAUDE.md に手順を全部書けば迷わないと思っていました。
セットアップの流れ、例外対応、ディレクトリごとの注意点、レビュー時の細則まで1か所に寄せたところ、数週間で古い手順と新しい手順が混ざり、同じ作業に対して別の指示が並ぶ状態になりました。
読んでいる側もどれを優先すべきか判断しにくくなり、結局いちばん守られなくなったのは、その CLAUDE.md でした。

そこから、変更頻度の高い部分を .claude/rules/ やスクリプト側へ逃がし、CLAUDE.md には原則と入口だけを残す形に変えると、遵守率が目に見えて安定しました。
たとえば frontend と backend で別々のレビュー観点があるなら、ルートの CLAUDE.md には「詳細は .claude/rules/frontend.md と .claude/rules/backend.md を参照（例）」のように場所だけ示し、個別ルールは各領域に置くほうが矛盾が出ません。
本節では構文としての自動 import を前提にせず、あくまで詳細の所在を明示する参照として書いておく、という考え方です。
@path/to/import のような記法も、実装された機能として断定するのではなく、「詳細はこのパスを見る」という案内の発想で扱うのが無難です。

書かないほうがいい内容

逆に CLAUDE.md に入れないほうがいいのは、厳格な実行制御、頻繁に変わる詳細、個人環境の設定、そして機密情報そのものです。
たとえば「rm -rf を絶対禁止」「docker build は常に承認必須」といった制御は、文章で書くより設定で止めるべきです。
依存バージョンの細かなピン留め、暫定的な回避策、ローカルだけの PATH 設定、個人用エイリアスのような情報も、共有ファイルに置くほどノイズになります。

機密情報を書かないのはもちろんとして、「このファイルにシークレットがあるので読まないこと」といった生々しい配置情報も、必要以上に集約しないほうが安全です。
秘密の存在を教えるメモより、permissions や hooks で実際に読めない状態を作るほうが筋が通ります。
CLAUDE.md は文脈を渡す仕組みであって、防壁そのものではありません。

500行以内を目安に、地図として使う

長くなるほど、共通方針より枝葉の説明が増え、毎回読む価値の薄い文が混ざりやすくなります。
結果として、肝心のルールほど埋もれます。
短いファイルは上品だから良いのではなく、毎セッションで効かせたい情報だけが前面に残るから意味があります。

分割の発想も、この地図としての役割に沿っています。
ルートの CLAUDE.md では全体原則だけを示し、領域別の詳細は .claude/rules/ やプロジェクト内ドキュメントへ誘導する。
frontend の命名規約、backend のマイグレーション手順、運用チームだけが使う補足は、必要な場所に置いたほうが更新点が追いやすくなります。
CLAUDE.md は全部を抱える本体ではなく、「どこに何があるか」を最短距離で伝える目次として設計したほうが、肥大化もルール逸脱も抑えやすくなります。

.claude/rules/ とディレクトリ別 CLAUDE.md の使い分け

基本方針はルートの CLAUDE.md に置きます。
ここにはプロジェクト全体で共通する考え方だけを残し、領域固有の約束事は .claude/rules/ に分けてください。

この切り分けを運用で安定させるには、ルートの CLAUDE.md を「全員が最初に共有する前提」に限定し、frontend/、infra/、docs/ のような領域別ルールは .claude/rules/ へ逃がす構成が実務では扱いやすいのが利点です。
『Claude があなたのプロジェクトを記憶する方法』でも、CLAUDE.md は文脈を渡すためのメモとして整理されており、必要な場面で追加の文脈を読む設計と相性がいいことがわかります。
共通部分を薄く保ち、必要になったときだけ詳細ルールを読む形にすると、普段は軽く、深い場所では濃くというメリハリが付きます。

私自身、この分割に切り替えてから運用の摩擦が減りました。
frontend だけ触る人には JS/TS の規約だけが見えていれば足りるのに、以前は Terraform の注意点や運用手順まで毎回視界に入っていました。
逆に infra 担当が terraform/ を開いた瞬間だけ IaC 専用ルールが効く形にすると、確認ダイアログへの心理的な疲れが減るだけでなく、関係ない領域の作法を誤って持ち込む事故も減りました。
常に全部を読ませるより、必要な場所で必要なルールだけが立ち上がるほうが、承認疲れと誤操作の両方を抑えられます。

ハイブリッド構成の標準レイアウト例

実務でバランスが取りやすいのは、ルートの CLAUDE.md、領域別の .claude/rules/、そしてごく特殊なサブツリーに置くディレクトリ別 CLAUDE.md を組み合わせるハイブリッド構成です。
全体像としては、ルートに共通方針を置き、通常の分岐は .claude/rules/ で受け、さらに infra/prod/ のような濃い文脈が必要な場所だけ局所的な CLAUDE.md を置きます。

たとえばルートの CLAUDE.md には、「このリポジトリはモノレポである」「変更前後で npm test または pytest -q 系のテストを優先する」「禁止事項は要約だけを書く」といった全体方針を書きます。
ここでの禁止事項は、危険操作を一つずつ列挙するのではなく、「本番環境への直接変更はしない」「機密情報を生成物に含めない」程度に留めます。
書かない内容も明確で、厳格な実行制御、頻繁に変わるデプロイ手順、個人用エイリアスやローカル環境の癖は外に出します。

その結果、全体方針は薄く保ち、領域別の詳細は対象ディレクトリが必要になったときだけ注入する設計が扱いやすくなります。
必要なときに必要な文脈だけ入るため、普段は軽く深い場所では濃くというメリハリが付きます。

さらに infra/prod/CLAUDE.md のようなディレクトリ別ファイルは、例外が強い場所にだけ置きます。
たとえば本番用 Terraform では、通常の infra ルールに加えて「変更計画の確認順序」「適用前に見るべき差分の観点」など、サブツリー限定の濃いルールが必要になります。
この階層に入ったときだけ文脈を厚くするので、全員に同じ重さの指示を背負わせずに済みます。
2026年1月28日の changelog では --add-dir 経由でのディレクトリからの CLAUDE.md 読み込み改善も記載されており、こうした局所的なメモの運用は実際のワークフローとも噛み合っています。

モノレポでのpathsベース分割

モノレポでは、全ルールを最初から注入すると、関係ない規約が会話に混ざって判断を鈍らせます。
そこで効くのが paths ベースの分割です。
frontend/ に触れている間はフロントエンド向けの規約だけ、terraform/ や infra/** に入った瞬間に IaC 向けの追加ルールが効くようにしておくと、文脈のノイズが減ります。
段階的にガードを強める考え方なので、浅い階層では共通原則だけ、深い階層ではその場所に固有の注意点まで届きます。

この方式が機能する理由は、ルールの適用範囲をパスで切れるからです。
たとえば apps/web/ にはフロントエンドの lint・型チェック・コンポーネント命名、services/api/ には API 互換性やマイグレーションの観点、infra/prod/** には本番差分確認の手順を割り当てる、といった設計です。
共通原則はルートの CLAUDE.md に固定し、追加ルールは対象パスに入ったときだけ乗るので、frontend 作業中に backend の規約まで抱え込むことがありません。

実務では、この「不要な規約注入を避ける」効果が想像以上に効きます。
たとえば apps/web/ だけ触っているのに、インフラ用語や本番運用の注意が毎回混ざる状態では、どの指示が今の作業に関係するのかを毎回仕分ける必要があります。
paths ベースで切ると、その仕分けを人間がやらなくて済みます。
深い階層に入った瞬間にだけ追加ルールが効くので、モノレポ特有の情報過多を抑えながら、必要な場所では見落としも減らせます。

ここで押さえたいのは、paths ベース分割が「何でも細かく分ける」ことではない点です。
分割の単位は、規約が明確に変わる境界に合わせるのが自然です。
frontend/ と infra/ のように責務が異なる場所、docs/ のように成果物の性質が違う場所、infra/prod/ のように同じインフラでも緊張感が変わる場所に絞ると、ルールの意味がぶれません。
逆に、日々変わる手順や個人ごとの好みまで paths にぶら下げると、分割しただけで保守対象が増えます。

運用の感覚としては、ルート CLAUDE.md を薄く保ち、.claude/rules/ で広く受け、局所だけディレクトリ別 CLAUDE.md を足す三層がいちばん安定します。
モノレポでもルール逸脱を減らしながら肥大化を防ぎやすい構成です。

Claude Code のベストプラクティス - Claude Code Docs

環境設定から並列セッションでのスケーリングまで、Claude Code を最大限に活用するためのヒントとパターン。

code.claude.com

権限管理の実装例：安全な CLAUDE.md と settings の組み合わせ

この種の設計では、方針を書く場所と強制する場所を分けると、ルールの肥大化と逸脱が同時に抑えられます。
前述の通り、CLAUDE.md は共通前提を短く渡すメモであり、危険操作の可否まで背負わせるとすぐに重くなります。
そこで、ルートの CLAUDE.md には「全員に毎回読ませたい宣言」だけを残し、実際の許可・拒否は .claude/settings.json と hooks に寄せる構成が安定します。

概念例：settings.jsonのpermissions設計（注）

以下に示す settings.json の例は「概念例（説明用の断片）」です。
公式のキー名、matcher の書式、$schema 指定などはバージョンや実装により変化し得ます。
コピー＆ペーストでそのまま実運用しないでください。
実運用前には必ず公式の settings schema（公式ドキュメント）を参照して、$schema を明示し、キー名・matcher・パス表現を当該バージョンに合わせて調整してください。
本サンプルは役割説明に重きを置いた断片例です。

Claude Code の設定 - Claude Code Docs

グローバルおよびプロジェクトレベルの設定と環境変数を使用して Claude Code を構成します。

code.claude.com

sandbox・hooks・Dev Container で防御を1段深くする

どの操作をsandbox/Dev Containerに送るかの判断基準

permissions と hooks まで入れると、日常の編集やテストはだいぶ整います。
ただ、それでも「そもそもホストで実行させないほうがいい」仕事は残ります。
そこで効いてくるのが /sandbox と Dev Containerです。
役割の違いで言えば、permissions が「許可するか止めるか」を決める層、hooks が「決まった検査を毎回入れる」層、sandbox と Dev Containerは「動かす場所そのものを分ける」層です。

/sandbox の意義は明快で、高権限タスクや未検証コードの実行を、被害範囲を限定した環境に閉じ込めることにあります。
たとえば外部リポジトリを clone して npm install や docker build を試す場面では、依存スクリプトやビルド処理が何を読むかを人間が事前に追い切れません。
こういう仕事をホストでそのまま走らせると、作業ディレクトリ外のファイルや手元の資格情報に触れる余地が残ります。
sandbox に送っておけば、少なくとも「読まれて困る場所に最初から届かない」状態を作れます。

判断基準は、操作そのものより その処理がどこまで外へ伸びるか で見ると整理しやすくなります。
ビルド、パッケージ導入、外部スクリプト実行、未知のテストハーネス起動、コンテナ関連コマンドのように、内部で何が呼ばれるか読みにくい処理は sandbox 側に寄せるのが基本です。
逆に、既に中身が分かっているローカル編集や、狭く許可したテスト実行はホスト側でも回せます。
特に docker build のような高リスク操作は、承認だけで済ませるより、実行場所まで切り分けたほうが安全弁として効きます。

ここで Dev Containerを組み合わせると、隔離の粒度をもう一段深くできます。
Dev Containerは Docker ベースの開発環境に作業を閉じ込める手段で、ネットワーク、ボリューム、ユーザー権限を制御しながら、必要なツール群だけを持ち込めます。
Claude 側の権限制御だけで守るのではなく、実行環境そのものをホストから切り離すので、高権限運用時の安全弁として扱いやすい構成です。
Claude Code セキュリティが強調しているのも、書き込み境界やアクセス範囲を環境側で明確にする発想です。

私自身、未信頼リポジトリのビルドを Dev Container と sandbox に閉じた運用へ切り替えてから、心理的な負担が明らかに変わりました。
以前は postinstall や補助スクリプトがどこまで見に行くかを毎回気にしていましたが、この形にしてからはホスト側の .ssh/ や .aws/ に一切アクセスされない前提を保てます。
ログを追うときも「いま触れているのはコンテナ内だけ」と境界がはっきりしているので、承認ダイアログを眺めるより安心感があります。

hooks の役割はここでも変わりません。
hooks は決定論的な制御に向いていて、毎回必須の lint、secret-scan、禁止パターン検出を機械的に差し込めます。
CLAUDE.md に「コミット前に秘密情報を確認」「危険コマンドは禁止」と書いておくのは方針の共有として有効ですが、毎回抜けなく動かしたいチェックは hooks に移すべきです。
モデルの解釈に委ねず、条件に一致したら必ず走るという性質があるので、環境隔離と相性がいいわけです。

セキュリティ - Claude Code Docs

Claude Code のセキュリティ対策とセキュアな使用方法のベストプラクティスについて学びます。

code.claude.com

承認疲れを避ける「自動許可」と「隔離」のトレードオフ

運用を詰めていくと、悩ましいのは「毎回 approve を出すか、auto-allow に寄せるか、それとも隔離環境に送るか」です。
ここを全部承認必須にすると、前述の通りノイズが増えて判断が雑になります。
逆に auto-allow を広げすぎると、日常操作に紛れて危ない処理まで通りやすくなります。
現場ではこの二択ではなく、「安全で反復回数が多いものは自動許可」「危険だが必要なものは隔離」「外部影響があるものは承認」の三分割で考えると破綻しません。

たとえば npm test や pytest -q のような定番テストは auto-allow に寄せる価値があります。
同じ確認を何度も挟むより、事前に許可したコマンドとして流したほうが作業のテンポが落ちません。
ただし、そのテストコマンドが未信頼のセットアップ処理や外部ダウンロードを含むなら、承認を増やすのではなく sandbox や Dev Containerへ送るほうが筋が通ります。
承認の回数を増やしても、中で何が起きるかの不透明さは解消しないからです。

hooks はこのトレードオフを支える裏方です。
自動許可したコマンドでも、PreToolUse で secret-scan や禁止パターン検出を差し込めば、毎回同じ品質ゲートを通せます。
ここで大事なのは、hooks に決定論的な検査を 맡せ、CLAUDE.md には「どんな基準で止めるか」という方針だけを書くことです。
運用ルールの文章と実行時の強制を分ける発想が一貫しています。
文章に細かい手順まで詰め込むより、lint や secret-scan は hooks で毎回走らせるほうが漏れません。

承認疲れを避けたい場面ほど、auto-allow の範囲を広げたくなりますが、広げる対象は「結果が読める操作」に限るべきです。
逆に、未知の依存関係解決、コンテナビルド、外部コード生成、権限の高い補助スクリプト実行のように、処理の途中で別のコマンドへ枝分かれしやすいものは、承認の前に隔離を検討したほうが運用が安定します。
承認は人間の判断に依存しますが、隔離は環境の境界として残るので、判断の質がぶれません。

実務で見ると、この「自動許可」と「隔離」を混同しないだけで事故の質が変わります。
自動許可は摩擦を減らすための設定で、隔離は被害範囲を小さくするための設定です。
同じ安全策に見えても目的が違います。
だから、頻繁に回すローカルテストを auto-allow にしつつ、未信頼リポジトリのビルドや高権限操作は Dev Container と /sandbox に寄せる構成が噛み合います。
承認ダイアログを減らしながら、ホストの資格情報やファイルへ直接触れさせない。
この二つを同時に満たせるのが、環境隔離を一段足す価値です。

よくある失敗例とトラブルシューティング

初心者がつまずく場所は、設定の書き分けよりも「どこに何を任せるか」を混同したときに集中します。
実際の事故は、難しい JSON を書き間違えた場面より、便利そうに見える一括許可や、長い指示書への過信から起きることが多いです。
ここでは、私自身が遠回りしたポイントも含めて、詰まりやすい箇所を具体的に潰していきます。

CLAUDE.md に全部書いてしまう

いちばん多い失敗は、CLAUDE.md を万能の設定ファイルだと思って、方針も禁止事項も承認条件も例外処理も全部そこへ押し込むことです。
これをやると、文章は長くなるのに実行制御は強くならず、読ませたい要点だけが埋もれます。
CLAUDE.md はプロジェクト記憶の入口として扱われていて、実行時の強制そのものを担う場所ではありません。

私の感覚では、CLAUDE.md は「短い憲法」に寄せたほうが安定します。
コミュニティでは約500行以内を目安にする整理もありますが、実務では行数より「一読で役割がわかるか」が効きます。
プロジェクト概要、守る方針、主要コマンド、ディレクトリごとの補足への導線までを簡潔に置き、危険コマンドの拒否や秘密情報の遮断は permissions、hooks、sandbox に移したほうが崩れません。
frontend と backend でルールが違うなら .claude/rules/ に分けるほうが筋が通ります。

Claude があなたのプロジェクトを記憶する方法 - Claude Code Docs

CLAUDE.md ファイルで Claude に永続的な指示を与え、自動メモリで Claude が自動的に学習を蓄積できるようにします。

code.claude.com

未信頼 repo をそのまま開いて実行まで進める

初見の OSS や、由来のはっきりしない社内アーカイブを開いた直後に、依存関係の解決やビルドまで流してしまうのも典型的な失敗です。
読むだけのつもりでも、package.json の postinstall、補助スクリプト、ビルド定義をたどるうちにホストの資格情報や広いファイル領域へ接触する余地が出ます。

こういう repo は、最初の一手を「読み取りのみ」に寄せたほうが安全です。
ファイル構成、README、ビルド手順、使っているランタイムを見て、実行が必要になった段階で sandbox かDev Containerへ移す。
この順番にすると、未知の処理をホスト上でいきなり走らせずに済みます。
前のセクションでも触れた通り、未信頼 repo の実行は承認回数の問題ではなく、境界をどこに置くかの問題です。

enableAllProjectMcpServers のような表現はコミュニティで使われる言い回しとして登場することがありますが、公式ドキュメントで同一のキー名が明示されているかは確認が必要です。
もし導入する場合は「コミュニティで使われる表現」である旨を明記し、公式 settings ドキュメントでキー名と動作を照合してから運用してください。

Windows で WebDAV や広いパス許可を入れてしまう

Windows 環境では、WebDAV や広い UNC パス許可を安易に入れると、想定よりずっと外側まで見える構成になりがちです。
起動フォルダだけを触らせるつもりが、共有ドライブやネットワーク越しの領域まで届いてしまうと、アクセス境界が曖昧になります。
Claude Code セキュリティが書き込み境界と許可範囲を明確に切ることを重視しているのは、この種の事故を防ぐためです。

対策は単純で、WebDAV は無効化するか、用途が限定された場所だけに絞ることです。
ファイル許可も広い UNC パスではなく、起動フォルダ配下に閉じる形を優先したほうが事故が起きにくくなります。
.ssh や資格情報ディレクトリの deny を入れていても、広い可視範囲そのものを残すと運用が雑になりやすいので、そもそも見せる範囲を狭く保つほうが安定します。

セッション途中で CLAUDE.md を更新しても反映が弱い

地味にハマるのが、セッション途中で CLAUDE.md を書き換えたのに、モデルの挙動があまり変わらない現象です。
CLAUDE.md はセッション開始時に読まれる比重が高く、途中変更がそのまま強く再認識されるとは限りません。
とくに長文を追記したケースでは、「書いたのに効かない」と感じやすいのが利点です。
2026年1月28日の changelog では --add-dir 側の CLAUDE.md 読み込み改善が入っていますが、それでも途中更新の扱いを過信しないほうが運用は安定します。

こういうときは、プロジェクトを再読み込みするか、対象ディレクトリを開き直してオンデマンド読込を誘発したほうが反映が揃います。
変更内容が長いなら、CLAUDE.md に追記するのではなく、条件に応じて読み込まれる rules 側へ分割して、注入されるタイミングを合わせるほうが効きます。
共通方針は短く固定し、途中で増えがちな細則だけを rules に逃がすと、運用中の違和感が減ります。

承認疲れで安全側の判断が鈍る

承認ダイアログが多すぎると、人は内容ではなくリズムで押してしまいます。
そこで全部を auto-allow に寄せると、今度は危険な操作まで普段の流れに混ざります。
ここで崩れない構成は、安全な定型操作だけを allow し、外部影響のある操作は approval を残す分け方です。

たとえば npm test や pytest -q のような反復テスト、フォーマッタ、静的解析は allow に寄せる価値があります。
git push、docker build、deploy、権限の高いビルド補助スクリプトは approval を維持したほうがよく、PreToolUse hook で追加ブロックを入れると運用が締まります。
危険パターンの検出は CLAUDE.md の文章より hooks のほうが確実です。
rm -rf、curl | bash、force push のようなものは、承認に頼るより先に機械的に止める設計のほうがぶれません。

承認疲れを解消したいときほど、許可を広げる方向へ行きがちですが、実際に効くのは「繰り返しで中身が読める操作だけ流す」「結果の外部影響が大きい操作は止めるか隔離する」という切り分けです。
この線引きができていると、毎回の判断量が減るのに、防御は薄くなりません。

最小権限テンプレート3例

個人開発テンプレ

個人開発では、まず「読むのは広め、変えるのは狭め」の形から入ると安定します。
ひとりで触る案件でも、CLAUDE.md に全部書けば安全になるわけではなく、実際に効かせたい境界は settings と sandbox に寄せたほうが事故が起きません。
ここでは、コード理解のための読み取りは認めつつ、編集範囲と外部通信を細く絞る構成が出発点になります。

私自身、最初は「自分しか触らないから少し広めでいい」と考えていましたが、秘密鍵ファイルを deny に入れる前は、誤って見に行かれないかという小さな不安が常に残っていました。
id_rsa や *.pem、.env 系を明示的に閉じてからは、その不安が作業中に割り込まなくなりました。
逆に、npm test と pytest は毎回承認を挟むほうが手間だけが増えます。
そこを自動許可へ寄せると、CI に投げる前の確認が止まらず回るようになり、手元での往復が一段軽くなりました。
一般的な開発者が反復テストを日に何度も回す前提なら、承認ダイアログの削減効果は体感でもはっきり出ます。

個人開発向けのひな形は、役割ごとにこう分けると収まりがよいです。
CLAUDE.md には「このリポジトリの目的」「主要ディレクトリ」「標準のテストコマンド」のような方針だけを書く。
長くなりすぎると扱いづらいので、コミュニティでも勧められているように、おおむね500行以内に収める前提で考えると破綻しにくくなります。
settings には許可と拒否を置き、書き込みは src/ と tests/ に限定する。
hooks は必要最小限にとどめ、危険なシェル断片だけを止める。
sandbox では、ビルドや任意スクリプト実行を隔離して、ネットワークは deny 既定に寄せます。

// 概念例（実運用前に必ず公式 schema を確認してください）
{
  "$schema": "https://example.com/settings.schema.json",
  "permissions": {
    "allow": [
      "Bash(npm test)",
      "Bash(pytest -q)",
      "Edit(./src/**)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(**/*id_rsa*)"
    ],
    "ask": [
      "Bash(curl:*)"
    ]
  }

このテンプレの勘所は、テストだけを自動で流し、外部 URL は閉じたまま始めることです。
API を叩く必要が出たら、必要な宛先だけ allow に足すほうが見通しが保てます。
たとえばGitHub API だけ必要なら、その用途に限った許可を足す、という順番です。
読み取り専用中心の設計にしておくと、生成物の確認や既存コードの把握はそのまま進み、編集と通信だけに意識を向ければ済みます。

チーム開発テンプレ

チーム開発になると、個人の安心感よりも「他の人に混ざっても運用が崩れないか」が基準になります。
ここでは、自動承認の範囲を少し広げてもよい一方で、コミットや公開につながる操作には必ず関門を残します。
git push や npm publish を approval に置くのはそのためです。
ローカルでの編集を許しても、外へ出る瞬間は別扱いにする、という線引きです。

役割分担も、個人開発よりひとつ細かくなります。
CLAUDE.md には全員共通の方針だけを置きます。
たとえばブランチ運用、テストの入口、レビュー観点の要約です。
frontend と backend で規約が違うなら、その差分は .claude/rules/ に切り出します。
直近のセクションで触れた通り、この分割は文脈を軽く保つうえでも効きます。
settings では push や publish を ask にし、hooks ではコミット前の lint と secret-scan を通さない限り先へ進ませない。
sandbox は、依存インストールやビルド補助スクリプトを隔離する場所として使います。
2026年2月23日の changelog で worktree isolation と hooks 拡張に触れられていることもあり、チームの並行作業では隔離前提で組んだほうが整理しやすくなります。

{
  "$schema": "
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm test)",
      "Bash(pytest -q)",
      "Edit(./src/**)",
      "Write(./src/**)",
      "Edit(./tests/**)",
      "Write(./tests/**)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(npm publish:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(**/*id_rsa*)", // 重複のため注記
      "Read(**/*.pem)"
    ]
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "command": "./scripts/pretool-lint-and-secret-scan.sh"
          }
        ]
      }
    ]
  }

MCP はここで欲張らないほうがよく、プロジェクト定義に入っているものを全部開けるのではなく、実際にチームで使うサーバーだけを許可する構成が向いています。
Issue 管理はGitHub、デザイン参照はFigmaのように、役割で切って許可したほうが、どこで何を読んだのかを追いやすくなります。
.claude/rules/ も、frontend.md、backend.md、infra.md のように領域別で分けておくと、関係ない規約が毎回前面に出てこないぶん、レビュー時のノイズが減ります。

機密案件テンプレ

顧客データ、個人情報、社外秘の分析基盤を含む案件では、個人開発や通常のチーム開発の延長では足りません。
ここでは、まず見せてはいけないファイルを deny で明示し、そのうえでネットワークをゼロトラスト前提に切ります。
.env、秘密鍵、バックアップ、エクスポート済みデータ、サービスアカウント JSON は「読ませないし触らせない」が基本線です。
ビルドやデータ処理は host 直ではなく sandbox やDev Containerの内側に閉じ込め、外へ出る通信も許可済みの宛先だけに絞ります。

このクラスの案件では、CLAUDE.md はさらに薄くなります。
書くのはデータ分類、扱ってよいダミーデータの範囲、処理の入口と出口だけで十分です。
強制したいことは settings、検査は hooks、隔離は sandbox に寄せたほうがぶれません。
たとえばバックアップ一式が置かれた backup/ や、鍵素材が集まる secrets/ を deny しておけば、参照の可能性を最初から潰せます。
私も秘密鍵ファイルを deny に入れてから、作業を始めるたびに「そこだけは触らせたくない」と気にし続ける必要がなくなりました。
安全策が頭の中ではなく設定ファイルに移ると、レビューや実装のほうへ集中を戻せます。

{
  "$schema": "
  "permissions": {
    "allow": [
      "Bash(npm test)",
      "Bash(pytest -q)"
このテンプレの勘所は、テストだけを自動で流し、外部 URL は閉じたまま始めることです。API を叩く必要が出たら、必要な宛先だけ allow に追加してください。
    "ask": [
      "Bash(git push:*)",
      "Bash(docker build:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(**/*id_rsa*)", // 別箇所（重複）
      "Read(**/*.pem)",
      "Read(**/*service_account*.json)",
      "Read(./backup/**)",
      "Read(./secrets/**)",
      "Write(./backup/**)",
      "Write(./secrets/**)"
    ]
  },
  "sandbox": {
    "enabled": true
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "./scripts/block-sensitive-reads.sh"
          }
        ]
      }
    ]
  }

機密案件では、ローカル設定だけで完結させず、組織側の統制も前提に入ります。
Claude Enterpriseでは SSO、SCIM、監査ログ、role-based permissioning が提供されるので、誰がどの権限で利用していたかを組織単位で追える形に寄せられます。
この層は個人の気配りではなく管理可能性を買う領域だとわかります。
さらに監査やイベント取得が必要な現場では、『Anthropicの Help Center』 にある通り、Enterprise で Compliance API を有効化する運用も視野に入ります。

テンプレとして見たときの違いは明快です。
個人開発は読み取り専用中心で、編集は src/ と tests/ に限定。
チーム開発は編集の自動承認を一部認めつつ、push と publish は承認必須。
機密案件はそこに加えて、sandbox 必須、機密ファイルは明示 deny、ネットワークは閉じた状態から必要分だけ開けるという構成です。
同じClaude Codeでも、どのレイヤーに何を置くかで性格が変わります。
読者が導入時に迷いにくいのは、この分担を最初から固定しておくテンプレです。

Access the Compliance API ｜ Claude Help Center

support.claude.com

運用ノートと料金・プランの前提

仕様変動に強いドキュメント運用のコツ

Claude Codeまわりは更新の速度が速く、昨日までの理解で組んだ運用がそのまま最適とは限りません。
だからこそ、CLAUDE.md と settings.json を「一度決めたら固定」ではなく、「変化を受け止める前提の設計」にしておくと、後から崩れにくくなります。
私がまず意識しているのは、CLAUDE.md を肥大化させないことです。
コミュニティでも実務目線の目安として約500行以内がよく挙げられますが、この感覚は実際当たっています。
長くなるほど参照したい方針が埋もれ、結果として“読まれるための文書”ではなく“置いてあるだけの文書”に近づきます。

そのため、共通方針は CLAUDE.md に短く置き、領域別の規約は .claude/rules/ に逃がし、強制したい制御は permissions や hooks に寄せる、という分割を崩さないほうが運用が安定します。
仕様変更が入っても、全部を一枚岩で直す必要がなくなるからです。
たとえば permissions のキー名や hooks のイベントは進化中で、手元の古いサンプルがそのまま通るとは限りません。
設定例をコピペ資産として持つより、どの層に何を書くかという設計原則を固定しておくほうが、更新への追従が速くなります。

更新ノートも見ておくと、どこが変わりやすいかの勘所がつかめます。
2026年1月の changelog では --add-dir 由来の CLAUDE.md 読み込みが改善され、2026年2月には worktree isolation や hooks 拡張の記載がありました。
こうした変更は、ルールの置き場所や読み込まれ方に直接効いてきます。
ClaudeLogの changelog を追うと、運用設計そのものに影響する更新が定期的に入っているのがわかります。
設定ファイルの断片より更新履歴を先に見る癖をつけると、古い前提のまま構成を増築せずに済みます。

月次でドキュメントと設定を棚卸しするだけでも、見落としていた小さな穴が複数見つかります。
私の手元でも、新しく入れた MCP の既定許可を見直し忘れていたことがあり、普段の開発では表面化しないのに、運用表と実設定を並べた瞬間にズレが見えました。
こういう穴は一つだけなら軽微でも、承認ルール、hooks、MCP、ローカル例外が別々に積み上がると、誰も全体像を説明できなくなります。
棚卸しの価値は“大きな事故を防ぐ”というより、“小さい食い違いを増やさない”ところにあります。

承認設計の見直し頻度と指標

承認設計は、厳しくするか緩めるかの二択ではなく、「どの操作で会話を止めるべきか」を整える作業です。
見直し頻度は月次がちょうどよく、これはドキュメント棚卸しと同じタイミングに重ねると回しやすくなります。
短すぎると運用の変化が見えず、長すぎると例外設定が積もります。
実際、承認フローの不満は一度の大事故より、日々の小さな引っかかりとして表面化します。
毎回止まる npm test は自動化したのに、派生コマンドだけ承認が残っている、git push は ask にしたのに複合コマンド経由では想定と違う動きをする、といったズレです。

指標として見たいのは、まず「承認が多い操作が、意図通り高リスク操作に集中しているか」です。
テストや lint のような反復作業で承認が頻発しているなら、設計より先に作業者の集中が削られます。
前述の通り、Bash(npm run test *) のような許可を入れると、日々の確認ダイアログをまとめて減らせます。
開発者が一日にテストを何度も回す前提なら、その差は体感ではっきり出ます。
git push や docker build のように外部への影響が大きい操作は、止まるべきところで止まっているほうが運用の説明がつきます。

もう一つ見たいのは、「例外の増え方」です。
ask を避けるために allow が増えていくと、最初は快適でも、数か月後には誰が何を無条件実行できるのか把握できなくなります。
ここで効くのが、承認対象をコマンド単位ではなく“影響範囲”で捉える視点です。
外部公開、リモート反映、コンテナ起動、秘密情報に触れる読み取り、このあたりは承認や hook 側に寄せる。
逆に、ローカルのテスト実行やフォーマットのように失敗しても戻しやすいものは自動許可へ寄せる。
分類の軸が明確だと、新しいツールや MCP を足したときも既存ルールに当てはめやすくなります。

組織導入では、承認設計のレビュー対象にプラン要件も入ります。
Claude Enterpriseで SSO、SCIM、監査ログ、role-based permissioning を使う前提なら、個人ローカルでの“うまく回る設定”だけでは足りません。
誰がどの権限セットを持つのか、チームごとの差分をどこで吸収するのかまで含めて設計する必要があります。
逆にClaude ProやClaude Maxの範囲で回すなら、設定ファイルの責務分離と月次の棚卸しを丁寧に続けるほうが効果が出ます。
コスト差は単なる価格帯の違いではなく、統制を製品機能に寄せるか、運用で吸収するかの違いとして現れます。

承認設計を見直す場では、現在の公式ドキュメントと手元設定の差分を見る姿勢が欠かせません。
とくに permissions のキー名、イベント名、hooks の拡張点は、過去のサンプルを信用しすぎると食い違いが生まれます。
古い設定がそのまま残る原因は、壊れたから直すのではなく、壊れていないから放置されることです。
月次レビューで見るべきなのは、エラーになっている設定だけではなく、「今の仕様なら、もっと短く、明確に書ける箇所がないか」という視点です。
その積み重ねで、承認は減らすべき場所で減り、止めるべき場所で止まる形に近づきます。

次にやること

次に触るなら、設定を足すより先に置き場所を入れ替えるのが近道です。
まず既存のCLAUDE.mdから、プロジェクトの前提や判断基準のような“方針”だけを残し、危険操作の禁止や承認条件のような“実行制御”は切り離します。
文書は読むための層、制御は止めるための層と分けるだけで、レビューの視点が揃います。

そのうえで、危険コマンド、機密ファイル、未信頼URLの扱いは『settings.json』と hooks へ移します。
Anthropicの設定ドキュメントでは permissions の評価順が deny、ask、allow と定義され、hooks では PreToolUse で実行前に判定できます。
つまり、「読ませない」「実行前に止める」を文書内の注意書きではなく、実際に効く設定へ寄せる段階です。
.env、秘密鍵、サービスアカウントJSONのようなファイル保護や、rm -rf、git push、docker 系の扱いは、この層に集めたほうが追跡しやすくなります。
hooks の仕様はAnthropicの 『hooks ドキュメント』 を一度見ながら、まずはブロック対象を少数に絞って始めると崩れません。

リポジトリが大きい場合は、CLAUDE.mdを延命するより .claude/rules/ へ分割したほうが収まりがよくなります。
共通ルールは短く保ち、frontend や backend、特定ディレクトリだけで必要になる規約を別ファイルに逃がす形です。
Claudeの changelog でも --add-dir まわりの読み込み改善や worktree isolation の拡張が続いていて、必要な文脈だけを後から効かせる流れと相性が合っています。
長い総合文書を毎回読ませるより、条件に合ったルールだけが効く状態のほうが、日々の修正で迷いません。

自分の現場では、この順番を「分離、分割、隔離」の3段階に固定して、半日だけ運用時間を確保して移しました。
午前中にCLAUDE.mdから制御文を抜き、昼前に .claude/rules/ へ割り振り、午後は hooks と sandbox の確認だけに絞る進め方です。
最初から全部を最適化しようとしなかったので承認疲れが先に減り、移行中の事故も出ませんでした。
設定を増やすことより、責務の境界を整えることが、そのまま運用コストの削減につながります。