AIが使うデータの契約とスキーマ変更を管理する

データ契約は、作る側と使う側が、項目、型、意味、品質、更新、権限、変更手順を共有する約束です。AIが入力をそれらしく解釈しても、契約違反が直ったことにはなりません。項目名や型の互換性と、金額・時刻・対象集団等の意味の互換性を分け、変更の影響を検索、prompt、tool、評価データまで追います。

Confluent Schema Registryは、BACKWARD、FORWARD、FULLおよびそれぞれのtransitiveな互換性検査を説明します。BACKWARDは新しい読み手が古いデータを読める方向、FORWARDは古い読み手が新しいデータを読める方向です。transitiveな設定は過去の複数版との互換性を確認し、非transitiveな検査は直前版との確認になります。デフォルトのBACKWARDを、全過去版との互換性として扱いません[S1: Compatibility types / Transitive property]。

dbt model contractsは、モデルを構築する際の列名・型等の契約検査を提供します。対応するmaterializationや制約の強制はデータ基盤により異なり、全resourceへ一律に適用されるものではありません[S2: Prerequisites / Define a contract]。dbt model versionsは、破壊的変更を別版として公開し、利用側の移行を扱う仕組みです[S3]。

これらは製品が確認する範囲の説明です。schema検査が通ったことを、業務意味・アクセス許可・回答品質の全てが正しいという証明にしません。AI側の変換で型だけを合わせて、変更の意味を隠すことも避けます。

以下はAI運用向けの辞典の提案です。契約を文書だけにせず、検査できる条件、責任者、変更時の受入結果へ結び付けます。

例として金額がintegerのまま、単位が円から千円へ変わった場合、構造の検査だけでは検出できません。updated_atの文字列形式が同じでも、UTCから地域時刻へ変われば、期間検索や締め日の意味が変わります。顧客IDが同じ型でも、一意性の範囲が全社からtenant内へ変われば、tenantを含む識別が必要になります。これは一般的な失敗例であり、参照製品の実障害を主張するものではありません。

変更を、追加、削除、改名、型変更、意味変更、品質条件変更、権限変更へ分けます。「項目を追加しただけ」でも、厳密なschema、tool引数、全文hash、prompt内の列順に依存するconsumerは影響を受ける可能性があります。互換性はproducerとconsumerの組合せ、形式、使用している版、保存済みデータの範囲に対して判定します。

移行では、旧版を必要とするconsumerを棚卸しし、新旧版を混ぜず識別できる形で併存させます。変換adapterを置くなら、変換前後の契約版と、失われる情報を記録します。変換できない値をAIに推測させて無言で埋めず、未対応として返すか、承認された縮退へ進めます。移行期間を過ぎても旧版利用が残る場合は、呼出しの観測と担当者への引渡しを行います。

過去データの再処理は、当時のschemaと意味を読める構成で行います。新schemaを登録したことだけでは、保存済みデータ、索引、cache、評価用の正解値は変わりません。旧データを新しい単位として読まないよう、データ版と変換版を結び付けます。rollbackも、古いreaderが新しいデータを読めるかを確認し、単にアプリのcommitを戻せば成立するとは考えません。

AIが旧項目名から新項目を連想できても、互換性の受入証拠にはしません。正しい変換を行う専用処理と、その上のAI処理を分けます。検索可能であることと、その情報をその利用者へ示してよいことも分けます。schemaからACL列が落ちた場合、本文だけが正常でも公開条件を満たしません。

契約違反を検出したデータは、原本・失敗理由・契約版を付けて隔離し、担当者と再処理条件を決めます。全体を止めるか、正当な部分集合だけを公開するかは業務の影響で決めます。例外を無期限の「承認済み」にせず、範囲、期限、失効条件、残るリスクを明示します。

受入検査には、nullと空文字、未知の列挙値、単位変更、桁溢れ、timezone境界、複合key、項目の削除・改名、過去版の再生、tenantの混同を含めます。構造の互換性検査に加え、意味を確認できる少数の固定入力と期待値を持ちます。AIで作ったテストだけを正解とせず、業務上の定義と独立した確認者へ照合します。

今回、実Schema Registryやdbt project、warehouse、RAG索引の移行試験は実施していません。形式別の互換性規則、adapter・materialization別の強制条件、既存consumerの実依存、意味の受入基準、旧版利用の残数はUNKNOWNです。本文の契約表は共通標準の必須項目だと称するものではなく、採用組織の設計案です。厳しすぎる契約で必要な変更を妨げることもあるため、実際のconsumerと移行負荷を確認して適用します。

「特定の契約版・producer/consumerの組合せで、構造と業務意味の受入を検証した」と記します。「schema互換なのでAIの回答も正しい」とは記しません。変換結果と利用側の結果をreadbackします。

• [S1] Confluent, Schema Evolution and Compatibility. https://docs.confluent.io/platform/current/schema-registry/fundamentals/schema-evolution.html （2026-10-20確認、形式・方向・transitivityを区別）
• [S2] dbt, Model contracts. https://docs.getdbt.com/docs/mesh/govern/model-contracts （同日確認、適用対象・制約の強制範囲は実基盤依存）
• [S3] dbt, Model versions. https://docs.getdbt.com/docs/mesh/govern/model-versions （同日確認、破壊的変更と移行の説明）
• 旧来歴: R1R-007-EA0250、退避Doc 1Vd0BP7G2UyPDRQs_-8dPvTgQ78Tk6kcVGuMJjqNdr84 tab t.0:13317–14700は所在確認だけの記録。旧Luna成果を推測再構成せず、canonical topicを維持して現行資料から本記事を完成しました。