データアナリストが使うと便利な生成AIプロンプト事例
こんにちは。Ubieでアナリティクスエンジニア/データアナリストをやっているむらなかです。
2024年5月に入社し、2ヶ月半の育休を挟んで10月に復帰しました。
医療ドメインは想像以上に奥深く、プロダクトの幅広さやデータの複雑性も相まって、毎日が新たな学びと挑戦の連続です。入社して間もない私にとって、新しい概念や膨大な情報を整理する作業は、大きな認知負荷となりがちでした。
Ubieでは全社的に生成AIの活用に力を入れており、BIチームでも互いの生成AI活用事例を共有しながら生産性向上を図っています。生成AIをうまく使うことで、前述の認知負荷も軽減できそうだと感じていて、実際、プロンプトの工夫次第でSQLやデータモデルの理解、分析要件整理など、日常的な業務をスムーズに進められるようになりました。
私のチームではスクラムを採用し、story pointを振ってベロシティを計測しているのですが、私の生産性は2ヶ月前の10月に比べて約25% 上がっています。（体感として1年後は2倍以上にはなる気がします）
今回は、UbieのBIチームが実際に活用している「データアナリストにとって便利なプロンプト」事例をいくつか紹介します。まだ蓄積途上のナレッジですが、同じような課題に直面する方々にとって、少しでも参考になれば幸いです。
はじめに
本記事では、データ分析や基盤構築といった業務プロセスを「仕様把握・業務理解」「要件定義・仕様策定」「分析・実装」「レビュー」の4つのフェーズに分解し、それぞれの段階で有用なLLMプロンプト事例を紹介していきます。
本記事内で紹介するプロンプトは、Copilot、dbt、BigQuery、Lightdash、Looker Studio、Notion、Slackと組み合わせた利用を前提としています。弊社では内製の生成AIツールを活用しています。（*本記事の内容はChatGPTなどの公式を利用してもできると思います）
社内用ChatGPTツール
内製ツールが気になる方はこちら！めちゃくちゃ使い倒してます！
*実務で機密データをインプットする際は、モデルへの学習利用を防ぐ設定など、セキュリティ・プライバシー対策をお忘れないようにお願いします。
システムプロンプト
はじめに私がよく使うシステムプロンプトを紹介します。
私はUbie株式会社の製薬事業向けのデータパイプライン開発やデータ分析をしているアナリティクスエンジニアです。
<Ubieの製薬事業概要>
ちなみに<Ubieの製薬事業概要>はGensparkなどで生成しています
Gensparkでの検索イメージ
事業ドメイン知識が必要な業務には、このプロンプトを冒頭に付与します。そうすると、事業に合わせた具体例などを生成してくれるので便利です。社内資料を入れるなら、初めての人でもわかりやすいオンボーディング資料などを抜粋すると良いと思います。
仕様把握・業務理解
このフェーズでは、膨大な情報や複雑な構造を理解する必要があり、認知負荷が高くなりがちです。ここでは、生成AIを活用して、こうした初期の情報整理やインプット作業を効率化するプロンプト事例を紹介します。
テーブルの仕様把握
データウェアハウスやデータマートは、多くのカラム、メタデータ、複雑なSQLロジックがあることも少なくないと思います。ここで、model（SQL）とyml（メタデータ定義ファイル）をまとめてモデルへ投入することで、テーブルのユースケースがわかったり、分析方向性をつかみやすくなります。
以下は、当社のデータマートを定義するSQLモデルとymlファイルです。このデータマートの主な分析ユースケースと、利用可能なメトリクス・ディメンションを教えてください。
[model]
<実際のSQLコード>
[yml]
<ymlファイル内容>
最近の生成AIの特長である大きなコンテキストウィンドウを存分に活かしてます。modelとymlファイルをまとめてコンテキストとして与えることで、人間では気が滅入るようなデータからユースケースを逆算する作業を代替してくれます。
ついでに同じスレッドでSQLを生成させると良いでしょう。
また、下記のようなファネル分析（MetricsAをCVとする週次集計）を行うためのクエリ例も示してください。
[SQLガイド]
ちなみに弊社のSQLのガイドは以下に似たものを使っています。
テーブルを修正したい場合はリネージを可視化しましょう。全体の処理が見えて冗長な結合などに気が付きやすくなります。mermaidで可視化すればNotionで見れます。
mermaidでリネージを可視化してください。
一度に多くの指示を与えるのではなく、ユースケースの説明、SQLの指示、リネージの可視化を分けたほうが期待する答えが返ってきやすいです。そうしないと、出力制限がかかって、間違った回答や浅い内容になってしまうことが多いです。
ダッシュボード提案
データ依頼があった際、せっかくカスタムクエリを書いたのに、すでにダッシュボードがあったとわかったら悲しいですよね。生成AIに目的に合ったダッシュボードを提案させることで、その無駄を省くことができます。
・あなたはA事業への営業活動に役にたつデータに詳しいBIエンジニアです。
・ユーザーからデータ抽出依頼を受けたときにその目的を達成できるダッシュボードのurlを出力してください。
・ユーザーには複数のダッシュボードのurlを提案しても構いません。目的を達成できる可能性が高い順に複数urlを提示してください。
・提案するurlについては、ダッシュボードの説明をしてください。
[ダッシュボードに関するデータ]
<ページタイトル, できること, URL, 説明の表データ>
[依頼内容]
<分析要件の記載>
注意としてダッシュボードのリストを事前に作っておく必要があります。それも生成AIを活用しましょう。今は個人用で使っていますが、網羅性が上がればビジネスチームへの展開なども検討しています。
複数のURLの候補を出すことで、欲しい回答に辿り着く可能性が上がります。
将来的には要件に合わせて動的にURLを生成するところまでにいきたいです。
ビジネス要件の理解
Slackログやパワーポイント資料など、ビジネスサイドの情報は業務を進める上では重要ですが、必ずしもエンジニア視点で整理されていません。生成AIで重要な前提条件や関心事項を抜き出し、なぜそれが重要かまで示してもらうことで、効果的な情報インプットが可能です。
私はA事業のBIエンジニアです。
以下は、事業部から共有されたパワーポイント資料とSlackログへのリンクです。これらから読み取れる主要なビジネス要件や、理解しておくべき前提・関心事項を箇条書きで整理してください。なぜその前提が重要なのかも教えてください。
<資料の添付やSlackログの抜粋>
自分の職種を伝えることで、漫然と共有を受けるよりも何を行動すればいいかという思考を促し、当事者意識を持って情報をインプットできます。根拠を示させるのも良かったです。
ペアプロ & 業務手順書作成
ペアプロのMTGなど、実際の業務手順を収録した動画・リアルタイムテキストログから、業務手順書やマニュアルを生成できます。
以下は、先ほどのペアプロセッションの文字起こしです。
この手順をもとに業務手順書を作成してください。手順ごとに必要ツールや注意点も明記してください。
<文字起こしのテキスト>
実際には、手順を修正したり、使った資料をドキュメントに貼ったりする作業があります。
10分で業務手順をまとめることができて、同じ作業をするときに迷いなく進めることができます。
要件定義・仕様策定
要件定義や仕様書作成は、ついついサボって頭の中でやろうとして、迷子になりがちですが、生成AIを使えばスムーズに進められます。JIRAチケット作成や仕様書ブラッシュアップ、モデル修正箇所の洗い出しまで、明瞭化と効率化が可能です。
JIRAチケットの内容作成
プロダクトバックログアイテムにできるようなものがあったとき、チケットにするのって少し気後れしますよね。タイトルだけあって、内容が空だとスクラムマスターに怒られるし。そんなときはこんなプロンプトです。
JIRAチケットの本体部分（背景、受け入れ基準、やりそうなこと、やらないこと）を整理して記載してください。
[JIRAチケットタイトル]
"Xのパイプラインのweek_startのタイムゾーンをJSTに統一する"
[議論ログ]
<Slack抜粋>
ちなみに弊社ではSlackにリアクションをつければJIRAのチケットの内容を作ってて教えてくれるワークフローがあるので、それを使っています。
仕様書の作成
JIRAチケットやSlackログ、Notionのメモをまとめて与えれば、要件定義書の再構成も簡単です。
以下は、要件定義書のドラフトと、その背景情報です。これらをもとに、要件定義書をより明確な記述に修正して、実装者が作業可能な仕様書を作成してください。前提条件、対象範囲、利用データソース、期待する出力フォーマットなど、欠けている情報を補完してください。
[要件定義書ドラフト]
<現行の要件定義書案, JIRAチケット記載内容のイメージ>
[関連情報]
<Slackログ>
<Notionページ>
修正箇所の特定
仕様が固まったら、同じスレッドで既存モデルを投入して「どこをどう直すか」を提案してもらいましょう。
仕様に合わせて修正すべき箇所（カラム名変更、フィルタ条件追加など）を特定してください。具体的な修正内容の提案してください。
[dbtモデル1]
<SQLコード>
[dbtモデル2]
<SQLコード>
場合によっては、そのままPR（プルリクエスト）としてあげられる品質のものもあります。
要件や仕様を明瞭化するメリットは、自分の頭が整理されるのみならず、適切なインプットを与えることで実装方針まで示してくれます。
さらに後述しますが、レビューまでも同じスレッドでできます。
私は従来は頭の中で要件や仕様を考えて仕事をするタイプでしたが、生成AIの活用メリットに気づいて以来、明文化と段階的な整理を心がけるようになりました。
今はJIRAのチケットに対して一つ生成AIツールのセッションを作って、そのセッションでいろんな仕事を進めるようにしています。
分析・実装
このフェーズでは、実際の分析作業や可視化、モデル開発といった「手を動かす」タスクが中心になります。従来は、クエリ修正やメタデータ整備、差分分析などに多くの時間を割いていたかもしれません。しかし、生成AIを活用することで、面倒な下準備や雑な試行錯誤が簡単にできることがあります。
メタデータの生成
dbtなどのツールを用いてデータ基盤を整備する場合、メタデータ（descriptionやschema.ymlなど）の整備は欠かせません。通常は手作業で書く必要がありますが、生成AIにサンプルデータやクエリを与えれば、モデルやカラムのdescriptionを自動生成してくれます。
コードをコピーする
以下は、dbtモデルで利用しているテーブルのサンプルデータと現行のSQLクエリです。
このテーブルに対応するschema.ymlファイルの雛形を作成してください。
descriptionや各カラムの意味をわかりやすく記述し、後続の分析者が利用しやすいメタデータを提示してください。
[サンプルデータ(csv)]
<CSVの抜粋>
[SQLクエリ]
<実際のSQLコード>
こうすることで、「わざわざdocsを読み返して、一からdescriptionを書く手間」が省け、メンテナンス性や可読性を高められます。
クエリの差分分析
「Aのダッシュボードと自分が出した数字が合わない」という状況は、データ分析をしているとよく発生します。差分分析は、単にクエリをもう一度書くよりも面倒なことが多いですが、生成AIを使うことで比較ポイントを迅速に洗い出せます。
以下は自分が作成したクエリとAダッシュボードで使用されているクエリです。
両者の数字が一致しない原因となりそうな条件や集計方法の違いを特定し、その修正案を示してください。
[自作クエリ]
<SQLコード>
[Aダッシュボードで使用されるクエリ]
<SQLコード>
生成AIはクエリ同士を比較して条件差異、JOINの違い、フィルタリングの有無などを列挙し、修正策を提案します。これによって、手動でクエリを読み込んで目視比較する作業を大幅に軽減できます。
キャプチャから分析
ダッシュボードのスクリーンショットやチャートキャプチャを生成AIに与えると、その可視化が何を示しているか、どういったインサイトが得られそうかをモデルが説明してくれます。まだ精度面で課題はありますが、初期的なインサイト探索には有効です。
以下は、当社ダッシュボードのチャートのスクリーンショットです。
このチャートが示す傾向や特徴、考えられるビジネス上の示唆を箇条書きで整理してください。
<チャートのキャプチャ画像>
モニタリングのような定形的な分析は、Slackに日次で連携してダッシュボードのチャートを示唆付きで出すなどの使い方があります。
CSVから分析
ある程度小規模なデータセット（1万行程度までのイメージです）であれば、CSVをそのまま投入して簡易的なEDA（Exploratory Data Analysis）を実行することが可能です。
以下は、顧客データを含むCSVファイルの一部抜粋です。
カラムを見てさまざまな仮説を立てて、分析をしてください。
その思考過程は明示してください。
[CSVデータ]
<CSVの抜粋>
これにより、分析者は素早くデータの傾向を把握し、本格的なモデル開発や高度な分析への足がかりを築けます。一方で、集計はあまり正確でないことが多いので、傾向だけ掴んで有益そうな分析は手元でやるようにしています。(ChatGPTならPythonで実行してくれるので正確なケースもある。)
命名
カラム名やCTE名、モデル名などのネーミングは、あまり時間をかけたくはないけど重要なタスクですよね。生成AIにコンテキスト（やりたい処理、関係するカラム）を与えれば、わかりやすくかつ規則性のある命名候補を示してくれます。
このCTEの命名をしたいです。
この処理に合った、分かりやすいCTE名とカラム名の候補を複数提案してください。
命名規則としては、snake_caseで、処理内容が直感的に分かる名前が望ましいです。
[処理の目的]
<CTEの目的>
[クエリ]
<SQL>
そのほかにも、コード生成（Python、JQL、GoogleAppsScript、VBA..etc）はもちろん、コード理解（プロダクトやインフラのコードやオープンソースのリポジトリ）の読み込みなどもとても便利です。分析のクラスタリングやラベリングにも使えます。実装・分析フェーズでは、利用用途がとても広いです。
レビュー
最後はレビューです。CTEのリネージ可視化や、仕様とコード・データの整合チェックが可能で、短時間で品質確認が行えます。
CTEレベルリネージの可視化
レビュー時、複数のモデルや複雑なCTEが組み合わさっている場合、データの流れを理解するのは骨が折れます。生成AIを活用してmermaid形式のリネージ図を生成させれば、二重参照や望ましくないレイヤリングが視覚的にわかりやすくなり、レビューワーへ説明する際の負担も減少します。
以下の[dbt model]のリネージをmarmaidで表現してください。
ただしモデルを一つ一つ読み込んでください。私が「次」と言ったら次のモデルのリネージを可視化してください。
[モデル1]
<SQLコード>
[モデル2]
<SQLコード>
...
[モデル10]
<SQLコード>
あとはスレッドで「次」というと、各モデルのリネージが次々と可視化されます。
次
最後に可視化したリネージをまとめましょう。
全体のリネージをMermaidで可視化して。
各モデルはmermaidのsubgraphでまとめて。
一気に可視化するよりも、一つずつモデルを可視化するほうが正しいリネージが可視化できます。
最近リファクタリングのために可視化したリネージ
これがあると複雑なクエリも短い時間で理解できます。構造を同僚に説明するときも簡単です。
今はこれをCIで自動的に可視化できないかを検討中です。
仕様とコードの整合チェック
要件定義書や仕様書と、PRで追加・変更されたコードをまとめて投入することで、生成AIが「この部分が仕様に合っているか」「前提条件が抜けていないか」を指摘してくれます。
[PR]が[仕様書]どおりになっているかチェックし、不整合がある場合は指摘してください。なぜ不整合だと判断したのかの根拠も教えてください。
[仕様書]
<本文>
[PR]
<PRで変更されたSQLの差分>
仕様とデータの整合チェック
仕様上は正しいけれど、実際のデータと合っているかは別問題です。サンプルデータと仕様ドキュメントを同時に与えれば、「このカラムは本当に指定されたデータ型・範囲に合っているか」「仕様で定めたルールに違反するデータはないか」を自動的に確認できます。
以下は、仕様ドキュメントとサンプルデータ（CSV）です。仕様上のルールに反しているデータが含まれていないか確認し、問題点があれば指摘してください。
[仕様書]
<本文>
[サンプルデータ]
<CSVまたはテーブル形式のデータのコピペ>
人間がサンプルチェック的に見るのも良いですが、生成AIならそれ以上の大きさのデータをチェックできます。（体感としては1000行くらいいけるイメージです。）
もちろん、生成AIにレビューの全てを任せるのは難しいですが、Testabilityが低く属人的になりがちなクエリのレビューを少しでもAIに任せていけることの価値は大きいと思います。
最後に
まとめると、自分が意識しているプロンプト設計は以下になりそうです。
- 大きなコンテキストウィンドウを活用：必要な情報を集め、網羅的に投入することで、モデルが総合的な理解を発揮しやすくなります。
- 単一要件を指示する：一度に多くの指示を出すのではなく、スレッドを通じて少しずつ指示を与えることで、出力制限や回答の浅さを回避できます。
- 根拠や思考過程の提示：モデルに根拠や思考プロセスを示すよう依頼すれば、なぜその回答になったかが明確になり、信頼性が高まります。
まだ発展途上の知見ですが、気になるプロンプトがあれば、ぜひ気軽に試してみてください。すべてを暗記する必要はなく、その都度参照しながら、自分やチームのワークフローに合わせて調整していけば十分だと思います。
最近の私の個人的なチャレンジとして、JIRAのチケットが作成されてからが完了するまでの一連の業務をどれだけ生成AIに寄せられるかをチャレンジしています。個別の断片的な作業を生成AIに任せるのではなく、生成AIを活用することを前提にして、生成AIでは難しい業務を私がやっていくイメージです。生成AIに任せた方が逆に手間なタスクもありますが、自分がやった方が早い仕事をあえて新入社員に任せることが長期的にはチームがスケールするのと同じで、一度任せて見ることに価値があると思います。そして、将来的には大半のプロセスが自動化される日が来ると考えています。少しでも進展があればまた記事にして紹介しようと思います。
逆にいうと、「仕様把握・業務理解」「要件定義・仕様策定」「分析・実装」「レビュー」というワークフローの個々の業務の断片的な作業の一つ一つは、プロンプトとインプットを与えたときのアウトプットに帰着でき、それを繋げないとワークフロー全体の作業を任せられないと考えることもできると思います。
チケットを作るだけで作業が完結する未来へ向けてという意味でも、このような試行錯誤は大切だと思っています。
上記の活用例はまだまだ発展途上ではあるので、他にも各社様の活用事例がありましたら紹介いただけると幸いです。
Ubieでは、BIチームの採用を強化しています！生成AI活用も全力でやってますので、気になる方はみて見てください！
Discussion