7月23日、PostmanのZelin Wan（Postmanエンジニアリングチームによる寄稿）が「APIFlow-Bench: The Enterprise Survival Test for AI Agents」と題した記事を公開した。エンタープライズ向けのAIエージェントがAPIワークフローを実際にこなせるかどうかを評価する新しいベンチマーク「APIFlow-Bench」について詳しく紹介されている。
「答えられる」ことと「実行できる」ことは別物だ
既存のAIベンチマークの多くは、モデルが正しい答えを出せるかどうかを測る。だがエンタープライズの現場では、問題はそこではない。トークンがセッション途中で切れたとき、マルフォームなペイロードを受け取ったとき、書き込みが成功したかどうかを確認できないとき——そういった状況でも、エージェントはワークフロー全体を完走できるか。それが本当の問いだ。
ステップが増えるほど、初期の小さなミスは連鎖して増幅される。ステップ3での小さなハルシネーションが、ステップ27で本番インシデントに化ける。これが「複合エラー（compounding error）」の問題であり、既存ベンチマークが見落としてきた領域だ。
APIFlow-Benchとは何か
APIFlow-BenchはPostmanが公開したベンチマークで、公開リーダーボードと全トランスクリプトが同時リリースされた。
構成は以下のとおり：
- 7つの評価軸
- 467タスク（226の依存チェーン＋241のスタンドアロンサブタスク）
- 最大20ステップの依存チェーン
- REST APIを対象とした決定論的バリデータによるスコアリング
スコアリングには2種類の指標を使う。TGC（Task Goal Completion）は個別タスクの完了率、SGC（Scenario Goal Completion）はシナリオ全体の完了率だ。
リーダーボードの結果：現時点でどのモデルが強いか
公開リーダーボードには複数の主要モデルのスコアが掲載されている。SGC（シナリオ全体完了率）で上位に位置するのはClaude 3.7 SonnetとGPT-4oで、特にmultistep・statefulness軸でのスコア差が顕著だ。一方、error_recoveryやauthentication軸ではモデル間の差が小さく、いずれも苦手とする傾向が見られる。詳細なスコア一覧は公開リーダーボードで確認できる。
7つの評価軸：何を測るか
| 軸 | テスト内容 |
|---|---|
| authentication | セッション途中でのトークンリフレッシュ |
| discovery | 紛らわしい候補の中から正しいエンドポイントを選ぶ |
| schema | APIに拒否されたリクエストボディを修正する |
| multistep | 複数のAPIコールをまたいで状態を維持する |
| error_recovery | 適切にバックオフしてリトライする |
| pagination | 最後のページまで確実に読み進める |
| statefulness | 副作用が実際に反映されたことを確認する |
各軸はeasy / medium / hardの3難易度で出題され、単独で採点される。「ワークフローが最終的に成功したか」という1ビットの結果に折り畳まずに、どの失敗モードで詰まったかを個別に診断できる点が最大の特徴だ。
既存ベンチマークとの比較
| ベンチマーク | 依存チェーン | 終端状態評価 | 認証リフレッシュ | ページネーション | スキーマ修復 |
|---|---|---|---|---|---|
| AppWorld | ✓ | ✓ | ✗ | ✓ | ◐ |
| τ-bench | ✓ | ✓ | ✗ | ✗ | ✗ |
| BFCL v3 | ✓ | ◐ | ✗ | ✗ | ✗ |
| APIFlow-Bench | ✓ | ✓ | ✓ | ✓ | ✓ |
認証リフレッシュとスキーマ修復は、調査した既存ベンチマークのいずれも独立した評価軸として扱っていない。
タスクの作りが面白い：「壊れた状態からスタート」
タスクの設計思想が実践的だ。テスト対象のエージェントには、きれいなプロンプトではなくすでに壊れているAPIコールが渡される。たとえば認証軸のタスクはこんな形をしている：
My nightly pull keeps 401ing against the readings API after the deploy.
This call is the one that's broken:
GET /v3/stations/stn-12/readings
headers: Authorization: Bearer tk_live_OLD_session
Error: {"error":"token_expired","hint":"refresh via POST /v3/oauth/token then retry"}
Refresh auth and get me the live reading for stn-12.
I need the value and the reading ref.
実際の開発者チケットをそのまま渡すような形式だ。エージェントは「正しい答えを出す」のではなく、「壊れたワークフローを修復して完走させる」ことを求められる。
タスクはすべて合成生成：プライバシー・コスト・再現性
タスクはすべて合成生成（synthetic）で、実際のユーザートラフィックは使っていない。この設計には3つの利点がある。
- プライバシー保護：実トラフィックの再利用が不要
- スケール：手作業より大量のタスクを難易度制御しながら生成できる
- 再現性：パイプラインを再実行すれば同じタスクセットを再生成できる
アクション空間は意図的にコンパクトに抑えられており、7ツール × 5エンティティ種別の組み合わせで構成される。7ツールとはCreate・Read・Update・Delete・List・Search・Validateといった基本操作に対応するインターフェース群を指し、5エンティティ種別（Station・Reading・User・Session・Reportなど）に対してポリモーフィックに動作する。たとえば「List」ツールはStationにもReadingにも同じ呼び出し形式で使えるため、バックエンドが拡張されてもインターフェースは7種類のままで安定する。
汚染対策として、すべてのタスクヘッダーにカナリアUUIDが埋め込まれており、プライベートタスク層も別途保持されている。
採点方法：文字列マッチは使わない
採点の基本方針は「答え文字列ではなく結果を採点する」ことだ。
サブストリングチェック（期待値が最終回答に含まれているか）は一見シンプルだが、2方向で壊れる。フォーマットが違うだけで正答を不正解と判定したり、偶然の一致で不正解を正答と判定したりする。APIFlow-Benchはこれを避けるため、決定論的バリデータで終端状態を直接確認する方式を採る。
エンタープライズAIエージェント評価の現在地
現在、AIエージェントを実業務に組み込もうとする企業が増えているが、ガバナンス・セキュリティ・インテグレーション・コンプライアンスへの懸念が導入の足かせになっている。そうした中で「モデルが流暢に答えられるか」ではなく「本番ワークフローで信頼できるか」を測る客観的な指標への需要は高まっている。APIFlow-Benchはその問いに対するPostmanからの一つの回答だ。
詳細はAPIFlow-Bench: The Enterprise Survival Test for AI Agentsを参照していただきたい。
