ベクトルデータベース

Vector Database

ai data beginner

意味を数値化したベクトルを保存し、意味の近いものを高速に探せるようにしたデータベースのこと。

概要（サマリー）

ベクトルデータベースとは、意味を数値化したベクトルを保存し、意味の近いものを高速に探せるようにしたデータベースのことである。

普通のデータベースが「IDが100番の行を出して」「名前が田中の人を探して」という一致を得意とするのに対し、ベクトルデータベースは「この文章に一番意味が近いものを5件出して」という近さを得意とする。図書館にたとえるなら、前者が請求番号で1冊を取り出す仕組み、後者が「この本と似た本」を棚全体から探す仕組みにあたる。

エンベディングで作った座標を保存する置き場であり、RAGを作るときの部品として登場することが多い。

詳細解説

なぜ専用のデータベースが要るのか

「近いものを探すだけなら、全部と比較すればいい」と思うかもしれない。実際、件数が少なければそれで足りる。

問題は件数が増えたときだ。1536次元のベクトルが10万件あると、1回の検索で10万回の距離計算が必要になる。100万件なら100万回である。これを検索のたびに行うと、応答が数秒〜数十秒かかってしまう。

ベクトルデータベースは、この総当たりを避けるための工夫を持っている。近そうな候補だけを絞り込んでから比較することで、件数が増えても現実的な速さを保つ。この絞り込みの仕組みが、通常のデータベースのインデックスにあたる役割を果たしている。

近似最近傍探索という考え方

その工夫の中心にあるのが「近似最近傍探索」と呼ばれる方法である。名前のとおり、厳密に一番近いものを探すのをあきらめる代わりに、圧倒的な速さを得る。

厳密に探す: 100万件と全部比較する。正確だが遅い
近似で探す: 「たぶんこのあたり」と当たりを付けて数千件だけ比較する。ごくまれに取りこぼすが、非常に速い

検索結果として「99%の確率で正しい上位5件」が一瞬で返るなら、実用上はそれで十分というわけである。多くのベクトルデータベースは、この精度と速度のバランスを設定で調整できるようになっている。

保存されるもの

ベクトルだけを保存しても使い物にならない。実際には3点をセットで保存する。

ベクトル: 意味の座標。検索に使う
元のテキスト: 検索でヒットしたときに、実際に表示・利用する中身
メタデータ: ファイル名・URL・作成日・カテゴリなど、絞り込みや出典表示に使う情報

メタデータは軽視されがちだが重要である。「2025年以降の文書に限定して意味検索する」「特定のカテゴリだけから探す」といった絞り込みは、メタデータがあって初めてできる。RAGで出典を表示するときにも使う。

代表的なサービス・製品

用途と規模によって選択肢がある。

Pinecone: 運用不要のクラウドサービス。手軽に始められる
Qdrant / Weaviate / Milvus: オープンソース。自前で動かせる
Chroma: 軽量で、手元の開発や小規模用途に向く
pgvector: PostgreSQL の拡張機能。既存のデータベースにベクトル検索を足せる
Supabase: pgvector を組み込んだ形で提供している

規模が小さいうちは、専用サービスを導入せず pgvector のように既存のデータベースへ機能を足す形で足りることも多い。数千件程度なら、ファイルに保存して全件比較するだけでも実用になる。「まずベクトルデータベースを選ぶ」のではなく、必要になってから選ぶほうが無駄がない。

基本的な使い方

操作は「入れる」と「近いものを探す」の2つが中心である。

# 1. 保存する（ベクトル・元テキスト・メタデータをセットで）
collection.add(
    ids=["doc-001"],
    embeddings=<a class="internal-link" href="https://noveblo.com/glossary/0.013, -0.027, 0.44, ....html" target="_blank" rel="noopener noreferrer">0.013, -0.027, 0.44, ...</a>,
    documents=["有給休暇は入社6か月後から10日付与される。"],
    metadatas=[{"source": "就業規則", "section": "第32条"}]
)

# 2. 意味が近いものを探す（質問文もベクトル化してから渡す）
hits = collection.query(
    query_embeddings=[question_vec],
    n_results=3,
    where={"source": "就業規則"}   # メタデータで絞り込める
)

n_results が取り出す件数、where がメタデータによる絞り込みである。この2つを調整するのが実務上のチューニングの中心になる。

通常のデータベースとの使い分け

置き換えるものではなく、役割が違う。

	通常のデータベース	ベクトルデータベース
得意な問い	条件に一致するものを出す	意味が近いものを出す
探し方	完全一致・範囲・部分一致	距離の計算
結果	条件に合う全件	近い順に上位N件
苦手なこと	表現の揺れ	型番や名前の完全一致

実務では併用する。ユーザー情報や注文履歴は通常のデータベース、文書の意味検索はベクトルデータベース、という分担になる。NoSQLと同じく、「万能の置き換え」ではなく用途特化の道具だと考えるのが正しい。

運用で気をつけること

モデルを変えたら作り直し: エンベディングのモデルを変更すると座標系が変わるため、保存済みの全ベクトルを再計算する必要がある
元データの更新に追随する: 文書を書き換えたら、対応するベクトルも更新しないと古い内容がヒットし続ける
費用: ベクトルは1件あたりのデータ量が大きい。100万件規模になると保存費用が無視できなくなる
削除の反映: 元の文書を消したのにベクトルが残っていると、存在しない資料を根拠に回答してしまう

とくに2つ目と4つ目は、RAGの回答が「なぜか古い」「消したはずの情報を答える」という不具合の原因になりやすい。

AIコーディングとの関係

AIに「ベクトルデータベースを使った検索を作って」と頼むと、たいてい何らかの製品を勝手に選んでコードを書き始める。あとから移行するのは手間なので、先に指定したい。

使う製品（あるいは「まずは外部サービスを使わない形で」と伝える）
保存する件数の見込み（数千件なのか、100万件なのか）
一緒に保存したいメタデータ
絞り込み条件が必要かどうか

たとえば「記事500本ぶんの検索を作りたい。まずは外部サービスを使わず、SQLiteとファイルで完結する構成にして。元テキストとファイル名・更新日も一緒に保存し、日付で絞り込めるようにして」と伝えれば、規模に見合ったものが出てくる。

生成後に確認したいのは、削除と更新の処理があるかである。AIは「保存する」「検索する」のコードは書いてくれるが、更新と削除を書き忘れることが多い。これがないと、運用を始めた途端に古いデータが残り続ける。

よくある勘違い

ベクトルデータベースがないとRAGは作れない？

作れる。文書が数百件程度なら、ベクトルをファイルに保存して全件比較するだけで十分に速い。ベクトルデータベースが必要になるのは、総当たりでは間に合わない規模になってからである。最初から導入すると、運用の手間だけが増えることもある。

通常のデータベースの置き換え？

役割が違う。ユーザー管理や在庫管理のような、条件に一致するデータを正確に取り出す用途には向かない。既存のデータベースを置き換えるのではなく、意味検索という機能を足すために併用するものである。

ベクトルを入れれば意味検索の精度が出る？

精度を決めるのは、どのエンベディングモデルを使うか、文書をどう分割するか、という前段の設計である。ベクトルデータベースは保存と検索を速くする道具であって、意味の理解そのものはしていない。

検索結果は必ず一番近いものが返る？

多くの製品は近似最近傍探索を使うため、厳密な最上位が返る保証はない。実用上はほぼ問題にならないが、「必ず正確な順位が必要」な用途では設定を厳密側に寄せるか、件数を多めに取り出してから絞る必要がある。

まとめ

ベクトルデータベースは、意味を数値化したベクトルを保存し、近いものを高速に探すためのデータベースである
全件比較を避ける近似最近傍探索により、件数が増えても現実的な速さを保つ
ベクトル・元テキスト・メタデータの3点をセットで保存する
通常のデータベースの置き換えではなく、用途を分けて併用する
数百件規模なら不要なこともある。必要になってから選べばよい

情報ソース

より詳しくAIに聞いてみよう

ベクトルデータベースが必要になるのはどれくらいの規模からか、判断の目安を教えてください。
近似最近傍探索がなぜ速いのかを、初心者向けに仕組みから説明してください。
pgvector と専用のベクトルデータベースを比べたとき、それぞれどんな場合に向いていますか。
ベクトルデータベースで元データの更新・削除を反映し忘れると、どんな問題が起きますか。
AIに意味検索の実装を頼むとき、更新・削除処理まで含めてもらうにはどう指示すればよいですか。