Googleがエージェント評価の再考を提唱、難易度を情報量で測るDiscovery Benchを解説

Google Cloud公式ブログで、Google Data Cloudのfrontier AIチームの2名が、AIエージェントを合否のスコアで測る従来のベンチマークでは能力がどこで崩れるかが見えないと指摘しました。同チームは、質問の曖昧さを情報理論の尺度で段階的に変えるメタベンチマーク「Discovery Bench」と、その中核となる改良ループiSQRを解説しています。

Google Data Cloudのfrontier AIチームが述べた主張の要点は、次の3点に整理できます。

• 合否スコアでは能力の「崖」が見えないと指摘
• 難易度を情報量で測るDiscovery Benchを提示
• 依拠した評価ベンチマークの正解データの誤りを報告

発信主体、測定条件、Discovery Benchの位置づけと提供状態を読み分けるための整理は、次の表のとおりです。

今回の内容は、Google Data Cloudのfrontier AIチームの2名が新シリーズ「Frontier and Center」で述べたものです。Discovery Bench関連の見解・測定値は同チーム自身によるものですが、後半の先行研究節の数値・知見は各引用研究による報告であり、同チームの自社測定ではありません。

編集注によると、数週間前に公開した「Open Knowledge Format」（LLM-wikiパターンを、現代のAIシステムが必要とするメタデータ・コンテキスト・キュレーション済み知識を表す可搬で相互運用可能な形式へ形式化する仕様）のブログが大きな反響を呼び、それがシリーズ開始の契機になったと説明されています。

同チームが問題視するのは、固定のベンチマークを一度走らせてスコアを算出し、進捗を宣言する評価の進め方です。合格点は試験が教えてくれることのうち最も面白みのない情報であり、次の違いを判別できないと述べています。

• どれだけ際どく落ちたのか
• どれだけ楽に通ったのか
• 次に何を教えるべきか

必要なのは合否の答案ではなく、能力がどこでどれだけ落ちるかを示す地図だ、というのが同チームの主張です。問うべきは「エージェントは合格できるか」ではなく「質問がどこまで曖昧になったらエージェントは壊れるか」だとしています。

この地図が特に効くのは、データエージェントのデータディスカバリ、つまり多数の候補から推論に使う正しいデータセットを探す検索と取得の工程で、エージェントは推論を始める前に数千のテーブルやファイルから正しい対象を見つけなければなりません。同チームはこれを干し草の山から針を探す問題に例え、今回のブログではベンチマークへ情報理論に根ざした詳細さと解像度（fidelity）を足すことで、評価ケース自体の品質に潜む問題まで露呈したと報告しました。

検索と取得の評価ケースは、しばしば難易度の階層へ分けられます。その区分は、根深い失敗シナリオが難しいとみなされる形で自然に生まれることも、人や機械がクエリ内で提供されるcontextにもとづき「easy」「hard」とラベルを貼ることもあります。

同チームは、こうした主観（sentiment）にもとづくラベル付けが唯一の方法ではないとしつつ、再現が難しいといった欠点を抱えたまま頻繁に使われていると述べました。評価ケースを1件ずつ人手で確かめる定番の方式も、規模の面では現実的ではないという指摘です。

そこで持ち出されるのがsurprisalという情報理論の概念で、同チームはこれを、あるクエリを与えた後も「正しいデータセットはどれか」について残る不確実性を表す尺度として扱っています。識別力の高い語が加わるほど、残る不確実性は小さくなるという整理です。

評価クエリ中の語句は、対象をコーパス内の他のすべてから鋭く切り分けるときに高いinformative power（識別力）を持ちます。識別力の異なる語を足し引きすれば評価ケースの難易度そのものを動かせる、というのが手法の前提となる考え方です。

TLEを外すと崩れるKramaBenchの衛星クエリ

例として挙げられているのが、公開ベンチマークKramaBenchの衛星データの設問です。衛星48445について2024年のTLE履歴を使い、major altitude changes（主要な高度変化）の総数を求めるクエリで、このTLEというトークンがほぼ一意にTLE_____48445というテーブルを指すと説明されました。

TLEを取り除くと、クエリは「衛星48445の衛星高度の数」といった曖昧な表現へ劣化します。すると、次の候補が同じように該当してしまいます。

• 密度テーブル
• 精密軌道ファイル
• 減衰ログ

同チームの手法はこの違いをsurprisalで定量化し、まれで的を射た語ほど多くのビットを運ぶものとして扱う点が特徴です。クエリのremaining surprisalは答えについてどれだけ不確実性が残っているかを示す量で、ゼロに近づくほどクエリはデータセットを1つに絞り込めるだけ具体的になったことを意味します。

同チームが改良を重ねていると述べるDiscovery Benchは、すべての評価ケースについて「easy」寄りと「hard」寄りの変種を生成し、難易度そのものを動かすメタベンチマークです。これによって、エージェントが成功にどれだけ近いか、あるいはどれだけ遠いかを監査できるとしています。

その中心に置かれるのが、iterative surprisal-based query refinement（iSQR）と呼ぶ改良ループです。iSQRは識別力の高い語や低い語を含むケースを生成し、エージェントがどこからクエリに答え始められるかを試します。

1つの設問に1つの言い回しを固定するのではなく、同じ設問を較正された曖昧さの3段階で生成する点が特徴です。その3段階は、次のとおりです。

• high ambiguity（高い曖昧さ）
• medium ambiguity（中程度の曖昧さ）
• low ambiguity（低い曖昧さ）

較正の根拠を主観的な意見ではなくビットに置くことで、語を足したり引いたりする理由を説明できます。難易度は感覚や分類によって与えられる属性であることをやめ、こちらが設計する対象になる、というのが主張の核です。

iSQRの位置づけの原文は、Google公式ブログのiSQR（改良ループ）に関する記述で確認できます。

同チームは、再現率（recall）重視で構築したF1エージェントをGemini 3.1 Pro上に用意し、KramaBenchの曖昧さの全域を掃引しました。測定されたF1曲線は、次の表のとおりです。

なお、公式ブログは較正された生成段階をhigh・medium・lowの3段階として説明していますが、F1曲線にはneutralも掲載されています。neutralの生成方法や3段階との関係は公式ブログに説明がないため、本記事では推測を加えません。

この曲線から、従来型の評価では見えなかった2つの発見が得られたとされます。その1つ目が「崖」です。

先の衛星48445のケースは、neutralの言い回しではF1が1.00でしたが、high ambiguityでは0.00へ落ちました。識別力を持つトークンのTLEを落とすと、エージェントは目的のテーブルを完全に見失います。

同じ基礎ケース、同じエージェント、同じグラウンドトゥルースでありながら、曖昧さを一段上げただけで崖から転落する結果となり、静的なベンチマークは断崖のある場所を平地として報告してしまうと同チームは指摘しています。これらの数値は、再現率重視のエージェントをGemini 3.1 Pro上でKramaBenchへ走らせた条件に紐づく同チームの自社測定であり、公式ブログ内に第三者による再現結果は示されていません。

2つ目の発見が「スイートスポット」です。同チームのDiscovery Agentでは、medium ambiguityがneutralを上回り、low ambiguityがneutralを下回ることもありました。

具体性を上げれば単調に良くなるのではなく、誘導には最適な量があるという読みです。ただし同チームは、曖昧さが少なく文脈が多いほど検索は改善するという仮説自体は概ね成り立つとしたうえで、今回のスイートスポットは評価対象としたDiscovery Agent固有の実装上のトレードオフを浮かび上がらせたものだと注記しています。

この曲線から同チームが名指しした2つの失敗モードと観測結果を、次の表に整理します。

いずれも個別の事例に紐づく同チームの観測値であり、一般則として示されたものではありません。失敗モードの原文は、Google公式ブログの適合率の崩落とcontext blow-upに関する記述で確認できます。

同チームは、最初の評価を、分野で確立されたベンチマークであるkramabench-astronomyの上に構築したと述べています。他のチームも、すでに自分たちの評価にこのデータセットを使っていました。

各チームがこのデータセットからベンチマークを派生させるうちに、時間の経過とともに微妙な問題が入り込んだのではないか、というのが同チームの仮説です。実際に各チームが使っていたベンチマークをGeminiの助けを借りて読み込んだところ、意味のある形で誤っていた（wrong in meaningful ways）と報告しています。

同チームが挙げる、実際に見つかった破綻の内訳は、次のとおりです。

• クエリに答えていない正解データのテーブル
• 一部チームの検索APIが返せない124個のシャード
• 正確な日付が要る箇所に月だけを指定

静かに壊れたグラウンドトゥルースは、自分たちにとどまらず、それを土台にした過去の分析すべてに静かに誤った結論をもたらす、というのが同チームの警告です。ここから、評価そのものが欠陥を持ちうる成果物でありながら、それを評価する者はほとんどいないという論点が引き出されています。

この破綻は同チームが自ら読み込んだ結果の報告であり、KramaBenchの著者や第三者による確認・訂正の状況はブログに記載がありません。原文は、Google公式ブログのグラウンドトゥルースの破綻に関する記述で確認できます。

難易度を生成するなら、その生成器自体も評価すべきではないか。同チームはこの再帰的な問いを立て、同じ曖昧さの掃引を2通りの方法で構築しました。

1つは純粋なLLMの推測で誘導語を選ぶ方法、もう1つはTF-IDFによるsurprisalに接地して語を選ぶ方法です。high ambiguityにおける両者のF1の差を、次の表にまとめます。

LLM構築側の約0.34は、前節のF1曲線におけるhigh ambiguityの0.34と同じ高曖昧度側の値です。両者は激しく食い違い、どちらかの地図がひどく歪んでいるとして、同チームは接地した側のほうが頑健だと結論づけました。

surprisalが足場を与えるのに対し、自由に走るLLMにはその足場がない、というのが理由ですが、この結論は外部の正解と突き合わせて示されたものではなく、同チームの評価と判断にとどまります。そのうえで同チームは、情報理論のレンズがエージェントを連続軸で採点するにとどまらず、ベンチマーク自身の構築を採点し、2つの掃引の間を裁定するものだと位置づけました。

evaluate your evalsという行動提起と留保

同チームの行動提起は「evaluate your evals（評価を評価せよ）」です。グラウンドトゥルースを読み、難易度をラベルではなく測定量として扱って掃引し、自分のシステムが壊れるビット幅を見つけ、判定ではなく信号を生む評価を作れ、という呼びかけになっています。

同チームによれば、モデルが良くなるほどこの問題は悪化します。エージェントが粗いベンチマークを次々と突破するにつれ、スコアは上限付近で飽和し、どこを改善できるかを示す力を失うためです。

一方で同チームは、難易度をエントロピーとして扱う手法も、そのエントロピーを推定するモデルの信頼性までしか信頼できず、測れる代理指標を押し込みすぎればエージェントではなく物差しを最適化してしまうと留保しました。これは合否評価へ戻る理由ではなく、評価器を被評価対象と同じ精査の下に置く理由であり、2つの掃引が食い違った箇所はGoogle公式ブログの接地した掃引のほうが頑健だとする記述で確認できます。

同チームは、メタベンチマーキングへ向かう流れが分野全体で起きていると述べ、先行研究を3系統に分けて紹介しました。その系統は、次のとおりです。

• 項目反応理論で難易度を測定量として扱う研究
• グラウンドトゥルースそのものを監査する研究
• 曖昧さを雑音ではなく本質として扱う研究

ブログが引用する主要な先行研究と、Google Cloudブログによる要約の対応を、次の表にまとめます。

ここで注意したいのは、これらがGoogle Cloudブログによる要約であって、同チーム自身の測定結果ではない点です。MMLU-Redux原論文はMMLU設問の6.49%が「誤りを含む」と推定しており、mislabeledというブログの要約とは表現が異なります。

またPlatinum Benchmarks原論文は15の既存ベンチマークを調査し、そこから抽出したexamples/subsetsを再ラベルしてplatinum版へ再整備したと述べており、Google Cloudブログの「10データセット」とは件数も単位も異なります。AmbigQA原論文の対象はNQ-openの14,042問であり、原論文はそのうち半数超に複数の解釈があると報告しており、一般の実質問全体についての割合を直接調査した結果ではありません。

Google Cloudブログは、見かけ上のハルシネーションがモデルの失敗ではなくクエリの曖昧さに由来することが多いという後続研究の知見も紹介していますが、その出典論文を特定していないため、本記事では独立検証できない二次的な紹介として扱います。

そのうえで同チームは、情報理論による曖昧さの掃引を実運用の企業データに対するメタベンチマークとして適用した例は他に見ておらず、この組み合わせにこそ新規性があると位置づけました。引用された8件の書誌情報は、Google公式ブログ末尾の参考文献リストで確認できます。

今回の内容は製品の発表ではなく、評価のやり方そのものへの問題提起です。読みどころは、Google Data Cloudのfrontier AIチームが自ら依拠していたベンチマークの正解データを読み直し、意味のある誤りを見つけたと報告した点にあります。

本記事で紹介したF1曲線、衛星48445の崖、適合率約8%、context blow-upによるF1低下、2方式の掃引の数値は、同チームが自社ブログで報告した測定結果であり、MMLU-Reduxの6.49%など先行研究節の数値は各引用研究による報告です。自社のエージェント評価でも、合否の1点だけを見ていないか、正解データを人が最後に読んだのはいつか、質問を一段曖昧にしたときの挙動を確かめたかという3点は、Discovery Benchを使わずに手元で問い直せます。

References

本記事で事実確認に使用したGoogle Cloudブログと各研究の一次資料は、次のとおりです。

1. Google Cloud. 「Frontier and Center: Who evaluates the evaluations?」. https://cloud.google.com/blog/products/data-analytics/evaluate-agent-performance/, (公式画面表示 2026-07-11; 参照 2026-07-13).
2. Google Cloud. 「Introducing the Open Knowledge Format」. https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing?e=0.
3. Maia Polo, F. et al. 「tinyBenchmarks: Evaluating LLMs with Fewer Examples」. ICML 2024. https://arxiv.org/abs/2402.14992.
4. Kipnis, A. et al. 「metabench: A Sparse Benchmark of Reasoning and Knowledge in Large Language Models」. ICLR 2025. https://arxiv.org/abs/2407.12844.
5. 「Lost in Benchmarks? Rethinking Large Language Model Benchmarking with Item Response Theory」(PSN-IRT). AAAI 2026. https://arxiv.org/abs/2505.15055.
6. Gema, A. P. et al. 「Are We Done with MMLU?」(MMLU-Redux). 2024. https://arxiv.org/abs/2406.04127.
7. Vendrow, J. et al. 「Do Large Language Model Benchmarks Test Reliability?」(Platinum Benchmarks). 2025. https://arxiv.org/abs/2502.03461.
8. White, C., Dooley, S. et al. 「LiveBench: A Challenging, Contamination-Limited LLM Benchmark」. 2024. https://arxiv.org/abs/2406.19314.
9. Min, S. et al. 「AmbigQA: Answering Ambiguous Open-domain Questions」. EMNLP 2020. https://aclanthology.org/2020.emnlp-main.466.
10. Lai, E., Vitagliano, G. et al. 「KramaBench: A Benchmark for AI Systems on Data-to-Insight Pipelines over Data Lakes」. 2025. https://arxiv.org/abs/2506.06541.

※本記事は、Google Data Cloudのfrontier AIチームによるGoogle Cloud公式技術ブログを基に編集しています。内容はAIで確認していますが、誤りや最新情報との差異がある場合は、以下フォームよりご報告ください。

ITやプログラミングに関するコラム

• 
  【CSS】notで複数の件を除外する方法
• 
  【Git】remote設定を変更する方法
• 
  【VBA】コメントアウトを設定する方法
• 
  x86とx64の違いを分かりやすく解説
• 
  マークダウンで改行する方法
• 
  CapsLockキーを解除する方法
• 
  GitLabとGitHubの違いを解説
• 
  Linuxで環境変数を確認する方法
• 
  UbuntuのIPアドレスを確認する方法
• 
  パソコンのメモリの目安を用途別に選ぶ方法

ITやプログラミングに関するニュース

• 
  VercelがAI GatewayにSeedream 5.0 Proを追加、AI SDKのモデル指定で画像生成と編集が可能に
• 
  AWSがAmazon LocationのPlaces APIを強化、住所表記の指定と移動手段別の検索が可能に
• 
  VercelがトレースにTree・Waterfallビューを追加、ログ画面で処理の階層と所要時間を確認可能に
• 
  Googleがエージェント評価の再考を提唱、難易度を情報量で測るDiscovery Benchを解説
• 
  Google CloudがCloud Runサンドボックスを公開プレビューで提供、サービスヘルスは一般提供に
• 
  Google Cloud EMEAが英国金融の重要第三者に指定、イングランド銀行・PRA・FCAの直接監督下に
• 
  AWS DMS Schema ConversionがSQL Serverのオフライン変換に対応、ソースDBへ接続せずスキーマを変換可能に
• 
  EC2 G7インスタンスが米国東部（バージニア北部）で利用可能に、G6比でAI推論性能が最大4.6倍
• 
  SageMaker HyperPodが継続プロビジョニングでのAMIベース構成に対応、S3のスクリプト管理なしでSlurmクラスターを作成可能に
• 
  AWSがEMR on EKSでSparkトラブルシューティングエージェントに対応、失敗ジョブの原因分析を自然言語で依頼可能に