LASSIC Media らしくメディア
データ契約(Data Contract)導入、外注の要点
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- データを作る側と使う側の間でスキーマや品質を明文化する「データ契約(Data Contract)」がなぜ必要になるのかを整理します。
- 契約に含める要素（スキーマ・SLA・所有者・後方互換ポリシー）と、CIでの契約テスト・スキーマレジストリとの関係を解説します。
- 所有権や変更通知といった組織面の課題と、外注で導入を進める場合の委託範囲・発注前の準備事項をまとめます。
目次
データ契約とは何か、なぜサイロ間で必要になるのか
データ契約(Data Contract)とは、データを生成する側（プロデューサ）とデータを利用する側（コンシューマ）の間で、スキーマ・品質・意味・SLA（サービス品質保証）をあらかじめ明文化しておく取り決めを指します*1。プロデューサ側のシステム変更が、下流の分析基盤やアプリケーションを予告なく壊さないようにする役割を持ちます。
複数のチームがそれぞれのデータベースやAPIを持つ組織では、あるチームがテーブルの列名を変更したり型を変えたりすると、それを参照する下流のダッシュボードやバッチ処理が突然エラーを起こすことがあります。こうした「暗黙の依存」は、プロデューサ側から見えないところで発生するため、事前に検知しづらいという性質を持ちます。
データ契約は、この暗黙の依存を明示的な約束に変える手段です。データ契約の業界仕様を公開するOpen Data Contract Standard（ODCS、bitolコミュニティが管理する仕様）では、契約をプロデューサとコンシューマの間の「合意」として位置づけ、スキーマだけでなく品質・SLA・所有者・利用条件までを1つのドキュメントにまとめる構成を提示しています*2。
本記事が扱うデータ契約は、データの「意味」と「変更の約束」を扱う点で、データカタログやマスタデータ管理（MDM）とは役割が異なります。データカタログはデータ資産の発見と分類を、MDMは顧客・商品などの基幹データの一元管理を担うのに対し、データ契約はプロデューサとコンシューマの間の技術的な取り決めそのものを指します。
契約に含める4要素とスキーマレジストリとの関係
データ契約に何を書き込むかは仕様によって多少異なりますが、実務上重要になる要素は次の4つに整理できます。
| 要素 | 内容 | 留意点 |
|---|---|---|
| スキーマ | フィールド名・データ型・必須／任意・構造を定義します。 | ODCSでは「models」に相当する項目でフィールドを列単位に列挙します*2。 |
| 品質・SLA | データの鮮度（更新頻度）・完全性・可用性に関する約束を定義します。 | ODCSでは「serviceLevel」としてこれらの指標を扱います*2。 |
| 所有者 | 契約の責任者（プロデューサ側のチーム・担当者）を明記します。 | 変更提案や問い合わせの窓口を一意に決めておく必要があります。 |
| 後方互換ポリシー | 列の削除・型変更・必須化など破壊的変更をどう扱うかを定めます。 | 非互換の変更は新バージョンとして提供し、旧バージョンを一定期間残す運用が一般的です*3。 |
スキーマレジストリは、この4要素のうち「スキーマ」と「後方互換ポリシー」を実行時に強制する仕組みです。Apache Kafkaのエコシステムで広く使われるConfluent Schema Registryは、プロデューサとコンシューマの間のスキーマ整合性を検証する中央リポジトリとして機能し、互換性チェックによって「プロデューサ・コンシューマ間の契約が破られていないか」を確認します*4。
つまりデータ契約は「何を約束するか」を定義する文書であり、スキーマレジストリは「その約束が守られているか」を実行時にチェックする仕組みです。両者は代替関係ではなく、契約の一部（スキーマ整合性）を技術的に強制する補完関係にあります。
CIパイプラインでの契約テストの位置づけ
データ契約を書いただけでは、実際の変更がそれに違反していないかを人手で確認する負担が残ります。ここで有効になるのが、CI（継続的インテグレーション）パイプラインに契約テストを組み込む方法です。
変換ツールdbtの「モデルコントラクト」機能は、この考え方をSQLモデルに適用したものです。モデル定義のYAMLに列名とデータ型を明記して`contract: enforced: true`を設定すると、dbtはビルド時にモデルのクエリが返す列と、定義された列（名前・型）が一致するかを事前検証します。一致しない場合はビルドを失敗させ、想定外のスキーマ変更が下流に伝播する前に止めます*3。
dbtは前回のプロジェクト状態と比較して、既存列の削除やデータ型の変更、制約の変更・削除を破壊的変更として自動検知する機能も備えています。バージョン管理された公開モデルであればエラーとして扱われ、リリース前に検知できる仕組みです*3。
Kafkaベースのストリーミング基盤では、Schema Registryの互換性チェックを同様の位置づけで使えます。新しいスキーマを登録する際、既存のコンシューマが読み取れなくなる変更（後方非互換）であればレジストリ側で登録を拒否する設定が可能です*4。データ契約仕様の側にも、契約ファイル同士を比較して破壊的変更を検出するCLIツールが用意されており、こうしたツールをCIのプルリクエスト検証に組み込む運用が広がっています*3。
いずれの仕組みも共通するのは、「契約違反をレビュー担当者の目視ではなく、パイプラインの自動チェックで止める」という発想です。契約テストが通らない変更はマージされない、という運用ルールにしておくことで、契約が形骸化するリスクを抑えられます。
所有権と変更通知、組織面で詰めておくこと
データ契約は技術仕様であると同時に、組織間の責任分担を明文化する文書でもあります。導入にあたっては、技術的な項目に加えて次の3点を組織として決めておく必要があります。
- 契約の所有者：どのチーム・担当者が契約の変更提案を受け付け、承認する権限を持つかを一意に決めます。
- 変更提案の手続き：破壊的変更を加える際、コンシューマ側にどの経路（チケット・チャット・レビュー会議等）で事前通知するかを定めます。
- 移行期間の運用：旧スキーマと新スキーマを並行提供する期間、および期間終了後の切断タイミングの決定権者を定めます。
データ契約に関する解説では、プロデューサが契約を定義・保守する役割を担い、コンシューマが要件を検証し、ガバナンス側が自動化・運用を管理するという3者の役割分担が紹介されています*5。この役割分担が曖昧なままだと、契約ファイル自体は存在してもレビュー・承認が滞り、実質的に更新されない「名ばかり契約」になりやすい点には注意が必要です。
組織をまたぐデータ連携では、契約の変更が複数チームの開発スケジュールに影響します。そのため変更提案から適用までのリードタイムを決めておくことも欠かせません。この調整には、データ基盤の設計・運用の両方を理解した実務者が関わる必要があり、社内のリソースだけで進めるのが難しい場面では外部パートナーの支援を検討する組織もあります。
外注する場合の委託範囲と発注前の準備
データ契約の導入を外注する場合、委託できる範囲は大きく3段階に分けられます。第一に契約の設計支援（既存データ資産の調査、契約項目のたたき台作成）、第二に契約テストの実装（CIパイプラインへの組み込み、スキーマレジストリとの連携設定）、第三に導入後の運用支援（契約違反の監視、変更提案フローの整備）です。
いずれの段階も、対象システムのデータ構造とパイプラインの実装を理解した上での作業になります。契約項目の設計だけを内製し、CIへの組み込みや既存基盤との連携部分を外部パートナーに委託する分業も選択肢の一つです。
データ契約の設計・実装を内製で行う場合、データモデリングの知識に加えて、CI/CDパイプラインの構築経験、利用しているデータ基盤（dbt・Kafka・クラウドDWH等）固有のツールへの理解が必要になります。これらを兼ね備えた人材を社内だけで確保するのは容易ではなく、既存の運用保守体制の中で契約導入を進めたい場合は、外部パートナーとの連携が現実的な選択肢になります。
発注前に準備しておくと発注後の手戻りを減らせる情報は次の通りです。
- 契約対象にしたいデータ資産の一覧（テーブル名・API名・利用しているデータ基盤）
- 現在利用しているCI/CDツールとデータ基盤（dbt・Kafka・クラウドDWH等）の構成
- 下流でそのデータを利用しているチーム・システムの一覧（影響範囲の把握のため）
- 過去にスキーマ変更で下流が破壊された事例があれば、その経緯（優先度判断の材料になります）
これらの情報が事前に整理されていると、外部パートナーが契約対象の優先順位づけや工数見積もりを行いやすくなり、要件定義工程の期間短縮につながります。
まとめ：データ契約導入の3つの判断軸
本稿では、データ契約(Data Contract)がプロデューサとコンシューマの間の暗黙の依存を明文化する取り決めであることを整理しました。要点を3つに集約すると、第一にデータ契約はスキーマ・SLA・所有者・後方互換ポリシーの4要素で構成され、第二にその実効性はCIでの契約テストとスキーマレジストリによる実行時検証で担保され、第三に技術面だけでなく所有権と変更通知の組織ルールを併せて整備する必要がある、という点に集約されます。外注を検討する際は、契約設計・CI実装・運用支援のどの段階を委託するかを見極めることが出発点になります。
よくある質問
データ契約とデータカタログはどう違いますか。
データカタログはデータ資産を発見・分類するための仕組みで、どこにどんなデータがあるかを整理します。データ契約はプロデューサとコンシューマの間で、スキーマ・品質・SLAをどう約束し、変更時にどう扱うかを定める取り決めです。両者は併用でき、カタログで発見したデータ資産に対して契約を結ぶという流れが一般的です。
データ契約を導入する際、既存システムの改修は必須ですか。
契約ファイルの作成自体は既存システムの改修を必須としません。ただし、CIでの契約テストやスキーマレジストリとの連携を実装する場合は、CI/CDパイプラインへの組み込み作業が発生します。まず契約項目を明文化するところから始め、段階的に自動検証を追加する進め方も選択肢になります。
dbtを使っていない場合でもデータ契約は導入できますか。
導入できます。dbtのモデルコントラクトはdbtを使う場合の実装手段の一つであり、データ契約という考え方自体はツールに依存しません。Kafkaを使うストリーミング基盤であればConfluent Schema Registry等の互換性チェック機能、その他のバッチ処理基盤であればOpen Data Contract Standardのような契約仕様とCLIツールを組み合わせる方法があります*2*4。
契約に違反した変更が発生した場合、どのように検知しますか。
CIパイプラインに契約テストを組み込んでいれば、ビルド時またはプルリクエストの検証時に検知できます。dbtのモデルコントラクトはビルド前のプリフライトチェックで列の不一致を検知し、Schema Registryは新しいスキーマの登録時点で後方非互換な変更を拒否する設定が可能です*3*4。検知後は所有者への通知と、契約に定めた移行手続きに沿って対応します。
データ契約導入の外注はどの工程から依頼できますか。
契約項目の設計支援から依頼することも、CIへの契約テスト実装だけを切り出して依頼することも可能です。既存のデータ資産一覧や利用中のCI/CDツール・データ基盤の構成が事前に整理されていると、委託範囲の切り分けがスムーズになります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Andrew Jones “Driving Data Quality with Data Contracts”の考え方を紹介するdatacontract.com「Data Contracts: The Complete Guide」（bitol／datacontract.comコミュニティ）
- *2 出典：Bitol（Open Data Contract Standard運営コミュニティ）「Open Data Contract Standard (ODCS)」仕様（GitHub: bitol-io/open-data-contract-standard）
- *3 出典：dbt Labs「Model contracts」dbt Developer Hub ドキュメント（docs.getdbt.com）
- *4 出典：Confluent「Schema Registry Overview」Confluent Platform ドキュメント（docs.confluent.io）
- *5 出典：Atlan「Data Contracts: Key Aspects, Tools, Setup」（atlan.com）
