3チームがAIエージェントのクロスリポジトリコンテキスト喪失に対して同じ修正をリリース

3週間前、Cortex 2026 Engineering in the Age of AI Benchmarkは、AI採用の加速以来、プルリクエストあたりのインシデントが23.5%増加し、変更失敗率が約30%上昇したことを示しました。私はそのデータと爆発半径への影響についてすぐに記事を書きました。

その時私が過小評価していたのは、言語がどれだけ速く変化するかでした。それ以来会話に定着したフレーズは「爆発半径」や「サービスカタログ」ではなく、「クロスリポジトリコンテキスト」です。そしてそれはほぼ常に「AIコーディングエージェント」と同じ文で使われています。理由は、大規模にAIコーディングエージェントを運用するチームが今公開しているものを読めば明らかです。彼らはAIが自分たちを高速化したことについて書いているのではなく、AIが複数のリポジトリにわたって安全にデプロイできるように構築しなければならなかったインフラストラクチャについて書いています。

過去6週間で、3つのチームが同じ診断と3つの異なる解決策を公開しました。彼らが収束している形状は、どれか一つよりも興味深く、私たち全員がエージェントランタイムインフラストラクチャをどう考えるかに直接的な影響を持ちます。

**3チームがリリースしたもの**

Neilos（dev.toの@neil_agentic）、3月27日。Go、Rust、TypeScript、Python、C++を横断する15以上のリポジトリを運営する個人創業者で、Telegramを通じて10の専門化されたClaude Codeエージェントを調整。彼の記事「How I Manage 15+ Repos with Claude Code (Without Losing My Mind)」では、診断ラインは直接的です。「セッション間でコンテキストをコピペし、どのPRがどれに依存しているかを手動で追跡し、全体像を見えないエージェントを監視することになる」と。

彼の解決策はttalと呼ばれ、「読み取りと探索」を「書き込み」から分離します。軽量な探索エージェントが任意のリポジトリを横断してコンテキストを収集します。ワーカーエージェントは、隔離されたgitワーカーツリー内で、一度に1つのリポジトリにのみ書き込みます。マネージャーエージェントはクロスリポジトリ計画を頭の中に保持し、適切なタイミングで適切なリポジトリに作業をルーティングします。データ構造としての依存関係グラフはありません。クロスリポジトリ調整は、マネージャーエージェントの推論と、名前をファイルパスにマッピングするプロジェクトレジストリに存在します。

Mabl、4月8日。25人のエンジニアチームが100以上のリポジトリを管理し、AI加速前は月に200以上のプルリクエストと40以上のプロダクションリリースをプッシュ。2026年2月までに、コミットの39%がAI支援、インフラリポジトリでは60%に。彼らの記事「How We Built a System for AI Agents to Ship Real Code Across 75+ Repos」は、4層アーキテクチャを説明。ここで重要な層は「Cross Repo Base」です。

Cross Repo Baseの中には「Repo Coordination Graph」があります：850行以上の構造化レジストリで、79のリポジトリをカバーし、詳細な依存関係グラフ、Pub/Subトピックマップ、データベーステーブル所有権、規定のリリース順序を含む。エージェントがクロスリポジトリ機能に取り組むとき、このグラフをクエリして、どのリポジトリを更新する必要があるか、マージ順序（上流ライブラリの前に消費者）、CODEOWNERSと依存関係チェーンに基づいてどのレビュアーをタグ付けするかを決定します。このレイヤーがないと、「すべてのエージェント呼び出しに人間がコンテキストを提供する必要があった」と報告。これにより、「コンテキストドリフトが失敗の約40%から5%未満に減少」。

Meta、4月6日。私は先週Metaの部族知識エンジンの記事について書いたので、簡潔に。Metaは50以上の専門エージェントを持つ多段階AIパイプラインを構築し、大規模データパイプラインの部族知識をマッピング。記事の終わり近くに重要な一文：「クロスリポジトリ依存関係インデックスとデータフローマップを生成し、変更がリポジトリ間でどのように伝播するかを示しました。これにより、『Xに依存するものは？』という質問がマルチファイル探索（約6000トークン）から単一のグラフルックアップ（約200トークン）に変わりました。」

これは、エージェントが計画中に尋ねる最も一般的な質問の1つに対する30倍のトークン削減です。

**何が同じで、何が異なるか**

痛みは同一です。3チームすべてが、エージェントが局所的に正しいコードを出荷するが、エージェントが存在を知らなかったコンシューマを壊すと説明しています。Mablはコンテキストドリフト、Metaは部族知識、Neilosは「全体像を見えない」エージェントと表現。現象は1つの現象です：変更の安全性を決定する依存関係グラフは、単一リポジトリの境界の外に存在し、つまりエージェントのコンテキストウィンドウの外に存在します。

解決策は教訓的な方法で分岐します。

MablとMetaは両方とも、依存関係グラフをクエリ可能な基盤として構築しました。Mablのものは構造化された850行のレジストリとして、エージェントが計画時に参照。Metaのものはパーサー由来のグラフインデックスとして、エージェントがツールとして呼び出します。形状は少し異なりますが、運用モデルは同じです。決定論的構造。自動的にリフレッシュ（Mablはレジストリ更新とCODEOWNERS、Metaはソースの再解析）。マルチファイル探索ではなく単一ルックアップとしてクエリ可能。グラフはエージェントとは別に存在し、どの単一エージェントセッションよりも長持ちします。

Neilosのttalは異なるアプローチを取ります。クロスリポジトリ情報は、マネージャーエージェントのワーキングメモリと、プロジェクト名をファイルシステムパスにマッピングするTOMLファイルに存在し、アーキテクチャは書き込みを一度に1つのリポジトリに分離し、調整モデルをマネージャーのプロンプトに保持します。これは10のエージェントと15のリポジトリを持つ個人オペレーターによく適合します。Mablの規模では、同じ問題が解決策を再形成します。25人のエンジニアが79のリポジトリにわたって作業する場合、単一のエージェントのコンテキストウィンドウでは調整モデルを保持するのに十分な大きさはなく、手動のレジストリはそのスループットで最新の状態を保てないため、依存関係モデルはどのエージェントの外にも存在しなければなりません。

私がこれから読み取るのは、依存関係グラフをクエリ可能な基盤とすることはスタイルの選択ではなく、問題をスケールしたときに現れる結果だということです。3つのチームが同じ壁にぶつかりました。2つは明示的に基盤を構築しました。1つは調整で処理しました。それはソロスケールでは正しい選択です。エージェントを運営するチームがそれを超えて成長すると、基盤が構築するものになります。

**なぜこれはプリミティブであるべきで、すべてのチームが再構築するものではないのか**

Mablの記事はこの層をほぼ当然のこととしてリストしています。Metaの記事はエージェントスウォームとクリティカルパスに関するセクションの後、1段落で言及しています。両チームとも、それが実際にやろうとしていたことのテーブルステークスとして扱っています。そして両方の場合において、構造層は彼らが構築したものの中で最も安価で、最も再利用可能で、最も耐久性のある部分です。MablのリポジトリごとのCLAUDE.mdはメンテナーなしで劣化します。MetaのLLM生成コンテキストファイルは自己リフレッシュするクリティカルスウォームなしで劣化します。依存関係グラフは劣化しません。なぜならパーサーがすべてのプッシュで実行されるからです。

これにより、MetaやMablではないすべてのチームに疑問が生じます：本当に手動で850行のリポジトリ調整グラフを書きたいですか？そしてリポジトリが追加、アーカイブ、リネーム、リファクタリングされるたびに最新に保つのですか？50人のエンジニア組織では、これはフルロードのエンジニア月の先行作業と、誰の職務記述書にも含まれていない継続的なメンテナンス税です。200人のエンジニア組織では、専用プラットフォームチームの責任であり、他にできるすべてのことと競合します。

このプリミティブは、どの単一チームの上にあるべきです。グラフ自体は構造的で、ソースコードから派生し、組織全体で形状が同じです。あなたが実際に欲しいもの（どのリポジトリがどれからインポートするか、誰がどのアーティファクトを消費するか、変更の推移的な爆発半径は何か）は、50のリポジトリでも500でも同じ質問です。AIコーディングエージェントを実行するすべてのマルチリポジトリ組織が、これをゼロから自分たちのバージョンを書く正当な理由はありません。それは機能ではなく、基盤です。

**APIとしての姿**

Riftmapは、単一の読み取り専用トークンを介してGitHubまたはGitLab組織からクロスリポジトリ依存関係グラフを自動発見し、10のエコシステムにわたるマニフェストを解析します：Terraform、Docker、Helm、Kubernetes、Kustomize、Go、npm、Python、Ansible、GitHub Actions/GitLab CI（さらに今後追加予定）。グラフは、AIエージェントが計画中に呼び出すように設計されたHTTP APIを通じてクエリ可能です。

自然なエージェントフローは3回の呼び出しです。エージェントがgithub.com/myorg/payments-apiのクローンで作業しているとします：

1. ローカルクローンURLをRiftmapリポジトリに解決

curl -s "$RIFTMAP_BASE_URL/repositories/lookup?url=https://github.com/myorg/payments-api" \ -H "X-API-Key: $RIFTMAP_API_KEY"

2. 1ラウンドトリップでコンテキストをハイドレート：リポジトリ + 依存関係 + 逆依存 + アーティファクト + 鮮度フィールド

curl -s "$RIFTMAP_BASE_URL/repositories/$REPO_ID/context" \ -H "X-API-Key: $RIFTMAP_API_KEY"

3. 実際に必要なときのみ：推移的な爆発半径

curl -s "$RIFTMAP_BASE_URL/repositories/$REPO_ID/impact?max_depth=3&min_confidence=0.8" \ -H "X-API-Key: $RIFTMAP_API_KEY"

3回の呼び出しで、MablのRepo Coordination GraphとMetaの依存関係インデックスが答えようとした質問に答えます。完全なスキーマはhttps://app.riftmap.dev/openapi.jsonで公開されています。一度取得してエージェントに渡せば、残りは型付きのhttpxまたはfetch呼び出しです。PythonとTypeScript版のこれらの例はエージェント統合ドキュメントにあり、各レスポンスが持つ鮮度契約（last_scanned_at、last_commit_sha、last_activity_at、archived）もあり、エージェントがグラフが古いかどうかを判断し、ユーザーに警告するか再スキャンをトリガーできます。

これが今日の基盤であり、HTTP APIとして公開されています。次にMCPサーバーとCLIがその順序で、Claude Code、Cursor、ClineエージェントがHTTP呼び出しを調整せずにドロップインできるようにします。順序と現在の状態は公開ロードマップページで追跡されています。

**インターフェースはモデルより長持ちする**

この時点で合理的な反論は：モデルが最終的にクロスリポジトリ推論に十分に優れ、これらすべてが不要になるのではないか？Claude 5や次世代が解決するのではないか？

私は、質問が反論が想定する方向には進まないと思います。モデルがクロスリポジトリ推論で改善され続けるとしても、3つのことが真実であり続けます。

第一に、マルチリポジトリ組織の依存関係マニフェストをモデルのコンテキストウィンドウ内から解析することは、パーサーが決定論的かつ安価に行える仕事をすることです。たとえ最先端モデルが完璧に実行しても、毎回の呼び出しでトークンコストを支払うことになりますが、構造的には事前計算されたルックアップです。Metaの30倍のトークン削減はモデル品質の問題ではなく、アーキテクチャの問題です。グラフインデックスは常に再構築するよりクエリする方が安価です。

第二に、モデルは6か月ごとに変わります。依存関係グラフは変わりません。安定したAPIの背後にあるクエリ可能なグラフは、呼び出すエージェントがClaude 4.7、Claude 5、または2027年の何であっても同じ形状を持ちます。インターフェースはモデルより長持ちします。基盤への投資は、特定のエージェントのコンテキスト戦略への投資とは異なる時間軸にあります。

第三に、鮮度問題は構造的です。今日訓練されたモデルは、あなたのチームが先週作成したリポジトリを知りません。昨夜のスキャンから派生したグラフは知っています。リポジトリグラフの変化率がモデルの再訓練率を超える限り、そのギャップは存在し、基盤がそれを埋める方法です。

モデルがクロスリポジトリ推論で良くなることでおそらく変わるのは、グラフの上に何をレイヤーするかです。検証された構造に基づくより良いセマンティック推論。既知の消費者影響に対するより良い自動PRレビュー。グラフ自体へのより良い自然言語インターフェース。これらは実際のことであり、重要になります。それらはすべて基盤の上にあり、基盤の代わりにはなりません。

**まとめ**

私がこの記事で始めた3つの投稿は、私がRiftmapを構築したのと同じ形の証拠であり、ただより大きな名前が付いているだけです。エンジニアが実際のエンジニアリング時間を費やして何かを構築するということは、その何かが必要とされていることを意味します。3つの独立したチームが2週間で同じ診断を公開するとき、パターンはパターンです。

アーキテクチャ上の賭けは変わっていません。最初に決定論的パーサー。グラフを耐久性のある層に。AIをその上の層として、検証された構造にアンカーし、それを再構築するのではなく。

[トークン節約のため省略]