テクニカル・サマリー：大規模言語モデル（LLM）を責めるな：エージェント・ハーネスの進化がいかにコーディング・エージェントの品質を左右するか

問題提起

コーディング・エージェント（ソフトウェアエンジニアリングのタスクを解決するためにLLMを利用する自律型システム）は、システムプロンプト、ツールの実行、コンテキスト管理、および反復的な推論ループをオーケストレートするミドルウェア層である「エージェント・ハーネス」に依存している。これらのハーネスは極めて高い速度で進化しているが、その進化がエージェントの品質（有効性と効率性）にどのような影響を与えるかについての理解には決定的な欠落がある。実務家は、ハーネスの更新後に品質の退行（リグレッション）を報告することが多いが、一貫してその原因をハーネス自体ではなく、基盤となるLLMに帰している。ハーネスの継続的な開発活動が品質の向上につながっているのか、それとも単に複雑性とコストを増大させているだけなのかを判断するために、LLMからエージェント・ハーネスの寄与を経験的に分離した研究はこれまで存在しなかった。

メソドロジー

著者らは、エージェント・ハーネスという変数を分離するために、基盤となるLLMを一定に保つように設計された縦断的な経験的研究を実施した。

• ランドスケープ分析 (RQ0): 5つの主要なオープンソース・エージェント・ハーネス（Codex, Qwen Code, Gemini, OpenCode, OpenHands）と2つのベースライン・プロジェクト（VS Code, GitHub CLI）を分析し、リリース速度、開発活動、およびメンテナンス負担を特徴付けた。
• 制御された縦断的評価 (RQ1–RQ3):
  • 対象: Qwen Code CLI の35件の連続的なマイナーリリースおよびパッチリリース（v0.0.10 から v0.10.3）。
  • モデル: 変数としてのモデル更新を排除するため、vLLMを介してローカルでホストされた単一の固定LLMバージョン（Qwen3-Next-80B-A3B-Instruct）を使用。
  • タスク: さまざまな難易度をカバーする SWE-bench Verified からの50個の層別化されたタスク。
  • 実行: 確率性を考慮するため、各リリースにつき各タスクを2回ずつ実行（計3,500回の実行）。
  • 指標:
    • 有効性 (Effectiveness): 解決率（生成されたパッチがすべてのテストに合格したタスクの割合）。
    • 効率性 (Efficiency): トークン消費量（入力/出力）およびツール呼び出し頻度。
  • 分析:
    • RQ2 (プロジェクトレベル): 品質変化を22のリリースレベルの開発要因（コミット構成、コードのチャーン、PRサイズ、コントリビューターのアクティビティなど）と相関させた。
    • RQ3 (アーキテクチャレベル): コードの変更を10個のコンポーネントからなるリファレンス・アーキテクチャにマッピングし、どのアーキテクチャ層（例：LLMプロバイダー、コンテキスト管理）が変更に対して最も敏感であるかを特定した。

主な貢献

1. 「ハイパー・チャーン（超高速な変動）」の特性化: コーディング・エージェント・ハーネスの、前例のない開発強度を定量化した。これらは従来のオープンソース・プロジェクトよりも13〜28倍頻繁にリリースされ、急速に数千のIssueを蓄積している。
2. 初の制御された縦断的評価: 35件の連続するリリースにわたってLLMを固定することで、エージェント・ハーネスの影響を分離した初の研究を提供した。
3. プロジェクトレベルの説明: 品質変化と相関する特定の開発パターン（機能重視のリリース vs 修正重視のリリース、PRサイズなど）を特定した。
4. アーキテクチャレベルのリスク分析: コミットをリファレンス・アーキテクチャにマッピングし、高リスクなコンポーネント（LLMプロバイダー、コンテキスト管理）と低リスクなコンポーネント（拡張性、セキュリティ）を特定した。
5. 再現パッケージ: 35個の全Qwen Code CLIバージョン、評価スクリプト、および生の結果を含む包括的なパッケージを公開した。

主な結果

RQ0: 進化の特性

コーディング・エージェント・ハーネスはハイパー・チャーンを示しており、週平均10〜18回のリリース、および1日あたり13〜34回のマージ済みコミットを行っている。成熟したプロジェクトとは異なり、これらのハーネスはIssueを解決するよりも速いペースでバックログを蓄積しており、一部のプロジェクトでは約54%のIssueしかクローズできていない。

RQ1: 品質の進化

• 有意な改善なし: 継続的な開発にもかかわらず、35回のリリースを通じて解決率に統計的に有意な改善は見られなかった。初期のバージョンが、より複雑な後のバージョンよりも優れたパフォーマンスを示すこともあった。
• 効率性の低下: 後期のリリースほど、より多くのリソースを消費している。タスクあたりのトークン消費量は、解決率の向上を伴うことなく、70%以上増加（約391Kから約668Kトークンへ）し、ツール呼び出しもいくつかのケースではほぼ倍増した。
• 失敗のコスト: 未解決のタスクは、解決済みのタスクよりも2.7倍多くのトークンと1.8倍のツール呼び出しを消費しており、これは失敗したエージェントが非生産的なループに陥っていることを示唆している。
• コストの要因: コストの増加は、システムプロンプトのサイズの8%拡大と、会話ターン（LLMとの相互作用）の18%の増加によって引き起こされており、これらが複合的に作用してトークン使用量を膨らませている。

RQ2: 開発パターン

• 機能重視のリリース: トークン消費量とツール呼び出しの増加を代償として、より高い解決率と相関した。
• 修正重視のリリース: 解決率を向上させることなく、高いトークン消費量に関連していた。
• PRサイズ: 大きなPR（集約された変更）はトークン消費量の減少と相関する一方、多くの小さく分散したPRはオーバーヘッドを増大させる。
• コードの削除: コードの削除は、コストの削減と相関している。

RQ3: アーキテクチャの感度

• 高リスク・コンポーネント: LLMプロバイダー層とコンテキスト管理層への変更は、品質の退行（リグレッション）としばしば関連している。特に、単一のリリースにおけるLLMプロバイダーへの大規模な変更は、即座にリグレッションのリスクを伴う。
• 低リスク・コンポーネント: 拡張性（プラグイン/フック）およびセキュリティコンポーネントへの変更は、一貫して安全または効率性の向上に関連している。
• リファクタリング: UI層のリファクタリングは、短期的には品質の向上をもたらしたが、長期的にはトークンコストを増大させるという相反する効果を示した。

意義と主張

本論文は、「エージェント・ハーネスの継続的な改善が、より優れたエージェントの品質につながる」という一般的な仮定は誤りであると主張している。本研究は、より多くのコードとより速いリリースが、必ずしも優れたエージェントをもたらすわけではないことを証明している。むしろ、それらはしばしば、有効性を向上させることなく効率性を低下させる複雑さを導入する。

著者らは、検知されないリグレッションの主な原因として、「非機能的なエージェント的リグレッション・テスト（Non-functional Agentic Regression Testing）」の欠如を挙げている。エージェント・ハーネスの現在のCI/CDパイプラインは、機能的な正当性（ツールが動作するか？）は検証するが、エージェントレベルの指標（解決率、トークン効率、ツール呼び出しのオーバーヘッド）に関する自動化されたベンチマークを欠いている。その結果、エージェントの性能を低下させるリリースであっても、既存の自動チェックを通過してしまうのである。

本論文の結論は以下の通りである：

1. 開発者は、エージェント・ハーネスを、機能的正当性だけでなく、トークン消費量やツール呼び出しのオーバーヘッドの監視を必要とする、品質クリティカルなソフトウェアとして扱う必要がある。
2. 研究者は、コーディング・エージェントを評価する際、基盤となるLLMだけでなく、エージェント・ハーネスのバージョンも報告・制御し、有効性と並んで効率性の指標を考慮する必要がある。
3. **エージェント的QA（Agentic QA）**には、生成されたパッチのコードの正当性だけでなく、エージェントとハーネスの相互作用から生じる行動品質を評価する、新しい自動化されたリグレッション・テストの実践が必要である。