3ヶ月で「壊れた」話

Claude Projectは便利です。

でも、情報を増やし続けるほど、回答の品質が落ちることがあります。

私もProject InstructionsとKnowledgeを3ヶ月間増やし続けた結果、Instructionsが約400行まで膨らみ、回答が冗長化する状態になりました。

このブログ自体、Claude Codeだけで作って運営しています（その全記録はClaude Codeだけでブログを作った話にまとめました）。

その運営ノウハウを全部Claude Projectに集約していったら、最終的にInstructionsを80行まで圧縮し、Knowledgeを7ファイルに分割することになりました。

その過程で起きたことを、失敗込みで書きます。

症状はこんな感じでした。

  • 毎チャットの読み込みが体感で重くなった
  • 同じルールがInstructionsとKnowledgeの両方に書いてある
  • どっちが正しいルールなのか、自分でもわからなくなる
  • コード寄りの技術情報が、記事執筆用のナレッジに埋もれている
  • 回答が長くなる。前置きが増える。ブレる

情報が増えるほど便利になる。

そう思っていたのに、実際は逆でした。

なぜ全部突っ込むと壊れるのか

原因を整理すると、要は「責務が分離されていない」ことに尽きます。

Claude Project Instructionsに書くべき情報と、Claude Project Knowledgeに書くべき情報。

性質がまったく違うものを、1つの箱に全部入れていたわけです。

結果として起きること：

  1. 指示競合　同じルールが2箇所に書いてあると、どちらを優先すべきかAI側も判断に迷う
  2. コンテキスト消費の増加　毎回全部読み込むので、必要な情報以上にコンテキストを消費している感覚があった
  3. メンテ不能化　ルールが古くなっても、どこに書いてあったか探すだけで一苦労
  4. 品質のブレ　情報過多で焦点がぼやけ、記事のクオリティが安定しない

「念のため関連しそうな情報を全部入れておく」という判断が、一番の落とし穴でした。

4層モデル

たどり着いた答えはシンプルです。

情報の性質ごとに、置き場所を分ける。

層役割配置更新頻度
A. ふるまいClaudeの動き方そのものProject Instructions低
B. 事実・ガイド記事執筆に必要な情報Project Knowledge（7分割）中
C. コード・技術技術詳細・テンプレGitHubリポジトリ中
D. 過去ログアーカイブ別ファイル（Knowledge対象外）低

どこに書くか迷ったら

判断に迷ったときは、この基準を使っています。

書く内容置き場所
話し方・回答の癖・常時守らせたいルールInstructions
記事執筆に使う事実・カテゴリ・アフィリ情報Knowledge
Frontmatter仕様・Vite設定・投稿スクリプトGitHub（リポジトリ）
過去の作業ログ・進捗メモArchive

迷ったら「毎チャット読む必要があるか？」で判断すると、だいたい決まります。

毎回読ませたいものだけがInstructions。

それ以外はKnowledgeか、リポジトリか、アーカイブに逃がす。

これだけで、判断のブレがなくなりました。

7ファイル構成

一番効果が大きかったのは、Project Knowledgeの分割です。

もともと1本の巨大ドキュメントに、ブログの基本情報も、執筆ルールも、事実関係も、タグ一覧も、記事一覧も、全部同居していました。

これを、役割ごとに7ファイルへ分けました。実際の構成（汎用化した名称）はこうです。

Knowledge/
├── 01-basic-info.md        ← ブログ基本情報・主要ID
├── 02-writing-rules.md     ← 執筆ルール・必須出力
├── 03-facts.md             ← 整合性維持用ファクト
├── 04-taxonomy.md          ← カテゴリ・タグ・色管理
├── 05-articles-index.md    ← 公開済み記事インデックス
├── 06-roadmap.md           ← コンテンツ戦略・ロードマップ
└── 07-affiliates.md        ← アフィリエイト戦略

各ファイルは100〜300行程度に収めています。

なぜ6でも10でもなく7なのか。

理由は単純で、「毎回参照する情報」「記事公開ごとに触る情報」「月次で見る情報」「ほぼ見ない情報」で自然に分けていったら、結果として7つになっただけです。

数を先に決めたわけではありません。

#ファイル毎回参照更新頻度
01basic-info◯年1回
02writing-rules◯ルール変更時
03facts◯事実変更時
04taxonomy◯記事公開ごと
05articles-index△記事公開ごと
06roadmap△月次
07affiliates×承認・変更時

設計で意識したのは、この5つ。

  • 1ファイル100〜300行に収める
  • 1ファイル1責務（編集時に他のルールと競合しない）
  • 表形式を優先する
  • 更新頻度でファイルを分ける
  • ファイル冒頭に「目的・更新タイミング」を明記する

タグを1つ追加するだけなのに、記事一覧やアフィリ戦略まで一緒に開いて確認する。

そんな無駄が、なくなったんです。

Before/After

数字で見ると、変化がわかりやすいと思います。

項目整理前整理後
ナレッジ構造1本集中・全部入り7ファイル分割
Project Instructions約400行約80行（80%削減）
過去の作業ログKnowledge内に同居別ファイルへ分離
コード側の禁止事項Knowledge内に混在リポジトリ側へ集約
アフィリURL管理スプシ＋Markdown二重スプシに一元化
投稿手順の記載Knowledge＋README二重README一元化
重複していたルール3箇所に散在1箇所に統一

Instructionsが400行から80行になったのが、体感としては一番大きな変化でした。

同じ質問をしても、前置きが短くなる。

結論から先に来る。

余計な確認が減る。

「情報を減らしたら精度が落ちるのでは」と最初は心配していましたが、実際は逆でした。

失敗パターン集

自分がやってしまった失敗を、正直に並べておきます。

  • Instructionsに、SEOルール・投稿フロー・frontmatter仕様・サムネ規定・技術ルールを全部書いた
  • ナレッジDoc1本に、事実も進捗も戦略も記事一覧も全部詰め込んだ
  • 過去の進捗ログをKnowledge内に累積させ続けた
  • アフィリエイトURLを、スプレッドシートとMarkdownの両方で管理していた
  • 投稿手順を、リポジトリのREADMEとKnowledgeの両方に書いていた
  • 「念のため」で、関係あるかもしれないファイルを全部アタッチしていた

どれも、悪意はないんです。

「念のため」の積み重ねが、結果として破綻を招きました。

起きた症状はどれも共通していて、回答の冗長化、指示競合、メンテ不能化、コンテキスト消費の増加。

情報を足すことは簡単。

引くことのほうが、圧倒的に難しい作業でした。

効果検証

新構成に移して1ヶ月ほど運用した体感では、前置きが短くなり、回答も体感で速くなりました（コンテキスト読み込みが軽い印象）。

Knowledge更新も、どのファイルを開けばいいか即座にわかるので、作業時間が短くなっています。

正確な数値計測はしていませんが、余計な前置きがなく、聞いたことにだけ答えてくれる状態に、ようやくたどり着きました。

このあたりの試行錯誤は、バイブコーディングでブログを作った体験記の延長線上にあります。

まとめ

もし今、

  • Instructionsが長い
  • Knowledgeが1ファイルにまとまっている
  • 同じ内容を何度も書いている

このどれかに当てはまるなら、一度責務ごとに分離してみてください。

情報は増やすより、整理したほうがAIは賢く使えます。

Claude Project Instructionsには、Claudeに毎回守らせたいルールだけを残す。

Claude Project Knowledgeには、記事執筆や作業に使う事実だけを置く。

それ以外は、リポジトリかアーカイブに逃がす。

この「責務で分ける」という考え方自体は、CursorでもGeminiでもChatGPTのプロジェクト機能でも、原則は同じだと思います。ツールが変わっても、情報を1箱に詰め込むと壊れるのは変わりません。

このブログがどんな人間に運営されているのかは、お小遣い月3万円パパの自己紹介に書いています。

記事数が増えるたびに、この構成もまだ微調整を続けています。