WeaviateとはGraphQLで扱えるベクトル検索エンジン

2026年6月3日

Weaviateはオランダ拠点のSeMI Technologiesが2019年に公開したオープンソースのベクトルデータベースで、Go言語で書かれた本体に対してGraphQLとREST、gRPCの三系統のAPIを備え、テキストや画像、音声などの埋め込みベクトルを近似最近傍探索で照合します。BM25と組み合わせたハイブリッド検索や、OpenAIやCohereのモデルを自動で呼び出して埋め込み生成までを内部で完結させる「モジュール」機構が特徴で、RAG基盤として採用されることが増えています。本稿ではWeaviateの内部構造、運用上の勘どころ、競合との違いまでを実務目線で整理します。

この記事の目次

WeaviateのアーキテクチャとGraphQL設計
モジュール機構と外部モデル連携
ハイブリッド検索とフィルタ性能
運用と他製品との位置づけ
まとめ

WeaviateのアーキテクチャとGraphQL設計

Weaviateのコア部分はGo言語で実装され、シャード単位でHNSW（Hierarchical Navigable Small World）インデックスを保持します。スキーマは「Class」と呼ばれる単位で定義し、各プロパティに型とベクトル化に使うモジュールを指定する構造で、リレーショナルデータベースのテーブルとオブジェクト指向のクラスを掛け合わせたような考え方になっています。永続化層にはLSMツリーを採用し、書き込みはWALに記録されてからメモリ上のインデックスへ反映されるため、再起動時にもベクトル状態が復元されます。

クエリインターフェースとしてGraphQLを採用している点が大きな特徴で、nearTextやnearVector、hybridといった述語をフィルタ条件と組み合わせて記述します。GraphQLの戻り値はネストした構造を一度のリクエストで取得できるため、検索結果と関連オブジェクトを同時に引き当てたいRAGアプリケーションと相性が良いとされています。v1.18以降はgRPC経由のバイナリプロトコルが追加され、Pythonクライアントv4ではGraphQLよりも桁違いに低レイテンシで通信できるようになりました。

モジュール機構と外部モデル連携

Weaviateは「vectorizer」と呼ばれるプラグイン群を持ち、text2vec-openaiやtext2vec-cohere、ローカルで動作するtext2vec-transformersなどを切り替えてベクトル化を担わせます。オブジェクトを投入する際に明示的にベクトルを渡さなくても、設定したモジュールが裏側でAPIを叩き、埋め込みを生成してから格納する仕組みのため、アプリケーション側にベクトル化ロジックを書かずに済みます。リランカー用のreranker-cohereや生成系のgenerative-openaiを組み合わせれば、検索から回答生成までをWeaviate内で完結させるRAGパイプラインを構成できます。

運用面では、外部APIキーをサーバ起動時の環境変数として保持し、テナントごとに切り替えるマルチテナンシー機能と組み合わせて使うのが定石です。v1.20で導入されたマルチテナント機能はテナントごとに独立したシャードを切るため、SaaSとして顧客データを分離したい場合に都合がよく、テナントの非アクティブ化やオフロードといったライフサイクル管理APIも整備されています。

ハイブリッド検索とフィルタ性能

WeaviateはHNSWによるベクトル類似度検索だけでなく、BM25Fによるキーワード検索を同居させ、両者のスコアをRRF（Reciprocal Rank Fusion）またはランク融合のαパラメータで結合するハイブリッド検索を標準搭載しています。語彙の一致と意味的な近さを両立できるため、型番や商品コードのような固有名詞を含む検索でも取りこぼしを減らせます。

フィルタ付き検索の挙動は競合製品との差が出やすい部分で、Weaviateは「pre-filter」と「post-filter」の自動切替えに加え、フィルタ済みインデックスを動的に構築する「flat」「dynamic」両モードを選べます。カーディナリティの低い属性であればHNSWの探索中にフィルタを評価し、高カーディナリティであれば対象集合を絞ってから線形探索する、といった戦略をプランナが切り替えるため、属性検索の組み合わせ次第で挙動が大きく変わる点は押さえておきたいところです。

運用と他製品との位置づけ

本番運用では、HNSWのパラメータ（efConstruction、ef、maxConnections）に加え、ベクトル圧縮のためのPQ（Product Quantization）やBQ（Binary Quantization）の有効化が要点になります。10億件規模ではメモリ使用量がボトルネックになりやすく、BQでメモリを32分の1程度に圧縮しつつ再ランクで精度を取り戻す構成がよく採られます。クラスタリングはRaftベースで合意形成を行い、v1.25からはスキーマ変更もRaft経由で複製されるため、ローリングアップグレード時の整合性が以前より大きく改善しました。

競合のQdrantやMilvusと比べると、Weaviateは「モジュール込みで完結する開発体験」と「GraphQLによる宣言的クエリ」を強みとしており、半面でストレージ最適化や水平スケールの最大規模ではMilvusに譲ると評価されることもあります。Weaviate Cloud Servicesによるマネージド提供や、Embedded Weaviateと呼ばれる組込みモードもあり、PoCから本番までを同一プロダクトでカバーできる点は採用判断の決め手になりやすいです。