Azure Cosmos DB distributed transactionsとは？Public Previewの変更点と確認ポイント

Azure Cosmos DBの「distributed transactions（分散トランザクション）」は、複数のアイテム、パーティション、コンテナー、データベースをまたぐ更新を、まとめて成功または失敗として扱えるようにするPublic Preview機能です。結論から言うと、注文作成と在庫更新、口座間送金、監査ログ記録のように「一部だけ成功すると困る処理」を、アプリケーション側の複雑な補償処理だけに頼らず実装しやすくなります。

ただし、すぐに本番へ入れてよい機能ではありません。2026年6月3日更新のMicrosoft Learnでは、この機能はPublic Previewであり、SLAなし、かつGA前に挙動・制限・対応シナリオが変わる可能性があると明記されています。対象もAzure Cosmos DB for NoSQLに限定され、アカウント構成やSDKにも条件があります。導入を検討する場合は、まず「自社のCosmos DBアカウントがプレビュー条件を満たすか」「既存のサガ、リトライ、補償処理を置き換えるべき箇所か」「マルチリージョン読み取りで整合性要件を満たせるか」を確認することが重要です。(Microsoft Learn)

Azure Cosmos DB distributed transactionsで何が変わるのか

今回のPublic Previewの中心は、Azure Cosmos DB for NoSQLで、複数の論理パーティション、複数コンテナー、複数データベースにまたがる読み取り・書き込みを、1つの分散トランザクションとして扱えるようになった点です。Microsoftの発表では、同一アカウント内のパーティション、コンテナー、データベースをまたぐ一連の書き込みを、すべてコミットするか、すべて適用しないかの単位で扱えると説明されています。(Microsoft for Developers)

従来のAzure Cosmos DBでは、Transactional BatchやストアドプロシージャによってACIDトランザクションを扱えましたが、基本的なスコープは同一コンテナー内の同一論理パーティションでした。つまり、同じパーティションキーを持つアイテム群であれば扱いやすい一方、別パーティションにある顧客データ、注文データ、監査イベントなどをまとめて原子的に更新するには、アプリケーション側でサガ、補償処理、冪等性制御、再試行ロジックを作り込む必要がありました。(Microsoft Learn)

観点	従来の主な選択肢	distributed transactionsのPublic Preview
トランザクション範囲	同一論理パーティション内が中心	複数論理パーティション、コンテナー、データベースをまたげる
主な実装	Transactional Batch、ストアドプロシージャ、サガ、補償処理	.NET SDKの分散トランザクションAPI
失敗時の扱い	アプリ側で巻き戻しや再試行を設計する場面が多い	一連の操作をまとめてコミット、またはロールバック
向いている処理	同じパーティションキー内の複数アイテム更新	口座間送金、注文と在庫、監査ログ、権限更新など
注意点	パーティション設計に強く依存	プレビュー制限、リージョン制約、SDK制約を確認する必要がある

重要なのは、これが「Cosmos DBのデータモデリングを考えなくてよくなる機能」ではないことです。パーティションキーは引き続きスケーラビリティ、RU消費、読み取り性能、ホットパーティション対策に大きく影響します。distributed transactionsは、どうしても分割されたデータを一貫した単位で扱う必要がある場面に使うべき機能です。

対象者：特に確認すべき管理者・開発者

このPublic Previewの影響を受けるのは、Azure Cosmos DBを単なるドキュメントストアとして使っているチームだけではありません。特に、業務整合性をアプリケーション側で担保しているシステムでは、設計や運用の見直し候補になります。

対象者	確認すべきこと
アプリケーション開発者	サガ、補償処理、手動ロールバック、冪等リトライで実装している処理を見直す
アーキテクト	パーティションキー設計とトランザクション境界の責務を再整理する
Azure管理者	対象アカウントがプレビュー条件を満たすか確認する
SRE・運用担当	RU消費、レイテンシ、429、失敗時の再試行、セカンダリリージョン読み取りを監視する
セキュリティ・ガバナンス担当	Public Preview、SLAなし、未対応機能の有無を本番利用基準に照らして判断する

特に注意したいのは、既存の本番アカウントがそのまま対象になるとは限らない点です。Microsoft Learnでは、NoSQL API、プロビジョニング済みスループット、パブリックAzureリージョン、単一書き込みリージョンなどの条件が示されています。また、Serverless、MongoDB/Cassandra/Table/Gremlin API、マルチリージョン書き込み、Customer-managed keys、Continuous backup、Hierarchical partition keysなどはプレビュー時点で未対応とされています。(Microsoft Learn)

利用できる主な操作とAPI

Public Previewでは、.NET v3 SDKに分散トランザクション用のAPIが追加されています。書き込みではCreateDistributedWriteTransaction()を使い、対象アイテムごとに操作をチェーンして、最後にCommitTransactionAsync()で一括コミットします。読み取りではCreateDistributedReadTransaction()を使い、複数パーティションや複数コンテナーに分かれたアイテムを、同じ時点のスナップショットとして読み取れます。(Microsoft Learn)

書き込みトランザクションでは、CreateItem、UpsertItem、ReplaceItem、PatchItem、DeleteItemを同じトランザクションに混在させられます。たとえば、口座Aを減額し、口座Bを増額し、別コンテナーに台帳レコードを作成する処理を、まとめて成功または失敗として扱う設計が可能になります。(Microsoft Learn)

DistributedTransactionResponse response = await client
    .CreateDistributedWriteTransaction()
    .ReplaceItem("banking", "accounts", new PartitionKey("account-A"), updatedAccountA)
    .ReplaceItem("banking", "accounts", new PartitionKey("account-B"), updatedAccountB)
    .CreateItem("banking", "ledger", new PartitionKey("2026-06"), ledgerEntry)
    .CommitTransactionAsync(CancellationToken.None);

この例で重要なのは、3つの操作を「順番に実行している」だけではなく、トランザクション単位としてまとめている点です。途中で一部の操作だけが成功して、残りが失敗した状態をアプリケーション側で修復する設計を減らせます。

プレビュー時点の制限と導入前チェック

Public Previewは検証用途として有用ですが、制限を理解せずに設計へ組み込むと、後からアカウント構成や運用要件と衝突します。Azure Updates上でも、In previewは非本番での利用とテストを想定したステータスとして説明されています。(マイクロソフト Azure)

確認項目	プレビュー時点の条件・制限	実務上の判断
API	NoSQL APIのみ	MongoDB、Cassandra、Table、Gremlin APIのワークロードは対象外
アカウント種別	プロビジョニング済みスループットのみ	Serverless利用中なら検証環境を分ける
リージョン	パブリックAzureクラウドリージョン	Sovereign、air-gapped、government cloudは対象外
書き込みリージョン	単一書き込みリージョン	マルチリージョン書き込み構成は対象外
SDK	.NET v3 SDKのプレビュー版	Java、Python、Node.jsなどの本番コードは対応状況を待つ
トランザクション上限	最大100操作、最大2MB	大きなバッチ処理には向けない
SLA	Public PreviewのためSLAなし	本番導入は組織の基準に照らして慎重に判断する

Microsoft Learnでは、プレビュー機能のセルフサービス登録はAzure portal、Azure CLI、PowerShellからは利用できず、オンボーディングフォームによる申請が必要とされています。申請は通常1〜2営業日で処理されると説明されていますが、実際の適用タイミングは環境や運用状況に依存する可能性があるため、検証計画には余裕を持たせるべきです。(Microsoft Learn)

管理者が確認すべき設定ポイント

管理者は、まず対象アカウントがプレビュー条件を満たすかを棚卸ししてください。特に、既存環境でContinuous backup、Customer-managed keys、Hierarchical partition keys、Per-partition automatic failoverなどを使っている場合、プレビュー時点のdistributed transactionsとは併用できない条件に該当する可能性があります。(Microsoft Learn)

次に確認すべきは権限です。Microsoft Learnでは、本番用途ではMicrosoft Entra IDの利用が推奨され、トランザクションに参加する各コンテナーに対して、利用するIDがデータプレーンの書き込み権限を持つ必要があると説明されています。ロールチェックはトランザクション内の個々の操作ごとに行われるため、一部のコンテナーだけ権限が不足していると、トランザクション全体の失敗要因になります。(Microsoft Learn)

管理者向けの実務チェックは次の順番で進めると安全です。

手順	確認内容
アカウント棚卸し	API、スループット種別、リージョン、書き込みリージョン数を確認する
未対応機能の確認	CMK、Continuous backup、HPK、PPAFなどの利用有無を確認する
検証環境の分離	本番アカウントではなく、同等構成の検証用アカウントを用意する
登録申請	オンボーディングフォームから対象アカウントの有効化を申請する
権限確認	トランザクション対象のすべてのコンテナーにデータプレーン権限を付与する
監視準備	RU消費、429、レイテンシ、失敗レスポンス、再試行回数を確認できるようにする

開発者が見直すべき実装ポイント

開発者は、既存コードのうち「一部だけ成功すると業務的に壊れる処理」を優先して洗い出してください。たとえば、注文作成、在庫引当、ポイント付与、監査イベント作成を別々のコンテナーに書いている場合、現在はどこかで失敗したときの補償処理が必要です。distributed transactionsを使うと、このうちCosmos DB内で完結する更新については、より直接的に原子性を表現できます。

一方で、すべてのサガやアウトボックス処理が不要になるわけではありません。Service Bus、外部API、別データベース、決済サービスなど、Cosmos DB外部の処理はこの分散トランザクションの対象外です。イベント発行の信頼性が必要な場合は、Azure Cosmos DBのChange Feed、Transactional Batch、Service Busを組み合わせるTransactional Outboxパターンが引き続き有効な選択肢になります。(Microsoft Learn)

実装時は、次の判断基準を使うと過剰利用を避けられます。

処理パターン	推奨判断
同一パーティションキー内の複数アイテム更新	既存のTransactional Batchを優先する
複数パーティションにまたがるが、同時成功が必須	distributed transactionsを検証候補にする
外部APIやメッセージ送信も含む	Outboxや冪等処理を併用する
100操作または2MBを超える可能性がある	トランザクション境界を小さく再設計する
単に実装を楽にしたいだけ	RU、レイテンシ、障害時挙動を測ってから判断する

特に、トランザクションを大きくしすぎないことが重要です。業務上の不変条件、つまり「この整合性だけは必ず守る」という最小単位に絞って設計してください。注文処理であれば「注文ヘッダー、在庫引当、監査イベント」までは1つの候補になりますが、メール送信、検索インデックス更新、外部CRM連携まで同じ境界に入れようとすると、設計が不自然になります。

マルチリージョン構成での注意点

マルチリージョン利用時は、分散トランザクションがどこで原子性を保証するのかを正しく理解する必要があります。Microsoft Learnでは、プレビュー時点のdistributed transactionsは書き込みリージョン内で原子的であり、マルチリージョン書き込みアカウントは未対応とされています。また、SDKはトランザクションの読み書きを書き込みリージョンへルーティングし、コミット済みデータはセカンダリリージョンへ非同期に複製されます。(Microsoft Learn)

このため、セカンダリリージョンで読み取るアプリケーションは、一時的に部分的な更新を観測する可能性があります。グローバルなread-after-write整合性が必要な場合は、読み取りをwrite regionに向ける、またはアカウントレベルでStrong consistencyとコミットレスポンスのセッショントークンを使う選択肢が示されています。(Microsoft Learn)

実務では、次のように切り分けると判断しやすくなります。

要件	確認ポイント
ユーザーが更新直後に同じ画面で結果を見る	書き込みリージョンへの読み取りルーティングを検討する
セカンダリリージョンで参照専用画面を表示する	一時的な遅延や部分反映を許容できるか確認する
金融、在庫、権限などで即時整合性が必要	整合性レベル、セッショントークン、読み取りリージョンを設計に含める
障害時のリージョン切り替えがある	フェイルオーバー時のトランザクション境界と再試行をテストする

移行・展開時に失敗しやすいポイント

導入で失敗しやすいのは、「サガを消せる」「パーティション設計を気にしなくてよい」と早合点するケースです。distributed transactionsは強力ですが、Cosmos DBのスケール設計を置き換えるものではありません。むしろ、どのデータを同時に守るべきかを明確にすることで効果を発揮します。

失敗を避けるには、既存処理をいきなり置き換えず、次の流れで段階的に検証してください。

フェーズ	実施内容
現状分析	補償処理、手動リカバリー、整合性チェックバッチがある箇所を洗い出す
候補選定	複数パーティション・複数コンテナーにまたがり、同時成功が必須の処理に絞る
環境確認	プレビュー条件に合う検証アカウントを用意する
小規模実装	1つの業務シナリオだけを対象にAPIを試す
障害テスト	タイムアウト、競合、権限不足、429、部分失敗を意図的に発生させる
性能測定	従来実装とRU、レイテンシ、再試行回数を比較する
展開判断	Preview制限と自社の本番利用基準を照らして採用範囲を決める

特に、既存の補償処理を削除するタイミングには注意が必要です。Public Preview中は仕様変更の可能性があります。まずはFeature Flagで切り替えられる形にし、問題が起きた場合に従来フローへ戻せる設計にしておくと安全です。

活用シーンの具体例

最も分かりやすい活用例は、口座間送金です。送金元の残高を減らし、送金先の残高を増やし、台帳に記録する処理で、どれか1つだけ成功すると業務データが壊れます。これらが異なるパーティションやコンテナーに分かれている場合、distributed transactionsの効果が出やすい領域です。

ECサイトでは、注文レコードの作成、在庫引当、監査イベントの記録が候補になります。これまでは、在庫更新だけ成功して注文作成が失敗した場合の巻き戻し、または注文だけ作られて在庫が引き当てられない場合の補正が必要でした。分散トランザクションを使えば、Cosmos DB内の関連更新について「すべて成功しなければ反映しない」という設計を取りやすくなります。

マルチテナントSaaSでは、ユーザー情報、テナント所属、権限ドキュメントを別々のパーティションキーで管理しているケースがあります。ユーザー追加時に権限だけ作成されない、または所属だけ残ると、認可バグや運用事故につながります。こうした「複数エンティティの状態が必ず一致しているべき処理」は、検証対象として優先度が高いといえます。

今すぐ確認すべきこと

Azure Cosmos DB distributed transactionsのPublic Previewは、アプリケーション側で抱えていたクロスパーティション整合性の負担を減らせる重要な更新です。ただし、Public Previewである以上、対象API、アカウント構成、SDK、リージョン、SLA、未対応機能を確認せずに採用するのは危険です。

まず行うべきことは、既存のCosmos DBワークロードから「同一パーティション内で完結しないが、同時成功が必要な処理」を洗い出すことです。そのうえで、対象アカウントがプレビュー条件を満たすか、検証環境を分けられるか、既存の補償処理を安全に切り替えられるかを確認してください。

同一パーティション内で完結する処理は、引き続きTransactional Batchが有力です。複数パーティションや複数コンテナーにまたがる業務不変条件がある場合に限り、distributed transactionsを検証候補にする。この線引きを明確にすることが、今回のPublic Previewを安全かつ実務的に活用する第一歩です。