Snowflakeコネクタについて
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
ユーザー 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 ロール設定
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 <username> SET DEFAULT_ROLE = PUBLIC, DEFAULT_SECONDARY_ROLES = (‘ALL’);
注意：Snowflakeの2024年8月の変更以降、DEFAULT_SECONDARY_ROLES = (‘ALL’)は新規作成ユーザーのデフォルトになっているため、多くの組織では既にこの設定がされています。変更する前にDESC USER <username>を実行して確認してください。
サービスアカウントロール設定
サービスアカウントは、特定の1つのロール（通常はPERPLEXITY_ROLE）で実行される単一の専用ユーザーです。OAuthで使用するPUBLIC + (‘ALL’)のパターンはここでは適用されません。代わりに、サービスユーザーのDEFAULT_ROLEを専用ロールに設定し、そのロールにPerplexityが必要とする権限のみを付与してください。これはSnowflakeのサービスアカウントベストプラクティスに従っています。
このユーザーを作成するための完全なSQLは、下記のセットアップガイドにあります。
（オプション）OAuth経由で使用できるロールの制限
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フローから完全に除外したい場合に使用してください。
Perplexityの操作範囲の制御
コネクタは、（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には事前インストール済み）— サービスアカウントセットアップのみ
ステップ1：キーペアの生成（サービスアカウント）
ターミナルから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
ステップ2：ロールとウェアハウスの作成
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;
ステップ3：サービスアカウントユーザーの作成
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つの専用ロールにスコープされます。
ステップ4：データへのアクセス権の付与
— 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ドキュメントを参照してください。
ステップ5：クエリ履歴とアクセス履歴へのアクセス権の付与
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がこれらのビューをどのように使用するかについては、データマップについてを参照してください。
アクセスの確認
USE ROLE ACCOUNTADMIN;
GRANT ROLE PERPLEXITY_ROLE TO USER <your_username>;
USE ROLE PERPLEXITY_ROLE;
USE WAREHOUSE PERPLEXITY_WAREHOUSE;
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY LIMIT 5;
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY LIMIT 5;
ステップ6：（オプション）IPアドレスの許可リスト設定
SnowflakeアカウントがIPで受信接続を制限している場合は、こちらのページのIPアドレスを許可リストに追加してください：
USE ROLE ACCOUNTADMIN;
CREATE NETWORK POLICY PERPLEXITY_COMPUTER_POLICY
ALLOWED_IP_LIST = (…US IPs from the link above…);
ALTER USER PERPLEXITY_USER SET NETWORK_POLICY = PERPLEXITY_COMPUTER_POLICY;
ステップ7：SnowflakeとPerplexityの接続
ユーザー OAuth用：まず管理者がセットアップ
組織がOAuthを使用している場合、個々のユーザーが認証できるようになる前に、組織管理者がSnowflake (User OAuth)コネクタを一度設定します。組織設定 → コネクタ → Snowflake (User OAuth)で、管理者は3ステップのパネルを確認できます：
OAuthアプリを管理 — PerplexityをSnowflakeアカウントに対するOAuthクライアントとして登録します。カスタムSnowflake SECURITY INTEGRATIONを作成し、生成されたクライアントIDとクライアントシークレットをPerplexityに貼り付ける手順を案内します。
Snowflake (User OAuth) で認証 — 管理者が一度認証して、統合がエンドツーエンドで機能することを確認します。
データマップを生成する（オプション） — 組織のデータマップをオプションで生成し（データマップについてを参照）、精度向上のための補足コンテキストを追加します。
ステップ1では、Snowflake側でセキュリティ統合を作成します。ACCOUNTADMINとして以下を実行してください：
USE ROLE ACCOUNTADMIN;
CREATE SECURITY INTEGRATION PERPLEXITY_OAUTH
TYPE = OAUTH
ENABLED = TRUE
OAUTH_CLIENT = CUSTOM
OAUTH_CLIENT_TYPE = ‘CONFIDENTIAL’
OAUTH_REDIRECT_URI = ‘https://ah.merge.dev/oauth/callback’
OAUTH_ISSUE_REFRESH_TOKENS = TRUE
OAUTH_REFRESH_TOKEN_VALIDITY = 7776000
OAUTH_USE_SECONDARY_ROLES = IMPLICIT
COMMENT = ‘OAuth security integration for Perplexity’;
クライアントIDとクライアントシークレットを取得してPerplexityに貼り付けます：
SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS(‘PERPLEXITY_OAUTH’);
管理者のセットアップが完了すると、個々のユーザーは以下の手順で接続できます。
接続（全ユーザー）
ユーザーには、管理者が設定したコネクタに対応する認証方法のみが表示されます。
設定のコネクタに移動し、SnowflakeまたはSnowflake (User OAuth)コネクタを見つけます。
有効化 → コネクタを追加をクリックします。
設定された認証方法を使用して認証します（下記参照）。
許可をクリックしてセットアップを完了します。
キーペア認証（Snowflakeコネクタ）。Snowflakeアカウント識別子、ユーザー名、秘密鍵（snowflake_computer_key.p8）を入力します。
OAuth（Snowflake (User OAuth) コネクタ）。サインインのためにSnowflakeにリダイレクトされます。ロール選択UIはありません — セッションはDEFAULT_ROLEをプライマリロールとして使用し、DEFAULT_SECONDARY_ROLESはOAUTH_USE_SECONDARY_ROLES = IMPLICITにより有効化されます。ロールのデフォルトが既に設定されている場合、追加の操作は不要です。
セッションで表示されるべきデータが見つからない場合は、Snowflake管理者にDEFAULT_ROLEとDEFAULT_SECONDARY_ROLESを確認するよう依頼してください（ユーザー OAuth ロール設定を参照）。
Snowflakeデータの活用
接続後、ComputerのタスクでSnowflakeデータを参照できます。データベース、スキーマ、テーブルに言及すると、Perplexityはマルチステップワークフローの一部としてそれらをクエリします — すべてセキュアなクラウドサンドボックス内で非同期に実行されます。以下のようなクエリを試してみてください：
「Q4売上テーブルの収益トレンドを要約し、主要指標を強調してください」
「過去30日間に更新されたすべての顧客レコードを検索してください」
「アナリティクススキーマに基づいてパフォーマンスの高い商品は何ですか？」
「今四半期のパイプラインデータを前四半期の数値と比較してください」
トラブルシューティング
組織でSnowflakeが有効になっていない
Enterprise組織のメンバーでコネクタを有効にできない場合は、管理者によって無効にされている可能性があります。組織管理者に確認するか、Perplexityサポートにお問い合わせください。
接続と認証の問題
PerplexityのIPアドレスがSnowflakeネットワークポリシーの許可リストに登録されていることを確認してください。
ロールに必要なウェアハウス、データベース、スキーマへの
USAGE権限があることを確認してください。ポリシー変更後は、ユーザーにコネクタの再接続を依頼してください。
「無効な秘密鍵」エラー
公開鍵ではなく秘密鍵（snowflake_computer_key.p8）を貼り付けていることを確認してください。ファイルは-----BEGIN PRIVATE KEY-----で始まるはずです。
現在の認証ポリシーによる認証拒否
ACCOUNTADMINとしてSHOW AUTHENTICATION POLICIESを実行し、PERPLEXITY_USERがKEYPAIRを含むポリシーの対象となっていることを確認してください。必要な場合：
CREATE AUTHENTICATION POLICY PERPLEXITY_AUTH_POLICY
AUTHENTICATION_METHODS = (‘KEYPAIR’)
CLIENT_TYPES = (‘DRIVERS’);
ALTER USER PERPLEXITY_USER SET AUTHENTICATION POLICY PERPLEXITY_AUTH_POLICY;
OAuth：接続後にユーザーが見えるデータが限られる
OAuthセッションはユーザーのDEFAULT_ROLEをプライマリロールとして使用し、セカンダリロールはOAUTH_USE_SECONDARY_ROLES = IMPLICITにより有効化されます。ユーザーが期待するアクセスを得られていない場合：
セキュリティ統合に
OAUTH_USE_SECONDARY_ROLES = IMPLICITが設定されていることを確認してください。DESC USER <username>を実行してDEFAULT_ROLEとDEFAULT_SECONDARY_ROLESを確認してください — セッションはそこで設定された内容を正確に使用します。ユーザーにユーザーごとのロール設定がなく、付与されたすべてにアクセスさせたい場合は、
DEFAULT_ROLE = PUBLICとDEFAULT_SECONDARY_ROLES = (‘ALL’)を設定してください。これらの設定を変更した後は、新しいトークンを発行するためにコネクタを切断して再接続するよう依頼してください。
ACCESS_HISTORY ビューがエラーを返す
SnowflakeアカウントがEnterprise Edition以上であることを確認してください。
ACCOUNT_USAGE ビューの権限不足
GRANT IMPORTED PRIVILEGESがACCOUNTADMINとして実行され、PERPLEXITY_ROLEがユーザーに付与されていることを確認してください。
キーペア認証の失敗
DESC USER PERPLEXITY_USERを再実行して、公開鍵のフィンガープリントが登録されていることを確認してください。
これらの設定を更新しても問題が解決しない場合は、Perplexityサポートにお問い合わせください。