45K starsのMilvus、ベクトル検索を10億規模のAI基盤へ変えたOSS

冒頭：検索を「機能」から「基盤」へ

Milvusは、LLMアプリケーションの裏側でembeddingを検索するdatabaseを、ノートPCのprototypeから大規模clusterまで伸ばそうとしてきた。

公式docsは2022年にbillion-scale vectors、2023年にtens of billionsへ拡張した歩みを説明している。出典

創業：Zillizから始まったOSS

Zillizは2017年創業で、Charles XieがCEOを務める。

会社は自分たちをMilvusを作ったengineers and scientistsと説明し、公式aboutにはCharles Xieの写真と役職を掲載している。出典

Charles Xieは、Zillizの使命を「複雑なdata infrastructure managementの負担を取り除き、AIの力をすべての組織へ届けること」と説明している。出典

転機・苦労：規模に合わせて作り直す

vector searchはdemoなら速くても、データ量と同時実行数が増えるとindex、storage、queryを別々に考えなければならない。

MilvusはLite、Standalone、Distributedの3つのdeployment modeを整え、architectureではstateless proxyと分離されたquery・data・indexの役割を示す。出典

成長・成功：性能を数字とcommunityで伝える

公式benchmarkはMilvus 2.2.0について、2.5倍のsearch latency削減、4.5倍のQPS増加、billion-scale similarity searchを報告した。出典

GitHub repositoryはApache 2.0 licenseで公開され、2026年8月時点で45.9K starsを表示している。出典

この成長は、databaseの機能だけではなく、Python SDK、各種integration、docs、communityを一緒に配った結果だ。

Zilliz公式は$113Mのinvestmentと10,000+ enterprise usersも掲げているが、これはMilvus OSS単体の売上ではなく、Zilliz全体の会社情報として読む必要がある。出典

結び：OSSを入口に運用価値へ

Milvusの物語は、検索engineをOSSで配り、localからdistributedへ移れる導線を作り、managed serviceで運用の難しさを引き受ける物語だ。

AI infrastructureでは、モデルの派手さより、データが増えた後も同じ開発体験を保てるかが採用を左右すると考えられる。

MilvusのPMFは、LLMアプリケーションで増え続けるembeddingを、既存のRDBだけでは扱いにくい検索インフラへ変換した点にある。

RAG、画像検索、hybrid searchを作る開発者は、Milvus Liteで試し、StandaloneやDistributedへ同じ概念を持ち込める。出典

対象は単なるAI研究者ではなく、検索品質と運用スケールを同時に求めるproduct teamだ。

OSSで導入障壁を下げ、Zilliz Cloudで運用負荷を引き受ける二層構造が、個人開発からenterpriseまでの連続性を作る。

Moatは、C++の検索engine、複数index、hardware optimization、分散architectureを一体で保守する実装蓄積にある。出典

Apache 2.0でcodeは開いているため、単純なlicenseではなく、contributors・integrations・運用知識の集合が防壁になる。

ネットワーク効果は中程度。

利用者が増えるほどSDK、connector、tutorial、benchmarkが増え、導入判断は容易になる。出典

ただしdatabase単体は利用者同士が直接つながるmarketplaceではないため、強いnetwork effectよりecosystem effectと見るのが妥当だ。

主なtargetは、RAGやrecommendation、semantic searchを構築するAI engineerと、数百万から数十億vectorの検索基盤を運用するplatform teamだ。

Milvus Liteは学習・prototype向け、Distributedは大規模Kubernetes向けで、規模に応じて選べる。出典

小規模なkeyword searchだけを求めるチームには過剰になり得る。

第一はdeploymentの段階設計だ。

Python library、single-machine、Kubernetes分散を同じproduct familyで提供し、試作から本番への移行コストを抑える。出典

第二はhardware-awareな検索engineと、compute/storageを分離したarchitecture。

公式benchmarkはMilvus 2.2.0で2.5倍のlatency削減、4.5倍のQPS増加を報告している。出典

OSSを入口にcommunityとcloudを接続したことも再現可能な要因だ。

最大のリスクは、vector searchの性能を引き出すための運用複雑性だ。

StandaloneからDistributedへ進むほど、Kubernetes、index、consistency、resource tuningの知識が必要になる。出典

また、vector database市場は競争が激しく、検索engineのbenchmarkはdataset・hardware・parameterに依存する。

OSSの強さを保ちながらmanaged serviceの収益を伸ばせるかは、公開情報だけでは要確認だ。

成長戦略はOSSをdeveloper acquisitionに使い、managed Zilliz Cloudへ運用の課金点を置くことだ。

GitHub、docs、community、LangChainやLlamaIndexなどのintegrationが発見と導入を担う。出典

この設計はbottom-upに強い一方、OSS利用が必ずcloud売上へ転換するわけではない。

self-hostedの価値を削らず、enterpriseのsecurity・scale・supportで差を作る必要がある。

主要チャネル: github, developer community, documentation, events, partners

インフラproductでは、最初から最大構成だけを売るより、local prototypeからproductionまでの移行経路を設計した方が採用を広げやすい。

MilvusのLite、Standalone、Distributedという段階は、学習コストを分割する。出典

OSSの成長はstarsだけで完結しない。

検索性能、docs、SDK、cloudの運用価値を一つの導線にして初めて、communityが事業の入口になる。

日本で展開するなら、社内文書検索や製造業の画像・センサーデータを対象に、localまたは国内cloudで閉じる導入テンプレートを用意したい。

個人情報・機密データを外へ出せない企業にはself-hostedが刺さる一方、Kubernetes運用者不足が障壁になるため、SIer向けの監視・バックアップ・日本語runbookまで商品化するのが現実的だ。