エンジニアの佐野です。最近はバンドルカードのデータ探索を行うための社内プロダクト Synapse (と名付けた) の開発をしています。雨後の筍のように AI の名を冠したソフトウェアやサービスが出るようになって久しいのですが、カンムでもとりわけ生成 LLM をはじめとする AI は業務で大いに活用されています。例えばソフトウェア開発では各位が Claude Code や Cursor を活用してコードを書いています。わからないことがあったら ChatGPT や Gemini に質問を投げかける、NotebookLM にドキュメントを要約してもらう、Notion や Box など AI 搭載をうたう SaaS ではそれを活用する...といったような。これらはもはや各社当たり前のようにやっているくらいには AI の活用は市民権を得たと思います。

さて自分の所属するチームですが、それら AI の個人活用の一歩先、AI で事業インパクトに貢献する、という目論見でデータ分析に強いエージェントの開発を行っています。今日はそのエージェント開発をなぜデータ分析における探索フェーズの支援にフォーカスさせたのかから始まりその思想と現在の実装、運用について書きます。

なぜデータ分析か
Synapse デモ
データ分析の従来のフローと Synapse 導入後のフローの違い、Synapse のスタンス
Synapse のシステム構成の現在
AI 利用のガバナンス
課題と方針
まとめ

1. なぜデータ分析か

なぜデータ分析か？ですが、それにはバンドルカードの成功体験があります。バンドルカードは息の長いプロダクトで、2016年に生まれもうすぐ10周年になります。その収益を支えているポチっとチャージという機能があるのですが、その機能はリリース当初からデータドリブンで改善が行われていました。エンジニアもエンジニアではない職種の人も日々 SQL を投げて探索的にデータを確認、仮説を立ててそれを検証して...という PDCA を回していました。それによってポチっとチャージは成長して、今でもカンムの主力機能の1つとなっています。そしてそのデータドリブンの開発という企業文化＋SQL勉強会もあり、現在も職種を問わず DB にアドホックなクエリをしてデータを調べる、という行為が日常的に行われています。このようにカンムでは「仮説を立て、検証を高速に回すデータ分析」が価値を生んできました。

時は流れ今の時代、AI 時代になったのですが、当初このエージェントは「気軽に社内のデータに触れられるもの」を目指しました。背景として、SQL を扱うという土台はあるもののテーブル構造を理解する必要があったり SQL 自体を書くのが手間であったりという状況もありました。自然言語でデータに質問できるインターフェースを作ればこの敷居を下げられるのではないか。そんな仮説からスタートしています。

チームはこの AI エージェントを社内に公開した後、社内のユーザからの使われ具合や入力されたプロンプトを見て議論を行いました。議論の結果、ポチっとチャージの成功や SQL 勉強会から続いているデータドリブンの思想を継承して次のステージに進むこととデータ分析に強い方向に尖らせることを決定し、チームはこのエージェントを Synapse と名付けました。

2. Synapse デモ

ここで Synapse のイメージを示したいのでデモとして不正取引の特徴量の調査をやってみます。見せられないものが多く白抜きばかりになってしまい恐縮ですが...。

このような調査をやると金額のビンを変更してヒストグラムを作り直したり、GROUP BY で別切り口で調査したり...といった作業が発生するのですが、このあたりの作業と結果の要約を LLM に依頼できます。これらの作業自体は高度ではありませんが試行回数が多くボトルネックになりがちです。この工程を人よりも素早くそして何度でも試せます。従来は1つの切り口を試すのに数十分かかっていた作業を、数秒〜数分で反復できるようにするのが狙いです。

簡単なデモを提示したところでこれが従来のデータ分析とどう異なるのかを説明します。

3. データ分析の従来のフローと Synapse 導入後のフローの違い、Synapse のスタンス

以下に一般的なデータ分析のフローを示します。データ探索の箇所は本記事で肝となるので小項目も書いています。

1: 課題設定
2: データ理解/定義
3: データ探索
- 3.1: SQL作成
- 3.2: テーブル／グラフ可視化
- 3.3: データの要約・特徴抽出
- 3.4: 仮説候補の提示
4: 仮説の選別
5: 解釈・意思決定
6: 施策実行

そして従来のように人間が自力で頑張る場合と Synapse のような LLM をデータ分析に活用するケースでの違いを表にします。

フェーズ	従来型	LLM活用 (Synapse)
1. 課題設定	作業 (人) ・ビジネス課題の言語化アウトプット・課題文（例：新規ユーザの7日継続率が低い）・対象ユーザ（例：直近3ヶ月の新規登録ユーザ）	作業 (人) ・ビジネス課題の言語化（※従来型と同じ）アウトプット・課題文（例：新規ユーザの7日継続率が低い）・対象ユーザ（例：直近3ヶ月の新規登録ユーザ）
2. データ理解 / 定義	作業 (人) ・テーブル定義書を読む・イベント仕様を確認・継続率の定義を決めるアウトプット・テーブル／カラム定義メモ・定義した継続率・定義はドキュメントと個人の解釈に依存	作業 (人) ・セマンティックレイヤーを作成・継続率の定義を明示的に定義アウトプット・セマンティック定義一覧・定義した継続率・LLMが参照する正式な意味定義
3.1 データ探索（入力）	作業 (人) ・継続率とユーザ属性を紐付けるSQLを設計・作成・JOIN条件や日付計算を調整・SQLを実行・修正アウトプット・継続率の集計表	作業 (人) ・自然言語で継続率やユーザ属性に関する問いを立てる・問いをエージェントに入力アウトプット・継続率の集計表
3.2 データ探索（可視化）	作業 (人) ・集計結果をもとにグラフを作成アウトプット・継続率推移のグラフ	作業 (システム / LLM支援) ・生成された集計結果を自動で可視化アウトプット・継続率推移のグラフ
3.3 データ探索（要約・特徴抽出）	作業 (人) ・数値やグラフを吟味・差分や特徴量を見つけるアウトプット・結果の要約・特徴量候補	作業 (LLM) ・結果を要約・差分や特徴量候補を提示アウトプット・結果の要約・特徴量候補
3.4 仮説立案	作業 (人) ・表やグラフを見て仮説を言語化アウトプット・複数の仮説候補	作業 (LLM) ・データに基づく仮説候補を提示アウトプット・複数の仮説候補
4. 仮説選別	作業 (人) ・仮説を選別・優先順位付けアウトプット・選定した仮説・想定される効果量	作業 (人) ・仮説を選別・優先順位付けアウトプット・選定した仮説・想定される効果量
5. 解釈・意思決定	作業 (人) ・分析結果の解釈・施策の意思決定アウトプット・検証方針・施策方針	作業 (人) ・分析結果の解釈・施策の意思決定アウトプット・検証方針・施策方針
6. 施策実行	作業 (人) ・施策の実装・モニタリング	作業 (人) ・施策の実装・モニタリング

要約すると Synapse がデータの特徴抽出や仮説候補の提示を行って分析者の仮説立案を支援します。スタンスとしては Synapse の出力は常に仮説候補であり、意思決定や判断を行うツールではないというスタンスです。それの評価・選別は人が行います。これは LLM の得意分野だけを当てはめた構図になります。Synapse は当然誤りを犯します (SQLのミスや意味の取り違え) 。しかし人が同じ誤りを犯すよりも早く何度でも試せる点に価値があります。ほとんどの社員が SQL を叩ける文化があるからこそ、そのボトルネックが明確でした。

※ セマンティックレイヤーは、Synapse運用者が事前に用意するデータの意味やロジックを説明する辞書です。分析者が毎回作るものではありません。

再三になりますが以下のような役割分担です。仮説の選別や検証の設計も担うようにしてもいいかもしれませんがまずは小さく始めています。

意味を決める: 人
問いを設計する: 人
探索を実行する: LLM
要約・仮説候補提示: LLM
仮説を選ぶ: 人
検証を設計する: 人
意思決定する: 人

ちなみにですが...Synapse は BI, AutoML ではなく探索フェーズの反復を高速化することで分析の質を上げることを目的としています。

BI: 指標を定常モニタリングし、組織で同じ数字を見る
AutoML: 答えを出す（予測・最適化）
Synapse: 探索フェーズを支援して仮説を生む

強いて言うなら ChatBI に近い領域に入ると思います。ただし Synapse は SQL を省力化するだけの ChatBI ではなく要約・特徴抽出・仮説候補提示まで含めた探索ループの支援に踏み込む方向です。

4. Synapse のシステム構成の現在

Synapse の構成は次のようになっています。アプリケーションは AWS ECS で稼働させていて、そのアプリケーションが Google Cloud の Vertex AI (Generative AI, Code Execution) 経由で LLM の呼び出しやグラフ化のためのコード実行を行います。データソースは現在は BigQuery となっていて、生成されたグラフや SQL は GCS に置かれます。AI エージェントのフレームワークは Google ADK です。Session というのは平たく言うと Google ADK がユーザの問い合わせ内容やユーザの管理を行うものです。Vertex AI をバックエンドにしてそれを管理することもできますがレイテンシ軽減のために RDS に格納するようにしています。

リージョンがバラバラになっているのですがこれにはいくつかの運用上の理由があります。

AWS ECS: カンムのメインのインフラなので。アプリケーションデプロイ〜モニタリングまでの一式の自動化やクレデンシャルの安全な管理の仕組みが既にある。
Session: Vertex AI のセッションのレイテンシが気になったので近いロケーションに逃がした。
BigQuery: カンムでは BigQuery を長らく運用しておりそのロケーションが US のため。
Code Execution: us-central1 しかサポートされていないため。
GCS: 日本なので。
Generative AI: Gemini 3 Pro などの最新モデルは global ロケーションでしか使えないため。また Claude など Google 外に存在する LLM を呼び出すこともできるのだがそれも global である必要があるため。

5. AI 利用のガバナンス

需要がありそうなので AI 利用のガバナンスについて触れておきます。カンムではもちろん LLM を利用する際はそのベンダのデータの取り扱いとモデルごとの利用規約を重視します。

Synapse はシステム構成で述べた通り Vertex AI 経由で Gemini 3 Pro を利用しています。また Vertex AI 経由で Claude のモデルも...と書いた通り、設定を変えれば Claude のモデルを利用することもできます。ただしプライバシーポリシーや利用規約が Claude を直接使うのと異なる可能性があるのでもし似たような構成を敷こうと考えている方は注意した方がよいです。

冒頭でも述べた通り、カンムでは以下のようにして Claude や Gemini はすでに業務で活用しています。

ユーザ (我々) -> Claude
ユーザ (我々) -> Gemini

しかしこの構成は次のようになります。

ユーザ (我々) -> Vertex AI -> Gemini
ユーザ (我々) -> Vertex AI -> Claude

このとき Claude が Vertex AI から送信されたデータをどう扱うか？Vertex AI 自体が Claude に送信するデータをどう扱うか？について注意が必要です。以下が私が参照したドキュメントで、これらのドキュメントを元にカンム社内のポリシーの整理を行いました。釈迦に説法かとは思いますが各種利用規約やプライバシーポリシーは目を通しておくべきです。

Google Cloud 公式
- Claude モデルのドキュメント: https://docs.cloud.google.com/vertex-ai/generative-ai/docs/partner-models/claude :
- パートナーモデル(Claudeなど)のデータ取り扱い: https://docs.cloud.google.com/vertex-ai/generative-ai/docs/partner-models/use-partner-models
- ZDR の説明: https://docs.cloud.google.com/vertex-ai/generative-ai/docs/vertex-ai-zero-data-retention
- サービス固有の規約: https://cloud.google.com/terms/service-terms
Anthropic 公式
- Consumer向け規約がAPI/Vertex AIに適用されないことを明記: https://www.anthropic.com/news/updates-to-our-consumer-terms
- Vertex AI 専用の商用利用規約: https://www-cdn.anthropic.com/471bd07290603ee509a5ea0d5ccf131ea5897232/anthropic-vertex-commercial-terms-march-2024.pdf
- 商用API向け規約: https://www.anthropic.com/legal/commercial-terms
- ZDR契約に関する説明: https://privacy.claude.com/en/articles/8956058-i-have-a-zero-data-retention-agreement-with-anthropic-what-products-does-it-apply-to

加えてですが、AI というよりは一般的なシステム運用の観点においても BigQuery を始め Google Cloud に入るデータやその保存ポリシーについてももちろんコンセンサスがとられた上で運用を行っています。

6. 課題と方針

とりあえず運用を開始して使ってもらっていますが課題は山盛りです。課題と向き合いつつ大事にしている方針を書いておきます。

AI の最新情報に追従しつつ地に足をつけた運用をする

この分野は毎月のようにアップデートがあり、 LLM のアップデートや新製品が出るたびに刺激的な言葉が踊ります。しかしながら、例えばモデルを例にとっても Gemini 3 Pro <-> Claude Opus 4.5 のような切り替えを行っても何かが劇的に変わることはありませんし我々の課題の根本解決にはならないです。ある程度使うモデルは固定したまま Synapse の特に回答精度の改善に注力すべきです。もしかしたら根本解決手段が上位のモデルを使うことであるかもしれませんが要素はそれだけではないはずです。数打ちゃ当たれのような思考でモデルやツールスタックをコロコロ切り替えていると何が効いたのかがわからなくなります。AI 利用のガバナンスの項目で Claude のモデルに切り替えることもできると触れましたが、基本的には現在使っている Gemini シリーズで評価と運用を行っていきます。とはいいつつどこかで他モデルの検証や切り替え判断のポイントを設けようと思っています。強力な武器や新しい概念が出てきたときはドラスティックにそれに変更する決断も必要です。チェックポイントは設けつつもある程度は今のスタックで課題解決を行う方針でいます。

セマンティックレイヤーの運用

セマンティックレイヤーはデータの意味やロジックを明示化するもので、正体は Synapse が読み込むテキストファイルです。カンムのデータベースに存在するテーブルやカラムの説明が書かれているもの (※) でその量は膨大です。これの拡充および精緻化が回答の精度にも繋がるのでここの運用をどう回すかが鍵になっていると考えています。セマンティックレイヤーは一度作って終わりではなくプロダクトや施策の変化に応じて継続的なメンテナンスが必要になるのですがその運用をどう回していくかが大きな課題になっています。

※ RAG とは違います。RAG は使わないのか？と思う人もいるかもしれませんが、上記地に足をつけた運用の箇所でも書いた通り目の前の課題を明確にしたうえでツール導入は行う方針です。

Text-to-SQL の評価

Synapse のコア機能は自然言語からの SQL 生成と実行です。これの精度をどう評価するか...。

SQL の正しさ（実行可能か）
意味の正しさ（問いに答えているか）
再現性（同じ質問で同じ結果が出るか）

Agent フレームワークとの付き合い

今は Google ADK の Python 版 (※) を使っています。が、やはり各ベンダーもそれに該当するソフトウェア (OpenAI: OpenAI Agents SDK, Anthropic: Claude Agent SDK) をリリースしており今後の業界の勢力図やスタンダードがどうなっていくのかを注視しています。

※ adk-python

チャット機能の運用と開発

UX に関わる部分です。今は Streamlit を使っています。最近 Streamlit よりは FastAPI だという情報が出回ったのを観測していて、そもそもフロントは自分で作らないという案も考えていたりします。たとえば Claude Desktop をフロントにして裏側に Synapse を配置する構成など…。

フィードバックをどう得るか

Synapse は社内プロダクトなので性善説に基づいたフィードバックは得やすいのですがその設計自体をどうするか...。現在は Synapse の回答内容に :+1: or :-1: のバイナリフィードバックのみを受けることができるようにしているのですが、それでもボタンを押してくれる人は少ないです。ユーザ (社員) のフィードバックを受けて改善に回すような仕組みが必要です。

7. まとめ

Synapse という社内のデータ分析を支援する AI エージェント開発についてコンセプトを述べた
カンムでは「SQLで探索し、仮説検証を高速に回す文化」が価値を生んできたため、Synapse もその延長として特に探索フェーズの反復を高速化することにフォーカスした
Synapse は自然言語 → SQL生成 → 実行 → 可視化 → 要約 → 仮説候補提示までを一貫して支援し、分析者の試行回数を増やす
一方で、Synapse の出力は常に「仮説候補」であり、評価・選別・意思決定は人が行う（AIが意思決定するツールではない）
精度を担保するために、セマンティックレイヤー（データの意味の辞書）を事前に整備し、LLMが意味を取り違えにくい構造にしている
実運用では、モデルやツール選定の浮つきよりも「回答精度の改善」「セマンティックの運用」「Text-to-SQL評価」「フィードバック設計」が主要な課題になるが、業界の変容は常に注視している。
このようなソフトウェアを作るときはデータの取り扱い・利用規約・ZDR などのガバナンス整理が不可欠である。
そして AI が当たり前になった今だからこそ、どこを人が担いどこを AI に任せるかを意識的に設計することが重要だと考えている。

カンムでは一緒に働く仲間を募集しています。

team.kanmu.co.jp

おわり