2026年2月、独立研究者のAristidis Vasilopoulos氏が「Codified Context: Infrastructure for AI Agents in a Complex Codebase」と題した論文を公開しました。AIコーディングエージェントがセッションをまたぐと記憶を失い、プロジェクト固有の規約を忘れ、過去と同じ失敗を繰り返す。大規模プロジェクトでこの問題にどう対処するかという課題に、3層構造のドキュメントインフラで挑んだ実践報告です。
注目すべきは著者の背景です。Vasilopoulos氏の専門は化学であり、ソフトウェアエンジニアリングは本業ではありません。AIエージェントを唯一のコード生成手段として、108,000行のC#分散リアルタイムシステムを70日間のパートタイム開発で構築しています。専門外の領域でAIとともにソフトウェアを作ると何が起きるのか。その成果と課題の両面が、データとともに記録された貴重なケーススタディです。
3層構造の「外部記憶」アーキテクチャ
この論文が提案するのは、AIエージェント向けのドキュメントを3つの階層に分けて管理する仕組みです。
- Tier 1：Constitution（ホットメモリ） … 約660行のMarkdownファイル。コーディング規約、命名規則、タスクの振り分けルールなどを記載し、毎セッション自動的に読み込まれる
- Tier 2：専門エージェント仕様 … 19体のドメイン特化エージェント、合計約9,300行。ネットワーク同期や座標変換など、特定領域の知識を埋め込んだ仕様書
- Tier 3：知識ベース（コールドメモリ） … 34件のサブシステム仕様書、合計約16,250行。MCP経由でオンデマンド検索して必要なときだけ読み込む
この3層分離の考え方は合理的です。常に必要な情報（Tier 1）、タスクに応じて呼び出す専門知識（Tier 2）、必要なときだけ検索する詳細仕様（Tier 3）。コンテキストウィンドウの圧迫を避けつつ、AIにプロジェクト固有の知識を供給する設計として筋が通っています。
実際に機能した：4つのケーススタディ
論文では、283のセッション（2,801の人間プロンプト、16,522のエージェントターン）から得られた4つのケーススタディが報告されています。
たとえばセーブシステムの仕様書は74セッション・4週間にわたって参照され続け、5つの後続機能すべてが一貫した設計で実装されました。また、ネットワークUIの同期パターンは、過去の試行錯誤から抽出された仕様書のおかげで、次の機能実装を一発で成功させています。
とりわけ印象的なのは、決定論的乱数生成器のデバッグ事例です。5回のコンテキストウィンドウ枯渇と84回のコード編集を経ても解決しなかったバグが、ドメイン知識を埋め込んだ専門エージェントの投入で、根本原因の特定に至りました。事前に仕様書へ整理された知識が、セッション中にゼロから再導出することなく問題を切り分けた好例です。
外部記憶としてのドキュメントが機能すること自体は、この論文が実証しているといえます。
見えてきた課題：ドキュメントが「第二の複雑性」になる
しかし、効果と同時にコストも浮き彫りになっています。
108,000行のC#コードを支えるために、約26,000行のドキュメントが必要になりました。コード比24.2%です。しかもこのドキュメントは自動生成ではなく、開発者がAIに指示して作成・更新を行う手動メンテナンスです。著者自身の報告では、週あたり1〜2時間のメンテナンスコストが発生していました。
さらに深刻なのが、論文自身がガイドラインG6として明記している問題です。「古い仕様書はAIを誤導する」。実際に、2回以上の事例で、更新されていない仕様書がAIに古い設計パターンを適用させ、テストで初めて問題が発覚しています。著者はこれに対処するためにドリフト検出スクリプトを導入していますが、これ自体がさらなる管理対象になっています。
ここに構造的なジレンマがあります。AIの記憶喪失を補うためにドキュメントを増やすと、そのドキュメントの鮮度管理が新たな複雑性として積み重なる。ドキュメント管理のためのツールが、さらに管理対象を生む。
「専門外の人がAIでソフトウェアを作る」という挑戦
この論文のもうひとつの価値は、ドメインエキスパートがAIを使って専門外のソフトウェア開発に挑んだケーススタディとしての側面です。
化学を専門とする著者が、AIエージェントだけで108,000行のリアルタイム分散システムを構築したという事実は、素直に尊敬に値します。同時に、ソフトウェアエンジニアリングの知見が限られる中でプロジェクトを進めると何が起きるかを、データとともに示した貴重な記録でもあります。
設計判断力の不足をドキュメント量で補おうとする力学が、コード比24.2%という数字に表れているとも読み取れます。経験豊富なソフトウェアエンジニアであれば暗黙知として持っている判断基準を、すべて明文化してAIに渡す必要があったからです。
AIの外部記憶は必要、問題は「どう管理するか」
この論文が示した知見は重要です。大規模プロジェクトにおいて、AIエージェントにプロジェクト固有の知識を供給する仕組みは確実に必要です。単一ファイルのマニフェストではスケールしないという指摘も、実践データに裏付けられています。
同時にこの論文は、「ドキュメントを手動で管理する」アプローチの限界も示しています。26,000行のドキュメントを常に最新に保つコストは、プロジェクトが大きくなるほど加速度的に増大します。
sqlewでの解決策
実はsqlewもこの論文で提起されている「大規模プロジェクトでのコンテキスト永続化」をテーマに開発されています。sqlewにおけるこの課題解決へのアプローチを次の記事でご紹介します。
参考文献
- Vasilopoulos, A. (2026). "Codified Context: Infrastructure for AI Agents in a Complex Codebase" — arXiv:2602.20478 — https://doi.org/10.48550/arXiv.2602.20478
- Lulla, J. L. et al. (2026). "On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents" — arXiv:2601.20404
- Zhang, Q. et al. (2026). "Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models" — arXiv:2510.04618
