📝
データコントラクトの概要と事例調査
データコントラクトとは何か
データコントラクトとは、データの提供者（プロデューサー）と利用者（コンシューマー）の間で交わす「契約」のことです（参考）ソフトウェアにおけるAPI契約のデータ版とも言え、提供されるデータについて構造（スキーマ）や形式、意味を定義し、さらにデータ品質保証の基準やサービスレベル目標（SLO）、データの利用規約、所有者まで含めて取り決めます 。この契約で定められたデータプロダクトのオーナー（責任者）が品質問題の対応責任を負う点も特徴です。データのスキーマや品質に関するチーム間の合意事項を文書化したものとして捉えられることもあります。
データコントラクト登場の背景
データコントラクトの概念は2019年頃から提唱され始め、欧州フィンテック企業GoCardlessのAndrew Jones氏が自社のデータ基盤で直面した問題を契機に発案したと言われています。従来、業務アプリケーションのデータベースをそのままETL/CDCで分析基盤に取り込み、後からデータ整形・クレンジングするのが一般的でした。しかしこの方法では上流のスキーマ変更が下流のレポートやダッシュボードを破壊し、ビジネスに支障をきたす恐れがあります。Jones氏は、重要なデータを連続的に複製するCDC環境ではバッチ処理よりリカバリーが難しく、粗悪なデータをせき止める仕組みが不可欠だと指摘しました 。その解決策として提供側と利用側でデータスキーマの契約を明示し、変更時にはバージョン管理と合意を経るというアイデアがデータコントラクトの源流となりました 。（参考）
データコントラクトが解決したいデータ基盤の課題
上流データ変更による下流破壊
アプリ開発者が不要と思ったカラムを削除した結果、下流の分析モデルやKPI計算が壊れる、といった事故が起こりえます 。これは、運用DBスキーマが合意無きAPIのように利用されていることが原因です。開発者は自分たちのデータが他チームに使われている認識や責任がなく、事前通知や変更管理もなされません 。
データ品質への無関心
プロダクト開発のエンジニアは自らの運用ユースケース以外でデータ品質の責任を持つインセンティブがなく、分析用途でどう使われるか認識していないケースが多くあります 。その結果、Garbage In/Garbage Outの悪循環（GIGOサイクル）に陥り、下流でゴミデータを拾っては対症療法的に清掃する非効率が発生します。
チーム間のコミュニケーション不足
従来、分析チームは上流サービスのデータ仕様を詳しく知らないまま利用しがちで、暗黙知や属人的な連携に頼っていました。その結果、「このフィールドのstatusって何の状態？」「order_timestampはどのタイミング？」といった定義の不明瞭さで誤解が生じます。プロダクト開発のエンジニアとデータチームのコミュニケーション不足は多くのデータ基盤で起きていると思われます。
データコントラクト導入のプラクティス（構成要素、組織体制、ツール）
構成要素
データコントラクトにおいて取り決める項目は以下のような内容になります。
①データスキーマ（項目名、データ型、必須/任意、形式フォーマットなど）、②データのセマンティクス（各フィールドのビジネス上の意味やルール）、③データ品質ルール（受け入れ基準となる制約やテスト項目）、④サービスレベル目標（遅延時間や更新頻度などのSLO）、⑤利用規約（データの用途制限やプライバシー/セキュリティ要件）、⑥オーナー情報（提供側責任者や連絡先）（参考）
組織体制
データコントラクトは単なる技術ではなく組織間の取り決めです。導入にあたっては以下の点に留意します。
データオーナーシップの明確化: 各データ領域に責任者（ドメインオーナーやデータプロダクトオーナー）を定め、契約の合意主体とします 。オーナー不在では契約が機能せず、結局データエンジニアが後追いで品質対応するハメになりがちです。
契約策定のコラボレーション: 利用チームと提供チームが協働して契約内容を作ります。利用者側がドラフトを提示し、提供側と何度も対話しながら項目定義や品質基準をすり合わせると良いでしょう 。この「コントラクトファースト」な要件定義プロセスによって、双方の期待値を一致させた上で開発・運用に入れます。
段階的な適用: 最初から全データに適用しようとせず、重要度が高く負担の小さい箇所から始めます。例えば10X社では、まず主要なデータソースについて「型」「項目説明」「Null許容か否か」といった基本事項の契約からスタートします。契約内容をあまり盛り込みすぎると提供側（開発チーム）の負荷が大きくなるため、まずは消費者にとって重要かつプロデューサー側の負担が少ない項目に絞ることがポイントです。 （参考）
変更管理と合意フロー: データコントラクトは変更時の手順も定めておきます。例えば「提供側が契約の新版を作成しn週間前までに通知」「利用側が承認したらリリース」といった合意フローを設計します。こうすることで、将来的なビジネス変化にも契約を更新しながら対応できます。契約変更はバージョン番号で管理し、古い版のサポート期限を設けることも検討します。
ツール
契約スキーマ管理: データコントラクトはYAMLやJSONなど機械可読な形でソース管理し、契約定義をコードとして扱います 。例えば先述のODCSのように標準フォーマットを用いるか、自社向けのスキーマ定義フォーマットを設計します。契約はGitリポジトリでバージョン管理し、変更差分を履歴に残します。10X社では、開発チームのコード内にスキーマ情報（型や説明）を埋め込み、CIで契約YAMLを自動生成・更新する仕組みをとっているようです。これによりドキュメントの手動メンテ不要で最新契約を維持し、契約変更が起きたコミットも追跡できています。
データ品質テスト自動化: データコントラクトで定義した品質ルールは、自動テストやモニタリングに組み込みます。例えばdbtの「モデル契約 (model contracts) 機能」を使えば、変換後テーブルのスキーマ（カラム名・型・制約）をあらかじめ宣言し、実行時に違反があればエラーとすることができます。Great Expectationsのようなオープンソースツールで期待値テストを実装し、契約準拠性を継続検証するのも一般的です 。これら既存ツールであれば初期導入のハードルが低く、まず小規模PoC的に契約駆動チェックを導入してみるのに適しています。
専用ツール・標準の活用: 最近ではデータコントラクト専用のCLIツールも登場しつつあります。例えばData Contract CLIというOSSは、YAMLで書かれた契約から自動的にデータ製品を検証するテストコードを生成し、CIパイプラインで実行できるようにする仕組みを提供しています。このようなツールをCI/CDに組み込めば、デプロイ時に契約違反がないか検証しつつリリースすることが可能です 。また前述のODCS (Bitolプロジェクト)のような業界標準に準拠したプラットフォーム製品が今後登場すれば、社外も含めた契約のやりとりが容易になることも期待されます。
国内外の導入事例
10X社の事例
ECプラットフォームを提供するスタートアップ10Xでは、データ生産者（開発チーム）と消費者（分析チーム）との間でデータの期待値にギャップがあり、仕様確認のコミュニケーションにも課題を抱えていました。これを解決するため2023年頃から段階的にデータコントラクトの導入を進めています 。具体的には、プロダクト開発チームが出力するBigQueryの中間テーブルを契約の境界と定め（コード上の型と実際に出力されるデータ型のずれを無くすため）、そのスキーマ情報（型・Nullable・説明文など）をソースコード中にアノテーションとして記述しました。CIパイプラインでその情報から契約YAMLを生成し、変更差分を自動検出できる仕組みも構築しています。まずは重要度の高いデータソースでPoC的に開始し、その成果を社内に周知しながら徐々に適用範囲を拡大しているとのことです。導入にあたっては「いきなり全部やろうとしない」「契約を結ぶポイント（データの境界）を明確にする」「契約情報とコードを乖離させず自動化する」といった知見が得られています。（参考）
PayPal社の事例
海外ではPayPalが代表的な事例です。同社はデータメッシュ戦略の一環で社内にデータコントラクト文化を根付かせ、ODCS (Open Data Contract Standard)として標準化を推進しています。PayPalでは各種社内データセットに対し契約テンプレートを適用し、スキーマやデータ品質ルールを明示的に管理していると報告されています。ODCSには「データ品質カテゴリ」「期待するデータの値範囲」「データ提供頻度」など詳細項目も含まれており、契約違反が発生した際には関係チームに通知される仕組みを備えています。ODCSはLinux Foundation傘下で標準となったことで、他企業も採用しやすい形で公開されている点が注目されます。（参考）
終わりに
この記事を書いている2025年4月時点ではデータコントラクトの取り組みは記事や公式ドキュメントも少なく、これがベストプラクティスと言えるものがまだないような印象でした。しかし、データの上流で品質を担保することは非常に重要であり、データ基盤の成熟とともにニーズは増してくるように思います！筆者もこれを機にスモールスタートでデータコントラクトに取り組みたいと思います！
Read next
Loading recommendations...