ChatGPTのようなAIに質問すると、まるですべてを暗記している職人のように答えが返ってきます。でも実務の仕組みでは、モデルは常に「手元にない情報」を、その場で取りに行いてから答えを支えています。社内文書、商品カタログ、レビュー、Web、権限のあるストレージ——情報がそこに散らばっているほど、「頭が良いか」より前に「必要なものをうまく探せるか」 が成果を分けます。
この記事は、検索やRAGに馴染みの薄い方でも、頭の中に動きの絵が浮かぶように流れをつなぎます。キーワード検索と意味検索の違いから、ハイブリッド・再ランキング、関係をたどる Graph RAG、手順を組み立てる エージェント型検索までを説明します。製品固有の深掘りは、筆者のQiita記事一覧 にあるエージェンティックRAGやFoundry IQの稿に寄せ、ここでは「全体を説明できる地図」に絞ります。
参考: 構成や技術要素の整理については、Microsoft が案内する RAG チャット／ナレッジベース向けの資料（https://aka.ms/ragchat/knowledgebase）を参照して執筆しています。同ショートリンクは、Azure-Samples の azure-search-openai-demo リポジトリにおけるナレッジベース・エージェンティック取得まわりのドキュメント（例: RAG chat: Using agentic retrieval）へ誘導されます。
賢さの前に「取りに行く」がある
多くの人は、AIを選ぶときどのモデルが強いかばかり気にします。それも大事です。ただ、現場の失敗の多くは「モデルが弱い」より参照すべき情報に届いていないところから起きます。たとえば、固有名詞は文書にそのまま載っているのに、質問の言い回しが違ってヒットしない。逆に、言い換えは通じても、型番や数値の一致でしか決まらない照合が抜ける——こうした取りこぼしは、あとからいくら生成を丁寧にしても埋まりにくいのです。
そこで押さえたいのが、次の短い流れです。人が質問し、AIが必要な情報を探し、見つけたものを整理し、自然な文章にします。塗料の選び方、ホースの長さ、レビューの傾向のような身近な例えでも、社内の申請フローや障害対応のRunbookでも、この骨格は同じです。
「探す」技術は階段になっている
いきなり難しい名前を並べるより、一段ずつ上がるイメージがおすすめです。下の図は、だいたいのシステムが通る道の骨格です。
ここから先は、この「探す」をどう工夫するかが本題です。
キーワード検索：まずは「言葉の一致」で探す
最初に出会うのが、普段の検索エンジンにも近いキーワード（全文）検索です。入力された語が、文書や商品名の中でどれだけ重なるかを見ます。代表的な考え方に BM25 があり、情報検索の世界ではごく一般的な基準です（Okapi BM25（Wikipedia））。
質問が「25フィートのドリップホース」のような数字・製品語がはっきりしたものだと、強みが出ます。
一方で弱点もあります。「庭の散水用品」のように文書側に同じ語が無いと、当たりが薄くなることがあります。つまりキーワード検索は言葉そのものには強いのですが、言い換えの世界までは自動では橋をかけません。
ベクトル検索：「意味の近さ」でつなぐ
そこで役立つのがベクトル検索（埋め込みによる近傍探索）です。言葉が一致しなくても、意味が近いものを近くに置いておき、質問から距離の短い候補を取ります。Azure AI Searchのドキュメントでも、ベクトル検索は意味的類似性のクエリに向く、と説明されています（Azure AI Search のベクトル検索の概要）。
高速化のために HNSW のような近似アルゴリズムが使われることもあります（例：HNSW の論文（arXiv））。DiskANN のような大規模向けの近傍探索実装も知られています（microsoft/DiskANN（GitHub））。入門の段階では、頭の中は**「意味の地図で近いものを拾う仕組み」**で十分です。
ハイブリッド検索：得意分野が違うから、両方使う
資料や現場の設計議論で繰り返し出るのが、どちらか一つでは足りないという結論です。キーワードは語と数値に強く、ベクトルは言い換えに強い——短所が補い合うからです。そこで両方を掛け合わせたのがハイブリッド検索で、Azure AI Searchでは全文とベクトルを組み合わせるパターンとして整理されています（ハイブリッド検索の概要）。
複数の並び順を一つにまとめる代表的手法に RRF（Reciprocal Rank Fusion） があります。Microsoft Learnでは、並列に走った複数クエリの順位を統合するアルゴリズム、と説明されています（ハイブリッド検索での RRF による関連性スコアリング）。イメージとしては、「両方のリストで上位にいた文書は、かなり有力だろう」 と票を合算する感覚で大丈夫です。
リランキング：候補集めと、最終の並べ替えは別作業
ハイブリッドまで行っても、並びは必ずしも質問の細部に最適ではありません。そこでもう一段、候補を質問に合わせて並べ直すのがリランキングです。Azure AI Searchでは、セマンティックランカーが RRF の後に動き、別スコアを返す流れが文書化されています（ハイブリッド検索での RRF による関連性スコアリング／セマンティック検索の概要）。
たとえば「25フィートのドリップホース」への最初の候補に、似たような別製品が紛れ込んでも、後段の並べ替えで本命が上がる——この「一段しぼる」感覚が、初心者向けには検索は広く集める、リランキングは納得できる順に整えると覚えると伝わりやすいです。
質問が複雑になると、「点」だけでは足りない
ここまでが多くのRAG入門の中心です。ところが実際の業務では、複数条件を同時に満たす商品はどれか、高価格帯と同等評価の安い代替は、機能Aとレビュー項目Bの両方が良いものは——といった問いが出ます。価格、機能、感情、カテゴリ比較が絡むため、バラバラの文書を単発で拾うだけでは答えに届きにくいのです。
Graph RAG：データ同士の「つながり」を手がかりにする
関係を明示的に持てると、複合条件に強くなります。Graph RAG をざっくり言うと、商品・機能・レビュー・トピックなどをノード（点）として、関係をエッジ（線）で結び、その上で探索する考え方です。Microsoft Research 側でも、グラフ構造を利用して大規模テキストから推論する GraphRAG の枠組みが紹介されています（GraphRAG（Microsoft Research）／解説ブログ：GraphRAG: ナラティブなプライベートデータでの LLM による探索を解放する）。
PostgreSQL でグラフ拡張として Apache AGE を使う例もよく議論されます（Apache AGE／Azure Database for PostgreSQL での Apache AGE）。実装の細部は別稿に任せ、ここで持ち帰りたいのは 「関係をデータとして持てると、複雑な“かつ”に強くなる」 という設計感です。
エージェント型検索：一発検索で終わらない問いに、手順を組み立てる
さらに現実には、質問が複文で、情報源も複数というパターンがあります。バスルーム向けの塗料とその価格帯、作業手順とあわせて商品一覧、工具の選定と交換時期——こうした問いは、一度の検索で終わらず、分解して順に当たり、最後にまとめる必要があります。
Microsoft の文脈では、この「計画して複数回取りに行く」取得が エージェンティック検索（agentic retrieval） として整理され、サブクエリ分解や複数ソース、結果の統合にまで踏み込む、と説明されています（Azure AI Search のエージェント検索の概要）。
つまり 「検索するAI」ではなく、「調べ方を考えながら調べるAI」 です。従来の「質問→1回検索→表示」と並べると、違いは手順の厚さにあります。エージェント設計のトレードオフや段階的に重い探索へ進む話は、すでに別稿で扱っています（筆者のQiita記事一覧）。
図書館のたとえで持ち帰るメッセージ
最後に、非エンジニアの方と話すときの図書館たとえを置いておきます。キーワード検索は目次やタイトルの語で棚を探す感じ。ベクトル検索は話題が近い本を近くに置く感じ。ハイブリッドは両方を掛け合わせる。リランキングは司書が「この質問ならこの順」に並べ直す作業。Graph RAGは人物・事件・引用の関係を線でたどる。エージェント型検索は 「まず辞典、次に紙、必要なら外部DB」 と、手順を考えながら動く司書です。
だから教訓はシンプルです。AIの答えを良くしたいなら、モデル選びだけに閉じず、何をどう探すか、情報をどうつなぐか、候補をどう選び直すかまで設計しよう——現場の品質は、だいたいここで決まります。
関連： 本稿は入門の地図に徹し、エージェンティックRAGやFoundry IQの接続、評価・権限・プレビュー制約といった実装寄りの論点は、筆者のQiita記事一覧 の該当稿へ回しています。一覧のなかにある「RAGは古い？」を題材にしたエージェンティックRAG／Foundry IQの稿や、RAGとエージェント型検索の対比の稿と併読すると、重複せずに深掘りできます。
作成日： 2026年3月25日