エージェントの計画能力はどう測る？推論深度・タスク分解・自己修正の評価実践

エージェントの評価を一晩かけて回したら、正答率 94%。数字だけ見れば悪くない。ところが本番に載せてから 3 日で、ユーザーから 11 件のクレームが入った。タスクの途中で止まる、同じツールを延々呼び続ける、重要なステップをいきなり飛ばす——そんな症状が続出した。

従来の評価方法には構造的な問題がある。94% という正答率は、単発の Q&A に答えられるかどうかしか示さない。7〜8 ステップの推論が必要なタスクを最後までこなせるかは、まったく見えてこない。選択式テストだけで実務能力を測るようなもので、点数は取れても、現場では動かない。

では、エージェントの計画能力はどう測ればいいのか。なぜ正答率だけでは足りないのか。本当に問題を炙り出せる評価体系はどう組み立てるのか。本記事では、推論深度・タスク分解・自己修正の評価手法を整理し、AgentBench・ToolBench・ACPBench など主要ベンチマークを比較します。

1. なぜエージェント評価はモデル評価より複雑なのか

モデル評価は比較的シンプルです。問題を出して、答えが合っているかを見る。選択肢が A か B か、生成コードがテストを通るか、翻訳の品質——次元は多くても、ロジック自体は明快です。

エージェントは違います。Anthropic のエンジニアリングチームが 2025 年のブログで述べたように、エージェントの能力は「プロセス能力」であり、「単発能力」ではありません。測っているのは「知っているか」ではなく、「複雑な環境で一連の正しい判断を下せるか」です。

具体的には、エージェントには 6 つの中核能力が求められます。

1. ツール呼び出し能力：いつどのツールを使うべきかを判断し、パラメータを正しく渡せること
2. タスク分解能力：大きな目標を実行可能な小ステップに分解し、ステップ間の依存関係が合理的であること
3. 推論能力：マルチホップ推論を処理でき、一発勝負ではなく段階的に導けること
4. 記憶能力：これまでのコンテキストを保持し、2 ステップ目で 1 ステップ目を忘れないこと
5. 自己修正能力：失敗に気づき、方針を調整し、袋小路に突っ込まないこと
6. 長期計画能力：数十ステップに及ぶ長いタスクチェーンを、途中で破綻させないこと

従来の評価指標——正答率、F1、BLEU——はすべて単発出力向けです。エージェントに必要なのは「プロセス」の評価。ここから複雑さが生まれます。

例を挙げましょう。北京から上海への航空券を、明日午後・予算 800 元以内という条件で予約してほしい、とエージェントに頼んだとします。一見シンプルですが、実際には次の処理が絡みます。

• まず便情報を検索する（ツール呼び出し）
• 条件に合う便を絞り込む（推論能力）
• 完全一致がなければ、時間か予算のどちらを緩めるか判断する（意思決定能力）
• 便を選んだら予約 API を呼ぶ（ツール呼び出し）
• API がエラーを返したら例外処理する（自己修正）

どれか 1 ステップでも崩れればタスクは失敗です。ところが最終結果——「予約できたか」——だけを見ると、多くの情報を見逃します。便の時間がずれている、予算超過なのに問題ないと判断している、API エラー後に再試行していない、といった兆候が隠れてしまうのです。

だから eval-driven development（評価駆動開発）は、エージェント領域でこれほど重要になります。Anthropic が推奨するのは、開発段階から評価を設計し、評価結果でイテレーションを導くこと。本番投入後に初めて問題を知るのではなく、先に評価で炙り出す——その発想です。

2. エージェント計画能力評価の中核次元

計画能力の評価は、大きく 3 つの次元に分けられます。タスク分解、推論深度、長期一貫性。抽象度は高いので、順に整理します。

タスク分解能力

要するに、エージェントが大きな目標を実行可能な小ステップに分解でき、かつステップ間の関係が合理的かどうかを見ます。

この能力の中核指標は Plan Graph Coherence（計画グラフ一貫性）です。エージェントが生成したタスクステップを有向グラフとして描き、各ノードをサブタスク、各エッジを依存関係とみなします。そこで次の 2 点を確認します。

1. トポロジカルソートの有効性：合理的な実行順序が存在するか。「B の前に A が必要なのに、A の前に B が必要」というデッドロックがないか
2. 循環依存の不在：グラフに環（ループ）がないか

以前、こんな失敗例に遭遇しました。データ分析レポートの作成を依頼したエージェントが、次の計画を出したのです。

1. データ収集
2. データクレンジング
3. データ分析
4. レポート生成
5. 分析結果に基づき、データ収集を追加する

問題が見えますか。5 ステップ目が 1 ステップ目に戻るのに、前段はすでに実行済みです。エージェント自身はループだと気づかず、そこで処理が延々と繰り返されました。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

典型的なタスク分解の失敗パターンは 3 つあります。

• 循環依存：上記のように、ステップ間が環を形成する
• ステップ飛ばし：結論に直行し、重要な中間ステップを落とす
• サブタスクの不完全性：分解結果だけでは目標達成に足りない

推論深度

この次元では、エージェントが多段階の推論を処理できるかを測ります。DeepSeek-V3-0324 はマルチホップ推論テストで 91% の正答率を記録しています（同モデルの技術レポートより）。ただし「マルチホップ」とは具体的に何でしょうか。

既知の事実から出発し、N 段階の導出を経て初めて最終回答に到達する問題のことです。例えば次のようなケースです。

• 既知：A は B より大きい。B は C より大きい
• 問い：A と C ではどちらが大きいか
• これは 2 ホップの推論問題です

実際のシナリオでは、5 ステップ以上の推論チェーンが珍しくありません。「先月の売上最高製品を見つけ、その売れ筋の理由を分析して」という依頼なら、次の流れが必要になります。

1. 先月の売上データを取得する
2. ソートして最高製品を特定する
3. その製品の特徴を分析する
4. 他製品と比較する
5. 原因をまとめる

各ステップは、前ステップの結果を前提に推論を続ける必要があります。指標としてはマルチホップ推論の正答率を使いますが、ホップ数ごとに分解して見るのがポイントです。3 ホップまでは耐えられても、5 ホップで崩れる——そういう傾向がよく出ます。

長期計画の一貫性

最も問題が出やすいのがこの次元です。50 ステップのタスクを、30 ステップ目まで進めたとき、最初の文脈をまだ覚えているでしょうか。

指標は State Drift Rate（状態ドリフト率）です。長タスクの実行中に、エージェントの内部状態が期待状態と一致しなかった回数を、総ステップ数で割って求めます。

実例があります。カスタマーサポートのエージェントが返金依頼を処理していて、前半は順調でした。ところがユーザーが「違う、別の注文の話です」と言った瞬間、エージェントが混乱し、以降の会話がすべて「別の注文」に引っ張られました。ユーザーが返金したいのは、最初に話していた注文のままなのに、です。これが状態ドリフト——長い対話の途中で、最初のコンテキストのアンカーを失う現象です。

理想的な State Drift Rate は 0.05 未満、つまり 100 ステップあたり不一致は 5 回以下が目安です。実際のテストでは、多くのオープンソースエージェントが 0.15〜0.25 に達し、かなりの差が出ます。

3. 主要ベンチマークの詳細比較

エージェント評価用のベンチマークは増えていますが、それぞれ焦点が異なります。主要 4 つを詳しく見て、選び方も整理します。

AgentBench：汎用型

AgentBench は清華大学チームが ICLR’24 で発表したもので、カバー範囲が最も広いです。LLM をエージェントとして扱った総合能力を、8 つの環境で測ります。

• OS 操作
• データベースクエリ
• 知識グラフ推論
• ショッピングシナリオ
• 検索エンジン
• 家事計画
• Web ブラウジング
• 電子ゲーム

29 の主要 LLM を対象に横断比較データを提供しています。モデルのエージェント能力がどの水準にあるかを素早く把握したいなら、AgentBench の簡易版を 1 回回すだけでも十分なことが多いです。

一方で、自己修正能力はカバーしていません。「初回に正解できるか」は測れても、「間違えたあと自分で気づき修正できるか」は測れない。自己修正こそ、実運用で最も必要な能力の 1 つです。

ACPBench：推論深度の専門家

IBM の ACPBench は、計画ロジックの深度推論に特化しています。ACP は Action, Change, Planning の略で、名前が示す通りの領域です。

特徴は形式化された推論検証です。出力結果が正しいかだけでなく、推論プロセス自体が論理規則に沿っているかをチェックします。旅行計画を任せた場合、各ステップの前提条件が満たされているか、因果関係が成立しているかを検証します。

エージェントの計画・推論能力を深く掘りたいときに向いています。欠点はカバーが狭く、計画ロジック中心で、ツール呼び出しやマルチモーダルなどは対象外です。

ToolBench：ツール呼び出し特化

ToolBench は API ツール呼び出し能力を測ります。外部 API を束ねたツール型エージェントを開発しているなら、最もフィットするベンチマークです。

大規模な API-planning シナリオを提供し、次を評価します。

• 呼び出すべき API を正しく選べるか
• パラメータが正しいか
• 複数 API を連鎖させるロジックが妥当か
• API 呼び出し失敗時に適切に処理できるか

ツール利用能力の評価に、実務でそのまま使えるテストセットです。

DeepPlanning：長期計画

DeepPlanning は長期間の Agentic Planning に特化しています。他のベンチマークが 5〜10 ステップ程度のタスクなら、DeepPlanning は 20〜50 ステップ、場合によってはそれ以上のチェーンを扱います。

長期計画の一貫性を評価するときに重要です。数十ステップ後も最初の目標を覚えているか、途中で方向を見失わないか——こうした問題を炙り出せます。

選定の目安

個人的な進め方としては、まず AgentBench でベースラインを取り、エージェントのおおよその位置を把握します。そのうえで、業務で最も重要な次元に合わせて特化ベンチマークを追加します。ツール呼び出しが中心なら ToolBench、複雑な計画が中心なら ACPBench と DeepPlanning、という具合です。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

4. 自己修正能力の評価実践

この章が、記事全体の中でも特に重要かもしれません。実環境ではエージェントが常に成功するわけではないからです。問題は、失敗したあと自分で気づき、修正できるかどうか。

自己修正がなぜ重要か

数字で見ると説得力があります。Reflexion は代表的な自己反思フレームワークで、HumanEval の通過率を 80% から 91% へ引き上げました。11 ポイントの改善は小さくありません。AlfWorld では 134 課題中 130 を解決し、成功率 97% を記録しています。

"Reflexion は自己反思フレームワークです。エージェントが失敗原因を分析し戦略を調整することで、HumanEval 通過率を 80% から 91% に引き上げ、AlfWorld 課題解決率は 97%（130/134）に達しました。"

Galileo チームの別研究でも、自己反思メカニズムにより問題解決性能が 9%〜18.5% 向上したと報告されています。差は大きい。

Reflexion アーキテクチャの仕組み

中核は 4 ステップで、シンプルです。

1. 実行：エージェントがタスクに挑む
2. 反思：失敗したら、原因を分析する
3. 修正：分析結果に基づき戦略を調整する
4. 再試行：新しい戦略でもう一度試す

鍵は「反思」の段階です。単に「もう一度やる」のではなく、「なぜ間違えたのか」「どう直すべきか」を言語化できる必要があります。自分の思考プロセスを俯瞰するメタ認知能力が求められます。

自己修正能力をどう評価するか

実践的な手順を 3 段階で示します。

ステップ 1：制御可能なエラーを注入する

テスト環境で、意図的にエラーシナリオを作ります。例えば次のようなものです。

• ツール呼び出しのタイムアウト
• API がエラーコードを返す
• パラメータ形式が不正
• リソースが存在しない

エラーは再現可能にしておき、同じ条件でエージェント同士を比較できるようにします。

ステップ 2：エージェントの反応を観察する

次を記録します。

• エラー発生に気づいたか
• 原因分析を試みたか
• どんな修正戦略を取ったか
• 修正後に成功したか
• 再試行は何回だったか

ステップ 3：指標を集計する

中核指標は 3 つです。

1. リカバリー率：エラー発生後、自律的に修正して最終成功した割合
2. 平均再試行回数：エラーから成功までに要した試行回数の平均
3. 最終達成率：修正が必要だったケースも含め、最終的に完了した割合

良い評価設計は、「初回から正解」と「失敗後に修正して成功」を区別できます。前者は基礎能力、後者は自己修正能力の表れです。

具体例

あるエージェントに、データベースからユーザー情報を取得してレポートを生成するタスクを渡したとします。

初回実行では SQL が誤っており、データベースは空結果を返しました。このとき 2 パターンに分かれます。

• 自己修正が弱いエージェント：空結果のままレポートを生成し、「データなし」で埋める
• 自己修正が強いエージェント：結果が空であることに気づき、検索条件の誤りを疑って修正し、再試行する

評価は、この差を捉えるために設計します。レポートには次を分けて載せるとよいでしょう。

• 初回成功率：最初の試行で正解した割合
• 修正後成功率：修正を経て最終成功した割合
• 完全失敗率：修正後も失敗した割合

3 つの数字を合わせて初めて、エージェント能力の全体像が見えます。

5. エージェント評価体系の構築

理論はここまで。実装に移りましょう。すぐ使える 3 層評価アーキテクチャを紹介します。

3 層評価アーキテクチャ

第 1 層：基本能力層

KiloClaw - 企業向けマネージド OpenClaw、AI エージェントのオーケストレーションとスマートルーティングを加速

今すぐ始める →広告

単点スキルを個別に測ります。

• ツール呼び出しの正確性：API とパラメータが正しいか
• 小タスク分解の正確性：単純タスクを合理的なステップに分解できるか
• 単ステップ推論の正確性：1 段階の推論が正しいか

ユニットテストの発想で、各テストを独立に走らせます。

第 2 層：シナリオタスク層

実際の業務フローを模したタスクを設計します。

• 典型的な業務プロセスをいくつか用意する
• 各プロセスは 5〜15 ステップ
• 正常系に加え、修正が必要な異常分岐も含める

単点能力ではなく、能力の組み合わせを見る層です。

第 3 層：総合評価層

すべての結果を集約します。

• 各次元のスコアをまとめる
• 業務上の重要度に応じて重み付けし、総合スコアを算出する
• 可視化レポートを生成する

評価フローの標準化

再実行可能な評価体系を組むなら、次のような流れが扱いやすいです。

# 評価環境を起動
docker compose -f eval-spec.yml up --build

# 指定ベンチマークを 3 回実行し平均を取る
python run_eval.py --benchmark agentbench-v2.1 --num-trials 3

# 評価レポートを出力
python export_report.py --format markdown --output eval_results.md

「3 回繰り返す」点が重要です。エージェントの出力にはランダム性があり、1 回だけでは結果がぶれます。複数回の平均の方が信頼できます。

中核指標リスト

評価基準としてそのまま使える一覧です。

閾値は実務経験に基づく参考値です。業務シナリオによってはもっと厳しく、場合によっては緩めてもよいでしょう。

まとめ

要点は 1 つです。エージェント評価は最終結果ではなく、プロセスの質を見るもの。従来指標は「合ったか間違ったか」しか教えてくれません。エージェントには、どの経路で結果に至ったか、迂回はなかったか、失敗後に自分で立て直せたか——そうした細かい分析が必要です。

eval-driven development は、エージェント開発の標準フローになるべきです。本番後に初めて問題を知るのではなく、開発段階で評価体系を整え、データで改善方向を決めましょう。

今すぐ始めるなら、次の順番が現実的です。

1. AgentBench でベースラインを取り、現状の水準を把握する
2. 業務シナリオに合わせ、2〜3 個の特化ベンチマークで深掘りする
3. 3 層評価アーキテクチャを組み、評価フローを標準化する
4. イテレーションのたびに評価を回し、データで変化を比較する

エージェントの信頼性は「なんとなく」では測れません。評価データで判断する——本記事の手法と実践ガイドが、その足がかりになれば幸いです。

参考資料

• Anthropic Engineering: Demystifying evals for AI agents - 公式エンジニアリングブログ、2025
• AgentBench: Evaluating LLMs as Agents (ICLR’24) - 清華大学チーム、学術ベンチマーク
• Survey on Evaluation of LLM-based Agents - arXiv サーベイ、2026
• Self-Reflection in LLM Agents - Reflexion 論文
• ACPBench: Reasoning about Action, Change, and Planning - IBM 研究