Azure Cosmos DB all versions and deletes change feed modeがGA：削除・中間更新を拾う実装と注意点

Azure Cosmos DBの「all versions and deletes change feed mode」は、コンテナー内で発生した作成・更新・削除を、変更フィードからより細かく追跡できるモードです。結論から言うと、削除を含む監査ログ、外部システムへのリアルタイム同期、TTL期限切れを起点にした後続処理を実装している環境では、今回のGAによって設計を見直す価値があります。Microsoftの公式告知では、Azure Cosmos DB for NoSQL向けにこのモードが一般提供され、従来は見えにくかった削除や中間更新をChange Feedで扱えるようになったことが示されています。(Microsoft for Developers)

ただし、既存のAzure Cosmos DBトリガーやChange Feed Processorをそのまま切り替えればよい、という単純な更新ではありません。利用にはContinuous backupの有効化が必要で、対象はAzure Cosmos DB for NoSQLに限定されます。また、読み取れる変更はバックアップ保持期間内に限られ、削除時に削除前ドキュメント全体が取得できるわけでもありません。導入前に「何を記録したいのか」「どこまで過去を追跡したいのか」「既存のsoft delete実装を残すのか」を整理することが重要です。(Microsoft Learn)

Azure Cosmos DB all versions and deletes change feed modeで何が変わるのか

今回の更新の中心は、Azure Cosmos DBのChange Feedで扱える変更イベントの粒度が広がったことです。従来からある既定のlatest versionモードでは、作成・更新されたアイテムの最新状態を取得できますが、削除はChange Feedに出てきません。また、読み取りまでの間に同じアイテムが複数回更新された場合、途中の状態ではなく最後の状態だけが見える仕組みです。(Microsoft Learn)

一方、all versions and deletesモードでは、作成、更新、削除の各変更を順序付きで取得できます。明示的な削除だけでなくTTLによる期限切れ削除も扱え、変更の種類を示すメタデータも含まれます。これにより、監査ログ、削除検知、外部データストアへの同期、イベントソーシングに近い処理をAzure Cosmos DBのChange Feedから実装しやすくなります。(Microsoft for Developers)

今回の更新は、Azure Cosmos DBのAIやCopilotそのものの機能追加ではありません。管理者や開発者が見るべきポイントは、Cosmos DBアカウントのバックアップ構成、Change Feedの読み取り方式、Azure FunctionsやSDKの実装、lease containerの設計です。

従来のlatest version modeとの違い

Azure Cosmos DBのChange Feedには、用途に応じて選ぶべきモードがあります。既存システムでChange Feedを使っている場合は、まず次の違いを確認してください。

観点	latest version mode	all versions and deletes mode
取得できる変更	作成・更新の最新状態	作成・更新・削除
削除イベント	取得できない	取得できる
TTL期限切れ	削除としては取得できない	TTL期限切れによる削除も取得できる
中間更新	同じアイテムが複数回更新された場合、最後の状態だけになることがある	読み取り間に発生した中間更新も取得できる
取得できる期間	コンテナーの先頭、特定時点、現在、チェックポイントなどから読み取り可能	Continuous backupの保持期間内。開始は「now」または保持期間内のチェックポイント
主な用途	検索インデックス更新、キャッシュ更新、移行、単純なリアルタイム処理	監査、削除検知、soft deleteの簡素化、外部同期、イベント処理
主な注意点	削除を拾うにはsoft deleteなどの工夫が必要	Continuous backupが必須。削除前の完全なドキュメントは取得できない

重要なのは、all versions and deletesモードが既定モードを置き換えるものではない点です。Microsoftの告知では、アカウント側で機能を有効化したうえで、processor、trigger、pull mode iteratorごとにどちらのモードを使うか選べると説明されています。同じコンテナーに対して、latest version modeの処理とall versions and deletes modeの処理を、別々のlease containerで並行稼働させることもできます。(Microsoft for Developers)

影響を受けるシステム

今回のGAで特に影響を受けるのは、「削除を正確に拾えないために、アプリケーション側で回避策を入れていたシステム」です。

たとえば、検索インデックス、データウェアハウス、キャッシュ、別クラウドのデータベースにCosmos DBの内容を同期している場合、削除イベントを拾えないと同期先に古いデータが残ります。これまではisDeletedのようなsoft deleteフラグを追加し、一定期間後にTTLで削除する設計がよく使われていました。all versions and deletes modeを使うと、削除をChange Feedから直接扱えるため、同期処理を簡素化できる可能性があります。

導入メリットが大きいケース

ケース	期待できる効果
監査ログを残したい	作成・更新・削除の発生をChange Feedで追跡しやすくなる
外部システムへ同期している	削除を同期先に反映しやすくなる
TTL期限切れを処理の起点にしたい	TTLによる削除を検知して後続処理を実行できる
同じアイテムの短時間連続更新を追いたい	読み取り間の中間更新を取りこぼしにくくなる
soft deleteの実装が複雑化している	`deleted`フラグや削除遅延の運用を見直せる

すぐに切り替えないほうがよいケース

すべてのChange Feed利用環境で新モードを使うべきとは限りません。次のような場合は、従来のlatest version modeのほうが扱いやすい可能性があります。

ケース	理由
最新状態だけ分かれば十分	中間更新や削除まで取得すると処理量が増える
過去の全履歴を無期限に再処理したい	all versions and deletes modeはContinuous backup保持期間の制約を受ける
削除前の完全なドキュメントが必要	削除イベントでは主にid、partition key、TTLかどうかなどのメタデータを扱う
NoSQL以外のAPIを使っている	all versions and deletes modeはAzure Cosmos DB for NoSQL向け
Continuous backupを有効化できない	このモードの前提条件を満たせない

管理者が最初に確認すべき設定

管理者は、コード変更より先にAzure Cosmos DBアカウントの前提条件を確認する必要があります。特にContinuous backup、対象API、リージョン、コスト、既存のパーティション構成を確認せずに進めると、検証環境では動いても本番展開で詰まりやすくなります。

確認項目	見るべきポイント	判断基準
対象API	Azure Cosmos DB for NoSQLか	NoSQL以外では対象外として扱う
Continuous backup	有効化済みか、保持期間は7日か30日か	読みたい変更期間と保持期間が合うか確認する
バックアップコスト	Continuous backupのストレージ・復元コスト	本番データ量とリージョン数で見積もる
機能有効化	FeaturesページまたはREST APIで有効化するか	変更管理の手順に組み込む
有効化中の制約	有効化には最大30分かかる場合があり、その間はアカウントに他の変更を加えられない	メンテナンス時間帯で作業する
partition merge	過去にpartition mergeした、または有効化中のアカウントか	該当する場合はサポート対象外に注意
ネットワーク経路	all versions and deletesのChange Feed要求はGateway modeを使う	Direct mode前提の性能見積もりを流用しない
権限	FunctionやアプリからCosmos DBへ接続する権限	管理プレーン権限だけでなくデータプレーンの権限を確認する
lease container	既存処理と新処理で共有していないか	並行稼働する処理ごとに分ける

Microsoft Learnでは、all versions and deletes modeを使うにはContinuous backupが必要で、読み取れる変更はContinuous backup期間内に限られると説明されています。また、機能有効化はAzure PortalのFeaturesページから行え、有効化完了まで最大30分かかる場合があります。(Microsoft Learn)

Continuous backup自体にも運用上の確認が必要です。Microsoft Learnでは、Continuous backupの保持期間として7日と30日のティアが示され、30日ティアではバックアップストレージの月額料金が発生し、復元にはティアにかかわらず料金が発生すると説明されています。料金はリージョンや構成で変わるため、本番導入前にAzure Pricing Calculatorや最新の価格ページで確認してください。(Microsoft Learn)

開発者が確認すべき実装ポイント

開発者が最も注意すべき点は、「取得できるデータの形がlatest version modeと違う」ことです。all versions and deletes modeでは、変更ごとにcurrentとmetadataのような情報を扱います。作成・更新では現在のドキュメントを取得できますが、削除ではcurrentが存在せず、id、partition key、TTL期限切れかどうかなどのメタデータを見て処理します。(Microsoft Learn)

operationTypeで処理を分ける

実装では、「ドキュメントがあるかどうか」だけで判断せず、必ずoperation typeを見て分岐する設計にします。

[Function(nameof(OrderChangeFeedFunction))]
public void Run(
    [CosmosDBTrigger(
        databaseName: "store-db",
        containerName: "orders",
        Connection = "CosmosDBConnection",
        LeaseContainerName = "leases-avd",
        CreateLeaseContainerIfNotExists = true,
        ChangeFeedMode = CosmosDBChangeFeedMode.AllVersionsAndDeletes)]
    IReadOnlyList<ChangeFeedItem<Order>> changes)
{
    foreach (var change in changes)
    {
        switch (change.Metadata.OperationType)
        {
            case ChangeFeedOperationType.Create:
                // 作成時の処理
                break;

            case ChangeFeedOperationType.Replace:
                // 更新時の処理
                break;

            case ChangeFeedOperationType.Delete:
                // 削除時の処理
                // change.Currentはnullになる前提で、Metadata.IdやPartitionKeyを使う
                break;
        }
    }
}

GA告知では、Azure FunctionsのCosmos DB triggerでChangeFeedMode = CosmosDBChangeFeedMode.AllVersionsAndDeletesを指定する例が示されています。Azure Functions triggerでの対応は、.NET isolated workerとin-process hosting modelが対象で、他言語のサポートは今後追加予定とされています。(Microsoft for Developers)

.NET Functionsではパッケージ版を確認する

Azure Functionsで使う場合は、ホスティングモデルに応じたNuGetパッケージのバージョン確認が必要です。NuGet上では、Microsoft.Azure.Functions.Worker.Extensions.CosmosDBとMicrosoft.Azure.WebJobs.Extensions.CosmosDBの4.16.1が確認でき、WebJobs側のパッケージにはMicrosoft.Azure.Cosmos >= 3.60.0への依存も記載されています。([NuGet][4])

新規実装では、可能であれば.NET isolated workerを優先して検討してください。Microsoft Learnでは、Azure Functionsのin-process modelは2026年11月10日にサポート終了予定と案内されています。既存のin-process Functionで今回のモードを使う場合でも、中長期的にはisolated workerへの移行計画を別途持っておくべきです。(Microsoft Learn)

変更前のドキュメントは取得できない

all versions and deletesという名称から、「更新前や削除前の完全なドキュメントも取れる」と誤解しがちです。しかし、Microsoft Learnでは、replaceやdelete操作について以前のバージョンを取得する方法は現在ないと説明されています。(Microsoft Learn)

たとえば、金額変更の前後差分を必ず残したい場合は、Change Feedだけに依存せず、アプリケーション側で変更前後の値を監査ログ用コンテナーに書く、または更新イベントを別途イベントストアに保存する設計が必要です。

順序と遅延を前提にする

all versions and deletes modeでは変更順序が保持されますが、実務では「完全に直感どおりの順番で常に届く」と考えるのは危険です。Microsoft Learnでは、変更は変更時刻順に届く一方、transactional batch、stored procedure、bulk mode request内のアイテムは同じ変更時刻を持つことがあり、その範囲内の順序は任意になる場合があると説明されています。また、TTL削除は期限切れ直後ではなく、コンテナーからパージされた時点でフィードに現れる点にも注意が必要です。(Microsoft Learn)

そのため、下流処理では冪等性を持たせることが重要です。たとえば、同期先に同じ削除イベントが再送されてもエラーにしない、更新イベントがリトライされても二重登録にならない、という設計にしておきます。

移行・展開の進め方

既存のChange Feed処理を本番で使っている場合、いきなり置き換えるのではなく、別系統のconsumerとして追加し、挙動を比較する進め方が安全です。

手順	実施内容	失敗を防ぐポイント
現状調査	Change Feedを使っているFunction、Processor、pull model、lease containerを洗い出す	どの処理が同じコンテナーを監視しているか確認する
要件整理	削除、中間更新、TTL、監査、同期のどれが必要か決める	「取れるから取る」ではなく用途を明確にする
検証環境準備	NoSQLアカウントでContinuous backupを有効化する	本番と同じ保持期間・リージョン構成に近づける
機能有効化	all versions and deletes change feed modeを有効化する	有効化中に他のアカウント変更を入れない
別consumer実装	既存処理とは別のlease containerまたはprefixで起動する	既存のlatest version処理を止めずに比較する
テストデータ投入	create、replace、連続replace、delete、TTL削除を実行する	期待するoperationTypeとmetadataが取れるか確認する
負荷検証	書き込みが多い時間帯を想定して処理量を測る	中間更新を拾う分、イベント数が増える前提で見る
段階展開	監査ログなど影響の小さい用途から本番投入する	いきなり同期基盤の主経路を置き換えない
運用移行	soft deleteや既存補助処理を残すか廃止するか決める	一定期間は二重記録で差分を比較する

特に注意したいのは、同じコンテナーに対して複数のAzure Functions triggerを構成する場合です。Microsoft Learnでは、同じコレクションに複数のFunctionを設定する場合、専用のlease collectionを使うか、異なるleaseCollectionPrefixを指定しないと、片方しかトリガーされない可能性があると説明されています。(Microsoft Learn)

失敗しやすいポイント

削除前のデータまで取得できると思い込む

削除イベントで取得できるのは、削除されたアイテムのid、partition key、TTL期限切れかどうかなどのメタデータが中心です。削除前の氏名、金額、ステータスなどを後から監査したいなら、削除前に別の監査ログへ書き出す設計が必要です。

過去の全履歴をさかのぼれると思い込む

all versions and deletes modeで読めるのは、Continuous backup保持期間内の変更です。また、読み取り開始位置は「now」または保持期間内のチェックポイントで、コンテナーの先頭や過去の任意時点から読み始めることはできません。過去データの完全な再構築を目的にしている場合は、別途エクスポート、バックアップ復元、履歴テーブルなどを組み合わせる必要があります。(Microsoft Learn)

soft deleteをすぐ削除する

既存システムでisDeletedやdeletedAtを使っている場合、all versions and deletes modeの導入直後に消すのは危険です。外部システム、管理画面、バッチ、問い合わせ対応、法務・監査要件でsoft deleteフラグを参照している可能性があります。まずは新モードで削除イベントが期待どおり取れるかを検証し、既存の参照箇所を洗い出してから段階的に整理しましょう。

Change Feedのイベント数増加を見積もらない

latest version modeでは1件にまとまっていた連続更新が、all versions and deletes modeでは複数イベントとして扱われることがあります。書き込み頻度が高いコンテナーでは、処理回数、Function実行回数、ログ量、下流API呼び出し回数が増える可能性があります。導入前に、ピーク時間帯の書き込み量と平均更新回数をもとに、下流処理の耐性を確認してください。

TTL削除を即時イベントとして扱う

TTLは期限が切れた瞬間にChange Feedへ必ず即時出る、という前提で設計しないほうが安全です。Microsoft Learnでは、TTL期限切れによる削除はアイテムがコンテナーからパージされたタイミングでフィードに現れると説明されています。期限切れ後すぐに通知や課金停止などの厳密な処理が必要な場合は、TTLだけに依存せず、別途スケジューラーや状態管理を組み合わせるべきです。(Microsoft Learn)

実務での活用シーン

外部検索インデックスの削除同期

Azure Cosmos DBのデータをAzure AI Search、Elasticsearch、OpenSearchなどに同期している場合、削除イベントを拾えないと検索インデックス側に古いドキュメントが残ります。all versions and deletes modeを使えば、削除イベントを受け取って同期先のドキュメントも削除する設計にできます。

この場合は、削除イベントのmetadataからidとpartition keyを取り、同期先のキーにマッピングできるかを確認します。同期先のキー設計がCosmos DBのidだけに依存している場合、partition key込みで一意性を保つ必要がないかも見直してください。

監査ログとコンプライアンス対応

ユーザープロファイル、注文、契約、権限設定など、変更履歴を追いたいデータでは、作成・更新・削除の区別が重要です。all versions and deletes modeではoperationTypeを使って処理を分けられるため、「誰が削除したか」「いつTTLで失効したか」「どのアイテムが更新されたか」を監査ログ用の別コンテナーやログ基盤に転送しやすくなります。

ただし、誰が変更したかはChange Feedのメタデータだけでは十分でない場合があります。監査要件があるなら、アプリケーション側でupdatedBy、deletedBy、requestId、sourceSystemなどの情報をドキュメントや別ログに残す設計も必要です。

削除を起点にしたクリーンアップ

注文、添付ファイル、キャッシュ、関連コンテナーなど、親データの削除に合わせて周辺データを片付ける処理にも向いています。たとえば、注文データが削除されたら関連する一時キャッシュを消す、ユーザーが削除されたら外部通知を送る、といった処理です。

この用途では、下流処理の失敗時に再試行できるように、削除イベントを直接処理するだけでなく、必要に応じてキューやログコンテナーに一度書き出す設計が安全です。

導入判断の基準

all versions and deletes modeは便利ですが、Change Feedの標準モードをすべて置き換えるものではありません。次のように使い分けると判断しやすくなります。

要件	推奨モード
最新状態を検索インデックスに反映したいだけ	latest version mode
削除を同期先に確実に反映したい	all versions and deletes mode
同じアイテムの中間更新も処理したい	all versions and deletes mode
コンテナー作成時からの全変更を再処理したい	latest version modeを検討
監査で削除イベントを残したい	all versions and deletes mode。ただし監査項目は別途設計
削除前の完全な値を保存したい	Change Feedだけでなく監査ログ実装が必要
Non-.NETのAzure Functions triggerで使いたい	公式サポート状況を確認し、必要ならProcessorやpull modelを検討

本番導入前のチェックリスト

本番展開前には、次の項目を最低限確認してください。

チェック項目	確認内容
対象アカウント	Azure Cosmos DB for NoSQLである
Continuous backup	有効化済みで、保持期間が要件に合っている
コスト	バックアップ、Function実行、ログ、下流API呼び出しの増加を見積もった
SDK・拡張機能	使用言語、Azure Functionsモデル、NuGetやSDKバージョンが対応している
lease container	既存処理と新処理で競合しない
削除イベント	明示削除とTTL削除を区別して処理できる
更新イベント	createとreplaceをoperationTypeで分けている
冪等性	同じイベントの再処理で二重登録や二重削除にならない
監査要件	削除前データや実行ユーザーが必要な場合、別途保存している
ロールバック	新consumerを停止しても既存処理に影響しない構成にしている

まとめ：まずは削除同期と監査用途から検証する

Azure Cosmos DB all versions and deletes change feed modeのGAは、削除や中間更新をChange Feedで扱いたい開発者にとって大きな改善です。特に、soft deleteで削除同期を回避していたシステム、監査ログを強化したいシステム、TTL期限切れを後続処理につなげたいシステムでは、設計を簡素化できる可能性があります。

一方で、Continuous backup必須、NoSQL API限定、保持期間の制約、削除前ドキュメントは取得できない、読み取り開始位置に制限がある、といった注意点があります。既存のChange Feed処理を置き換えるのではなく、まずは別lease containerで新consumerを立て、作成・更新・削除・TTLの挙動を検証するところから始めるのが現実的です。

管理者はアカウント設定とバックアップコストを確認し、開発者はoperationType、metadata、冪等性、SDK/Functionsの対応状況を確認してください。そのうえで、監査ログや削除同期など効果が見えやすいワークロードから段階的に展開すると、安全にメリットを取り込めます。
[4]: https://www.nuget.org/packages/Microsoft.Azure.Functions.Worker.Extensions.CosmosDB “
NuGet Gallery
| Microsoft.Azure.Functions.Worker.Extensions.CosmosDB 4.16.1
“

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure Cosmos DB all versions and deletes change feed modeがGA：削除・中間更新を拾う実装と注意点

Azure Cosmos DB all versions and deletes change feed modeで何が変わるのか

従来のlatest version modeとの違い