こんにちは。
プロダクトDivでデータアナリスト・アナリティクスエンジニアをしているタダケンです。
前回の記事では、Snowflake Intelligence（以下、SI）における「コンテキスト（Semantic View）の育て方」についてお話ししました。
今回は、そのコンテキストを利用する側である「分析エージェント自体の設計」について、kubellでの実践事例を交えて紹介します。
「全社員向けの万能エージェント」を作るべきか、それとも「特定用途のエージェント」を作るべきか。現在進行系で検証を進めている私たちの解は、「エンドユーザーの職種（ユースケース）ごとにエージェントを立てる」というアプローチです。
分析エージェントの基本アーキテクチャ
Snowflake Intelligenceを用いたエージェント構築においては、大きく2つのコンポーネントが登場します。
- Cortex Agent: ユーザーと対話し、適切なデータやツールを選択して回答を生成する「頭脳」。
- Semantic View: 自然言語をSQLに変換するためのデータ定義層（コンテキスト）。
技術的には、1つのCortex Agentに全社のあらゆるSemantic Viewを紐付けることも可能です。しかし、私たちはあえて「1つの職種（役割）につき、1つのAgent」という設計方針をとっています。
例えば、「事業管理AIエージェント」や「プロダクト分析AIエージェント」といった具合です。
なぜ職種別にエージェントをわけるのか？
最大の理由は、「コンテキストの境界」を明確にするためです。
ユースケースを絞ったほうが、性能評価なども含めて、エージェントの開発業務はやりやすいのです。ですが、ユースケースを絞り込みすぎて、例えば、特定業務のリスト抽出にしぼると、「それ、BIでよくない？」という問いが頭をよぎります。
一方で、ユースケースを広く取り過ぎてしまうと、守備範囲がいたずらに広がってしまい、実際にスピード感を持っての価値提供がしにくくなってしまいます。一般的にコンテキストが多すぎるとLLMは精度が落ちていきます。具体的に検証したわけではないですが、アウトプット精度の安定化をさせる意味でも守備範囲を適切にコントロールしたほうがいいと考えています。
そのため、kubellにおいては「エンドユーザーの職種（ユースケース）ごとにエージェントを立てる」というアプローチを軸にしています。
1.UXの最適化
職種ごとに「よくある質問」や「回答のトーン」は異なります。エージェントを分けることで、その職種に特化した振る舞いを定義しやすくなります。それぞれの文脈に合わせたSemantic Viewのみを参照させることができます。
売上のSemantic Viewは事業管理がアクセスする、アクティブユーザーのSemantic ViewはプロダクトAIがアクセスするといった管理がしやすくなります。
2.用語の衝突回避
同じ「ライセンス数」という言葉でも、事業管理部門とプロダクト部門では使われ方は異なります。エージェントを分けることで、同じSemantic Viewに対しても、別のコンテキストを当てることができます。
例えば、事業管理AIとプロダクト分析AIでライセンス数推移という同じSemantic Viewにアクセスはさせますが、使い方は違うといったケースにも対応しやすくなります。
事業管理観点だと、従業員規模や職種といった点で関心が強い、プロダクト開発観点だと、デバイスごと、OSバージョンごとといった点に関心が強いといった違いなどもあります。（こういった違いは実際に利用されてみて、ログを見て気がつきました）
実践事例：事業管理AIエージェント
現在検証を進めている、事業管理部向けの「事業管理AIエージェント」で、具体的な内容をご紹介します。
事業管理の皆さまは普段、SalesforceやBIツール（Exploratoryなど）、Spreadsheetを駆使して、事業数値のモニタリングや要因分析を行っています。この業務をチャットインターフェースで支援することが目的です。
このエージェントには、ツールとして以下の2つのSemantic Viewへのアクセス権を与えています。
1. ライセンス購入の変更履歴 これは、ライセンス購入の変更履歴をベースにしたSemantic Viewです。
- 役割: 「時系列の推移」を分析する。
- 答えられる問い:
- 「先月のライセンス純増数は？」
- 「解約の推移を月別に見せて」
- 「プランごとのアップグレード数は？」
2. 現在時点での組織の最新情報 これは、組織ごとの現在の契約状態や属性情報をベースにしたSemantic Viewです。
- 役割: 「現在の状態（スナップショット）」や「属性」を分析する。
- 答えられる問い:
- 「現在の有料契約組織の業種別内訳は？」
- 「従業員数100名以上の企業のリストを出して」
エージェントの振る舞い ユーザーが「従業員規模別の解約率の推移を知りたい」と質問すると、エージェントは自律的にこれら2つのSemantic Viewを使い分けながら、SQLを生成して回答します。
私たちは、このように「目的別のSemantic View」を用意し、それをエージェントというインターフェースでつなぎ合わせるアプローチをとっています。
エージェント設計のポイント
このアーキテクチャで重要になる設計のポイントは以下の2点です。
Semantic Viewは「部品」として作る
1つのSemantic Viewにすべての結合を含めようとせず、分析の軸（ディメンション）やファクトごとにViewをモジュール化しておきます。
dbtのモデル設計に近い話（というか切っても切れない話）になるのですが、「1つのテーブルで1つの分析ユースケースにある程度答えられる」ような、比較的ワイドなテーブル（Wide Table）として作成しています。
- Physical Table : Semantic View = 1 : 1：dbtで作られた最終レポート層の物理テーブルとSemantic Viewは基本的には1対1で対応させます。
- 複雑さを排除：結合（Join）などの複雑な処理はdbt側で済ませておき、Semantic Viewはあくまでそのワイドテーブルを自然言語で検索しやすくする役割に徹します。
一方で何でもかんでも含んだ巨大なテーブルにしてしまうと、取り回しがしにくくなります。
あくまで時系列の分析をするときはこれ、最新断面のデータを使って分析するときはこれといった、分析観点での分析SQLの作りやすさを大事にしつつ、テーブル、Semantic Viewの設計をしています。
この辺りの落とし所がアナリティクス・エンジニアの腕の見せ所だと思っています。
また、Semantic Viewを部品として作ることにより、他のエージェント（例：カスタマーサポート用エージェントなど）が必要になった際も、同じViewを「部品」として再利用できます。
エージェントを「専門家」として定義する
Cortex Agentのプロンプトには、そのエージェントのペルソナを明確に記述します。「あなたは事業管理の専門家です。数値の整合性を最重視し、曖昧な場合は内訳を確認してください。事業管理メンバーの質問に回答し、事業目標の達成のための支援を行なってください」といった指示を与えることで、職種ごとの特徴に合わせたエージェント設計をすることができます。
また、職種ごとにエージェントを分割することで、Cortex AgentsのExample Questionsも設定しやすくなります。
事業管理AIエージェントの場合は
- 月別のライセンス純増数の推移は？
- 現在の有効な組織数を業種・プラン別に算出した上で、特徴を教えて
- 利用開始時期別に有料転換率を算出して
といった、Example Questionsを設定しています。
まとめ
- One Agent per Role: 全社統一ではなく、ユーザーの職種ごとにエージェントを立てる。
- Context as a Tool: データ（Semantic View）は、エージェントが利用する「道具」として部品化して提供する。
この構成により、各エージェントはそれぞれの領域の「専門家」として振る舞いつつ、裏側のデータ定義（Semantic View）は適切にガバナンスを効かせた状態で管理・再利用が可能になります。
Snowflake Intelligenceは、単にデータをチャットで検索機能を提供するだけでなく、こうした「組織ごとの分析コンテキスト」を実装するための柔軟な基盤を提供してくれています。
現在はプロトタイプ段階ですが、今後は実際に事業管理部やプロダクト開発のメンバーに使ってもらいながら、フィードバックループを回してエージェントを「育成」していく予定です。
最後に
まだまだ道半ばでチャレンジ中な部分もありますが、データ活用におけるAI推進をされている方の参考になれば幸いです。
また、エージェントを介してデータのアクセスコントロールをどのようにおこなっているかについてはデータエンジニアリンググループのじまさんがきっと記事を書いてくれる予定です。
株式会社kubellでは、データとAIを活用して新しい価値を創造したいアナリスト・データエンジニアを募集しています！
