売上列の計算方法を変えたいのに、どのダッシュボードやAIがその列を使っているか分からない。担当者へ聞き回り、SQLを検索し、最後は変更して問題が出ないことを祈る。この違和感は、データの一覧がないことだけでなく、データ同士のつながりが記録されていないことから生まれます。
結論から言えば、データリネージ（データリネージュとも呼ばれます）とは、データがどこで生まれ、どの処理で変換され、どこへ渡り、何に使われるかを追跡できる記録です。データの家系図という訳もありますが、実務では路線図に近いものです。障害時には原因と影響先をたどり、変更前には巻き込む利用者を確認します。
最初に結論
データリネージは、データソース、テーブルや列、変換Job、ダッシュボードなどの依存関係と実行履歴を記録する仕組みです。上流をたどれば値の由来と障害原因を、下流をたどれば変更の影響先を確認できます。完全な図を手作業で描くのではなく、SQL解析や実行イベントから自動収集し、重要な空白だけを補います。
この記事のポイント
- ・上流探索は由来と原因調査、下流探索は変更の影響分析に使う
- ・テーブル単位から始め、重要指標だけカラム単位へ細かくする
- ・設計上の依存関係と、実際に動いたRunの履歴は別物として扱う
- ・リネージ単体で終わらせず、Owner、契約、品質、利用状況と結び付ける
対象：データがどこから来てどこで使われるか分からず、変更や障害の影響調査に時間がかかるデータ担当者と管理者
データの路線図として考える
注文APIからRawテーブルへ入り、変換Jobで通貨と税を整え、売上マートを経由して経営ダッシュボードへ届くとします。リネージは、それぞれを点、依存関係を線として記録します。ダッシュボードの数字が怪しければ上流へ戻り、売上マートを変更したければ下流へ進みます。
データカタログが駅名、説明、Ownerを載せた案内帳だとすれば、リネージは駅同士を結ぶ路線です。実際の製品では両者が統合されることが多く、品質結果やアクセス権も同じ画面で確認できます。ただし、きれいな図を作ること自体が目的ではありません。調査や変更の判断時間を短くするためのメタデータです。
テーブル単位とカラム単位を使い分ける
粒度を細かくするほど便利ですが、取得と維持の難しさも増えます。まずテーブルやDataset単位で主要経路を把握し、売上、顧客ID、同意状態など、意味とリスクが大きい列をカラム単位で追うのが現実的です。
| 粒度 | 分かること | 向いている用途 | 注意点 |
|---|---|---|---|
| データセット単位 | システム間の大きな流れ | 全体構成と責任境界 | 具体的な変換は見えにくい |
| テーブル単位 | 入出力テーブルの依存 | 障害・変更の影響分析 | 列ごとの由来は分からない |
| カラム単位 | 列の変換元と利用先 | 指標、PII、規制対応 | SQL解析と保守の難度が上がる |
| Job・Run単位 | いつ何が実行されたか | 失敗原因と再実行判断 | 設計図だけでは得られない |
設計時リネージと実行時リネージの違い
SQLやパイプライン定義を解析すると、どの入力からどの出力を作る予定かが分かります。これは設計時または静的リネージです。実行前の変更影響を調べやすい一方、条件分岐、動的SQL、手作業、実行されなかった処理までは正確に表せない場合があります。
実行時リネージは、JobのRunごとに実際の入出力、時刻、状態をイベントとして記録します。OpenLineageはJob、Run、Datasetを中心としたオープンな標準を提供しています。実障害の調査に強い反面、連携していないツールや失われたイベントは見えません。設計時と実行時を照合することで、予定された経路と実際の経路の差も発見できます。
| 種類 | 主な取得元 | 強み | 弱み |
|---|---|---|---|
| 設計時・静的 | SQL、dbt、DAG、定義ファイル | 実行前の影響分析ができる | 動的処理や手作業を見落とす |
| 実行時・動的 | Query Log、Job Event、OpenLineage | 実際のRunと失敗を追える | 未連携処理と将来の経路は見えない |
リネージが役立つ4つの場面
一つ目は障害の原因調査です。異常なレポートから上流へたどり、失敗したJobや変更されたSourceを絞ります。二つ目は変更の影響分析です。列の削除や型変更の前に、下流テーブルと利用者を確認して通知できます。
三つ目は監査と説明責任です。経営指標やAI回答に使われたデータの由来と変換を説明しやすくなります。四つ目は機密データの管理です。個人情報がどこへ複製・加工されたかを追い、保護や削除の漏れを探せます。ただし、図に線があるだけで変換ロジックの妥当性やアクセス権が保証されるわけではありません。
- 上流へたどるRoot Cause Analysis
- 下流へたどるChange Impact Analysis
- 指標やAI回答のProvenance確認
- PII・機密情報の伝播と利用範囲の確認
リネージを集める4つの方法
単一の方法ですべてを捉えるのは難しいため、基盤に合わせて組み合わせます。クラウドDWHやCatalogの標準機能が既にQuery Logを解析しているなら、まずその範囲を確認します。別製品を入れる前に、何が自動取得され、保持期間と権限がどうなっているかを把握してください。
- 1. 定義ファイルを解析する：dbt model、DAG、ETL設定から予定された入出力を抽出します。Version管理と相性が良い方法です。
- 2. SQLとQuery Logを解析する：CREATE、INSERT、SELECTなどからテーブル・列の依存を推定します。動的SQLの扱いを確認します。
- 3. 実行イベントを送る：Jobの開始・完了・失敗と入出力DatasetをOpenLineageなどの形式で収集します。
- 4. 見えない経路を補う：表計算へのExportや外部SaaS連携など、重要なのに自動取得できない接続だけを手動登録します。
小規模チームの導入は重要経路一本から
全社のデータ地図を完成させてから使い始めようとすると、完成前に現実が変わります。まず重要なダッシュボードかAI機能を一つ選び、出力から主要Sourceまでをたどります。その経路のテーブル、Job、Owner、更新頻度、品質結果を登録し、実際の障害または変更レビューで使ってみます。
役立たなかった理由が粒度不足なら、該当する重要列だけカラムリネージを足します。経路が欠けていたなら収集連携を追加します。利用者が見つからないなら、アクセスログやBIの参照情報と結び付けます。ユースケースに沿って不足を埋める方が、線の本数をKPIにするより価値を生みます。
- 1. 判断したい問いを決める：『売上列を変えたら誰に影響するか』のように、具体的な利用場面を一つ選びます。
- 2. 対象経路を限定する：重要な出力からSourceまで、関係するテーブルとJobだけを集めます。
- 3. 自動取得率と空白を確認する：標準連携で見える範囲と、手作業・外部SaaSなど見えない範囲を明示します。
- 4. 実務で検証する：変更レビューや障害訓練で使い、必要な粒度、Owner、保持期間を調整します。
完全なリネージという前提を置かない
リネージは収集できたメタデータの範囲を表します。線がないから依存がないとは限りません。CSV Download後の加工、コピーされた表計算、外部へのAPI送信は見えないことがあります。重要な判断では、カバー範囲と最終更新時刻を確認し、人への確認も残します。
また、依存関係だけでは意味を説明できません。売上列がどこから来たか分かっても、税込みか、取消を含むか、誰が承認したかはデータコントラクトやセマンティック定義が必要です。リネージをデータカタログ、品質結果、Owner、権限と結び付けて初めて、安心して変更できる地図になります。
次に読む記事
参考文献
本記事は以下の公式文書、標準、論文、公開記事・投稿を確認し、初心者向けに論点を再構成しています。 仕様や制度は更新されるため、導入時はリンク先の最新版も確認してください。
- What is data lineage? — Google Cloud（最終確認：2026-08-07）：データリネージの定義、可視化、影響分析と規制対応の用途を参照。
- OpenLineage Documentation — OpenLineage（最終確認：2026-08-07）：Job、Run、Datasetを核にしたオープンな実行時リネージ標準を参照。
- Capture and view data lineage using Unity Catalog — Databricks（最終確認：2026-08-07）：Table・Column Lineageの自動取得、保持、権限に関する実装例を参照。
- Data lineage in Amazon DataZone — Amazon Web Services（最終確認：2026-08-07）：OpenLineage互換イベントとRun単位の上流・下流追跡を参照。
よくある質問
データリネージとデータカタログの違いは何ですか？
データカタログはデータの名前、説明、Owner、分類などを検索できる台帳です。リネージはSource、変換、出力の依存関係と履歴です。実務ではカタログ上でリネージを表示し、意味と経路を一緒に確認します。
カラム単位のリネージは必須ですか？
必須ではありません。全体の障害・変更影響はテーブル単位でも把握できます。経営指標、個人情報、規制対象など、列ごとの由来と伝播を確認する価値が高い部分からカラム単位にします。
リネージは自動で100%取得できますか？
通常はできません。対応するQuery Log、SQL、Job Eventは自動化できますが、動的SQL、手作業、Export後の表計算、未連携SaaSには空白が残ります。対応範囲を明示し、重要な経路のみ補完します。
まとめと次の一歩
データリネージは完成した地図ではなく、取得できたメタデータの範囲で由来と影響を判断する道具です。重要経路から始め、カタログ・品質・責任者・権限と結び付けて初めて変更判断に使えます。