ベクトル検索とは、テキストを埋め込み（意味を数値化したベクトル）に変換し、ベクトル同士の距離の近さで関連文書を探す検索方式です。「同じ単語が含まれるか」で探す従来のキーワード検索と違い、「意味が近いか」で探すため、言い換えや表記ゆれを越えて関連情報を拾えます。RAGやAI検索が内部で関連文書を集めるとき、この仕組みが働いています。
ベクトル検索は、あらかじめ大量の文書を埋め込みベクトル（＝意味を保った数値の並び）に変換して保管しておき、検索時にはユーザーの質問も同じ方法でベクトルに変換し、質問ベクトルに「距離が近い」文書ベクトルを取り出す検索方式です。ここでの距離は、多くの場合コサイン類似度（＝2つのベクトルの向きのずれで近さを測る指標。向きが同じなら近い）で測ります。字面ではなく、意味の座標上での近さで結果を並べるのが本質です。
対になる概念が、キーワード検索（＝レキシカル検索。文字列の一致で探す方式）です。代表的な手法にBM25（＝単語の出現頻度と希少さで関連度を点数化する古典的アルゴリズム）があり、長年の検索エンジンの土台でした。キーワード検索は「東京タワー」「型番XYZ-100」のような固有の文字列を正確に当てるのが得意ですが、「あの赤い電波塔」のような言い換えには弱いです。ベクトル検索はその逆で、言い換えや意図の一致に強く、完全一致の正確さでは劣ることがあります。両者は優劣ではなく、得意分野が異なる補完関係です。
この補完関係を活かすため、実務では両方を併用するハイブリッド検索（＝キーワード検索とベクトル検索を組み合わせ、双方の結果を統合する方式）が広く使われます。固有名詞や型番はキーワード側で確実に拾い、言い換えや文脈はベクトル側で拾います。多くのAI検索・企業内検索は、単独のベクトル検索ではなくこのハイブリッド構成を採ります。
AI検索対策（AIO＝AIに引用・参照されるための最適化）において、ベクトル検索は「自社コンテンツが回答候補に選ばれるかどうかの選抜工程」に相当します。RAG型のAI検索は、ユーザーの質問に対し、まずベクトル検索で関連文書を数件〜数十件に絞り込み、その絞り込まれた文書だけをAIに渡して回答を作らせます。つまり、このベクトル検索の網に掛からなければ、その後どれだけ良い文章であってもAIの目に触れず、回答に反映される可能性はゼロになります。
ここが従来のSEOと決定的に違う点です。従来の検索結果は10位でも20位でもリンクとして一応表示され、ユーザーが下までスクロールすれば見える余地がありました。しかしAI検索の選抜は、上位の少数だけをAIに渡し、残りは事実上「無かったこと」になります。順位が少し下という中間はなく、選ばれるか・選ばれないかの二択に近いです。だからこそ、質問の意味に対して自社コンテンツをどれだけ近い座標へ寄せられるかが死活的に重要になります。
さらに、ベクトル検索はチャンク（＝文書を数百字程度に分割したかたまり）単位で行われるのが一般的です。したがって、拾われる対象はページ全体ではなく個々のブロックです。ページのどこか1箇所に良い記述があっても、そのブロック単体で意味が完結していなければ、切り出された瞬間に意味を失い、質問との近さが下がります。「1見出し1論点」「結論先出し」といったAIO実務の定石は、このチャンク単位のベクトル照合に最適化された書き方だと言えます。
ベクトル検索は、事前準備（インデックス作成）と検索実行の2段階で動きます。
- 対象の文書群を、意味のまとまりごとにチャンク（かたまり）へ分割します。
- 各チャンクを埋め込みモデルでベクトルに変換します。
- ベクトルをベクトルデータベース（＝ベクトルを大量に保存し近傍探索できる保管庫）へ、元の文章とひも付けて格納します（ここまでが事前準備）。
- 検索実行時、ユーザーの質問を同じモデルでベクトル化します。
- 近似最近傍探索（ANN＝厳密でなくとも十分近いものを高速に探す手法）で、質問ベクトルに近い文書ベクトルを取り出します。
- 必要に応じてリランキング（＝高精度モデルで並べ替え）で上位を精査し、最終的な関連文書を確定します。
候補が数百万件を超えると、すべてのベクトルと距離を総当たりで比べるのは非現実的です。そこでANNが使われ、多少の取りこぼしを許容する代わりに桁違いの速度を得ます。この高速化があるからこそ、質問のたびに大量文書と意味照合するAI検索が、実用的な待ち時間とコストで成立しています。
キーワード検索とベクトル検索の使い分け| 場面 | キーワード検索が有利 | ベクトル検索が有利 |
|---|
| 固有名詞・型番 | ○（完全一致で確実） | △（近い別物を拾う恐れ） |
| 言い換え・同義 | ×（別単語だと外す） | ○（意味で一致） |
| 意図のあいまいな質問 | △ | ○（意味で寄せられる） |
| 短い記号的クエリ | ○ | △ |
| 実務の結論 | 併用（ハイブリッド検索）が有効 | 併用（ハイブリッド検索）が有効 |
横にスクロールできます
キーワード検索とベクトル検索の差は、次のような質問で顕著に出ます。
- 質問「引っ越し前にやることは？」に対し、「転居時の手続きチェックリスト」というページ：共通単語は少ないが、ベクトル検索なら意味が近く拾えます。
- 質問「iPhone 15 Pro のバッテリー交換費用」：型番はキーワード検索で確実に当て、「費用感」の周辺はベクトル検索が補います（＝ハイブリッドが最適）。
- 質問「会社を辞めたい」：「退職の進め方」「離職の手順」といった別表現のページを、ベクトル検索が意味の近さで束ねて拾います。
この特性から、AI検索を意識したコンテンツでは、想定される多様な言い回し（ユーザーが実際に打ち込む自然な表現）に意味を寄せることが有効です。ただし、固有名詞・数値・型番のように「正確な一致が価値になる情報」は、あいまいに言い換えず正確に明記することが、ハイブリッド検索のキーワード側で確実に拾われるために重要です。
もう1つ実務で効くのが、質問文そのものに近いブロックを用意することです。ベクトル検索は質問ベクトルと文書ベクトルの近さで並べるため、ユーザーが投げそうな問いを見出しやFAQの質問文として本文に含めておくと、その質問ベクトルに強く反応するブロックができます。「〇〇の解約方法は？」という見出しを立て、直後に手順を置く、といった構成は、読者にとって分かりやすいだけでなく、ベクトル検索の照合とも正面からかみ合います。人間向けの親切な構成が、そのままベクトル検索対策になる好例です。
一方で、ベクトル検索の弱点も正しく理解しておく必要があります。意味が近いものを広く拾う性質は、裏を返せば「近いけれど答えではないもの」まで拾いやすいということです。たとえば型番「XYZ-100」の質問に、意味の近い別型番「XYZ-200」を混ぜて返すことがあります。また、否定表現（「〇〇でない方法」）の意味を取り違え、逆の内容を近いと判定する場合もあります。こうした苦手は、キーワード検索での完全一致や、リランキングでの精査によって補うのが実務の定石です。ベクトル検索を過信せず、その限界を織り込んだ設計にすることが、精度の安定につながります。
ベクトル検索を支える基盤が、ベクトルデータベース（＝大量のベクトルを保存し、近いものを高速に探せる専用の保管庫）です。一般的なデータベースが「IDが一致する行」を引くのに対し、ベクトルデータベースは「与えられたベクトルに近いベクトル」を引くことに特化しています。ここで問題になるのが計算量です。候補が数百万〜数億件になると、質問ベクトルと全件の距離を1つずつ計算する総当たり（＝厳密最近傍探索）は、待ち時間もコストも現実的でなくなります。
この壁を越えるのが近似最近傍探索（ANN＝Approximate Nearest Neighbor）です。ANNは、あらかじめベクトルを「近いもの同士が集まる」ような索引構造に組み上げておき、検索時にはその構造をたどって、厳密な最短ではないが十分に近い候補を高速に取り出します。多少の取りこぼし（＝本来もっと近いものを見逃す確率）を許容する代わりに、総当たりよりはるかに速く答えを得るのが基本的な考え方です。AI検索が質問のたびに大量文書と意味照合できるのは、このANNによる高速化があるからです。裏を返せば、ANNは近似であるため、「上位に来なかった＝関連が薄い」とは限らず、索引の作り方次第で拾い漏れが起きうる、という限界も抱えます。
ハイブリッド検索では、キーワード検索とベクトル検索という異なる基準の結果を1つの順位にまとめる必要があります。ここでよく使われるのが、両者の順位を統合するスコア合成（＝それぞれの順位や点数を一定のルールで足し合わせ、総合順位を作る方式）です。これにより、固有名詞をキーワード側で確実に拾いつつ、言い換えをベクトル側で補い、双方の長所を1つの結果に反映できます。多くの企業内検索・AI検索がこの統合方式を採るのは、単独方式では必ずどちらかの弱点が検索漏れとして表面化するからです。
厳密探索と近似探索（ANN）の違い| 観点 | 厳密最近傍探索 | 近似最近傍探索（ANN） |
|---|
| 正確さ | 常に最も近いものを返す | 十分近いものを返す（取りこぼしあり） |
| 速度 | 件数が増えると遅い | 大規模でも高速 |
| コスト | 大規模では高い | 抑えられる |
| 実務での採用 | 小規模・精度最優先 | AI検索など大規模の標準 |
横にスクロールできます
- ベクトル検索なら意味が分かるのでキーワードは不要、という誤解：型番・固有名詞・数値は完全一致が効くため、正確な明記は依然として重要。
- 近いものが出れば正しい、という誤解：近さ（関連性）は正しさ（正確性）を保証しません。関連はあるが誤った文書も拾われることがあります。
- ページ単位で拾われる、という誤解：実際はチャンク単位。ブロック単体で意味が完結していないと近さが下がります。
- モデルは何でもよい、という誤解：日本語の意味関係を適切に捉えられる埋め込みモデルかどうかで、日本語検索の精度は大きく変わります。
- 主要トピックごとに、ユーザーが使う自然な言い回しを想定し、その意味に寄る本文を用意します。
- 見出しブロックを1論点に絞り、チャンク単体で読んでも意味が通るように結論・定義を前半へ置きます。
- 固有名詞・型番・数値・日付は言い換えず正確に明記し、ハイブリッド検索のキーワード側でも確実に拾わせます。
- 同義語・表記ゆれを自然な範囲で併記し、意味の網を広げます（不自然な羅列はしません）。
- FAQ形式など「質問文そのもの」を含むブロックを設け、質問ベクトルとの近さを高めます。
ベクトル検索とキーワード検索は、結局どちらを使えばいいですか。
多くの場合は両方です。固有名詞や型番の完全一致はキーワード検索、言い換えや意図の一致はベクトル検索が得意なため、両者を統合するハイブリッド検索が最も安定します。片方だけに寄せると、それぞれの弱点がそのまま検索漏れになります。
ベクトル検索で上位に出れば、必ずAIの回答に載りますか。
必ずではありません。ベクトル検索は「関連文書の候補を集める」工程で、その後リランキングでの絞り込みや、AIが実際にどの文を使うかという判断が続きます。候補に入ることは必要条件ですが、十分条件ではありません。
自社で何を用意すればベクトル検索に強くなりますか。
ブロック単位で意味が完結し、質問の言い回しに意味が近いコンテンツです。結論先出し・1見出し1論点・自然な同義表現の併記が有効で、これはRAG型AI検索の選抜工程と直接かみ合います。
ベクトル検索の結果に自社が入っているか、自分で確認できますか。
直接の可視化は難しいものの、AI検索に想定質問を投げて自社が回答・出典に現れるかを繰り返し観測すれば、拾われているかの目安になります。現れない質問は、意味が質問に寄っていないか、ブロックの意味が完結していない可能性が高く、コンテンツ改善の手がかりになります。
