「基幹システムで登録したはずの一件が、在庫側に反映されていない」——複数のシステムを連携させる受託案件では、こうした「たまに一件だけ抜ける」報告が、運用が始まってしばらくしてから上がってきます。よくある作りは、夜間バッチで一方のデータベースを丸ごと読み、もう一方へコピーする方式です。これは大半のケースで動きますが、コピー中に更新された一件をすり抜けたり、前回コピー以降に削除されたデータの扱いを誤ったりして、少しずつズレが溜まる。全件コピーし直してもズレが消えないとき、原因は「変更を後から全体を見て推測している」ことにあります。いつ・何が変わったかを正確に拾えていないのです。
この「変更を漏れなく拾って届ける」ための定番の手法が、変更データキャプチャ（CDC, Change Data Capture）です。InfoQ が 2026 年 6 月に紹介した Write-Ahead Intent Log: A Foundation for Efficient CDC at Scale（InfoQ） は、大規模でも変更を取りこぼさず CDC を成立させる設計を扱っています。規模は違っても、「全件コピーではなく、変更そのものを追う」という発想は、受託の地味なシステム間連携にこそ効きます。本記事では、CDC を受託の文脈でどう捉え、どう導入を判断するかを整理します。
なぜ「全件コピー方式」が取りこぼすのか
夜間バッチで全件を読んでコピーする連携は、作るのが簡単で、最初は問題なく動きます。取りこぼしが生まれるのは、この方式が抱える次の弱点が、運用の中で顔を出すからです。
第一に、コピー中の更新を捉えられない。何万件ものデータを読んでいる最中に、別の処理がその一件を更新したら、読み終えたデータは古いままか新しいままか、タイミング次第でブレます。読んでいる間も世界は止まりません。
第二に、削除が伝わらない。元のデータが削除されたとき、全件コピーでは「無くなったこと」をコピー先に伝えるのが難しい。コピー先に残骸が残り続け、両者がズレていきます。
第三に、遅延と負荷が大きい。一日一回のバッチでは、その間に起きた変更は最大で丸一日反映されません。かといって頻度を上げると、毎回全件を読むので、データが増えるほど処理が重く、本番のデータベースに負荷をかけます。
第四に、ズレの原因を追えない。「いつ・何が変わったか」を記録していないので、ズレを見つけても、どの変更が抜けたのかを後から特定できません。再発防止が、毎回「全件コピーし直し」になってしまいます。
複数システムにまたがってデータがどう流れているかが見えなくなる構図は、サービス間の繋がりが追えなくなる問題と同根です。何がどこへ連携しているかを把握する考え方は、サービス依存関係の可視化の記事で扱ったとおりで、CDC はその「データの流れ」を確実な一本道にする手段です。
CDC の基本 — 「結果を比べる」から「変更を追う」へ
CDC の発想は、コピー先とコピー元の結果を後から比べるのではなく、コピー元で起きた変更そのものを順番に拾って届けることです。鍵になるのが、多くのデータベースが内部に持っている変更の記録です。
データベースは、データを書き換える前に「これからこう変える」という記録を先に残してから、実際の更新を行う仕組み（先行書き込みログ、Write-Ahead Log）を持っています。これは本来クラッシュからの復旧用ですが、この記録を読めば、いつ・どの行が・どう変わったかが、起きた順番のまま正確に分かる。CDC は、この変更の記録を順に読み取り、他システムへ届けます。
全件コピー方式:
毎晩、テーブル全体を読む → コピー先と突き合わせる
（コピー中の更新・削除を取りこぼしやすい／重い）
CDC方式:
DBの変更記録を、起きた順に読む
「Aを追加」「Bを更新」「Cを削除」を一件ずつ届ける
（変更そのものを追うので、取りこぼしと削除漏れが起きにくい）この切り替えで、先の弱点が裏返ります。
| 観点 | 全件コピー | CDC |
|---|---|---|
| コピー中の更新 | 取りこぼしやすい | 変更を順に拾うので漏れにくい |
| 削除の伝達 | 伝わりにくい | 「削除」も一つの変更として届く |
| 反映の速さ | バッチ間隔ぶん遅れる | 変更ごとにほぼ即時 |
| 本番への負荷 | 毎回全件を読み重い | 変更分だけで軽い |
| ズレの追跡 | 原因を特定しづらい | 変更の履歴を辿れる |
「変更を順番どおりに、確実に届ける」という性質は、処理の途中で落ちても続きから再開できる信頼性のある実行と相性が良い。届け先での処理を確実にやり切る設計については、永続ワークフローの記事で扱った考え方と組み合わせると、連携全体を「落ちても取りこぼさない」形にできます。
受託で導入するときの落とし穴
弊社が連携の改修を引き継いだある卸売業の受託システム（社名は伏せます）では、基幹の受注データを在庫管理へ夜間バッチでコピーしていて、月に数件、在庫に反映されない受注が出ていました。現場は「数が合わないので毎朝、目視で突き合わせている」状態で、その手作業が常態化していました。原因は、バッチ実行中に登録・修正された受注の取りこぼしと、キャンセル（削除）が在庫側に伝わっていないことの二つでした。
私たちは、全件コピーをやめ、基幹データベースの変更記録を順に読んで在庫側へ届ける CDC 方式へ段階的に切り替えました。いきなり全テーブルを対象にせず、取りこぼしが実害になっていた受注テーブルだけを先に CDC 化し、効果を確認してから対象を広げる方針です。受注の追加・修正・キャンセルが、起きた順に在庫へ届くようになり、毎朝の目視突き合わせは不要になりました。やったのは、結果を後から比べる方式を、変更を順に追う方式に替えただけです。
この改修で一番効いた学びは、「同じ変更が二回届いても壊れない」ように受け取り側を作ることでした。CDC は再送や再開が起こり得るため、同じ変更が二度届く可能性があります。受け取り側が素朴に「受注を追加」と処理すると、二重登録が生まれる。各変更に一意の識別子を持たせ、「すでに処理済みなら何もしない」形（冪等な受け取り）にしておくのが必須です。これを怠ると、取りこぼしは直っても、こんどは重複という別の障害が出ます。
もう一つの落とし穴は、連携するデータの形（スキーマ）の変化に備えることです。基幹側でテーブルの構造が変わると、CDC で流れてくる変更の形も変わり、受け取り側が解釈できなくなります。連携が増えるほど、このスキーマの食い違いが事故の温床になります。流れるデータの形を取り決めて管理する考え方は、スキーマ氾濫を抑える記事で扱ったとおりで、CDC を入れるなら最初からスキーマの管理を併せて設計するのが安全です。
どこから着手するか
システム間のデータ連携で「たまに一件抜ける」「削除が伝わらない」「毎朝の目視突き合わせが常態化している」なら、全件コピーから変更を追う方式への切り替えを検討する価値があります。ただし、全テーブルを一度に CDC 化する必要はありません。
最初の一歩としては、取りこぼしが最も実害になっている一つのテーブル（受注・在庫・会計など）を選び、そこだけを CDC で連携してみること。そのうえで、受け取り側を「同じ変更が二回来ても壊れない」冪等な作りにし、流れるデータの形を取り決めておく。これだけで、最も困っていた連携の取りこぼしが止まり、効果を確認してから対象を段階的に広げられます。
システム間の連携でデータがたまにズレる、削除やキャンセルが片方に伝わらない、数を合わせるための手作業が常態化している——そうしたお悩みがあれば、グリームハブのお問い合わせからご相談ください。現行の連携方式を拝見し、取りこぼさない CDC ベースの連携へ、システムを止めずに段階的に寄せる設計をご一緒に組みます。
