エージェントの評価は「成功率」だけでは足りない：pass^k、手順数、費用の測り方を、Anthropic・OpenAI・論文で確かめる

3行でいうと

エージェントは、同じ課題でも毎回結果が変わります。Anthropicの解説は、1つの課題を複数回（試行）やり、「1回でも成功する確率（pass@k）」と「毎回成功する確率（pass^k）」を使い分けるよう書いています。1回あたりの成功率が75%でも、3回連続で成功する確率は約42%です。
手順数（ターン数、道具の呼び出し数）、トークン数、遅さは、成功率とは別に記録できます。Kapoorらの論文（arXiv:2407.01502）は、精度だけでなく費用も合わせて見ないと、結論を誤ると主張しています。
評価そのものも壊れます。Anthropicの解説は、採点や課題の不具合を直し、枠組みも制約の少ないものに変えたら、42%だった点数が95%になった例を挙げています。点数だけでなく、実際の記録（トランスクリプト）を読むよう勧めています。

この記事では、まだ評価を組んで確かめていません。この記事は、公式の文書と論文の要旨・ページを読んでまとめたもので、実際に使って確かめた記録ではありません。情報は2026年10月16日に確認し、10月22日に読み直しました。変わることがあります。

先に結論

エージェントの評価では、「答えが合っていたか」の前に、「何を1回の試行とし、何を成功とするか」を決めます。Anthropicの解説は、「結果（outcome）」を試行の終わりの環境の状態と定義しています。言葉でなく、環境の状態で見る、という考え方です（僕らの読みです）。
数は3種類に分けて持つと整理しやすいです。成功率（何回やって何回成功か）、手順数（何ターン、道具を何回呼んだか）、費用と遅さ（トークン、時間）。これはAnthropicの記録項目と、SWE-benchの表示項目を読んだ、僕らの整理です。
評価の道具や基準は、評価対象と同じくらい点検が要ります。0%が続く課題は、エージェントの失敗でなく課題の不具合であることが多い、とAnthropicは書いています。

前提：言葉の整理

Anthropicの「Demystifying evals for AI agents」（2026年1月9日公開）は、まず言葉を定義しています。僕らの言葉で言い換えます。

言葉	意味
課題（task）	入力と成功の基準が決まった、1つのテスト
試行（trial）	1つの課題に対する、1回の挑戦。結果が毎回変わるので、複数回行う
採点役（grader）	成績を付ける仕組み。1つの課題に複数付けられる
記録（transcript、trace）	試行の全記録。出力、道具の呼び出し、考え、途中の結果を含む
結果（outcome）	試行の終わりの環境の状態
評価の実行環境（evaluation harness）	課題を並べて走らせ、記録し、採点し、集計する土台
エージェントの枠組み（agent harness）	モデルがエージェントとして動けるようにする仕組み

最後の2つの違いは大切です。解説は、「エージェントを評価する」とは、モデルと枠組みを合わせて評価することだ、と書いています。同じモデルでも、枠組みが違えば点数が変わります。

自分用の評価（evals）を10問から始める方法や、変更のたびに回して回帰を見張る方法は、別の記事で扱っています。この記事は、エージェントに特有の測り方に絞ります。

成功率：1回の成功と「毎回の成功」は別物

Anthropicの解説は、結果が毎回変わるので、課題ごとに複数回の試行を行う、と書いています。そのうえで、2つの指標を挙げています。

pass@k。 k回のうち、少なくとも1回成功する確率です。kを増やすと上がります。
pass^k（パス・ハット・ケー）。 k回のすべてが成功する確率です。kを増やすと下がります。

解説の数字の例です。1回の成功率が75%で、3回行うと、3回とも成功する確率（pass^3）は、0.75の3乗で約42%です。k=1ではどちらも同じ値で、kが10になると、pass@kは100%に近づき、pass^kは0%に近づく、と書かれています。

僕らの補足です。この計算は、各回が独立で、成功率が一定だと仮定しています。同じ条件でk回やれば、pass@3は1から0.25の3乗を引いた約98%になります（僕らの計算で、公式が書いた数字ではありません）。同じ75%のエージェントが、「3回のうち1回でも成功すれば十分な仕事」では約98%、「3回とも成功してほしい仕事」では約42%に見えます。どちらの指標が自分の仕事に合うかで、同じエージェントの評価が大きく変わります。

pass^kは、τ-bench（タウ・ベンチ）という論文で提案された指標です。arXivの要旨によると、τ-benchは、AIがユーザー役のAIと会話しながら、領域ごとの道具（API）と規則に従って仕事をする場面を模擬します。採点は、会話の終わりのデータベースの状態を、正解の状態と比べて行います。結果として、gpt-4oのような関数呼び出しのエージェントでも、成功は課題の半分未満で、小売の領域ではpass^8が25%を下回る、つまり同じ課題を8回やって毎回成功するのは4分の1に満たない、と書かれています。要旨には、pass^kの正式な定義は載っていませんでした。

手順数・費用・遅さ：成功率と別に測る

Anthropicの解説の例には、記録から取れる数として、n_turns（ターン数）、n_toolcalls（道具の呼び出し数）、n_total_tokens（トークンの合計）、遅さとしてtime_to_first_token（最初の1語まで）、output_tokens_per_sec（1秒あたりの出力）、time_to_last_token（最後まで）が出てきます。本文には、固定した課題の集まりで、遅さ、トークン、課題あたりの費用、エラー率を追える、とも書かれています。ただし、例の設定に費用の項目はありませんでした。

この3つが別々に必要な理由を、論文が主張しています。Kapoorらの論文（2024年7月1日にarXivへ投稿。arXiv:2407.01502）の要旨は、エージェントの評価が精度ばかりを見ていることで、最先端のエージェントが「必要以上に複雑で高価」になり、精度の向上がどこから来たかを誤解させる、と書いています。対策として、費用と精度を同時に最適化する見方を提案しています。要旨には、具体的な数字は載っていませんでした。

SWE-benchの公式ページは、実際の見せ方の例です。ページには、通常の「解決した割合（% Resolved）」のほかに、費用に対する解決数、平均の費用、費用の上限、手順の上限、費用と手順の累積の分布、といった表示があります。ただし、具体的な費用や手順の上限の値は、読んだ範囲に出ていませんでした。「Bash Only」の表示は、全モデルが同じmini-SWE-agentの環境で動く標準化された見方（500問）と説明されています。

見立てです。同じ点数なら、手順が少なく、安く、速いほうがよいエージェントです。逆に、点数が少し高くても、手順や費用が何倍にもなるなら、使う場面で割に合うかは別問題です。そのために、成功率の表と一緒に、1課題あたりの手順数、トークン、時間の分布を並べて見ると、判断しやすいと思います。

採点：道筋ではなく、結果を見る

Anthropicの解説は、採点役を3種類に分けています。

種類	強み	弱み
コードによる採点（文字の一致、テスト、道具の呼び出しの確認など）	速い、安い、客観的、再現しやすい	正しい別解に弱く、細かい判断ができない
モデルによる採点（基準表、比較、複数の判定役の合意など）	柔軟で、自由な出力にも使える	結果が揺れ、費用がかかり、人間との照合が要る
人による採点（専門家の確認、抜き取りなど）	質が高く、モデル採点の較正に使える	高く、遅い

さらに、次の点が書かれています。出力を採点するのであって、決まった手順を取ったかどうかを採点するのではありません。複数の部分からなる課題には部分点を付けます。モデルの判定役には「わからない」の選択肢を与えます。観点ごとに別の判定役を使います。

一方、OpenAIの「Evaluate agent workflows」のページは、エージェントの途中経過を採点する流れを書いています。トレース（モデル呼び出し、道具の呼び出し、ガードレール、引き継ぎの端から端までの記録）に、採点役を当て、道具の選び方、引き継ぎが必要な場面で行われたか、規則違反があったか、といった観点で見ます。ダッシュボードのLogsからTracesを開き、採点役を作って走らせ、結果で指示文や道具の設計を直し、そのあと、繰り返し測れるデータセットと評価の実行に進む、という順序です。このページには、採点役の種類や数字は書かれていません。

2つを並べると、Anthropicは「結果を主に見る」、OpenAIは「記録を見て、途中のどこで間違えたかを探す」という強調の違いがあります。僕らは、両方を使う前提で読みました。結果で成否を決め、記録で原因を探す、という分担です。

評価の土台を疑う

Anthropicの解説で、僕らがいちばん参考になると感じたのは、評価そのものが壊れていた例です。

CORE-Benchで最初42%と出ました。調べると、硬すぎる採点、課題の指示のあいまいさ、再現できない課題が見つかりました。これらを直し、制約の少ない枠組みに変えると、点数は95%になりました。
各試行は、きれいな環境から始めるよう勧められています。共有の状態があると、失敗が連動したり、点が水増しされたりします。例として、エージェントが前の試行のGit履歴を見て有利になった、と書かれています。
多くの試行を重ねても0%の課題は、エージェントが無能なのではなく、課題が壊れている印であることが多い、とあります。参考の解答（その課題が解けることを示すもの）を用意するよう勧められています。
解説は、評価の飽和（解ける課題をすべて解いてしまう状態）にも触れています。SWE-bench Verifiedが80%を超えて飽和に近い、とあります。飽和した評価は、退化を見つけるのには使えても、改善を示せなくなります。

これらに基づく運用として、解説は、実際の記録（transcript）を読むことを勧めています。失敗が、エージェントの誤りなのか、採点の誤りなのかが、点数だけでは分からないからです。

Anthropicの解説にある採点設定の例と、始め方の数字

解説のYAMLの例は、課題ごとに採点役を並べる形です。

場面	採点の項目（例）
コードのエージェント	テストが通ること、品質の基準表によるモデル採点、静的解析（`ruff`、`mypy`、`bandit`）、必要な道具を呼ぶこと
会話のエージェント	必要な道具（`verify_identity`、金額が100以下の`process_refund`、`send_confirmation`）、`max_turns: 10`

会話の評価では、ユーザー役を別のモデルにやらせることが多い、とあります。

始め方の目安は、20〜50の課題です。

なお、OpenAIの「Working with evals」のページには、OpenAIのEvals基盤が2026年10月31日に読み取り専用に、11月30日に終了する予定と書かれていました。新規にはDatasetsが代わりに案内されています。

この記事は、実際に使って確かめた記録ではありません。

見立て：最小の記録の形

ここからは、公式の記載を読んだうえでのこの記事の見立てで、動作確認はしていません。1つの試行ごとに、次の項目を行として残すと、上の話をすべて同じ表で見られます。

項目	目的
課題ID、試行番号	pass^kの集計（同じ課題をk回）
結果の合否	環境の状態で判定（言葉でなく）
ターン数、道具の呼び出し数	手順の増減を見る
トークン数、時間	費用と遅さを見る
失敗の分類（エージェントか、課題か、採点か）	記録を読んだ結果を、あとで集計する

pass@kとpass^kの両方を出し、手順数と費用の分布（平均だけでなく、重い試行の上位）も出します。点数が変わったら、先に記録を数件読みます。

気をつけること

この記事では、どの評価も組んでいません。内容は公式の文書と論文の要旨・ページを読んだ範囲です。
WebFetchは要約を返します。数字や用語は要約の記載で、文言は言い換えています。要約に混じっていた推論は、事実として使っていません。
τ-benchとAI Agents That Matterは、arXivの要旨だけを読みました。論文の本文や、pass^kの定義の式は読んでいません。
OpenAIの2つのページ（agent evalsとtrace grading）は、採点役の種類や数字を書いていませんでした。「ない」とは断定できません。
SWE-benchのページは、費用と手順の上限の値を、読んだ範囲では出していませんでした。
Anthropicの解説は、自社の経験にもとづく記事です。種類ごとの助言がありますが、ここでは主に共通する部分だけを使いました。
「手順数が少ないほどよい」という見方は、僕らの見立てです。公式の文書が一律にそう書いているわけではありません。
点数や仕様は変わることがあります。

出典

更新履歴

2026年10月25日 書き方を直しました。
- 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した
2026年10月22日 公式の資料を読み直しました。書いてあることに変わりはありませんでした。