ベクトルデータベース

ベクトルデータベースとは

ベクトルデータベース (Vector Database) は、埋め込みベクトル (高次元の数値配列) を保存し、指定した距離尺度でクエリベクトルに近い順に取り出すことへ特化したデータベースである。RAG、セマンティック検索、レコメンデーションの基盤として使われる。値が一致するかを問うのではなく距離の順位を返すため、評価の指標も「一致したか」ではなく「上位 k 件のうち何件が本当の近傍か」になる。

なぜ必要か

通常のデータベースはキーワードの完全一致や部分一致でしか検索できない。しかし、自然言語の検索では「TypeScript 入門」と「JavaScript の基礎」のように、キーワードが一致しなくても意味的に近いドキュメントを見つけたい場面がある。ベクトル DB は、テキストを数値ベクトルに変換し、ベクトル間の距離で意味的な類似度を計算することで、この問題を解決する。

通常の DB: WHERE name = 'Alice'  ← 完全一致
ベクトル DB: 「TypeScript 入門」に意味的に近いドキュメントを検索
  → 「JavaScript の基礎」「フロントエンド開発」がヒット (キーワード一致なし)

距離尺度と正規化の関係

尺度の選択は検索精度に直結する。代表的なものは 3 つある。

• コサイン類似度: ベクトルの向きだけを見る。文書の長さや語数に由来するノルムの差を無視できるため、テキスト埋め込みでの既定的な選択になりやすい。
• 内積 (ドット積): 向きと大きさの両方を見る。ノルムが関連度を担うよう設計されたモデル向け。
• ユークリッド距離 (L2): 空間上の直線距離。

押さえておくべきは、ベクトルを長さ 1 に正規化すると内積とコサイン類似度が一致し、L2 距離で並べた順位もコサイン類似度で並べた順位と一致するという関係である。正規化済みの埋め込みなら 3 つの尺度は実質同じ順位を返すため、尺度の選択が結果を変えるのは正規化していない場合に限られる。逆に、正規化しないまま内積で検索すると、ノルムの大きいベクトルばかりが上位に来る偏りが出る。

どの尺度を使うべきかは埋め込みモデル側の仕様で決まる。Amazon S3 Vectors の案内でも、最も正確な結果を得るには埋め込みモデルが推奨する距離尺度を選ぶよう明記されている (2026 年 8 月時点)。尺度はインデックス作成時に固定される設計が多く、後から変えるには作り直しが必要になるため、最初に確認しておく。

主要なベクトル DB

選定の軸は 2 つある。すでに運用している DB や検索基盤の拡張として足すのか、ベクトル検索専用のエンジンを別に立てるのか。そして、マネージドで済ませるのか自分で運用するのか。既存の検索基盤や PostgreSQL があるなら前者から検討するのが定石で、専用エンジンは規模や機能要件が既存の延長では足りなくなってから効いてくる。

Bedrock Knowledge Bases から選べるストアには、ほかに OpenSearch Serverless、Aurora PostgreSQL、Neptune Analytics なども並ぶ (2026 年 8 月時点)。この領域の対応表は動きが速いので、設計時に公式ドキュメントで現況を取り直す前提で扱う。

OpenSearch でのベクトル検索

knn_vector 型のフィールドを定義し、検索側は knn クエリを投げる。ここで最も間違いやすいのが dimension で、埋め込みモデルの出力次元と一致していなければ登録の時点で弾かれる。モデルを差し替えて次元が変われば、インデックスを作り直して全件を入れ直すことになる。

// インデックスの作成
PUT /documents
{
  "mappings": {
    "properties": {
      "title": { "type": "text" },
      "embedding": { "type": "knn_vector", "dimension": 1024 }
    }
  }
}

// ベクトル検索
POST /documents/_search
{
  "query": {
    "knn": {
      "embedding": {
        "vector": [0.12, -0.34, ...],
        "k": 10
      }
    }
  }
}

エンジンとアルゴリズムは method で明示できる。省略時の既定はバージョンによって変わるため、精度や遅延を詰める段階では明示しておくほうが後から追いやすい。

RAG の中での担当範囲

RAG においてベクトル DB が担うのは、あらかじめ入れておいた文書ベクトルに対する近傍検索の一段だけである。

1. ドキュメントを埋め込みベクトルに変換 (Bedrock の埋め込みモデル)
2. ベクトル DB に保存                      ← ベクトル DB の担当
3. ユーザーの質問を埋め込みベクトルに変換
4. ベクトル DB で類似ドキュメントを検索 (k-NN)  ← ベクトル DB の担当
5. 検索結果 + 質問を生成モデルに渡す
6. 回答を生成

前提は、登録時と検索時で同じモデル、同じ前処理、同じ距離尺度を使うことである。ここが食い違うと、エラーにはならないまま検索結果の質だけが落ちる。分割の粒度や検索結果の渡し方は RAG 側の設計課題で、ベクトルの作り方そのものは埋め込み の側の話になる。

近似最近傍探索 (ANN)

全ベクトルとの距離を総当たりで計算すれば必ず正解が得られるが、計算量は件数に比例して増えるため、規模が大きくなると応答時間に収まらなくなる。ANN は正解の近傍を取りこぼす可能性を受け入れる代わりに、探索範囲を絞って応答時間を縮める。ここで見る指標が recall で、本来の上位 k 件のうち何件を返せたかを表す。探索パラメーターを大きくすれば recall は上がり遅延も伸びる、という一方向のトレードオフのどこに置くかを決める作業になる。取りこぼしが許されない要件なら、ANN ではなく厳密探索を選ぶ (小規模なら総当たりでも十分速い)。

代表的なアルゴリズムは、性質の異なる 3 系統に分かれる。

HNSW と IVF は探索構造の話、PQ は格納形式の話なので、軸が直交していて併用できる。OpenSearch では FAISS エンジンが HNSW と IVF の両方、Lucene エンジンが HNSW を実装しており、PQ は符号化方式として組み合わせて指定する (2026 年 8 月時点)。

フィルターとキーワード検索の併用

実務の検索条件は「この期間の、このカテゴリの文書だけから近いものを探す」という形になりやすい。ここには順序の問題があり、絞り込みを近傍探索の前にかけるか後にかけるかで結果が変わる。後にかける方式 (事後フィルター) は上位 k 件を取ってからその中を絞るため、条件に合う文書が少ないと結果が数件しか残らず、極端な場合は空になる。条件が厳しいほど、先に絞ってから探す方式や厳密探索への切り替えが必要になる。どちらの経路を通るかはエンジンと条件で変わるので、期待した件数が返るかを実データで確かめておく。

意味の近さだけを見る検索は、型番や略語のように語そのものを当てたい場合に弱い。ベクトル検索とキーワード検索を並行して実行し、双方のスコアを正規化して結合するハイブリッド検索が定番の対処になる。尺度の異なるスコアを足し合わせるので、結合前の正規化と重み付けが結果を左右する。

小規模なら専用の仕組みを持たない

数千件程度なら、DynamoDB などにベクトルを配列として保存し、Lambda で全件読み込んでコサイン類似度を計算する方式でも成立する。この規模では総当たりが十分速く、インデックスの構築と運用が要らない分だけ構成が単純になる。応答時間、件数、読み取りコストのいずれかが目に見えて悪化した時点が移行の合図で、そこで OpenSearch のようなインデックスを持つ側へ移す。

基礎から学ぶなら関連書籍が手がかりになる。