2026.07.31 AI

Milvusとは？v3.0の外部コレクション・インデックス選定・デプロイ形態【2026年版】

Milvusは、数十億件規模のベクトルを扱う前提で設計されたOSSのベクトルデータベースです。ライセンスはApache-2.0、実装言語はGo、GitHubのスター数は45,430（2026年7月30日時点）。2026年7月29日にはv3.0.0が正式リリースとなり、データレイク上のファイルをコピーせず参照して索引を張る構成が加わりました。この記事では、4層アーキテクチャ、インデックスと量子化の選び方、Lite・Standalone・Distributedの線引き、pymilvusでの実装、2.6から3.0へ上げるときの互換境界を実装視点で整理します。

まとめ：Milvus採用の4条件と他のベクトルDBへ委ねる判断

Milvusを選ぶ理由は4つに絞れます。1つ目は規模の上限が高いこと。Distributed構成で1億から数百億ベクトルまで一続きに伸ばせます。2つ目はインデックスの選択肢が広く、メモリ・ディスク・GPUを跨いで再現率と費用のバランスを自分で決められること。3つ目は2.6のWoodpecker WALでKafkaやPulsarの運用が不要になったこと。4つ目はApache-2.0で、顧客環境へ組み込む受託案件でもライセンス上の制約が軽いことです。

見送る条件も明確です。数十万件規模でPostgreSQLをすでに運用しているならpgvectorで足ります。KubernetesもDockerも自前で持たない体制なら、マネージド型に寄せたほうが総額は下がります。v3.0.0は出たばかりなので、既存の2.6系本番を今すぐ移す必要もありません。Storage V3は既定で無効、新しいインデックス版もopt-inで、そこに触れない限り2.6へのロールバックが保証されます。まず3.0のバイナリへ上げ、外部コレクションは検証環境で試す順序を推奨します。

Milvusの定義とApache-2.0で自社ホストできる前提条件

Milvusは「ベクトルを入れる箱」ではなく、投入・索引構築・検索・コンパクションを別々のノードへ分けた分散データベースです。まず全体像から押さえます。

Zillizが開発しLinux Foundationへ寄贈したOSSという立ち位置

MilvusはZillizが開発し、Linux Foundation AI & Data配下のプロジェクトとして運営されています。ライセンスはApache-2.0で、特許条項を含む寛容型。コピーレフトの伝播がないため、顧客環境に組み込んで納品する受託開発でもソース開示の義務は生じません。GitHubのスター数は45,430、フォークは4,148（2026年7月30日時点）です。

実装はGoで、埋め込み生成そのものは外部に任せる設計です。テキストをベクトルへ変換する処理はアプリ側かfunction定義で行い、Milvusは格納と近傍探索に集中します。索引構造の前提から理解したい場合は、ベクトル化とインデックス構造から理解するベクトルデータベースの仕組みを先に読むと、以降のパラメータの意味がつかみやすくなるはずです。

Proxy・Coordinator・ワーカー・ストレージの4層構造

Milvusは4層に分かれています。アクセス層のProxyはステートレスで、リクエストの検証と結果の集約を担う前段。その下のCoordinatorはクラスタに1つだけactiveで動き、DDLとDCL、タイムスタンプの発行、WALとStreaming Nodeの束ね、Query Nodeのトポロジ管理、コンパクションと索引構築タスクの配布を受け持ちます。

ワーカー層は3種類です。Streaming Nodeはシャード単位の整合性を保証し、書き込み直後の growing データへのクエリに応え、成長中のセグメントを封止済みへ変換します。Query Nodeは履歴データを読み込んで検索を処理し、Data Nodeはコンパクションと索引構築を引き受けます。ワーカー自身は判断を持たず、指示はすべてCoordinatorから降りてくる構造です。

ストレージ層は3つで、メタ情報はetcd、索引ファイルやログのスナップショットはMinIOやS3、書き込みログはWoodpeckerが受けます。この分離があるため、投入が重い時間帯はData Nodeだけ、検索が重い時間帯はQuery Nodeだけを増やす資源配分ができます。

Woodpecker WALがKafkaとPulsarの運用を外した効果

2.6で入ったWoodpeckerは、Milvus専用に作られた書き込みログの実装です。従来はKafkaかPulsarを外部に立てる必要があり、メッセージキューの冗長化と監視まで抱える構図でした。Woodpeckerはオブジェクトストレージへ直接書くゼロディスク設計で、この依存を外します。

公表されているスループットは、S3モードで750MB/s（Kafka比5.8倍）、ローカルファイルシステムモードで450MB/s（同3.5倍）。数字そのものより、運用対象のミドルウェアが1つ減る点が現場では効きます。

v3.0の外部コレクションとStorage V3が変える置き場所

2026年7月29日に正式リリースされたv3.0.0は、内部形式の刷新と「レイクの上で索引を張る」構成の追加が主眼です。ここが2.x系の解説記事と最も食い違う部分になります。

External Collectionでレイクのファイルを複製せず索引する

External Collectionは、Lance・Iceberg・Parquet・Vortex 形式のファイルをMilvusへ取り込まずに参照し、その場に索引を構築する機能です。データのコピーが発生せず、読み取り専用として扱われます。データ基盤側にすでにテキストや特徴量が並んでいる案件では、ETLを1本減らせます。

外部フィールドからfunctionの出力を生成できる点も見逃せません。BM25の疎ベクトルや埋め込みを、外部テーブルの列を入力として作れます。milvus-table 形式ではSnapshotメタ自体を外部ソースにでき、分析基盤と検索基盤で同じ実体を共有できます。

Storage V3（Loon）とSnapshotが揃えた時点指定の読み取り

Storage V3は、オブジェクトストレージ上にマニフェストを置くカラムナ形式です。どのカラムグループとデルタログでデータセットが構成されるかを、Avro形式の不変スナップショットとして記録します。メタデータのオーバーヘッドはほぼゼロで、外部コレクションとSnapshotの土台です。

Snapshotは、セグメント参照によるpoint-in-timeの読み取り専用ビューで、追加ストレージはほぼ発生しません。ライブのコレクションが書き込みを受け続けている裏で、バッチ処理と検索系が同一時点のデータを見られます。

疎ベクトル索引の刷新で圧縮後のBM25索引が3分の1になった

疎ベクトル側も入れ替わりました。SINDI、Block-Max WAND、Block-Max MaxScore といったアルゴリズムが入り、転置リストの圧縮と量子化を設定できます。公表値では、同等の再現率で圧縮後のBM25索引がおおよそ2.6の3分の1に収まります。全文検索とベクトル検索を同居させるRAG構成では疎ベクトル側のメモリが効くため、ここが実務上の差になる部分です。

後段も変わり、Function Chain リランクがL0の早期再スコアとL2の後段リランクを順に実行します。スキーマ側も、止めずにカラムを追加・削除できるようになりました。

2.6から3.0へ上げるときの互換とロールバック保証の境界線

移行の判断材料になる注記が明示されています。Storage V3（Loon）は既定で無効で、有効化は手動です。新しいインデックス版もopt-inで、使うにはバージョン指定が要ります。そしてStorage V3の機能に手を出すまでは、2.6から3.0への互換とロールバックが保証されます。

つまり移行は二段階に割れます。第一段はバイナリを3.0へ上げるだけの更新で、ここは戻せる範囲。第二段はStorage V3と外部コレクションを有効化する更新で、ここを越えるとロールバックの保証から出ます。本番では第一段だけ先に済ませ、第二段は検証環境で手順が固まってから入れる進め方が安全です。GPUを使う場合はもう1点、v3.0のGPUイメージが CUDA 12.9 前提でUbuntu 20.04 をサポートしないため、基盤側のOS更新が先行タスクになります。

Milvusのインデックスと量子化をメモリ費と再現率から決める

Milvusの設定で最も費用に効くのは索引の型です。選択肢が多い分、指針を持たないと決められません。

メモリ・ディスク・GPUに分かれる索引ファミリーの全体像を掴む

索引は置き場所で3系統に分かれます。メモリ系はFLATとIVF族（IVF_FLAT・IVF_SQ8・IVF_PQ・IVF_RABITQ）、HNSW族（HNSW・HNSW_SQ・HNSW_PQ・HNSW_PRQ）。ディスク系はDiskANNで、Vamanaグラフに PQ 圧縮を組み合わせて10億点規模をSSDへ載せます。GPU系は GPU_CAGRA・GPU_IVF_FLAT・GPU_IVF_PQ。ほかにバイナリ向けの BIN_FLAT、疎ベクトル向けの SPARSE_INVERTED_INDEX があります。

索引 置き場所 向く場面
FLAT メモリ 全件走査で再現率100%
IVF_FLAT メモリ topK 2000超の大量取得
IVF_RABITQ メモリ 1ビット量子化で費用減
HNSW メモリ 低Kで再現率と速度を両立
HNSW_SQ メモリ HNSWのメモリを段階圧縮
DiskANN ディスク 10億点規模をSSDに置く
GPU_CAGRA GPU 高QPSをGPUで押し切る
SPARSE_INVERTED_INDEX メモリ BM25と疎ベクトルの検索

距離計算のメトリックは、浮動小数ベクトルが L2・IP・COSINE、バイナリが JACCARD・HAMMING、疎ベクトルが IP と BM25 です。埋め込みモデルの多くはコサイン前提なので、迷ったらCOSINEから入り、仕様書に内積が明記されている場合だけIPへ替えます。

RaBitQの1ビット量子化がメモリを72%削った実測値の読み方

2.6で入った IVF_RABITQ は、1ビット量子化でベクトルを原寸の約3%まで圧縮します。公表されている効果はメモリ72%削減とクエリ4倍速。ここに SQ8 による精緻化を併用すると、再現率95%を保ったままメモリは基準比28%に収まり、スループットは 236 QPS から 946 QPS へ伸びています。

実務での読み方はこうです。1,536次元・1,000万件を素で持てば約59GBのメモリが要りますが、1ビット量子化を噛ませれば十数GB級まで落ちます。ただし量子化は再現率を削る操作なので、評価セットで recall@10 を測ってから本番へ入れる手順は外せません。

検索のtopKとフィルタ率で索引を切り替えるときの判断の分岐点

公式の選択指針は素直です。原データがメモリに載り、topKが小さい検索が主ならグラフ系（HNSW）が有利。topKが2,000を超えるような大量取得ではIVF族のほうが向きます。スカラー条件で候補が絞り込まれ、フィルタ率が98%を超えるケースでは、索引のオーバーヘッドを避けてFLATで走査したほうが速くなります。

10億点を超えるならDiskANNでグラフをディスクへ逃がします。RAGの一次検索は topK 20〜50 で足りることが多いため、実務ではHNSW系かIVF_RABITQのどちらかに落ち着く場面が大半です。

Lite・Standalone・Distributedを規模で線引きする基準

Milvusは同じAPIで3つの動かし方を持ちます。取り違えると、検証で快適だったものが本番で詰まります。

3つのデプロイ形態が想定する規模と制約の違いを一覧表で整理する

形態 規模の目安 前提と制約
Milvus Lite 数百万ベクトルまで Python限定・本番想定外
Standalone 1億ベクトルまで Docker単一イメージ
Distributed 1億〜数百億 Kubernetes前提

Milvus Liteはアプリへ import して使うPythonライブラリで、ノートブックや資源の限られた端末での試作を想定した構成。アクセス制御やパーティションは持たず、公式にも本番用途は想定外と書かれています。Standaloneは全コンポーネントを単一のDockerイメージへ詰めた構成で、拡張性より立ち上げの速さが要る初期の本番に向きます。Distributedは投入と検索を別ノードへ分離でき、可用性と資源配分の自由度が最も高い形態です。

検証環境から本番へ移すときに書き換えるのは接続先の文字列だけ

3形態はクライアントAPIが共通です。Milvus Liteはローカルのファイル名を、StandaloneとDistributedはエンドポイントのURIを渡します。つまり検証コードは接続文字列の差し替えだけで本番へ持ち上がります。

ただしLiteにはパーティションもロールも無いため、マルチテナントの設計をLite上で確かめることはできません。テナント分離を含む案件では、検証の段階からStandaloneをDockerで立てておくほうが手戻りは少なくなります。単一クラスタで最大10万コレクションを扱える点も、テナントごとにコレクションを切る設計の材料です。

pymilvusで最小構成のRAG検索を組むところまでの実装手順

ここからは実装です。Milvus Liteで動く最小の形から始めます。

Milvus Liteでコレクション生成から近傍検索までを通す最小コード

ファイル名を渡すだけでLiteが起動し、サーバの準備は要りません。

from pymilvus import MilvusClient

client = MilvusClient("milvus_demo.db")

client.create_collection(
    collection_name="docs",
    dimension=1024,
    metric_type="COSINE",
)

client.insert(collection_name="docs", data=rows)

res = client.search(
    collection_name="docs",
    data=[query_vector],
    limit=5,
    output_fields=["text"],
)

rows は id・vector・text を持つ辞書のリストです。次元数は埋め込みモデルに合わせます。この段階では索引の型を指定していないため、Milvusが既定の索引を張ります。件数が数万を超えたら索引を明示してください。

IVF_RABITQを明示してメモリ費を抑える索引定義の書き方

索引はコレクションとは別に定義します。量子化を効かせるならここで型を指定します。

index_params = client.prepare_index_params()

index_params.add_index(
    field_name="vector",
    index_type="IVF_RABITQ",
    metric_type="COSINE",
    params={"nlist": 1024},
)

client.create_index(
    collection_name="docs",
    index_params=index_params,
)

nlist はクラスタ数で、件数の平方根前後から調整します。検索時は nprobe を上げるほど再現率が上がり、遅くなります。この2つを評価セットで振り、必要な recall を満たす最小の nprobe を決める作業が索引調整の実体です。

密ベクトルと疎ベクトルを1回で束ねるハイブリッド検索の実装例

RAGの検索精度は、意味検索とキーワード検索を併用したときに上がります。Milvusは両方を1つのリクエストで受け、RRFで融合できます。

from pymilvus import AnnSearchRequest, RRFRanker

dense = AnnSearchRequest(
    data=[query_vector],
    anns_field="vector",
    param={"nprobe": 32},
    limit=20,
)

sparse = AnnSearchRequest(
    data=[query_text],
    anns_field="sparse",
    param={"drop_ratio_search": 0.2},
    limit=20,
)

res = client.hybrid_search(
    collection_name="docs",
    reqs=[dense, sparse],
    ranker=RRFRanker(60),
    limit=5,
)

疎ベクトル側はBM25のfunctionを定義しておけば、テキストを渡すだけでMilvusが疎ベクトルへ変換します。融合の仕組みと重み付けの考え方はハイブリッド検索とは？RAGでBM25とベクトル検索を統合する仕組み・RRF・実装コードで整理しています。日本語文書ではトークナイザの選択が精度を左右するため、アナライザ設定は必ず実データで確かめてください。

Milvusの費用が実際に決まる場所と量子化から始める削減の順序

ベクトルDBの費用は、保持しているベクトルの本数ではなくメモリの載せ方で決まります。Milvusには費用を下げる仕掛けが3つあります。

ホットコールド階層ストレージとJSONパス索引で効く2つの削減策

1つ目はホットコールドの階層ストレージです。アクセス頻度に応じてデータを高速なストレージと安価なストレージへ自動で振り分け、ストレージ費を最大50%削減します。全期間の文書を検索対象に残したまま、直近以外を安いほうへ寄せられます。

2つ目はJSONパス索引です。ネストしたメタデータへのフィルタ遅延が140msから1.5msへ縮んだと公表されています。テナントIDや文書種別をJSONに持たせる設計でも、フィルタが遅いから索引を分割する、という妥協が要りません。3つ目は前述の量子化で、削減幅はここが最も大きい。量子化でメモリを削り、階層ストレージでコールド分を逃がし、足りなければノードを増やす順で当たるのが定石です。

マネージド型のZilliz Cloudを選ぶ場合に確かめる項目

自社で運用しない選択肢がマネージドのZilliz Cloudです。無料枠・従量課金・専有クラスタで提供されますが、単価は改定が入るため金額は書きません。見積り時は、保存容量の単価、演算リソースの課金単位、リージョンの選択肢、SLAの水準、監査ログやSSOの可否という5点を公式ページで実機確認してください。国内保管が条件なら、リージョンの実在をコンソール上で確かめます。

自社ホストとマネージドの分岐は、ベクトルの本数ではなく体制で決まります。Kubernetesを日常的に運用しているチームがあるならDistributedの自社ホストが安く、そうでないならマネージドの月額のほうが人件費込みで安い。設計の当て方や既存文書の取り込みから相談したい場合は、RAG構築支援で実装まで含めて対応しています。

Milvusを採用する条件と他のベクトルDBへ委ねる場面の線引き

ここまでの内容を採用判断の形に落とします。曖昧に併記せず、条件で言い切ります。

この4条件のうち3つが揃うならMilvusを採用して問題ない

第一に、ベクトルが1,000万件を超える見込みがあること。この規模から、量子化とノード分離で費用を制御できる設計が効いてきます。第二に、KubernetesかDockerの運用主体が社内にあること。第三に、密ベクトルと疎ベクトルを同居させ、フィルタ条件も併用する検索要件があること。索引の型と融合の方式を自分で選べる利点が出ます。第四に、顧客環境へ組み込む納品形態であること。Apache-2.0ならライセンス確認で止まる場面がほぼありません。この4つのうち3つ以上に当てはまるならMilvusで組んで問題ない。逆に1つも当てはまらない案件で選ぶと、運用の手数だけが増えます。

pgvector・Pinecone・Weaviateへ寄せたほうがよい3場面

1つ目は、データが数十万件規模でPostgreSQLをすでに運用している場合。同じDBに収まるほうがバックアップも権限管理も一元化できます。pgvectorの基本概要とPostgreSQLにおけるベクトル検索の重要性で構成の当て方を確認してください。

2つ目は、インフラ運用の担当を置けない場合。サーバレス型に寄せると容量計画そのものが不要になります。料金体系と制限値の読み方はPineconeとは？サーバーレス型ベクトルDBの料金・制限値・実装と選び分けにまとめました。3つ目は、テナントごとの分離が要件の中心にある場合。テナントをシャードとして扱う製品のほうが素直に組めるため、Weaviateとは？ハイブリッド検索・マルチテナンシー・料金と選定基準と比較して決めるのが妥当です。

よくある質問

Milvusは無料で使えますか？

OSS版はApache-2.0で公開されており、自社ホストする限り利用料はかかりません。費用が発生するのはサーバとストレージの実費です。マネージドのZilliz Cloudでは無料枠を超えた分が課金対象になります。

Milvus LiteとStandaloneはどちらを使うべきですか？

数百万ベクトルまでの試作ならLiteで足ります。ただしLiteはPython SDK限定で、公式にも本番用途は想定外と書かれています。テナント分離や権限管理を検証に含めるなら、最初からStandaloneをDockerで立ててください。

v3.0.0へすぐ移行すべきですか？

本番の2.6系を急いで移す必要はありません。3.0はバイナリを上げるだけなら2.6へのロールバックが保証され、その保証はStorage V3を有効化した時点で外れます。外部コレクションとStorage V3は検証環境で手順を固めてから本番へ入れてください。

MilvusとElasticsearchは併用すべきですか？

2.6でBM25の全文検索が強化され、Elasticsearch比で3〜4倍のスループット（条件により7倍QPS）が公表されています。検索用途がRAGの文書取得に閉じるなら、Milvus側へ寄せて構成を1つ減らす判断が成り立ちます。ログ分析や集計を兼ねている場合は、併用のまま役割を分けるほうが無理はありません。

日本語の文書でも精度は出ますか？

密ベクトル側の精度は埋め込みモデルで決まるため、日本語対応のモデルを選べば問題は出ません。差が出るのは疎ベクトル側で、BM25のトークナイザ設定が効きます。既定のままだと日本語が分かち書きされず、キーワード一致がほぼ機能しません。アナライザを日本語向けに設定してから本番へ入れてください。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る