Azure FunctionsでAzure Cosmos DBの変更フィードを使っている場合、今回の「Azure Functions documentation update: feat(cosmos): support AllChangesAndDelete changefeed mode」は、削除イベントや中間更新をFunctions側で扱いやすくする重要な更新です。結論から言うと、.NET isolated worker向けのCosmos DB拡張機能にChangeFeedMode設定が追加され、従来の最新バージョンだけを処理する方式に加えて、AllVersionsAndDeletes、つまり「すべてのバージョンと削除」モードを指定できるようになります。既存のCosmos DBトリガーは既定でLatestVersionのまま動くため、明示的に設定を変えない限り挙動は大きく変わりません。ただし、本番利用前にはパッケージバージョン、Cosmos DBアカウントの継続的バックアップ、受け取り型、リース設定、削除イベント処理の冪等性を必ず確認する必要があります。(GitHub)
Azure Functions documentation update: feat(cosmos): support AllChangesAndDelete changefeed modeで変わること
今回の更新は、Azure Functionsの.NET isolated worker向けCosmos DB拡張機能に、Cosmos DB変更フィードの読み取りモードを指定する仕組みを追加するものです。GitHub上のPR #3420では、Microsoft.Azure.Functions.Worker.Extensions.CosmosDBのバージョンを4.16.0へ上げ、基盤となるMicrosoft.Azure.WebJobs.Extensions.CosmosDB依存関係も4.16.0へ更新する変更が入っています。あわせて、CosmosDBChangeFeedMode enumとCosmosDBTriggerAttribute.ChangeFeedModeプロパティが追加されています。(GitHub)
注意したいのは、PRタイトルではAllChangesAndDeleteという表記が使われていますが、コードとリリースノート上の正式な指定値はAllVersionsAndDeletesです。記事内では、Azure Cosmos DBの機能名に合わせてAllVersionsAndDeletesを中心に説明します。PRのrelease notesにも「support AllVersionsAndDeletes changefeed mode」と記載されています。(GitHub)
| 項目 | 変更前 | 変更後 |
|---|---|---|
| Cosmos DBトリガーの変更フィードモード | 基本的に最新バージョンモード | ChangeFeedModeでモード指定が可能 |
| 既定値 | 最新バージョンのみ | LatestVersionのまま |
| 削除イベントの取得 | 通常は取得できない | AllVersionsAndDeletes指定時に取得対象になる |
| 中間更新の取得 | 短時間に複数回更新されると途中状態を取り逃がす可能性がある | 保持期間内であれば中間変更も処理対象になる |
| 影響を受ける主な開発者 | Cosmos DB Triggerを使う.NET isolated worker開発者 | 削除・中間更新をFunctionsで処理したい開発者 |
そもそもAllVersionsAndDeletesとは何か
Azure Cosmos DBの変更フィードには、大きく分けてLatestVersionモードとAllVersionsAndDeletesモードがあります。LatestVersionは、項目の作成や更新の最新状態を扱うモードです。削除は変更フィードに現れず、同じ項目に短時間で複数回更新が入った場合、途中の更新をすべて処理できるとは限りません。(Microsoft Learn)
一方、AllVersionsAndDeletesは、作成、更新、削除をより細かく追跡するためのモードです。削除イベントやTTL期限切れによる削除も扱えるため、監査ログ、データ同期、外部検索インデックスの削除反映、イベントソーシング寄りの処理で役立ちます。ただし、利用にはAzure Cosmos DBアカウントの継続的バックアップが必要で、読み取れる変更はバックアップ保持期間内に限られます。(Microsoft Learn)
| 比較項目 | LatestVersion | AllVersionsAndDeletes |
|---|---|---|
| 作成イベント | 取得できる | 取得できる |
| 更新イベント | 最新状態を取得 | 中間更新も取得対象 |
| 削除イベント | 取得できない | 取得できる |
| TTLによる削除 | 取得できない | 削除理由のメタデータとして扱える |
| 保持期間 | コンテナー内に項目が存在する範囲で扱いやすい | 継続的バックアップの保持期間に依存 |
| 開始位置 | 先頭、特定時刻、現在、チェックポイントなど | 現時点または継続トークン／リースからの再開が中心 |
| 向いている用途 | キャッシュ更新、検索インデックス更新、一般的なデータ同期 | 削除検知、監査、CDC、データ移行、外部システムへの正確な反映 |
今回の更新で影響を受ける対象者
最も影響を受けるのは、Azure Functionsの.NET isolated workerでCosmos DB Triggerを使っている開発チームです。Microsoft.Azure.Functions.Worker.Extensions.CosmosDBにChangeFeedModeが追加されたため、関数コード側で変更フィードモードを明示できるようになります。PR #3420では、CosmosDBTriggerAttributeにChangeFeedModeプロパティが追加され、既定値はCosmosDBChangeFeedMode.LatestVersionとされています。(GitHub)
一方で、すべてのAzure Functionsアプリが自動的にAllVersionsAndDeletesを使えるわけではありません。対象は、利用している言語、Functionsの実行モデル、Cosmos DB拡張機能のバージョン、拡張機能バンドルの更新状況によって変わります。Microsoft LearnのCosmos DBバインド資料では、Azure Functions v4向けのCosmos DB拡張機能はNuGetパッケージまたは拡張機能バンドルで導入する形になっており、.NETの実行モデルによって参照するパッケージも異なります。(Microsoft Learn)
| 立場 | 確認すべきこと |
|---|---|
| Azure管理者 | Cosmos DBアカウントがNoSQL APIか、継続的バックアップが有効か、機能が有効化されているか |
| Functions開発者 | Cosmos DB拡張機能のバージョン、ChangeFeedMode指定、受け取り型、削除イベント処理 |
| SRE／運用担当 | リースコンテナー、RU消費、Application Insightsログ、再処理時の冪等性 |
| アーキテクト | LatestVersionのままでよいか、AllVersionsAndDeletesへ切り替える価値があるか |
管理者が最初に確認すべき設定
AllVersionsAndDeletesは、コードだけを変えても動きません。まずAzure Cosmos DB側の前提条件を確認します。
| 確認項目 | 確認内容 | 見落とすと起きること |
|---|---|---|
| アカウント種別 | Azure Cosmos DB for NoSQLアカウントか | 対象外APIでは利用できない |
| バックアップ設定 | 継続的バックアップが有効か | AllVersionsAndDeletesを読めない |
| 機能有効化 | 「すべてのバージョンと削除」変更フィードモードが有効か | トリガー側で指定しても期待通り処理できない |
| 保持期間 | 変更をどの期間までさかのぼって読む必要があるか | 保持期間外の変更は読めない |
| リース設計 | 既存トリガーとリースを分けるか | 既存処理のチェックポイントと混ざり、検証が難しくなる |
| RU監視 | 監視対象コンテナーとリースコンテナーのRUを監視しているか | 遅延、スロットリング、処理詰まりが起きやすい |
Microsoft Learnでは、AllVersionsAndDeletesを使うには継続的バックアップが必要で、機能有効化にはAzure portalの「機能」ページを使う方法が案内されています。有効化プロセスには時間がかかる場合があり、その間はアカウント変更を避けるべきとされています。(Microsoft Learn)
開発者が確認すべきコード変更
今回の中心は、Cosmos DB TriggerにChangeFeedModeを指定できるようになる点です。PR #3420で追加されたenumには、最新バージョンのみを扱うLatestVersionと、中間更新・削除を扱うAllVersionsAndDeletesが定義されています。CosmosDBTriggerAttribute.ChangeFeedModeの既定値はLatestVersionなので、既存コードは基本的に従来モードのままです。(GitHub)
PackageReferenceの確認
.NET isolated workerでは、Microsoft.Azure.Functions.Worker.Extensions.CosmosDBを参照します。PR上では4.16.0への更新が記載されていますが、実際の導入時はNuGet Galleryや社内のパッケージフィードで、対象バージョンが公開済みかを確認してください。GitHub Releasesでは、基盤側のMicrosoft.Azure.WebJobs.Extensions.CosmosDB 4.16.0が2026年5月20日に公開され、AllVersionsAndDelete changefeed modeのサポートとMicrosoft.Azure.Cosmos 3.60.0への更新が記載されています。(GitHub)
<ItemGroup>
<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.CosmosDB" Version="4.16.0" />
</ItemGroup>上記は確認ポイントを示す例です。実際には、利用中のFunctions Worker、Cosmos DB拡張、Azure Functions runtime、CI/CD環境で復元されるパッケージの整合性を確認してから固定してください。
ChangeFeedMode指定の基本イメージ
AllVersionsAndDeletesを使う場合は、Cosmos DB Triggerの属性にChangeFeedModeを指定します。以下は読み方を示すための簡略例です。
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;
public class CosmosChangeFeedFunction
{
private readonly ILogger<CosmosChangeFeedFunction> _logger;
public CosmosChangeFeedFunction(ILogger<CosmosChangeFeedFunction> logger)
{
_logger = logger;
}
[Function(nameof(CosmosChangeFeedFunction))]
public void Run(
[CosmosDBTrigger(
databaseName: "appdb",
containerName: "items",
Connection = "CosmosDbConnection",
LeaseContainerName = "leases",
ChangeFeedMode = CosmosDBChangeFeedMode.AllVersionsAndDeletes)]
string changes)
{
_logger.LogInformation("Cosmos DB change feed received: {Changes}", changes);
}
}最初の検証では、いきなりPOCOに強く型付けするより、ログでペイロードの形を確認する方が安全です。AllVersionsAndDeletesでは、作成・置換・削除でレスポンスの形が変わり、削除イベントではcurrent本文ではなくmetadata中心の情報になるためです。Cosmos DBの公式ドキュメントでも、削除操作のレスポンス例はoperationType、id、partitionKey、timeToLiveExpiredなどのメタデータを持つ形で説明されています。(Microsoft Learn)
ChangeFeedItemを使う場面に注意する
Cosmos DB SDKでは、AllVersionsAndDeletesの変更を型付きで扱うためにChangeFeedItem<T>が用意されています。これは、現在の項目、以前の情報、メタデータを含む変更フィードリソースを表す型です。(Microsoft Learn)
基盤側のWebJobs拡張では、AllVersionsAndDeletes利用時に項目型をChangeFeedItem<T>でラップする必要がある旨がコードコメントや過去PRで示されています。特にインプロセスやWebJobs拡張側の処理では、Tだけを受け取ると削除イベントのメタデータを扱えず、期待したバインドにならない可能性があります。(GitHub)
ただし、.NET isolated workerではホストとワーカー間のバインディング形状が異なるため、対象バージョンでの実際の受け取り型を検証することが重要です。2026年5月22日時点では、out-of-process worker向けにAllVersionsAndDeletesの型シムを修正するPR #1000も開かれており、ワーカー側ではJObjectとして渡るケースへの対応が議論されています。したがって、本番投入前に最新の修正版リリース、E2Eテスト結果、実ペイロードを確認してください。(GitHub)
LatestVersionからAllVersionsAndDeletesへ切り替えるべきか
すべてのCosmos DB TriggerをAllVersionsAndDeletesへ変える必要はありません。むしろ、目的が「最新の状態を別システムへ反映する」だけなら、LatestVersionの方がシンプルです。
| 利用シーン | 推奨モード | 理由 |
|---|---|---|
| 商品マスタの最新状態を検索インデックスへ反映する | LatestVersion | 最新状態だけ分かればよい |
| キャッシュを更新する | LatestVersion | 中間更新より最終状態が重要 |
| 物理削除を外部システムにも反映したい | AllVersionsAndDeletes | 削除イベントを検知できる |
| 監査ログや変更履歴を残したい | AllVersionsAndDeletes | 作成、更新、削除をイベントとして扱いやすい |
| 短時間に同一項目が何度も更新され、その都度処理したい | AllVersionsAndDeletes | 中間更新を取りこぼしにくい |
| 保持期間を超えて全履歴を読み直したい | LatestVersionまたは別設計 | AllVersionsAndDeletesは継続的バックアップ保持期間に依存する |
重要なのは、AllVersionsAndDeletesを「高機能な上位互換」と考えないことです。削除や中間更新まで処理できる分、イベント数は増え、処理ロジックも複雑になります。保持期間、再処理、順序、重複実行、失敗時のリトライまで含めて設計する必要があります。
移行時に失敗しやすいポイント
既存トリガーをそのまま切り替えてしまう
既存のLatestVersionトリガーをいきなりAllVersionsAndDeletesへ変えると、処理対象イベントの意味が変わります。これまで「更新されたドキュメント」として処理していたコードに、削除イベントやメタデータ中心のイベントが流れる可能性があります。
特に、以下のようなコードは見直しが必要です。
// 例: すべての変更に current item がある前提の処理
foreach (var item in items)
{
await searchIndex.UpsertAsync(item.Id, item);
}AllVersionsAndDeletesでは、削除イベントを受けたときに検索インデックスから削除する、外部DBのレコードを論理削除する、監査ログにdeleteとして記録するなど、操作種別ごとの分岐が必要になります。
リースコンテナーを分けずに検証する
FunctionsのCosmos DB Triggerは、リースコンテナーを使って処理位置を管理します。検証段階で既存のリース設定を使い回すと、どこから読み始めたのか、どのモードのチェックポイントなのかが分かりにくくなります。
安全に検証するなら、最初は以下のいずれかを選びます。
- 検証用の
LeaseContainerNameを用意する LeaseContainerPrefixで既存処理と分離する- ステージングスロットまたは検証用Function Appで動かす
- 本番データに近いCosmos DBアカウントを使い、削除イベントまでE2Eで確認する
Azure Functionsのhost.jsonにはCosmos DB拡張のleasePrefix設定もあり、同じリースコンテナーを共有する場合の識別に使えます。(Microsoft Learn)
StartFromBeginningやStartFromTimeの期待値を誤る
LatestVersionでは、先頭や特定時刻から変更フィードを読む設計が比較的しやすい一方、AllVersionsAndDeletesでは制約があります。Microsoft Learnでは、AllVersionsAndDeletesはコンテナーの先頭や過去のタイムスタンプから開始する機能が現在サポートされておらず、現時点または以前のリース／継続トークンから開始すると説明されています。(Microsoft Learn)
つまり、「過去30日分の削除イベントをすぐにFunctionsで再処理したい」という要件は、保持期間と開始位置の制約を踏まえて設計しなければなりません。過去分の厳密な再構築が必要なら、変更フィードだけでなく、監査テーブル、イベントストア、バックアップ復元、外部ログ基盤との組み合わせも検討してください。
削除イベントの冪等性を考えていない
Azure Functionsのイベント処理では、同じ変更が再処理される可能性を前提にするべきです。削除イベントを受けたとき、外部システム側ですでに削除済みでもエラーにしない設計が必要です。
実務では、次のような実装が安全です。
| 処理 | 避けたい実装 | 安全な実装 |
|---|---|---|
| 検索インデックス削除 | 対象なしで例外終了 | 対象なしは成功扱い |
| 外部DB更新 | deleteイベントを通常更新として扱う | operationTypeで分岐 |
| 通知送信 | 再処理のたびに通知 | イベントIDやLSN相当の値で重複抑止 |
| 監査ログ | 同じイベントを何度も登録 | 一意キーでupsertまたは重複排除 |
展開前チェックリスト
本番展開前には、コードレビューだけでなく、実際のCosmos DBアカウントを使った結合テストが欠かせません。特にdeleteとTTL期限切れは、ローカルの単体テストだけでは見落としやすいポイントです。
| チェック | 合格条件 |
|---|---|
| パッケージ | 対象のCosmos DB拡張バージョンがCI/CDで復元されている |
| Cosmos DB設定 | NoSQLアカウント、継続的バックアップ、All versions and deletes機能が有効 |
| トリガー設定 | ChangeFeedMode = CosmosDBChangeFeedMode.AllVersionsAndDeletesを明示 |
| 受け取り型 | 作成、更新、削除、TTL削除の各イベントで期待通りにデシリアライズできる |
| リース | 既存処理と分離したリースコンテナーまたはprefixで検証済み |
| 監視 | Application Insightsで処理件数、例外、遅延、RU消費を確認できる |
| 冪等性 | 同一イベントの再処理でも外部システムが壊れない |
| ロールバック | LatestVersionへ戻す手順、旧パッケージへ戻す手順がある |
| ドキュメント | 運用手順に削除イベントの扱いを追記している |
管理者・開発者別の対応手順
管理者の手順
| 手順 | 作業 |
|---|---|
| 現状確認 | 対象Function App、Cosmos DBアカウント、利用中パッケージを一覧化する |
| Cosmos DB確認 | NoSQL API、継続的バックアップ、保持期間を確認する |
| 機能有効化 | Azure portalまたは対応APIでAll versions and deletes変更フィードモードを有効化する |
| 検証環境準備 | 本番とは別のリース設定、ステージングスロット、監視設定を用意する |
| 展開判定 | 処理遅延、RU、例外、削除イベント処理の結果を見て本番適用を判断する |
開発者の手順
| 手順 | 作業 |
|---|---|
| 依存関係更新 | Cosmos DB拡張機能の対象バージョンを更新する |
| トリガー修正 | ChangeFeedModeを明示する |
| ペイロード確認 | create、replace、delete、TTL deleteの実データをログで確認する |
| 分岐実装 | operationTypeに応じてupsert、delete、監査記録を分ける |
| 冪等化 | 外部システムへの反映処理を再実行に強くする |
| テスト | 実Cosmos DBアカウントでE2Eテストを行う |
今回の更新を使うべきケース、使わない方がよいケース
AllVersionsAndDeletesは、削除や中間更新を「ビジネス上のイベント」として扱いたい場合に価値があります。たとえば、ユーザーがデータを削除したことを別システムにも反映したい、外部DWHへ正確な変更ログを送りたい、短時間の複数更新をそれぞれ処理したい、といったケースです。
反対に、単に最新状態を保てればよいシステムでは、LatestVersionのままの方が運用しやすいです。削除はソフト削除フラグで十分、変更履歴は別の監査ログに保存している、イベント数を増やしたくない、保持期間の制約を受けたくない場合は、無理に切り替える必要はありません。
まとめ：まずは影響範囲を小さくして検証する
Azure Functionsの「Azure Functions documentation update: feat(cosmos): support AllChangesAndDelete changefeed mode」は、Cosmos DB Triggerで削除イベントや中間更新を扱いたいチームにとって大きな前進です。ポイントは、PR名のAllChangesAndDeleteではなく、実際の指定値としてはAllVersionsAndDeletesを使うこと、既定値はLatestVersionのままであること、そしてCosmos DB側の継続的バックアップと機能有効化が必要なことです。
次に取るべき行動はシンプルです。まず、対象Function AppのCosmos DB拡張機能バージョンと実行モデルを確認します。次に、検証用リース設定を用意し、作成・更新・削除・TTL削除の4パターンをステージング環境で流します。最後に、削除イベントの冪等処理と監視を整えてから、本番へ段階的に展開してください。
コメント