CDCとは｜変更データキャプチャの仕組みとDebezium導入の判断軸

CDCとは｜データベースの変更だけを取り出す仕組み

CDCとは、データベースに対して行われた変更（INSERT・UPDATE・DELETE）を検出し、その差分だけを下流のシステムへ伝える技術の総称です。英語のChange Data Captureの略で、日本語では変更データキャプチャと呼びます。

条件としては、変更を検出できる手段がデータベース側に用意されていることが前提になります。例外として、トランザクションログへのアクセスが許されないマネージドDBや共有環境では、後述する別方式に切り替える必要があります。

CDCの定義と「結局なにが嬉しいのか」

嬉しさは3点に集約できます。

ひとつ目は転送量の削減です。1,000万行のテーブルを毎晩まるごと洗い替えしていた処理が、1日あたり数万行の差分転送で済むケースがあります。

ふたつ目は鮮度です。夜間バッチだと最大24時間遅れていたデータが、適切に構成されたログベースCDCならミリ秒〜数秒のオーダーで下流に届きます。Debeziumの公式ドキュメントも、MySQL・PostgreSQLでミリ秒単位の低遅延イベント生成に言及しています。ただし実際の遅延は、DBの負荷・ネットワーク・受け手側の処理速度で変わります。

3つ目は削除を取りこぼさないことです。更新日時カラムを見るだけの連携では、物理削除された行は「消えたこと」自体が検知できません。

バッチ連携（洗い替え・差分抽出）との違い

比べると役割がはっきりします。

バッチが悪いわけではありません。日次のレポート用途で鮮度が求められないなら、運用の単純さを優先して洗い替えを続ける判断も妥当です。CDCを入れるかどうかは「鮮度が業務要件か」で切り分けると迷いません。

なお、変換レイヤーまで含めたデータ基盤の全体像はdbtとは｜データ変換(ELT)の仕組み・使い方・案件単価やApache Airflowとは｜DAGの仕組み・dbt/Dagsterとの違い・案件単価で整理しています。CDCは「取り込み口」の技術であり、変換・オーケストレーションとは担当範囲が別です。

ミニFAQ：CDCとレプリケーションは何が違う？

Q. データベースのレプリケーション機能と何が違いますか。

A. 仕組みは近いですが、出口が違います。レプリケーションは同じ製品のDBへ同じ形のデータを複製するのが基本です。CDCは変更を「イベント」として取り出し、データウェアハウス・検索エンジン・他サービスのDBなど異種のシステムへ届けることを目的にします。Debeziumもデータベースのレプリケーション機構に相乗りして変更を読み出しています。

CDCの3方式｜ログベース・トリガーベース・クエリベース

結論から言えば、サーバー設定を変更できるならログベース、できないならトリガーベース、物理削除がない前提ならクエリベースという優先順位になります。条件は「DBサーバーの設定権限があるか」「物理削除を使っているか」「書き込みレイテンシにどこまで余裕があるか」の3つです。

クエリベース（更新日時カラムを定期的に見る方式）

更新日時のカラムを基準に、前回取得時刻より新しい行を定期的に問い合わせる方式です。アプリケーション側の改修だけで成立するため、導入コストは3方式で最も低く収まります。

弱点は2つ。物理削除を検知できないことと、ポーリング間隔より短い時間に複数回更新された行は最終状態しか拾えないことです。前者は論理削除フラグへの統一、後者は要件として許容できるかの確認が必要になります。

トリガーベース（履歴テーブルに書き出す方式）

対象テーブルにトリガーを仕掛け、変更内容を専用の履歴テーブルへ書き込む方式です。削除も中間更新も取りこぼしません。DDL権限さえあれば導入でき、サーバーの設定変更が不要な点が実務では効きます。

代償は書き込み性能です。トリガーは元のトランザクションの内側で同期的に動くため、本番の書き込みレイテンシに直接上乗せされます。更新が多いテーブルほど影響が出ます。履歴テーブルの肥大化対策（パーティション・定期削除）も運用に含める必要があります。

ログベース（トランザクションログを読む方式）

データベースが内部で生成するトランザクションログ（PostgreSQLのWAL＝変更を先に書き込む履歴ログ、MySQLのバイナリログ、OracleのREDOログなど）を読み取って変更を検出します。アプリケーションもテーブル定義も変更せずに済み、本番DBへの追加負荷が最も小さい方式です。

一方で、DBサーバーの設定変更と、変更イベントを受け取る基盤（Kafkaなど）の構築・運用がセットで必要になります。導入のハードルが3方式で最も高いのはここです。

3方式の比較早見表

Debeziumとは｜ログベースCDCの代表的な実装

Debeziumは、ログベースCDCを実現するオープンソースのプラットフォームです。データベースを監視するように設定すると、行レベルの変更をアプリケーションから利用できるイベントとして取り出せます。ログベースCDCのOSSとして候補に挙がることが多く、商用サポート付きのディストリビューションも提供されています。

2026年10月時点でDebezium公式のリリース情報から確認できる最新系列は3.7です。バージョンは短い周期で更新されるため、導入前に必ず公式リリースページで現在の対応バージョンを確認してください。

対応データベースとイベントの中身

Debezium公式のアーキテクチャ解説によると、ソース側のコネクタはMySQL・MariaDB・MongoDB・PostgreSQL・Oracle・SQL Server・Db2・Cassandra・Vitess・Spanner・Informix・CockroachDBなどに対応しています。シンク側にもJDBC・MongoDB向けが用意されています。

対応状況はバージョンによって異なり、コネクタごとに安定度やサポート形態にも差があります。採用候補を絞る前に、公式の対応表で自分が使うデータベースのバージョンが含まれるか確認してください。

生成される変更イベントには、変更前の値（before）、変更後の値（after）、操作種別、トランザクション情報、ログ上の位置といったメタデータが含まれます。beforeが取れることが、単なる「最新行の転送」との決定的な違いです。

4つのデプロイ形態

ここが設計の分かれ目になります。

Kafkaを前提にするかどうかで運用負荷が大きく変わります。Kafka自体の設計・運用についてはApache Kafkaとは｜分散イベントストリーミング基盤の仕組み・用途・案件単価を解説を、受け取ったストリームを加工する層についてはApache Flinkとは｜ストリーム処理の仕組みとKafka・Sparkの違いを参照してください。

初期スナップショットとストリーミングの関係

Debeziumは初回接続時に一貫性のあるスナップショットを取得し、その時点のログ位置から継続的にストリーミングへ切り替えます。この引き継ぎがあるため、スナップショット中に発生した変更も漏れません。

注意点は初期スナップショットの所要時間です。数億行規模のテーブルでは数時間かかることもあり、その間は本番DBへの読み取り負荷が継続します。業務影響が小さい時間帯に実施する計画を立ててください。

主要データベース別の前提設定

結論：どのデータベースでも「ログ出力の有効化」と「専用ユーザーへの権限付与」の2点が共通の作業になります。 条件はDBごとに異なり、マネージドDBでは提供側が許可したパラメータしか変更できない点が例外にあたります。

PostgreSQLの場合

Debezium公式のPostgreSQLコネクタ解説では、ロジカルデコーディングを有効にするためにwal_levelをlogicalへ設定することが前提とされています。あわせてレプリケーションスロットとpublicationの用意が必要です。本番環境ではスロットを手動で作成する運用が推奨されています。

権限はスーパーユーザーを使い回さず、Debezium専用のレプリケーションユーザーに必要な権限だけを付与する形が推奨されています。

最も重要な警告はディスク枯渇です。 レプリケーションスロットが消費されない状態が続くと、PostgreSQLはWALセグメントを削除できません。コネクタを停止したまま放置すると、WALが積み上がってディスクを使い切ります。設定そのものより、この監視を入れ忘れることのほうが事故につながります。

PostgreSQL自体の特性はPostgreSQLとは？特徴・MySQLとの違い・案件単価・将来性をフリーランス視点で解説にまとめています。

MySQLの場合

バイナリログの有効化と、行単位の記録形式（ROW形式）への設定が前提になります。加えて、レプリケーション用の識別子（server-id）の割り当てと、レプリケーション権限を持つユーザーの作成が必要です。必要な設定値と権限の一覧はDebezium公式のMySQLコネクタ解説で確認してください。

バイナリログの保持期間も設計に含めます。保持期間が短い状態でコネクタが長時間停止すると、必要なログがすでに削除されていて再開できず、スナップショットの取り直しになります。

MySQLの基礎はMySQLとは？特徴・PostgreSQLとの違い・案件単価・将来性をフリーランス視点で解説で解説しています。

Oracle・SQL Server・マネージドDBの場合

Oracleは、ログの読み取りにLogMinerを使う方式が一般的です。アーカイブログモードの有効化と、追加ログ（サプリメンタルロギング）の設定が前提になります。

SQL Serverは、データベースとテーブルの両方でCDC機能を有効化したうえで、Debeziumがその変更テーブルを読み取る構成です。

マネージドDBでは、パラメータグループで許可された範囲しか変更できない点に注意してください。AWS RDSやAuroraの場合はパラメータグループ経由での設定と再起動が必要になるケースがあります。詳細はAWS RDSとは｜マネージドDBの基本・MySQL/PostgreSQLとの違い・案件単価をフリーランス視点で解説を参照してください。

ミニFAQ：設定変更にサービス停止は必要？

Q. wal_levelやバイナリログの設定変更で、本番を止める必要がありますか。

A. ケースによります。PostgreSQLのwal_levelは再起動が必要なパラメータのため、計画停止かフェイルオーバーを伴う作業になります。MySQLでバイナリログを新たに有効化する場合も再起動が前提です。すでにレプリカ構成でバイナリログやWALが有効になっている環境では、追加の再起動なしで進められることもあります。現状の設定値を先に確認してから計画を立ててください。

CDCの典型ユースケース

CDCが効くのは「同じデータを別の場所でも最新に保ちたい」場面です。代表的な3つを挙げます。

分析基盤へのニアリアルタイム連携

業務DBの変更をデータウェアハウスへ流し込み、ダッシュボードの鮮度を上げる用途です。夜間バッチでは「昨日までの数字」しか見えなかったものが、数分遅れの数字で判断できるようになります。

送り先としてはBigQueryとは？特徴・できること・データ分析案件の単価をフリーランス視点で解説やSnowflakeとは？データクラウドの特徴・BigQueryとの違い・案件動向をフリーランス視点で解説、Databricksとは｜レイクハウスの仕組み・Snowflakeとの違い・案件単価が候補になります。

マイクロサービス間のデータ同期とOutboxパターン

複数サービスでデータを持ち合う構成では、「DBに書く」と「イベントを発行する」を両方やると、片方だけ成功する二重書き込み問題が起きます。

この回避策がOutboxパターンです。業務データの更新と同じトランザクションで送信用テーブルに1行書き、その行の変更をCDCで拾ってイベントとして配信します。トランザクションが成功したものだけが必ず配信される構造になります。DebeziumもOutboxイベントルーターとして公式に機能を提供しています。

前提となるアーキテクチャの考え方はマイクロサービスとは｜モノリスとの違い・採用判断・案件動向を解説、イベント駆動アーキテクチャとは｜同期APIとの違いと採用判断、イベントソーシングとCQRSとは｜違い・仕組みと導入判断の基準で整理しています。

停止時間を抑えたデータベース移行

移行元の全データをスナップショットで移したあと、移行中に発生した変更をCDCで追いかけ、差分がほぼ消えた時点で切り替える手法です。全件コピーの時間だけサービスを止める方式に比べ、停止時間を大幅に短縮できます。オンプレからクラウドへの移行案件で使われることの多いパターンです。

自前Debeziumとマネージドサービスの選び方

結論：Kafkaをすでに運用しているか、配信先が複数あるなら自前Debezium。単一クラウド内でDWHへ流すだけならマネージドが素直です。 条件はチームの運用体制とクラウド構成、例外はコストが読みにくい大容量ワークロードです。

主要な選択肢の比較

公式の仕様はAWS DMSのユーザーガイドとGoogle Cloud Datastreamの概要で確認できます。課金モデルが「処理データ量」か「インスタンス稼働時間」かで総額の見え方が変わるため、見積もり時は自分のワークロードに当てはめて試算してください。

判断フロー

上から順に当てはめると、だいたい一意に決まります。

1. DBサーバーの設定を変更できない → ログベースを諦め、トリガーベースかクエリベースを検討する

2. 変更できる、かつ配信先が単一クラウドのDWHだけ → マネージドサービス（Datastream・DMS等）を第一候補にする

3. 配信先が複数ある、またはストリーム処理を挟む → Debezium + Kafkaを検討する

4. Kafkaの運用を持ちたくないが自前で組みたい → Debezium Serverを検討する

5. チームにKafka経験者がいない、かつ納期が短い → マネージドかSaaSに寄せ、自前構築は次フェーズに回す

逆に、日次レポートで鮮度が足りている、物理削除を使っていない、CDC基盤を見る運用担当を置けない、のいずれかに当てはまるなら、既存のバッチ連携を維持するほうが安全です。CDCは「入れない」判断も正解になります。

5番は軽視されがちですが、実務では最も効く判断軸です。Kafka ConnectとDebeziumの組み合わせは、動かすだけなら数日でも、本番運用に耐える監視・再起動手順・スキーマ運用まで含めると設計に1〜2か月を見ておくほうが安全です。

CDC導入チェックリスト

設計レビューの前に、以下を埋められるか確認してください。

• 対象テーブルと、連携しないテーブルを列挙したか

• 遅延の許容値を数値で決めたか（例：5分以内）

• 物理削除があるか。ある場合、下流でどう表現するか決めたか

• 初期スナップショットの所要時間と実施時間帯を見積もったか

• レプリケーションスロット・バイナリログの監視項目とアラート閾値を決めたか

• コネクタ停止時の最大許容停止時間を、ログ保持期間より短く設定したか

• 下流の処理を冪等（同じ処理を複数回実行しても結果が変わらない状態）にしたか

• スキーマ変更時の手順と、関係者への連絡経路を決めたか

• 個人情報を含むカラムのマスキング・除外方針を決めたか

• 障害時にスナップショットから取り直す判断基準を決めたか

CDC導入でつまずきやすい5つのポイント

レプリケーションスロットの放置とディスク枯渇

最頻出の事故です。コネクタを止めたまま連休を挟み、WALが積み上がって本番DBのディスクを圧迫する、という流れで起きます。スロットの遅延量（未消費のログサイズ）を監視項目に入れ、閾値を超えたらアラートを上げる設計にしてください。使わなくなったスロットの削除も運用手順に含めます。

重複配信と冪等性

ログベースCDCの配信保証は、基本的に少なくとも1回（at-least-once）です。障害復旧時に同じイベントが再送される前提で下流を作る必要があります。主キーと変更位置を使った上書き（UPSERT）にしておくと、重複が来ても結果が壊れません。

スキーマ変更への追従

上流でカラムが追加・削除されると、下流のテーブル定義と食い違います。スキーマレジストリでイベントの構造を管理する、あるいは下流を半構造化のまま受けて変換レイヤーで吸収する、といった方針を先に決めておきます。運用で効くのは技術選定より、DDLを打つ前にデータ基盤側へ連絡が来る体制を作ることです。

初期スナップショット時の負荷

大規模テーブルのスナップショットは本番DBへの読み取り負荷になります。リードレプリカから取得する、テーブルを分けて段階的に実施する、といった分散が有効です。増分スナップショット（テーブルを少しずつ取り込みながらストリーミングも継続する方式）に対応しているかも確認してください。

「とりあえず全テーブル」にしてしまう

対象を絞らずに始めると、イベント量が膨らみ、監視対象も増え、コストが読めなくなります。最初は業務上の価値が明確な数テーブルに限定し、運用が回ることを確認してから広げる進め方が無難です。

CDC案件とフリーランスの単価

結論：CDC単体を要件に掲げる案件は多くありません。データ基盤構築やマイクロサービス移行の案件要件の一部として登場するのが実情です。

以下の数字は、2026年10月時点で首都圏中心の主要フリーランスエージェント数社の公開案件ページ（週4〜5日稼働の準委任案件が中心、リモート可の募集を含む）を確認し、データ基盤・ストリーミング関連の募集のうちCDC・Debezium・トランザクションログ連携に言及していたものを観測ベースで整理した目安です。該当する公開案件は数十件規模の確認にとどまるため、レンジは参考値として読んでください。CDC単独の案件ではなく、CDCを構成要素として含むデータ基盤・ストリーミング案件を対象にしたレンジである点にも注意してください。

まずは公開案件ベースの目安として読んでください。非公開案件は個別条件で上振れするケースがありますが、母集団が異なるため同列には扱えません。

レイヤー別のより詳しい相場はデータ基盤案件の単価相場｜ETL・DWH・BIレイヤー別の目安とスキル、職種としての全体像はデータエンジニアとは？仕事内容・年収・将来性をわかりやすく解説とデータエンジニアの年収は？単価相場からフリーランスの報酬まで解説にまとめています。

自分がどのくらいの単価を狙えるか気になる方は、無料のフリーランスエンジニア単価診断で現在の市場単価の目安を確認できます。単価を体系的に上げる考え方は『フリーランスエンジニアの単価相場と単価の上げ方』で整理しています。

案件の探し方と、職務経歴書に書くべきこと

案件を探す際は、「CDC」という語だけで絞ると母集団が小さくなります。Kafka・Debezium・Datastream・DMS・データ基盤といった周辺ワードを併用し、フリコンの案件一覧などで横断的に見るほうが実務的です。

職務経歴書では、使ったツール名より扱ったデータ量・遅延要件・障害対応の経験が評価されます。「日次1,000万件の変更を遅延5分以内で連携」「スナップショット再取得の手順を整備」といった書き方のほうが、面談での具体的な会話につながります。未経験から入る順序はフリーランスデータエンジニアになるには？案件の探し方と必要スキルを解説が参考になります。

まとめ

CDCは「変わった行だけを低遅延で届ける」技術で、サーバー設定を変更できる環境ならログベースを第一候補に、設定権限がなければトリガーベースへ落とすのが実務的な順序です。

• CDCの価値は転送量・鮮度・削除検知の3点。鮮度が業務要件でないならバッチのままでよい

• 方式選定は「サーバー設定の権限」「物理削除の有無」「書き込みレイテンシの余裕」の3つで決まる

• Debeziumは4つのデプロイ形態を持つ。Kafkaを前提にするかどうかが運用負荷の分岐点

• PostgreSQLはレプリケーションスロット放置によるディスク枯渇が最大の事故要因。監視を必ず入れる

• 配信は少なくとも1回が基本。下流は冪等に作る

• 単一クラウド内でDWHへ流すだけならマネージドサービスのほうが素直

次のステップとしては、対象テーブルを3つ程度に絞り、ローカル環境でDebeziumを動かしてイベントの中身を確認するところから始めてください。beforeとafterの構造を自分の目で見ると、下流の設計方針が具体的に決まります。

参照した一次情報は以下のとおりです。

• Debezium公式ドキュメント：アーキテクチャ

• Debezium公式ドキュメント：PostgreSQLコネクタ

• Debezium公式ドキュメント：Outboxイベントルーター

• Debezium公式ドキュメント：MySQLコネクタ

• Debezium公式：リリース一覧（最新バージョンの確認用）

• AWS Database Migration Service ユーザーガイド

• Google Cloud Datastream の概要