dbt民主化とLLMによる開発ブースト ~ AI Readyな分析サイクルを目指して ~

2025/07/03 に開催された Tokyo dbt Meetup #15 に登壇した際の登壇資料です

Transcript

1. ※本資料には弊社の秘密情報が含まれております。貴社限りとさせていただき、 SNS等への アップロードを含め、貴社の関係者以外の方に開示されることのないようお願い申し上げます。 Confidential dbt民主化とLLMによる開発ブースト ~ AI Readyな分析サイクルを目指して ~ 2025 / 7 / 3 Ubie株式会社 Shunya Yoshikawa
2. 2 自己紹介 Shunya Yoshikawa (@yosh_yumyum) Data Engineer @Ubie, Inc. • 2023/9よりData EngineerとしてUbieにjoin • Data Engineering, Data Privacy, 横断的なデータ 利活用推進をやっています。 • よく使う技術 ◦ BigQuery, dbt, Terraform, Python, Cursor, Claude Code
3. 3 Confidential Ubieについて 3
4. 会社概要 Hello, Healthy world. 世界80億人の健康寿命を延ばす挑戦 Vision 4 健康は、地域や文化、人種を問わず、全ての人にとって普遍的なテーマ。 Ubieは医療先 進国である日本で育んだプラットフォームを世界に広げ、地球上の 80億人の健康寿命を 延ばすことを使命としています。目指すのは、健康がだれにとっても空気や水のように当 たり前となる世界です。
5. 会社概要 テクノロジーで人々を適切な医療に案内する 「どうしてあの時病院に行かなかったのか」と重篤化して後悔する方、最悪の場合命を落と す方がいます。一方で多くの医療従事者は、早期に発見されていれば救えたはずの患者 の死を、無念の思いで見届けています。さらに世界には、医療へのアクセスが困難な地 域、医療資源が不足している国が数多く存在するのが現状です。私たちは医療先進国日 本発の企業としてテクノロジーで世界中の医療に貢献します。 Mission 5
6. 事業紹介 6 自分の症状を答えるだけで、 参考病名や近くの医療機関等 「受診の手がかり」が調べられます 医療現場で実際に使われ鍛えられた AIを、 生活者が適切な医療にかかる目安として開放しています (2020年提供開始 ) 無料で 誰でも いつでも ほぼ全ての症状で ＊ ＊99% (1.3万超)の症状に対応 生活者 医療機関 製薬企業 生活者向け事業 情報 アクセシビリティ 好事例2023 選出 総務省 症状検索エンジン「ユビー」ダウンロードリンク https://ubie.go.link?adj_t=1c2ifxv9
7. 事業紹介 7 問診業務効率化や認知向上など、患者さんとのコミュ ニケーション設計を通じ、診察の質向上を支援する医 療機関向けサービスです 医療機関向け事業 病院・クリニックそれぞれのニーズに合わせた 以下のような機能を提供・開発しています ユビーAI問診 ユビーリンク ユビー生成AI etc… 生活者 医療機関 製薬企業 導入数 1,800 施設超 https://intro.dr-ubie.com/ ユビーメディカルナビ サイト
8. 製薬企業が持つ、疾患・治療啓発につながる情報を生活 者・医療機関に提供することで、早期かつ適切な受診や、 診療業務の支援を行います。薬剤の適正処方を最大化 し、治療アウトカム向上に貢献することを目指しています。 8 事業紹介 製薬企業向け事業 生活者 医療機関 製薬企業 Ubieが保有する医療プラットフォーム を通じて、製薬企業と生活者・医療機関を つなぐサービスです ユビー for Pharma https://ph-ubie.com/
11. 11 • Ubieはデータの会社。 事業・プロダクトにおける仮説検証・インサイト発掘や製薬企業向けのレポーティン グなど幅広い場面で価値を生み出している。 • 患者の情報を適切に繋ぎ合わせ理解することで適切な医療に案内する、ときには N数の少ない病気 (希少疾患 )の患者を適切な医療に案内する、そのために 信頼性の高いデータが必須 • データ利活用推進と信頼性維持・向上が、 Ubieのプロダクト・プラットフォームそのものの価値向上に寄 与する。 Ubieにおけるデータの重要性について詳しくはこちら • Ubieのデータ信頼性とその向上の取り組み（ https://zenn.dev/ubie_dev/articles/5d57fa39ac7af1） Ubieでのデータ利活用とデータ分析基盤の位置付け
12. 12 Confidential 2. Develop: LLMの積極的な導入 目次 １．はじめにdbt, LLMの動向とこれからの Ubieデータ分析基盤 3．Plan: Data Contractを起点にした協業 4. Discovery / Analysis: コード管理による効用を最大化
13. 13 Confidential はじめに dbt, LLMの動向と これからのUbieデータ分析基盤 13
14. 14 最近のdbtとLLMの動向 (Ubieで使っているツールを中心に ) dbt Fusion engine on Bigquery の public beta https://www.getdbt.com/blog/dbt-fusion-engine-publi c-beta-bigquery 公式 dbt MCP server のリリース https://docs.getdbt.com/blog/introducing-dbt-mcp-server AI Coding Agentの発達(画像はClaude Code Action) https://github.com/anthropics/claude-code-action 革新的なツールの登場で 開発環境が激変 & 効率が飛躍的に向上している Lightdash AI agents の登場 https://docs.lightdash.com/guides/ai-agents
15. 15 これからの Ubieデータ分析基盤： ADLC全体のenabling ➢ dbt / LLMの進化でdbt開発が加速し、 データを知っていれば誰 でも透過的に開発できる状態 に近づいている ➢ 自動化・AIへの移譲は進んでもデータ分析の全体プロセスは変わ らないのではないか？ ➢ Ubieデータ分析基盤に求められる責務はデータパイプラインの構 築・運用という狭いプロセスではなく、 end-to-end の分析ライフサイクル (ADLC) のenablingへ ➢ ライフサイクル中の各プロセスをよく理解し、生成 AI含め 適切なhowを提供し、データ利活用推進する roleへchange The Analytics Development Lifecycle (ADLC) https://www.getdbt.com/resources/the-analytics-develop ment-lifecycle You are the best judge of how you are maximally effective. https://www.getdbt.com/resources/the-analytics-development-lifecycle より
16. 16 Confidential 2．Develop 16
17. 17 dbt Repository の開発規模推移： PR数 / PR作成者数 / 一人あたり PR数の推移
18. 18 dbt Repository の開発規模推移からわかること ➢ 2025/06時点では正社員約 240人、うちエンジニアが約 60人で、多くのメンバーが dbtを使った開発に関わっている エンジニアだけでなく、ビジネス職の人が SQLを書いたり dbtを使うこともある ➢ 生成AIの進化やDevin, Cursorなどツール導入だけでなく、 生成AIを前提とした開発プロセスの整備 (cursor rulesの整備 など) が開発数増加に寄与している ➢ 一方、分析基盤のメンバーは増えていない & dbtに詳しいAE/DAも本来のValueが発揮できる分析業務に betしている 開発規模を品質高く維持するために、 生成AI活用を前提とした開発プロセスの 再構築と効率化が必須
19. 19 ➢ 2024: GitHub CopilotやCursorを一部で試用 ➢ 2025/01: 全社的にCursorを導入、同時期にDevinも* この時期から継続して Cursor rulesも整備 thanks to okiyuki99 as Analytics Engineer ➢ 2025/06: Claude Code / Claude Code GitHub Action も 導入、エディタを開かない開発も普及中 生成AI活用に関する変遷 メンテされ続けるcursor rules 開発フローに応じた rules *CursorやDevinなどツール導入についてはこちら ： https://findy-code.io/media/articles/ai-career-ubie-250521
20. 20 Claude Code Action • 6月よりClaude Code Actionがリリースされ、 @claudeでClaudeを呼び出せるように • token / Vertex AI部分が共通化された社内 GitHub Actionsをdbt Repoでも利用している • issueからタスク依頼が可能になり、軽微な変更が楽に (Devinに近い体験 ) Claude Code Actionへの依頼の様子
21. 21 ➢ AIによるReviewも積極的に取り入れ、ナレッジの属人化と Reviewer負担を軽減 ➢ CoderabbitもCLAUDE.mdや.cursor/rulesなどを読んでくれるよう になり、AIによるCode Reviewは日々進歩 ref: https://docs.coderabbit.ai/integrations/knowledge-base/ ➢ Auto Approve も導入しているが、重要な変更は人間が Reviewする ようCode Ownersを運用 ➢ column descriptionなどメタデータも生成したくなってしまうが ルールベースで伝播させる (dbt-osmosis, dbt-fusionに期待) 開発補助：柔軟な Reviewと自動修正の導入 Claude Code GitHub ActionによるCustom Reviewのdemo 目的に応じ、自動生成とReviewを使い分けることも
22. 22 今後：End-to-Endなデータパイプライン開発を透過的に ➢ アプリケーション DBやログからデータが生成され、分析できるように なるまでのデータパイプライン構築には多くの Stepが必要 ◦ カラム追加など軽微な場合、 GitHub PRで3本程度 ◦ 新設DBからの連携の場合、 PR10本以上になることも ➢ データエンジニア・アナリティクスエンジニアのリソースは限られてお り、増え続けるデータ分析需要に対して逼迫しがち ➢ メタデータがデータ分析で重要なように、データパイプライン構築で はドキュメントが重要 ➢ 依頼は人 (Engineer)ではなく生成 AIに頼むようになり、 AIがアクセスできない暗黙知や、ガードレール (validate, test)の不 在による品質低下 がボトルネックに データ分析基盤全体図 : プライバシー・セキュリティを dbt repositoryでのレイヤリング
23. 23 • 生成AIを前提とする開発では (でなくても )ドキュメントがとにかく重要 • ドキュメントも生成 AIで作りたいが、人間にも AIにも優しいように体系化したい → Diátaxis (ディアタクシス) フレームワークで構造化 explanation dbtなどの基本的用語や社内ルールの説明。他のドキュメントや cursor ruleの@で呼ぶ how-to-guides 特定の開発ステップに対応。 @で呼び出し可能な具体のルールで、これを元に rulesを作成 reference 詳細な仕様や技術的な内容。レイヤリング規則など横断的な知識をまとめたもの tutorial 学習用のリソースで、基本的に人が概観をつかむ用 ドキュメントの生成と構造化
24. 24 • dbt開発に閉じず、データ分析や Google Cloud側の構築など横断的なものはホスティング • GitHub RepositoryではAI Agentに読ませたいドキュメントを置く ドキュメントの置き場所 社内開発ドキュメントポータル Botを通じ検索できるように
25. 25 Confidential 3．ADLC: Plan
26. 26 データに関わる横断的な協業 (Plan) Engineer, Analystが平行で作業するだけでなく 同期的に論点や影響の擦り合わせを行い回避できる問題も多い Data Value Chainと称して定期的 & 必要に応じ横断的な連携を実施 Analyst(AE, DA) • 可視化・KPI定義・インサイト抽出 • データマート・データウェアハウスの構築 • データ仕様を元にクエリ作成・分析 • (mart付近の) データテストのハンドリング Engineer(SWE, DE) • プロダクト開発・データの蓄積 • データパイプライン構築 • column description など仕様(メタデータ )の入力 • (stagingまでの) データテストのハンドリング EngineerとAnalystの大まかな役割分担、EngineerがAnalyst的なことをする場合もその逆もあり得る(Hats, not badges)
27. 27 Data Contractの策定 ➢ Data Value Chainでは議論の過程とその結果定義されたデータの仕様 / SLA / ユースケースをADCのように残 している ➢ 特に、Engineer→AnalystへOwnershipが移るようなdbt modelの実装時はGitHub PRで双方が議論し Data Contractを定めるように開発プロセスを改めている ◦ この策定過程をデータコントラクトストーミング (仮)と呼んでいる Data Contract 策定の様子 staging (interface) intermediate (data component) mart (dm,dwh) Owner: Engineer Owner: Engineer Owner: Analyst レイヤリングとData Ownerの変遷, カッコ内はUbieでのレイヤー呼称. data componetでSupplyer: Engineer, Consumer: Analyst の関係ができる
28. 28 ➢ Planとして全社標準として根付かせつつ、 Data ContractおよびPlanの過程で決まった仕様を後続のプロセスにシームレスに接続する ことが重要 Develop: ➡ 生成AIがアクセスできる場所に配置し、 Reviewやドキュメントのscaffoldで反映できるように ➡ Custom Schema Validationで、Data Contract違反（テスト不足、metadata欠損)を気づけるように Discover: ➡ Data Contractおよび依存する成果物を生成 AIで検索できるように 　 (dbt MCP server Discovery Metadata APIなど) Data Contractのこれから https://schemas.getdbt.com/ dbt JSON Schemaが公開されており自分でValidationも組める
29. 29 Confidential 4. Discovery / Analysis 29
30. 30 ➢ 社内生成内 AIエージェント : Dev GeniusやMCP toolからdbt repoを取得し、用途に応じた Discovery体験を構築 ◦ Lightdash APIから取得した dbt exposureから、ダッシュボード検索 ◦ Elementary Artifact からテーブル検索 ◦ metadataを元にデータマート検索と SQL生成 ➢ HTML形式のReportやJupyter notebookで アドホックな分析結果を共有するケースも Discovery / Analysis 詳しくは：Ubieの生成AI×データ利活用の現在地 https://note.com/okiyuki/n/na526aeabd4b6
31. 31 これからの Discovery ➢ 社内AIエージェント”Dev Genius”でユースケースに応じたDiscoveryができるようになった ➢ dbt Cloud Discovery API や Lightdash AI Agent などツールの発展でより楽になるかもしれない ➢ ただ、Garbage in Garbage out の法則は変わらない。DB側でのデータモデリングに改善の余地を抱えたまま、 データマートで吸収してしまう例も増えてきた。 LLM & Human Friendly なモデリングを 鍵になりそうなもの ◦ PlanやDevelopで適切なモデリング、メタデータ入力、カラム命名を堅実にやる ◦ Audit log、INFORMATION_SCHEMAを活用したtableユースケース分析 (Observe) ◦ コンテキストの集約(データ量が多いとハルシネーションが起きやすい )
32. 32 dbt & LLMの普及で見えたこと ➢ 改めてdbtによるコード管理の偉大さを実感。 AIがアクセスできる情報が増え、データ分析の効率化・民 主化に大きく寄与している ➢ ADLCの多くのプロセス (Develop / Analysis / Discovery) を速度が上がっている ➢ 一方、他のプロセスが速度・質の面でボトルネックに感じる 場面も増えてきた ◦ Planでのモデリング・影響範囲補足への改善 ◦ Observeでの利活用状況監視不足 ◦ Deployにおける CI/CDの速度 (dbt-fusionに期待) ➢ 循環する ADLCにおいて律速段階となり得るプロセスを都度特定し改善していく必要がある
33. 33 これからの Ubieデータ分析基盤 ➢ 一つのプロセスに閉じず、 フルサイクルエンジニアリング の考えを持ってデータ分析の質・速度を底上げし ていかなければならない 直近は、以下を重点的に ◦ Data Observability ◦ CI/CDでの dbt unit_test の広域展開 (dbt-fusionによる高速化に期待 ) ◦ validation(e.g. dbt-checkpoint, dbt_project_evaluator)の活用 ➢ Enablingやドキュメント・メタデータの蓄積はツールが変わっても不変 ➢ dbt MCP tool, AI Agent への投資は変わらず積極的に
34. 34 Confidential おわり ご清聴ありがとうございました！ 34