OpenRouter、LLM向けWeb検索の総合ベンチマークを公開　検索回数の増加が精度向上に最も寄与と報告

要点

• OpenRouterは、AIモデルとWeb検索エンジンの組み合わせによる精度・コスト・速度を評価するライブベンチマークを公開した。

• 検索の試行回数上限（検索バジェット）を1回から25回へ増やすことが、品質改善において最も大きな効果を持つことが明らかになった。

• 検索回数を1回に制限した場合、モデルが追加の推論処理を行うことで、かえって応答時間が長くなる現象がOpenAI製モデルなどで確認された。

• 検索エンジンの違いによる精度差（平均10ポイント）よりも、モデル自体の性能差（平均15ポイント）の方が結果を大きく左右することが示された。

• 正解できない問題ではモデルが検索上限まで試行を繰り返す傾向があり、失敗率の高いタスクではコスト増のリスクとなる。

• 米OpenRouterは2026年8月12日、大規模言語モデル（LLM）と各種Web検索機能を組み合わせた際の性能やコストを多角的に比較・可視化するライブベンチマークページを公開した。モデル、検索エンジン、検索手法、検索回数（バジェット）の4要素を組み合わせ、複数の評価データセットを用いて継続的に測定しているという。

4つの評価軸とテスト設計

OpenRouterの発表によると、LLMにWeb検索を行わせる際の設定は主に「利用するモデル」「検索エンジン」「検索手法」「検索バジェット」の4つの選択肢に分かれる。

検索エンジンとしては、OpenAIやAnthropic、Googleが提供するネイティブ機能に加え、Exa、Parallel、Perplexityといったサードパーティ製エンジンを選択できる。また検索手法には、プロンプト投入前に検索結果をコンテキストとして渡す方式と、モデル自身が必要に応じて検索ツールを呼び出す方式がある。後者のツール方式では、モデルに許可する検索回数（1回、5回、25回など）をバジェットとして制御可能だ。

これらを評価するため、同社は以下の4つのベンチマークを継続的に実行している。

• BrowseComp: 実際のWebブラウジングを必要とする難度の高い事実調査タスク
• DeepSearchQA: 複数の情報源を横断して調べるリサーチタスク
• WideSearch: 表形式の空欄を網羅的に埋めるような広範囲の情報収集タスク
• HLE: 検索を伴う専門家レベルの試験問題

各ベンチマークでは品質、コストパフォーマンス、応答速度の観点からランキングがリアルタイムに更新される仕組みとなっている。

検索バジェットの増加が精度を大きく押し上げる

公開された検証データにおいて、モデルの出力品質に最も強く影響を与えた要素は「検索バジェット（許可された検索回数）」の拡大だったという。

事実調査タスクであるBrowseCompをPerplexityエンジン経由で実行したテストでは、検索回数を1回から25回に増やした結果、Claude Opus 5（high）のスコアは35.8%（0.14ドル）から89.0%（0.99ドル）へ、GPT-5.6 Sol（high）は46.3%（0.20ドル）から82.4%（0.50ドル）へ、GPT-5.6 Luna（extra-high）は33.7%（0.02ドル）から74.0%（0.10ドル）へと大幅に上昇した。

同社はこの結果について、検索回数を1回から25回に増やすことで、コストの上昇を2.5倍〜7倍程度に抑えつつスコアをほぼ倍増させることが可能であり、最もコスト効率良く精度を高めるアプローチであると説明している。

応答速度の逆転と「失敗時の検索過多」によるコストリスク

検索回数の上限を増やすと処理時間が一律で延びると思われがちだが、データ上では逆の現象も観測された。GPT-5.6 Lunaでは、1回検索時の応答時間が1問あたり140秒だったのに対し、25回検索時では111秒に短縮された。1回と5回の両方で計測した35パターンのうち3分の1以上で、検索回数が少ない方が低速になる結果となり、これらはすべてOpenAI製のモデルだったという。検索回数が厳しく制限された環境において、モデルが不足した情報を補うために追加の推論処理を長く行ったことが原因とされている。

一方で、検索回数の拡大にはデメリットも存在する。比較的容易なタスクや、正解に到達できない難問においては、コストが跳ね上がるリスクがある。

正解時と不正解時における平均検索回数を比較したデータでは、いずれのベンチマークでも不正解時の方が多くの検索回数を消費していた。例えばBrowseCompでは正解時の平均検索回数が10.3回だったのに対し、不正解時では19.7回に達した。モデルが答えを見つけられないまま検索バジェットを使い切るまで探索を繰り返すためであり、WideSearchでは最大で81回の検索を試行した末に不正解となったケースも記録されたという。

エンジンの違い以上にモデル自体の性能が寄与

バジェットを25回に設定した状態での比較では、検索エンジンの選択よりも、土台となるモデルの選定が精度に大きな影響を与えることが判明した。

BrowseCompにおいてモデルを固定して検索エンジンを変更した場合、スコアの変動幅は平均10ポイントだった。これに対し、最先端のフロンティアモデルとコスト効率重視のモデルとの間には平均15ポイントの性能差が生じた。エンジンごとの利用コストのばらつきもフロンティアモデルほど顕著で、最も高価なエンジンと安価なエンジンの間で最大2.5倍の開きが出たとしている。

OpenRouterは、これらのベンチマーク結果は候補を絞り込むための基準であり、実際のワークロードやタスクの難易度に応じた最適な構成の検証が重要であるとしている。