Azure Cosmos DB for NoSQLとは｜API選定・RU料金・整合性・ベクトル検索

Azure Cosmos DBは、6種類のAPIから1つを選ぶ設計になっているうえに、課金がインスタンスサイズではなくRU（要求ユニット）／秒と消費ストレージの2つのメーターで決まります。そのため「とりあえず作ってみる」と、あとから変更できないAPIとパーティションキーを抱えたまま運用に入ってしまいがちです。この記事では、NoSQL用APIを軸に、API選定・課金モデル・整合性レベル・パーティション設計・ベクトル検索の実装を、Microsoft Learnに記載された数値をそのまま示しながら順に整理します。

まとめ

• 新規開発で迷ったらNoSQL用APIを選びます。公式ドキュメントも、ドライバーの柔軟性とグローバルスケールが要るシナリオではNoSQL用ネイティブAPIを使うよう明示しています。
• 2025年11月18日に、旧Azure Cosmos DB for MongoDB（仮想コア）はAzure DocumentDBとして分離しました。MongoDB互換を仮想コア課金で使いたい場合の選択肢はCosmos DBの外に移っています。
• 課金はRU/秒。手動プロビジョニングの下限は400 RU/秒、自動スケールは最大値1000 RU/秒からで、サーバーレスは使った分だけです。ライフタイム無料レベルは1000 RU/秒と25 GBまで無償です。
• 整合性は5段階。強力と有界整合性制約は4レプリカ中2つから読むため、同じRU数で得られる読み取りスループットが他の3レベルの半分になります。
• 論理パーティションは20 GB、パーティションあたりのスループットは10,000 RU/秒が上限です。この2つに当たる設計は、あとから階層パーティションキーで作り直すことになります。
• ベクトル検索は機能を有効化してコンテナー作成時にベクトルポリシーを定義します。検索対象が5万ベクトルを超えるならdiskANN、それ以下ならquantizedFlatが目安です。
• 運用データの分析はMicrosoft Fabricへのミラーリングで切り出します。Azure Synapse Linkは新規プロジェクトではサポート対象外と公式が明記しているため、選んではいけません。

Azure Cosmos DBの基本仕様とAzure DocumentDBの分離

フルマネージドNoSQLとベクトルデータベースの二面性

Azure Cosmos DBは、ドキュメント・キー値・グラフ・テーブル・ベクトルのデータモデルを1つのサービスで扱うフルマネージドデータベースです。公式ドキュメントは応答時間を「1桁ミリ秒」、マルチリージョン構成の可用性SLAを99.999%と記載しています。待ち時間については、読み取り・書き込みとも99パーセンタイルで10ミリ秒未満が保証値です。50パーセンタイルの平均は読み取りが通常4ミリ秒以下、書き込みが通常5ミリ秒以下とされていますが、こちらは保証値ではなく実測の目安と読んでください。

概要ページ（2026年2月更新）が冒頭で掲げているのが、ベクトルデータベースとしての役割です。埋め込みベクトルを元データと同じドキュメント内に持てるため、RAGやAIエージェントで専用のベクトルストアを別に用意してデータを二重管理する必要がありません。後述するDiskANNベースのインデックスは、この用途のために組み込まれています。

Azure DocumentDBの独立で変わった選択肢

ここは2026年時点で最も誤解しやすい変更点です。仮想コア課金だった旧Azure Cosmos DB for MongoDB（vCore）は、2025年11月18日のIgnite 2025でAzure DocumentDBとして独立しました。Linux Foundation配下のオープンソースDocumentDBプロジェクトに名称を揃えたもので、既存クラスターはポータル上で自動的に新名称へ切り替わっています。一方、RU課金のMongoDB用APIはCosmos DB側に残っているため、「MongoDB互換＝Cosmos DB」という以前の理解のままだと選定を誤ります。

判断は単純です。MongoDBの集計パイプライン忠実度やマルチクラウド可搬性が要件でなければCosmos DBを選び、要件であればAzure DocumentDBを選びます。公式ドキュメントも同じ切り分けを推奨しています。

6種類のAPIと選定基準

新規開発でNoSQL用APIが既定になる理由

Cosmos DBはNoSQL、MongoDB、Apache Cassandra、Apache Gremlin、Table、PostgreSQLの6つのAPIを提供します。APIはアカウント作成時に決まり、あとから別のAPIへ切り替えることはできません。ここでNoSQL用APIを推す理由は好みではなく、機能の到達順です。ベクトル検索や、NoSQL用APIのクエリエディター限定で提供されるMicrosoft Copilot for Azure in Cosmos DB（プレビュー）のような新機能はNoSQL用APIに最初に実装され、SDKも.NET・Java・JavaScript・Python・Go・Rustと最も広く揃っています。公式ドキュメントも、ドライバーの柔軟性とグローバルスケールが必要なほとんどの新規シナリオではNoSQL用ネイティブAPIを使い、Azure DocumentDBは必要な場合にのみ選ぶよう明記しています。

NoSQL用APIのデータ操作はSQLライクな構文で書けます。実際のCRUDの書き方はAzure Cosmos DBで行うCRUD操作：データの挿入・取得・更新・削除の方法で扱っているため、本記事では設計判断に絞ります。

既存資産を移行する場合のAPI対応

他のAPIを選ぶ動機は、ほぼ既存アプリの移行に限られます。ワイヤプロトコル互換なので、接続文字列の差し替えだけでアプリケーションのコードを大きく変えずに移せる点が価値です。

なお整合性レベルの扱いはAPIごとに異なります。GremlinとTable用APIはアカウントに設定した既定の整合性レベルをそのまま使い、MongoDB用APIとCassandra用APIはそれぞれのマッピング表に従います。

RU課金の3モデルと無料枠

プロビジョニング済み・自動スケール・サーバーレスの分岐

Cosmos DBの費用は、データベース操作に対するRU/秒と、データとインデックスが消費したストレージ（GB）の2つのメーターで決まります。金額の大半を占めるのはRU/秒側で、3つのモデルをワークロードの変動幅で選び分けます。

• 手動プロビジョニング：常時ほぼ一定の負荷向け。下限は400 RU/秒です。負荷が読めているなら、確保量を固定できるこのモデルが無駄になりません。
• 自動スケール：設定した最大RU/秒（Tmax）に対し、0.1×Tmaxから自動で上下します。課金は1時間ごとに、その時間内でスケールした最大RU/秒か0.1×Tmaxの高い方です。つまり全く使わない時間帯でも最大値の10%は課金されます。
• サーバーレス：消費したRUだけの従量課金。開発環境や散発的なアクセスに向きますが、リージョンは1つに限定されます。

1つ注意が要るのは、データベースレベルでコンテナー間にRU/秒を分け合う「共有スループット」構成です。この構成では後述のベクトルインデックスと検索がサポートされません。ベクトル検索を使う予定があるなら、専用スループット（手動・自動スケール）かサーバーレスを選んでください。

コンテナーの上限は1,000,000 RU/秒で、サポートリクエストで引き上げられます。1年または3年のコミットで予約容量を購入すると、最大63%の割引が適用されます。

最小RU/秒がストレージとスケール履歴で上がる仕組み

見落としやすいのが、最小RU/秒はデータ量と過去のスケール履歴で上がっていく点です。一度大きくスケールさせると、縮小しても下限が戻りません。

同じ条件でストレージが2000 GBまで増えると、手動は2000 RU/秒、自動スケールは20,000 RU/秒が下限になります。データが増えるほど最低料金が上がる構造だと理解しておくと、見積もりが崩れません。

ライフタイム無料レベルとAzure無料アカウントの使い分け

無償で試す経路は3つあります。ライフタイム無料レベルは1000 RU/秒と25 GBまでがアカウントの生存期間中ずっと無料ですが、Azureサブスクリプションあたり1アカウントのみ、かつアカウント作成時にオプトインが必要です。Azure無料アカウントでは30日間200ドルのクレジットに加え、12か月間400 RU/秒と25 GBが使えます。課金なしで開発だけ進めたい場合は、ローカルで動くエミュレーターが確実です。手順はAzure Cosmos DB エミュレーターを使ったローカル開発の全体像にまとめています。

整合性レベル5段階が読み取りコストに与える影響

5つのレベルの保証内容

多くの分散NoSQLが強力と最終的の2択なのに対し、Cosmos DBは5段階を用意しています。強い順に並べると次のとおりです。

RPOはいずれもリージョンが2つ以上ある場合の値です。単一リージョンアカウントでは、整合性レベルによらず240分未満とされています。

有界整合性制約のKとTには下限があります。単一リージョンアカウントでは10回の書き込みまたは5秒、複数リージョンアカウントでは100,000回の書き込みまたは300秒です。ここより短い遅延は設定できません。

強力と有界整合性制約で読み取りRUが2倍になる仕組み

整合性の選択はコストに直結します。強力と有界整合性制約は、保証のために4レプリカセットのうち2つのレプリカから読む必要があり、公式ドキュメントは「同じ要求ユニット数に対して、厳密と有界整合性制約の読み取りスループットは他の整合性レベルの半分になる」と明記しています。裏を返せば、同じ読み取り量をさばくのに倍のRUが要るということです。書き込み側のRU消費は、どのレベルでも変わりません。

既定にセッションが推奨されるのは、この費用対効果の釣り合いが良いためです。セッションは単一レプリカ読み取りなので最終的整合性と同等のスループット・待ち時間を保ちながら、「自分が書いた内容を自分は必ず読める」という、ユーザー単位で動くアプリケーションが実際に必要とする保証を満たします。

強力を選ぶ前に確認すべき制約が2つあります。複数の書き込みリージョンを持つアカウントでは強力を使用できません。もう1つは距離です。5,000マイル（8,000キロメートル）を超えて離れたリージョンにまたがるアカウントでは、書き込み待ち時間が99パーセンタイルで最遠2リージョン間のラウンドトリップ時間の2倍＋10ミリ秒になるため、強力は既定でブロックされています（サポートへ問い合わせれば有効化自体は可能です）。グローバル分散と強い整合性は両立しない、と割り切って設計するほうが安全でしょう。

論理パーティション20 GB制限を前提としたデータ設計

パーティションと項目の上限値

Cosmos DBの設計で最初に効いてくるのが、後から変えにくい制限値です。運用で当たりやすいものを挙げます。

コンテナー全体のストレージは無制限ですが、論理パーティション単位では20 GBで頭打ちになります。テナントIDのようにカーディナリティが低いキーを選ぶと、特定テナントのデータが増えた時点でその論理パーティションだけが上限に達し、書き込みが止まってしまいます。ID値のほうにも落とし穴があります。サービス側は「/」と「\」以外のUnicode文字を許可しますが、公式ドキュメントは相互運用性の観点から英数字のASCII文字のみを強く推奨しています。Azure Data FactoryやSpark、Kafkaのコネクタで処理が失敗する既知の制限があるためです。

階層パーティションキーと合成パーティションキーの使い分け

20 GBに当たったときの正攻法は、階層パーティションキー（サブパーティション）です。最大3階層のキーを設定でき、第1階層のキーに対して20 GBを超えるデータを持てます。マルチテナントSaaSのように「テナントID配下がいくらでも増える」構造では、テナントID・ユーザーID・日付のように階層化するのが定石です。

もう一つの手が合成パーティションキーで、複数のプロパティを連結した値を人工的に作ってカーディナリティを上げます。既存アプリを大きく変えずに分散を改善したい場合に向きます。

Azureサポートに申請すれば論理パーティションの上限を一時的に引き上げられますが、これは再設計までの時間を稼ぐための緩和策です。公式ドキュメントは、上限が引き上げられている間はSLAの保証が適用されないと明記しています。恒久策として使ってはいけません。

Cosmos DB for NoSQLのベクトル検索実装

機能の有効化とベクトルポリシーの定義

ベクトル検索は既定では無効です。ポータルの「設定」から「機能」を開き、「Vector Search for NoSQL API」を有効化するか、Azure CLIで機能を追加します。登録要求は自動で適用されますが、反映まで最大15分かかります。

az cosmosdb update \
     --resource-group <resource-group-name> \
     --name <account-name> \
     --capabilities EnableNoSQLVectorSearch

次に、コンテナー作成時にベクトルポリシーを定義します。ここで指定した次元数・データ型・距離関数は、あとから直接変更できません。変更するにはポリシーやインデックスをいったん削除して追加し直す必要があるため、埋め込みモデルを決めてから作成してください。既定の次元数は1536です。Azure OpenAIのtext-embedding-ada-002の出力次元と同じ値のため、そのまま使えるケースが多い数字になっています。

{
    "vectorEmbeddings": [
        {
            "path": "/contentVector",
            "dataType": "float32",
            "distanceFunction": "cosine",
            "dimensions": 1536
        }
    ]
}

データ型はfloat32、float16、int8、uint8から選べます。float16にするとベクトルのストレージ使用量を約50%削減できる代わりに、精度が落ちる可能性があります。距離関数はcosine（既定）、dotproduct、euclideanの3つで、埋め込みモデルが推奨する指標に合わせてください。

flat・quantizedFlat・diskANNのインデックス選定

ベクトルインデックスは3種類あり、次元数の上限と得意な規模が違います。

flatは再現率100%を保証できる代わりに505次元までしか扱えません。text-embedding-3-largeの3072次元やada-002の1536次元を使う時点で、選択肢はquantizedFlatかdiskANNの2つに絞られます。公式ドキュメントは、検索対象が5万ベクトルを超える場合はdiskANNが全インデックス種別の中で最も高速だとしています。

ここに落とし穴が1つあります。quantizedFlatとdiskANNは、量子化の精度を担保するために最低1,000個のベクトルがインデックスされている必要があり、それ未満だとフルスキャンにフォールバックしてRU料金がかえって高くつきます。少量データでの性能検証が本番と乖離するのは、たいていこれが原因です。

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [ { "path": "/*" } ],
    "excludedPaths": [
        { "path": "/_etag/?" },
        { "path": "/contentVector/*" }
    ],
    "vectorIndexes": [
        { "path": "/contentVector", "type": "diskANN" }
    ]
}

このJSONの前半は、ベクトル専用ではなく通常のインデックス作成ポリシーです。Cosmos DBは既定で全プロパティに自動インデックスを張る（automatic: true、includedPaths が /*）ため、インデックス対象が増えるほど書き込みRUも増えます。使わないパスを excludedPaths に落とすのがRU最適化の定石で、ベクトルのパスは特にここへ入れておきます。除外しないと高次元配列にまで自動インデックスが走り、書き込みRUを無駄に消費するためです。なお複合インデックスは最大8プロパティ・最大100パスまで定義できます。

VectorDistanceによるクエリと運用上の制約

検索はVectorDistanceシステム関数で行います。SELECT句のTOP Nは必須と考えてください。公式ドキュメントは、TOPを付けないとベクトル検索が大量の結果を返そうとし、クエリのコストと待ち時間が必要以上に増えると警告しています。

SELECT TOP 10 c.title, VectorDistance(c.contentVector, [1,2,3]) AS SimilarityScore
FROM c
ORDER BY VectorDistance(c.contentVector, [1,2,3])

ベクトル検索はWHERE句の通常のフィルターと組み合わせられます。テナントIDやカテゴリで絞ってからベクトル距離で並べると、検索対象が縮んで精度もコストも改善します。RAGの実装ではこの併用が効きます。

採用前に確認すべき制約は次の4つです。共有スループットのアカウントはベクトルインデックスと検索の対象外です。ワイルドカード（*、[]）や配列内に入れ子になったベクトルパスも指定できません。コンテナーでベクトルインデックスと検索を有効にした場合、あとから無効化する手段はありません。最後に、500万を超えるベクトルを短時間で投入するとインデックス作成に追加の時間がかかるため、初期ロードの計画に織り込んでおいてください。

AIエージェントからCosmos DBを操作する構成を検討している場合は、Azure CosmosDB MCPサーバを使ったセットアップの完全手順ガイドが接続部分の実装を扱っています。

Cosmos DBを選ぶべきでない条件

ここは玉虫色にせず言い切ります。公式ドキュメント自身が、適合が不十分なアプリケーションとして2種類を挙げています。

分析ワークロード（OLAP）でRUが溶ける理由

対話型分析やストリーミング分析、一括分析を主目的にするなら、公式は代替としてMicrosoft Fabricを検討するよう明記しています。Cosmos DBはポイント読み取りと分散クエリに最適化されているため、全件スキャンを伴う集計はRUを大量に消費するからです。運用データの分析が必要なら、Microsoft Fabricへのミラーリングで分析側へ切り出す構成が前提になります。

ここは情報が古いまま出回っている領域なので、はっきり書きます。従来の選択肢だったAzure Synapse Linkは、公式ドキュメント（2025年12月更新）で「新しいプロジェクトではサポートされなくなりました。この機能は使用しないでください」と名指しで案内されており、GA済みのFabricミラーリングへの移行が推奨されています。新規構成で選んではいけません。

結合が多いリレーショナル設計を避けるべき条件

ホワイトラベルのCRMのように結合が多い設計は、Azure SQL DatabaseやAzure Database for MySQLのほうが素直です。誤解されやすいのですが、NoSQL用APIのJOINは同一項目内の配列を展開する自己結合で、コンテナーやドキュメントをまたぐ結合はそもそもできません。1クエリあたり10個という制限（サポート申請で引き上げ可）以前に、多重結合を想定した作りではないということです。

グラフ走査が主体で、関係そのものを検索したいケースも別の判断になります。Gremlin用APIやAI Graphの構成はAzure Cosmos DB AI Graphとは何か？その概要と特徴で扱っています。

よくある質問

Azure Cosmos DBとは何ですか

Microsoftが提供するフルマネージドの分散NoSQLデータベースサービスです。ドキュメント・キー値・グラフ・テーブル・ベクトルのデータモデルを1つのサービスで扱い、複数リージョン構成では99.999%の可用性SLAが適用されます。サーバー管理やパッチ適用、インデックスの手動メンテナンスは不要で、スループットとストレージはリージョンごとに独立して伸縮できます。

Azure Cosmos DBは無料で使えますか

ライフタイム無料レベルを使えば、1000 RU/秒と25 GBまで無料です。注意点は申し込みのタイミングで、Azureサブスクリプションあたり1アカウントのみ、かつアカウント作成時にオプトインしないと後から切り替えられません。作成済みのアカウントを無料レベルへ変更する手段は無いということです。

NoSQL用APIとMongoDB用APIはどちらを選ぶべきですか

新規開発ならNoSQL用APIです。判断が割れるのは、仮想コア課金でMongoDB互換を使いたい場合でしょう。その提供は2025年11月18日にAzure DocumentDBとして分離しているため、選定先はCosmos DBの外になります。Cosmos DB側に残っているMongoDB用APIはRU課金で、既存のMongoDBアプリをRUモデルに載せたいときの選択肢です。いずれにせよAPIはアカウント作成後に変更できません。

既存のコンテナーにあとからベクトルポリシーを追加できますか

部分的にできます。公式ドキュメントによると、新しいパス構成の追加や既存パス構成の削除は可能ですが、ベクトル埋め込みポリシーやベクトルインデックス作成ポリシーの設定値そのものを直接変更することはできません。次元数や距離関数を変えたい場合は、いったん削除してから新しい構成で追加し直す形になります。埋め込みモデルを途中で乗り換える可能性があるなら、コンテナーを分ける前提で設計しておくほうが安全です。

整合性レベルはあとから変更できますか

できます。アカウントの既定の整合性レベルはいつでも構成でき、変更するとそのアカウント配下の全データベースとコンテナーに適用されます。ただし公式ドキュメントは、変更後にアプリケーションを再デプロイしてSDKインスタンスを再作成するよう求めています。SDKが古い既定値を保持したままだと反映されないためです。特定のリクエストだけ既定より弱いレベルへ上書きすることも可能で、この場合は単一レプリカからの読み取りになります。変更できないのはAPIの種類とコンテナーのパーティションキーのほうです。

関連記事

• Azure Cosmos DB エミュレーターを使ったローカル開発の全体像
• Azure Cosmos DBで行うCRUD操作：データの挿入・取得・更新・削除の方法
• Azure CosmosDB MCPサーバを使ったセットアップの完全手順ガイド
• Azure Cosmos DB AI Graphとは何か？その概要と特徴