メタデータの3種類（最重要）
| 種類 | 内容 | 例 | 主な利用者 |
|---|
| ビジネス | 用語定義・ビジネスルール・スチュワード情報 | 「顧客」の定義、機密ランク | ビジネスユーザー・Data Steward |
| 技術 | 構造・スキーマ・DDL・制約 | テーブル名、データ型、キー | 開発者・DBA・データアーキテクト |
| 運用 | 処理実行状況・ログ・更新履歴 | ETLログ、最終更新日時 | データエンジニア・オペレーター |
データリネージ（Data Lineage）— データの系譜
| 粒度 | 内容 | 実装コスト | 推奨場面 |
|---|
| システムレベル | A → B → C のシステム間フロー | 低 | 最初のステップ |
| テーブルレベル | table_X → table_Y の依存関係 | 中 | GDPR基本対応 |
| カラムレベル | 特定の計算式・変換ロジックを追跡 | 高 | 規制対応（BCBS239等） |
データカタログとメタデータ関連ツールの比較
| 用語 | 役割 |
|---|
Business Glossary
ビジネスグロッサリー |
ビジネス用語の統一定義集。ビジネスユーザー向け |
Data Dictionary
データディクショナリ |
データ要素の技術仕様書。開発者・DBA向け |
Data Catalog
データカタログ |
データ発見・検索のプラットフォーム（フロントエンド） |
Metadata Repository
メタデータリポジトリ |
メタデータの格納基盤（バックエンド） |
Business Glossary vs Data Dictionary
| 観点 | Business Glossary | Data Dictionary |
|---|
| 対象者 | ビジネスユーザー | 開発者・DBA |
| 内容 | 概念の定義・文脈 | 技術仕様（型・長さ・制約） |
| 例 | 「顧客」の定義文 | customer_id: BIGINT NOT NULL |
試験パターン
「ビジネス用語を統一したい」→ Business Glossary / 「テーブル定義を文書化したい」→ Data Dictionary
メタデータアーキテクチャのパターン
Centralized（集中型）
全データソース → 中央メタデータリポジトリ ← 全ユーザー
適合: 中規模組織・中央集権型ガバナンス
問題: ソース数増加でボトルネック
Federated（連邦型）
部門Aストア + 部門Bストア → メタデータハブ（統合ビュー）
適合: データメッシュ・大規模組織
問題: 部門間でのメタデータ標準の統一困難
Active Metadata（能動型）
データ更新 → メタデータ自動更新 → 下流処理を自動トリガー
Passive（記録するだけ）から進化した概念
応用: DQ違反の自動アラート・影響リストの自動生成
Case 1: データカタログ導入プロジェクト（グローバル製薬企業）
背景
社員8,000名・データソース200以上。DWHに300以上のテーブルがあるがビジネス上の意味が不明。同じ顧客セグメント計算SQLが部門ごとに15種類存在。GxP（医薬品規制）の監査で「データの起源を証明できない」と指摘。
ツール選定
| ツール | 候補理由 | 選定結果 |
|---|
| Collibra | エンタープライズ向け・ガバナンス統合 | 採用 |
| Apache Atlas | オープンソース・Hadoopエコシステム統合 | 候補落選（サポート懸念） |
| Microsoft Purview | Azure環境と統合 | 候補落選（マルチクラウドに不向き） |
| Alation | AIによる自動提案 | 最終候補まで残るも予算超過 |
Business Glossary エントリ例
term: "アクティブ顧客"
definition: "過去12ヶ月以内に最低1回の購入取引がある顧客"
synonyms: ["有効顧客", "active customer"]
data_steward: "営業本部 田中部長"
related_tables:
- table: "dim_customer"
column: "is_active_flg"
導入後の効果
| 指標 | Before | After（12ヶ月後） |
|---|
| データ発見にかかる平均時間 | 2.3時間 | 18分 |
| データ定義の重複定義 | 15種類 | 1種類（共通化） |
| 監査対応時間 | 5日 | 0.5日 |
| 未使用テーブルの割合 | 不明 | 37%（廃止候補特定） |
Case 2: データリネージの実装（地方銀行 — BCBS239対応）
背景
BCBS 239（バーゼル委員会のリスクデータ集計原則）への対応が必要。「貸倒引当金計算に使ったデータがどこから来たか」をカラムレベルでトレースできる必要がある。
リネージ収集の自動化手法
ETLツール統合
dbt はメタデータとリネージを自動生成。Apache Airflow + OpenLineage でジョブ実行のリネージをキャプチャ。
最も効率的
クエリログ解析
BigQueryのINFORMATION_SCHEMAからクエリログを解析してリネージを推定。
推定精度は中程度
静的コード解析
SQLパーサーでSELECT文のソース・ターゲットを抽出。dbtのmanifest.jsonを解析。
詳細なリネージが可能
失敗パターン
手動でリネージを記録しようとする → すぐに陳腐化し管理不能。リネージをドキュメントで管理する → コードとの乖離が発生。自動収集が必須。
Case 3: メタデータ成熟度モデル
| レベル | 状態 |
|---|
| Level 1 | アドホック（個人のノート・Excelで管理） |
| Level 2 | 部分的（一部システムのみ管理） |
| Level 3 | 標準化（組織全体で統一ツール・プロセス） |
| Level 4 | 管理（品質指標・活用率でメタデータを評価） |
| Level 5 | 最適化（Active Metadata・自動化） |
メタデータ品質指標（Specialist試験頻出）
| 指標 | 計算方法 | 目標値 |
|---|
| カバレッジ | 定義済みオブジェクト / 全オブジェクト | 90%以上 |
| 鮮度 | 最終更新からの経過日数 | 30日以内 |
| 正確性 | 定義と実際のデータが一致する割合 | 95%以上 |
| 利用率 | カタログ経由でのデータアクセス率 | 組織ごとに定義 |
Case 4: Impact Analysis の実装
背景
DWHのソーステーブル（src_customer）のカラム名を変更したい（cust_no → customer_id）。変更前に影響範囲を調査する必要がある。
| 依存オブジェクト | 影響度 | 対応方法 |
|---|
| ETLジョブ（5本） | 高 | ETLの修正が必要 |
| ストアドプロシージャ（3本） | 高 | 修正が必要 |
| ビュー（8本） | 中 | ビュー定義の更新 |
| BIレポート（12本） | 中 | データソース設定の確認 |
| Excelマクロ（不明） | 不明 | IT部門外のツールは把握困難 |
教訓
Impact Analysis が完全に機能するには、すべてのデータフローがメタデータとして記録されている必要がある。Excelマクロのような「管理外ツール」はリスクとして認識されるべき。