技術的概要：LLM エージェント能力評価のための統一フレームワークの必要性

問題定義

大規模言語モデル（LLM）のエージェント能力の評価は、モデルをエージェントハarness（プロンプト、メモリ、ツールインターフェース、パーサー）でラップし、実行環境に配置する実行可能なベンチマークへと移行しつつある。本論文は、2 つの LLM がエージェントベンチマークで異なるスコアを獲得した場合、そのばらつきをモデルの内在的なエージェント能力に確実に帰属させることができないという重大な「識別問題」を特定している。むしろ、スコアは以下の LLM 以外のコンポーネントによって交絡されている：

• ハarnessの互換性： プロンプトの足場（scaffolding）、計画戦略（例：ReAct 対 Chain-of-Thought）、メモリ形式の違い。
• 推論のばらつき： プロバイダー固有のコンテンツモデレーション、API 制約、エンジン固有のデコード動作（例：vLLM 対 Transformers）。
• ツール呼び出しの不一致： 互換性のないスキーマ定義、パラメータ型の処理、パーサーの厳格さ（例：正規表現ベースの JSON パーシング対ネイティブ関数呼び出し）。
• 環境のドリフト： ライブで動的な環境（例：ウェブ検索）の使用は、タスクの解決がモデルの能力ではなく評価時点のインターネットの状態に依存する、再現不可能なノイズをもたらす。

著者らは、これらの交絡要因に対処しない限り、ベンチマークスコアはモデルの能力と周囲のスタックで行われたエンジニアリング上の選択を混同し、LLM 間の比較を科学的に無効にするであると主張している。

手法と提案フレームワーク

本論文は、航空力学における風洞試験やハードウェアにおける GPU ベンチマークと同様の「変数制御」の原則に基づいた「統一評価フレームワーク」を提案する。このフレームワークは、すべてのエージェント製品を標準化したり、展開されたシステムにおけるイノベーションを凍結したりするものではなく、むしろ LLM コンポーネントを特に評価するための制御された実験基盤の創出を目指す。

このフレームワークは 2 つの中核コンポーネントから構成される：

1. 制御された実行基盤

このコンポーネントは、モデルを取り巻く LLM 以外の層を標準化し、評価間において一定であることを保証する。以下を義務付ける：

• 固定された Harness メカニズム： プロンプト構築、メモリのシリアライズ、ツールのディスパッチのための標準化されたランタイム。本論文は、メモリの表現、エラー処理、計画ループの均一性を保証するため、既存の汎用足場（例：smolagents）を参照実装として採用することを提案している。
• 決定論的環境： 環境ドリフトを排除するため、ライブで動的な環境を、バージョン固定のスナップショットベースの環境（例：ウェブコンテンツのスナップショット化またはシミュレートされたデータベースの使用）に置き換える。
• 標準化された入力/出力契約： 基盤上で実行されるすべてのベンチマークにおいて、ツールの定義、パラメータ型、および解析ルールが一貫していることを保証する。

2. 原則的な評価手法

このコンポーネントは、エージェントの行動がどのように測定され報告されるかを標準化する：

• 規範的メトリクス： 単一のスカラースコアを超え、軌道の正しさ、環境状態の変化、リソース使用量（トークンコスト、レイテンシ）を網羅する多次元報告システムへの移行。
• パレートフロンティア分析： 単一の集約スコアではなく、正しさ、効率性、コストにおける優位性に基づいてモデルを評価する。
• 共有された失敗分類体系： 異なるベンチマーク間での比較可能な失敗分析を可能にするため、エージェントの失敗（例：「誤った情報」、「無効な形式」）の統一分類を確立する。
• バージョン管理ガバナンス： MLPerf や vLLM に類似したバージョン管理システムを実装し、スコアに特定のフレームワークバージョンをタグ付けする。これにより、技術の進化に合わせて仕様を進化させつつ、過去のデータを無効化することなく、現在の概念の硬直化を防ぐ。

主要な貢献

1. 交絡変数の診断： 本論文は、推論設定、プロンプト足場、メモリ管理、ツール呼び出しのセマンティクス、環境のダイナミクスを含む、LLM 以外の評価ノイズの源を体系的に分類する。厳格なパーサーと寛容なパーサーがツールの使用スコアをどのように変化させるかといった具体的な例を示し、これらの効果の大きさを実証する。
2. 評価と展開の区別： 著者らは、統一フレームワークがモデル能力の「制御された比較」のためのものであり、Harness のイノベーションが望ましい「展開されたエージェント製品」（Claude Code や Codex など）の設計とは区別されることを明確にする。
3. 運用仕様： 本論文は、ベンチマークが基盤に対して「プラグイン互換」であるための構造的要件を概説し、特定の構造的制約（例：自動化可能な成功基準、バージョン固定の環境）を満たさなければならない指令セット（$I$）、ツールセット（$T$）、環境セット（$E$）のトリプレットを定義する。
4. ガバナンスモデル： 評価の安定性の必要性と LLM エージェントのイノベーションの急速なペースとの間の緊張を管理するための、バージョン管理に基づくガバナンスモデルを提案する。

結果と証拠

本論文は、特定のモデルを比較する新しい実験結果を提示するものではない。むしろ、その「結果」は以下から導き出される：

• 経験的観察： 同じベンチマークで異なる Harness 下で評価された場合、同じ LLM が著しく異なるスコアを生み出すことを示した『Holistic Agent Leaderboard』[10] を引用する。
• ケーススタディ：
  • プロンプト足場： 約 200 語の BFCL プロンプトと約 2,000 語のsmolagents足場を比較し、後者が明示的な計画と再計画のロジックをエンコードしており、それが人工的にパフォーマンスを向上させることを示す。
  • メモリ表現： 構造化されたメモリステップ（smolagents）とフラットなチャット履歴（τ-bench、BFCL）を対照させ、エラータグ付けとステップタイピングが回復能力にどのように影響するかを示す。
  • 環境ドリフト： BrowseCompおよびBFCL V4からの 3 つの軌跡を分析し、ライブウェブ検索結果（古くなったスニペット、ボット対策ブロック、検索インデックスのシフト）が正しい推論トレースを失敗としてラベル付けさせ、スコアがモデルの能力と同様に環境の状態を反映していることを証明する。

意義と主張

本論文は、現在の LLM エージェント評価の状態が、科学的に解釈可能な進歩に対する「構造的障壁」であると主張する。その意義は以下の点にある：

• 公平な帰属の可能化： Harness と環境を一定に保つことで、フレームワークは研究者がパフォーマンスの違いを厳密に LLM に帰属させ、モデル能力をエンジニアリング努力から分離することを可能にする。
• 再現性： ライブ環境のドリフトに起因する現在のエージェントベンチマークの「再現不可能性」に対処し、スコアがテストの瞬間ではなくモデルの性質であることを保証する。
• コミュニティの標準化： MLPerf が GPU ベンチマークを標準化したように、ベンチマーク固有の独自スタックから、共有されたバージョン管理インフラへの移行を呼びかける。

著者らは、この作業をエージェント設計におけるイノベーションへの制限としてではなく、それらの設計を駆動する基盤モデルのエージェント能力を正確に測定するための必要条件として位置づけている。