はじめに
RAG（検索拡張生成）が広まってから、「ベクトルDB」という言葉をよく見かけるようになりました。
Pinecone、Milvus、Qdrant、Weaviate、pgvectorなど、選択肢も増えています。
そこで気になったのが、次の疑問です。
ベクトルDBは、LLMと一緒に登場した新しい技術なのか？
先に要点をまとめると、ベクトルを使って近いデータを探す考え方と探索アルゴリズムは古く、埋め込みモデル、運用機能、RAGを含む利用需要が近年まとまったと捉えるのがよさそうです。
ただし、「最近傍探索の歴史＝そのままベクトルDB製品の歴史」ではありません。本記事では、両者を分けながらベクトル表現や多次元探索から現在のベクトルDBにつながる、約50年の流れを追います。
※本記事は技術史の入口をつかむための整理メモです。年は論文公開、プレプリント公開、公開リポジトリ作成など、確認できた節目を表します。製品の創業年や正式提供開始年と同じとは限りません。情報は2026年10月1日時点で確認しました。
※本記事の図は、公開論文・公式リポジトリ等の情報をもとに筆者が独自に作成したものであり、各製品・団体の公式資料ではありません。
まず「ベクトル検索」と「ベクトルDB」を分ける
ベクトル検索が解く中心的な問題は、クエリのベクトルに近いベクトルを探すことです。これは最近傍探索（Nearest Neighbor Search）と呼ばれます。
一方、ベクトルDBという呼び名には、一般に探索以外の機能も含まれます。
- ベクトルと元データの保存
- 追加、更新、削除
- メタデータによる絞り込み
- 永続化、バックアップ、可用性
- アクセス制御や分散運用
境界は明確ではありません。専用製品もあれば、pgvectorのように既存DBへベクトル検索を追加する拡張もあります。FaissやAnnoyのような探索ライブラリもあります。
ここを分けると、歴史を追いやすくなります。
古くから研究されてきたのは、主に「どう表現し、どう近いものを探すか」です。近年目立つようになったのは、それをアプリケーションで運用しやすい形にまとめた製品・拡張と、その利用需要です。
ざっくり年表
| 年 | 節目 | 何が重要だったか |
|---|---|---|
| 1975 | Saltonらのベクトル空間モデル | 文書と検索要求をベクトル空間で扱う代表的な枠組み |
| 1975 | Bentleyのk-d木 | 多次元データを分割して探索する索引 |
| 1984 | GuttmanのR木 | 長方形領域を使う空間索引。地理・図形検索の系譜で重要 |
| 1998 | Indyk・MotwaniのLSH | 近似最近傍探索を理論的に扱う代表的な節目 |
| 1999 | Beyerらの高次元最近傍分析 | 高次元で「近い」が判別しにくくなる条件を分析 |
| 2011 | JégouらのProduct Quantization | ベクトルを圧縮し、大規模検索を効率化 |
| 2013 | word2vec | 学習された単語ベクトルを広く普及させた節目 |
| 2016 | HNSWのプレプリント | 多層の近傍グラフを使うANN手法 |
| 2017 | Faiss論文・公開リポジトリ | 大規模な類似検索をライブラリとして利用しやすくした |
| 2010年代後半〜2020年代前半 | 専用DBやDB拡張が増加 | 探索に保存・更新・フィルタ・運用機能を組み合わせた |
| 2020 | RAG論文 | 生成モデルと外部検索を組み合わせる代表的な構成を提示 |
この年表は「ベクトルDB」という単一技術が一直線に進歩した歴史ではありません。情報検索、計算幾何、データベース、機械学習の複数の流れが合流したものです。
1970〜80年代：ベクトル表現と空間索引
文書をベクトル空間で扱う
Salton、Wong、Yangは1975年の論文で、文書検索におけるベクトル空間モデルを示しました。現在のニューラル埋め込みとは作り方が異なりますが、文書や検索要求をベクトルとして表し、近さを検索へ使う発想を確認できる節目です。
つまり、テキストを数値ベクトルとして比較する発想はLLM以前からあるということです。
多次元空間を分割して探す
同じ1975年には、Bentleyがk-d木を発表しました。空間を軸に沿って分割し、探索時に調べなくてよい領域を枝刈りします。
1984年には、GuttmanがR木を提案しました。R木は点だけでなく、長方形など広がりを持つ空間オブジェクトを扱う索引です。
ただし、R木は地理・図形検索で重要な系譜であり、現在の高次元埋め込み検索と同じものではありません。「多次元データを索引で速く探す」という隣接分野の節目として見るのが安全です。
1990年代〜2010年代初頭：高次元では「厳密に探す」が難しくなる
次元が増えると、低次元で有効だった空間分割や枝刈りが効きにくくなる場合があります。また、距離の分布が集中し、最近傍と遠い点との差が小さくなるデータ分布もあります。
Beyerらの1999年の論文は、高次元で最近傍が意味を持ちにくくなる条件を分析しました。ここで注意したいのは、高次元なら必ず最近傍探索が無意味になるわけではないことです。影響はデータ分布、距離尺度、次元数、索引、クエリ条件によって変わります。
この難しさに対する一つの方向が、近似最近傍探索（ANN: Approximate Nearest Neighbor）です。厳密な最近傍を必ず返すことより、再現率・応答時間・メモリ使用量のバランスを取ります。
1998年のIndykとMotwaniの論文は、LSH（Locality-Sensitive Hashing）を用いた近似最近傍探索の代表的な節目です。2011年に掲載されたJégouらのProduct Quantization（PQ）は、ベクトルを短いコードへ量子化し、距離計算とメモリ使用量を抑える方向を示しました。
ただし、ベクトル検索が常に近似とは限りません。たとえばpgvectorは、公式READMEでexact searchとapproximate searchの両方をサポートすると説明しています。小規模データや、取りこぼしを避けたい（高い再現率が必要な）場面では、厳密検索を選ぶこともできます。
2010年代：学習された埋め込みとANNライブラリが広がる
word2vecは「埋め込みの起源」ではなく、普及の節目
2013年のword2vec論文は、大規模コーパスから単語の連続ベクトル表現を効率よく学習し、構文的・意味的な類似性を評価しました。
分散表現やニューラルなベクトル表現の研究はそれ以前にもあります。そのため、「word2vecが埋め込みを発明した」とするより、学習された単語ベクトルを広く知らしめた節目と見るのが適切です。
その後、文・画像などをベクトル化するモデルが広がりました。ただし、ベクトルの近さが人間の考える意味の近さを常に保証するわけではありません。結果は、モデル、学習データ、入力、距離尺度、検索対象によって変わります。
HNSWとFaiss
MalkovとYashuninは2016年にHNSW（Hierarchical Navigable Small World）のプレプリントを公開しました。HNSWは、近傍関係を表すグラフを階層化し、上位層から候補を絞りながら探索します。
2017年には、Faissの実装につながる大規模GPU類似検索の論文が公開され、Faissの公開GitHubリポジトリも作成されました。現在のFaissは、厳密検索、転置ファイル、PQ、グラフ系など複数の索引を提供します。
この時期に整ったのは一つの万能アルゴリズムではなく、データ量、精度、速度、メモリに応じて索引を選べる実装基盤でした。
2010年代後半〜：探索技術が「運用するシステム」になる
専用ベクトルDBや既存DBの拡張が目立つようになった時期は、一つの年で区切れません。
公開GitHubリポジトリの作成時期という限定した物差しで見ると、Weaviateは2016年、Milvusは2019年、Qdrantは2020年、pgvectorは2021年です。これは各製品の創業年や正式提供開始年ではなく、公開開発上の節目にすぎません。それでも、2010年代後半から2020年代前半に選択肢が増えた流れは確認できます。
ライブラリとの差は、単にANNが速いことではありません。アプリケーションでは、次のような機能も必要になります。
- ベクトルと業務データを一緒に管理する
- 追加・更新・削除を継続的に行う
- テナント、権限、カテゴリなどで絞り込む
- バックアップ、複製、監視を行う
専用ベクトルDB、既存RDBの拡張、検索エンジンのベクトル機能には、それぞれ異なる設計があります。「ベクトルDB」という名前だけで一括りにせず、必要な運用機能まで比較する必要があります。
RAGで新しくなったのは、探索そのものより使われ方
Lewisらは2020年のRAG論文で、生成モデルと外部の非パラメトリックな記憶を組み合わせる構成を示しました。2022年以降、LLMアプリケーションで外部文書を検索してプロンプトへ渡す使い方への関心が高まり、ベクトル検索も一般の開発者に見えやすくなりました。
ただし、RAGが必ず専用ベクトルDBを必要とするわけではありません。厳密検索、キーワード検索、ハイブリッド検索、既存DBの拡張なども選択肢です。また、2020年のRAG論文を「ベクトルDB誕生の論文」と扱うのも正確ではありません。
RAGが持ち込んだ新しさは、最近傍探索の発明ではなく、生成モデルの回答時に外部情報を検索して使う構成が、広い開発者層の実装課題になったことだと整理できます。
結局、何が古くて何が新しいのか
| 観点 | 以前からあるもの | 近年目立つようになったもの |
|---|---|---|
| 表現 | 文書・画像・特徴量をベクトルで表す | 大規模に学習された汎用的な埋め込みモデル |
| 探索 | 厳密最近傍探索、空間索引、LSH、量子化 | HNSWなどを含む実用的なANN実装の普及 |
| ソフトウェア | 研究実装、検索ライブラリ | 保存・更新・フィルタ・分散運用を含む製品・DB拡張 |
| 利用場面 | 情報検索、画像検索、推薦など | LLMアプリケーションやRAGでの利用拡大 |
一言でまとめるなら、次のようになります。
ベクトルDBは、LLMと同時に突然生まれた単一技術ではない。約50年にわたる表現・探索の研究へ、学習された埋め込み、運用機能、RAGを含む近年の需要が重なったもの。
実際に選ぶときは歴史よりトレードオフを見る
歴史を知ると、製品名より先に確認すべき点が見えてきます。
- 厳密検索と近似検索のどちらが必要か
- 近似検索なら、許容できる再現率と遅延はどの程度か
- 更新頻度、削除、フィルタ条件はどの程度あるか
- メモリ、保存容量、構築時間をどこまで使えるか
- 埋め込みモデルと距離尺度は用途に合っているか
- 専用DBが必要か、既存DB・検索基盤へ追加すれば足りるか
ANNは「100%正確でなくても速ければよい」という一言だけでは選べません。実データでrecall、latency、index build time、memoryを測り、更新やフィルタも含めて判断する必要があります。
まとめ
- 文書をベクトルで扱う代表的な研究とk-d木は1975年までさかのぼる
- 高次元では探索が難しくなる場合があり、LSH、PQ、HNSWなど複数のアプローチが発展した
- word2vecは埋め込みの起源ではなく、学習された単語ベクトル普及の節目と見るのが安全
- ベクトル検索には厳密検索と近似検索の両方がある
- 近年の新しさは、運用機能を含む製品・拡張と、LLM・RAGを含む利用場面の広がりにある
- RAGは専用ベクトルDBを必須としない
「ベクトルDBは新しいのか」という問いには、中の探索技術は古く、現在の組み合わせと使われ方が新しいと答えるのが、いちばん実態に近そうです。
参考（一次資料・公式情報）
- G. Salton, A. Wong, C. S. Yang, “A Vector Space Model for Automatic Indexing,” Communications of the ACM, 1975
- J. L. Bentley, “Multidimensional Binary Search Trees Used for Associative Searching,” Communications of the ACM, 1975
- A. Guttman, “R-trees: A Dynamic Index Structure for Spatial Searching,” SIGMOD, 1984
- P. Indyk, R. Motwani, “Approximate Nearest Neighbors: Towards Removing the Curse of Dimensionality,” STOC, 1998
- H. Jégou, M. Douze, C. Schmid, “Product Quantization for Nearest Neighbor Search,” IEEE TPAMI, 2011
- T. Mikolov et al., “Efficient Estimation of Word Representations in Vector Space,” 2013
- Y. A. Malkov, D. A. Yashunin, “Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs,” 2016
- J. Johnson, M. Douze, H. Jégou, “Billion-scale Similarity Search with GPUs,” 2017
- Faiss（公式GitHub）
- P. Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks,” 2020
- pgvector（公式GitHub。exact / approximate searchの説明）
- 公開リポジトリ作成時期の確認先（GitHub API）