ベクトルデータベースとは｜仕組み・使いどころと選び方6観点

図書館で調べ物をしたとき、司書の方に相談したことがあります。テーマを伝えると、10冊ほど持ってきてくれました。

的確でした。ただ、その10冊に答えは無かった。

もう一度相談すると、今度は別の10冊が来ます。また的確で、また答えが無い。

3回目のとき、司書の方が言いました。「この分野は、こっちの棚の続きにありますよ」

答えは、11冊目以降にありました。 選び方が悪かったのではありません。一度に10冊しか運べなかっただけです。

先に一行だけ置きます。ベクトルデータベースとは、文章を数値の並びに変換して保存し、意味の近さで検索できるようにした保存先のことです。

題材は、社内の文書をAIに参照させる仕組みです。議事録や案件記録を検索して、その内容を根拠に答えさせます。

前置きはさておき、本題に入ります。

今日は、この検索の精度を上げようとして、埋め込みではないところで詰まった話をしていこうと思います。

① 教科書どおりに、全文検索とベクトル検索を併用する

ベクトルデータベースの基本をすでにご存じの方は、② そのとおりに組んで、日本語の全文検索が効かないから読み進められます。

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

ベクトルデータベースとは、文章・画像・音声を数値の並び（ベクトル）に変換して保存し、「意味が近いもの」を高速に探せるようにしたデータベースです。ベクトルDBとも呼ばれます。

従来のデータベースが「一致するもの」を探すのに対し、ベクトルデータベースは「近いもの」を探します。完全に同じ言葉が入っていなくても、意味が近ければ引ける、というのが違いです。

従来のデータベース（RDB・NoSQL）との違い

	探し方	得意なこと	苦手なこと
RDB	条件が一致する行を引く	正確な値、集計、整合性	表記ゆれ、言い換え
全文検索	語が含まれる文書を引く	型番・固有名詞・法令番号	言い換え、同義語
ベクトルDB	意味が近い順に引く	言い換え、曖昧な問い合わせ	「完全に一致する語」を確実に当てること

3つは置き換えの関係ではありません。実務では、正確さが要る部分をRDBや全文検索に残し、ばらつく問い合わせをベクトル検索に回す形になります。

ベクトル埋め込み（Embedding）とは

文章や画像を数値の並びに変換したものを、ベクトル埋め込み（Embedding）と呼びます。変換には埋め込みモデルを使い、意味が近いものほど、変換後の数値も近い位置に来ます。

密ベクトル（Dense） — 意味を圧縮して表す。言い換えに強い
疎ベクトル（Sparse） — 語の重みを表す。キーワードの一致に強い

次元数はモデルごとに決まっています。途中で埋め込みモデルを替えると、保存済みのベクトルを全件作り直すことになります。最初の選定が、後から効いてきます。

ベクトル検索の仕組み — 類似度と近似最近傍

検索のときは、質問も同じモデルでベクトルに変換し、保存済みのベクトルとの距離（類似度）を測って近い順に返します。測り方にはコサイン類似度、内積、ユークリッド距離などがあります。

探し方	中身	トレードオフ
厳密なk近傍（kNN）	全件と比べて、確実に近い順を出す	正確だが、件数が増えると遅い
近似最近傍（ANN）	索引をたどって、ほぼ近いものを高速に出す	速いが、取りこぼしが起こりうる

索引の作り方にはHNSW、IVF、PQなどがあります。どれも「速さ」と「取りこぼしの少なさ」を交換しています。ここに設定値があることを知っておくと、「精度が出ない」ときに疑う場所が1つ増えます。

ベクトルデータベースの主な使いどころ

RAG（社内資料の検索と回答） — 生成AIに渡す根拠を探す。いま最も多い用途
意味検索（セマンティック検索） — 言い換えても引ける社内検索
おすすめの提示（レコメンド） — 似た商品・似た記事を出す
分類とクラスタリング — 似たもの同士をまとめる
異常検知・不正検知 — いつもと違うものを見つける
画像・音声の検索 — 似た画像、似た声を探す

用途によって、求められるものが逆になります。RAGは「取りこぼさないこと」が大事ですが、レコメンドは「上位数件が良ければ十分」です。どちらなのかで、索引の設定も評価のしかたも変わります。

メタデータのフィルタリング

ベクトルだけでなく、出典・日付・部署・カテゴリといった属性を一緒に保存できます。「営業部が見てよい資料のうち、意味が近いもの」という絞り込みができます。

アクセス権限の制御は、ここで行うのが原則です。取り出した後に隠す方式にすると、渡した時点で情報が外に出ています。

多段階の検索とリランキング

実務では、1回の検索で終わらせない構成がよく使われます。

1段目 — ベクトル検索で候補を広めに取る
2段目 — 別のモデルで、質問との関連順に並べ直す（リランキング）
ハイブリッド検索 — ベクトル検索とキーワード検索の結果を組み合わせる

ハイブリッド検索が定石とされるのは、2つの検索が取りこぼすものが違うからです。型番や固有名詞はキーワード側が、言い換えはベクトル側が拾います。

ベクトルデータベースの3つのタイプ

タイプ	中身	向いているとき
フルマネージド（SaaS）	運用込みで提供される	早く始めたい。運用の人手が無い
OSS専用型	ベクトル検索に特化した製品を自前で動かす	規模が大きい。細かく調整したい
既存DBの拡張型	いま使っているDBにベクトル機能を足す	データを1か所にまとめたい

迷ったら3つ目から検討してください。すでに使っているデータベースで足りるなら、運用する対象を増やさずに済みます。

選ぶときに比べる6つの観点

性能 — 件数が増えたときの速さ、同時利用への耐性
検索の機能 — ハイブリッド検索、フィルタ、リランキングに対応するか
運用の要件 — バックアップ、可用性、更新のしやすさ
セキュリティと権限 — 保存先の国、暗号化、権限の粒度
周辺の道具との相性 — 使う予定のフレームワークに繋がるか
費用 — 保存量と検索回数で増える形が多い

比較表の機能欄では差が出にくくなっています。差が出るのは1つ目と6つ目、つまり自社のデータ量で、いくらで、どのくらいの速さで動くかです。実データの一部で試すのが、いちばん早い比較になります。

導入するときの進め方

	やること	終わったと言える状態
1. 用途を決める	RAGか、検索か、レコメンドか	取りこぼしを許容できるかが言える
2. 評価用の質問を集める	実際に来る問い合わせを20〜30件	想像で作った質問が混じっていない
3. 埋め込みモデルを選ぶ	日本語で評価されているものを	次元数と費用を把握している
4. 保存して、検索を動かす	索引を作り、検索を試す	検索が返る
5. 測って、直す	正しい根拠が取れているかを見る	取れた率を数字で言える

5で見るのは、回答の良し悪しではありません。「答えの入った資料が、検索の結果に入っていたか」です。ここを分けて測らないと、直す場所が決まりません。

運用で注意すること

資料が更新されたときの取り込み直し — 手作業だと止まる
削除された資料の扱い — 消し忘れると古い答えが返り続ける
埋め込みモデルの入れ替え — 全件の作り直しになる
保存量の増加 — 費用と速さの両方に効く
権限の変更 — 異動や退職に追随できているか

3つ目を、契約や設計の段階で見込んでおいてください。モデルは数年で世代交代します。作り直しの手順が用意されていないと、新しいモデルに移れないまま古い精度で使い続けることになります。

ベクトルデータベースについてよくある質問

Q. ベクトルデータベースと従来のデータベースは、何が違いますか。
従来のデータベースは「一致するもの」を、ベクトルデータベースは「意味が近いもの」を探します。置き換えの関係ではなく、正確さが要る部分は従来のまま残すのが実務的です。

Q. ベクトル検索と全文検索は、どちらを使えばよいですか。
併用（ハイブリッド検索）が定石です。型番・固有名詞・法令番号のように字面が決まっているものは全文検索が、言い換えや曖昧な問い合わせはベクトル検索が拾います。

Q. 埋め込みモデルは、後から変えられますか。
変えられますが、保存済みのベクトルを全件作り直すことになります。次元数もモデルごとに違います。作り直しの手順を、最初から用意しておいてください。

Q. 精度が出ません。どこを疑えばよいですか。
「答えの入った資料が検索結果に入っていたか」と「回答が合っていたか」を分けて測ってください。前者が取れていないなら、切り方・埋め込み・索引の設定（近似検索は速さと引き換えに取りこぼします）の側です。

Q. どのベクトルデータベースを選べばよいですか。
まずいま使っているデータベースの拡張機能で足りないかを見てください。足りなければ、運用の人手があるかでフルマネージドかOSS専用型かを決めます。比較は、実データの一部を入れて試すのがいちばん早いです。

教科書どおりの構成から始めました。

→ 文書を断片（チャンク）に分ける
→ それぞれをベクトルに変換して保存
→ 質問もベクトルにして、近いものを取ってくる
→ あわせて全文検索もかけ、両方の結果を使う

併用が定石とされています。意味で引くベクトル検索と、語で引く全文検索。取りこぼしが減ります。

ここまでは、教科書どおりです。

ここまでが、ベクトルデータベースの教科書どおりの整理です。仕組みを押さえ、用途を決め、ハイブリッド検索で取りこぼしを減らす。

この記事の後半で扱うのは、この定石どおりに組んだ検索で、実際に何が返ってこなかったかです。設定そのものは、間違っていませんでした。

② そのとおりに組んで、日本語の全文検索が効かない

ところが、全文検索の精度が出ませんでした。

日本語には、語と語のあいだに空白がありません。どこで切るかを機械が決めることになります。切り方が想定と違うと、あるはずの文書が引けません。

使っていた基盤の日本語全文検索は、この精度が低いという課題を抱えていました。

そこで判断しました。全文検索を避けて、ベクトル検索の精度を根本的に上げるほうに寄せる。

片肺で飛ぶことになるので、ベクトル側を本気で改善する必要がありました。

③ そして、埋め込みではないところに天井があると気づく

改善の入口として、まず埋め込みの質を疑いました。モデルを変える、チャンクの分け方を変える、正規化を変える。

少しは良くなりました。ただ、頭打ちになります。

原因を探して、制約に行き当たりました。

検索結果は、上位K個しか指定できません。使っていた構成では、最大10個でした。

つまり、こうです。

→ 何万件あっても → 返るのは10件
→ 11番目に正解があっても → 存在しないのと同じ
→ 埋め込みを改善する → 10件の中身は良くなる
→ 10件という数は、変わらない

司書の方と同じでした。 選び方は良くなっている。運べる冊数が変わっていない。

④ 原因は「取りに行く力」だけを上げようとしていたこと

原因を一つに絞ると、これでした。

私は、1回の検索で正解を引き当てようとしていました。

10件しか取れないなら、その10件に正解が入っている必要があります。 これを常に成立させるのは、無理です。質問の書き方ひとつで順位は動きます。

必要だったのは、10件の中身から周辺へ辿れることでした。

司書の方の「こっちの棚の続きにありますよ」が、まさにそれです。 持ってきた10冊が外れでも、そこから次の場所が分かればよかった。

⑤ 直してみる — チャンクに関係性を持たせ、局所的にグラフを組ませる

最初に検討したのは、ナレッジグラフの全体構築でした。文書間の関係を全部つないだ地図を作る。

難しすぎました。 文書は増え続け、関係の定義も揺れます。地図を作り終える前に、地図が古くなります。

そこで、方針を変えました。

各チャンクに「関係性」のメタデータを持たせ、AIが内部で局所的なナレッジグラフを推論・構築する。

全体像は作りません。取ってきた断片が持っている関係の情報から、その場で必要な範囲だけを組み立てさせます。

→ 上位10件のうち、1件でも当たればいい
→ そこに「これは何に属し、何の前後にあり、何を参照しているか」が書いてある
→ AIがその関係を辿って、周辺を引き直す

件数の天井は動かせないので、1件あたりの情報量を増やしました。

そして、この方針には現実的な利点がありました。実装のハードルが低い。 全体のグラフを構築する仕組みは要らず、チャンクにメタデータを足して、ベクトルデータベースと連携させれば動きます。

⑥ あとで知った — これは検索の古典的なトレードオフだった

素朴な対処のつもりでしたが、やっていたことを言い換えると、情報検索の基本的なトレードオフでした。

検索の評価には、対になる2つの見方があります。

→ 適合率 — 取ってきたものが、どれだけ正しいか
→ 再現率 — 正しいもののうち、どれだけ取れたか

そして、上位K件で切るという設計は、再現率に天井を置く行為です。

正解が20件あるのに10件しか返さないなら、再現率は最初から50%が上限です。埋め込みをどれだけ改善しても、この上限は動きません。改善されるのは適合率のほうだけです。

私は、再現率の問題を、適合率の道具で解こうとしていました。

そして、関係性のメタデータを足すという対処は、1回の検索で完結させるのをやめて、辿れるようにすることでした。天井を上げるのではなく、天井の下で往復できるようにしたわけです。

図書館で司書の方がやっていたのも、同じです。10冊という制約は変えず、次の棚を教えてくれました。

新しい理屈は、ひとつも要りませんでした。
改善の記録にはこう残っています。「RAG検索において全文検索を避け、ベクトル検索の精度を根本的に向上させる」。ところで、その手段として書かれていたのが「各チャンクに関係性のメタデータを付与し、AIエージェントが内部でローカルなナレッジグラフを推論・構築する」でした。ただし「ナレッジグラフの全体構築の難しさを踏まえ」という前置きが付いています。実は、この前置きが判断の本体です。全体を作らないと決めたから、実装のハードルが下がりました。

あとで知った — 天井の正体は、件数ではなく次元だった

上位K件で切っているから届かない、という理解で運用していました。ところが、もう一段下に原因があります。

Google DeepMind が公開した LIMIT というデータセットの研究が、そこを扱っています。1本のベクトルで表現できる上位K件の組み合わせの数は、埋め込みの次元数によって上限が決まるという指摘です。

文書が増えるほど、「関連あり」と言えるまとまり方の数は急速に増えます。一方で、表現できる側の容量は次元数のまま動きません。 つまり天井は、検索の設定ではなく、表現の幾何そのものから来ています。

これはモデルを大きくしても、学習データを増やしても消えません。

数字が厳しいところです。Google や Snowflake の最新の埋め込みモデルでも、この課題では再現率が20%を割ったと報告されています。そして同じ課題で、数十年前からある BM25 という語の一致で探す方式が、非常に良い成績を出しました。

意味で探すほうが賢い、という前提が崩れる結果です。

だから現在の実務では、ベクトル検索と語の一致検索を併用する多段構成が推奨されています。1段目の再現率が0.85なら、どれだけ優れた並べ替えを後段に置いても0.85を超えません。 後段は、前段が取れなかったものを取り戻せないからです。

隣を辿らせるという対処は、この幾何の制約を、件数ではなく経路で迂回するやり方だったことになります。理屈は後から追いつきました。

⑦ 何が変わったか

改善の入口が変わりました。

“`
前：精度が出ない → 埋め込みを変える → 頭打ち
後：精度が出ない → 何件返しているかを見る → 天井を確認してから手を打つ
“`

最初に見るのが、モデルではなく件数になりました。
順番を変えてからの実測です。埋め込みを触らずに、関係性のメタデータを足しただけで、必要な文書に辿り着いた割合が上がりました。 取得件数の上限は10件のままです。

施策	上位10件の質	辿り着けた割合
埋め込みの変更	上がる	変わらず
チャンクの分割変更	少し上がる	少し上がる
関係性メタデータ	変わらず	上がる

⑧ 現場で使うなら、この2枚

表1：精度が出ないときに見る順番

順	見るもの	天井かどうか
1	返している件数の上限	天井。ここが効く
2	チャンクの分け方	効くが上限内
3	関係性のメタデータの有無	天井の下で往復できるか
4	埋め込みモデル	適合率だけが動く
5	全文検索の併用可否	言語による

1番を確認せずに4番から始めると、必ず頭打ちになります。

表2：チャンクに持たせるメタデータ

種類	例	何に効くか
所属	どの文書・どの章の一部か	周辺を引き直せる
前後	直前・直後の断片	文脈が切れない
参照	言及している別文書	関係を辿れる
日付・作成者	—	絞り込みに使える

全体のグラフは作らないでください。 作り終える前に古くなります。

表3：件数の上限を確かめる手順

手順	見るもの
1	検索の設定で返す件数の上限を読む
2	上限を10件から20件へ上げられるか試す
3	上げられないなら、辿れる設計へ切り替える
4	上げられても、応答時間が2倍になっていないか見る

2行目で上げられる環境なら、そもそもこの記事の問題は起きません。 上げられない前提の構成を使っているかどうかを、最初に確かめてください。
設定を読むときの合言葉も置いておきます。「返す件数の上限はいくつか」。ただ、この一言を先に聞くだけで、埋め込みの入れ替え2回とチャンク分割の変更3回が省けました。

運用では、次の5件に名前を付けて配りました。名前が付くと、会議の中で指差せるようになります。

1件目、「上位K件に入らなかった文書は、無いのと同じ」。 存在していても、後段には届きません。ここは精度の問題ではなく、件数の問題です。

2件目、「再現率には、構造的な天井がある」。 上位10件で切る限り、11件目以降がどれだけ良くても届きません。埋め込みを磨いても、この天井は動きません。

3件目、「埋め込みを直す前に、件数の上限を疑う」。 改善の順番を逆にすると、数か月かけて天井の下を磨くことになります。

4件目、「チャンクに、隣を指す情報を持たせる」。 前後や参照先を持たせておくと、10件しか取れなくても周辺へ辿れます。取得件数を増やさずに届く範囲が広がります。

5件目、「全体を作らず、局所を辿らせる」。 全体の関係図を作る労力と、隣を1件持たせる労力では、桁が違います。

この5件は、1枚に印刷して配れる分量に収めています。増やすと、誰も覚えません。

⑨ この考え方が効き続ける理由

埋め込みは、これからも良くなります。それでも、この制約は残ります。 件数で切るという設計は、費用と応答速度の都合から来ているからです。

→ 全部を渡せない → 上位K件で切る
→ 切る → 再現率に天井ができる
→ 天井 → 埋め込みでは越えられない

渡せる量に上限がある限り、辿れる設計が要ります。

そして、この考え方は検索に限りません。一度に全部を運べない場面すべてに当てはまります。 運ぶ量を増やすか、運んだものから次を辿れるようにするか。たいてい、後者のほうが安い。

ただし、正直に書いておきます。この関係性メタデータを、誰がどう付けるかは解けていません。 人が付けると続きません。AIに付けさせると、付け方が揺れます。 そして揺れた関係を辿ると、辿った先も揺れます。

いまは、AIに付けさせて、目視で直しています。 きれいな解ではありません。

順番を変えてからの実測です。埋め込みには手を触れず、関係性のメタデータを足しただけで、必要な文書に辿り着いた割合が上がりました。取得件数の上限は10件のままです。上位10件のうち、関係を辿る手がかりを持つ断片は平均で3件ありました。

もう1件、運用で効いたことを書いておきます。取得件数の上限は、設定画面に書いてありました。 誰も読んでいなかっただけです。埋め込みを2回入れ替えて、チャンクの分割を3回変えたあとで、ようやく設定を開きました。手を動かす前に、制約を読む。 当たり前のことが、いちばん後回しになります。

当時の判断を、もう1件だけ引いておきます。「実装のハードルが低い」。ところで、これは性能ではなく着手のしやすさの話です。ただし、着手できない改善は存在しないのと同じでした。

関連して、MCPで社内の文書をAIから引けるようにする話と、LLMに自分の出力を検証させてはいけない話を別に書いています。社内RAGが現場で止まる場所話はすでに公開しています。あわせて読むと、同じ判断が別の場所でも効いていることが分かると思います。

この判断を実際の案件で使う場面については、社内GPT・RAG構築のページに整理しています。

上位10件といえば、検索結果の2ページ目を見た記憶がほとんどありません。

無かったのではなく、見ていなかっただけでした。だいたいいつも、そういうことになっています。

以上です。

ベクトルデータベースよくある質問

ベクトルデータベースと従来のデータベースは、何が違いますか？

従来のデータベース（RDB）は条件が一致する行を引き、全文検索は語が含まれる文書を引きます。ベクトルデータベースは、文章や画像を数値の並びに変換して保存し、意味が近い順に引きます。完全に同じ言葉が入っていなくても引ける代わりに、完全一致を確実に当てることは苦手です。置き換えではなく、正確さが要る部分は従来のまま残すのが実務的です。

ベクトル検索と全文検索は、どちらを使えばよいですか？

併用（ハイブリッド検索）が定石です。2つの検索は取りこぼすものが違い、型番・固有名詞・法令番号のように字面が決まっているものは全文検索が、言い換えや曖昧な問い合わせはベクトル検索が拾います。さらに、取り出した候補を別のモデルで並べ直すリランキングを足す構成もよく使われます。

埋め込みモデルは、後から変えられますか？

変えられますが、保存済みのベクトルを全件作り直すことになります。次元数もモデルごとに違うためです。モデルは数年で世代交代するので、作り直しの手順を最初から用意しておいてください。用意がないと、新しいモデルに移れないまま古い精度で使い続けることになります。

ベクトル検索の精度が出ません。どこを疑えばよいですか？

「答えの入った資料が検索結果に入っていたか」と「回答が合っていたか」を分けて測ってください。前者が取れていないなら、切り方（チャンク）、埋め込みモデル、索引の設定の側です。近似最近傍（ANN）は速さと引き換えに取りこぼしが起こりうるので、そこに設定値があることも疑ってください。

どのベクトルデータベースを選べばよいですか？

まず、いま使っているデータベースの拡張機能で足りないかを見てください。足りなければ、運用の人手があるかでフルマネージド（SaaS）かOSS専用型かを決めます。比べる観点は、性能・検索機能・運用要件・セキュリティと権限・周辺の道具との相性・費用の6つですが、機能欄では差が出にくいので、実データの一部を入れて試すのがいちばん早い比較です。