Azure Cosmos DBとは？料金の目安・RU課金・API選定と設計の注意点

Azure Cosmos DBは、Microsoftが提供するフルマネージドの分散NoSQLデータベースです。使い始める前に決めておくことが3つあります。6種類のAPIのどれを使うか、パーティションキーを何にするか、RU（要求ユニット）をどの方式で確保するかです。APIとパーティションキーはあとから変えられず、RUの確保方式で月額は数倍変わります。この記事では、東日本リージョンの現行単価で月額を試算しながら、API選定・整合性レベル・パーティション設計・主要機能・RDBやDynamoDBとの違いを、Microsoft Learnの数値で整理します。

まとめ

• 新規開発ならNoSQL用APIを選びます。ベクトル検索などの新機能はNoSQL用APIに先に入ります。
• 料金の大半はスループット（RU）とストレージです。東日本リージョンの単一書き込み構成では、手動プロビジョニングが100 RU/秒あたり0.009ドル/時、ストレージが1 GBあたり月0.2825ドルです（2026年11月、Azure Retail Prices API）。最小の400 RU/秒ならRU部分だけで月約26ドル、ストレージ10 GBを足すと月約29ドルです。
• ライフタイム無料レベルなら1000 RU/秒と25 GBまで無料です。アカウント作成時にしか選べず、サーバーレスには使えません。
• 整合性は5段階です。強力と有界整合性制約は、同じRUで得られる読み取りスループットが他の3レベルの半分になります。
• 論理パーティションは20 GB・10,000 RU/秒が上限です。テナントIDのような偏るキーは、階層パーティションキーで最初から割っておきます。
• 仮想コア課金のMongoDB互換は2025年11月18日にAzure DocumentDBへ分離しました。Cosmos DB for PostgreSQLも新規プロジェクトには推奨されていません。
• 集計・分析が主目的なら、Cosmos DBではなくMicrosoft Fabricへのミラーリングで切り出します。Azure Synapse Linkは新規プロジェクトでは使えません。

Azure Cosmos DBの仕組みとリソースの4階層

NoSQLデータベースとしての位置づけとSLA

Cosmos DBはドキュメント・キー値・グラフ・テーブル・ベクトルのデータを1つのサービスで扱います。「SQLかNoSQLか」と聞かれれば、NoSQLです。NoSQL用APIでSQLに似た構文のクエリを書けるため混同されますが、スキーマを持たないJSONドキュメントを格納する非リレーショナルなデータベースです。

公式の整合性レベルのドキュメントによると、待ち時間の保証値は読み取り・書き込みとも99パーセンタイルで10ミリ秒未満です。ただし、複数リージョンにまたがるアカウントで「強力」の整合性を使う書き込みは例外で、リージョン間の距離に応じて長くなります。50パーセンタイルで読み取り4ミリ秒以下・書き込み5ミリ秒以下という数字も載っていますが、こちらは保証値ではなく目安です。可用性SLAは最大99.999%で、これは複数の書き込みリージョンを持つ構成などに適用される値です。

アカウント・データベース・コンテナー・項目の関係

Cosmos DBのリソースは4階層です。RDBの用語に置き換えると全体像がつかみやすくなります。

RDBのテーブルと違い、コンテナーにはスキーマがありません。同じコンテナーに形の違う項目を混在させられます。課金と性能に直結するスループット（RU/秒）はコンテナー単位かデータベース単位で設定するので、「コンテナーとは何か」は「パーティションキーとRUを持つ箱」と覚えるのが実務的です。階層の詳細はリソースモデルのドキュメントにあります。

グローバル分散とマルチリージョン書き込み

アカウントにはAzureのリージョンを後から追加・削除でき、データは追加したリージョンへ自動で複製されます。書き込みを1リージョンに集める構成のほか、全リージョンで書き込みを受けるマルチリージョン書き込みも選べます。

注意点は料金と整合性です。マルチリージョン書き込み用のRUは、東日本リージョンで100 RU/秒あたり0.018ドル/時と、単一書き込みリージョンの2倍の単価です。後述する「強力」の整合性レベルも、複数の書き込みリージョンを持つアカウントでは使えません。マルチリージョン書き込みが要るのは、複数の拠点からの書き込みを低遅延で受けたい場合や、リージョン障害時にも書き込みを止められない場合です。書き込み拠点が1か所で、障害時に数分の切り替えと直近の書き込みの欠落を許容できるなら、単一書き込みリージョンに読み取り用のリージョンを足す構成で要件を満たせます。

6種類のAPIの選び方とAzure DocumentDBの分離

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

Cosmos DBのAPIはNoSQL、MongoDB、Apache Cassandra、Apache Gremlin、Table、PostgreSQLの6つです。APIはアカウント作成時に決まり、あとから切り替えられません。新規開発でNoSQL用APIを推すのは機能の到達順が理由です。ベクトル検索・全文検索・グローバルセカンダリインデックスといった新機能はNoSQL用APIに入ります。

挿入・更新・削除の具体的なコードはAzure Cosmos DBのCRUD操作：挿入・読み取り・更新・削除をPython SDKで書く方法で扱っているので、本記事では設計判断に絞ります。

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

NoSQL以外のAPIを選ぶ動機は、ほぼ既存アプリの移行です。ワイヤプロトコル互換なので、使っている機能が対応範囲に収まればアプリのコードを大きく変えずに移せます。ただし互換は全機能ではありません。たとえばMongoDB用API 7.0では、$lookup で let と pipeline を組み合わせる書き方がエラーになるとMongoDB 7.0の機能サポート表に書かれています。移行前に、使っている演算子とコマンドを対応表と突き合わせてください。

PostgreSQLは表に残していますが、新規では選びません。Azure Cosmos DB for PostgreSQLの概要ページは冒頭で「廃止に向かっており新規プロジェクトには推奨しない」と明記し、分散PostgreSQLならAzure Database for PostgreSQLのエラスティッククラスター、NoSQLならCosmos DB for NoSQLへ誘導しています。グラフ用途の選択肢はAzureのグラフDBはどれを使う？Gremlin・Fabric Graph・Apache AGEの料金と制約、Cosmos AI Graphの正体で比べています。

Azure DocumentDBとの使い分け

仮想コア課金だった旧Azure Cosmos DB for MongoDB（vCore）は、2025年11月18日にAzure DocumentDBとして一般提供になり、Cosmos DBから独立しました。RU課金のMongoDB用APIはCosmos DB側に残っています。

MongoDBの集計パイプラインへの忠実度やマルチクラウドでの可搬性が要件ならAzure DocumentDB、そうでなければCosmos DBです。DocumentDBのOSS版との関係はDocumentDBとは｜Microsoft発OSSのPostgreSQL実装とAzure DocumentDBの違いで整理しています。

Azure Cosmos DBの料金：東日本リージョンの単価と月額試算

料金を決める2つのメーターと3つのスループット方式

費用の大半は、操作に使うスループット（RU）と、データとインデックスが占めるストレージ（GB）の2つで決まります。どちらもリージョンごとに課金されるので、リージョンを2つにすれば両方がほぼ2倍になります。ほかに、継続的バックアップ、リージョン間のデータ転送、専用ゲートウェイなどを使うと別料金がかかります。1 RUは1 KBの項目をIDとパーティションキーで1件読む（ポイント読み取り）コストです。書き込みやクエリはそれより多くのRUを消費します。RU/秒の確保方式は3つあり、負荷の変動幅で選びます。

• 手動プロビジョニング：確保したRU/秒に毎時課金。下限は400 RU/秒。負荷がほぼ一定の本番向けです。
• 自動スケール：最大RU/秒（Tmax）を決めると、0.1×Tmaxから自動で上下します。1時間ごとに、その時間の最大RU/秒か0.1×Tmaxの高い方で課金されます。使わない時間帯でも最大値の10%は払います。
• サーバーレス：RU/秒を確保せず、消費したRUの合計だけ払う従量制。リージョンは1つに限られます。

確保したRU/秒を超えた要求はHTTP 429で拒否され、SDKが自動で再試行します。429が続くなら、RU不足かパーティションの偏りのどちらかです。

東日本リージョンの単価表

Microsoftが公開しているAzure Retail Prices APIで、東日本（japaneast）の従量単価を2026年11月3日に取得しました（serviceName が Azure Cosmos DB、priceType が Consumption の行）。円額はAPIがJPY指定で返した参考値で、為替で変わります。最新の価格はAzure Cosmos DBの価格ページで確認してください。

単一書き込みリージョンのアカウントでは、自動スケールの単価が手動の1.5倍です（マルチリージョン書き込みのアカウントは別の単価体系です）。そのため、常に最大値近くまで使うワークロードでは自動スケールが割高になり、ピークが短いワークロードでは安くなります。1年・3年の予約容量は手動と自動スケールの両方に使えます。ただし100〜999,900 RU/秒の予約は1年20%・3年30%の固定割引で、よく引用される「最大63%」は3,000万RU/秒規模の3年予約で届く値です。サーバーレスとストレージは予約の対象外です。

ワークロード別の月額試算

1か月を730時間として、上の単価から計算した試算です。前提は単一リージョン・ゾーン冗長なし・予約容量なしで、ストレージは10 GB（月2.83ドル）を加えています。バックアップの追加分・データ転送・税は含めていません。

判断の目安はこうです。夜間や休日にほぼ止まる社内システムは、自動スケールかサーバーレスのほうが手動より安くなります。常時一定の負荷がある本番は、手動プロビジョニングが基本です。ただし負荷が小さいと、月5,000万RU程度ならサーバーレスのほうが安い計算になります（上の表）。予約容量を足すかは、予約分を使い切れるか、最小RU/秒の下限を含めて比べてから決めます。開発・検証環境はサーバーレスか、後述の無料レベルで足ります。正式な見積もりは、項目サイズとクエリの種類から必要RUを出すAzure Cosmos DB 容量計算ツールで詰めてください。

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

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

自動スケールの式は、設定できる最大値Tmaxの下限です。実際の課金の下限はその10%なので、Tmax 5,000なら最低500 RU/秒分を払います。同じ条件でストレージが2,000 GBまで増えると、手動の下限は2,000 RU/秒、自動スケールはTmaxの下限が20,000（課金の下限は2,000 RU/秒分）になります。データが増えるほど最低料金が上がる構造です。一時的な大量投入のためにRUを跳ね上げると、この下限が上がります。

無料レベルと無料アカウントの使い分け

ライフタイム無料レベルは、1000 RU/秒と25 GBまでがアカウントの存続期間中ずっと無料です。Azureサブスクリプションあたり1アカウントだけで、アカウント作成時にオプトインしないと後から切り替えられません。また、サーバーレスのアカウントでは使えず、手動か自動スケールのアカウントが対象です。Azure無料アカウントの特典（12か月間400 RU/秒と25 GB）とは合算でき、最初の12か月は1400 RU/秒と50 GBまで無料になります。課金を一切発生させずに開発を進めたいなら、ローカルで動くAzure Cosmos DB エミュレーターの使い方｜vNextのDocker起動とWindows版の選び方が手軽です。

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

5つのレベルの保証内容

多くの分散NoSQLが「強い整合性か結果整合性か」の2択なのに対し、Cosmos DBは5段階を用意しています。

有界整合性制約のKとTには下限があり、単一リージョンでは10回の書き込みまたは5秒、複数リージョンでは100,000回の書き込みまたは300秒より短くできません。整合性モデルそのものの考え方は結果整合性とは？強整合性との違いとレプリカ遅延の設計を実装者目線で解説で扱っています。

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

強力と有界整合性制約は、保証のために4つのレプリカのうち2つから読みます。公式ドキュメントは「同じ要求ユニット数に対して、厳密と有界整合性制約の読み取りスループットは他の整合性レベルの半分になる」と明記しています。同じ読み取り量をさばくのに倍のRUが要るということです。

既定のセッションが推奨されるのはこのためです。単一レプリカから読むので最終的整合性と同じスループットを保ちつつ、ユーザー単位で動くアプリが実際に必要とする「自分が書いた内容は読める」を満たします。整合性はアカウントの既定値をいつでも変更でき、リクエスト単位で既定より弱いレベルを指定することもできます。変更後はアプリを再デプロイしてSDKのクライアントを作り直す必要があります。

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

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

Cosmos DBは項目をパーティションキーの値ごとに論理パーティションへ分け、それを物理パーティションへ自動配置します。パーティション分割のドキュメントとサービスクォータから、設計で当たりやすい上限を抜き出します。

コンテナー全体のストレージは無制限ですが、論理パーティション単位では20 GBで止まります。テナントIDのように値の種類が少ないキーを選ぶと、大口テナントのデータが増えた時点でそのパーティションだけ書き込みが止まります。パーティションキーも、項目ごとのキーの値も、作成後に変更できません。キーを変えるには新しいコンテナーへデータを移すしかありません。

パーティションキーを含まないクエリは全物理パーティションを回るため、物理パーティション1つあたり2〜3 RUが上乗せされます。読み取りが多いコンテナーでは、よく使う絞り込み条件をそのままパーティションキーにするのが基本です。

階層パーティションキーとグローバルセカンダリインデックスの使い分け

20 GBを超えうる設計の正攻法は階層パーティションキーです。最大3階層のキーを設定でき、第1階層の値ごとに20 GBを超えるデータを持てます。マルチテナントSaaSなら「テナントID→ユーザーID→日付」のように階層化します。複数の項目を連結した合成キーで値の種類を増やす手もあり、既存アプリを大きく変えずに偏りを減らしたいときに向きます。

1つのキーではクエリのパターンをさばけない場合、NoSQL用APIではグローバルセカンダリインデックスを足せます。別のパーティションキーを持つ読み取り専用コンテナーに、変更フィード経由でデータが自動同期される仕組みで、クロスパーティションクエリを避けられます。同期は結果整合で、インデックス側のコンテナーは自動スケール必須です。費用は3か所で増えます。インデックス側のストレージとRU、同期元で変更フィードを読むRU、そして同期元の置換・削除にかかる50〜100%の上乗せです。サポート申請で論理パーティションの上限を一時的に引き上げる手もありますが、引き上げ中はSLAが適用されないため、再設計までのつなぎとして扱います。

変更フィード・統合キャッシュ・ベクトル検索の使いどころ

変更フィードによるイベント連携

変更フィードは、コンテナー内の項目の作成・更新を読み出す仕組みです。順序が保証されるのはパーティションキーの値ごとで、コンテナー全体の発生順ではありません。Azure Functionsのトリガーにつなぐと、注文データの書き込みをきっかけに通知・集計・検索インデックスへの同期を走らせられます。キューやメッセージ基盤を別に立てずにイベント駆動の処理を組めるのが利点です。

既定の「最新バージョン」モードは項目ごとに最新の状態だけを返すため、読み取りの間に起きた中間の更新は省かれ、削除も流れてきません。削除も拾うなら、削除フラグを立ててからTTLで消す設計にするか、「すべてのバージョンと削除」モードを使います。後者はNoSQL用APIのアカウント限定で、継続的バックアップの構成が前提です。読めるのはバックアップの保持期間内の変更だけで、コンテナーの先頭から読み直すこともできません。

統合キャッシュで読み取りRUを抑える条件

統合キャッシュは、専用ゲートウェイ上に置かれるメモリキャッシュです。同じポイント読み取りやクエリを繰り返すと、キャッシュから返った分はRUを消費しません。商品カタログのように読み取りが書き込みより圧倒的に多いデータで効きます。

使える条件は絞られています。NoSQL用APIのアカウントで専用ゲートウェイを作り、その接続文字列を使ってゲートウェイモードで接続し、読み取りの整合性をセッションか最終的にする必要があります。強力・有界整合性制約・一貫性のあるプレフィックスの読み取りはキャッシュを素通りします。費用面では、専用ゲートウェイがノード単位の時間課金で、東日本のD4sは1ノード1時間0.446ドル（月約326ドル）です。可用性SLAの対象にするには3ノード以上が必要です。読み取りRUの削減額がこれを上回るかで判断します。書き込みが多いワークロードや、同じ読み取りがほとんど繰り返されないワークロードには向きません。

ベクトル検索と全文検索の実装

NoSQL用APIは、埋め込みベクトルを元データと同じドキュメントに持ち、近傍検索できます。RAGやAIエージェント向けに専用のベクトルストアを別に立て、データを二重管理する必要がありません。ベクトル検索のドキュメントに沿うと、手順は3つです。アカウントで機能「Vector Search for NoSQL API」を有効化し（反映まで最大15分）、コンテナー作成時にベクトルポリシーを定義し、インデックスを選びます。

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

次元数・データ型・距離関数は作成後に直接変更できません。埋め込みモデルを決めてからコンテナーを作ります。インデックスは3種類で、下の表の「5万」は、コンテナー全体の件数ではなく、WHERE句などで絞り込んだ後の検索対象のベクトル数です。公式も一般的な目安であり実測で確かめるよう書いています。

落とし穴は2つです。quantizedFlatとdiskANNは最低1,000件のベクトルが入るまでフルスキャンにフォールバックするので、少量データでの性能検証は本番と一致しません。もう1つは書き込みRUで、既定の自動インデックスは全プロパティに張られるため、ベクトルのパスはインデックス作成ポリシーの excludedPaths に入れておきます。検索は VectorDistance 関数に TOP N を付けて書きます。

SELECT TOP 10 c.title, VectorDistance(c.contentVector, @embedding) AS score
FROM c
WHERE c.tenantId = @tenantId
ORDER BY VectorDistance(c.contentVector, @embedding)

@embedding には検索文をベクトル化した1536次元の配列を、@tenantId には絞り込み用の文字列を渡します。WHERE句で先に絞ると検索対象のベクトル数が減り、効くインデックスも変わるため、本番に近いデータ量で確かめてください。共有スループットのデータベースではベクトル検索を使えないので、使う予定があるコンテナーは専用スループットかサーバーレスで作ります。キーワード一致も効かせたい場合は、全文検索とベクトル検索のスコアをReciprocal Rank Fusion（RRF）で合成するハイブリッド検索を使えます。外部の検索サービスは要りません。AIエージェントからCosmos DBを操作する構成はAzure Cosmos DB MCPサーバーの使い方：Azure MCP Server 3.0とMCP Toolkitの接続・権限設計で扱っています。

RDB・Amazon DynamoDBとの違い

RDBとの違いとデータの振り分け方

最大の違いは結合です。NoSQL用APIのJOINは同じ項目内の配列を展開する自己結合で、コンテナーやドキュメントをまたぐ結合はできません。複数項目をまたぐACIDトランザクションも、同じ論理パーティション内に限られます。そのため、一緒に読むデータは1つの項目にまとめる（非正規化する）のがCosmos DBの設計の基本です。

振り分けの基準ははっきりしています。会計・在庫・受発注のように多対多の結合と厳密なトランザクションが中心のデータはRDBに置きます。スキーマが頻繁に変わるデータ、読み書きが大量に発生するセッション・イベント・カタログ、複数リージョンで低遅延に読みたいデータがCosmos DBの領分です。データベースの種類ごとの基本はデータベースとは？種類・DBMS・RDBとNoSQLの選び方を実装目線で解説にまとめています。

Amazon DynamoDBとの違い

AWSでCosmos DBに近い位置にいるのがAmazon DynamoDBです。どちらもフルマネージドで水平スケールし、サーバーレスに近い従量課金を持ちます。違いは主に2点です。Cosmos DBは複数のAPIとデータモデルを1サービスに束ね、NoSQL用APIではSQLに似たクエリを書けること、そして整合性を5段階から選べることです。複数リージョンへの書き込みはどちらも可能で、DynamoDBではグローバルテーブルがこれに当たります。DynamoDBの読み取りは結果整合性か強い整合性の2択で、強い整合性の読み取りは結果整合性の2倍の読み取りキャパシティを消費します。強い整合性を選ぶと読み取りコストが倍になる構造は、Cosmos DBの強力・有界整合性制約と同じです。

実際の選定は、性能差よりも周辺サービスをAzureとAWSのどちらに寄せるかで決まります。MongoDB互換のAWS側の選択肢はAmazon DocumentDBとは？MongoDB互換マネージドDBの仕組み・料金・採用判断を実装者目線で解説で扱っています。

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

全件走査を伴う分析ワークロードとRU消費

対話型分析や一括集計が主目的なら、Cosmos DBを選びません。ポイント読み取りと分散クエリに最適化されているため、全件スキャンを伴う集計はRUを大量に消費します。公式の概要ページも、分析ワークロードには代替としてMicrosoft Fabricを挙げています。運用データを分析したい場合は、Fabricへのミラーリングで分析側へ複製する構成を取ります。

ここは古い情報が出回っています。従来の選択肢だったAzure Synapse Linkは、Synapse Linkのドキュメントの冒頭で「新しいプロジェクトではサポートされなくなりました。この機能は使用しないでください」と案内されています。概要ページには今もSynapse Linkが機能として並んでいるので、そちらだけ読むと古い構成を選んでしまいます。

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

ホワイトラベルのCRMや基幹システムのように、エンティティ同士の結合が多い設計はAzure SQL DatabaseやAzure Database for PostgreSQL・MySQLのほうが素直です。Cosmos DBに載せると、結合をアプリ側で書き、非正規化したデータの整合をアプリで保つことになります。一時データの退避やセッションキャッシュだけが目的なら、より軽いキャッシュサービスで足ります。画像や動画などのファイル、長期保管のログは、項目の上限が2 MBでストレージ単価も高いCosmos DBではなく、Azure Blob Storageとは？仕組み・Blobの種類とアクセス層・S3との違いを実装者目線で解説で扱うオブジェクトストレージに置きます。どのデータをどの基盤に載せるかを要件定義の段階で固めたい場合は、issohのデータベース設計・移行支援でパーティション設計とRUの見積もりから相談できます。

よくある質問

Azure Cosmos DBとは何ですか？

Microsoftが提供するフルマネージドの分散NoSQLデータベースです。ドキュメント・キー値・グラフ・テーブル・ベクトルのデータを1つのサービスで扱い、可用性SLAは複数の書き込みリージョンを持つ構成などで最大99.999%です。サーバー管理やパッチ適用は不要で、スループットはRU/秒で確保します。

Azure Cosmos DBの料金はいくらですか？

東日本リージョンでは、手動プロビジョニングが100 RU/秒あたり0.009ドル/時、ストレージが1 GBあたり月0.2825ドルです（2026年11月時点）。最小の400 RU/秒なら、RU部分は月約26ドルです。アクセスが散発的ならサーバーレス（100万RUあたり0.285ドル）のほうが安くなります。

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

ライフタイム無料レベルを使えば、1000 RU/秒と25 GBまで無料です。Azureサブスクリプションあたり1アカウントのみで、アカウント作成時にオプトインしないと後から切り替えられません。サーバーレスのアカウントには適用されません。

Cosmos DBとRDBの違いは何ですか？

Cosmos DBはスキーマを持たないJSONドキュメントを格納し、コンテナーをまたぐ結合ができません。複数項目のトランザクションも同じ論理パーティション内に限られます。結合と厳密なトランザクションが中心ならRDB、大量の読み書きや複数リージョンでの低遅延が要件ならCosmos DBが向きます。

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

新規開発ならNoSQL用APIです。MongoDB用APIは既存のMongoDBアプリをRU課金で動かしたいときの選択肢です。仮想コア課金でMongoDB互換を使いたい場合はAzure DocumentDBが選定先になります。いずれもAPIはアカウント作成後に変更できません。

関連記事

• Azure Cosmos DB エミュレーターの使い方｜vNextのDocker起動とWindows版の選び方
• Azure Cosmos DBのCRUD操作：挿入・読み取り・更新・削除をPython SDKで書く方法
• Azure Cosmos DB MCPサーバーの使い方：Azure MCP Server 3.0とMCP Toolkitの接続・権限設計
• AzureのグラフDBはどれを使う？Gremlin・Fabric Graph・Apache AGEの料金と制約、Cosmos AI Graphの正体
• DocumentDBとは｜Microsoft発OSSのPostgreSQL実装とAzure DocumentDBの違い【2026年9月時点】