CDCでAI Knowledgeを更新する

Change Data Capture（CDC）は、databaseの変更をAI/RAG knowledgeへ低遅延で届ける経路として利用できます。ただし、CDCを導入しただけでsource databaseからretrieval indexまでexactly-onceに一致するわけではありません。 CDC transportと、document/chunk/embedding/search indexへのmaterializationを別のstate machineとして管理します。

初回snapshotと継続change streamの境界を明示します。 connector/database/versionによってはsnapshotとstreamの切替付近でduplicateが発生し得ます。snapshot完了というcontrol eventだけでduplicate-freeを仮定せず、source positionとevent identityをconsumerへ渡します。

各materializationにsource database/table、entity/aggregate key、source offset/LSN/binlog position、event ID、operation、schema version、transform/chunker version、embedding model/version、materialized-at timestampを結び付けます。 同一eventの再配送をidempotentに処理し、既に適用済みのsource positionより古いeventを無条件に上書きしません。

Kafka Connectにはsource connector向けexactly-once supportがありますが、connector capability、worker configuration、distributed mode等の条件があります。 このexactly-once boundaryをembedding APIやvector/search indexへの外部writeまで拡張して解釈しません。 source→Kafkaがtransactionalでも、Kafka→transform→embedding→indexは別のfailure/transaction domainです。各段階でidempotency、precondition、readbackを設計します。

historical change eventを常にcurrent database schemaでdecodeしません。 Debeziumのようにschema historyを保持する実装では、eventが発生した時点のschemaを再構成する仕組みがあります。schema changeとconsumer rolloutの順序を管理し、未知schemaをsilent coercionしません。

database rowをそのままembedding identityにしません。 canonical document生成、chunking、normalization、embedding modelのversionをmaterialization identityへ含めます。transform/versionが変わった場合は、同じsource rowでもrebuild対象として識別します。 UPDATEでは新chunkを追加するだけでなく、旧chunkとの置換関係を確定します。

source delete eventを受信したことと、knowledge surfaceから実際に消えたことを分けます。 delete/tombstoneを処理した後、vector/search index、cache、derived document等の対象をreadbackし、残存がないか確認します。privacy erasureではbackup/retentionを含む別のdata-lifecycle要件も確認します。

connector processがhealthyでもknowledgeがfreshとは限りません。 source positionからtransform、embedding、index commitまでのmaterialization watermarkを持ちます。source-to-index lag、oldest pending event、failed materializationを監視します。

full rebuildやbackfillをlive streamと無制御に並走させません。 rebuild開始時のcutover watermarkを固定し、snapshot由来recordとlive eventをdedupeします。rebuild完了後にwatermark以降のchangeを確実に適用してから切り替えます。

CDC streamだけを唯一のcorrectness detectorにしません。 定期的にsource-of-truthとknowledge indexをreconcileし、entity inventory、version、hash/count、sampled content、delete stateを比較します。 missed event、offset rewind、transform failure、index partial write、stale chunkを検出した場合は、対象entityまたはbounded rangeを再materializeします。

CDC対象table/columnがretrieval利用を許可されているとは限りません。 source scope、tenant、data classification、row/field authorizationをmaterialization前に確認します。database access権限とAI retrieval公開範囲を同一視しません。

snapshot/stream duplicate、source-log loss、offset rewind/loss、connector restart、schema evolution、key change、out-of-order/duplicate event、delete loss、transform/embed/index failure、stale chunk、model-version drift、lag、rebuild/live race、poison event、ACL drift、PII deletion residual、index eventual consistencyを想定します。

本項は2026-10-06時点のDebeziumおよびApache Kafka Connect documentationとbounded local fixtureに基づきます。live database、CDC connector、Kafka、vector/search indexへのmutationは未実施です。

CDCはAI knowledge更新の変更配送経路として有効ですが、source databaseからretrieval indexまでのexactly-once correctnessを自動的には保証しません。snapshot/stream境界、source offset、event dedupe、entity ordering、event時点schema、delete propagation、transform/embedding version、index writeのidempotency、watermarkと定期reconciliationを別々に検証してください。

対象database、CDC connector/version、managed CDC、log retention、snapshot mode、offset形式、schema history/registry、index/vector store、chunk/embed model、ACL propagation、delete/retention、RPO/RTO、rebuild procedure、reconciliation SLOは未確認です。

CDC transportとAI knowledge materializationを分離し、snapshot duplicate、exactly-once boundary、schema history、delete/readback、reconciliationを監査可能な運用境界として固定します。