変更要約: DP-420 第4章を新規作成（ドメイン4: クエリ最適化とインデックス(インデックスポリシー included/excluded path・書き込み多 vs 読み取り多・複合インデックス・range/spatial・統合キャッシュ integrated cache 専用ゲートウェイ・RU コスト request charge/クエリメトリクス)、変更フィード(Azure Functions トリガー/SDK change feed processor・lease/変更フィードエスティメーター backlog/非正規化更新・参照強制・集計永続化・アーカイブ)）。
4.2変更フィード（change feed）の活用
変更フィードの処理（Azure Functions トリガー、SDK の change feed processor）、変更フィードエスティメーター、変更フィードによる非正規化/参照強制/集計永続化/アーカイブを理解します。
変更フィード（change feed） はコンテナの項目の作成/更新を時系列で永続的に読み取れる仕組みで、イベント駆動の処理パイプラインの土台になります（最適化の観点では「重い同期処理を非同期に逃がす」役割）。
4.2.1変更フィードの処理方法
処理方法は主に 2 つ＝Azure Functions の Cosmos DB トリガー でサーバーレスに変更を受けて処理する（運用が簡単・スケールは Functions 任せ）、または SDK の change feed processor でアプリ内に組み込み、リース（lease）コンテナでチェックポイントしながら並列に消費する（細かい制御が可能）。スケールでは 変更フィードエスティメーター（change feed estimator） が 未処理の変更量（バックログ） を見積もり、処理インスタンス数（並列度）を増減する判断に使う。
4.2.2変更フィードの用途
変更フィードを使った定番パターン＝非正規化した複製の更新（元が変わったら複製先も更新）、参照整合性の強制（関連項目の整合維持）、集計の永続化（実行時に集計せず、変更時に集計結果を更新しておきレポートを高速化）、データのアーカイブ（古い変更を別ストアへ退避）。いずれも「読み取り時に重い計算をする」代わりに「書き込み時に変更フィードで前処理する」ことで、読み取りの RU/遅延を最適化する考え方です。
決め手：「サーバーレスに変更を処理」＝Azure Functions の Cosmos DB トリガー。「アプリ内で細かく制御・並列消費」＝SDK の change feed processor（lease コンテナ）。「未処理バックログを見てインスタンス数を調整」＝変更フィードエスティメーター。「読み取り時の重い集計を書き込み時に前処理」＝集計の永続化。
混同に注意：
①change feed processor（消費）と change feed estimator（バックログ見積もり）を取り違えない。
②変更フィードは作成/更新を返すが、既定では削除は含まれない（削除は TTL+ソフトデリート等で表現）。
③Functions トリガーと SDK processor は同じ変更フィードの異なる消費方法。
4.2.3この節のまとめ
- 変更フィードの処理＝Azure Functions トリガー(サーバーレス) or SDK change feed processor(lease で並列・制御)
- 変更フィードエスティメーターで未処理バックログを把握し処理インスタンス数を調整
- 用途＝非正規化更新/参照強制/集計の永続化/アーカイブで読み取りを最適化
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. コンテナの変更を、インフラ管理を最小限にサーバーレスで処理したい。最適なのはどれですか？
Q2. アプリ内で変更フィードを並列に消費し、リース（lease）でチェックポイントしながら細かく制御したい。最適なのはどれですか？
Q3. 変更フィードの未処理バックログを把握して処理インスタンス数を調整したい。最適なのはどれですか？
Q4. レポートのために、読み取り時の重い集計を避けて変更時に集計結果を更新しておきたい。最適なパターンはどれですか？
Q5. 既定の変更フィードについて正しいのはどれですか？