Zillizはいかにベクトルデータベースの未来を見据え、本番環境向けに構築したか
Innovator CoffeeとZillizのエンジニアリング担当VPであるJames Luanのポッドキャストを振り返る記事です。
生成AIが主流になる以前、ベクトルデータベースが単独で語られることはほとんどありませんでした。注目の多くは依然としてリレーショナルデータベース、検索エンジン、あるいはビッグデータフレームワークに向けられていました。ベクトル検索は、話題に上るとしても、たいてい研究論文やアルゴリズムライブラリの中に存在するものであり、本番システムに関する議論の中にあるものではありませんでした。
しかし、ベクトルデータベースは突然現れたわけではありません。それらは、データが作成され、利用される方法における、より深い変化から生まれました。2017〜2018年ごろ、Zillizのチームは同じ問題が繰り返し現れていることに気づき始めました。企業は、テキスト、画像、音声、ログ、ユーザー行動といった、はるかに多くの非構造化データを扱いたいと考えていましたが、既存のツールはそのために作られていなかったのです。従来のデータベースやキーワード検索はこのデータを保存することはできましたが、それを理解することは得意ではありませんでした。完全一致の扱いには優れていましたが、意味や類似性となると話は別でした。
ベクトルは、そのギャップを埋める実用的な方法を提供しました。テキスト、画像、その他のコンテンツを埋め込みに変換することで、類似性はシステムが直接計算できるものになりました。データがこのように表現されるようになると、データベースはもはや単にレコードを保存するだけのものではなくなりました。キーワードだけでなく、意味に基づいて情報を取得できるようになったのです。
したがって、ベクトルデータベースは、強力なモデルと雑多な現実世界のデータの間に位置し、非構造化情報を大規模に検索可能、比較可能、そして利用可能にします。
では、ベクトル検索はどのようにして研究から本番環境へと飛躍し、ベクトルデータベースは次にどこへ向かうのでしょうか？ 英語ポッドキャスト Innovator Coffee の最近のエピソードで、Zilliz のエンジニアリング担当VPである James Luan は、同社の創業ストーリー、Zillizのオープンソースベクトルデータベースである Milvus の背後にある考え方、そしてシステムを形作った設計原則を踏まえ、自身の見解を共有しました。
アルゴリズムから本番環境へ：ベクトルデータベースの進化
ベクトル検索が本番利用可能になる前の初期を振り返り、James Luan は、初期の進展の大半は大手テクノロジー企業の内部で起きていたと述べています。MetaのFAISSのようなプロジェクトは技術的基盤を築きましたが、それらはデータベースではなくライブラリでした。同様のベクトル検索システムはMicrosoftやSpotifyなどの企業にも存在し、通常は社内利用向けに構築され、特定のワークロードに合わせて調整されていました。これらのツールは有効でしたが、汎用的で長期間稼働するシステムとして設計されたものではありませんでした。
転機は、ベクトル検索が研究から実際のプロダクトへ移行したときに訪れました。チームがそれを本番環境にデプロイしようとすると、システムレベルの課題を無視できなくなりました。スケーラビリティ、信頼性、日々の運用は、検索品質と同じくらい重要でした。そこで異なる道筋が現れました。一部のチームは、オンライン推論と大規模言語モデルとの密接な統合に最適化されたマネージドサービスを構築しました。別のチームは、より広範なインフラストラクチャのアプローチを取り、ベクトル検索をデータレイクや従来型データベースと統合して、エンタープライズ規模のユースケースを支援しました。Jamesの見解では、この分岐は、あらゆる新しいインフラストラクチャ層が出現する過程における自然な段階です。
大規模言語モデルが成熟し、アプリケーションが本番環境に到達するにつれて、ベクトルデータベースの役割は急速に拡大しました。初期のユースケースは、推薦システム、画像検索、コンテンツマッチングといった類似性ベースの取得に焦点を当てていました。過去2〜3年で、Retrieval-Augmented Generation (RAG) が支配的なパターンになりました。RAGシステムでは、ベクトルデータベースがモデルに関連性の高い、根拠のあるコンテキストを提供し、事実の取得を可能にし、ハルシネーションの低減を支援します。
その役割は、エージェントベースのシステムにおいてさらに重要になります。ここでは、ベクトルデータベースが長期的またはニアラインのメモリとして機能し、多段階推論、コンテキスト圧縮、マルチモーダル検索を支えます。James はこの変化を、シンプルな原則で要約しています。構造は少なく、知能はより多く。モデルの能力が向上するにつれて、硬直的なパイプラインや重い事前ラベリングは、システムの足かせになり得ます。エージェントは、柔軟なセマンティック空間で動作し、情報をどのように検索して組み合わせるかを動的に判断するほうが、より優れた性能を発揮します。
同時に、James はベクトルデータベースが魔法ではないことを強調しています。検索品質は、アルゴリズムと同じくらいデータガバナンスに依存します。適切にキュレーションされた、ドメインに関連するデータ、そして継続的な評価が不可欠です。埋め込みモデル、リランカー、検索戦略は急速に進化しており、スタックを長期間見直さないチームは、しばしば後れを取ります。
推論の先を見据えると、James はベクトルデータベースがトレーニングとデータ準備において、ますます大きな役割を果たすと見ています。マルチモーダルモデルがより一般的になるにつれ、ベクトル検索は、テキスト、画像、動画、PDF にまたがる大規模データセットのクレンジング、重複排除、キュレーションにますます利用されています。時間とともに、これはデータレイクと収束し、バッチデータ処理とオンライン推論をつなぐ「ベクトルレイク」アーキテクチャになる可能性があります。
その長期的な見方では、ベクトルデータベースはもはや単なる検索エンジンではありません。トレーニング、推論、長期的なデータガバナンスにまたがるセマンティックレイヤーとなり、AI システムのライフサイクル全体を支えます。
ベクトルデータベースが主流になる前に Zilliz が方向性を見出した方法
James は、Zilliz の初期を、すぐに明確な方向性があった時期ではなく、探索の期間だったと説明しています。彼も同社の CEO も、Oracle で長年トランザクションシステムを構築してきた、従来型データベースのバックグラウンドを持っていました。最初から、彼らはもう一つの従来型データベースを作りたいわけではないと分かっていましたが、その代替が何であるべきかは、まだ未解決の問いでした。
最初の試みは、専用ハードウェアを通じて大規模データ処理を高速化することを目的とした、GPU アクセラレーションデータベースでした。技術的には機能しました。商業的には機能しませんでした。GPU は高い性能をもたらしましたが、高価であり、ほとんどの実世界のワークロードでは、コストパフォーマンスのトレードオフを正当化するのが困難でした。同時に、ClickHouse のような CPU ベースのシステムが急速に進化し、コストのごく一部で性能差の多くを埋めていました。
その経験は、より深い再考を迫りました。データベースをどう高速化するかを問う代わりに、チームは別の問いを立て始めました。どのような種類のデータが、まだ十分に扱われていないのか? 従来の分析ワークロードやトランザクションワークロードには、すでに成熟したソリューションがありました。際立っていたのは、非構造化データ――テキスト、画像、そしてユーザーが単に保存するだけでなく、検索し理解したいとますます望むその他のコンテンツでした。
転機はユーザーからのフィードバックを通じて訪れました。一部の初期ユーザーは、そのシステムを画像検索の高速化に使えるかどうかを尋ねました。その問いは、ベクトル表現によって可能になる、大規模なセマンティック類似性という、より広い機会を示していました。チームは、GPU ではなくベクトルこそが、より根本的な抽象化であると気づきました。その洞察から、Milvus は大規模ベクトル検索に焦点を当てたオープンソースプロジェクトとして生まれました。
James は、このピボットがハイプに動かされたものではなかったと強調しています。当時、「ベクトルデータベース」は認知されたカテゴリではなく、その用語自体にも明確な定義はありませんでした。意思決定を導いたのは、データベースの基本原則に根ざした確信でした。つまり、セマンティック検索が重要になるのであれば、最終的には他の重要なデータシステムと同じ性質――スケーラビリティ、安定性、信頼性――が必要になる、というものです。
その選択が、その後のすべての方向性を定めました。ベクトルを第一級のデータとして、そしてデータベースを長期間稼働するシステムとして早期に位置づけたことで、Zilliz は AI 駆動アプリケーションへの業界の移行に先んじることになりました――その移行が広く可視化されるずっと前に。
モデルがその後、研究から本番環境へと移行するにつれて、ベクトルデータベースはエンタープライズAIアーキテクチャの中核的な一部となり、RAGパイプライン、エージェントシステム、マルチモーダル検索、大規模な学習データの重複排除を支えるようになりました。その拡大に伴い、新たな期待も生まれました。速度だけではもはや十分ではありませんでした。精度、スケーラビリティ、コスト効率、データガバナンス、セキュリティのすべてが最優先の課題となりました。
Jamesの見解では、これらの要求のバランスを取るシステムを構築することは、短期的な最適化の問題ではありません。それには忍耐、継続的なエンジニアリング投資、そして新しいカテゴリーへの初期の熱狂をはるかに超えた、インフラの基礎への長期的なコミットメントが必要です。
技術的課題と解決策：本番環境でベクトルデータベースを運用する
ベクトルデータベースが実際の本番AIシステムに移行するにつれて、Jamesは、成功は生の性能だけの問題ではなくなったと主張しています。初期の導入では、何よりも速度が重要でした。しかし大規模言語モデルが登場すると、本当の課題は、コスト、精度、信頼性、エンタープライズ要件を同時にバランスさせながら、持続的にスケールできるシステムを構築することになりました。
コスト：メモリのみの検索を超えて
Jamesは、初期のベクトル検索システムがインメモリインデックスに大きく依存していたと指摘しています。このアプローチはデータセットが小さいうちは機能しましたが、LLM駆動のアプリケーションによってデータ量がはるかに増えるにつれて、経済的に持続不可能になりました。その規模では、レイテンシを数ミリ秒削減することよりも、ストレージコストを管理することの方がはるかに重要です。
解決策は、ストレージとインデックス作成に対する階層型アプローチです。インメモリ、ディスクベース、オブジェクトストレージのインデックスを組み合わせることで、ベクトルデータベースはストレージコストを最大100分の1まで削減できます。この変化は既存のワークロードを最適化するだけではなく、そもそも大規模検索を実用可能にします。
実世界の規模におけるスケーラビリティと安定性
コスト圧力はすぐにスケーラビリティの限界を露呈させます。Jamesは、多くのチームが導入しやすいという理由で、シンプルな単一ノード構成から始めると述べています。問題は後になって、データが短期間で10倍、50倍、さらには100倍に増えたときに現れます。
この現実を受けて、ZillizはMilvusを分散型のクラウドネイティブシステムとして再構築しました。Jamesにとって、スケーラビリティは安定性と切り離せません。スケールできても実際のワークロード下で予測不能に失敗するシステムは、使えるインフラではありません。
彼は、安定性こそがベクトル検索を本番システムにするうえで最も難しい部分であることが多いと強調しています。既存のオープンソースツールを使えば、多くのチームは6〜12か月で動作するプロトタイプを構築できます。難しいのは、データ量、クエリパターン、運用上の複雑性が変化する中で、そのシステムを長期間にわたって確実に動作させることです。
性能最適化とは異なり、安定性は単一のブレークスルーから生まれるものではありません。性能向上は目に見えます—ベンチマークによって数か月で20%または30%の改善を示すことができます。安定性は異なる方法で構築されます。各修正によってSLAが改善されるのはほんの数分の1パーセントで、それ自体ではほとんど気づかれないかもしれません。しかし、何百もの小さな累積的改善を通じて、システムは徐々に長期的なインフラとして運用できるだけの信頼性を備えるようになります。
精度：検索が上限を決める
RAGおよびエージェントシステムでは、検索品質がモデル性能を直接決定します。システムが正しい情報を検索できなければ、モデルにはそれを補う方法がありません。
Jamesは、精度はデータベースだけの問題ではないと強調しています。それは、埋め込みモデル、リランキング戦略、データ品質を含む検索スタック全体に依存します。これらのコンポーネントは急速に進化するため、チームは長期的に精度を維持するために、頻繁に—多くの場合数か月ごとに—セットアップを再評価する必要があります。
Zillizがオープンソースとビジネスのバランスを取る方法
この1〜2年、Jamesは、オープンソース企業に繰り返し持ち上がる課題について多くの時間を費やして考えてきました。それは、成長するビジネスを運営しながら、活発なオープンソースコミュニティをどのように構築し、維持するかという課題です。
オープンソースと商業的な目標は、必ずしもきれいに一致するわけではありません。オープンソースプロジェクトは、オープン性、長期的な参加、そしてコミュニティの信頼に依存しています。一方で、企業には管理すべき収益目標や成長上の制約があります。近年、このミスマッチは業界全体でより顕在化してきました。James は、いくつかのチームが自社のオープンソースプロジェクトをメンテナンスモードへ移行するのを見てきました。それは技術が機能しなくなったからではなく、ビジネスが拡大するにつれて、オープンソースモデルを支えることが難しくなったからです。
しかし Zilliz にとって、オープンソースは単なる技術的な選択ではなく、Go-to-Market の意思決定でもあります。実際には、高度に技術的な無料トライアルのように機能します。つまり、開発者が実際の利用を通じてプロダクトを発見し、評価し、信頼を得るための手段です。これは、初期ユーザーの獲得が難しいスタートアップにとって特に重要です。Zilliz のようなエンジニアリング主導のチームにとって、これは従来型のマーケティングやセールス主導のアプローチよりもはるかに効果的であることが証明されました。
Milvus をオープンソース化することで、チームは GitHub を主要な入り口として位置づけました。開発者は実際のワークロードで Milvus を使用し、フィードバックを共有し、改善をプロジェクトに還元しました。時間の経過とともに、これによりユーザー、コミュニティ、プロダクト開発の間に緊密なフィードバックループが生まれました。
その成果は明確でした。James によると、Zilliz Cloud の顧客の約80%は、オープンソースの Milvus プロジェクトのユーザーとして始まったそうです。オープンソースは強力な信頼の仕組みとしても機能しました。自分たちで Milvus を運用した経験のあるチームは、その後、商用サービスを採用することにはるかに前向きでした。
しかし、その移行は決して自動的に起こるものではありませんでした。James は、オープンソースだけではビジネスは生まれないと明言しています。商用プロダクトは、単にオープンソースをパッケージ化するだけでは不十分であり、オープンソース版では解決できない課題を解決しなければなりません。Zilliz にとって、その価値は Milvus を大規模に信頼性高く運用することにあります。アップグレードの管理、障害への対応、そしてパフォーマンスとコストの継続的な最適化です。
このアプローチの重要な成果の一つは、多くのユーザーがマネージドサービスへ移行した後に、総コストの低下を実感していることです。ベクトルデータベースは、インデックス化、量子化、ストレージの進歩に牽引されて急速に進化しています。Zilliz Cloud を利用することで、ユーザーはアップグレードやインフラ管理の負担を自ら負うことなく、こうした改善の恩恵を継続的に受けられます。
James の視点では、このバランスこそがこのモデルを持続可能にしているものです。オープンソースはアクセスと信頼を生み出します。商用サービスは、長期的なインフラの進歩を実践的な価値へと変換します。それでいて、そもそもユーザーを惹きつけたオープン性を損なうことはありません。
混雑した市場で Zilliz が際立つ理由
今日のベクトルデータベース市場をどう見ているかと問われると、James は AI の急速な普及によって、この領域が短期間で混雑したことを認めています。現在では、マネージドサービス、軽量なプラグイン、そしてベクトル検索機能を提供する新規参入企業が増えています。表面的には、これらのソリューションの多くは似ているように見えます。
James の見解では、本当の違いは機能チェックリストによって決まるのではなく、基盤となるシステムの深さと成熟度によって決まります。基本的なベクトル検索機能を構築することは比較的容易です。しかし、長期間にわたって大規模に信頼性高く稼働できるシステムを構築することは容易ではありません。
システムの成熟度
Zilliz の優位性は、システムの成熟度、具体的にはスケーラビリティ、安定性、コスト管理から始まります。当初から Milvus は、データ量が数十倍に増えても安定性を維持できる、分散型で Kubernetes ネイティブなデータベースとして設計されました。これが重要なのは、ベクトルワークロードが滑らかにスケールすることはめったにないからです。小規模ではうまく機能するシステムでも、利用が継続的で、急激に変動し、予測しづらくなると苦戦することがよくあります。
コストもまた、その成熟度の一部です。Zilliz は早期から、メモリ、ディスク、オブジェクトストレージを組み合わせたマルチティアインデックスに投資しました。これによりユーザーは、単一の高価な運用モードに縛られるのではなく、ワークロードの進化に応じてパフォーマンスとコストのバランスを取るための実用的な柔軟性を得られます。
エンタープライズ対応
エンタープライズ対応は、もう一つの重要な差別化要因です。Jamesは、Zillizを、主にモデル中心またはAI中心のバックグラウンドを持つチームと対比しています。Zillizのルーツは従来型のデータベースエンジニアリングにあり、そのためアクセス制御、データ分離、BYOCデプロイメント、暗号化、コンプライアンスといった機能への早期投資につながりました。
これらの機能は、エンタープライズ規模では任意のものではありません。ベクトルデータベースが開発者の実験段階を超え、金融、医療、厳格なセキュリティおよびガバナンス要件を持つ大規模組織のような規制環境へ進むことを可能にするものです。
運用の信頼性
Jamesは、多くのチームがベクトルデータベースの長期的な運用の複雑さを過小評価していると指摘しています。初期のシステムは管理された環境ではうまく機能するかもしれませんが、データが急速に増加し、同時実行性が高まり、AIアプリケーションが継続的な本番運用に移行すると、本当の課題が現れます。
ほとんどの企業は、複雑なインフラの運用に時間とリソースを投資したいとは考えていません。特にベクトル検索のような高度に専門化された領域ではなおさらです。ここに、Jamesが考えるZillizの役割があります。つまり、ベクトルデータベースを大規模に運用する負担を引き受けることで、チームがインフラの保守ではなくアプリケーション構築に集中できるようにすることです。市場が成熟するにつれ、この分業はますます重要になります。
今後の展望：ベクトルデータベースの次の段階
今後3年から5年を見据えて、Jamesは業界の進む方向について現実的な見方をしています。成長は続きますが、重要な問いはもはやベクトルデータベースシステムを構築できるかどうかではなく、それらを持続可能な形で運用できるかどうかになります。モデルが大規模化し、AIアプリケーションが本番環境へより深く入り込むにつれて、データ量は急速に拡大し、コスト管理、信頼性、精度、セキュリティに対する基準が引き上げられます。
そのような環境では、検索品質を損なうことなくコストを一桁削減できる能力が、決定的なベンチマークになります。Jamesは、ここで持続的な優位性が形成されると考えています。ベクトルデータベース領域における長期的なリーダーは、機能や話題性によって決まるのではなく、インフラに対する規律、すなわち大規模システムを効率的かつ信頼性高く、長期にわたって運用する能力によって決まるのです。
議論の全編を聴くには、Spotify、Apple Podcasts、およびYouTubeでエピソードをご覧いただけます。
読み続けて
Introducing Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud
We're announcing the general availability of Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud.
Why and How to Migrate from Self-Hosted Milvus to Zilliz Cloud
A simple, step-by-step guide to migrating from Milvus to Zilliz Cloud. Learn both endpoint and backup methods for a smooth, scalable vector database migration.
Why Context Engineering Is Becoming the Full Stack of AI Agents
Discover how context engineering unifies prompts, RAG, and tools to build smarter, production-ready AI agents powered by Milvus.