データガバナンス・Lineage・PII 完全ガイド: OpenLineage、Collibra・Atlan・DataHub、Unity・Polaris、GDPR・韓国個人情報保護法 (2025)

Season 5 Ep 7 — Ep 1–6 でデータはますます増え、複雑になった。Ep 7 はその反対の軸 —「どう統治するか」。データを管理しなければ、データが会社を支配する。

• Prologue — 「わが社の顧客メールアドレスは何か所にあるのか」
• 第1章 · データガバナンスの定義
  • 1.1 ガバナンスの4軸
  • 1.2 なぜ今重要なのか
  • 1.3 ガバナンスのスペクトラム
• 第2章 · OpenLineage — 系譜の標準
  • 2.1 アイデンティティ
  • 2.2 構造
  • 2.3 統合
  • 2.4 サンプルイベント
  • 2.5 価値
• 第3章 · データカタログ4大
  • 3.1 Collibra
  • 3.2 Atlan
  • 3.3 DataHub
  • 3.4 Alation
  • 3.5 その他
  • 3.6 比較
• 第4章 · 技術カタログ — Unity/Polaris/Glue
  • 4.1 Unity Catalog
  • 4.2 Polaris
  • 4.3 AWS Glue Data Catalog
  • 4.4 Nessie / Gravitino
  • 4.5 ビジネス vs 技術カタログ
• 第5章 · PII — 定義と検出
  • 5.1 PII の定義
  • 5.2 自動検出ツール
  • 5.3 検出方式
  • 5.4 分類等級
• 第6章 · PII の保護 — マスキング・トークン化・暗号化
  • 6.1 マスキング
  • 6.2 トークン化（Tokenization）
  • 6.3 ハッシュ化・匿名化
  • 6.4 暗号化
  • 6.5 Dynamic Masking の例（Snowflake）
• 第7章 · 規制 — GDPR、韓国 PIPA、AI Act
  • 7.1 GDPR（EU、2018–）
  • 7.2 韓国個人情報保護法（PIPA）
  • 7.3 韓国 AI 基本法（2024–）
  • 7.4 その他の規制
  • 7.5 共通原則
• 第8章 · Data Subject Request (DSR)
  • 8.1 リクエストの種類
  • 8.2 実装の難易度
  • 8.3 実務パターン
  • 8.4 AI・学習データ
• 第9章 · AI 時代のガバナンス拡張
  • 9.1 モデルカタログ
  • 9.2 プロンプト・エージェントカタログ
  • 9.3 学習データの出所追跡
  • 9.4 AI 出力の監査
  • 9.5 規制との接続
• 第10章 · 実践アーキテクチャ — ガバナンス統合
  • 10.1 レイヤー
  • 10.2 ポリシー例
  • 10.3 監査
  • 10.4 自動化
• 第11章 · 韓国企業のガバナンスの現実
  • 11.1 現況
  • 11.2 規制対応
  • 11.3 課題
  • 11.4 参考事例
• 第12章 · 失敗事例8選
  • 12.1 PII が BI ダッシュボードに露出
  • 12.2 系譜のない障害対応
  • 12.3 削除リクエストの処理に1か月
  • 12.4 オーナー不明のテーブルが数千個
  • 12.5 カタログはあるが空っぽ
  • 12.6 アクセス権限の断片化
  • 12.7 外注人材が PII に全面アクセス
  • 12.8 AI 学習データの出所が不明
• 第13章 · アンチパターン10選
  • 13.1 「ガバナンスは後で」
  • 13.2 カタログはあるがオーナーがいない
  • 13.3 PII 検出が正規表現数行
  • 13.4 バックアップの規制に無関心
  • 13.5 Lineage を手作業の文書で
  • 13.6 Data Contract なしに上流を好き勝手に変更
  • 13.7 外部共有の統制がない
  • 13.8 監査ログの保管期間が短い
  • 13.9 カタログツールを複数併用
  • 13.10 AI・ML 領域をガバナンスの外に
• 第14章 · チェックリスト — データガバナンス12項目
• 第15章 · 次回予告 — Season 5 Ep 8:「Observability 2025 (Logs・Metrics・Traces + LLM)」

Prologue — 「わが社の顧客メールアドレスは何か所にあるのか」

2025年、CTO が最も答えにくい質問:

• 顧客のメールアドレスはいくつのテーブル・システムにあるのか
• そのうち PII マスキングされているものはどれくらいか
• ユーザーが「私のデータを消してほしい」と言ったら、どこから消すのか
• このダッシュボードの数字はどの原本データから来たのか

4つの質問すべてに「わかりません」と答えるなら、その会社は規制リスクと製品品質リスクを同時に抱えている。この記事では、その4つの質問に答えられるようにするツールとプロセスを整理する。

第1章 · データガバナンスの定義

1.1 ガバナンスの4軸

• カタログ: 自社にどんなデータがあるのか
• Lineage: どこから来てどこへ行くのか
• 品質（Quality）: 信頼できるデータなのか
• セキュリティ・規制（PII・RBAC）: 誰が見られて、どれだけ保管するのか

1.2 なぜ今重要なのか

• データスタックの分断（Ep 1–6）で管理の複雑さが激増
• EU AI Act、GDPR、韓国個人情報保護法の強化
• AI モデルがデータを学習・推論 → 著作権・PII の問題
• 顧客・従業員によるデータ権利の行使が増加

1.3 ガバナンスのスペクトラム

• カタログ: 読み取り中心、従業員による探索
• Active governance: ポリシーの強制、違反のブロック
• Federation: マルチクラウド・マルチ DB の統合管理

第2章 · OpenLineage — 系譜の標準

2.1 アイデンティティ

• 2020年オープンソース、LF AI & Data 財団
• データ系譜（Lineage）の業界標準スペック
• Python・Java・OpenAPI のリファレンス実装

2.2 構造

• Job: 実行単位（Airflow DAG・dbt run・Flink job）
• Run: Job の実行インスタンス
• Dataset: 入力・出力データセット
• Event: START/COMPLETE/FAIL イベント

2.3 統合

• Airflow、dbt、Spark、Flink、Dagster、Prefect に対応
• Marquez（リファレンスのメタデータストア）
• Datakin → Astronomer が SaaS を提供
• DataHub・Atlan・Collibra が OpenLineage を受信

2.4 サンプルイベント

{
  "eventType": "COMPLETE",
  "job": {"name": "dbt.fact_orders"},
  "run": {"runId": "..."},
  "inputs": [{"name": "raw.orders"}, {"name": "raw.customers"}],
  "outputs": [{"name": "analytics.fact_orders"}]
}

2.5 価値

• 自動の系譜収集 → 人による文書作成の負担が減る
• ツール間で移植可能
• 障害分析・影響度評価

第3章 · データカタログ4大

3.1 Collibra

• 2008年、ベルギー → エンタープライズガバナンスの最強者
• 金融・公共・製薬に特化
• ビジネス用語集（Glossary）・ポリシー管理が強み

3.2 Atlan

• 2018年、インド → モダンデータスタックと親和的
• dbt・Snowflake・Databricks の統合が卓越
• コラボレーション・UX が優秀

3.3 DataHub

• 2020年 LinkedIn → Apache
• オープンソース、セルフホスティング可能
• Acryl Data（商用 SaaS）が支援

3.4 Alation

• 2012年 → エンタープライズのコラボレーションカタログ
• Data Intelligence Platform としてのポジショニング

3.5 その他

• Secoda、Castor（→ CoreView）、OpenMetadata、Amundsen（Lyft）
• Informatica Data Governance、IBM Watson Knowledge Catalog

3.6 比較

第4章 · 技術カタログ — Unity/Polaris/Glue

4.1 Unity Catalog

• Databricks のガバナンスレイヤー
• 2024年にオープンソース化（Unity Catalog OSS）
• Table・Volume・Model・Function を統合
• Delta・Iceberg のどちらにも対応

4.2 Polaris

• Snowflake のオープンな Iceberg REST カタログ
• 2024年オープンソース
• 外部エンジンからアクセス可能
• ガバナンス + カタログの結合

4.3 AWS Glue Data Catalog

• AWS の標準カタログ
• Iceberg・Delta・Hudi に対応
• Lake Formation と組み合わせて権限・監査

4.4 Nessie / Gravitino

• Nessie: Git のようなブランチ・タグ
• Gravitino: メタデータの連合（複数カタログの統合）

4.5 ビジネス vs 技術カタログ

• 技術カタログ: エンジン・クエリが使うメタデータ
• ビジネスカタログ: 人が使う意味・オーナー・SLA
• 2025年は両者の接続（OpenLineage・OpenMetadata）が標準

第5章 · PII — 定義と検出

5.1 PII の定義

• Personally Identifiable Information
• 直接識別（氏名・住民登録番号・カード番号）
• 間接識別（生年月日+地域・IP・クッキー ID）
• センシティブ情報（健康・宗教・志向）

5.2 自動検出ツール

• AWS Macie, Google DLP, Azure Purview: クラウド DLP
• Privacera, BigID, OneTrust: エンタープライズ専門
• Presidio (Microsoft): オープンソース
• Snowflake Data Classification: DW 内蔵

5.3 検出方式

• 正規表現（カード・住民登録番号）
• 辞書ベース（氏名・住所）
• ML 分類器（文脈を含む）
• カラムサンプリング + エントロピー分析

5.4 分類等級

• Public / Internal / Confidential / PII / Sensitive PII / Regulated
• 等級ごとにアクセス・ログ保存・暗号化ポリシーを差別化

第6章 · PII の保護 — マスキング・トークン化・暗号化

6.1 マスキング

• メール: john@***.com
• カード: **** **** **** 1234
• 氏名: 山*太郎 または 山田OO
• Dynamic Data Masking: クエリ時にユーザーごとに違う値を見せる

6.2 トークン化（Tokenization）

• PII を無意味なトークンに置き換え、別の金庫（Vault）にマッピングを保存
• 分析可能性を保ちながら、漏洩時の影響を最小化
• Vault: HashiCorp Vault、AWS KMS + 自前サービス

6.3 ハッシュ化・匿名化

• SHA-256 などの一方向ハッシュ: 分析は可能、原本の復元は不可
• k-anonymity、l-diversity、differential privacy
• 医療・公共データで活用

6.4 暗号化

• At rest: S3 SSE、ディスク暗号化
• In transit: TLS
• Column-level: Parquet Modular Encryption
• Field-level: アプリケーションで暗号化してから保存

6.5 Dynamic Masking の例（Snowflake）

CREATE MASKING POLICY mask_email AS (val STRING)
RETURNS STRING ->
  CASE WHEN CURRENT_ROLE() IN ('ADMIN') THEN val
       ELSE REGEXP_REPLACE(val, '.+@', '***@')
  END;

ALTER TABLE customers MODIFY COLUMN email
  SET MASKING POLICY mask_email;

第7章 · 規制 — GDPR、韓国 PIPA、AI Act

7.1 GDPR（EU、2018–）

• データ主体の権利（アクセス・削除・ポータビリティ・訂正・処理の拒否）
• Legal basis（同意・契約など）の明示が必要
• DPIA（影響評価）、DPO（保護責任者）
• 違反時は全世界売上の 4% または 2,000万ユーロ

7.2 韓国個人情報保護法（PIPA）

• 2011年制定、2020年・2023年改正
• 個人情報の処理に対する同意・目的の明示
• 2023年改正: データ主体の権利を強化（閲覧・削除・移転）
• 課徴金の売上 3% 上限を導入
• 個人情報保護委員会が監督

7.3 韓国 AI 基本法（2024–）

• 高リスク AI の事前影響評価
• 責任ある AI の開発・運用指針
• 事業者の報告義務

7.4 その他の規制

• 米国の HIPAA、GLBA、CPRA（カリフォルニア）
• シンガポール PDPA、日本 APPI
• セクター別: 金融監督院、医療法、電子金融監督規程

7.5 共通原則

• 目的制限: 収集目的以外での利用を禁止
• 最小収集: 必要な分だけ
• 保有期間: 目的達成後に破棄
• 主体の権利: 閲覧・訂正・削除・移転
• 透明性: 処理状況の公開

第8章 · Data Subject Request (DSR)

8.1 リクエストの種類

• Access: 自分のデータの閲覧
• Rectification: 訂正
• Erasure（Right to be forgotten）: 削除
• Portability: 他サービスへの移転
• Object: 処理の拒否

8.2 実装の難易度

• Warehouse の該当ユーザーの行を削除
• Lakehouse Iceberg の row-level delete
• バックアップ・ログの処理
• ML 学習データに含まれている場合（再学習?）
• 第三者に共有されたデータ

8.3 実務パターン

• データマップ（Data Map）: PII が存在するテーブル・場所の一覧
• Unique ID: ユーザーごとの一意 ID で全システムを検索
• DSR ワークフローツール: OneTrust・TrustArc・Osano
• ログ・バックアップポリシー: 法定期間の経過後に自動破棄

8.4 AI・学習データ

• 訓練データからの個人削除は原則として難しい
• 解決策: 仮名化・匿名化・Synthetic data
• Machine unlearning の研究が進行中

第9章 · AI 時代のガバナンス拡張

9.1 モデルカタログ

• 会社が使っているモデルの一覧
• バージョン・データ・性能・ライセンス・監査
• MLflow・Databricks Model Registry・Weights & Biases・HuggingFace Hub

9.2 プロンプト・エージェントカタログ

• システムプロンプトのバージョン
• エージェントのツール・権限
• Ep 11（LLMOps）の延長

9.3 学習データの出所追跡

• 著作権・ライセンスの文書化
• データセットカード（Dataset Card）
• 監査要請時に原本の根拠を提示

9.4 AI 出力の監査

• 応答ログ・引用・意思決定の根拠
• Postmortem のための再現可能性

9.5 規制との接続

• EU AI Act: 高リスクモデルの品質管理・文書化
• 韓国 AI 基本法: 影響評価

第10章 · 実践アーキテクチャ — ガバナンス統合

10.1 レイヤー

• 収集: Kafka・Fivetran・Airbyte → OpenLineage イベント
• 変換: dbt・Spark → OpenLineage を自動送出
• 保存: Iceberg・Delta + カタログ（Unity/Polaris/Glue）
• ガバナンス: DataHub/Atlan/Collibra が受信・統合
• ポリシー: Unity/Lake Formation/Ranger/OPA
• PII: Macie/Privacera/DLP

10.2 ポリシー例

• Raw: 原本、アクセス制限、保管 90日
• Silver: マスキング + トークン化、1年
• Gold: 集計、権限ベースのマスキング、3年以上
• バックアップ: 暗号化、法的期間の経過後に自動破棄

10.3 監査

• すべてのクエリ・DDL のログ
• アクセス異常の検出（異常な時間帯・IP・量）
• 四半期ごとの監査レポート

10.4 自動化

• PR マージ時のガバナンスチェック CI
• 新しいテーブル → 自動分類・オーナー指定
• アクセス申請 → 承認ワークフロー

第11章 · 韓国企業のガバナンスの現実

11.1 現況

• 金融・公共: 自社構築 + Collibra/Informatica の併用
• 大企業: DataHub オープンソース → 社内フォーク
• 中堅・スタートアップ: Atlan・Secoda の導入が増加
• オブザーバビリティ・PII 専用ツールは初期段階

11.2 規制対応

• 個人情報保護委員会の監査・課徴金の事例が増加
• 金融保安院のガイドライン
• 公共データ3法（個人情報・信用情報・情報通信網）

11.3 課題

• 網分離環境でのカタログ構築
• 韓国語メタデータへの対応
• レガシー DW の履歴の自動収集が困難
• 人材不足: ガバナンス専任の人材が希少

11.4 参考事例

• トス: 社内データプラットフォームに DSR・カタログを統合
• カカオ: PII 自動分類パイプライン
• ネイバー: ガバナンス標準チーム + 自前カタログ
• サムスン SDS・LG CNS: 企業顧客向けガバナンス SI パッケージ

第12章 · 失敗事例8選

12.1 PII が BI ダッシュボードに露出

Dynamic masking なしで実名が露出 → 監査で指摘。

12.2 系譜のない障害対応

「この指標が間違っている理由」を探すのに半日かかった。

12.3 削除リクエストの処理に1か月

手作業で、複数システムの同時削除に失敗。

12.4 オーナー不明のテーブルが数千個

誰に聞けばいいのか分からない。

12.5 カタログはあるが空っぽ

初期構築後にメンテナンスされず、現実と乖離。

12.6 アクセス権限の断片化

10個の DB がそれぞれ RBAC、中央管理に失敗。

12.7 外注人材が PII に全面アクセス

監査違反。

12.8 AI 学習データの出所が不明

著作権紛争・規制調査のときに無力。

第13章 · アンチパターン10選

13.1 「ガバナンスは後で」

規模が大きくなるほど作り直しが難しくなる。最初から土台を敷く。

13.2 カタログはあるがオーナーがいない

文書があるだけで、責任がない。

13.3 PII 検出が正規表現数行

ML 分類器・サンプリングの併用が必要。

13.4 バックアップの規制に無関心

「破棄期限は過ぎたのにバックアップに残っている」という事故。

13.5 Lineage を手作業の文書で

自動収集（OpenLineage）を導入する。

13.6 Data Contract なしに上流を好き勝手に変更

コンシューマー全員が壊れる。

13.7 外部共有の統制がない

S3 バケットの公開、メールの添付ファイル。

13.8 監査ログの保管期間が短い

規制要件を満たせない。

13.9 カタログツールを複数併用

統合なしに重複管理。

13.10 AI・ML 領域をガバナンスの外に

2025年ではこれが最大のリスク。

第14章 · チェックリスト — データガバナンス12項目

• データカタログ（ビジネス + 技術）の統合
• OpenLineage ベースの Lineage 自動収集
• テーブル・モデルのオーナー・SLA の明示
• PII の自動検出・分類パイプライン
• マスキング・トークン化・暗号化ポリシー
• DSR ワークフローと処理期限
• 権限・監査ログの中央集約
• データ契約 · 変更プロセス
• 法的な保管・破棄ポリシー
• AI・ML 領域のガバナンス（モデル・データの出所）
• 規制マッピング（GDPR・PIPA・AI Act・セクター規制）
• 従業員教育・経営陣への報告

第15章 · 次回予告 — Season 5 Ep 8:「Observability 2025 (Logs・Metrics・Traces + LLM)」

ガバナンスが「データをどう管理するか」だとすれば、Observability は「システムとデータが実際にどう回っているか」だ。

• OpenTelemetry の成熟
• Metric・Log・Trace という3大シグナルの統合
• Grafana Cloud・Datadog・New Relic・Splunk・Honeycomb・SigNoz
• Tempo・Loki・Mimir・Jaeger・Zipkin
• LLM オブザーバビリティ（LangFuse・LangSmith・Phoenix・Helicone、Ep 6 の延長）
• SLO・SLI とエラーバジェット
• カオスエンジニアリングと回復力
• 韓国企業のオブザーバビリティスタック
• 「オブザーバビリティは保険ではなく製品品質」

「オブザーバビリティなくして運用なし」 — 2025年のインフラのデフォルト。

次回の記事で会おう。

まとめ: 2025年のデータガバナンスはカタログ + Lineage + 品質 + PII・規制の4軸。OpenLineage が系譜の標準になり、Collibra・Atlan・DataHub・Alation がカタログの4大オプション、Unity・Polaris・Glue が技術カタログを担う。PII は検出・分類・マスキング・トークン化・暗号化の5段階で管理され、GDPR・韓国 PIPA・AI Act が規制のトライアングル。AI 時代のガバナンスはモデル・プロンプト・学習データまで拡張され、データ主体の権利（DSR）には自動化ワークフローが必須。韓国企業は網分離・韓国語メタデータ・レガシー統合が課題であり、ガバナンス専任人材の確保が次世代の競争力になる。「管理しなければ管理される」 — データガバナンスの2025年の法則。