先に結論だけ
エージェントルールを蓄積すると、1つのルールが次のルール発見を助け、エージェントの自律性が加速度的に高まります。ルール遵守率が低下したら剪定・ワークフロー分割・スキル化で対処します。空いたコンテキストに新たなルールを詰め込み、このサイクルを回すことで複利効果が持続します。
はじめに
本記事はClaude Codeのルール運用における経験則をまとめたものです。
本記事の検証環境はClaude Code v2.1.101（2026-04-11時点）です。
コンパクションの内部挙動はAnthropicが公開しておらず、ルール遵守率の定量計測も環境依存が大きいため、内部メカニズムは断定できません。バージョンごとに挙動が変わる可能性があるため、検証環境と手元のバージョンを照らし合わせたうえでお読みください。
Boris Cherny氏はXのスレッドで、Claude Codeの活用Tipsを共有しています。その中で「チームでCLAUDE.mdに投資する価値がある」と述べています。
公式ドキュメントも、CLAUDE.mdを「毎回説明し直す代わりに書き留める場所」として扱い、失敗の繰り返しやレビュー指摘をきっかけに育てることを推奨しています。本記事では、その具体的な育て方を経験から示します。
対象読者はClaude Codeのルール・スキルの基本概念を知っている方です。コンパクションやコンテキストウィンドウの概念は前提知識として扱います。
複利効果：ルール蓄積が自律性を高める
エージェントが失敗した点をルールに変換し蓄積すると、同じ失敗を繰り返さなくなります。エージェントが自律的に動ける時間が長くなり、人間の介入頻度が減ります。
この効果は単純な蓄積にとどまりません。1つのルールが次のルール発見を助けるフィードバックループが形成されます。たとえば「git push --forceを禁止する」というルールを追加すると、エージェントが安全なgit操作を意識し始めます。その結果、ユーザーは「git cleanの代わりにgit stashを使う」という関連ルールの必要性に気づきやすくなります。ルールが十分に蓄積されると、エージェント自身が関連ルールの追加を提案することもあります。
公式のベストプラクティスは、ルールの肥大化による遵守率の低下と、曖昧な指示が無視されるリスクに焦点を当てています。本記事では、肥大化の兆候の把握から対処、そしてルールへの継続的な投資サイクルまでの経験的な方法論を示します。
限界点：CLAUDE.md遵守率の低下
複利効果がいつまでも続くわけではありません。ルールの蓄積には限界点があります。
観察される兆候
ルールを蓄積し続けると、ある時点で遵守率の低下が観察されます。公式ドキュメントでも、CLAUDE.mdが200行を超えるとコンテキスト消費が増え遵守率が低下すること、コンパクション後にルールが失われたように見える現象が取り上げられています。コミュニティでは以下の現象も報告されています。
- Lost in the middle現象: ルールファイルの先頭と末尾は重視されるが、中央部が忘却される
- コンパクション後の遵守率低下: GitHub Issue #14258では、コンパクション後のフレームワーク遵守率の低下が具体的に報告されています
- 復唱ルールの効果: エージェントにルールを繰り返させる指示が、作業コンテキストへのルール転写と忘却検知の両方に機能する
これらの兆候が現れたら、ルールと作業コンテキストのバランスが崩れ始めたサインです。
背景：ルールのコンテキスト占有構造
なぜ遵守率が低下するのでしょうか。
公式ドキュメントに明記された事実: 公式ドキュメントによると、CLAUDE.mdはシステムプロンプトではなくユーザーメッセージとして注入されます。コンパクション後にディスクから再読み込みされるため、ルール自体は消えません。
コミュニティでの報告: 前述のIssue #14258では、コンパクション後に会話の要約が「フレームワークはすでに議論済み」と記載されることでソースファイルの再読が行われなくなり、行動ドリフトが発生するという報告があります。
筆者の推測: ルールはコンテキストを固定的に占有する一方、作業コンテキストだけが圧縮されるという非対称な構造があります。ルール自体は存在していても、作業の文脈が薄くなることで関連付けが弱まり、実質的に機能しにくくなると考えています。
対処サイクル
遵守率の低下が観察されたら、以下の3段階で対処します。
日本語ルールを英訳するだけでもトークン量を削減できます。英語は日本語と比較してトークナイザーの効率が高いため、同じ意味をより少ないトークンで表現できます。
剪定する
ルールから「how（やり方）」だけを残し「why（理由）」を削ります。
公式のベストプラクティスでも「削除したら間違いを犯すか？」を剪定基準として推奨しています。剪定前後でエージェントの作業性能が変わらないことを確認しながら進めます。
剪定の具体例です。
剪定前：
# rm / rmdir Command Policy
## Prohibited Operations
`rm` and `rmdir` are denied (settings.json).
## Why
Accidental file deletion is irreversible and has caused data loss incidents
in the past. macOS Trash provides a safety net with "Put Back" support.
## Alternative
Use `trash-item <path>` to move files/directories to Trash.
剪定後：
# rm / rmdir Command Policy
`rm` and `rmdir` are denied (settings.json).
Use `trash-item <path>` to move files/directories to Trash.
whyセクションを削除しても、エージェントはtrash-itemを使うという行動を維持できます。削除したwhyは、必要に応じてスキルに移動します（後述の「スキル化する」を参照）。
ワークフローを分割する
単一セッションで作業を続けると、作業コンテキストが肥大化します。
たとえばプラン作成→実行→改善点発見→再プラン→再実行を1セッションで繰り返すと、コンテキストが膨張し続けます。改善点をファイルにダンプしてセッションを終了します。改善済みプランから新セッションを開始すれば、コンテキストがリセットされルール遵守率も回復します。
ワークフローの分割基準
ファイルに成果物をダンプできるなら、そのワークフローは分割できます。
分割可能な例：
- バグの調査結果と実行計画をダンプする。修正と確認は別セッション。
- オープンエンドな調査→プランニング→実装をセッションごとにファイル出力。
- 記事プラン作成→記事本体の執筆を別セッションで実行。
ワークフローの分割方法自体もスキル化できます。日常業務には再利用可能な型が多く、スキル化することで成功率が上がります。
スキル化する（遅延ロード化）
CLAUDE.mdやrulesにスキル名を記載しておくと、エージェントはそのルールを適用・実行・判断するときに必要に応じてスキル本体を読み出しに行きます。スキル本体はセッション開始時にはロードされず、必要になった時点ではじめてロードされます。常時ロードされるルールをスキルに切り出すことで、この遅延ロードの構造に切り替えられます。
剪定で削ったwhyの受け皿がスキルです。エッジケースで判断材料が必要なときだけ遅延ロードで参照される構造になります。
ここで重要なのは、インポートと遅延ロードの区別です。
| ロード方式 | 仕組み | メモリコスト |
|---|---|---|
| インポート（常時ロード） | CLAUDE.mdの@インポートやrulesディレクトリのファイルがセッション開始時に結合される |
ファイルサイズがそのまま常駐コスト |
| パスマッチルール | rulesのglobs指定で、特定のファイルパターンにマッチしたときだけロードされる | 条件付き。マッチしなければゼロ |
| 遅延ロード | スキルのdescriptionだけが常時展開され、本体は呼び出されるまで消費しない | descriptionのみ（本体の一部） |
たとえば.github/workflows/*.ymlを編集するときだけGitHub Actions hardening rulesをロードする、といった使い方がパスマッチルールです。
遅延ロードの例として、先ほど剪定したルールをさらに発展させます。
# rm / rmdir Command Policy
`rm` and `rmdir` are denied (settings.json).
Use `trash-item <path>` to move files/directories to Trash.
Background: See `rm-alternative-design` skill for rationale and decision criteria.
剪定で削ったwhyをスキルに移動し、ルールからはスキル名で参照します。通常はルール本体の2行だけで動作し、エッジケースで判断材料が必要なときだけスキルが遅延ロードされます。
常時ロード・パスマッチルール・遅延ロードを使い分けることで、コンテキスト消費を段階的に最適化できます。
スキル化のデメリットは呼び出し漏れ（必要なときにスキルが呼び出されないこと）です。descriptionを充実させることで呼び出し漏れを軽減できます。
循環構造：フィードバックから育てる
剪定・ワークフロー分割・スキル化で空いたコンテキストに、新たなルールを詰め込みます。これが複利効果の循環構造です。
ルール蓄積→遵守率低下→対処サイクル（剪定・分割・スキル化）→コンテキスト回復→新たなルール追加→ルール蓄積……
この循環の中で、ルールの総量は増え続けますが、コンテキストに同時にロードされるルールは対処サイクルによって制御されます。
最初から完璧なルールセットを目指す必要はありません。まず使ってみて、遵守率が低下したら対処サイクルを回します。緻密な事前設計よりも、実際の失敗パターンからルールを帰納的に導出する方が、エージェントの挙動に即した質の高いルールになります。