AgentBench: エージェントとしてのLLM評価 — 金融AIの信頼性向上に向けた教訓

Beancountの書き戻しエージェントが確実に実行すべきことは何かと自問すると、その答えは「テキストを生成すること」ではなく、「構造化された環境において、脱線することなく一連のアクションを実行すること」です。AgentBench（Liu et al., 清華大学, ICLR 2024）は、その能力を大規模に測定しようとした最初期の本格的な試みの1つであり、2023年時点のスナップショットから得られた数値には、今なお抽出する価値のある教訓が含まれています。

論文の概要

清華大学のXiao Liu氏と21名の共著者によるAgentBenchは、LLMを受動的なテキスト生成器ではなくインタラクティブなエージェントとしてストレスステストするために設計された、8つの環境を定義しています。そのうち5つはオリジナルの環境です：OS（bash操作）、データベース（SQL生成とエラー回復）、ナレッジグラフ（ツールベースの構造化クエリ）、デジタルカードゲーム（複数ターンの戦略的競争）、水平思考パズル（推論対話）です。残りの3つは既存のデータセットを適応させたもので、ALFWorldの家事（House-Holding）、WebShopのネットショッピング、Mind2Webのウェブ閲覧です。本論文では、商用APIモデルから最大70Bのオープンソースモデルまで27のモデルを評価しました。開発用スプリット約4,000件、テスト用スプリット約13,000件の生成結果を対象に、環境ごとの成功率と総合スコアを報告しています。

主要な知見

• GPT-4が総合スコア4.01で首位となりました。Claude-2は2.49、GPT-3.5-turboは2.32でした。投稿時に最強のオープンソースモデルだったCodeLlama-34Bは、わずか0.96にとどまりました。APIベースのモデルの平均は2.24であるのに対し、オープンソースは0.42でした。
• GPT-4はOSで42.4%、データベースで32.0%、家事で78.0%を記録しました。この差は、どの環境が指示への忠実さを重視し、どの環境が構造化された推論を重視するかを示しています。
• 「タスク制限超過（Task Limit Exceeded）」が支配的な失敗モードです。ナレッジグラフの失敗の67.9%が、タスク解決前にステップ予算に達していました。これは知識の欠如ではなく、長期スパンの推論における失敗です。
• フォーマット準拠エラーはデータベースタスクの失敗の53.3%を占めています。エージェントが構文的に誤ったSQLを生成したり、クエリを評価器が解析できない文章で囲んだりすることが原因です。
• 無効なアクションの選択は、家事タスクの失敗の64.1%を引き起こしました。エージェントが現在の状態で利用できないアクション名を指定してしまうケースです。
• コードによる学習は「タスク全体で相反する影響」を及ぼします。手順に従う環境では役立ちますが、対話中心の環境では一般的な推論を損なう可能性があります。

何が通用し、何が通用しないか

マルチ環境、マルチターン、インタラクティブな評価という核心的な設計の選択は正しく、依然として活用が進んでいません。ほとんどのLLMベンチマークはいまだにシングルターンの生成品質を測定していますが、AgentBenchはタスクが完了するか予算が尽きるまで、エージェントが意思決定を継続しなければならないことを正しく主張しています。

とはいえ、このスナップショットは時間の経過による影響を受けています。GPT-4（4.01）と最高のオープンソースモデル（0.96）の間の格差は2023年中盤には驚異的に見えましたが、2025年までにその差はほぼ解消されました。Llama 3.1 70BやQwen 2.5 72Bのようなモデルは、2年前には高い壁だった指示への忠実さやフォーマット準拠の基準を今やクリアしています。この論文を「オープンソースはエージェントタスクをこなせない」という証拠として読むのは誤りでしょう。むしろ「フォーマットへの準拠と長期的な一貫性が難問である」という証拠として読むべきであり、その価値は失われていません。

また、広さと深さの間のジレンマもあります。8つの環境は包括的に聞こえますが、個々の環境は比較的浅いものです。WebArena（Zhou et al., 2024）はウェブ閲覧だけで812の長期スパンの定型タスクをカバーしており、OSWorld（Xie et al., 2024）はUbuntuとWindows上の369の実践的なデスクトップタスクをベンチマークしています。AgentBenchは環境を横断する指標を提供してくれますが、特定の環境に注力する場合は、ドメイン特化型のベンチマークに取って代わるものではありません。

表4の失敗モードの分類はおそらく最も永続的な貢献です。著者は失敗を「タスク制限超過」「フォーマットエラー」「無効なアクション」などに分解しています。これらは実装上のバグではなく、マルチターンのプレッシャーの下でLLMが状態を維持し、利用可能なアクションを追跡し、解析可能な出力を生成する方法における構造的な弱点です。本格的なエージェントシステムを構築するには、これらに対処する必要があります。

なぜこれが金融AIにとって重要なのか

これら3つの主要な失敗モードは、Beancount書き戻しエージェントを破綻させると予想される要因にほぼ直接当てはまります。

タスク制限超過は、帳簿照合（レコンシリエーション）の失敗モードです。複数口座の期末締めを照合するには、開始残高の確認、貸借の照合、不一致の特定、修正案の提示が必要であり、この一連の作業は容易に10〜20ステップに及びます。コンテキストやステップの予算を途中で使い果たして諦めてしまうエージェントは、単に失敗するだけでなく、帳簿を不完全な修正状態のまま放置する恐れがあります。

フォーマットエラーは、取引入力の失敗モードです。Beancountには厳格な構文があります。不正な形式のポスティング（通貨の欠落、誤ったインデント、無効なフラグ）はパースエラーとなり、ファイルを破損させます。Beancountの出力の周囲に説明文を生成したり、正しいように見えて形式が異なる構文を作成したりするエージェントは使い物になりません。これは、より厳格なドメインに適用されたCRITIC論文の核心的な問題です。

無効なアクションは、書き戻しの安全性に関する問題です。実際の帳簿で動作するBeancountエージェントが実行できる安全な操作は、取引の追記、フラグの修正、ポスティングの移動など、限られています。そのセットに含まれないアクション（例えば、オープンポジションが残っている口座の削除など）を捏造することは、監査まで気づかれない可能性のある正確性の欠陥です。

「コード学習が相反する影響を及ぼす」という発見も関連性があります。Beancountの書き戻しは、知識の検索よりもコード生成に近いため、コードで事前学習されたモデルは自然に適合するはずです。しかし、コード学習がマルチターン設定での対話追従能力を低下させるのであれば、導入前にそれらのトレードオフを明らかにするために、ハイブリッドな評価（AgentBenchのような手法）が必要になります。

次に読むべきもの

• WebArena (Zhou et al., 2024; arXiv:2307.13854) — 実際のブラウザ環境における812のウェブ閲覧タスク。AgentBenchのウェブ層を深化させた後継研究。
• OSWorld (Xie et al., 2024; NeurIPS 2024) — ファイルシステムやGUIタスクを含む完全なデスクトップ環境ベンチマーク。OSWorldのOS環境は、AgentBenchのOS層を直接的かつ深く発展させたものです。
• TAU-bench (Yao et al., 2024) — 実際のツール利用とユーザーシミュレーションを用いた、小売および航空会社のAPI環境でのエージェント評価。Beancountの「環境としての帳簿」設定に最も近い公開ベンチマークです。