サービス開発チームがDBのメタデータを書く。これをデータマートまで持ち込む。全てを自動化したい！->しました

サービス開発チームがDBのメタデータを書く。これ をデータマートまで持ち込む。全てを自動化した い！->しました Tokyo dbt Meetup #19 / 2026.02.25

自己紹介 しめにゃん（@_sisisin） 株式会社ナレッジワーク ソフトウェアエンジニア データ領域は2025/04に初参入

• https://x.com/_sisisin

おしながき システム概観・モチベーション Google Cloud側のデータ・メタデータ統合の仕組み解説 AWS側のデータ・メタデータ統合の仕組み解説

おしながき システム概観・モチベーション ←いまココ Google Cloud側のデータ・メタデータ統合の仕組み解説 AWS側のデータ・メタデータ統合の仕組み解説

システム概観 Google Cloud上にサービスを構築 データ基盤もGoogle Cloud 昨年の事業統合により、AWSのシステムもサービスとして新たに統合

データ基盤全体像 Data Sources Data Lake Data Warehouse Data Marts service project PostgreSQL MySQL Data Lake from knowledgework Data Mart for knowledgework PostgreSQL Replica Mart Model Parquet data project Data Lake from AWS data-mart project Data Warehouse by dbt Staging / Intermediate Model Data Mart for analytics BigLake Table Mart Model dbt Cloud Run 論理レイヤー クラウド インフラ

データ基盤全体像 Google Cloud Cloud SQL -> BigQuery -> dbt AWS RDS -> S3 -> GCS -> BigQuery -> dbt

Why メタデータ？ エンタープライズ企業を主たるターゲットとしてサービスを売っているので、個人情報 の取り扱いを厳格に運用したいという要求がある（万が一漏れたりするとマジで大惨 事） 組織としてもISMSやプライバシー認証を取得するなどの活動も行っている

Why メタデータ？ データ基盤もその例に漏れず、お客様の個人情報を理由なく閲覧できないような制御 をしっかり運用する必要がある （データ活用文脈でのdescriptionよりは、こちらの個人情報かどうかの判別が最重要 項目となっている）

How メタデータ？ BigQueryのポリシータグ機能を利用し、列レベルのアクセス制御を行う PII（個人情報）を含む列は特定のロールだけが承認フローを経てのみ閲覧可能なよう に慎重に取り扱い

自動化したい！ このような状況があるので、 サービス開発者がDBスキーマを定義する時点でPIIの判断を行いたい（正確性を担 保） 判定したPIIをデータパイプラインで常にキープし続けたい という要求が発生している 人力運用ではとてもではないが賄えないので、仕組みで担保していきたいというモチ ベーション

おしながき システム概観・モチベーション Google Cloud側のデータ・メタデータ統合の仕組み解説 ←いまココ AWS側のデータ・メタデータ統合の仕組み解説

Google Cloud側サービスのデータ・メタデータ処理 前提の共有と、その上での設計 実装 を順に説明していきます

Google Cloud側サービスのデータ・メタデータ処理 - 設計 Cloud SQL Datastream BigQuery DatastreamというマネージドCDC / Replicationサービスを利用してCloud SQL上の PostgreSQLのデータをBigQueryへ同期している しかしDatastreamには一部制約がある

制約とは -> スキーマが動的に生成されるのでこちら で制御できない！

制約について Datastreamはデータ（行）のCDCレプリケーション データ変更が発生して初めてスキーマが更新されるという性質 故に、mainブランチと実環境でスキーマが違うし、もっと言うと開発・本番環境でも スキーマが一致するとは限らない もちろんポリシータグも直接コード化は出来ない 更に、PostgreSQLのCOMMENT情報も同期されない

ということで dbt側のYAML定義が「ある時点のスキーマ」を前提にできない 総論、データの同期そのものは簡単だが、スキーマやメタデータの扱いに制約がある という形 この上でどうにかして上手いことデータ基盤へデータ・メタデータを持ち込みたい

どうやったか メタデータ定義はPostgreSQLのCOMMENT ON句で書いてもらう そのメタデータをINFORMATION_SCHEMAから引っ張ってきてBigQueryに反映さ せるGitHub Actionsを動かす -> BigQueryをSSoTとするように、すべての情報がちゃんとBigQueryに集約されるよう 設計

どうやったか サービス側でちゃんとBigQueryのテーブルに情報が同期されてる状態を担保する スキーマが環境ごとに異なる問題に関してはデータ基盤側でどうにかする。BigQuery がSSoTになっていればなんとか出来るので

Google Cloud側サービスのデータ・メタデータ処理 - 実装
PostgreSQLのCOMMENT ON句にJSONを埋め込む

COMMENT ON COLUMN users.name IS 'ユーザーの名前
%kw_meta_v1%{"mask_policy": "pii"}';

mask_policy 値 none pii ... の値: 意味 マスク不要 個人情報 （他にもいくつかのポリシーあり）

サービスを実装する人がメタデータの判断をするのが望ましい DataplexCatalogのyamlを書かされるよりはマイグレーションファイルにDDLと共 に書くほうが認知負荷は低かろう という判断でこのような構成にしています

書き忘れ防止策 マイグレーションファイルのlint処理を行い、そこでコメントのチェック処理を入れて いる 文字列型などの列を作った場合にメタコメントが記述されているかチェック メタコメントのスキーマが正しいかチェック

BigQueryへの同期 GitHub Actionsで以下の処理を実施 1. CI上でPostgreSQLを立ち上げてDBマイグレーション実行 -> メタデータ付きDBを 構築 2. INFORMATION_SCHEMAからコメントを抽出 3. 実環境のBigQueryテーブル・列のコメントとポリシータグを更新

Google Cloudのサービスのデータ・メタデータ整備はこのように実現した ここまでで、Datastreamでレプリケーションされた BigQueryテーブルがSSoTとなるよ うにメタデータまで集約 した状態を構築できた データ基盤側のリポジトリではこのBigQueryテーブルだけを参照してデータを構築す ればOK。どうやってメタデータが送られてくるかといった点に関心を持たずにいられ てハッピーというわけ

AWSの話は一旦置いておいて、先に最後（=dbtのデータマート）までの流れを追う

図（再掲） Cloud SQL Datastream BigQuery

dbt上でのデータ・メタデータの取り扱い 前提として、BigQueryに欲しい情報が全部あるものとする そうなっていれば、source定義〜モデルのyamlも全てBigQueryを正として扱う発想で 解決できるはず

という発想の元、自動生成CLIを作った

heaven-syncerというCLIを自作しました 以下のような事ができます -> source yamlの生成 heaven-syncer generate:model -> model properties yamlの生成 heaven-syncer generate:snapshot -> snapshot yamlの生成（詳細は省略） heaven-syncer inherit-meta -> メタデータ継承 dbt-osmosis というOSS+αぐらいの機能を作り込んでいます heaven-syncer generate:source

heaven-syncer generate:source dbt sourceの定義を自動で生成する 事前にどんなBigQuery datasetのsourceを生成するかを設定しておく 設定ファイルを元にしてコマンド実行時にBigQueryのスキーマやメタデータを読 み取ってsource定義を出力 追加のロジックでconfigフィールドに色々情報を足せるようにしている（重要） ここでmask_policyをconfig.metaに入れたり、開発環境・本番環境のスキーマ の差異をどうにかする情報を入れたりしている

生成例
version: 2
sources:
- name: knowledgework_db
tables:
- name: users
config:
enabled: "{{ target.name in ['local', 'dev', 'qa'] }}"
meta:
primary_keys:
- id
columns:
- name: id
data_type: STRING
description: ユーザID(UUID)
- name: email
data_type: STRING
description: ユーザーのメールアドレス
config:
meta:
kwmeta:
mask_policy: pii

heaven-syncer generate:model BigQuery上にあるモデルのテーブル情報を参照して dbt model propertiesのyamlを生成 する 生成する内容は単にテーブルの列名やらdescriptionやらがあれば書く、程度 モデルのyamlを勝手に作ってくれる、という点が大事

生成されるymlの例 version: 2 models: - name: stg_tenants columns: - name: id description: テナントID data_type: STRING

heaven-syncer inherit-meta メタデータの継承処理を行う 概ね dbt-osmosis というOSSで実現していることを実装した このコマンドの出力時に、sourceに定義されている kw_meta を元に policy_tags 設 定を出力し、ポリシータグの継承を実現

# sources.yml 抜粋
- name: email
data_type: STRING
description: ユーザーのメールアドレス
config:
meta:
kwmeta:
mask_policy: pii
# staging model YAML
version: 2
models:
- name: stg_users
columns:
- name: email
data_type: STRING
description: ユーザーのメールアドレス
config:
meta:
kwmeta:
mask_policy: pii
policy_tags:
- '{{ var("policy_tags").pii[target.name] }}'

PostgreSQL COMMENT -> BigQuery description -> sources.yml -> dbt DAG内でmeta inheritance という流れの中で、独自定義のmeta情報を混ぜ込みつつ上手いこと一気通貫でメタデ ータが扱えた

ほんとに？

概ねdbt-osmosisでやっていることを実装しています と述べたが、実は dbt-osmosis と同じくカラムリネージをあまり精度高くやれていな い課題がある（列名の単純マッチのような文字列処理の範疇で出来ることだけやって いる） ・・・なので、普通に取りこぼす問題があるのであった・・・

これではいけませんね ではその問題をどう対処しているかというと、Claude Code Actionにレビュー用のカス タムコマンドを用意してPRごとにレビューさせてなんとかしている （なんとかというが、LLMにとってはかなり自明寄りのタスクなので、精度よく指摘 してくれていい感じ）

review-dbt-policy-tags.md 抜粋 --description: Review dbt models for policy tag inheritance issues argument-hint: '[PR number]' allowed-tools: Bash(gh pr diff:*), Bash(gh pr view:*), Bash(./tools/ci/pr/upsert-comment.ts:*), Read, Grep, Glob --# Review dbt Policy Tags Review a pull request for policy tag (pii, cscd) inheritance issues in dbt models. ## Context - PR diff: !`gh pr diff $ARGUMENTS` - PR info: !`gh pr view $ARGUMENTS --json title,body,files` ## Task Analyze the PR diff and check if policy tags are properly inherited from staging models to downstream models.

GitHub Actions抜粋
- name: Run Policy Tag Review
uses: anthropics/claude-code-action@70e16deb18402428bd09e08d1ec3662a872e3c72 # v1.0.41
with:
claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
prompt: /review-dbt-policy-tags ${{ inputs.pr-number }}
claude_args: '--allowed-tools "Bash(gh pr diff:*),Bash(gh pr view:*),Bash(./tools/ci/pr/upsert-comment.ts:*),Read,Grep,Glob"'

ということで PostgreSQLからデータマートまでのデータ・メタデータ統合を紹介した

おしながき システム概観・モチベーション Google Cloud側のデータ・メタデータ統合の仕組み解説 AWS側のデータ・メタデータ統合の仕組み解説 ←いまココ

データ基盤全体像（再掲） Data Sources Data Lake Data Warehouse Data Marts service project PostgreSQL MySQL Data Lake from knowledgework Data Mart for knowledgework PostgreSQL Replica Mart Model Parquet data project Data Lake from AWS data-mart project Data Warehouse by dbt Staging / Intermediate Model Data Mart for analytics BigLake Table Mart Model dbt Cloud Run 論理レイヤー クラウド インフラ

AWS側サービスのデータ・メタデータ処理 RDS AWS Glue S3 Storage Transfer GCS BigQuery DBのデータをファイルに吐き出してGoogle Cloudへ転送してBigQueryへ取り込む、と いう定番構成 しかし、この構成でも当然メタデータの同期や環境ごとのスキーマの差異について対 処をしないと困っちゃうので、そのへんの工夫について紹介

対処しないと困る問題 こちらはDatastreamのときと違い、BigQueryのテーブル定義はスキーマを事前定義出 来る構成 しかし、開発環境と本番環境でスキーマの差異が生じるのはこちらでも発生する 故に、単純にmainブランチのマイグレーションファイルから作れるスキーマを元にし てBigQueryのテーブルを定義するのは上手くいかない

どうしたか 最終的に以下のようなワークフローの構成にした a. (GitHub Action) テーブルメタデータを抽出し、GCSへ配置するワークフロー b. (AWS) AWS GlueでMySQLのデータをParquetにしてS3へ配置するワークフロー c. (Google Cloud) ParquetをGCSへ転送してBigQueryテーブルを作りつつメタデータを 付与するワークフロー （＊）bのワークフローは元々統合した会社側で構築されていたものをそのまま利用す ることにした

どうしたか GitHub / GitHub Actions GCP - データ基盤 metadata file GitHub Actions AWS GCS parquet RDS (MySQL) AWS Glue S3 BigQuery

解説 - a. GitHub Action テーブルメタデータを抽出し、GCSへ配置するワークフロー Parquetを出すワークフローが既に構築されていたので、これを使わない手はない が、メタデータは落ちる

->メタデータ再構築をする必要があり、そのためのGitHub Actionsを組んで解決

解説 - a. GitHub Action MySQLをたててマイグレーションを実施して得られるスキーマ情報を参照したい 実DBにデータが入るのはmainにマイグレーションが入るより必ず遅い という前提があるため、データ転送のワークフローとは独立してGitHub Actions上にワ ークフローを構築 毎日最新のメタデータをデータ基盤用のジョブ向けにお届けする君となっています

解説 - b. AWS AWS GlueでMySQLのデータをParquetにしてS3へ配置するワークフロー AWS GlueというマネージドETLを利用してMySQLからデータを取り出してParquetファ イルとしてS3に配置 元々はAthenaから利用できるように構築していた基盤だが、Parquetをそのまま持って くるだけでBigQueryに取り込めるのでこれでいいっしょ！ってことで利用させてもら った

解説 - c. Google Cloud ParquetをGCSへ転送してBigQueryテーブルを作りつつメタデータを付与するワー クフロー このワークフローは実際には以下のようなステップを実行している Storage Transfer Serviceを利用したS3 to GCSのデータ転送 CREATE OR REPLACE EXTERNAL TABLE を発行してテーブルを作成 & a のワークフ ローで作ったメタデータをテーブルに付与するジョブ

BigQueryにはBigLakeテーブルという、GCSのような外部ストレージのデータをレコー ドとして扱う機能がある これを利用すればParquetに対してそのままクエリが出来る しかし、先程述べた通りテーブルスキーマが環境ごとに異なる・メタデータを持たな いという前提があるために、毎回作り直しとメタデータ付与をする処理を実行してい る

＊毎回テーブル作り直しって聞くとエッて感じるが、BigLakeテーブルはストレージが 外部化されている故に作り直しているのはスキーマなどのメタデータのみ テーブル作り直しのコスト（お金・時間）は全然低く済むのでこれで運用可能性の高 い作りとなっている

このアプローチで「メタデータやスキーマがちゃんと実態に即したSSoTと呼べる BigQueryテーブルを用意」が達成される

dbt側は？ しかしてAWSのデータをBigQueryに持ち込むことができた ここから先は「BigQueryというSSoTを介してdbtの環境を作る」という設計になってい るのであとは全く同じようにsource定義〜マートテーブル作成までが出来るようにな っている 新たにAWSのデータを取り込もうという話になってもBigQueryを作り切るだけをゴー ルとして動くだけで良かったので設計・実装面で迷うことは少なく済んで良かった

こぼればなし 仕組みの構築は「BigQueryちゃんと作ればOK！」で割と簡単だが、AWSのシステム側 のDBには当然列コメントの kw_meta メタデータはない なので、このデータパイプラインの開発と並行して列ごとにPIIを判定して列コメント として付与するという作業も行ったりした

作業としては以下のようなことを実施 全部のテーブル・列を列挙したスプレッドシートを用意して、列ごとにPII判定を サービス側のエンジニアに依頼 結果を元にマイグレーションファイルを実装 マイグレーションのlinterもMySQL用に再実装 この辺の実装類は全部AI任せに出来ていてかなり楽ができた（人による判定は関係者 各位めちゃ協力的でスーパースムーズに進んでウルトラありがたかった）

まとめ Data Sources Data Lake Data Warehouse Data Marts service project PostgreSQL MySQL Data Lake from knowledgework Data Mart for knowledgework PostgreSQL Replica Mart Model Parquet data project Data Lake from AWS data-mart project Data Warehouse by dbt Staging / Intermediate Model Data Mart for analytics BigLake Table Mart Model dbt Cloud Run 論理レイヤー クラウド インフラ

まとめ ナレッジワークでGoogle Cloud, AWSのサービスのデータ及びメタデータの統合の取り 組みについてお話しました 全体として一貫性のある形で扱えるようになっていて運用負荷も軽く済んでおり、具 合よく出来たなと思っています 参考になればこれ幸い

Appendix #1 ナレッジワークにおけるデータ基盤の構成 - 2025/09 アプリケーションDBのメタデータをデータ基盤に自動で伝播させる仕組みを構築 しました 如何にしてdbt-osmosisを自作CLIへ移行したか 今回の発表に関連する内容をzennで公開しているので、こちらも良ければどうぞ

• https://zenn.dev/knowledgework/articles/knowledgework-data-platform-20250905
• https://zenn.dev/knowledgework/articles/sync-metadata-to-data-platform-20251013
• https://zenn.dev/knowledgework/articles/20251213-replace-dbt-osmosis

Appendix #2 他にもこんな自動化・仕組み化・AI活用をやってます dbtのエラー・遅延モデルを収集してモニタリング kw_metaスキーマの二重管理問題の対処 dbt Orphan Table削除 Claude Code 活用 Lightdashのチャート作成をCoding Agentに委ねる などなど・・・ もし気になるトピックがあったら是非お話しましょう

ありがとうございました