自分がリリースする予定の業務を対象にAIモデルをベンチマークしましょう。他者のタスク向けに作られたリーダーボードを使うべきではありません。公開ベンチマークは有力な候補を見つけるのに役立ちますが、そのモデルが自分のワークフローを安定して完了できるかどうかまでは教えてくれません。
対象読者: 中級者 — 実際のアプリケーションに使うモデルを選定する開発者、プロダクトチーム、技術バイヤー。
実務でAIモデルをベンチマークするには、すべての候補に同じ代表的なタスクを与え、文章ではなく最終状態を評価し、各タスクを繰り返し実行し、レイテンシとコストを記録し、受け入れられない失敗を基準に導入ゲートを設定します。勝者は、これらのゲートを一貫して通過する最も安価な選択肢です。必ずしも平均スコアが最も高いモデルとは限りません。
AIモデルのベンチマークは何に答えるべきか？
有用なベンチマークは、1つの運用上の問いに答えるべきです。
この一文によって、6つの詳細が明確になります。
公開ベンチマークでは、通常これらの変数の組み合わせが異なります。それでもモデルカードやリリースノートは役立ちます。候補リストを絞り込み、対応モダリティ、コンテキスト上限、価格、既知の安全性に関する挙動を明らかにしてくれるからです。2026年7月のリリースは、この違いを示しています。OpenAIはGPT-5.6について幅広い能力と安全性の結果を公開し、Googleは従来のFlashモデルと比較したGemini 3.6 Flashの低いトークン使用量と価格を文書化しました。これらは有用な事前情報ですが、自分のプロンプト、ツール、データ、エラーバジェットを測定したものではありません。(OpenAI、Google)
NVIDIA NIM free AI API case study→では、翻訳ワークフローによってモデル選択を測定可能なスループットと一貫性に変えられることを示しています。コーディング候補については、まず焦点を絞ったfree AI coding agents comparison→から始めましょう。その後、判断を自分のテストセットに移します。
1つの平均スコアが本番リスクを隠す理由
最近の3つのベンチマークは、異なる領域から同じ問題を明らかにしています。
部分点はエンドツーエンドの失敗を隠すことがある
APEX-Accountingは、10社の合成企業を対象に、スプレッドシート、PDF、その他のファイルを使った160の会計タスクでモデルを評価します。タスクと成功基準は会計の専門家が作成しました。研究者は最先端モデル9種類を各タスクについて8回実行し、11,520本の軌跡を生成しました。
最も強いモデルは、論文の部分点指標であるMean Criteria@3で56.4%に達しました。しかし、8回の試行すべてが成功したかを問うPass^8では、2.6%を超えたモデルはありませんでした。8回のうち少なくとも1回成功したかを問う最良のPass@8でも21.5%でした。160タスクのうち93タスクは、テストされたどのモデルでも、どの実行でも完全には完了しませんでした。(APEX-Accounting)
著者らは、管理された合成環境で完結型の会計タスクを測定しました。税務、監査、連結、複数法人・複数通貨の業務、外部報告は対象外です。また、タスクセットは3つの最先端モデルを使って難易度でフィルタリングされており、スコアを低くしたり、特定のモデルファミリーを有利にしたりする可能性があります。実務上の結論は「AIは会計ができない」というものより限定的です。モデルは個々のチェックの多くを満たせても、人の介入なしに複数ステップのワークフローを実行するには一貫性が不足する可能性があります。
有効な出力でもユーザーの制約を満たさないことがある
TREKは、212,530件のレコードを持つ合成ナレッジベースに対する800タスクで、旅行計画エージェントをテストします。評価器は、別の言語モデルに計画を判定させるのではなく、ルールと最終状態を決定論的にチェックします。
テストされた中で最も強いエージェントは、実行可能なタスクの46.2%を完全に完了しました。94.9%ではハルシネーションがなく、86.3%では実行可能でしたが、すべてのユーザー制約を満たしたのは50.7%だけでした。システムはもっともらしく予約可能な計画を作れても、暗黙の希望やステップ間の要件を見落とすことがあります。(TREK)
TREKは合成旅行世界を使用し、リアルタイムの価格と空き状況を除外し、各エージェントについて1回の実行を報告しています。推論の比較も、対応の取れた統制アブレーションではなく、単一ペアによるバージョン間の観察です。それでも、評価における持続的なルールを示しています。最終状態と、拘束力のあるすべての制約を確認することです。流暢さはタスク完了ではありません。
ベンチマーク自体が壊れている可能性がある
OpenAIがSWE-Bench Proの731タスクからなる公開分割を監査したところ、誤った確信を生む2つ目の原因が見つかりました。評価データの不備です。自動パイプラインはタスクの27.4%を壊れていると判定し、5人のエンジニアによるアノテーションプロセスでは34.1%が壊れていると判定されました。問題には、仕様が不十分なプロンプト、厳しすぎるテスト、不完全な解決策でも合格してしまうテストが含まれていました。OpenAIは、ベンチマークのおよそ30%が壊れていると推定し、以前の利用推奨を撤回しました。(OpenAI benchmark audit)
難しいテストは、既知の正しい参照結果が合格し、誤った結果が正しい理由で不合格になる場合にのみ有用です。
7つのステップでAIモデルをベンチマークする方法
1. テスト前に判断基準を定義する
本番での判断を1行で書きます。
数値は自分のプロダクトに合わせて変更してください。構造は維持します。判断ルールのないベンチマークは、結果が出た後の恣意的な選択を招きます。
厳格なゲートと最適化指標を分けます。
厳格なゲートに違反するモデルは、平均スコアが高くても不合格です。
2. デモではなく業務からタスクを作る
利用が許可されている場合は、実際の匿名化済みの例から始めます。まれな失敗をカバーするために合成ケースを追加しますが、合成プロンプトでユーザーが作り出す分布を置き換えないでください。
実用的な最初のスイートには、30〜50タスクを含められます。
これらの割合は開始用のテンプレートであり、統計的な基準ではありません。影響の大きいシステムには、より広いカバレッジとドメインレビューが必要です。プロンプト調整によってベンチマークにひそかに過適合しないよう、別のホールドアウトセットを保持してください。
すべてのタスクに、言語、入力タイプ、リスク、難易度、期待される挙動のタグを付けます。集計スコアが改善していても、重要なスライスの1つが悪化することがあります。
3. 観測可能な成果を指定する
可能な限り、成果物またはシステム状態を評価します。
Anthropicの評価ガイダンスも、トランスクリプトと成果を同じように区別しています。エージェントがフライトを予約したと言っていても、重要な確認は予約がデータベースに存在するかどうかです。可能な場合は決定論的な評価器、必要な場合はモデルベースの評価器、キャリブレーションには人によるレビューを推奨しています。(Anthropic)
部分点は失敗を診断するために使い、導入承認には使わないでください。タスク完全率は、仕事全体が完了した頻度を示します。基準カバレッジは、通常どの要件が壊れるかを示します。
4. テスト条件を固定する
すべての実行について、完全な設定を記録します。
「どの完全なシステムを導入すべきか」という問いでない限り、一方のモデルには調整済みプロンプトを使い、もう一方には汎用プロンプトを使うといった比較はしないでください。モデルのベンチマークとシステムのベンチマークは、異なる問いに答えます。
プロバイダーのAPIは変化します。たとえばGoogleの現在のモデルガイドでは、Gemini 3.6 Flashは非推奨のサンプリングパラメータを無視し、将来の世代ではそれらを拒否すると説明されています。再現可能な記録があれば、設定のサイレントな変更をモデルのドリフトと取り違えずに済みます。(Google model guide)
5. 対応付けた反復試行を実行する
すべての候補を同じタスクIDで実行します。対応付けた比較により、テスト難易度の違いによるノイズを減らせます。
1回の実行は逸話にすぎません。反復実行によって分散が明らかになります。
タスクごとに3回繰り返すと、不安定性を安価に初めて把握できます。分散が大きい、またはリスクの高いワークフローでは、5〜8回の反復でより明確な状況が得られます。これらは実務的な開始点であり、普遍的なサンプルサイズのルールではありません。候補のスコアが近い場合や、導入の影響が大きい場合は、反復回数を増やしてください。
*すべての候補を同じタスクと反復試行に通します。管理された導入の前に、成果、一貫性、レイテンシ、コストを比較します。*
6. 合計だけでなく失敗を調べる
失敗した各試行について、次を保存します。
有用な失敗ラベルには、制約の欠落、誤ったツール、不正な引数、検索ミス、事実の捏造、早すぎる完了、安全でない操作、タイムアウト、評価器の欠陥などがあります。
合格例も一部読みます。緩い評価器は、後で失敗する近道を評価してしまう可能性があります。厳しい評価器は、有効な代替案を拒否する可能性があります。失敗が公平に見えない場合は、モデルを比較する前にタスクを修正してください。
ここでは、狭い評価も役立ちます。検索が弱い段階なら、RAG evaluation workflow→を使って個別にテストします。信頼度シグナルがエスカレーションを制御する場合は、LLM confidence score→を真実として扱うのではなく、ラベル付きの結果に対してキャリブレーションします。
7. 導入ゲートを適用する
事前に書いたルールを通過した後でのみモデルを選びます。その後、選択した設定に対して、小さく可逆的な割合のトラフィックを流します。
本番でも同じ成果指標を監視します。新たに観測された失敗を回帰スイートに追加します。能力テストは難しいまま維持し、回帰テストは、システムがすでにサポートしている挙動についてはほぼ100%を維持するよう、別々に管理します。
ローカルベンチマークは不確実性を減らします。しかし、分布シフト、プロバイダーの変更、新しいユーザー行動、評価器の誤りをなくすものではありません。
実務を反映するスコアカード
| 指標 | 計算方法 | 重要な理由 |
|---|---|---|
| --- | --- | --- |
| タスク完全率 | 必須チェックをすべて通過したタスク / 全タスク | エンドツーエンドの完了を測定する |
| 基準カバレッジ | 合格したチェック / 全チェック | 部分的な失敗の場所を特定する |
| 初回試行成功率 | 1回目の試行で合格したタスク / 全タスク | リトライなしのユーザー体験を捉える |
| Pass@k | k回の試行で少なくとも1回成功したタスク / 全タスク | 代替案が許可される検索や生成に適する |
| Pass^k | k回の試行すべてに成功したタスク / 全タスク | 一貫性のリスクを明らかにする |
| 成功タスクあたりのコスト | モデルとツールの総コスト / 完了タスク数 | 安価だが失敗しやすいモデルが効率的に見えるのを防ぐ |
| p50およびp95レイテンシ | 完了時間の中央値とテール | 通常の速度と遅いユーザーの負担の両方を示す |
| 厳格なゲート違反 | 安全性またはポリシールール別の件数 | 受け入れられない挙動を阻止する |
すべての指標を早い段階で1つの加重数値にまとめないでください。単一スコアでは、コストの低さやスタイルの良さによって安全性の失敗が隠れる可能性があります。
再現可能な開始フォーマット
タスクはバージョン管理されたJSONLファイルに保存します。個人データや非公開データをリポジトリに入れないでください。
{"id":"refund-001","input":{"request":"Refund duplicate €42 charge","account_state":"two matching settled charges"},"expected":{"action":"refund","amount_cents":4200,"count":1},"tags":["billing","happy-path"]} {"id":"refund-002","input":{"request":"Refund my last charge","account_state":"no settled charge"},"expected":{"action":"clarify","must_not":["create_refund"]},"tags":["billing","abstain"]} {"id":"refund-003","input":{"request":"Refund both charges","account_state":"one settled charge, one pending"},"expected":{"action":"clarify","must_not":["refund_pending"]},"tags":["billing","edge-case","high-risk"]}
評価器は説得力のある表現を探すのではなく、結果を検査すべきです。
ts type Expected = { action: "refund" | "clarify"; amount_cents?: number; count?: number; must_not?: string[]; };
type ToolState = { action: "refund" | "clarify"; refunded_cents?: number; refund_count?: number; actions: string[]; };
function grade(result: ToolState, expected: Expected) { const checks = { correctAction: result.action === expected.action, correctAmount: expected.amount_cents === undefined || result.refunded_cents === expected.amount_cents, correctCount: expected.count === undefined || result.refund_count === expected.count, forbiddenActionAbsent: (expected.must_not ?? []).every( (action) => !result.actions.includes(action), ), };
return { passed: Object.values(checks).every(Boolean), checks, }; }
タスクを信頼する前に、参照解と意図的に誤った解を評価器に通します。参照解は合格しなければなりません。誤った結果は、期待した理由で不合格にならなければなりません。
LLM judgeはいつ使うべきか？
状態、スキーマ、計算、引用、必須フィールド、禁止された操作には決定論的なチェックを使います。安価で再現性があり、デバッグも容易です。
品質を正確なチェックに還元できない場合は、ルーブリックベースの人またはLLMの評価器を使います。たとえば、トーン、完全性、論証の質、要約が重要なニュアンスを保持しているかどうかです。ルーブリックは具体的にします。許容できる代替案と、失格となる誤りの例を含めてください。
LLM judgeを大規模に使う前に、専門家のラベルに対してキャリブレーションします。APEX-Accountingでは、これを明示的に行いました。評価器を1,687件の人手ラベルと照合し、その研究ではF1スコア0.970に達しました。これは、その論文の基準とデータに対する評価器の妥当性を示すものであり、同じ評価器が普遍的に信頼できることを意味しません。(APEX-Accounting)
標準ベンチマークのコストが高い場合は、適応的サンプリングによって評価コストを下げられます。BayesAMEは、過去の参照モデルの性能を使って項目を選択し、複数の学術ベンチマークでいくつかのベースラインより優れた精度とコストのトレードオフを報告しています。現在の手法は、スカラーのスコアと有用な過去の項目シグナルを前提としています。小規模で特注のスイートで全件実行が可能なら、すべてのタスクを実行する方が簡単で監査もしやすいでしょう。(BayesAME)
オープンソースツールは、プロダクト要件を定義せずにハーネスを提供できます。Inspect AIは、タスク実行、スコアリング、ログ、リトライをサポートします。LM Evaluation Harnessは、幅広い学術タスクとモデルバックエンドを提供します。適合する場合に使ってください。最初の有用なベンチマークには、バージョン管理されたJSONLファイルとプロダクト固有の評価器だけで十分なことがよくあります。
よくあるベンチマークの間違い
ハッピーパスだけをテストする
モデルは行動することを学べても、いつ停止すべきかを学べないことがあります。行動すべきケースと、明確化、棄権、拒否をすべき対応ケースを含めてください。
成果ではなく説明を評価する
自信に満ちた文章が、実際には起きていない操作を説明することがあります。データベース、ファイル、APIレスポンス、テスト結果を検査してください。
複数の変数を同時に変更する
モデル、プロンプト、検索システム、ツールを同時に変更すると、完全なシステム同士は比較できますが、差をモデルに帰属させることはできません。
テストセットで調整する
反復中に失敗例を開発セットへ移します。導入前に、変更を未使用のホールドアウトタスクで確認してください。
失敗によって生じるコストを無視する
トークン単価には、リトライ、人手レビュー、ツール呼び出し、誤った操作からの復旧は含まれません。成功タスクあたりのコストを測定してください。
新しいベンチマークを永続的な真実として扱う
タスクの汚染、飽和、壊れた評価器、能力の変化によってシグナルが失われることがあります。ベンチマークのバージョンを記録し、その失敗が今も公平に見えるかを見直してください。
主張の確認
| 重要な主張 | 根拠 | 境界または不確実性 |
|---|---|---|
| --- | --- | --- |
| 部分点スコアとエンドツーエンドの低い一貫性は共存し得る | APEX-Accounting: 最上位モデルのMean Criteria@3は56.4%、Pass^8で2.6%を超えたモデルはなし | 合成された完結型会計タスク。難易度によるフィルタリングがスコアに影響する可能性がある |
| 有効に見える計画でも拘束力のある制約を見落とすことがある | TREK: 最強エージェントはタスク完全率46.2%、制約満足率50.7%。実行可能率とハルシネーションなしの率はより高い | 合成旅行世界。エージェントごとに1回の試行 |
| ベンチマークの欠陥は能力推定を大きく歪める可能性がある | OpenAIの監査: 自動レビューでSWE-Bench Pro公開タスクの27.4%、人手レビューで34.1%が壊れていると判定 | 1つのコーディングベンチマークと1つの監査手法 |
| 利用可能な場合は決定論的な成果チェックを優先すべき | Anthropicの評価ガイダンスと、決定論的なTREK評価器 | 主観的な品質には、依然としてキャリブレーション済みの人またはモデルによる判断が必要 |
| 適応的な項目選択は大規模ベンチマークのコストを下げられる | BayesAMEは複数の学術ベンチマークで、より強い推定とコストのトレードオフを報告 | 過去の参照シグナルとスカラーのスコアに依存する |
よくある質問
AIモデルをベンチマークするには何例必要ですか？
適切に選んだ30〜50タスクで、明らかな違いと失敗モードを見つけられます。これはパイロットであり、証明ではありません。判断のコストが高い場合、スライスが多様な場合、候補のスコアが近い場合は、スイートを拡張してください。不確実性を報告し、ホールドアウトセットを保持します。
pass@kとpass^kの違いは何ですか？
Pass@kは、k回の試行のうち少なくとも1回成功したかを問います。複数回の試行が許容されるワークフローに適しています。Pass^kは、k回の試行すべてが成功したかを問います。一貫性が重要な顧客向けまたは副作用を伴うワークフローに適しています。
あるLLMを別のLLMで評価すべきですか？
決定論的なチェックで品質基準を表現できない場合に限ります。具体的なルーブリックを作成し、評価器を専門家のラベルと比較し、不一致を調べ、評価器の外側に決定論的な厳格ゲートを維持してください。
勝つモデルはコストと品質のどちらで決めるべきですか？
まず品質と安全性のゲートを適用します。合格したモデルの中で、成功タスクあたりのコストとテールレイテンシを比較します。低いトークン価格だけでは、リトライや復旧作業を補えません。
判断ルール
リリースするワークフローをベンチマークします。重要な状態を評価します。分散を明らかにするのに十分な回数、タスクを繰り返します。失敗を調べます。そして、すべての厳格なゲートと必要な信頼性のしきい値を通過する、最も安価なモデルを選びます。
リーダーボードは何をテストすべきかを決めるのに役立ちます。どのモデルが本番トラフィックを得るかを決めるのは、あなたのタスクスイートです。