Hello everyone,
毎日ニコニコしているニコです！
最近、私たちのチームは新しいデータプラットフォームの改善に取り組んでいます。技術面だけでなく、組織の仕組みづくりにも多くの時間をかけてきました。大変だと思いますが、楽しく仕事ができてよかったです！
はじめに
ちなみに、現在、私たちの分析の多くはアドホック分析が中心です
このやり方だと、意思決定を素早く行えるという大きなメリットがあります。私たちはそこを大事にしてきました。
しかし一方で、データの品質が十分でない場合も多く、その結果として意思決定の根拠が揺らぎ、誤った判断につながるリスクもありました。
そのリスクを減らし、かつスピードを保ちながら進んでいくために必要なのが「データマネジメントライフサイクル」の仕組みです。
この考えについては、Harry さんが以下の記事で詳しく説明しています。
だからこそ「データマネジメントのライフサイクルを、もっと協力的に、もっと早く、もっと簡単にみんなで回していくこと」ことがチームのずっと大きな目標になっています。最近はその実現のために AI をどう活用できるか を実験してきました。今回の記事ではその「trial and error」と学びを紹介します。
なぜこの話に取り組んでいるのか？
理由はシンプルで、アドホック分析は探索的・短期的でスピードが命だからです。データチームがすべてをさばくのではなく、現場のメンバー自身が素早く意思決定できる仕組みが必要なのです。AI の進化はその助けになると考えています。
具体的には、
- ルールやガードレールを敷いて安定性を高める
- コマンドやインタビュー形式でフローを標準化する
- 複数のエージェントを役割分担させる
といったことを試しています。この記事は「完成したベストプラクティス」ではなく、あくまで 現在進行中の旅の記録です。
なぜアドホック分析が大事なのか
現実的には、データチームだけで全ての業務知識をカバーすることはできません。データを最も必要としているのは、アプリ開発者やマーケティング、プロダクトマネージャー、オペレーションのメンバーなど、日々現場で意思決定を行っている人たちです。彼らこそが新しい疑問を投げかけ、自分の領域に適したロジックを探し続けています。データチームの役割は、その活動を支えるインフラをつくることにあります。
しかし、すべての分析リクエストをデータチーム経由にしてしまうと、すぐにボトルネックが発生します。だからこそ重要なのは、誰もが自分でデータを分析できるようにすること。ただし、自由に分析できるだけでは十分ではなく、同時に 一貫性と品質を保つ仕組み も必要です。
実際に社内データを見ると、分析リクエストの約80%がアドホック分析です。探索的で短期的で、スピード感が求められるケースが大半です。だからこそ「速さ」が不可欠になります。
そして私たちは考えました。
「AI を使えば、専門家でなくてもデータチームを待たずに効果的な分析ができるのではないか？」
アドホック分析での LLM 活用方法
ルールとガードレールを作る
最初に LLM をワークフローに取り入れたとき、私たちのやり方はとても単純でした。モデルに「コードやクエリを作って」とお願いするだけで、「いい結果が出ればラッキー」と思っていました。実際、うまくいくこともありましたが、同じ入力でもまったく違う結果が出ることも多かったのです。
この一貫性のなさは、LLM が確率的に動く性質から来ています。このランダムさを抑えるためには、ルールを作ることが必要だと気づきました。
私たちの環境は dbt を中心にしているので、次のようなルールを立てました。
-
プロジェクトの大きな目的
プロジェクト全体で「何を達成したいのか」を明確にし、AI の出力がその方向性から外れないようにします。目的がぶれると、どれだけ良いクエリでも役立たなくなってしまいます。 -
アーキテクチャやフォルダ構造
フォルダやファイルの配置ルールを統一することで、誰が見ても同じ流れで理解できる状態をつくります。これにより、モデルの管理や保守も簡単になります。 -
クエリのモデリング規約やスタイル
インデントやエイリアスの付け方などを統一し、読みやすさと再利用性を高めます。スタイルが揃っていると、AI が出力するクエリもより安定します。 -
クエリを作成・テストするときの定型フロー
「作る → テストする → 修正する」という流れを決めておき、どのユーザーが取り組んでも同じ品質を担保できるようにしています。フローを定めることで無駄な試行錯誤を減らせます。
これらのルールを「レール」として敷くことで、出力がプロダクション環境の標準に沿ったものになるようにしています。
コマンドを使ってフローを標準化する
次に役立っているのが、Claude の コマンド機能です。この機能を使うと、よく使うパターンをあらかじめ定義できるので、毎回ゼロから書く必要がなくなります。ユーザーはショートカットを呼び出すだけで、安定した結果を得られるようになります。
現在、私たちが特に使っているのは次の 2 つのコマンドです。
adhoc コマンド
素早く試すための探索的なモデルを作るときに使います。思いついた分析をすぐに形にできるので、スピード感を重視する場面に役立ちます。
model_testコマンド
一度使って便利だったモデルを、正式なティア構造の中に昇格させるときに使います。これにより「作って終わり」にならず、再利用できる形に整理されます。
こうして入口を標準化することで、出力のばらつきを減らせるだけでなく、非エンジニアのメンバーでも迷わず正しいプロセスを踏めるようになりました。
「インタビュー」でコンテキストを集める
分析において重要なのは、コンテキストなしでは何も始まらないということです。残念ながら AI は私たちの頭の中を読むことはできません。だからこそ、クエリを作る前に十分な背景情報を与える工夫が必要になります。
私たちはそこで「インタビュー」のような仕組みを取り入れました。AI があらかじめ用意された質問を順番に投げかけ、できるだけ多くの情報を集めてからモデルを作り始めるという方法です。最近の LLM はコンテキストウィンドウが広がっているため、必要な情報をたっぷり与えても技術的な制限にすぐ当たることはありません。
ユーザーにできるだけ詳細を入力してもらう
テストを行うとき、細かい情報の重要性が特に際立ちます。理論上はシンプルに見えるテストでも、実際には膨大なデータを扱うことになり、実行時間が長くかかったり、他の処理を妨げてしまったりすることがあります。
そのため、最初の段階でユーザーにできるだけ多くの詳細を入力してもらうようにしています。事前に十分な情報があれば、テストやクエリを効率的で正確、かつ状況に合った形で設計できるからです。
複数のエージェントで役割を分ける
ソフトウェアエンジニアリングの考え方に影響を受けて、私たちは マルチエージェントの仕組みも試しています。1つの AI にすべてを任せるのではなく、エージェントごとに役割を分けて担当させる方法です。
データアーキテクトエージェント
分析の設計を担当します。より抽象的な質問を投げかけたり、複雑なロジックを分解したりする役割です。
データモデラーエージェント
実際にクエリを書いたり修正したりして、分析を実行する役割です。
このように役割を分担すると処理が少し遅くなることもありますが、流れが明確になり、コンテキストが膨れ上がるのを防げます。実際に使ってみると、大きなエージェント1つに全部任せるよりも、小さく集中したエージェントのほうが安定した結果を出すことが多いと感じています。
ChallengesとPain Points
非決定性（Non-Determinism）
どれだけルールを設定しても、LLM は予測不能な動きをします。指示を無視したり、エージェントへの役割分担をうまくできなかったり、意図したフローを省略してしまうこともあります。
また、モデルの種類によっても大きな差があることに気づきました。たとえば Claude Opus はマルチエージェントの調整を比較的うまくこなしますが、利用できる枠（クオータ）に制限があります。一方で Claude Sonnet に切り替えると、まるで別物のように品質が落ちてしまうこともありました。
ただ最近、Sonnet 4.5 がリリースされたばかりなので、この点は改善されているかもしれません。今後さらに検証を進めて、より良いバランスが取れることを期待しています。
コンテキスト収集への抵抗感
人間的な要素として、多くの人は細かい情報を入力するのを好まないという問題があります。多くのユーザーは AI に「魔法のようなもの」を期待していて、短い一文を入れるだけで完璧な結果を返してくれると思ってしまいがちです。
ソフトウェア開発のようにコードベースにある程度の暗黙的なコンテキストが含まれている領域では、それでもなんとかなる場合もあります。しかしデータ分析の世界では、データセットごとに特有のクセがあり、分析にはそれぞれ固有の前提条件が存在します。
そのため、コンテキストの収集は避けられません。ただし同時に、ユーザーにとっては「インタビュー疲れ」を引き起こす原因にもなっています。AI がもっとコンテキストを理解できるようになるまでは、この課題はしばらく残り続けるでしょう。
バランスを取ること
おそらく最も難しい課題は、バランスをどう取るかという点です。
AI を使えば作業スピードは速くなり、できることの幅も広がります。しかし、ツールである LLM も、使う人間（アナリスト）もどちらも非決定的であるため、結果を予測するのがとても難しくなります。
モデルの処理に時間がかかりすぎることもあれば、テストが重くなりすぎて他の作業を妨げることもあります。逆に、ユーザーが十分なコンテキストを与えられず、不完全な結果につながることもあります。
スピード、正確さ、そして使いやすさのちょうど良いバランスは常に変化しています。だからこそ私たちは常に注意深く状況を見直し、改善を続ける必要があるのです。
学びと改善点
プロセス改善
現在特に力を入れているのは、アドホックモデルをティア3に昇格させるプロセスです。ティア3とは、メタデータが整備されていて、組織的に再利用できるようになったモデルを指します。ティアリングに関してもしもっと理解したかったら、ぜひ上の共有された記事を読んでみてください！
一つの例として、現在私たちの dbt では Adhoc クエリが作成されると、Snowflake 上では view として materialized されます。ですが多くの場合、このビューは元テーブルのデータ量が非常に多いため、テストを実行すると全件スキャンが走ってしまい、とても重くなってしまいます。
もちろん、adhoc command や model_test フローの中で「テストを制限する」などの特別な工夫を入れてはいますが、それでも依然として パフォーマンスが遅くなるケース が多く見られました。特に、ユーザーがモデルをティア3 に昇格させようとする際、ビューのままでは処理が遅くなりやすいのです。さらに「なぜテストが失敗するのか」「なぜこんなに時間がかかるのか」がユーザーにとって分かりにくいこともありました。中には「自分の Adhoc モデルがすごく遅い」と直接フィードバックをもらうケースもあります。
そのため私たちは、ティア3モデルは view materialization ではなく、テーブル（固定テーブルやインクリメンタルテーブル）や Dynamic Table に切り替えるという改善を検討しています。これだけでテストの実行速度、パフォーマンス、そして信頼性が大きく改善されると考えています。
教育とコラボレーション
AI はいくつかの作業を自動化してくれますが、プロセスの中心にいるのはやはり人間です。システムとの付き合い方を周りに教えたり、フィードバックを聞いたり、チームとして協力を促すことは、AI のワークフローを設計することと同じくらい重要です。
AI を「ツール」として扱う
最後に一番大事なことを強調したいのは、AI はあくまでツールであるということです。
どうしても「AI ならすべてを解決できる」と思いたくなりますし、AGI（汎用人工知能）の時代が来れば、もしかするとそれは現実になるかもしれません。ですが、今の LLM はあくまで「学習データに基づいて次のトークンを予測する統計モデル」に過ぎません。
生産性を大きく高めてくれる力はありますが、それは人間の判断や丁寧な設計、そして適切なガードレールと組み合わせてこそ本当の価値を発揮します。
おわりに
私たちの アドホック分析とティアリングにおける AI 活用の旅は、まだまだ道半ばです。データとAIモデルは今後も進化を続けますし、それに合わせて私たちのワークフローも変わっていく可能性が高い。そのたびに、成功からも失敗からも新しい学びを得ています。
大事なのは、誰もがもっと自由にデータを扱い、分析し、自信を持って使える環境へと着実に近づいていることです。ボトルネックに縛られることなく、安心してデータを活用できる未来を目指しています。
この記事は、決まりきった手順書ではありません。むしろ、今の私たちの試行錯誤や学びを記録した「open diary」のようなものです。同じような課題に取り組んでいる方がいれば、ぜひみなさんの工夫や学びも教えていただけると嬉しいです。
Discussion