ベクトル検索用の Azure サービスを選択する

ベクター検索は、ベクトルの形でデータベースに格納されている情報を検索する方法です。ベクトルは、テキストや画像などのメディアの機能や特性を表す数値のグループです。情報内のセマンティックリレーションシップをキャプチャするため、正確なキーワードマッチングを超えた類似性検索が可能になります。

Azure には、ベクター化されたデータを格納および検索するための複数の方法が用意されています。この記事は、アプリケーションに適したベクター検索サービスAzure選択するのに役立ちます。

この記事では、ベクトル検索機能に基づいて次のサービスを比較します。

各サービスのシステム要件を比較するには、「候補となるサービスと機能のマトリックスを選択する」を参照してください。

サービス候補を選択する

このセクションでは、ニーズに最適なサービスを選択するのに役立ちます。選択肢を絞り込むには、まずシステム要件を検討します。

主な要件

従来のデータベースソリューションと AI Search のどちらを使用するかを決定するには、要件と、データに対してライブまたはリアルタイムのベクター検索を実行できるかどうかを検討します。ベクター化されたフィールドの値を頻繁に変更し、それらの変更をリアルタイムまたはほぼリアルタイムで検索できる必要がある場合は、従来のリレーショナルデータベースまたはNoSQL データベースがシナリオに最適です。同様に、既存のデータベースがパフォーマンス目標を満たす最適な方法である可能性があります。ただし、ワークロードでリアルタイムまたはほぼリアルタイムのベクター検索が不要で、ベクターのインデックスを管理できる場合は、AI Search を使用できます。

従来のデータベースソリューションを選択する場合は、チームのスキルセットと既存のデータベースに基づいてデータベースサービスを選択します。 NoSQLのAzure Cosmos DBなど、データベースサービスを既に使用している場合は、そのサービスがシナリオに最も簡単なソリューションである可能性があります。

NoSQLのAzure Cosmos DBは、運用データとベクター検索を同じシステムに保持し、フルテキストスコアリング、ハイブリッド検索、または組み込みの再ランク付けが必要な場合に適しています。セマンティックリランカーはプレビュー段階です。アプリケーションがレコードとその埋め込みを一緒に書き込むときに、更新されたアイテムに対してクエリを実行する前に、別の検索インデックスを同期する必要はありません。
AI Search は、ファセットやオートコンプリートなどの統合されたベクター化と検索固有の機能を備えた、複数のソースのコンテンツに対して個別のマネージドインデックスが必要な場合に適しています。
Azure Database for PostgreSQLでは、エラスティッククラスターを使用した水平スケーリングがサポートされます。これは、水平シャーディングをサポートするオープンソース Citus 拡張機能のマネージドオファリングです。この機能は、ベクターデータを複数のノードに分散します。これは、大規模なベクターデータセットに役立ちます。
超低待機時間、メモリ内ベクター検索が必要な場合、またはキャッシュまたはセッション管理のために Redis が既にデプロイされている場合は、managed Redis Azure検討してください。

各データベースサービスには、ベクター検索に固有の機能と制限があります。データベースの種類に必要な機能があることを確認します。

新しいサービスと追加のデータベースインスタンスにより、コストと複雑さが増す可能性があります。オーバーヘッドを減らすために、既存の設計を引き続き使用できます。現在のデータベースでのベクター検索は、専用のベクター検索サービスよりもコスト効率が高い場合があります。

高度な取得機能のサポートは、サービスによって異なります。 NoSQLとAzure DocumentDB のAzure Cosmos DBは、逆ランク融合 (RRF) を使用してフルテキスト検索とベクター検索を組み合わせたネイティブハイブリッド検索を提供します。 NoSQLのAzure Cosmos DBでは、プレビューでセマンティックリランカーも提供されます。 AI Search では、マネージド検索機能としてハイブリッド検索とセマンティックランク付けが提供されます。これらの機能を提供しないサービスの場合は、アプリケーションまたはデータベースコードに必要なランク付けロジックを実装します。

機能マトリックス

このセクションの表は、ベクトル検索サービスの機能Azureまとめたものです。使用可能なサービスと要件を比較します。一部のサービスは特定のシナリオに適しているため、各表に示されているトレードオフを考慮してください。

Microsoft Fabricで作業している場合は、イベントハウスをベクターデータベースとして使用することで、ベクター類似性検索 (VSS) に Real-Time インテリジェンスを使用できます。詳細については、Fabricドキュメントを参照してください。

基本機能

ベクターデータ型、近似最近傍 (ANN) ベクターインデックス、ベクターディメンションの制限、複数のベクターフィールド、および複数のベクターインデックスのネイティブサポートは、サービスによって異なります。ワークロードには、これらの機能の 1 つ以上が必要な場合があります。

次の表に、各Azure サービスのベクター機能を示します。

能力	Azure Cosmos DB for NoSQL	Azure DocumentDB	Azure Database for PostgreSQL	Azure マネージド再配布	AI検索	SQL Database
組み込みのベクトル検索	はい	可¹	可²	はい³	はい⁴	はい
ベクトルデータ型	はい	はい	はい	はい	はい	はい⁵
ディメンションの制限⁶	4,096⁷、またはフラットインデックス付き 505	構成に応じて 16,000⁸、4,000、または 2,000	16,000⁹ または 2,000	32,768	4,096¹⁰	1,998 ¹¹
複数のベクトルフィールド	はい	はい¹²	はい	はい	はい	はい
複数のベクトルインデックス	はい	はい¹³	はい	はい	はい	はい

Azure DocumentDB では、埋め込みでのベクター検索がサポートされています。
pgvectorPostgreSQL の拡張機能であり、ベクター検索をサポートします。 pg_diskann拡張機能は、大規模な効率的な ANN 検索のための DiskANN ベースのベクターインデックス作成を提供します。
Azure Managed Redis の RediSearch モジュールは、ベクター検索を提供します。
AI Search ではベクターがサポートされています。
SQL Database では、ベクターデータ型がサポートされています。
OpenAI 埋め込みモデルには、text-embedding-ada-002 および text-embedding-3-small 用の 1,536 次元と、text-embedding-3-large 用の 3,072 ディメンションが含まれます。 Azure Vision マルチモーダル埋め込みモデルには、画像とテキストの両方に 1,024 個のディメンションがあります。
フラットインデックス型を使用してインデックスを作成するベクターは、最大 505 次元を持つことができます。量子化されたFlat または DiskANN インデックスの種類を使用してインデックスを作成するベクターは、最大 4,096 次元を持つことができます。
DiskANN と製品量子化を使用して、最大 16,000 次元のベクトルにインデックスを付けることができます。半精度の階層ナビゲーション可能な小さな世界 (HNSW) または IVFFlat は、最大 4,000 次元のベクターインデックスをサポートします。圧縮を使用しない場合、インデックス作成の既定の最大ベクトル次元は 2,000 です。詳細については、Azure DocumentDB のベクター次元を参照してください。
ベクターには、最大 16,000 個のディメンションを含めることができます。ただし、IVFFlat および HNSW アルゴリズムを使用したインデックス作成では、最大 2,000 次元のベクトルがサポートされます。
AI Search では、Matryoshka Representation Learning ベースのディメンションの切り捨てがサポートされています。テキスト埋め込み 3 モデルでは、ベクターディメンションを減らすことができます。たとえば、256 次元または 512 ディメンションを使用できます。
SQL Database では、最大 1,998 次元のネイティブベクターデータ型がサポートされています。
各Azure DocumentDB ベクターインデックスは、1 つのベクターパスを対象とします。クエリを実行する必要があるベクターフィールドごとに個別のベクターインデックスを作成します。
Azure DocumentDB コレクションには複数のインデックスを作成できますが、特定のベクターパスをターゲットにできるのは 1 つのベクターインデックスだけです。

検索方法

ワークロードでは、多くの場合、ベクター検索とフルテキスト検索またはハイブリッド検索を組み合わせる必要があります。ハイブリッド検索は、フルテキスト検索またはセマンティック検索とベクター検索を組み合わせたものです。ハイブリッド検索と再ランク付けを組み合わせると、ワークロードの精度が高くなります。独自のコードを使用して、ハイブリッド検索と再ランク付けを手動で実装することも、ベクターストアがこのワークロード要件をどのようにサポートしているかを検討することもできます。

検索メソッド	Azure Cosmos DB for NoSQL	Azure DocumentDB	Azure Database for PostgreSQL	Azure マネージド再配布	AI検索	SQL Database
フルテキスト検索	はい¹²	可²	はい³	はい⁴	はい	はい⁵
ハイブリッド検索	はい⁶	はい⁷	はい⁸	はい⁹	はい¹⁰	はい¹¹
組み込みの再ランク付け	はい (プレビュー)¹³	いいえ	いいえ	いいえ	可¹	いいえ

セマンティックランク付けでは、フルテキスト検索とベクター検索の結果が再ランク付けされます。
Azure DocumentDB では、テキストインデックスを使用した検索とクエリがサポートされています。
PostgreSQL では、フルテキスト検索がサポートされています。
Azure Managed Redis では、テキストトークン化、ステミング、ランク付けなど、RediSearch モジュールを使用したフルテキスト検索がサポートされています。
SQL Serverでは、フルテキスト検索がサポートされます。
NoSQLのAzure Cosmos DBでは、RRF を使用した BM25 フルテキストスコアリングとベクター検索を組み合わせたハイブリッド検索がサポートされます。コンポーネントのランク付けに重みを割り当てることができます。
Azure DocumentDB では、フルテキスト検索とベクター検索と逆ランク融合を組み合わせたハイブリッド検索がネイティブにサポートされます。
ハイブリッド検索は組み込まれませんが、サンプルコードを使用できます。
Azure Managed Redis では、VSS とテキスト、数値、タグ、および geo フィールドの属性フィルターを組み合わせて使用したハイブリッド検索がサポートされます。
フルテキスト検索、ベクター検索、セマンティックランク付けを組み合わせたハイブリッド検索は、AI Search の機能です。
SQL Database とSQL Serverのハイブリッド検索の例を使用できます。
NoSQLのAzure Cosmos DBでは、フルテキスト検索とフルテキストスコアリングがサポートされます。
NoSQLのAzure Cosmos DBのセマンティックリランカーはプレビュー段階です。サポートされているAzure Cosmos DB SDK を使用して、ベクター、フルテキスト、またはハイブリッドクエリの結果を再ランク付けできます。

ベクトルデータインデックス作成アルゴリズム

ベクトルデータのインデックス作成は、ベクトルを効率的に格納および取得する機能です。インデックス作成は、データソースに対する類似性検索と最近隣クエリの速度と精度に影響します。

インデックスでは通常、完全な k ニアレストネイバー (Ek-NN) アルゴリズムまたは ANN アルゴリズムが使用されます。 Ek-NN は、すべてのデータポイントに対して完全な検索を実行し、正確な k の最も近い近傍を返します。少量のデータを検索する場合、Ek-NN はミリ秒単位で動作します。データセットが大きい場合は、待機時間が発生する可能性があります。

DiskANN、 HNSW、および IVFFlat は ANN アルゴリズムインデックスです。適切なインデックス作成戦略を選択するには、データセットの性質、クエリの特定の要件、使用可能なリソースなど、さまざまな要因を慎重に考慮する必要があります。 DiskANN は、データセットの変更に適応し、計算リソースを節約できます。 HNSW は、高速なクエリ応答を必要とし、データセットの変更に適応できるシステムに優れています。 IVFFlat は、ハードウェアリソースが制限されている環境やクエリボリュームが多くない環境で有効です。

次の表に、使用可能なベクターデータインデックスの種類を示します。

インデックス作成のアプローチ	Azure Cosmos DB for NoSQL	Azure DocumentDB	Azure Database for PostgreSQL	Azure マネージド再配布	AI検索	SQL Database
DiskANN	はい	可¹	可²	いいえ	いいえ	はい³
Ek-NN	はい	はい	はい	はい⁴	はい	はい
HNSW	いいえ	可¹	はい	はい⁵	はい	いいえ
IVFFlat	いいえ	はい	はい	いいえ	いいえ	いいえ
その他	Flat、quantizedFlat⁶	パスごとに 1 つのベクターフィールドとインデックス⁷ ⁸	-	-	スカラー量子化、二項量子化⁹	-

詳細については、「Azure DocumentDB の統合ベクターストア」を参照してください。
詳細については、「DiskANN for Azure Database for PostgreSQL.
ネイティブ DiskANN ベクターインデックス作成はプレビュー段階です。詳細については、SQL データベースエンジンのベクター検索とベクターインデックスを参照してください。
Azure Managed Redis では、ブルートフォース検索に FLAT インデックスの種類を使用した Ek-NN 検索がサポートされています。
Azure Managed Redis では、ANN 検索用の HNSW がサポートされます。詳細については、 VSS を参照してください。
詳細については、「ベクターインデックス作成ポリシー」を参照してください。
インデックス作成は、パスごとに 1 つのベクターにのみ適用されます。
ベクターパスごとに作成できるインデックスは 1 つだけです。
AI Search では、スカラー量子化とバイナリ量子化がサポートされ、検索インデックスのベクターサイズが小さくなります。

類似性と距離の計算機能

ベクター検索では、コサインの類似性、ドット積、ユークリッド距離の計算方法がサポートされています。これらのメソッドを使用して、2 つのベクトル間の類似性または距離を計算します。

予備データ分析では、メトリックとユークリッド距離を使用して、さまざまなデータ構造の分析情報を抽出できます。一般に、テキスト分類はユークリッド距離の下でより優れたパフォーマンスを発揮します。特定のテキストに最も類似したテキストの検索は、通常、コサイン類似度を使用するとより適切に機能します。

Azure OpenAI 埋め込みでは、ドキュメントとクエリの間の計算の類似性にコサインの類似性が依存します。

組み込みのベクトル比較計算	Azure Cosmos DB for NoSQL	Azure DocumentDB	Azure Database for PostgreSQL	Azure マネージド再配布	AI検索	SQL Database
コサイン類似度	可¹	はい	はい	可²	はい	はい³
ユークリッド距離	可¹	はい	はい	可²	はい	はい³
ドット積	可¹	はい	はい	可²	はい	はい³

詳細については、NoSQLのAzure Cosmos DBのベクトル距離計算を参照してください。
Azure Managed Redis では、コサインの類似性、ユークリッド距離、および内部積距離メトリックがサポートされています。詳細については、 VSS を参照してください。
詳細については、SQL Database と SQL Server の距離計算の例を参照してください。

Azure OpenAI とその他のコンポーネントとの統合

ベクター検索を他のMicrosoftコンポーネントにリンクできます。たとえば、OpenAI Azureは、VSS のデータおよび入力クエリのベクターを作成するのに役立ちます。

能力	Azure Cosmos DB for NoSQL	Azure DocumentDB	Azure Database for PostgreSQL	Azure マネージド再配布	AI検索	SQL Database
Foundry IQ の統合	いいえ	いいえ	いいえ	いいえ	はい	いいえ
Foundry Agent Service の統合	可¹	いいえ	可²	可²	はい³	可²
統合Azure OpenAI 埋め込み生成	いいえ	いいえ	はい⁴	いいえ	はい⁵	はい⁶
セマンティックカーネルの統合	はい⁷	はい⁸	はい⁹	はい¹⁰	はい¹¹	はい¹²

Foundry Agent Service の統合は、エージェント状態ストレージを通じて提供されます。
Foundry Agent Service の統合は、データ、ベクター検索、またはツールアクセスを通じて提供されます。
Foundry Agent Service の統合は、ナレッジの取得とベクター検索を通じて提供されます。
Azure AI 拡張機能を使用できます。
AI Search には、テキストチャンクをベクター化するスキルが含まれています。
埋め込みモデルデプロイ用のストアドプロシージャを作成できます。
このサービスは、メモリコネクタとベクターデータベースコネクタとしてサポートされています。詳細については、C# のドキュメントとPythonドキュメントを参照してください。
このサービスは、ベクターデータベースコネクタとしてサポートされています。詳細については、C# のドキュメントとPythonドキュメントを参照してください。
このサービスは、メモリコネクタとベクターデータベースコネクタとしてサポートされています。詳細については、 C# のドキュメントを参照してください。
このサービスは、ベクターデータベースコネクタとしてサポートされています。詳細については、「 Redis コネクタの使用」を参照してください。
このサービスは、メモリコネクタとベクターデータベースコネクタとしてサポートされています。詳細については、C# のドキュメントとPythonドキュメントを参照してください。
このサービスはメモリコネクタとしてサポートされています。

運用上の考慮事項

機能マトリックスは、機能要件を満たすサービスを識別します。複数のサービスが適格な場合は、各オプションがデータの配置、鮮度、フィルター処理、容量、埋め込みメンテナンスにどのように影響するかを比較します。

データの配置と鮮度

NoSQL、Azure DocumentDB、Azure Database for PostgreSQL、およびAzure SQL DatabaseのAzure Cosmos DBは、ワークロードの運用レコードを含む埋め込みを格納できます。アプリケーションが埋め込みを生成し、レコードを使用して書き込む場合、両方の値がデータベースの書き込みパスを介して更新されます。この設計により、個別の検索インデックス同期プロセスが回避されます。

AI Search では、ソースシステムとは別の検索インデックスが保持されます。ドキュメントをインデックスにプッシュしたり、インデクサーを使用してサポートされているデータソースからデータをプルしたりすることができます。個別のインデックスを使用すると、複数のシステムのコンテンツを結合して整形し、トランザクションワークロードとは別に取得をスケーリングできます。また、検索可能なデータの別のコピーも作成されます。ソースの更新と対応するインデックスの更新の間の時間を考慮します。

運用レコードが頻繁に変更され、取得で更新された値を使用する必要がある場合は、併置された設計を選択します。コーパスが複数のシステムにまたがる場合、またはマネージドコンテンツの抽出、エンリッチメント、ベクター化が必要な場合は、個別の検索インデックスを選択します。

フィルター処理とパーティション分割

ほとんどの実稼働ベクタークエリでは、フィルターを使用して、テナント、セキュリティ、ドキュメントセット、またはアプリケーションの境界を適用します。再呼び出しと待機時間の両方に影響を与える可能性があるため、ベクター検索を使用してフィルターを評価します。

NoSQLのAzure Cosmos DBで、VectorDistanceを使用するクエリのWHERE句にサポートされている述語を追加します。パーティションキーフィルターは、検索を一致する論理パーティションに制限します。
Azure DocumentDB で、サポートされているフィルターを cosmosSearch 演算子に追加します。
AI Search では、フィルター可能な非ベクターフィールドを作成し、ベクターフィルターモードを使用して、サービスがベクター取得の前後にフィルターを適用するかどうかを制御します。

容量と地域設計

サービスでは異なるスケーリングと課金単位が使用されるため、定価比較では特定のワークロードのコストは表示されません。モデルインデックスサイズ、ベクトルディメンション、クエリレート、更新率、レプリカ、パーティション、およびデータベーススループット。別の検索インデックスを評価するときに、ソースデータベースのコストを含めます。

地域設計も異なります。

Azure Cosmos DBでは、Azure リージョン間で組み込みのデータ分散が提供され、複数の書き込みリージョンがサポートされます。
AI Search はリージョンサービスです。マルチリージョン AI 検索設計では、各リージョンで検索サービスを使用し、インデックスを揃え続けるプロセスが必要です。

埋め込みを最新の状態に保つ

埋め込みとは、派生データです。ソースコンテンツが変更されたとき、または別の埋め込みモデルを採用したときに再生成します。

AI Search インデクサーは、サポートされているソースのチャンクと統合ベクター化を調整できます。データベース中心の設計では、アプリケーションまたはデータパイプラインがこれらの手順を実行し、結果のベクターを書き込みます。変更フィードまたはソースイベントはそのプロセスを開始できますが、更新された埋め込みを格納するまで、新しいコンテンツは意味的に検索できません。

寄稿者

Microsoft では、この記事を保持しています。次の共同作成者がこの記事を書きました。

主要著者

斉藤優 |ソリューションエンジニア
山本美穂 |シニアソリューションエンジニア

その他の共同作成者:

大槌田慶太 |シニアソリューションエンジニア
マニシュ・シャルマ |プリンシパルプログラムマネージャー

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ

フィードバック

このページはお役に立ちましたか?

最終更新: 2026-09-21