RAGやセマンティック検索の運用では、データの増加に合わせて、検索性能、運用負荷、コストを見直すタイミングがやってきます。Qdrantを利用していて、MilvusベースのマネージドサービスであるZilliz Cloudを検討している方もいるのではないでしょうか。
Zilliz Cloudには、Qdrantの接続情報を指定してデータを取り込む移行機能があります。この記事では、コンソールを使った移行から、インデックスの作成、ロード、検索の動作確認までを紹介します。
押さえておきたいのは、データの移行完了と、アプリケーションの切り替え完了は別だということです。 データをコピーした後にも、検索できる状態への準備と、検索結果の検証が必要になります。
本記事は2026年9月26日時点の公式ドキュメントと、提供された操作デモ録画をもとに構成しています。画面名や利用可能な設定は、環境や更新によって異なる場合があります。デモで確認できた操作と、本番移行に向けた推奨事項を分けて説明します。
実際の操作を先に確認したい方は、操作動画をご覧ください。
なぜZilliz Cloudへ移行するのか
Zilliz Cloudへの移行を検討する主な理由は、データ規模の拡大に対応しながら、検索性能、コスト、運用負荷をまとめて最適化できることです。
| 課題 | Zilliz Cloudで期待できること |
|---|---|
| データ量の増加 | コンピュートとストレージを分離して拡張できます。Tiered Storageでは、メモリ、SSD、オブジェクトストレージを使い分け、大量のデータを効率よく保持できます。 |
| インデックスの調整 | AUTOINDEXがワークロードに応じたインデックスを選択し、精度と性能の調整にかかる負担を抑えます。 |
| RAGの検索品質 | ベクトル検索に加え、BM25全文検索、DenseとSparseのハイブリッド検索、リランキングを一つの基盤で利用できます。 |
| トラフィックの増加 | Dedicatedクラスタでは、Query CUやレプリカを追加して容量と検索スループットを拡張できます。自動スケーリングやスケジュールスケーリングにも対応しており、本番環境の負荷変動に合わせてリソースを調整できます。 |
| 可用性と復旧 | スナップショット、バックアップ、PITR、Global Clusterによるリージョン間の切り替えなどを利用できます。 |
| セキュリティと運用 | RBAC、SSO、監査ログ、保存時・通信時の暗号化、CMEKなど、企業向けの管理機能を利用できます。 |
| AI開発との連携 | 各種SDK、AIフレームワーク、Embedding・Rerankingモデル、ETLや監視ツールとの統合が用意されています。 |
検索対象や利用者が増え、性能改善と基盤運用の両方に時間がかかるようになったチームにとって、Zilliz Cloudは検索基盤の管理負担を減らし、アプリケーション開発に集中するための選択肢になります。
各機能の利用可否や上限は、プラン、クラウド、リージョン、クラスタ構成によって異なります。導入前に最新のドキュメントを確認してください。
今回の移行例
操作デモでは、QdrantのコレクションをZilliz CloudのDedicatedクラスタへ移行しています。記事中では、次の構成を例に進めます。
| 項目 | デモで確認できる構成 |
|---|---|
| 移行対象コレクション | qdrant_migration_demo |
| 移行先データベース | qdrant_migration |
| 主キー | id |
| ベクトルフィールド |
dense_vector、384次元 |
| 固定フィールド |
section_title、year、text、source_url
|
| ベクトルインデックス | AUTOINDEX、COSINE |
デモの次元数や距離指標は、すべてのデータに共通する設定ではありません。自分のQdrantコレクションで使っている埋め込みモデル、次元数、距離指標を先に確認してください。
今回の流れは次のとおりです。
Qdrantの接続情報を準備
→ 移行元・移行先を選択
→ フィールドの対応を確認
→ 移行ジョブを実行
→ インデックスを作成
→ コレクションをロード
→ データと検索結果を確認
操作動画
以下の動画では、Qdrantの接続設定からZilliz Cloudへのデータ移行、インデックス作成、Collectionのロード、検索確認までの一連の操作を紹介しています。
動画が表示されない場合は、YouTubeで視聴することもできます。
1. 移行前の準備
Qdrant側では、対象クラスタのエンドポイントと、対象データを読み取れるAPIキーを用意します。デモでは、クラスタのOverviewとAPI Keys画面で確認しています。
前提は、移行元がパブリックインターネットから到達可能で、対象コレクションにデータがあることです。Zilliz Cloud側ではOrganization OwnerまたはProject Adminの権限と、十分なクラスタ容量が必要です。IP制限を利用している場合は、指定されたZilliz CloudのIPアドレスを許可します。Qdrant移行の前提条件
移行先には、既存データと混同しないデータベースやコレクション名を用意すると検証しやすくなります。たとえば、まず検証用データベースへ移し、アプリケーションの接続先を切り替える前に結果を確認する方法です。
本番データに更新が入っている場合は、コピー中の追加・更新・削除をどう扱うかも決めておきます。小規模な移行なら、書き込みを一時停止して移行と検証を行う方法が考えられます。停止できない場合は、差分の記録・再反映や二重書き込みを含む設計が必要です。
本記事のコンソール操作だけで、継続的な差分同期や無停止切り替えまで保証されるとは扱いません。無停止移行が必要な場合は、Qdrantからの移行で利用できる方式と条件を事前に確認してください。
2. Migrationsから移行元と移行先を指定する
Zilliz Cloudコンソールで対象プロジェクトを開き、MigrationsからQdrantの移行画面へ進みます。
接続設定では、準備したQdrantのエンドポイントとAPIキーを指定し、接続を確認します。その後、移行するコレクションと、移行先のZilliz Cloudクラスタ・データベースを選択します。外部データソースの移行手順
ここでは、次の組み合わせを確認してからマッピング画面に進みます。
| 設定 | 今回の例 |
|---|---|
| 移行元 | Qdrantの対象クラスタ |
| 対象コレクション | qdrant_migration_demo |
| 移行先 | 利用するZilliz Cloudクラスタ |
| 移行先データベース | qdrant_migration |
3. Review Mappingsでスキーマを確認する
デモのReview Mappings画面では、左側にQdrantのフィールド、右側にZilliz Cloudのフィールドが表示されます。
ここは、名前だけを確認して通過するのではなく、アプリケーションが期待するデータ型になっているかを見る工程です。
主キーとベクトル
今回の例では、idはVARCHARの主キー、dense_vectorは384次元のFLOAT_VECTORとして表示されています。
元のIDを引き続き使う場合は、Auto IDの設定に注意してください。公式ガイドでは、Auto IDを有効にすると元のIDは破棄されると説明されています。また、Sparse Vectorはサンプルデータ内で空の場合にマッピングされないため、利用している場合は検出結果を確認します。Qdrantの型マッピング
アプリケーション側で数値IDを扱っているなら、移行後の文字列IDとの対応を確認しましょう。外部データベースとの結合や、IDを指定した更新・削除で影響が出る可能性があります。
Payloadを固定フィールドにする
デモでは、Payloadの一部を固定フィールドとして扱う設定にしています。移行先で確認できる型は次のとおりです。
| フィールド | 型 | 想定する用途 |
|---|---|---|
section_title |
VARCHAR |
セクション名の表示 |
year |
INT64 |
年による絞り込み |
text |
VARCHAR |
検索結果の本文、RAGの参照テキスト |
source_url |
VARCHAR |
出典リンク |
「常に同じ型で検索・表示したい項目」を固定フィールドにし、それ以外を動的フィールドとして扱うと、移行後のデータ構造を整理しやすくなります。
ただし、型の自動検出は全件検査ではありません。公式ガイドでは100行をサンプリングするとされています。出現頻度の低いキーや、レコードによって型が異なる項目は別途確認してください。配列は自動検出・変換に制約があるため、必要に応じて手動でフィールドを追加します。Payload変換の注意事項
たとえばyearに整数の2025と文字列の"2025"が混在しているなら、移行前に揃えるか、受け側の型を見直します。値の欠落についても、Nullableやデフォルト値の設定と合わせて確認しておきましょう。
Advanced Settingsを確認して実行する
デモでは、Advanced SettingsにFunction、Shard、Timezoneなどが表示されています。今回のように既存のDense Vectorを移す検証では、まず元のデータと検索条件を再現することを優先します。全文検索などの追加機能は、移行結果を確認してから段階的に検証すると、問題の原因を切り分けやすくなります。
コレクション名、主キー、フィールド、次元数を確認したら、Migrateを押してジョブを開始します。
4. Jobsで進捗を確認する
実行後はJobsで該当の移行ジョブを確認します。デモでは、処理中のジョブにIn Progressが表示されています。
コレクションが移行先に見えても、その時点でコピーが完了したとは限りません。対象ジョブの完了状態を確認してから、件数とデータの検証に進みます。エラーがあれば、ジョブの詳細で失敗した処理を確認します。移行の監視と検証
本番移行では、移行前の件数や対象範囲を記録しておくと、検証時に比較できます。更新を止めずに移した場合は、「どの時点の件数と比較しているか」も揃える必要があります。
5. ベクトルインデックスを作成する
移行ジョブが完了しても、検索準備は終わっていません。 外部移行では、インデックスの作成とコレクションのロードを別途行う必要があります。外部移行の制約
デモでも、移行先コレクションのOverviewは最初にUnloadedとなっており、その後にインデックスを作成しています。
- 移行先コレクションを開く。
- Indexes タブで + Index を選ぶ。
- フィールドに
dense_vectorを指定する。 - 距離指標などの設定を確認し、Createで作成する。
- インデックスの作成完了を確認する。
デモの作成後の画面では、dense_vectorに対してAUTOINDEX、距離指標COSINEが表示され、TotalとIndexedはいずれも1,178になっています。
距離指標は、元の検索との比較に関わる設定です。今回のCOSINEを無条件に選ばず、Qdrant側の設定と、移行先での指標の意味を確認してください。
6. コレクションをロードする
インデックスの準備ができたら、コレクションのActionsからロード操作を行います。
デモでは、OverviewのStatusがLoadingからLoadedへ変わっています。ここまで確認して、検索の動作確認に進みます。
ロードは、検索・クエリで利用するデータをメモリに読み込む工程です。詳しい条件や操作はLoad & Releaseの公式ドキュメントを参照してください。
7. API Playgroundで検索を確認する
最後に、コレクションのAPI PlaygroundでSearch Dataを開きます。
デモの検索リクエストでは、データベースとしてqdrant_migration、検索対象フィールドとしてdense_vectorが使われています。実行後にはSuccessとcode: 0、結果データが表示されています。
まずは、このように検索が成功するところまで確認しましょう。そのうえで、本番切り替えの判断には追加の検証が必要です。
「検索できた」と「検索品質が保たれた」を分けて確認する
次の検証は、デモの操作に加えて行うことをおすすめします。
| 検証 | 確認方法 |
|---|---|
| データ件数 | 同じ時点・範囲のQdrant側の件数と比較する |
| IDとPayload | 複数の既知IDを選び、本文・年・URLなどを突き合わせる |
| ベクトル | 次元数と、サンプルのベクトル値を照合する |
| 検索品質 | 同じクエリベクトル、Top K、フィルタで比較する |
| 境界ケース | 欠損値、長い文字列、配列、まれなPayloadキーを確認する |
比較には、実際の問い合わせや正解文書が分かっているクエリを使います。疎通確認用のランダムベクトルだけでは、RAGで必要な文書が取得できるかは判断できません。
また、検索結果の順位やスコアが完全一致することだけを合格条件にせず、必要な文書が取得できるか、業務上の品質基準を満たすかを評価しましょう。スコアのしきい値を使っているアプリケーションでは、その基準も再検証します。
アプリケーションを切り替える前に
ここまでで、データの移行と検索の疎通確認ができます。実際のサービスで使うには、アプリケーション側の接続と検索処理も変更します。
Qdrantクライアントの接続URLだけを変更して完了する前提にはせず、次の対応を確認してください。
- Zilliz Cloudに対応するSDKまたはREST APIで接続する。
- データベース名、コレクション名、ベクトルフィールド名を指定し直す。
- Payloadのフィルタ条件を移行先の書式で表現する。
- 返却データから本文、ID、出典URLを取り出す処理を確認する。
- 追加・更新・削除も移行先に対して動作することを確認する。
本番では、たとえば「書き込み停止 → 移行 → 件数・検索検証 → 接続先切り替え → 書き込み再開」のように、切り替えの順序を明確にします。継続的に更新する構成なら、その間の差分をどこで記録し、どう反映するかまで手順に含めます。
切り戻しを想定する場合も、接続先を戻すだけでは十分とは限りません。切り替え後にZilliz Cloudへ書き込んだデータを、元の環境へどう反映するかを決めておきましょう。
つまずきやすいポイント
| 状況 | 最初に確認すること |
|---|---|
| Qdrantへ接続できない | エンドポイント、APIキー、ネットワーク到達性、IP許可設定 |
| 移行先で名前が衝突する | 別のコレクション名または検証用データベースを使う |
| 一部のPayloadが想定どおりにならない | サンプルに現れないキー、型の混在、配列、欠損値 |
| 移行後に検索できない | インデックスの作成状況とLoaded状態 |
| 検索結果が期待と異なる | 埋め込みモデル、次元数、距離指標、フィルタ、Top K |
| 既存IDによる更新・削除ができない | IDの文字列化とAuto IDの設定 |
おわりに
QdrantからZilliz Cloudへの移行は、コンソールで接続先とフィールドの対応を設定するところから始められます。今回のデモでは、384次元のベクトルとメタデータを持つコレクションについて、移行後のインデックス作成、ロード、API Playgroundでの検索成功までを確認できました。
最初は検証用コレクションで同じ流れを試し、検索品質、性能、運用のしやすさを確かめるのがおすすめです。その結果をもとに、更新データの扱いとアプリケーションの切り替えを計画していきましょう。
参考資料
- Migrate from Qdrant to Zilliz Cloud
- External Migration Basics
- Qdrant vs. Zilliz Cloud
- AUTOINDEX Explained
- Load & Release
- Qdrant: Distributed Deployment
- Qdrant: Overview / Deployments
- 操作手順の参照：提供されたデモ録画
QdrantMigration2Zilliz.mov（非公開資料）