LLMベースのコーディングエージェント（Claude Code、Cursor など）は、セッションが変わるたびにプロジェクトの規約や過去のミスを忘れてしまう。小さなプロトタイプなら問題にならないが、10万行を超える大規模コードベースでは「毎回同じ説明をする」「直したはずのバグパターンが再発する」といったコストが無視できなくなる。

2026年2月に公開された論文 Codified Context: Infrastructure for AI Agents in a Complex Codebase（Aristidis Vasilopoulos）は、この問題に対して 3層のメモリインフラストラクチャ を提案し、108,000行のC#分散システムを283セッションかけて構築した実践データとともに検証している。

問題：セッション間で失われる記憶

LLMエージェントは各セッションの開始時にコンテキストがリセットされる。.cursorrules や CLAUDE.md のような単一ファイルでプロジェクト規約を伝える方法は小規模なら有効だが、10万行規模のシステムでは単一プロンプトに収まりきらない。

結果として起きる典型的な問題:

  • 命名規則やアーキテクチャパターンの逸脱
  • 過去に修正した失敗パターンの再発
  • サブシステム間の整合性の欠如

提案手法：3層の Codified Context

論文では、プロジェクト知識を 負荷分散インフラストラクチャ として扱う3層アーキテクチャを提案している。

Tier 1: Hot-Memory Constitution（約660行）

常にセッションにロードされるMarkdownファイル。以下を含む:

  • コード品質基準・命名規則
  • ビルドコマンド
  • アーキテクチャパターンの要約
  • よくある操作のチェックリスト
  • 既知の失敗モード（過去のバグパターン）
  • オーケストレーション用トリガーテーブル

トリガーテーブルは「どのファイルを変更したら、どの専門エージェントを呼ぶか」を定義する:

ファイル変更割り当てエージェント
Network, syncnetwork-protocol-designer
Coordinates, cameracoordinate-wizard
UI配信ui-sync-specialist

Tier 2: Specialized Agents（19エージェント、約9,300行）

タスクに応じて呼び出される専門エージェント群。2つのクラスに分かれる:

  • 高能力エージェント（8個、平均711行）: ネットワークプロトコル設計、アーキテクチャ検証、デバッグなど
  • 標準能力エージェント（11個、平均327行）: 特定タスクにフォーカス

各エージェント仕様の 50%以上がプロジェクト固有のドメイン知識 で構成されている。コード例、数式、失敗モードなど、そのプロジェクトでしか使えない具体的な情報が埋め込まれている点が特徴。

Tier 3: Cold-Memory Knowledge Base（34文書、約16,250行）

サブシステムごとの詳細仕様をMarkdownで記述し、MCP（Model Context Protocol）検索サーバー経由でオンデマンド参照する:

list_subsystems()          # サブシステム一覧
find_relevant_context(task) # タスクに関連する文書を検索
suggest_agent(task)         # 適切なエージェントを提案
search_context_documents(query) # 横断検索

定量的な結果

70日間（兼業）の開発で得られた実績データ:

メトリクス値
C#コード行数108,256行
開発セッション283回
人間プロンプト2,801個
エージェント呼び出し1,197回
エージェント自律ターン16,522回
MCP検索呼び出し1,478回

知識インフラストラクチャの規模は全コードの 24.2% に達する:

  • Tier 1: 660行（0.6%）
  • Tier 2: 9,300行（8.6%）
  • Tier 3: 16,250行（15.0%）

セッションの87%はアドホック（直接実装やデバッグ）、13%が計画→実行→レビューの構造化セッション。

ケーススタディ: 失敗の伝播を防ぐ

セーブシステム（調整文書として機能）

2層セーブシステム（ディスク/メモリ）の仕様を文書化し、74セッション・12エージェント会話で参照された。結果、継続的なバグはゼロ。後続の5機能すべてが一貫して正しく実装された。

UI同期パターン（経験のキャプチャ）

ショップUIの同期でパケット喪失時の問題が発生。ui-sync-patterns.md（126行）を作成した結果、次のUI機能（ラジアルダイヤル）は 初回の試行で正しく実装 された。

決定論的RNG（協調デバッグ）

最も複雑なケース。デバッグが5セッション・84コード編集に及んだが、network-protocol-designerエージェント（915行）の埋め込み知識により、以下の根本原因を特定:

  • ガード句がサイレント失敗していた
  • 2つの内部時計が異なるレートで更新されていた
  • 時計補正式に符号エラーがあった

実践ガイドライン

論文が提示する6つのガイドライン:

  1. 基本的な Constitution だけでも大きな効果: プロジェクト目標・スタック・核心規約だけで初期段階から劇的に改善する
  2. 実装前に計画エージェントを実行: 必要な仕様とスペシャリストが自動サーフェスされる
  3. 自動ルーティングを設定する: トリガーテーブルがなければ、適切なエージェントは呼ばれない
  4. 2回説明したら文書化: 繰り返しの説明は仕様化すべきシグナル
  5. 迷ったらエージェントを作る: ドメイン知識を埋め込むことで膠着セッションを解消
  6. 古い仕様は誤導する: エージェントは文書を絶対信頼するため、陳腐化した仕様は失敗の原因になる

メンテナンスコストは、セッションごとに約5分の仕様更新と隔週30〜45分のレビュー。週1〜2時間のオーバーヘッドで、セッション間の一貫性が確保できるとしている。

まとめ

この論文の核心は、プロジェクト知識をコードと同様にバージョン管理されるインフラとして扱うという発想の転換にある。CLAUDE.md や .cursorrules の延長線上にあるが、Hot/Cold の階層分離と専門エージェントの組み合わせにより、10万行規模でもスケールする仕組みを実証した点が新しい。

AIコーディングエージェントを本格的に活用するなら、「どのモデルを使うか」だけでなく「どうやってプロジェクト知識を構造化してエージェントに渡すか」が勝負の分かれ目になりそうだ。

参考