同じ指摘をまた書いている、という疲労感
マルチエージェントで記事を量産し始めて最初にぶつかった壁が、「また同じことを指摘している」という疲労感でした。Writerエージェントは前回のレビューを覚えていません。Auditorが「段落冒頭を太字インラインヘッダーにしない」と指摘しても、次の記事でまた同じ書き方が出てくる。人間のチームなら「先週言いましたよね」で済む話が、ステートレスなエージェントには通用しない。
この問題を解決するために blog-agents に設けたのが knowledge/ ディレクトリです。CLAUDE.md（62行）を意図的に薄く保ちながら、エージェント別の学習ログをここに蓄積する二層構造にしています。現時点で10ファイル、合計2800行以上まで育っています。
CLAUDE.md と knowledge/ の役割分担
なぜ CLAUDE.md に全部書かないのか、という疑問から話を始めます。
CLAUDE.md は全エージェントが毎セッション読むファイルです。Anthropic 公式ドキュメントでも 200 行以下が推奨されているとおり、太らせるとそれだけコンテキストウィンドウを消費します。blog-agents の CLAUDE.md は 62 行に抑えており、役割はポインタに徹しています。
- プロジェクト全体の構造図とエージェント一覧
- WordPress 認証情報の在処（実値はなく参照先だけ）
- 品質基準のサマリ（文字数・見出し数・具体例の必要性）
一方、knowledge/ に入るのはもっと動的な情報です。「先月のレビューで発見したAI臭のパターン」「feedback-log から抽象化されたルール30個」といった、使い続けるほど増えていくデータが主役です。
各エージェントは作業開始時に自分に対応するサブディレクトリだけを読みます。Writer は writer-lessons/ を読み、Tone-checker は tone-checker-lessons/ を読む。Auditor が seo-lessons/ を読む必要はありません。この仕組みにより、knowledge/ がどれだけ膨らんでも全体のコンテキストには影響しない。
knowledge/ の構造を解体する
現在の blog-agents の knowledge/ はこうなっています。
knowledge/
├── blog-style.md # 28行 - 全エージェント共通スタイルガイド
├── topics-queue.md # テーマキュー
├── writer-lessons/
│ ├── general.md # 35行 - 抽象化されたルール30個
│ ├── avoid-patterns.md # 15行 - AI臭の禁止パターン
│ └── feedback-log.md # 2402行 - 生のレビュー記録
├── tone-checker-lessons/
│ └── patterns.md # 338行 - AI臭パターン31個以上
├── plagiarism-lessons/
│ └── patterns.md
├── auditor-lessons/
│ └── patterns.md
├── researcher-lessons/
│ └── patterns.md
└── seo-lessons/
└── patterns.mdエージェントごとに lessons/ サブディレクトリを切り、役割を分離しています。blog-style.md だけは全エージェント共通で、文体・読者像・禁止表現などをまとめたものです。
writer-lessons の3層設計
writer-lessons だけが3ファイル構成になっています。「生ログ → 抽象ルール → 禁止リスト」という順で情報が整理されており、意図的にこの構造にしました。
feedback-log.md（2402行以上）
Auditor がレビューした際のコメントをそのまま記録します。記事タイトル・日付・「良かった点」「改善余地」のセクションが時系列で積み上がっています。
## 2026-05-13 | Claude Code Opus 4.7 1M Context記事
**レビュー結果: OK（差し戻しなし）**
**良かった点:**
- 導入の「このファイルから先は読ませられないな」というセリフが
読者の日常体験を的確に掴んでいる
- 数字が豊富：10万行以上・MRCRスコア93%→76%・SWE-bench 80.8%→87.6%
- AI臭チェック項目（三点列挙・太字インラインヘッダー・定型まとめ）すべて問題なしこの生ログには抽象化の前のノイズも含まれますが、「どの記事でどんな問題が起きたか」を後から追跡できる価値があります。
general.md（35行）
feedback-log の傾向を Auditor が分析して抽象化したルール集です。現在 30 個以上の指針が入っています。
例として数行を抜き出すと、「導入部で読者の『あるある』な悩みを具体的に言語化する」「コードブロックを複数含む技術記事は 3,800 字を執筆目安にする」「まとめの三点列挙＋時間タグパターンを複数記事に連続して使わない」といった内容が並んでいます。どれも具体的なレビュー体験から生まれた指針です。
avoid-patterns.md（15行）
「やってはいけないこと」だけを短く集めたリストです。「『〜について説明します』で段落を始めない」「箇条書きを3回以上連続で使わない」「著者名・年付きの学術引用はAIによる架空引用の可能性が高いため一般表現に置換する」といった禁止事項が並びます。
3層に分けることで、Writerは「general.md と avoid-patterns.md を読めば今日の執筆に必要な情報がわかる」状態になっています。2400行の生ログを毎回全部読む必要はありません。
tone-checker-lessons が語る蓄積の速度
tone-checker-lessons/patterns.md は現在 338 行、AI臭パターンが 34 個以上入っています。5月だけで追加されたもので、記事1本のレビューごとに 2〜3 個のペースで増えました。
実際に登録されているパターンの一部を挙げます。
| # | パターン名 | 内容 |
|---|---|---|
| 1 | まとめの三点列挙 | 「〜（X分）。〜（X分）。〜（X分）。この3つから〜」という定型まとめ |
| 2 | 視点宣言フレーズ | 「〇〇の立場から〜」という書き出し |
| 3 | 数の先行宣言 | 「〇つある」「〇点に整理できる」という冒頭宣言 |
| 4 | 三段階構造 | 「まず〜。次に〜。最後に〜。」の定型展開 |
| 5 | 太字インラインヘッダー | 段落冒頭で「〇〇は〜だ」と太字をヘッダー代わりに使う |
| 6 | 接続詞の連続 | 「さらに」「加えて」「また」が段落をまたいで連続する |
| 7 | 定型ブリッジ文 | 「以下で整理する」「次のセクションで詳しく見る」 |
| 8 | em-dash の多用 | 1記事に em-dash（—）が5回以上出現する |
Tone-checker は次の記事のレビュー前にこのファイルを読みます。パターンが増えるほど検出精度が上がる構造です（現在34番まで登録済み）。
育てるサイクルと Auto Memory との違い
ナレッジが育つサイクルは単純です。記事が公開されたら Auditor が feedback-log に記録する。記録が一定量溜まったら general.md を更新する。次の記事の執筆前に Writer が general.md を読む。この繰り返しで、エージェントは徐々に精度を上げていきます。
Claude Code の公式機能に Auto Memory というものがあります。~/.claude/projects/ に Claude 自身が「覚えておくべきこと」を自動で書き込む仕組みです。
blog-agents の knowledge/ はこれとは少し違います。Auto Memory は Claude が自己判断で書き込みますが、knowledge/ は Auditor（人間の指示で動くエージェント）がレビュー結果を元に書き込みます。「誰が何を書いたか」が追跡可能で、抽象化フェーズで意図的な判断が入る点が組織運用向きだと感じています。
自分のプロジェクトで Auto Memory を活用しているケースは、以前の記事でも触れているので、組み合わせて読んでみてください。
knowledge/ 設計を他プロジェクトで使うには
blog-agents 固有の話として読んできましたが、設計の考え方は汎用的です。
私が意識したのは次のことです。エージェント別にディレクトリを切る、生ログと抽象ルールは別ファイルにする、「このファイルは誰が読む」を決める、書き込み役を持つエージェント（またはワークフロー）を用意する。この判断さえ先に固めておけば、どんなマルチエージェント構成でも同じ考え方が使えます。
CLAUDE.md の設計については先日の記事で詳しく書いています。knowledge/ との関係を理解した上で合わせて読むと、全体の設計意図がつながります。また blog-agents の全体像についてはこちらの記事も参照してください。
マルチエージェントは「立ち上げた直後がもっとも賢い」という逆説があります。設定ファイルや指示は完璧でも、実際に動かすと想定外の癖が出てくる。その癖を knowledge/ に書き留め、抽象化して次回に渡す。そのサイクルを地道に回すことで、エージェントは使い続けるほど精度が上がっていきます。
自分のプロジェクトの CLAUDE.md に knowledge/ へのポインタを1行追加して、エージェントのレビュー結果を記録するファイルを1つ作ってみてください。それだけで始まります。
コメント