AI ベンチマークの読み方：LLMの評価表を5分で見極める

LLMの選定でAI ベンチマークを使う目的は、次に何を試すべきかを絞ることです。SWE-bench Verifiedが測るのは、選別された500件のソフトウェア課題への対応力です。高得点だからといって、エージェントが自社の返金ポリシーを守れるとは限りません。最高スコアに目を向ける前に、課題の内容、実行条件、採点方法を確認しましょう。

2026年10月15日に、各ベンチマークの開発者が公開するページとGoogleのモデルカードで確認しました。 以下のベンチマーク解説は、各テストが何を測るかを説明するものです。具体例のスコアはGoogleの公表値であり、その読み解き方と評価のチェックリストは本記事独自のものです。

コーディングアシスタントなら、まずリポジトリやターミナルでの作業を見ます。カスタマーサービスのエージェントなら、対話中のツール利用とポリシー遵守です。文書アシスタントなら、長いコンテキストを使った推論から確認します。幅広い知識を測るスコアは判断材料になりますが、それだけで採用を決めることはできません。

AI ベンチマークは何を測っているのか？

ベンチマークが測るのは、特定のルールの下で、特定の課題群に対して発揮した性能です。知能を保証する証明書というより、競技の記録に近いものです。短距離走のタイムは有用な情報ですが、それだけで山岳救助に誰を向かわせるべきかは決まりません。

データセットには、質問や課題が入っています。評価プロトコルは、モデルに何を与え、どのような補助を認め、結果をどう採点するかを定めます。ハーネスはスキャフォールドとも呼ばれ、モデルを取り巻くソフトウェアを指します。プロンプト、ツール、処理を繰り返す実行ループなどが含まれます。

モデルの発表で「コードを書ける」と説明されたとき、この違いが重要になります。短いプロンプトから関数を書くモデルと、リポジトリを探索し、ファイルを編集し、テストを実行してエラーから復旧するエージェントでは、求められる仕事が違います。後者のスコアは、ハーネスも含めたシステム全体の成果です。

SWE-benchのリーダーボードでは、共通のmini-SWE-agent環境を使った評価など、実行条件を区別して掲載しています。自社のコーディング製品では、ツールや指示、制限が異なるかもしれません。そのスコアを自分たちの業務に当てはめる前に、モデルの周囲で何が動いていたのかを確認してください。

LLMベンチマークの比較で押さえたい評価の種類

スコアを比較する前に、ベンチマークの課題が実際の仕事に合っているかを見ます。以下は、2026年の汎用モデル、コーディング、音声関連の発表で押さえておきたい評価の系統と、その主張を読み解くためのコンテキスト評価です。各ベンチマーク名から、開発者のページまたはリポジトリに移動できます。

名前とバージョンは必ずセットで記録します。 HLE-Diamondには精査された1,000問が含まれ、確定版の初代HLEには2,500問が含まれます。Terminal-Bench 4.0では、リソースと課題が変更されました。現在のtauリポジトリには、新しいモダリティと採点の修正の両方が記載されています。新旧の数値を並べても、モデルが改善したのではなく、試験が変わっている可能性があります。

自分の業務では、どのスコアを重視すべきか？

防ぎたい失敗に近い課題を扱う評価を選びます。AI機能を選ぶ創業者、エージェントの導入を承認するCTO、サポートチケットを処理する運用担当者では、モデル発表の評価表で重視すべき行が違います。

コーディングエージェントの評価で見るべきもの

既存製品を保守する開発者は、リポジトリの修正とターミナル作業から確認するのが適切です。SWE-benchは課題解決の証拠に、Terminal-Benchはシェルで作業を遂行する能力の証拠になります。LiveCodeBenchとHumanEvalは、より限定されたプログラミング能力を確かめるのに役立ちます。ただし、どれか1つで、自社のコードベースにとって保守しやすいパッチかどうかまで測れるわけではありません。

個人開発者が、アカウント削除の処理変更をエージェントに依頼する場面を考えてみましょう。正しいヘルパー関数を書くのは、仕事の一部です。影響を受ける呼び出し箇所をすべて見つけ、権限の扱いを維持し、テストを更新し、顧客レコードの不整合を残さないことまで求められます。評価にはこの変更作業全体を含め、本番で与える予定のリポジトリへのアクセスとツールを使わせる必要があります。

選定の基準： 複数のファイルや実行手順にまたがる仕事では、候補に入れる前にエージェントとしての課題遂行能力を示す結果を求めます。関数単位のスコアは補助情報として使います。自社の事例からレビュー負担を減らせると判断できるまでは、受け入れ工程にコードレビューを残してください。

LLMの推論力を測るベンチマーク

GPQA、HLE、MMLU-Pro、AIME、ARC-AGIは、それぞれ異なる推論能力を探る評価です。特に、難しい科学や数学の問題を解く必要があるとき、何を詳しく調べるべきかを知る手掛かりになります。一方、自社の業務ルールに従えるかを直接確かめる証拠の代わりにはなりにくいものです。

GPQA Diamondの198問は、意図的に選び抜かれた科学の問題群です。社内の調査アシスタントを評価するCTOなら、この結果を候補の絞り込みに使ったうえで、自社資料を参照しなければ答えられない質問を試せます。サポート責任者であれば、ポリシーに沿ったツール利用とエスカレーションに、より注意を向けるべきです。

Humanity's Last Examは、名前が示す大きな目標と、実際に測定している能力を分けて考えます。開発者自身も、正解が定まる学術問題での成績と、自律的な研究能力を明確に区別しています。既知の解がある難問に答えられても、取り組む価値のある問題を選び、信頼できる証拠を集め、自分の誤りに気づけることまでは示していません。

長文コンテキストと音声は、それぞれ個別に確かめる

コンテキストウィンドウが表すのは容量、つまりシステムが受け取れる入力の量です。長文コンテキストの評価では、その入力を使って何ができるかを問います。検索のテストは情報を見つける力を、推論のテストは情報同士を結び付ける力を測ります。RULERの開発者は、埋もれた事実を見つけられたことだけで、長文コンテキスト全般の性能を代表させるべきではない理由を示しています。

契約書を確認する担当者にとって有用なのは、付録の例外規定と契約本文の条項を結び付け、両方を正しく引用できるかというテストです。答えが書かれていない文書、記載内容が更新で無効になった文書、矛盾する記載がある文書も含めます。各箇所を検索できていても、両立しない版の内容を自信満々に混ぜてしまえば失敗です。

音声では、聞き取り、推論、発話、会話の進行制御を分けて考えます。FLEURSは文字起こしの評価に、Big Bench Audioは音声の質問からの推論に、VoiceBenchは音声指示に応じるさまざまな課題に関わります。現在のtau系でも音声対話を評価しています。それぞれ測っているものは異なります。

電話サポートの試験導入には、背景雑音、名前、割り込み、訂正、人への引き継ぎを含めるべきです。実際のやり取りを聞き、最終的な操作も確認します。文字起こしでは正しく見えても、音声での応対がもどかしかったり、別のアカウントを更新していたりすることがあります。

LLMの性能比較は、業務の制約とセットで考える

導入判断では、業務上の制限内で受け入れ基準を満たした仕事を完了できることを、性能と定義します。回答の品質、確実に完了すること、応答時間はそれぞれ別の要件です。多くの推論処理を使うベンチマークの実行条件は、夜間に行う調査には適していても、リアルタイムのサポート対応には合わない場合があります。

導入を検討する側は、必要な課題区分と、実際の製品構成での結果を求めるべきです。運用担当者は失敗と復旧の過程を確認し、開発者は設定を再現できる必要があります。販売側が評価時の構成を示せないのであれば、そのスコアだけでは本番導入を決める証拠として不十分です。

モデル発表の評価表を5分で読み解く

新モデルを詳しく評価する価値があるかどうかは、以下の5分間の確認で判断できます。これは評価表を読む手順であり、自社アプリケーションでの安全性や有用性を確かめる時間として十分だという意味ではありません。

1. 1

   1分目：必要な仕事を明確にする

   求める成果を書き出します。リポジトリの課題を修正する、サポート依頼を解決する、文書から回答する、音声通話に対応する、といった内容です。それに近い行を選びます。関係のない分野での好成績は、導入判断から外します。

2. 2

   2分目：試験の条件を特定する

   ベンチマークの版、サブセット、言語、課題の対象期間を記録します。Diamond、Verified、オフライン、テキストのみ、ツール使用といった条件に注目してください。ラベルだけでは分からない場合は、ベンチマーク自体のページを確認します。

3. 3

   3分目：実行環境を確認する

   ハーネス、ツール、推論設定、制限時間、試行回数のルールを探します。自社製品でも同じ条件を使うのかを考えてください。検索へのアクセス、コード実行、再試行回数の増加によって、スコアが示す能力は変わります。

4. 4

   4分目：指標の意味を読み解く

   正解率は、正しいと判定された結果の割合です。F1は、返した項目のうち正しいものの割合と、必要な項目をどれだけ見つけたかのバランスを取ります。部分点では、完了していなくても進捗が評価される場合があります。誤り率は低いほど良い指標です。パーセンテージを仕事の完了率と受け取る前に、定義を読んでください。

5. 5

   5分目：誰が測定した結果かをたどる

   テストを実施したのは、モデルの開発元、ベンチマークの運営者、別の評価者のいずれなのかを確認します。表全体が同じ手順で測定されたと思い込まず、各行の注記を読みます。出典と設定を保存したうえで、自社テストに進める候補を選びます。

最後に、「関連する課題の系統で、現行版を使用し、実行条件も把握できた。自社の事例で試す価値がある」という短い判断メモを残します。そこまで書けない場合は、稼働中のシステムを変更する前に、不明な点を記録してください。

GoogleのGemini 4 Argonの評価表を読んでみる

Googleの汎用AIモデルであるGemini 4 Argonは、異なる種類の課題と採点方法が同じ表に並んでいるため、読み解き方を学ぶのに適した例です。以下は、2026年10月15日に確認した10月のモデルカードから、Googleの結果を転載したものです。本記事のために測定した数値ではなく、Googleの公表結果です。

数値は、その行の名称と注記を合わせて読みます。これらのパーセンテージは、分母も意味も共通ではありません。

BFSは幅優先探索を意味し、グラフのつながりを深さの浅い順にたどります。トークンは、モデルのコンテキスト量を測る単位であり、単語と同じではありません。

結論を出す前に注記を読む

Googleの評価方法によると、Argonは原則として思考設定を最高にし、pass@1を使用していますが、例外もあります。DeepSWEの結果にはmini-sweハーネスを使っています。Terminal-Benchでは自社で測定した結果を掲載する一方、比較対象の結果は公式リーダーボードから取得しています。GraphWalksは、各モデルの結果をGoogle自身が測定しています。OSWorldでは3回の実行の最大値を採用し、オフラインでの部分点を報告しています。

つまり、複数の評価方法が混在しており、表のすべての数値が、条件を統一した実験から得られたわけではありません。開発者が次に確かめるべきなのは、コーディング用のハーネスが、想定するエージェントに近いかどうかです。導入を検討する側なら、提案されたアプリケーション構成が、結果の裏付けとなる条件と一致しているかを見ます。運用担当者なら、その指標が仕事の完了を評価しているかを確認します。

本記事で差を計算すると、 公表されたGraphWalksのF1は、99.7から84.2を引いて15.5パーセントポイントの差になります。ただし、両行は長さの異なるサブセットを使っているため、この引き算だけで、同一問題における長さの因果的な影響を切り分けることはできません。それでも、短いコンテキストの行だけを引用すると、長い文書を扱う業務に関わる証拠が抜け落ちることは分かります。

コンピューター操作の評価でも、読み方は具体的です。部分点を「自社のデスクトップ作業を、この割合で完了できる」と読み替えてはいけません。人に作業を引き継ぐアシスタントなら、途中まで進めることにも価値があります。一方、無人で動かすプロセスには、正しく最後まで完了したことを示す証拠が必要です。

このモデルの導入判断については、Gemini 4 Argonの解説と、別記事のGemini 4 ArgonとOpus 5.5の比較も参照してください。

高スコアでも判断を誤るのはなぜか？

正当な高スコアであっても、自社が知りたいことへの答えとは限りません。大切なのは、その限界を特定し、何を確かめれば疑問を解消できるかを考えることです。

データ汚染と、特定のテストへの最適化

データ汚染とは、評価用の問題や解答が学習データに入り込むことです。その場合、モデルは未知の問題を解く代わりに、過去に見た内容を利用できてしまいます。公開テスト自体が最適化の対象になることもあります。同じ課題に対してプロンプトやスキャフォールドを何度も調整すると、未見の課題で確かめるという評価の価値が弱まります。

LiveCodeBenchは公開時期の分かる問題を使っており、評価者は学習データの期限より後に公開された課題を選べます。これは有用な設計ですが、名前に「Live」が付く結果なら汚染がないと考えてよいわけではありません。実際に使った問題の対象期間を確認してください。不自然なほど大きいスコアの上昇は、評価手順を調べるきっかけとして扱い、不正の証拠とはみなしません。

自社評価では、プロンプト調整に使わないホールドアウト用の事例群を確保します。失敗例を開発用の事例に取り込んだら、ホールドアウトには新しい事例を補充してください。そうしないと、よく知っている例には非常に強くても、それ以外では崩れやすいシステムになりかねません。

スキャフォールド次第で、比較しているシステムが変わる

モデルを動かす仕組みは重要です。検索、ファイル操作ツール、再試行、丁寧に書かれた指示を備えるモデルは、単発のプロンプトに答える同じモデルとは、導入するシステムとしては別物です。スキャフォールドの改善は価値のある技術的進歩ですが、その成果をすべて基盤モデルの能力に帰すと判断を誤ります。

モデルを変えた影響だけを切り分けたいなら、共通のハーネスを使います。完成した製品同士を選ぶなら、製品全体を評価します。問いが違えば、結論が異なることもあります。

ベンダーの測定結果と、独立した再現結果を区別する

開発元の結果は、方法が明確なら有用です。ベンチマーク運営者の結果も、比較の目的に合う構成なら役立ちます。どちらの肩書きも、プロトコルを読むことの代わりにはなりません。リーダーボードへの提出結果と、共通条件の下で独立に再実行された結果は区別してください。

プロンプト、モデル識別子、ハーネス、採点方法、除外条件、不確実性を確認します。ばらつきの情報が十分でない小さな差を、移行の決め手にするべきではありません。結果が掲載されていないことは、証拠がないという意味であり、自動的にゼロ点を意味するわけではありません。

集計方法も確認してください。全体平均には、評価者が選んだ課題と重み付けが反映されています。自社のサポート依頼には、その平均にはほとんど影響しない例外ケースが大量に含まれているかもしれません。無関係なベンチマークのパーセンテージを平均して、独自の知能スコアを作らないでください。

採点が適切でも、測る成果がずれていることがある

ユニットテスト、正解データ、モデルによる判定、人間の好みは、それぞれ異なるものを評価します。テストの網羅性が足りず、不具合を見逃す場合もあれば、正解データ自体に誤りがある場合もあります。モデルによる判定では、正しい操作より、よどみない説明が好まれることもあります。好みによる勝敗が測るのは、その手順で回答者が何を好んだかです。

現在のtauリポジトリには、課題と採点の修正が記録されています。修正によって評価は改善されますが、同時にバージョンの管理が欠かせなくなります。テストは保守される測定の仕組みであり、疑う余地のない真実ではありません。

自社の評価が必要になるのはいつか？

判断が自社のデータ、ポリシー、ツール、ユーザー、許容できる失敗の程度に左右されるなら、自社で評価を行います。公開スコアは、有望な候補を見つけるには十分です。しかし、顧客レコードを変更したり、非公開文書を基に回答したりするエージェントの導入を承認するには不十分です。

すぐ検証に進むべきなのは、 関連するベンチマークの改善が、現行システムで把握している失敗に対応している場合です。その失敗の種類について、条件をそろえて比較します。移行を待つべきなのは、 改善した課題が自社の仕事と無関係な場合や、公表された実行環境を自社製品で使えない場合です。現行システムを維持すべきなのは、 すでに受け入れ基準を満たしており、新候補に業務上の改善が確認できていない場合です。

中堅企業のサポートチームなら、試験導入の出発点として50件を用意する方法があります。通常の依頼を20件、ポリシーの例外を10件、入力の欠落や矛盾を10件、権限やエスカレーションに関する事例を10件です。これは設計例としての件数であり、このサンプルで導入判断に統計的に十分だと主張するものではありません。最終的な件数は、検出したい失敗率や差に合わせて決めます。

候補を試す前に、何を成功とするかを定義します。返金の事例なら、適用条件を正しく判定し、対象アカウントと金額を間違えず、権限のない操作をせず、分かりやすく説明することが求められるでしょう。エスカレーションの事例は、依頼を自力で解決できなくても、正しく引き継げれば合格にします。

各候補を、実際に使う予定のプロンプト、検索、ツール、権限で動かします。最終メッセージだけでなく、処理後のレコードと操作履歴を確認してください。結果が安定しない事例は繰り返し、応答時間は別に記録し、判定が食い違う事例は改善を宣言する前に見直します。最終判断には、ホールドアウト用の事例群を残しておきます。

Promptfooは、テストケースとアサーションを使い、プロンプト、モデル、アプリケーションを比較する評価ツールです。ドキュメントでは実行の仕組みを、本サイトのPromptfooレビューでは、その用途と自分たちで責任を持つべき部分を解説しています。

選択されたアカウントや禁止操作の有無など、直接確認できる事実には、判定が一意に決まるチェックを使います。説明に不足がないか、根拠があるかなど、判断が必要な品質には評価基準表を用意し、人が付けたラベルに照らして調整します。LLM-as-a-judgeのガイドでは、この採点の仕組みと失敗のパターンを扱っています。

週明けに着手すること： 業務フローを1つ選び、受け入れ基準を書き、直近の事例を集めます。そのうえで、現行システムと候補1つを同じ条件で比較します。導入の判断は、ユーザーにとって重要な成果と失敗に基づいて行ってください。

ベンチマークの評価表でよくある疑問

代表的なLLMベンチマークには何がありますか？

まず、評価の系統を押さえます。コーディングエージェントにはSWE-benchとTerminal-Bench、学術的な質問にはGPQAとHumanity's Last Exam、対話中のツール利用にはtau系があり、長文コンテキストと音声にはそれぞれ別のテストがあります。スコアは版と設定を付けて扱ってください。

コーディングに最適なLLMベンチマークはどれですか？

仕事に最も近いベンチマークを使います。SWE-benchはリポジトリの課題解決、Terminal-Benchはターミナル作業、HumanEvalは関数生成を扱い、LiveCodeBenchには公開時期が分かる競技課題が含まれます。その結果を自社に当てはめられるかは、自社リポジトリでの変更作業によって判断します。

LLMベンチマークのデータセットとは何ですか？

データセットは、質問や課題を提供するものです。ベンチマークの結果を比較するには、プロンプト、ツール、制限、試行回数、採点方法といったプロトコルも必要です。同じデータセット名を使っているだけでは、結果同士を比較できるとはいえません。

AIの評価と導入に関する実践的な情報は、ニュースレターに登録してお受け取りください。