はじめに
本屋さんで出会った『メタデータ管理入門』という本を読んでいます。タイトルからは、「Data Catalogの使い方」のような内容を想像していたけど、全然違った。
直近の課題としては、業務データをBigQueryへ入れて分析・可視化につなげるELTに関わっていて、その中でもメタデータに関する問題は出てきます。項目の意味、フラグは0/1なのかBOOLEANなのか、NULLの扱い、リネージュ、似た項目の違い、項目が追加された経緯、etc...。
そういう情報はないかというと、大体ある。大量のConfluence（以下、コンフルエンス）のあちこちに。コンフルエンスは、ブログの塊のような、wikiのようなものだと私は思っていて、こんな問題があります。
- 書いた人、レベル、視点がいろいろ
- 時期がバラバラ
- 同じ対象を違う観点で説明する
- 過去には正しかったが今は違う情報も出てくる
email STRING を見ても、メールアドレスのことはよくわからない
例えばBigQueryに、 customer.email STRING という列があったとして、ここからわかるのは、「customerテーブルのSTRING型の列」くらいです。
でも人が知りたいことはそれではなくて、
- この
emailは何のためのメールアドレスなのか？ - 個人情報なのか？
- マスクされているのか？
- どのシステムから来ているのか？
- 誰がアクセスできるのか？
- どのレポートで使われているのか？
- いつから現在の仕様になったのか？
という感じでさまざま。
１つのメールアドレスにはたくさんの顔がある
つまり email という列には、たくさんの顔があって、見る人によって見たい顔が違い、そして管理・記録しているところも違う。
- 型：BigQueryのSTRING
- 業務上の意味：業務要件を記したドキュメント内での役割
- 個人情報分類：プライバシー/個人情報の観点、ソースの加工方法
- アクセス権：GCPのIAM
- データの流れ：Lineage
- 変更経緯：変更履歴とその理由
「型」「個人情報分類」がキーで、「STRING」「マスクしている」が値の、キーとバリューのセットのようなものが大量にある。『メタデータ管理入門』を読んで、「メタデータ」という言葉、そして関係者は本当に広いと思った。
でも、ここまではなんとなく想像できていた。
本を読んでいて面白かったのは、その次だった。
これらは単に種類が違うだけでなく、それぞれ別の人、別の仕組み、別の場所で管理されている。
同じITランドスケープを、違う地図で見ている
customer.email は１つしかないのに、立場や管理システムによって見え方が変わる。
- データマネジメント：STRING型の列
- 情報管理：個人情報
- IT管理：CRMやMAが利用するデータ
- ナレッジ管理：業務仕様や設計判断で文書化されている対象
ここでは customer.email という1列に注目したけど、これはもっと広い範囲でも同じで、本の表現を借りれば、同じITランドスケープを立場によって違う地図として描いている。
立場によって見方が変わり、その立場ごとに、ドキュメンテーションされているし、先輩から後輩へ伝わっている。
なお本の中では、メタデータ管理システムは、サイロ化されてそれぞれ独立した情報になってるよね、という文脈だけど、私が関わるシステムでは、コンフルエンスという巨大な堆積層の中に、さまざまな立場から見たITランドスケープの断面が埋まっている。（業務要件、設計意図、運用知識、変更履歴...）
全部を１つにしなくていいという、Meta Grid
著者の考え方は、「全部を１つに統合しましょう」ではありません。
むしろ「BigQueryとしての見方」「IAMとしての見方」「変更管理としての見方」はそのまま残す。そのうえで、分散したメタデータ同士をリンクする。
この思想をMeta Gridとして紹介しています。
本には、
- マイクロサービス ＝＞ 業務データの分散化
- データメッシュ ＝＞ 分析データの分散化
- Meta Grid ＝＞ メタデータの分散化
という第３の分散化として説明してます。この辺りは本書を読むと面白い。
自分の環境ではどう使えそうか
さて、上で書いた通り自分の環境では、本の例ほど管理システムが綺麗に分かれていない。むしろ、「BigQuery＝物理的な事実」「コンフルエンス＝その他大量の知識」に近いです。
そこで、本のMeta Gridをそのまま実装するのではなく、「事実とその根拠を接続する薄いレイヤー」として解釈してみました。
もちろん、これは本書で説明されているMeta Gridそのものではありません。私なりに「分散した情報を無理に集約せず、つながりだけを持つ」という発想を小さく試してみたものです。
customer.email を例とすると
---
entity: customer.email
fact:
personal_data: true
validity:
from: 2026-10-01
to: null
source:
type: confluence
reference: xxxx
---
# customer.email
顧客のメールアドレス。
個人情報として扱う。
詳細な根拠や仕様についてはSourceを参照する。
人が読む情報はYAML Front Matter付きのMarkdownファイルで持ち、AIや検索処理が引きやすいように、別途JSONのインデックスを生成する形にしてみました。詳細情報自体は元ドキュメント側に残し、ここでは検索や接続に必要な情報だけを持つイメージです。
ポイントは、
コンフルエンスの内容をここへ転記することではない。
「何についての情報か」「いつ有効な情報か」「根拠はどこか」だけを持つ。
こうすると、冒頭に書いた「情報はある。でも散らばっていて、新旧や視点が入り混じっている」という問題を、少し扱いやすくできそうです。
AIをデータディスカバリーチームの一員にする
本の中では、「データディスカバリーチーム」を作って、「従業員」「コンサルタント」「ソフトウェアベンダー」という立ち位置で陥りやすい問題を回避するよう書いています。
ここで私の環境では、AIを活用してみようと思っています。つまりAIをデータディスカバリーチームの一員にする！
「customer.emailって、どのシステムから来てるんだっけ？」「個人情報が扱われているテーブル・列はどれ？」などの疑問を、まずAIに調査させる。ただし、AIの回答だけでは知識がその場限りになる。
そこで、調査によって確認できた「事実・有効期間・根拠」をMarkdownへ残す。
次に同じような質問が来た時には、その地図をまず参照する。
既存文書を検索して回答するだけのRAGではなく、調査結果そのものが次の検索対象として蓄積されていきます。
つまりAIが質問に答えるたびに、組織の知識の地図が少しずつ育つ。
おわりに
今回の本は、抽象度も高く、略語もたくさん出てくるので、正直読むのは楽ではないです。私はAIに言葉や文脈を聞きながら読みました。
でも読み終わる前から、BigQueryの列の見え方が少し変わりました。
customer.email STRING と書いてあるのを見たとき、「この列について、会社の中には他にどんな地図が描かれているのだろう？」と考えるようになりました。
それだけでも、この本を読んだ価値はあった気がします。
では、よきメタライフを！