前提整理:APIの検索ツールと検索画面は別物である
生成AIのAPIで得られる検索結果と、ブラウザの検索画面で見える結果が食い違う。この違和感の多くは、そもそも両者が返している成果物が別物だという前提を共有していないことから生まれます。まずは公式ドキュメントに書かれている定義を確認しておきます。
Gemini APIのグラウンディングはモデルが判断する多段フロー
Gemini APIのGrounding with Google Searchは、単に検索APIを叩いてリンクを取得する仕組みではありません。公式ドキュメントによれば、プロンプトを受け取ったモデルが「検索がこの回答改善に有効か」を自ら分析し、必要と判断した場合のみ1つまたは複数の検索クエリを自動生成して実行、その結果を統合したうえで出典付きの回答を返す、という多段のフローとして説明されています。つまり、同じ質問を投げても、モデルが検索を必要と判断しなければ検索は走らず、必要と判断すれば複数回の検索が行われることもあります。モデルの知識カットオフを超えたリアルタイムのウェブ情報に基づく回答と、検証可能な出典の提示を目的とした機能と位置づけられています(Google AI for Developers)。
OpenAIのウェブ検索は複数のツール・モデルが提供されている
OpenAIのAPIでは、用途に応じて複数のウェブ検索の実装が用意されています(OpenAI API公式ドキュメント)。代表的なものを整理すると次のとおりです。
- Chat Completionsの検索対応モデル:`gpt-4o-search-preview` などの検索特化モデル。検索が組み込まれた応答を返す
- Responses APIの `web_search_preview` ツール:シンプルなウェブ検索。filters等の高度設定は非対応
- Responses APIの `web_search` ツール:ドメイン制限などのfiltersや詳細なオプションに対応した新しい版
- Deep Research:多数の情報源を横断して数分かけて調査を行う別系統のツール
同じ「ウェブ検索」と呼ばれていても、モデル・ツール・設定によって挙動が異なるため、上位結果に近い応答が返るものと、思考の中で何度も検索し直して統合するものでは、最終的に手元に届く情報の中身が一致しないのは当然だと分かります。
順位付きリンク一覧と生成された回答は比較対象が違う
検索画面が返すのは、順位が付いたリンクの一覧です。対してAPIが返すのは、モデルが取得情報を統合して生成した文章と、それに紐づく出典です。前者は「候補の並び」、後者は「候補を読み込んだ末の要約と根拠」であり、出力形式そのものが異なります。したがって、検索画面の1位のサイトがAPIの回答に出てこないという事象は、それ単体では不整合とは言えません。差の原因を切り分けるには、この定義の違いを出発点に置く必要があります。
差を生む要因を分解する:検索コンテキスト量・ドメイン制限・取得経路・地域指定
APIと検索画面の出力がずれる原因は、抽象的な精度差ではなくパラメータの仕様そのものに宿っています。ここでは公式仕様に基づき、差の発生源を4つの軸に分解します。
1. 検索コンテキスト量:件数は保証されない
OpenAIのweb searchでは`search_context_size`をlow/medium/highの3段階で指定し、検索結果からモデルへ渡す文脈量を調整できます(mediumがデフォルト)。ただし公式ドキュメントは、これが正確なトークン数や出典・引用の件数を保証するものではないと明記しています。つまりhighにすれば必ず出典が増えるわけではなく、同じ設定でも参照範囲は揺れます。さらに`sources`フィールドは回答生成時に参照した全URLを返す一方、本文中の引用は関連性の高いものだけが示されるため、通常は`sources`の件数のほうが引用より多くなります。画面で見えるリンク数とAPIで返る引用数を単純比較しても一致しないのは、この構造上の必然です。OpenAI API公式ドキュメント(Web search)
2. ドメイン制限:結果集合を人為的に狭める
Responses APIの`web_search`ツールでは、`filters`パラメータで`allowed_domains`または`blocked_domains`を最大100件まで指定でき、指定したドメインのサブドメインも対象に含まれます。許可リストを敷けば、検索画面なら上位に出てくるはずの情報源が最初から候補に入りません。逆に除外設定をすると、サブドメイン単位でまとめて落ちるため、想定より広い範囲が消えることもあります。ここは意図的に差を作っている部分であり、設定を忘れると原因不明のずれとして見えてしまいます。なお、ドメイン制限は`web_search`ツールで利用可能で、旧来の`web_search_preview`ツールは対応していない点に注意が必要です。
3. 取得経路:ライブ取得か否か
Responses APIの`web_search`ツールには`external_web_access`という項目があり、外部ウェブへの取得挙動を制御します。既定は有効(ライブ取得)で、無効化した運用では更新直後のページが即時反映されない時間軸のずれが生じ得ます。ただし公式ドキュメントには、`web_search_preview`ツールでは`external_web_access`が無視される旨も記載されており、どのツールを使っているかによって挙動が変わります。情報の鮮度を前提にした設計の考え方はSEOコンサルティングの設計論とも通じます。
4. 地域指定:近似であり非対応ケースもある
`user_location`では国・都市・地域を近似的に指定し、検索結果を地域に寄せられます。あくまで近似であり、ブラウザの現在地に基づく画面表示と厳密に一致するものではありません。加えて、Deep Research系モデルのウェブ検索では地域指定がサポートされないと公式で明示されています。地域差を検証する場合は、この非対応ケースに気を付ける必要があります。
差を再現・検証する手順:sourcesと引用の突き合わせで何が起きたかを可視化する
差の原因を推測で語らないためには、実際に何が取得され、そのうち何が答えに使われたのかを分けて観察する必要があります。そのための最短経路が、参照URLの一覧と本文中の引用を突き合わせる作業です。
手順1:参照URLの一覧を丸ごと保存する
まずレスポンスから参照URL群を取り出し、実行ごとにそのまま保存します。ここで重要なのは、引用として本文に現れたURLだけを見て満足しないことです。OpenAI API公式ドキュメント(Web search)が示すように、`sources`は回答生成時に見た全体を返すため、引用より広い集合になります。検索画面の結果と体感がずれたとき、そのURLが取得されていたのか、取得されたが引用されなかったのかを最初に切り分けます。
手順2:差分を4つの観点で読む
- 未取得:検索画面で上位にあるのに参照URLにも現れない。取得段階の問題として扱う。
- 取得済み・非引用:参照URLにはあるが本文に引用されない。関連性判断の段階で落ちている。
- 引用あり・順位不一致:引用はされているが、検索画面での目立ち方と重みが違う。
- 想定外の混入:期待していないドメインが参照URLに入っている。条件設定の見直し対象。
手順3:条件を1つずつ変える
比較テストは、同じプロンプト・同じモデルを固定したうえで、使用する検索ツール、地域指定、ドメイン条件、コンテキスト量のいずれか1つだけを動かします。2つ以上を同時に変えると、差分がどの要因由来か判別できません。各条件で3回以上繰り返し、参照URLの重なり具合も見ておくと、条件の影響か実行ごとの揺れかを分けやすくなります。
手順4:やり直せる形で記録する
- 実行日時とモデル名、プロンプト全文
- 変更した条件と、固定した条件の一覧
- 参照URLの全件と、本文引用に現れたURL
- 上記4観点での分類結果
- 同時刻に検索画面で確認した上位URL
この5項目が揃っていれば、後から第三者が同じ条件を再構成して確認できます。差の説明は、この記録があって初めて主張として成立します。
2026年の実務対応チェックリスト:差を前提に設計する
APIの回答と検索画面の内容がずれるのは不具合ではなく、設計思想の違いから生じる仕様上の帰結です。実務では差をなくそうとするのではなく、差が出る前提で用途ごとに設計と説明責任を組み立てます。以下を最終チェックリストとして活用してください。
用途別に検索ツール・モデルを選ぶ
OpenAIの各種検索ツール・モデル(前述の通り)とGeminiのグラウンディングは、それぞれ得意な場面が異なります。代表的な選定基準を4つ挙げます。
- 速度重視・単純な事実確認:Chat Completionsの検索対応モデルや`web_search_preview`。シンプルな挙動のため、検索画面との乖離を説明しやすい
- 比較検討や多角的な整理・ドメイン制限が必要:Responses APIの`web_search`ツール。filters・sources・詳細オプションが揃っており、対象範囲を制御しつつ思考の途中で検索を繰り返せる
- 調査レポートや白書作成:Deep Research。時間とコストを見込み、地域指定が非対応な点を先に伝える
- 多言語・出典必須の回答生成:Geminiのグラウンディング。Google AI for Developersが示すとおり検証可能な出典提示を目的としており、引用リンクの提示が要件の案件と相性がよい
ドメイン制限の使いどころと副作用
`allowed_domains`は、参照元を公的機関や自社ドキュメントに限定したい医療・金融・社内ナレッジ用途で有効です。一方で許可リストに情報が存在しない場合、回答が薄くなる、あるいは古い情報に依存するという副作用が生じます。`blocked_domains`も同様に、除外した先に一次情報があると精度が落ちます。制限をかける案件では、対象外の情報が回答に出てこないこと自体を仕様として明文化しておきます。なお、この機能はResponses APIの`web_search`ツールで利用可能で、`web_search_preview`ツールは非対応な点は要確認事項です。
鮮度リスクの合意形成
ライブ取得の可否は使用するツールと設定に依存します(OpenAI API公式ドキュメント)。速報性が要るテーマではライブ取得を有効にした`web_search`ツールを選び、社内説明では「いつ時点の情報か」を回答とセットで提示できる形にしておくのが安全です。
残すべき最小限の証跡
- 実行日時とモデル、使用した検索ツールの選択理由
- ドメイン制限の有無と、その業務上の根拠
- 取得経路の設定内容(ツールの種類とパラメータ)
- 参照URL群と本文引用の対応関係
この4点があれば、クライアントから乖離を指摘された際も、原因を仕様として説明できます。差を管理対象として扱う姿勢が、AI活用における信頼性の土台になります。
