Finatext Tech BlogPublicationへの投稿
🏄

Snowflake-managed MCP ServerのOAuth認証への理解と権限設計

Takumi
に公開
Snowflake
Model Context Protocol
tech

はじめに

こんにちは。ナウキャストでエンジニアをしているTakumiです。

ここ最近，Snowflake-managed MCPを安全に使うには何が必要かを整理していました。
接続は MCP Client（ローカルPC）→ MCP Server → Snowflake という経路になるので，"SnowflakeのAI機能を使ってデータ分析を行うときのロール構成をまとめる"のときと同様，権限の設計を誤ると本来見えてはいけないデータが参照される（≒情報漏洩）リスクがあります。

そのうえで，次の2つは切り分けて押さえておく必要があります。

  • 認証（Authentication） … MCP 経由で Snowflake に接続するとき，誰として接続するのかをどう示すか
  • 認可（Authorization / RBAC） … その接続に紐づくロールで，MCP・各 Tool・Semantic View や Table などリソースに対して，最小権限として何を付与すべきか

本記事では，この2点について公式ドキュメントや挙動を踏まえて整理します。

この記事では言及しないこと

MCP Serverの本番運用を考える

本番利用で考慮すべきリスク

これはMCP Serverに限らず，LLMに業務データや業務アクションを渡す場合に共通する話ですが，本番利用では少なくとも以下の観点を考慮する必要があります。

意図しないデータアクセス

まず，よく使うToolの実行権限モデルをざっくり整理すると次のとおりです。

対象 実行時の権限モデル 注意点
Cortex Search Service owner's rights ServiceにUSAGEがあれば，呼び出し元ロールの基底テーブル権限に関係なく，インデックス済みデータに到達しうる
Cortex Analyst 呼び出しユーザーの権限に従う（必要権限: Semantic Viewや参照先へのSELECT/USAGE） Semantic Viewや参照先オブジェクトの権限設計が甘いと過剰参照になる
Cortex Agent Agent自体はオーケストレーター。実データアクセスは各Toolの権限モデルに依存 AgentにToolをぶら下げるときは，Toolごとの権限モデルを個別確認する
Stored Procedure EXECUTE AS OWNER / CALLER / RESTRICTED CALLER（defaultはOWNER） OWNERのままだと，呼び出し元より強い権限で処理が走る可能性がある

MCP Server経由でも，これまでのSnowflakeの権限モデル自体は変わりません。なので，MCP Serverだから特別気をつけなければいけないと言うわけではなく，このような注意点があることを認識した方が万が一の備えになります。

SQL実行Toolの危険性

Snowflake-managed MCP Serverでは，SYSTEM_EXECUTE_SQL というTool typeを使うことで，Snowflakeに対してSQLを実行できます。これは非常に強力ですが，設計を誤るとLLMに任意SQL実行能力を渡すことになります。

例えば，強い権限を持つRoleでMCP Serverに接続できる状態にしてしまい，SQL実行Toolからロール変更やDDL / DML / 権限変更系のSQLが実行できると，影響範囲が大きくなります。Security Integrationでは ACCOUNTADMIN, ORGADMIN, GLOBALORGADMIN, SECURITYADMIN はデフォルトでブロックされますが，SYSADMIN や独自の強権限Roleは設計次第で利用できてしまうため，SECURITY INTEGRATION側のRole制御も重要です。（Warehouseの話と，Roleによる最小権限の話はここでは割愛。）
その場合のクイックにできる設定は以下の通りかなと思います。

  • read_only: true を設定し，読み取り用途に限定する
  • query_timeout を設定し，長時間・高コストなクエリを抑制する
  • SECURITY INTEGRATION側で利用可能なRoleを制限する
read_only: true と「OAuth SECURITY INTEGRATION側で利用可能なRoleを制限する」について補足
read_only: true でどこまで読み取り限定にできるか

read_only=true は完全に "書き込み禁止モード"です。

  • DML (INSERT/UPDATE/DELETE/MERGE/TRUNCATE)
  • DDL (CREATE/ALTER/DROP)
  • DCL (GRANT/REVOKE)

すべて同じ以下のエラーでブロックされます。

http 422, error code 399517: !399517!

そのため，書き込み系・権限変更系の操作を一括で抑止したいユースケースでは read_only: true を有効にしておくのが基本になります。（エラーメッセージが不親切なので，せめて"operation not allowed in read-only mode"みたいに返して欲しい。）

検証結果は以下のとおりでした。

カテゴリ クエリ例 結果
SELECT SELECT COUNT(*) FROM ... ○
SHOW SHOW TABLES IN ... / SHOW MCP SERVERS / SHOW GRANTS ... ○
CURRENT_*系 SELECT CURRENT_ROLE() ○
DESC DESC TABLE ... ○
EXPLAIN EXPLAIN SELECT COUNT(*) FROM ... ○
CREATE CREATE OR REPLACE TEMP TABLE ... ×
INSERT INSERT INTO ...（テーブル存在前提） ×
UPDATE UPDATE ... SET ... WHERE 1=0（実テーブル） ×
DELETE DELETE FROM ... WHERE 1=0（実テーブル） ×
GRANT / REVOKE GRANT USAGE ON MCP SERVER ... ×
OAuth SECURITY INTEGRATIONによるRole制限の限界

SECURITY INTEGRATION には個別のRoleをdenyする BLOCKED_ROLES_LIST はありますが，「このRoleだけ許可する」というallow listを直接書く仕組みはありません。そのため，使わせたくないRoleをdeny listに列挙していく運用になり，新しい強権限Roleが追加されるたびに更新しないと，ユーザーに付与済みのRole経由でMCPからアクセスされうる，という運用上の難しさがあります。

このdeny list運用を補完する手段として，Client接続時にOAuth scopeを session:role:<ROLE> で固定するアプローチがあります。挙動・設定方法・限界については，認証設計の章のOAuthセッションは指定したRoleに固定され USE ROLE できないで扱います。

Programmatic Access Token(PAT)管理の難しさ

Snowflake-managed MCP Serverでは，OAuthに加えてPATを使った接続も可能です。PATはSnowflakeのユーザー単位で発行されるトークンであり，原則として「ユーザー1人につき1つ（または用途ごとに複数）」を本人が発行・管理するものです。チームや組織で1つのPATを共有する使い方は，監査追跡上「誰が実行したか」が特定できなくなるため避けるべきです。

このユーザー単位という前提を踏まえると，本番で利用ユーザーが増えるほど次の運用負荷と漏洩リスクが線形に増えていきます。

  • 各ユーザーが自分のMCP Client（ローカルPCや設定ファイル）にPATを保存する必要があり，誤commitや端末紛失時の漏洩経路が増える
  • 有効期限ごとに各ユーザーが個別にローテーションする必要があり，運用が回らないと期限切れや古いトークンの放置が発生する
  • 退職・異動時に対象ユーザーのPATを確実にrevokeする運用を，ユーザー数だけ繰り返す必要がある

特に，運用負担を減らそうとして「管理者が代表してPATを発行し，ファイルサーバーや社内Wikiに置いて各ユーザーがコピペする」といった共有運用に倒すと，前述の監査追跡性が失われるうえ漏洩面も広がるため，これは避けるべきです。

Snowflake公式も，MCP Serverの認証方式としてOAuthの利用を推奨しており，hardcoded tokenはToken漏洩につながる可能性があるとしています。一方でOAuthを採用するなら，社内のSnowflakeユーザー管理（払い出し・初回ログイン・無効化/削除）とRole管理を運用に組み込む必要があります。（社員全員にユーザーを払い出すのが組織体力的に厳しいことがありそう。）

そのため，本番利用では次の整理が現実的です。

  • 少人数の技術検証では，対象ユーザーが自身のPAT（最小権限Roleに紐づけ・短い有効期限）を発行して使う
  • 社内展開・本番利用では，OAuthを基本にする
  • OAuthを使う場合は，Snowflakeユーザー，Role，SECURITY INTEGRATION，Client設定，退職/異動時の権限剥奪まで含めて設計する
  • ビジネスユーザー向けには，MCP Clientごとの手作業設定を減らすため，将来的にはMCP Gatewayで接続設定を隠蔽することも検討する

要するに，認証方式の選択だけでなく，ユーザーライフサイクルとRBAC運用をセットで設計することが重要です。

Toolの過剰公開

MCP ServerにどのToolを公開するかは，LLMにどの操作能力を渡すかを決める設計そのものです。Snowflake RBACによって最終的な実行権限は制御できますが，権限上実行可能なToolをすべてLLMに見せるべきではありません。

例えば，売上分析用のMCP Serverであれば，承認済みのSemantic Viewを使うCortex Analyst Toolや，関連ドキュメントを検索するCortex Search Toolに絞るのが自然です。一方で，任意SQL実行Tool，Stored Procedure実行Tool，オブジェクト作成・削除系のToolまで同じMCP Serverに公開すると，LLMが意図しないToolを選択したり，似たToolを取り違えたりするリスクが高まります。

Snowflake公式ドキュメントでも，Toolやdescriptionを適切に検証しないと，tool poisoningやtool shadowingのような脆弱性につながる可能性があると注意喚起されています。

そのため，本番運用では，ユースケースごとにMCP Serverを分け，公開するToolを最小限にし，Tool名・descriptionに用途，対象データ，禁止事項を明記することが重要です。特にSQL実行ToolやGeneric Toolは，必要な場合のみ，専用Role・専用Warehouse・監査前提で公開すべきです。

監査不能な利用

本番運用では，MCP経由の利用が監査できることも重要です。

監査で最低限必要なのは，実行主体（どのユーザー／ロールか），実行時刻（いつ），実行SQL（何をしたのか），実行コスト を後から突合できることです。これが欠けると，万が一問題が発生した場合にLLM経由で起きた誤操作や過剰アクセスの原因を特定できません。
Snowflake公式ブログのとおり，Snowflake-managed MCP ServerはSnowflakeのRBACやポリシー管理の枠内で運用できます。つまり，MCP利用も既存の監査導線（Query/Access/Login History）に載せて設計できます。

実務では，Snowflake側の監査情報と，MCP Client側またはMCP Gateway側の操作ログを突合できるように設計します。Snowflake側では，QUERY_HISTORY で実行SQL・実行ユーザー・ロール・Warehouse・実行時間・QUERY_TAG を確認し，ACCESS_HISTORY で参照・変更されたオブジェクトを確認できます。必要に応じて，LOGIN_HISTORY から認証イベントも確認します。

ただし，どのMCP Server，どのTool，どのアプリケーション上の操作 によってSQLが実行されたかは，Snowflakeの標準監査情報だけでは十分に分かりません。そのため，自前のMCP GatewayやClientアプリを挟む場合は，request_id, end_user, tool_name などをログに残し，同じ識別子を QUERY_TAG に付与できると，QUERY_HISTORY と突合しやすくなります。

認証設計

Snowflake MCP Serverで利用できる認証・認可方式

Snowflake-managed MCP Serverに接続する際の認証方式は，主に OAuth 2.0 と Programmatic Access Token（PAT） の2つです。

実運用の第一候補はOAuthです。ユーザー単位で認可しやすく，Secret配布を最小化できます。ただしDynamic Client Registrationは使えないため，事前にSECURITY INTEGRATIONと client_id / client_secret / callback URI の準備が必要です。

PATは検証用途では扱いやすい一方，本番ではトークン配布・保管・ローテーションの運用負荷が高くなります。利用する場合は，MCP専用Role・短い有効期限・最小権限を前提にします。

Snowflakeとしての推奨は？

公式ドキュメントに，

We recommend using OAuth as the authentication method. Using hardcoded tokens can lead to token leakage.

と記載があるようにSnowflake-managed MCP Serverの本番利用では，基本的にOAuthを優先するのが自然です。
OAuthを優先する理由は，Snowflake固有の事情だけではありません。MCPのAuthorization仕様でも，認可自体は任意とされている一方，HTTP-based transportで認可を扱う場合はOAuth 2.1ベースの仕様に従うことが想定されています。

OAuthを実現するために必要な準備

Snowflake-managed MCP Server を OAuth で利用する場合，Snowflake 側に OAuth 用の SECURITY INTEGRATION を作成します。
SECURITY INTEGRATION は，Snowflake における OAuth Client の設定を管理するためのオブジェクトです。ここで，redirect URI，client type，利用可能な role scope，blocked roles，secondary roles の扱いなどを定義します。
MCP Client は，この SECURITY INTEGRATION から発行される client_id / client_secret を使って Snowflake の OAuth 認可フローを実行し，Snowflake-managed MCP Server に接続します。

SECURITY INTEGRATIONでは，デフォルトで ACCOUNTADMIN， ORGADMIN， GLOBALORGADMIN， SECURITYADMIN はOAuthで利用できないRoleとして扱われます。必要に応じて SYSADMIN，USERADMIN などの強いRoleも追加し，MCP経由で利用できるRoleをさらに絞ると事故を防ぎやすくなります。

CREATE OR REPLACE SECURITY INTEGRATION oauth_claude_code_mcp
  TYPE = OAUTH
  OAUTH_CLIENT = CUSTOM
  ENABLED = TRUE
  OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
  OAUTH_REDIRECT_URI = 'http://localhost:6274/callback' -- port numberは任意（Clientに依存）
  OAUTH_ALLOW_NON_TLS_REDIRECT_URI = TRUE
  OAUTH_USE_SECONDARY_ROLES = NONE
  PRE_AUTHORIZED_ROLES_LIST = ('AI_ANALYST') # ここに含めたRoleは，OAuth認証後にユーザーがそのRoleの利用に明示的に同意する必要がなくなります。
  BLOCKED_ROLES_LIST = (
    'ACCOUNTADMIN',
    'SECURITYADMIN',
    'SYSADMIN',
    'USERADMIN'
  );

作成後，次の SQL で OAuth Client の情報を取得します。

SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('OAUTH_CLAUDE_CODE_MCP');

ここで取得できる OAUTH_CLIENT_ID と OAUTH_CLIENT_SECRET を MCP Client 側に設定します。
Claude Codeの場合のコマンドは以下のとおりです。

MCP_CLIENT_SECRET=<your client secret> \
claude mcp add-json <registration name> \
'{
  "type": "http",
  "url": "https://<account identifier>.snowflakecomputing.com/api/v2/databases/<database name>/schemas/<schema name>/mcp-servers/<SERVER NAME>",
  "oauth": {
    "clientId": "<YOUR CLIENT ID>",
    "callbackPort": <YOUR PORT NUMBER>,
    "scopes": "session:role:<YOUR ROLE NAME>"
  }
}' \
--client-secret

ここからは，他のMCPと同様に/mcpで該当のMCP Serverを選んでAuthenticateすれば大丈夫です。


気をつけたいポイント

Client登録方法の対応状況

MCPの公式ドキュメントが示しているClient登録方法は以下の3つです。

  • Client ID Metadata Documents
  • Pre-registration
  • Dynamic Client Registration

Snowflake-managed MCP Serverで対応しているのは，SECURITY INTEGRATIONを用いたPre-registrationのみです。

Secondary Rolesの取り扱い

OAUTH_USE_SECONDARY_ROLES = IMPLICIT を指定すると，ユーザーの default secondary roles が有効化され，MCP 経由で想定以上の権限が使われる可能性があります。まずは NONE とし，必要な権限を MCP 用ロールに明示的に付与する方が安全です。

Cursor + OAuth + Snowflake-managed MCPが現状は実現できない

Snowflakeで許可される redirect URI は以下のような形式です。

http://localhost:<固定ポート>/callback

一方で，Cursorのcallback URLはcursor://から始まります。Snowflake SECURITY INTEGRATIONがこのカスタム形式に対応していないため，現時点では Snowflake-managed MCP × OAuth を Cursor で実現するのは難しそうです。

Claude CodeにおけるMCP追加コマンド

Claude Code の場合，Snowflake 側で発行した client_id / client_secret を指定して MCP Server を追加できます。

MCP_CLIENT_SECRET="<OAUTH_CLIENT_SECRET>" \
claude mcp add --transport http \
  --client-id "<OAUTH_CLIENT_ID>" \
  --client-secret \
  --callback-port 6274 \
  snowflake-document-mcp \
  "https://<account>.snowflakecomputing.com/api/v2/databases/<db>/schemas/<schema>/mcp-servers/<server>"

ただし，この形式ではOAuth認証の途中で以下エラーが発生しました。

The role ALL requested has been explicitly blocked for use with this application by an administrator.

このエラーはOAuth 認可時に要求される scope がデフォルトで session:role:all になっていてSnowflake 側で ALL がブロックされている環境では，そこの不一致が発生するためです。（OAuthのURLを読むとわかります。）

特定ロールに固定したい場合は，claude mcp add-json を使って oauth.scopes を明示します。

MCP_CLIENT_SECRET="<OAUTH_CLIENT_SECRET>" \
claude mcp add-json snowflake-document-mcp \
'{
  "type": "http",
  "url": "https://<account>.snowflakecomputing.com/api/v2/databases/<db>/schemas/<schema>/mcp-servers/<server>",
  "oauth": {
    "clientId": "<OAUTH_CLIENT_ID>",
    "callbackPort": 6274,
    "scopes": "session:role:AI_ANALYST"
  }
}' \
--client-secret

この設定により，Claude Code が Snowflake OAuth に要求する role scope を次のように固定できます。

session:role:AI_ANALYST

認証時にブラウザで開かれる URL を確認し，以下のようになっていれば，意図したロールで認証されています。

scope=session%3Arole%3AAI_ANALYST

OAuthセッションは指定したRoleに固定され USE ROLE できない

oauth.scopes に session:role:<ROLE> を指定してOAuth認証した場合，そのセッションは指定Roleに固定されます。MCP経由でLLMにセッション内のロール切替（USE ROLE）を試みさせると，次のエラーが返ります。

003107: SQL execution error: Current session is restricted. USE ROLE not allowed.

原因は，OAuth scopeでセッションのRoleが固定されていることです。read_only: true の有無とは関係なく，session:role:<ROLE> でscopeを切っている限り USE ROLE を使ったロールの切り替えはブロックされます。

なお，oauth.scopes を指定している間は，実質的に「scopesでallowしたRoleしか使えない」状態を作れます。ただし，この安全策はscope指定が前提であり，SECURITY INTEGRATION 側に「このscopeを必ず指定させる」という強制の仕組みはありません。
scopeの指定はあくまでClient（ユーザー）側で行う設定なので，そのユーザーに付与されているすべてのRoleがMCP経由で使えてしまうことを止められません。ここが懸念になる環境では，個人ユーザーでの接続ではなく，サービスユーザー方式に切り替え，そのユーザーに付与するRole自体を事前に最小限に絞っておく，という運用が良いのかなと思います。

指定したRoleに対象MCP Serverへの権限がないと再接続に失敗する

oauth.scopes で指定したRoleが，対象のSnowflake-managed MCP Serverに対する USAGE 権限（およびその上流のDatabase / Schemaへの USAGE）を持っていない場合，OAuth認可フロー自体は成功しますが，その直後にMCP Serverへの再接続が失敗し，Claude Code上で次のようなエラーが出ます。

Got new credentials, but reconnecting to <registration name> failed. Restart Claude Code to retry.

このエラーは「認証は通ったが認可されていない（Roleにそもそも当該MCP Serverを利用する権限がない）」状態を示しています。Claude Codeを再起動しても同じ結果になるため，対処としては，oauth.scopes に指定するRoleに対して，対象MCP Server・上流Database / Schemaへの USAGE を付与するか，必要権限を持つ別のRoleに oauth.scopes を切り替える必要があります。

MCP Serverの接続設定

MCP Server接続用のホスト名にはアンダースコア（_）ではなくハイフン（-）を使うこと。アンダースコアを含むホスト名では接続に問題が発生します。

細かい話はNowcastの池田が書いた以下テックブログを参照ください。

Snowflake REST API で SSL CertVerificationError が出て沼った話

認可設計（権限設計）

各MCP Client → Snowflake-managed MCP → Tool → Objects それぞれの権限は別レイヤーになります。

MCP Client（Claude Code / Cursor / Claudeなど）
        ↓ 認証 OAuth or PAT
Snowflake Managed MCP Server
        ↓ MCP SERVER USAGE / MODIFY
MCP Tool
        ↓ Tool種別ごとの権限
Semantic View / Cortex Search / Cortex Agent / SQL Execution / UDF / Stored Procedure
        ↓ 実行時に参照されるSnowflakeオブジェクト
Table / View / Warehouse / Database / Schema / Stage

みたいな感じです。この記事では，"実行時に参照されるSnowflakeオブジェクト"の権限は必要十分に持っていることを前提として，それより上のレイヤーの権限を整理します。

ポイントとして，Snowflake公式のセキュリティ推奨事項にも明記されているとおり，MCP Serverへの権限だけじゃなくて，Tool（Cortex Search Service / Semantic View / Cortex Agent / UDF / Stored Procedure）ごとに別途権限を付与する必要があります。

レイヤー 権限 対象オブジェクト 用途
MCP Server管理 CREATE MCP SERVER Schema MCP Serverの作成
MCP Server管理 OWNERSHIP MCP Server MCP Server構成の更新・削除
MCP Server管理 MODIFY MCP Server update / drop / describe / show / use（tools/list, tools/call）
MCP Server利用 USAGE MCP Server MCP Serverへの接続およびTool一覧の取得（discover）
Tool実行 USAGE Cortex Search Service Cortex Search Tool の実行
Tool実行 SELECT Semantic View Cortex Analyst Tool の実行
Tool実行 USAGE Cortex Agent Cortex Agent Tool の実行
Tool実行 USAGE UDF / Stored Procedure UDF / SP Tool の実行

Role設計例

以下の3ロールに役割を分離する構成を例として示します。最小権限の原則に従い，「MCP Serverを作る人」「MCP Serverを所有・運用する人」「MCP Server経由でデータ分析する人」を切り分けます。

そのうえで，MCP固有ではないアカウント横断の責務はSnowflake標準のシステムロールに任せ，MCP関連ロールには以下を含めません。

  • SECURITY INTEGRATION の作成・管理は，CREATE INTEGRATION ON ACCOUNT を持つ SECURITYADMIN（または ACCOUNTADMIN）の責務とします。OAuth Clientの設定はMCPだけでなく他統合でも使う横断的なセキュリティ資産なので，MCP用ロールに寄せません。
  • MCP関連ロールの作成・GRANT管理は，USERADMIN の責務とします。ロール階層の整備をMCP_ADMIN_ROLE自身が行えると，MCP管理者がアカウント全体のRBACを書き換えられる強権限になってしまうためです。

これを踏まえた3ロールは次のとおりです。MCP_ADMIN_ROLE はプラットフォーム横断の責務なのでアカウントに1つ用意し，MCP_OWNER_ROLE と MCP_USER_ROLE はSchemaごとに作成して，所有者と利用者の境界をSchema単位で切り分けます。Schemaは既にドメイン/チームの論理グループとして使われていることが多く，CREATE MCP SERVER の権限単位とも揃うため，ここではSchema単位を前提とします。下位ロールを上位ロールに継承させ，上位は下位の機能を内包する構成にします。

  • MCP_<schema>_USER_ROLE（Schemaごとに作成）

    • 位置付け: 人間のアナリストやデータサイエンティストが，Claude Code / Cursor / ClaudeなどのMCP Client経由でMCP Serverを利用する際のロール。利用させたいSchemaの数だけ用意する。
    • 主な権限:
      • 対象Schema配下のMCP Serverへの USAGE（接続とTool発見）
      • 利用を許可するTool先オブジェクトへの権限（必要なものだけを選択的に付与）
        • Cortex Search Service: USAGE
        • Semantic View: SELECT
        • Cortex Agent: USAGE
        • UDF / Stored Procedure: USAGE
      • 関連Database / Schemaへの USAGE，必要なWarehouseへの USAGE
    • 用途: 対話的な分析・調査ユースケース。OAuth認証で連携することを推奨。

  • MCP_<schema>_OWNER_ROLE（Schemaごとに作成。同じSchemaの MCP_<schema>_USER_ROLE を継承）

    • 位置付け: 対象Schema配下のMCP Serverオブジェクトを所有・保守するロール。利用者として動作確認できるよう，同じSchemaの MCP_<schema>_USER_ROLE を継承する。
    • 主な権限:
      • 対象Schema配下のMCP Serverに対する OWNERSHIP
      • 上流のDatabase / Schemaへの USAGE
      • Tool定義に組み込むCortex Search / Semantic View / Cortex Agent / UDF / SPへの参照権限（Tool定義時の検証用）
    • 用途: MCP Serverのtool構成（server_spec）の更新，削除，describe，show。CI/CDでMCP Serverを更新する場合のデプロイロールとしても利用。

  • MCP_ADMIN_ROLE（アカウントに1つ。各 MCP_<schema>_OWNER_ROLE を継承）

    • 位置付け: MCPプラットフォーム上で新規にMCP Serverを立ち上げるためのロール。既存のMCP Serverを保守するためにOwnerの機能も使えるよう，各SchemaのOwnerロールを継承する。
    • 主な権限:
      • 配置先Schemaへの CREATE MCP SERVER
    • 用途: MCP Serverの新規作成。SECURITY INTEGRATION の作成や，MCP関連ロールの作成・GRANT管理は含まない。

ロール間の関係は次のとおりです。SECURITYADMIN と USERADMIN はSnowflake標準のシステムロールで，MCP関連ロールの外側からセットアップ・運用を支えます。

SECURITYADMIN                       USERADMIN
   │                                   │
   │ CREATE                            │ CREATE ROLE / GRANT管理
   ▼                                   ▼
SECURITY INTEGRATION              MCP_ADMIN_ROLE （アカウントに1つ）
（OAuth Client設定）                    │ 継承
                                       ├────────────────┬────────────────┐
                                       ▼                ▼                ▼
                              MCP_<schemaA>_OWNER  MCP_<schemaB>_OWNER  ...
                                       │ 継承            │ 継承
                                       ▼                ▼
                              MCP_<schemaA>_USER   MCP_<schemaB>_USER   ...
                                       │                │
                                       │ USAGE / SELECT
                                       ▼                ▼
                              Schema A配下の         Schema B配下の
                              MCP Server /          MCP Server /
                              Tool先オブジェクト     Tool先オブジェクト

ユーザーへのGRANTは，アナリストには該当Schemaの MCP_<schema>_USER_ROLE，MCP Serverのオーナー担当には MCP_<schema>_OWNER_ROLE，プラットフォーム管理者には MCP_ADMIN_ROLE を付与する形です。

この構成では，MCP_ADMIN_ROLE は各SchemaのOwner / Userの機能を内包しますが，アカウント横断の権限（INTEGRATION作成，ロールのGRANT管理）は持ちません。MCP固有の責務に閉じた強さに留めることで，事故時の影響範囲を抑えます。

まとめ

Snowflake-managed MCP Serverを本番利用する際は，接続方式を選ぶだけでなく，認証・認可・監査を一体で設計することが重要です。(Snowflakeに限らずですが。)

この辺の運用始めないとわからないと言うことが多分にあるため，十分な検討をしつつもスモールスタートで進めていくのがいいのかもしれません。

この記事が誰かの役に立ちましたら幸いです。

Finatext Tech Blog
Finatext Tech BlogPublication

『金融を"サービス"として再発明する』Finatextグループのテックブログです。

Discussion