Dataformのリポジトリを立ち上げるときにまずやること / dataform-day0-2026

2026年6月8日に開催された Dataform Meetup #2 の登壇資料です。

Transcript

1. Dataformのリポジトリを立ち上げるときに まずやること 品原 悠杜 (@snhrytdesu) Dataform Meetup #2 (2026-06-08)
2. 2 本日話すこと 直近 BigQuery x Dataform でデータ基盤をゼロから立ち上げる機会があった そのときに最初にやっておいてよかったことをご紹介 最初にやっておくとなおよしだが、後から取り入れても有効な話ばかりだと思いま す。誰かの参考になれば！ コストモニタリング用mart整備 エージェントハーネス CI/CD
3. 3 自己紹介 品原 悠杜 (@snhrytdesu) 日本に200人ぐらいしかいない名字 Dataform の呪縛に5年間囚われている人 フリーランス ex マイベスト ← アイデミー ← NTTCom
4. 4 Excuse 当たり前ですが）BigQuery x Dataform でデータ基盤を構築する前提 開発環境として Dataform CLI を使ったローカル主体の環境を想定 クラウド版の IDE を使って開発している方は？→ 今すぐ CLI に乗り換えましょう ハーネスの定義は諸説あるので、 「AIで開発するための足回りの話」ぐらいの心づ もりでお聞きいただけると幸いです m(_ _)m
5. コストモニタリング用mart整備
6. 6 どうせみんな BigQuery のコストは論点になる 組織によって優先度や重要度は様々あるが、いつか必ず、コストと真面目に向き合 わないといけない時がやってくる 特に、社内のデータ活用が一定進んでくると、スプレッドシートのデータコネクタ による野良クエリの発行が横行する
7. 7 なので、最初から全力でモニタリングの足場を整える INFORMATION_SCHMA.JOBS を使って、以下のような粒度で total_bytes_billed をモニタリン グしているチームは多いと思う しかし、これだけでは不十分なことが多い。最初から以下を BigQuery に連携しておきたい date x user_email date x referenced_tables query (topN) Cloud Audit Logs: スプシのデータコネクトによる課金がシートURL単位でモニタリングできるようにな る user_email から所属への変換用テーブル: 所属ごとに集約して利用傾向が追えるようになる ただし、このテーブルを最新化する運用には人事部門などの後ろ盾が必要。調整ファイト
8. 8 パイプラインイメージ
9. 9 tips1: INFORMATION_SCHEMA の日次スナップショット保管 コストが許すなら、 INFORMATION_SCHEMA の日次スナ ップショットをとっておくと便利。特 に以下はおすすめ JOBS TABLE_STORAGE 情報の宝庫 180日前までしか履歴が遡れないので、コ ストが許すなら永続化する デフォルトではその時点のデータのみで 履歴が追えない 履歴があるとストレージコストの増分試 算に便利 config { type: "incremental", schema: "staging", bigquery: { partitionBy: "date", clusterBy: ["user_email"], }, uniqueKey: ["job_id"], protected: true, } pre_operations { declare checkpoint_timestamp default( ${ when( incremental(), `select max(creation_time) from ${self()}`, `timestamp("2026-01-01 00:00:00 UTC")` ) } ) } select date(creation_time, "Asia/Tokyo") as date, * from `region-${dataform.projectConfig.defaultLocation}.INFORMATION_SCHEMA.JOBS` where creation_time > checkpoint_timestamp
10. 10 tips2: bytes→コスト変換（概算）UDFを作っておくと使いまわしが効きやすい config { type: "operations", schema: "udfs", hasOutput: true, tags: ["udfs"], } create or replace function ${self()}( byte_count int64, cost_category string ) returns float64 as ( case cost_category when "computing" then safe_divide(byte_count, pow(1024, 4)) * 6.25 when "active_logical_storage" then safe_divide(byte_count, pow(1024, 3)) * 0.000031507 * 24 when "longterm_logical_storage" then safe_divide(byte_count, pow(1024, 3)) * 0.000021918 * 24 when "active_physical_storage" then safe_divide(byte_count, pow(1024, 3)) * 0.000054795 * 24 when "longterm_physical_storage" then safe_divide(byte_count, pow(1024, 3)) * 0.000027397 * 24 else error(format("Unsupported cost category: %s", cost_category)) end ) options ( description = "バイト数とコストカテゴリからBigQuery利用コストの概算をUSDで返す。東京リージョンの公開単価を使用し、無料枠、契約割引、税、丸め、為替 換算は考慮しない。ストレージはGiB-hour単価を24倍した1日分" );
11. 2. エージェントハーネス
12. 12 bq query コマンドを直接叩かせない AI に自律してクエリを書かせようと思ったら、コードベースだけではなく、既存のテーブルの 中身も見て開発させたい → bq query ただし、ノーガードでクエリを叩かせると、BigQuery 側のコスト観点や、AI 側のトークン消 費観点で懸念がある make query のようにショートカットを定義する .bigqueryrc で最大サイズや出力フォーマットを固定してリポジトリ管理 デフォルトでは $HOME のファイルを見に行くので、向き先をリポジトリに強制するために make query = bq query --bigqueryrc .bigueryrc “SQL” のようにwrapする その上で、settings.json で Bash(bq query*) を deny しておく（Claude Code の場合）
13. 13 .bigqueryrc の例 `--format` で指定できるもの [global] --apilog=stdout # クエリ結果の出力形式を JSON に固定 --format=json --location=asia-northeast1 [query] --use_legacy_sql=false # 出力行数の upper --max_rows=100 # クエリサイズの upper --maximum_bytes_billed=100000000 画像出典: https://docs.cloud.google.com/bigquery/docs/reference/bq-cli-reference?hl=ja#global_flags
14. 14 テーブルメタデータの mart を作っておくとより便利 色々な INFORMATION_SCHEMA を join して、テーブル毎の指標を集約したワイドテーブルを Dataform でモデリングしておく make report テーブル名 := make query “select * from table_report where table_id = 'テーブル 名'” のように wrap しておくと、人間にとっても AI にとっても便利 レコード数 / ストレージサイズ freshness 直近 30 日の ジョブ実行回数 / クエリコスト / ジョブ実行ユーザー topN カラム description 充填率 推奨事項 ( INFORMATION_SCHEMA.RECOMMENDATIONS ) etc. make query の前にチェックを挟む エージェントスキル化して、特定テーブルの健全性レポートを HTML 出力 「 table_report の推奨事項があるテーブルを改善する PR 書いて」で
15. 3. CI/CD
16. 16 SQLFluff でコーディングスタイルを統一 .sqlfluff に SQL のコーディングスタイル を記述 pre-commit や GitHub Actions などで強制 適用する @hiracky16 さん作の sqlfluff-templater- dataform があるので是非！
17. 17 リネーム・削除済モデルの自動お掃除 リネームする前の古いテーブルが残りっぱな しで、社内から「更新止まってるみたいなん ですけど」と問い合わせが来た経験はあり ませんか？ 残念ながら、Dataform には、モデル側の変 更に追従して BigQuery 側のリソースを自動 でリネーム・削除してくれる仕組みがない 自作しましょう リネーム・削除を検知してPR内で予告をだ し、マージ後に BigQuery 側のリソース削除 を実施する Action →
18. 18 Dataform Cloud へのワークフロー設定自動反映 Dataform Cloud でワークフローを動かす場 合、ワークフローの設定はモデリングとは 別で管理する必要がある → tag 新設時のス ケジューラ設定漏れなどが起こりやすい 手動はブルシット。かといって、Terraform にワークフローの責務は持たせたくない JSON ファイル 1 つでクラウド側に設定を 自動反映する GitHub Actions を公開してい ます！（宣伝）
19. Conclusion
20. 20 まとめ Dataform のリポジトリを立ち上げる際にやってよかったことを紹介 コストモニタリング用mart整備 エージェントハーネス CI/CD INFORMATION_SCHEMA だけでは不十分になるので、Audit Log やユーザーメタデータも基盤に連携 して、最初からがっつり足場を整えておこう AI に bq query で好き勝手やらせない テーブルのメタデータ集約 mart があると便利 コーディングスタイルの統一 by SQLFLuff リネーム・削除済モデルの自動お掃除 Dataform Cloud へのワークフロー設定自動反映
21. 21 諸々取り入れたリポジトリテンプレートを公開しました 近日公開予定
22. ご清聴ありがとうございました @snhrytdesu