Azure Cosmos DBとは｜特徴・整合性・料金とDynamoDBの違い

Azure Cosmos DBとは｜マルチモデルNoSQLの基本

結論から言えば、Azure Cosmos DBは主に「アプリの手前に置く運用データベース」です。大量集計や対話型分析の主基盤として使うサービスではありません。

Microsoftは公式ドキュメントで、ドキュメント・ベクター・キー値・グラフ・テーブルといった運用データモデルすべてに対応する統合データベースと位置づけています（Azure Cosmos DB 概要｜Microsoft Learn）。インフラの調達もパッチ適用もMicrosoft側が持つフルマネージド型で、利用者が設計するのはデータモデル・パーティション・整合性・スループットの4点に絞られます。

対応API（5種類）とデータモデル

Cosmos DBは1つのサービスでありながら、接続する「API」を選ぶことで振る舞いが変わります。2026年11月10日時点のMicrosoft Learnでは、主に以下のAPIが案内されています。

新規に書くならネイティブのNoSQL用APIが基本線です。互換APIは既存資産の移行や、ドライバーを変えたくない事情があるときの選択肢と考えると整理しやすくなります。

SDKは.NET・Java・JavaScript／Node.js・Python・Go・Rustが用意され、インデックスは既定で自動作成されます。多くのワークロードで手動のインデックス保守が不要になる点は、運用工数の読みに効いてきます。

Azure DocumentDBとの分離（2026年の重要な変化）

ここは多くの日本語記事がまだ追いきれていない論点です。

2026年11月10日時点で、MicrosoftはCosmos DBとは別に、Azure DocumentDB（仮想コア） という製品を案内しています（Azure DocumentDBとAzure Cosmos DBの比較｜Microsoft Learn）。PostgreSQLエンジン上に構築されたオープンソースのDocumentDBエンジンを搭載し、MongoDBワイヤプロトコル互換を持つサービスです。両者は似て見えますが、設計の向きがはっきり違います。

以下はMicrosoft Learnで案内されている代表的な条件の比較です。可用性SLAは選択したリージョン数・書き込み構成・整合性・契約条件で変わるため、実際の値は公式のSLA文書で確認してください。

Microsoft自身は、ドライバーの柔軟性とグローバルスケールが要るならCosmos DBのネイティブNoSQL用API、MongoDBの集計忠実度やマルチクラウド移植性が要るならDocumentDB、という切り分けを案内しています（Azure DocumentDBとAzure Cosmos DBの比較｜Microsoft Learn）。

案件の現場では「Cosmos DBのMongo API」と言われたときに、どちらの製品の話なのかを確認しないと見積もりが崩れます。最初の面談で聞いておくと安全な項目です。

ミニFAQ｜基本編

Cosmos DBはRDBの置き換えになりますか。

なりません。リレーション性が高いアプリケーション（たとえば複雑な結合が前提の業務システム）は、Microsoft自身がAzure SQLやAzure Database for MySQLを検討するよう案内しています。Cosmos DBが得意なのは、スキーマが揺れる・書き込みが多い・レイテンシに厳しい領域です。

分析用途に使えますか。

対話型分析や大量バッチ分析（OLAP）は不得手な領域とされており、代替としてMicrosoft Fabricが挙げられています。分析が要る場合は、Azure Synapse LinkやFabricミラーリングで分析ストアに逃がす構成が定石です。

5つの整合性レベルと選び方

Cosmos DBを語るうえで外せないのがここです。

多くの分散NoSQLでは、強い整合性と結果整合性を軸に設計を考えることが多いところです。Cosmos DBは、その間に3段階を置いた5レベルを用意しています（整合性レベルの選択｜Microsoft Learn）。

実務ではセッション整合性が出発点になります。ユーザー単位で動くアプリの直感に最も近く、書き込みレイテンシと読み取りスループットのバランスが良いためです。

整合性はスループットとコストに跳ね返る

ここが設計上の落とし穴です。

強力整合性と有界整合性制約では、保証のために4レプリカセット中2つのレプリカから読む必要があります。セッション・一貫性のあるプレフィックス・最終的の3つは単一レプリカ読み取りです。結果として、少なくとも読み取りについては、同じデータを読む場合のRU消費が他レベルの約2倍になります。書き込みやストレージには直接かかる話ではない点に注意してください。

「とりあえず一番強いレベルにしておこう」という判断は、読み取り中心のワークロードではRU消費と請求額を大きく押し上げます。この構造を理解しているかどうかは、面談でもよく効く論点です。

マルチリージョン書き込みとの制約

複数の書き込みリージョンを持つアカウントでは、強力整合性を使えません。複数リージョンで同時に書き込む構成では、全リージョンで常に最新値を線形化して読む保証を維持するのが難しいためです。なおRPOは許容できるデータ損失時間、RTOは復旧までの時間目標を指します。

もう1つ、距離の制約もあります。5,000マイル（8,000キロメートル）を超えるリージョンにまたがるアカウントでは、強力整合性が既定でブロックされます。有効化にはサポートへの問い合わせが必要です。日本と北米・欧州をまたぐ構成を検討しているなら、設計の早い段階で確認しておく項目になります。

レイテンシの目安も押さえておきましょう。Microsoftは、適切に構成された環境での目安として、読み取り・書き込みともに99パーセンタイルで10ミリ秒未満、50パーセンタイルでは読み取り4ミリ秒以下・書き込み5ミリ秒以下という値を示しています。実際のレイテンシはリージョン、整合性レベル、ネットワーク、リクエスト内容やパーティション設計に左右されます。また複数リージョンで強力整合性を使う場合は例外で、書き込みレイテンシは「最も遠い2リージョン間の往復時間の2倍＋10ミリ秒」になります。

ミニFAQ｜整合性編

既定の整合性レベルは後から変えられますか。

アカウント単位でいつでも変更できます。ただし変更後はアプリケーションを再起動してSDKインスタンスを作り直す必要があります。リクエスト単位で既定を上書きすることも可能ですが、上書きが効くのはSDKクライアント内の読み取りに限られます。

障害時にどれくらいのデータが失われ得ますか。

整合性レベルと構成で変わります。MicrosoftのSLA／可用性に関するドキュメントでは、複数リージョン・単一書き込みリージョンでセッション／一貫性のあるプレフィックス／最終的を使う場合のRPO目標が15分未満、強力整合性なら0、単一リージョン構成はどの整合性レベルでも240分未満と案内されています。実際の要件確認では、最新のSLA文書と自分の構成条件を突き合わせてください。

パーティション設計の勘所｜20GBの壁

Cosmos DBで最初に、そして最後まで効いてくるのがパーティションキーの選定です。

論理パーティションは、同じパーティションキー値を持つアイテムの集合です。通常の単一パーティションキー設計では、この論理パーティション1つあたりの上限が20GBになります（20GBを超える見込みがある場合は、後述する階層パーティションキーを検討します）。そして物理パーティション1つが提供できるスループットは最大10,000 RU/秒で、論理パーティションは必ず1つの物理パーティションに載るため、論理パーティションあたりのスループット上限も10,000 RU/秒になります（パーティション分割と水平スケーリング｜Microsoft Learn）。

パーティションキーの選び方

公式が挙げる条件は4つです。

1. 値が変更されないプロパティであること

2. カーディナリティが高いこと（取り得る値が広範囲に及ぶ）

3. RU消費とストレージが論理パーティション間で均等に分散すること

4. 値のサイズが2048バイト以下（大きいパーティションキーを有効にしていない場合は101バイト）

決定的なのは1番です。パーティションキーの値は作成後に変更できません。項目の置換操作ではパーティションキーが既存と一致している必要があり、パーティション間を移動させる手段として使えません。キーを変えるには、新しいコンテナーへデータを移すことになります。

読み取りが多いコンテナーでは、クエリのフィルター条件に頻出するプロパティをキーにするとクロスパーティションクエリを減らせます。クロスパーティションクエリでは、各物理パーティションへ問い合わせる分だけRU消費が増えるためです。公式ドキュメントでは、パーティションごとに数RU程度の追加が発生する例が示されています（実際の増分はクエリ内容・インデックス・返却件数・パーティション数で変わります）。

20GBを超えそうなときの逃げ道

テナントごとにデータが偏るマルチテナント構成などでは、単一のキーで20GBを超える見込みが立ちます。この場合は階層パーティションキー（サブパーティション）を使い、最大3レベルの階層を構成します。第1レベルのカーディナリティが高く、かつほとんどのクエリに含まれるよう設計することが前提条件になります。

複数のクエリパターンを1つのキーで賄えない場合は、グローバルセカンダリインデックス（2026年11月10日時点ではプレビュー）という選択肢もあります。異なるパーティションキーを持つコンテナーがソースと自動同期される仕組みで、追加のストレージとRUコストと引き換えにクロスパーティションクエリを排除できます。プレビュー段階の機能なので、本番採用の可否は公式ドキュメントで最新状況を確認してください。

なお公式ドキュメント上の目安として、30,000 RU/秒を超えるプロビジョニングや100GBを超えるデータ量では、複数の物理パーティションに広がる可能性が高くなります（物理パーティションの分割自体はサービス側が管理します）。これ以下の規模なら、クロスパーティションクエリの性能を過度に気にする必要はありません。

料金とRUの考え方

結論として、Cosmos DBの請求額は「保存したデータ量」より「叩いた回数と重さ」で決まります。

RU（要求ユニット）は、読み書きやクエリに必要なCPU・IOPS・メモリを1つの通貨に丸めた単位です。たとえばセッション整合性での1KBアイテムのポイント読み取りが約1 RU、という形で正規化されています。整合性レベルや項目サイズ、クエリの内容によって消費RUは変わります（要求ユニット｜Microsoft Learn）。

3つのスループットモデル

負荷変動が読みにくい初期段階では、オートスケールから入り、実測後に手動プロビジョニングへ切り替える判断が現実的です。常時高負荷で安定しているなら手動プロビジョニングのほうが安く収まります。サーバーレスは安く見えますが、常時トラフィックがあるワークロードでは割高に転ぶケースがあります。

無料で試せる範囲

検証コストをかけずに触れる手段が3つ用意されています。

• ライフタイム無料レベル：1,000 RU/秒のスループットと25GBのストレージが無料（無料レベル｜Microsoft Learn）

• Azure無料アカウント：2026年11月10日時点では、最初の30日間のクレジットと、一定期間の無料枠（400 RU/秒と25GBのストレージ）が案内されています。条件は国・時期で変わるため公式ページで確認してください

• エミュレーター：ローカル環境でCosmos DBを無償でエミュレート。開発・テスト用

長期運用が見えているなら、条件によっては予約容量の購入で最大63%の割引が案内されています。適用可否と割引率はリージョン・契約期間・構成で変わります。正確な単価は地域と構成で変わるため、見積もりはAzure Cosmos DBの価格ページで確認してください。

コストを外す典型パターン

実務で請求額が想定を超えるときは、だいたい次のどれかです。

• 整合性レベルを強力に固定したまま読み取りが多い（同条件の読み取りでRU消費が約2倍になりやすい）

• パーティションキーが偏り、ホットパーティションでレート制限が出て、それを回避するために全体のRUを上げてしまう

• クロスパーティションクエリが常態化している

• インデックスポリシーを既定のまま使い、書き込みが多いコンテナーで不要なインデックス更新が走っている

4つ目は見落とされがちです。Cosmos DBは既定で全プロパティに自動インデックスを張るため、書き込み負荷が高いコンテナーではインデックス対象を絞るだけでRU消費が下がることがあります。

DynamoDB・MongoDBとの違いと使い分け

AWS経験者がCosmos DBに入るとき、頭の中の対応表を一度作っておくと理解が速くなります。

DynamoDBとの比較

設計思想の差をまとめると、DynamoDBは「アクセスパターンを先に決めてから設計する」色が強く、Cosmos DBは「自動インデックスによりクエリの柔軟性は比較的高いが、パーティションキー設計は最初に固める必要がある」という違いです。どちらが優れているという話ではなく、クラウドの選択に引きずられて決まるのが実情です。

DynamoDB側の設計思想はDynamoDBとは｜AWSのNoSQL DBの特徴・RDSとの違い・案件単価で整理しています。AWSからの移行検討なら、両方を見比べてください。

MongoDB・Cassandra・Redisとの関係

Cosmos DBはこれらの互換APIを提供しているため、「競合」と「受け皿」の両面を持ちます。

• MongoDB：ドキュメント指向という点で最も近い。集計パイプラインの忠実度を重視するならAzure DocumentDB側が候補になる。特性の違いはMongoDBとは？特徴・RDBとの違い・案件単価を参照

• Cassandra：書き込み分散に強いワイドカラム型。Cassandra用APIで受けられるが、運用の勘所は異なる（Cassandraとは｜分散NoSQLの特徴）

• Redis：インメモリのキャッシュ／KVSで、そもそも層が違う。永続化が主目的ならCosmos DB、揮発前提の高速アクセスならRedis（Redisとは？特徴・できること）

• Neo4j：グラフ特化。関係性の探索が主目的ならGremlin用APIより専用製品が勝るケースがある（Neo4jとは｜グラフデータベースの特徴）

リレーショナルな要件が強いなら、そもそもNoSQLではなくマネージドRDBが正解です。Amazon Auroraとは｜RDSとの違い・料金と移行案件の単価のようなRDB側の選択肢も並べて検討するほうが、結果として事故が減ります。

向いているケース・向かないケース

公式が挙げる適合パターンは明快です。

向いているのは、スキーマが頻繁に変わる反復開発、リアルタイムのパーソナライズのようなレイテンシに厳しい処理、予約プラットフォームのような負荷変動が激しいワークロード、IoTデバイスの状態やログのような高スループット処理、顧客向けWebアプリのようなミッションクリティカル用途です。

向かないのは、対話型分析やストリーミング分析などのOLAPワークロードと、リレーション性が高いアプリケーションの2つ。前者はMicrosoft Fabric、後者はAzure SQLやAzure Database for MySQLが代替として案内されています。

ベクター検索とAI用途

近年の位置づけの変化として、Cosmos DBはベクターデータベースとしての機能を取り込んでいます。DiskANNを使ったベクター検索とハイブリッド類似性検索を備え、運用データと埋め込みを同じ場所に置けることが売りです（ベクターデータベース｜Microsoft Learn）。

RAG構成でベクターストアを別立てするか、運用DBに寄せるかは判断が分かれるところです。専用ベクターDBとの比較はベクトルDBの選び方｜Pinecone・Weaviate・Qdrant・pgvectorの使い分けにまとめています。Azure上でLLMを組むならAzure OpenAI Serviceとは｜料金・モデル選定と企業LLM導入案件の実務と合わせて読むと、構成の全体像がつかめます。

フリーランス案件での扱われ方と単価の目安

短答から言います。Cosmos DB単独で募集される案件はほとんどありません。Azureの設計・構築案件の構成要素として登場し、単価はAzure全体の経験値で決まります。

以下の数値は、フリコンに掲載中の案件をスキルタグ別に集計した参考値です（2026年11月10日時点）。掲載時点の提示単価であって成約単価ではなく、またCosmos DB単独のタグ集計でもありません。職種構成や案件レイヤーが異なるため、タグ間の単価差がスキルの優劣を示すものでもない点にご注意ください。

Azureタグの案件は、掲載タイトルを見る限りインフラ寄りのクラウド移行・環境構築が中心です。一方でNoSQLタグは件数こそ少ないものの、単価帯は上に寄ります。データストア設計まで任される案件は人数が絞られる、という構造がそのまま出ていると読めます。

自分の経験でどのレンジを狙えるかを把握しておきたい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。単価を体系的に上げる考え方はフリーランスエンジニアの単価相場と単価の上げ方で整理しています。

案件で求められるスキルセット

掲載案件やポジションの記述から見えてくる共通項は、Cosmos DBの操作そのものよりその周辺にあります。

• Azure全体の設計経験（仮想ネットワーク、Entra ID、監視まわり）

• RU設計とコスト最適化の説明責任。「なぜこのRUなのか」を言語化できるか

• パーティションキー選定の判断根拠。カーディナリティとクエリパターンの両面から説明できるか

• 整合性レベルを業務要件から逆算する力

• サーバーレス構成との組み合わせ（Azure Functionsとは？サーバレスの仕組み・AWS Lambdaとの違い）

面談で頻出するのは3番目と4番目です。「パーティションキーに何を選びましたか、その理由は」という質問は、設計を自分でやったかどうかが一発で割れる問いになっています。

資格で補強する場合（2026年の変更点）

Cosmos DBに直接対応する資格は、長らくDP-420「Azure Cosmos DB Developer Specialty」でした。これが2026年10月6日付で「Azure Cosmos DB AI Developer Associate」へ名称とレベルが変更され、試験内容にもAI検索・エージェントメモリ・Fabric関連の出題範囲が加わっています。最新の出題範囲はDP-420 試験の学習ガイド｜Microsoft Learnで確認してください。

資格単体で単価が上がるわけではありませんが、Azure未経験から案件に入る足がかりとしては機能します。全体のロードマップはAzure認定資格おすすめ一覧｜AZ-900からのロードマップを参照してください。

案件の探し方

Cosmos DBという語で検索しても案件はほぼヒットしません。実務的には、Azure環境タグかNoSQLタグから入り、募集要項の本文で使用データストアを確認する流れになります。

• Azure案件一覧

• NoSQL案件一覧

どのクラウドから攻めるか迷っている段階なら、クラウド案件の参入順序｜AWS・Azure・GCPどれから取るかの判断軸が判断材料になります。複数の案件を比較する段階に入ったら、案件の選び方｜フリーランスエンジニアが単価・稼働・スキルで決める優先順位の優先順位づけが使えます。

導入でよくある失敗と対策

失敗1｜パーティションキーを「とりあえずID」で決めてしまう

項目IDをパーティションキーにすること自体は、公式も推奨する選択肢です。値が一意でRU消費が均等に分散し、ポイント読み取りが効率的になります。

問題は、クエリパターンを確認せずに決めてしまうケースです。IDでフィルターしないクエリが主流なら、毎回クロスパーティションクエリが走ります。しかもキーは後から変えられません。アクセスパターンを書き出してからキーを決めるという順番を崩さないことが、唯一の予防策になります。

失敗2｜強力整合性を「安全策」として選ぶ

読み取りRUが2倍になり、マルチリージョン書き込みが使えなくなり、遠距離リージョン構成では既定でブロックされます。安全策のつもりが制約の束になるパターンです。

業務要件を整理して、「古い値を見せると実害が出るデータ」だけを強力整合性にし、残りはセッションに置く。アカウント既定をセッションにしてリクエスト単位で上書きする設計も可能です。

失敗3｜RU不足のレート制限を全体のRU増で殴る

特定の論理パーティションにアクセスが集中すると、全体のRUに余裕があってもそのパーティションだけで制限に当たります。ここでRUを引き上げても、偏りは解消しません。コストだけが増えます。

スループットは物理パーティション間で均等に分割される、という前提を思い出してください。見るべきはRUの総量ではなく、論理パーティションごとの消費の偏りです。20GBに近づいているパーティションはAzure Monitorのアラートで監視できます。

導入前チェックリスト

設計に入る前に、この10項目を埋められるかを確認してください。埋まらない項目がある状態で本番構成を決めると、だいたいあとで作り直しになります。

4番と5番を同時に確認するのがポイントです。この2つは片方を決めるともう片方が制約されるため、別々に決めると矛盾します。

まとめ

Azure Cosmos DBは、整合性とコストを自分で選ぶタイプのデータベースです。既定値に任せて動かすのではなく、業務要件から逆算して設計した人だけが性能とコストの両方を取れます。

• マルチモデルNoSQLで、NoSQL・MongoDB・Cassandra・Gremlin・Tableの5つのAPIに対応。新規ならネイティブのNoSQL用APIが基本

• 整合性は5段階。セッションを出発点に、強力整合性は「古い値が実害になるデータ」に限定する

• 強力整合性と有界整合性制約は同条件の読み取りでRU消費が約2倍。マルチリージョン書き込みとは併用不可、8,000km超は既定でブロック

• 論理パーティションは20GB・10,000 RU/秒が上限で、キーは後から変更できない。アクセスパターンを書き出してから決める

• 料金はRU/秒。オートスケールから入り、無料レベル（1,000 RU/秒＋25GB）で検証してから本番規模を決める

• 案件はAzure設計・構築案件の一部として登場する。Azureタグの掲載平均は83万円／月、NoSQLタグは91万円／月（フリコン掲載・2026年11月10日時点の参考値）

• 資格はDP-420が2026年10月6日にAI寄りの内容へ改定済み。出題範囲は公式の学習ガイドで確認する

次のステップとしては、ライフタイム無料レベルでアカウントを1つ作り、手元のデータで論理パーティションを意図的に偏らせてレート制限を体験してみてください。ドキュメントを読むより早く、RU設計の感覚がつかめます。

参照した一次情報は以下のとおりです。

• Azure Cosmos DB 概要｜Microsoft Learn

• 整合性レベルの選択｜Microsoft Learn

• パーティション分割と水平スケーリング｜Microsoft Learn

• 要求ユニット｜Microsoft Learn

• Azure Cosmos DB 無料レベル｜Microsoft Learn

• Azure Cosmos DB の価格

• Azure DocumentDBとAzure Cosmos DBの比較｜Microsoft Learn

• Azure Cosmos DB のベクターデータベース｜Microsoft Learn

• DP-420 試験の学習ガイド｜Microsoft Learn