Weaviate Cloudとは？クラスタ種別・接続とロール設計・運用の勘所を実装者目線で解説【2026年8月版】

Weaviate Cloudは、OSSのベクトルデータベースであるWeaviate Databaseを開発元がそのままマネージドで提供する環境です。自社でKubernetesやDockerを組まずにクラスタを立て、RESTとgRPCのエンドポイントとAPIキーだけでアプリケーションからつなげます。

ただし「マネージドだから楽」で話は終わりません。クラスタ種別によって生存条件もSLAも変わり、インデックス構造は作成時の選択で決まり、版は自動更新されるためピン留めできない前提で設計する必要があります。この記事は、RAG基盤の受託開発でWeaviate Cloudを採用するときに実際につまずく箇所を、公式ドキュメントの数値とあわせて順に整理したものです。製品としてのWeaviate本体の仕組みや料金の逆算はWeaviateとは？ハイブリッド検索・マルチテナンシー・料金と選定基準で扱っているため、本記事はマネージド環境の構築と運用に範囲を絞ります。

まとめ：Weaviate Cloudを選ぶ3条件と自社ホストへ戻す判断

先に結論を置きます。Weaviate Cloudが有利になるのは次の3条件がそろう場面です。第一に、ベクトルメモリの増減を見張る運用人員を専任で置けないこと。第二に、Weaviate EmbeddingsやQuery Agentといったクラウド専用機能を設計に組み込みたいこと。第三に、稼働率SLAを契約上の要件として書く必要があることです。

逆に、データの所在地や閉域接続が要件で決まっている案件、既存のKubernetes基盤にワークロードを寄せたほうが総額が下がる案件、数十万件規模でpgvectorに収まる案件では自社ホストが有利になります。判断を分ける実務上の分岐点は、月額単価そのものではなく「バージョンを自分で決めたいか」と「ネットワーク境界を自分で引きたいか」の2点です。

Weaviate Cloudが引き受ける範囲と3つのクラスタ種別

Weaviate Cloudが引き受けるのは、Weaviate Databaseの構築・スケール・バックアップ・バージョン更新までの層です。コレクション定義やベクトル化の設計、検索クエリの組み立ては従来どおり実装側の仕事として残ります。つまり「サーバー管理が消える」だけで、検索設計の難度は下がりません。

Free・Shared Cloud・Dedicated Cloudの3種別と分離度の差

2026年8月時点のドキュメントでは、クラスタはFree・Shared Cloud・Dedicated Cloudの3種別に整理されています。Shared Cloudは共有インフラ上のフルマネージドSaaSで、ベクトルメモリの量に応じて自動でスケールし、5つのクラウドリージョンから選べます。稼働率SLAは99.5〜99.9%です。

Dedicated Cloudは専有インフラにクラスタを分離する構成で、SOC 2とHIPAAへの対応、99.9〜99.95%のSLA、24時間365日のサポートと担当マネージャーが付きます。監査対応を求められる医療・金融系の案件では、この分離度がそのまま採否を決めます。

なお料金ページ側の表記はFree・Flex・Premiumの3プランで、ドキュメントのクラスタ種別とは呼び分けが異なります。契約プランの名前と、クラスタの配置形態の名前が別体系になっていると読み取るのが安全です。

Freeクラスタが7日で停止し30日で消える検証枠の制約と運用上の注意

Freeクラスタは検証用として無料で作れますが、生存条件が明確に決まっています。7日間の無操作で停止状態に入り、その後さらに30日間の無操作で削除対象となる仕様です。1ユーザーにつき1つまでという制限もあります。

この条件は、案件のPoCを止めたまま放置すると環境ごと消えることを意味します。デモ環境をFreeクラスタで維持する運用は避け、投入スクリプトと設定をコードで持っておき、いつでも作り直せる状態にしておくほうが安全でした。インデックスの選択肢もCost Optimizedのみに固定されるため、Performance Optimizedを前提とした性能検証はFree枠では成立しません。

Shared Cloudの既定6クラスタ枠と2つのプロファイル選択

Shared Cloudは組織あたり既定で6クラスタまで作成できます。開発・ステージング・本番でテナントを分ける設計なら枠内に収まりますが、顧客ごとにクラスタを切る設計にすると早い段階で上限に当たります。顧客分離はクラスタ分割ではなく、Weaviate本体のマルチテナンシー機能で受けるのが基本線です。

作成時にはCost OptimizedとPerformance Optimizedのどちらかを選びます。前者はHFresh、後者はHNSWがインデックス構造の土台になり、メモリ費と検索レイテンシのトレードオフがここで決まります。あとから切り替える前提を持たず、想定データ量と応答要件を先に確定させてから作成してください。

Weaviate Cloudのクラスタ作成で決める4項目と構造の分岐

クラスタ作成の画面で決める実質的な項目は4つです。クラウドプロバイダ、リージョン、インデックスのプロファイル、そしてバックアップの保持日数。加えて、月次のAI Services割当（Weaviate EmbeddingsやQuery Agentの利用枠）が種別ごとに付いてきます。

Cost OptimizedとPerformance Optimizedの選び分け基準

Cost Optimizedを選ぶとHFreshが土台になります。HFreshはベクトル本体をディスク上の領域に置き、代表点だけを小さなインデックスとしてメモリに残す構造のため、データが継続的に増えるワークロードでもメモリ費が抑えられました。取り込みが止まらない社内文書検索のような用途と相性が良好です。

Performance Optimizedを選ぶとHNSWがメモリ常駐で動き、検索レイテンシが読みやすくなります。対話UIの裏で毎秒数十件を返すような導線では、こちらを起点に見積もるのが妥当です。インデックス構造そのものの挙動や量子化との組み合わせはWeaviate本体の解説記事で詳しく扱っています。

クラウドプロバイダ・リージョン・バックアップ保持日数の決め方

クラウドプロバイダの既定はGCPです。既存システムがAWS上にあるなら、リージョンの物理距離とネットワーク経路が応答時間に効くため、プロバイダとリージョンの組み合わせを先に決めてから性能検証に入ります。Shared Cloudで選べるリージョンは5つで、日本国内にデータを置く要件があるかどうかは案件初期に確認しておくべき事項です。

バックアップ保持日数はShared Cloudで設定でき、詳細画面にも表示されます。保持日数はバックアップストレージの課金にそのまま乗るため、要件から逆算して短く握るのが実務的でした。監査で世代保持が求められる場合は、日数を延ばすか外部への書き出しを併用するかを設計段階で決めます。

クラスタ詳細画面で確認する項目と監視に使える4つのメトリクス

詳細画面ではクラスタ名、RESTエンドポイント、gRPCエンドポイント、APIキー、ロール、Weaviate Database version、クラウドプロバイダ、リージョン、作成日時、種別が確認できます。Shared Cloudではバックアップ保持日数と稼働率SLAも並びます。障害時の一次切り分けは、まずこの画面のバージョンとリージョンを控えるところから始めるのが速い手順です。

メトリクスとして出るのはクエリレイテンシ、取り込みスループット、平均バッチサイズ、オブジェクト数の4種です。統計側にはDimensions stored、Object count、Cluster expires onが表示されます。Dimensions storedは次元課金の主軸になる値なので、監視ダッシュボードに写して週次で追う運用を推奨します。

平均バッチサイズは見落とされがちですが、投入処理のチューニング指標として役に立ちます。バッチが小さいまま推移していれば、クライアント側のバッチ設定かネットワーク経路のどちらかに詰まりがあると読み替えられました。

API keyとロール設計で決まるWeaviate Cloudの接続権限

Weaviate Cloudへの接続はAPIキーで行います。キーはロールに結び付いており、どのキーを誰に渡すかがそのまま権限設計そのものです。ここを雑に扱うと、検証用のキーが本番クラスタの書き込み権限を持ったまま配布される事故につながります。

adminとviewerの既定ロールとカスタムロールの使い分け

既定ロールとしてadminとviewerが用意されており、必要に応じてカスタムロールも作成できます。基本の設計は単純で、投入バッチとスキーマ変更にはadmin、アプリケーションからの検索専用にはviewerを割り当てます。BIツールや社内ツールから読むだけの経路にadminキーを配るのは避けてください。

カスタムロールは、コレクション単位で権限を切りたいときに効きます。マルチテナント構成で顧客ごとの読み取り経路を分ける場合や、評価パイプラインだけに限定的な書き込みを許す場合が該当します。キーの棚卸しは四半期ごとの定例作業として運用手順に入れておくと安全でした。

Pythonクライアントv4での接続とgRPCの自動導出の挙動

Pythonクライアントv4では、RESTエンドポイントとAPIキーを渡すだけで接続が確立します。gRPCエンドポイントはRESTエンドポイントからクライアント側が導出するため、明示指定は通常不要です。

import weaviate
from weaviate.classes.init import Auth
import os

client = weaviate.connect_to_weaviate_cloud(
    cluster_url=os.environ["WEAVIATE_URL"],
    auth_credentials=Auth.api_key(os.environ["WEAVIATE_API_KEY"]),
)
print(client.is_ready())
client.close()

引数はcluster_url、auth_credentials、additional_config、skip_init_checksが主要なところです。additional_configではタイムアウトを調整でき、skip_init_checksは接続時の初期確認を飛ばす逃げ道になります。接続オブジェクトは使い終えたら明示的に閉じる書き方を徹底してください。

クラスタへ接続できないときに切り分ける3点とタイムアウト設定

接続が通らないときに見る箇所は3つに絞れます。1つ目はRESTエンドポイントの綴りとプロトコル、2つ目はAPIキーに紐づくロールの権限、3つ目はgRPCの到達性です。特に3つ目は、社内プロキシやファイアウォールがgRPCの通信を落としている構成で表面化します。

RESTでの疎通は取れるのにコレクション操作だけが失敗する症状が出たら、まずgRPC経路を疑ってください。切り分けとしてskip_init_checksを一時的に有効にし、どの段階で止まっているかを特定する方法が使えます。恒久対処はネットワーク側の許可であって、初期確認の常時スキップではありません。

タイムアウトはadditional_configで初期化・検索・投入それぞれに設定できます。大きなバッチを投入する処理では既定値のままだと打ち切られる場合があるため、投入系だけ長めに取る調整が現実的でした。

Weaviate Cloud限定で使える埋め込みとエージェントの機能

Weaviate Cloudには、自社ホストでは使えない機能が2つあります。マネージドの埋め込み推論であるWeaviate Embeddingsと、自然言語で検索を組み立てるQuery Agentです。どちらもGA提供で、この2つを設計に組み込むかどうかがマネージドを選ぶ理由そのものになる場合があります。

Weaviate Embeddingsの3モデルと無料クラスタの日次上限

Weaviate EmbeddingsはWeaviate Cloud専用のマネージド埋め込み推論サービスで、データ側とクエリ側のベクトル生成をクラスタ内で完結させます。ドキュメントに挙がっているモデルはsnowflake-arctic-embed-m-v1.5、snowflake-arctic-embed-l-v2.0、そしてマルチモーダル向けのcolmodernvbertの3種です。

無料クラスタのレート制限は1クラスタあたり1日2,000リクエストで、バッチ1回あたり200オブジェクトまで扱えます。単純計算で1日あたり最大40万件の埋め込み生成に相当しました。PoC段階の初期投入なら十分に回りますが、数百万件規模の初回投入を無料枠で終わらせる計画は成り立ちません。

外部の埋め込みAPIを別途契約するか、この機能に寄せるかは、モデル選定の自由度と運用の手数のトレードオフです。日本語の検索精度をモデル比較で詰めたい案件では外部APIを、構成要素を減らして早く立ち上げたい案件ではWeaviate Embeddingsを選ぶ整理になります。

Query Agentのaskとsearchを本番導線へ載せる判断材料

Query AgentもWeaviate Cloud限定の機能で、GA提供です。動作モードは2つあり、askモードは自然言語の質問に対して回答を返し、searchモードは条件で絞り込んだオブジェクトをそのまま返します。PythonとJavaScriptのAgentsクライアントから呼び出せます。

無料枠は月250回のaskまたは1,000回のsearchで、有償プランでは月間の実行枠が別建てで提供されます。検証には足りる一方、本番のユーザー導線に直結させる場合は実行回数の見積もりを先に置いてください。エージェント側でクエリを組み立てる分だけ応答時間は伸びるため、対話UIに載せるならレイテンシの実測が必要になります。

検索工程を自前で組む場合との比較軸は、精度の作り込み余地と再現性です。検索の分解や再ランクを自分で設計したい案件では、RAGの検索工程を扱った記事で整理した手順に沿って組むほうが調整が効きます。

Weaviate Cloudの自動更新と版管理を運用計画へ織り込む方法

自社ホストとの最大の運用差はバージョン管理にあります。Weaviate Cloudは既存クラスタを自動で更新するため、実装側で版をピン留めし続ける選択肢がありません。更新が勝手に進む前提で、壊れる箇所を先に洗い出しておく設計が求められます。

保守対象が最新3マイナーに限られる前提と自動更新への備え方針

Weaviate Databaseの保守対象は最新3マイナーに限られます。2026年8月時点では1.38系（2026-06-05）、1.37系（2026-04-16）、1.36系（2026-02-24）が該当し、リリース間隔はおよそ2か月です。この方針そのものの詳細はWeaviate本体の記事で扱いました。

マネージド側では、この更新サイクルがそのまま自動で適用されます。年に数回はサーバー側の挙動が変わる前提を運用計画に書き、リリースノートの確認を定例業務として組み込んでください。「更新しない」という選択肢を持てない点が、自社ホストとの設計上の最大の違いになります。

クライアントとサーバーの版差で壊れる箇所を先に洗い出す検証手順

実際に壊れやすいのはクライアントライブラリとサーバーの版差です。非推奨になった呼び出し、モジュール設定の書式変更、量子化やインデックスに関する設定名の変更あたりが典型でした。アプリケーション側のクライアントを固定したまま数か月放置すると、サーバー更新後に警告や失敗が出ます。

備えとしては、CIでクライアント最新版を使った結合テストを定期実行し、投入・検索・削除の基本経路を毎週なぞる構成が実用的です。テスト用のクラスタは本番と同じ種別で用意し、種別差による挙動の違いを持ち込まないようにします。検証結果を残しておけば、障害時に「更新起因か実装起因か」の切り分けが数分で済みました。

セルフホストからWeaviate Cloudへ移すときの判断と手順

すでにDockerやKubernetesでWeaviateを動かしている環境から、マネージドへ寄せるべきかを問われる場面は多くあります。判断は感覚ではなく、運用工数・機能要件・契約要件の3軸で切ると迷いません。

マネージドへ寄せる価値が出る3条件と受託案件での実務判断の勘所

移行の価値が出るのは次の3条件です。第一に、ベクトルメモリの増加に応じたノード増設を判断できる担当者が常時いないこと。第二に、Weaviate EmbeddingsやQuery Agentを設計へ組み込む方針が固まっていること。第三に、稼働率を契約書に記載する必要があることです。

受託案件では、納品後の運用を発注者側が引き取る構図が一般的です。引き取り先に基盤運用の担当を置けないなら、初期費用が多少上がってもマネージドに寄せたほうが1年目以降の総額は下がります。データ投入パイプラインとコレクション定義をコードで管理しておけば、環境の作り直しは短時間で済みました。当社では、こうした環境選定から投入設計・評価までを含めてRAG構築支援として請け負っています。

データ所在と閉域要件でWeaviate Cloudを見送る具体的な場面

見送りの判断も明確に置きます。データを国内かつ自社管理のネットワーク内に閉じる要件がある案件、VPC内での閉域接続を前提に監査を通す案件では、マネージドの共有インフラは条件を満たしません。Dedicated Cloudで分離度を上げる選択肢はありますが、その時点で費用は跳ね上がります。

件数が数十万件に収まり、既存のPostgreSQLで検索も完結する規模なら、そもそもベクトルデータベースを別立てにしない構成が有利です。サーバーレス型のマネージドと比べたい場合はPineconeの料金と制限値をまとめた記事と並べて評価してください。判断の順序は「自社ホストで足りるか」「マネージドが必要か」「どのマネージドか」の3段階が実務的です。

よくある質問

Weaviate Cloudは無料で使い続けられますか？

Freeクラスタの作成自体は無料ですが、7日間の無操作で停止し、その後30日間の無操作で削除されます。利用できるのは1ユーザーにつき1つまでで、インデックスの選択肢もCost Optimizedに固定という条件です。継続利用というより、検証枠として扱うのが実態に合っています。

Weaviate Cloudと自社ホストの違いはどこに出ますか？

差が出るのは3点です。バージョンを自分で決められるかどうか、ネットワーク境界を自分で引けるかどうか、そしてWeaviate EmbeddingsとQuery Agentを使えるかどうか。検索機能そのものの設計方法は共通なので、移行してもコレクション定義やクエリの書き方は流用できます。

リージョンやクラウドプロバイダは選べますか？

選べます。プロバイダの既定はGCPで、Shared Cloudでは5つのリージョンから選択できます。既存システムの配置と物理距離が応答時間に効くため、性能検証の前に組み合わせを確定させてください。データ所在の要件がある案件では、この選択が採否そのものを決めます。

料金はどのように決まりますか？

課金はベクトル次元数、オブジェクトストレージ、バックアップストレージの3軸で決まります。2026年8月時点の料金ページではFreeが0ドル、Flexが月45ドルから、Premiumが月400ドルからと記載されています。実データ量からの月額逆算はWeaviate本体の記事で計算手順を示しました。

Query Agentは自社ホストのWeaviateでも使えますか？

使えません。Query AgentとWeaviate EmbeddingsはいずれもWeaviate Cloud限定の機能です。自社ホストで同等の体験を作るなら、検索工程と埋め込み生成を自前で組む前提になります。この機能を設計に織り込むかどうかは、マネージドを選ぶ理由として先に確定させておくべき論点です。

関連記事

• Weaviateとは？ハイブリッド検索・マルチテナンシー・料金と選定基準【2026年版】 … Weaviate本体のインデックス構造・量子化・日本語検索・プラン料金の逆算を扱っています
• Pineconeとは？サーバーレス型ベクトルDBの料金・制限値・実装と選び分け【2026年版】 … マネージド型ベクトルDBの比較検討で並べる候補として整理しています
• リトリーバルとは？RAGの検索工程の仕組みと実装・精度改善の判断基準【2026年版】 … Query Agentに任せず検索工程を自前で組む場合の設計手順を解説しています
• ベクトルデータベースとグラフデータベースの違い｜比較表と使い分け・GraphRAGでの併用【2026年版】 … そもそもベクトルDBを別立てにするかの前段判断に使えます