Azure Cosmos DBの運用で「RU使用率が高いから、とりあえずスループットを増やす」と判断していないでしょうか。2026年5月に公開された公式ブログ「Azure Cosmos DB Conf 2026 Recap: Lessons from Production」で強調されている結論は、本番環境の性能問題は、単純なRU不足ではなく、パーティション設計・クエリ形状・データモデルの問題として現れることが多いという点です。実際、100%近いRU使用率、スロットリング、P99レイテンシ悪化に悩んでいたチームは、スループットを増やさず、特定の論理パーティションに80%以上のトラフィックが集中していた原因を修正することで、RU使用率を20〜35%まで下げた事例が紹介されています。(Microsoft for Developers)
この記事では、Azure Cosmos DB Conf 2026の公式Recapをもとに、Azure Cosmos DBを本番運用する管理者・開発者が確認すべき変更点、影響範囲、設定・移行・展開時の注意点を実務目線で整理します。
Azure Cosmos DB Conf 2026 Recapの要点は「スケール障害は設計障害として現れる」
公式Recapで繰り返し語られているのは、Azure Cosmos DBが悪い設計を作るのではなく、悪い設計を早い段階で可視化するという考え方です。OpenAI、Vercel、Walmartなどの事例でも、問題の中心は単なるスペック不足ではなく、データモデリング、パーティションキー、クエリ設計、インデックス、Change Feed、AIエージェントのメモリ設計でした。(Microsoft for Developers)
特に重要なのは、Azure Cosmos DBの本番運用では次のような判断が求められることです。
| 観点 | よくある誤解 | 実務での判断基準 |
|---|---|---|
| RU使用率 | 高いならRUを増やす | どの論理パーティションが消費しているかを見る |
| スロットリング | 429が出たらリトライを強化する | リトライで負荷が増幅していないか確認する |
| パーティションキー | 一意性が高ければよい | 実際のアクセスパターンで均等に分散するかを見る |
| クエリ | SQLとして正しければよい | クロスパーティションか、ポイント読み取りかを確認する |
| AI/RAG用途 | ベクトルDBを別に足せばよい | 運用データ、ベクトル、検索、履歴をどう同じ設計に載せるかを見る |
今回のRecapは、新機能の羅列ではなく、本番で失敗しないための設計原則の再確認として読むべき内容です。
何が変わるのか：RU追加より「使えるRU」に注目する流れが強まる
Azure Cosmos DBでは、プロビジョニングしたスループットが物理パーティションに分散されます。公式ブログでは、たとえば40,000 RU/sを4つの物理パーティションで持つ場合、各パーティションは10,000 RU/sを受け持つため、トラフィックが1つのパーティションに偏ると、有効に使えるスループットは実質10,000 RU/sに近くなると説明されています。(Microsoft for Developers)
つまり、管理者が確認すべきなのは「合計RUが足りているか」だけではありません。次の問いが重要です。
- 特定のテナント、ユーザー、店舗、デバイス、連携アカウントに負荷が集中していないか
- 429 Too Many Requestsが全体ではなく一部の論理パーティションで発生していないか
- リトライが連鎖して、さらにRUを消費していないか
- P99レイテンシ悪化が、ホットパーティションに起因していないか
公式Recapの事例では、userIdをパーティションキーにしていたものの、ある自動連携アカウントが大量の書き込みを発生させていました。そのため、見た目には自然なuserIdでも、本番ではホットパーティションを作る原因になっていました。(Microsoft for Developers)
「よいパーティションキー」はデータの分類ではなくアクセスの分散で決める
パーティションキーは「データが何であるか」を表す項目ではなく、「どのようにアクセスされるか」を表す設計要素です。
たとえば、注文データを扱う場合、単純にtenantIdだけをパーティションキーにすると、大規模テナントだけが突出して負荷を持つ可能性があります。一方で、アクセスパターンが「テナント別・ステータス別・期間別のダッシュボード表示」であれば、tenantId、status、timeBucketのように、読み取りパターンに合わせて分散を設計する選択肢があります。
公式ドキュメントでも、Azure Cosmos DBはパーティションキーに基づいて論理パーティションと物理パーティションへデータを分散し、水平スケーリングを実現すると説明されています。階層パーティションキーを使うと、最大3レベルのキー階層を構成し、データ分散とスケールを最適化できます。(Microsoft Learn)
影響範囲：本番運用中のアプリほど見直し効果が大きい
今回のRecapで示された教訓は、これからAzure Cosmos DBを使い始めるチームだけでなく、すでに本番稼働しているシステムにも大きく関係します。
特に影響を受けやすいのは、次のような環境です。
| 対象 | 見直すべきポイント |
|---|---|
| マルチテナントSaaS | 大口テナントや連携アカウントがホットパーティション化していないか |
| EC・在庫・注文管理 | ステータス検索や期間検索がクロスパーティションになっていないか |
| IoT・イベント収集 | デバイスIDや拠点ID単位で書き込みが集中していないか |
| AIチャット・エージェント | 会話履歴、ベクトル、検索インデックスが同じアクセス単位で扱えるか |
| 移行案件 | 既存RDBやMongoDBのキー設計をそのまま持ち込んでいないか |
Azure Cosmos DBは、アプリケーションが成長した後にパーティションキーを簡単に差し替えるのが難しいサービスです。そのため、既存システムでは「今すぐ変える」よりも、まずホットスポットを観測し、影響の大きいコンテナーから段階的に再設計するのが現実的です。
開発者が確認すべき設定：クエリ形状とインデックスをRU目線で見る
公式Recapでは、クエリ種別によるRU消費の差も強調されています。クロスパーティションクエリは多くのパーティションにファンアウトする一方、パーティションキーを指定したクエリは対象を絞れます。ポイント読み取りはさらに効率的です。公式ブログでは、典型例としてクロスパーティションクエリが100〜400 RU、パーティションフィルター付きクエリが2〜4 RU、ポイント読み取りが約1 RUと紹介されています。(Microsoft for Developers)
たとえば、次のようなクエリは一見シンプルでも、ホットパスで多用するとコストとレイテンシの原因になります。
SELECT * FROM orders WHERE status = 'pending'このクエリは、テナントをまたいでpendingの注文を探すため、設計によってはクロスパーティションになりやすいです。実務では、次のようにアクセス単位を明示するほうが安全です。
SELECT * FROM orders
WHERE tenantId = @tenantId
AND status = 'pending'ただし、単にWHERE句を足せばよいわけではありません。パーティションキーとクエリ条件が合っていなければ、期待したRU削減にならない場合があります。
インデックスは「読むため」だけでなく「書き込みコスト」も見る
Azure Cosmos DBでは、既定のインデックス設定により多くのクエリを扱いやすくなります。一方で、すべての項目を広くインデックス化すると、書き込み時のRU消費が増えることがあります。公式Recapでも、パーティション、インデックス、クエリ形状を見直してコストを削減した事例が紹介されています。(Microsoft for Developers)
開発者は、次のような確認を行うべきです。
| 確認項目 | 実務での見方 |
|---|---|
| よく使う検索条件 | パーティションキーと一緒に指定されているか |
ORDER BY | 必要なインデックスがあるか、不要な並べ替えをしていないか |
| 大量取得 | ページング、投影、集計の設計が適切か |
| 書き込み頻度 | 不要なプロパティまでインデックス化していないか |
| RU測定 | ローカルや検証環境でもクエリごとのRUを確認しているか |
本番投入前のレビューでは、「このクエリは正しいか」ではなく、このクエリは本番のアクセス量で安定して安いかを確認することが重要です。
管理者が確認すべき設定：可用性、フェイルオーバー、監視
Recapでは、階層パーティションキー、パーティションレベルの自動フェイルオーバー、フリート全体のスループット管理、可用性向上なども取り上げられています。(Microsoft for Developers)
ただし、これらは「有効にすればすべて解決する」機能ではありません。管理者は、現在のアカウント構成、リージョン構成、SDK、バックアップ、監視項目をセットで確認する必要があります。
パーティションレベル自動フェイルオーバーはプレビュー条件に注意する
Microsoft Learnでは、Per Partition Automatic FailoverはPublic Previewとして説明されており、プレビュー機能にはSLAが付かない旨が記載されています。(Microsoft Learn)
そのため、本番環境で検討する場合は、次の点を確認してください。
| 確認項目 | 注意点 |
|---|---|
| 機能の提供状態 | プレビューか一般提供かを必ず確認する |
| SLA | プレビュー機能に依存した可用性設計にしない |
| 対象リージョン | 利用中リージョンでサポートされるか確認する |
| SDK設定 | 障害時のルーティング、再試行、タイムアウトを確認する |
| 運用手順 | フェイルオーバー時の監視・通知・復旧確認を決める |
可用性機能は、設計ミスを隠すものではありません。ホットパーティションやリトライ増幅が残っていると、障害時にさらに影響が大きくなる可能性があります。
AIエージェント時代の変更点：データベースは「記憶」の設計になる
2026年のRecapで特徴的なのは、AIエージェントやRAGにおけるAzure Cosmos DBの役割が強く打ち出されている点です。公式ブログでは、LLMはステートレスであり、メモリ戦略がコスト、検索品質、ユーザー体験に影響すると説明されています。会話履歴、ベクトル埋め込み、全文検索、ハイブリッド検索を、同じパーティション設計の中で扱う重要性が示されています。(Microsoft for Developers)
Azure Cosmos DB for NoSQLでは、ベクトル検索と全文検索スコアリングを組み合わせるハイブリッド検索がサポートされています。Microsoft Learnでは、Reciprocal Rank Fusionを使ってベクトル検索と全文検索を組み合わせる機能として説明されています。(Microsoft Learn)
AIアプリで確認すべきポイントは次の通りです。
| 用途 | 設計ポイント |
|---|---|
| チャット履歴 | sessionIdやuserId + sessionIdなど、読み返し単位で分散する |
| セマンティックキャッシュ | 同じ問い合わせや類似問い合わせを安く再利用できるようにする |
| RAG | ベクトルだけでなく、テナント、権限、時刻、カテゴリで絞り込めるようにする |
| エージェントメモリ | 短期記憶、長期記憶、エンティティ情報を分けて考える |
| コスト管理 | トークンコストとRUコストを両方測る |
よくある失敗は、デモ段階では少量の会話履歴とベクトル検索で問題なく動くものの、本番でユーザー数、会話数、検索回数が増えた瞬間に、外部ベクトルDB、キャッシュ、RDB、キューが複雑に絡み合うことです。Azure Cosmos DBを使う場合は、最初から「検索の精度」だけでなく、「どの単位で記憶を読み書きするか」を決める必要があります。
Change Feedの活用：状態を直接読むよりイベントから派生させる
公式Recapでは、成熟したアーキテクチャとして、変更可能な状態を直接共有するのではなく、イベントを記録し、必要な読み取りモデルを派生させる考え方も紹介されています。Azure Cosmos DBのChange Feedは、コンテナーごとの変更を順序付き・パーティション単位で扱える仕組みとして説明されています。(Microsoft for Developers)
Microsoft Learnでは、Change Feedの「all versions and deletes」モードにより、作成、更新、削除を含む変更を確認できる一方、このモードを使うには継続的バックアップが構成されている必要があると説明されています。(Microsoft Learn)
Change Feedを展開する際は、次の点を事前に決めておくべきです。
| 項目 | 確認内容 |
|---|---|
| モード | 最新版のみで足りるか、削除や中間更新も必要か |
| バックアップ | all versions and deletesを使う場合、継続的バックアップ要件を満たすか |
| 再処理 | continuation tokenやチェックポイントをどう管理するか |
| 冪等性 | 同じイベントを再処理しても結果が壊れないか |
| 派生先 | 読み取り用コンテナー、検索インデックス、分析基盤などを分けるか |
特にイベント駆動設計では、「一度だけ実行されるはず」という前提は危険です。リトライ、再起動、チェックポイント復旧を考慮し、処理は冪等に設計する必要があります。
移行時の注意点：既存DBの構造をそのまま持ち込まない
Azure Cosmos DBへの移行では、RDBやMongoDBの既存スキーマをそのまま移すだけでは、期待した性能やコストにならないことがあります。公式Recapでも、MongoDB互換の移行と、RDBMSからCosmos DB Agent Kitを使って非正規化されたドキュメントモデルへ移行するアプローチが紹介されています。どちらのケースでも、最終的な教訓は「アクセスパターン設計を飛ばせない」という点です。(Microsoft for Developers)
移行前には、最低限次の棚卸しを行いましょう。
| 棚卸し項目 | 確認すること |
|---|---|
| 主要アクセスパターン | どの画面・APIが、どの条件で、どの頻度で読むか |
| 書き込み集中 | バッチ、連携、Webhook、IoTなどが偏らないか |
| トランザクション要件 | 同一論理パーティション内で完結できるか |
| 集計・検索 | Cosmos DBで直接行うか、派生ビューや分析基盤に逃がすか |
| 移行方式 | オフライン移行か、CDCを使ったオンライン移行か |
| カットオーバー | 差分同期、検証、ロールバック手順を用意するか |
移行で失敗しやすいのは、「現行DBで動いているから同じ構造でよい」と判断することです。Azure Cosmos DBでは、正規化されたテーブル構造よりも、読み取り単位に合わせたドキュメント設計や、Change Feedによる読み取りモデルの分離が有効になる場合があります。
展開前チェックリスト：本番投入前に見るべきポイント
Azure Cosmos DBの新規開発・移行・機能追加では、次のチェックリストを使うと、RU不足に見える設計問題を早めに見つけやすくなります。
| チェック項目 | OKの目安 |
|---|---|
| パーティションキー | 高頻度アクセスが特定キーに偏らない |
| クエリ | ホットパスでクロスパーティションクエリを多用していない |
| RU測定 | 主要APIごとのRU、P95/P99レイテンシを測っている |
| リトライ | 429発生時に無制限リトライや同時再試行をしていない |
| インデックス | 読み取り要件と書き込みコストの両方を見ている |
| Change Feed | 冪等性、チェックポイント、削除検知の要件を決めている |
| 可用性 | リージョン、フェイルオーバー、SDK、監視をセットで確認している |
| 移行 | 既存スキーマではなくアクセスパターンから再設計している |
このチェックで問題が出た場合、最初にやるべきことはRU増強ではありません。Azure MonitorやCosmos DBのメトリックを使い、どの操作、どのパーティションキー、どのクエリが負荷を作っているかを特定することです。
管理者・開発者が今すぐ取るべき行動
今回のAzure Cosmos DB Conf 2026 Recapから実務に落とし込むなら、まず次の順番で確認すると効果的です。
1つ目は、RU使用率と429の発生箇所をコンテナー単位ではなく、可能な限りパーティションキーや操作単位で確認することです。全体の平均値だけを見ると、ホットパーティションを見落とします。
2つ目は、主要クエリを棚卸しし、クロスパーティション、パーティションフィルター付きクエリ、ポイント読み取りに分類することです。特に高頻度APIでは、1回あたりのRU差が月額コストとP99レイテンシに直結します。
3つ目は、AI・検索・イベント処理の新機能を追加する前に、既存のパーティション設計と整合するかを確認することです。ベクトル検索やChange Feedは強力ですが、アクセス単位がずれていると、設計の複雑さだけが増えます。
Azure Cosmos DBの本番運用で重要なのは、「どれだけRUを持っているか」ではなく、そのRUをアプリケーションが均等かつ予測可能に使える設計になっているかです。今回のRecapは、スケールするシステムほど、データモデル、パーティションキー、クエリ、イベント設計を早い段階で見直すべきだという実践的な警告として読むべきでしょう。
コメント