Snowflakeコネクタを使用すると、PerplexityからSnowflakeデータウェアハウス内のデータを直接クエリできます。SQLを手動で記述したりSnowflakeコンソールに切り替えたりすることなく、Snowflakeデータベース、その他の接続済みアプリ、ウェブ全体の情報を検索・組み合わせることができます。
Perplexity Pro、Perplexity Max、Enterprise Pro、Enterprise Maxで利用できます。Snowflakeの接続はユーザーごとに行われます。共有プロジェクトにデータを同期しない限り、組織内の他のユーザーがあなたのデータをクエリすることはできません。
このガイドでは、コネクタの仕組み、認証方法の選び方、ロールと読み取り専用アクセスの設定方法、そしてステップバイステップのセットアップを説明します。最短の手順を知りたい場合：ほとんどの組織ではユーザー OAuthを使用すべきです — セットアップガイドにお進みください。
有効化後、コネクタはSnowflakeアカウントに安全に接続し、認可されたデータベース、スキーマ、テーブル、ビュー全体を検索できるようにします。Snowflakeデータが変更されると、コネクタは次回のクエリで変更を自動的に反映します。
サポートされているデータオブジェクト：
テーブル
ビューとマテリアライズドビュー
スキーマ
データベース
構造化データ（CSV、JSON、Parquetバックのテーブル）
非構造化データ（Snowflakeステージに保存された画像、音声、動画）はサポートされていません。
Snowflake認証には2つの独立した次元があります：クエリを誰として実行するか（アイデンティティ）と、そのアイデンティティをどのように証明するか（認証情報）です。Perplexityはディレクトリに2つのコネクタを提供しており、それぞれ推奨される組み合わせに対応しています：
Snowflake (User OAuth) — 各Perplexityユーザーが自分のSnowflakeアカウント（TYPE = PERSON）でOAuth経由でサインインします。ほとんどの組織に推奨。
Snowflake — すべてのPerplexityユーザーが、キーペアを使用する単一の共有サービスアカウント（TYPE = SERVICE）経由でクエリを実行します。エンドユーザーが個別のSnowflakeアカウントを持っていない場合に使用してください。
ユーザー OAuthでは、各ユーザーが自分の認証情報で認証し、クエリはそのユーザー本来のSnowflake権限で実行され、ユーザーごとの明確な監査証跡が得られます。共有サービスアカウントは不要で、ロールベースアクセス制御（RBAC）をPerplexity内で再作成する必要もありません。これはSnowflake自身の方向性とも一致しており、そのマネージドMCPサーバーは現在OAuth 2.0のみをサポートしています。
注意：OAuthでは、アクセストークンはサインイン時に単一のプライマリロール（ユーザーのDEFAULT\_ROLE）に紐付けられます。ユーザーが付与されたすべてにアクセスできるようにするため、セカンダリロールを設定してください（ユーザー OAuth ロール設定を参照）。
共有サービスアカウント（TYPE = SERVICE + キーペア）が適切な場合：
エンドユーザーが個別のSnowflakeアカウントを持っていない場合（例：Perplexity経由でクエリを実行するが、Snowflakeへの直接アクセスを持たないビジネスユーザー）。
監査を簡素化するために、すべてのPerplexityクエリを単一の共有アイデンティティで実行させたい場合。
ユーザーごとのアイデンティティが不要な社内環境やテスト環境を設定する場合。
サービスアカウントには、権限を絞った専用ロールを設定してください — サービスアカウントロール設定を参照してください。
プログラマティックアクセストークン（PAT）に関する注意：SnowflakeはPAT認証情報もサポートしており、コネクタもこれを受け付けます。ただし、新規セットアップにはPATを推奨しません。トークンは短い期間で有効期限が切れ、作成時に単一ロールに固定的に紐付けられるため、このガイドの例では一貫してキーペアを使用しています。どうしてもPATを使用する必要がある場合は、作成時にROLE\_RESTRICTIONをPerplexity専用ロールに設定してください。
OAuthセッションはユーザーのDEFAULT\_ROLEをプライマリロールとして開始されます。セッション内でのロール切り替えはサポートされておらず、Perplexityはロール選択UIを表示しません。つまり、各ユーザーがDEFAULT\_ROLEとDEFAULT\_SECONDARY\_ROLESに設定した内容が、そのままPerplexityセッションで使用されます。
セキュリティ統合レベルで一度だけ設定してください：
OAUTH\_USE\_SECONDARY\_ROLES = IMPLICIT
SnowflakeにおけるこのパラメーターのデフォルトはNONEで、OAuthセッションはプライマリロールのみがアクティブな状態で開始されます。IMPLICITに設定すると、Snowflakeは各ユーザーのDEFAULT\_SECONDARY\_ROLESも自動的に有効化します。これがないと、ユーザーはDEFAULT\_ROLEから到達できるデータのみが見えることになり、これが望ましいケースはほとんどありません。
次に、2つのケースのいずれかに対応してください：
ケースA — ユーザーのロールデフォルトが既に設定されている場合。ユーザーのDEFAULT\_ROLEとDEFAULT\_SECONDARY\_ROLESが既に望む形で設定されている場合、他に何もする必要はありません。IMPLICIT設定で十分です — 各ユーザーの既存のデフォルトがPerplexityセッションで使用されます。
ケースB — ユーザーのロールデフォルトが未設定の場合。DEFAULT\_ROLEをPUBLICに、DEFAULT\_SECONDARY\_ROLESをALLに設定することで、各セッションにそのユーザーに付与されたすべてのロールの和集合を与えます：
ALTER USER \SET DEFAULT\_ROLE = PUBLIC, DEFAULT\_SECONDARY\_ROLES = ('ALL');
注意：Snowflakeの2024年8月の変更以降、DEFAULT\_SECONDARY\_ROLES = ('ALL')は新規作成ユーザーのデフォルトになっているため、多くの組織では既にこの設定がされています。変更する前にDESC USER \を実行して確認してください。
サービスアカウントは、特定の1つのロール（通常はPERPLEXITY\_ROLE）で実行される単一の専用ユーザーです。OAuthで使用するPUBLIC + ('ALL')のパターンはここでは適用されません。代わりに、サービスユーザーのDEFAULT\_ROLEを専用ロールに設定し、そのロールにPerplexityが必要とする権限のみを付与してください。これはSnowflakeのサービスアカウントベストプラクティスに従っています。
このユーザーを作成するための完全なSQLは、下記のセットアップガイドにあります。
PerplexityのOAuth統合経由でユーザーが認証できるSnowflakeロールを制限するには、セキュリティ統合レベルでスコープしてください：
PRE\_AUTHORIZED\_ROLES\_LIST — この統合で許可されるロールの許可リスト。
BLOCKED\_ROLES\_LIST — この統合でブロックされるロールの拒否リスト。
ALTER SECURITY INTEGRATION PERPLEXITY\_OAUTH
SET PRE\_AUTHORIZED\_ROLES\_LIST = ('ANALYST\_ROLE', 'READ\_ONLY\_ROLE');
機密性の高いロール（例：ACCOUNTADMIN）をOAuthフローから完全に除外したい場合に使用してください。
コネクタは、（MergeのSnowflakeコネクタを元にした）ツールサーフェス経由でSQLを実行します。Snowflake (User OAuth)コネクタは、名前付きのきめ細かなツールを公開しています。これには専用の読み取り専用クエリツール（execute\_sql\_readonly）が含まれ、SELECT、WITH、SHOW、DESCRIBE、EXPLAIN、VALUES、LISTのみを受け付け、DDL/DMLや複数ステートメントの入力を拒否します。サービスアカウント用のSnowflakeコネクタは、DDLやDMLを含む任意のSQLを受け付ける汎用のexecute\_sqlツールを公開しています。
信頼できる制御手段はSnowflake RBACです。どのツールが呼び出されても、クエリは設定で許可されたロールの下で実行されるため、Snowflakeロールレベルで読み取り専用を強制することが信頼できる最終防衛線であり、サービスアカウントコネクタでは唯一の強制境界です。
推奨パターン — 専用ロールで読み取り専用を強制する。Perplexityにクエリさせたいデータベース、スキーマ、テーブルに対してUSAGEとSELECTのみを付与し、INSERT、UPDATE、DELETE、CREATE、DROP、OWNERSHIP、ウェアハウスのMODIFYを付与しないPERPLEXITY\_READ\_ONLYのようなロールをプロビジョニングします。その上で、ユーザーがそのロールで認証するようにします：
ユーザーのDEFAULT\_ROLEとして設定する、または
OAuth統合をPRE\_AUTHORIZED\_ROLES\_LISTでスコープする、および/またはBLOCKED\_ROLES\_LISTで書き込み可能なロールを除外します（OAuth経由で使用できるロールの制限を参照）。
このようにRBACを設定することで、どのツールが呼び出されても、Perplexityによる書き込み試行はSnowflakeによって拒否されます。
注意：コネクタ設定には利用可能なツールを一覧表示するツール権限パネルがあります。Snowflake (User OAuth)コネクタでは、公開するツールを絞り込むことができます。読み取り専用のセットアップでは、読み取り系のツール（例：execute\_sql\_readonly、list\_\*、describe\_\*、get\_\*）のみを有効にして、書き込み/DDLツールをサーフェスから除外してください。これは多層防御として扱い、信頼できる境界とはみなさないでください。アクセスを信頼できる形で強制するのは、上記のSnowflake RBACです。
接続されると、Snowflakeコネクタはお客様に代わって以下の操作を実行できます：
Snowflakeデータに対してSQLクエリを実行する
Cortex SearchとCortex Analystをクエリする
カスタムUDFとストアドプロシージャを実行する
Snowflakeでアクセスを取り消したりロールを削除したりすると、そのデータはPerplexityから即座にアクセスできなくなります。PerplexityでSnowflakeを切断した場合、キャッシュされたデータを保持するか削除するかを選択できます。
Enterprise組織向けに、PerplexityはSOC 2 Type II認証、エンドツーエンド暗号化、厳格なデータプライバシー対策、きめ細かなユーザーアクセス制御を提供しています。SnowflakeデータがAIのトレーニングに使用されることはありません。
Snowflakeの接続はユーザーごとに行われます。組織内の他のユーザーがあなたのデータをクエリすることはできません。ただし、共有プロジェクトにデータを同期した場合、そのプロジェクトにアクセスできる全員が検索できるようになります。
組織管理者は、組織設定の権限画面から、すべてのユーザーに対してコネクタを有効または無効にできます。読み取り/書き込みの強制はSnowflakeロールレベルで処理されます（Perplexityの操作範囲の制御を参照）。
認証方法に合ったパスを選択してください：
ユーザー OAuth（推奨）：組織管理者がOAuthアプリを一度設定し、その後ユーザーが個別にサインインします。SnowflakeとPerplexityの接続に直接進んでください — ステップ1〜6のSQLはサービスアカウントセットアップ専用です。
サービスアカウント（キーペア）：ステップ1〜6のSQLセットアップを実行し、ステップ7で接続します。
ACCOUNTADMINロール（またはCREATE USERとGRANT権限を持つロール）
OpenSSLがローカルにインストールされている（macOSには事前インストール済み）— サービスアカウントセットアップのみ
ターミナルからRSA秘密鍵を生成します：
openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out snowflake\_computer\_key.p8 -nocrypt
次に対応する公開鍵を生成します：
openssl rsa -in snowflake\_computer\_key.p8 -pubout -out snowflake\_computer\_key.pub
USE ROLE ACCOUNTADMIN;
-- Create a dedicated role
CREATE ROLE IF NOT EXISTS PERPLEXITY\_ROLE
COMMENT = 'Role for Perplexity service account';
-- Create a warehouse (or use an existing one)
CREATE WAREHOUSE IF NOT EXISTS PERPLEXITY\_WAREHOUSE
WAREHOUSE\_SIZE = 'XSMALL'
AUTO\_SUSPEND = 60
AUTO\_RESUME = TRUE
COMMENT = 'Warehouse for Perplexity queries';
-- Grant warehouse usage to the role
GRANT USAGE ON WAREHOUSE PERPLEXITY\_WAREHOUSE TO ROLE PERPLEXITY\_ROLE;
ACCOUNTADMINとして以下を実行します。RSA\_PUBLIC\_KEYの値をsnowflake\_computer\_key.pubファイルの内容（ヘッダー行とフッター行を除く）に置き換えてください。
USE ROLE ACCOUNTADMIN;
CREATE USER PERPLEXITY\_USER
TYPE = SERVICE
DEFAULT\_ROLE = PERPLEXITY\_ROLE
DEFAULT\_WAREHOUSE = PERPLEXITY\_WAREHOUSE
COMMENT = 'Service account for Perplexity'
RSA\_PUBLIC\_KEY = 'MIIBIjANBgkqhki...your\_public\_key\_here...IDAQAB';
-- Grant the dedicated role to the service account
GRANT ROLE PERPLEXITY\_ROLE TO USER PERPLEXITY\_USER;
注意：TYPE = SERVICEはこれを非人間アカウントとして指定します — パスワードは設定しないでください。DEFAULT\_ROLE = PERPLEXITY\_ROLEにより、Perplexityが必要とする権限のみを持つ1つの専用ロールにスコープされます。
-- Grant access to a specific database
GRANT USAGE ON DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
-- Grant access to all schemas in a database (current and future)
GRANT USAGE ON ALL SCHEMAS IN DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
GRANT USAGE ON FUTURE SCHEMAS IN DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
-- Grant read access to all tables and views (current and future)
GRANT SELECT ON ALL TABLES IN DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
GRANT SELECT ON FUTURE TABLES IN DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
GRANT SELECT ON ALL VIEWS IN DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
GRANT SELECT ON FUTURE VIEWS IN DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
より選択的なアクセスについては、Snowflake GRANTドキュメントを参照してください。
Perplexityは、正確なクエリ生成のためのデータマップを構築するために、SNOWFLAKE.ACCOUNT\_USAGEスキーマの2つのビューを使用します：
|
ビュー |
目的 |
|
|
クエリメタデータ、パフォーマンス、使用パターン |
|
|
オブジェクトレベルの監査証跡（Enterprise Editionのみ） |
USE ROLE ACCOUNTADMIN;
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE PERPLEXITY\_ROLE;
注意：ACCESS\_HISTORYはSnowflake Enterprise Edition以上でのみ利用可能です。Standard EditionではPerplexityは自動的にQUERY\_HISTORYにフォールバックします。このステップをスキップするとクエリ精度が低下します。Perplexityがこれらのビューをどのように使用するかについては、データマップについてを参照してください。