Deep Research性能ベンチマーク比較｜スコアを同列に読めない理由

自律的にWebを探索して長文の調査レポートを作成する「Deep Research」製品や研究エージェントが次々と登場しています。企業のAI推進、研究、あるいはシステム調達の担当者にとって、これらの最新AIツールをどのような基準で評価し、自社の業務へ導入すべきかは極めて重要な課題です。各ベンダーは自社製品の優秀さをアピールするために数多くのテスト結果を公表していますが、そこには実務適用を考える上で注意すべき落とし穴が存在します。異なる前提条件のもとで算出されたスコアを一つの比較表にまとめ、「このモデルが一番点数が高いから優秀に違いない」と単純に判断してしまうと、導入後の実業務において期待値を大きく裏切る結果になりかねません。

では、各社が掲げる数字の背景にはどのような違いがあるのでしょうか。OpenAI BrowseComp、GAIA、FRAMES、あるいはDeepResearch Benchといった多様なベンチマークのスコアは、それぞれ一体どのような能力を測るために作られたものなのでしょうか。そして、測定している能力が異なるそれらの指標を、実務で使うための製品比較へどのように役立てていけばよいのでしょうか。

本記事では、各ベンチマークの問題形式と採点方法を整理し、公開スコアを製品選定にどう使うかを解説します。問題形式、Web検索環境、採点器、試行回数、モデル版を記録した上で、自社の業務質問を使って比較します。

本記事を読み終える頃には、これらの入り組んだ前提条件をしっかりと整理・把握できるようになります。その上で、APIの実行費用や最終的な報告品質といった実務に直結する現実的な指標を揃え、ベンダーの公表値をただ眺める段階から、自社専用の厳密な社内評価プロセスへと確信を持って歩みを進めるための判断基準を手に入れることができるはずです。

Deep Researchの「性能」は一つの点数ではない

Deep Researchと呼ばれる高度な自律型リサーチエージェントを比較する際、各社が公表するベンチマークスコアを単一の「性能」として横並びに評価してしまうケースが見受けられます。しかし、Deep Researchの性能は一つの点数で表せるものではありません。なぜなら、一口に「リサーチ」と言っても、評価に用いられるベンチマークごとに測っている能力がまったく異なるからです。

例えば、短い事実質問に対してモデルが正しい答えを返せるかという事実性を測るSimpleQAや、広範で高度な専門知識を問うHumanity’s Last Examは、モデルの知識や推論の正確性を評価します。しかし、これらは長文の調査報告を評価するためのものではなく、リサーチプロセスにおける検索過程や引用品質を直接測る設計ではありません。

一方で、正しい情報源へ到達するための行動力を測るテストもあります。GAIAは、推論、マルチモーダル、Web検索、ツール利用が複合的に求められる実世界型の質問を3段階で評価します。また、OpenAI BrowseCompは、1,266件の難しい探索問題と正解文字列を用いて、エージェントの閲覧・探索能力そのものを検証します。

さらに、複数の情報をまとめ上げる能力を測るテストも存在します。FRAMESは、複数の情報源を統合して回答を導く長文脈・検索課題を提示します。より実践的なレポート作成能力については、長文レポートの内容、引用の正確さ、完全性などを複数軸で評価する研究ベンチマークであるDeepResearch Benchや、主要なWebリサーチ製品を同一の動作環境(scaffold)に置いて評価する設計を提示した別系統のDeep Research Benchが開発されています。

このように、各ベンチマークが測る対象は大きく異なります。自社でAIエージェントの導入を検討する際は、これらのスコアを混同してはいけません。短答QAの点数と、数十ページに及ぶ調査報告書における引用精度の点数は、まったく別の指標として比較表の別列へ置くべきです。

製品の比較評価において、少なくとも以下の要素を別の測定対象として明確に定義する必要があります。

• 正答：事実や専門知識に対する単純な回答の正確さ
• 探索：複雑なWeb空間から必要な情報を探し出し、正解にたどり着く行動能力
• 引用：複数の情報源を矛盾なく統合し、正しい根拠を提示する能力
• 長文報告：レポートとしての完全性や構成力
• 費用と時間：上記を達成するために消費するAPIコストや実行時間

一つの「高いスコア」が、単純な知識の豊富さを示しているのか、それとも複雑な調査を完遂する実務能力を示しているのかを見極めることが、正しい製品比較の第一歩となります。

主要ベンチマークを問題形式で比較する

各社がアピールするスコアを実務の製品比較へ活かすためには、それぞれのテストが「どのような問題形式(分母)」を用い、「どのような方法で採点」しているのかを正確に把握する必要があります。主要なベンチマークの評価形式を整理すると、以下の表のようになります。

このように、スコアの算出基盤は多岐にわたります。例えば、BrowseCompのスコアは「1,266件」という明確な問題数の分母に対して、正解文字列にどれだけ到達できたかという合致度を示します。一方、DeepResearch Benchなどのレポート作成タスクでは単一の正解文字列が存在しないため、完全性や引用品質といった複数軸に基づくルーブリック(評価基準)を用いた採点器が稼働します。

導入担当者が異なる製品を公平に比較したい場合、単なるパーセンテージだけを追うのではなく、評価の前提条件を紐づけて管理する仕組みが必要です。具体例として、架空の社内管理ファイル「benchmark-ledger.csv」を作成し、ベンチマーク名やスコアの他に、「問題数(分母)」「許可されたツール」「正解形式」「採点器」「試行数」「日付」といった項目を必ず記録するようにします。

「製品Aは90点、製品Bは85点」という表面的な数字に惑わされず、各スコアの分母と採点方法を紐解いて記録帳へ落とし込むことで、自社の求めるリサーチ業務の性質に合致した指標を正しく選び取ることができるようになります。

公開スコアを横並びにできない条件がある

前節では、ベンチマークごとに問題形式や採点方法が異なることを見てきました。では、同一のベンチマークであれば、ベンダー各社が公表する数字をそのまま順位にしてよいのでしょうか。結論から言えば、公開スコアを横並びにして単純に順位付けをすることは適切ではありません。

OpenAIのDeep Research紹介ではGAIA、Humanity’s Last Exam、さらには内部評価の結果が示されているが、これらは製品提供者の自己評価を含むものです。OpenAI Deep Research system cardが能力や安全性評価と併せて評価条件をまとめているように、どのような環境や設定でテストが行われたかという前提条件を読み解く作業が欠かせません。

特に、Webにアクセスして情報を集めるリサーチエージェント特有の課題として、検索環境の差異が挙げられます。BrowseComp-Plusは、ライブWeb APIの動的・不透明な検索が公平性と再現性を損なうと指摘します。Webの検索結果はテストを行う時点によって変化し、利用する検索APIの仕様によっても取得できる情報が変わります。そのため、異なる環境で計測されたスコアを横に並べることは、本来フェアな比較とは言えません。

また、Alibaba DeepResearchの公式リポジトリは複数ベンチマーク結果を示しているが、これも実行設定とモデルの版を併記して読む必要があるとしています。

これらを製品比較の表に落とし込む際、架空の事例として、比較表の中に同名モデルが並んでいたとしても、スコアの公開日と検索環境が違う行は比較不能として分けるべきです。モデルのバージョン、接続している検索API、テストを実施した時点、エージェントを動かすscaffold(実行の足場となるプログラム構成)、試行回数、さらには学習データとベンチマーク問題の重複といった要素が一つでも異なれば、結果の持つ意味は大きくブレます。たとえば、OpenAI BrowseCompが用いる1,266件の難しい探索問題と正解文字列による評価において、1発勝負で出したスコアと、複数回試行した中で最も良いスコアを拾った結果とを同列に比較してはいけません。

公開スコアから候補を絞ったら、同じ資料範囲と質問で各製品を動かします。出力の引用精度、所要時間、費用を並べると、社内で使う条件に合うかを判断できます。

社内の実務質問で再評価する

公開されているスコアが横並びに比較できない以上、自社でAIエージェントの導入を検討する際、「自社で何を測れば導入判断になるか」が重要な課題となります。前節で触れた通り、リサーチエージェントはWebを自律的に探索しますが、BrowseComp-Plusが指摘するように、ライブWeb APIの動的・不透明な検索が公平性と再現性を損なう要因となります。そのため、自社の統制下で評価環境を揃え、実務に即した課題でテストをやり直すステップが不可欠です。

自社独自の評価セットを作るにあたっては、すでに社内で正解がわかっている「既知答」を用いるのが有効です。そこへ回答を導くための「根拠」が含まれているか、扱う情報の「更新頻度」はどの程度か、誤った情報を出力した場合の「失敗影響」の大きさはどのくらいか、といった実務上の観点を加味して質問を設計します。単純な一問一答ではなく、実際の業務で直面する複雑な調査要件を再現することが目的となります。

その際、公開されているベンチマークの評価設計が社内テストの基盤として役立ちます。別系統のDeep Research Benchは主要Webリサーチ製品を同一scaffoldで評価する設計を提示しており、自社でも製品間の実行環境を極力揃えるべきだとわかります。また、生成された成果物の品質をどう測るかについては、長文レポートの内容、引用、完全性等を複数軸で評価する研究ベンチマークであるDeepResearch Benchのアプローチが有用です。さらに、DeepResearch Bench IIが専門家レポートから作るrubricで調査エージェントを診断するように、自社の業務要件に基づいた独自の評価基準を設けることが推奨されます。

これを実践するための架空の具体例を挙げます。まず、自社業務に直結する20問の実務質問セットを作成します。検索環境のブレを排除するため、すべての製品に対して「同じ日」に「同じ資料範囲」を指定してテストを実施します。さらに結果の安定性を確認するため、各質問を「3回」繰り返して実行させます。出力された長文の調査レポートに対しては、自社が作成した評価基準に従い、「主張単位の引用一致を人が採点する」というプロセスを踏みます。

条件を揃えた3回の試行で、引用の一致率と結果のばらつきを見ます。業務で使えるレポートが安定して出る製品を候補として残します。

スコアと費用・再現性を一緒に記録する

前節で述べた自社業務に基づく再評価を終えた後、最終的に何を製品比較表へ載せるべきでしょうか。単純なスコアの平均値だけを並べた表では、実務における有用性や運用コストを正しく測ることはできません。導入判断を下すためには、平均だけでなく結果の分散、失敗の傾向、所要時間、トークン消費量、検索回数、そして最終的な人の修正工数までを一緒に記録する必要があります。

OpenAI Deep Research system cardが能力や安全性評価と併せて評価条件を詳細にまとめているように、スコアはその前提となる条件とセットで扱われるべきです。また、Alibaba DeepResearchの公式リポジトリが複数ベンチマーク結果を示す際にも、実行設定とモデルの版を併記して読む必要があるとされていることから、記録の粒度が重要であることがわかります。

特にWeb上の情報を扱う場合、BrowseComp-Plusが指摘するように、ライブWeb APIの動的・不透明な検索が公平性と再現性を損なう要因となります。そのため、「何度か試せば1回は良いレポートが出る」のか、「安定して実務水準の成果物を出せる」のかを見極めるため、複数回試行した際のスコアの分散や失敗パターンの記録が不可欠です。

さらに、出力物の質とコストのバランスも重要な指標です。別系統のDeep Research Benchが主要Webリサーチ製品を同一scaffoldで評価する設計を提示しているように、システム環境の条件を揃えた上で違いを測ります。品質面については、DeepResearch Benchが示すように長文レポートの内容、引用、完全性等を複数軸で評価し、さらにDeepResearch Bench IIが専門家レポートから作るrubricで調査エージェントを診断するように、細分化された基準に基づく結果を記録します。

これらを比較表へ落とし込むための架空の具体例として、社内評価用の管理ファイルであるeval-results.csvを作成します。このファイルには、各製品のタスクごとの成功率、rubricに基づく引用精度、処理が完了するまでの中央値時間、消費したトークン数と検索回数から算出した費用、そして最終的に成果物を実用に耐える水準へ引き上げるためにかかった人の確認分を保存します。

このように、品質スコアだけでなく、費用や再現性、人の手による修正コストまでを一つの記録として統合することで、自社の実務要件と予算に見合った最適なDeep Research製品を客観的に比較・選定できるようになります。

よくある質問

Q1. ベンダーの公開スコアを自社で確認する際、どのような条件に注意すべきですか

ベンダーが公表するスコアを読み解く際は、テスト時の前提条件を必ず確認してください。OpenAI Deep Research system cardが能力や安全性評価とともに評価条件をまとめているように、結果には必ず前提があります。また、Alibaba DeepResearchの公式リポジトリが実行設定と版を併記して読む必要があるとしている通り、使用されたモデルのバージョンや細かい実行設定が少しでも異なれば、結果の再現性は保証されません。

Q2. プレスリリースで発表される自己評価スコアは、製品比較にどう活用すればよいですか

ベンダーの自己評価スコアは、あくまで参考値として扱い、そのまま比較表の順位付けに使わないことが重要です。OpenAIのDeep Research紹介では、GAIAやHumanity’s Last Examの結果に加えて内部評価の結果が示されていますが、これらには製品提供者の自己評価が含まれています。自社で比較を行う際は、必ず評価条件や採点方法の違いを考慮して読み替える必要があります。

Q3. 同じテストを数日あけて実行すると結果が変わるのはなぜですか

Web検索を伴うエージェント特有の現象であり、検索環境の動的な変化が原因です。BrowseComp-Plusは、ライブWeb APIの動的・不透明な検索が公平性と再現性を損なうと指摘しています。検索エンジンが返す情報は常に更新されるため、実行する日時が変わればエージェントが取得する情報も変わり、スコアが変動する例外要因となります。自社で検証する際は同日に行うなどの統制が必要です。

Q4. 自社の調査業務に合うツールを選ぶため、どのベンチマークを見るべきですか

測りたい実務能力に合致した指標を選んでください。SimpleQAは短い事実質問で事実性を測り、Humanity’s Last Examは広範な専門知識を問いますが、これらは検索過程や引用品質を直接測る設計ではありません。実際の調査業務に近い能力を見極めたい場合は、長文レポートの内容、引用、完全性等を複数軸で評価する研究ベンチマークであるDeepResearch Benchのような指標を重視すべきです。

Q5. AIの出力結果をどの段階で人の手による確認へ戻すべきですか

エージェントが生成した調査レポートを実業務へ適用する際は、品質と引用の正確性を人が最終確認する運用を組み込んでください。確認方法としては、DeepResearch Bench IIが専門家レポートから作るrubricで調査エージェントを診断するように、自社の業務要件に基づいた独自の評価基準を用意します。架空の運用例として、出力された主張に対して引用元との一致を人がチェックし、基準を満たさないものや根拠が不明瞭な箇所を発見した条件で人の手による修正へ戻します。この際にかかる修正工数も導入可否の判断材料として記録してください。

調査手法について

こちらの記事はグラフAIリサーチプラットフォームのSnorbeを使って作られています。Snorbeは研究開発・新規事業向けの調査テーマに応じた幅広い項目のオートリサーチや、ナレッジグラフの構築、構造化レポートの生成ができるAIリサーチツールです。

Screenshot

調査したいテーマを入力するだけで、AIが深堀りすべき観点や広げるべき調査項目をレコメンドしながら、自動でリサーチを進めます。収集した情報はナレッジグラフとして蓄積され、未調査領域（ホワイトスペース）を可視化しながら調査の網羅性を高めていけます。

また、観点マトリクスを30秒・構造化レポートを10分で自動生成する機能があり、出典付きのレポートをMarkdown/PDF形式でエクスポートできます。調査の元データも保存されるため、ファクトチェックや社内共有も容易です。

ご利用をご希望の方は、こちらよりお申し込みください。

また、グラフAIを活用した社内ナレッジ管理や、研究開発・新規事業のリサーチ支援、セルフホスト導入のご相談も受け付けています。お困りの方はお気軽にご連絡ください。

冨田到

市場調査やデスクリサーチの生成AIエージェントを作っています 仲間探し中 / Founder of AI Desk Research Agent @deskrex , https://deskrex.ai

www.deskrex.ai/