1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

久々にSnowflakeトライアルを作ったら初期セットアップがPATだけで大体完結した

1
Last updated at Posted at 2026-03-31

はじめに

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.

Programmatic access tokens | Snowflake Documentation

ざっくり言うと 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_USERTYPE = 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_nameaccount_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_IDOAUTH_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#78modelcontextprotocol/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."

anthropics/claude-ai-mcp#78 より

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 ログイン!

image.png

さあ、$40を使わせてくれるのか...?

image.png

→ 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便利!

以上です。

1
0
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?