フレームワーク活用ガイドひとことで言うと#
データがどこで生まれ、どう変換され、どこで使われているかを端から端まで追跡・可視化する手法。データの「家系図」を作ることで、品質問題の原因特定や変更の影響分析ができるようになる。
押さえておきたい用語#
- リネージ（Lineage）
- データの出自・系譜を意味する。あるデータがどのソースから生まれ、どんな処理を経て現在の形になったかの履歴を指す。
- 上流（Upstream）
- データの流れにおいて発生源に近い側のこと。ソースシステムやETL処理の入力側がこれにあたる。
- 下流（Downstream）
- データの流れにおいて最終利用に近い側である。BIダッシュボードやレポート、機械学習モデルなどが該当する。
- 影響分析（Impact Analysis）
- あるデータやテーブルを変更したとき、下流のどのレポート・システムに影響が及ぶかを特定する分析手法。
データリネージの全体像#
こんな悩みに効く#
- ダッシュボードの数値がおかしいとき、原因がどの処理にあるかわからない
- テーブルのカラムを変更したいが、どのレポートに影響するか把握できない
- 規制当局から「この数値の算出根拠を示せ」と求められたときに答えられない
基本の使い方#
すべてのデータを一度に追跡しようとすると膨大な作業になる。まずビジネスインパクトの大きいデータから着手する。
優先度の高いデータの例:
- 経営ダッシュボードに表示される売上・利益・KPI
- 規制レポートに使われるデータ（金融機関の自己資本比率など）
- 機械学習モデルの入力データ（予測精度に直結）
最終的な出力（レポートやダッシュボード）から逆引きで辿るのがポイント。
特定したデータについて、以下の情報を記録する。
| 項目 | 内容 |
|---|---|
| ソース | どのシステムのどのテーブル・APIから取得しているか |
| 変換処理 | どんなETL/ELTジョブが加工しているか |
| 格納先 | DWH・データレイクのどのテーブルに入るか |
| 利用先 | どのダッシュボード・レポート・モデルが参照しているか |
手作業で始めてもよいが、SQLのCREATE文やdbtのYAMLから自動抽出できると効率的。
手作業のマッピングは更新が止まりやすい。パイプラインの変更に追従するため、自動でリネージを収集する仕組みを導入する。
代表的なツール:
- OpenLineage: オープンソースのリネージ標準仕様
- DataHub / Amundsen: メタデータプラットフォームのリネージ機能
- dbt: SQLモデル間の依存関係を自動でグラフ化
- クラウドネイティブ: BigQuery INFORMATION_SCHEMA、AWS Glue Data Catalogなど
最初はdbtのリネージグラフから始めるのが最も手軽。
構築したリネージを3つの場面で活用する。
- 障害対応: ダッシュボードの数値異常 → リネージを辿って原因のETLジョブを特定
- 変更管理: テーブル定義の変更前に → 下流の影響範囲を確認してから実施
- コンプライアンス: 監査対応 → データの算出根拠と処理履歴を提示
リネージは作って終わりではなく、使い続けることで価値が出る。
具体例#
月商2.4億円のEC企業。ある月曜の朝、経営ダッシュボードの週次売上が前週比40%減と表示された。実際の受注件数は変わっていないのに、数字だけが急落している。
リネージ導入前はエンジニア3名が丸1日かけてETLジョブを手動で追跡し、12時間後にようやく原因を特定していた。
リネージ導入後は、ダッシュボードの「週次売上」フィールドから逆引きし、mart_weekly_sales → transform_orders → raw_orders の流れを5分で可視化。transform_orders のログを確認すると、金曜夜のデプロイで通貨換算ロジックが変更されていたことが判明した。修正パッチを当てて再実行し、30分で正常な数値に復旧。経営判断の遅延も防げた。
従業員1,200名の地方銀行。金融庁の検査で「自己資本比率の算出に使用したデータの出所と処理過程を示してください」と求められた。
以前は担当者が3週間かけてExcelとメールを辿り、処理過程を手動でまとめていた。データリネージを導入した後は、検査官の前でリネージグラフを表示し、以下を即座に提示した。
- 自己資本比率の構成要素（Tier1資本、リスクアセット等）のソースシステム
- 各データの変換ルールと集計ロジック
- 最終レポートまでの全処理ステップと実行日時
検査対応にかかる時間が3週間から2日に短縮。検査官からも「データ管理体制が明確で信頼できる」と評価を受けた。
従業員800名の食品メーカー。基幹システムのリプレースに伴い、受注テーブルのカラム名47個を変更する必要があった。
リネージグラフで下流の影響範囲を確認した結果:
- 影響を受けるETLジョブ: 23本
- 影響を受けるダッシュボード: 8枚
- 影響を受けるバッチレポート: 5本
これを元に、変更対象を一覧化し、修正 → テスト → リリースの計画を2週間で策定。移行当日のトラブルはゼロだった。リネージなしで同じ移行を行った前回のシステム更新では、想定外の障害が14件発生し、復旧に3日を要していた。
やりがちな失敗パターン#
- 全データを一度にマッピングしようとする — 組織のデータ資産は膨大で、すべてを網羅しようとすると完成しない。ビジネスクリティカルなレポート上位10本から逆引きで始める
- 手動のドキュメントだけで管理する — Excelやコンフルエンスに書いたリネージは更新が止まる。自動収集の仕組みを早期に導入し、パイプラインの変更に追従させる
- リネージを作って満足し活用しない — 可視化しただけでは価値がない。障害対応・変更管理・監査対応の実務プロセスに組み込むことで初めてROIが出る
まとめ#
データリネージは、データの発生源から最終利用までの流れを追跡・可視化する手法。使い始めると「このカラム変更、どこに影響するんだっけ」を30分かけて調べていた作業が5分で終わるようになる。まずはdbtのリネージグラフから触ってみると、自分のパイプラインの全体像が初めて見えてくる。