都会の喧騒から

考えるための言葉と、働くための知恵を。

データリネージとは？CRM・MA・BIの数字の出所と変更影響を追跡する方法

BtoBマーケティングのダッシュボードに「商談化率15％」と表示されている。経営会議でその数字を説明するとき、どの顧客情報から計算され、どの段階で重複を除き、どの部門が定義を変えたのか分かるでしょうか。

このような「数字がどこから来て、どのように加工され、どこで使われたか」を確認するための考え方がデータリネージ（Data Lineage）です。CRM、MA、データウェアハウス、BIを横断するBtoB業務で、数字の意味と変更の影響を追うための基礎を整理します。

データリネージとは――データの出所、加工、利用先をつなぐ関係図

Google CloudのKnowledge Catalog公式資料は、データリネージを、データがどこから来て、どこへ移動し、途中でどのような変更・変換を受けるかを追跡する仕組みとして説明しています。

例えばフォームで取得した企業情報がMAへ登録され、CRMの商談記録と結合され、BIで「受注率」として表示されるなら、その経路を明示します。単にツール名を並べるのでなく、テーブル・項目・処理・レポートの関係を追います。

データリネージは、データを全部一つのデータベースへ集約することとは異なります。また、正しいデータが必ず入っていると証明する仕組みそのものでもありません。追跡できることと、入力の正確性、利用目的の妥当性は別に確認します。

最初に分けたい三つのレベル

  • システム間の流れ：フォーム→MA→CRM→分析基盤→ダッシュボードという、全体のデータ経路を確認する。
  • テーブル・データセット単位：どのテーブルを入力し、どの集計テーブルやビューが出力されたかを追う。
  • 列・フィールド単位：商談日、受注金額、企業IDなどの項目が、元のどの列からどう計算されたかを追う。

Google Cloudの公式「About data lineage visualization in Knowledge Catalog」は、テーブル単位と列単位の追跡の違い、上流（upstream）と下流（downstream）の関係を説明しています。

ただし、使うサービスや設定、権限によって自動的に取得できる範囲は変わります。列ごとの計算が何でも追える、どの外部SaaSも自動連携できる、という意味ではありません。

BtoBの商談化率を例に、どこで意味が変わるか

以下は説明用の架空例です。ウェビナー登録者をMAで管理し、商談になった場合にはCRMへ登録します。BI上では「商談化率」と表示されています。

しかし、分母はウェビナーに登録した人数でしょうか、実際に参加した人数でしょうか。同じ企業から5人参加した場合は5件でしょうか、それとも1社でしょうか。分子には営業が受け入れたリードを使うのでしょうか、正式な商談レコードを使うのでしょうか。

これらの定義が曖昧なままだと、計算結果が整合しているように見えても、会議で違う数字を話している可能性があります。

例えば追跡対象を次のように置きます。

  • 取得：イベント登録フォームの登録日時、企業情報、同意・連絡条件。
  • MA：重複の判定、対象者の分類、参加・不参加の記録。
  • CRM：企業IDとのひも付け、営業受入の条件、商談レコードの発生。
  • 加工：企業単位へ集約するか、人物単位を維持するか、期間をどうそろえるか。
  • BI：レポート名、計算式、元データの更新時刻、指標の責任者。

この一覧は当サイトの実務整理であり、OpenLineage等が定めた正式なBtoB指標定義ではありません。実際には企業ごとに異なるデータモデルを使います。

上流（upstream）と下流（downstream）を使い分ける

ダッシュボードに不自然な数字が現れたら、結果から元のデータへ戻る方向が「上流」の確認です。どのテーブルと処理がこの指標を作ったのかを調べます。

一方、CRMで企業IDの形式を変更するとしたら、その変更を受けるMA、ETL、BI、営業レポートを調べる必要があります。これは「下流」の影響確認です。

Google CloudのKnowledge Catalogでは、対象とするデータ資産に応じて、リネージをグラフ・一覧などで閲覧する仕組みがあります。上流と下流の表示、テーブルや列単位での確認が可能な対象もあります。ただし機能の対象となる資産、権限、データの記録有無を事前に確認する必要があります。

参考：Google Cloud「About data lineage」、「About data lineage visualization」。

OpenLineageのRun・Job・Datasetは何を表すか

OpenLineageは、ジョブの実行とデータセット間の関係を記録・交換するためのオープンな仕様です。仕様には、主にJob（処理の定義）、Run（その実行）、Dataset（入力や出力になるデータの集合）という概念があります。

たとえば毎晩CRMデータを取り込む処理を一つのJobとし、10月15日夜の実行をそのRunとして記録します。入力としてCRM由来のデータセット、出力として集計テーブルを扱います。

付加的な情報はFacetとして記録できます。Facetには処理の情報、データセットのスキーマ、品質や実行結果などに関係するものがあります。

重要なのは、「あるデータが別のデータへ流れた」という構造的な依存関係と、「その日何が実際に実行されたか」の記録が異なることです。ジョブが定義されていても、昨日の処理が失敗していたなら、新しい数値は届いていないかもしれません。

出典：OpenLineage公式「Facets & Extensibility」、OpenLineage仕様本文。仕様の実装方法は使用製品やバージョンによって変わります。

dbtのexposures――ダッシュボードも利用先として管理する

dbtの公式「Add Exposures to your DAG」は、ダッシュボード、アプリケーション、データサイエンスの処理など、dbtプロジェクトの下流でデータを利用するものをexposureとして定義する方法を説明しています。

これは「集計テーブルが正しく生成できる」だけでなく「誰がそのテーブルを何のレポートに使っているか」を把握するための発想です。依存関係が分かれば、あるモデルの変更時に、利用しているレポートを確認する手掛かりになります。

ただし、すべてのBI製品への接続やCRM内の計算ロジックがdbtから自動で見えるわけではありません。対象外の経路は、別の記録や手動の管理が必要になる場合があります。

公式資料：dbt Developer Hub「Add Exposures to your DAG」。

リネージが追えない「空白」をどう扱うか

MAの管理画面からCSVを手動で出し、営業担当者がExcelで加工して、会議用スライドに数値を貼る。こうした作業は実際にあり得ますが、自動化されたリネージには残らない場合があります。

「図に線がない」ことは、必ずしもデータのつながりが存在しないことを意味しません。手作業、非対応の接続、権限不足、実行ログの欠落、過去の変更などによって追跡できないことがあります。

不明な経路は推測の矢印で埋めず、「確認済み」「関係者に要確認」「現在は追跡不可」と状態を分けます。技術的な可視化の範囲と、実際の業務の全体像を区別することが大切です。

データリネージとデータ契約・品質検査はどう違う？

似たテーマに見える三つですが、答える問いが異なります。

  • データリネージ：この指標・項目はどこから来て、どの処理を経て、どこで使われているか。
  • データ契約（Data Contract）：提供者と利用者が、項目の意味・形式・品質・変更時の連絡について何を約束しているか。
  • データ品質検査：実際のデータが、欠損や重複、許容範囲などのルールを満たしているか。

リネージの図が正しくても、元のデータに誤登録があれば正しい数値にはなりません。データ契約の仕様があっても、転送先で違う集計ロジックを使えば、指標の意味がずれるかもしれません。

それぞれを組み合わせて使う考え方はデータ契約の実務、全体の運用体制はCRM・MAのデータ運用設計で補足しています。

顧客情報の流れを追跡するときのプライバシー

データの出所を理解することは、個人情報や機密データを社内の誰もが自由に見られることとは異なります。ログやリネージのメタデータであっても、データセット名、処理のSQL、項目名などから機密の処理や取引関係が推測できる場合があります。

利用者が何を知る必要があるかに合わせて、メタデータの閲覧権限、ログの保管・削除、アクセスの監査を設計します。顧客の許可なく個人情報を別用途へ流すことを、リネージで追跡できるからという理由で正当化できません。

Google Cloudの公式利用ガイドでは、リネージ情報を閲覧するためのIAM権限が必要とされています。収集できる情報と見える情報を分けて設計します。参考：Google Cloud「View data lineage」。

2週間で試す：ひとつのKPIから上流をたどる

大量のシステム構成を全て図にしようとすると、作業が止まってしまうかもしれません。まず経営や営業で実際に使っている指標を一つ選び、現在の範囲で追跡する方法を試します。

  • 1〜3日目：「商談数」などのKPIを一つ選び、利用者・分母・分子・期間・更新責任者を確認する。
  • 4〜6日目：レポートから元のテーブル・CRM/MAの項目へたどる。確認できた接続と未確認の経路を分ける。
  • 7〜10日目：重複排除や企業IDの結合、期間集計、手作業の変更がどこにあるか調べる。
  • 11〜14日目：小さな項目変更を想定し、どのレポートへ影響するか確認し、責任者と連絡先を記録する。

これは本サイトの実務提案であり、二週間ですべてのデータリネージを完成できるという保証ではありません。重要な接点が外部委託先や権限のない環境にある場合は、確認可能な範囲を限定します。

架空例：リード件数が突然増えた本当の理由を探す

ある会社のダッシュボードで、リード件数が突然増えたとします。マーケティングチームは新しい広告が成功したと考えました。しかし上流をたどると、フォーム登録の重複を除いていた処理が一時的に実行されていなかった可能性が見つかりました。

この場合、広告からの流入が増えたという結論はまだ出せません。処理の実行記録、重複数、元の問い合わせ件数、対象期間を確認し、修正前後のレポートを区別します。

これは実際の障害報告ではなく説明用の架空例です。リネージの有無が特定の広告成果を自動的に示すという意味でもありません。

リネージを整える目的は「図を美しくすること」ではない

大切なのは、数字に疑問が生じたときに誰が調べられるか、項目を変更するときに誰へ知らせればよいか、利用者へどのような制約を伝えるかです。

全てのデータを一度に追跡できなくても、重要なKPIの上流・下流を少しずつ明らかにすれば、誤った判断を減らす手掛かりになります。逆に、高度な可視化ツールを導入しても業務上の定義が曖昧なら、数値の信頼性は高まりません。

BIの数字を読む際の限界についてはマーケティング・ダッシュボードの限界も参照できます。

参考資料と確認範囲

「商談化率」の架空例、三つのレベルの分け方、2週間の実務手順は編集上の提案です。参考資料がこれらの施策による売上改善を直接実証したわけではありません。仕様や対応範囲は使用製品・契約・時点によって異なります。

次の問いを探す

言葉・人物・作品・仕事など、気になるキーワードからほかの記事へ。

編集方針と運営者について →