はじめに
技術部データプラットフォームグループの富士谷です。データプラットフォームグループでは、データ分析のために、データウェアハウスの開発を行っています。詳細は以下の記事をご確認ください。
社内ではBIツールとして主にRedashを使っています。分析者はPdMやマーケターの方が中心ですが、必ずしも全員がテーブル構造やSQLに習熟しているわけではありません。データマートやセマンティックレイヤーを十分に構築できていないため、分析者は過去のクエリを参考にやや複雑なSQLを書くケースが多くあります。
一方、世の中では、生成AIを使って分析を支援する取り組みが急速に進んでいます。昨年の弊社主催の勉強会(yabaibuki#6)でもいくつか紹介されました。データ分析の負担の軽減を目的として、AIを使って何かサポートできないか、今あるものを組み合わせて色々試してみようと考えました。この記事では、昨年の下半期に実験的に構築した分析用Slackbotについて簡単に紹介します。正直、うまくいかなかったことも多いのですが、その点も含めて、なにかの参考になれば幸いです。
回答例
早速ですが回答例の一部を画像にして公開します。Slackbotに対してメンションをすると、スレッド内で回答してくれます。
社内情報がふんだんにあるので一部除いています。雰囲気だけ掴んでいただければと思います。ハルシネーションとか実装ミスとかも割とありますが、なんとかベースにできるSQLを回答してくれます。
構成と工夫
システムの構成は以下のようなものです。
ベースとなるツール
生成AIを動かす場所については、今回はSlackbotを選びました。他のアイデアとして、GeminiでGemの配布、Notebook LM、 GitHub Copilot、Claude Code CLIもありました。エンジニアに限らず多くのユーザが利用できること、コンテキストの自動更新が容易であること、利用状況が把握しやすいことなどを考慮して、Slackbot（Slack Bolt）を選びました。 OpenAIは、BetterChatGPTのためにアカウントを持っていたので流用しています。利用したモデルは初期はGPT-4.1 miniで、現在はGPT-5.2 Chatを利用しています。
コンテキスト
利用しているコンテキストは、以下の3つです。
- Redashクエリの情報
- Redshiftのテーブル・カラム情報
- データ基盤の簡単な説明や、回答時の注意点など
社内のドメイン知識やテーブル間の関係（よくjoinされるもの）といった情報は、Redashクエリに多く含まれているだろう、という仮定のもと、手っ取り早く、RedashクエリをAPIで取得しjsonファイルにして、Vector Storeに保存してFile Searchで利用しています。また、Redshiftのテーブル・カラムの情報は、SchemaSpyが生成するxmlファイルを加工して作っています。
複数Redashへの対応
社内には事業部ごとにRedashの別のインスタンスが存在します。使えるRedshiftのスキーマも異なります。そのため、事業部ごとにコンテキストを切り替える必要があります。理想はSlackで問い合わせた人の所属部署を特定することですが相当大変です。簡単にCanvas APIを使ってチャンネルごとにコンテキストを切り替えられるようにしています。はてな社の記事を参考にさせていただきました。
課題
社内で使ってもらったり、利用者からフィードバックを頂いたり*1したのですが、色々と課題があります。主要なものを記載しておきます。
コンテキストの量と質
Redashクエリにタイトルは付与されていますが、クエリを作った背景や目的、詳細な説明はほとんどのクエリには記載されていません。テーブル情報もあるとはいえ、AIが社内用語や複雑な分析要件を解釈してクエリを構築するには情報が不足しています。カラムの値レベルの情報もほとんど入れられていません。
Redashクエリは直近で実行されたクエリを検索対象にしています。ただし、これだと「今は見ていないが、定期的には実行されている」ような定期実行クエリが入ってしまいます。ベクトル検索では必ずしも重要性を判断できません。AIの取り組みとは別に、時々Redash整理の活動を行っていますが、利用部署・利用者が多く完全には行いきれていません。
プロダクトのデータベースに閉じる分析であるならば、プロダクトのコードベースをコンテキストとして含めることも考えられます。しかし、データ基盤にはWebアプリ、ネイティブアプリ、Google Analytics 4など多様なデータソースが存在し、すべてをコンテキストに含めてAIエージェントに後はよろしく、というのも難しそうです。質問と回答を見ていても「このコンテキスト、いい感じに生成AIに教えたいんだけど教えられてないんだよなあ」みたいなのがかなりあります。
利用ターゲットとのズレ
最初は初心者にフォーカスをおいて開発しましたが、初心者は利用があまり進まず中級者以上の人が比較的よく利用する乖離が生じています。AIがハルシネーションしたり実装ミスしたりすることを理解したうえで利用する場合にはある程度有用そうですが、そもそもテーブルやSQLに不慣れな場合にはリスクが高く、有用ではありません。AIの回答も長くなりがちで、これを読み解いたりするのも相当に負担です。
定量的な精度評価、回答速度と品質のトレードオフ
「実行できるクエリを作れたか」は比較的簡単に評価できますが、一方で「データ分析として正しいか」は評価が難しいです。Text2SQLの本来的な難しさだと思いますが、精度評価の基準作りが困難です。質問をいくつかに定型化するのも大変で、今はほとんどできていません。
強いモデルを使ったりreasoning_effortを高めたりすると体感としてはハルシネーションが減るように見えました。しかし、回答速度が落ちます。Slackbotなので速度は重要です。品質・精度は計測しづらい一方で、速度は計測しやすい指標であることも、速度を優先することになる一因かもしれません。
Redashの様々なデータソース
Redashにはデータウェアハウス（Redshift）とは別のデータソースとして、個人情報にアクセスできないようにしたプロダクトDBのリードレプリカ（またはコピー）が接続されてることがあります。データウェアハウスを使う必要がないために、プロダクトのデータソースを使って分析や業務を行うことも多くあります。また、データウェアハウスではプロダクトDBのテーブルの完全なコピーを取れているわけではなく、データウェアハウスには存在しないテーブルもあります。
今はRedshiftに特化したコンテキストにしていますが、本来は利用するデータソース（業務要件）にあわせて、コンテキストを適切に切り替える必要があります。データソースごとに切り替えられるようにしても、AIエージェント的なアプローチをするにしても、Slackbotでは色々と大変そうです。
おわりに
試してみないとわからなかったところもありましたが、始める前からネックになるだろうと思っていたところにそのまま引っかかったことも多かったです。コンテキストエンジニアリングとかアナリティクスエンジニアリングの重要性をあらためて実感しています。
そのためには、「データが作られるプロダクト」「データ基盤」「データ分析の現場」のそれぞれを近づけたり、データ分析周りの整備にもう少し興味を持ってもらう人を増やしたりしていく努力も必要だと感じています。データプラットフォームグループのメンバーは、分析に特化したテーブルをあらためて構築しようとアナリティクスエンジニアリングの方向にも進みつつあります。このような取り組みは一朝一夕でできるものではありません。個人的には課題をいっぱい書きましたが「色々やることあるなあ」と思っています。引き続きデータ基盤やデータ分析業務の改善を続けていきます。
*1:特にご協力いただいたマッハバイトのお二人ありがとうございます！
