2026 年 5 月のリリースノート

2026-05-13

[BYOC] マルチデータプレーンサポート

Zilliz Cloud BYOC は、単一のプロジェクト内で複数のデータプレーンをサポートするようになりました。BYOC プロジェクトは複数のリージョンにまたがることができ、各データプレーンはリージョン固有のインフラストラクチャ単位を表します。

• BYOC プロジェクト内の複数のデータプレーンと、データプレーン管理用の新しいデータプレーンページ

• プロジェクト内で対象のリージョン/dataplane を選択してクラスターを作成します。

既存の BYOC プロジェクトは互換性を保ち、データ移行は不要です。現在の BYOC プロジェクトは、1 つのデータプレーンを持つプロジェクトとして引き続き動作します。

詳細については、AWS への BYOC のデプロイ、AWS への BYOC-I のデプロイ、Microsoft Azure への BYOC-I のデプロイ、GCP への BYOC のデプロイ を参照してください。

2026-05-09

ベクトル Lakebase パブリックプレビュー

このメジャーリリースでは、Zilliz Cloud はベクトルデータベース製品から ベクトル Lakebase プラットフォームへ進化します。

アップグレード後、従来のベクトルデータベースサービスは、レイテンシーが重要なワークロード向けのリアルタイムサービングレイヤーになります。一方、プラットフォームはデータとコンピュートの全体的な機能を拡張し、最新の AI アプリケーションとエージェントアプリケーションに必要なセマンティック検索と分析のワークフローループをより適切にサポートします。

ベクトル Lakebase は、S3 ベースの統合データ基盤上に構築され、3 つのアクセスモードで AI とエージェントのワークロードを支援します:

• レイテンシーが重要な本番サービング向けのリアルタイム検索、

• インタラクティブで多段階の探索向けの反復的な探索、

• オフラインマイニングとデータセット最適化向けのバッチ分析。

ベクトル Lakebase は、完全に分離されたストレージ・コンピュートアーキテクチャ上に構築されています。データはデータベースに保存されます。データベースはコンピュートクラスターから独立したプロジェクトレベルのベクトルストアであり、チームはテキスト、JSON、ラベル、地理空間データ、その他の種類の属性とともに、無制限のベクトルを保存できます。

特に、Zilliz ベクトル Lakebase では、次の主要な機能が導入されています:

On-Demand Search

インタラクティブな探索とバッチ分析は、多くの場合、フィードバックデータ、ログ、エージェントのメモ、クロールされたコーパスなど、オンラインサービングより 1〜3 桁大きいデータセットを処理します。これらのワークロードは通常、継続的にアクティブではなくタスク駆動型であり、コンピュートリソースは時間の 97% 以上アイドル状態になります。そのため、大規模な常時稼働のベクトルデータベースクラスターを使用することは、コスト面から正当化するのが難しいことがよくあります。

Zilliz On-Demand Search は、オブジェクトストレージとオンデマンドコンピュートに対して直接課金します。これは AWS Lambda と同様で、料金は主に割り当てられたリソースサイズと実行時間に基づき、ストレージコストは基盤となる S3 のコストに近い水準に保たれます。

これらの非常時稼働ワークロードでは、On-Demand Search と Serverless の両方が従量課金モデルに従います。ただし、当社の実験では、月あたり累積 10 時間のアクティブなコンピュートを伴う 10 億ベクトルのワークロードにおいて、On-Demand Search の総コストは Serverless の約 1/15 にすぎません（$318 対 $4,937）。

詳細については、On-Demand Search のクイックスタート および オンデマンドコンピュートのコスト を参照してください。

External Data Lake Search

Zilliz ベクトル Lakebase は、完全に管理されたストレージとクエリコンピュートを提供しながら、既存のデータレイクインフラストラクチャとガバナンスパイプラインを持つ顧客もサポートします。

AI ワークロードでは、データレイク上のデータを直接使用して効率的な取得とセマンティック探索を可能にすることが重要な課題です。Spark や Ray などの従来のシステムは、インデックスで高速化されたセマンティック検索ではなく、全データスキャンと map-reduce 計算に最適化されています。

これに対処するため、Zilliz は外部コレクションモードを提供します。これは、顧客所有のデータレイクテーブルへのゼロコピーの論理マッピングであり、高性能なインデックス作成と全スペクトルの検索機能がその上に構築されています。

既存のデータレイクのインデックス作成と高速化の方法については、外部データレイク検索のクイックスタート を参照してください。

ベクトル Lakebase は、Zilliz Cloud コンソール、REST API、PyMilvus、Zilliz CLI からアクセスできます。コンピュート、ストレージ、ストレージリクエストにわたる使用量ベースの課金が導入され、Query CU、Indexing CU、プロジェクトデータベースストレージ、ストレージリクエストが含まれます。

Milvus 3.0 パブリックプレビュー

ベクトル Lakebase のローンチとともに、Zilliz は Milvus 3.0 のパブリックプレビューもリリースします。このバージョンでは、Milvus はオープンデータフォーマットと、既存のデータレイクおよび大規模データ処理エンジンとのより広範な統合を通じて、ベクトルデータベース機能を AI データインフラストラクチャスタックへ拡張します。

Notes

このリリースでは、Milvus 3.0 の機能はオンデマンドクラスターでのみサポートされます。サービングクラスターはまだサポートされていません。

外部データとストレージフォーマット

• 外部コレクション — データを Milvus にコピーせず、オブジェクトストレージ（Parquet、Lance、Vortex、Iceberg）上で直接参照します。Milvus はスキーマ、インデックス、クエリ実行のみを管理します。増分 Refresh により、コレクションはソースファイルの変更と同期した状態に保たれ、単一のデータセットを複数のインスタンスから同時に提供できます。

  詳細については、外部コレクションの作成 を参照してください。

• 外部バックフィル （プライベートプレビュー） — ダウンタイムなしで、稼働中のコレクション上の埋め込みモデルをアップグレードします。AddCollectionField を使用して新しいベクトルフィールドを追加し、Snapshot で一貫性のある開始ポイントを固定して、埋め込みジョブをオフラインで実行し、通常の取り込みパスを通じて値を書き戻します。新しい列にインデックスが作成されると、アプリケーションが切り替わります。

  外部バックフィルのプライベートプレビューに参加するには、お問い合わせください。

スキーマとデータモデリング

• Null ベクトル — 6 種類すべてのベクトル型にわたって、ベクトルフィールドを NULL 許容にできます。検索時に NULL 行は自動的にスキップされ、検索品質に影響を与えません。また、NULL ベクトルは実質的にストレージを消費しません。既存のコレクションでは、再構築せずに AddCollectionField を使用して、NULL 許容の新しいベクトル列をオンラインで追加できます。

  詳細については、NULL 許容フィールド および デフォルト値 を参照してください。

• EmbList + DiskANN — エンティティごとに可変長のベクトルリストを保存し、DiskANN によってディスク上にインデックスを作成します。長いドキュメント、ColBERT などの late-interaction モデル、マルチモーダルエンティティに適しており、大規模なコーパスサイズでも RAM を制御下に保ちます。

  詳細については、StructArray の概要 および StructArray オペレーター を参照してください。

• MinHash DIDO（Doc-in、Doc-out） — MINHASH_LSH にサーバー側の MinHash 関数を追加します。Milvus は挿入、一括挿入、検索の際にシグネチャを自動計算するため、重複排除、フィンガープリント、盗用検出のワークフローでアプリケーション側の前処理は不要です。

  詳細については、MinHash 関数 を参照してください。

検索とランキングの制御

• Query / Search Order By — 検索結果とクエリ結果に対して複数フィールドの並べ替えを実行でき、フィールドごとに ASC / DESC を指定してカーネルにプッシュダウンします。複合ランキングのために過剰に取得したり、クライアント側で再並べ替えしたりする必要はなくなりました。

  詳細については、基本的なベクトル検索、Grouping Search、および クエリ を参照してください。

データライフサイクルと運用

• Snapshot — データをコピーせずに既存のセグメントを参照する、コレクションの特定時点の読み取り専用ビューです。バッチジョブは MVCC 方式の分離の下で実行され、稼働中のコレクションは書き込みを受け付け続けます。A/B 評価、重複排除、バックフィル検証に適しています。

  詳細については、Snapshot および Snapshot の管理 を参照してください。

• Entity TTL（行レベル TTL） — Timestamptz TTL フィールドによる行単位の有効期限です。期限切れの行は自動的に回収され、保持コンプライアンス、セッションデータ、会話履歴に対応します。アプリケーション側のクリーンアップは不要です。

  詳細については、コレクション TTL の設定 を参照してください。

• Force Merge — オフピーク時間帯に（同期または非同期で）セグメントの Compaction を明示的にトリガーし、セグメントの断片化によるクエリレイテンシーのジッターとストレージオーバーヘッドを削減します。

テキストと Spark を活用したデータ処理

• カスタム辞書とトークナイザー （プライベートプレビュー） — FileResource メカニズムを介して、カスタムトークナイザー辞書、同義語リスト、ストップワードリスト、decompounder ルールを登録します。BM25、アナライザー、Text Match に反映され、アプリケーションコードに分散させるのではなく、一元的にバージョン管理されます。

• Spark セマンティック重複排除 （プライベートプレビュー） — 大規模な Spark データ処理向けのセマンティック重複排除をサポートします。

• Spark 異常検出 （プライベートプレビュー） — Spark ベースのデータ処理中に、異常なレコードまたはパターンを検出します。

  上記のいずれかの機能のプライベートプレビューに参加するには、お問い合わせください。

外部ボリューム

Zilliz Cloud は、マネージドボリュームに加えて外部ボリュームをサポートするようになりました。外部ボリュームは、ユーザー自身のクラウドオブジェクトストレージ内のバケットまたはパスへの読み取り専用の参照です。これにより、Zilliz Cloud はデータを最初に Zilliz Cloud にコピーすることなく、インポート、移行、外部コレクションのワークフロー向けに、ソースデータをその場で読み取ることができます。

• データが存在する場所でデータを使用する — 外部ボリュームを AWS S3 または Google Cloud Storage のパスに指定します。データはバケット内に保持され、Zilliz Cloud は必要なときにのみデータを読み取ります。

• 制御されたリージョンアクセス — アクセスは Storage Integration と Zilliz Cloud RBAC を通じて管理され、認可されたプロジェクトユーザーのみが外部ボリュームを作成または管理できます。

詳細については、外部ボリューム を参照してください。

Large TopK

Large TopK はコレクションレベルでサポートされるようになり、有効化されたコレクションでは返されるエンティティの最大数が 16,384 から 1,000,000 に拡張されます。サービングクラスターとオンデマンドコンピュートの両方で利用でき、データマイニングおよびバッチ分析のワークロードに最適です。候補生成、モデル評価、大規模な類似検索などのユースケースで、より広範な候補のリコールを可能にします。

詳細については、Large TopK の使用 を参照してください。

機能強化

• リージョン対応のプロジェクトガバナンス — プロジェクトにはリージョン制約が含まれるようになり、企業がデータレジデンシーを管理し、リージョン単位のデータプレーンアクセスを明示的に保つことができます。リージョンモデルは、Zilliz Cloud コンソールと API の両方に反映されます。

• Zilliz CLI の更新 — Zilliz CLI は、Lakebase、外部ボリューム、リージョン対応の操作、料金関連の更新など、このリリースの変更をカバーするように更新されました。詳細は、Zilliz CLI のエクスペリエンスを参照してください。