どこに何を書けばいいかわからない
Claude Code を使っていて気づくのは、「Claudeに覚えさせる場所」が思ったより多いことだ。CLAUDE.md だけかと思っていたら、Auto Memory があり、.claude/skills/ があり、自前で作った knowledge/ フォルダもあったりする。
筆者が運用している blog-agents プロジェクトでは、いまセッション開始時に Claude が参照しうる記憶が4層に分かれている。整理するとこうなる。
| 層 | 場所 | 誰が書く | 読込 | blog-agents実数値 |
|---|---|---|---|---|
| Global User CLAUDE.md | ~/.claude/CLAUDE.md | 自分 | 全プロジェクト | 44行 |
| Project CLAUDE.md | ./CLAUDE.md | チーム | そのプロジェクト | 62行 |
| Auto Memory | ~/.claude/projects/<project>/memory/ | Claude自身 | セッション開始時 | 6ファイル |
| knowledge/（独自） | ~/project/blog-agents/knowledge/ | Auditor | 役割別に必要時 | 3,021行 / 10ファイル |
書き手だけ見ても、ユーザー（自分）・Claude自身・別のサブエージェント、と3者ぶら下がる。それぞれの責務を理解しないと、CLAUDE.md が膨れ上がってコンテキストを食いつぶす。
層1: Global User CLAUDE.md（44行）
~/.claude/CLAUDE.md は、すべての Claude Code セッション開始時に読まれる。書き手は自分、対象は「全プロジェクトで効かせたい癖」だ。
筆者の Global CLAUDE.md には、たとえば「常に日本語で会話する」「日付・曜日を出力するときは date -j -f コマンドで確認する」「特定の相談はジャンルを判定して /hiroshi-hayashiyama:magi スキルを起動する」といったルールが入っている。プロジェクトとは無関係に、自分の好みや作業スタイルとして毎回効かせたいもの。
逆に言えば、プロジェクト固有の話は書かない。書くと別のプロジェクトでも読み込まれてコンテキストを汚す。44行で十分まわっている。
層2: Project CLAUDE.md（62行）
./CLAUDE.md または ./.claude/CLAUDE.md は、そのプロジェクト内でセッションを開始したときに読まれる。書き手はチーム（個人運用なら自分）、対象はそのプロジェクトに固有の規約・構造・運用ルール。
blog-agents の Project CLAUDE.md には、ブログ概要・ディレクトリ構造・サブエージェントとスキル一覧・パイプラインフロー・Discord/WordPress連携・品質基準が並ぶ。テーブル形式で密度を上げて、本文よりも参照ポインタに近い構造にしてある。詳細は別ファイル（subagent定義・SKILL.md・knowledge/）に委譲する設計だ。
公式は「200行以下を目指せ」と言う。書きたいことは増え続けるので、定期的に削るか、Skill や knowledge/ に逃がす。詳しくはCLAUDE.md設計記事で62行の中身を解体してある。
層3: Auto Memory（Claudeが自分で書く）
~/.claude/projects/ に置かれる。書き手は Claude 自身だ。ユーザーが「これダメ」と修正すると、Claude が「次回も気をつけよう」と判断して MEMORY.md とサブファイルに保存する。
blog-agents の Auto Memory に何が入っているかを覗くと、5つの feedback ファイルがある。
- まとめセクションの三点列挙＋時間タグを使わない
- 「3つ」固執の三点強制を避ける
- 段落冒頭の太字インラインヘッダーを使わない
- Discord メンション後は必ず改行を入れる
- WordPress テーブルは HTML で書く
特に最後の WordPress テーブルの memo は、Markdown→HTMLへ変換する Python スニペット込みで保存されている。同じ問題が複数記事で起きた後に Claude が自動的に書き残した。以降のセッションでそのまま参照される。
筆者が「これメモして」と頼んだのではなく、Claude が学習した結果として書かれている点が他の3層と違う。
層4: knowledge/（役割別の専門学習層）
ここから先は Claude Code の公式機能ではなく、blog-agents が自前で作った層になる。knowledge/ ディレクトリに、各サブエージェント別の lessons ファイルが置いてある。
合計10ファイル・3,021行。内訳は writer-lessons（feedback-log 2,402行＋general 35行＋avoid-patterns 15行）、tone-checker-lessons/patterns.md（340行・34+パターン）、plagiarism/auditor/researcher/seo の各 patterns.md、共通の blog-style.md と topics-queue.md だ。
書き手は Auditor エージェント。レビューを通じて「writer がやりがちなミス」「tone-checker が検出すべきパターン」を抽出し、対応する lessons ファイルに追記する。読み手は各サブエージェントで、自分の担当ファイルだけを作業前に読む。
CLAUDE.md と Auto Memory の2つでカバーしきれないのは、「役割別に異なる細かい癖」だった。Writer は記事構成のルールを、tone-checker は AI 臭の検出パターンを、それぞれ独立に育てたい。3,021行を CLAUDE.md に詰めるとコンテキストが破綻するが、knowledge/ に役割別に置けば必要なエージェントだけが読む。詳細はknowledge/詳解記事に書いた。
4層間の連携パターン
4つは独立しているように見えて、実際は連動する。
「フィードバック → Auto Memory → 次回適用」の流れが基本だ。ユーザーが修正を入れると、Claude が Auto Memory に書き残し、次のセッションで同じミスを避ける。Claude 単独で完結するので、筆者は何もしなくていい。
Auto Memory に具体例が溜まってくると、Auditor が抽象ルール化して knowledge/general.md に追記する。「タイムタグ3点列挙」「太字インラインヘッダー」は最初 Auto Memory に個別保存され、そのうち tone-checker-lessons/patterns.md に体系化された。具体例が抽象ルールに昇格していくイメージだ。
Project CLAUDE.md 自体は薄く保ち、詳細は Auto Memory・knowledge/・subagent定義へ委譲する。CLAUDE.md は「目次」で、中身は他の3層に書く、という分業がうまく機能している。
「どこに書くか」の判断フロー
書きたいことが出てきたら、まず「全プロジェクトで効かせたいか」を問う。そうなら Global CLAUDE.md に書く。プロジェクト固有の規約や構造なら Project CLAUDE.md で、200行以下を維持する意識で。
ユーザーの修正フィードバックから生まれた内容、つまり Claude が「次回も気をつけよう」と判断するものは、Auto Memory に任せる。自分で書かなくていい。役割別の専門知識、たとえば writer 用の記事構成ルールや tone-checker 用の検出パターンは knowledge/<role>-lessons/ へ。
よくあるミスは、何でも Project CLAUDE.md に書いて200行を超えるパターン。CLAUDE.md は毎セッションで全文ロードされるので、太らせるとコンテキスト圧迫の元になる。「常時読ませる必要があるか？」と問いかけて、そうでなければ他の3層に逃がす。
筆者の blog-agents は CLAUDE.md 62行・knowledge/ 3,021行という非対称な構成になっている。最初は CLAUDE.md にどんどん書いていたが、200行に近づいた段階で「これは tone-checker しか読まなくていい」「これは writer 専用だ」と切り出していった結果がこの構成だ。
CLAUDE.md を太らせそうになったら、一度立ち止まって「どの層の話か」を問い直してみてほしい。
コメント