CDC（Change Data Capture）とは？3方式の仕組み・実装設定と採用判断を実装者目線で解説

CDC（Change Data Capture・変更データキャプチャ）は、データベースに起きたINSERT・UPDATE・DELETEを1行単位のイベントとして取り出し、別のシステムへ流し込む技術です。夜間バッチで全件を洗い替える連携と違い、削除された行も、同じ行に何度も入った中間の更新も落とさずに渡せます。

この記事では、DB間のデータ連携や分析基盤への取り込みを設計する実装者向けに、3方式の内部動作、MySQLやPostgreSQLで必要な設定、受け側が引き受ける冪等化と順序の設計を整理します。なお本記事のCDCはデータベースの技術で、米国の疾病対策センター（Centers for Disease Control and Prevention）とは無関係です。

まとめ｜CDC採用の可否を分ける3つの条件

CDCを入れるかどうかは3点で決まります。第1に、削除と中間の更新履歴を落とせないこと。第2に、反映までの許容遅延が分単位より短いこと。第3に、ソースDBのサーバー設定を触る権限が取れること。この3つがそろわないなら、バッチの差分抽出で足ります。

方式選択はほぼ決着がついており、ログベースを第一候補に置き、サーバー設定を触れない環境に限ってトリガーベースへ落とすのが現実的な順序です。難所は取得側ではなく受け側。配信保証はat-least-onceが基本で、主キーでの冪等化、パーティション単位に閉じた順序保証、スキーマ変更時の互換モードを織り込まないまま本番に出すと、二重計上や取り込み停止という形で跳ね返ってきます。

CDC（変更データキャプチャ）の定義と、バッチ差分抽出では届かない要件

INSERT・UPDATE・DELETEを捕捉して他システムへ渡す処理の全体像

CDCが出力するのは、テーブルの現在の姿ではなく「変更そのもの」です。1件の変更イベントには、操作の種別、変更前の行の姿、変更後の行の姿、発生位置を示すログ上のオフセットが入ります。Debeziumが生成するイベントなら、操作種別はc（create）、u（update）、d（delete）、r（初期スナップショット由来）という値で区別されます。

効くのは変更前後の両方を持つ点。金額カラムが1000円から1200円へ変わったとき、差分200円を受け側で計算できます。現在値だけを定期取得する連携では、この差は分かりません。

全件洗い替えと更新日時カラム方式が取りこぼす削除と中間更新の履歴

バッチ差分抽出には構造的な穴が4つあります。物理削除された行は抽出クエリの結果に現れないので検知できません。同じ行が1回のバッチ間隔内に3回更新されると、最後の1回しか残りません。更新日時カラムはアプリ側の実装依存で、管理画面からの直接更新やDBAの手作業UPDATEでは書き換わらないことがあります。長時間トランザクションがコミットされれば、抽出済みの時刻範囲へ後から行が差し込まれます。

4つのうち実務で最初に事故になるのは削除です。マスタから消えたはずの取引先が分析基盤に残り続け、集計値が合わなくなる。データ量が増えてから発覚するため、修復コストが高くつきます。バッチ抽出そのものの設計はETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説で整理しているので、CDCと役割分担させる前提で読み比べてください。

クエリベース・トリガーベース・ログベースという3方式の内部動作

更新日時とフラグを問い合わせるクエリベース方式が抱える負荷と取りこぼし

クエリベースは、updated_atのような列で前回取得時刻より新しい行を定期的に問い合わせる方式です。DB側の設定変更が要らないため、共有ホスティングやSaaSのDBでも動きます。実装コストは3方式で最も低いままです。

代償は2つ。物理削除は原理的に拾えないため、アプリ側を論理削除へ統一する改修が前提になります。もう1つは負荷で、更新日時列にインデックスを張ってもなお、ポーリング間隔を詰めるほど本番DBへのクエリが積み上がります。1分間隔なら1日1440回、10テーブルで14400回。この定常負荷を本番DBに背負わせる判断が要ります。

トリガーベース方式が書き込みトランザクションに上乗せする遅延

トリガーベースは、対象テーブルにAFTER INSERT・UPDATE・DELETEのトリガーを仕掛け、変更内容を専用の履歴テーブルへ書き込む方式です。削除も中間更新も取りこぼさず、サーバーの設定権限がなくてもテーブルへのDDL権限だけで導入できます。

問題は実行タイミングにあります。トリガーは元のトランザクションの内側で同期的に走るため、書き込みのレイテンシへ直接上乗せされます。1行の更新が2行の書き込みになり、WALやREDOの生成量もおよそ倍。秒間数千件の更新が走るOLTPテーブルに仕掛けると、業務側の応答時間が先に悲鳴を上げます。カラム追加のたびにトリガー本体を書き換える保守も発生します。

トランザクションログを読むログベース方式の仕組みと必要になる設定

ログベースは、DBがクラッシュリカバリとレプリケーションのために書いているトランザクションログ（MySQLのbinlog、PostgreSQLのWAL、OracleのREDOログ、SQL Serverのトランザクションログ）を外部から読み取る方式です。本番テーブルに追加のクエリを投げず、アプリ側の改修も要りません。取得できるのはコミット済みの変更だけで、しかもコミット順に並んでいます。ロールバックされた変更が流れてこないのは、この性質がトランザクションとは？ACID・分離レベル・commit/rollbackを実装目線で解説【2026年版】で扱う原子性の副産物だからです。

遅延・DB負荷・削除検知の3軸で3方式を比べたときの選び分け方

「まずクエリベースで作り、後で移行する」と決めると受け側の設計が削除なし前提で固まり、移行時に作り直しになります。選んでよいのは、削除が起きない追記専用テーブルと検証環境に限られます。

主要4データベースでログベースCDCを有効にする設定と権限の勘所

MySQLのbinlogをROW形式で読むために必要な設定とユーザー権限

MySQLではlog_binを有効にし、binlog_format=ROWとbinlog_row_image=FULLを指定します。ROW形式でないとSQL文しか記録されず、どの行がどう変わったかを復元できません。MySQL 8.0系以降はbinlog_formatの既定値がROWなので、既定のままなら追加作業は保持期間と権限だけ。接続ユーザーにはREPLICATION SLAVEとREPLICATION CLIENT、初期スナップショット用のSELECTが要ります。

見落としやすいのは保持期間。binlog_expire_logs_secondsの既定値は2592000秒（30日）で、これを短く詰めた環境でCDCプロセスが長時間停止すると、再開位置のbinlogが消えており、初期スナップショットからのやり直しになります。

PostgreSQLの論理レプリケーションとスロット滞留によるWAL肥大

PostgreSQLではwal_level=logicalへ変更し（再起動が要ります）、max_replication_slotsとmax_wal_sendersに空きを確保します。出力プラグインはPostgreSQL 10以降に標準搭載されたpgoutputが既定路線で、追加ビルドは不要。UPDATEとDELETEで変更前の全カラムが欲しい場合はテーブルにREPLICA IDENTITY FULLを設定します。既定では主キー列しか変更前の値が入りません。

この製品固有の事故がレプリケーションスロットの滞留です。スロットは受信側が読んだLSNを保持し、それより新しいWALをサーバー側へ留め置きます。CDCプロセスが落ちたままスロットを残せば、WALが消えずにディスクを食い潰し、最悪データベースが書き込み不能になります。対策はmax_slot_wal_keep_size（PostgreSQL 13以降）で上限を設けることと、pg_replication_slotsビューの遅延バイト数を監視に入れることの2点です。

SQL ServerのCDC機能とOracleのLogMiner・XStreamの違い

SQL Serverには製品組み込みのCDC機能があり、sys.sp_cdc_enable_dbでデータベース単位、sys.sp_cdc_enable_tableでテーブル単位に有効化します。変更内容は専用の変更テーブルに蓄積され、キャプチャジョブとクリーンアップジョブがSQL Server Agent上で動く仕組みです。Agentが止まると変更が溜まらないため、その死活監視が実質の必須項目。変更テーブルの保持期間は既定で4320分（3日）で、この値のまま連休中に障害が起きると復旧時にはデータが消えています。かつてEnterprise Edition限定でしたが、SQL Server 2016 SP1以降はStandard Editionでも使えます。

Oracleは選択肢が2つに割れます。LogMinerは追加ライセンスなしでREDOログを解析できる代わりに、変更量が多い環境ではサーバー側のCPUを消費します。XStreamは低オーバーヘッドですが、利用にはOracle GoldenGateのライセンスが必要。どちらもARCHIVELOGモードでの運用と補足ロギング（supplemental logging）の有効化が前提で、ライセンス費用が絡む唯一の製品なので見積もり段階で調達部門に確認しておきます。

初期スナップショットと増分スナップショットで停止時間を抑える手順

CDCは既存データを持たないため、稼働開始時に必ず初期スナップショットを取ります。テーブル全体にロックをかける素朴な実装では、数億行のテーブルで業務が止まりかねません。手順は次の順序に固定できます。

1. 対象テーブルを絞り込み、連携が要る列だけを列挙する
2. ログの読み取り位置を先に確保し、スナップショット中の変更を失わせない
3. 主キー範囲でチャンク分割し、区切りながら既存行を読み出す
4. 読み出し済み範囲に届いた変更イベントを、後勝ちで上書き適用する

Debeziumはこの流れを増分スナップショット（incremental snapshot）として実装しており、シグナル用テーブルへ行を挿入すれば稼働中でも再スナップショットを指示できます。連携対象が増え続ける案件では、この機能の有無が運用コストを分けます。

順序保証・重複配信・スキーマ変更というCDC運用の3つの落とし穴

at-least-onceを前提に受け側を冪等化する設計と主キーの決め方

ログベースCDCの配信保証は、実装のほとんどがat-least-once（少なくとも1回）です。プロセスが再起動すると最後にコミットしたオフセットから読み直すため、同じイベントが2回届きます。exactly-onceを謳う構成もありますが条件が限られるので、受け側を冪等に作って重複を吸収する方が保守しやすくなります。

実装は、主キーによるUPSERTと、イベントに含まれるログ位置での上書き判定の組み合わせが基本形。適用済みのオフセット以前のイベントが届いたら捨てる、という判定を入れておけば、再送も再スナップショットも安全に受けられます。パイプライン全体としての冪等性はデータパイプラインとは？種類・構成要素と冪等性から考える設計判断を解説【2026年版】で整理しているので、CDCを入力段として組み込む際の土台になります。

パーティションキーで順序を守る範囲と守れない範囲の切り分け方

Kafkaを挟む構成で順序が保証されるのは同一パーティション内だけです。主キーをパーティションキーに使い、同じ行への変更が必ず同じパーティションへ落ちるようにすれば、「作成→更新→削除」の入れ替わりは防げます。

守れないのはテーブルをまたいだ順序です。注文ヘッダと注文明細が別トピックに流れる構成では、明細が先に届くことがあります。受け側で外部キー制約を張っていれば、この瞬間に取り込みが落ちます。対策は3つ。制約を外して後から整合チェックを回す、関連テーブルを同一トピックにまとめる、業務イベント用のoutboxテーブルを1本立ててそこだけをCDCで拾う。分析基盤への取り込みなら1つ目、マイクロサービス間の業務イベント配信なら3つ目が現実的な着地です。

DDL変更をスキーマレジストリで吸収するときの互換モードの選択

ソースDBにカラムが1本増えた瞬間、下流のコンシューマが古いスキーマでデコードに失敗する。これがCDC運用で最も頻度の高い停止要因です。スキーマレジストリを挟んで互換モードを明示しておけば、変更の可否をデプロイ前に機械判定できます。

既定のBACKWARD互換は、新しいスキーマで古いデータを読めることが条件。デフォルト値付きのカラム追加と削除は通り、必須カラムの追加は弾かれます。読み手より書き手を先に更新する運用ならBACKWARD、逆ならFORWARD、両方向を担保するならFULL。運用チームが分かれる案件ではFULLへ寄せ、デプロイ順序への依存を消す方が事故が減ります。

Debezium・AWS DMS・マネージド製品のどれを選ぶかの判断基準

Debezium 3.6系の現在地とKafka Connect前提の運用コスト

DebeziumはCDCのOSS実装として事実上の標準で、MySQL・PostgreSQL・SQL Server・Oracle・MongoDBなどのコネクタを持ちます。2026年7月時点で公開されている最新は3.6.0.Finalで、リリースは2026年7月1日。スキーマ履歴をRocksDBでオフヒープ化してメモリ消費を抑える改善と、MySQLコネクタのポーリング経路でのCPUオーバーヘッド削減が入りました。破壊的変更は含まれないとアナウンスされており、3.5系（3.5.2.Finalは2026年6月2日公開）からの追随は軽い部類です。

費用が発生しない代わり、運用の総量は最も多くなります。標準構成ではKafka ConnectのワーカーとKafkaクラスタを維持することになり、コネクタのタスク監視、オフセットトピックの管理、スキーマレジストリの運用が付属。ブローカーを自前運用したくないなら、Amazon MSK（Managed Streaming for Apache Kafka）とは？仕組み・料金・使い方とKafka自前運用との違いを解説で整理したマネージドサービスへ寄せる構成が現実的。Kafkaを前提にしない配信先が欲しい場合は、Debezium Serverという単独実行形態も選べます。

AWS DMSのCDCモードとサーバーレス構成が向く移行案件の形

AWS DMSは、フルロード（既存データの一括移行）と継続的レプリケーション（CDC）を1つのタスクで扱えるマネージドサービスです。オンプレミスのOracleやSQL ServerからAurora・Redshiftへ移す案件では、初期移行と切り替え直前の追随を同じ仕組みで完結できる点が効きます。

DMS Serverlessは処理能力をDCU（1 DCUが2GB RAM相当）という単位で従量課金し、変更量に応じて自動で上下します。2025年4月にはレプリケーションストレージの自動スケーリングが加わり、既定100GBの上限を超える大量トランザクションでも手当てが不要になりました。数週間から数か月に及ぶ継続レプリケーションならサーバーレス、数日で終わる短期移行ならキャパシティを読み切れるプロビジョンド、という分け方が扱いやすくなります。

CDCを採用しない方がよい条件と、そのときに置き換える現実的な手段

次の3つに当てはまるなら、CDCは見送るべきです。

第1に、許容遅延が1時間以上ある連携。常時稼働プロセスとログ監視が増えるだけなので、夜間バッチと更新日時での差分抽出で足ります。第2に、ソースがパッケージ製品やSaaSで、DBサーバーの設定変更権限が自社にない場合。ログベースが選べず、トリガーはベンダー保守の対象外になるため、提供済みのAPIやエクスポート機能を使う方が保守性で勝ります。第3に、連携先が1系統だけで受け側がバッチ集計しかしない場合。秒単位で届けても下流が1日1回しか動かないなら、遅延の短縮は成果に結びつきません。

逆に、見送ってはいけない条件も1つ。ソースDBで物理削除が発生し、それを下流へ伝える必要がある場合です。バッチ差分では原理的に満たせず、アプリを論理削除へ全面改修するコストの方が高くつきます。

導入前に必ず通しておく検証の順番と、外部に任せる判断の線引き方

検証は順番を守れば手戻りが出ません。ログ設定の変更が再起動を伴うかの確認、初期スナップショットの所要時間の実測、CDCプロセスを24時間停止させてログ保持期間内に復帰できるかの確認、スキーマ変更を1本入れて下流が止まらないかの確認、重複イベントを流しての冪等性確認。この5つで本番障害の大半は潰せます。

外部に任せるかどうかは、対象テーブル数とDB製品の数で線を引きます。単一のMySQLから数テーブルを流すだけなら、社内でDebeziumを立てて運用する範囲に収まるはずです。一方、OracleとSQL Serverが混在し対象が数十テーブルに及び、業務停止時間の上限が決まっている移行案件では、設計と検証の工数が跳ね上がります。一創ではCDCを含むデータ連携基盤の設計から構築までをデータ分析基盤構築・MLOps構築支援として請けており、既存DBの設定制約を洗い出す段階から相談を受け付けています。

よくある質問

実装者から挙がる質問を5つ挙げます。

CDCとETLは何が違うのですか？

役割の階層が違います。CDCは「変更をどう取り出すか」という抽出（Extract）部分の技術で、ETLは抽出・変換・書き込みを含む流れ全体を指します。両者は排他ではなく、ETLの抽出段にCDCを据える構成が一般的。処理単位も異なり、ETLがバッチ単位でまとめるのに対しCDCは1行単位の変更イベントを連続的に流します。

米国のCDC（疾病対策センター）とデータベースのCDCは関係がありますか？

まったく別の略語です。データベース領域のCDCはChange Data Capture（変更データキャプチャ）の略で、DBの変更を捕捉する技術を指します。公衆衛生の文脈で登場するCDCはCenters for Disease Control and Preventionの略で、米国の政府機関のこと。技術情報を探すなら「CDC データベース」「change data capture」のように語を足して絞り込んでください。

ログベースCDCを有効にするとデータベースの性能は落ちますか？

トランザクションログはCDCの有無にかかわらず書かれるため、読み取り自体による性能低下はほとんどありません。影響が出るのは設定変更の副作用です。PostgreSQLでREPLICA IDENTITY FULLを設定すると変更前の全カラムがWALに書かれ、生成量が増えます。スロット滞留やbinlogの保持期間延長でディスク使用量も増えるため、容量監視は事前に整えておきます。

DebeziumはKafkaがないと使えませんか？

Kafkaなしでも使えます。標準構成はKafka Connect上でコネクタを動かす形ですが、Debezium Serverという単独プロセスで起動すれば、Kinesis・Google Cloud Pub/Sub・Apache Pulsar・Redisといった宛先へ直接配信できます。ただしKafka構成が持つ再処理のしやすさやコンシューマグループによる分散は失われるので、配信先が1つに固定できる小規模構成向けと捉えてください。

CDCで削除されたレコードはどのように伝わりますか？

削除は操作種別dのイベントとして届き、変更前の行の内容が入った状態で配信されます。Kafkaを使う構成では、続けて同じキーで値がnullのメッセージ（トゥームストーン）が送られる設定が既定。ログコンパクション時にそのキーの履歴を物理削除させる目印で、不要ならコネクタ設定で抑制できます。受け側では物理削除として適用するか、削除フラグの更新として扱うかを事前に決めておいてください。

関連記事

• データパイプラインとは？種類・構成要素と冪等性から考える設計判断を解説【2026年版】：パイプライン全体の設計と冪等性の考え方を整理しています
• ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説：バッチ抽出との役割分担を決める前提になります
• ストリーム処理とは？仕組み・処理モデルとバッチ処理との使い分けを実装視点で解説：CDCが流したイベントを処理する側の設計です
• Amazon MSK（Managed Streaming for Apache Kafka）とは？仕組み・料金・使い方とKafka自前運用との違いを解説：Kafka運用をマネージドへ寄せる選択肢です
• トランザクションとは？ACID・分離レベル・commit/rollbackを実装目線で解説【2026年版】：コミット済み変更だけを拾える理由の土台です