kubell Creator's Note

株式会社kubellのエンジニアのブログです。

ビジネスチャット「Chatwork」のエンジニアのブログです。

読者になる

「自然言語でデータに聞ける」を社内の当たり前にしたい

こんにちは。プロダクトデータアナリストの合田(@shohei_trapi)です。

本記事はChatwork 15周年に合わせた「#kubellブログリレー」の記事として執筆しています。今回はSnowflakeのAI機能を活用した、社内のデータ分析基盤づくりについて書いていきます。技術的な話も含め、社内のリアルについても触れていきます。

「社内のデータ活用・民主化を推進したい方」「SnowflakeのAI機能に関心がある方」「データアナリストとして組織への価値提供を模索している方」は是非読んでいただきたいです(もちろんそうでない方も大歓迎です)。

データを見たいのにすぐ見れない

「先週のサインアップ数の内訳ってどんな感じだった?」

こんなシンプルな疑問でも、自分で答えを得るのは意外と難しいものです。非エンジニアであればデータアナリストにチケットを起票して、数日待って回答をもらう。エンジニアであっても、自分の担当領域以外のテーブル構造やクエリは把握していないので、結局誰かに聞くことになる。

データは社内に蓄積されているのに、それを見るためのハードルが高い。この「データへのアクセスにボトルネックがある」という問題は、おそらく多くの組織が抱えている課題ではないでしょうか。

kubellでも同じ状況がありました。データアナリストがボトルネックになり得るため、「特定の人に依存しないデータ分析の仕組み」を作る必要性がこれまで以上に高まっていました。

https://speakerdeck.com/kaz3284/snowflakedetaji-pan-detiao-muaihuo-yong-4nian-jian-nodataopsnoji-chu-womotoni?slide=7

そこで取り組んだのが、AIエージェントを活用した「データ分析の民主化」です。自然言語で質問すれば、誰でも必要なデータを取得できる環境を社内に整備する。この記事では、その取り組みの中で見えてきたことをお伝えしたいと思います。

Snowflakeに閉じたデータ分析AI基盤という選択

kubellでは以前からSnowflake上にデータ基盤を構築してきました。この積み重ねがあったからこそ、データ分析のAI化もSnowflakeのエコシステムに閉じた形で実現できています。データのガバナンスやアクセス制御をSnowflake上で一元管理しながら、新たにAI機能を載せるだけで済む。外部ツールとの連携やデータの持ち出しを考えなくてよいのは、運用面で大きなメリットでした。

Snowflakeは2025年から2026年にかけて、データ分析向けのAI機能を相次いでリリースしています。今回活用しているのは、そのうちの2つです。

1つ目は「Snowflake Intelligence」。2025年11月に正式リリースとなった機能で、ユーザーが自然言語で質問すると、AIがSQLを自動生成して実行し、結果をテーブルやグラフで返してくれます。最大の特徴は「Semantic View」と呼ばれる仕組みで、AIが参照するデータの範囲や意味を運営側が事前に定義できること。つまり「正しく答える」ことに重点を置いた設計です。

creators-note.chatwork.com

2つ目は「Cortex Code」。2026年2月にCLI上で、2026年3月にSnowsight上で正式リリースとなったAIコーディングエージェントです。こちらはデータベース全体を自由に探索でき、SQLやPythonのコードをAIが支援してくれます。いわば「広く探索する」ためのツールです。

この2つは競合ではなく、補完関係にあります。非エンジニアのメンバーには、精度をコントロールでき安心して使えるSnowflake Intelligenceを。SQLやデータ構造の一部を理解しているエンジニアには、自由度高くデータを探索できるCortex Codeを。ユーザーの技術レベルや用途に応じて使い分けられる体制になっています。

Snowflake Intelligence と Cortex Code の役割分担

とはいえ、全社的な「データ分析の民主化」の今の主軸はSnowflake Intelligenceで考えています。誤った回答が返ってきたときに非エンジニアのユーザーがそれを見抜くのは難しい。だからこそ、回答の対象範囲を運営側で制御し、その範囲内で高い精度を担保するアプローチが、より多くの人に安心して使ってもらうには適していると判断しました。

もっとも、AI関連のプロダクトは日々進化しており、今の最適解が半年後も同じとは限りません。特定のツールに固執するのではなく、その時々で最適なものを柔軟に使い分けていく姿勢が大事だと考えています。

社内でどう使われているか

Snowflake Intelligence上に構築したのは、用途別に分かれた3つのAIエージェントです。約3ヶ月の運用期間を経て、PdM、デザイナー、事業管理、広告事業メンバーなど、部門や職種を横断してさまざまなメンバーが利用しています。

具体的にどんな使われ方をしているか、少しだけ紹介します。

事業管理は、事業数字の内訳を深掘りする場面で活用しています。定期的なKPIレポートはBI(Business Intelligence)ツールで提供していますが、そこから「この数字の内訳は?」「導入経路別に分解するとどうなる?」と一歩踏み込んだ分析をしたいとき、これまではアナリストへの依頼が必要でした。事業数字は正確さが最も求められる領域なので、現時点でエージェントが対応できる範囲はまだ限定的ですが、少しずつカバー範囲を広げている段階です。

PdMは、より深い分析に使っています。たとえば「ある業種の組織規模分布をヒストグラムで見たい」「セグメントの閾値を30名で区切る合理性を検証したい」といった、戦略的な意思決定に直結する分析です。AIとの対話が二桁に及ぶこともあり、探索的にデータを掘り下げていく使い方が特徴的でした。

デザイナーは、特定機能の利用実態の把握に使っています。「〇〇機能の利用率は?」から始まり、「デバイス別の利用状況」「利用率と解約率の相関」と段階的に深掘りしていました。また、特定機能の利用上限を調べるための問いなども見られ、UI・UXに関連したデータが分析できることが重要だと感じました。

現時点ですべての問いに対し回答できているわけではありませんが、整備していくことで「データが必要になる→チケット起票→数日待つ」が「データが必要になる→自然言語で質問→数秒で取得」に変わることを改めて実感しました。

利用ログからわかった3つの発見

運用期間中の利用ログを分析したところ、いくつか興味深い発見がありました。

発見1:職種によって使い方がまったく違う

事業管理は事業数字に関するデータをBIツールと併用しながら深掘り、PdMは一つのテーマを二桁かけて深く掘り下げ、デザイナーは特定機能にフォーカスした定量分析を行う。同じツールを使っていても、職種によって利用パターンがはっきり分かれました。

これは、エージェントの設計時にペルソナを分けて用途別に構築した判断が正しかったことを裏付けています。「万能な1つのエージェント」ではなく、「それぞれの業務に最適化された複数のエージェント」という設計方針が機能していました。

creators-note.chatwork.com

発見2:初回体験の設計が定着率を大きく左右する

利用者のうち、約4割が1日のみの利用で離脱していました。一方で、3日以上利用した層は自走的に深い分析まで到達しており、明確に二極化していたのです。

1日で離脱したユーザーの利用ログを見ると、「何ができる?」「どんなデータが見れる?」といったメタ的な質問が多く、エージェントの能力範囲を把握できないまま離れてしまった様子が読み取れました。つまり、ツールの機能ではなくオンボーディングの設計に課題があったということです。「最初の1問で成功体験を作れるか」が定着率を分ける鍵だと痛感しました。

発見3:ユーザーがAIの"間違い"を正す場面が生まれた

これが個人的にもっとも面白かった発見です。デザイナーが「この数値、MAUの定義と合っていないのでは?」とAIの回答に反論したり、PdMがSQLを直接渡して「この条件で再集計して」と補正したりする場面が複数回ありました。

一見するとAIの精度不足に見えますが、実はこれこそが「人とAIの協働」の健全な姿だと考えています。AIが出した一次回答を、業務知識を持つ人間がレビューし、必要に応じて補正する。そしてその補正内容がSemantic Viewの改善にフィードバックされ、次回以降の精度が上がる。このループが自然に回り始めたのは、大きな手応えでした。

https://creators-note.chatwork.com/entry/2026/01/19/160816

万能ではない:現時点の限界

正直な話、できないことはまだまだたくさんあります。

単純な集計やカウント、期間指定のフィルタリング、基本的なグルーピングといった定型的な分析はある程度対応できます。一方で、複数のテーブルをまたぐ複雑な多段集計や、Semantic Viewが未整備の領域への質問、曖昧な表現への対応はまだ難しく、ハルシネーション(もっともらしいが誤った回答)のリスクも依然としてあります。

ここで重要なのは、「精度のコントロール=Semantic Viewの継続的な整備」だということです。エージェントは一度構築して終わりではなく、ユーザーの利用パターンや指摘を受けてデータの定義やカバー範囲を地道にアップデートし続ける必要があります。運用コストがゼロになるわけではなく、「アナリストへの依頼対応」が「Semantic Viewの整備・改善」に置き換わった、という表現のほうが実態に近いかもしれません。

今後の展望

現在は、3つの軸で改善を進めています。

1つ目は、エージェントの回答精度とUXの改善です。ユーザーがどのエージェントに質問すべきか迷うケースが散見されたため、自動で適切なエージェントに振り分ける仕組みを検討しています。

2つ目は、対応データの拡充です。現状カバーしきれていないプロダクトデータや、複数の属性情報を組み合わせた集計を実現するため、Semantic Viewの追加・改善を行っていきます。

3つ目は、フィードバックループの強化です。ユーザーの利用がそのまま改善サイクルにつながる仕組みを、AIエージェントも活用しながらより効率よく意図的に設計していきたいと考えています。

さいごに

Chatworkはこの15年間で、膨大なプロダクトデータを蓄積してきました。しかし、そのデータにアクセスできる人はごく一部に限られていました。「自然言語でデータに聞ける」という体験を社内の当たり前にすることで、15年分の資産をもっと多くの人の意思決定に届けていきます。まだ道半ばですが、ユーザーと一緒にこの仕組みを育てていければと思っています。

そしてこの取り組みなどを共に実行してくれる仲間も募集中です。興味のあるポジションがありましたらぜひご応募ください。 hrmos.co

最後まで読んでいただきありがとうございました。引き続き「#kubellブログリレー」をお楽しみください。