8月24日、Myron Koch（Peak Summit Labs）が「PrimeAgentOrchestrator: Memory-Primed Agent Spawning for Personal AI Infrastructure」と題した論文を公開した。セッションをまたいで記憶を引き継ぐLLMコーディングエージェントのオーケストレーションシステム「PrimeAgentOrchestrator」の設計と4ヶ月間の実運用経験を詳述した内容で、エージェント本体を一切改変せずに外側から記憶注入を実現するという非侵襲的なアプローチが技術的に注目に値する。
「毎回ゼロから」という根本問題
Claude CodeやGitHub CopilotのようなLLMコーディングエージェントは、セッションを開始するたびにコンテキストウィンドウが空の状態でスタートする。前のセッションで積み上げたプロジェクトの背景知識、ユーザーの好み、過去の設計判断——これらはすべて揮発する。
Kochはこの問題を「accumulated knowledge from prior work」が毎回捨てられると表現し、パーソナルAIインフラとして実用に耐えるには解決が必要だと指摘している。
この課題に対してMemGPTなど複数の研究アプローチが存在するが、それらの多くはエージェント内部の改修を前提とする。PAOはその前提を取り払い、既製エージェントの外側から記憶を差し込むという設計思想を選んだ。
PrimeAgentOrchestrator（PAO）の仕組み
PAOは、AnthropicのターミナルベースのコーディングエージェントであるClaude Codeの新規インスタンスを起動する際に、ユーザーの既存の個人データベースからコンパイルした関連記憶を事前注入するシステムだ。
スポーン（インスタンス生成）時の処理フローは以下の通りだ：
- 2つのメモリバックエンドを並列クエリ
- PostgreSQLエンティティ観察データベース：構造化された実体情報を管理
- Cloudflare Workersセマンティック検索インデックス：意味的類似性に基づく検索を担当
- バックエンド固有の検索戦略でフュージョン：2系統の結果を統合して「ブリーフィング」を生成
- ファイルシステムインジェクションで配信：Claude Codeが持つ設定ファイルの自動読み込み挙動を利用して、コンパイルされた記憶を注入する
ここで着目すべきは、単一の統合メモリシステムを構築する代わりに、異種のメモリシステムをブリッジするアーキテクチャ選択だ。Kochはこれを意図的なトレードオフとして論文内で取り上げている。「統合メモリシステムを作らない」という判断は、現実的な個人インフラの制約——既存DBをそのまま活かす——を前提にした実装者目線の選択であり、ゼロから専用基盤を構築することが難しいパーソナルユースケースに対して現実解を示している。
また、PAOはエージェントのライフサイクル全体を管理する。具体的にはトラスト事前設定（trust pre-seeding）、エラー検知を含むレディネスポーリング、適応型ターミナルテキストインジェクションが含まれる。
4ヶ月の実運用で見えた3世代の進化
この論文は純粋な理論提案ではなく、2025年12月〜2026年3月の4ヶ月間にわたる実運用経験レポートだ。実際に自分のパーソナルインフラとして動かし続けた著者が記録した知見という点が、エンジニアにとって特に価値がある。
Kochはコンテキスト配信メカニズムの3世代にわたる変遷を記録している。各世代の再設計を促した失敗モードが具体的に文書化されており、「なぜそのアーキテクチャでは不十分だったか」という実装上の教訓として読める内容になっている。単なるシステム紹介にとどまらず、試行錯誤のプロセスを追える点が本論文の強みだ。
設計上のポイント整理
本システムの技術的な特徴をまとめると：
- ファイルシステムインジェクションという配信手段の選択は、Claude Codeが設定ファイルを自動読み込みする既存の挙動を利用したもので、エージェントの内部実装を変更せずに記憶注入を実現している
- PostgreSQL（構造化）とCloudflare Workers（セマンティック）という性質の異なる2系統を並列運用することで、単一システムでは補えない検索の多様性を確保している
- エージェント本体を改変しない非侵襲的アプローチは、将来的にエージェント側がアップデートされた際の保守コストを抑える観点でも合理的な選択といえる
詳細はPrimeAgentOrchestrator: Memory-Primed Agent Spawning for Personal AI Infrastructureを参照していただきたい。
