Weaviateとは？ハイブリッド検索・マルチテナンシー・料金と選定基準【2026年版】

Weaviateは、キーワード検索と意味検索を1つのクエリで返すOSSのベクトルデータベースです。ライセンスはBSD-3-Clause、実装言語はGoで、GitHubのスター数は16,671（2026年7月30日時点）。この記事では、インデックスと量子化の選び方、alpha既定0.75のハイブリッド検索、日本語BM25を効かせるkagome_jaの有効化、マルチテナンシー、1.38系のMCPサーバー、料金から月額を逆算する手順までを実装視点で整理し、pgvectorやマネージド型へ寄せるべき案件の条件も示します。

まとめ：Weaviate採用の4条件とpgvector・Pineconeへ委ねる判断

Weaviateを選ぶ理由は4つです。BM25Fとベクトルを1エンドポイントで融合できること、テナント単位でシャードを分ける構造がSaaSの分離要件に噛み合うこと、HFreshとRQ量子化でメモリ費を桁で下げられること、1.38系でMCPサーバーが正式提供となりエージェントから直接叩ける口が標準で付いたことです。

見送る条件も明確です。数十万件以内で既にPostgreSQLを運用しているならpgvectorで足り、運用人員を置けない体制ならマネージド型の方が総額は安く済みます。費用面の要点は1つ。次元課金は1,536次元×1,000万件でも月$71程度にとどまり、支配的なのは最低料金と運用人件費です。保守対象が最新3マイナー（2026年7月時点で1.36系・1.37系・1.38系）に限られる点も、年間の運用コストとして見積もりに入れてください。

AIネイティブなベクトルデータベースとしてのWeaviateの構造

Weaviateは「ベクトルを入れる箱」ではなく、ベクトル化・検索・生成の呼び出しまでを内側に抱えたデータベースとして設計されています。

Weaviateの定義とBSD-3-Clauseで自社ホストできる前提条件

Weaviateは、オブジェクトとその埋め込みベクトルを同一のデータストアに保持し、近傍探索・フィルタ・キーワード検索を同じAPIで受けるベクトルデータベースです。ライセンスはBSD-3-Clause。再配布時に著作権表示と免責条項を残す義務はありますが、コピーレフトの伝播はありません。受託開発で顧客環境へ組み込む案件では、この点が採用可否を分けます。

実装はGoの単一バイナリで、Dockerイメージ1つで起動できます。JVMやZooKeeperのような外部依存はありません。インデックス構造の前提から押さえたい場合は、ベクトル化とインデックス構造から理解するベクトルデータベースの仕組みを先に読むと以降の設定値の意味がつかみやすくなります。

Vectorizerモジュールがベクトル化を内側に取り込む仕組み

Weaviateの特徴が最も出るのがvectorizerです。コレクション定義に text2vec 系のモジュールを指定すると、オブジェクト投入の時点でWeaviateが埋め込みAPIを呼び、ベクトルを生成して格納します。アプリ側に埋め込み生成のコードは要りません。

副作用もあります。埋め込みモデルの選択がスキーマ定義に結び付くため、差し替え時はコレクション設計から見直すことになります。自前で生成したベクトルを直接渡す運用も可能なので、モデル評価を回すフェーズは外部生成、確定後はvectorizer任せへ切り替える進め方が現実的です。

コレクションとプロパティ定義が決めるフィルタとBM25の挙動

データはコレクション単位で管理します。コレクションはスキーマ定義を共有するオブジェクトの集合で、各オブジェクトはプロパティ群と任意のベクトルを持つJSONドキュメントです。プロパティにはデータ型に加え、トークナイズ方式とインデックス対象の指定が付きます。フィルタ用の数値・日付プロパティとBM25対象のテキストプロパティを分けて設計しておくと、後述するハイブリッド検索の挙動が読みやすくなります。RAG用途なら、チャンク本文・出典URL・更新日時・テナント識別子の4点が最小構成です。

HNSW・HFresh・量子化で決まるメモリ費とrecallの設計判断

インデックスと量子化の組み合わせが、そのままインフラ費に跳ね返ります。

HNSW・flat・dynamicの3インデックスと切替閾値1万件

既定はHNSWです。多層グラフを辿って対数時間で近傍を返す構造で、ノードとエッジをメモリに保持するためデータ量に比例してメモリを食います。flatインデックスは全ベクトルを単純なリストに置く方式で、メモリ消費は小さい一方、件数に対して検索時間が線形に伸びます。

両者を自動で切り替えるのがdynamicインデックス（v1.25以降）です。オブジェクト数が既定10,000件を超えた時点でflatからHNSWへ移行し、非同期インデックスの有効化が前提になります。テナントごとのデータ量がばらつく構成では、この自動切替がメモリ費を抑えます。

数百万件までならHNSW、テナント数が多いならdynamic、メモリ費が制約ならHFreshの順に当てます。

HFreshがディスク常駐で下げるメモリ費とRQ-1内蔵の条件

1.36系で導入されたHFreshは、1.38系（2026年6月）で正式提供になりました。SPFreshアルゴリズムを土台に、ベクトルをpostingsと呼ぶディスク上の領域へまとめ、そのセントロイドだけを小さなHNSWとしてメモリに置く構造です。データが継続的に流れ込むワークロードでメモリ使用量を低く保ちます。

制約は2点。RQ-1量子化が内蔵されている前提で動くこと、距離指標がcosineとl2-squaredに限られることです。内積やハミング距離を前提にした設計では選べません。有効化にプレビューフラグは不要で、名前付きベクトル単位で指定します。

PQ・BQ・SQ・RQの圧縮率と98〜99%recallの実装選択

量子化は4系統です。PQはベクトルを分割してセントロイドで表現する方式で、768次元×4バイトの生ベクトルに対し圧縮版は128×1バイト相当、約24倍の差が出ます。BQは1次元1ビットに落として32倍削減しますが、情報損失は大きく、精度の落ち方は埋め込みモデル次第です。SQは32ビット浮動小数点を256段階の8ビット整数へ写して4倍削減し、BQより精度を保てます。

2026年時点で最初に検討すべきはRQです。8ビットRQは1.32系でHNSW、1.35系でflatに対応し、4倍圧縮でrecall 98〜99%という公表値。1ビットRQは1.33系でHNSW、1.35系でflatに対応し、約32倍圧縮まで踏み込める一方、recallは調整済みPQよりやや落ちるとされます。

実務の判断はこうです。まず8ビットRQを既定に置き、メモリ費が合わないときだけ1ビットRQへ落として、over-fetchと再スコアリングで取りこぼしを回収する。RQが選べる環境で、PQの調整に時間を割く価値は小さくなりました。

alpha既定0.75と融合方式が変えるハイブリッド検索の当たり方

BM25Fの語彙一致とベクトルの意味的近さを、1回のクエリで融合して返す。ここがWeaviateを選ぶ実装上の最大の理由です。

alphaを0.75から動かす判断基準と型番検索で外す失敗例

alphaは0から1の範囲で、既定値は0.75です。1に近づくほどベクトル検索寄り、0に近づくほどキーワード検索寄りになります。既定値は意味検索に重心を置いた配分で、FAQや社内文書の検索なら妥当な出発点です。

問題が出るのは型番・品番・エラーコードを引く検索です。「ABC-1200X」のような文字列は埋め込み空間で近傍が定まらず、alpha 0.75のままだと語彙一致した正解が上位から押し出されます。型番検索が業務要件に入るなら、クエリの形（英数字と記号の比率、文字数）で分岐させ、該当時はalphaを0.2〜0.3へ落としてください。統合の仕組みはハイブリッド検索とは？RAGでBM25とベクトル検索を統合する仕組みで解説しています。

2つの融合アルゴリズムの差分とautocutを使える前提条件

融合方式は2つです。relativeScoreFusionは両検索の実スコアを正規化して足し合わせる方式で、1.24系以降はこちらが推奨の既定として扱われます。rankedFusionは順位のみを使う旧来方式です。GraphQL APIのリファレンスには fusionType の既定を rankedFusion とする記述が残っているため、クライアント側で明示指定するのが安全です。

実装上の差はautocutの可否に出ます。スコアの落差から結果を自動で打ち切るautocutはrelativeScoreFusionでのみ機能します。RAGでコンテキストに詰める件数を動的に決めたいなら、relativeScoreFusionを明示したうえでautocutを併用してください。

日本語BM25でkagome_jaを有効化する環境変数と検証手順

日本語案件で最初に踏む落とし穴がトークナイズです。既定のwordは英数字以外の文字で分割するため、日本語の文はほぼ意味のある語に切れません。BM25側が機能しないまま「ハイブリッド検索なのに語彙一致が弱い」という症状が出ます。

選べる方式は word・lowercase・whitespace・field・trigram・gse・kagome_ja・kagome_kr の8種類です。日本語の形態素解析にはkagome_jaを指定します。ただしkagome_jaは資源節約のため既定でロードされないので、インスタンス側で環境変数 ENABLE_TOKENIZER_KAGOME_JA を true にする必要があります。中国語混在のコーパスならgseも候補です。

検証はコレクション作成前に済ませてください。トークナイズ方式はプロパティ定義に紐づくため、後から変えると再インデックスが発生します。同じ文書セットへalphaを0に固定したBM25単独クエリを投げ、word指定とkagome_ja指定でヒット件数を比べる。差が出なければ環境変数が効いていません。

名前付きベクトルとマルチテナンシーで作るSaaS向け分離設計

SaaSや複数顧客案件では、この2機能の設計が運用費を左右します。

1オブジェクトに複数ベクトル空間を持たせる名前付きベクトル設計

名前付きベクトルは、1つのオブジェクトに複数のベクトル空間を持たせる仕組みです。空間ごとにインデックス種別・圧縮方式・vectorizerを個別指定できるため、同じ商品データへ「説明文の意味検索用」と「画像の類似検索用」を別モデルで併存させられます。既存コレクションへの後追い追加は1.31系以降で可能です。

実務では埋め込みモデルの移行に効きます。新モデルの空間を追加して両方へ書き込み、検索側を段階的に切り替え、旧空間を落とす。ダウンタイムなしで差し替える経路が標準機能で確保されています。

ACTIVE・INACTIVE・OFFLOADEDの3状態で削るテナント費用

マルチテナンシーでは、テナントごとにシャードを割り当ててデータとベクトルインデックスを分離します。削除もテナント単位で完結するため、解約時のデータ消去要件に素直に応えられます。規模の目安は、9ノード（n1-standard-8）構成で約17万のアクティブテナントという実測値。上限を決めるのはOSのファイルディスクリプタ数です。

費用面で効くのは状態遷移です。ACTIVEは読み書き可能でメモリに載った状態、INACTIVEはローカルディスクに置いたまま参照不可、OFFLOADEDはAWS S3へ退避した状態です（OFFLOADINGとONLOADINGは遷移中の内部状態で、利用者側から指定はしません）。休眠テナントをINACTIVEやOFFLOADEDへ落とせば、契約数が伸びてもメモリ費は線形には増えません。

1.38系のMCPサーバー正式提供で変わるエージェント接続の設計

2026年6月の1.38系は、エージェントからデータストアを直接叩く構成の前提を変えました。

MCPサーバー内蔵で4ツールをエージェントへ開放する実装と権限

1.38系でMCPサーバーが正式提供になりました。REST APIと同じポート上の v1/mcp をStreamable HTTPのエンドポイントとして公開し、コレクション設定の取得・テナント一覧・ハイブリッド検索の実行・オブジェクトのupsertという4ツールをエージェントへ差し出します。検索用のツール定義を自前で書く工程が消えます。

運用上の要点は権限管理です。1.38系では有効化フラグがランタイム変更可能になり、ローリング再起動なしでエージェントの書き込み権限を付け外しできます。upsertを開けたままだと本番データを書き換えられる状態になるため、読み取りのみ有効にし、投入は別経路のバッチへ寄せる構成を既定にしてください。

Free・Flex・Premiumの3プラン料金と次元課金からの月額逆算

マネージド側の料金は2026年7月時点で3階層です。

Free枠10万オブジェクトとFlex・Premiumの契約条件の差

Freeは月額$0で、10万オブジェクト・メモリ1GB・ディスク10GB・1コレクションという枠。PoCの範囲なら足りますが、コレクションが1つに限られるためスキーマ設計の比較検証には窮屈です。Flexは月$45からの従量課金で、オブジェクト数の制限がなくなります。

Premiumは月$400からの前払契約で、共有と専用を選べます。業務システムへ組み込む案件では、初動が翌営業日というFlexの条件が要件定義と衝突しがちです。SLAの数字ではなくサポート応答時間から逆にプランを決める判断が実務的です。

1536次元×1000万件で月額を逆算する次元課金の計算手順

課金単位は格納したベクトル次元数です。単価はFlexが100万次元あたり$0.00465から、Premiumは共有$0.003875、専用$0.002718から。計算式は「次元数×オブジェクト数÷100万×単価」の一本です。

1,536次元の埋め込みを1,000万件格納する場合、総次元数は153億、100万次元単位で15,360。Flex単価なら月$71.4、Premium共有なら月$59.5です。100万件なら$7.1で、月$45の最低料金に飲まれます。1億件まで伸ばして月$714。数千万件規模までは、ストレージ単価より最低料金と運用人件費の方が大きくなります。

自社ホストと比べる際は、この額をクラウドのVM費用とエンジニアの工数と並べてください。1,000万件規模でマネージド月$71が、同等の可用性を自前で組む工数を下回るのは明らかです。RAG基盤を社内で抱えるか外へ出すかで迷う段階なら、RAG構築支援で扱っている構成パターンが判断材料になります。

最新3マイナーのみ保守という版管理方針が生む運用コストの実像

ここを見落とすと、稼働から半年で保守対象外のバージョンを本番に抱えます。

1.36・1.37・1.38の3世代だけが受けるパッチ提供の範囲

Weaviateはバグ修正とセキュリティパッチを最新3マイナーにのみ提供し、それより古いマイナーは能動的な保守対象から外れます。2026年7月時点の対象は1.36系（2026年2月24日）・1.37系（2026年4月16日）・1.38系（2026年6月）の3世代で、各マイナーの最新パッチを当て続けることも公式の推奨です。

この方針は、脆弱性が公表されたときの選択肢を狭めます。保守対象外で動いていると、パッチ適用ではなくマイナーアップグレードが唯一の対処になり、機能差分の検証を緊急対応の中で行う羽目になります。

約2か月間隔で出るマイナー更新を年間の運用計画へ織り込む手順

マイナーのリリース間隔は約2か月です。3世代しか保守されない前提と組み合わせると、あるバージョンが保守対象でいられる期間は概ね半年。年2〜3回のアップグレードが運用の固定費になります。

受託案件では、この工数を保守契約に明記するのが安全です。検証環境を1マイナー先行で回し、設定差分を確認してから本番へ上げます。1.38系では非同期レプリケーションがクラスタ単位のスケジューラへ再実装され、レプリケーション係数1超のコレクションで既定オンになりました（停止は ASYNC_REPLICATION_DISABLED）。設定を触っていないのに挙動が変わる更新があるため、リリースノートの既定値変更だけは毎回目を通してください。年2回の定期アップグレードと緊急パッチ用の予備工数を別枠で確保する形が、現実的な落とし所です。

Weaviateを採用する4条件とpgvector・Pineconeへ寄せる場面

条件を満たさない案件でWeaviateを選ぶと、運用工数だけが増えます。

ハイブリッド検索とテナント分離が要件になる受託案件の採用条件

採用条件は4つで、2つ以上該当すれば有力候補になります。語彙一致と意味検索の両立が要件で精度の調整余地を残したい案件、顧客ごとのデータ分離が契約条件に含まれるSaaS、数千万件規模のベクトルをメモリ費の制約下で扱う案件（HFresh＋8ビットRQが効きます）、AIエージェントから直接データストアを叩く構成で1.38系のMCPサーバーを標準の口にしたい案件です。日本語主体のコーパスなら、kagome_jaを外部トークナイザなしで選べる点も加点材料になります。

数十万件以内・運用人員ゼロの現場でWeaviateを見送る基準

見送る条件は3つ、いずれも明確に言い切れます。1つめ、既にPostgreSQLを運用していてベクトルが数十万件以内ならpgvectorを選びます。バックアップ・監視・権限管理を既存のDB運用へ載せられる利点が、ハイブリッド検索の機能差を上回るためです。

2つめ、クラスタ運用に人を割けない体制ならマネージド専業へ寄せます。年2〜3回のアップグレードを引き受けられないなら、Pineconeのサーバーレス型のようにインフラ管理を持たない構成の方が総額で下回ります。3つめ、ローカル検証や試作だけならChromaで十分です。テナント分離とハイブリッド検索の調整余地、この2つが要件に無いならWeaviateを選ぶ理由は薄くなります。

よくある質問

導入検討でよく挙がる5つの疑問に答えます。

Weaviateは無料で使えますか？

OSS版はBSD-3-Clauseで、自社サーバーやクラウド上に自分で立てる限り費用はかかりません。マネージドのWeaviate Cloudにも月額$0のFree枠があり、10万オブジェクト・メモリ1GB・ディスク10GB・1コレクションまで試せます（2026年7月時点）。Free枠はコレクションが1つに限られるため、本番相当の検証は月$45からのFlexで行い、SLAとサポート応答が要件に入る段階でPremiumを検討する流れになります。

WeaviateとPineconeはどちらを選ぶべきですか？

分岐点はインフラを自分で持つかどうかです。テナント分離やインデックス種別・量子化方式まで自分で決めたい案件、日本語BM25のトークナイザを選びたい案件はWeaviateが向きます。運用を持たずに検索機能だけ欲しい場合は、Pineconeのようなサーバーレス型が適します。年2〜3回のマイナーアップグレードが固定費として発生する点も、比較材料に入れてください。

Weaviateの日本語検索はそのまま使えますか？

ベクトル検索は埋め込みモデル側が日本語に対応していれば動きます。一方でBM25側は既定のwordトークナイザだと日本語がほぼ分割されません。語彙一致を効かせるには、プロパティのトークナイズ方式にkagome_jaを指定し、環境変数 ENABLE_TOKENIZER_KAGOME_JA を true にします。この指定はプロパティ定義に紐づくため、後から変更すると再インデックスが必要です。

既存のPostgreSQLからWeaviateへ移行する必要はありますか？

データが数十万件以内で、検索がベクトル近傍だけで足りているなら移行の必要はありません。pgvectorのまま既存のDB運用へ載せておく方が、総保有コストは低く収まります。移行を検討する目安は3つ。件数が数百万件を超えてメモリ費が問題になったとき、語彙一致と意味検索の融合を細かく調整したくなったとき、顧客ごとのデータ分離が契約要件に入ったときです。

Weaviate Cloudと自社ホストで機能差はありますか？

データベース本体は同じコードベースなので、インデックス種別・量子化・ハイブリッド検索・マルチテナンシーはどちらでも使えます。差が出るのは運用側です。自社ホストは環境変数の指定やバージョン選択を自由に決められる代わり、アップグレードとバックアップを自分で回します。Weaviate CloudはGoogle Cloud上でリージョンを選ぶ方式のため、国内保管が要件なら選択できるリージョンを事前に実機で確認してください。

関連記事

• ChromaDBとは？アーキテクチャ・使い方・pgvectorとの違いまで：ローカル試作向けの軽量ベクトルDBとの機能差を確認できます
• ベクトルデータベースとグラフデータベースの違い：Weaviateの近傍探索とグラフ構造の探索をどう使い分けるかを整理しています
• リランクモデルとは？ベクトル検索と組み合わせる種類・仕組み・選び方：ハイブリッド検索の後段でrecallを精度へ変える工程を解説しています
• チャンク分割とは？RAGで効くチャンクサイズまで徹底解説：Weaviateへ投入する前段のチャンク設計を扱っています