
RAGとAI検索が別技術だという前提を外し、AI検索の回答生成そのものがRAGの実装であることを起点に整理した記事。RAGの3工程と事前学習との役割分担を最小構成で押さえたうえで、ChatGPT Search/Perplexity/AI Overviews/Claude/Microsoft Copilotの検索経路と引用形式の差を比較する。中核は、社内RAGとAI検索のRAGで自社が握れる変数が正反対になるという対照と、自社ページが引用に至るまでの4段階(インデックス到達・取得・候補残存・引用)ごとの脱落原因の切り分け。読了後、どの段階で止まっているかに応じて着手箇所を1つ決められる状態を目標とする。
AI検索とRAGは、同じ仕組みを内側から見るか外側から見るかの違い
RAGとAI検索は別々の技術ではなく、AI検索が回答を組み立てる仕組みそのものがRAG(検索拡張生成)です。
「別物なのか、同じものなのか」という迷いが生まれるのは、読み手の理解不足ではなく、解説の文脈が二つに割れているためです。一方では、社内文書を検索して回答する社内システムの構築技術として語られます。これに対しもう一方では、ChatGPT SearchやPerplexity(Perplexity AI)が動く裏側の技術として語られます。同じ語が「作る側の話」と「使われる側の話」に分かれて流通しているため、二つの別技術のように見えます。
実際に確かめたいのは、たいてい次の点です。
ChatGPT SearchやPerplexity、AI Overviews(AI概要)は何を検索しているのか。そして、そこに自社のページは出るのか。1つの質問の裏でAI検索が何度も検索を走らせる挙動については、関連記事『【国内最大規模のクエリファンアウト調査】AIは1つの質問の裏で最大33回検索する』で詳しく解説しています。
押さえるべきは、RAGの3工程を暗記することではありません。自社のページが、そもそも取得(Retrieval)の対象に届いていないのか、取得はされたうえで引用に選ばれていないのかを、段階で切り分けることです。原因が違えば打ち手も違います。クローラーの設定で止まっているページの見出しをいくら書き直しても、状況は動きません。
RAG(検索拡張生成)は、外部資料を見ながら答える仕組み
RAGは、LLM(大規模言語モデル)が回答を作る前に外部の情報を検索し、その内容を材料として渡してから文章を生成する構成を指します。工程は3つです。
-
検索(Retrieval):質問に関連する文書を探して取り出す
-
拡張(Augmented):取り出した文書をプロンプトに差し込み、生成の材料にする
-
生成(Generation):材料を踏まえて回答文を書く
この構成が必要になる理由は、LLM単体の性質にあります。モデル内部の知識(事前学習)は学習時点で固定されるため、公開直後の情報や社外に出ていない社内データは含まれません。身近な例でわかりやすいのは、自分でファイルを読み込ませてその中の情報を抜き取るのケースです。
事前学習だけに頼ると、知らない領域を推測で作った回答が出やすくなります。RAGは回答の根拠を外部文書に置くことでこの推測を抑え、ハルシネーション(嘘)の発生余地を狭めます。根拠となる文書が特定できるため、出典を提示できることも副次的な効果です。この「回答を外部の根拠に結びつける」考え方をグラウンディング(根拠付け)と呼びます。
混同しやすいのは、ファインチューニングとの関係です。ファインチューニングはモデル自体の振る舞いを学習で変える手段であり、更新のたびに再学習が要ります。一方RAGは、モデルを変えずに参照先の文書を差し替えるだけで内容が変わります。要するに、前者は話し方を仕込む方法、後者は資料を持たせる方法です。誤情報そのものを防ぐ設計を先に整理したい場合は、関連記事『AI対策で誤情報を防ぐためのリスク整理と実践的な回避術』を参照してください。
ここまでがAI検索の話に入る前提です。RAGを社内システムの構築技術として詳しく追う必要は、自社サイトの引用を目的とする限りありません。
ChatGPT SearchやPerplexityは何を検索しているのか
各AI検索は、いずれもRAGの構成を採りながら、検索の取りに行き方と引用の出し方が異なります。公開されている解説と各社ドキュメントで確認できる範囲を整理すると、次のようになります。
|
サービス |
検索の取りに行き方(公開情報ベース) |
引用の出し方 |
|
ChatGPT Search |
Bing系の検索インデックスを基盤にWebを参照する |
ソースリンクをまとめて表示する |
|
Perplexity |
自社のリアルタイムWeb検索を使い、中核モデルにSonarを据える |
文単位で番号付きの引用を付ける |
|
AI Overviews/AI Mode(AIモード) |
Google検索のインデックスを利用し、AI Modeでは前段でQFO(クエリファンアウト)を行う |
回答の該当箇所にリンクを付与する |
|
Claude |
会話中のWeb検索機能で外部情報を参照する |
参照したページをリンクで提示する |
|
Microsoft Copilot |
Bing系の検索基盤を利用する |
出典リンクを併記する |
各サービスの内部仕様は非公開部分が多く、数か月単位で変わります。ちょうど最近少し変更がありました。(2026年9月上旬)運用の判断に使う際は、各社の公式ドキュメントを一次情報として確認してください。
構造として重要なのは、質問文がそのまま検索クエリになるとは限らない点です。QFOを行う実装では、1つの質問がサブクエリ群に分解され、それぞれが個別に検索されます。つまり、読者が入力した文言ではなく、AIが内部で作り直した複数の問いに対して、自社ページが当たるかどうかが問われます。
検索の中身は、ベクトル検索とキーワード検索を組み合わせたハイブリッド検索が一般的です。ベクトル検索は意味の近さで探すため、語が一致していなくても拾われる余地があります。一方でキーワード検索は表記の一致に強く働きます。取り出された候補はリランキングで並べ替えられ、そのうえで回答生成に渡される分だけが材料になります。
前提として押さえておきたいのは、拾われる単位がページ全体ではないことです。文書はチャンク(文書の分割単位)に切られ、パッセージ単位で類似度が測られます。ページとして良く書けていても、切り出された一区切りが単独で意味を成さなければ、候補としての扱いは弱くなります。
社内RAGとAI検索のRAGでは、握れる変数が正反対になる
同じ技術でありながら、社内RAGとAI検索のRAGは、自社が調整できる変数がほぼ逆になります。ここを混ぜたまま議論すると、社内RAGの成功体験がそのまま通用するという誤解が生まれます。
|
変数 |
社内RAG |
AI検索のRAG |
|
対象データ |
自社が選んだ社内文書 |
公開Webページ全般 |
|
チャンクの設計 |
自社が分割単位を決める |
各サービス側が決める |
|
埋め込みモデル・ベクトルデータベース |
自社が選定する |
選べない |
|
リランキングの基準 |
調整できる |
非公開 |
|
インデックスへの収録 |
自社が投入する |
到達性は自社の設定と各社の判断に依存する |
|
精度の評価 |
検索ログで再現率・適合率を測れる |
回答が揺れるため、目視や外部ツールでの確認が中心になる |
整理すると、社内RAGで自社が握っているのは検索基盤そのものです。これに対しAI検索では、検索基盤の側は一切触れません。自社が握れるのは、検索基盤に渡される原稿、つまり公開しているページの中身と、そこへの到達経路だけです。
この違いは打ち手の性質を変えます。社内RAGでは精度が出なければチャンクサイズやリランカーを調整できますが、AI検索では調整対象が存在しません。実務上は、「基盤を最適化する」発想から「どう切られても意味が通る原稿を置く」発想へ、設計の軸を移すことになります。
自社ページがAI検索に引用されるまでの4段階
引用されない状態は、一つの現象ではありません。到達していないのか、取得はされたが候補で消えたのか、候補には残ったが出典として選ばれなかったのかで、原因も対処も変わります。段階を分けると次のように見えます。つまりRAGのどの工程で脱落しているのか見る必要があります。
|
段階 |
通過している状態 |
落ちているときの見え方 |
主な原因 |
|
1 インデックス到達 |
各AI検索が参照する経路にページが載っている |
どの質問でも一切登場しない |
AIクローラーの一括拒否、JavaScript依存のレンダリング、noindexの残存 |
|
2 取得(Retrieval) |
サブクエリの語彙とページの語彙が重なる |
指名検索では出るが、一般的な質問では出ない |
サブクエリの被覆が狭い、表記ゆれによるエンティティ分散 |
|
3 候補残存(リランキング) |
検索候補の上位に残る |
同じ趣旨の質問でも出たり出なかったりする |
パッセージが単独で意味を成さない、内容が他ページで代替できる |
|
4 引用 |
回答の根拠として出典に出る |
内容は反映されているのに出典に名前がない |
定義文が曖昧、情報の鮮度が判別できない、回答への寄与度が低い |
第1段階:インデックス到達で落ちる
AIクローラーには用途の違いがあります。学習用クローラー(GPTBot、ClaudeBot、CCBotなど)、検索用クローラー(OAI-SearchBot、Claude-SearchBot、PerplexityBotなど)、ユーザー操作起点の取得(ChatGPT-Userなど)の3分類です。robots.txtで用途を区別せずまとめて拒否すると、学習利用を避ける目的で検索経由の露出まで同時に閉じることになります。これが機会損失の典型です。
llms.txtについては、主要サービスのうち公式に対応を表明しているのはPerplexityにとどまり、他の主要サービスでは明確な表明が確認できません。設置自体の負荷は小さいものの、実効範囲は限定的だと見ておくのが妥当です。
第2段階:取得で落ちる
質問はサブクエリに分解されるため、狙ったキーワード1語に最適化しても、分解後の問いに当たらなければ拾われません。判断基準としては、1つのテーマについて読者が抱く問いを列挙し、そのうち何割が本文中で実際に語彙として現れているかを見ます。
同時に効くのが表記の統一です。同一のサービス名や概念を複数の表記で書いていると、エンティティとしての結びつきが分散します。サイト内で表記規則を決め、初出のみ併記して以降は統一する運用が、地味ですが取得段階に効きます。
第3段階:候補に残れず落ちる
ここが「認知はされているが引用されない」状態の実体です。切り出された一区切り(チャンク)が、前の段落を読まないと意味が取れない書き方になっていると、候補として弱くなります。具体的には、「このように」「上記の通り」で始まる段落や、見出しと本文の対応が緩い箇所が該当します。
もう一つは代替可能性です。他のページでも同じ内容が書けるなら、権威性の高いドメインが優先されます。自社にしかない実測値や運用上の条件は、この段階で効きます。
第4段階:引用の直前で落ちる
回答生成の材料に入っても、出典として提示されるとは限りません。回答文への寄与が小さい情報は、内容だけ使われて出典に残らないことがあります。定義文が言い切れているか、いつ時点の情報かが判別できるかは、この段階の分かれ目になります。更新日だけを更新して中身が変わっていないページは、鮮度の判断材料として機能しにくくなります。
段階を確認したうえでの実装手順と構造化データの設計は、関連記事『LLMOとコンテンツマーケティングを統合する実践ガイド』にまとめています。
引用に耐える単位で書くための見出し設計
自社が握れる変数が「渡す原稿」だけである以上、設計の焦点は、どこで切られても意味が通る単位を作ることに絞られます。
第一に、H2とH3を意味単位で完結させます。見出し配下の最初の段落だけを読んだときに、その見出しの問いに答えられているかを点検します。答えが数段落先にあるなら、切り出された一区切りは答えを持たないことになります。
第二に、定義文を独立させます。「〇〇とは、〜する〇〇です」の形の一文を、修飾や前置きなしで置きます。この一文は、取得の対象としても、引用の対象としても機能します。
第三に、指示語で前段落に依存させないことです。段落の冒頭で主語を省略すると、単体で読んだときに主題が消えます。同じ語を繰り返すことになりますが、この文脈では表記の一貫性が優先されます。
第四に、狙いを「1位を取る」から「候補に残り続ける」へ置き換えます。AI検索の回答は同じ質問でも揺れます。1回の出現ではなく、複数のサブクエリで候補に入り続ける状態を作るほうが、結果として引用の回数は安定します。ページ単位ではなくトピック単位で内部リンクを束ね、関連する問いを面で覆う設計が、この狙いに対応します。
RAGとAI検索をめぐって残りやすい疑問
AIクローラーは許可すべきか、拒否すべきか
学習用と検索用で判断を分けるのが基本です。学習利用を避けたい方針があるなら学習用クローラーのみを制御し、検索用クローラーとユーザー操作起点の取得は許可する形が、露出を保ちながら方針を実現する構成になります。まとめて拒否すると、第1段階で全ての質問から外れます。
引用されているかどうかは、どう確認するのか
主要サービスに同じ質問を投げ、出典欄に自社ドメインが出るかを記録する方法が最も直接的です。回答は揺れるため、1回の結果で判断せず、質問文を変えながら複数回試します。アクセス解析側では、AI検索からのリファラと指名検索の推移を併せて見ます。ゼロクリック検索の比率が上がる局面では、表示回数とクリック率が乖離するため、流入数だけを指標にすると実態を見誤ります。
社内RAGを構築していれば、AI検索にも強くなるのか
直接には繋がりません。社内RAGで蓄積されるのは検索基盤側の設計知見であり、AI検索で自社が握れるのは公開ページの中身だけだからです。とはいえ、社内RAGの運用で「どの書き方の文書が拾われにくいか」を観察した経験は、チャンク単位で読まれる前提の原稿設計にそのまま転用できます。
まとめ
RAGとAI検索は同じ仕組みであり、違うのは自社が触れる範囲です。社内RAGでは検索基盤を自社が握りますが、AI検索では渡す原稿しか握れません。
引用されない状態を一括りにせず、インデックス到達、取得、候補残存、引用の4段階で切り分けると、打ち手が一つに定まります。どの質問でも出ないならクローラーの設定、一般的な質問で出ないなら語彙と表記、出たり出なかったりするなら段落の自己完結性、内容だけ使われているなら定義文と鮮度です。
最初に着手する最小単位は3つです。robots.txtでAIクローラーを用途別に見直すこと、主要ページの見出し直下の段落が単独で問いに答えているか点検すること、サイト内でサービス名と用語の表記を統一することです。いずれも1週間以内に着手でき、順番を守れば、次に何を測るかも決まります。
検索流入そのものの前提が変わりつつある状況を含めて整理したい場合は、関連記事『SEOとは?効果が出ない原因とAI検索時代の対策をわかりやすく解説』で詳しく解説しています。自社サイトが現在どの段階で止まっているかを確認する場合は、umoren.aiのLLMO診断で、公開ページの到達性と引用状況を無料で確認できます。
RAGの理解を自社サイトの改善につなげる記事
AI検索の仕組みを理解しても、自社サイトのどこから直すかは別の判断になります。段階ごとの脱落原因を押さえたうえで、実装と計測の順序を決める記事から読み進めてください。
-
AI検索時代にオウンドメディアはどう変わるべきか?:PV依存を脱したオウンドメディアの設計法
-
指名検索が少ない会社がLLMOで先にやるべきこと:指名検索が少ない企業が先に着手する優先順位
-
AI Overview対策ツールで検索結果に"選ばれる情報"になるための実践攻略ガイド:AI Overviewの引用状況を可視化するツールの判断軸
-
AI検索の普及で問い合わせ経路はどう変わるのか?:問い合わせ経路の変化に合わせたKPIの整理法
-
BtoB向けAI検索対策(LLMO/GEO/AIO)会社おすすめ12社比較:BtoBでLLMO支援会社を比較するときの判断軸
AI開発・LLMO対策のご相談はこちら
Queueのエンジニアチームが貴社の課題に合わせてご提案します
