Notion用Snowflake MCPのセットアップ

カスタムエージェントとNotionエージェントは、Snowflakeが実行するMCP（Model Context Protocol）サーバーを通じてSnowflakeに接続できます。セットアップが完了すると、エージェントにSnowflakeウェアハウスのデータについて質問し、Notionで直接回答を得ることができます。

セットアップは段階的に行われ、各段階に担当者がいます：

• Snowflake管理者が、ロール、ウェアハウス、およびMCPサーバーを設定します。

• Notionワークスペースオーナーまたは管理者が、ワークスペースのSnowflake MCP接続を構成します。

• ワークスペースメンバーは、各自のSnowflake認証情報を使用してカスタムエージェントからSnowflake MCPに接続するか、SnowflakeをNotionエージェントに直接接続できます。この記事のステップ1〜10は、どちらのパスでも同じです。ステップ11で、接続したいエージェントに応じてパスが分かれます。

• 利用可能なツールは、Snowflakeのクラウドリージョンによって異なる場合があります。

• SnowflakeのMCPサーバーは、中国本土または政府機関向けリージョンでは利用できません。

• ワークスペースはビジネスプランまたはエンタープライズプランである必要があります。

• Notionはウェブ版またはデスクトップ版を使用してください。この機能はモバイルでは利用できません。

• 会社でSnowflakeアカウントが必要です。

• カスタムエージェントを構築するには、ワークスペースでエージェントを作成する権限が必要です。

チームがSnowflakeをNotionに接続する前に、Snowflake管理者がアクセスを設定する必要があります。これは最も手間のかかるステップですが、一度だけ行えば完了します。Notionワークスペース管理者と連携してください。NotionがリダイレクトURIを提供し、SnowflakeがOAuthクライアントIDとシークレットを提供します。

ロールとウェアハウスを設定し、MCPサーバーを作成し、必要なリソースへのアクセスを付与し、OAuthスコープとセキュリティ対策統合を構成し、組織で必要な場合はネットワークポリシーを追加します。

始める前に、Notionワークスペース管理者と一緒にこのワークシートに記入してください。セットアップが完了すれば、メンバーはこれをスキップして、各自のSnowflakeアカウントでサインインできます。

アカウントのホスト名にはアンダースコアではなくハイフンを使用します。サーバーURL内の各オブジェクト名が、Snowflake内の対応するオブジェクト名と一致していることを確認してください。

可能な限り、専用の最小権限ロールと承認済みのウェアハウスを1つ使用してください。

セカンダリロールのない制限付きロール（推奨）。 このモデルは理解と監査が容易です。OAUTH_USE_SECONDARY_ROLES = NONEを設定し、ALLOWED_ROLES_LISTを指定して、Notionスコープsession:role:<mcp_access_role>を使用してください。

ユーザーのデフォルトのセカンダリロール（オプション）。 このモデルは、サーバーが各ユーザーのSnowflake DEFAULT_SECONDARY_ROLESから継承された権限を必要とする場合にのみ使用してください。OAUTH_USE_SECONDARY_ROLES = IMPLICITを設定し、ALLOWED_ROLES_LISTを省略して、明示的なメインロールスコープを使用してください。SnowflakeではALLOWED_ROLES_LISTを使用したIMPLICITセカンダリロールは許可されないため、このモデルを使用する場合は許可リストを省略してください。

MCPサーバーには、可能な限り専用の最小権限ロールを使用してください。

このロールは、通常のID管理プロセスを通じて付与してください。OktaまたはSCIMがSnowflakeのロールメンバーシップを管理している場合は、そのプロセス外で手動でユーザーを追加しないでください。

サーバーを実行するチームが所有するデータベースとスキーマを作成または選択してください。

管理されたビジネス上の質問については、メンバーが使用するツールとしてCortex Agentを公開できます。これにより、セマンティックビュー、検証済みクエリ、検索、オーケストレーションを一元管理できます。Cortex Agentはオプションです。作成する場合は、以下の仕様を使用してください。既存のエージェントを置き換える場合は、置き換え後のエージェントが承認済みの仕様と一致していることを確認してください。

その他のサポートされているSnowflake MCPツールタイプには、CORTEX_ANALYST_MESSAGE、CORTEX_SEARCH_SERVICE_QUERY、GENERIC、SYSTEM_EXECUTE_SQLがあります。

各ツールに明確な名前と説明を付けてください。どのようなデータを対象としているか、結果の詳細はどの程度か、いつ使用すべきかを説明してください。これにより、エージェントが適切なツールを選択できるようになります。

MCPサーバー上のUSAGE権限により、ロールはサーバーに接続してそのツールを検出できるようになります。この権限では、ウェアハウス、エージェント、セマンティックビュー、検索サービス、ストアドプロシージャ、または基盤となるデータへのアクセス権はロールに付与されません。サーバーのツールが必要とする各リソースへのアクセス権をロールに付与してください。

各ツールが必要とする追加リソースに対してのみアクセス権を付与してください。例えば、承認されたセマンティックビューに対するSELECT、Cortex 検索サービスに対するUSAGE、または特定の関数やプロシージャに対するUSAGEを付与します。PUBLICに対してロールを付与したり、現在または将来のオブジェクトに対して広範な権限を追加したりしないでください。

OAuthを設定する前に、MCPサーバーとその権限を確認してください。

メンバーが要求すべき正確なロールをアドバタイズするようにMCPスキーマを設定してください。

明示的なロールスコープを使用してください。session:role:allは使用しないでください。Snowflakeはその値をユーザーのデフォルトのメインロールとして扱い、すべてのロールへのアクセスとしては扱いません。また、特権ロールのポリシーによってブロックされる可能性があります。明示的なロールを使用することで、要求されたアクセスが明確になり、確認が容易になります。

このSQLを実行する前に、Notionワークスペースの管理者と調整してください。ワークスペースのMCP設定フォームにSnowflakeサーバーのURLを入力するよう依頼し、認証を手動で構成とワークスペース共有OAuthクライアントを使用をオンにしてください。NotionがリダイレクトURIを生成します。それをコピーしてSnowflake管理者に送信してください。SnowflakeがクライアントIDとシークレットを作成した後、ワークスペース管理者が接続の設定を完了できます。

Notionが提供するリダイレクトURIをそのまま使用してください。末尾にスラッシュやクエリパラメータを追加したり、ホストを変更したりしないでください。

IS_AGENTIC = TRUEを設定すると、この統合を通じて作成されたセッションはエージェントセッションとしてマークされます。これにより、SnowflakeのIS_AGENT_ACTIVATED()関数はTRUEを返し、Snowflakeはエージェント固有の監査およびガバナンスを適用できるようになります。オプションのセカンダリロールモデルを使用する場合は、OAUTH_USE_SECONDARY_ROLES = IMPLICITを設定し、ALLOWED_ROLES_LISTを省略してください。

リフレッシュトークンの有効期間である7776000秒は90日に相当します。これを使用する前に、組織の再認証およびトークンローテーションポリシーに適合していることを確認してください。日常的な変更には、CREATE OR REPLACE SECURITY INTEGRATIONの使用を避けてください。統合を置き換えると、既存の接続が中断される可能性があります。

シークレットを表示せずに統合を確認するには、以下を実行します。

統合が有効になっていること、リダイレクトURIが完全に一致していること、ロールが許可されておりブロックされていないこと、リフレッシュトークンとPKCEが有効になっていること、および認可エンドポイントとトークンエンドポイントの両方がSnowflakeのパブリックアカウントホストを使用していることを確認してください。

このステップは、組織でネットワークポリシーが必要な場合にのみ実行します。セキュリティまたはネットワークのオーナーに、Notionの現在のエグレス範囲を承認するよう依頼してください。

OAuth統合では、両方のNotionプログラムを許可する必要があります。

1. OAuthコールバックを処理し、認可コードを交換するAPIプログラム

2. 接続を検証し、ツールを実行し、トークンを更新するワークスペースランタイムプログラム

これらのプログラムでは、異なるNotionエグレスアドレスが使用される場合があります。最初のトークン交換中に使用されたアドレスのみを許可した場合、サインインは成功しても、検証やトークンの更新が失敗する可能性があります。Notionの現在承認されているエグレス範囲を使用してください。ブラウザやログから取得した一時的なIPアドレスを本番環境の許可リストに追加しないでください。

このネットワークポリシーは、個々のユーザーではなく、OAuth統合に適用してください。ブラウザサインイン、VPNアクセス、またはユーザーネットワークアクセスに対するアカウント全体のポリシーは変更しないでください。ネットワークポリシーがトークンリクエストをブロックした場合、Snowflakeは invalid_client を返すことがあります。このエラーは、必ずしもクライアントIDやシークレットが正しくないことを意味するわけではありません。

これを安全なSnowflakeワークシートで実行します。統合名は大文字と小文字を区別し、通常は大文字です：

クライアントIDとそれに対応するシークレットを、承認された安全なチャネルを使用してNotionワークスペース管理者に共有してください。Snowflakeは2つの有効なシークレットを提供するため、ダウンタイムなしでローテーションできます。シークレットをドキュメント、チャット、チケット、またはソース管理に貼り付けないでください。

Snowflakeの準備ができたら、ワークスペースの所有者または管理者がワークスペースに対してサーバーを一度追加します。その後、メンバーはSnowflake MCPをカスタムエージェントに接続する場合でも、独自のNotionエージェントに接続する場合でも、OAuthクライアントシークレットを見ることなくそれを見つけることができます。

1. ワークスペースの Settings に移動します。

2. コネクション → ワークスペース共有MCP を選択します。

3. New workspace MCP を選択します。

これらのフィールドに入力し、Add MCP server を選択します：

保存後、新しい行がこのワークスペースと共有の下に表示され、ワークスペースOAuthクライアントが設定済みと表示されることを確認してください。

この設定が行う内容:

• メンバーが承認済みのサーバーを見つけやすくします。

• OAuthクライアントシークレットをNotionの暗号化された接続ストレージに一度だけ保存します。

• メンバーが承認したサーバーURL、クライアント、およびスコープでサインインすることを確実にします。

• 共有Snowflakeセッションを作成したり、Snowflakeのアクセス制御をバイパスしたりすることはありません。

• すべてのメンバーを自動的に接続することはありません。各メンバーが個別にサインインする必要があります。

この設定を削除すると、新しいメンバーはサーバーを見つけることができなくなります。既存の接続は表示されたままになる可能性があるため、Snowflakeの権限取り消しや既存の接続の削除と合わせてこの変更を行ってください。

管理者がSnowflake MCP接続の準備を完了したら、それを使用する方法は2つあります。チーム用に設定する場合は、11Aから始めてください。自分自身の質問をするだけであれば、11Bに進んでください。両方行うことも可能です。これらは別々の接続です。

カスタムエージェントを使用すると、チームはSnowflakeのデータに関する質問を1か所で行えるようになります。Snowflakeを一度接続し、指標やテーブルに関する指示を追加して、エージェントをチームと共有します。これを使用するすべてのユーザーは、各自の認証情報でSnowflakeにサインインする必要があるため、各ユーザーは自分が閲覧を許可されているデータに基づいた回答のみを得ることができます。

Snowflakeをカスタムエージェントに接続する

1. カスタムエージェントを開くか、新しく作成します。

2. 設定 → ツールとアクセスの順に移動します。

3. 接続を追加を選択し、Workspace Managedとラベル付けされたSnowflakeサーバーを選択します。Custom MCP serverを選択したり、サーバーURLを手動で入力したりしないでください。

4. ブラウザでSnowflakeにサインインします。組織で通常使用しているOktaやSSOのサインイン画面が表示される場合があります。

5. 要求されたSnowflakeロールを確認し、承認します。

6. エージェントが使用できるツールを選択します。書き込み可能なツールとCORTEX_AGENT_RUNは、テストが完了するまで承認を求める設定のままにしておいてください。

7. Connectを選択し、接続が接続済みと表示されることを確認します。

エージェントにコンテキストを与える

この接続により、エージェントはSnowflakeにアクセスできるようになります。指示には、会社がそのデータをどのように使用するかを記述します。エージェントの指示の中で、どのような種類の質問に対してどのツールを使用するか、チームが主要な指標をどのように定義しているか、どのテーブルやセマンティックビューから開始すべきかを説明してください。検証済みの質問例をいくつか用意しておくと非常に役立ちます。すぐに使える開始点については、「Data Scoutツールキットガイド」を参照してください。

エージェントを共有する

他のカスタムエージェントと同様の方法で、チームとエージェントを共有します。Snowflakeを必要とする質問を初めて行う際に、各自のSnowflakeアカウントでサインインするよう求められます。クライアントIDやシークレットの入力を求められることはありません。

自分のチャットで独自の質問をしたい場合は、SnowflakeをNotionエージェントに接続します。自分のSnowflakeアカウントでサインインするため、エージェントは自分が閲覧を許可されているデータにのみアクセスします。

1. 設定 → Notion AIを開きます。

2. MCPサーバーの下にあるMCPサーバーを追加を選択します。

3. Workspace Managedとラベル付けされたSnowflakeサーバーを選択します。Custom MCP serverを選択したり、サーバーURLを手動で入力したりしないでください。

4. Connectを選択します。

5. ブラウザでSnowflakeにサインインします。組織で通常使用しているOktaやSSOのサインイン画面が表示される場合があります。

6. 要求されたSnowflakeロールを確認し、承認します。

7. ブラウザでNotionを開くかどうかを確認するメッセージが表示されたら、Notionを開くを選択します。

8. サーバーのステータスが 認証が必要 ではなく、接続済み であることを確認してください。

接続後、チャットの すべてのソース → MCPサーバー にSnowflakeが表示されます。

1. Snowflakeを使用するはずの、答えがわかっている無害な質問をしてください。

2. エージェントがSnowflakeを使用し、結果を返すことを確認してください。

3. 与えられたロールの範囲外のデータにアクセスできないことを確認してください。

カスタムエージェントをセットアップした場合は、Snowflakeのロールがより制限されているチームメイトにも試してもらうようにしてください。彼らは自分のデータのみを見ることができ、あなたのデータは見ることができないはずです。これが、エージェントが作成者のアクセスではなく、各個人のアクセスを使用していることを確認する最も早い方法です。

より詳細な確認を行うには、Snowflake管理者に依頼して、ユーザー、ロール、ウェアハウス、およびクエリ履歴を確認してもらってください。サインインが成功しても本人確認にはなりますが、すべての権限が正しいことの確認にはなりません。

Snowflakeのデータについて、エージェントに具体的な質問をしてください。例：

• 「Snowflakeから、先月の合計登録者数を教えてください。」

• 「Snowflakeから、今四半期の収益が高いアカウント上位10社を教えてください。」

カスタムエージェントの場合、指示でいつ使用するかが明確になっていれば、通常「Snowflakeから」という言葉を省略できます。Notionエージェントでは、Snowflakeと指定することで、エージェントが適切なソースを選択しやすくなります。

大規模なリクエストは時間がかかったり、タイムアウトしたりすることがあります。その場合は、より限定的な質問をするか、リクエストを小さな質問に分割してください。

ほとんどの場合、何もしなくても接続は維持されます。Snowflakeは短期間有効なアクセストークンを使用し、Notionがバックグラウンドでそれらを更新します。アクセストークンの期限が切れただけでは、接続は切断されません。

次のような場合は、再度サインインする必要があります。

• リフレッシュトークンの有効期限が切れた場合、または管理者がそれを取り消した場合

• 管理者がOAuth統合またはクライアントシークレットを置き換えた場合

• Snowflakeのロールが削除された場合

• 管理者がワークスペースの設定または接続を削除した場合

• ネットワークポリシーがトークンの更新をブロックしています

カスタムエージェントを使用する場合、各ユーザーのサインインは個別に行われます。あるユーザーが再度サインインを求められても他のユーザーには影響せず、エージェントを作成したユーザーが何かを行う必要はありません。

クライアントシークレットをローテーションする場合： 統合を置き換えるのではなく、Snowflakeの2つのシークレットによるローテーションを使用してください。古いシークレットを廃止する前に、両方のシークレットを十分に長い期間有効にして、ワークスペースの設定を更新およびテストできるようにしてください。

ALTER SECURITY INTEGRATION <oauth_integration_name>
REFRESH OAUTH_CLIENT_SECRET_2;

• Snowflake MCP接続がリストにありません。 ワークスペース管理者がまだ追加していないか、ワークスペースがカスタムサーバーを制限している可能性があります。管理者にサポートを依頼してください。

• クライアントIDまたはシークレットを求められます。 おそらくカスタムMCPオプションを選択しています。戻って、Workspace Managed とマークされたSnowflakeサーバーを選択してください。

• 再度サインインを求められます。 Snowflakeセッションの有効期限が切れているか、管理者が接続を更新した可能性があります。Snowflakeに再度サインインしてください。

• カスタムエージェントを開いたときにSnowflakeへのサインインを求められました。 初回は想定される動作です。管理されたカスタムエージェントを使用する各ユーザーは、自身のSnowflake認証情報でサインインする必要があります。

• チームメイトが同じカスタムエージェントから異なる結果を取得しました。 想定される動作です。エージェントは各チームメイトのSnowflakeアクセスを使用するため、ロールが異なれば表示されるデータも異なります。

• カスタムエージェントがチャットでは機能しますが、スケジュールでは機能しません。 スケジュール実行やトリガー実行にはサインインしているチームメイトが存在しないため、現時点ではチームメイトごとのサインインを伴うSnowflakeアクセスを使用できません。

• サインインしましたが、接続できないか、ツールが失敗します。 サインインは本人確認を行うものですが、アクセスは引き続きSnowflakeの権限付与に依存します。Snowflake管理者に、ご自身のロールでサーバー、ウェアハウス、エージェント、およびデータにアクセスできるか確認を依頼してください。

• エージェントがテーブルを見つけられません。 エージェントは、お客様のSnowflakeアカウントがアクセスできるデータにのみアクセス可能です。Snowflakeの権限を確認し、質問にテーブル名を含めてください。

• リクエストがタイムアウトします。 より具体的な質問をするか、リクエストを小さな質問に分割してください。

これらのエラーは通常、NotionではなくSnowflakeの設定に起因します。Snowflake管理者に共有してください。

• サーバーURLが https://https%3A... のように重複して表示されます。 アドレスの先頭に余分な https:// が付いた状態で貼り付けられています。URLが https:// 1つだけで始まるように修正してください。

• 「This server does not support OAuth authentication.（このサーバーはOAuth認証をサポートしていません）」と表示されます。 セキュリティ統合がOAuth用に設定されていないか、サーバーURLが間違っています。Snowflake管理者に、OAuthセキュリティ統合とサーバーURLを確認するよう依頼してください。

• サインインまたは更新中に invalid_client と表示されます。 クライアントIDまたはシークレットが間違っているか、シークレットが変更されています。管理者に現在のクライアントIDとシークレットを問い合わせてください。

• サインインは成功しますが、すぐに失敗します。 ロールがサーバーに到達していないか、ロールまたはネットワークルールがセッションをブロックしている可能性があります。管理者に権限とポリシーを確認するよう依頼してください。

• 「The role ALL requested has been explicitly blocked.（要求されたロールALLは明示的にブロックされています）」と表示されます。 接続が一度にすべてのロール（session:role:all）を要求しましたが、これはブロックされています。代わりに、session:role:analystのように、実際のロール名を使用して正確なロールを1つ指定してください。

• リダイレクトエラー（エラー390307）が表示されます。 Snowflakeに保存されているリダイレクトURLが、Notionで使用されているものと一致しません。管理者に、セキュリティ対策のリダイレクトURLをNotionの正確な値に設定するよう依頼してください。

• 無効なコードチャレンジに関するエラー390311が表示されます。 これはPKCEの不一致です。管理者に、セキュリティ対策でOAUTH_ENFORCE_PKCEが正しく設定されていることを確認するよう依頼してください。

• 接続はされていますが、ツールが表示されません。 MCPサーバーに対するUSAGE権限がロールに不足している可能性があります。管理者に権限を確認してもらい、その後DESCRIBE MCP SERVERを実行してセットアップを確認してください。

• 期待していたよりも多くのデータ、または少ないデータにアクセスできます。 セカンダリロールによって、セッションで参照できる内容が変わります。管理者に、セッションでどのロールがアクティブになっているかを確認してください。

• 以前は機能していましたが、クライアントシークレットがローテーションされたため、全員が接続に失敗するようになりました。 保存された接続が古くなっていますので、管理者に新しいクライアントシークレットを確認してもらい、再度接続してください。

• 以前は正常に動作していましたが、現在、あなただけで動作しなくなっています。 ロール、権限、またはポリシーが変更されたか、セッションの有効期限が切れている可能性があります。再度サインインいただき、管理者にアクセスの状態をご確認いただくようお願いします。

• アカウント識別子が拒否されました。 ドットではなく、myorg-myaccountのようにハイフンを使用したorganization-account形式を使用してください。

• PrivateLinkアカウントが接続できません。 PrivateLinkアカウントには追加のネットワーク設定が必要です。PrivateLinkがNotion接続を許可しているかどうかを管理者に確認してください。

• Snowflakeは、スケジュール実行やトリガー実行では利用できません。 これらの実行にはサインインしているユーザーが存在しないため、現時点では個人ごとのサインインを使用できません。代わりにチャットでリクエストを実行してください。

• ブラウザ経由でサインインした後、oauth_security_errorが表示されます。 アカウントレベルのネットワークポリシーがリクエストをブロックしている可能性があります。管理者が以下を実行して確認できます：

• サインインは成功したように見えますが、正しいスコープを指定してもロールエラーが発生します。 デフォルトのロールがブロックされている可能性があります（例：ACCOUNTADMINやBLOCKED_ROLES_LISTに含まれるロール）。管理者が確認して修正できます：

これらの読み取り専用コマンドは、設定を変更することなく管理者がセットアップを確認するのに役立ちます。Snowflakeで実行してください。

セットアップを完了するには、以下のSnowflakeガイドを使用してください：

• Snowflake管理型MCPサーバー

• Snowflake OAuthセキュリティ統合を作成する

• カスタムクライアント向けのSnowflake OAuth

• Snowflake OAuthの概要

• Snowflakeアカウント識別子

• カスタムエージェント

• カスタムエージェント向けのMCP接続

• MCPサーバーをNotionエージェントに接続する

• エージェントを接続する際のセキュリティ対策に関するベストプラクティス