AI エージェントにプロジェクト記憶やナレッジ層（設計判断・手順などの蓄積ドキュメント）を読ませる機能の設計。蓄積データをセッション開始時に全文注入するとトークンコストが蓄積量に比例して増え、既存の常時読み込みファイル（CLAUDE.md / AGENTS.md / システムプロンプト等）との二重管理問題も生む。その改善として「開始時にタイトル+要約のインデックスを全件注入し、本文はオンデマンド取得」という階層化を採っても、蓄積が増えると同じ形で破綻する。数十件規模の実運用で、インデックスだけが毎セッション数千トークンを占め、しかも活用されないことを確認した。

インデックス注入の破綻の症状

• インデックスは件数に比例して単調増加し、常時注入コストが頭打ちにならない。
• 蓄積の大半は決着済み・再発しない案件になり、将来セッションの文脈価値がない項目が active な項目と同列に並ぶ。
• 「常時適用の少量指示」用の器が空のまま、目次のはずのインデックスが事実上の常時注入コンテンツになる逆転が起きる。
• 開始時に一覧を見せても、数週間後の関連する判断の瞬間にエージェントがそれを想起する保証がない。読ませているのに使われない。

階層化の設計（改訂版）

• 常時読み込み層: 毎セッション必ず適用すべき少量の恒常指示と蓄積の件数程度のみ。上書き更新型の単一ドキュメントにし、意図的に小さく保つ（サイズ目安の警告を UI に置くとよい）。応答トークン量を蓄積件数に非依存にする。
• 取得層: インデックス注入ではなくセマンティック検索ツールを提供する。知識が効くのはセッション開始時ではなく類似の判断をする瞬間。設計記録の実用価値は「却下した代替案を再提案しない・過去の決定と矛盾しない」ことに尽きるため、取得の引き金は計画起草・設計検討のワークフロー側に埋め込む（起草前に検索するステップを計画作成手順自体に追加する）。ルールで「読め」と言うより、発火点が明確な手順に検索を組み込む方が確実に効く。
• 本文層: ID 指定の取得ツールでオンデマンドに読む。
• ライフサイクル: archived 相当の状態を入れ、決着済み・上書き済みの記録をデフォルト検索対象から外す。検索では明示オプトインで引ける形にし、監査証跡としては残す。

却下した代替案

• 縮小 push（直近 N 件だけインデックス注入）: N の恣意性が残り、古いが関連の深い判断に届かず、線形成長の根治にならない。
• 常時層の全廃: 恒常指示や承認待ち提案など「毎セッション配達すべき少量」の経路は維持する。

適用条件（段階の問題）

• 蓄積が少量のうちはインデックス注入の方が単純で良い。初手から検索基盤を作る必要はない。
• 蓄積が数十件を超え、常時注入が数千トークン級になったら検索方式への移行を検討する。
• セマンティック検索の基盤（embedding + ベクトル検索）が重複検出などで既にあるなら、公開配線だけで済むことが多い。

二重管理の回避

既存の常時読み込みファイルとの住み分けルールを先に明文化する。「リポジトリから導出可能・チーム共有可・コミット可な内容は既存ファイル、コミットできない個人文脈・リポジトリ横断の判断・却下案の履歴は新しい層」のように、置き場を内容の性質で機械的に決められる基準にする。

検証

• 蓄積ドキュメントが数十件ある状態でセッションを開始し、初期注入トークン量が蓄積件数に依存しないことを確認する。
• 計画起草ワークフローで検索が実際に発火し、過去の却下案・決定が起草に反映されるかを次の実案件で観測する。参照カウントを取れば「よく引かれる記録（恒常指示へ昇格候補）／引かれない記録（アーカイブ候補）」も数字で見える。