Integrated embeddings for Azure Cosmos DB for NoSQLとは？Azure SQL利用者も確認したい変更点

2026年6月3日に確認された「[In preview] Public Preview: Integrated embeddings for Azure Cosmos DB for NoSQL」は、Azure Cosmos DB for NoSQLで埋め込みベクトルを自動生成・維持できるようにするパブリックプレビューです。結論から言うと、RAGやセマンティック検索で必要だった「データ変更の検知」「埋め込みモデルの呼び出し」「Cosmos DBへのベクトル書き戻し」を、個別パイプラインとして作り込む負担を減らせます。ただし、これはAzure SQL本体の機能追加ではなく、Azure Cosmos DB for NoSQLの機能です。Azure SQLのデータをAI検索やRAG用にCosmos DBへ連携しているチームは、設計・運用コスト・権限設定を見直す価値があります。(Microsoft for Developers)

Azure SQLの機能ではない点を最初に確認する

今回の「Integrated embeddings for Azure Cosmos DB for NoSQL」は、名前のとおりAzure Cosmos DB for NoSQL向けの機能です。Azure SQL Database、SQL Server、Azure SQL Managed Instanceに対して、埋め込み生成機能が直接追加されるわけではありません。

そのため、Azure SQLだけで業務アプリを運用している環境では、すぐにデータベース設定を変更する必要はありません。一方で、次のような構成では影響があります。

利用パターン	影響
Azure SQLの業務データをCosmos DBへ同期し、RAG検索に使っている	既存の埋め込み生成ジョブを簡素化できる可能性がある
Cosmos DB for NoSQLをAIアプリのベクトルストアとして使っている	設定・権限・コスト・非同期処理の確認が必要
Azure SQLだけで検索・分析を完結している	今回の機能による直接的な設定変更は基本的に不要
既存のAzure FunctionsやData Factoryで埋め込みを作っている	移行候補。ただしプレビューの制約を踏まえた検証が必要

実務では「Azure SQLのデータをどこでベクトル化するか」が論点になります。トランザクション処理はAzure SQL、AI検索やエージェントの参照データはAzure Cosmos DB for NoSQL、という分離構成を採っている場合に、今回のプレビューが選択肢になります。

Integrated embeddingsで何が変わるのか

従来、Azure Cosmos DB上のデータをRAGやセマンティック検索に使うには、データ変更を検知し、Azure OpenAIなどの埋め込みモデルにテキストを送信し、生成されたベクトルをCosmos DBへ保存する処理を別途作る必要がありました。Integrated Embeddingsでは、Cosmos DBがデータ変更を検知し、指定したMicrosoft Foundryの埋め込みモデルを使って非同期にベクトルを生成し、指定したパスへ書き戻します。(Microsoft Learn)

観点	従来の構成	Integrated Embeddings利用時
データ変更の検知	Change Feed、Functions、バッチ処理などを自前で構成	Cosmos DB側が変更を検知
埋め込みモデル呼び出し	アプリやジョブがAzure OpenAIなどを呼び出す	Cosmos DBがMicrosoft Foundryのデプロイ済みモデルを呼び出す
ベクトルの保存	アプリ側でCosmos DBに書き戻す	指定したアイテム内のパスに自動保存
リトライ・スロットリング対応	実装と監視が必要	パイプライン実装は軽くなるが、モデルの制限やRU消費の監視は必要
検索処理	`VectorDistance()`などで検索	ベクトル生成後の検索方法は基本的に同じ

重要なのは、アプリの責務がゼロになるわけではない点です。データ側の埋め込み生成は簡素化されますが、ユーザーの検索文や質問文を同じモデルでベクトル化し、VectorDistance()などを使って検索する処理はアプリ側に残ることがあります。Microsoftのサンプルでも、検索クエリ文字列は同じMicrosoft Foundryの埋め込みモデルを呼び出してベクトル化しています。(Microsoft for Developers)

仕組みの中心は`embeddingSource`

Integrated Embeddingsは、コンテナーのベクトル埋め込みポリシーにembeddingSourceを追加して構成します。ここで「どの項目を埋め込み対象にするか」「どのモデルを使うか」「生成したベクトルをどこに保存するか」を定義します。(Microsoft Learn)

{
  "vectorEmbeddings": [
    {
      "path": "/embedding",
      "dataType": "float32",
      "dimensions": 1536,
      "distanceFunction": "cosine",
      "embeddingSource": {
        "sourcePaths": ["/title", "/description"],
        "deploymentName": "text-embedding-3-small",
        "modelName": "text-embedding-3-small",
        "endpoint": "https://<foundry-resource-name>.openai.azure.com/",
        "authType": "Entra"
      }
    }
  ]
}

主な設定項目は次のとおりです。

項目	確認ポイント
`sourcePaths`	埋め込みモデルへ入力するアイテム内のプロパティ。例：`/title`、`/description`
`path`	生成されたベクトルを保存するパス。例：`/embedding`
`deploymentName`	Microsoft Foundryでデプロイした埋め込みモデルのデプロイ名
`modelName`	使用する基盤モデル名
`endpoint`	Microsoft Foundryリソースのエンドポイント
`authType`	現時点では`Entra`がサポートされています

複数のsourcePathsを指定すると、文字列値が結合されて1つの入力として埋め込みモデルに送信されます。入力は1アイテムあたり8,192トークンまでで、超過分は埋め込み入力として切り捨てられます。長い文書をそのまま1アイテムに入れるより、検索単位に合わせてチャンク化しておくほうが精度とコストの両面で扱いやすくなります。(Microsoft Learn)

利用前に確認すべき前提条件

Integrated Embeddingsを試す前に、まず次の前提条件を確認します。

確認項目	内容
Azure Cosmos DB for NoSQLアカウント	既存または新規のCosmos DB for NoSQLアカウントが必要
Vector Searchの有効化	NoSQL APIのVector Search機能を有効化する
Change Feedモード	All versions and deletes change feed modeを有効化する
Microsoft Foundry	Azure OpenAI埋め込みモデルをデプロイしたFoundryリソースが必要
マネージドID	Cosmos DBアカウントにシステム割り当てまたはユーザー割り当てマネージドIDを設定し、既定IDとして構成する
RBAC	Cosmos DBのマネージドIDに、Foundryリソース上で`Cognitive Services OpenAI User`ロールを付与する
対応モデル	`text-embedding-3-large`、`text-embedding-3-small`、`text-embedding-ada-002`が対象
リージョン	段階的ロールアウト中のため、サブスクリプションやリージョンによって利用可否が異なる可能性がある
プレビュー扱い	SLAなしのプレビューであり、本番ワークロードには推奨されていない

Microsoft Learnでは、Integrated Embeddingsがプレビュー機能であり、SLAなしで提供されること、リージョンによって利用できない場合があることが明記されています。検証環境での評価を前提にし、本番投入を急がない設計が安全です。(Microsoft Learn)

管理者が見るべき設定ポイント

Vector SearchとChange Feedを先に確認する

Integrated Embeddingsは、Azure Cosmos DB for NoSQLのベクトル検索機能と組み合わせて使う前提です。Cosmos DBでは、ベクトルをドキュメント内に通常データと並べて保存し、WHERE句など既存のNoSQLクエリ条件と組み合わせて検索できます。ベクトル検索を有効化するには、AzureポータルのFeaturesから「Vector Search for NoSQL API」を有効化するか、Azure CLIでEnableNoSQLVectorSearchを指定します。(Microsoft Learn)

注意点として、ベクトル検索は一度コンテナーで有効化すると無効化できない制約があります。また、Shared Throughputアカウントではサポートされていないとされています。既存の本番コンテナーへ直接適用するのではなく、検証用アカウントまたは検証用コンテナーで挙動を確認してから判断しましょう。(Microsoft Learn)

マネージドIDとRBACを疎かにしない

Cosmos DBがMicrosoft Foundryの埋め込みモデルを呼び出すため、Cosmos DBアカウントのマネージドIDを既定IDとして設定し、Foundryリソース側でCognitive Services OpenAI Userロールを付与する必要があります。ここが不足していると、ポリシーが正しく見えても埋め込みが生成されません。(Microsoft Learn)

開発者が管理SDKを使って検証する場合は、スクリプト実行者にもCosmos DB OperatorやCosmos DB Built-in Data Contributorなどの権限が必要になるケースがあります。環境ごとに「Cosmos DBを構成する権限」と「データを読み書きする権限」を分けて棚卸ししておくと、CI/CDや本番展開で詰まりにくくなります。(Microsoft Learn)

ポータルだけで完結しない点に注意する

現時点では、コンテナーのベクトルポリシー自体はAzureポータルで管理できても、embeddingSourceの構成はポータルで未対応です。SDKを使った設定が必要で、Azure CLI、ARM、Bicepなどの対応は今後拡充される予定とされています。(Microsoft Learn)

運用チームがIaCを必須にしている場合は、プレビュー段階で既存のデプロイ標準に乗せられるかを先に確認してください。手動SDK実行だけで本番相当の構成を作ると、後から環境差分の追跡が難しくなります。

開発者が設計で注意すべきポイント

`sourcePaths`には「意味を表す安定した項目」を選ぶ

sourcePathsに指定する項目は、検索したい意味をよく表すテキストに絞るのが基本です。商品検索なら/titleと/description、FAQ検索なら/questionと/answer、文書検索ならチャンク化済みの/contentなどが候補になります。

逆に、在庫数、価格、一時的なステータス、更新日時などを含めると、意味検索の精度に寄与しにくいだけでなく、値の変更が多い場合に再埋め込みの頻度が増えます。埋め込み対象は「検索意図に効く項目か」「頻繁に変わりすぎないか」「機密情報を含まないか」の3点で選ぶと失敗しにくくなります。

埋め込み生成は非同期である

Integrated Embeddingsは、アイテムの書き込みや更新を検知して非同期に埋め込みを生成します。つまり、アイテムを保存した直後に必ず/embeddingが存在するとは限りません。Microsoftのクイックスタートでも、アイテム挿入後に埋め込みが書き戻されるまでポーリングする流れが示されています。(Microsoft Learn)

検索APIを作る場合は、次のような対策を入れておくと安全です。

IS_DEFINED(c.embedding)のような条件で、埋め込み済みデータだけを検索対象にする
新規登録直後のデータはキーワード検索にフォールバックする
管理画面で「検索反映待ち」の状態を表示する
バックログが溜まった場合に、Foundryのモデルクォータ、Cosmos DBのRU、書き込み量を確認する

Microsoft Learnのトラブルシューティングでも、埋め込みプロパティが欠ける場合、Cosmos DB側の処理待ち、ポリシー不一致、生成失敗、sourcePathsの欠損や空値などを確認するよう案内されています。(Microsoft Learn)

クエリ側の埋め込み生成は別途考える

Integrated Embeddingsが自動化するのは、主にCosmos DB内のアイテムに対する埋め込み生成です。ユーザーが入力した検索文や質問文をベクトル化する処理は、アプリケーション側で同じ埋め込みモデルを呼び出す構成になることがあります。

例えば、ECサイトで「冬山で暖かく過ごせるもの」と検索された場合、アプリはその検索文を埋め込みモデルでベクトル化し、Cosmos DB内の商品説明ベクトルと近いものを検索します。完全一致キーワードだけでは「防寒グローブ」「スキー用ジャケット」「寒冷地用寝袋」などを拾いきれないため、ベクトル検索の価値が出ます。

ハイブリッド検索も検討する

純粋なベクトル検索は意味の近さに強い一方、型番、製品名、SKU、エラーコードのような完全一致が重要な検索では弱くなることがあります。Azure Cosmos DB for NoSQLでは、ベクトル類似度と全文検索を組み合わせるハイブリッド検索もサポートされており、必要に応じてWHERE句でカテゴリやタグを絞り込めます。(Microsoft for Developers)

実務では、次のように使い分けるとよいでしょう。

検索ニーズ	推奨アプローチ
「意味が近い情報」を探したい	ベクトル検索
型番、注文番号、エラーコードを探したい	キーワード検索・完全一致
意味もキーワードも重要	ハイブリッド検索
カテゴリや権限で検索範囲を制限したい	`WHERE`句やパーティション設計と併用

移行時の注意点

既存パイプラインはすぐ停止しない

すでにAzure Functions、Data Factory、Container Apps、GitHub Actionsなどで埋め込み生成パイプラインを運用している場合、Integrated Embeddingsへ一気に切り替えるのは避けたほうが安全です。プレビュー機能であることに加え、既存の検索結果と新しいベクトル生成結果が完全に同じになるとは限りません。

おすすめは、既存の/embeddingとは別に/embedding_previewのような検証用パスを用意するか、検証用コンテナーを作成して比較する方法です。検索上位10件、クリック率、回答生成の根拠、RU消費、生成待ち時間を比較し、品質基準を満たしてから切り替えを検討します。

既存データのバックフィルを設計する

Integrated Embeddingsはデータ変更を検知して埋め込みを生成します。既存の大量データをどう埋め込み済みにするかは、検証環境で必ず確認してください。必要に応じて、対象アイテムを段階的に再upsertする、移行用コンテナーへコピーする、バッチ単位で検証するなどのバックフィル手順を設計します。

特に数百万件規模のデータでは、Foundry側のモデルクォータ、Cosmos DBのRU、ベクトルインデックス構築時間がボトルネックになります。Microsoftのパフォーマンスガイドでも、埋め込みモデル、次元数、インデックス種別、パーティション設計、スループット、取り込み方式、クエリ時のチューニングを順に検討することが推奨されています。(Microsoft Learn)

コストは「機能料金ゼロ」だけで判断しない

Integrated Embeddings自体は追加料金なしで利用できるとされています。ただし、Microsoft Foundryの埋め込みモデル推論には課金が発生し、Cosmos DB側でもChange Feedの読み取りや生成ベクトルの書き戻しでRUを消費します。(Microsoft Learn)

つまり、運用パイプラインの開発・保守コストは下がる可能性がありますが、推論コストとRUコストが消えるわけではありません。頻繁に更新される項目をsourcePathsに入れると、再埋め込みが増えてコストが膨らみます。検証では、少なくとも次の数値を記録してください。

測定項目	見る理由
1日あたりの対象アイテム更新数	再埋め込み回数に直結する
1アイテムあたりの平均入力トークン数	Foundry推論コストに影響する
埋め込み生成完了までの時間	検索反映の遅延を評価する
Cosmos DBのRU消費	Change Feed読み取りと書き戻しの負荷を見る
モデルのレート制限到達回数	バックログ発生の原因を切り分ける

採用判断の目安

Integrated Embeddingsは、すべての環境で今すぐ置き換える機能というより、AIアプリ開発の構成を簡素化するための有力なプレビューです。採用判断は次のように整理できます。

判断	向いているケース
試す価値が高い	新規のRAGアプリ、非本番環境、既存パイプラインの保守が重い、Cosmos DBをベクトルストアとして使う予定がある
慎重に検証	既存パイプラインが安定している、検索品質の差分が業務影響に直結する、データ件数が多い
まだ待つべき	本番SLAが必須、ポータルやBicepだけで構成管理したい、Shared Throughputを使っている、リージョンで未提供

Azure SQL利用者にとっての判断基準は、「Azure SQLのデータをAI検索用にCosmos DBへ持たせる必然性があるか」です。既存のSQL検索で十分な業務に無理に導入する必要はありません。一方、自然文検索、社内ナレッジ検索、FAQ自動応答、エージェントの長期記憶などを構築する場合は、Cosmos DB側で埋め込みを同期できるメリットがあります。

展開前チェックリスト

本番相当環境へ近づける前に、次の順で確認すると抜け漏れを減らせます。

順番	確認内容
1	今回の対象がAzure SQLではなくAzure Cosmos DB for NoSQLであることを関係者に共有する
2	対象リージョンとサブスクリプションでプレビューが利用可能か確認する
3	Vector SearchとAll versions and deletes change feed modeを有効化する
4	Microsoft Foundryに対応する埋め込みモデルをデプロイする
5	Cosmos DBアカウントのマネージドIDを既定IDとして設定する
6	Foundryリソースで`Cognitive Services OpenAI User`を付与する
7	`sourcePaths`、保存先パス、次元数、距離関数、ベクトルインデックスを設計する
8	SDKで検証用コンテナーを作成し、少量データで生成完了を確認する
9	クエリ側の埋め込み生成、ベクトル検索、ハイブリッド検索を試す
10	RU、推論コスト、生成遅延、検索品質を既存構成と比較する
11	既存パイプラインとの二重書き込みや競合を避ける切り替え手順を作る
12	プレビュー制約を踏まえ、本番適用可否を判断する

よくある疑問

Azure SQLの設定変更は必要ですか？

Azure SQL本体に対する直接の設定変更は不要です。今回の機能はAzure Cosmos DB for NoSQLの機能です。ただし、Azure SQLのデータをCosmos DBへ同期してAI検索に使っている場合は、埋め込み生成パイプラインの見直し対象になります。

これで埋め込み生成ジョブは完全に不要になりますか？

データ側の埋め込み生成ジョブは簡素化できる可能性があります。ただし、検索クエリ側のベクトル化、検索API、品質評価、監視、コスト管理は引き続き必要です。

本番環境で使えますか？

現時点ではプレビュー機能であり、SLAなしで提供され、本番ワークロードには推奨されていません。まずは検証環境で、既存検索との品質差分、生成遅延、コスト、障害時の挙動を確認してください。(Microsoft Learn)

埋め込みが生成されない場合は何を見ればよいですか？

まず、Integrated Embeddingsが有効か、コンテナーのベクトル埋め込みポリシーにembeddingSourceが含まれているか、アイテムにsourcePathsで指定したプロパティが存在し、空またはnullでないかを確認します。生成が遅い場合は、Cosmos DBの処理待ち、RU不足、アイテムサイズ、Foundryモデルのクォータやレート制限も確認します。(Microsoft Learn)

まずは小さく検証し、Azure SQL連携の役割分担を見直す

Integrated embeddings for Azure Cosmos DB for NoSQLは、Azure上でRAGやセマンティック検索を作る際の埋め込み同期を大きく簡素化できる機能です。特に、Azure SQLの業務データをCosmos DBへ連携し、AIアプリの検索基盤として使っているチームには、既存パイプラインの削減余地があります。

ただし、プレビュー段階であること、Azure SQL本体の機能ではないこと、ポータルやIaC対応に制約があること、推論コストとRU消費が発生することは押さえておく必要があります。まずは検証用コンテナーで少量データを使い、埋め込み生成、検索精度、反映遅延、コストを測定しましょう。そのうえで、Azure SQLはトランザクションの正本、Azure Cosmos DB for NoSQLはAI検索・RAG向けのベクトルストア、という役割分担が自社の要件に合うかを判断するのが現実的です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Integrated embeddings for Azure Cosmos DB for NoSQLとは？Azure SQL利用者も確認したい変更点

Azure SQLの機能ではない点を最初に確認する

Integrated embeddingsで何が変わるのか

仕組みの中心は`embeddingSource`

利用前に確認すべき前提条件