Agentの計画能力をどう評価するか？推論深度・タスク分解・自己修正テストの実践ガイド

深夜3時。画面に47回目のエラー。一晩Agentを走らせた評価結果を見つめていた—94%の精度、かなり良い数字。しかし本番環境にデプロイすると、3日間で11件のユーザー苦情、全部同じ問題：タスクが途中で止まる、同じツールを無限ループで呼び出す、あるいは重要なステップを突然スキップする。

その夜、一つのことに気づいた：従来の評価手法が嘘をついていた。94%の精度は単発の質問に正答できることしか示しておらず、7-8ステップの推論が必要なタスクを完了できるかは完全に見えていない。選択式テストだけで仕事能力を判断するようなもの—高得点でも実務ができない。

その後2週間かけてAgent評価手法を研究し、多くの落とし穴を経験した。この記事で共有したいのは：Agentの計画能力をどう適切に評価するか、なぜ精度だけではダメなのか、そして本当に問題を発見できる評価システムをどう構築するか。

1. Agent評価はモデル評価より複雑な理由

モデル評価はシンプル：問題を提示、答えが正しいかチェック。選択肢AかB、コード生成がテストケースを通るか、翻訳品質—次元は多いがロジックは明確。

Agentは違う。Anthropicのエンジニアリングチームが2025年のブログで言及：Agentの能力は「プロセス能力」、単発能力ではない。テストしているのは「知っているか」ではなく、「複雑環境で一連の正しい判断をできるか」。

具体的に、Agentには6つの核心能力が必要：

1. ツール呼び出し能力：いつどのツールを使うか知っている、パラメータが正しい
2. タスク分解能力：大きな目標を実行可能な小ステップに分割、合理的な依存関係
3. 推論能力：マルチホップ推論を処理、段階的に、一発勝負ではない
4. 記憶能力：以前のコンテキストを記憶、ステップ2でステップ1を忘れない
5. 自己修正能力：エラーを発見、調整、袋小路に入らない
6. 長期計画能力：数十ステップの長タスクチェーン、途中で問題なし

従来の評価指標—精度、F1、BLEU—全部単発出力向け。Agentは「プロセス」評価が必要、事態が複雑になる。

例えば。北京から上海への航空券を予約、明日午後、800元以内。シンプルに見えるが実際は：

• 航空便情報を検索（ツール呼び出し）
• 条件一致便をフィルタ（推論能力）
• 完全一致がない場合、時間か予算を緩めるか判断（決定能力）
• 選択後予約APIを呼び出し（ツール呼び出し）
• APIエラー時例外処理（自己修正）

どのステップが失敗してもタスク失敗。しかし最終結果だけ見る—「予約できたか」—多くの情報を見逃す。便時間が違う、予算超過でもAgentはOKと思っている、あるいはAPIエラーでも再試行なし。

これがeval-driven development（評価駆動開発）がAgent領域で重要な理由。Anthropic推奨：開発段階で評価を設計、評価でAgentのイテレーションをガイド、デプロイ後に問題発見ではない。

2. Agent計画能力評価の核心次元

Agent計画能力評価は3つの核心次元：タスク分解、推論深度、長期一貫性。抽象的に聞こえる、一つずつ解説。

タスク分解能力

シンプルに、Agentが大きな目標を実行可能な小ステップに分割できるか、関係が合理的か？

核心指標はPlan Graph Coherence（計画グラフ一貫性）。どういう意味？Agent生成のタスクステップを有向グラフで描く、各ノードはサブタスク、エッジは依存関係。2点をチェック：

1. トポロジカルソート有効性：合理的な実行順序が見つかるか、「Bの前にAが必要、でもAの前にBが必要」のようなデッドループがない
2. 循環依存なし：グラフにリングがない

こんな失敗ケースに遭遇：Agentにデータ分析レポート作成を依頼、計画は：

1. データ収集
2. データクリーン
3. データ分析
4. レポート生成
5. 分析結果に基づきデータ収集補足

問題が見える？ステップ5がステップ1に戻る、しかし既に実行済み。Agentはこれがループだと気づかず、そこで繰り返し実行。

典型的なタスク分解失敗モード：

• 循環依存：上記のようなステップ間リング
• ステップスキップ：結論に直接ジャンプ、重要な中間ステップ漏れ
• サブタスク不完全：分割ステップが目標完了に不足

推論深度

この次元はAgentがマルチステップ推論を処理できるかテスト。DeepSeek-V3-0324はマルチホップ推論テストで91%精度達成、技術レポートより。しかし「マルチホップ」は具体的に何？

シンプルに、既知事実から、Nステップの導出で最終回答に達する必要。例：

• 既知：AはBより大きい、BはCより大きい
• 質問：AとCどちらが大きい？
• これは2ホップ推論問題

実シナリオでAgentは5+ステップ推論チェーンに遭遇。例：「前月売上最高製品を見つけ、なぜ売れたか分析」。このタスクは：

1. 前月売上データ検索
2. ソートで最高製品を見つける
3. その製品特徴を分析
4. 他製品と比較
5. 原因をまとめる

各ステップは前ステップ結果に基づき推論必要。指標はマルチホップ推論精度、しかし細分化：異なるホップ数の精度それぞれ。3ホップはOK、5ホップでクラッシュが多い。

長期計画一貫性

この次元が最も問題になりやすい。50ステップのタスク、ステップ30でAgentは最初のコンテキストを記憶しているか？

指標はState Drift Rate（状態ドリフト率）、計算：長タスク実行中、Agent内部状態と期待状態不一致回数、総ステップ数で割る。

実ケースを見た：カスタマーサービスAgentが返金要求を処理、全部正常、ユーザーが「いや、別の注文です」と言い、Agentが混乱、後続の全対話が「別の注文」について、しかしユーザーは実際最初の注文を返金したい。これは状態ドリフト—長対話で最初のコンテキストアンカーを失う。

理想のState Drift Rateは0.05以下、100ステップで最大5回不一致。しかし実テストでは多くのオープンソースAgentが0.15-0.25ドリフト、かなり大きな差距。

3. 主流ベンチマーク深度比較

市場にAgent評価ベンチマークが多数、それぞれフォーカスが違う。4つの主流を詳細解説、選択提案も。

AgentBench：汎用型プレイヤー

AgentBenchはTsinghuaチームがICLR’24で発表、最広カバー。LLM Agentの総合能力を8環境でテスト：

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

このベンチマークは29主流LLMをテスト、全面的な横比較データ提供。Agent能力レベルを迅速把握、AgentBench簡易版を実行すればOK。

しかし明確な欠点：自己修正能力評価カバーなし。「初回正解できるか」テスト、「エラーを発見修正できるか」はテストしない。自己修正は実シナリオでAgent最も必要な能力の一つ。

ACPBench：推論深度専門家

IBMのACPBenchは計画ロジック深度推論にフォーカス。ACPはAction, Change, Planning、名前が全部説明。

特徴は形式化推論検証。意味：出力正確さだけではなく、推論プロセス自体がロジックルールに従うか検証。旅行計画など、各ステップの前提条件が満足、因果関係が成立を検証。

適用シナリオ：Agent計画推論能力の深度テスト、最終結果だけではない。欠点：カバー範囲が狭い、主に計画ロジック、ツール呼び出し、マルチモーダルなど次元なし。

ToolBench：ツール呼び出し専用

ToolBenchはAPIツール呼び出し能力テスト。ツール型Agentを開発—外部APIを呼び出すアシスタントなど—このベンチマーク最適。

大規模API-planningテストシナリオ提供、テスト：

• 正しいAPI呼び出しを選択できるか
• パラメータが正しいか
• マルチAPIチェーン呼び出しロジックが正しいか
• API呼び出し失敗時処理できるか

Agentツール使用能力評価に非常に実用的。

DeepPlanning：長サイクル計画

DeepPlanningは長サイクルAgentic Planningにフォーカス。他ベンチマークは5-10ステップタスク、DeepPlanningは20-50+ステップタスクチェーンテスト。

長期計画一貫性評価に重要。Agentは数十ステップ後最初の目標を記憶できるか？途中で方向を見失うか？DeepPlanningで発見。

選択提案

シナリオ	推奨ベンチマーク	理由
初期迅速検証	AgentBench簡易版	広カバー、迅速レベル把握
計画能力特化	ACPBench	深度推論検証、形式化チェック
ツール型Agent	ToolBench	API呼び出し特化テスト
本番級検収	組合せ使用	マルチ次元カバー、補完

提案：まずAgentBenchベースライン実行、Agentレベル把握。その後ビジネスニーズに特化ベンチマーク。ツール呼び出しフォーカス—ToolBench；複雑計画—ACPBenchとDeepPlanning。

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

正直、この章が最も重要かもしれない。理由？実環境でAgentは常に成功できない。ポイント：エラーを発見できるか？修正できるか？

自己修正の重要性

データで語る。Reflexionは古典的自己反思フレームワーク、HumanEval通過率を80%から91%に向上。11ポイント増加、有意義。AlfWorldテストで、Reflexionは134チャレンジ中130を解決、97%成功率。

"Reflexionは自己反思フレームワーク、Agentが失敗原因を分析し戦略を調整することでHumanEval通過率を80%から91%に向上、AlfWorldチャレンジ解決率97%（130/134）達成。"

別の研究（Galileoチーム）データ、自己反思メカニズムで問題解決性能9-18.5%向上。これが差距。

Reflexionアーキテクチャ動作

核心メカニズムはシンプル、4ステップ：

1. 実行：Agentがタスク試行
2. 反思：失敗なら、Agentが失敗原因分析
3. 修正：反思結果で戦略調整
4. 再試行：新戦略で再実行

ポイントは「反思」ステップ。単純「再試行」ではなく、「なぜ間違った」「どう修正」を説明必要。Agentのメタ認知能力が必要—自思考プロセスを審視。

自己修正能力どう評価？

実践的アプローチ：

ステップ1：制御可能エラー注入

テスト環境で故意にエラーシナリオ作成：

• ツール呼び出しタイムアウト
• APIエラーコード
• パラメータフォーマットエラー
• リソース不存在

エラーは再現可能、同じ条件で異Agentを比較。

ステップ2：Agent反応観察

記録：

• Agentがエラー発生を識別できるか？
• エラー原因分析を試行したか？
• どんな修正戦略を採用？
• 修正成功したか？
• 再試行回数？

ステップ3：指標統計

3核心指標：

1. リカバリー率：エラー後、Agent自己修正し最終成功比率
2. 平均再試行回数：エラーから成功、平均再試行数
3. 最終達成率：全タスク（修正必要含む）、最終完了パーセント

良い評価設計は「初回成功」と「エラー後修正」を区別必要。前者は基本能力、後者は自己修正能力。

実例

Agentテスト、タスク：DBからユーザー情報検索しレポート生成。

初回実行、検索文エラー、DB空結果返却。2状況：

• 自己修正なしAgent：空結果でレポート生成、全部「データなし」
• 自己修正ありAgent：空結果発見、検索条件エラーか反思、修正後再試行

評価でこの差を捕捉。レポートで単独列出：

• 初回成功率：初回正解比率
• 修正後成功率：修正必要、最終成功比率
• 完全失敗率：修正後も失敗比率

3組データで完全Agent能力プロファイル。

5. Agent評価システム構築

理論終了、実践。3層評価アーキテクチャ、すぐ使用可能。

3層評価アーキテクチャ

第1層：基本能力層

単発スキルテスト、各能力単独：

• ツール呼び出し正確性：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回繰り返し」。Agent出力にランダム性、単発テスト不安定、平均値が信頼。

核心指標リスト

評価標準として使用可能表：

指標	計算方式	理想閾値	提案
Tool Call F1	トークンレベルパラメータマッチング	>= 0.92	ツール型Agent核心指標
Plan Coherence	トポロジ有効性 + 循環なし	1.0	完璧必要、循環で廃
State Drift Rate	状態不一致 / 総ステップ数	< 0.05	低い方が良い
Recovery Rate	エラー回復成功 / 総エラー数	>= 0.8	自己修正の直接反映
初回成功率	初回正解比率	>= 0.85	基本能力
最終達成率	修正込み総成功率	>= 0.95	修正能力含む

閾値は実経験の参照値。実際標準はビジネスシナリオ依存—一部は高要求、一部は緩和可能。

結論

全て語った、核心は一点：Agent評価は最終結果ではなくプロセス品質。従来指標は「正誤」を示す、Agentはより細粒度プロセス分析必要—どう結果に到達、迂回したか、エラー時調整できるか。

eval-driven developmentはAgent開発標準フローになるべき。デプロイ後問題発見ではなく、開発段階で評価システム構築、データでイテレーション方向ガイド。

今すぐ始めるなら、こう提案：

1. AgentBenchベースライン実行、Agentレベル把握
2. ビジネスシナリオに基づき2-3特化ベンチマーク深度テスト
3. 3層評価アーキテクチャ構築、評価プロセス標準化
4. 各イテレーションで評価実行、データで比較

Agent信頼性は「感覚」で判断ではなく、評価データで決定。この手法と実践ガイドでいくつかの落とし穴を回避できることを期待。

---

参考資料

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

FAQ

Agent評価と従来LLM評価の本質的違いは何？

従来評価は単発能力テスト（質問精度、コード生成品質）、Agent評価はプロセス能力テスト—ツール呼び出し、タスク分解、推論深度、記憶、自己修正、長期計画6つの核心能力含む。Agentは複雑環境で一連の正しい判断をする必要、一問一答ではない。

適切なAgent評価ベンチマークをどう選択？

シナリオで選択：

• 初期迅速検証：AgentBench簡易版（8環境カバー、29LLM比較）
• 計画能力特化：ACPBench（形式化推論検証）
• ツール型Agent：ToolBench（API呼び出し特化）
• 長サイクル計画：DeepPlanning（20-50ステップタスクチェーン）
• 本番級検収：組合せ使用、マルチ次元カバー

Agent計画能力評価の核心指標は？

3つの核心指標：

• Plan Coherence：循環依存とステップスキップ検出、理想値 = 1.0
• マルチホップ推論精度：2-5ホップ推論チェーンテスト、DeepSeek-V3-0324は91%達成
• State Drift Rate：長タスク中コンテキスト保持、理想値 < 0.05

自己修正能力をどう評価？

Reflexionフレームワークで評価、核心指標：

• リカバリー率：エラー後自己修正比率、 >= 80%必要
• 平均再試行回数：エラーから成功までの試行数
• 最終達成率：修正込み総成功率、 >= 95%必要

ReflexionはHumanEval通過率を80%から91%向上、AlfWorld成功率97%。

Agent評価システム構築ステップは？

3層評価アーキテクチャ：

• 基本能力層：単発スキルテスト（ツール呼び出し正確性、小タスク分解、単ステップ推論）
• シナリオタスク層：実ビジネスフローシミュレーション（5-15ステップ、正常 + 例外分岐）
• 総合評価層：マルチ次元指標集約、加重計算、可視化レポート

評価3回繰り返し平均値推奨、AgentBenchでベースライン確立後特化ベンチマーク追加。