CLAUDE.md×権限の実用レシピ｜毎回の説明と危険な編集をそのまま貼って減らす

「テストの前は必ず npm.cmd run test を回して」。先週もそう言った。先々週も言った。なのに今週もまた、Claude Codeはテストを飛ばして「完了しました」と返してきました。

毎回ゼロから説明し直すあの徒労感、僕も心底うんざりしていました。そしてもう一方では、放っておくと git reset --hard を一発で通そうとする怖さもある。説明の手間を減らしたいのに、自由にさせると事故る。この板挟みです。

抜け出す鍵は、役割を2つに割ることでした。やってほしいことは CLAUDE.md に書く。やってほしくないことは settings.json で止める。 公式ドキュメントもはっきり書いていて、CLAUDE.md は「コンテキスト（参考情報）」であって強制力はありません。確実にブロックしたいなら権限ルールか hook を使え、と(How Claude remembers your project)。ここを混同すると、いくら CLAUDE.md に「rm 禁止」と書いても素通りします。

この記事は理屈の解説ではなく、痛点ごとに「そのまま貼れる」レシピを並べた台所のレシピ帳です。自分の悩みに当てはまる節だけ拾って、コピペして調整してください。

この記事の要点

• CLAUDE.md は「お願い」、settings.json は「強制」。毎回の説明は前者、危険操作の遮断は後者で解く。混ぜると効かない。
• 「毎回同じ説明をさせられる」→ CLAUDE.md に検証コマンドと前提を5〜10行で固定する。
• 「危険な編集を防ぐ」→ settings.json の deny に rm -rf git reset --hard .env 読み取りを先に入れる。deny は最優先で効く。
• 「検証漏れ」→ PreToolUse / PostToolUse の hook で build やテストを機械的に走らせる。お願いではなく実行。
• 「勝手にコミット・デプロイされる」→ git commit git push deploy を ask に置いて、人間のボタンを必須にする。
• 設定構文の網羅リファレンスと、承認モード・sandbox の運用論は姉妹記事に分けてある。この記事は「悩み→貼れるレシピ」に徹する。

設定項目を一個ずつ正確に知りたいときは Claude Code 権限設定リファレンス を、毎日どこを自動にしてどこを承認にするかの運用判断は Approval / Sandbox 設定ガイド を開いてください。ここではその2つを土台に、コピペ用のレシピだけを盛り付けます。

先に「お願い」と「強制」の境界を腹に入れる

レシピに入る前に、ここだけ一度ちゃんと押さえます。ここを外すと全部のレシピが効きません。

CLAUDE.md に書いた内容は、毎セッションの冒頭で読み込まれる「参考メモ」です。Claude はそれを読んで従おうとしますが、従う保証はない。だから「コミットの前に必ずテスト」みたいな必ず実行してほしい手順を CLAUDE.md だけに頼ると、忙しい日にすっぽ抜けます。

一方 settings.json の permissions は、Claude Code 本体が強制します。deny に入れた操作は、プロンプトでどう頼まれても、CLAUDE.md に何と書いてあっても通りません。評価は deny → ask → allow の順で、最初に当たったルールが勝ちます。

道具	性質	向いている用途	限界
CLAUDE.md	お願い（コンテキスト）	検証コマンド、命名規則、触らない方針	強制力なし。守るかは Claude 次第
settings.json deny/ask	強制（本体が遮断）	破壊コマンド、秘密ファイル、外部副作用	「やり方」までは教えられない
hook（PreToolUse 等）	強制（任意のコマンド実行）	build 必須、secret 混入チェック	シェルが書ける範囲に依存

覚え方はシンプルです。「〜してほしい」は CLAUDE.md、「〜させない／確認を挟む」は settings.json、「〜を必ず走らせる」は hook。 これを頭に置いて、以下のレシピを読んでください。

レシピ1：毎回同じ説明をさせられる

いちばん多い悩みがこれです。検証コマンド、ディレクトリ構成、コミット規約。毎セッション説明し直すのは時間の無駄なので、CLAUDE.md に固定します。

コツは欲張らないこと。公式も CLAUDE.md は200行以内を目安にと書いています。長いほど読み飛ばされるので、最初は本当に毎回言っていることだけ。

プロジェクト直下の CLAUDE.md（または .claude/CLAUDE.md）にこう書きます。

# このプロジェクトの約束

## 検証（コードを変えたら必ず）
- ビルド: `npm.cmd run build`
- テスト: `npm.cmd run test`
- 変更範囲の確認: `git diff --stat`

## ディレクトリ
- 記事本文: `site/src/content/blog/`（編集してよい）
- レイアウト: `site/src/layouts/`（触る前に相談）
- スクリプト: `scripts/`（触る前に相談）

## やらないこと
- `.env` と `billing/` は開かない
- 指示がない限り commit / push しない

ポイントは具体性です。「ちゃんとテストして」ではなく、実行コマンドそのものを書く。「整理して」ではなく、編集してよいフォルダ名を書く。公式の言い方を借りれば、Format code properly ではなく Use 2-space indentation と書け、です。

それでも従わない手順（コミット前のテストなど）が出てきたら、それは CLAUDE.md の限界です。お願いで足りないものは、レシピ3の hook に格上げします。

複数の約束が増えてきたら、@path で外部ファイルを取り込めます。README や別ファイルの規約をそのまま参照に回せるので、CLAUDE.md 本体は短く保てます。

プロジェクト概要は @README、npm コマンド一覧は @package.json を参照。

# 追加ルール
- git の流儀 @docs/git-instructions.md

ファイル種別ごとにルールを分けたいなら .claude/rules/ に置いて、frontmatter の paths で対象を絞れます。TypeScript を触るときだけ読み込ませる、といった出し分けができます。

---
paths:
  - "src/api/**/*.ts"
---

# API のルール
- すべてのエンドポイントで入力バリデーションを必須にする
- エラー応答は共通フォーマットを使う

レシピ2：危険な編集・破壊コマンドを防ぐ

「いい感じに整理して」で40ファイル消された、みたいな事故を二度と起こさないための層です。ここは CLAUDE.md ではなく settings.json の deny。お願いではなく、本体に止めさせます。

チームで共有する .claude/settings.json に、危険な形を先に潰しておきます。deny は最優先なので、あとから誰かが allow を足しても外せません。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(secrets/**)",
      "Read(~/.ssh/**)",
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Bash(git push --force *)",
      "Bash(git clean *)",
      "Bash(curl * | sh)"
    ]
  }
}

ここで効いてくる構文の勘所が2つあります。

ひとつ目、Read(.env) はカレント以下のどの階層の .env にも当たります（Read(**/.env) と同義）。深い場所に隠れた秘密ファイルも巻き取れます。

ふたつ目、* の前のスペースは語境界として効きます。Bash(rm -rf *) は rm -rf foo に当たるけれど、関係ない別コマンドには当たらない。逆にスペースなしの Bash(rm*) は予想外まで当たるので、危険遮断では「コマンド＋スペース＋*」の形が読みやすくて安全です。この辺の詳しい挙動は 権限設定リファレンス にまとめてあります。

ひとつ注意。Read / Edit の deny が効くのは、Claude の組み込みファイルツールと、cat head sed など本体が認識する Bash までです。Python や Node のスクリプトが自前でファイルを開く動きは止められません。OS レベルで塞ぐなら sandbox が要ります。

そして大前提として、.env 禁止を CLAUDE.md にだけ書くのは無意味です。CLAUDE.md は強制力を持たないので、秘密ファイルやデプロイの遮断は必ず settings.json 側に置いてください。

レシピ3：検証漏れ（テスト・ビルドをすっ飛ばす）

冒頭の「テストを飛ばす」問題です。CLAUDE.md に「コミット前にテスト」と書いても抜けるのは、それがお願いだから。必ず走らせたいなら hook にします。

PreToolUse はツール実行の「前」、PostToolUse は「後」に任意のコマンドを差し込めます。.claude/settings.json にこう書くと、編集のたびにテストが走り、デプロイの前にビルドが強制されます。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "npm.cmd run test"
        }]
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Bash(npx wrangler pages deploy*)",
        "hooks": [{
          "type": "command",
          "command": "npm.cmd run build"
        }]
      }
    ]
  }
}

PreToolUse の hook が exit code 2 で終わると、その操作はブロックされます。たとえば「.env がステージされていたらコミットを止める」を、お願いではなく機械の門番として置けます。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git commit*)",
        "hooks": [{
          "type": "command",
          "command": "git diff --cached --name-only | findstr /R \"^\\.env\" && exit 2 || exit 0"
        }]
      }
    ]
  }
}

僕の経験上、hook は欲張ると壊れます。npm.cmd run test を毎回フルで回すと遅くて、結局誰かが hook を外します。止める hook を1つ、検証する hook を1つくらいが続きます。重い検証は変更範囲だけに絞るか、CI 側に逃がすのが現実的です。詳しい使い分けは Hooks ガイド を見てください。

レシピ4：勝手にコミット・デプロイされる

外部に副作用が出る操作——コミット、プッシュ、デプロイ、メール送信——は、自動にしてはいけません。かといって全部禁止だと不便。だから ask に置いて、人間がボタンを押すまで保留にします。

.claude/settings.json の permissions に、速くしたい読み取り系を allow、副作用のある操作を ask、破壊系を deny と三段に分けます。これがレシピ1〜3を1ファイルにまとめた完成形です。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "Bash(npm.cmd run build)",
      "Bash(npm.cmd run test)",
      "Bash(git status)",
      "Bash(git diff:*)"
    ],
    "ask": [
      "Edit",
      "Write",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git push:*)",
      "Bash(npx wrangler pages deploy:*)"
    ],
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Bash(git push --force *)"
    ]
  }
}

git commit を ask にしておくと、Claude が勝手に履歴を作りません。差分を見てから自分でコミットメッセージを整えられます。デプロイも同じで、ask のダイアログが「本当に本番に出す？」のひと呼吸になります。

なお ask を増やしすぎると、人は1週間で反射的に「はい」を押し始めます。本当に止めたい数個だけ ask に置き、安全だと確信した操作はあとから allow に格上げするのがコツです。この「広げる順番」の運用論は Approval / Sandbox 設定ガイド に詳しく書きました。

どこに置くか：チーム共有と個人上書き

最後に置き場所です。ここを間違えると、せっかくの deny を個人設定で外せてしまいます。

• .claude/settings.json … git 管理。チーム共有の deny と標準ルールはここ。
• .claude/settings.local.json … gitignore 推奨。自分だけの allow 追加はここ。
• ~/.claude/settings.json … 全プロジェクト共通の自分の好み。

鉄則は、deny はチーム共有ファイルに置き、個人ファイルには allow の追加だけ。権限ルールはスコープをまたいでマージされ、どこか1か所で deny されたら他では allow できません。だからチームの deny を個人設定で破れない構造にできます。

echo ".claude/settings.local.json" >> .gitignore

CLAUDE.md も同様に、チーム共有は CLAUDE.md、個人メモは gitignore した CLAUDE.local.md に分けられます。「自分のサンドボックスURL」みたいな私用設定は後者へ逃がします。

よくある質問

Q. CLAUDE.md に「.env を読むな」と書けば安全？ いいえ。CLAUDE.md は参考メモで強制力がありません。秘密ファイルの遮断は必ず settings.json の deny（例 Read(.env)）に書きます。CLAUDE.md は補助であって防壁ではありません。

Q. 「コミット前に必ずテスト」をCLAUDE.mdに書いても守ってくれない。 それが CLAUDE.md の限界です。必ず実行させたい手順は hook に格上げします。PreToolUse の Bash(git commit*) でテストを走らせ、失敗なら exit 2 でコミットを止めれば、お願いではなく機械が止めます（レシピ3参照）。

Q. allow を広げると速いけど怖い。どこまで広げていい？ 読み取り（Read / Grep / Glob）と検証コマンド（build / test）までは allow で快適です。外部に副作用が出る push・deploy・メール送信は ask、破壊系は deny。広げる順番の判断は Approval / Sandbox 設定ガイド が詳しいです。

Q. Bash(git *) を allow にしたら危険なコマンドまで通った。 git で始まる全部に当たるためです。広い allow を置くなら、Bash(git reset --hard *) や Bash(git push --force *) を先に deny で潰します。deny は最優先なので、広い allow があっても危険形だけ確実に止まります。

Q. CLAUDE.md にお願いを書くのと、Claudeに「覚えて」と頼むのは同じ？ 別物です。「覚えて」と頼むと auto memory（Claude が自分で書くメモ）に入ります。チームで共有したい約束は、明示的に「CLAUDE.md に追記して」と頼むか、自分でファイルを編集します。

実際に試した結果

このサイトを Claude Code で回すようになって、僕の運用はこの形に落ち着きました。「テストして」を毎回打つのをやめて CLAUDE.md に固定し、それでも抜けるテストは PostToolUse の hook に移した。.env と破壊コマンドは最初に deny で塞いだ。git commit と deploy は ask のまま残した。

体感で変わったのは、悩む対象です。前は「Claude を信じていいか」で迷っていました。今は「どのレシピで止まったか」を見るだけ。deny で止まればそれは設計どおりだし、ask が出たら自分で最終判断すればいい。説明の徒労も、ヒヤッとする瞬間も、どちらもこの2ファイルにレシピを足すだけで確実に減りました。

まずは自分がいちばんうんざりしている痛点を1つ選んで、対応する節のコードをコピペしてみてください。設定構文を網羅的に確かめるなら 権限設定リファレンス、毎日の自動／承認の線引きは Approval / Sandbox 設定ガイド が地図になります。型をまとめて手元に置きたいなら 教材一覧、自分のチームの運用設計まで踏み込むなら 導入相談 もどうぞ。