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

ベクトルデータベースは一つの問いに、非常に速く答える

数値の並びを渡すと、それに最も近い保存済みの並びを返す。それがインターフェースのすべてだ。

この数値の並びがエンベディングだ。エンベディングモデルは、文章や商品説明、画像を数百から数千個の数値に変換し、似た意味が近くに位置するように配置する。その仕組みはAIにおけるエンベディングとはで解説している。ベクトルデータベースは、その並びが大量になったときに保存される場所だ。それぞれをIDとメタデータとともに保存し、インデックスを構築して、最近傍探索に答える。「これがクエリベクトルだ、最も近い10件をくれ」というわけだ。

難しいのは「速く」という部分だ。1,536個の数値からなる100万件の保存済みベクトルとクエリを比較するのは15億回の掛け算になり、これをキー入力のたびに行うのはスケールしない。そこでベクトルデータベースは近似最近傍インデックスを使う。最も一般的なのはHNSWで、MalkovとYashuninによる2016年の論文に基づくグラフ構造であり、100万件すべてではなく数百件の候補だけを調べて、ほぼ毎回正しい答えを返す。この「ほぼ」がトレードオフであり、わずかな再現率と引き換えに千倍の高速化を得ている。

既存のデータベースは単語を照合し、ベクトルデータベースは意味を照合する

リレーショナルデータベースは値が一致する行を見つける。WHERE customer_id = 4127のように。全文検索インデックスは単語を含む文書を見つける。refund AND policyのように。ベクトルデータベースは意味が近い項目を見つける。「返金してほしい」というクエリは、2つが単語を一つも共有していなくても「返品と返金」というタイトルの文章を返す。

最後の行は、この区分がいかに曖昧かを示している。pgvectorは通常のPostgresにベクトル列とHNSWインデックスを追加するものであり、Elasticsearchは2019年のバージョン7.0からベクトルフィールドを、2022年のバージョン8.0からHNSW検索を持っている。「ベクトルデータベース」は、多くの場合すでに使っているデータベースの中の一機能であって新しい製品ではなく、単体製品はPostgresにできないことをするのではなく、スケールと運用の洗練度で競っている。

文書チャットは末尾にモデルが付いたベクトル検索である

RAGとはで解説している検索拡張生成には、検索の段階と執筆の段階がある。ベクトルデータベースは検索の段階を担う。

1. 各文書を数百から千トークン程度の文章に分割する。
2. すべての文章をエンベディングし、そのベクトルを文章のテキストと出典とともにベクトルデータベースに保存する。
3. 質問が届いたら、それをエンベディングし、最も近い文章をデータベースに問い合わせる。
4. それらの文章を質問とともに言語モデルに渡し、回答を書かせる。

手順1と2は、文書が追加されたときに一度だけ発生する。手順3と4は、質問のたびに発生する。言語モデルはコレクション全体を見ることはなく、データベースが選んだ5件から10件の文章だけを見る。だからこそ答えの質は検索の質に左右される。最も近いベクトルが間違った文章であれば、モデルは自信を持って間違った質問に答えてしまう。これはAIハルシネーションとはでは創作ではなく検索の失敗として扱われる。

いつ必要で、いつファイル全体を送るほうが良いか

この判断はサイズの問題だ。モデルは一度にコンテキストウィンドウしか考慮できず、その中のトークンはすべてターンごとに課金される。ベクトルデータベースは、関連する部分だけをモデルの前に置くために存在する。一つの文書がそのまま収まるなら、検索は省略できる手順だ。収まらないコレクションでは、それが唯一の選択肢になる。

300,000トークン、数百ページのレポートに10個の質問をし、質問ごとに1,000トークンの文章を5件検索するという設計で、2つの方式の価格を比較してみる。毎回ファイル全体を送ると300万入力トークンになる。質問ごとに1,000トークンの文章を5件検索すると5万トークンだ。2026-08-20にOpenRouterから取得したAIモデルコストインデックスの一覧入力価格では、この差はどのモデルでも60倍になる。プロンプトキャッシュが提供されている場合、同じファイルの再読み込みは一覧価格の10分の1から2分の1で課金され、差はおよそ6倍から30倍に縮まる。それでも検索のほうが有利だが、差は小さくなる。

ファイルが予算に収まる場合、ファイル全体を送る設計はそのお金に見合うものをもたらす。40,000トークン程度の60ページの契約書なら、「第14条と矛盾する箇所があるか」といった、文書全体を一度に必要とする質問にモデルが答えられるようになる。検索ではこれはできない。第14条とその矛盾を同じバッチで見ることが決してないからだ。ここから導かれる原則はこうだ。一つの文書、またはごく少数ならまるごと入れる。ライブラリならベクトルデータベースを通す。両者の間では、トピックごとにアップロードを分割し、モデルが必要なセクションを受け取れるようにする。

Whiziはテキストそのものを、最大40,000トークンのターンで送る

Whiziはチャットのためにベクトルデータベースを動かしていない。ファイルを添付すると、ドキュメントのアップロードの仕組みがテキストを抽出し、ターンあたり最大40,000トークンという定額の予算までモデルへプロンプトのテキストとして送る。それより長いアップロードは切り詰められ、トーストとメッセージ内のマーカーでその旨が示される。プロジェクトファイルも同じ仕組みで動く。プロジェクト機能は最大10ファイルを固定し、その内容をメッセージごとにプロンプトへ再構築する。1ファイルあたり32,000文字、プロジェクト全体で120,000文字が上限だ。

この上限が設計の境界線になる。32,000文字を超えて固定されたファイルは切り詰められ、40,000トークンのターン予算を超えた添付は切られ、プロジェクトは検索可能なライブラリではなくフォルダだ。このトレードオフは意図的なものだ。ターン予算に収まる契約書や論文なら、検索させるよりテキストをそのまま存在させるほうが優れており、実際に役立つ検証、つまりモデルが使った箇所を引用させるという確認は、その文章がそこに存在するからこそ機能する。文書が千件あるなら、ベクトルデータベースが正しい道具であり、チャットアプリは正しくない道具だ。

この仕組みから2つの習慣が生まれる。複数のファイルを添付したら、質問の中で対象のファイル名を一度は挙げること。さもないとモデルが黙って選んでしまう。そして行動を起こす答えについては、必ず引用を求めること。検索システムは間違った文章を返すことがあり、ファイル全体を渡すシステムは文書ではなく記憶から答えてしまうことがある。引用を求めればどちらも見抜ける。