ある朝、Claude Codeに「おはよう」と打ったら、返ってきたのは朝のブリーフィングではなく、見当違いなコード補完だった。
CLAUDE.mdを開いた。634行。スクロールしても終わらない。セッション開始プロトコル、メンバーの口調定義、行動原則、ライティングルール、タスク管理体制——全部が1ファイルに詰め込まれていた。
Claude Codeは起動時にCLAUDE.mdを読む。コンテキストウィンドウに丸ごと載せる。634行はトークン換算で約2,000。MCP定義と合わせると、会話が始まる前にコンテキストの1割以上が埋まっている計算だ。
量の問題じゃない。構造の問題だ。
何が起きていたのか
CLAUDE.mdは「便利だから全部書く」の誘惑に弱い。
最初は50行くらいだった。プロジェクトの概要、基本的な応答ルール、ファイルパスの規約。これで十分動く。問題はここからだ。
「口調のルールも書いておこう」→ 7人分の口調定義で200行追加。
「行動原則も明文化しよう」→ 100行追加。
「対外ライティングのルールも」→ 50行追加。
「セッション開始・終了のプロトコルも」→ 80行追加。
気づいたら634行。もはやCLAUDE.mdではなく、CLAUDE小説。
実害もあった。コンテキストウィンドウが圧迫されて、長い会話の途中でClaude Codeが自動圧縮を走らせる。圧縮されると、CLAUDE.mdの末尾に書いた重要なルールが消える。634行のうち後半300行が「なかったこと」になる瞬間がある。
「おはよう」で朝のブリーフィングが走らなかったのは、そのプロトコルが圧縮で消えていたからだ。
.claude/rules/ という分割先
Claude Codeには、CLAUDE.mdとは別に自動で読み込まれるルールファイルの仕組みがある。
.claude/
├── rules/ ← ここに.mdファイルを置くと自動で読み込まれる
│ ├── behavior.md
│ ├── tone-and-speech.md
│ └── writing-style.md
├── skills/ ← トリガーワードで呼び出されるスキル定義
│ ├── morning/
│ ├── goodnight/
│ ├── memo/
│ └── resume/
└── settings.json
.claude/rules/ に置いた .md ファイルは、CLAUDE.mdと同じくセッション開始時に自動でコンテキストに読み込まれる。CLAUDE.mdに全部書くのと技術的には同じだが、ファイルを分けられる。これだけで世界が変わった。
ちなみに、rules/ 内のファイルはアルファベット順に読み込まれる。つまりファイル名で優先度を制御できる。00_core.md → 01_behavior.md → 02_style.md のようにプレフィックスをつければ、読み込み順を意図通りに並べられる。うちは今のところ3ファイルなのでプレフィックスなしで運用しているが、ルールが増えてきたら検討する余地がある。
何を残して、何を外に出したか
分割の判断基準は1つ。「これはいつ必要か？」
CLAUDE.mdに残すもの ── 常に必要な情報
- プロジェクトの全体像（チーム構成、フォルダ構造）
- セッション開始・終了のプロトコル
- タスク管理の責任分担
- 基本姿勢（呼称、ファイル保存先）
これらはどの会話でも最初に必要になる情報だ。CLAUDE.mdの役割は「このプロジェクトは何か」を伝えること。組織の定款みたいなもの。
.claude/rules/ に出すもの ── 特定の場面で参照する情報
| ファイル | 行数 | 中身 |
|---|---|---|
behavior.md |
103行 | 行動原則。計画を立ててから動く、完了前に検証する、等 |
tone-and-speech.md |
287行 | 7人分の口調・一人称・呼称ルール |
writing-style.md |
53行 | 対外発信のライティングルール。AI臭の排除 |
口調の定義が287行もあるのは、メンバーが7人いるからだ。それぞれの一人称、他メンバーの呼び方、場面ごとの口調パターン、NG表現。これを全部CLAUDE.mdに書いていたら、本体の情報が埋もれる。
# tone-and-speech.md（抜粋）
## 村田の口調
**基本文体**: 口数少なめ。ぶっきらぼうだけど悪気なし。
技術の話になるとスイッチ入って急に喋る。
#### 〇〇さんに対して
- 砕けた敬語：「〜っすね」「〜っすよ」
- テンション上がったとき：「これヤバいっすよ」
- 報告：「できました」「あ、それもう調べました」
#### NG
- 「ございます」「いたします」等の過度な敬語は使わない
- 長い前置きや回りくどい説明はしない
こういう定義が7人分ある。287行になるのは当然。だが、これは会話中にClaude Codeが参照する情報であって、プロジェクトの構造を理解するための情報ではない。分割すべきカテゴリだ。
.claude/skills/ ── もう一段の分割
rules/ が「常に読み込まれるルール」なら、skills/ は「呼ばれたときだけ展開されるマクロ」だ。
.claude/skills/
├── morning/SKILL.md ← 「おはよう」で展開
├── goodnight/SKILL.md ← 「おやすみ」で展開
├── memo/SKILL.md ← 「メモして」で展開
└── resume/SKILL.md ← 「続きから」で展開
SKILL.mdにはYAMLフロントマターでトリガー条件を書く。
---
name: morning
description: 朝ブリーフィングを実行する。「おはよう」「今日の予定」等で自動トリガー。
---
以下の手順で朝ブリーフィングを実行してください：
1. Google Calendar MCPで今日+明日の予定を取得
2. Gmail MCPで未読・未返信メールを確認
3. 各メンバーのステータスファイルを読み取る
4. ブリーフィングフォーマットに沿って報告
スキルの利点は遅延読み込み。セッション開始時にはスキル名と説明文だけがコンテキストに入り、実際のSKILL.md本文はトリガーされたときに初めて展開される。634行のCLAUDE.mdに全部入れていた時代とは、コンテキスト効率が段違いだ。
Before / After
分割前と分割後を数字で比較する。
【Before】
CLAUDE.md: 634行（全部入り）
rules/: なし
skills/: なし
合計: 634行 → 常時コンテキスト占有: 634行分
【After】
CLAUDE.md: 278行（構造・プロトコル・基本姿勢）
rules/behavior.md: 103行（行動原則）
rules/tone-and-speech.md: 287行（口調定義）
rules/writing-style.md: 53行（ライティングルール）
skills/: 4スキル（トリガー時のみ展開）
合計: 721行 + スキル120行
常時コンテキスト占有: 721行分
（スキルは呼ばれるまで名前だけ）
総行数は増えた。 634行が841行になっている。
でも、それでいい。分割したことで各ファイルが「自分の責務」を持った。口調を修正するなら tone-and-speech.md だけ開けばいい。行動原則を追加するなら behavior.md だけ。CLAUDE.md本体には触らなくていい。
これ、ソフトウェア設計そのものだ。
モノリスをマイクロサービスに分割しても、総コード量は増える。でも変更の影響範囲は小さくなる。テストもデプロイも独立にできる。CLAUDE.mdの分割も同じ原理で動いている。rules/ は共有ライブラリ。どのセッションからも参照されるが、本体とは独立に更新できる。skills/ はプラグイン。必要なときだけロードされて、使わないときはメモリを食わない。
圧縮耐性 ── Compact Instructions
コンテキストウィンドウが限界に近づくと、Claude Codeは古いメッセージを自動圧縮する。このとき、CLAUDE.mdの末尾に書いた情報が失われるリスクがある。
対策として、CLAUDE.mdの末尾に「Compact Instructions」セクションを置いている。
## Compact Instructions（自動圧縮時に保持すべき最重要情報）
コンテキストウィンドウの自動圧縮が発生しても、
以下の情報は必ず保持すること：
1. チーム全体として振る舞う
2. 〇〇さんを「〇〇さん」と呼ぶ
3. 口調は tone-and-speech.md に従う
4. 行動原則は behavior.md に従う
5. ステータスファイル: 各メンバーフォルダに ステータス.md
6. つぶやき保存先: メモ・思いつき/YYYY-MM-DD_つぶやき.md
7. lessons.md: ミスパターンを記録・参照する
これは「圧縮後に残ってほしい情報のサマリー」。Claude Codeの圧縮アルゴリズムはCLAUDE.mdの内容を優先的に保持する設計だが、長すぎると末尾が切れる。だから最重要情報を末尾に凝縮しておく。圧縮が走っても、ここだけは残る。保険だ。
実際、これを入れる前と後で挙動が変わった。入れる前は長い会話の後半で口調が崩れたり、ファイル保存先を間違えたりしていた。入れた後は、2時間超えのセッションでも基本ルールが維持される。やっていることは単純——「忘れるな」と書いてあるだけ。だが、書いてあるのとないのとでは全然違う。人間のチェックリストと同じだ。
CLAUDE.md設計の5原則
運用してみて見えてきた、CLAUDE.md設計のベストプラクティス。
1. 1ファイルに100行以上書いたら分割を疑え
100行を超えたら、そこには複数の関心事が混在している。CLAUDE.mdの責務は「プロジェクトの全体像を伝えること」。それ以外はrulesやskillsに出す。
2. 「いつ必要か」で置き場所を決める
- 常に必要 → CLAUDE.md
-
常に参照されるルール →
.claude/rules/ -
特定のトリガーで必要 →
.claude/skills/
3. 変更頻度で分ける
口調の定義は安定している。一度決めたら変わらない。一方、行動原則は毎週のように追記・修正が入る。変更頻度が違うものを同じファイルに置くと、差分が見にくい。gitの履歴も汚れる。
4. Compact Instructionsは保険として必ず入れる
長い会話でコンテキストが圧縮されたとき、何が残るかはClaude Code任せ。だが、明示的に「これだけは残せ」と書いておくと生存率が上がる。コストはゼロ。入れない理由がない。
5. 総行数を気にするな。構造を気にしろ
分割すると総行数は増える。各ファイルにヘッダやフォーマット定義が入るからだ。でも問題は行数じゃない。「このルールを修正したいとき、どのファイルを開けばいいか一瞬でわかるか？」——これが設計の良し悪し。
書いて終わりじゃない
CLAUDE.mdは書いた瞬間から陳腐化が始まる。
うちでは週に1回、担当者がCLAUDE.mdと全ルールファイルを点検して、「定義と現実のズレ」を洗い出す。使われていない定義は消す。実態に合わない定義は書き換える。新しく必要になった定義を足す。
定義は生き物だ。回しながら育てるもの。
634行のモノリスは壊れた。278行 + ルールファイルの構造に分割してから、「おはよう」は毎朝ちゃんと朝のブリーフィングを返してくれるようになった。