kubell Creator's Note

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

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

読者になる

データ活用AIエージェントの構築で見えた、Snowflake Intelligenceの可能性

こんにちは。
プロダクトDivでデータアナリスト・アナリティクスエンジニアをしているタダケンです。

データ活用技術の進化は目覚ましいですが、最近特に注目しているのが Snowflake Intelligence(以下、SI)です。

kubellでも、プロダクト・事業戦略目標の達成に向けて、この新しい技術のポテンシャルをいち早く検証すべく、PoC的に実証実験を行っています。

今回は、Snowflake Intelligenceの技術的な概要と、実際にPoCを通じて見えてきた「分析用AIエージェントを実用化するためのコンテキストの育て方」について、具体的な知見を紹介したいと思います。

Snowflake Intelligenceの概要

Snowflake Intelligenceは、自然言語を用いてデータと対話し、インサイトの抽出からアクションの実行までを包括的に支援するインターフェースです。実態としては、複数のコンポーネントで構成されています。

Cortex Analyst(構造化データ分析)、Cortex Search(非構造データ検索)、Cortex Agents(自動タスク実行)を通じて、対話形式で洞察を得られれます。

弊社で主に活用しているのが、以下2点になります。

  1. Cortex Agents: ユーザーからの自然言語の問いかけを受け取り、ツール選択やタスク実行を行うオーケストレーター。
  2. Cortex Analyst (Semantic View): データの意味(セマンティック)、文脈(コンテキスト)を定義し、自然言語を精度の高いSQLに変換するセマンティックレイヤー。

これらとdbtで構築したデータモデルを組み合わせて、AIエージェントを構成しています。

簡単な概念図

ユーザーが直接触れるのはAgentの部分ですが、私たちデータエンジニアやアナリストが注力すべきなのは、後者の Cortex Analyst (Semantic View) の構築と運用にあると私たちは考えています。

実は大事な分析基盤の整備

少し話が脱線しますが、dbtでのデータモデルの整備を地道に行ってきたおかげで、比較的早期にSIの恩恵を受けやすくなっています。主要な集計ロジックが分析基盤側にあるおかげで、BIでもみても、AIエージェントで問い合わせをしても同じデータ定義でデータを確認できる環境を整えてきた強みが発揮されました。

kubellの分析基盤

このあたりの詳しい内容はご興味があれば、以下の資料もご覧ください。

speakerdeck.com

Semantic Viewの重要性:AIに「文脈」を教える

検証を進める中で痛感したのは、「データさえあればAIが勝手に分析してくれる」という魔法のような世界はまだ先だということです。

AIが高い精度で回答するためには、AIが理解できるようにデータの意味(セマンティック)、文脈(コンテキスト)を定義してあげる必要があります。

この役割を担うのが Semantic View です。これは従来のデータモデルの上に位置する「(概念としての)セマンティックレイヤー」です。

  • ビジネスロジック: 「解約」の定義や、「アクティブユーザー」の計算条件。
  • ドメイン知識: 特定のプランやキャンペーンに関する社内用語。
  • 除外条件: テストデータや特殊な顧客の扱い。

こうした人間の暗黙知を、AIが理解可能な形(メタデータ)として記述していく工程は、コンテキストエンジニアリングと呼ばれ、非常にエンジニアリング要素の強い作業です。

分析用AIエージェントにおけるセマンティックとコンテキストの育て方

では、具体的にどのようにしてSemantic Viewを「育てていく」のか。kubellでの取り組み事例をもとに、いくつかのポイントを紹介します。

1. Descriptionを詳細に記述する

データベースのコメント機能以上に、Semantic ViewにおけるDescriptionは重要です。これはAIへの直接的な指示書となります。 特に Custom Instructions(カスタム指示) の設定が肝になります。

  • Question categorization: データからは回答できない質問(例:「来月の株価は?」など)に対する振る舞いを定義します。
  • SQL generation: SQL生成時の厳格なルールを記述します。例えば、「株主優待プランのデータは特定の分析以外では除外する」といったガバナンスルールをここで制御します。

2. カラム単位での丁寧な補足

Semantic Viewの作成時、ある程度の定義をYAML形式で自動生成してくれますが、実用レベルにするには人間による補正が不可欠です。

  • Dimensions / Measuresの再定義: 分析の意図に合わせて、集計軸(Dimension)と数値指標(Measure)を正確に定義し直します。
  • Synonyms(同義語)の登録: 「MRR」「ARR」などの専門用語や、社内でしか通じない略語を登録し、表記ゆれに対応させます。
  • Sample Values: コード値などが何を意味するのか、具体的な値を例示してAIの理解を助けます。

地道な作業ですが、ここを丁寧に作り込むかどうかが、回答精度の分かれ道になります。

3. Verified Queriesによるサンプルクエリの拡充

これが最も効果的なテクニックだと感じています。

複雑な集計ロジックや、頻出の質問パターンを、「質問と正解SQLのペア」としてSemantic Viewに登録(Verified Queries)しておきます。

AIはこれらの正解例を参照し、応用することで未知の質問にも答えられるようになります。

「週ごとのライセンス数の推移を算出する」というSQL例を一つ教えておけば、「四半期別で見たい」「部署別にみたい」といった応用的な質問にも対応できるようになります。

まさにAIを教育していく感覚に近いです。

4. 利用と育成のサイクルを回す

Semantic Viewは一度作って終わりではありません。むしろ、リリースしてからが本番です。 重要なのは、「ユーザーに使ってもらい、そのログを元にコンテキストを育て、さらに使いやすくする」というサイクルを回すことです。

  1. ユーザーに使ってもらう: まずは社内のユーザーに触ってもらい、具体的な質問を投げてもらいます。
  2. 利用状況をモニタリングする: ユーザーがどのような問いかけをし、AIがどのようなSQLを生成したかは全てログに残ります。
  3. コンテキストを育てる: 「意図しないSQLが生成されている」「答えられない質問がある」といった課題を見つけ、dbtでカラムを追加したり、Semantic View(DescriptionやVerified Queries)を修正・追記します。
  4. 使いやすくなる: コンテキストが育つことで、AIの回答精度が向上し、ユーザーにとってより使いやすいエージェントへと進化します。

この辺りのモニタリングがデフォルトでできるのがSnowflakeの強みだと思います。

このサイクルを高速で回し、エージェントを「育てていく」プロセスこそが、AI活用の成功の鍵となると、私たちは考えています。

まとめ

今回の検証を通じて、AIエージェント活用の本質は「ツール導入」ではなく、「育成」にあると再確認しました。

  1. AIが理解しやすいデータ環境(Semantic View)を設計する。
  2. まず使ってもらう(ユースケースを探る)
  3. ユーザーの利用ログをモニタリングする。
  4. フィードバックをもとに、定義やセマンティック・コンテキストを修正し続ける。

この育成サイクルを回すことこそが、これからのデータエンジニア・アナリストの重要な役割になっていくと考えています。

泥臭い作業ではありますが、エンジニアリングによってAIの精度が上がり、ビジネスの意思決定に寄与していく過程は、非常にやりがいを感じるポイントです。

まだまだ道半ばでチャレンジ中な部分もありますが、データ活用におけるAI推進をされている方の参考になれば幸いです。

株式会社kubellでは、データとAIを活用して新しい価値を創造したいアナリスト・データエンジニアを募集しています!

hrmos.co

hrmos.co

hrmos.co