ETL・ELTからAIの知識索引まで更新の成立を追う

ETLは取り出したデータを変換してから読み込み、ELTは読み込んだ後の基盤で変換します。AIの知識更新では、その後にも解析、分割、embedding、索引公開、権限の反映があります。取込ジョブが成功しただけで、検索や回答が最新・正確・閲覧可能になったとは判断できません。原本から検索可能な版まで、何がどこまで反映されたかを追います。

AirbyteのIncremental Appendはcursorを用いて変更分を取得し、Append + Dedupedは主キーとcursorに基づいて最終状態を重複排除します。文書は、元データが変わってもcursor列が適切に更新されなければ、変更を取得できない制約を示しています[S1: Known Limitations]。主キー・cursor・connectorを確認せず、増分同期を差分の完全な検出として扱いません。

DebeziumのSQL向けNew Record State Extractionは、変更イベントを単純化するSMTです。元のイベントは操作種別、出所、時刻、変更前後などを持ち、SMTの設定により付加メタデータや削除イベント・tombstoneの表現が変わります[S2: Change event structure / Behavior / Configuration options]。削除について、同一ページの説明文とオプション表を確認すると、保持・変換・除去の選択を実設定で確かめる必要があります。本記事は「デフォルトなら必ず削除が下流へ伝わる」と断定しません。

OpenLineageは、run・jobと入力・出力datasetの関係、およびschema、version、品質等のfacetを表現する仕組みを提供します[S3]。lineageイベントが存在することは、索引の検索結果や認可の正しさを検証済みという意味ではありません。これらの取込・変換の契約とAI側の受入契約を接続します。

以下は辞典の提案です。原本ID、原本version/hash、更新時刻、取得時刻、connector版、変換版、schema、ACL、派生物のIDを保持します。機密データを全ての台帳へ複製せず、参照と必要な証拠に限定します。

処理が失敗しても、原本を再取得するところから全てやり直す必要がないように、独立して再実行できる単位を作ります。一方、後段の成功を理由に前段の欠落を隠しません。受信件数、変換成功、意図的除外、失敗、公開件数が対応するようにし、除外した理由を追える状態にします。

増分更新では、同じ時刻を持つ複数レコード、遅れて届く変更、cursorを更新しない修正、主キー変更を確認します。境界を重ねて再取得する場合は、安定したIDと版で重複を抑えます。取得した直後にcursorだけを先へ進め、下流への永続化が終わっていなければ、再開時に取り残しが起こります。checkpointの意味を「取得済み」と「検索可能」を分けて記録します。

原本を削除しても、既存chunkやembeddingが自動で消えるとは限りません。原本IDから派生物を列挙できる関係を持ち、索引、cache、会話中の参照等へどこまで削除・失効を伝えるかを定めます。本文が同じでACLだけ変わった更新も処理対象です。削除命令や権限失効の反映が未確認の間は、古い索引へ単純に切り戻さないようにします。

再生時には、原本の同じ版と固定した変換設定を指定します。AIによる要約・分類を変換工程へ含めるなら、model/prompt、出力schema、検証条件を記録します。再実行で同じ文章になることを前提にせず、保存済みの出力と採用理由を残します。埋め込まれた命令を原本データとして扱い、外部処理への権限ある指示へ昇格させません。

新世代の索引を別領域に構築し、品質・削除・認可の検査後に参照先を切り替える方法が考えられます。ただし、原本、検索索引、cacheが一つのトランザクションになるとは限りません。切替中の可視性、遅延、古い応答、失効優先の制御を明示します。

仮想例として、原本十件のうち九件が解析でき、一件が失敗した場合、「十件取込成功」とは記録しません。九件だけを公開するなら、対象集合と一件の未公開理由を示します。本文は更新できてもACL更新が失敗した場合は、機密情報の公開条件を満たしたとは扱いません。見栄えのよい回答を一件作るだけで、全取込の成立を代替しません。

主な失敗は、silent drop、古い文書の残留、重複chunk、原本と引用の版違い、部分再生成、削除漏れ、ACL剥落です。検査には、内容だけ変えた原本、ACLだけ変えた原本、削除、同時刻更新、壊れたファイル、再試行、途中停止を含めます。検索結果から原本の正しい版と閲覧条件へ戻れることを確認します。

鮮度は、最終job成功時刻だけでなく、原本変更から検索可能になるまでの遅延として測ります。全更新、重要資料、削除・権限変更を分け、長い遅延や失敗した集合を隠さないようにします。件数が同じでも内容が古い場合があるため、ID・版・hashを用いた照合も行います。

今回、実connectorの同期、CDC、parser、embedding、索引切替、削除・ACL伝播の実機試験は実施していません。採用connectorの機能、cursorの精度、削除検出、対象APIの整合性、索引の原子性、実遅延と受入基準はUNKNOWNです。記録したschemaやhashは意味の正しさを自動保証しません。構造化されたwarehouseの成功を、RAG全体の正確性へ延長しません。

「特定の原本版と変換構成について、取込・検索・引用・認可・削除の反映を照合した」と表現します。AIの回答だけを信用して「知識更新済み」としません。

• [S1] Airbyte, Incremental Append / Append + Deduped. https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-modes/incremental-append ; https://docs.airbyte.com/platform/using-airbyte/core-concepts/sync-modes/incremental-append-deduped （2026-10-20確認、connector別成立は別途確認）
• [S2] Debezium, New Record State Extraction. https://debezium.io/documentation/reference/stable/transformations/event-flattening.html （同日確認、SQL向けSMTの仕様）
• [S3] OpenLineage, Dataset Facets. https://openlineage.io/docs/spec/facets/dataset-facets/ （同日確認、閲覧時の表示版1.54.0）
• 旧来歴: R1R-007-EA0249、退避Doc 1Vd0BP7G2UyPDRQs_-8dPvTgQ78Tk6kcVGuMJjqNdr84 tab t.0:13317–14700はEA-249～254の所在確認記録です。Luna先行成果を発見した証拠ではないため、旧研究の推測復元をせず現行資料から本記事を作成しました。