チェンジフィードとは？Cosmos DB・DynamoDBでの変更フィード実装と採用判断

チェンジフィードは、データベース自身が自分への書き込みを発生順のログとして外へ配るしくみです。Azure Cosmos DBでは変更フィード、Amazon DynamoDBではDynamoDB Streams、MongoDBではチェンジストリームと呼ばれ、名前は違っても「DBが自前で変更履歴を持ち、コンシューマが好きな位置から読み進める」という骨格は共通しています。外付けのコネクタを立ててトランザクションログから変更を捕捉するCDCと目的は重なりますが、運用の重さと制約の出方はまったく別物です。この記事では、3製品の保持期間と削除検知の差、コンシューマ側の並列処理の組み方、そして専用のCDCツールへ寄せるべき条件までを実装者の目線で整理します。

まとめ｜チェンジフィード採用の可否を分ける3つの前提条件

チェンジフィードが噛み合うのは、次の3つが同時に成り立つ場合です。第一に、変更の発生元が単一のデータベースで、そこに閉じた通知で用が足りること。第二に、コンシューマ側が同じ変更を2回受け取っても壊れない作りにできること。第三に、保持期間の内側で確実に処理を回し切れる運用体制があること。3つ目を軽く見ると、障害で半日止まっただけでDynamoDB Streamsの24時間を食い潰し、取りこぼしに気づかないまま先へ進みます。

実装で最初に決めるのは2点だけです。削除を拾う必要があるか、そして変更前の像が要るか。この2点で選べるモードが決まり、Cosmos DBならプレビュー機能と継続的バックアップの構成まで芋づるで決まります。逆にこの2点が曖昧なまま組むと、後から差分同期の仕様を作り直す羽目になります。

見送りが妥当なのは、変更元が複数のDB製品にまたがる場合、宛先が複数あって変換も挟みたい場合、そしてリレーショナルデータベースが混在する場合です。この3つに当てはまるなら、DB組み込みの機能を製品ごとに並べるより、CDCツールで受け口を統一したほうが総工数は下がります。判断の分岐は第5章と第6章に条件付きで示しました。

データベース標準機能として変更を配信するチェンジフィードの定義と適用範囲

用語の混乱がいちばん起きやすいのが、CDCとの関係です。ここを先に切り分けておくと、製品ドキュメントの読み方が定まります。

CDCと重なる部分とDB組み込み機能に閉じる部分の線引きの基準

CDCは変更を捕捉する方式の総称で、クエリベース・トリガーベース・ログベースの3系統に分かれます。チェンジフィードはこのうちログベースの発想を、ベンダが製品機能として組み込んで公開したものだと捉えると位置づけが定まります。方式の中身そのものはCDCの3方式と実装設定を扱った記事で扱っているため、ここでは繰り返しません。

実装者から見た差は3つあります。外部にコネクタのプロセスを立てないので、監視対象がDBとコンシューマだけに減ること。権限設計がDBのロールに閉じ、レプリケーション用の特権を別途切らずに済むこと。そして、機能の制約がベンダの実装に固定され、回避策を自分で作れないことです。3つ目は利点の裏返しで、後述する保持期間の壁がその典型になります。

Cosmos DB・DynamoDB・MongoDBで呼び名が異なる同一機能の対応表

同じ概念に別の製品名が付いているため、検索するときは製品名を先に確定させてください。

Cosmos DBだけ既定で削除が落ちる点が、移行や同期を組むときの最初の分岐になります。Cosmos DBのAPI選定とRU課金の前提を押さえたうえで読むと、リースコンテナーの費用が別に乗る理由まで一続きで理解できます。

取得できるのは変更後の像か変更前の像かで分かれる設計上の制約と確認手順

受け取れるペイロードの形は製品ごとに異なる仕様です。DynamoDB StreamsはStreamViewTypeで4種類から選び、新旧両方が要るならNEW_AND_OLD_IMAGESを指定します。MongoDBは変更前の像を得るためにfullDocumentBeforeChangeを指定したうえで、コレクション側でchangeStreamPreAndPostImagesを有効化する必要があります。

Cosmos DBは事情が異なり、置換や削除の直前バージョンを取得する手段が現時点で用意されていません。差分の中身を使って通知内容を組み立てる設計にしていると、この一点で作り直しになります。着手前に、宛先の処理が変更前の値を必要とするかどうかを洗い出してください。

Cosmos DB・DynamoDB・MongoDBの保持期間と削除検知の差

保持期間は、障害時にどこまで巻き戻せるかを決める数字です。製品間の開きが大きく、同じ設計をそのまま横展開できません。

削除を拾えない既定モードとソフト削除で代替する実装の手順と注意点

Cosmos DBの最新バージョンモードは既定で有効になっており、挿入と更新だけがフィードに現れます。削除された項目はフィードに出てこないため、公式が案内する代替はソフト削除です。項目に削除フラグの属性を足して更新扱いで流し、あわせてTTLを設定して実体を後から消します。

この方式には注意すべき落とし穴も存在します。TTLの失効による削除は最新バージョンモードではキャプチャされないため、コンシューマ側はフラグ付きの更新を見た時点で削除として処理し切る必要があります。TTLの期限より短い間隔で処理を回すことも前提条件です。削除そのものを確実に受け取りたいなら、すべてのバージョンと削除モードを使う選択になりますが、2026年8月時点でこれはプレビュー扱いで、NoSQL用アカウント限定かつ継続的バックアップの構成が必須です。

24時間で消えるDynamoDB Streamsと継続的バックアップ依存の保持

保持期間を並べると、設計上どこにリスクが集まるかが見えます。

数字の意味はそれぞれ違います。Cosmos DBの最新バージョンモードは固定の保持期間を持たず、コンテナーの先頭まで遡って読み直せる一方、削除は最初から対象外です。全バージョンモードは削除まで拾えますが、読めるのは継続的バックアップの保持期間内だけで、コンテナー作成から8日経っていて保持期間が7日なら直近7日分しか読めません。DynamoDBの24時間は最も短く、ここを超えるとレコードは自動で消え、手動で延ばす手段もありません。

oplogの容量が再開可能な範囲を決めるMongoDBの制約と回避策

MongoDBのチェンジストリームには明示的な保持期間の設定がなく、再開できる範囲はoplogに履歴が残っているかで決まります。書き込み量が増えればoplogは早く一周し、停止から復帰したときに再開トークンが失効します。ドキュメント指向データベースとしてのMongoDBの構造を前提に、oplogサイズを書き込みピークの実測から逆算しておくのが安全です。

再開の作法にも製品固有の段差がある点には注意が必要です。通常はイベントの_idに入る再開トークンを保存してresumeAfterで戻りますが、コレクションの削除やリネームでinvalidateが飛んだ後はこれが使えず、startAfterで新しいストリームとして張り直す必要があります。変更前イメージを使う構成ではconfig.system.preimagesの容量も監視対象に入り、MongoDB 6.0以降はexpireAfterSecondsで保持を絞れます。タイムシリーズコレクションは対象外なので、時系列データを別コレクションに逃がしている設計では通知が飛ばない点に注意してください。

リースとシャードで並列処理を分担するコンシューマ側の実装構造

読み取り側の構造は製品ごとに名前が違うだけで、やっていることは「範囲を分けて並列に読み、どこまで読んだかを永続化する」に集約されます。

変更フィードプロセッサの4要素とリース既定値が示す復旧時間の目安

Cosmos DBの変更フィードプロセッサは、監視対象コンテナー・リースコンテナー・コンピューティングインスタンス・デリゲートの4つで構成されます。物理パーティションの範囲ごとにリース文書が作られ、稼働中のインスタンスへ均等に配られる作りです。ここから直接わかる制約が1つあります。1つのリースは同時に1インスタンスしか持てないため、インスタンス数をリース数より多くしても並列度は上がりません。

復旧の速さは既定値から読めます。リース取得は17秒ごと、リースの有効期限は60秒、リースの更新は13秒ごとが既定なので、ホストがクラッシュしてから別ホストが引き継ぐまで最大で1分強かかる計算です。ここを詰めるとリースコンテナーの要求ユニット消費が増加する点にも注意が必要です。サーバー側のタイムアウト既定は5秒で、クライアント側のネットワークタイムアウトはこれより長く取らないと処理が止まります。なおプロセッサのライブラリは.NET V3とJava V4にしか無く、Node.jsとPythonではプルモデルで自前のチェックポイント管理を書くことになります。

Lambda2関数までという読み取り側の上限と超えた場合の回避策

DynamoDB Streams側の並列単位はシャードで、親シャードを先に処理してから子シャードへ進む順序制約が付きます。Lambdaと繋ぐ場合、ストリームは1秒に4回ポーリングされます。

実装で先に効いてくるのは本数の上限です。同一のDynamoDBストリームにサブスクライブできるのは最大2関数までで、3つ以上を繋ぐと読み込みのスロットリングが起きる可能性があります。コンシューマを3系統以上に増やしたいなら、選択肢は2つです。1つ目は受け口を1関数にまとめ、その先でSNSやSQSへ扇状に配る構成。2つ目が次章のKinesis経路で、拡張ファンアウトを使って複数の下流へ同時に届ける構成です。前者は順序保証を保ったまま本数を増やせるので、まずこちらを検討してください。

少なくとも1回配信を前提にした冪等な受け口の作り方と検証方法

変更フィードプロセッサの配信保証は「少なくとも1回」です。デリゲートで未処理の例外が出るとスレッドが止まり、リースストアに残る最後のチェックポイントから同じバッチが再送されます。処理が成功するまで再送が続く設計なので、同じ変更を2回受け取る前提でコンシューマを書く必要があります。

受け口を冪等にする定石は3つです。主キーによるupsertに寄せる、処理済みIDを記録して二重実行を弾く、副作用のある呼び出しをリクエストIDで重複排除する。この設計はイベント駆動アーキテクチャの実装パターンで扱う考え方と同じで、チェンジフィード固有の話ではありません。検証は、同じバッチを意図的に2回流して結果が一致するかを見るだけで足ります。加えて、デリゲート内で例外を握り潰さず、処理できなかった文書を別コンテナーへ退避するロジックを入れておくと、同一バッチの再試行で永久に前へ進まない状態を避けられます。

順序保証を捨てて保持を伸ばすKinesis経路との使い分けの判断

DynamoDBには変更を外へ出す経路が2本あり、性質が正反対です。ここを取り違えると、後から順序の破綻に気づいて作り直しになります。

重複と順序前後を許容できるかで決まる24時間超の保持の取り方

DynamoDB Streamsは、各レコードがストリームに1回だけ現れ、実際の項目変更と同じ順序で並ぶことが公式に明記されています。対してKinesis Data Streams for DynamoDBは、レコードが変更発生と異なる順序で現れることがあり、同じ項目の通知が複数回現れることもあります。順序と重複の判定はApproximateCreationDateTimeの値を見て自前で行う前提です。

この差を踏まえた使い分けははっきりしています。24時間を超える再処理が要る、あるいはコンシューマを3系統以上ぶら下げたいなら、Kinesis経路を選んで受け口側で重複排除と並べ替えを実装してください。逆に、在庫や残高のように順序が意味を持つ処理を素直に書きたいなら、Streamsのまま2関数以内に収める構成を維持します。なお1つのテーブルから接続できるKinesisデータストリームは1本だけで、同一アカウント・同一リージョンに限られ、課金は変更データキャプチャユニット（1項目あたり1KBの変更で1ユニット）で積み上がります。バイナリ属性はbase64が二重に掛かるため、読み出し側で2回デコードする実装も忘れずに入れてください。

チェンジフィードを使わずCDCツールへ寄せるべき3つの判断条件

DB組み込みの機能で押し切らないほうがよい場面があります。第一に、変更元が2種類以上のDB製品にまたがる場合。製品ごとに保持期間もペイロード形式も違うため、コンシューマ側に製品別の分岐が増え続けます。第二に、宛先が複数あって途中で変換や結合を挟みたい場合。第三に、リレーショナルデータベースが混在する場合です。

この3つのどれかに当てはまるなら、Debeziumのコネクタと配置形態を軸に受け口を統一したほうが総工数は下がります。判断の目安は、変更元が3つを超えるかどうか。それ未満で単一製品に閉じているなら、コネクタとブローカーの運用を抱え込むより組み込み機能のほうが軽く済みます。

受託開発の現場でチェンジフィードを採用しない場面と代替の設計

ここまでの制約を、実際の案件でどう判断に落とすかを条件付きで示します。

初期同期と差分同期を分けて設計する移行時の手順と落とし穴の回避

既存データの移行でチェンジフィードを使うときは、初期同期と差分同期を必ず分けて設計してください。Cosmos DBの最新バージョンモードなら開始時刻に最小値を渡してコンテナーの先頭から読み直せるため、初期同期を兼ねられます。ただし開始時刻の精度は約5秒で、リースコンテナーが一度初期化された後は開始点の設定を変えても効きません。

他の2製品では兼用が効きません。DynamoDB Streamsは24時間より前へ遡れないので、初期同期はテーブルのエクスポートやスキャンで別に行い、その開始時点より前のシャードイテレータからストリームを読み始める段取りが要ります。Cosmos DBの全バージョンモードも先頭からの読み取りに対応しておらず、現時点か既存のリース状態からしか始められません。移行案件でいちばん多い事故は、初期同期の完了時刻とストリーム読み出しの開始位置が重ならず、その間の更新が丸ごと落ちるパターンです。順序を逆にして、先にストリームを読み始めてからエクスポートを取り、重複分は冪等な受け口で吸収する手順に固定してください。

見送りが妥当になる3条件と代わりに選ぶ構成の判断基準と検証手順

見送るべき条件を挙げます。第一に、反映が日次で足りる場合。この要件ならバッチのエクスポートと差分取り込みのほうが運用も費用も軽く収まります。第二に、コンシューマ側を冪等にできない場合。少なくとも1回配信が前提なので、二重処理が業務上許されないのに受け口を作り替えられないなら、この経路は選べません。第三に、監視と再処理の担い手を置けない場合です。保持期間の内側で必ず処理し切る運用は、アラートと再実行の手順がセットで初めて成立します。

代替は要件で決まります。日次で足りるならエクスポート起点のバッチ、複数DBをまたぐならCDCツール、単一DBで即時性が要るならチェンジフィードという順で当てはめてください。検証は、本番相当の書き込み量で1週間流し、ピーク時の遅延とoplogやシャードの消化状況を実測するところから始めるのが確実です。設計の切り分けと運用体制まで含めて外部と組む選択肢もあり、当社ではデータ分析基盤構築・MLOps構築支援として、この見極めの工程から支援しています。

よくある質問

チェンジフィードの検討で実際に挙がる質問のうち、各製品の公式ドキュメントの記述に照らして答えられるものを5つ挙げます。

チェンジフィードとCDCは同じものですか？

目的は重なりますが、指す範囲は異なる概念です。CDCは変更を捕捉する方式の総称で、クエリベース・トリガーベース・ログベースの3系統を含みます。チェンジフィードはこのうちログベースの発想をデータベース側が組み込み機能として提供したもので、外部コネクタを立てずに済む代わりに、保持期間やペイロード形式の制約をベンダの実装に合わせる必要があります。

削除された項目も取得できますか？

製品ごとに削除イベントの扱いが異なる仕様です。DynamoDB StreamsとMongoDBのチェンジストリームは削除イベントを配信します。Azure Cosmos DBの既定である最新バージョンモードでは削除が記録されないため、削除フラグとTTLを組み合わせたソフト削除で代替するか、2026年8月時点でプレビューのすべてのバージョンと削除モードを有効にする選択になります。

チェンジフィードの読み取りに追加料金はかかりますか？

追加料金が必要です。Cosmos DBでは監視対象コンテナーの読み取りとリースコンテナーの状態更新の双方で要求ユニットを消費し、インスタンス数が増えるほどリースコンテナー側の消費も増えます。DynamoDBでKinesis経路を使う場合は、変更データキャプチャユニット（1項目あたり1KBの変更で1ユニット）とKinesis側の料金が別々に積み上がります。

同じ変更が2回届くことはありますか？

同じ変更が2回届く可能性は否定できません。Cosmos DBの変更フィードプロセッサは少なくとも1回の配信保証で、デリゲートが例外を返すと同じバッチが再送されます。Kinesis Data Streams for DynamoDBでも同じ項目の通知が複数回現れることがあります。DynamoDB Streamsは各レコードが1回だけ現れる仕様ですが、コンシューマ側の再試行で重複処理は起こりうるため、受け口は冪等に作ってください。

過去のデータを最初から読み直せますか？

Cosmos DBの最新バージョンモードだけが、コンテナーの先頭から読み直せます。同じCosmos DBでもすべてのバージョンと削除モードは先頭からの読み取りに対応しておらず、現時点か既存のチェックポイントからの再開に限られます。DynamoDB Streamsは24時間、MongoDBはoplogに残っている範囲までしか遡れません。

関連記事

• CDC（Change Data Capture）とは？3方式の仕組み・実装設定と採用判断を実装者目線で解説：外部ツールで変更を捕捉する方式との比較材料です。
• Debeziumとは？コネクタ設定と3つの配置形態を実装視点で解説【2026年版】：複数DBをまたぐ場合に受け口を統一する選択肢です。
• Azure Cosmos DB for NoSQLとは｜API選定・RU料金・整合性・ベクトル検索：リースコンテナーの費用を見積もる前提になります。
• AWS DynamoDBとは？特徴・使い方・料金・RDSとの違いを実装目線で解説：ストリームを有効化する側のテーブル設計を確認できます。
• ストリーム処理とは？仕組み・処理モデルとバッチ処理との使い分けを実装視点で解説：受け取った変更を処理する側の設計を整理しています。