生成AIで頻繁に使われる「ベクトル検索」とは、テキストや画像を数値ベクトル（embedding）に変換し、意味的に近い情報を高速に検索する技術です。
従来のキーワード検索では拾えなかった「言い換え」「文脈」「意図の近さ」を捉えられる点が大きな特徴で、RAG（検索拡張生成）や社内ナレッジ検索の中核技術として活用されています。
本記事では、ベクトル検索の基本から、実務で精度を左右する設計ポイント、よくある注意点までを整理します。
ベクトルとは何か：文章を「意味の座標」に変換する
ベクトル検索では、まず文章を embedding（埋め込み）モデル に入力し、数百〜数千次元の数値配列に変換します。
この数値ベクトルは、
- 意味が近い文章ほど
- 数値空間上で近い位置に配置される
ように学習されています。
たとえば
- 「返金したい」
- 「購入をキャンセルしたい」
といった表現は単語レベルでは異なりますが、意味が近いため、ベクトル空間では距離が近くなります。
ベクトル検索の基本フロー（RAGでの典型構成）
生成AIと組み合わせる場合、以下の流れが一般的です。
- ドキュメントを適切な単位で分割（チャンク化）
- 各チャンクを embedding してベクトル化
- ベクトルDBや検索エンジンに保存・インデックス化
- ユーザーの質問も embedding してベクトル化
- ベクトル距離が近い上位K件を検索
- 取得した文章を LLM に渡して回答を生成
この「検索部分」の品質が低いと、生成AIは誤った根拠をもとに回答してしまうため、RAG全体の精度はベクトル検索設計に大きく依存します。
類似度の測り方：距離関数の考え方
ベクトル同士の近さは、主に以下の方法で測定されます。
- コサイン類似度：方向の近さを測る（長さの影響を受けにくい）
- 内積（dot product）：計算効率が高いケースが多い
- ユークリッド距離（L2）：幾何学的な距離
どれを使うべきかは embedding モデルや検索基盤の実装に依存するため、モデル提供側の推奨に従うのが安全です。
ベクトル検索の強みと限界
得意な領域
- 言い換え・類義語・表現揺れへの対応
- ユーザーが正式名称を知らない質問
- FAQ、マニュアル、議事録などの意味検索
単体では苦手になりやすい領域
- 厳密な数値条件や範囲指定
- 型番・注文番号・エラーコードなどの完全一致
- 「最新のみ」「特定日付以降」といった条件
これはベクトル検索が使えないという意味ではなく、意味空間だけで厳密条件を保証するのが難しいという特性によるものです。
そのため、実務では次に紹介するハイブリッド検索がよく採用されます。
ハイブリッド検索：ベクトル検索 × キーワード検索
多くの現場では、以下を組み合わせます。
- キーワード検索（BM25など）：完全一致・固有名詞に強い
- ベクトル検索：意味的な近さに強い
両者の検索結果をスコア融合（例：RRFなど）することで、「どちらかでしか拾えない情報」を補完でき、検索の安定性が向上します。
実務的な使い分け例
- 型番・固有名詞 → キーワード検索が有効
- 相談文・自然文質問 → ベクトル検索が有効
- 実運用 → 両方を併用する構成が最も安定
精度を左右する設計ポイント①：チャンク設計
ベクトル検索の品質は、ドキュメントをどう分割するかで大きく変わります。
チャンクが大きすぎる場合
- 話題が混ざり、embedding が曖昧になる
- 検索結果が冗長になりやすい
小さすぎる場合
- 文脈が失われ、意味が薄くなる
- 似た断片が大量にヒットしやすい
一般的な初期値の一例
- 300〜800トークン程度
- オーバーラップ：50〜150トークン程度
ただしこれはあくまで出発点であり、ドキュメントの種類や質問の傾向、rerankの有無によって最適値は変わります。
最終的には評価指標を使って調整するのが前提です。
精度を左右する設計ポイント②：メタデータフィルタ
意味検索だけに頼ると、無関係な文書が混ざることがあります。
そこで重要になるのが メタデータによる事前絞り込みです。
例
- ドキュメント種別（FAQ / 仕様 / マニュアル）
- 製品名・部署・言語
- 更新日・公開範囲・権限情報
理想的な流れ
- メタデータ条件で候補を限定
- その中でベクトル検索を実行
これにより、ノイズが大幅に減少します。
精度を左右する設計ポイント③：再ランキング（rerank）
ベクトル検索は「候補収集」は得意ですが、上位の並び順は必ずしも最適ではありません。
そこでよく使われるのが 2段階検索です。
- embedding検索で広めに候補を取得
- reranker（多くはクロスエンコーダ）で質問と文書を同時に評価し、並び替え
- 上位数件のみを LLM に渡す
候補数（例：数十〜数百件）は、精度とレイテンシのバランスを見て調整します。
検索だけでは不十分：生成AI側での工夫
RAGでは、検索結果の「渡し方」も重要です。
- 重複チャンクの除去
- 類似しすぎた結果の分散（MMRなど）
- 要点を保ったままの簡潔な提示
- 回答と根拠の紐付け（出典明示）
これらを行わないと、検索自体が正しくても回答が不安定になります。
評価と改善：感覚に頼らないために
検索単体の評価
- Recall@K
- MRR、nDCG
RAG全体の評価
- 回答の正確性
- 根拠との整合性
- 不要な推測や断定がないか
「質問 → 正解根拠（どの段落が答えか）」をセットにした評価データを用意すると、改善が進めやすくなります。
まとめ
- ベクトル検索は「意味検索」に強いが、万能ではない
- ハイブリッド検索、メタデータ、rerankを組み合わせることで実務品質に近づく
- 数値や設計値に絶対解はなく、評価しながら調整する前提が重要
生成AIの検索精度は、モデル選定以上に 設計と運用で差が出ます。
目的（FAQ削減、社内検索、コンテンツ検索など）に応じて、最適な構成を設計することが成功の鍵になります。
