【ITニュース解説】vector storage is not your new database religion

ベクトルストレージは、AI技術、特に文章を理解し質問に答えるAIシステム（検索拡張生成、RAGと呼ばれる）で注目される技術だ。しかし、これがどんな場面でも最適な万能のデータベースだという考え方は誤りである。RAGの試作段階で、データ構成（データモデル）を考えるより先に、どのベクトルデータベースを使うかを決めてしまいがちだが、これは通常、順序が逆なのだ。

最初に考えるべき難しい問題は、どの技術がデータを高速に検索できるかという性能比較ではない。むしろ、データがどのくらい最新であるべきか、古いデータを誰が削除するのか、顧客ごとにデータをどう分離するのか、メタデータフィルターのテスト方法、スキーマ変更時の再構築、そして元の情報源がベクトル化（埋め込み）後も「真実の源」であり続けるのか、といった基本的なデータ管理の問いに答えを出すことだ。データベース選択は重要だが、絶対的な信仰の対象ではない。

現在、ベクトル検索機能は、既存のプラットフォームサービスに吸収されつつある。AWS S3にベクトル検索機能が追加され、Google BigQuery内でもベクトルインデックスが管理できる。OpenSearchのような検索プラットフォームでは、従来の検索機能に加えてベクトル検索が統合された。Cloudflare Vectorizeはエッジアプリケーションに近い場所でベクトル検索を提供し、PostgreSQLのpgvectorも使い勝手が向上している。これは専用ベクトルデータベースが不要になる意味ではなく、深く考えずに安易に特定のベクトルデータベースを選ぶ風潮が終わりを告げていることを示している。

ベクトルは、AIのための特殊なデータ形式ではなく、データの「保存ポリシー」の一部となりつつある。以前は、テキストをベクトル化し、データベースに保存し、検索してAIモデルに渡すというシンプルな流れがデモには十分だった。しかし、本番システムでは、データが「ホット」「ウォーム」「コールド」のどれか、特定のキーワードやユーザーごとのアクセス制限、鮮度、セキュリティラベル、正確な情報源の特定など、複雑な検索要件への対応が求められる。また、データ削除時の対応、異なるAIモデルで作成されたベクトルの共存、データ取り込み失敗時の影響といった運用上の問題も発生する。

これらの問いが生じたとき、ベクトル検索はAIの単なる機能から、重要な「データインフラストラクチャ」の一部となる。AWS S3 Vectorsが注目されるのは、オブジェクトストレージがすべてのベクトルデータベースの代替になるわけではなく、耐久性、規模、コスト、ガバナンス、既存サービスとの統合といったストレージ本来の特性が、特定のベクトルワークロードで重要だとAWSが明言した点にある。これはAIモデルではなく、ストレージの議論だ。

「ベクトル検索」という言葉の裏には、少なくとも5つの異なる種類のワークロードが隠れている。「ホットな商品検索」は、検索ボックスやお勧め機能など、非常に低い遅延が求められる。予測可能な検索速度、厳格なフィルタリング、迅速なロールバックが必要だ。「フィルター付きエンタープライズ検索」は、アクセス権限が非常に重要となる。メタデータフィルターは単なるおまけではなく、認証モデルの一部だ。「コールドな意味検索アーカイブ」は、コストが最優先される。大量のベクトルを低頻度で検索する場合、高価なインデックス費用を避け、コスト効率の良い方法を選ぶべきだ。「データウェアハウスネイティブ検索」は、分析との連携が重要だ。BigQueryのような分析データとベクトルを組み合わせ、意味検索をSQLワークフローやビジネス指標と統合できるかがポイントとなる。「エッジ検索」は、データの物理的な配置が重要だ。Cloudflare Vectorizeのようにエッジアプリケーションの近くでベクトル検索を行うことで、遅延やデータの局所性に関する要件に対応する。「Postgres検索」は、データの所有権と関係する。データが既にPostgresにあり、アクセス制御もそこで管理されている場合、pgvectorが最も現実的だ。これは、埋め込みデータを別の場所に移動する運用負荷が、検索の利点を上回る可能性があるためだ。これらのシステムには、それぞれ異なるデフォルトの選択が必要となる。

オブジェクトストレージがベクトルデータベースを不要にするわけではない。専用ベクトルデータベースは、ベクトル検索がコア製品であり、高度なインデックス管理、低遅延検索、ハイブリッドランキング、マルチリージョン運用などが求められる場合に依然として重要だ。同様に、従来の検索エンジン、リレーショナルデータベース、データウェアハウスも、それぞれの得意分野で役割を果たす。結論として、ベクトルストレージは「階層化」されつつある。これは、重要なデータタイプが単一の流行サービスに留まらず、システム全体にわたって様々な形で現れるようになる一般的な道筋だ。この階層を理解しているチームは、「ベクトルデータベース」を単なるチェックボックスとして扱うチームよりも、より良い選択ができるだろう。

ベクトル自体よりも、誰がいつ何を使って作成し、どのように利用できるかといった「メタデータ」こそが最も重要だ。メタデータが不正確だと、検索品質は著しく低下し、古い情報や間違ったデータが返される原因となる。これはAIモデルの不備ではなく、メタデータによるデータ管理の不備が原因だ。真のデータソースの明確化、モデルとデータ分割方法のバージョン管理、データ取り込みの追跡、削除の確実な反映、再構築の再現性、フィルタリングのテスト可能性、コスト管理といった地味なプラットフォームエンジニアリングがここで役立つ。これらの作業は、データベースの選択よりも優先すべきだ。

ほとんどのチームはシステムのレイテンシやエラー率、コストを監視できるが、「リコールドリフト」（検索結果の関連性の変化）の監視は苦手だ。ベクトルインデックスは技術的に健全でも、製品としては機能不全に陥ることがある。例えば、AIエージェントが古い文書を使う、メタデータフィルターが正しい結果を除外する、コスト優先のインデックス設定が特定のクエリで悪い結果を出す、といった問題だ。本番RAGシステムには「関連性テスト」が必要だ。既知の質問セットと期待される情報源を用意し、インデックス再構築やモデル変更のたびにテストする。フィルタリング後のリコールを測定し、古い情報源の使用や、誤った境界を越えた検索結果の発生を監視する。インデックス変更はスキーマ変更のようにレビューすべきだ。検索品質をテストできないなら、それは検索インフラストラクチャではない。

新しいベクトルプラットフォーム導入前には、いくつかの問いに答える必要がある。例えば、各埋め込みオブジェクトの真のソース、検索に必要なデータの鮮度、削除の伝播方法とその証明、認証とフィルタリングに必須のメタデータ、顧客フィルタが迂回されないか、埋め込みモデルやデータ分割方法のバージョンと再構築のトリガー、コスト負担、ベクトルのアクセス頻度による区分、バックアップ対象、インデックス変更後の関連性測定、ロールバック計画などだ。これらの質問は、具体的なツールの選択を直接示すものではないが、自分が直面している問題の本質を教えてくれる。この本質理解こそが、多くのアーキテクチャ議論で最も忘れられがちな部分なのだ。

埋め込みデータは、もはや一時的なAIの派生データではない。AIエージェントの判断、顧客サポートの引用、検索ランキング、コンプライアンスアシスタントの情報源などを決定する、重要な「本番データ」なのだ。派生データであり不完全であるかもしれないが、本番データには所有権、ライフサイクル、テスト、そして運用ポリシーが必要だ。ベクトルストレージは新しいデータベースの宗教ではなく、AIという新しい装いをまとって現れた、昔ながらのデータインフラに関する問いだ。まずこれらの問いに答えを出し、それからデータベースを選択すべきだ。