- 削るほどよい、と思っていた話
- まず実測——公式は200行、私のは373行
- 削ってみた——陳腐化の5分類
- 結果——削れたのは約3.6%だった
- なぜ削れないのか——96%は事故の記録
- なぜ肥大化は止まらないのか
- 設計図は誰のために書くのか
- まとめ——削る前に「削れないもの」を知る
この記事の実施記録（2026年6月）: 自分のClaude Codeプロジェクトの CLAUDE.md（本体71行）と参照先 rules/ 4ファイル（302行）、合計373行・約37,600バイト（推定9,400〜12,500トークン）を棚卸しした。Anthropic公式は「CLAUDE.mdは200行以下」を推奨している。削れる箇所を5分類で洗い出して実際に削除した結果、正味で削れたのは14行・約3.6%だった。残った96%は、すべて過去の具体的な事故に紐づいたルールだった。この記事は「どこまで削れるか」ではなく「何が削れないか」を設計の核として書く。
削るほどよい、と思っていた話
Claude Codeを使い込むと、CLAUDE.md は自然と育っていく。「この操作で事故ったから、次は禁止」「このパターンは毎回失敗するから、手順を明文化」——そうやって一行ずつ書き足していくと、AIの挙動がどんどん安定する。書けば書くほど賢くなる、という実感がある。
ところが、ある日ふと気づいた。CLAUDE.md はセッション開始時に毎回コンテキストへ読み込まれる。つまり書いた行数ぶん、毎回トークンを消費し続けている。丁寧に育てた設計図が、そのまま毎回の課金対象になっていた。
これは私の思い込みではなく、Anthropicの公式ドキュメントにもはっきり書かれている。
Your CLAUDE.md file is loaded into context at session start. If it contains detailed instructions for specific workflows (...), those tokens are present even when you're doing unrelated work. (...) Aim to keep CLAUDE.md under 200 lines by including only essentials.
（CLAUDE.mdはセッション開始時にコンテキストへ読み込まれる。特定ワークフロー向けの詳細な指示が含まれていると、無関係な作業をしているときでもそのトークンが存在し続ける。CLAUDE.mdは本質的なものだけにして200行以下に保つことを目指そう）
出典: Anthropic「Manage costs effectively」（2026-06-24に原文確認）
公式の推奨は200行以下。私のは何行か。実測してみた。
まず実測——公式は200行、私のは373行
数字を感覚で語らないために、wc -l で測った（2026-06-24実測）。
| ファイル | 行数 |
|---|---|
CLAUDE.md 本体 |
71行 |
.claude/rules/global-rules.md |
38行 |
.claude/rules/coo-rules.md |
150行 |
.claude/rules/agent-roles.md |
98行 |
.claude/rules/path-policy.md |
16行 |
| 合計 | 373行 |
CLAUDE.md 本体は71行で、公式推奨の200行に収まっている。だが私のプロジェクトでは本体から rules/ 配下の4ファイルを参照しており、セッション開始時にはこれらも実質的に読まれる。合計すると373行、バイト数で約37,600バイト。日本語が混在しているため3〜4バイト/トークンで換算すると、推定9,400〜12,500トークンになる。
このトークンが、私が何をしていようと毎セッションの先頭に積まれる。ウイスキーの記事を書いていても、スクリプトを直していても、まずこの設計図が読み込まれてから本題が始まる。
外部にも近い計測がある。token-optimizer（github.com/hamzafarooq/token-optimizer）というツールでは、ある CLAUDE.md を3,847トークンから312トークンへ、91.9%削減した計測値が公開されている。ただし「品質は落ちなかった」という表現はこの数値を取り上げた二次記事が付け加えた解釈で、一次ソースに品質比較の記述はない。削減率は計測値、品質差の有無は未検証——そう切り分けて受け取るのが正確だ。
ともあれ、削れるなら削りたい。そう思って棚卸しを始めた。
削ってみた——陳腐化の5分類
やみくもに削るとルールが壊れる。そこで「どういうルールなら削っていいか」を先に分類した。実際に削除作業をして見つかった陳腐化のパターンは、次の5つだった。
1. ツール廃止型——存在しないツールへの警告
最初に見つけたのが、これだ。blogsync というはてなブログ同期ツールについて、「直接実行禁止」「サブシェル経由でのみ実行」といったルールが、CLAUDE.md と rules/ にまたがって書かれていた。
ところが blogsync は、2026年5月末に独自のAtomPub CLIへ移行した時点で廃止済みだった。バイナリは存在しない。つまり、存在しないツールへの警告が毎セッション読み込まれ続けていた。
削除した（実測: 11行削除・2行修正、正味9行減）。
行数自体は小さい。問題はなぜ気づかなかったかのほうだ。ツールを移行したとき、「ルールも消す」という発想がそもそもなかった。増やすフローはあるのに、削るフローがない。だから廃止されたツールのルールが幽霊のように残り続けた。
2. 能力拡張型——迂回ルールが不要になった
次は、ツールが消えたのではなく、より良い代替が登場して迂回が不要になったパターン。
私のルールには「ブラウザ操作が必要なときはCowork（Claudeデスクトップアプリの機能）に投げるべきか確認する」というチェックがあった。だがClaude in Chrome（ブラウザを直接操作できるMCP連携）が使えるようになり、CLIから直接ブラウザを触れるようになった。Cowork経由で迂回する前提が崩れたので、このチェックは不要になった。
ツールが消えたわけではないのに、ルールが陳腐化する。能力が拡張されると、それまで必要だった「回り道の指示」が宙に浮く。
3. 重複型——同じルールが2箇所に
同じ「30行を超える実装は専門エージェントに委任する」というルールが、coo-rules.md の別々の段落に二重で書かれていた。これは単純に冗長なので片方を整理した。
4. 参照切れ型——リンク先が消えていた
ルールの根拠として参照していたレビューファイルへのパスが、実ファイルの移動・削除で切れていた。リンク先が存在しない参照は、読み手（AI）が辿ろうとして無駄に動くか、単に意味をなさない。
5. 未発火型——一度も発動していない予防ルール
「念のため」で追加したものの、対応するインシデント記録が一度も生まれていない予防的ルールがいくつかあった。発火実績ゼロのルールは、効いているのか効いていないのかを検証できない。今回はそのうち明らかに過剰だったものを削った。
ここで一点、正直に書いておく。「未発火だから即削除」は危険でもある。発火していないのは、ルールが事故を未然に防いでいるからかもしれない。今回削れたのは、別のより強いルールでカバーされていて重複していた未発火ルールだけだ。単独で予防効果を担っている未発火ルールは残した。この線引きは次章の「削れないもの」につながる。
結果——削れたのは約3.6%だった
5分類で洗い出して削った結果を、コミットの差分から実測した（2026-06-24）。
| 削除内容 | 正味の削減行数 |
|---|---|
| blogsync（ツール廃止型） | 9行 |
| 未発火トリガー | 5行 |
| 参照切れ修正 | 0行（書き換え） |
| 30行ルール重複 | 0行（書き換え） |
| 正味合計 | 約14行 |
削減前は387行、削減後は373行。正味で削れたのは14行、率にして約3.6%。体感では「けっこう削った」のに、全体の4%にも届かなかった。逆に言えば、96%が削れずに残った。
ここで普通なら「もっと攻めて削ろう」と思うところだ。だが私は逆のことに気づいた。残った96%は、削れなかったのではなく、削ってはいけないものだった。
なぜ削れないのか——96%は事故の記録
残った96%を一つずつ眺めて、共通点が見えた。削れないルールは、すべて「不可逆な外部副作用」に紐づいている。
具体的にはこういうものだ。
- はてなブログのカテゴリを空のまま公開すると、Qiitaへのクロスポスト時にタグ空エラーで失敗する。だから「Categoryを必ず1つ以上設定」が残る
- デフォルト値を独断で変更したら、Zennの記事5本が一時的に非公開になった。だから「デフォルト値変更は事前承認」が残る
これらは一度やってしまうと取り返しがつかない。公開記事のURLは元に戻せないし、課金は発生済みになる。可逆な失敗のルールは削れるが、不可逆な失敗のルールは削れない。
今回削った14行は、全部「事故に紐づいていないルール」だった。廃止ツールの警告、重複、参照切れ、別ルールで代替済みの未発火トリガー——どれも消しても何も壊れない。一方、残った96%は、一つ残らず過去の具体的な事故が裏付けていた。
つまり私の CLAUDE.md は、もはや「ルール集」ではない。事故の累積カルテだ。日付付きの事故参照が全体で20箇所以上あり、失敗のたびに一行ずつ書き加えられてきた記録になっている。
なぜ肥大化は止まらないのか
ここで一歩引いて、構造を考えてみる。なぜこのプロジェクトの設計図はここまで膨らんだのか。理由は3つあると私は考えている（以下は実測した事実からの私の解釈だ）。
第一に、コードで縛れないものをテキストで縛っている。 普通のコーディングプロジェクトなら、「URLを書き換えるな」はテストやCIで機械的に縛れる。ところがこのプロジェクトで縛りたい対象は、Claudeの判断そのものだ。判断は実行時にしか現れず、テストで事前に潰せない。コードで閉じられない不確実性が、全部テキストへ沈殿していく。
第二に、肥大化は副作用ではなく仕様だ。 私の CLAUDE.md には「トリガーリストは事故型を追記して育てる運用」と明記してある。育てる、と書いてある以上、行数は単調に増えるよう設計されている。増やすループは制度化されているのに、削るループは制度化されていない。 生成には正のフィードバックがあり、淘汰には何のフィードバックもない。だから一方向に膨らむ。
第三に、これは執筆・運用主体のプロジェクトだからだ。 静的な仕様で動くプロジェクトのルールは安定する。だがここでは記事公開・クロスポスト・権限管理など、外部サービスと不可逆にやり取りする操作が多い。失敗の種類が多く、しかもそのたびに学習として記録される。失敗学習でルールが動的に増える構造そのものが、肥大化の源だ。
肥大化は怠慢の結果ではない。失敗を一つも捨てずに制度へ翻訳してきた結果だ。
設計図は誰のために書くのか
ここまで来て、最初の問いに戻る。CLAUDE.md は誰のために書いているのか。
書き始めた頃の私は、無意識に「書いた自分が安心するため」に書いていた節がある。丁寧に設計図を作り込むと、仕組みをコントロールできている気がする。だが毎回読まれてトークンを消費するのは、安心料ではない。実際にそのルールが必要になる瞬間のために、AIへ渡しているのだ。
だとすれば、設計の評価軸は「どれだけ丁寧に書いたか」ではない。「削ったとき本当に何かが壊れるか」だ。削っても何も壊れないルールは、書いた自分の安心のために置かれている。削ったら不可逆な事故が起きるルールだけが、AIのために本当に必要なルールだ。
公式が200行を推奨し、外部ツールが91.9%削減を示すのを見て、私も「攻めて削ろう」と身構えた。だが実際に棚卸しすると、削れたのは約3.6%で、本質は残り96%のほうにあった。重さと賢さはトレードオフではなく、ほぼ同じものだった。 96%の重さは、96%ぶんの失敗から学んだ賢さそのものだった。
もちろん、これは私のプロジェクト固有の事情でもある。あなたの CLAUDE.md が「念のため」で膨らんでいるなら、削れる余地は私より大きいだろう。公式の言う通り、特定ワークフローの詳細手順はスキル（オンデマンドで読み込まれる仕組み）へ移すだけでベース context は軽くなる。削れるものは削るべきだ。 ただ、削り終えたあとに残るものこそが、あなたの設計の核心になる。
まとめ——削る前に「削れないもの」を知る
最後に、再現できる手順としてまとめておく。
- まず実測する。
wc -lでCLAUDE.mdと参照先ファイルの合計行数を測る。感覚で「重い／軽い」を語らない - 5分類で棚卸しする。 ツール廃止型／能力拡張型／重複型／参照切れ型／未発火型。この5つに当てはまるものは、削っても何も壊れない可能性が高い
- 削る前に「紐づく事故」を確認する。 そのルールが不可逆な外部副作用（公開URL・課金・外部API）を防いでいるなら、削らない。可逆な失敗のルールだけ削る
- 詳細手順はスキルへ逃がす。 特定ワークフローの長い手順は
CLAUDE.mdから外し、必要なときだけ読み込まれるスキルへ移す（公式推奨の手法）
削減の目標は「200行」でも「91.9%減」でもない。本当の問いは、何を忘れる勇気を持つかだ。失敗の記録を一つ消すというのは、「もう二度と同じ事故は起きない」と賭けることに等しい。その賭けに勝てるルールだけを削る。残りは、賢さの重みとして抱えておく。
CLAUDE.md の棚卸しをこれから始めたい方には、基礎から固め直せる入門書がある。まず「そもそも CLAUDE.md に何を書くべきか」の型を押さえておくと、今回のような陳腐化の見極めがしやすくなる。
- Claude CodeによるAI駆動開発入門（平川 知秀 著）
- 実践Claude Code入門（西見 公宏・吉田 真吾・大嶋 勇樹 著）
CLAUDE.md を削り込んでいくと、次の問いが出てくる——そもそもルールは CLAUDE.md に書くべきなのか、それとも別の場所に渡すべきなのか。
ルールが守られないのも、サブエージェントが動かないのも、多くは「どこに渡すか」の設計の問題だ。CLAUDE.md・サブエージェント・スキル・Playbook・メモリ・設定/権限・MCPという7つのレイヤーのうち、そのルールはどこに置けば一番効くのか。それを一章ずつ解剖したのが、Zenn Booksの「コードを書けない私がClaude Codeに『仕組み』を渡すまで」（Vol.4）だ。今回の「削れるルール／削れないルール」の話は、第4章「Playbook：手順ではなく『判断の地図』を渡す・腐らせない」と地続きになっている。
