CLAUDE.md が長くなってきたとき、「短くしよう」と考えるのはたぶん間違いです。
書いたルールにはそれぞれ理由があったはずで、消していいものはあまりありません。やることは短縮ではなく、毎回読まれる場所から、必要なときだけ読まれる場所へ移すことです。うちの場合、総量はほぼ変えずに常時ロードだけ半分以下になりました。
うちは6月時点で、毎セッション読まれる分だけで約325行ありました。これを仕分け直して常時ロードを約150行まで落とし、いまは156行で運用しています。この記事は、そのときの作業手順と、迷った行をどう処理したかの話です。
なお rules/ と skills/ の線引きをどう設計するか は以前の記事に、CLAUDE.md / Skills / Agents の3層構成そのものはこちらの記事に書きました。この記事は設計論ではなく、すでに膨らんだ CLAUDE.md を実際に仕分けて戻す作業ログに絞ります。
前提: 何が「毎回」読まれるのか
移す先を決めるには、それぞれがいつ読まれるかを正確に把握しておく必要があります。ここは誤解しやすい部分です。
| 仕組み | 読み込まれるタイミング |
|---|---|
CLAUDE.md（＋ @ で import したファイル） |
毎セッション必ず全文 |
.claude/skills/<name>/SKILL.md |
frontmatter の name と description は毎回／本文はタスクが合致したときだけ
|
サブディレクトリの CLAUDE.md
|
そのディレクトリ配下を触ったときだけ |
Skill に逃がしても description は毎回読まれます。つまり 「手順の本体は本文へ、description は起動条件と照合の手がかりまで」 が正しい運用です。ここを勘違いして description に手順まで書くと、Skill 化した意味が薄れます。
長いから読まれない、という単純な話ではありません。効いていてほしい数行が、今日のタスクと無関係な指示に埋もれるのが問題です。
仕分け: 3分類に振り分ける
各行を次のどれかに振ります。
- 常時ルール … どの作業の日でも効いてほしい（コミット規約、触ってはいけないファイル）
- 条件付きルール … 特定作業のときだけ要る（記事投稿時のタグ上限、リリース手順）
- 参照データ … ルールではなく、必要になったら見に行く情報（料金表、エンドポイント一覧、カタログ）
1と2の線引きは前述の記事に譲るとして、実際に手を動かすと 3の「参照データ」が一番かさばっていた というのが今回の発見でした。ルールのつもりで書いていないので意識に上りにくく、しかも表形式なので行数を食います。
迷ったらこの一問です。
「この行、今日の作業と関係ない日に読まれても意味があるか？」
迷った行の実例
実際に迷ったのは「外部サービスへの投稿は、1回失敗しても再送しない」という行でした。
分類上は明らかに2（条件付きルール）です。その投稿作業をする日以外には関係がありません。素直に投稿用の Skill に入れて終わり、のはずでした。
これを常時ルールとして残したのは、踏んだときの結果が取り消せないからです。API がエラーを返したときに反射的に再送すると、同じ記事が二重に公開される可能性があります。公開されてしまうと、消しても痕跡は残ります。Skill に入れた場合、その Skill が呼ばれた文脈でしか効きません。「投稿スキルを経由せず手で API を叩いた」ような日には効かないことになります。
なので分類の一問には、実務上もう一段の例外を足しています。
「この行が効かなかったとき、あとから取り消せるか？」→ 取り消せないなら、条件付きでも常時ルールに残す
行数の節約より事故の回避が優先です。この例外に当たる行は多くありません。うちの場合は 取り消せない外部への発信（二重公開、人への送信）だけで、2〜3行でした。
逃がし先1: 参照データ → 別ファイル＋「毎回ロードしない」の明記
読めば分かる情報は、本文ごと CLAUDE.md に置く必要はありません。
<!-- Before: 表をそのまま貼っていた -->
## プラン一覧
| プラン | 価格 | 内容 |
|---|---|---|
| プラン1 | 7,700円/月 | チャット、8時間以内返信 |
| プラン2 | 13,000円/月 | 月2回ビデオ + チャット |
（以下30行ほど続く）
<!-- After: 要点1行と、置き場所と、読むタイミングだけ -->
**プラン**: チャット 7,700円 ／ ビデオ+チャット 13,000円
（4プラン詳細カタログは `.claude/rules/plans.md` 参照・毎回ロードしない）
肝は 「毎回ロードしない」と明記すること です。パスだけ書いておくと、見つけた時点で読みに行かれることがあります。
逆に常時読ませたいものは @ 記法で明示的に import します。
@rules/workflow.md
@rules/conventions.md
@ を付けたものは毎回展開されるので、@import の数がそのまま常時ロード量です。ここを増やすと元の木阿弥になります。
逃がし先2: 条件付きルール → Skill（description の書き方が要）
.claude/skills/<name>/SKILL.md を作り、description に いつ呼ばれるべきか を書きます。ここが効くかどうかで、Skill が呼ばれるかが変わります。
悪い例:
---
name: db-migration-check
description: DBマイグレーションのチェックを行うスキル
---
これは「何をするか」しか書いていません。今のタスクがこれに該当するかを判断する材料がないので、必要な場面で選ばれにくくなります。
良い例:
---
name: db-migration-check
description: マイグレーションファイルを追加・編集したとき、または本番デプロイ前に実行する。ロールバック手順の有無・NOT NULL 追加時のデフォルト値・大量データ更新時のロック時間を確認する。schema.rb を直接編集した形跡があるときも起動。
---
改善点は3つです。
- 起動条件を書いている（「〜したとき」「〜の前に」）
-
チェック対象を具体語で書いている（
schema.rb、NOT NULLなどが照合の手がかりになる） - 手順や前提は description に書かない（それは本文の仕事）
「短く」と書きましたが、文字数そのものより 起動条件と照合できる具体語が入っているか が要点です。目安は1〜3文で、上の良い例くらいの分量なら問題ありません。
手順の本体は SKILL.md の本文に書きます。本文はタスクが合致したときだけ読まれるので、常時ロードほどシビアではありません。ただし呼ばれた瞬間は全文が載るので、長くなってきたら references/ に切り出して本文からリンクします。
.claude/skills/post-x-thread-draft/
├── SKILL.md ← 手順の本体（合致時に読まれる）
└── references/
├── templates.md ← さらに必要になったときだけ
└── checks.md
常時ロード → 合致時 → さらに必要なとき、と段階を作っておくと、1回のセッションで読まれる量が抑えられます。
逃がし先3: 特定フォルダの作法 → サブディレクトリの CLAUDE.md
「この資材を触るときだけ守ってほしい」種類のルールは、そのフォルダに CLAUDE.md を置きます。配下を触ったときだけ読まれるので、常時ロードには乗りません。
02_メンティー管理/
├── CLAUDE.md ← このフォルダを触ったときだけ読まれる
├── 田中さん/
└── 佐藤さん/
「命名規則」「このフォルダのファイル構成」のような、対象が明確に限定されるルールはここが一番収まりがいいです。ルートの CLAUDE.md からは、存在と役割を1行だけ書いておきます。
Before / After
Before: 常時ロード 約325行（6月時点・規約・手順・カタログ・トラブル事例が全部同居）
After:
.claude/
├── CLAUDE.md 65行 ← 常時ルールのみ
├── rules/
│ ├── workflow.md 27行 ← @import（常時）
│ ├── conventions.md 25行 ← @import（常時）
│ ├── pair-review.md 39行 ← @import（常時）
│ ├── plans.md 50行 ← パス言及のみ（毎回ロードしない）
│ └── x-bot.md 14行 ← パス言及のみ（Bot作業時だけ）
└── skills/ 19個 ← description は毎回／本文は合致時のみ
常時ロードは 65 + 27 + 25 + 39 = 156行（＋ skills 19個分の description）。仕分け直後は約150行で、その後の追記でいまは156行です。残りは必要なときだけ読まれます。総量はほとんど減っていません。置き場所を変えただけです。
体感として変わったのは、CLAUDE.md を開いたときに「今これ関係あるか？」と読み飛ばす行がなくなったことでした。人が読んで判断しやすい状態になっていれば、指示としても素直になっているはずだ、という考え方でやっています。
AI に仕分けを手伝わせるときの頼み方
この仕分け自体を Claude Code にやらせられますが、頼み方でかなり変わります。
悪い例:
CLAUDE.md が長いので短くして
これは文章の圧縮にいきます。ルールの条件や例外が削られて、残った行の意味が変わることがあります。短くはなりますが、情報は消えています。
良い例:
.claude/CLAUDE.md の各行を次の3分類に仕分けて、表で出して。まだファイルは編集しないで。
1. 常時ルール（どの作業の日でも効いてほしい）
2. 条件付きルール（特定作業のときだけ要る → 移動先の skill 名も案を出す）
3. 参照データ（ルールではない情報 → 切り出すファイル名の案も出す）
分類の根拠を1行ずつ添えて。判断に迷った行は「迷い」として別枠にして。
違いは3点です。
- 分類の枠を先に与えている（「短くして」は目的だけで、判断基準を渡していない）
- まず表で出させて、編集させていない（提案を見てから実行できる）
- 迷った行を別枠にさせている（勝手に決められると、後で気づけない）
3つ目が地味に効きます。迷いを潰させると、AI はどちらかに倒して答えを出します。倒した理由は表に出てこないので、あとで「なぜこの行が消えたのか」を追えなくなります。「迷い」枠を作らせておけば、その数行だけ自分で決めれば済みます。
まとめ
- 短縮ではなく 移動。消していいルールは思っているより少ない
- 分類は「毎回要るか」の一問。特に 参照データ（表・カタログ） が一番かさばる
- ただし 踏むと取り消せない行は、条件付きでも常時ルールに残す
- Skill に逃がしても description は毎回読まれる。手順の本体は本文、description は起動条件
- フォルダ限定のルールはサブディレクトリの CLAUDE.md が収まりがいい
- AI に仕分けさせるときは 分類枠を渡す・表で出させる・迷いを別枠にさせる
今 CLAUDE.md が200行を超えているなら、上の分類プロンプトを一度投げてみると、自分でも忘れていた条件付きルールがそこそこ見つかると思います。
未経験者向けの講座を運営しています
未経験から Next.js + Supabase + Claude Code で Webアプリを公開するまで を、全20セッションで体系化した教材です。Claude Code を学習パートナーにする CLAUDE.md / Skills 設計までセットで含みます。
- 無料体験版（git clone してすぐ動く・最初の数セッション分・⭐ Star もよろしくお願いします）→ https://github.com/ayies128/next-ai-camp-trial
- 教材完全版＋月5,500円のメンタリング（全20セッション＋チャット質問し放題）→ https://menta.work/plan/20251?ref=qiita
- YouTube『AIエンジニア情報局』（AI×開発ニュースを1本5分でキャッチアップできる別運営チャンネル・無料）→ https://www.youtube.com/channel/UC1rXVD9WYsQPQEWZyd-A1KA/?ref=qiita
※ この教材は Qiita 読者の方には易しすぎる内容なので、初心者の知り合いへの紹介や社内研修の参考としてどうぞ。