ベクトルストアとエンベディング

文書基準: 2026年8月

概要

こんな状況で役立ちます

社内文書ベースのチャットボット — 「昨年の休暇ポリシーは何だったか?」に会社の文書を検索して答えさせる
製品FAQ自動応答 — 数百ページの製品マニュアルをもとに顧客問い合わせを処理
セマンティック検索 — 「安い宿」で検索した際に「コスパの良いホテル」「手頃な価格のペンション」も一緒に見つける
レコメンドシステム — 似た商品・コンテンツ・ユーザーを自動でおすすめ

ベクトルストアとは

わかりやすく理解する

図書館の司書を思い浮かべてください。司書に「機械学習の本はありますか?」と尋ねると、タイトルに「機械学習」が入っていなくても似たテーマの本を探してくれます。「人工知能」「ディープラーニング」「AI基礎」といった本たちをです。

ベクトルストアは、こうした司書の役割を果たすデータベースです。文書の「意味」を記憶しておき、似た意味の文書を素早く見つけてくれます。

通常検索 vs ベクトル検索

方式	検索基準	例
キーワード検索(通常のDB)	単語が完全一致	「安い宿」→「安い」が含まれる文書のみ
ベクトル検索(ベクトルストア)	意味が類似	「安い宿」→「コスパの良いホテル」「お得なペンション」も検索

動作方式

graph LR
    A[元データ<br/>文書、画像など] -->|変換| B[数値配列<br/>= ベクトル]
    B -->|保存| C[ベクトルストア]
    Q[ユーザーの質問] -->|変換| V[質問ベクトル]
    V -->|類似検索| C
    C -->|回答| R[関連文書を返却]

3行要約:

元データ(テキスト、画像)を数値配列(ベクトル) に変換します。この過程をエンベディングと呼びます。
ベクトルをベクトルストアに保存します。
質問も同じ方式でベクトル化し、最も似ているベクトルを探して元データを返します。

どんな選択肢があるか

ベクトルを保存する方法は大きく2つあります。

1. 専用ベクトルストア

ベクトル検索に特化した製品です。大規模・高性能が必要な場合に使用します。

ベンダー	製品	特徴
AWS	OpenSearch Serverless ベクトルエンジン	大規模ベクトル検索
AWS	S3 Vectors (Preview)	S3の耐久性 + 低コスト
Azure	Azure AI Search	ベクトル + キーワード + セマンティックランキング統合
Google Cloud	Vertex AI Vector Search	Google ScaNNアルゴリズムによる高性能
OCI	OCI AI Vector Search	Autonomous Database内蔵、SQLベース

2. 既存DBのベクトル拡張

既に使用しているDBにベクトル機能を追加する方式です。別途インフラなしで始められます。

ベンダー	製品	特徴
AWS	Aurora PostgreSQL (pgvector)	リレーショナル + ベクトルを1つのDBで
AWS	ElastiCache for Valkey	インメモリベクトル、超低遅延
Azure	Cosmos DB ベクトル検索	グローバル分散 + ベクトル
Google Cloud	AlloyDB(ベクトル検索)	PostgreSQL互換 + 高性能
Google Cloud	Cloud SQL (pgvector)	簡単に始められる

3. RAG自動パイプライン

複雑な設定なしに「文書をアップロードすれば自動でベクトル化」してくれるマネージドサービスです。

ベンダー	製品	特徴
AWS	Bedrock Knowledge Bases	文書 → エンベディング → 保存 → RAGを自動化
Azure	Azure AI Search + OpenAI “On Your Data”	最速のRAG構成
Google Cloud	Vertex AI RAG Engine	文書 → エンベディング → 検索を統合
OCI	OCI Enterprise AI Agents	OCI Search連携RAG

いつ何を選ぶか

状況	推奨される選択
初めて導入し、設定なしで素早く	RAG自動パイプライン(Bedrock Knowledge Basesなど)
既にPostgreSQLを使用している	既存DBのベクトル拡張(pgvector)
ベクトルが数百万件以上、性能が重要	専用ベクトルストア(OpenSearch、Vertex AI Vector Search)
Oracle DBを使用している	OCI AI Vector Search
超低遅延が必要(リアルタイムレコメンドなど)	Valkeyベースのインメモリ

発展編: アルゴリズムと性能

ベクトルストアの性能を深く理解したり、チューニングが必要な際に知っておくとよい内容です。

ANNアルゴリズム

数百万のベクトルの中から「最も近いもの」を正確に見つけるには、すべてのベクトルと比較する必要があり低速です。これを解決するためにANN(近似最近傍探索、Approximate Nearest Neighbor)アルゴリズムを使用します。精度をわずかに犠牲にして速度を大きく得る方式です。

アルゴリズム	特徴	主な使用先
HNSW	グラフベース。精度/速度のバランスが良い	pgvector, OpenSearch, Azure AI Search
IVF	クラスタベース。メモリ効率が良い	pgvector, FAISS
IVFPQ	IVF + ベクトル圧縮でメモリ削減	Neptune Analytics, FAISS
ScaNN	Google開発。TPU最適化	Vertex AI Vector Search

エンベディングの次元と保存容量

エンベディングモデルが生成するベクトルのサイズ(次元数)が、保存容量と検索速度を決定します。

簡単な計算: 1,000,000件 × 1536次元 × 4バイト = 約6GB

ベンダー	モデル	次元	特徴
AWS	Titan Embeddings V2	256–1024	可変次元、Bedrockネイティブ
Azure	text-embedding-3-large	256–3072	OpenAI、可変次元
Google	Gemini Embedding 2	768	Vertex AIネイティブ
Cohere	Embed 4	1024	マルチモーダル、多言語、OCI/Bedrock
オープンソース	BGE-M3, E5など	768–1024	セルフホスティング可能

選定基準: 韓国語性能が重要であれば多言語モデル(Cohere、BGE-M3)、コスト優先なら低次元、精度優先なら高次元。モデル変更時は全ベクトルの再インデックスが必要です。

ハイブリッド検索

ベクトル検索は意味に強い一方、製品コード(SKU-12345)のような正確な文字列には弱いです。ハイブリッド検索は、ベクトル検索 + 従来のキーワード検索(BM25)を組み合わせて精度を高めます。

よくある間違い

最初から専用ベクトルストアを導入 — 数万件規模ではpgvectorやRAG自動パイプラインで十分なのに、過剰なインフラを構築してコストを浪費
エンベディングモデルを変更したのに既存ベクトルを再生成しない — モデルが変わるとベクトル空間が変わるため、全体の再インデックスが必須
メタデータフィルタリングを設計しない — 権限ベースの文書フィルタリングやカテゴリフィルタなしに全ベクトルを検索し、不要な結果を返す

チェックリスト

データ規模と性能要件に合ったベクトルストアの種類(RAG自動パイプライン / DB拡張 / 専用)を選択したか
エンベディングモデル変更時に全ベクトル再生成パイプラインを用意したか
メタデータ(権限、カテゴリ、日付)をベクトルと共に保存し、フィルタリング検索が可能か