Notion向けSnowflake MCPをセットアップする

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

セットアップは段階的に行われ、各段階に担当のユーザーがいます。

• Snowflake管理者が、ロール、ウェアハウス、Snowflake管理下のMCPサーバーをセットアップします。

• Notionのワークスペースオーナーか管理者が、ワークスペースのSnowflake MCPコネクションを設定します。

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

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

• Snowflakeの管理下にあるMCPサーバーは、中国本土や政府機関向けのリージョンでは利用できません。

• Notionワークスペースはビジネスプランかエンタープライズプランを利用している必要があります。

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

• あなたの会社にSnowflakeアカウントが必要です。

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

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

ロールとウェアハウスをセットアップし、Snowflake管理下の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ではIMPLICITセカンダリロールとALLOWED_ROLES_LISTを併用できないため、このモデルを使用する場合は許可リストを省略してください。

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

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

サーバーを実行することになるチームが所有するデータベースとスキーマを作成するか、選択します。

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

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

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

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

各ツールが必要とする追加リソースに対してのみアクセス権を付与してください。たとえば、承認されたセマンティックビューに対するSELECT、Cortex Searchサービスに対する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の準備が整ったら、ワークスペースオーナーか管理者が、そのワークスペースにサーバーを1回追加します。その後、メンバーはSnowflake MCPをカスタムエージェントに接続する場合でも、自分のNotionエージェントに接続する場合でも、OAuthクライアントシークレットを見ることなくサーバーを見つけられます。

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

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

3. 新しいワークスペースMCPを選択します。

以下のフィールドに入力し、MCPサーバーを追加を選択します。

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

この設定でできること。

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

• OAuthクライアントシークレットをNotionの暗号化されたコネクションストレージに1回保存します。

• メンバーが、承認済みのサーバーURL、クライアント、スコープを使ってサインインできるようにします。

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

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

この設定を削除すると、新しいメンバーはサーバーを見つけられなくなります。既存のコネクションは表示されたままになる可能性があるため、この変更と同時に、Snowflakeの権限取り消しと既存のコネクションの削除を実施してください。

管理者がSnowflake MCPコネクションを準備した後は、2通りの方法でそれを利用できます。チーム用に設定する場合は11Aから始めてください。自分の質問に答えてほしいだけなら、11Bに進んでください。両方を設定することもできます。それぞれ別のコネクションになります。

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

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

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

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

3. コネクションを追加を選択し、管理対象ワークスペースのラベルが付いたSnowflakeサーバーを選択します。カスタムMCPサーバーを選択したり、サーバーURLを手動で入力したりしないでください。

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

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

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

7. 接続を選択し、コネクションが接続済みと表示されることを確認します。

エージェントにコンテキストを提供する

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

エージェントを共有する

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

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

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

2. MCPサーバーの下で、MCPサーバーを追加を選択します。

3. 管理対象ワークスペースのラベルが付いたSnowflakeサーバーを選択します。カスタムMCPサーバーを選択したり、サーバーURLを手動で入力したりしないでください。

4. 接続を選択します。

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

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

7. ブラウザでNotionを開くかどうか尋ねられたら、Notionを開くを選択します。

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

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

1. Snowflakeを使って答える必要のある、無害で、答えが分かっている質問をします。

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

3. 自分に付与されたロールの範囲外のデータにアクセスできないことを確認します。

カスタムエージェントを設定した場合は、Snowflakeのロールがより限定されたチームメイトにも試してもらってください。そのチームメイトには、あなたではなく本人に閲覧が許可されたデータだけが表示されるはずです。これが、エージェントがあなたではなく各ユーザーのアクセス権を使っていることを確認する最も手早い方法です。

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

エージェントにSnowflakeデータに関する具体的な質問をしてください。たとえば、次のように質問できます。

• 「Snowflakeのデータによると、先月の合計サインアップ数はいくつでしたか？」

• 「Snowflakeのデータによると、今四半期の収益が高いアカウント上位10社はどこですか？」

カスタムエージェントの場合、いつSnowflakeを使うかが指示で明確になっていれば、通常は「Snowflakeのデータによると」を省略できます。Notionエージェントの場合は、Snowflakeを指定すると、エージェントが適切なソースを選ぶのに役立ちます。

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

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

以下の場合、再度サインインする必要があります。

• リフレッシュトークンの有効期限が切れたか、管理者がリフレッシュトークンを無効にした場合

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

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

• 管理者がワークスペースの設定かコネクションを削除した場合

• ネットワークポリシーによってトークンの更新がブロックされた場合

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

クライアントシークレットをローテーションする場合は、インテグレーションを置き換えずに、Snowflakeの2つのシークレットを使ってローテーションします。古いシークレットを廃止する前に、ワークスペースの設定を更新してテストするための十分な時間、両方のシークレットを有効にしておいてください。

ALTER SECURITY INTEGRATION <oauth_integration_name>
REFRESH OAUTH_CLIENT_SECRET_2;

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

• クライアントIDやシークレットを求められます。おそらくカスタムMCPオプションを選択しています。戻って、代わりに管理対象ワークスペースとマークされたSnowflakeサーバーを選択してください。

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

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

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

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

• サインインはできましたが、接続できないか、ツールが動作しません。サインインは本人確認を行うものですが、アクセス権は引き続きSnowflakeの権限設定に依存します。Snowflake管理者に、あなたのロールでサーバー、ウェアハウス、エージェント、データにアクセスできるか確認を依頼してください。

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

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

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

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

• 「このサーバーはOAuth認証をサポートしていません」と表示されます。セキュリティインテグレーションがOAuth用に設定されていないか、サーバーURLが間違っています。Snowflake管理者に、OAuthセキュリティインテグレーションとサーバーURLを確認するよう依頼してください。

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

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

• 「すべてを要求したロールが明示的にブロックされました」と表示されます。コネクションですべてのロールが一度に要求されました（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エージェントに接続する

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