この記事の結論（先に 3 行）

1. CLAUDE.md は「守られる前提のルールブック」ではない。Anthropic 公式が advisory（参考情報） と明言しており、太く書くほど薄まる。
2. 暴走を本当に止めたいルールは Hooks（PreToolUse 等）= deterministic な機械ガード に降ろす。CLAUDE.md・rules・Hooks の 3 層が同じことを言って初めて「毎回守る」が成立する。
3. 筆者が自律エージェントで実運用している CLAUDE.md は 本体 36 行 + rules-*.md 6 ファイル + Rule 57 条。この記事ではその実測値と「失敗駆動ルール（P-NNN）」の回し方を全部出す。

2026 年 5 月末、Qiita で「16 万スター超の CLAUDE.md に学ぶ、Claude Code を暴走させない運用術」がバズり、Zenn でも実運用ベースのガードレール集が相次いで公開された。CLAUDE.md の「書き方」の記事は無数にあるが、実際に金銭が動く自律エージェントを動かしている CLAUDE.md の中身と実測値 を出している記事は、筆者が探した範囲ではほとんど無い。

この記事は、その穴を埋める。筆者は複数の収益化プロダクト（技術ブログ・SaaS・営業自動化）を 1 つの Claude Code セッション群で自律運用しており、その統制レイヤーがまさに CLAUDE.md だ。本番で実際に使っている数字とルール設計を、機密に触れない範囲で公開する。

---

1. なぜ今「暴走させない運用」なのか — 課金構造の変化が背景

なぜ 2026 年 5 月末に「暴走防止」がこれほどバズったのか。背景には課金構造の変化がある。

• Claude Code: 2026 年 6 月 15 日改定で、自動化エージェント利用と通常会話利用が別バケット管理になる（公式アナウンス。当ブログでも改定の論点整理で扱った）。
• GitHub Copilot: 2026 年 6 月 1 日に年間プランが廃止され、AI Credits の従量課金へ移行する（公式）。

つまり 「エージェントが余計なことをすると、そのまま課金に跳ね返る」 時代に入った。海外でも「denial-of-wallet（財布枯渇攻撃）」「runaway cost」という言葉で、エージェントの暴走＝コスト事故という文脈が語られている（出典: orchestrator.dev “Claude Code & Agent Memory: Best Practices for 2026” / howtoharden.com “Anthropic Claude Hardening Guide”）。

無断リファクタリング・無関係ファイルの上書き・過剰な抽象化——これらは以前なら「やり直せばいい」で済んだが、これからは トークン消費＝実費 として効いてくる。だから「暴走させない設計」が今、技術コミュニティの最優先テーマになっている。

---

2. 最重要の誤解：CLAUDE.md は「絶対ルール」ではなく advisory

ここが本記事で一番伝えたい点だ。多くの入門記事が CLAUDE.md に「絶対に〜するな」と書けば守られる前提で書かれているが、それは設計として危険だ。

Anthropic の公式ドキュメントおよび英語圏の実務記事（Matthew Groff “Implementing CLAUDE.md and Agent Skills” 等）は、CLAUDE.md の指示を advisory（参考情報） として扱うと整理している。Claude はこのファイルをコンテキストとして処理するが、ハードルールのように毎回必ず従う義務を負うわけではない、というのが公式の立場だ。

ガイドライン・コーディングの好み・アーキテクチャ判断は CLAUDE.md に書く。 しかし lint 実行・フォーマット・危険コマンドのブロックのような 「絶対に毎回守らせたいハードルール」は Hooks に書く。Hooks は deterministic（決定論的）で、AI の気分に関係なく必ず走る。

この区別を曖昧にしたまま CLAUDE.md に祈りのように禁止事項を積み上げると、(a) ファイルが肥大化して本当に大事な指示が埋もれ、(b) それでも確率的に破られる、という二重の失敗が起きる。英語圏の HumanLayer は CLAUDE.md を 60 行未満に保ち、Anthropic は 300 行未満、実務の sweet spot は 60〜100 行とされる（出典: 上記 WebSearch 群）。

裏を返すと、CLAUDE.md の役割は「Claude に毎セッション同じ前提を読み込ませ、意思決定の方向を揃えること」であって、「物理的に止めること」ではない。 止めるのは Hooks の仕事だ。

---

3. 一次情報：筆者が本番運用している CLAUDE.md の実測値

ここから先は筆者の運用リポジトリを実測した数字だ（wc -l / grep の出力ベース。Type A 一次情報）。

3-1. 構成と行数

ファイル	役割	実測行数
CLAUDE.md（本体）	import-only の入口	36 行
rules-base.md	基本原則（ROI・撤退基準など）	20 行
rules-development.md	開発（TDD・レビュー）	21 行
rules-customer.md	顧客対応	24 行
rules-operations.md	運用	25 行
rules-session-v2.md	セッション運用	43 行
rules-automation.md	自動化・自己修復	20 行

ポイントは 本体 CLAUDE.md を 36 行に保っている こと。Anthropic 公式が推奨する「concise（簡潔）」を満たすため、ルール本体は別ファイルに逃がし、本体は @docs/protocols/rules-*.md の import 宣言だけ にしている。

# CLAUDE.md（本体・抜粋・import-only ≤40 行を維持）

@docs/protocols/rules-base.md
@docs/protocols/rules-development.md
@docs/protocols/rules-customer.md
@docs/protocols/rules-operations.md
@docs/protocols/rules-session-v2.md
@docs/protocols/rules-automation.md

Anthropic の @path import は最大 5 hops まで辿れる仕様だが、本リポは depth 1（本体 → rules-*.md の 1 段のみ） に固定している。深くネストすると人間が追えなくなるためだ。これは公式仕様（memory ドキュメント）に沿った、しかし「あえて 1 段で止める」という運用判断である。

3-2. ルール総数

grep で数えると、6 つの rules ファイルに散っているルール行は 合計 87 行、ルール番号としては Rule 1〜57（枝番含む）に達する。Qiita でバズった「16 万スターの CLAUDE.md」が汎用テンプレートだとすると、こちらは 特定の収益化オペレーションに特化して肥大した実例 という位置づけだ。

⚠️ 正直に書くと、Rule 57 条は多すぎる。これは「失敗するたびにルールを足してきた」結果であり、後述する 200 行ルールとは常に綱引きしている。万人向けの理想形ではなく、1 つの運用がどこまで膨らむかの生々しいサンプル として読んでほしい（これは筆者の所感）。

---

4. 3 層ガードレール（L1 / L2 / L3）の実装

Zenn の実運用ガードレール記事でも整理されている通り、暴走防止は 3 層が同じことを言って初めて成立する。筆者のリポジトリでの対応を表にすると以下になる。

層	役割	性質	本リポでの実体
L1: CLAUDE.md 本体	全体方針・目的・読込順序	advisory	36 行の import 入口 + 作業順（役割宣言 → 計画 → レビュー → 実行）
L2: rules-*.md	条件付きで適用する詳細ルール	advisory（参照される）	Rule 1〜57 を 6 ファイルに分割
L3: Hooks	機械的に強制するガード	deterministic	SessionStart / PreToolUse 等

重要なのは L3 だ。例えば筆者のリポジトリには「顧客の最終返信から 72 時間を超えたスレッドへは一切送信しない」というルール（後述の Rule 16）がある。これを advisory な CLAUDE.md だけに書くと、長いセッションの終盤で確率的に破られうる。だから本来は PreToolUse hook（block-stale-customer-draft）で送信操作そのものをブロックする 設計を置く——L1/L2 で方針を示し、L3 で物理的に止める、という二重防壁である。

// .claude/settings.json（イメージ。Hooks は deterministic に走る）
{
  "hooks": {
    "PreToolUse": [
      {
        // 例: 古い下書きの送信や、危険な破壊操作を機械的にブロックする
        "matcher": "Bash",
        "command": "scripts/guards/block-dangerous-op.sh"
      }
    ]
  }
}

補足（事実と所感の分離）: 上記 block-stale-customer-draft hook について、筆者リポジトリでは現状 未配線（Phase 2 で対応予定） という状態をルール本文に明記している。「ガードを設計したが配線していない」ことを正直にルールへ書き残すこと自体が、暴走防止の運用では効く——というのが筆者の経験則だ（所感）。

---

5. 失敗駆動ルール（P-NNN）— ルールは「最初から」ではなく「事故後」に生える

入門記事は「最初に良い CLAUDE.md を書こう」と言う。だが実運用での真実は逆で、良いルールは事故のあとに生える。

筆者のリポジトリでは、失敗パターンに P-NNN という連番 ID を振り、レビュー時に自動で参照する仕組みにしている。実例（機密に触れない範囲）:

• P-010「送信先誤り」: 別案件のメッセージボックスに誤送信しかけた事故 → 「送信前に宛先 URL・案件名・本文を別エージェントで三重確認する」ルールへ昇格。
• 並列セッション clobber: 複数エージェントが同じファイルを同時編集して上書きし合った事故 → 「着手前に git status と mtime で他セッションの未コミット編集を検出する」ルール（Rule 32b）へ昇格。

この「事故 → ルール化 → 次から自動注入」のループこそが、CLAUDE.md を 生きたガードレール にする。テンプレートをコピーしただけの CLAUDE.md には、あなたのプロジェクト固有の事故史が入っていない。だから守れない。

英語圏でも、76Hata 氏の claude-code_guard-rules のように「実際に起きた事故（設定ファイルのサイレント上書き・ビルド後の報告漏れ等）から逆算したガードレール集」が公開され始めている。ルールは抽象論ではなく事故ログから書く ——これは日英のコミュニティで合致しつつある潮流だ。

---

6. 200 行ルールと「Litmus Test」— 肥大化との戦い方

Rule 57 条まで膨らんだリポジトリが、それでも本体 36 行を保てるのはなぜか。答えは 明確な肥大化対策ルール を持っているからだ。

筆者は Anthropic 公式 best-practices の Litmus Test をルール編集の必須基準にしている:

各行について「この行を消したら Claude がミスするか?」を自問する。No なら削除候補。

公式は “Bloated CLAUDE.md files cause Claude to ignore your actual instructions”（肥大化した CLAUDE.md は、Claude にあなたの本当の指示を無視させる）と明言している。だから:

1. ルール本体は @import される rules-*.md に置き、常時ロードされる各ファイルに 5KB の soft cap を設ける（独自運用基準）。
2. 詳細な手順・FAQ は @import されない参照ドキュメント（docs/ 配下）へ逃がす。常時コンテキストに乗せない。
3. IMPORTANT / YOU MUST のような強調は 濫用すると希釈される（公式: “rules getting lost in the noise”）。本リポは 1 ファイル ≤5 件を目安に抑制している。

この「足し続けるが、本体は太らせない」両立が、長期運用 CLAUDE.md の肝だ。

---

7. 個人開発者が今日からできる 5 ステップ

ここまでの内容を、明日から自分のリポジトリで試せる手順に落とす。

1. 本体を import-only にする: CLAUDE.md 本体は目的・読込順序・@import 宣言だけにし、ルール詳細は docs/rules/*.md に分割する（目標: 本体 ≤60 行）。
2. ハードルールを Hooks に降ろす: 「絶対に止めたい操作（force push / rm -rf / 本番デプロイ）」は CLAUDE.md ではなく .claude/settings.json の PreToolUse hook でブロックする。
3. 失敗ログを P-NNN で記録する: 事故が起きたら、その場で連番 ID を振って 1〜3 行で「何が起きたか」を残す。修正はあとでいい。
4. Litmus Test で月次掃除: 各行に「消したら Claude がミスするか?」を問い、No の行を削る。
5. 強調を絞る: IMPORTANT の濫用をやめる。本当に重要な 5 件だけに使う。

---

8. キャリアの文脈：CLAUDE.md 設計力は「市場で評価される技能」になりつつある

最後に収益・キャリアの観点を 1 つ。AI エージェントを「暴走させずに本番運用する」スキル——つまり CLAUDE.md・Hooks・レビューパイプラインを設計してエージェントを統制する力は、2026 年の採用市場で評価対象になりつつある（これは筆者が複数の公開求人・採用要件を眺めた所感であり、定量調査ではない）。「AI にコードを書かせる人」ではなく 「AI に何をどの粒度で委譲し、どこで機械的に止めるかを設計できる人」 が希少だからだ。

体系的に学びたいなら、AI コーディング・エージェント設計の講座でインプットを一気に固めるのが時短になる。

設計力が付いたら、次は「その技能が市場でいくらの値が付くか」を測るフェーズだ。即転職する必要はなく、自分の市場価値レンジを把握する用途でもキャリア面談は使える。

---

まとめ

• CLAUDE.md は advisory。祈りを書く場所ではなく、毎セッション方向を揃える場所。
• 本当に止めたいものは Hooks（deterministic） に降ろす。L1/L2/L3 の 3 層が一致して初めて「毎回守る」が成立する。
• 良いルールは 事故のあとに生える（失敗駆動・P-NNN）。テンプレのコピーには、あなたの事故史が入っていない。
• ルールは足し続けてよいが、本体は Litmus Test と 5KB cap で太らせない。
• この設計力は 市場で評価される技能 になりつつある。学習（Coloso）と市場価値の測定（TechGo）の二段で投資効率を最適化したい。

関連記事として、当ブログのClaude Code カスタムサブエージェント完全ガイド、Claude Code 大規模コードベース実践ガイドも、エージェント統制の実装面を補完する。