はじめに
Snowflake の勉強がてら、久々にトライアルアカウントを作ってみました。
改めてみてみると、過去に書いた記事の時点からずいぶん変わったなぁと。
SQLワークシートは今はもうないんですね。
「My Workspace」というエリアになっていて、左上の + から SQL File を作る形になっていました。
SQLワークシート、もうすでに懐かしいな...。
そうそう、認証まわりも増えましたね。
PAT(Programmatic Access Token)や WIF(Workload Identity Federation)が整備されてきて、パスワードベースの設定を書く場面がすっかり減ったというか、もうない印象です。
ということで、ここではPATを使ってどこまで認証が通せるのか?
キーペアを払い出さなくても認証が通せるのか?
...を、備忘録兼ねて最近のSnowflake(2026年3月時点)でトライアルアカウントを作ってからの Snow CLI / Terraform / dbt Fusion / MCP まで一通り繋いだ手順をまとめます。
PATとは
公式ドキュメントには以下のように書いてあります。
A programmatic access token (PAT) is a token that enables secure, programmatic access to Snowflake.
ざっくり言うと API キーみたいなもの、という理解で使っています。
以前はキーペア認証(.p8 ファイルの秘密鍵...)が多かったのですが、PAT は Snowsight 上でポチポチ発行できるし、ツールには環境変数で渡すだけ。
失効させたいときも Snowsight 上から即できるので、管理がだいぶ楽になりました。
トライアルアカウント作成
何回もやっている人からすると、いつもの、ですね。
https://signup.snowflake.com/ からサインアップします。
リージョンは AWS us-west-2 (Oregon) で。
Cortex 対応モデルが多い等、AI機能を試したい場合はここを選ぶと良いかなと思ってます。
サインアップ完了後、Snowsight にログインできることを確認します。
Snowsight の Workspace
ワークスペースといえば、Databr ... ゲフゲフ
ログインしたら左上の + ボタンを押してみると以下のようなメニューが並んでいます。
- SQL File
- Python Worksheet
- Notebook
- Streamlit App
- Git Repository
- ...
SQL を実行したい場合は SQL File を選びます。
My Workspace 上に .sql ファイルが作られて、左ペインからファイル一覧で管理できるようになってますね。
ああ、SQLワークシートさん...
ユーザー・権限設計
以下で考えます。
TRIAL_ADMIN(サインアップ時に作られたデフォルトユーザー)
認証 : パスワード + (実務ではMFA)、ブラウザのみ
ロール : ACCOUNTADMIN
用途 : Snowsightからの管理操作・緊急脱出用
PATなし : NWポリシーが不要 = ロックアウトされない
SYS_TRIAL_USER(これから作るサービスユーザー)
認証 : PAT
ロール : SYSADMIN
用途 : snow CLI / Terraform / dbt / MCP 全部ここ
NWポリシー : ここにだけ当てる
PAT を使う = NWポリシーが必要になります。
NWポリシーは...ロックアウトの危険がありますね。
考慮したつもりでも、ついやってしまう、しまった、となる瞬間が...
TRIAL_ADMIN に PAT を持たせない
= TRIAL_ADMIN に NWポリシーが不要
= TRIAL_ADMIN はロックアウトされない
SYS_TRIAL_USER がどんな状態になっても、TRIAL_ADMIN で Snowsight から即座に直せます。
トライアルでも実務でも、この様に何かしら救済を考慮しておくと安心かなと思います。
My Workspace で setup.sql を作って実行
Snowsight 左上 + → SQL File → ファイル名を setup.sql にします。
以下を貼り付けて実行します。
-- サービスユーザー作成
USE ROLE USERADMIN;
CREATE USER SYS_TRIAL_USER
TYPE = SERVICE
DEFAULT_ROLE = SYSADMIN
DEFAULT_WAREHOUSE = COMPUTE_WH
;
-- ロール付与
USE ROLE SECURITYADMIN;
GRANT ROLE SYSADMIN TO USER SYS_TRIAL_USER;
-- ウェアハウスの使用権限を付与
USE ROLE SYSADMIN;
GRANT USAGE ON WAREHOUSE COMPUTE_WH TO ROLE SYSADMIN;
-- ネットワークポリシー作成(まずフルオープン)
-- IP固定したい場合は '0.0.0.0/0' を自分のIPに変更する
USE ROLE ACCOUNTADMIN;
CREATE NETWORK POLICY tools_nw_policy
ALLOWED_IP_LIST = ('0.0.0.0/0')
;
-- SYS_TRIAL_USER にのみ適用(TRIAL_ADMINには絶対当てない)
ALTER USER SYS_TRIAL_USER SET NETWORK_POLICY = tools_nw_policy;
-- SNOWFLAKE.ACCOUNT_USAGE を SYSADMIN で参照できるようにする
USE ROLE ACCOUNTADMIN;
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE SYSADMIN;
-- Cortex AI 関数を SYSADMIN で使えるようにする
USE ROLE SECURITYADMIN;
GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE SYSADMIN;
フルオープンにしてしまえばロックアウトの心配はなくなるんじゃ?というツッコミはその通りです。
PAT を使う制約でNWポリシーが必要なだけなので、0.0.0.0/0 のままにしてしまえばロックアウト云々の話は消えます。
ただ、「せっかくだからIP絞ろう」と、たまたまいつもと違う環境で作業していて、その時のIPでNWポリシーを設定してしまった暁には...ゴクリ。
PAT発行
SYS_TRIAL_USER は TYPE = SERVICE のため Snowsight にログインできません。
ACCOUNTADMIN の TRIAL_ADMIN が Snowsight から代理発行します。
Snowsight → Admin → Users & Roles → SYS_TRIAL_USER → Programmatic access tokens → Generate
| 項目 | 設定値 |
|---|---|
| Name | SYS_TRIAL_USER_PAT |
| Expires in | 1 month |
| Grant access | Single role → SYSADMIN ← デフォルトのPUBLICから必ず変更 |
トライアルは30日なので、期間中に再発行しなくて済むよう1ヶ月にしました。
ロール: PUBLIC のまま PAT を発行すると実質何もできないので要注意。
PAT の名前が任意な理由
Snowflake の公式ドキュメント(Programmatic access tokens)を確認すると、PAT は1ユーザーに複数作成できる設計になっています。
なので、こういう使い方ができます。
SYS_TRIAL_USER
└── SYS_TRIAL_USER_PAT_TERRAFORM (Terraform用)
└── SYS_TRIAL_USER_PAT_DBT (dbt用)
└── SYS_TRIAL_USER_PAT_MCP (MCP用)
ツールごとに払い出して、例えば漏洩したときに該当 PAT だけ失効させて他PATは生かす設計ができる、と解釈しています。
ロール別に発行できるのもいいですね。
今回のように1本だけ使うなら SYS_TRIAL_USER_PAT で十分かと思います。
発行したら画面を閉じる前に export
トークンは再表示不可です。 発行直後に以下をターミナルに貼ってください。
後ほど生成するプロファイル名を「TRIAL01」と名付けるとして、
export SNOWFLAKE_CONNECTIONS_TRIAL01_TOKEN="ここにPATの値を貼る"
export SNOWFLAKE_TOKEN="$SNOWFLAKE_CONNECTIONS_TRIAL01_TOKEN"
としておきます。
# 値が入っているか確認してから画面を閉じる
echo $SNOWFLAKE_TOKEN
ツールインストール
今回PAT認証で使ってみようとしているツール群をインストールします。
# tenv(Terraformバージョン管理)
brew install tenv
tenv terraform install latest
tenv terraform use latest
# dbt Fusion
curl -fsSL https://public.cdn.getdbt.com/fs/install/install.sh | sh -s -- --update
# snow CLI
brew tap snowflakedb/snowflake-cli
brew install snowflake-cli
Snow CLI 設定
アカウント識別子は Snowsight から確認します。
Snowsight 左下のアカウント名をクリック → Account Details
| 項目 | 確認できる値 |
|---|---|
account |
Account identifier(<ORG>-<ACCOUNT> 形式) |
organization_name |
Organization name |
account_name |
Account name |
# ~/.snowflake/config.toml
[connections.trial01]
account = "<org>-<account>"
user = "SYS_TRIAL_USER"
role = "SYSADMIN"
warehouse = "COMPUTE_WH"
authenticator = "PROGRAMMATIC_ACCESS_TOKEN"
接続確認します。
snow connection test -c trial01
snow sql -q "SELECT CURRENT_USER(), CURRENT_ROLE();" -c trial01
Cortex AI を snow CLI から叩いてみる
接続が通ったら、そのまま Cortex 関数を試してみます。
# テキスト補完(AI_COMPLETE)
snow sql -q "
SELECT AI_COMPLETE(
'claude-4-sonnet',
'あなたのモデルの特徴について、ChatGPTやGeminiとどう違いますか?自分の推しポイントを箇条書きで教えてください。'
) AS answer;
" -c trial01
# 日本語→英語翻訳
snow sql -q "
SELECT SNOWFLAKE.CORTEX.TRANSLATE(
'データエンジニアリングの未来は明るい。',
'ja',
'en'
) AS translated;
" -c trial01
# センチメント分析
snow sql -q "
SELECT SNOWFLAKE.CORTEX.SENTIMENT(
'I am very satisfied because Snowflake is easy to use.'
) AS sentiment_score;
" -c trial01
なお、SENTIMENT は英語ベースのモデルのようです。
日本語テキストをそのまま渡すと意図しない結果になってしまったので、先に TRANSLATE で英語に変換してから渡すと良さそうです。
Terraform 設定
Terraform provider は snow CLI の config.toml を読みません。
~/.snowflake/config(拡張子なし・完全別ファイル)を作る必要があります。
ちなみにキー名も snow CLI と異なります。
snow CLI は account(ハイフン区切り)ですが、Terraform 用は organization_name と account_name を分けて書く形です。
cat > ~/.snowflake/config << 'EOF'
[trial01]
organization_name = '<org>'
account_name = '<account>'
user = 'SYS_TRIAL_USER'
role = 'SYSADMIN'
warehouse = 'COMPUTE_WH'
authenticator = 'PROGRAMMATIC_ACCESS_TOKEN'
EOF
chmod 600 ~/.snowflake/config
providers.tf
terraform {
required_providers {
snowflake = {
source = "snowflakedb/snowflake"
version = "~> 2.14"
}
}
}
provider "snowflake" {
profile = "trial01"
}
main.tf
後で MCP サーバーを作るので、専用スキーマ MCP_SCHEMA もここで一緒に作っておきます。
resource "snowflake_database" "trial" {
name = "TRIAL_DB"
comment = "trial database"
}
resource "snowflake_schema" "trial" {
database = snowflake_database.trial.name
name = "TRIAL_SCHEMA"
comment = "一般用途のスキーマ"
}
resource "snowflake_schema" "mcp" {
database = snowflake_database.trial.name
name = "MCP_SCHEMA"
comment = "Managed MCP Server用スキーマ"
}
terraform init
terraform plan
terraform apply
dbt Fusion 接続設定
dbt Fusion は PAT をネイティブサポートしていませんが、password フィールドに PAT を渡すと動くようです。
Snowflake のコネクタ側が PAT をパスワードとして受け付ける仕様のため、と解釈しています。
(dbt Slack コミュニティや GitHub Issues で確認されている動作です。気になる方は最新状況を確認してみてください)
dbt プロジェクトの初期化
dbt Fusion はプロジェクト名を --project-name で指定します。
インタラクティブなプロファイル設定は存在しないため --skip-profile-setup を付けて、profiles.yml は手動で作成します。
mkdir ~/dbt_trial && cd ~/dbt_trial
dbt init --project-name trial01 --skip-profile-setup
# profiles.yml を手動作成
mkdir -p ~/.dbt
cat > ~/.dbt/profiles.yml << 'EOF'
trial01:
target: dev
outputs:
dev:
type: snowflake
account: "<org>-<account>"
user: SYS_TRIAL_USER
password: "{{ env_var('SNOWFLAKE_CONNECTIONS_TRIAL01_TOKEN') }}"
role: SYSADMIN
warehouse: COMPUTE_WH
database: TRIAL_DB
schema: TRIAL_SCHEMA
threads: 4
EOF
接続確認
cd ~/dbt_trial/trial01
dbt debug
All checks passed! が出れば完了です。
おお...PATひとつで
- snow CLI
- Terraform
- dbt
の認証設定が完結しました。
キーペアなんて一度も作ってないし設定していない。
こりゃ便利ですね。
MCP × Claude.ai
Snowflake の Managed MCP サーバーを Claude.ai に繋ぎます。
2026年3月時点で Terraform provider は MCP サーバーオブジェクトに対応していないため、ここは snow CLI で実行します。
Terraform で作った MCP_SCHEMA の上に乗せる形です。
OAuth Security Integration の作成
PAT での tools/call(SQL実行)は Snowflake Managed MCP では動作しないことが確認されています。
正式サポートの認証方式は OAuth です。
TRIAL_ADMIN で Snowsight にログインして以下を実行します。
USE ROLE ACCOUNTADMIN;
CREATE OR REPLACE SECURITY INTEGRATION SNOWFLAKE_MCP_OAUTH
TYPE = OAUTH
OAUTH_CLIENT = CUSTOM
OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
OAUTH_REDIRECT_URI = 'https://claude.ai/api/mcp/auth_callback'
OAUTH_ISSUE_REFRESH_TOKENS = TRUE
OAUTH_REFRESH_TOKEN_VALIDITY = 7776000
OAUTH_USE_SECONDARY_ROLES = 'IMPLICIT'
BLOCKED_ROLES_LIST = ('ACCOUNTADMIN', 'ORGADMIN', 'SECURITYADMIN')
ENABLED = TRUE;
-- クレデンシャル取得(このあとClaude.aiに設定する値)
SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('SNOWFLAKE_MCP_OAUTH');
JSON で OAUTH_CLIENT_ID と OAUTH_CLIENT_SECRET が返るので、コピーしておきます。
MCP サーバー作成
Snow CLI で実行します。
cat > mcp_setup.sql << 'EOF'
USE DATABASE TRIAL_DB;
USE SCHEMA MCP_SCHEMA;
CREATE OR REPLACE MCP SERVER trial_mcp
FROM SPECIFICATION $$
tools:
- name: "sql_exec"
type: "SYSTEM_EXECUTE_SQL"
title: "SQL実行"
description: "TRIAL_DBに対してSQLクエリを実行します"
config:
warehouse: "COMPUTE_WH"
$$;
GRANT USAGE ON MCP SERVER TRIAL_DB.MCP_SCHEMA.trial_mcp TO ROLE SYSADMIN;
-- 確認
SHOW MCP SERVERS IN SCHEMA TRIAL_DB.MCP_SCHEMA;
DESCRIBE MCP SERVER TRIAL_DB.MCP_SCHEMA.trial_mcp;
EOF
snow sql -c trial01 -f mcp_setup.sql
疎通確認
tools/list でツール一覧が返れば接続 OK です。
curl -s -X POST \
"https://<org>-<account>.snowflakecomputing.com/api/v2/databases/TRIAL_DB/schemas/MCP_SCHEMA/mcp-servers/trial_mcp" \
--header "Content-Type: application/json" \
--header "Authorization: Bearer $SNOWFLAKE_CONNECTIONS_TRIAL01_TOKEN" \
--data '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'
Claude.ai にコネクタを追加
MCP エンドポイント URL を確認します。
snow sql -c trial01 -q "
SELECT 'https://' || CURRENT_ORGANIZATION_NAME() || '-' || CURRENT_ACCOUNT_NAME() ||
'.snowflakecomputing.com/api/v2/databases/TRIAL_DB/schemas/MCP_SCHEMA/mcp-servers/trial_mcp'
AS mcp_endpoint_url;
"
claude.ai → Settings → Connectors → Add custom connector → Snowflake
| 項目 | 値 |
|---|---|
| Server URL | 上のURLの出力値 |
| OAuth Client ID |
SYSTEM$SHOW_OAUTH_CLIENT_SECRETS で取得した OAUTH_CLIENT_ID
|
| OAuth Client Secret | 同じく OAUTH_CLIENT_SECRET
|
設定後に Snowflake のログイン画面が出るので、TRIAL_ADMIN でログインして認証します。
2026年3月末現在の既知バグ
さて、MCPは無事動くのか...?
と、試そうとしたんです。
ですがどうにも動かなかった...
接続・認証まで通っても SQL 実行(sql_exec)が Error parsing response になってしまいます。
ここで時間を溶かしました。
接続自体は通っているように見えるので、設定が悪いのかと何度も見直してしまいました。
これは Anthropic 側のバグらしく、anthropics/claude-ai-mcp#78 と modelcontextprotocol/modelcontextprotocol#653 で追跡されています。
Snowflake サポートのコメントによると:
"The Claude Desktop Snowflake connector is directing the browser to an incorrect OAuth authorization endpoint. ... I also noticed the connector is using
scope=claudeai, which is not a recognized Snowflake OAuth scope."
Claude.ai が OAuth 認可リクエストで送信する scope が claudeai になっているのが原因のようです。
これは Snowflake が認識しない値なので、SQL 実行が認可されない状況、だそうです。
ちなみにクエリ履歴を確認したところ、SQL は Snowflake 側に1件も届いていませんでした。
#78 は 2026年3月時点でまだ OPEN。
修正が入り次第また試してみます。
おまけ:Cortex Code CLI を試したい場合
Cortex Code CLI は通常の Snowflake トライアルとは別のアカウントが必要です。
https://signup.snowflake.com/cortex-code から申し込むと、全く別の Snowflake アカウントが発行されます。
案内されるがまま登録を進めていざ Snowsight ログイン!
さあ、$40を使わせてくれるのか...?
→ Snowflake「クレカ登録オナシャス」「さもなくばサインアウトで」
→ ワイ「え?」
あら。。。
お試しするにもクレカ登録必須のようです。
なので一度ここで停めました。
課金体系も Snowflake のプラットフォームとは独立していて、30日間 \$40 クレジット付き、その後は月 \$20 のサブスクリプションの模様。
本編の Terraform・dbt・snow CLI 環境とは完全に切り離して考えてください。
試したい場合は上記 URL から別途サインアップして、そのアカウント用に接続設定を追加する必要があります。
なんでアカウントが別れてるんだ...
# インストール
curl -LsS https://ai.snowflake.com/static/cc-scripts/install.sh | sh
# Podmanのインストール確認 → n(試した環境はmacですが、インストールを進めると止まったので)
# 起動
cortex
# 1. 接続一覧 → Cortex Code CLI用のアカウントを選択
# 2. Do you want to use the same account for SQL queries? → y
# 3. Do you trust this project? → 1. Yes, proceed
コンソールが起動したら自然言語で Snowflake に話しかけられます。
(もちろんクレカ登録済の前提で)
おわりに
今回のセットアップを振り返ると、SYS_TRIAL_USER_PAT 1本で大体なんとかなりました。
キーペア?一度も作ってません。
SNOWFLAKE_CONNECTIONS_TRIAL01_TOKEN = "eyJraWQi..."
├── snow CLI → 直接読む
├── Terraform → SNOWFLAKE_TOKEN 経由
└── dbt Fusion → profiles.yml の env_var() 経由
PAT の値をファイルに書かず、環境変数の export だけで全ツールを回せているのも個人的に嬉しいポイントです。
設定ファイルにクレデンシャルが残らない。
以前はキーペア認証(.p8)を使っていましたが、ツールごとにファイルのパスや形式が微妙に違って地味に面倒でした。
PAT なら「Bearer トークンを環境変数に入れて渡すだけ」なので、パスワードを設定ファイルに書く必要もない。
これは楽です。
ファイル構成はこんな感じになりました。
~/.snowflake/
config.toml # snow CLI用([connections.xxx]形式)
config # Terraform専用([xxx]形式・拡張子なし)
~/.dbt/
profiles.yml # dbt Fusion用
snowflake-trial/
providers.tf
main.tf
mcp_setup.sql
MCP の SQL 実行は Claude.ai 側のバグ修正待ちですが、それ以外は PAT 1本で一通り繋がっています。
修正が入り次第また試してみます。
PAT便利!
以上です。

