Ubie BI×生成AI スペースレポート#1〜ダッシュボード開発・データパイプライン開発の最新事例〜
イントロダクション
登壇者
togachi（とがわ）
Ubieのデータアナリスト。本イベントの進行・司会を担当。
okiyuki（おきゆき）
Ubieでデータアナリスト兼アナリティクスエンジニアを担当。ダッシュボードや分析基盤の整備を推進。
matsu-ryu（まつりゅー）
前職からヘルスケア関連のデータ分析に携わる。データを使った新しいアプローチに挑戦中。
ktrru（むらなか）
2024年5月にUbieにジョイン。アナリティクスエンジニア・データアナリストを兼任し、パイプライン開発を中心に活躍。
開催背景
今回のスペースでは、Ubie BIメンバー3名の事例を中心に「ダッシュボード開発」「dbtモデル開発」「データパイプライン開発」という3つの切り口で、実際の活用の様子やそこでの学びを共有しました。
当日のスペースの録音は以下をご覧ください↓
第1セッション：ダッシュボード開発における生成AI活用
スピーカー
okiyuki（おきゆき）
セッション概要
明日の12時からスペースで社内のダッシュボード開発とその分析に生成AIを使ってる話を紹介します。
— OKIYUKI (@okiyuki99) January 15, 2025
添付はデジタル庁のダッシュボードデザインの実践ガイドブックをプロンプトに与えてダッシュボードを改良するイメージです。他のメンバーから複数の事例も話されるのでお気軽にぜひ！#BI生成AI #Ubie https://t.co/2OnplyyXKI pic.twitter.com/nvlSdNdPes
きっかけ
Ubie社内では内製の生成AIツール「Dev Genius」（ChatGPTなどのモデルをAPI経由で業務活用するプラットフォーム）があり、安全かつ簡単に色々なモデル（GPT-4、Claudeなど）を試せる環境が整っています。
普段自分も使っている中で「BIのダッシュボード開発でも活かせそうだ！」という着想から、ダッシュボード開発・分析・運用フェーズで積極的に取り入れ始めました。
活用内容
ダッシュボード開発での生成AIの応用
ダッシュボードの仕様は利用者・プロダクトオーナーとのすり合わせから始まるが、最終的に「見やすく、標準的な設計」に整えるのは意外と難しいです。
デジタル庁が公表している「ダッシュボードデザインの実践ガイドブック」などをDev Geniusのプロンプトに組み込んでいます。それにダッシュボードのスクリーンショットをインプットにすることで、ガイドラインにそってチェックしてもらい、提案を生成AIから受け取るようにしています。
プロンプトの例は以下です。長文を扱うので、Gemini 1.5 Pro を利用しています。
あなたはデータ分析のプロフェッショナルで、以下のダッシュボードデザインの実践ガイドブックを作成しました。このダッシュボードデザインの実績ガイドブックに基づき、改善点および良い点を提示してください。
改善点および良い点を提示するときは
* どの章・項目についてのことかを明示的に書いてください
* できるだけ具体的に改善点および良い点を指示してください
===
ダッシュボードデザインの実践ガイドブック
# 目次
1. はじめに
- 1.1 ダッシュボードとは
- 1.2 ガイドブックの対象範囲
- 1.3 ダッシュボード作成の流れ
2. 要件の整理
- 2.1 目的を定義する
- 2.2制約条件を整理する
- 2.3 要件定義ワークシート
3. プロトタイピング
- 3.1 プロトタイピングのプロセス
- 3.2 載せるべき情報を整理する
- 3.3 プロトタイプを作る
- 3.4 レイアウトの考え方
- 3.5 要望を元に改善する
4. 情報表現のポイント
- 4.1 グラフとは4.2 グラフの種類と選び方
- 4.3 カラーパレット
- 4.4 グラフ設計の原則
- 4.5 Do’s Dont’s
5. 実装
- 5.1 チャート・コンポーネントライブラリ（ベータ版）
- 5.2 レイアウトグリッド
- 5.3 操作マニュアル
- 5.4 チェックリスト
- 5.5 アクセシビリティの対応
6. おわりに
... (ガイドブックの内容が続く）ダッシュボード上のデータ分析の補助
ダッシュボードのスクリーンショットをインプットにすることで、データ分析してもらうことを始めています。
「ここの数値が下がっているのは○○が原因の可能性がある」など、人間の視点では見落としがちな観点を提案してくれるケースもできることを確認しています。ただ、ダッシュボード上では表現できてないコンテキスト（例: 数値が減少した理由となった施策の内容など）などを適切にインプットしないと分析が浅くなるので今後工夫は必要です。
得られた効果と今後の展望
ダッシュボード開発時には、盲点がなく品質の高いダッシュボードを作りやすくなったと感じています。また、自身の「ダッシュボード設計のクセ」を客観的に振り返るきっかけになります。
「とりあえず数値をたくさん並べるだけ」ではなく、重要な指標の強調や構造化などが促される。
チーム内でのレビュー時間が減り、初期段階から一定水準の品質を保てるようになった。
今は、ダッシュボードの開発の半自動化を洗練させていきたい。将来的には、ダッシュボードの開発だけでなく、開発〜分析〜自動改善提案をほぼ自動化する仕組みを目指していきたい。
社内BIツールのLightdashにはChart as Code としてダッシュボードやグラフをコード管理する仕組みがある。
コードベースであれば、生成AIは画面の「どこに」「どんな指標」があるかを把握しやすいため、ダッシュボード開発を自動で行いやすい。
コード生成〜画面作成のパイプラインを構築し、人間は最終チェックと意思決定に集中する体制へ進化させていきたい。
第2セッション：開発者向け生成AI活用Tips
スピーカー
matsu-ryu（まつりゅー）
セッション概要
dbtモデルをCline, Cursorで作成する話
matsu-ryu氏が取り組んでいるのは、「dbtモデル開発のエージェント化」 です。ClineやCursorなどの新しいツールは、以下のような機能を持っています。
Cline
AIエージェントがコーディングからファイル操作、ターミナルコマンドの実行まで自律的に進めるClineは、プロンプトを与えるだけで、「ファイルを開きます」「SQLファイルを作成します」といった手順を自動で提示し、必要に応じて実行許可を求めながら作業を進めます。
SQLの仕様やスキーマ情報を細かく指示することで、一連のdbtモデル開発をほぼ自動化例えば「2つのテーブルを結合して、このカラムを抽出し、schema.ymlとドキュメントも生成してほしい」という要件をプロンプト化すれば、Clineが自動的にSQLファイル、schema.yml、ドキュメントなどを用意してくれます。
Cursor
LLM対話インタフェースつきエディタCursorはエディタ上で生成AIと対話しながら部分的にコードを修正・補完することができるツールです。
細かい修正やリファクタリング指示が容易例えば、schema.ymlのdescriptionを補足したり、テスト定義を削除したりといった修正を、対話形式でサッと行うことができます。
1. 具体的な開発フロー
ここでは、Clineを活用してdbtモデルを作成する、ざっくりとした流れを紹介します。
1.1 モデル作成用のプロンプトを準備
参考となるdbtモデル・schemaファイルの明示
すでに存在する類似のモデルがあれば、そのSQLやschema.ymlをClineに「読ませる」よう指示します。
モデルを格納するディレクトリ構成、命名規則、依存関係などもプロンプトで言及しておくとスムーズです。
結合方法や抽出項目など仕様を詳細に記述
どのテーブルを結合し、どのようにフィルタし、どのカラムを最終出力するかなど、可能な限り詳しく書きます。
Clineはビジネスドメイン固有の知識がないため、プロンプトに記載しない部分は推測に頼ることになります。
※ プロンプトの例
dbtモデルを作成してください
参考モデル
models/rwd_medicine
以下の、sqlファイル、schema.yml,doc.mdを読み込んで、参考にしてください。
以下のファイルを参考にしてくだｄさい。
格納場所
models/session_test
ファイル名
sql:session_test.sql
ドキュメント:docx
sqlの仕様
- import
- session_summary
- rwd_survey_master
- logic_joined_data
- A: session_summaryとrwd_survey_masterを結合
- session_summary.disease_idsを
unnestしてcross join
- 結合条件
- import_rwd_survey_masterのdisease_idとunnestしたdisease_idを結合
- final
- logicの２つのCTEを結合
- 最終的な項目
- rwd_survey_master.survey_code
- session_summary.data_key
- session_summary.start_time_jst
- session_summary.symptom_name
1.2 Clineが自動生成 → 人間が確認
Clineが手順を示しながらファイルを作成・編集
「ファイルをリードします」「SQLファイルを新規作成します」など、Clineが自律的に進めていきます。
途中で「OK/NG」を都度指示するイメージで、最終的な出力をレビューしながら調整します。
単純なモデルならほぼ正解が出力される
例えば「2テーブルを結合し、いくつかのカラムを抽出するだけ」のモデルであれば、簡単に80点以上のコードが得られます。
schema.ymlやドキュメントも同時に生成してくれるため、導入時の手間が大幅に削減されます。
1.3 細かい修正はCursorで対話的に
schema.ymlの不要なテストの削除、descriptionの補足
Clineが出力したschema.ymlには、時々不要なテストや不十分なdescriptionが混ざることがあります。
そこでCursorを使い、エディタ上で「ここのカラム説明を追加して」「いらないテストは消して」と対話的に指示すると、瞬時に修正が反映されます。
dbt-osmosisとの組み合わせも有効
dbtが公式に提供するツール「dbt-osmosis」を併用すると、schema.ymlのdescriptionやテスト定義を一元管理・自動生成できます。
AIエージェントが苦手な部分を他のツールで補いつつ、Cursorで最終調整する流れがスムーズです。
2. 得られた知見
2.1 プロンプト次第で成果が変わる
細かく設計情報を盛り込むほど、Clineは正確に作業を進めてくれる例えば結合条件や主キー・外部キー情報、出力したいカラム名などを詳細に書き込むことで、修正要件が減らせます。
逆に、抽象的な指示しか与えないと誤りが多くなるビジネスドメインに強く依存するSQLやテーブル構造の場合、とくにドメイン知識の不足が顕在化します。
2.2 「80点のコードをAIに任せる」使い方がベストプラクティス
現時点では、AIが生成したコードをそのまま本番投入できるケースはまだ少ないですが、80点のたたき台を一瞬で作ってもらえるのは大きなメリットです。
人間がレビューし、ビジネスロジックの微調整を施すのが理想的なワークフローだと感じました。
2.3 MCPなどの拡張機能を活用すればさらに強力に
Clineには「MCP」という拡張機能があり、外部ツールやデータサンプルと連携しながらプロンプトを動的に生成することが可能です。
例えば、実際のスキーマ定義やテーブルの一部データを参照したうえでSQLを組み立てさせる、といった高度なことができるようになれば、より複雑なdbtモデル開発にも対応できる余地があります。
まとめ
ClineとCursorを使うことで、dbtモデルの開発効率を大幅に上げられる可能性を感じています。特に以下のポイントが印象的でした。
ファイル生成・編集作業の多くが半自動化
dbtモデル構成やSQL作成、schema.ymlやドキュメント生成など、煩雑な作業が一気にスピードアップ。
プロンプトにビジネスドメインの知識を詰め込む必要がある
AIエージェントを活かすために、事前の仕様整理とプロンプト設計が重要。
「80点のアウトプット→人間が補完」の流れが最適
AIの得意分野は「ある程度決まった形式でのコード生成」。最後の仕上げや現場レベルのロジック調整は、人間が行うのが現実的。
今後、MCPなどの拡張機能によってClineがさらに賢くなると、dbtモデル開発の多くのステップがAIによって補完されるでしょう。その結果、私たちはビジネスドメインに根ざした分析や新たなロジック検討にリソースを集中できるようになるはずです。
第3セッション：データパイプライン開発をLLMで工数圧縮した話
スピーカー
ktrru（むらなか）
セッション概要
データパイプタイン開発にLLM使った事例
— むらなか Ubie (@ktrru) January 16, 2025
1. JIRA、Slackログなどから仕様書を作らせる
2. 編集箇所をコピペして実装方針を立てさせる->PR作成
3. 仕様書とコードの一致、仕様書とデータの一致を確かめる
ポイントは「仕様と実装の分離」と「編集箇所が少ないアーキテクチャ」と思った#BI生成AI #Ubie pic.twitter.com/Mh8FQkPEum
「チケット→PRまで30分で完了」を実現
Jiraチケットが立ったタイミングから、自分が開発に着手し、セルフレビューを終えてPRを出すまでを通常数時間かかるところを30分以内で完了させることに成功しました。
具体的には下記のアプローチを取っています。
要件定義書の自動生成
SlackログやExcelにまとまった仕様を一度LLMに集約させ、要件定義書を半自動で生成。
LLMに「正しいコンテキスト」を与えることで、仕様と実装のブレを減らす。
編集対象コードの抽出＆LLMでコード生成
dbtモデルなど、編集すべきSQLファイルをLLMに丸ごと渡し、今回の変更仕様に沿った実装方針を提案してもらう。
内容をチェックしつつ、問題なければプルリクへ反映。
LLMを活用したセルフレビュー
「仕様との不整合」「明らかなハードコードやバグ」がないかを、再度LLMに確認させる。
100%完璧ではないが、見逃しを減らすのに有効。
成果とチームへの波及
社歴の浅いメンバーでも最速レベルのスピードで修正PRが出せるようになり、個人の習熟度差を埋める効果が期待できます。
BIチームでは週1回、各メンバーが「生成AI活用事例」を共有する場を設けており、このような体験談を他メンバーも即実践→技術浸透が進んでいます。
今後の展望
業務プロセス自体を最適化
せっかくLLMを使うなら、仕様検討〜実装〜レビューまでがスムーズに情報連携する仕組みを作るために、ビジネスプロセスもAIネイティブに変えていきたいです。タスクの自動連結
「チケットが立ったらLLMが自動で差分コードを提案する」レベルまで進められれば、さらなる爆速化が期待できます。
クロージング
本イベントでは、
ダッシュボード開発・分析・維持運用への生成AI活用（okiyuki）
dbtモデル開発の自動化に向けたエージェント活用（matsu-ryu）
データパイプライン改修効率化事例（ktrru / むらなか）
という3つの事例を通じて、BI領域×生成AI の最新事例やノウハウを共有しました。それぞれのセッションで共通していたポイントは、
「80点を自動生成→人間が20点を補う」使い方が現状最も実務に合っている
ドメイン知識の注入（プロンプトに参考情報をしっかり示す）が重要
プロセスごとに得られるインサイトや学びを、チーム全体で週1回以上の共有を行い、スピード感を持って知見を拡散する
という点です。
今後の展開
第二回の開催も企画中！
「BIでの活用をもっと深掘りする」「他社事例とコラボする」など、可能性が広がっています。
「こんな話を聞いてみたい」「一緒に勉強会・イベントをやりたい」などあれば、「#BI生成AI #Ubie 」 のハッシュタグでSNS投稿や、気軽にご連絡いただけると嬉しいです。
最後に、本イベントに参加いただいた皆さま、ハッシュタグで盛り上げていただいた皆さまに心より感謝申し上げます。UbieのBIチームはこれからも「生成AIとBIの接点」を探りつつ、新しいナレッジやプロダクト開発に挑戦していきます。ご興味あれば、ぜひお気軽にお声かけください！
おわりに
「ちょっとでも業務の参考になった」「おもしろかった」という方は、ぜひTwitter(X)などで #BI生成AI #Ubie をつけて感想をポストお願いします！
今後も第2回開催やコラボイベントを検討しています。リクエストや質問など、いつでもお待ちしています。ご覧いただき、ありがとうございました！
Ubieではデータ関連職種の採用を強化しております！興味を持った方はぜひご応募お待ちしております。
まず話を聞いてみたい場合はカジュアル面談もぜひ