CRMに「商談化」と記録されたデータをMAへ渡す。集計ダッシュボードでは「商談化率」が表示される。しかし営業部門とマーケティング部門で、その言葉が指す出来事が違っていたらどうでしょう。連携そのものは動いていても、数字を根拠に意思決定することは難しくなります。
このような問題を考える手掛かりがデータ契約（Data Contract）です。データを作る側と使う側が、何を、どんな形式・意味・品質で提供し、変更時に何を知らせるかを定めます。この記事では、BtoBマーケティングのCRM・MA連携を例に、データ契約の意味と始め方を整理します。
データ契約とは――データの受け渡しに「期待する条件」を書く
データ契約は、データの提供者と利用者の間で、対象データの構造、意味、品質、サービス水準、所有者、変更方法などを明確にするための取り決めです。「契約」という名前ですが、必ずしも法律上の契約書や外部企業との有償契約を意味しません。社内で共有する仕様や運用上の約束として使う場合もあります。
Open Data Contract Standard（ODCS）の公式ドキュメントは、構造（schema）、意味（semantics）、品質（quality）、責任主体（ownership）、データの所在などをYAML形式で表現する枠組みを説明しています。特定のベンダー製品を買わなければ導入できないというものではありません。
ただし、文書を作っただけでデータが正しくなるわけではありません。内容を関係者が理解し、運用と検査に結びつける必要があります。
CRM・MA連携で起こりやすい四つの「ずれ」
1. 項目名は同じでも、意味が違う
営業の「新規リード」が、まだ連絡していない企業を指すのか、フォーム登録した個人を指すのか。どちらも社内では「リード」と呼ばれることがあります。集計結果を共有しても、異なる対象を数えていれば意思決定に使えません。
2. 更新したのに別のツールへ届かない
CRMの担当者変更が、MAへ反映されるのは数分後なのか翌日なのか。途中で連携が失敗したとき、誰が気づき、どのように再送するのか。更新頻度を決めていないと、同じ画面を見ていても情報の新しさが異なる場合があります。
3. 入力必須と、空欄を認める範囲が違う
「部署名」が空欄のデータを取り込めるか。削除済みの顧客はどう表現するか。フォーマットの条件を変えるだけで、受け取る側の処理が止まる可能性があります。
4. 予告なく項目が変更される
CRM側で「企業ID」という項目を別の型へ変更した場合、MAやBIの連携が失敗することがあります。項目名が変わらなくても、内容や計算方法が変わればレポートの意味は変化します。
以上は説明のために整理した実務例であり、特定企業における障害発生率を示すものではありません。
最小限のデータ契約に書くべき8項目
最初から大規模なデータ基盤を用意する必要はありません。例えばCRMからBIへ渡す商談データについて、まず次の項目を1枚にまとめます。
- 目的・利用者：誰が何の判断に使うデータか。顧客情報を受け取る正当な用途は何か。
- 提供元と更新責任者：原本を持つシステムと、データ項目を定義する部署・担当者。
- 項目定義：company_id、opportunity_id、stageなどの名前、型、値の意味。
- データの単位：一行が「企業」「人物」「商談」のどれを表すか。重複をどこまで許すか。
- 品質条件：必須項目、許容値、重複、欠損、確認できない値の扱い。
- 鮮度：更新の目安、遅延時の警告、再処理の方法。全データの即時同期が必要とは限らない。
- 変更の扱い：項目削除、名称・型・意味の変更を誰へいつ通知し、移行期間をどう設けるか。
- 利用・保護の条件：閲覧権限、保存期間、個人情報の利用目的、契約や社内規程の制約。
この8項目は当サイトが実務向けに整理したチェックリストです。ODCSの正式なフィールド名や必須項目と、一対一で一致するものではありません。
架空例：営業の「SQL」をダッシュボードで数える
以下は実在の企業の運用例ではなく、説明用の架空例です。マーケティング部門は営業へ渡した件数をSQLと呼び、営業部門は条件を確認して受け入れた案件をSQLと呼んでいるとします。
データ連携が正しくても、定義の違いを放置すると、同じ指標名で異なる数字が並びます。契約に定義を加えるなら、例えば次の点を記載します。
- 指標名：営業受入済みリード。
- イベント：営業が指定条件を確認し、受入ステータスを記録した時点。
- 識別：同じ人が複数商談へ関与する場合に、どの単位で数えるか。
- 時間：どのタイムゾーンの日付を使い、更新がいつ反映されるか。
- 例外：差し戻し、重複、誤登録、後日の訂正をどう扱うか。
- 管理者：業務定義の最終責任者と、技術連携の担当者。
これで必ず正しい指標になるわけではありません。顧客の購買段階と社内の営業ステージの違いを理解し、実際の入力ルールや運用が定義に合っているかも確認します。
データ契約とデータ品質検査は別だが、組み合わせるとよい
「部署名は必須」「企業IDは重複しない」という取り決めを作っても、実際のデータを検査しなければ違反には気づけません。Google CloudのKnowledge Catalog（旧Dataplex Universal Catalog）は、欠損、値の妥当性、一意性、カスタムSQLなどで品質を確認するデータ品質スキャンを説明しています。
品質検査が失敗したときは、すべてのデータを自動で削除するのではなく、原因を調べ、業務への影響を判断します。例えば部署名が不明なリードは、入力不備なのか、本人が回答していないだけなのかで対応が変わります。
契約は期待する状態を記述するものであり、検査は現実の状態がそれに合っているか確認するものです。両方を混同しないことが大切です。
データ契約とAPI仕様書・SLA・プライバシーポリシーの違い
API仕様書は、リクエストやレスポンスの形式、認証などのインターフェースを中心に説明します。データ契約ではそれに加え、業務上の意味、品質、利用者への影響、変更の通知などを扱えます。
SLAは、提供するサービス水準や合意した目標を定義する考え方です。データ契約では鮮度や可用性を含める場合がありますが、すべてのデータ契約が法的なSLAを生むわけではありません。
また、個人情報の利用目的や第三者提供の条件をデータ契約に記載しても、それだけで適法な取得・提供・利用になるとは限りません。企業のセキュリティ・法務・プライバシー担当による確認が必要です。詳しくはゼロパーティデータと個人情報の取扱いを参照してください。
dbtのモデル契約が示す「変更すると壊れる」問題
dbtの公式ドキュメントは、モデル契約で列名・データ型などの構造的な条件を示し、それらを変える際に下流の利用者へ影響することを説明しています。
例えばこれまで文字列だった企業IDを整数へ変更すれば、読み込む仕組みや結合処理が壊れる可能性があります。dbtのモデルバージョン機能は、破壊的な変更を行う場合に、新旧モデルを一定期間並行させ、利用者が移行する時間を設ける方法を示しています。
ただし、dbtによる検査がすべての業務定義の変更を自動検知するわけではありません。同じデータ型のまま「商談化」の意味を変えた場合も、実務上は重要な変更になり得ます。技術的な差分検出と、業務上の変更管理は両方必要です。
最初の2週間で試す小さな導入
以下は既存のCRM・MAを持つBtoBチームを想定した当サイト独自の実務提案です。全社のデータ基盤を作り替える話ではありません。
- 1〜3日目：営業・マーケティング双方が頻繁に使い、食い違いが問題になるデータを一つ選ぶ。
- 4〜6日目：提供元と利用者が、項目名、業務上の意味、単位、更新・欠損の扱いを文章化する。
- 7〜10日目：手動または承認された仕組みで検査し、実際の欠損や誤解、変更の影響を確かめる。
- 11〜14日目：定義の変更が必要な点、判断者と通知先、負担の大きい条件を見直す。
小規模チームでは、最初は共有文書でも構いません。技術的な自動検査は、利用規模と失敗の影響が大きくなった時点で検討する方法もあります。大規模な規約やツールの導入を目的化しないことが重要です。
変更通知は「技術担当だけ」に送ればよいわけではない
データを使うのはエンジニアだけではありません。営業、マーケティング、財務、経営が同じ指標を参照する場合もあります。データの項目が変わらなくても、定義が変わると数値の解釈や過去比較に影響します。
そのため、変更の内容だけでなく、どの指標やレポートが影響を受けるか、過去のデータを再計算するか、誰が確認するかを記録します。必要に応じて、旧定義と新定義の差、変更日、復旧手順を残します。
データ全体の管理体制やツールの役割分担はCRM・MAのデータ連携と安全な運用設計、更新時の欠損・重複・削除についてはBtoB顧客データの鮮度管理で別の観点から解説しています。
AIに顧客データを渡すときも「データ契約」だけでは足りない
生成AIを使えば、データの意味が自動で正しく解釈されるわけではありません。個人を識別できる情報、機密の商談記録、契約条件などは、利用目的・外部提供・保存・アクセス権を確認したうえで扱う必要があります。
データ契約で品質や意味を定義することは有用ですが、AIへの入力を許可するセキュリティ審査や個人情報保護上の確認を置き換えるものではありません。まず架空データで分析方法を試し、実データが必要なら組織の承認された環境で扱います。
まとめ――データを増やすより、安心して解釈できる状態をつくる
CRMとMAの連携が動いていても、データの意味や更新条件が揃っていなければ、数字は組織の意思決定を助けません。
データ契約は、作る人と使う人が、意味・品質・変更について共通の期待を持つための道具です。最初からすべてを自動化しなくても、重要な指標や連携から定義を揃えられます。
何を数え、誰が直し、いつ変わり、どの判断に使うのか。その問いを共有することが、BtoBのデータ活用を堅実にする第一歩です。
参考資料・出典
- Data Contract CLI「Open Data Contract Standard」：構造・意味・品質・提供者・サービス水準などのフィールドを説明。
- dbt Developer Hub「About model governance」：モデル契約の構造的な保証とバージョン管理について。
- dbt Developer Hub「Model versions」：破壊的変更、移行期間、旧モデルの廃止条件について。
- Google Cloud「自動データ品質を使用する」：欠損、値の妥当性、一意性などの品質ルール。
- OpenMetadata Standards「Data Contract」：データ資産の構造、意味、品質、SLA、オーナーシップ等の定義。
本記事のCRM・MA事例と8項目、2週間の導入手順は公式仕様を参考にした編集上の提案です。例示した指標の定義は架空のもので、読者の組織にそのまま適用すべき正式基準ではありません。各製品の仕様・名称は将来変更される場合があります。