---
title: "Qdrant Cloudの使い方：クラスタ作成・APIキー・Python接続とDockerからの移行【v1.20対応】"
url: "https://www.issoh.co.jp/tech/details/19490/"
published: 2026-11-08
updated: 2026-11-08
categories: ["データベース"]
publisher: "株式会社一創"
---

# Qdrant Cloudの使い方：クラスタ作成・APIキー・Python接続とDockerからの移行【v1.20対応】

Qdrant Cloudは、ベクトル検索エンジンQdrantのクラスタをAWS・GCP・Azure上で開発元が運用するマネージドサービスです。APIとクライアントはオープンソース版と共通で、変わるのは接続先URLとAPIキーだけです。この記事では2026年11月8日時点のQdrant v1.20.0とqdrant-client 1.20.0を前提に、階層の違い、クラスタ作成、APIキーとPython接続、容量見積もり、バックアップと版更新、Docker版からの移行までを公式ドキュメントに沿って進めます。

## まとめ：Qdrant CloudはFreeで接続を確かめ本番はStandard3ノードで作る

最初の検証はクレジットカード不要のFreeクラスタで足ります。ただしFreeは1ノード・RAM 1GBで、使わないまま1週間で停止、さらに4週間で削除されます。

本番はStandard以上で3ノード以上、High Availabilityを有効にして作成します。High AvailabilityとMulti AZは作成時にしか選べないため、後から足せない設定を最初に決めるのが要点です。APIキーは用途ごとに分けて期限を付け、検索だけのアプリには読み取り専用キーを渡します。Docker版で育てたコレクションは公式の移行ツールでそのまま持ち込めます。

## Qdrant Cloudの提供形態とFree・Standard・Premiumの選択基準

クラスタを作る前に、どの形態とどの階層を選ぶかを決めます。ベクトルDB全般の仕組みは[ベクトルDBとは？仕組み・インデックス構造・製品比較](https://www.issoh.co.jp/tech/details/7691/)で扱っているので、ここではQdrant Cloud固有の選択肢に絞ります。

### Managed・Hybrid・Private Cloudの3形態とデータの置き場所の違い

[公式のAbout Qdrant Managed Cloud](https://qdrant.tech/documentation/cloud/)は、提供形態を3つに分けています。Managed CloudはQdrant社のインフラ上でQdrant社が運用する形態です。Hybrid Cloudは利用者のKubernetes上でクラスタが動き、Qdrant CloudがOperator経由で運用を担います。Private Cloudは利用者のKubernetes上で利用者自身が運用し、Qdrant Cloudとは接続しません。

この記事が扱うのはManaged Cloudです。社内規程で「データは自社のAWSアカウントの外に置かない」と決まっている場合は、Managed Cloudではなく、データを自社クラスタに残せるHybrid Cloudを検討の土台にします。

### Freeクラスタの1GB RAM・4GBディスクと1週間で停止する制限

[公式のCreate a clusterページ](https://qdrant.tech/documentation/cloud/create-cluster/)によると、Freeクラスタは1ノードで、RAM 1GB・vCPU 0.5・ディスク4GBです。選べるプロバイダとリージョンは限られ、版の更新はダウンタイムを伴います。スナップショットの取得と復元はAPIからの手動操作に限られ、定期バックアップは使えません。

見落としやすいのは停止と削除の規則です。1週間使われないと停止し、停止したまま4週間たつと削除されます。検証の合間に1か月空けばデータは残りません。評価用のデータは再投入できる形で手元に持っておきます。

### Standard・PremiumのSLAとサポート時間で決まる本番適性

[公式の料金ページ](https://qdrant.tech/pricing/)では、Standardは従量課金、Premiumは最低利用額のある契約です。両者の差は稼働率の保証と障害時の対応時間に出ます。

| 階層       | 稼働率の保証                 | サポート              | 重大障害の初回応答  |
| -------- | ---------------------- | ----------------- | ---------- |
| Free     | なし                     | コミュニティ（ベストエフォート）  | なし         |
| Standard | 99.5%                  | メール・チケット（平日の営業時間） | 4時間（営業時間内） |
| Premium  | 99.9%（Multi AZは99.95%） | 24時間365日          | 1時間        |

夜間の停止を翌営業日に直せばよい社内検索ならStandardで足ります。顧客が24時間使う検索基盤や、Multi AZ・プライベート接続・顧客管理キーでの暗号化が要件ならPremiumです。この3つはPremium限定の機能です。

## コンソールとqcloud CLIでQdrant Cloudのクラスタを作成する手順

検証はコンソール、同じ構成を繰り返し作る場面はCLIかTerraform、という分け方が実務的です。

### Cloud Consoleでプロバイダ・リージョン・ノード構成を選ぶ流れ

Standardクラスタを作る前に、請求情報の登録が必要です。登録後の流れは次のとおりです。

1. Cloud ConsoleのClustersを開き、Createを選ぶ
2. FreeかStandardを選ぶ（ほとんどのオプションはStandard専用）
3. プロバイダとリージョン、またはHybrid Cloudの環境を選ぶ
4. ノードあたりのRAM・vCPU・ノード数を選ぶ（全ノードは同じサイズ）
5. 3ノード以上ならHigh Availabilityにチェックを入れる
6. 構成と料金を確かめてCreateを押す

手順5を飛ばすと、各シャードのレプリカが1つだけのクラスタになり、公式は可用性の保証を受けられないと明記しています。AWSを選んだ場合だけ、RAMの大きい構成でインデックス作成用のGPUを付けられ、ディスクは32GiB以上でBalanced、256GiB以上でPerformanceという速度帯の区分です。マーケットプレイス経由で支払う契約では、有料クラスタはそのプロバイダのリージョンに限られます。

### AWSのリージョン一覧をqcloud CLIで確かめてから作る方法

公式ドキュメントには選べるリージョンの一覧が載っていません。東京など特定のリージョンが要件なら、[公式のQdrant Cloud CLI](https://qdrant.tech/documentation/cloud-cli/)で一覧を取ってから作成します。[qcloud-cliのリポジトリ](https://github.com/qdrant/qcloud-cli)は2026年11月5日にv0.35.0を公開しており、READMEは開発初期でコマンドの書式が版ごとに変わりうるとしているため、スクリプトに組み込むなら版を固定します。

```
# 導入（macOS・Linux）と版の確認
brew install qdrant/tap/qcloud
qcloud version

# Cloud Management Keyとアカウントを登録する
qcloud context set my-cloud --api-key <CLOUD_MANAGEMENT_KEY> --account-id <ACCOUNT_ID>
qcloud context use my-cloud

# AWSで選べるリージョンを一覧する
qcloud cloud-region list --cloud-provider aws

# 一覧にあったリージョンを指定して作成し、稼働するまで待つ
qcloud cluster create \
  --cloud-provider aws \
  --cloud-region <一覧で確認したリージョン> \
  --cpu 2000m --ram 8GiB --disk 50GiB \
  --name rag-dev --wait

# 状態の確認と、読み取り専用で期限付きのAPIキーの発行
qcloud cluster describe <CLUSTER_ID>
qcloud cluster key create <CLUSTER_ID> --name app-read \
  --access-type read-only --expires 2027-06-30
```

CPU・RAM・ディスクを指定すると、合うパッケージが自動で選ばれます。CLIの認証に使うCloud Management Keyは、クラスタへの検索や書き込みには使えません。環境ごとに同じ構成を作り直すなら、[公式のTerraformプロバイダ](https://qdrant.tech/documentation/cloud-tools/terraform/)`qdrant/qdrant-cloud`でも定義できます。出力のAPIキーはstateに残るため、[TerraformでAWSを構築する手順](https://www.issoh.co.jp/tech/details/1900/)と同じく暗号化したリモートバックエンドに置きます。

## Database APIキー発行とPython・curlでQdrant Cloudへ接続

クラスタができたら、アプリ用のキーを発行して接続します。Qdrant Cloudには役割の違う認証情報が3種類あり、ここを取り違えると401で止まります。

### 権限・有効期限・コレクション制限を付けたAPIキーの発行方法

[公式のAuthenticationページ](https://qdrant.tech/documentation/cloud/authentication/)によると、クラスタのREST・gRPC APIに使うのはDatabase APIキーです。CLIやTerraformに使うCloud Management Key、コンソールへのサインインとは独立しており、片方でもう片方の権限は得られません。

Database APIキーはクラスタ詳細のAPI Keysで作ります。有効期限の既定は90日、空欄なら無期限です。権限は既定でクラスタ全体の書き込みですが、読み取り専用やコレクション単位の制限にできます。キーは作成直後に一度しか表示されず、有効化に数秒かかるため、最初の要求が403でも再試行で通ることがあります。

見落としやすいのは、ユーザーを削除してもそのユーザーが作ったキーは失効しない点です。退職や異動の手順に、キーの失効を先に入れておきます。発行したキーでClaude CodeからMCP経由でクラスタにつなぐ場合の設定は[Qdrant MCPの使い方：mcp-server-qdrantをClaude Codeにつなぐ設定と記憶ストア化](https://www.issoh.co.jp/tech/details/19491/)で扱っています。

### qdrant-client 1.20系でクラスタURLとAPIキーを渡して検索するコード

PyPIの[qdrant-client](https://pypi.org/project/qdrant-client/)は2026年10月22日公開の1.20.0が最新で、Python 3.10以上が必要です。[公式のCloud Quickstart](https://qdrant.tech/documentation/cloud-quickstart/)と同じく、`cloud_inference=True`を付けると、テキストを渡すだけでクラスタ側が埋め込みを作ります。

```
# pip install "qdrant-client==1.20.0"
import os

from qdrant_client import QdrantClient, models

client = QdrantClient(
    url=os.environ["QDRANT_URL"],          # 例: https://<cluster-id>.<region>.aws.cloud.qdrant.io
    api_key=os.environ["QDRANT_API_KEY"],  # Database APIキー（Cloud Management Keyではない）
    cloud_inference=True,                  # 埋め込みをクラスタ側で生成する
)
MODEL = "sentence-transformers/all-MiniLM-L6-v2"  # 出力は384次元
COL = "faq"

if not client.collection_exists(COL):
    client.create_collection(
        collection_name=COL,
        vectors_config=models.VectorParams(size=384, distance=models.Distance.COSINE),
    )

docs = ["経費精算は月末締めで翌月10日に支払う", "有給休暇の申請は3営業日前までに出す"]
client.upsert(
    collection_name=COL,
    points=[
        models.PointStruct(id=i, vector=models.Document(text=t, model=MODEL), payload={"text": t})
        for i, t in enumerate(docs)
    ],
)

res = client.query_points(
    collection_name=COL,
    query=models.Document(text="休みの申請はいつまで？", model=MODEL),
    with_payload=True,
    limit=3,
)
for p in res.points:
    print(round(p.score, 3), p.payload["text"])
```

自前で作った埋め込みを入れる場合は、`cloud_inference`を外し、`vector`に数値の配列を渡します。作り方は[Pythonでembeddingを生成する方法](https://www.issoh.co.jp/tech/details/4081/)を参照してください。Cloud Inferenceで使えるモデルはクラスタ詳細のInferenceタブで確かめられ、有料モデルの推論トークンは課金の対象です。

### 401・403・タイムアウトが返るときの原因を切り分ける順番

[公式のConnectページ](https://qdrant.tech/documentation/cloud/cluster-access/)によると、エンドポイントは`<cluster-id>.<region>.<provider>.cloud.qdrant.io`の形式で、RESTは443か6333、gRPCはTLS付きの6334で受けます。TLSは常に必須です。疎通しないときは次の順で見ます。

- 401：送ったキーがDatabase APIキーか。Cloud Management Keyを渡していないか
- 403：キーの期限切れ、読み取り専用キーでの書き込み、許可外のコレクションへの操作。作成直後なら数秒待って再試行
- タイムアウト・接続拒否：プロトコルとポートの組み合わせ、Client IP Restrictionsの許可範囲に送信元が入っているか
- gRPCだけ失敗：TLSを有効にしているか、ポートが6334か

curlなら`curl https://<エンドポイント>:6333 -H "api-key: $QDRANT_API_KEY"`で、認証が通ればクラスタの版を含むJSONが返ります。

### Client IP Restrictionsとプライベート接続で通信経路を絞る設定

既定では、有効なキーを持つクライアントはどのネットワークからでも接続できます。クラスタ詳細のClient IP Restrictionsに許可するIP範囲を入れると、そこからの接続だけを受け付けます。本番では、アプリが動くNATゲートウェイの固定IPなどを登録しておく設定が基本です。

公衆インターネットを通さない接続に対応するのはPremiumだけです。IP制限で要件を満たせるならStandardのまま進め、経路の閉域化が監査で求められる場合にPremiumを選びます。AWS側の閉域接続の仕組みは[AWS PrivateLinkとは：仕組み・VPCエンドポイントとの違い](https://www.issoh.co.jp/tech/details/15473/)で整理しています。

## Qdrant Cloudの容量見積もりとノード数で課金額の増え方を読む

課金は、vCPU・メモリ・ディスク・バックアップ容量・有料モデルの推論トークンを時間単位で計る従量制です。料金ページに単価の一覧は無く、必要なメモリ量を見積もってから計算ツールに入れます。

### ベクトル数×次元×レプリカ数で必要メモリを見積もる容量計算式

Create a clusterページは、密ベクトルの容量を「点数×レプリカ数×次元数×1次元あたりのバイト数」で見積もるよう示しています。1次元あたりはfloat32で4バイト、float16で2、uint8で1です。そこにHNSWインデックス分の20〜30%と、WALやスナップショット用の余裕20%を足します。

```
# 100万チャンク・768次元・float32・レプリカ2の見積もり
points, dims, bytes_per_dim, replicas = 1_000_000, 768, 4, 2

dense_gb = points * replicas * dims * bytes_per_dim / 1024**3
total_gb = dense_gb * 1.3 * 1.2           # HNSW分30%と余裕20%を上限側で加算
node_ram_gb = 8
nodes = max(3, -(-total_gb // (node_ram_gb * 0.8)))  # RAM使用率80%未満・本番は3ノード以上

print(f"ベクトル本体 {dense_gb:.1f}GB / 見積もり {total_gb:.1f}GB / ノード数 {int(nodes)}")
# ベクトル本体 5.7GB / 見積もり 8.9GB / ノード数 3
```

ベクトル本体の5.7GBは公式の例と一致します。ペイロードとその索引は式に入らないため、本文テキストをペイロードに持たせるなら別に上乗せします。

### RAM使用率80%とシャード数12の設計ルールで決めるノード構成

同じページの設計ルールは、ノードのRAM使用率を80%未満に保つことです。超えるとOSがキャッシュを追い出し、応答時間が急に伸びます。1ノードで扱える目安は約1億ベクトルで、高次元のfloat32ではそれより少なくなります。

シャード数はノードあたり2以上とし、迷ったら12にします。12は1・2・3・4・6・12ノードのどれでも割り切れるため、後からノードを増やしても偏りません。逆に2シャードのまま1ノードから3ノードへ増やすと、3台目にはシャードが載らず遊んでしまいます。シャード数はコレクション作成時に決まり、変えるにはv1.13.0以降のリシャーディングが要ります。

### 量子化とcoldティアでメモリ課金を抑える判断基準と採用を見送る場面

量子化はベクトルのメモリを4〜32分の1に減らします。coldティアはRAMに先読みせずメモリマップドファイルから読む方式で、代わりにディスクを多めに付けます。

数百万件を超えて月額がメモリで膨らむ段階なら、まず量子化を試します。一方、問い合わせ対応のように応答時間に上限がある検索でcoldティアを使うのは見送ります。ディスク読みが入る分、遅い問い合わせが混ざるからです。製品をまたいだ料金体系の比較は[ベクトルデータベースの価格とおすすめ](https://www.issoh.co.jp/column/details/16480/)にまとめています。

## Qdrant Cloudのバックアップ・スケーリング・版更新で止まる操作と止まらない操作

マネージドでも、操作によってはクラスタが止まります。再起動や巻き戻しを伴う操作を先に把握しておきます。

### 定期バックアップの保持日数と同じクラスタへの復元で失うデータ

[公式のBackupsページ](https://qdrant.tech/documentation/cloud/backups/)によると、定期バックアップは画面から日次・週次・月次で、CLI・API・TerraformからはUTCのcron式で設定します。保持はCLIで1〜365日、APIで省略すると無期限です。AWSとGCPのバックアップは2回目以降が差分方式です。

復元には2つの道があります。同じクラスタへ戻すと、復元中はクラスタが使えず、バックアップ後に書いたデータは消え、CPU・メモリ・ノード数・Qdrantの版までバックアップ時点に戻ります。新しいクラスタへ復元すれば元のクラスタは無傷です。障害対応では、まず`qcloud cluster create-from-backup`で別クラスタに戻して確かめ、接続先を切り替えます。

### 垂直スケーリングで再起動が起きる条件とディスクだけを増設する場合

[公式のScalingページ](https://qdrant.tech/documentation/cloud/cluster-scaling/)によると、CPUかメモリを変えると、増やす場合も減らす場合も各ノードが再起動します。コレクションがレプリケートされていなければ短い停止が起きます。ディスクだけの増設では再起動しません。

危ないのはメモリの縮小です。コンソールとqcloudはピーク使用量を下回る縮小に警告を出すだけで、API・Terraform・Pulumiは警告なしで適用します。データが収まらなければ増やし直すまで使えないため、縮小の前にメモリ使用量を確かめます。

### 最新と直前3マイナーのサポート範囲とSDKを後から上げる更新順

[公式のUpdatesページ](https://qdrant.tech/documentation/cloud/cluster-upgrades/)によると、サポート対象は最新版と直前の3つのマイナー版です。2026年11月時点の最新は[v1.20.0](https://github.com/qdrant/qdrant/releases/tag/v1.20.0)なので、1.17系より古いとサポート要求がSLAの対象外になります。レプリカ2以上の複数ノードは無停止のローリング更新、単一ノードやレプリカ1のコレクションがある場合は短い停止を伴います。

更新の順番は、バックアップを取る、クラスタを上げる、最後にSDKを上げる、です。複数のマイナー版を飛ばすと中間の版への更新が自動で挟まるので、SDKはそれが終わってから上げます。

## Docker版からQdrant Cloudへ移す手順とセルフホストとの選び分け

手元のDockerで検証したコレクションは、作り直さずにCloudへ移せます。Docker版の構築手順は[Qdrant Dockerの構築手順：docker run・Compose・永続化・APIキー](https://www.issoh.co.jp/tech/details/19488/)で解説しています。

### qdrant-migrationでDocker版のコレクションをCloudへ移すコマンド

[公式のMigrate Between Qdrant Instances](https://qdrant.tech/documentation/migrate-to-qdrant/from-qdrant/)は、移行用コンテナの`qdrant`サブコマンドを案内しています。移行はgRPCで行うため、移行元・移行先ともURLのポートは6334です。

```
# 移行元＝手元のDocker（6334を公開しておく）、移行先＝Qdrant Cloud
docker run --net=host --rm -it registry.cloud.qdrant.io/library/qdrant-migration qdrant \
  --source.url 'http://localhost:6334' \
  --source.api-key "$LOCAL_QDRANT_API_KEY" \
  --source.collection 'docs' \
  --target.url 'https://<cluster-id>.<region>.aws.cloud.qdrant.io:6334' \
  --target.api-key "$QDRANT_API_KEY" \
  --target.collection 'docs' \
  --migration.num-workers 4
```

移行先にコレクションが無ければ、移行元のベクトル設定・HNSW設定・量子化・シャーディングを引き継いで自動で作られます。シャード数を12に変えたいなど設定を変える場合は、先に移行先でコレクションを作っておく手順です。移行中の移行先は、移行元コレクションの2倍のRAMとディスクを要します。大きめの構成で受けて、終わってから縮めます。

### Docker自前運用を続ける条件とQdrant Cloudへ移すべき場面

Dockerの単一ノードで続けてよいのは、社内向けで数時間止まっても業務が回り、1台に収まる規模で、日次のスナップショットから戻せば済む場合です。PoC段階のRAGや社内規程の検索がこれに当たります。

顧客向けの検索のように止まると損失が出る用途では、Docker単体の運用は採用しません。3ノードのレプリケーション、ローリング更新、定期バックアップは、Standardなら作成時の設定で揃いますが、Dockerでは自前で組んで保守し続けるのが前提です。責任範囲の分け方は[マネージドサービスとは？フルマネージド・アンマネージドの違いと責任範囲](https://www.issoh.co.jp/tech/details/13442/)で整理しています。データを社外に置けない場合はHybrid Cloudを選びます。

### RAG基盤をQdrant Cloudで組むときに外部へ任せる作業と社内判断

Qdrant Cloudはクラスタの運用を引き受けますが、検索の質までは引き受けません。文書の分割単位、埋め込みモデルの選定と入れ替え時の再投入、権限に応じたペイロードでの絞り込み、回答精度の評価は、どのベクトルDBを選んでも利用者側に残ります。

社内に持つべきなのは、どの文書を誰に見せるかという権限の定義と、正しい回答を判定する評価データです。クラスタ設計・取り込みバッチ・精度改善の繰り返しは外部に任せても判断は失われません。Qdrant Cloudを使った社内文書検索やチャットボットの構築は、[RAG構築支援](https://www.issoh.co.jp/service/ai/rag/)で要件の整理から相談できます。全体の進め方は[RAG構築の手順とは？データ整備から本番運用まで](https://www.issoh.co.jp/column/details/12920/)も参考になります。

## よくある質問

Qdrant Cloudの導入でよく出る質問に答えます。

### Qdrant Cloudは無料でどこまで使えますか？

Freeクラスタは期限なしで使え、1ノード・RAM 1GB・vCPU 0.5・ディスク4GBの構成です。クレジットカードは不要で、選んだモデルのCloud Inferenceも無料で試せる範囲です。SLAと定期バックアップは無く、1週間使わないと停止し、停止から4週間で削除されます。接続とAPIの確認には十分で、容量が足りなくなればStandardへ上げられます。

### Qdrant Cloudで東京リージョンは選べますか？

2026年11月8日時点で、公式ドキュメントにはリージョンの一覧が掲載されていません。作成画面の一覧を見るか、`qcloud cloud-region list --cloud-provider aws`で確かめるのが確実です。Freeは選べるリージョンが限られます。希望のリージョンが無く、保存場所に規程上の制約がある場合は、自社のKubernetesで動かすHybrid Cloudが代わりの選択肢です。

### Qdrant CloudのAPIキーをなくしたらどうすればよいですか？

再表示する方法はありません。同じ権限で新しいキーを作り、アプリに配備してから古いキーを失効させます。公式が期限前の入れ替えでも推奨しているのは、この作成・配備・失効の順序です。アプリや環境ごとにキーを1本ずつ割り当てておけば、失効させたときに止まる範囲が小さく済みます。

### Cloud Inferenceを使えば埋め込みモデルを別に用意しなくてよいですか？

用意しなくても動きます。`cloud_inference=True`で接続し、テキストとモデル名を渡せばクラスタ側で埋め込みを作ります。Quickstartの例は384次元の`all-MiniLM-L6-v2`です。日本語の社内文書で精度を出したい場合は、Inferenceタブで日本語に強いモデルがあるかを確かめ、無ければ自前の埋め込みを渡す構成にします。

### Qdrant CloudとPinecone・Weaviate Cloudはどう選び分けますか？

Dockerで検証したコードをそのまま本番へ持ち込むなら、OSS版と同じAPIのQdrant Cloudが素直です。サーバーの構成を意識せず使いたい場合は[Pineconeとは？サーバーレス型ベクトルDBの料金と選び分け](https://www.issoh.co.jp/tech/details/15926/)、スキーマやモジュールで検索を組みたい場合は[Weaviate Cloudとは？クラスタ種別・接続とロール設計](https://www.issoh.co.jp/tech/details/16458/)と比べてください。どれもPoCの評価データで検索精度と月額を並べてから決めます。

## 関連記事

- [Qdrant Dockerの構築手順：docker run・Compose・永続化・APIキーとPythonで検索するまで【v1.20対応】](https://www.issoh.co.jp/tech/details/19488/)：Qdrantをセルフホストで立てる場合の手順
- [Weaviate Cloudとは？クラスタ種別・接続とロール設計・運用の勘所を実装者目線で解説【2026年8月版】](https://www.issoh.co.jp/tech/details/16458/)：別製品のマネージド版との比較材料
- [ベクトルDBとは？仕組み・インデックス構造・製品比較とpgvectorで動かす手順【2026年版】](https://www.issoh.co.jp/tech/details/7691/)：ベクトルDBの仕組みと製品の違い
- [ベクトルデータベースの価格とおすすめ｜3タイプの料金体系比較とRAG用途の選び方【2026年版】](https://www.issoh.co.jp/column/details/16480/)：マネージド型と自前運用の費用比較
- [RAG構築の手順とは？データ整備から精度向上・本番運用までの進め方](https://www.issoh.co.jp/column/details/12920/)：検索基盤を作った後のRAG全体の進め方

---

出典: [Qdrant Cloudの使い方：クラスタ作成・APIキー・Python接続とDockerからの移行【v1.20対応】](<https://www.issoh.co.jp/tech/details/19490/>)（株式会社一創）