デルタメモ

Snowflake

Snowflakeのチャット用MCPにはSemantic Viewだけ渡す—数え方はツール説明に書かない

事業の担当者が外部のチャットでSnowflakeの売上や人数を尋ねるとき、人数の数え方や月の区切りをMCPのツール説明に書くと、Semantic Viewを直したあとも説明文に古い定義が残ります。チャットが読める範囲をSemantic Viewだけにし、どの料金がかかるかを決めてから使う道具を選ぶ判断基準です。

事業の担当者が、外部のチャットに売上や人数を言葉で尋ねるようになると、MCPのツール説明に数え方まで書いてしまいがちです。その説明は会話のたびにモデルへ渡り、Semantic Viewに書いた定義と二重になります。片方だけ直すと、チャットは古い数え方のまま答えます。読み終わると、定義をどこに書くか、チャットに何を読ませるか、コネクタを増やすか、どの料金がかかるかを分けて判断できます。公開する前に、質問を1つ手元のSQLと突き合わせるところまでが合格です。

この記事でわかること

外部のチャットからSnowflakeの売上や人数を尋ねるとき、定義をどこに書くか、誰に何を読ませるか、どの料金がかかるかを判断できるようにします。社名、金額、個人の数字は出しません。文言は2026年11月7日に公式を開いて確認しました。

前提

対象は、組織のチャット用コネクタから、Snowflake上のMCPサーバーを使う構成です。集計の意味はSemantic Viewに置き、事業向けのロールはそのビューだけを読みます。外部チャットの製品名は問いません。Claudeでも、ほかのMCP対応チャットでも、判断は同じです。

失敗1 数え方をツールの説明に複製する

MCPのツールには description があります。モデルは道具を選ぶとき、この文を読みます。売上の月をどの日で区切るか、人数をどう数えるかまでここに書くと、同じ文をSemantic Viewの COMMENT と AI_SQL_GENERATION にも置くことになり、直す場所が二か所になります。公式のモデリングガイドは、説明文が答えの精度を最も左右する、と書いています。AI_SQL_GENERATION は、Cortex AnalystがSQLをどう書くかの指示です。COMMENT はビューや列の説明です。

悪い例は、ツール説明とSemantic Viewの両方に「月初は請求日、人数は契約を一意に数える」と書き、請求日の定義だけビュー側を直すことです。チャットはツール説明に残った古い定義で集計します。

良い例では、ツール説明に書くのは変わらない決まりだけです。読めるSemantic Viewの名前を示し、会話の最初に DESCRIBE SEMANTIC VIEW を流して、返ってきた COMMENT と AI_SQL_GENERATION に従わせます。答えには使った定義とデータの最新日を書き、個人を1人ずつ出しません。数え方そのものはSemantic Viewだけに置きます。

合格条件は、人数、売上、期間の定義を直すとき、編集する場所がSemantic Viewの COMMENT と AI_SQL_GENERATION だけであることです。

失敗2 元の表まで読めるロールでビュー経由と言う

Semantic Viewを作ったあとも、事業向けロールに元の表のSELECTが残っていると、モデルはビューを通さず表を読めます。人数を数えるためだけの識別子や、個人が特定できる列が、モデルの答えに出せる項目に入っているときも同じです。画面の題名とツールの title が違うと、利用者はどの道具がどの画面の話か選べません。

悪い例は、ビューを作ったことだけを根拠に「Semantic View経由」と書き、元表のSELECTと個人列を残すことです。

良い例では、事業向けロールがSELECTできる対象をSemantic Viewに閉じます。識別子と個人列は、答えに出せる項目へ入れません。画面の題名とツールの title は、同じ業務の名前にします。

合格条件は、事業向けロールで元の表をSELECTできず、答えの項目に個人を1行ずつ出せる列が無いことです。

失敗3 主題のたびにコネクタを増やす

組織のチャットには、コネクタが利用者の画面に並びます。売上、在庫、問い合わせを別々のMCPサーバーに分けると、サーバー名もURLもOAuthの同意も増えます。利用者は主題が変わるたびにつなぎ直します。

悪い例は、データを足すたびにコネクタを新規作成することです。

良い例では、組織のコネクタ1つにMCPサーバー1つを対応させます。データを増やすときはサーバー名とURLを変えず、主題ごとの読むだけの道具を足します。OAuthの統合は接続先ごとに1つにし、同じ接続先のサーバーが増えても統合は使い回して、許すロールだけを足します。

合格条件は、主題を1つ足したあとも、利用者が再接続するURLとOAuth統合が増えていないことです。

失敗4 どの料金がかかるかを決めずに道具を選ぶ

道具の種類で、請求されるものが変わります。公式では、Cortex Analystのクレジットは処理したメッセージの数で数え、成功した応答だけが対象です。Analystが生成したSQLを実行する分は、別途ウェアハウスの費用になります。外部のチャットがSQLを書き、ウェアハウスがSemantic Viewを読む経路では、Cortex Analystを呼びません。そのAIクレジットは発生せず、消費されるのは外部チャット側のトークンと、クエリを実行するウェアハウスです。MCPでつなぐこと自体は、AIクレジットの有無を決めません。

公式は、業務の質問向けMCPではCortex Agentだけをクライアントに見せ、同じサーバーに SYSTEM_EXECUTE_SQL を載せないことを勧めています。載せると、クライアントがSemantic Viewと検証済みクエリを迂回できるためです。直接SQLが必要なら、公式は別のMCPサーバーと、権限を絞った専用ロールに分ける、としています。

ここで扱う選択は、その推奨と逆です。コネクタを増やさず、Cortex AnalystのAIクレジットを発生させないために、同じサーバーへ読むだけのSQL道具を足します。選ぶなら、迂回できることを設計メモに残し、ロールと道具の契約で読める対象をSemantic Viewだけに閉じます。制限の無いSQL実行を同じサーバーへ載せ、ビューを作っただけで読める対象を閉じないままにしてはいけません。

悪い例は、クレジットの話を後回しにして道具を足し、同じサーバーに制限の無いSQL実行を置くことです。

良い例では、先に二択を一文で残します。Cortex AnalystかCortex Agentで、答えの組み立てをSemantic Viewに寄せ、メッセージ単位のAIクレジットとウェアハウスを払うか。外部チャットがSQLを書き、ウェアハウスとチャットのトークンだけを払い、読める対象はSemantic Viewに閉じるか。後者を選んだ理由がAIクレジットであることと、公式が迂回を警告していることを、同じ文面に書きます。

合格条件は、道具を足す前に、Cortex AnalystのAIクレジットが発生する経路か、ウェアハウスと外部チャットのトークンだけか、が一文で書いてあることです。SQL道具を出す場合は、元の表を読めないことと、公式の迂回警告に触れた文があることも含めます。

失敗5 それらしい表が出ただけで利用者に渡す

自然文の質問は、列名が業務語の表を返します。定義が違っていても、見た目はもっともらしくなります。

悪い例は、チャットが表を返したことをもって公開にすることです。

良い例では、検証済みの集計質問を1つ決めておきます。同じ質問を手元のSQLでも実行し、チャットの数字と一致してから利用者に渡します。記事やチャットのログに、一致した数字そのものは残しません。残すのは、どの質問で一致を見たかです。

合格条件は、利用者に渡す前に、1問についてチャットの結果と手元のSQLの結果が一致した記録があることです。

作業前にAIへ渡す入力

人間向けの長い手順は書きません。次は、ルールファイルへ残す文と、作業の開始時にチャットへ貼る文です。

AI向けの永続ルール

SnowflakeのMCPで、外部チャットから事業の集計を答える道具を足すとき:
- 人数、売上、期間の定義はSemantic ViewのCOMMENTとAI_SQL_GENERATIONだけに書く。ツールのdescriptionに複製しない。descriptionに書いてよいのは、読めるビュー、会話の最初にDESCRIBE SEMANTIC VIEWを流してそのCOMMENTとAI_SQL_GENERATIONに従うこと、答えに定義とデータの最新日を書くこと、個人を1人ずつ出さないこと、だけ。
- 事業向けロールがSELECTできる対象はSemantic Viewだけ。元の表のSELECTは付けない。個人を特定する列と、人数を数えるためだけの識別子は、答えに出せる項目へ入れない。画面の題名とツールのtitleは同じ業務の名前にする。
- データ追加は同じMCPサーバーに読むだけの道具を足す。サーバー名、URL、接続先ごとのOAuth統合は増やさない。許すロールだけ足す。
- 道具を選ぶ前に、Cortex AnalystかCortex Agentでメッセージ単位のAIクレジットを払うか、外部チャットがSQLを書いてウェアハウスとチャットのトークンだけを払うかを一文で書く。公式は業務質問向けにCortex Agentだけを見せ、同じサーバーのSYSTEM_EXECUTE_SQLはSemantic Viewと検証済みクエリを迂回しうると警告している。SQL道具を出すなら、その警告に触れ、読める対象をSemantic Viewに閉じる。制限の無いSQLを同じサーバーへ載せない。
- 利用者に渡す前に、検証済みの集計質問を1つ、手元のSQLと突き合わせる。一致した数字そのものはチャットや記事に残さない。

AI向けの開始時に貼る文

SnowflakeのMCPに、外部チャットから集計を聞く道具を足したい。実装はまだするな。
先に次を出せ。定義を書く場所（Semantic ViewのCOMMENTとAI_SQL_GENERATIONか、ツール説明か）。事業ロールがSELECTできる対象。増やすのが道具か、サーバーURLとOAuth統合か。消費されるのがCortex AnalystのAIクレジットか、ウェアハウスと外部チャットのトークンか。公式が同じサーバーのSQL実行に出している迂回の警告に、今回の選択が触れているか。
公開前の突き合わせに使う質問を1つ提案し、数字そのものは書くな。

人間向け

なし。上をAIに渡すだけでよい。

参考リンク