Azure Cosmos DBの「Integrated Vector Database」は、ベクトル検索専用の外部データベースを必ず追加するのではなく、Azure Cosmos DB内に元データとベクトル埋め込みを一緒に保存し、検索・RAG・AIエージェントから直接使うための設計です。結論から言うと、管理者は「機能有効化」「スループット」「コンテナー設計」「インデックス変更のしづらさ」を確認し、開発者は「ベクトルの次元数」「距離関数」「インデックス種別」「TOP N付きのクエリ」「移行時の再埋め込み」を重点的に見直す必要があります。
Microsoft Learnの公式情報では、Azure Cosmos DBの統合ベクトルデータベースはNoSQLとPostgreSQLを対象に説明されています。ただし、実務で新規採用を検討する場合は、Azure Cosmos DB for NoSQLを中心に評価するのが安全です。特にAzure Cosmos DB for PostgreSQLについては、関連ドキュメントで退役パスにあることが示されており、新規プロジェクトでは推奨されていません。(Microsoft Learn) (Microsoft Learn)
Integrated Vector Databaseで何が変わるのか
今回のポイントは、Azure Cosmos DBが「アプリケーションデータの保存先」にとどまらず、ベクトル検索を含むAIアプリケーションのデータ基盤として使いやすく整理されたことです。
従来のRAG構成では、業務データをAzure Cosmos DBや他のDBに保存し、ベクトル埋め込みは別のベクトルデータベースや検索サービスに複製する構成がよく使われました。この構成は柔軟ですが、同期処理、データ整合性、運用コスト、障害時の切り分けが複雑になりやすいのが難点です。
Integrated Vector Databaseでは、元データとベクトル埋め込みを同じCosmos DBのデータモデル内で扱えます。Microsoftの公式説明でも、埋め込みと元データを同じ場所に置くことで、別の純粋なベクトルデータベースへ複製するコストを減らし、データ整合性、スケール、パフォーマンスを高めやすいとされています。(Microsoft Learn)
| 観点 | 従来ありがちな構成 | Integrated Vector Databaseの考え方 |
|---|---|---|
| データ配置 | 業務DBとベクトルDBを分離 | 元データとベクトルをCosmos DB内に同居 |
| データ同期 | 変更のたびに別DBへ同期が必要 | 同じ論理データに近い形で管理しやすい |
| 検索 | 外部ベクトルDBへ問い合わせ | Cosmos DB for NoSQLでVectorDistanceを使って検索 |
| 運用 | DB、検索、同期基盤を別々に監視 | Cosmos DB側のRU、インデックス、パーティション設計が重要 |
| 注意点 | 外部DBのコスト・整合性 | Cosmos DBの制限、インデックス設計、移行計画 |
つまり、「専用ベクトルDBが不要になる」と単純に考えるより、Cosmos DB上の業務データをAI検索・RAGに近づける選択肢が増えたと捉えるのが現実的です。
影響を受ける対象者
Integrated Vector Databaseの影響が大きいのは、次のような管理者・開発者です。
| 対象者 | 確認すべき理由 |
|---|---|
| Azure Cosmos DB for NoSQLの管理者 | アカウント機能、スループット、インデックス、パーティション設計が検索性能とRUに直結する |
| RAGアプリ開発者 | 埋め込みの保存先、検索クエリ、プロンプトへの渡し方を見直す必要がある |
| 外部ベクトルDBを併用しているチーム | 同期処理や二重管理をCosmos DBへ集約できるか検討できる |
| 生成AI基盤のアーキテクト | AI Search、専用ベクトルDB、Cosmos DB内蔵検索の使い分けが必要になる |
| Cosmos DB for PostgreSQL利用者 | サービスの退役パスを踏まえた移行判断が必要になる |
一方で、全文検索、ランキング、検索UI、フィルター条件、アクセス制御、既存の検索基盤が複雑に絡むシステムでは、Azure AI Searchなどの検索専用サービスと比較検討すべきです。Cosmos DBのベクトル検索は強力ですが、すべての検索要件を置き換える前提で進めると、後から設計変更が大きくなります。
Azure Cosmos DB for NoSQLで利用できる主な機能
Azure Cosmos DB for NoSQLでは、ドキュメント内に通常のJSONデータと高次元ベクトルを一緒に保存できます。公式ドキュメントでは、ベクトルをドキュメントのプロパティとして格納し、flat、quantizedFlat、diskANNのインデックス方式を選べることが説明されています。さらに、WHERE句による通常のNoSQLクエリフィルターとベクトル検索を組み合わせられます。(Microsoft Learn)
代表的な検索イメージ
たとえば、商品データに説明文の埋め込みを持たせ、ユーザーの質問に近い商品を検索する場合、次のような考え方になります。
SELECT TOP 10
c.id,
c.name,
VectorDistance(c.embedding, @queryVector) AS similarityScore
FROM c
WHERE c.tenantId = @tenantId
ORDER BY VectorDistance(c.embedding, @queryVector)ここで重要なのは、TOP Nを必ず付けることです。公式ドキュメントでも、TOP Nを付けないと必要以上に多くの結果を返そうとして、RU消費とレイテンシが増える可能性があるとされています。(Microsoft Learn)
また、VECTORDISTANCE関数は2つのベクトル間の類似度スコアを返します。引数では、インデックスを使うか、ブルートフォース検索にするか、距離関数や検索リスト倍率などを指定できます。精度を上げる設定は、RUやレイテンシ増加とトレードオフになるため、本番前に実データで検証する必要があります。(Microsoft Learn)
管理者が最初に確認すべき設定
Azure Cosmos DB for NoSQLでベクトル検索を使うには、まずアカウント側で機能を有効化します。AzureポータルではCosmos DBリソースの「Features」から「Vector Search for NoSQL API」を有効化し、Azure CLIではEnableNoSQLVectorSearch capabilityを指定できます。登録は自動承認されますが、反映まで最大15分程度かかる可能性があります。(Microsoft Learn)
az cosmosdb update \
--resource-group <resource-group-name> \
--name <account-name> \
--capabilities EnableNoSQLVectorSearch管理者が確認すべきポイントは、機能をオンにできるかだけではありません。特に以下は、展開前に必ずチェックしてください。
| 確認項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| アカウント機能 | NoSQL Vector Searchが有効か | 有効化直後にデプロイして、まだ反映されていない |
| スループット | 共有スループットを使っていないか | 公式制限により、現時点では共有スループットのアカウントでベクトルインデックスと検索はサポートされない |
| コンテナー設計 | ベクトルパス、次元数、距離関数を決めているか | 後から簡単に変更できる前提で設計してしまう |
| インデックス | flat、quantizedFlat、diskANNのどれを使うか | 小規模検証の結果だけで大規模本番に展開する |
| RUとレイテンシ | 検索時と投入時のRUを測定しているか | 埋め込みの一括投入でインデックス構築時間を見落とす |
| パーティション | 検索範囲をパーティションキーやWHERE句で絞れるか | 全体検索前提になり、RUと応答時間が悪化する |
公式ドキュメントでは、quantizedFlatとdiskANNは少なくとも1,000件のベクトルが必要で、少ない場合はフルスキャンになること、flatは最大505次元、quantizedFlatとdiskANNは最大4,096次元であること、短時間に500万件を超えるような大量投入ではインデックス構築時間に注意が必要なことが示されています。さらに、コンテナーでベクトルインデックスと検索を有効化すると無効化できない点も重要です。(Microsoft Learn)
開発者が設計すべきベクトルポリシー
ベクトル検索を行うには、コンテナーにベクトルポリシーを定義します。ベクトルポリシーでは、どのプロパティにベクトルが入るのか、データ型、次元数、距離関数を指定します。対応するデータ型はfloat32、float16、int8、uint8で、距離関数はcosine、dot product、euclideanを選べます。(Microsoft Learn)
{
"vectorEmbeddings": [
{
"path": "/embedding",
"dataType": "float32",
"distanceFunction": "cosine",
"dimensions": 1536
}
]
}この設定で特に重要なのは、埋め込みモデルの次元数とCosmos DB側のdimensionsを一致させることです。たとえば、開発中に埋め込みモデルを変更すると、出力されるベクトルの次元数が変わる場合があります。そのまま投入すると検索できない、または移行時に再埋め込みが必要になる可能性があります。
float16を使うとベクトルの保存容量を削減できますが、精度低下が起きる可能性があります。公式ドキュメントでも、多くの埋め込みモデルはfloat32を使う一方、float16はストレージを50%削減できるが精度が下がる可能性があると説明されています。(Microsoft Learn)
インデックス種別の選び方
Azure Cosmos DB for NoSQLのベクトルインデックスは、ワークロードに合わせて選ぶ必要があります。単に「高速そうだからDiskANN」と決めるのではなく、データ件数、検索範囲、精度要件、RU予算で判断します。
| インデックス種別 | 向いているケース | 注意点 |
|---|---|---|
flat | 小規模で、完全な再現率を重視する検索 | 最大505次元。高次元の一般的なLLM埋め込みには合わない場合がある |
quantizedFlat | フィルターで検索対象を絞れる小〜中規模検索 | 圧縮により精度がわずかに下がる可能性がある。1,000件未満ではフルスキャンになる |
diskANN | 大規模なベクトル検索、低レイテンシ、低RUを狙う本番用途 | 近似最近傍検索なので、精度と速度の検証が必要。1,000件未満では効果を確認しにくい |
公式情報では、quantizedFlatは検索対象が50,000ベクトル以下に絞られるシナリオの目安として示され、diskANNは50,000ベクトルを超える検索範囲で特に高性能な選択肢として説明されています。ただし、これは一般的なガイドラインであり、実際の性能はシナリオごとにテストすべきとされています。(Microsoft Learn)
本番展開では、次の3つのメトリックを必ずセットで測定してください。
| 指標 | 見るべき理由 |
|---|---|
| Recall | 本当に欲しい文書・商品・FAQが上位に出ているか |
| RU消費 | クエリコストが想定内か |
| P95/P99レイテンシ | ユーザー体験やAPIタイムアウトに影響しないか |
特にRAGでは、検索結果の上位数件が回答品質を大きく左右します。平均レイテンシだけでなく、「正しい根拠が上位に来るか」を評価しないと、運用後に回答の品質問題として表面化します。
設定変更と移行で注意すべきポイント
ベクトルポリシーとベクトルインデックスは、通常のアプリ設定のように気軽に変更できるものではありません。公式ドキュメントでは、新しいパス構成の追加や削除はできる一方、既存のベクトル埋め込みポリシーやインデックス設定を直接変更することはできず、変更時は既存ポリシーやインデックスを削除して新しい構成で追加し直す必要があるとされています。(Microsoft Learn)
そのため、次のような設計ミスは避けるべきです。
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
/vector1のような仮名で本番作成する | 後から意味のあるパスに変えたくなる | /embedding、/contentVectorなど用途が分かる名前にする |
| 埋め込みモデルを未確定のまま次元数を決める | モデル変更時に再作成・再投入が必要になる | モデル、次元数、距離関数を先に固定する |
| ベクトルを配列の中にネストする | ベクトルポリシーやインデックスで使えない可能性がある | ベクトルはルート直下または明確なプロパティに置く |
| 検証データが1,000件未満 | quantizedFlatやdiskANNの効果を判断できない | 本番に近い件数で性能検証する |
| TOP句なしで検索する | RUとレイテンシが増えやすい | 必ずSELECT TOP Nを使う |
公式制限では、ワイルドカード文字や配列内にネストされたベクトルパスは、ベクトルポリシーまたはベクトルインデックスで現在サポートされていません。ドキュメント構造を柔軟にしすぎると、後から検索対象として扱えないデータが出るため、ベクトル用プロパティは最初から固定しておくのが安全です。(Microsoft Learn)
外部ベクトルDBから移行する場合の進め方
すでにPinecone、Milvus、Qdrant、Azure AI Searchなどにベクトルを持っている場合、いきなりCosmos DBへ切り替えるのは危険です。特にRAGでは、検索結果の順位が少し変わるだけで回答の根拠が変わります。
移行は次の順序で進めると失敗しにくくなります。
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 現状棚卸し | ベクトル件数、次元数、距離関数、メタデータ、フィルター条件を確認 | Cosmos DBの制限内に収まるか |
| スキーマ設計 | 元データと埋め込みを同じドキュメントに持たせるか決める | 更新頻度とドキュメントサイズを確認 |
| 新コンテナー作成 | ベクトルポリシーとインデックスを定義 | 後から変更しない前提でレビュー |
| バックフィル | 既存データから埋め込みを投入 | RU、投入速度、インデックス構築時間を見る |
| 二重書き込み | 旧ベクトルDBとCosmos DBへ同時書き込み | 差分や欠損がないか |
| シャドー検索 | 本番ユーザーには見せず、同じクエリで検索結果を比較 | Recall、順位、回答品質を比較 |
| 段階的切り替え | 一部トラフィックからCosmos DB検索へ移行 | エラー率、RU、レイテンシを監視 |
移行時に最も見落とされやすいのは、埋め込みの再生成コストです。元のベクトルDBで使っていた埋め込みモデル、前処理、チャンク分割、正規化、距離関数が分からないと、同じデータを移しても検索結果が変わります。移行前に「どのテキストから、どのモデルで、どの次元数のベクトルを作ったか」を必ず記録してください。
RAGアプリでの実装ポイント
Azure Cosmos DBのIntegrated Vector Databaseは、RAGとの相性が高い機能です。公式ドキュメントでも、Azure Cosmos DB for NoSQLを使う単純なRAGパターンとして、NoSQLベクトルインデックスの有効化、コンテナーベクトルポリシーとベクトルインデックスの設定、データ挿入、Azure OpenAI Embeddingsによる埋め込み作成、ベクトル類似検索、Azure OpenAI Completionsモデルによる回答生成が示されています。(Microsoft Learn)
実装時は、次のように責務を分けると保守しやすくなります。
| レイヤー | 役割 | 実装時の注意 |
|---|---|---|
| 取り込み | 文書、商品、FAQなどを分割して保存 | チャンクサイズとメタデータを固定する |
| 埋め込み生成 | Azure OpenAI Embeddingsなどでベクトル化 | モデル名、バージョン相当、次元数を記録する |
| 保存 | Cosmos DBに元データとベクトルを保存 | ベクトルパスを固定し、配列内に入れない |
| 検索 | VectorDistanceとWHERE句で候補を取得 | テナント、カテゴリ、公開状態などで絞り込む |
| 生成 | 検索結果をプロンプトに渡す | 根拠文書IDや更新日時も一緒に渡す |
| 評価 | 回答品質、Recall、RU、レイテンシを測る | モデル変更時に再評価する |
RAGで重要なのは、ベクトル検索だけを改善しても不十分な点です。チャンク分割が粗すぎると、検索結果に不要な文脈が混ざります。逆に細かすぎると、回答に必要な背景が欠けます。Cosmos DBに保存する時点で、sourceId、chunkId、tenantId、category、updatedAtなどのメタデータを持たせておくと、検索結果のフィルター、監査、再生成がしやすくなります。
PostgreSQL利用者は新規採用を慎重に判断する
公式のIntegrated Vector Databaseページでは、Azure Cosmos DB for PostgreSQLも対象として挙げられています。一方で、pgvectorの関連ドキュメントでは、Azure Cosmos DB for PostgreSQLは退役パスにあり、新規プロジェクトでは推奨されないと説明されています。PostgreSQLワークロードではAzure Database for PostgreSQLのElastic Clusters、NoSQLワークロードではAzure Cosmos DB for NoSQLの利用が案内されています。(Microsoft Learn)
そのため、これから新しくAIアプリやRAG基盤を作る場合、次のように判断するとよいでしょう。
| 要件 | 推奨される検討先 |
|---|---|
| JSONドキュメント中心、グローバル分散、低レイテンシが重要 | Azure Cosmos DB for NoSQL |
| PostgreSQL互換、SQL資産、Citus系の水平分散が重要 | Azure Database for PostgreSQL Elastic Clusters |
| 既存のCosmos DB for PostgreSQLを利用中 | 退役パスを踏まえた移行計画を作る |
| 検索UI、全文検索、セマンティックランキングも重視 | Azure AI Searchなど検索サービスとの併用も検討 |
「PostgreSQLでも使える」と「これから新規で選ぶべき」は別の話です。既存環境の延命ではなく、新規開発や長期運用を前提にするなら、公式の退役方針を確認したうえでサービス選定を行ってください。
本番展開前のチェックリスト
本番環境へ展開する前に、少なくとも以下を確認しておくと、後戻りのコストを減らせます。
| チェック項目 | 確認結果 |
|---|---|
| NoSQL Vector Search機能を対象アカウントで有効化した | □ |
| 共有スループットの制限に該当しないことを確認した | □ |
| 埋め込みモデル、次元数、距離関数を固定した | □ |
| ベクトルパスを配列内に置いていない | □ |
flat、quantizedFlat、diskANNの選定理由を記録した | □ |
| 1,000件未満の検証だけで性能判断していない | □ |
TOP N付きの検索クエリを使っている | □ |
| RU、P95/P99レイテンシ、Recallを測定した | □ |
| 大量投入時のインデックス構築時間を検証した | □ |
| 旧ベクトルDBからの切り戻し手順を用意した | □ |
| PostgreSQL利用時は退役パスと移行先を確認した | □ |
特に管理者と開発者で認識を合わせたいのは、ベクトル検索が「アプリ機能」ではなく「データ基盤の設計」に関わる点です。後から検索精度だけを調整するつもりでも、実際にはパーティション、RU、インデックス、データ投入方式、埋め込みモデルまで影響します。
まず何から始めるべきか
Azure Cosmos DBのIntegrated Vector Databaseを検討するなら、最初にやるべきことは本番導入ではなく、既存データの代表サンプルで小さなRAG検索を作り、Recall、RU、レイテンシを測ることです。
具体的には、FAQ、商品説明、社内文書などから数千〜数万件のチャンクを用意し、Azure Cosmos DB for NoSQLにベクトルポリシーとインデックスを設定します。そのうえで、実際のユーザー質問に近いクエリを流し、上位結果が業務的に正しいかを確認します。quantizedFlatとdiskANNの比較、WHERE句による絞り込み、TOP Nの件数変更を試すと、本番で必要なRUと応答時間の目安が見えてきます。
Integrated Vector Databaseは、Azure Cosmos DBを使っている組織にとって、RAGやAIエージェントの構成をシンプルにできる有力な選択肢です。ただし、便利さだけで進めると、インデックス変更、スループット制限、移行時の再埋め込みでつまずきます。まずは対象データ、検索要件、埋め込みモデル、インデックス種別を決め、検証環境で測定してから段階的に展開するのが最も確実です。
コメント