データリネージ

英語名 Data Lineage
読み方 データ リネージ
難易度
所要時間 数週間〜数ヶ月(段階的に構築)
提唱者 データウェアハウスの運用管理から発展し、規制対応やデータメッシュの普及で重要性が拡大
目次

ひとことで言うと
#

データがどこで生まれ、どう変換され、どこで使われているかを端から端まで追跡・可視化する手法。データの「家系図」を作ることで、品質問題の原因特定や変更の影響分析ができるようになる。

押さえておきたい用語
#

押さえておきたい用語
リネージ(Lineage)
データの出自・系譜を意味する。あるデータがどのソースから生まれ、どんな処理を経て現在の形になったかの履歴を指す。
上流(Upstream)
データの流れにおいて発生源に近い側のこと。ソースシステムやETL処理の入力側がこれにあたる。
下流(Downstream)
データの流れにおいて最終利用に近い側である。BIダッシュボードやレポート、機械学習モデルなどが該当する。
影響分析(Impact Analysis)
あるデータやテーブルを変更したとき、下流のどのレポート・システムに影響が及ぶかを特定する分析手法。

データリネージの全体像
#

データリネージ:発生源から最終利用までの追跡フロー
ソースシステムCRM基幹システムログ・APIETL / 変換抽出・加工・結合フィルタリング集計・変換ルールDWH / レイク統合・蓄積マート作成履歴管理データリネージ最終利用BIダッシュボード経営レポートMLモデル規制レポートデータ連携先影響分析上流の変更が下流のどこに影響するかデータの流れを端から端まで追跡し、品質と信頼性を担保する
データリネージ構築の進め方フロー
1
対象データの特定
重要なレポート・KPIから逆引き
2
流れのマッピング
ソース→変換→格納→利用を記録
3
自動収集の仕組み化
ツールでリネージを自動取得
運用と活用
影響分析・品質追跡に日常活用

こんな悩みに効く
#

  • ダッシュボードの数値がおかしいとき、原因がどの処理にあるかわからない
  • テーブルのカラムを変更したいが、どのレポートに影響するか把握できない
  • 規制当局から「この数値の算出根拠を示せ」と求められたときに答えられない

基本の使い方
#

ステップ1: 追跡対象のデータを特定する

すべてのデータを一度に追跡しようとすると膨大な作業になる。まずビジネスインパクトの大きいデータから着手する。

優先度の高いデータの例:

  • 経営ダッシュボードに表示される売上・利益・KPI
  • 規制レポートに使われるデータ(金融機関の自己資本比率など)
  • 機械学習モデルの入力データ(予測精度に直結)

最終的な出力(レポートやダッシュボード)から逆引きで辿るのがポイント。

ステップ2: データの流れをマッピングする

特定したデータについて、以下の情報を記録する。

項目内容
ソースどのシステムのどのテーブル・APIから取得しているか
変換処理どんなETL/ELTジョブが加工しているか
格納先DWH・データレイクのどのテーブルに入るか
利用先どのダッシュボード・レポート・モデルが参照しているか

手作業で始めてもよいが、SQLのCREATE文やdbtのYAMLから自動抽出できると効率的。

ステップ3: 自動収集の仕組みを導入する

手作業のマッピングは更新が止まりやすい。パイプラインの変更に追従するため、自動でリネージを収集する仕組みを導入する。

代表的なツール:

  • OpenLineage: オープンソースのリネージ標準仕様
  • DataHub / Amundsen: メタデータプラットフォームのリネージ機能
  • dbt: SQLモデル間の依存関係を自動でグラフ化
  • クラウドネイティブ: BigQuery INFORMATION_SCHEMA、AWS Glue Data Catalogなど

最初はdbtのリネージグラフから始めるのが最も手軽。

ステップ4: 日常業務でリネージを活用する

構築したリネージを3つの場面で活用する。

  1. 障害対応: ダッシュボードの数値異常 → リネージを辿って原因のETLジョブを特定
  2. 変更管理: テーブル定義の変更前に → 下流の影響範囲を確認してから実施
  3. コンプライアンス: 監査対応 → データの算出根拠と処理履歴を提示

リネージは作って終わりではなく、使い続けることで価値が出る

具体例
#

例1:EC企業がダッシュボードの売上不一致を30分で特定する

状況: 月商2.4億円のEC企業。ある月曜の朝、経営ダッシュボードの週次売上が前週比40%減と表示された。実際の受注件数は変わっていないのに、数字だけが急落している。

リネージ導入前: エンジニア3名が丸1日かけてETLジョブを手動で追跡。12時間後にようやく原因を特定。

リネージ導入後の対応:

  1. ダッシュボードの「週次売上」フィールドからリネージを逆引き
  2. 参照先のDWHテーブル mart_weekly_sales → ETLジョブ transform_orders → ソーステーブル raw_orders の流れを5分で可視化
  3. transform_orders ジョブのログを確認 → 金曜夜のデプロイで通貨換算ロジックが変更されていたことを発見
  4. 修正パッチを当てて再実行 → 30分で正常な数値に復旧

原因特定が12時間から30分に短縮された。経営判断の遅延も防げた。

例2:金融機関が規制レポートの算出根拠を即座に提示する

状況: 従業員1,200名の地方銀行。金融庁の検査で「自己資本比率の算出に使用したデータの出所と処理過程を示してください」と求められた。

以前は担当者が3週間かけてExcelとメールを辿り、処理過程を手動でまとめていた。データリネージを導入した後は、検査官の前でリネージグラフを表示し、以下を即座に提示した。

  • 自己資本比率の構成要素(Tier1資本、リスクアセット等)のソースシステム
  • 各データの変換ルール集計ロジック
  • 最終レポートまでの全処理ステップと実行日時

検査対応にかかる時間が3週間から2日に短縮。検査官からも「データ管理体制が明確で信頼できる」と評価を受けた。

例3:食品メーカーがテーブル変更の影響を事前に把握してトラブルゼロで移行する

状況: 従業員800名の食品メーカー。基幹システムのリプレースに伴い、受注テーブルのカラム名47個を変更する必要があった。

リネージグラフで下流の影響範囲を確認した結果:

  • 影響を受けるETLジョブ: 23本
  • 影響を受けるダッシュボード: 8枚
  • 影響を受けるバッチレポート: 5本

これを元に、変更対象を一覧化し、修正 → テスト → リリースの計画を2週間で策定。移行当日のトラブルはゼロだった。リネージなしで同じ移行を行った前回のシステム更新では、想定外の障害が14件発生し、復旧に3日を要していた。

やりがちな失敗パターン
#

  1. 全データを一度にマッピングしようとする — 組織のデータ資産は膨大で、すべてを網羅しようとすると完成しない。ビジネスクリティカルなレポート上位10本から逆引きで始める
  2. 手動のドキュメントだけで管理する — Excelやコンフルエンスに書いたリネージは更新が止まる。自動収集の仕組みを早期に導入し、パイプラインの変更に追従させる
  3. リネージを作って満足し活用しない — 可視化しただけでは価値がない。障害対応・変更管理・監査対応の実務プロセスに組み込むことで初めてROIが出る

まとめ
#

データリネージは、データの発生源から最終利用までの流れを追跡・可視化する手法。障害時の原因特定、変更時の影響分析、規制対応の根拠提示という3つの実務場面で即効性がある。まずはビジネスインパクトの大きいレポートから逆引きでリネージを構築し、自動収集の仕組みへと段階的に発展させるのが現実的な進め方になる。