本論文は、AI コーディングエージェントは幅広いプログラミング知識を持つ一方でプロジェクトの記憶を持たない、という観察から出発する。各セッションは、以前のセッション、確立された慣習、過去の失敗を知らないまま始まる。AGENTS.md、CLAUDE.md、.cursorrules のような単一ファイルのマニフェストは小規模なプロジェクトではこの問題に対処できるが、著者はそれらがスケールしないと論じる。1,000 行のプロトタイプは 1 つのプロンプトで説明できても、100,000 行のシステムはそうはいかない。先行する実証研究がそうしたファイルに開発者が何を書いているかを特徴づけてきたのに対し、本論文はプロジェクトの知識が単一ファイルに収まらなくなったときに何が起きるかを問う。
その答えがコード化されたコンテキストインフラストラクチャ（codified context infrastructure）であり、機械による消費を明示的な目的として書かれた構造化された成果物、すなわち主な読み手が開発者ではなく AI エージェントである文書として定義される。これは、Claude Code を唯一のコード生成ツールとして、パートタイムで 70 日間かけて 108,000 行の C# によるリアルタイム・マルチプレイヤー・シミュレーションを構築する中で反復的に開発された。アーキテクチャは読み込み戦略の異なる 3 層からなる。すべてのセッションに読み込まれる約 660 行の単一の Markdown の憲章（ホットメモリ）には、コード規約、慣習、ビルドコマンド、既知の失敗モード、そして変更対象のファイルに応じてタスクを専門エージェントに振り分けるトリガーテーブルが収められている。19 の専門化されたエージェント仕様は合計約 9,300 行で、それぞれがドメインエキスパートのペルソナであり、その内容の半分以上は振る舞いの指示ではなくプロジェクトのドメイン知識である。そして 34 のサブシステム仕様書、合計約 16,250 行からなる知識ベース（コールドメモリ）は、Model Context Protocol の検索サーバーを通じてオンデマンドで提供される。
著者はこれをマルチエージェント協調フレームワークを補完するものと位置づけている。それらのフレームワークがエージェント同士の協調のしかたを定義するのに対し、本研究はエージェントが依存する知識を構造化する。つまり、コードそのものではなく、設計意図、制約、失敗モードといったコードについての知識をインデックス化する。エージェント仕様の例、検索サーバー、ブートストラップ用エージェントを含むこのフレームワークは、オープンソースのコンパニオンリポジトリとして公開されている。
主なポイント
- 283 の開発セッションにわたり、著者は 2,801 件の人間のプロンプト、1,197 回のエージェント呼び出し、16,522 回の自律的なエージェントターン ── 人間のプロンプト 1 件あたりおよそ 6 ターン ── を記録し、218 のセッションにわたって知識ベースへの検索呼び出しが 1,478 回あったとしている。
- コンテキストインフラストラクチャは合計約 26,200 行で、コードベースの規模の 24.2% にあたる。著者はこの知識対コードの比率を、目標や知見としてではなく、このプロジェクトの複雑さとドメインを反映したものとして扱っている。
- 専門エージェントは通常、事前に設計されたのではなく、観察された失敗に応じて作られた。あるドメインのデバッグが繰り返し行き詰まったり、同じ知識を何度も説明し直す必要が生じたりしたときには、その知識をエージェント仕様にコード化してタスクをやり直すほうが速かった。
- 4 つの観察的ケーススタディが、コード化されたコンテキストの異なる役割を示している。74 のセッションで参照されたセーブシステムの仕様では、その間に 5 つの永続化機能が構築され、セーブ関連のバグは発生しなかった。UI 同期の仕様は、後の機能が確立されたパターンを最初の試みで適用することを可能にした。何も返さなかった検索クエリは文書化されていないサブシステムの存在を露呈させ、そのサブシステムはリファクタリングの前に仕様化された。そしてあるドメインエージェントは、その埋め込まれた知識によって、それまで 5 回の試みで解決できなかった決定性のバグの解決に貢献した。
- 仕様の陳腐化が主要な失敗モードだった。少なくとも 2 回、古くなった文書のせいでエージェントが最近のリファクタリングと矛盾するコードを生成しており、著者はエージェントがドキュメントを絶対的に信頼することを強調している。対応する仕様の更新なしにソースファイルが変更されたときに警告するセッション開始時のフックが、このチェックを部分的に自動化している。
- 保守のオーバーヘッドは平均して週に約 1〜2 時間だった ── 仕様に影響があったセッションごとにおよそ 5 分、それに加えてすべてのコンテキスト文書を対象とした隔週のレビューである。
- 本論文は実践者向けの 6 つのガイドラインを抽出している。その中には、基本的な憲章は初日から大きな役割を果たすこと、2 度説明した知識は書き留めるべきこと、エージェントの混乱は仕様が欠けているか古くなっていることを示す診断シグナルであること、が含まれる。
注記
著者は、本論文がシステム論文兼経験報告であり、その貢献は有効性の統計的証拠ではなくアーキテクチャにあると明言している。評価は単一の開発者による単一のプロジェクトであり、統制された実験ではなく観察的ケーススタディに依拠しており、因果的な主張は行っていない。切り分けられない交絡要因の 1 つとして開発者自身の経験の成長がある。実装は MCP をサポートする Claude Code に結びついているが、著者は、その原則 ── 階層化された知識、ホット／コールドの分離、ドメイン専門家へのルーティング ── は、セッション開始時の設定とオンデマンドの検索をサポートするあらゆるエージェント型コーディングツールに適用できると論じている。著者は自身がソフトウェアエンジニアリングではなく化学のバックグラウンドを持つことに触れ、このプロジェクトを、ドメインエキスパートが AI エージェントを使って本来の専門外のソフトウェアを構築するためのテストケースとして位置づけており、各層の統制されたベンチマーク評価を最も直近の次のステップとして挙げている。
本論文は、永続的な Markdown と spec–plan–implement ワークフローによって類似の問題に取り組むものとして Conductor（Gemini CLI 拡張機能） に言及しており、自らの研究は独立かつ同時期に開発されたもので、エージェント型コーディングツール間で移植可能な知識の組織化に焦点を当てていると説明している。ここで抽出したバージョンは arXiv:2602.20478v1 [cs.SE] である。