CLAUDE.md 最適化 v2 — 「置き場所」で効果が変わる

2026年3月7日 16:33 更新

一言でいうと

CLAUDE.md はシステムプロンプトじゃない。ルールの「置き場所」を変えるだけで効果が上がる。

なぜこれが必要なのか

今の CLAUDE.md は77行。行数自体は悪くないけど、「会話の後半で忘れられる」問題が構造的に起きている。

たとえば「設定ファイルを変えたら yadm（設定ファイルをGitで管理するツール）で commit → push すること」というルール。これは作業の最後に必要なルールなのに、CLAUDE.md に書いてあるだけだとセッションの終盤で忘れられやすい。

原因は、CLAUDE.md がシステムプロンプト（AIの根本的な性格設定）ではなく、ユーザーメッセージ（会話の最初の1通目）として注入されること。会話が長くなるほど「最初の1通目」は遠い記憶になり、影響力が薄れる。

放置すると、セッション後半で重要なルールが無視される現象が繰り返される。前回の最適化（v1、2/27）で122行→77行に減らしたのは正しかったけど、「何行あるか」より「どこに置くか」が本質だった。

何をするのか

CLAUDE.md の77行を「いつ必要か」で3つに仕分ける。

BEFORE（現在）

77行すべて CLAUDE.md に集約
セッション開始時に1回注入
後半で忘れられるリスク
全ルールが毎回読み込まれる

AFTER（提案）

CLAUDE.md は約45行に絞る
コーディングルールは rules/ へ
ファイル編集時に自動注入
不要な行は削除

3つの置き場所の違い

置き場所	注入タイミング	影響力	向いている内容
`CLAUDE.md`	セッション開始時（1回）	会話が長くなると薄れる	プロジェクトの全体像、ワークフロー
`.claude/rules/`	対象ファイルを初めて触った時	作業中に注入されるので強い	コーディングルール、設定変更手順
`--append-system-prompt`	常時（システムプロンプト）	最も強い（減衰しない）	絶対に忘れてほしくない行動規範

.claude/rules/ のポイントは、ファイルパスの条件をつけられること。「.ts ファイルを編集するときだけ」「package.json を触るときだけ」のように、必要なタイミングで必要なルールだけ注入される。しかも CLAUDE.md より「新しいメッセージ」として届くので、影響力が強い。

具体的な仕分け

Step 1: CLAUDE.md に残す（約45行）

「セッション開始時に知っておくべき情報」だけを残す。

1 基本原則（ワークフロー系）

「専門用語は括弧で解説」「AskUserQuestion で質問」「調査してから自作」「t-wada の性格を憑依」「recall search の使い方」「回答1行目は意味のあるテキスト」など。これらは全タスクに共通する行動指針なのでCLAUDE.mdに残す。

2 ツール情報・プロジェクト構造

パッケージマネージャの判定方法、外部ツール連携（X・Discord・Gemini で何を使う/使わない）、plan-viewer の場所、Second-Brain のパス。Claude が最初に作業環境を理解するために必要。

3 コンテキスト管理

Opus/Sonnet の使い分け基準、/compact のルール（Obsidian 書き出し→compact の順序）。セッション全体の管理方針。

Step 2: `.claude/rules/` に移す（4-5ファイル）

「特定のファイルを触るときに必要なルール」を移動する。ファイルを触ったタイミングで自動注入されるので、セッション後半でも忘れられない。

A rules/code-style.md — コーディングルール

「コメントは Why のみ」「型アサーション（as）は設計で回避」「後方互換性は不要」。.ts / .tsx / .js ファイルを触った時だけ注入。

B rules/config-files.md — 設定ファイルのルール

「デフォルト値を調べ、変更が必要な場合のみ追記」「jsonc 対応なら .jsonc 拡張子」「JSONC のコメントは行末」。.json / .jsonc / tsconfig* を触った時だけ注入。

C ライブラリ採用基準 → CLAUDE.md に残す（変更）

当初は rules/dependency-eval.md に移す案だったが、フィードバックにより変更。ライブラリを採用するかどうかの判断は package.json を編集する前のプランニング段階で必要。rules/ だと「ファイルを触った時」にしか注入されないので手遅れになる。CLAUDE.md に残して、調査フェーズで常に意識できるようにする。

D rules/dotfiles.md — 設定管理のルール

「設定変更後は yadm add → commit → push」「ADR（設計判断の記録）は ~/.claude/docs/adr-*.md に蓄積」。Claude Code の設定ファイルを触った時だけ注入。

Step 3: 削除する行

Claude がデフォルトで既にやっていること、またはスキルの description（説明文）で自動トリガーされるもの。消しても品質は変わらない。

削除する行

時間をいくらかけても良いので、品質を優先すること
実装は静的解析とテスト実行、動作確認まで完了させる
型アサーション (as) は設計で回避する
plugin-dev:* で利用可能なスキルを確認し…
検証の際にはtmux-claude-debuggingスキルを使用する

削除の理由

品質優先・静的解析は検証順序のルール（tsc → リンター → テスト）と重複。
型アサーション回避も Claude の標準的な振る舞い。
plugin-dev / tmux-debugging はスキルの description で自動的に発火するから、CLAUDE.md で重ねて指定する必要がない。

※ YAGNI / KISS はフィードバックにより残すことに決定。Claude のデフォルト行動ではあるが、ユーザーが「特に強調したい」意思表示として機能している。

効果の見込み

	BEFORE	AFTER
CLAUDE.md 行数	77行	約50行
コーディングルールの影響力	セッション後半で減衰	ファイル編集時に都度注入（減衰しない）
毎セッションの読み込み量	全77行（不要なルール含む）	45行 + 必要な rules のみ
yadm push 忘れ	起きうる	設定ファイル編集時に自動リマインド

ポイント

判断基準は「消したら Claude がミスするか？」 — 公式ドキュメントが推奨するゴールデンルール。No なら消す。今回の削除候補は全てこの基準でテスト済み。

Anthropic 公式 + Zenn 記事 + X の話題を統合した結論。 CLAUDE.md の行数を減らすだけでなく、「ルールが必要なタイミングで届く」仕組みにすることが本質。

リポジトリ作成時のルール（frontend-design で LP 作成、README は最小限）は今回見送り。 .claude/rules/ は paths 条件でファイル単位のトリガーができるけど、「リポジトリ作成時」はファイルパスで条件指定しにくい。スキル化（/new-repo のようなコマンド）のほうが適切。

ソース: Zenn: CLAUDE.md に何を書くべきか / Anthropic 公式 Best Practices / HumanLayer: Writing a good CLAUDE.md / Builder.io: CLAUDE.md Guide