はじめに

株式会社シロクでデータエンジニアをしている文翔（かざりしょう）です。こちらはCyberAgent Developers Advent Calendar 2025 20日目の記事です。

シロクは「N organic」や「FAS」などのブランドを展開するスキンケアブランドの会社であり、顧客体験の向上のために日々多様なデータが活用されています。現在、シロクではAIを使った分析によって、少ない工数で成果を最大化する取り組みを行なっております。

本記事では、どのようにAI分析基盤とAI エージェントを構築しているかの現在の取り組みについて紹介します。

データ分析の課題

各ブランドの成長に伴い、データに基づく意思決定の重要性が増しており、複数の事業部からデータチームへのレポート作成や分析依頼が増加しています。その一方で、以下のような課題が顕在化してきていました。

分析依頼の増加によるリソースの低下。
類似の分析やアウトプットの増加。
AI活用による効率化ニーズが高まり。
クエリの誤用によるリスクの拡大。

ここで、Slackで分析依頼を投げるだけで、Snowflake側でSQLを生成・実行し、結果をSlack上に返すプラットフォームを構築することで、これらの課題を解決を試みました。これにより、Snowflakeにアクセスできない人でも、簡単にかつ正確な分析を提供することを実現できると考えました。

# Snowflake MCPサーバーについて

今回AI分析をするにあたり、Snowflake MCPサーバーの活用を行いました。

Snowflake MCPサーバーは、Snowflake と AI エージェントを接続するための Model Context Protocol（MCP）対応サーバーです。

Snowflakeでは公式に MCP サーバーの実装が提供されており、ローカル開発環境やエディタ（Cursor 等）からSnowflakeを直接操作する用途としても注目されています。

Snowflake MCPサーバーを使うことで、AI から以下のような操作が可能になります。

自然言語による Snowflake データの問い合わせ（Text-to-SQL）
Snowflake 上のテーブルやビューを使った探索的分析
Cortex Analyst / Cortex Search など Snowflake の AI 機能との連携

なお、シロクではn8nを利用し、SlackからSnowflake MCPサーバーを呼び出す仕組みを構築しました。Slack 上の自然言語入力を起点に Snowflake のデータ取得・分析を行えるようにしています。

AI分析基盤の全体像

この仕組みはn8nを通じて、Slackを起点にAIが問い合わせ内容を判断し、適切なSnowflake AgentをSnowflake MCPサーバーを通じて呼び出すフローになっています。

① Slack（入口）
ユーザーは Slack 上で `@` メンションを使い、自然言語で質問を投稿します。

② AI Agent（GPT）
Slack から受け取った質問を AI Agent が解釈し、

どの種類のデータを参照すべきか
どのドメインのSnowflake Agentを使うべきか

を判断します。ここでは問い合わせ内容に応じたAgentの振り分けを行っています。

③ Snowflake MCPサーバー
GPTのAI Agentの判断結果をもとに、Snowflake MCPサーバー経由でSnowflake Agentsを呼び出します。MCPを介することで、Snowflake 側の権限管理やガバナンスを保ったまま、安全にデータ取得・分析を実行を実現しました。

④ Slack へ結果を返却

Snowflake から取得した結果は AI Agent に返され、要約・整形されたうえで Slack にメッセージとして返信されます。

このようにして、Slack → AI → Snowflakeという自然言語ベースのデータ活用フローを実現しています。

ポイント

スキーマー構成

今回、AI Agentが利用する以下のリソースはすべてMART_AIに配置しました。

Semantic Views
Cortex Agents
Cortex Search の検索対象テーブル
会話履歴や補助テーブル（CONVERSATION_HISTORIES など）

これにより、

AI が参照できる範囲をスキーマ単位で制御できる
既存の分析・BI 用マートと責務を分離できる
権限設計がシンプルになる

というメリットがあります。なお、AI Agentが利用する Snowflake ユーザー・ロールについても、MART_AI スキーマのみ参照可能し、他スキーマへのアクセス権は付与しないという設計にしています。


mart_ai/
├─ tables/
│  ├─ conversation_histories/     # 依頼の会話履歴用のテーブル
│  └─ 社内用語のテーブル/            # 社内用語テーブル
│
├─ semantic_views/                # Cortex Analyst 用 Semantic View
│  ├─ fact_[tablesA]/             # ドメインAのセマンティックView
│  └─ fact_[tablesB]/             # ドメインBのセマンティックView
│
├─ agents/
│  ├─ [tablesA]_agents/           # ドメインAのAgents
│  └─ [tablesB]_agents/           # ドメインBのAgents
│
├─ cortex_search_services/
│  └─ word_lists_search/           # 社内用語・補助情報（RAG 用）

この構成にしておくことで、AI Agent を安全かつ継続的に運用しやすい Snowflake設計を実現してます

Semantic Views

Semantic Viewsは、Snowflake の Cortex Analyst が参照するための論理ビューです。SQL や物理テーブル構造をそのまま見せるのではなく、AI が業務指標として理解しやすい形に定義したデータ層になります。
Semantic View では、あらかじめ以下を定義します。

売上や注文数などの業務指標
AI が使ってよいテーブル・カラム
JOIN や集計の前提ルール

これにより、AI AgentはSQL を推測せずに、意味ベースでデータを扱えるようになります。

セマンティックViewはterraformの.tfファイルで管理されており、SQLの定義と一緒にテーブルやカラムの説明を記述しています。


resource "snowflake_semantic_view" "fact_orders" {
  database = "DATABASE"
  schema   = "MART_AI"
  name     = "FACT_ORDERS_SEMANTIC_VIEW"

  # --- 主テーブル ---
  tables {
    table_alias = "FACT"
    table_name  = "\"DB\".\"MART\".\"FACT_ORDERS\""
    primary_key = ["ORDER_ID"]
    comment     = "注文ファクト"
  }

  # --- ディメンション ---
  dimensions {
    qualified_expression_name = "\"FACT\".\"TIMESTAMP\""
    sql_expression            = "\"FACT\".\"TIMESTAMP\""
    comment                   = "購入日時"
  }

  # --- メトリクス ---
  metrics {
    semantic_expression {
      qualified_expression_name = "\"FACT\".\"ORDER_COUNT\""
      sql_expression            = "COUNT(DISTINCT \"FACT\".\"ORDER_ID\")"
      comment                   = "注文数"
    }
  }

  # --- ディメンションテーブルとの関係 ---
  tables {
    table_alias = "DIM_ORDER"
    table_name  = "\"DB\".\"MART".\"DIM_ORDERS\""
    primary_key = ["ORDER_KEY"]
  }

  relationships {
    table_name_or_alias {
      table_alias = "FACT"
    }
    relationship_columns = ["ORDER_KEY"]

    referenced_table_name_or_alias {
      table_alias = "DIM_ORDER"
    }
    referenced_relationship_columns = ["ORDER_KEY"]
  }
}

Cortex Search

Cortex Search は、Snowflake 上の非構造化データを対象にした検索機能です。ドキュメント、テキストログ、問い合わせ履歴などを事前にインデックス化し、キーワード検索やベクトル検索を通じてAIから参照できるようにします。Cortex Search を使うことで、

SQL では扱いづらいテキストデータ
FAQ、問い合わせ履歴、説明文などの文章

を AI Agent が検索・要約できるデータソースとして扱えるようになります。

今回Cortex Searchは、社内用語や業務知識といった非構造化な情報を AI Agent に渡すために活用しています。仮に、社内で「メロン」といいう言葉が「POS」という意味をさしていた時、このようなユーザーの言葉とデータ定義のズレを埋めるために、社内用語テーブルを Cortex Search に登録し、RAG として AI Agent から参照させています。

処理の流れはシンプルで、

ユーザーの質問を AI Agent が受け取る
Cortex Search で社内用語・補足情報を検索
検索結果を文脈として AI Agent に渡す
どのデータを見るべきかを判断する

という形です。この構成により、ユーザーは用語AI Agent が「何を指しているか」を補完できる。構造化データにつなげやすくなるという効果がありました。

Cortex Search は、検索そのものよりも「AI が判断するための知識を補う用途」で使うと相性が良いと感じています。

Cortex Agents

Cortex Agentsとは、自然言語の質問を起点に、Snowflake 上のデータ分析や検索を自動化する AI エージェント機能です。構造化/非構造化データの両方を扱え、ユーザーの質問を理解したうえで必要な処理を判断し、適切な Snowflake の機能を呼び出して結果を返却し、内部では主に以下の機能が使われます。

Cortex Analyst：構造化データに対する SQL 自動生成・分析
Cortex Search：非構造化データに対する検索（RAG）

Snowflake 内で完結するため、既存の権限管理やガバナンスを保ったまま AI を活用できるのも大きな特徴です。

Snowflake AI Agents を使う際のポイントは、1つのAgentを万能にしないことだと考えています。下の図のように、業務ドメインごとに役割を分けた Agentを用意しており、自分のドメインのデータマートだけにアクセスできる構成にしています。

ユーザーは「POSの売上は？」のように曖昧な質問を投げますが、どのAgent使うかは最初のAI Agent（ルーティング役）が判断してもらい、そのドメインに特化したAgentsが分析してもらうことで、より精度を高めることをここ見ました。

また、各AgentsのOverviewには、「あなたは〇〇に詳しいデータアナリストです」といったAgentsの役割を日本語で明確に記述しています。これだけで、回答のブレがかなり減りました。

アウトプット

最終アウトプットは以下のようになりました。依頼に対して、Snowflake MCPサーバーを経由して分析結果を出しているのがわかります。なお、結果は全てダミーデータになります。

まとめ

本記事では、シロクにおける Snowflake を中心とした AI 分析基盤と AI Agent の構成について紹介しました。ポイントは、「AI を賢くする前に、AI が安全に・正しく使えるデータの形を整えること」だと考えています。

Snowflake MCP サーバーを使い、Slack から自然言語で分析できる入口を用意
MART_AI スキーマに AI 用リソースを集約し、権限と責務を明確化
Semantic Views で「AI に見せたい業務指標」を定義
Cortex Search で社内用語や暗黙知を補完
Cortex Agents を業務ドメインごとに分け、精度とガバナンスを両立

これにより、分析依頼の属人化を減らしつつ、AI を実務で使える形に落とし込むことができました。AI 分析は「ツールを入れること」よりも、データ設計・権限設計・Agent の役割分担が重要だと感じています。

まだ試行錯誤の途中ですが、同じように AI 活用を検討している方の参考になれば幸いです。最後まで読んでいただき、ありがとうございました。

本記事内で使用している Snowflake および Snowflake のロゴは Snowflake Inc. の商標または登録商標です。
本記事は Snowflake Inc. による公式な見解・提供ではなく、筆者個人の取り組みを紹介するものです。

Cloudflare Tunnel で内部公開の Cloud Run にアクセスしてみる

Snowflake MCPサーバーを使ったAI分析基盤の構築

目次