コーディングエージェント向けハーネス設計の実証的研究

概要

コーディングエージェントのパフォーマンスは、基盤となる大規模言語モデル（LLM）単体によって決まるのではなく、モデルとその「ハーネス」——計画、アクション空間、コンテキスト管理を統合したシステム——の相互作用によって決まる。研究によれば、普遍的な「最良」ハーネスは存在せず、最適な構成はモデルのネイティブな能力、タスクの種類、利用可能なリソース予算に依存する。

コンテキスト管理の役割

コンテキストウィンドウの予算が限られている場合、コンテキスト管理は特に重要である。その主な価値は、コンテキストオーバーフローの失敗を防ぐことであり、エージェントが本質的に行動を変えることなく、より長い実行軌道を維持できるようにすることにある。

コンテキスト管理に関する主な発見は以下の通りである：

• 予算感受性： コンテキストウィンドウが小さい場合、コンテキスト管理の恩恵が最も顕著になる。たとえば、32kウィンドウでは管理済みと未管理のコンテキスト間の成功確率の差が最大35.7ポイントに達するが、128kでは2.7ポイントまで低下する。
• 最適戦略： LLMベースの要約の前に、ルールベースの省略（不要なコンテキストの削除）を段階的に行うことで、全体的な効率が最も高くなる。
• 回復可能性： 省略されたコンテンツを復元可能にするメカニズムを追加しても、精度の向上は得られない。モデルはこれらの機能をほとんど利用しないからである。

計画の役割：補強材かコスト削減か

モデルの強さが増すにつれて、計画コンポーネントの有用性は変化する。弱いモデルでは、計画はタスクを早期に放棄するのを防ぐ精度の補強材として機能する。強いモデルでは、計画は冗長な検証ステップを減らすコスト削減手段として主に機能し、最終的な精度にはほとんど影響しない。

この傾向は業界の実践にも見られる。たとえば、一部の新しいフロンティアモデルでは、TaskCreate や TodoWrite といった組み込みタスク追跡ツールが削除されている。これは、モデルのネイティブな推論能力が高まったことで、明示的なセッション内計画ツールの必要性が減少したためである。

アクション空間とツールの習熟度

事前に定義された構造化ツールと、純粋なbashインターフェースの選択は、モデルのシェルコマンド習熟度に依存する。

• bash対応モデル： bashの習熟度が高いモデルは、bashのみのインターフェースを使用することで、より効果的かつ低コストに動作する。特にコマンドライン中心のタスクでは、複数のコード変更を1つのツール呼び出しに統合できるため、特に有効である。
• 弱いモデル： bashコントロールが弱いモデルには、事前に定義されたツールが成功確率を向上させる。これは、モデルのシェル習熟度の欠如を補うために必要な構造を提供するからである。

結論：条件付きシステム問題としてのハーネス設計

本研究は、ハーネス設計を条件付きシステム問題として扱うべきだと結論づけている。デフォルトのコンポーネントセットを採用するのではなく、ターゲットモデル、タスクの種類、リソース予算に基づいてコンポーネントを選択すべきである。

コミュニティの知見の統合

業界の実務家や研究者たちは、これらの発見に関するいくつかのニュアンスを強調している：

"もし車Aがよりよく走っているなら…それは必ずしもエンジンが優れているからではない。タイヤが良くて、ギアボックスが良く、ボディが軽いからかもしれない…。あなたのハーネスは、基盤となるモデルのネイティブな能力に適応できるし、その欠如を補うこともできる。"

一部の批判者は、研究がNemotronやMistralモデルに焦点を当てており、Claude、GPT、DeepSeekなどのプロバイダーの最新フロンティアモデルを対象としていない点を指摘した。しかし、他の人々は、コンテキストウィンドウと管理戦略の関係に関する発見が、チェックポイントによるセッションの保存など、現実世界の利用パターンにおいても非常に適用可能であると主張している。