AI から Snowflake を触る3つの道を比べる:手元の MCP・Snowflake の MCP サーバー・画面操作
AI に Snowflake を触らせる道は、いま大きく3つあります。手元で動かす MCP(AI が外の道具を使うための接続口)、Snowflake の中に作る MCP サーバー、そして AI が Snowsight(Snowflake の画面)をブラウザで操作する方法です。同じ作業を3つの道でやってみて、何ができて、どこで止まり、どれくらい速いかを比べました。

比べた作業
どの道でも、次の3つをやりました。
1. セマンティックビュー(集計の決まりを書いたもの)に、日本語で「2026年6月の保存率は?」と聞く 2. SQL で集計を読む 3. 試験用の置き場に表を作る・消す
使ったのは、自社の Snowflake の試験用の置き場だけです。作業の前に毎回、接続先が自社のアカウントかを確かめています。
道1:手元の MCP
Claude アプリに、Snowflake Labs が公開している MCP サーバーを登録して使う道です。これまでの記事の作業の多くは、この道でやりました。
- 入る役:設定に書いた利用者とロールで入る。読むだけの利用者で入る接続と、作業用の接続を分けている
- 書き込み:ロールに権限があれば通る。送ってよい SQL の種類を設定で絞れるが、文の見た目で分けるだけなので、副問い合わせや EXECUTE IMMEDIATE に包むと止めた種類も通る
- 長い処理:4分かかる予測モデルの学習は、待ち時間切れで止まった(Snowflake 側では学習が続いていた)
この道は、表やビューや画面を「作る」作業に向いています。守りは設定ではなく、入る役(ロール)で決めます。
道2:Snowflake の MCP サーバー
Snowflake の中に MCP サーバーという入れ物を作り、そこに AI に使わせたい道具を並べる道です。今回は、Cortex Analyst(日本語の質問から SQL を作る機能)と、SQL を実行する道具の2つを並べました。
CREATE MCP SERVER ORDER_SYSTEM.BLOG_LAB.IG_MCP FROM SPECIFICATION $$
tools:
- name: "instagram_analyst"
type: "CORTEX_ANALYST_MESSAGE"
identifier: "ORDER_SYSTEM.SEMANTIC_SANDBOX.ICHIBAN_INSTAGRAM_SV"
description: "インスタ月次の集計の決まりを持つセマンティックビューに日本語で質問する"
- name: "run_sql"
type: "SYSTEM_EXECUTE_SQL"
description: "SQL を実行する"
$$;
呼び出しは、Snowflake の決まったアドレスに JSON-RPC(MCP の約束ごとに沿った手紙のような形)で送ります。今回は、利用者の鍵で作った署名つきの合言葉(JWT)を付けて、手元のプログラムから呼びました。
道具の一覧を聞くと、SQL を実行する道具には「読むだけ」の印(readOnlyHint)が付いて返ってきました。
日本語で聞く
「2026年6月の保存率は?」と送ると、3.6秒で次が返りました。
- 質問の読み方:「投稿ごとの保存率の平均ではなく、月全体の保存合計 ÷ リーチ合計 × 100 で算出する」
- SQL:`SELECT * FROM SEMANTIC_VIEW(… METRICS monthly_save_rate …)`
Cortex Analyst の道具が返すのは、読み方と SQL までです。数字を出すには、その SQL を SQL 実行の道具で流します。流すと 0.20 が返り、公開している月次レポートと一致しました。
書き込みを試す
ここが、道1と一番違ったところです。道1で止まる種類を抜けた書き方も含めて、書き込みを試しました。
| 送ったもの | 結果 |
|---|---|
| SELECT・SHOW | 通る(道1では SHOW が止まる) |
| CREATE TABLE | 止まる |
| DELETE | 止まる |
| EXECUTE IMMEDIATE の中で CREATE TABLE | 止まる |
| 表を作る手続きの CALL(呼んだ人の権限で動くもの) | 止まる |
| 表を作る手続きの CALL(持ち主の権限で動くもの) | 止まる |
| SELECT と DROP を2文まとめて | 止まる(1文だけ受け付ける) |
使ったロールには、表を作る権限があります。それでも全部止まりました。文の見た目ではなく、実行の段で書き込みを止めているようです。手続きの中に隠した書き込みまで止まったのは、道1には無い固さです。
一方で、止まったときのエラーは「!399517!」という番号だけで、理由が分かりません。AI に任せていると、なぜ失敗したのかを AI も人も判断しにくい点は気になりました。
あとから画面で追える
Snowsight の「モニタリング」→「クエリ履歴」で、利用者を絞って見ると、MCP サーバー経由で流れた SQL が並んでいました。止まった書き込みは「失敗」と出ます。

1件を開くと、クエリタグに「cortex-agent-…」、クライアントに「SQLAPI 2.0.0 snowflake cortex」と残っていました。AI が MCP サーバー経由で流したものだと、あとから見分けられます。

AI に何をさせたかを後から確かめられるのは、任せる側としては大事な点です。
道3:AI の画面操作
AI がブラウザで Snowsight を操作する道です。前の記事で、Cortex Analyst のプレイグラウンドに質問する様子を撮ったのも、この道です。

- 入る役:画面にログインしている人の役。今回は管理者(ACCOUNTADMIN)でログインしていたので、AI も管理者の力で動く
- 速さ:質問を打つ・待つ・画面を撮る、で1問あたり約30秒。道2の10倍近くかかった
- つまずき:人と同じ所でつまずく。セマンティックビューを読む許可が無いと、画面に権限エラーが出た。操作するブラウザが別のパソコンに切り替わる、ボタンの位置を外す、といった画面操作ならではの失敗も何度かあった
画面操作は、道1・道2と違って「人と同じ力」で動きます。ログインしている人が管理者なら、AI も表を消せます。今回は、読む・確かめる・撮るだけに使い、作る・消すは画面からはやっていません。
その代わり、画面にしか無い機能(プレイグラウンドで答えを確かめる、Streamlit の画面を開く)を確かめられ、人が見るのと同じ写真が残ります。手順書や記事を作るには、この道が欠かせませんでした。
比べた結果
| 道1 手元の MCP | 道2 Snowflake の MCP サーバー | 道3 画面操作 | |
|---|---|---|---|
| 入る役 | 設定に書いた役 | 呼んだ利用者の役 | ログインしている人の役 |
| 日本語で質問 | 設定しだい | 読み方と SQL(約4秒) | 読み方・SQL・結果(約30秒) |
| 書き込み | 役しだい。包み直すと止めた種類も通る | 包み直しも手続きも止まる | 人と同じ(何でもできる) |
| 失敗の分かりやすさ | エラー文がそのまま返る | 番号だけ | 画面に人と同じ表示 |
| 向いている作業 | 作る・直す | 読む・答える | 確かめる・撮る |
まとめ
- 読むだけなら、Snowflake の MCP サーバーが一番固い。手続きに隠した書き込みまで止まった
- 作る作業は手元の MCP で、守りは入る役(ロール)で決める。設定ファイルの絞りは抜けられる
- AI の画面操作は、ログインしている人の力で動く。読む・確かめる・撮るに使い、作る・消すは任せない

