【設計】CLAUDE.mdを肥大化させない3層構造|context/とmemory

AI活用
この記事は約7分で読めます。

このブログは Claude Code に文体チェックや画像生成を任せながら運用しています。プロジェクトのお作法を伝えるために CLAUDE.md(プロジェクト直下の常設指示書)を使うのですが、油断するとすぐ1,000行を超えて肥大化します。肥大化した CLAUDE.md は、Claudeの毎リクエストに丸ごと積まれるためトークンが嵩み、しかも当のClaude自身が長すぎて細部を取りこぼします。

この記事では、私の環境で運用している CLAUDE.mdcontext/ 配下のサブドキュメント/自動メモリ(memory)の3層構造をまとめます。目的はチェック機能の向上とトークン節約の両立で、そのためにスリム化・役割分担・運用ルールの3つを組み合わせています。同じく Claude Code でリポジトリを育てている方の参考になればうれしいです。

この記事でわかること

  • CLAUDE.md をスリムに保つための、3層に分けた情報の置き場所
  • それぞれに「何を書くか/何を書かないか」の判断基準
  • 肥大化に気づいて分割するときの、具体的な切り出し手順

背景:放置するとCLAUDE.mdは平気で1,000行を超える

私のリポジトリでは当初、Claudeに守らせたいルールをすべて CLAUDE.md に直接書いていました。文体ルール、画像のお作法、プライバシー配慮、WordPress投稿APIの注意点、デザインCSS……。とにかく1ファイルに集約していました。

ところが半年ほど書き足し続けたところで、CLAUDE.md がじわじわ重くなってきました。具体的には次のような症状です。

  • 毎回のセッションで「結論→理由→手順」の指示が読まれる前に、長大な文体ルールでコンテキストが埋まる
  • ルールを追加しても、Claudeが古い箇所を優先してしまい新ルールが効かないことがある
  • 自分でも全体像を把握できなくなり、同じ趣旨のルールを2か所に書いてしまう

肥大化の本質は「常に読まれるもの」と「必要なときだけ読めばよいもの」が混ざっていることです。これを分けるところから始めました。

解決の方針:3層に分けて、CLAUDE.mdは「目次と判断基準」だけにする

最終的に落ち着いた構成はこうなりました。

レイヤ 場所 役割 読まれるタイミング
常設指示 CLAUDE.md プロジェクトの判断基準・カテゴリ・参照先の目次 毎セッション必ず
サブドキュメント context/*.md 文体・画像・WP環境などの詳細ルール Claudeが必要と判断したとき
自動メモリ ~/.claude/.../memory/ ユーザー固有の好み・過去の指摘 Claudeが該当タスクで参照

ポイントは、CLAUDE.md に詳細を書かず「どこに何があるか」と「迷ったときの判断基準」だけに絞ることです。詳細は context/ 配下の専用ファイルへ寄せます。常設は薄く、必要なときに必要なものを開く、という方針です。

手順1:CLAUDE.md には「目次」と「判断基準」だけを置く

CLAUDE.md のトップには、サブドキュメントへのリンクを並べる節を作ります。私のリポジトリでは次のようにしています。

## 詳細は外部ファイルを参照(必要時のみ読む)

- **文体・語り口**: `context/style-guide.md` ← 執筆前に必ず読む
- **記事公開フロー**: `context/workflow-publish.md`
- **画像管理・アイキャッチ**: `context/workflow-images.md`
- **WP環境**: `context/wp-environment.md` ← SEO設定やキャッシュで問題が出たら見る
- **デザイン・記法ルール**: `context/design-rules.md` ← カラーパレット・追加CSS・吹き出し記法

各行のおしりに「いつ読むか」を書いておくのがコツです。Claudeは CLAUDE.md を毎回読むので、ここの一行で「今このタスクに style-guide.md が必要か」を判断してくれます。逆にこの一行がないと、毎回すべてのファイルを読みに行ってしまい、トークンの節約になりません。

CLAUDE.md に残してよいのは、次のような「判断基準そのもの」です。

  • カテゴリ・タグの設計思想(どこに分類するかの境界)
  • プライバシー配慮で公開してよい情報のライン
  • ターゲット読者の像
  • 死守ルール(体言止め禁止、誇張表現禁止など短い原則)

詳細な語彙リストや事例はサブドキュメント側に追い出します。

手順2:context/ に役割ごとのサブドキュメントを切り出す

肥大化した CLAUDE.md から context/ に切り出すときは、「どのタスクのときに読むか」で1ファイルにまとめるのが目安です。私の構成だと次のようになっています。

ファイル 主な内容
style-guide.md 文末パターン、NG語、独自語彙、書き出しテンプレ
workflow-publish.md wp_post.py の使い方、公開後の自動処理
workflow-images.md アイキャッチ生成・命名規則・縦長画像のCSSクラス
design-rules.md カラーパレット・追加CSS全文・吹き出し記法
wp-environment.md プラグイン構成・SEO設定・キャッシュの落とし穴

ファイル分割の判断基準はシンプルで、「1つのタスクをやり切るのに必要な情報がそのファイル1つで揃うか」です。たとえば画像周りの作業をしているときに workflow-images.md だけ開けば完結するように、命名規則もCSSクラスも生成プロンプトもこのファイルにまとめます。タスクの粒度で切ると、Claudeが取り回しやすい単位になります。

逆にやってしまいがちな失敗が、種類別(NG語集/OK語集/トーン集……)に分けてしまうことです。タスク粒度ではなく分類粒度で切ると、1つのタスクでファイルを何個もまたいで読むことになり、トークン的にも認知的にも不利です。私も最初は分類で切っていて、後から統合しました。

手順3:ユーザー固有の好みは「自動メモリ」に逃がす

Claude Code の memory/ ディレクトリは、ユーザー固有の指摘や好みを蓄積する仕組みです。~/.claude/projects/<プロジェクトハッシュ>/memory/ に置かれ、MEMORY.md がインデックスとして毎セッション読み込まれます。

私はここを「繰り返し同じ指摘をしないための備忘録」として使っています。たとえば次のような項目です。

  • 「想定以上に〜」のような誇張表現を指摘されたら、その旨を feedback_writing_tone.md に追記
  • WordPress投稿APIで status 省略の事故が起きたら、再発防止のメモを feedback_wp_posting.md に追記
  • スクショの保存場所のような環境固有の情報は reference_screenshot_folder.md に置く

CLAUDE.md との違いは、「プロジェクトとして守るべきルール」か、「私個人がよく言うこと・好み」かです。前者は CLAUDE.md または context/、後者は memory/ に置く、と決めると迷いません。memory/ に書いたものはClaude側が能動的に管理してくれるので、こちらで構造を作り込みすぎないのもポイントです。

詰まったこと・気づいたこと

詰まり1:分割しすぎても今度は迷子になる

最初に細かく分けすぎたとき、context/ 配下が10ファイルを超えてきて、Claudeも私もどこに何が書いてあるか追えなくなりました。結局、1ファイル200〜600行くらいを上限の目安にして、それ以下のファイルは隣接するファイルに統合する方針にしました。分割の粒度は「タスク1つ=ファイル1つ」が、迷子にならないちょうどよいラインだと思います

詰まり2:context/ に書いただけでは実装に効かない

これは別記事に切り出して書いたのですが、context/ にルールを書いても、画像生成や文体チェックの実装スクリプトに反映されていないと意味がありません。書いただけで満足してしまう状況が起きうるのは問題です。詳しくは CLAUDE.mdのルールが実装で守られない問題を自動検知する に書きました。CLAUDE.md の薄型化と合わせて、整合性チェックを月次で回す運用に落としています。

詰まり3:肥大化は「行数」より「重複」で気づくほうが早い

分割を考えたタイミングは、同じ趣旨のルールを2か所に書いていると気づいた時です。重複は次の3パターンで発生しやすいようです。

  • 文体ルールを CLAUDE.mdstyle-guide.md の両方に書いている
  • カラーパレットを CLAUDE.md 本文と design-rules.md の両方に書いている
  • プライバシー配慮を CLAUDE.mdfeedback_privacy.md(memory)の両方に書いている

重複を見つけたら、詳細は context/memory/ 側に寄せて、CLAUDE.md には1行リンクだけ残すを原則にしています。

まとめ

  • CLAUDE.md は「目次と判断基準」だけに絞り、詳細は context/ 配下のタスク別ファイルに寄せる
  • context/ のファイル分割は「1タスクで読み切れる単位」が目安。種類別ではなく作業別に切る
  • ユーザー固有の好みや過去の指摘は memory/ に逃がす(プロジェクトのルールではなく個人の癖だから)
  • 肥大化のサインは行数より重複。同じ趣旨を2か所に書いていたら分割を考える

Claude Code でブログ運用していると、ルールが増えるのは健全な成長の証でもあります。ただし全部を CLAUDE.md に積むのはトークン的にもメンテナンス的にも持続しないので、3層で役割を分けておくと長く使い続けやすくなります。同じようにリポジトリを育てている方は試してみてください。

コメント

タイトルとURLをコピーしました