ベクトルデータベースは、似た意味をどう探すのか

インターネットや業務システムで情報を探す際、頭に浮かんだ言葉と文書中の表現が完全に一致するとは限りません。従来のキーワード検索では、入力した単語そのものが文書に含まれていなければヒットしませんでした。例えば「散歩が好きな小型のペット」と検索したとき、検索語と同じ表現がそのまま含まれていなくても、「トイプードル」や「室内犬の飼い方」といった関連文書を探し出したい場面があります。 この「言葉の字面にとらわれず、意味の関連性に基づいて探す」仕組みを実現するのが、埋め込みモデルとベクトルデータベースを組み合わせた「ベクトル検索」です。 コンピュータは言葉の意味をどのように数値へ変換し、膨大なデータから似た意味を探し出しているのでしょうか。幾何学的な計算の仕組みから実務上の工夫、知っておくべき限界までを解説します。

---

1. 文字の一致から「意味の近さ」へ：ベクトル検索の基本原理

キーワード検索の限界とベクトル検索

従来のキーワード検索（完全一致や部分一致）は、文書中に指定した文字列（字面）が存在するかどうかを機械的に判定します。型番や固有名詞をピンポイントで探す用途には適していますが、表現のゆらぎや同義語、文脈のニュアンスを柔軟に汲み取ることは困難です。 これに対しベクトル検索は、単語や文章を多次元の数値リスト（ベクトル）へ変換し、空間上の「幾何学的な位置の近さ」によって関連性を判定します。これにより、検索文と対象文書の間で使われている単語が一致していなくても、意味的に関連のある候補を見つけ出せます。

埋め込みモデルとベクトルデータベースの役割分担

ベクトル検索システムは、大きく「埋め込みモデル」と「ベクトルデータベース」の2つで構成され、両者の役割は明確に分かれています。

• 埋め込みモデル（Embedding Model）：文章や画像などの非構造化データを受け取り、文脈的な特徴を数百〜千次元以上の数値の並び（埋め込みベクトル）へと変換するニューラルネットワークです。言語を多次元の座標へ変換する「翻訳」の役割を担います。
• ベクトルデータベース（Vector Database）：生成された大量のベクトルを保存・インデックス化し、検索クエリのベクトルとの幾何学的距離を高速に計算して近い候補を抽出・管理するストレージです。

文章を空間上の座標へ変換するのがモデルの仕事であり、その座標群を保存して素早く探し出すのがデータベースの仕事です。

同一空間への配置という大前提

ベクトル検索が正しく機能するには、検索対象の文書群とユーザーの検索クエリが、互換性のある同一の埋め込みモデルによって同一の多次元空間に変換されていることが絶対的な前提条件となります。 もし文書群をモデルAでベクトル化し、検索クエリを別のモデルBでベクトル化すると、モデルごとに座標軸の意味やスケールが全く異なるため、距離や角度を計算しても数学的・意味論的に無意味な結果しか得られません。多言語検索やマルチモーダル検索（テキストから画像を検索するなど）であっても、同一の共有潜在空間を形成するよう共同訓練された互換モデルを用いる必要があります。

分布仮説と2次元モデルの限界

埋め込みモデルが文章を数値化する背景には、言語学の「分布仮説（似た文脈に出現する単語は似た意味を持つ）」があります。深層学習モデルは膨大なテキストから単語や文脈の共起パターンを統計的に捉え、意味が近い表現を多次元空間上の近い位置に配置するよう最適化されます。ただし、これは文脈の学習に基づく統計的推測であり、意味が似ている語が常に幾何学的に近接することを論理的・絶対的に保証するものではありません。 また、解説でよく用いられる「横軸を動物らしさ、縦軸をサイズ」とした2次元の直交座標系は、幾何学的直感を助けるための模式化（説明用モデル）にすぎません。実際の深層学習モデルが構築する意味空間（潜在空間）は数百〜数千次元（例：768次元、1536次元など）の高次元空間です。高次元空間では、特定の1軸が特定の単語概念と一対一で対応するわけではなく、無数の次元が組み合わさった分散表現として意味が形成されています。

---

2. 「近さ」を測る幾何学：ユークリッド距離とコサイン類似度

幾何学的近さを測る2つの尺度

文章がベクトルとして表現されたとき、コンピュータは「意味が似ているか」を「空間上で幾何学的に近いか」という問題に置き換えて計算します。代表的な尺度は「ユークリッド距離」と「コサイン類似度」の2つです。

1. ユークリッド距離（L2距離）

空間内の2点間の直線距離を測る尺度です。クエリベクトルを q = (q_1, \dots, q_n)、文書ベクトルを v = (v_1, \dots, v_n) とすると、以下の式で定義されます。

d(q, v) = \sqrt{\sum_{i=1}^n (q_i - v_i)^2} 値が小さく 0$ に近いほど、空間上で2点が物理的に近接していることを示します。

1. コサイン類似度

2つのベクトルがなす角度 \theta のコサイン値を測る尺度で、ベクトルの向き（方向）の近さを評価します。内積とノルム（大きさ \|q\| = \sqrt{\sum q_i^2}）を用いて次のように定義されます。

\cos(q, v) = \frac{q \cdot v}{\|q\| \|v\|} = \frac{\sum_{i=1}^n q_i v_i}{\sqrt{\sum_{i=1}^n q_i^2} \sqrt{\sum_{i=1}^n v_i^2}} 値の範囲は -1 から 1 で、1 は向きが完全に一致、0 は直交（無相関）、-1$ は真逆の向きを示します。

ただし、コサイン類似度の幾何学的状態（同方向・直交・反対方向）を、言葉の「意味の一致」「無関係」「対義語」と安易に同一視してはなりません。言葉の対義語が空間で必ず真逆を向くわけではなく、直交するからといって完全に独立した意味概念であるとも限りません。また、「文章が長いほどベクトルの長さ（ノルム）が大きくなる」という説明も誤りです。埋め込みモデルの出力次元数は固定されており、ノルムは文章の文字数に単純比例しません。

正規化条件下での数学的関係式

実務システムでは、計算コスト削減や検索の一貫性を保つため、ベクトルのノルムが 1 になるよう単位長に正規化（\|q\| = 1, \|v\| = 1）して保存することが一般的です。 すべてのベクトルが正規化されている条件下では、ユークリッド距離の2乗 \|q - v\|^2 とコサイン類似度 \cos(q, v) の間に以下の数学的等式が厳密に成り立ちます。

\|q - v\|^2 = (q - v) \cdot (q - v) = \|q\|^2 - 2(q \cdot v) + \|v\|^2 = 1 - 2\cos(q, v) + 1 = 2 - 2\cos(q, v)$ この式から明らかなように、正規化されたベクトル同士を比較する場合、コサイン類似度が最大となる候補はユークリッド距離が最小となる候補と完全に一致します。したがって、この条件下ではどちらの尺度を採用しても検索結果の順位は変わりません。

ノルムが異なる場合の順位逆転：独立した検算例

しかし、ベクトルが正規化されていない（ノルムが異なる）場合、ベクトルの「向き」を測るコサイン類似度と、「直線距離」を測るユークリッド距離の間で順位の逆転が発生します。以下の2次元の検算例で確認できます。

• 検索クエリ：q = (1, 1)
• 候補文書A：A = (2, 2)
• 候補文書B：B = (1, 0)

各候補の尺度を計算します。

【コサイン類似度の計算】

• 内積：q \cdot A = 1 \times 2 + 1 \times 2 = 4、q \cdot B = 1 \times 1 + 1 \times 0 = 1
• ノルム：\|q\| = \sqrt{1^2 + 1^2} = \sqrt{2} \approx 1.414、\|A\| = \sqrt{2^2 + 2^2} = 2\sqrt{2} \approx 2.828、\|B\| = \sqrt{1^2 + 0^2} = 1.0
• コサイン類似度：

\cos(q, A) = \frac{4}{\sqrt{2} \times 2\sqrt{2}} = \frac{4}{4} = 1.0 \cos(q, B) = \frac{1}{\sqrt{2} \times 1} = \frac{1}{\sqrt{2}} \approx 0.7071

• 順位：1位 A (1.0) ＞ 2位 B (約0.707)

【ユークリッド距離の計算】

• d(q, A) = \sqrt{(1 - 2)^2 + (1 - 2)^2} = \sqrt{1 + 1} = \sqrt{2} \approx 1.414
• d(q, B) = \sqrt{(1 - 1)^2 + (1 - 0)^2} = \sqrt{0 + 1} = 1.0
• 順位（値が小さい順）：1位 B (1.0) ＞ 2位 A (約1.414)

このように、向きを重視するコサイン類似度では A が上位ですが、原点からの直線距離を重視するユークリッド距離では B が上位になります。非正規化ベクトルでは、採用する尺度によって順位が根本的に変わり得ます。

ゼロベクトルの数学的未定義性と操作ツール

幾何学的尺度における重要な例外が「ゼロベクトル \mathbf{0} = (0, \dots, 0)」です。ゼロベクトルはノルムが \|\mathbf{0}\| = 0 となるため、ユークリッド距離は計算できるものの、コサイン類似度は分母にノルムが現れるためゼロ除算（0/0）が発生し、数学的に値が定義されません（未定義）。システム実装ではゼロベクトル入力への例外処理や事前バリデーションが必須です。

上記の操作ツール（vector-search--tool-01）は、幾何学的な位置関係と計算尺度（ユークリッド距離およびコサイン類似度）の違いを視覚的に体験できるシミュレータです。角度が一致していても距離が離れているケースや、角度がずれていても直線距離が近いケースを動的に確認できます。 ただし、本ツールに組み込まれている固定データは、幾何学的計算の振る舞いを理解するための「架空の2次元数値」です。実際の深層学習モデルが構築する数千次元の高次元空間や、現実の文書の意味関係そのものを表したものではないという限界を理解した上で、計算ルールの確認用として活用してください。

---

3. なぜ高速に探せるのか：Sentence-BERTの事前計算とHNSW

深層学習モデルによる検索の計算負荷問題

初期の大規模言語モデル（BERTなど）を情報検索に応用する際、最大の障害となったのが計算負荷でした。 従来の方式（クロスエンコーダ型）は、検索クエリとデータベース内の文書をペアとしてモデルに入力し、巨大なニューラルネットワークの多層構造の中で双方向の注意機構（アテンション）を計算して類似度を算出します。この手法は極めて高精度ですが、例えばデータベース内に10万件の文書がある場合、1回の検索ごとに10万回の重い推論を実行しなければなりません。これでは検索結果を返すだけで膨大な時間を要し、実用的な対話やWeb検索としては成り立ちませんでした。

Sentence-BERTによる事前計算のブレイクスルー

この問題を解決したのが、Sentence-BERT（SBERT: arXiv:1908.10084）に代表されるバイエンコーダ型の手法です。 SBERTは、文章単体を独立した単一のベクトルとして出力するよう学習されたモデルです。これにより、データベースに登録する数万〜数百万件の文書群を、あらかじめオフラインでベクトル化してデータベースに保存（事前計算）しておくことが可能になりました。 検索時には、ユーザーのクエリ文を1回だけモデルに通してクエリベクトルを生成すれば、あとは保存済みの文書ベクトル群との間で内積や距離を計算するだけで検索が完了します。文章対ごとのモデル推論を繰り返す必要がなくなり、検索レイテンシはミリ秒単位にまで劇的に短縮されました。

小中規模での全件走査と大規模データでのANN

文書ベクトル保存後、最も確実な検索方法は、クエリベクトルと全文書ベクトルとの類似度を1件ずつ計算する「全件走査（ブルートフォース探索 / フラット探索）」です。全件走査はすべての候補を比較するため、100%確実に真の最近傍（最も近いベクトル）を見つけ出せます（厳密探索）。 「総当たり走査は実用不可能」と過剰に否定されることがありますが、これは正確ではありません。現代のハードウェア（CPUのSIMD演算やGPU行列計算）を活用すれば、数千件から数万件程度の小中規模データであれば、全件走査であっても数ミリ秒から数十ミリ秒程度で処理できます。インデックス構築時間やメモリオーバーヘッドがなく、取りこぼし（精度劣化）が原理的に生じないため、小中規模システムでは最も堅牢で実用的な選択肢です。

しかし、データ規模が数十万件から数億件に達すると、全件走査の計算コスト（計算量 O(N)）は許容限界を超えます。そこで実務では、わずかな検索精度（真の最近傍を取りこぼす可能性）を許容する代わりに探索を劇的に高速化する「近似最近傍探索（ANN: Approximate Nearest Neighbor）」が用いられます。

HNSWの多層グラフ構造とトレードオフの真実

現代のベクトルデータベースで最も広く採用されているANNアルゴリズムが、多層グラフ構造を利用する「HNSW（arXiv:1603.09320）」です。 HNSWは、高速リスト探索構造「スキップリスト」の階層概念を空間グラフへと拡張したものです。

• 最上層：少数のノード同士が長距離リンクでまばらに接続されており、探索初期にクエリ方向へ向かって大股で空間内をジャンプします。
• 中間層〜最下層：下層へ降りるにつれてノード数が増加し、短い距離のリンクで密に接続されます。

探索は最上層から開始され、クエリに近いノードを見つけたら1つ下の層へ移動します。これを最下層まで繰り返すことで、空間全体を走査することなく、少ないステップ数で目的の近傍領域へ到達できます。

ただし、HNSWの計算量や検索性能に対する無条件の過信は禁物です。「いかなるデータでも探索計算量が O(\log N) で瞬時に最適解が得られる」という説明は、原典の前提条件を無視した誤解です。 原典論文（arXiv:1603.09320v4 §4.2.1）の対数探索ステップの理論解析は、空間が厳密なDelaunayグラフ構造等を形成できる幾何学的条件を仮定した理想モデルに基づいています。実際のデータベースで構築されるグラフは有限リソースで作られる「近似グラフ」であり、無条件で最悪計算量 O(\log N) が保証されるわけでも、100%確実に真の最近傍が取得できる保証もありません。

HNSWの運用は、常に以下のトレードオフとの調整になります。

• 構築時パラメータ $M$（各ノードの最大接続数）：M を大きくすると接続が密になり精度が向上しますが、インデックス構築時間とメモリ消費量が増大します。
• 探索時パラメータ $efSearch$（探索時に保持する候補リストサイズ）：efSearch を大きくすると真の最近傍を見つけ出せる確率（再現率：Recall）が高まりますが、検索レイテンシが増大します。

許容レイテンシ、メモリ容量、要求される再現率のバランスを測定しながら、パラメータを適切にチューニングすることが不可欠です。

---

4. 弱点を補う実務の工夫：属性フィルタとハイブリッド検索

ベクトル検索が苦手とする領域と役割分担

ベクトル検索は「意味の近さ」を捉える点に優れていますが、万能ではありません。実務において以下の要件には極めて脆弱です。

1. 型番や固有名詞、コードの完全一致（例：「X-500」と「X-501」の区別）
2. 厳密な数値条件や範囲指定（例：「価格が3,000円以下」「在庫あり」）
3. 明示的な否定条件（例：「〜を含まない」）

例えば、型番が1文字違うだけの製品同士は文脈が極めて似通っているため、空間上でほぼ同じ位置に配置されて区別が困難になります。また、数値の大小比較や否定の論理演算を幾何学的距離だけで処理することは原理的に不可能です。 こうした弱点を克服するため、単語の出現頻度に基づく伝統的な「全文検索（BM25等）」とベクトル検索を併用する「ハイブリッド検索」が広く採用されています。 なお、全文検索エンジンを「一文字も違わない完全一致を処理するもの」と断定してはなりません。BM25等もトークン化（形態素解析やN-gram）や大文字小文字の統一、語幹処理などの正規化に依存しています。したがって、システム設計では以下の明確な役割分担が必要です。

• 専用の完全一致フィールド（B-treeインデックス等）：型番や商品IDなどの厳密一致。
• 属性フィルタ：カテゴリ、日付、価格などの構造化メタデータ。
• 全文検索（BM25等）：キーワード出現や専門用語、字面の一致を重視するテキスト検索。
• ベクトル検索：表現のゆらぎや抽象的な概念、意味の類似性を重視する自然言語検索。

独立した3つの処理：属性フィルタ・順位融合・リランキング

実務の検索パイプラインでは、以下の3つの処理が独立したステップとして組み合わされます。

1. 属性フィルタ（Filtering）：メタデータに基づいて候補を絞り込む論理演算です（例：category = 'pets'）。
2. 順位融合（Rank Fusion / RRF）：全文検索とベクトル検索の各順位リストを統合するアルゴリズムです。代表的な手法「RRF（Reciprocal Rank Fusion）」では、各エンジンの順位の逆数から総合スコアを算出します。

RRF\_Score = \sum_{m \in M} \frac{1}{k + rank_m} ここで k は定数、rank_m$ は各エンジンでの順位です。RRFはスコアのスケールが異なる異種検索を安全に統合できますが、順位融合自体は「必須条件を強制する（足切りを行う）」機能ではない点に注意が必要です。

1. 再順位付け（リランキング / Re-ranking）：絞り込まれた上位候補（例：上位50〜100件）に対し、高精度だが重いクロスエンコーダ型モデル等を適用して最終順位を精密に決定する追加処理です。

近似インデックスにおける属性フィルタの罠と反復走査

PostgreSQLの拡張機能「pgvector」などでベクトル検索と属性フィルタを併用する際、インデックスの物理走査順序に起因する「件数不足問題」が発生することがあります。 属性フィルタの適用方式には主に以下の2通りがあります。

• pre-filtering：先に属性フィルタで絞り込んでからベクトルを検索する。
• post-filtering：先にベクトルインデックス（HNSW等）を走査して上位候補を取得し、その後に属性フィルタを適用して不一致の候補を破棄する。

post-filteringにおいて、近似インデックス走査で取得した上位 K 件の中に属性条件を満たすデータがごくわずかしかない場合、要求した取得件数（LIMIT）に満たないまま結果が返される「件数不足（フィルタ落ち）」が起こります。例えば全データ中に対象カテゴリが1%しかない場合、近似走査で100件取得してもフィルタ通過が0〜1件になってしまいます。 この問題を解決するため、pgvector等では「反復インデックス走査（Iterative Index Scans）」が導入されています。要求件数が満たされるまでグラフ探索を継続して候補を補充する仕組みです。

ここで重要なのは、「SQLなどのクエリで記述される論理条件」と「データベースが内部で実行する物理的な走査順序」を混同しないことです。

SELECT id, content 
FROM documents 
WHERE category = 'pets' 
ORDER BY embedding <=> query_vector 
LIMIT 10;

このSQL文は「petsカテゴリ内で最も類似する10件を返す」という論理的な要求にすぎません。データベースが物理的に属性インデックスを先に使ったのか、HNSW走査後にフィルタしたのか、反復走査を実行したのかは、インデックス構成やオプティマイザの判断によります。信頼性の高いシステム設計には、この物理挙動を正しく把握することが不可欠です。

---

5. 幾何学的類似度と事実の真偽：意味の近さが保証しないこと

幾何学的類似度は「事実の正しさ」を証明しない

ベクトル検索を検索拡張生成（RAG）などのAIシステムに組み込む際、最も警戒すべき誤解は「類似度スコアが高い検索結果は、客観的事実として正しい情報である」という思い込みです。 埋め込みモデルが出力するベクトル空間上の類似度（幾何学的な近さ）は、単語や文脈の出現パターンの統計的類似性を示しているにすぎず、記述内容が客観的事実として正しいことや論理的に妥当であることを何一つ証明しません。埋め込みモデルはファクトチェッカーではなく、真偽を判定する能力は持ちません。

反対の主張や主客の反転が近接する失敗例

文脈やトピックが同一であれば、正反対の主張や論理が破綻した文章であっても高い類似度スコアを記録してしまう失敗例が起こり得ます。 例えば、「天動説」を肯定する言説と「地動説」を説明する文章を比較した場合、どちらにも「太陽」「地球」「惑星」「公転」といった天文学的語彙が高密度で共通出現します。埋め込みモデルはこれらを「天体の運動に関する話題」として捉えるため、文脈パターンが似ていることで幾何学的に近い位置に配置される可能性が十分にあります。 同様に、「A社がB社を買収した」と「B社がA社を買収した」という主語と目的語が反転した文章や、否定語（「〜ではない」）が含まれる文章でも、話題全体が近ければ高類似度と判定されるリスクが存在します。

一次資料の確認と利用姿勢

したがって、類似度スコアの高さだけを根拠に検索結果を鵜呑みにすることは極めて危険です。 システム設計者や利用者は、提示された文書が信頼できる公式発表や学術的根拠などの一次資料に基づいているかを必ず検証し、情報が作成・更新された日付を確認する運用を徹底しなければなりません。ベクトル検索は「関連しそうな候補を効率よく拾い上げる道具」であり、情報の正確性や真偽を判定する最終的な責任は常に人間と検証プロセス側にあります。

---

6. よくある疑問（FAQ）

Q1: ベクトルの次元数は多ければ多いほど、常に検索精度が向上するのか？

A: 必ずしも向上するとは限りません。次元数を増やすと微細なニュアンスを表現できる可能性が高まる一方、計算負荷、メモリ消費量、インデックス構築時間が次元数に比例して増大します。さらに次元数が極端に高くなると、空間内のあらゆる点同士の距離の差が相対的に小さくなり、近傍探索の識別力が低下する「次元の呪い」の影響も受けやすくなります。実務ではタスクの難易度と計算リソースのバランスを考慮してモデルを選定する必要があります。近年では、必要に応じてベクトルの先頭部分を切り出して次元数を縮小できるMatryoshka Representation Learning（MRL）などの技術も実用されています。

Q2: ベクトルデータベースを導入すれば、生成AIのハルシネーション（誤生成）は完全に防げるのか？

A: 完全に防ぐことはできません。ベクトルデータベースは関連しそうなテキスト断片を検索してLLMに渡す役割を果たしますが、第5節で解説した通り、類似度が高い文書が客観的事実として正しい保証はありません。データベース内に誤った情報、古い規約、矛盾する記述が含まれていれば、ベクトル検索はそれらを高精度に拾い上げてしまい、LLMもそれに基づいて誤った回答を生成します。ハルシネーションを防ぐには、格納する元データの品質管理（データガバナンス）やメタデータによる日付フィルタ、生成後のファクトチェック機構の併用が不可欠です。

Q3: キーワード検索（BM25等）は、将来的にすべてベクトル検索へ置き換わるのか？

A: 完全に置き換わる可能性は極めて低いです。第4節で解説したように、ベクトル検索とキーワード検索はトレードオフの関係にあり、得意分野が根本的に異なります。明確な型番や固有名詞、特定の専門用語を検索する場合、文字の一致を直接評価するキーワード検索やB-treeインデックスの方が圧倒的に高速かつ確実です。一方、抽象的な表現や言い換えを含む曖昧な探索ではベクトル検索が強みを発揮します。現代の情報検索において推奨されるのは、どちらか一方に偏るのではなく、両者の強みを統合したハイブリッド検索と適切な属性フィルタの設計です。

---

7. 結び：仕組みを理解し、適切に使いこなすために

ベクトル検索は、単語の一致という制約を超え、意味の文脈に基づいた柔軟な情報探索を可能にする強力な技術です。 その基盤には、埋め込みモデルによる事前計算、ユークリッド距離やコサイン類似度による幾何学的計算、そしてHNSWをはじめとする近似探索アルゴリズムの精巧な工夫が存在します。 しかし同時に、高次元空間の性質、近似アルゴリズムにおける再現率とのトレードオフ、厳密一致の難しさ、そして「幾何学的類似度は事実の正しさを保証しない」という本質的な限界を理解しておく必要があります。 これらの特性と限界を正しく把握し、属性フィルタやキーワード検索と巧みに組み合わせることで、初めてベクトルデータベースの真の価値を引き出すことができます。

---