はじめに
こんにちは。ucchi- です。普段は広告のデータを整えつつ、全社横断のデータ整備も行っています。
この記事では、以下 3 つのテーマについて紹介します。
- データ分析を自律的に行う「LLM Agent」
- LLM Agent の能力を最大限に引き出す「LLM-Ready なデータ基盤」
- LLM-Ready なデータ基盤を高速に構築するための「FlyWheel（改善サイクル）」
LLM Agent は対話を通じてデータ分析を行う
まず、この記事における「LLM Agent」を定義します。これはデータ分析を自律的に行う大規模言語モデルであり、以下のように動作します。
- LLM Agent に問いを投げかける
- LLM Agent は問いを解釈し、SQLクエリの生成、実行、結果の可視化、解釈を行う
- そこから自律的に分析を深掘りしたり、追加のフィードバックを求めたりする
参考）Google Cloud の Conversational Analytics API
参考）Snowflake の Cortex Agents
LLM Agent はデータ分析の民主化と効率化を促す
利用者とデータ基盤の間をつなぐインターフェースは「SQL」や「BI」が中心でした。
「LLM Agent」という新しいインターフェースが登場したことで、データ分析業務は大きく民主化・効率化されます。今までの「BI 中心のデータ分析」と「LLM Agent によるデータ分析」を比較し、データ分析に関わる課題がどのように解決されるのかを整理します。
対象者 |
課題 |
BI 中心のデータ分析 |
LLM Agent によるデータ分析 |
|---|---|---|---|
データ利用者 |
SQL が書けない |
集計済みの指標を、BI を通じて確認する。深掘りが必要な場合はアナリストに依頼し、SQLを書いてもらう。 |
LLM が SQL を作成し、可視化を行う。 数値の正しさを確認したい場合のみアナリストに依頼する。 |
データ利用者 |
分析依頼のリードタイムがかかる |
データ分析をアナリストに依頼し、報告を受ける。 |
LLM との対話を通じて、自分でデータ分析を行う。リードタイムがなくなる |
データアナリスト |
データ分析依頼が多い |
SQL が書けない利用者からデータ分析依頼を受ける。 定型的な分析はサマリーテーブルを作成し、利用者が BI で分析できるようにする。 |
利用者自身が LLM Agent を用いて分析するため、分析依頼が減少する。 LLM が目的に応じたサマリーテーブルを都度作成するため、事前作成が不要になり、管理するテーブルが減る。 |
データアナリスト |
データ分析に時間がかかる |
以下の分析サイクルを回す。 - 仮説を立てる - SQLクエリを書く - 結果を可視化する - 結果を解釈する - 仮説を深化させる クエリ作成と可視化に時間がかかる。 |
以下の分析サイクルを回す。 - 仮説を立てる - LLM に尋ねて、分析を行わせる - 結果を解釈する - 仮説を深化させる クエリ作成と可視化を Agent が行うため、分析サイクルをより高速に回せる。 |
LLM が賢くなるほど、より抽象的で難しい問いに対しても、正確な分析結果を返すようになります。また、一度により深い分析を行えるようになります。
一方で「Garbage in, garbage out」という言葉があるように、データ基盤の品質が悪ければ、LLM Agent もアナリストも正しい分析ができません。
そこで、LLM の能力を最大限に引き出すためのデータ基盤について考えます。
参考）LLM の登場が BI の役割をどう変化させるか、に関する考察記事 www.getdbt.com
LLM-Ready なデータ基盤ではデータウェアハウス層の整備が重要
この記事において「LLM-Ready なデータ基盤」とは「LLM Agent が自律的に、分析を完結できる環境」を指します。これは、「データアナリストが分析しやすいデータ基盤」と言い換えてもいいかもしれません。
LLM-Ready なデータ基盤は、従来の BI 中心の基盤とデータ利用の構造が異なります。
BI中心のデータ基盤 |
LLM-Readyなデータ基盤 |
|
|---|---|---|
用途 |
BIを通じたデータの可視化 深掘り分析は、アナリストがデータ品質を確かめながら実施する |
LLM Agent を介した自由なデータ分析 定型的な可視化から、N1の深掘り分析までを、誰もが行えるようになる |
利用者が アクセスするデータ |
サマリーテーブル （データマート層） |
ログテーブル （データウェアハウス層） - ディメンションテーブル - ファクトテーブル - ワイドテーブル |
データ モデリング |
用途に応じたサマリーテーブルの作成 |
ビジネスプロセスのモデリング 用途に応じた集計は LLM Agent がアドホックに行う |
担保すべき データ品質 |
BIで表示される指標が正しい |
どのような集計をしても正しい つまり、レコードが全て正しい |
最も大きな違いは、これまでデータマート層（サマリーテーブル）が担っていた役割を LLM Agent が代替し、利用者は Agent を介してデータウェアハウス層（ログテーブル）に直接アクセスするようになる点です。
例えば、従来はダッシュボードで指標を確認し、考察していた利用者が、LLM Agent に「今月の売上推移は？」「特に伸びているセグメントは？」と問いかけて、ログテーブルから直接答えを得られるようになります。
だからこそ、どんな集計や切り口で分析しても常に正しい答えを返せる、理解しやすいデータウェアハウス層（ログテーブル）の整備が重要になります。
「ビジネスプロセスのモデリング」がデータ基盤を LLM-Ready にする
では、LLM Agent が理解しやすいログテーブルとはどのようなものでしょうか？
それは、「閲覧」「購買」といったビジネスプロセスをモデリングしたテーブルです。それぞれのビジネスプロセスに対して「誰が、何を、いつ、どこで、どれくらい、なぜ、どのように（5W2H）」が揃ったデータセットです。
ビジネスプロセスのモデリングでは、例えば以下のような処理を行います。
- アプリケーションの開発者しか知らない仕様を無くす。例えば「
user_type=1」を「user_type="有料会員"」に置き換える - データモデルを、利用者が直感的に理解できるビジネスの仕組みと一致させる。例えば動画投稿サイトにおいて「メンバーシップに登録すると、チャンネル登録者ではなくなる」というシステム仕様があるとする。これは利用者の感覚と合わないため、データ上では「チャンネル登録者」という括りに「メンバーシップ登録者」も含まれるようにモデリングし、ビジネスの実態とのズレをなくす
これらのテーブル群があることで、LLM Agent やアナリストは、裏側の仕様の複雑さに悩まされることなく自由な分析を行えるようになります。
目的に特化した分析やサマリーテーブルの作成は LLM Agent に任せ、彼らがのびのびと分析するためのコンテキストを社内各所から収集し、汎用的なディメンションとファクトを整えることが、今後のデータエンジニアの仕事になっていくと私は考えています。機械学習における特徴量整備が近しい概念です。
詳細は書籍『アジャイルデータモデリング』や、メルカリ社が公開している「Basic Tables」の記事が参考になります。設計思想や実装方法、データ品質担保やステークホルダーとの対話の仕方などが網羅的にまとまっているため、実践の際に役立つはずです。
（公平を期すために補足すると、私は『アジャイルデータモデリング』の訳者の1人です）
LLM-Ready なデータ基盤を高速に立ち上げるための FlyWheel
ここまで、「LLM-Ready なデータ基盤」には「ビジネスプロセスのモデリング」が重要である、という話をしました。
一方で、「ビジネスプロセスのモデリング」を行うには大規模なリソースが必要です。なぜなら、多くの場合、LLM-Ready なテーブルは既存の DB や DWH には存在せず、ビジネスの実態に合わせてゼロから作る必要があるからです。例えば以下の作業が必要になります。
- 構築作業：例えば、「注文」という1つのファクトを定義するために、複数の DB の仕様や過去の経緯を解読し、正しい SQL を構築し、ステークホルダーとの対話を通じて仕様を確認し、合意形成を行う必要があります
- 品質保証作業：さらに、そのデータがどんな分析軸で集計しても値が正しくなるように、集計値ではなくレコード単位での正しさを継続的に担保する必要があります
先行事例でも、データ整備に多くの時間を費やしています。
私たち BI Product チームは 2023 年から「Basic Tables」と呼ばれる、分析の利便性を高めるテーブル群の構築に取り組んできました。
こうしたデータ整備に大規模なリソースを割く判断を得ることは、容易ではありません。そこで私たちは、より直接的な事業価値につながる「経営層向けの報告」と「LLM Agent の業務活用」を旗印に、データ整備へのリソース投下を正当化しました。
この記事において「FlyWheel」とは、「トップダウン（経営報告）」と「ボトムアップ（LLM Agent 活用）」の改善サイクルを通じてデータ基盤が高速に整備される仕組みを指します。2つのプロジェクトが同時に進行することで、LLM-Ready なデータが2倍の速度で整備され、より深いインサイトが生み出され、ステークホルダーからの信頼を獲得し、さらなるデータ整備につなげることができます。全体像は以下です。
トップダウンの改善サイクル（結果指標の整備）
トップダウンの改善サイクルは、私の所属する経営企画チーム（Business Integration Division の BI推進チーム）が推進しています。
経営報告の会議体を起点とし、データ整備のためのリソースを確保します。弊社では2025年9月現在で20プロダクトが存在しており、経営報告の場で月次でプロダクトをひとつずつ取り上げ、プロダクトの深掘りや横断分析を行っています。このプロセスを通じて、報告の土台となる各プロダクトの重要な「結果指標」に関するログテーブルを体系的に整備しています。これにより、経営陣の支援を得ながら、基盤整備の強力な推進力を得ることができます。
ボトムアップの改善サイクル（原因指標の整備）
ボトムアップの改善サイクルは、データ基盤チーム（Platform Division の Data Platform Team）が推進しています。この部署はデータ分析 LLM Agent を開発しています。
トップダウンに整備されるのは、売上やMAU（月ごとのアクティブユーザー数）といった「結果」のデータが中心です。しかし、分析サイクルを自律的に完結させるには、「なぜ売上が上がったのか」という「理由」の部分も必要です。そこで、マーケティング部門など特定の部署と対話し、LLM Agent を実際に触ってもらいながら、彼らの具体的なニーズに応えるためのフィードバックサイクルを回しています。これにより、現場のユースケースに即したデータが整備され、データ基盤の価値が深化します。
「原因」と「結果」が噛み合うことで、インサイトが生まれる
トップダウンとボトムアップの改善サイクルが連携することで、「結果」と「原因」が結びついた質の高いインサイトが生まれます。「検索流入が増えたことで閲覧数が伸びた」「新機能がユーザーに価値を提供し、回遊が増えたことでMAUが伸びた」というように、現場の具体的な施策と、経営陣が参照するKPIが結びつくようになるだろうと考えています。
より深いインサイトが、さらなるデータ整備へとつながる（FlyWheel）
こうして生まれた質の高いインサイトは、ステークホルダーにデータ活用の価値を実感させ、次のデータ整備への投資を呼び込みます。これが「FlyWheel」として回り始めると、データ整備はさらに加速します。「結果から原因を探る」深掘りや「原因が結果をどう変えるか」という予測が可能になります。これは最終的に、さまざまな施策の精度を高め、改善サイクルを高速化し、ユーザーへの提供価値を最大化します。
今後
最後に、今後の展望についてまとめます。
整備：LLM Agent の社内全体公開と、データ整備の民主化
LLM-Ready なデータ整備は非常に時間がかかります。経営企画チームとデータ基盤チームによるデータ整備だけでは、高まる需要に追いつけていません。
将来的には、LLM Agent を社内全体に一般公開することによって、データ整備の価値をより多くの社員に理解してもらうことを目指します。そして、LLM Agent の価値を理解した利用者自身がデータ基盤開発に参加し、整備を行っていくサイクルを確立し、LLM-Ready なデータ基盤が自律的に成長していく状態を作りたいと考えています。
活用：LLM-Ready なデータ基盤整備を通じた、新たなインサイトの発見
FlyWheel によって「原因」と「結果」のデータが増えるほど、分析の組み合わせは掛け算で増加します。この広大な分析空間を、無限の手数を持つ LLM Agent が探索することで、今までは辿り着けなかった深いインサイトの発見が期待できます。
これは ChatGPT や Gemini の「Deep Research 機能」を社内データに適用するイメージです。例えば、ある施策後に LLM Agent は、以下のような分析を自律的に実行します。
- 効果検証
- 施策が最も効果的だった顧客セグメントを特定する
- そのセグメントの共通的な特徴を抽出する
- 類似施策の収益予測
- 似た特徴を持つ未アプローチのセグメントをリストアップする
- 同様の施策を実行した場合の収益をシミュレーションする
このような LLM Agent との協業は、データアナリストが行う業務・役割に影響を与えると考えています。データアナリストは、LLM Agent が生み出した分析結果の価値を見極め、意思決定につなげることに集中できるようになりますし、将来的には施策の実行業務も Agent に任せて効率化できるかもしれません。
まとめ
- LLM Agent とは、対話を通じてデータ分析を行う新たなインターフェースです。データ分析の民主化と効率化を促します
- LLM-Ready なデータ基盤 とは、LLM Agent やアナリストが、アプリケーションに由来する難しさに悩むことなくデータ分析を行えるデータ基盤です。利用者がアクセスするテーブルがサマリーテーブルからログテーブルへ移行します。ビジネスプロセスのモデリングが鍵を握ります
- LLM-Ready なデータ基盤を高速で立ち上げるため、 私たちは、トップダウンとボトムアップの2つの改善サイクルを通じた FlyWheel の構築を行いました。「原因」と「結果」のデータ整備が、現場から経営まで結びついた質の高いインサイトを生み出し、さらなるデータ整備への動機付けになります
ピクシブでは、一緒に働く仲間を探しています。
興味をお持ちの方は下記URLからエントリーをお待ちしております！
