Zenn
🐕

なぜプロダクト開発は生成AIと相性が良いのかをデータ屋の視点から考察した

に公開
データ
生成 AI
ai駆動開発
text2sql
idea

※この記事は、データ系の人間が書いています
※LLMにはほぼ全部書き直しを推奨されましたが変更してないのでよみづらいかもしれないです
※都度修正を行なっていきます

データ分析に生成AIを適用させる取り組みをしてて思うことは、一発で完了してくれるプロンプトを書くことがめっちゃむずいです

でも、世の中ではDevinやClaude Codeが活躍していて、Issueを書くだけで段取りを決めて自立して改善してテストも終えるところまでの開発をしてくれていたりする。
データ分析に限らず、一般的な開発ほどAIと相性が良いものが何なのか、について考察してみた

現状生成AIが溶け込んでいるもののピックアップと考察

この記事に都合の良いチョイスをしています

  • veo3などの動画/画像生成
    • これはそれ用にfine tuningされており、それに対するテストも豊富に行われている
    • こういったものは、対話形式でdetailを修正することが一定可能なため、そのコストを払ってでも生産性を向上できているため許容されている
  • 学術的な方面への適用
    • 論文を記載したり、自立して論文を作成することができている
    • これは、論文は命題があり、いかにそれが正しいのかを証明するためという明確なGoalが定まっている。さらに、類似論文やreferenceなどを正しく与えることができればGoalに向かって行動ができるから

上記を踏まえ、プロダクト開発になぜ溶け込めたのか

個人的には次の要素がとても大きいと感じています

  • GitHub の master branch には常に最新の状態のみが保管されている
  • 思考に必要なものがほとんど含まれている(ことが多い)
  • 受け入れ条件やテストなどを定義し、コード上で実装することができ、その定義に関して明確に記載することができる
  • frontend部分についても、mockやfigmaなどで画像などを含む形式でどのようにしたいのかを先に与えることができる
  • TRD(Technical Requirements Document)などである程度細かい要件をあらかじめ記載していることが多い
  • 曖昧なビジネス要件を、先にCode上で記載されている表現に用語に変換されている

このように、あらかじめやることが決まっていて、それに対して実行をした時にどういう状態になっているべきなのかがある程度はっきりしている状態であれば、やりなおしなども自立して行えることが必須となっている

データ分析全体をWith AIにするために目指したい方向性

現在自分の所属している企業では次のように分解して生成AIを取り込むようなロードマップを構築した

企業におけるデータの活用をするために必要なことは何があるでしょうか？
データを蓄積して、データをクレンジングし、アクセスを可能にし、可視化し、意思決定を行い、場合によってはプロダクトに組み込むなどの高度な分析を実施する。基本的にはこのような流れだと思います
この全ての流れをAIがサポート/主体となって実施するような体制を構築するためのものとして、LayerとLevelを定義しました

Layer

Cultureは、AI Copilotをビジネス部門へも解放する際、データの民主化としてどのような状態になっていることが望ましいのかを対比させるために記載している

Layer Hierarchy Layer Applying AI Culture
1 🔗 データ連携ができている (Data Engineering) ・AI駆動開発による、データエンジニアリングのサポートが行えている
・AI駆動開発による、データエンジニアリングの領域の開発をビジネス側も行える		 データ基盤リテラシーの醸成が必要
2 🔍 データにアクセスしやすい　(Easy access to data) text2sqlなどの生成AIにより、より正しい必要なデータを正しくすばやく取得できる ビジネスを数字でより正しく判断できる、データを読む力、活用する力が必要
3 📊 可視化しやすい (Support for visualization and basic analysis) Graphicalな可視化や簡単なものであったり特殊な可視化であっても裏でPythonなどが実行される環境でインタラクティブに可視化ができる仕組みが構築されている 基本的な可視化のパターンを網羅的に知識として持っている
4 🧠 意思決定に使われている (Data is being used in the company's decision-making) 出力された結果を、事業の状態を把握した上で今後どのような意思決定をするべきか正しく判断できるための解釈の結果が素早く自動で算出される AIの考察結果が妥当かどうかを判断できる、分析力を持っている
5 🤖 AIを活用して高度な分析がしやすい (Conduct advanced analysis like Machine Learning.) 機械学習などのより高度な分析をすることができる。そのために、分析基盤と分析プラットフォームと生成AIがシームレスにつながっている 機械学習やAIを用いた分析手法について一般的な知識と正しい活用方法を理解している

Level

  • Lv.1 : データ組織内において、業務を遂行できている / Able to carry out tasks within the data Organization.
  • Lv.2 : CursorなどのLLMサポートツールなどを用いて、データチーム内で業務の効率化が測れている / By utilizing LLM-assisted tools such as Cursor, we have been able to improve operational efficiency within the data team.
  • Lv.3 : CursorなどのLLMサポートツールなどを用いて、データチーム外の人間が業務の効率化を図れている / By using LLM-assisted tools such as Cursor, people outside the data team have been able to improve the efficiency of their work.
  • Lv.4 : 汎用的なLLMサポートツールなどを用いて、データチーム外の一部の部門の人間が業務の効率化を測れている / By using general-purpose LLM-assisted tools, some departments outside the data team have been able to improve the efficiency of their operations
  • Lv.5 : 汎用的なLLMサポートツールなどを用いて、全部門の人間が業務の効率化を測れている / By using general-purpose LLM-assisted tools, all departments have been able to improve the efficiency of their operations.

それぞれにおいてアプローチは異なるが、基本的には次のような戦略を考えている

1. データ連携

データエンジニアリング領域に関しては、基本的にプロダクト開発と同じ状態を作り出せると考えているため、いわゆるAI駆動開発のいろはをつぎ込んでいる。
ただし、ギャップとしては次の要素があり、それぞれ解決策を検討している

  • Sourceデータを生成している部分でのみそれがどのように作られてそれらにどのような値が入っているのかが明らかにされているため、データコントラクトを推進することで一定解消される予定

2. データにアクセスしやすい

text2sqlを用いて、欲しいデータを自由に抽出する仕組みを構築する
ただ、text2sql自体も正しいデータ抽出をするためのハードルがとても多い。基本的には次のステップを踏んでそれらに対して技術課題があると感じている

ちなみに、text2sql自体は2023年春にはbeta versionを構築し、社内で展開した。精度は悪いが簡単なものは実行できたりクエリの中身を理解したりする用途では活躍をしている。
なお、世の中の進んでいる企業ではどのように実装されているのかは
https://satoshihirose.hateblo.jp/entry/2025/04/09/155623
は大いに参考になるため、読んでおくと良い

  • なんの目的で何をするためにデータを抽出するのかの明文化
    • 基本的にこの時点でハイコンテキストになっててLLMからするとハルシネーションの温床になっている
  • outputイメージの作成
    • 目的が明らかであればおそらく作成が可能
    • 出力列別に細かい条件が付与されていることが必要
    • whereであったりwindow関数をどのように適用させるのかであったりということがわかるように記載されている必要がある
  • SQL計画の策定
    • outputイメージの作成のために
  • table選択(これは各ステップにおいて複数回使われる)
  • column選択
  • sample queryの取得
    • templateSQLや過去作成されたSQLなどの情報を付与することで精度を向上
  • SQL計画の再作成
    • tableとfield情報を正しく得た上で最適な解を模索する必要がある
  • SQL作成
    • Query生成を行い
    • dry runにてデバッグし
    • query resultを得て何かしらの評価を行う

現在の自分の思考だと、上記を構築し、各ステップにおいてレビューを挟むことで一定の精度を保証するものは作成できると踏んでいる

3. 可視化しやすい

こちら、現状でもOpenAIが2024年の夏くらいに公開したData Analystなどでも一定実現できていたため、それを裏で実行し、可視化する環境を作れば基本的にはできると思っています。
工夫する点としては、

  • データの渡し方
  • データの定義 / description and type
  • 過去の同様のデータの加工例
    あたりを渡してあげると比較的スムーズに処理を行えるかなと思っています

4. 意思決定に使われている

ここは鬼門だと思っています。
基本的に意思決定は"総合的に鑑みて"という要素が強いと感じています。そのため

  • 競合の動向
  • 自社(プロダクト)のロードマップやミッションなどの情報
  • 自社(プロダクト)の状況
  • 自社(プロダクト)の過去の施策の結果とその考察
  • 実施中の施策や今回の施策についてのあれこれ
    などなどを渡してやっと意思決定をできる土俵に持っていけるのではないかと考えています。

このstep4と2,3を繰り返して意思決定する材料を分析して最終的に示唆を出す、そういうことをやりたいです。
なので、上記の会社に散りばめられている情報をいかに統合し必要な情報を渡せるのか、そういったことをどうすればいいのかを今考えてる最中です

5. AIを活用して高度な分析がしやすい

すみません、これに関しては全くイメージ湧いてないです
GoogleCloud, AWS, AzureあたりでまるっとできるようになるかDatabricksさんあたりが先に到達するか、くらいです。

ただし

上記のような5ステップをそれぞれ最適化した上で全部を統合してアクセスできる環境を用意してあげないと、たとえば

  • どのSourceのどのデータなのか、現状のビジネス状況はどうなっているのか、過去の意思決定はどうしたのか、などを総合的に見て一気通貫して分析業務を行えることはできないだろうなーというのと、会話しながらでないと人間のイメージって結局曖昧なところからスタートするので、アナリストがビジネスと会話しながらGoalを決めてそれのための集計業務をするといったようなコンサルテーションLayerはUI上必須になるんだろうなーというイメージを持っている

全体を通して、

  • データ分析プラットフォーム外のデータをどう閲覧してわかりやすくするか
  • text2sqlの精度をいかに上げるか
    という点がとても難しいなと思っています。まずはその課題を無視して統合する仕組みを簡単に作ってから部分最適化を進めていくのがPMF的によいのかなぁと考えてたりします

ギャップと今後の方向性

データ話が多かったですが、ここまで記載してきた中で、

  • 最新の情報かつ、その情報量が答えを出すために必要な情報量であるか
  • 求めている回答に対して、曖昧さを回避できているか
    この二点が、自立したAIを運用できるかにかかっているのではないかという結論に至った。
    ビジネス側やデータ分析の方面では、常に曖昧な中で答えを出すという現状を解消していく方向性が良いと考えている

Discussion