Azure Cosmos DB入門｜グローバル分散NoSQLのパーティションキー設計・料金体系をオンプレ経験者向けに徹底解説

2026年5月29日2026年6月9日

オンプレミスでRDB（リレーショナルデータベース）を長年使ってきたエンジニアがAzureに移行したとき、「Cosmos DBって何者なんだ？」と戸惑うケースは珍しくありません。テーブルではなく「コンテナ」、行ではなく「アイテム」という用語の世界に飛び込むうえ、料金体系もRU（Request Unit）という独自単位で計算されるため、最初はとっつきにくく感じるものです。

この記事では、Azure Cosmos DBについて、オンプレ経験者にもわかりやすく解説します。基本概念からアカウント・コンテナの作成手順、パーティションキーの設計、料金の仕組み、よくあるハマりポイントまで、一通りカバーします。

なぜCosmos DBなのか？RDBとNoSQLの何が違うのか

オンプレ時代、大半のシステムはMySQL・PostgreSQL・SQL Serverといったリレーショナルデータベースを中心に設計されていました。テーブルを正規化し、JOINで結合して取り出す——これが長年のスタンダードでした。

ではなぜ、クラウドではNoSQLを選ぶケースが増えているのでしょうか。理由は主に3つあります。

・スケーラビリティ: RDBの垂直スケール（サーバーを強化する）には物理的な限界があります。NoSQLは水平スケール（サーバーを増やす）で対応できるため、急激なアクセス増に強いです。
・スキーマの柔軟性: JSONドキュメントとして保存するため、カラム追加のたびにALTER TABLEを発行する必要がありません。スタートアップや仕様変更が頻繁なプロジェクトで特に重宝されます。
・グローバル分散: Cosmos DBはボタン一つでデータを複数リージョンにレプリケートできます。オンプレでの地理冗長構成は構築コストが膨大でしたが、Cosmos DBでは数クリックで実現できます。

Azure SQL DatabaseとAzure Cosmos DBの使い分けの目安

項目	Azure SQL Database	Azure Cosmos DB
データ形式	テーブル（正規化）	JSONドキュメント
JOINの使いやすさ	得意	苦手（非推奨）
スケール方式	主に垂直スケール	水平スケール（自動）
グローバル分散	geo-replication設定が必要	ポータルで数クリック
主なユースケース	基幹業務・財務・ERP	IoT・Webアプリ・チャット・SNS

Cosmos DBが力を発揮するのは「スキーマが頻繁に変わる」「大量のリクエストが来る」「グローバルに展開する」場面です。逆に、複雑なJOINが必要な業務システムでは素直にSQL Databaseを使ったほうが無難です。RDB経験者が「とりあえずCosmos DB」と飛びつくと、設計の複雑さに後悔することがあるので注意してください。

基本的な使い方（Azureポータル操作）

1. Cosmos DBアカウントの作成とAPIの選択

Azureポータルにログインし、「リソースの作成」→「Azure Cosmos DB」を選択します。

最初の重要な判断がAPIの選択です。Cosmos DBは複数のAPIをサポートしており、用途に応じて選びます。

・NoSQL（コアAPI）: JSONドキュメント形式、最も汎用的。新規開発ならこれを選んでおけば間違いない。
・MongoDB API: 既存のMongoDBアプリをほぼそのまま移行できる。
・Cassandra API: ワイドカラム型。IoTログや時系列データ向け。
・Gremlin API: グラフDB。SNSの「友人の友人」のような関係性データ向け。
・Table API: Azure Table Storageとの互換維持目的。レガシーシステムからの移行用。

新規開発ではNoSQL（コアAPI）を選ぶのが鉄則です。Cosmos DBの機能を最も活かせるAPIであり、ドキュメントも最も充実しています。APIは後から変更できないので、ここは慎重に選んでください。

アカウント名を設定し、リージョンを「東日本（Japan East）」に設定します。バックアップポリシーやキャパシティモード（後述）も初期設定で決まるため、確認しながら進めましょう。作成には数分かかります。

2. データベースとコンテナの作成

アカウントが作成できたら、次にデータベースとコンテナを作成します。Cosmos DBの階層構造を頭に入れておきましょう。

・アカウント: Cosmos DBリソースの最上位。課金・レプリケーションの単位。
・データベース: コンテナをグルーピングするための名前空間。スループット共有の単位にもなる。
・コンテナ: RDBのテーブルに相当。アイテムを格納する入れ物。パーティションキーはここで設定。
・アイテム: RDBの1行（レコード）に相当。JSON形式で保存される。

Azure CLIでコンテナを作成する場合：

# Azure CLI でCosmos DBコンテナを作成する # 事前に az login でサインイン済みであること ACCOUNT_NAME="mycosmosaccount" RESOURCE_GROUP="myResourceGroup" DATABASE_NAME="myDatabase" CONTAINER_NAME="myContainer" PARTITION_KEY="/userId" # データベースを作成 az cosmosdb sql database create --account-name $ACCOUNT_NAME --resource-group $RESOURCE_GROUP --name $DATABASE_NAME # コンテナを作成（スループット400RU/s） az cosmosdb sql container create --account-name $ACCOUNT_NAME --resource-group $RESOURCE_GROUP --database-name $DATABASE_NAME --name $CONTAINER_NAME --partition-key-path $PARTITION_KEY --throughput 400

ここで「パーティションキー」が登場します。これがCosmos DBの設計における最重要事項で、後のセクションで詳しく解説します。

3. データの投入と取得

Azureポータルの「データエクスプローラー」からGUIでアイテムを直接操作できます。また、REST APIやSDK（.NET、Python、Java、Node.jsなど）を使ってプログラムから操作するのが実務では一般的です。

Python SDKを使った基本操作の例：


# pip install azure-cosmos でSDKをインストール済みの前提

from azure.cosmos import CosmosClient, PartitionKey

# 接続設定（接続文字列はAzureポータルの「キー」から取得）
endpoint = "https://mycosmosaccount.documents.azure.com:443/"
key = "your_primary_key_here"
client = CosmosClient(endpoint, key)

database = client.get_database_client("myDatabase")
container = database.get_container_client("myContainer")

# アイテムの追加（id は必須フィールド）
item = {
    "id": "user001",
    "userId": "user001",
    "name": "山田太郎",
    "email": "yamada@example.com",
    "plan": "premium"
}
container.upsert_item(item)

# アイテムの取得（パーティションキーを指定して効率よく検索）
query = "SELECT * FROM c WHERE c.userId = 'user001'"
items = list(container.query_items(
    query=query,
    partition_key="user001"  # パーティションキーを明示することでコスト削減
))
print(items)

料金の仕組み（RU/sとコスト感覚）

Cosmos DBの料金で最も戸惑うのがRU（Request Unit）という単位です。

RUとは、データベース操作の「コスト」を抽象化した単位で、CPUやメモリ・IOの複合指標です。1KBのドキュメントを1件読み取る操作がおよそ1RUに相当します。書き込みはその約5倍（約5RU）、クエリはインデックスの使われ方によって大きく変わります。

スループットの3つのモード（2026年5月時点の料金・東日本リージョン）

モード	概要	向いているケース	料金の目安
プロビジョニングスループット	RU/sを事前に確保（最低400RU/s）。時間単位で課金。	トラフィックが安定しているシステム	400RU/sで約$23.36/月
オートスケールスループット	最大RU/sを設定し、負荷に応じて自動でスケール。最低でも最大値の10%を課金。	トラフィックにムラがあるシステム	最大1000RU/sで最低100RU/s分課金
サーバーレス	消費したRUに対してのみ課金。プロビジョニング不要。	開発環境・小規模アプリ・実験用途	100万RU消費で約$0.25

ストレージ料金は別途1GBあたり約$0.25/月（2026年5月時点）です。

【コスト注意点】Cosmos DBはリクエスト数ではなくRU消費量に対して課金されます。クエリの書き方が非効率だとRU消費量が爆発し、意図しない高額請求につながります。「SQLライクに書けるから」と複雑なクエリを書きがちな移行初期は要注意です。特にインデックスが当たっていないフィールドでのフィルタや、後述するクロスパーティションクエリはRU消費が大きいので意識しておきましょう。

パーティションキー設計（Cosmos DBで最も重要なポイント）

Cosmos DBの性能とコストを左右する最大の設計判断がパーティションキーの選択です。

パーティションキーとは、Cosmos DBが内部でデータを物理的に分散配置するための「仕切り」です。RDBでいえばシャーディングの分割キーに相当しますが、Cosmos DBではこれを自動で管理してくれます。一度設定したパーティションキーは変更できないため、コンテナ作成前の設計が非常に重要です。

良いパーティションキーの条件

・カーディナリティが高い（値の種類が多い）: `userId` や `orderId` など、多くの異なる値を持つフィールドが理想です。これにより、データが多数のパーティションに均等に分散されます。
・よく使うクエリのフィルタ条件と一致する: 多くのクエリでパーティションキーをWHERE句に含められるようにします。これにより「クロスパーティションクエリ」を回避でき、RU消費を抑えられます。
・書き込みが特定のキーに偏らない（ホットパーティション回避）: タイムスタンプを主キーにすると、最新時刻のパーティションに書き込みが集中してスループット上限に達しやすくなります。

悪いパーティションキーの例とその影響

パーティションキーの例	問題点
status（”active”/”inactive”）	値が2種類しかなく、データが2か所に偏る。分散効果がほぼゼロ。
createdAt（タイムスタンプ）	書き込みが最新パーティションに集中するホットスポット問題が発生。
country（日本国内のみ運用）	実質1種類のキーしか使われず分散効果ゼロ。
tenantId（10社のみのBtoBシステム）	10パーティションに分かれるが、大手1社への偏りがホットスポットになる可能性。

複合パーティションキーという選択肢

1フィールドのカーディナリティが低い場合、複数フィールドを結合したキーを使う方法があります。Cosmos DB NoSQL APIでは2026年以降、階層パーティションキー（Hierarchical Partition Keys）という機能が使えるようになり、最大3レベルのキー構成が可能です。例えば `tenantId` + `userId` の2段階にすることで、テナント単位の効率的なクエリと十分な分散を両立できます。

よくあるトラブルと対処法

【トラブル1】429エラー「Request rate is large」が頻発する

プロビジョニングしたRU/sの上限を超えたときに発生するエラーです。

対処法：
・スループットを増やす: Azureポータルでコンテナのスループットを増やします（即時反映されます）。一時的な対応として有効ですが、コスト増に直結するので根本対策も並行して行いましょう。
・クエリを最適化する: クロスパーティションクエリを排除し、WHERE句にパーティションキーを含めます。インデックスが当たっていないフィールドでのフィルタは特に重いです。
・SDK側のリトライロジックを活用する: Cosmos DB SDKはデフォルトで429エラー時に自動リトライします。`Retry-After-ms` ヘッダーの値に従って待機するため、アプリ側で独自にリトライを実装するよりSDKに任せるほうが安全です。

【トラブル2】クロスパーティションクエリで料金が跳ね上がる

パーティションキーをWHERE句に含まないクエリを実行すると、全パーティションを走査します。これがクロスパーティションクエリで、RU消費が急増します。

対処法：
・設計段階に立ち返り、頻繁に実行するクエリのフィルタ条件にパーティションキーを合わせます。
・分析目的のクロスパーティションクエリは、Cosmos DBではなくAzure Synapse Linkを経由してSynapse Analyticsで実行する方法があります。OLTP（トランザクション処理）と分析を分離することで、本番DBへの負荷とコストを抑えられます。

【トラブル3】「id」フィールドに関するエラー

Cosmos DBのすべてのアイテムには `id` フィールドが必須です。省略するとエラーになります。また、`id` は同一パーティション内でユニークである必要があります（異なるパーティション間では重複可能）。

RDB移行時に、既存のサロゲートキーをそのまま `id` に使うと、パーティションをまたいだ場合に重複が発生して予期しない動作につながることがあります。`id` の命名規則は移行設計の初期段階で決めておきましょう。

【トラブル4】Cosmos DBエミュレーターで動いたのに本番で動かない

Cosmos DBのローカル開発ではDockerイメージで動くエミュレーターを使いますが、エミュレーターはRU制限をチェックしないなど本番と挙動が異なる部分があります。開発中は問題なく動いていたのに、本番に上げたら429が多発したという事例は少なくありません。ステージング環境では本番に近いスループット設定で負荷テストを行うことを強く推奨します。

本記事のまとめ

Azure Cosmos DBは、RDB経験者にとって最初は概念が異なる部分が多いですが、設計の考え方を理解すれば現場でのパフォーマンスとコストの制御が可能になります。

ポイント	まとめ
APIの選択	新規開発はNoSQL API一択。MongoDB移行ならMongoDB API。変更不可なので慎重に。
料金単位	RU/sでスループットを管理。クエリ効率がコストに直結するため最適化必須。
パーティションキー	変更不可。カーディナリティ高・ホットスポット回避を最優先で設計する。
クロスパーティション	RU消費爆増の元。分析クエリはSynapse Linkで分離する設計が有効。
RDB vs Cosmos DB	JOIN多用の業務システムはSQL Database。スケール・グローバル展開重視はCosmos DB。

AWSのNoSQLであるAmazon DynamoDBとCosmos DBは概念が似ており、DynamoDBを先に理解しているとCosmos DBの設計も飲み込みやすくなります。クラウドDBの移行やLinuxサーバー上でのDB運用については、姉妹サイトLinuxMaster.JPでも実践的なノウハウを紹介しています。