❄️
Snowflake MCP ServerとMCPクライアントで実現するAIエージェント時代のデータ分析基盤構築

2025/10/06に公開
Snowflake
Model Context Protocol
Cursor
Claude
tech
こんにちは。

株式会社アシストにてMDSエンジニア・Snowflakeエンジニアをしている山本です。

業務ではお客様のSnowflakeを中心としたデータ分析基盤の構築支援を行っています。

 Snowflake MCP ServerとMCPクライアントで実現するAIエージェント時代のデータ分析基盤構築2025年、急速に発展してきたMCP(モデルコンテキストプロトコル)と、Snowflake Labs[1]で開発されているSnowflake OSS MCP Serverを活用し、これからのAIエージェント時代のデータ分析基盤をどのように設計・構築していくかを機能検証しながら考えてみます。
!この記事は約20分で読めます。

 背景と最新動向Snowflakeコミュニティ製のものとして2025年5月(Git履歴)からSnowflake Labsでひっそりと開発がされていたSnowflake OSS MCP Serverを、2025年7月からSnowflake社が公式的にアナウンスするようになったようです。

https://www.snowflake.com/en/blog/mcp-servers-unify-extend-data-agents/
2025年10月現在、Snowflake MCP Serverについての記事を調べても数記事しかなく、Snowflake MCP Serverでは何ができるの？という方もまだまだ多いのではないかと思います。

https://zenn.dev/search?q=Snowflake%2520MCP
Mediumの記事ではそこそこ存在しており、Snowflake本国ではかなり検証されてきているのではと感じられます。

https://medium.com/search?q=Snowflake+MCP
!この記事を書いている内に、Snowflake-managed MCP Serverが公開されました。
この記事ではOSS MCP Serverにのみ触れています。

 そもそもMCPとはモデルコンテキストプロトコル（MCP）は、開発者がデータソースとAI搭載ツール間の安全な双方向接続を構築できるようにするオープンスタンダードです。アーキテクチャはシンプルで、開発者はMCPサーバーを介してデータを公開するか、これらのサーバーに接続するAIアプリケーション（MCPクライアント）を構築することができます。(Google翻訳)

https://www.anthropic.com/news/model-context-protocol

目的: AIエージェントが同一プロトコルでツール群を安全利用すること

利点: 実装の共通化、開発・運用コスト削減、監査容易性
MCPが発表されて以降、各サードパーティー製品もこぞってMCPサーバーを公開しています。

https://github.com/modelcontextprotocol/servers
!公式サードパーティー製のものから、公式コミュニティ製のもの、非公式コミュニティ製のもの、個人製のものと多種多様のものが存在しているため導入は慎重に行うことを推奨します。

特に個人製・非公式コミュニティ製を導入する場合には注意が必要だと思われます。
私もメイン課金IDEを、長年愛用していたPyCharmからCursorに乗り換えたぐらいなので、サードパーティー製品群とAIエージェントをMCPサーバーで連携できるというのはインパクトが大きいのではないかと思います。

企業において業務上でのAIエージェント実行が主流になれば製品導入の際に、MCPクライアントとして機能するのか？MCPサーバーで連携できる製品なのか？が重要視されてくるのではないでしょうか。

 Snowflake OSS MCP ServerでできることSnowflake OSS MCP Serverの概念図(自作)

Cortex Search : Retrieval Augmented Generation (RAG) アプリケーションで一般的に使用される方法で、Snowflake 内の非構造化データをクエリします。

Cortex Analyst : 豊富なセマンティック モデリングを介して、Snowflake 内の構造化データをクエリします。

Cortex Agent : 構造化データと非構造化データの検索をエージェント的にオーケストレーターで実行

Object Management: 作成、削除、更新など、Snowflake の最も一般的なオブジェクトに対して基本的な操作を実行します。

SQL Execution: ユーザーが設定した権限によって管理される LLM 生成の SQL を実行します。

Semantic View Querying：Snowflakeセマンティックビューの検出とクエリ
https://github.com/Snowflake-Labs/mcp
なんと9月初旬のSWT2025まではオブジェクト管理・CortexAnalyst・CortexSearchのみの対応と言っていたのに、10月現在はCortexAgentとセマンティックビューの検出とクエリも対応したようです....

アップデートスピードが速すぎる....
MCP Serverがどのように構築されているか気になる方はGithubのソースコードを解析すると良いと思います。

 実際にMCP ServerでSnowflakeインフラを構築・運用してみた実際にSnowflake OSS MCP Serverを導入する手順についてはSnowflake社の菅野さんの記事が参考になります。

https://zenn.dev/tsubasa_tech/articles/70ab5fb2b5ed99
!今回はClaude Desktopで行っていますが、設定手順はCursorと同じです。
!生成AIにデータベース内に入っている企業情報を流す際には所属企業のガバナンスに従うことを推奨します。

この記事ではMarketplaceに提供されている無料のUS_REAL_ESTATEというアメリカの住宅情報のデータセットを使用しています。

 ・Object Management / SQL Execution




特にどんなデータベースなのかコメントしていなくても解釈してくれて表示してくれます。環境内作成の標準データベースやMarketplaceからのインポートデータベースなど種類ごとに表示してくれるのが分かりやすいですね。
CREATE(テーブル作成)・INSERT(データ挿入)・SELECT(データ選択)も自然言語で行えます。






 ・Semantic View Querying
!執筆時点ではSemantic Viewの機能は追加されたばかりのようですので、万が一期待通りに動作しない部分を発見したらGithubのIssuesで報告しましょう。
では、実際にCortex Analystを作成するためにセマンティックモデルを作成してもらいましょう。
!Marketplaceのデータセットに対してオブジェクト操作はできないため、標準データベースにコピーする必要があります。




作成した構文を出力するためにDesktop CommanderのMCPが必要になっています。この辺りの複数のMCPが連携しあって問題解決を行っていくというのがMCPのコンセプトですね。


作ってくれたセマンティックモデルを見てみましょう。適切そうな名前も付けてくれています。
セマンティックモデルの内容 yamamoto_semantic.yaml
model_version: 1

tables:
  - name: house_price_index
    description: "Housing price index data from FHFA showing price trends"
    base_table: 
      database: YAMAMOTO
      schema: REAL_ESTATE  
      table: HOUSE_PRICE_INDEX
    dimensions:
      - name: geo_id
        synonyms: [geography_id, location_id]
        description: "Geographic identifier"
        expr: GEO_ID
        data_type: varchar
      - name: geo_name
        synonyms: [location_name, geography_name, area_name]
        description: "Geographic area name"
        expr: GEO_NAME
        data_type: varchar
      - name: geo_level
        synonyms: [geography_level, location_level]
        description: "Geographic level (State, County, Metro Area)"
        expr: GEO_LEVEL
        data_type: varchar
      - name: property_classification
        synonyms: [property_type, housing_type]
        description: "Property classification (traditional, distress-free)"
        expr: PROPERTY_CLASSIFICATION
        data_type: varchar
      - name: index_type
        synonyms: [measurement_type, index_method]
        description: "Index calculation method (all-transactions, purchase-only)"
        expr: INDEX_TYPE
        data_type: varchar
      - name: frequency
        synonyms: [reporting_frequency, data_frequency]
        description: "Data reporting frequency"
        expr: FREQUENCY
        data_type: varchar
      - name: date
        synonyms: [reporting_date, period, time]
        description: "Date of the measurement"
        expr: DATE
        data_type: date
    measures:
      - name: price_index_value
        synonyms: [price_index, housing_price_index, hpi_value]
        description: "Housing price index value"
        expr: VALUE
        data_type: number
        agg: avg
      - name: avg_price_index
        synonyms: [average_price_index, mean_price_index]
        description: "Average housing price index"
        expr: AVG(VALUE)
        data_type: number
      - name: max_price_index
        synonyms: [highest_price_index, peak_price_index]
        description: "Maximum housing price index"
        expr: MAX(VALUE)
        data_type: number

  - name: construction_data
    description: "Construction permits and spending data"
    base_table: 
      database: YAMAMOTO
      schema: REAL_ESTATE
      table: CONSTRUCTION_DATA
    dimensions:
      - name: geo_id
        synonyms: [geography_id, location_id]
        description: "Geographic identifier"
        expr: GEO_ID
        data_type: varchar
      - name: geo_name  
        synonyms: [location_name, geography_name, area_name]
        description: "Geographic area name"
        expr: GEO_NAME
        data_type: varchar
      - name: geo_level
        synonyms: [geography_level, location_level] 
        description: "Geographic level (State, County, Metro Area)"
        expr: GEO_LEVEL
        data_type: varchar
      - name: building_use
        synonyms: [building_type, property_use, construction_type]
        description: "Building usage category"
        expr: BUILDING_USE
        data_type: varchar
      - name: measure_type
        synonyms: [metric_type, measurement]
        description: "Type of measurement"
        expr: MEASURE
        data_type: varchar
      - name: measurement_type
        synonyms: [data_type, estimation_type]
        description: "Measurement methodology"
        expr: MEASUREMENT_TYPE
        data_type: varchar
      - name: date
        synonyms: [reporting_date, period, time]
        description: "Date of the measurement"
        expr: DATE
        data_type: date
    measures:
      - name: construction_value
        synonyms: [value, amount, construction_amount]
        description: "Construction value or count"
        expr: VALUE
        data_type: number
        agg: sum
      - name: total_construction_value
        synonyms: [total_value, sum_construction]
        description: "Total construction value"
        expr: SUM(VALUE)
        data_type: number
      - name: avg_construction_value
        synonyms: [average_construction, mean_construction]
        description: "Average construction value"
        expr: AVG(VALUE)
        data_type: number

  - name: geography_master
    description: "Geographic reference data"
    base_table: 
      database: YAMAMOTO
      schema: REAL_ESTATE
      table: GEOGRAPHY_MASTER
    dimensions:
      - name: geo_id
        synonyms: [geography_id, location_id]
        description: "Geographic identifier"
        expr: GEO_ID
        data_type: varchar
      - name: geo_name
        synonyms: [location_name, geography_name, area_name]
        description: "Geographic area name"
        expr: GEO_NAME
        data_type: varchar
      - name: geo_level
        synonyms: [geography_level, location_level]
        description: "Geographic level"
        expr: LEVEL
        data_type: varchar

relationships:
  - name: hpi_to_geography
    from: house_price_index
    to: geography_master
    join_type: inner
    join_on: 
      - from_column: geo_id
        to_column: geo_id
  - name: construction_to_geography
    from: construction_data
    to: geography_master
    join_type: inner
    join_on:
      - from_column: geo_id
        to_column: geo_id

!作成されたセマンティックモデルを見てみたらエラーが出ていました....



構文が間違っていたみたいなのでこの辺りは精度向上に期待ですね....
作成したテーブルとそのテーブルのリレーションまで解釈してセマンティックモデルを作成してくれています。

Marketplaceのデータセットは綺麗に整備されているのでそのおかげもあると思います。
Semantic Viewの検出とクエリ(中身確認)もやってみます。





セマンティックビュークエリを実行して、セマンティックモデルの構成も理解できているようです。

https://docs.snowflake.com/en/user-guide/views-semantic/querying
今回のセマンティックモデルにはメトリクスが定義されていないのですが、企業におけるドメイン知識をディメンション・ファクト・メトリクスなどに設定していると正しく取得してくれると思われます。

Semantic Modelの全体構成図(自作)

 ・Cortex Search
今回はこちらのチュートリアルで作成するAirbnbのCortex Searchを利用します。
https://docs.snowflake.com/ja/user-guide/snowflake-cortex/cortex-search/overview-tutorials
どんなCortex Searchが利用できるか聞いてみます。

ドキュメントからAirbnbにはどんな部屋タイプが存在しているのか聞いてみます。

Airbnbドキュメントから自然言語で問い合わせができるようです。

 ・Cortex Analyst
登録したCortex Analystで何ができるかを聞いて、分析してもらいました。

US_REAL_ESTATEのデータセットについて解釈して、どのような分析が可能か教えてくれました。


 ・Cortex Agent
!執筆時点ではCortex Agentの機能は追加されたばかりのようですので、万が一期待通りに動作しない部分を発見したらGithubのIssuesで報告しましょう。
設定ファイルに登録しているCortex Agentが認識されているのか確認してみましょう。

ここまでで作成したCortex Analystを登録したAgentを設定に登録しています。

では実際にAgentに質問してみましょう。



どうやらAgentの権限で問題が発生しているようで....

色々試してみましたが原因がわからず....
Cortex Agentを構成しているCortex Analystを使用して迂回した分析を行ってくれました。

Search, Analyst, Agentに関してはアクセス権限をもっているかどうかは設定で確認する必要があります。 Agentを使える権限でアクセスしているのに使えない....
Cortex Agentの構造からCortex SearchとCortex AnalystはCortex Agentの部分集合の関係にあるものですが、MCPを使う上での棲み分けをどうしていくのかは考えていく必要がありますね。

SearchとAnalystの組み合わせによってAgentの解答の精度が変わってくるというのはあり得る話ですので、その辺りの検証も運用していく上では必要になってくると思います。

 MCPサーバーでSnowflakeインフラを自動構築するメリット/デメリットメリット
自然言語な設計書を基にエージェントが再現性高く構築可能（経緯が違っても最終的なアウトプットが設計書に則っているかを見た場合）
監査性・可観測性の向上（Chat単位での指示と実行ログの一元化）
AIエージェント連携により並行作業・自律復旧が可能
デメリット
権限境界の設計ミスがリスクを拡大（設計書が間違っていればエージェントは暴走しかねない）
設計の曖昧さや抜け漏れがそのまま実装に反映される（ドメイン知識がある人間なら修正できるがAIではそのまま実装してしまう）
人手による検証工程を省くと、データ整合性や命名規約逸脱が顕在化
!とりわけMCPを本番適用時は、最小権限・変更申請フロー・監査証跡を前提に計画しましょう。

まだ検証段階な面が大きいMCPを本番環境に適用する方は滅多にいないと思いますが....

 設計書ドリブンな自動インフラ構築という考え方正確な設計書（スキーマ、権限、ワークロード、スケーリング方針）を一次成果物として残し、その設計書をAIエージェントに渡して構築・運用を委譲するのがAIエージェント時代のベストではないかと考えます。この辺りは今後様々なエンジニアが取り組むことでべスプラが出来上がってくると思いますので、各々が考えるべスプラをもみ合っていくのが大切かと思われます。

AIエージェントに丸投げになるようになってくると、さらに設計書のバージョン管理とレビュー、検証観点の明文化が鍵になってくるでしょう。

 まとめ現状ではMCPはローカルPC依存になるため、企業での導入に関してはガバナンスの面から難しいところが多いと考えられます....
そういったことも踏まえてなのか、SnowflakeはSnowflake上で管理されたMCP Serverを開発中のようです。
Snowflake managed MCP servers are coming soon to Cortex AI

Snowflake Cortex AI MCP servers are on the way. The managed MCP servers will enable agents to remotely and securely retrieve data from Snowflake accounts without the need to deploy your own server infrastructure. MCP is revolutionizing AI interoperability by providing a standardized framework for integrating AI models with external tools! It is poised to become the default protocol for agent communication with tools and resources.

https://www.snowflake.com/en/blog/mcp-servers-unify-extend-data-agents/
ClaudeDesktopやCursorは設定管理をするのはローカルになるため企業導入が難しいところが、Snowflake上で組織で管理されたMCPサーバーによるAIエージェント実行ができるならばより導入しやすくなるかと思います。
ClaudeはEnterpriseエディションでMCPの組織管理はできるそうです。
そうなってくると、加速していくAIエージェント時代において"人力"での検証を組み込むというのが重要になってくるのではないかと考えられます。

人の手を介さずデータベースが構築される時代が現実になりつつあるからこそ、人間による整合性テスト・レビュー・命名規約チェック・データ品質検証をパイプラインに組み込むことが重要になってくるのではないでしょうか。
人間が考えたSQLでのデータベース構築
↓
TerraformといったIaCでのデータベース構築
↓
AIエージェントでのデータベース構築
どのフェーズでも大本となる設計書が重要にはなっていますが、このように進化していくことが予想され、そうなった時にAIエージェントのコントロールをどうするのかが重要な観点になってくるかと思われます。

設計書を"何で"作るかの議論は宗教戦争になるのでここでは触れないでおきます。

脚注
Snowflake Labsとは、Snowflake愛好家たちによる有志のOSS開発プロジェクトです。世界中の優秀なエンジニアがSnowflakeの便利なOSSを開発してくれています。

https://github.com/snowflake-labs ↩︎
Snowflake MCP ServerとMCPクライアントで実現するAIエージェント時代のデータ分析基盤構築

背景と最新動向

そもそもMCPとは

Snowflake OSS MCP Serverでできること

実際にMCP ServerでSnowflakeインフラを構築・運用してみた

・Object Management / SQL Execution

・Semantic View Querying

・Cortex Search

・Cortex Analyst

・Cortex Agent

MCPサーバーでSnowflakeインフラを自動構築するメリット/デメリット

設計書ドリブンな自動インフラ構築という考え方

まとめ

Discussion
