Knowledge Catalog を活用したメタデータ自動付与パイプライン構築

Supership株式会社 今村豊（プロダクト開発本部 アドテクノロジーセンター 副センター長）によるGoogle Cloud Next Tokyo '26（セッションID: D2-DA-14）の登壇資料です。

広告プラットフォーム事業におけるBigQuery上のメタデータ管理の課題を踏まえ、Google CloudのKnowledge Catalogを軸としたメタデータ自動付与パイプラインの構築事例を紹介しています。国際標準フレームワークCDMC（Cloud Data Management Capabilities）に準拠したデータガバナンス自動化のPoCについて、設計から検証結果までを解説します。

関連情報: https://supership.jp/news/2026/07/02/14473/

▼一緒に働く仲間を募集中です！
https://supership.jp/recruit/

▼オープン社内報も毎月更新中！
社内報：https://super-stories.com/

Transcript

1. Knowledge Catalog を 活用したメタデータ 自動付与パイプライン構築 Proprietary
2. セッション内容 Google Cloud Next Tokyo 01 事業背景と問題 02 アーキテクチャ 03 実装 04 成果 Proprietary
3. 今村 豊 Supership 株式会社 プロダクト開発本部 アドテクノロジーセンター 副センター長 Google Cloud Next Tokyo Proprietary
4. 01. 事業背景と問題 Google Cloud Next Tokyo Proprietary
5. Supership グループについて 大企業 × スタートアップが共創するハイブリッド スタートアップです。 合計 10 社 スタートアップ 共創体 グループ企業 7 社合併 関連会社 Google Cloud Next Tokyo 設立背景 KDDI オープン領域における事業拡大 推進を目的として、数多く ベン チャー企業を M&A し、そ 中核企業と して Supership を設立。 スタートアップ企業 スピード感と高度な テクノロジーに加えて、大企業 アセット をもとにビジネスを展開するハイブリッド スタートアップとして成長を続ける。 「新たな価値を共創する世界的なテクノ ロジー企業群になる」というビジョン も とにインターネット 世界からリアル 領 域まで、データとテクノロジーを強みにあ らゆる分野で 事業拡大、新規事業 創出を目指す。 Proprietary
6. 事業紹介 グループとして大きく 2 つ 事業カテゴリを展開し、新規事業 マーケティングソリューション事業 データソリューション事業 創出にもチャレンジしています。 ポスト Cookie に対応する次世代型データ マーケティング オンライン / オフライン 垣根を越えたデータ起点 提供 企業価値創出を支援 主にここ 話をします Google Cloud Next Tokyo Proprietary
7. 事業背景 事業特性（データ管理 • • • 観点から） 多数 契約先企業から データを 「預かる」 （広告主・媒体・パートナー） 預かったデータを多様な形で 「活用する」 （セグメント分析・デマンドや媒体へ 連携・広告配信・データ連携） データ活用に 調達時に発生する利用範囲・保持期間・秘匿性といった 制約が常に付きまとう → データ管理 Google Cloud Next Tokyo 成否が、そ まま事業リスクに直結 Proprietary
8. 取り扱うデータ 広告配信ログ 広告配信プラットフォームが受信するインプレッション、クリックなど イベントログ。 → 接続する媒体や他 プラットフォームと 契約が付随する。 オーディエンス データ 広告配信ターゲティングやセグメント分析用 オーディエンス 属性情報。 → 他事業者から連携されて流入するデータに対する利用契約が付随する。 Google Cloud Next Tokyo Proprietary
9. データ基盤 変遷 オンプレ Hadoop から Google Cloud へ 2021 〜 2023 年 オンプレ Hadoop（約 300 ノード / 11PB HDFS）を Lift & Shift で Google Cloud へ移行完了 現在（2026 年） Shift フェーズ進行中 • • • Hadoop 互換基盤メイン → BigQuery メインへ切り替え中 Lift 完了時点で保存データ 1/3 に削減済み（データ 整理） データ ガバナンス強化 Shift フェーズ 最重要テーマ Google Cloud Next Tokyo Proprietary
10. 管理対象 規模感 Hive テーブルと BigQuery テーブル • • 合計。 Hive テーブル 周辺ワークロード互換 ためし らく残る そこに Shift で BigQuery 側が積み上がる 管理対象 手動で 増える一方。 メタデータ運用 Google Cloud Next Tokyo 破綻する。 Proprietary
11. 課題 ① データと契約 • • • • 管理 複雑化している 複数社間 データ提供契約が多数、並行して存在 契約書 利用条件（データ項目・用途 限定）が、デー タ カタログに 未反映 契約制約違反リスクを都度 手動でチェック 「こ テーブル ど 事業者・契約・条項に紐づくか」が 現場で 即答できない Google Cloud Next Tokyo Proprietary
12. 課題 ② メタデータ管理が手動 • • データ オーナーや付帯契約が不明なテーブルがあ る→ ダーク データ化 新しいテーブルが作られるたびに、誰かが手動でメタ データを付与する必要がある ◦ 基盤移行中でテーブル数 日々増加 → 手動 棚卸しで 限界 Google Cloud Next Tokyo Proprietary
13. 課題 規模 × 管理 まとめ 複雑性 × 手動運用 = スケールしない スケーラビリティ Google Cloud Next Tokyo ために自動化が必要 Proprietary
14. 02. アーキテクチャ Google Cloud Next Tokyo Proprietary
15. CDMC フレームワーク CDMC（Cloud Data Management Capabilities） クラウド上 • • • データ管理能力を体系化した国際標準フレームワーク 14 キー コントロール うち、本プロジェクト Key 2 / 6 にフォーカス ◦ Key 2 Data Ownership ← 課題 ②（データオーナー） ◦ Key 6 Data Classifications ← 課題 ①（付帯契約情報） CDMC 観点に沿ってデータ管理 課題を分解して捉えることができた。 さらに Google Cloud 公式でこ CDMC 参照実装 記事が公開されている。 [1] こ 記事 データ管理 自動化を前提とした実装を提案しており、非常に具体 性が高く参考になった。 [1] BigQuery データ ウェアハウスに CDMC Google Cloud Next Tokyo キー コントロール フレームワークを実装する Proprietary
16. 全体像 ノウハウ 応用 ：メタデータを生成するパイプラインを作る。 データを生成するパイプラインと同じ。 データ エンジニア 既存知見（ SQL・オーケストレーション）をそ まま転用可能。 オーケストレーション オーケストレーション Cloud Workflow 毎時起動 Cloud Scheduler 収集 変換 Entry Collector Cloud Run 付与 ETL BigQuery Aspect Updater Cloud Run メタデータ メタデータ ストレージ Knowledge Catalog Google Cloud Next Tokyo Proprietary
17. メイン 指標：ガバナンス カバレッジ データ管理 以降 自動化によって どれくらい 実装・成果 「こ 1つ メタデータが解決されるか を追跡する指標。 数字をどう上げるか」をベースに評価する。 オーナー・契約を自動特定できた Entry ガバナンス カバレッジ = 統制対象 Entry 全カタログ (BigQuery + Hive) − スコープ外 ※スコープ外 ＝ temp テーブルや個人サンドボックス等 Google Cloud Next Tokyo Proprietary
18. 中心となるデータモデル パイプラインが扱う 4 つ • • • • 中心エンティティ データ オーナー ：データ 管理元。オーナー レジストリで管理 契約：事業者間 データ提供契約（用途 制限など）。契約レジストリで管理 Entry（Knowledge Catalog）：各 Hive, BigQuery テーブルを自動登録したカタログ項目 Aspect（Knowledge Catalog）：Entry に付与するメタデータ（オーナー・契約制約など） → 解決したオーナーと契約を Entry に Aspect として付与 データオーナーレジストリ BigQuery Aspect Knowledge Catalog 契約 レジストリ BigQuery レジストリから属性を Aspect として抽出 Google Cloud Next Tokyo Entry Knowledge Catalog Entry に Aspect を付与することでメタデータとして登録 Proprietary
19. データ 流れ：収集 → 変換 → 付与 • • • 収集：テーブル → Knowledge Catalog Entry（自動登録）→ Entry Collector が Entry 情報を BigQuery に蓄積 変換：dbt + BigQuery でレジストリ（オーナー / 契約）と JOIN して付与対象 Aspect を生成 付与：Aspect Updater が Knowledge Catalog API で Aspect 付与 収集 Hive / BigQuery テーブル Knowledge Catalog Entry Entry Collector 変換 更新 Entry dbt 付与 Aspect 更新リクエスト Aspect Updater Aspect オーナー / 契約 データオーナー レジストリ Aspect Updater 契約 レジストリ Google Cloud Next Tokyo Proprietary
20. 変化 手動管理 自動管理 手動管理（スプレッドシート 台帳・属人的） 自動パイプライン（毎時実行・ IaC で再現可能） オーナー自動特定 0%（カタログ全体が不明） オーナー自動特定でカバー（ BigQuery + Hive ） オーナー / 契約紐付けが見えない カタログを開け テーブル増加に追いつけない 未解決 Google Cloud Next Tokyo 制約が分かる 例外台帳で可視化・期限管理 Proprietary
21. 03. 実装 Google Cloud Next Tokyo Proprietary
22. Entry Collector • • • Knowledge Catalog Search API で、更新された Entry を毎時収集 (updatetime>{query_time}) BigQuery テーブルに蓄積（時間パーティション） Search API 呼び出し 現状コストが発生しない で気軽に呼び出せる 収集 変換 Staging メタデータストレージ Knowledge Catalog SearchEntriesRequest 差分取り込み Google Cloud Next Tokyo Entry Collector Cloud Run Entry 生データ load Proprietary
23. BigQuery を用いたメタデータ 結合 • • • SQL で宣言的に Aspect 算出過程をデータモデルとして定義する。 Entry とレジストリ (背景情報 ) JOIN でメタデータ結合を行う。（後述） レジストリ Entry ID パターンマッチやラベル 照合を結合キーにする。 変換 Intermediate Staging Marts Entry 生データ データ管理 Aspect オーナー レジストリ Aspect 更新リクエスト エンリッチ済み Entry 契約管理 Aspect 契約レジストリ Google Cloud Next Tokyo Proprietary
24. BigQuery（SQL）で Aspect を計算する 基本 Entry 属性を使ってレジストリを lookup する操作を JOIN で表現。 正規表現マッチを JOIN キーにしている Entry ID /datasets/A/tables/i mpression /datasets/A/tables/ click Google Cloud Next Tokyo Entry パターン テーブル名 impression click join mappings m -- glob パターン (*) を正規表現に変換してentry_id と突合 on regexp_contains(e.entry_id, concat('^', regexp_replace( regexp_replace(m.entry_pattern, r'([.\+?()\[\]{}|^$])', r'\\\1'), r'\*', '[^/]*'), '$')) 契約 /datasets/A/tables/* 配信ログ契約 /datasets/B/tables/a udience_Z_* Z 社オーディエン ス データ Proprietary
25. オーナー・契約をどう解決するか • • Entry ごとに確度 高い順で上から解決。最初に当たった層で確定する。 4 段階 層で処理する（L3 現状未実装な で設計 み）。 Entry L1 宣言：ラベル照合 confirmed → Aspect 付与 L2 ルール：パターン L3 推定：作成者 例外台帳 （猶予期限つき・期限管理） L4 未解決 Google Cloud Next Tokyo Proprietary
26. 2 種類 • • Custom Aspect を自動付与 DataManagement Aspect：オーナー（データ 管理元）。 ◦ 機密区分・保持期間など 今後拡張 ContractualData Aspect：契約 ID ◦ 匿名化要件、地理的制約など 今後拡張 Aspect フィールド Google Cloud Next Tokyo CDMC Key owner Key 2: Data Ownership contracts Key 6: Data Classifications（付帯契約情報） Proprietary
27. Aspect 付与 結果（例） データ カタログを開くだけで、契約やオーナー情報が分かる状態。 Google Cloud Next Tokyo Proprietary
28. 04. 成果 Google Cloud Next Tokyo Proprietary
29. 成果：ガバナンス カバレッジ 変化 0% → 98.6% Before After 手動運用でオーナー付与ゼロ（ 0%） After: 自動特定 800 / 統制対象 811 Entry = 98.6% • • 対象 カタログ全 1,544 Entry（BigQuery 295 + Hive 1,249）。temp・サンドボックス等 733 件 ス コープ外宣言、真 未解決 11 件 みで例外台帳に可視化 カバレッジ 宣言（レジストリ） × ルール × 例外台帳 積。 → 整備が進むほど自動で上昇 Google Cloud Next Tokyo Proprietary
30. KPI / KGI：ガバナンス 進捗を測る KPI（プロセス指標） • • ガバナンス カバレッジ ＝ 98.6% CDMC 準拠率（自動計測中 サブ指標: Ownership / Classification / データ品 質） KGI（ゴール指標） Shift フェーズ 出口 • • 「ダーク データ ゼロ」 スコープ内でオーナー不明 データ: 現在 11 件 → 例外台帳で期限管理し 0 件 へ 契約紐付け不明 データ: 例外台帳で可視化し 0 件へ Google Cloud Next Tokyo Proprietary
31. 学び ガバナンス 実行面 「もう一つ データ パイプライン」として 自動化できる Google Cloud Next Tokyo Proprietary
32. 現実的な課題 • • 収集 スケーラビリティ：管理対象プロジェクトが増えた場合 並列収集処理が必 要（10 プロジェクト程度を管理していく） 契約書 PDF から 自動抽出：実装（ML.GENERATE_TEXT ベース ） 存在する が、抽出精度 未検証。契約文書を Cloud Storage に集約する運用など周辺課 題が山積 → 実運用まで 到達せず → こうした課題 あるも 、 自動化 基盤 整備できるとわかった PoCだった Google Cloud Next Tokyo Proprietary
33. まとめ：キーメッセージ 3 つ • • • データ ガバナンス 自動化 、 Google Cloud サービスを組み合わせれ 今すぐ始められる ◦ Knowledge Catalog + BigQuery + Cloud Workflows ◦ Knowledge Catalog 機能が充実してきたことで、ガバナンス課題に取り組みやすくなってきてい る 国際標準フレームワーク（ CDMC）に沿って設計すると、何をすべきかが明確になる ◦ フレームワークによって部分問題に分割して解決することができるようになった 小さく始めて、段階的に拡張する ◦ PoC → 段階的に対象拡大 → 本番化（Lift & Shift Shift フェーズと合わせ進行） Google Cloud Next Tokyo Proprietary
34. 今後 • • • • • 展望 契約書 PDF から 自動抽出 本番化（実装済み・精度検証と PDF 集約運用 整 備が今後 課題） CDMC キー コントロール準拠度ダッシュボード 機密データ 自動分類（Sensitive Data Protection 連携） データ品質 自動測定 Policy を使ったアクセス制御 ：付与済み Aspect（機密区分・契約制約）を起点 に、ポリシータグ / 列レベル アクセス制御で「メタデータに基づく実アクセス制御」へ 展開 Google Cloud Next Tokyo Proprietary
35. Thank you Proprietary