CLAUDE.md を薄く強力に育てる。ルールを常駐させず、意味で発火させて効かせる Progressive Disclosure 構成

Claude Code を使い込むほど、CLAUDE.md にはルールや作業のコツが溜まっていきます。ところが CLAUDE.md は毎セッション自動で読み込まれるため、足したぶんだけ毎回のコンテキスト消費が増えます。しかも公式ドキュメントは CLAUDE.md を 200 行以下に保つことを推奨しており、「長いファイルはコンテキストを消費し、遵守率を下げる (Longer files consume more context and reduce adherence)」と明記しています。教えたいことは増えるのに、教えるほど効かなくなります。CLAUDE.md を育てようとすると、必ずこのジレンマに突き当たります。

本記事で紹介する構成は、このジレンマを構造的に回避します。ルールの本文は ~/.claude/docs/ 配下 (起動時にロードされない場所) に置き、CLAUDE.md には「当てる条件」だけを書きます。条件に当たった瞬間、Claude が自分でファイルを読みに行きます。この構成の要点は、ルールを 1 件増やしても、常駐コンテキストは CLAUDE.md のトリガー 2〜3 行ぶんしか増えない ことです。ルール本文が 100 行あっても、常駐は 2〜3 行のままです。つまり常駐コストの面でスケールする作りになっています。

この構成は、Anthropic 公式の Agent Skills が採用している設計原則 Progressive Disclosure (段階的開示) と同じ構造を持っています。本記事では、公式ドキュメントの記述を裏付けにしながら、この構成の作り方と使いどころを整理します。

目次

CLAUDE.md の常駐コスト、起動時に何がロードされるのか
お手本は公式 Skills の Progressive Disclosure (段階的開示)
docs/ 配下とトリガー表で同じ構造を CLAUDE.md に作る
ルール 1 件が常駐 2〜3 行に固定されるからスケールする
paths frontmatter (機械的スコープ) との使い分け
hooks・Skills との境界
どこに何を置くか、配置の 4 段階
既存環境を移行する最初の一歩
モデルが賢くなれば不要になるのか
まとめ
Appendix (最小再現セット)
参考資料

CLAUDE.md の常駐コスト、起動時に何がロードされるのか

まず前提として、「常駐している」(= セッション開始時にコンテキストへロードされる) ものが何かを、公式ドキュメントの記述で整理します。ユーザースコープ (~/.claude/ 配下) で、ユーザーが書くルールのロード経路は次の 2 つです (このほかに auto memory の MEMORY.md も起動時にロードされますが、Claude が自動管理する領域なので本記事では扱いません)。

1 つ目の経路は、CLAUDE.md 本体と、そこから @ インポートされたファイルです。CLAUDE.md には @path/to/import 構文で別ファイルを取り込めますが、公式ドキュメントはこう明記しています。

Imported files are expanded and loaded into context at launch alongside the CLAUDE.md that references them.
(インポートされたファイルは展開され、参照元の CLAUDE.md とともに起動時にコンテキストへロードされます)

さらに、肥大化対策の文脈でも次のように注意を促しています。

Splitting into @path imports helps organization but doesn’t reduce context, since imported files load at launch.
(@path インポートへの分割は整理には役立ちますが、インポートされたファイルは起動時にロードされるため、コンテキストは減りません)

つまり、長くなった CLAUDE.md の中身を別ファイルに切り出して @ 参照に置き換えても (例: 300 行の CLAUDE.md を @docs/coding-style.md など 3 行の参照に分割しても)、参照先が起動時に展開される以上、コンテキストに乗る量は分割前と変わりません。見た目の整理にはなりますが、常駐削減にはならないのです。

2 つ目の経路は ~/.claude/rules/ 配下のファイルで、こちらは見落とされやすい経路です。公式ドキュメントには次の記述があります。

Rules without paths frontmatter are loaded at launch with the same priority as .claude/CLAUDE.md.
(paths frontmatter を持たないルールは、起動時に .claude/CLAUDE.md と同じ優先度でロードされます)

rules/ 配下にファイルを置くこと自体が常駐を意味します (後述の paths frontmatter を付けない限り)。CLAUDE.md から @ で参照しているかどうかは無関係です。

この 2 経路が常駐の実体です。何がロードされているかを正確に確認するには、組み込みコマンドの /context (コンテキスト使用量のトークン内訳。Memory files 欄に、実際にロードされたファイルの一覧が並びます) を使います。/memory はメモリファイルの置き場所の一覧と編集の入口で、未作成のエントリも表示されるため、「実際にロードされたか」の確認には /context を使うのが確実です。行数ベースで手早く概算するなら、次のコマンドも使えます。

# CLAUDE.md 本体 + rules/ 配下の合計行数 (概算)
wc -l ~/.claude/CLAUDE.md ~/.claude/rules/*.md

ただしこちらはあくまで概算です。CLAUDE.md が @ インポートしているファイルは含まれず、逆に paths frontmatter 付きで常駐しないルールは数えてしまいます (また rules/ はサブディレクトリも再帰的にロード対象になるため、階層を分けている場合は glob の調整が必要です)。削減の before / after を行数で手早く比較する簡易指標と考えてください。

逆に言うと、ユーザーが書くルールで起動時ロードの対象になるのは CLAUDE.md (+ インポート先) と rules/ 配下だけです。それ以外の場所、たとえば ~/.claude/docs/ のような任意のディレクトリに置いたファイルは、Claude が Read ツールで明示的に開いたときだけコンテキストに乗ります。この「ロードされない置き場」が、後述する構成の土台になります。

お手本は公式 Skills の Progressive Disclosure (段階的開示)

Progressive Disclosure は、AI エージェントに情報を渡すときの設計原則で、「必要な瞬間に、必要な粒度で、必要な情報だけ」を届ける考え方です。全部を最初に詰め込むと、注意が散って精度が落ち、トークンも無駄になります。必要な瞬間にだけ渡せば、精度もコンテキストの余白も保てます。

Anthropic 公式の Agent Skills は、この Progressive Disclosure を 3 段階のロードで実装しています。

注目したいのは、公式ドキュメントがこの構造の利点を「スケーラビリティ」として説明している点です。

This lightweight approach means you can install many Skills without context penalty: until a Skill is triggered, only its name and description occupy context.
(この軽量なアプローチにより、コンテキストのペナルティなしに多数の Skill をインストールできます。Skill が発動するまで、コンテキストを占有するのは名前と説明だけです)

Skill をいくつ増やしても、常駐するのは 1 件あたり name + description の 100 トークン程度にとどまります。本文や同梱ファイルがどれだけ大きくても、常駐コストには乗りません。この「増やしても常駐が薄いまま」という性質が、Progressive Disclosure がもたらすスケールの構造です。

なおこの原則は Skills 固有のものではありません。Anthropic のエンジニアリングブログ Effective context engineering for AI agents でも、軽量な識別子 (ファイルパス等) だけを保持して実行時に必要なデータを動的にロードする “just in time” 戦略として、エージェント設計の一般的なアプローチに位置づけられています。

そして本記事の核心はここです。同じ構造は、Skill にしない生のルール (作業規律・判断基準) に対しても、自分の CLAUDE.md 環境に作れます。

docs/ 配下とトリガー表で同じ構造を CLAUDE.md に作る

実装は次の 2 つの組み合わせです。

(a) ルール本文を ~/.claude/docs/ 配下に置く (常駐しない場所)

前述のとおり、起動時ロードの対象は CLAUDE.md (+ インポート先) と rules/ 配下です。~/.claude/docs/ のような任意のディレクトリは対象外なので、ここに置いたファイルは Claude が Read で開いたときだけコンテキストに乗ります。ルール本体・方法論・詳細規律は基本的にここに置きます。

mkdir -p ~/.claude/docs/disciplines

(b) CLAUDE.md にトリガー表を書く (「当てる条件」+「やること」)

CLAUDE.md 本文に、意味的な条件と対応するアクションを 1 対 1 で書きます。筆者の CLAUDE.md を簡略化・再構成した例です。

# 作業の方法論・規律（トリガー表 — 当てる条件に当たったら従う）

各項目の「当てる条件」が発動トリガー。当たった瞬間に「やること」に従う。やることがファイル参照になっている項目は、その場で Read してから挙動を決める（要点をここに置かないのは、要点で済ませて誤動作するのを防ぐため）。直接の行動が書いてある項目はそれだけで動ける。

1. **段階的構築**
   - 当てる条件: 数百行規模の長い成果物 (HTML / Markdown / コード) を書こうとするとき
   - やること: docs/disciplines/incremental-construction.md を読んで従う

2. **ADR 起票**
   - 当てる条件: 代替案比較を始めた瞬間 / 同じ問題に 2 回目のアプローチが頭をよぎった瞬間
   - やること: docs/disciplines/adr-howto.md を読んで起票する

3. **過去セッションの想起**
   - 当てる条件: 「前に調べた / やった / 決めた気がする」と感じた瞬間 / 同じテーマを一から調べ直しそうなとき
   - やること: 過去の会話ログ・メモを横断検索するスクリプトを実行してから着手する

4. **人間向け文書の文体**
   - 当てる条件: 人間の読者に向けた文書 (記事・スライド・README・報告書等) の本文を書き始める瞬間 (ファイル適用前にチャットへ修正文を提示する場合も含む) / 既存文書をレビュー・リライトするよう頼まれた瞬間 (LLM 向け指示ファイル = SKILL.md / CLAUDE.md 等は対象外)
   - やること: docs/disciplines/writing-guide.md を読んで、禁止リストと照合しながら書く

これは Skills の 3 段階ロードと同じ構造です。トリガー表の各項目 (2〜3 行) が Level 1 のメタデータに相当し、docs/disciplines/ 配下の本文が Level 2 に相当します。Skill の description をユーザーの要求にマッチさせる代わりに、「当てる条件」を Claude 自身の状況認識にマッチさせています。条件に注目すると、2 の「同じ問題に 2 回目のアプローチが頭をよぎった瞬間」や 3 の「前に調べた気がすると感じた瞬間」は、ファイルパスにもツール呼び出しにも現れない純粋な認知状態です。こうした条件で発動させられることが、この仕組みの強みです。また 3 のように「やること」が 1 行の直接行動で済む項目は、参照先ファイルを持たずトリガー表だけで完結させることもできます。この形は項目の全文を常駐させるのと同じことなので、数行で書き切れる規律に限って使います。4 のように「LLM 向け指示ファイルは対象外」「チャットへの提示も含む」といった除外・包含の条件を添えて、発火の範囲を調整することもできます。

書くときのポイントは 2 つあります。

1 つ目は、「当てる条件」を意味的な言葉で書くことです。「〜しようとする直前」「〜と感じた瞬間」「〜を始めた瞬間」のように、発動してほしい瞬間の状態を描写します (本記事では、条件に当たって規律が呼び出されることを「発動」または「発火」と呼びます)。トリガー表は発火するかどうかがすべて LLM の意味理解に懸かっている仕組みなので、発火の信頼性を上げる最大のレバーはこの言葉選びです。同じ規律でも、「アーキテクチャ変更時」のような外形的なラベルより、「代替案の比較を始めた瞬間」「同じ問題に 2 回目のアプローチが頭をよぎった瞬間」のように内的な状態を描写する言葉のほうが、狙って発火させやすくなります。

2 つ目は、CLAUDE.md 側にルールの要点を書かないことです。要点や抜粋を書いてしまうと、Claude がファイルを Read せずその要点だけで動いてしまうことがあります。全文を読ませたいルールは、あえて中身を書かず参照だけを置きます。

合言葉テストで動作確認する

構成ができたら、思い込みではなく動作で確かめます。

• 常駐していないことの確認。docs/disciplines/ に「合言葉は◯◯」とだけ書いたテストファイルを置いて新規セッションを起動し、Claude に (Read させずに) 合言葉を聞きます。答えられなければ常駐していません。逆に同じファイルを rules/ に置くと答えられるはずです
• トリガーが効くことの確認。トリガー表の「当てる条件」に当たる依頼を実際にして、Claude が該当ファイルを Read しに行くかを観察します

ルール 1 件が常駐 2〜3 行に固定されるからスケールする

この構成の最大の利点は、冒頭に書いたとおりルールを増やしたときの常駐コストの伸び方にあります。

rules/ 配下に直接置く従来の構成では、ルール 1 件の常駐コストはそのファイルの全行数です。50 行の規律ファイルを足せば、常駐が 50 行増えます。ルールの本文を丁寧に書くほど、そして件数が増えるほど、常駐は本文の総量に比例して膨らみます。「詳しく書きたい。でも書くと毎セッション重くなる」。冒頭のジレンマの正体はこの比例関係です。

トリガー表の構成では、この比例関係が切れます。ルール 1 件の常駐コストは、本文の行数がいくらであってもトリガー表の 2〜3 行に固定されます。本文を 30 行から 100 行に育てても、常駐は 1 行も増えません。ルールが 10 件でも 20 件でも、常駐の増分は件数 × 2〜3 行だけで、各ルールをどれだけ詳しく書くかとは無関係です。

これは Skills が「Skill をいくつ入れても常駐は 1 件あたり name + description の 100 トークン程度」で済むのと同型の構造です。常駐するのはインデックスだけで、本文はオンデマンドで読まれます。この作りにしておくと、「ルールを足すと重くなるから足すのをためらう」というブレーキが外れ、CLAUDE.md 環境を安心して育て続けられます。公式ドキュメントの「200 行以下」推奨とも両立します。本文がどれだけ育っても、CLAUDE.md 本体はトリガー表だけの薄いままだからです。

副次的な利点として、鮮度もあります。常駐ルールは起動時のスナップショットですが、オンデマンドのファイルは使う瞬間にディスクから読まれるため、規律ファイルの修正が再起動なしで次の発火から効きます。さらに、発火したときの本文はコンテキストの最後尾、つまり行動の直前の位置に入ります。前掲の Anthropic エンジニアリングブログも、コンテキストが長くなるほどモデルの想起精度が下がる現象 (context rot) に触れています。セッション冒頭に載って会話とともに遠ざかっていく常駐ルールと、使う瞬間に手元へ届くオンデマンドの本文では、効き方の性格が違います。

この「必要な瞬間にだけ強く効く」性質は、ルールの用途も広げます。渡せるのは禁止事項の列挙だけではありません。「こういう場面ではこういう出力に流れがち」というモデルの癖に、その瞬間だけ前提のバイアスを差し込んで思考の方向を整える、いわばモデルを自分好みに「調律」する使い方ができます。常時かけっぱなしの常駐指示と違い、特定の瞬間にだけ差し込むので、調律の項目を何件増やしても常駐は増えません。

paths frontmatter (機械的スコープ) との使い分け

rules/ 配下のファイルには paths frontmatter を付けて、パターンに合致するファイルを Claude が Read したときだけロードさせることもできます。これも常駐削減の手段ですが、トリガー表とは発動条件の表現力が違います。

paths は「既存の .tf ファイルに手を入れるときだけ、モジュール構成や命名規約などの Terraform コーディング規約をロードする」のような、観測可能な作業状態に向きます。ただし 1 つ注意があります。発動のきっかけは「該当ファイルの Read」だけです。公式ドキュメントは次のように明記しています。

Path-scoped rules trigger when Claude reads files matching the pattern, not on every tool use.
(paths でスコープされたルールは、Claude がパターンに合致するファイルを読んだときに発動します。すべてのツール実行で発動するわけではありません)

既存ファイルの編集は Edit の前に Read が入るので発動しますが、新しい .tf をゼロから書き起こす Write では発動せず、規約は届きません。コーディング規約が最も効いてほしい新規作成の場面で抜ける可能性がある、ということです。機械マッチで確実なのはパス判定そのものであって、Read という発動の機会が来ることまでは保証されません。

一方「代替案の比較を始めた瞬間」「前に調べた気がすると感じた瞬間」のような Claude の意図・認知状態は、そもそもパスでは表現できません。ここがトリガー表の守備範囲です。

hooks・Skills との境界

Claude Code には、機械的なガードである hooks (PreToolUse 等) と permissions.deny、そして Skills という手段もあります。本記事で扱ってきた CLAUDE.md や rules も含め、モデルの外側からエージェントの挙動を支えるこうした仕組みは、総称してハーネスと呼ばれます。トリガー表に何を受け持たせるかは、hooks・Skills との境界を引くと決めやすくなります。

確実に守らせたいものは hooks に寄せる

公式ドキュメントは、CLAUDE.md がコンテキストであって強制力のある設定ではないことを明言し、こう案内しています。

To block an action regardless of what Claude decides, use a PreToolUse hook instead.
(Claude の判断に関わらずアクションをブロックするには、代わりに PreToolUse hook を使ってください)

hooks は発火率 100% なので、条件をツール名・コマンド文字列・ファイルパスで書けるものは hooks の側に置くほうが確実です。トリガー表にしか書けないのは、次のどちらかに当たるものです。

• 条件が機械観測できないもの。「仕様が複数解釈できると気づいた瞬間」「前に調べた気がした瞬間」のような、Claude の意図・認知状態が条件になっている
• 介入すべきタイミングにツール呼び出しがないもの。たとえば「数百行の成果物を一気に書き下ろそうとしている」に PreToolUse (Write) で介入しても、発火した時点で本文は組み上がっていて手遅れです。介入点が生成より前・思考の中にある

逆に、運用してみて「この条件は結局毎回特定のツール呼び出しに収束する」と分かった項目は、hook に昇格させて 100% 化できます。この昇格先を持っておくと、トリガー表は本当に LLM の判断が必要な項目だけに絞り込まれていきます。

Skills との違いは「手順のパッケージか、判断の規律か」

Skills との違いは、実は起動機構にはありません。Skill の description も、トリガー表の「当てる条件」も、常駐する短い文を LLM が意味判定して全文をオンデマンドで読む、同じ Progressive Disclosure の仕組みです。違いは対象にあります。Skills が扱うのは、呼ばれた瞬間に実行して完了する手順です。トリガー表が扱うのは、特定のタスクに閉じず、あらゆる作業に横断して効く判断規律です。

Skills はスクリプト同梱・引数・配布を備えた「手順を実行するパッケージ」です。「結論を出す前に反証側の目で見直す」のような判断規律を Skill に切り出しても、これらの付属能力に使い道がありません。また Skill を増やすと description を 1 件ずつ常駐させ (発動条件を作り込むと 1 件で数百トークンになることもあります)、Skill 一覧を混雑させて手順系 Skill の発火精度にも影響します。この分離は、わかりやすさに加えて常駐コストの面でも合理的です。なお Skills に切り出した手順の中に危険な操作が含まれる場合、hooks / deny の機械ガードは Skill と排他ではなく併用できます。

発火は 100% ではないというトレードオフ

トリガー表の弱点も明確にしておきます。発火が LLM の意味判定である以上、hooks のような 100% の確実性はありません。公式ドキュメントも、具体的で簡潔な指示ほど一貫して従われると述べており、CLAUDE.md の遵守が確率的なものであることを前提にしています。

だからこそ、違反したときの被害が大きい「絶対に守りたいルール」は、常駐 (後述の段階 1) か hooks に置きます。トリガー表に置くのは、発火漏れが致命傷にならない方法論・判断規律です。遵守力を「発火率 × 発火時の効き」の掛け算で考えると、絶対に守りたいルールは常駐、発火時の詳細度と鮮度が効く判断規律はトリガー表、という使い分けになります。

被害の大きさとは別に、もう 1 つトリガー表に置けないものがあります。発動すべき瞬間を、Claude 自身が自覚できないタイプの規律です。トリガー表の条件には「同じ問題に 2 回目のアプローチが頭をよぎった瞬間」のような内的な出来事も書けますが、それはその出来事を Claude 自身が観測できるからです。一方、「結論を急いで検証が緩んでいる」「設計上の判断を通常の変更と誤認している」といった状態は、渦中では認識そのものが立ちません。認識できない条件は言葉をどれだけ磨いても発火の機会が来ないため、この種の規律は常駐 (後述の段階 1) に置き、毎ターン視界に入れておきます。

発火漏れそのものは、hook を操作の禁止ではなく「一度だけ立ち止まらせる関所」として併用することでも補えます。先ほど hooks に寄せたのは、禁止コマンドのように条件も対処も機械の言葉で書き切れる規律でした。発火の瞬間は機械で拾えるのに、中身の判断に LLM が必要で hooks に移せない規律が残ります。そこで規律の本文は docs 配下に置いたまま、対象パスへの書き込みなど機械的に観測できるツール呼び出しの直前に、hook で案内を返します。実装は、セッション初回だけ deny して再実行は素通しにする形でも、ブロックせず案内文を添えて続行させる形でも成立します。案内文は「規律ファイルを確認したか」という確認調にせず、「この操作は◯◯に当たるか。当たるなら△△を読んでから進め、当たらないならそのまま再実行してよい」のように、読むべき状況かどうかの判断とその後の分岐まで書きます。確認調の案内には「確認済み」と即答して素通りする余地がありますが、判断と次の一手まで指定すれば、トリガー表の発火が漏れていてもツール実行の時点で同じ判断が一度は確実に走ります。判断基準の本文まで hook に書き込むと docs との二重管理になるので、hook が運ぶのは判断の問いと参照先までに留めます。ただしこの補強が効くのはツール呼び出しが起きる規律だけで、チャットへの提示のようにツールを伴わない瞬間には届きません。そこは引き続きトリガー表の意味的な発火が受け持ちます。

どこに何を置くか、配置の 4 段階

ここまでの仕組みを合わせると、ルールの置き場は常駐コストの高い順に 4 段階に整理できます。なお以下で「機械ガード」と呼ぶのは、settings.json の permissions.deny や hooks による、Claude の判断に依存しない機械的なブロックのことです。

どの段階に置くかは、次の 5 軸を上から順に当てて決めます。先頭の軸は安全の制約、残りの軸はコストの最適化で、この順序に意味があります (安全の要求を先に確定させないと、被害が大きいルールの機械で拾えない残余まで、発火が確率的な段階 2 に置いてしまいます)。

• 違反したときの被害は不可逆で大きいか (機密の漏洩・ファイルの削除・外部への送信等。revert できる commit のように事後に取り消せるものは含めない)。YES なら他の軸に関わらず段階 1 か hooks を主ガードにする (前述のとおり、発火が確率的なトリガー表を単独のガードにしない)
• 発動条件は機械的か、意味的か。機械的 (パス・コマンドで書けて、かつ介入が間に合うツール呼び出しがある) なら、発火率 100% の機械側 (段階 3 か hooks) を最優先する。発火が Claude の自覚に依存しない点でも文章より確実。条件をコマンドで書けても、発火した時点で生成が終わっていて手遅れになるもの (前述の「数百行を一気に書き下ろす」等) は意味的として扱う
• 機械的だった場合、機械ガードだけで完全にカバーできるか。できるなら段階 4 (削除・機械ガード一本化)。挙動規律が残るなら段階 3 か hooks に置いた上で、機械で拾えない残余を文章ルールとして併置する (併置先は次の 2 軸で決める。段階 3 の paths は発動時に本文全文が届くため、併置が要るのは deny やブロック型 hooks の場合だけ)
• 常に適用されるか、ほぼ毎ターン発動するか。「〜するとき」という発動の瞬間を限定できないルール (応答の言語・文体等) はトリガーで拾う瞬間がなく、瞬間を書けてもほぼ毎ターン発動するルールは毎回 Read が走ってオンデマンドの節約にならない。どちらも段階 1 (本文が数行ならトリガー表への直書きでも同等)
• 発動すべき瞬間を Claude が自覚できるか。自覚できないタイプの規律 (違反の渦中でそう認識できないもの・前述) は、条件を自己認識できず段階 2 では発火しないため、段階 1 に置いて毎ターン視界に入れる。ここまでのすべての判定を通り抜けたもの、つまり特定の瞬間に発動し、機械では書けず、Claude が自覚できる規律だけが、段階 2 に落ちる

この 5 軸は、手順パッケージの分離 (前節) を先頭に置くと「対象の種別 → 要求される確実性 → コスト最適化」の 3 層に並びます。フロー図にすると次のとおりです。

段階 4 には注意点が 1 つあります。permissions.deny や hooks で機械的にブロックされている操作 (例: rm 系コマンドの deny) は文章ルールを削れそうに見えますが、機械ガードでカバーされない側面は残す必要があります。スクリプト経由の同等操作 (Python の os.remove 等)、「拒否されたら別の方法を試す」ではなく「ユーザーへの提示に切り替える」といった挙動規律、判断のリマインダーなどは、機械ガードでは拾えません。一般論で「重複しているから削れる」と判断せず、ガードの実装と文章ルールの中身を突き合わせてから削るのが安全です。

既存環境を移行する最初の一歩

まず自分の常駐サイズを可視化するところから始めます。/context でトークン内訳と、実際にロードされたファイルの一覧 (Memory files 欄) を確認します (行数で手早く見るなら前述の wc -l でも構いません)。

次に rules/ 配下の各ファイルを、前述のフロー図と同じ順で 1 件ずつ問い直し、Skills と 4 段階に振り分けます。上から順に判定し、最初に当てはまった行で確定します。

• 手順を実行するパッケージ (スクリプト・引数・配布に使い道がある) → 4 段階でなく Skills へ切り出す
• 違反時の被害が不可逆で大きい → 段階 1 か hooks を主ガードにする
• 発動条件をパス・コマンドで書ける (かつ介入が間に合うツール呼び出しがある) → 機械ガードで完全にカバーできるなら段階 4 (削除)。挙動規律が残るなら段階 3 (paths frontmatter。発動は Read 起点) か hooks に置き、機械で拾えない部分を文章として併置する (併置先は下の 2 行で判定。paths に置いた場合は発動時に本文全文が届くため併置不要)
• 常に適用される・ほぼ毎ターン発動する → 段階 1 のまま
• 発動すべき瞬間を Claude が自覚できない → 段階 1 のまま (常駐で毎ターン視界に入れる)
• ここまでのどれにも当たらない (特定の瞬間に発動し、機械では書けず、自覚できる) → 段階 2 に降ろす (本文を docs/disciplines/ へ移動し、CLAUDE.md トリガー表に 1 項目追記)

移行時に陥りやすい落とし穴を 2 つ挙げます。

• ファイルを分けるだけでは常駐は減りません。分割・移動した先が CLAUDE.md から @ インポートされる場所や rules/ 配下である限り、起動時ロードの対象のままです。常駐が減るのは、docs/ 配下のようなロード対象外の場所へ本文を出し、CLAUDE.md 側をトリガー表に置き換えたときだけです
• 一度に全部変えず、1 件ずつ移します。一括で移すと、機械ガードとの重複判断の見落とし (前述) や、常駐に残すべきルールの取りこぼしが起きやすくなります。移すたびに合言葉テストとトリガー発火の観察で確かめるのが確実です

最後に、運用上の注意を 1 つ挙げます。トリガーの発火漏れはエラーにならず、何のシグナルも残しません。観測の仕組みがないと「条件の言葉が悪くて効いていない」ことに気づけないため、トリガー表は「書けば効く設定」というより、発火漏れを見つけて条件の言葉を直し、発火テストで確かめる「運用込みで効く監視ルール」に近いものと捉えておくのが実態に合います。

モデルが賢くなれば不要になるのか

最後に、「モデルが賢くなれば、こうした整備は不要になるのではないか」という疑問に触れておきます。この疑問の背景には、賢いモデルほど細かい指示で縛るより思考の余地を残した方がうまく動く、という考え方があります。その考え方自体は正しいものです。それでも、整備を減らしていったとき最後まで残るのは、モデルがどれだけ賢くなっても推論できない情報です。利用者個人の好み、チームのルール、どの環境が本番かといった環境固有の事情は、モデルの能力では当てようがなく、何らかの形で渡すしかありません。

トリガー表は、その渡し方として最も「縛らない」形を狙ったものです。全文を常駐させて毎ターン読ませるのではなく、常駐させるのは条件の数行だけにして、いつ効かせるかの判断はモデル自身に任せます。前述のとおり発火は LLM の意味理解に懸かっているため、この構成の弱点である発火率は、モデルが賢くなるほど改善が期待できます。ただしこれは期待であって保証ではありません。発火が懸かっているのは、長いコンテキストの中で常駐指示に追従し続ける能力であり、これは世代間で単調に改善するとは限らず、モデル更新で効き方が変わることもあります。だからこそ前述の発火テストを世代ごとの回帰テストとして使い、改善していれば剥がし、変わっていれば条件の言葉を直します。モデルの進化を追い風にできるかは、この観測運用とセットです。

同時に、モデルの進化は「もう素でできるから消せる」ルールも生みます。条件が機械化できると分かったものを hook に昇格させるのと同じように、モデルの世代が上がるたびに棚卸しし、不要になったルールは段階 4 (削除) に落とします。ルールは増やす一方ではなく、モデルが賢くなった分だけ剥がしていく前提の運用です。1 件 1 ファイル + トリガー表のインデックスという構成は、足すときだけでなく、この剥がす判断もしやすくします。

足す側も同じで、筆者は思いつきや念のためでルールを足さないようにしています。主な起点は実タスクで起きた失敗で、再発 1 件で即ルール化はせず、起票から恒久化・効果の観測待ちまでの状態を持つ台帳に記録して、恒久化するかどうかは人間が判断します。恒久化した対策も入れて終わりではなく、次に同じ状況が来たときに効いたかを観測できてはじめてクローズします。効かなければ条件の言葉を直すか、対策ごと差し替えます。トリガー表に並ぶのは、この台帳を通ったものだけです。

まとめ

CLAUDE.md は「書けば書くほど重くなる」ものではなく、置き場所の設計しだいで薄いまま育てられます。実際、筆者の環境では台帳と発火テストを通じて今もルールが入れ替わり続けていますが、それでも常駐は薄いまま保たれています。まずは /context で自分の常駐サイズを可視化し、rules/ のファイルを 1 件、トリガー表 + docs/ 配下の構成に降ろすところから試してみてください。

Appendix (最小再現セット)

本記事の「段階 2 (Progressive Disclosure)」構成を最小限で作る手順です。

A-1. オンデマンド置き場を作る

mkdir -p ~/.claude/docs/disciplines

A-2. CLAUDE.md にトリガー表の骨組みを足す

~/.claude/CLAUDE.md に以下を追記します (項目は自分のルールに合わせて読み替えてください)。

# 作業の方法論・規律（トリガー表 — 当てる条件に当たったら従う）

各項目の「当てる条件」が発動トリガー。当たった瞬間に「やること」に従う。やることがファイル参照になっている項目は、その場で Read してから挙動を決める（要点をここに置かないのは、要点で済ませて誤動作するのを防ぐため）。直接の行動が書いてある項目はそれだけで動ける。

1. **段階的構築**
   - 当てる条件: 数百行規模の長い成果物 (HTML / Markdown / コード) を書こうとするとき
   - やること: docs/disciplines/incremental-construction.md を読んで従う

2. **過去セッションの想起**
   - 当てる条件: 「前に調べた / やった / 決めた気がする」と感じた瞬間
   - やること: 過去の会話ログ・メモを横断検索するスクリプトを実行してから着手する

ポイントは、「当てる条件」を意味的な言葉 (「〜しようとする直前」「〜と感じた瞬間」) で書くことと、参照先ファイルを rules/ ではなく docs/ 配下に置くこと (rules/ に置くと auto-load で常駐してしまう) です。

A-3. 既存ルールの棚卸しを Claude Code に頼む

既存の rules/ を棚卸しして移行するなら、Claude Code に次のように頼めます (そのまま貼れます。機械ガードとの重複判断や auto-load 仕様の見落としなど、移行時に踏みやすい失敗への対策を制約として織り込んであります)。

~/.claude/CLAUDE.md と ~/.claude/rules/*.md を読んで、各ルールを次の 4 段階に分類する案を出してください。

1. 全文常駐 (rules/ に置いたまま): 常に適用される・ほぼ毎ターン発動するもの / 違反時の即時被害が大きいもの (機械ガードで守り切れない LLM 判断の残余を含む)
2. トリガー常駐 + 本文オンデマンド: docs/disciplines/ へ移動し、CLAUDE.md のトリガー表に「当てる条件」+「やること」を 1 項目追記。特定の瞬間にだけ発動する方法論が対象
3. paths スコープ常駐: 特定のパスのファイルを Read するときだけ要るもの (発動は該当ファイルの Read 時のみで、新規作成時には発動しない点に注意)
4. 削除: settings.json の permissions.deny / hooks が禁止と拒否時の代替行動の両方をカバーしており、文章でしか伝えられない挙動規律 (スクリプト経由の同等操作の禁止等) や判断のリマインダーが残っていないもの

制約:
- 分類の根拠は一般論で判断せず、各ファイルの中身と settings.json / hooks の実装を必ず Read で確認してから提案してください
- 1 つのルールに複数の挙動が含まれる場合 (例: 「commit は専用フロー経由で行う」と「add を直接打たない」) は、挙動ごとに分けて分類してください。機械化できるかどうかは挙動単位で異なります
- 機械ガードと重複して見えても、スクリプト経由の同等操作・迂回禁止の挙動規律・判断のリマインダーなど LLM 判断が要る部分は削除しないでください。残す部分の置き場所は、高頻度で発動するか発動を自覚できないものなら段階 1、それ以外は段階 2 に分類してください
- 機械ガードへの集約 (段階 4) や hook の新設を提案する場合は、その deny / hook が正当な呼び出しを巻き込まないかを先に確認してください (例: git add を一律に deny すると、commit を代行する自作 Skill の内部で実行される git add も巻き込みます)。拒否したい実行だけをコマンドの書式などの機械的な特徴で区別できることを確かめてから提案してください
- 発動条件をツール名・コマンド・パスで書けるのに機械ガードが未実装のルールは、4 段階の分類とは別枠で「hook 新設候補」として提示してください。ただし条件を書けても介入が間に合わないもの (該当ツールが呼ばれる時点で対象の生成・判断が終わっているルール) は候補にせず、段階 2 として分類してください
- スクリプト・引数・配布に使い道がある手順のパッケージが rules/ に紛れていたら、4 段階の分類とは別枠で「Skill 化候補」として提示してください
- 発動すべき瞬間を Claude 自身が自覚できないタイプの規律 (結論を急ぐ、判断を誤認する等) は、段階 2 に降ろすと条件に気づけず発火しません。発動条件をパスで書けるなら段階 3 に、書けなければ段階 1 に残してください
- 文章ルール同士の内容の重複を見つけても、それだけで削除に分類しないでください。同じ規律を複数の経路で発火させる意図的な冗長化のことがあります。重複の指摘と削除の提案は分けて出してください
- rules/ 配下は paths frontmatter を持たない限り auto-load で常駐します。ファイルの分割や @ インポートの整理だけでは常駐は減らない前提で提案してください

出力形式:
- 表は 2 つに分けてください。表 1 は変更提案 (現状の段階から別の段階へ移すもの) だけを載せ、列は「ファイル / 挙動」「現状」「提案」「根拠 (1 行)」とします。変更が無いものは表 1 に載せないでください
- 表 2 は現状維持の確認です。段階ごとにファイル名を列挙するだけにして、根拠は書かないでください (私が聞いたら答えてください)
- 別枠 (hook 新設候補 / Skill 化候補 / 重複の指摘) は表の後に、それぞれ 1 段落以内で書いてください。該当が無い枠は省略してください

まず表 1・表 2 と別枠だけを出して止まってください。私が合意したら、段階 2 のファイル移動と CLAUDE.md への追記を実行してください。

A-4. 動作確認

• 常駐していないことの確認。docs/disciplines/ に「合言葉は◯◯」とだけ書いたテストファイルを置いて新規セッションを起動し、Claude に (Read させずに) 合言葉を聞きます。答えられなければ常駐していません
• トリガーが効くことの確認。「当てる条件」に当たる依頼を実際にして、Claude が該当ファイルを Read しに行くかを観察します

# 常駐行数の before / after 比較 (概算。正確な内訳は /context で確認)
wc -l ~/.claude/CLAUDE.md ~/.claude/rules/*.md

参考資料

• How Claude remembers your project (Claude Code 公式ドキュメント。CLAUDE.md / rules / インポートのロード仕様)
• Agent Skills overview (公式ドキュメント。Progressive Disclosure の 3 段階ロード)
• Effective context engineering for AI agents (Anthropic エンジニアリングブログ)