フレームワーク活用ガイドひとことで言うと#
データの提供者と利用者の間で「何を・どんな形式で・どの品質で・いつまでに届けるか」を明文化した合意書。APIの仕様書のように、データにも契約を設けることで、予告なしのスキーマ変更や品質劣化を防ぐ。
押さえておきたい用語#
- スキーマ（Schema）
- データの構造定義を指す。カラム名・データ型・Nullable可否などを規定したもので、コントラクトの中核をなす。
- SLA（Service Level Agreement）
- データの提供水準に関する合意のこと。更新頻度・遅延許容時間・可用性などを数値で定める。
- データプロデューサー（Data Producer）
- データを生成・提供する側のチームやシステムである。コントラクトに基づいてスキーマと品質を保証する責任を持つ。
- データコンシューマー（Data Consumer）
- データを受け取り・利用する側のチームやシステム。コントラクトに定義された仕様を前提にパイプラインやレポートを構築する。
- セマンティクス（Semantics）
- カラムの意味や業務定義を記述したもの。「revenue」が税込か税抜か、返品控除後かなどを明確にする。
データコントラクトの全体像#
こんな悩みに効く#
- 上流チームのスキーマ変更で、下流のダッシュボードが突然壊れる
- データの品質が劣化しているのに、誰が責任を持つのか曖昧
- チーム間で「このカラムの意味は何？」という確認が繰り返し発生する
基本の使い方#
すべてのデータに契約を作るのは現実的ではない。まずチーム間で共有され、問題が頻発しているデータから始める。
選定基準:
- 複数チームが利用しているデータセット
- 過去にスキーマ変更で障害が発生したテーブル
- 経営レポートやKPIに直結する重要データ
最初は3〜5個のデータセットに絞るのが成功のコツ。
プロデューサーとコンシューマーが一緒に以下を定義する。
スキーマ定義:
- カラム名、データ型、Nullable可否
- 主キー、外部キーの制約
セマンティクス:
- 各カラムの業務上の意味（例:
revenue= 税抜・返品控除後・円建て） - 計算式がある場合はその定義
品質基準:
- 欠損率の上限（例: 1%以下）
- 重複レコードの許容（例: ゼロ）
- 値の範囲（例:
ageは 0〜150）
SLA:
- 更新頻度と配信タイミング（例: 毎朝6:00 JSTまでに更新完了）
- 遅延の許容時間（例: 30分以内）
変更ルール:
- 破壊的変更（カラム削除・型変更）は2週間前に通知
- 非破壊的変更（カラム追加）は事後通知で可
契約を人手でチェックし続けるのは現実的ではない。CI/CDパイプラインに検証を組み込む。
検証の実装方法:
- スキーマ検証: Great Expectations、Soda、dbt testsでカラムの型・制約をチェック
- 品質チェック: 欠損率・重複・値の範囲を自動計測
- SLA監視: パイプラインの完了時刻を監視し、遅延時にアラート
契約違反が検出されたらSlack通知 + チケット自動起票する仕組みが理想的。
運用開始後、契約違反の傾向を月次で振り返る。
- 頻繁に違反する項目 → 品質基準が現実離れしていないか見直す
- 一度も違反しない項目 → 基準が甘すぎないか確認
- 新たな品質問題 → 契約に項目を追加
コントラクトは生きたドキュメントであり、運用しながら育てていくもの。
具体例#
状況: 従業員300名のD2C企業。プロダクトチームが管理するユーザーテーブルを、マーケティングチームがセグメント配信に利用している。
起きていた問題:
- プロダクトチームが
user_typeカラムの値を予告なく変更（“free”→“free_plan”）→ セグメント条件が不一致に emailカラムの欠損率が突然**8%**に上昇 → 配信対象から漏れるユーザーが発生- 週平均5件のセグメント配信エラーが発生
導入したコントラクト:
user_typeの許容値:free_plan,pro,enterpriseの3値に限定emailの欠損率: 0.5%以下- 破壊的変更: 1週間前にSlack通知 + コンシューマーの承認
導入後3ヶ月で配信エラーは週5件からゼロに。マーケティングチームが「とりあえず動くか確認する」作業に費やしていた週4時間がそのまま浮いた。
状況: 従業員2,500名の証券会社。取引データを基盤チームが集約し、リスク管理部門が規制レポートを作成している。四半期に1回の頻度で、レポート提出直前にデータ不備が発覚し、徹夜で修正するのが常態化していた。
コントラクトで定義した内容:
| 項目 | 基準 |
|---|---|
| 取引IDの一意性 | 重複ゼロ |
| 約定日時の欠損 | 0件 |
| 通貨コード | ISO 4217準拠 |
| 更新SLA | 翌営業日7:00までに反映 |
| 破壊的変更 | 4週間前通知 + 承認 |
Great Expectationsで日次検証を実装し、違反時はPagerDutyでオンコール担当に即時通知。提出直前の「データ不備発覚 → 徹夜修正」が4四半期連続でゼロに。規制領域では「問題を起こさないこと」自体が最大の成果であり、コントラクトはその保険として機能した。
状況: 人口25万人の地方自治体。12部署がそれぞれ独自フォーマットでオープンデータを公開していたが、利用者（市民・企業・研究者）から「フォーマットがバラバラで使えない」という苦情が年間40件以上寄せられていた。
各部署と「オープンデータコントラクト」を締結:
- ファイル形式: CSV（UTF-8） に統一
- カラム名: 総務省推奨語彙に準拠
- 更新頻度: 月次データは翌月10日までに公開
- 欠損値の表記: 空文字ではなく
NAで統一
公開前の自動バリデーションスクリプトを導入し、基準を満たさないファイルは公開不可とした。苦情件数は年間40件から3件に減少。「公開する」だけでなく「使える形で届ける」への転換が活用を呼び込んだ。
やりがちな失敗パターン#
- 契約を厳しくしすぎて運用が回らない — 欠損率0%、遅延0秒といった完璧主義の基準は違反が頻発して形骸化する。現状の実績値を測定し、そこから10〜20%改善した値を最初の基準にする
- コントラクトを作っても自動検証しない — 合意書だけ作って検証しなければ、ただの紙になる。契約と同時に自動テストを実装するのが鉄則
- プロデューサー側だけで勝手に決める — コンシューマーの要件を聞かずに一方的に定義すると、実際の利用に合わない契約になる。両者が同席して合意する場を設ける
まとめ#
データコントラクトは、データの提供者と利用者の間でスキーマ・品質基準・SLAを明文化する合意の仕組み。予告なしのスキーマ変更や品質劣化を防ぎ、チーム間のデータ連携を安定させる。まずは障害が頻発しているデータセットに対して契約を結び、自動検証を組み込むところから始めるのが効果的。