ChatGPT、Gemini、ClaudeなどでWeb検索を使っていると、同じことを質問しているのに引用されるサイトや回答内容が違うことがあります。
モデルの性能差として説明したくなりますが、Web検索を使った回答では、その前にもう一つ大きな処理があります。
検索エンジンが、Web上にある膨大なページからAIに読ませる候補を選んでいることです。
AIが現在のWebについて回答するとき、インターネット全体をその場で読んでいるわけではありません。検索クエリを作り、検索結果を取得し、その中からページを読み、得られた情報を使って回答します。
ユーザーの質問
↓
検索クエリを生成
↓
検索エンジン
↓
候補ページを取得
↓
必要なページを読む
↓
比較・要約
↓
AIの回答この構造で考えると、Google、Bing、Braveといった検索エンジンは、人間が検索するときだけのサービスではありません。
AIにとっては、巨大なWebから読むべき情報を絞り込むretrieval layerでもあります。
この記事では、検索順位を上げる方法ではなく、AIを検索や調査に使う側から現代の検索エンジンを見ていきます。
AIが読めるのは検索で見つかった情報だけ
Web上に非常に詳しい記事があったとしても、そのページを検索エンジンが認識していなければ、検索経由ではAIも見つけられません。
たとえば、ある技術について次の3つのページが存在するとします。
ページA
有名な企業の公式ドキュメント
検索インデックスに登録済み
ページB
数年前からある解説記事
検索インデックスに登録済み
ページC
昨日公開された非常に詳しい個人ブログ
まだ検索インデックスに存在しないページCが最も質問に合っていたとしても、検索結果の候補に入らなければAIはページCを読むことができません。
検索ワードを何度変更しても同じです。
Web上には存在する
↓
検索インデックスには存在しない
↓
検索結果として返せない
↓
AIも検索経由では発見できないもちろん、URLを直接AIへ渡したり、別の検索基盤を使ったりすれば見つけられる可能性があります。
ここで区別したいのは、「情報が存在しない」と「現在使っている検索経路では発見できない」は別の状態だということです。
AI検索の回答を見るときにも、この違いは重要になります。
検索エンジンはAIの候補集合を作っている
LLMは、検索エンジンから返されたページを読んで内容を比較したり、複数の情報から回答を組み立てたりできます。
しかし、その前段階で候補から外れたページについては比較できません。
Web全体
↓
検索インデックス
↓
検索クエリとの関連性を評価
↓
上位の候補を取得
↓
LLMが読む検索分野では、関連する情報をどれだけ取りこぼさず取得できるかを考えるときに recall（再現率） という言葉があります。
AI検索でも同じ問題があります。
スパムや無関係なページを大量に混ぜれば、AIへ渡す情報の品質は下がります。一方で、厳しく絞りすぎれば、新しいサイトや知名度の低いサイトにある有用な情報まで落とす可能性があります。
広く拾う
↓
有用な情報を見落としにくい
↓
ノイズも増えやすい
厳しく選ぶ
↓
ノイズを減らしやすい
↓
有用な情報を取りこぼす可能性もあるAIにとって良い検索エンジンを考える場合、検索結果の見た目だけではなく、このバランスを見る必要があります。
Google・Bing・Braveは同じ検索エンジンでも方向性が違う
Google、Microsoft Bing、Brave SearchはいずれもWebをクロールし、検索用のインデックスを構築しています。
同じWebを対象にしていても、ページの発見方法や外部との接続方法には違いがあります。
| 検索エンジン | ページ発見の特徴 | 外部との接続で特徴的なもの |
|---|---|---|
| Googlebotによる大規模クロール | Search Console、sitemap | |
| Bing | Bingbotによるクロール | IndexNowによる更新通知 |
| Brave | 独自クローラー + WDP | 独立インデックスをSearch APIとして提供 |
この違いをAI側から見ると、それぞれ別の性格を持ったretrieval基盤になります。
Googleは巨大な検索エコシステムを持っている
Google検索では、Googlebotがリンクなどを辿りながらWebページを発見します。
サイト運営者はXML Sitemapを公開したり、Google Search Consoleを利用したりできますが、Search Consoleへ1ページずつ登録しなければGoogleに掲載されないわけではありません。通常はGoogle側がWebを巡回してページを発見します。
Google Search Consoleが強力なのは、インデックス状況だけでなく、検索結果に何回表示されたか、どの検索クエリから訪問されたか、クリック率がどうなっているかといった情報までサイト運営者へ返しているところです。
検索エンジン、広告、Analytics、Webmaster向けツールまで含めて、大きな検索エコシステムが形成されています。
そしてGeminiでは、このGoogle SearchがAIの検索基盤として直接利用される仕組みがあります。
Gemini APIには Grounding with Google Search が用意されており、Geminiが必要に応じて検索し、Google Searchから取得した情報を使って引用付きの回答を生成できます。
質問
↓
Gemini
↓
Google Search
↓
検索結果
↓
Geminiが回答を生成人間向けに長年構築してきたGoogle Searchのインデックスを、AIのretrievalにも利用できる構造です。
Google 検索によるグラウンディング | Gemini API | Google AI for Developers
Google 検索のリアルタイム情報にモデルの回答をグラウンディングすることで、事実の精度を高め、引用を提供できます。
https://ai.google.dev/gemini-api/docs/google-search?hl=ja
BingはIndexNowで更新側から検索エンジンへ通知できる
Bingも基本的にはクローラーがWebを巡回してページを発見します。
一方でMicrosoftは IndexNow を推進しています。
通常のクローリングでは、検索エンジン側がサイトを訪れて更新の有無を確認します。
検索エンジン
↓
サイトを確認
↓
更新されている？IndexNowでは逆方向の通知が可能です。
サイトを更新
↓
IndexNow
↓
検索エンジンへURLを通知記事を追加した、内容を更新した、ページを削除した、といった変更をサイト側から検索エンジンへ伝えられます。
検索エンジンが大量のWebサイトを繰り返し確認するだけでなく、変更した側もイベントを通知できるため、更新情報を早く発見する経路を増やせます。
ただしIndexNowでURLを送信したからといって、インデックス登録されることが保証されるわけではありません。通知は「このURLが変わった」という情報であり、実際にクロールするか、インデックスへ登録するかは検索エンジン側が判断します。
AIから見ると、この仕組みは freshness に関係します。
最新ニュース、価格変更、新しいドキュメントなどを扱う場合、検索インデックスがどれだけ早く現在のWebを反映できるかは、そのままAIが取得できる情報の新しさに影響します。
https://www.bing.com/indexnow
Braveは独立インデックスに人間の利用シグナルも取り入れる
Brave SearchはGoogleやBingの検索結果をそのまま再配信している検索エンジンではなく、独自のWebインデックスを持っています。
その構築方法で特徴的なのが Web Discovery Project（WDP） です。
WDPはBrave Browser利用者が任意で参加できる仕組みで、検索やWebページ訪問についての匿名化された情報をBrave Searchの改善に利用します。
ここでBrave BrowserとBrave Searchは分けて考える必要があります。Brave Browserを使っていても、検索エンジンとしてGoogleなどを選択できます。
そのため、条件を満たしたWDP参加者については、次のような経路もあり得ます。
Brave Browser
↓
別の検索エンジンで検索
↓
あるWebページを発見
↓
匿名化された利用シグナル
↓
Brave Searchのインデックスやランキング改善BraveはWDPについて、検索クエリ、検索結果のクリック、訪問したページのURL、ページ滞在に関する情報などを利用すると説明しています。
ただし、Brave Browserを利用していれば無条件ですべて送信されるわけではありません。WDPはオプトイン方式で、個人へ結びつけにくくするためのプライバシー保護も設けられています。
この方法によってBraveは、クローラーだけでなくWeb利用から得られるシグナルも検索インデックスの成長や検索結果の改善に利用しています。
https://support.brave.com/hc/en-us/articles/36223995501709-What-is-the-Web-Discovery-Project-in-Brave
Braveの仕組みにも弱点はある
WDPは興味深い仕組みですが、「人間が利用したページを使うから良い情報だけが集まる」という単純なものではありません。
たとえば、公開直後の新しいサイトを考えてみます。
新しく公開されたサイト
↓
まだ外部リンクが少ない
↓
Brave Browser利用者もほとんど訪れていない
↓
Brave側がまだ十分に発見できていないそのサイトに非常に良い情報が存在していても、検索インデックスに入っていなければ検索結果には出ません。
これはBraveだけの問題ではなく、検索エンジンがWebをインデックスする以上、どこでも起こり得る問題です。
ただ、検索エンジンによってクローラーの規模、URLの発見経路、更新頻度、ランキング方法が違うため、同じWebを対象にしていても検索エンジンごとに「見えているWeb」は完全には一致しません。
ここがAI検索にも影響します。
BraveはAI向け検索インフラとして見ると面白い
Brave Searchが特に興味深いのは、検索ページそのものだけでなく、独立した検索インデックスを Brave Search API として外部へ提供していることです。
BraveはSearch APIをAI AgentやChatbot向けにも提供しており、通常の検索結果に加えて、LLMで利用しやすい検索コンテキストやreranking関連の機能も展開しています。
BraveのWeb Index
↓
┌───────────────┐
Brave Search
AI検索サービス
Chatbot
AI Agent
RAGシステム
└───────────────┘人間がBrave Searchをどれだけ使うかとは別に、AIがWebへアクセスするための検索インフラとしてBrave Indexを提供するという方向があります。
GoogleにはGoogle SearchとGeminiがあり、MicrosoftにはBingとCopilotがあります。
Braveは検索APIを通して、他社のAIやAgentから利用できる立場を取りやすい検索エンジンです。
Brave Search API | Brave
Enterprise-grade Web search API accessing an index of 40+ billion pages. Specialized endpoints to train models, power search, and more. Real-time indexing, low latencies, and flexible pricing.
https://brave.com/search/api/
検索エンジンとAIサービスは1対1で対応するとは限らない
ここで注意したいのが、
ChatGPT = Bing
Gemini = Google
Claude = Braveのように単純化しすぎないことです。
Geminiについては、GoogleがGoogle SearchによるGroundingを公式機能として提供しているため、関係は明確です。
一方、ChatGPT Searchは必要に応じて外部の検索プロバイダーも利用しながら、OpenAI側で検索クエリの生成や検索結果の処理を行います。OpenAIは検索用のクローラーであるOAI-SearchBotも運用しています。
つまり、単にBingの検索画面を裏側で呼び出しているだけではありません。
https://help.openai.com/en/articles/9237897
Claudeについても注意が必要です。
商用ClaudeではWeb Searchが組み込み機能として提供されていますが、通常のテキストWeb検索で利用する検索バックエンドは、現在のAnthropic公式ヘルプでは特定されていません。
一方、Claude for Government向けのWeb Search ConnectorではBrave Search APIを利用することが明記されています。またClaudeの画像検索についてはBingを利用すると説明されています。
そのため、現時点で一般化して「Claudeの検索エンジンはBrave」と断定するのは正確ではありません。
Enable and use web search | Anthropic Help Center
https://support.claude.com/en/articles/10684626-enable-and-use-web-search
MCP: Web Search | Anthropic Help Center
https://support.claude.com/en/articles/14503775-mcp-web-search
AIサービス側でも、検索クエリの作り方、検索プロバイダー、独自クローラー、検索結果の再ランキング、Webページの取得方法など、複数の処理を組み合わせられます。
AIサービス
│
├─ クエリ生成
├─ 検索プロバイダー
├─ 独自インデックス
├─ Webページ取得
├─ reranking
└─ LLMによる回答生成そのため、AIのWeb検索品質を「どの検索エンジンを使っているか」だけで評価することもできません。
AI目線では検索エンジンの評価軸も変わる
人間向け検索エンジンでは、検索画面の使いやすさ、広告の量、検索結果の見せ方、プライバシーなどが重要です。
AIが利用する検索基盤として見る場合は、少し違う指標も重要になります。
| 観点 | AI検索に与える影響 |
|---|---|
| Coverage | Webのどこまでインデックスできているか |
| Freshness | 新しい情報や更新をどれだけ早く反映できるか |
| Recall | 関係するページをどれだけ取りこぼさず取得できるか |
| Ranking | 質問に合うページを上位へ出せるか |
| Spam filtering | SEOスパムやコピーコンテンツをどこまで減らせるか |
| Latency | Agentが繰り返し検索するときに十分高速か |
| API / Context | LLMが扱いやすい形で検索結果を取得できるか |
AIは検索結果を最終回答としてそのまま表示する必要がありません。
検索エンジンが候補を絞ったあと、LLM側でも複数ページを比較したり、一次情報を優先したり、追加検索したりできます。
検索エンジン
「関係しそうな情報はこのあたり」
↓
LLM
「公式情報はこちら」
「複数ソースで一致している」
「この部分は情報が食い違っている」
↓
回答検索エンジンは答えそのものを決めるのではなく、AIが検討する情報の入口を作ることになります。
検索上位だから正しいとは限らない
ここで検索エンジンを「事前に正しい情報だけを選別してくれるシステム」と考えるのも危険です。
Google、Bing、Braveのどれも、Web上の事実だけを保存したデータベースではありません。
検索結果の上位にあることと、事実として正しいことは同じではありません。
検索エンジン
↓
関連性の高そうな候補を選ぶ
LLM
↓
候補を比較する
ユーザー
↓
重要な情報なら一次情報まで確認するAI検索では、検索エンジンとLLMの両方に評価処理があるからこそ、最終的な引用元を見ることが重要になります。
同じ質問でAIごとの回答が違う理由
ここまでの仕組みを見ると、ChatGPT、Gemini、Claudeで回答が違う理由も、モデル性能だけでは説明できないことが分かります。
違いが生まれる場所は複数あります。
質問
↓
① 検索する必要があると判断するか
↓
② どんな検索クエリを作るか
↓
③ どの検索インデックスを見るか
↓
④ どの検索結果を選ぶか
↓
⑤ どのページを実際に取得できるか
↓
⑥ 取得した情報をどう評価するか
↓
⑦ どう回答としてまとめるかモデルが同程度に優秀でも、③や④で違うページが渡されれば回答は変わります。
逆に、同じ検索エンジンを利用していても、①、②、④以降の実装が違えば結果は変わります。
AI検索を比較するときには、「モデルAの方が賢い」で終わらせず、何を検索して、どの情報を取得したのかを見ると原因を理解しやすくなります。
「見つからない」を結論にしない
AIを調査に使うとき、特に注意したいのが「見つからなかった」という回答です。
AIが検索して該当情報を発見できなかったとしても、それだけで情報が存在しないことは証明できません。
検索して見つからない
≠
Web上に存在しない新しいサイト、アクセスの少ないサイト、他言語のページ、検索エンジンがまだクロールしていないページなどに情報が存在する可能性があります。
重要な調査では、検索経路を変えることもできます。
- 別のAIでも同じテーマを検索する
- 検索語を別の言語に変える
- 公式サイトや特定ドメインに限定して探す
- サービス名や論文名など固有名詞を使う
- URLが分かっている場合は直接AIへ渡す
- 一次情報を優先して再検索する
AIに検索機能が付いたことで調査はかなり楽になりましたが、検索インデックスの外側まで自動的に見えるようになったわけではありません。
サイト運営側ではWebmaster Toolsが必須とは限らない
検索エンジンの話をすると、Google Search ConsoleやBing Webmaster Toolsのようなサイト運営者向け機能も出てきます。
ただし、これらが全員に必要というわけではありません。
サイト運営の目的が、
記事を公開する
↓
検索などから人が来る
↓
実際にどれくらい読まれたか知る程度なら、ページビュー、訪問数、Referrerなどは自分のサイト側でも計測できます。
Search Consoleが特に価値を持つのは、
どんな検索キーワードで表示されたか
何回検索結果に表示されたか
検索順位はどのあたりか
表示されたうち何回クリックされたかといった、検索結果からサイトへ来る前の情報を分析したい場合です。
これはSEOやコンテンツマーケティングでは重要ですが、単純に人間がどの程度サイトを利用しているかを知りたいだけなら、必ずしも検索エンジン側の分析ツールが中心になるわけではありません。
AI目線で検索エンジンを見る場合も、Webmaster機能の多さより、インデックスそのもののcoverage、freshness、recall、ranking qualityの方が本質的です。
AI時代でも検索エンジンはなくならない
生成AIが検索結果を直接まとめるようになると、「検索エンジンはAIに置き換わる」と考えたくなります。
しかし、Web全体から最新情報を取得するという問題は残ります。
LLMが毎回Web上のすべてのページを読むことは現実的ではありません。
Web全体
↓
候補を絞る
↓
必要な情報を取得する
↓
LLMが考えるこの「候補を絞る」部分が必要である限り、検索インデックス、ランキング、retrievalは重要です。
変わるのは、その検索結果を誰が読むかです。
これまでは主に人間が検索結果一覧を見て、クリックするページを選んでいました。
検索エンジン
↓
検索結果一覧
↓
人間が選ぶAI検索では、その間にAIが入ります。
検索エンジン
↓
候補ページ
↓
AIが取得・比較
↓
回答
↓
人間検索エンジンが表に見えにくくなっても、裏側で担当する仕事はむしろ重要になります。
まとめ
AIのWeb検索を見るとき、LLMだけを見ていると検索結果の違いを説明できないことがあります。
AIが現在のWebについて回答するまでには、検索エンジンによるretrievalがあります。
Web
↓
検索インデックス
↓
検索・ランキング
↓
ページ取得
↓
LLM
↓
回答Google、Bing、Braveは同じWebを対象にしていても、ページの発見方法、インデックスの更新方法、ランキング、外部への提供方法が異なります。
その違いによって、AIが最初に見ることのできる情報も変わります。
特に覚えておきたいのは、AIが検索で見つけられなかった情報が、Web上に存在しないとは限らないことです。
AI検索の精度を考えるときには、モデルの性能だけでなく、そのモデルへどのような候補を渡しているのかを見る必要があります。
AI時代の検索エンジンは、人間に10本の青いリンクを表示するだけの仕組みではなくなりつつあります。
Web全体から情報を探し、ノイズを減らし、最新性を保ち、AIが読む候補を作る。
検索エンジンは、AIがWebを見るための視界そのものになりつつあります。
