技術要約：GitHubにおけるAIエージェントのプルリクエスト

問題提起

AIコーディングエージェントは、課題を評価し、修正案を書き、自律的にプルリクエスト（PR）を提出するところまで進化し、独立して動作できるようになりましたが、並行するエージェント活動の影響を理解することには決定的なギャップが存在します。これまでの研究は、個々のエージェントの出力品質や、単一のエージェントのPRとベースブランチとの間の競合に焦点を当ててきました。しかし、複数のエージェント（あるいは同一のエージェントの複数のインスタンス）が同時に同じリポジトリに対して作業を行う場合に何が起こるのかという実証的な調査は行われていません。具体的には、既存の文献では以下の点に関するデータが欠落しています：

1. GitHubにおける並行的なエージェント・ワークフローの頻度。
2. これらの同時進行中のワークフローが互いに競合する可能性。
3. これらの競合の構造的な性質（例：テキスト競合かセマンティック競合か）。

本論文は、自律的開発におけるアーキテクチャとテキスト間の「コーディネーション・ギャップ（調整の乖離）」に対処するものであり、バージョン管理ツールは行レベルのテキスト競合を検出できるものの、複数の自律的な開発者間の競合する意図を本質的に解決することはできないという点に注目しています。

メソドロジー

本研究では、2,807個のリポジトリにわたる33,596個のPRを含むAIDev-popデータセットを利用しています。著者らは、以下の4部構成の実証的アプローチを採用しています。

1. 共活動（Co-activity）の定式化： 著者らは、時間的な重複に基づいて「共活動的（co-active）」なPRを定義しています。PR $P_i$ は、リポジトリ、作成エージェント、オープン時刻（$T_{open}$）、クローズ時刻（$T_{close}$）によって定義されます。2つのPRは、その活動ウィンドウ $[T_{open} - k, T_{close} + k]$ が重なる場合に「共活動的」であるとみなされます。本研究では、4つの時間パディング閾値（$k \in \{0, 1, 3, 7\}$ 日）にわたってこれを分析しています。
2. 層化抽出： 高活性なリポジトリによる結果の偏りを避けるため、著者らはマージ・リプレイ用の層化サンプルを作成しました。
   • 層A（エージェント内 / Intra-agent）： 625個のリポジトリ。各リポジトリから、同一のエージェントによる一対のPRを抽出。
   • 層B（クロスエージェント / Cross-agent）： クロスエージェント活動を示す全122個のリポジトリ。各リポジトリから、異なるエージェントによる一対のPRを抽出。
   • 合計サンプル： 747組のユニークな共活動ペア。
3. 大規模マージ・リプレイ： 著者らは、ヘッドレス git merge-tree 機能を用いた自動化されたマルチスレッド・プロセスを開発しました。これは、ワーキングディレクトリに触れることなく、メモリ内で3ウェイ・マージをシミュレートするものです。プロセスは両方のPRのヘッドコミットを取得し、共通の先祖を特定し、マージを試みます。
   • 競合検出： リターンコード 1 はテキスト競合を示します。システムは競合するファイルパスと競合タイプ（例：content、modify/delete、add/add）を抽出します。
   • 範囲： 本研究は厳密にテキスト競合（レイヤー1）に焦点を当てています。著者らは、ビルド（レイヤー2）やセマンティック（レイヤー3）の競合は、テキストのマージが成功しない限り発生し得ないため、これはシステム摩擦の「保守的な下限値」を提供していると述べています。
4. タクソノミー（分類）分析： 競合はファイルタイプ（ソースコード、依存関係、設定など）および構造的タイプ（コンテンツの重複か、削除などの構造的変更か）によって分類されます。

主な貢献と結果

1. 並行性の頻度 (RQ1)

並行するエージェント活動は蔓延しています。

• 厳密な重複 ($k=0$): 40.2% のリポジトリに、少なくとも一組の共活動的なPRが含まれています。
• PRレベルの普及率: すべてのエージェント作成PRの 79.4% が、別のエージェントのPRと並行してオープンされています。
• 拡張されたウィンドウ: ±7日のウィンドウを許容した場合、53.4% のリポジトリと 95.0% のPRが共活動性を示します。

2. 共活動の構成 (RQ2)

並行性の大部分は、クロスエージェントではなく**エージェント内（Intra-agent）**のものです。

• エージェント内: 共活動的なペアの 99.5% は、同一のエージェントモデルによって作成されています。
• クロスエージェント: ペアのうち異なるエージェントが関与するのはわずか 0.5% であり、それは 2,807 個のリポジトリのうちわずか 122 個（約4.3%）で見られました。
• 支配的要因: OpenAI Codex が並行性の主要な推進力となっており、クロスエージェント相互作用における「多数派のアドバンテージ（majority anchor）」として機能しています。

3. マージ競合率 (RQ3)

並行するエージェントのPRをマージする際には、エージェント内とクロスエージェントのシナリオ間で明確な違いを伴う、重大な摩擦が生じます。

• エージェント内競合率: 19.8% (119/601 組)。
• クロスエージェント競合率: 41.7% (48/115 組)。
• 統計的有意性: これらの率の95%信頼区間は重なっておらず、これら2つのカテゴリ間における競合の可能性の明確な差異を示しています。

4. 競合の構造とタクソノミー

競合の性質は、深いコーディネーションの失敗を明らかにしています。

• ファイルタイプ: 競合したファイルの 84.4% はソースコードであり、依存関係のマニフェストが主な競合源であるという仮定を覆しています。
• 構造的 vs コンテンツ:
  • 57.6% はコンテンツ競合（同じ行への異なる更新）。
  • 41.9% は構造的競合（modify/delete が 26.8%、add/add が 15.1%）。
• 示唆: エージェントは、ファイルが存在すべきかどうかについて頻繁に意見が分かれたり、同じ新しいファイルを独立して作成したりしており、これは並行操作に対する認識の欠如を示しています。

5. 関連性 (RQ4)

• スループット: PRレベルの共活動は、リポジトリのスループットとともに増加します（低スループットのリポジトリの約53%から、高スループットのリポジトリの約90%へ）。
• エージェント: Devin (82.5%) と OpenAI Codex (80.9%) が最も高いPRレベルの共活動率を示しています。
• 言語: Go (92%) および Ruby (87%) のリポジトリが最も高い共活動率を示し、C++ (56%) や HTML (44%) は最も低い値を示しました。

重要性と主張

本論文は、並行するエージェントの提出に関する最初の実証的検討を提供すると主張しています。その主な意義は、マルチエージェントのオーケストレーションが、現在は異種ベンダー間の調整の問題であるという理論的な仮定に異議を唱える点にあります。むしろ、データは、単一のエージェント・フレームワークからの高頻度な出力を管理することが支配的な運用上の問題であることを明らかにしています。

著者らは次のように断言しています：

1. 認識の欠如: 現在のエージェントは、同じファイルを変更している他のエージェント（たとえ同種のエージェントであっても）に対する「水平的な認識」を持たず、孤立して動作しています。
2. 保守的な見積もり: 報告された競合率（19.8% および 41.7%）は保守的な下限値です。これらはテキスト競合のみを表しており、実際のコストには、測定されていないビルド失敗、セマンティックな矛盾、CI/CDの計算資源の浪費、およびトークン予算の枯渇が含まれます。
3. 構造的な不一致: 構造的競合（modify/delete, add/add）の高い割合は、エージェントが単に行を編集しているだけでなく、リポジトリの構造そのものについて根本的に意見を異にしていることを示唆しており、これは単純なコードレビューでは容易に解決できない問題です。

結論として、未調整のリアクティブな開発パラダイムは現代の自律的エンジニアリングには不十分であり、今後の研究は、これらの統合摩擦を軽減するために、プログラムによるオーケストレーションおよびライブ・ワークスペース通信プロトコルに焦点を当てる必要があると述べています。