Snowflakeコネクターについて
Snowflakeコネクターを使用すると、PerplexityからSnowflakeデータウェアハウスに保存されたデータを直接クエリできます。SnowflakeとPerplexityの生産性機能を統合し、手動クエリや画面切り替えなしにSnowflakeデータベース、メール、カレンダー、その他の接続済みアプリ、ウェブ全体の関連情報を即座に検索・組み合わせることができます。
Snowflakeコネクターは Perplexity Pro、Perplexity Max、Enterprise Pro、Enterprise Max ユーザーが利用できます。
Snowflake コネクターの機能
有効化後、Snowflakeコネクターは認可されたSnowflakeデータベース、スキーマ、テーブル全体を検索し、そのデータに基づいた回答を提供します。コネクターはSnowflakeアカウントに安全に接続し、ウェアハウスの情報と他のソースを組み合わせた包括的な検索を実現します。
コネクターを使用すると、SQLクエリを手動で記述したりSnowflakeコンソールに切り替えたりすることなく、テーブル、ビュー、スキーマ全体の情報を素早く検索できます。Snowflakeデータが更新されると、以降のクエリで変更が自動的に反映されます。
サポートされているデータオブジェクト
Snowflakeコネクターは以下をサポートしています：
テーブル
ビューとマテリアライズドビュー
スキーマ
データベース
構造化データ（CSV、JSON、Parquetバックのテーブル）
現時点では、非構造化データ（Snowflakeステージに保存された画像、音声、動画）はサポートされていません。
認証方法
Snowflake認証には2つの独立した次元があります：クエリを実行するユーザー（アイデンティティ）と、そのアイデンティティの証明方法（認証情報）です。ほとんどの組み合わせがSnowflakeで有効です。詳細はSnowflakeパートナー認証ドキュメントをご覧ください。
アイデンティティ（Snowflakeユーザータイプ）：
TYPE = PERSON— Perplexityユーザーごとに個別のSnowflakeユーザーアカウントTYPE = SERVICE— すべてのPerplexityユーザーが共通で使用する単一のサービスアカウント（例：PERPLEXITY_USER）
認証情報（ユーザーの認証方法）：
OAuth（ブラウザベースのフロー）
キーペア（RSA秘密鍵）
プログラマティックアクセストークン（PAT）
アイデンティティ × 認証情報マトリクス
| OAuth | キーペア | PAT |
| ✅ 推奨 | ✅ Snowflakeでサポート | ✅ Snowflakeでサポート |
| ❌ 非対応（OAuthは対話型ログインが必要） | ✅ サービスアカウントに推奨 | ✅ サポート（単一ロールのみ） |
⚠️ 現在のPerplexityコネクターUIで公開されている内容：
Perplexityはディレクトリに2つの独立したコネクターを提供しています：
"Snowflake (User OAuth)" —
PERSON+ OAuth（ユーザーごとの認証、推奨）
"Snowflake" —
SERVICE+ キーペア、またはSERVICE+ PAT（共有認証、フォールバック）
ユーザーごとのキーペアまたはPAT（PERSON + キーペア / PERSON + PAT）はSnowflakeで技術的にサポートされていますが、現在Perplexityのコネクター UIには公開されていません。これを求めているユーザーがいる場合（例：OAuthなしのユーザーレベルキーペア）は、コネクターチームにお問い合わせください。Snowflakeによってブロックされているわけではありません。
推奨パス：ユーザー OAuth
ユーザー OAuth（PERSON + OAuth）を推奨します。各Perplexityユーザーが自分のSnowflake認証情報で認証し、クエリはそのユーザー本来のSnowflake権限で実行されます。共有サービスアカウントは不要で、PerplexityでRBACロジックを再作成する必要もなく、Snowflake上でユーザーごとの明確な監査証跡が得られます。Snowflakeの方向性とも一致しており、Snowflakeによると「キーペアとPATはOAuthを使用できないサービスアカウントのフォールバックオプションです」とされ、SnowflakeのマネージドMCPサーバーは現在OAuth 2.0のみをサポートしています。
注意：OAuthでは、アクセストークンは認証時に特定のSnowflakeロール（具体的にはユーザーのDEFAULT_ROLE）に暗号的に紐付けられます。セッション内でユーザーが付与されたすべてのロールにアクセスできるようにするため、セカンダリロールを正しく設定してください（下記のユーザー OAuth ロール設定を参照）。
フォールバックパス：サービスアカウント
サービスアカウント（SERVICE + キーペア、または SERVICE + PAT）が適切な場合：
エンドユーザーが個別のSnowflakeアカウントを持っていない場合（例：Perplexity経由でクエリを実行するが、Snowflakeへの直接アクセスを持たないビジネスユーザー）
簡便性や監査上の理由から、すべてのPerplexityクエリを単一の共有アイデンティティで実行させたい場合
ユーザーごとのアイデンティティが不要な社内/テスト環境を設定する場合
サービスアカウントを使用する場合はPATよりもキーペアを推奨します。PATは有効期限が短く、作成時に単一ロールに紐付けられます（下記のサービスアカウントロール設定を参照）。
ロール設定
ユーザー OAuth ロール設定（推奨）
SnowflakeのOAuth認証では、アクセストークンは単一のプライマリロール（ユーザーのDEFAULT_ROLE）に紐付けられ、アクティブなセッション内でのロール切り替えはサポートされていません。Perplexityはロール選択UIを提供しません。Snowflakeでユーザーが設定したDEFAULT_ROLEとDEFAULT_SECONDARY_ROLESがOAuthセッションで使用されます。
セキュリティ統合レベルでの推奨設定：
OAUTH_USE_SECONDARY_ROLES = IMPLICIT
SnowflakeではこのパラメーターのデフォルトはNONEです。つまりOAuthセッションはユーザーのプライマリロールのみがアクティブな状態で開始され、付与されたセカンダリロールは有効化されません。IMPLICITに設定すると、OAuthセッションの開始時に各ユーザーのDEFAULT_SECONDARY_ROLESも自動的に有効化されます。どちらの設定でも統合は機能しますが、IMPLICITなしではユーザーは他のロールが付与されているかどうかに関わらずDEFAULT_ROLEからアクセスできるデータのみが見えます。
2つのケース
ケースA — ユーザーのロールデフォルトが既に設定されている場合。ユーザーのDEFAULT_ROLEとDEFAULT_SECONDARY_ROLESが望む形で設定済みの場合（ユーザーごとのRBAC、カスタムデフォルトロール、特定のセカンダリロールリストなど）、追加の操作は不要です。セキュリティ統合のIMPLICIT設定で十分です。各ユーザーの既存のデフォルトがPerplexityセッションで使用されます。
ケースB — ユーザーのロールデフォルトが未設定の場合。ユーザーごとのロールデフォルトを設定していない場合、全ユーザーのDEFAULT_ROLEをPUBLICに設定し、DEFAULT_SECONDARY_ROLESをALLに設定することを推奨します。統合でのOAUTH_USE_SECONDARY_ROLES = IMPLICITと組み合わせることで、各セッションにそのユーザーに付与されたすべてのロールの和集合が与えられます：
ALTER USER <username> SET
DEFAULT_ROLE = PUBLIC,
DEFAULT_SECONDARY_ROLES = ('ALL');
注意：Snowflakeの2024年8月の動作変更以降、DEFAULT_SECONDARY_ROLES = ('ALL')は新規作成ユーザーのアカウントレベルのデフォルトになっています。多くの組織では既にこの設定がされています。変更前にDESC USER <username>を実行して確認してください。
サービスアカウントロール設定
OAuthとは異なり、サービスアカウントはコネクター用に作成された特定のロール（通常はPERPLEXITY_ROLE）で実行される単一の専用ユーザーです。OAuthで使用するDEFAULT_ROLE = PUBLIC + DEFAULT_SECONDARY_ROLES = ('ALL')のパターンはここでは適用されません。代わりに、サービスユーザーのDEFAULT_ROLEを専用のPERPLEXITY_ROLEに設定し、そのロールにPerplexityが必要とする権限のみを付与してください。
サービスアカウントユーザーを作成する際に以下を適用してください（PATより推奨するキーペア認証を使用）：
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';
これはSnowflakeのサービスアカウントベストプラクティスに従っています。サービスユーザーは付与されたすべてのロールの和集合を継承するのではなく、権限を絞った単一のロールにスコープされます。
PATを使用したサービスアカウント
キーペアの代わりにプログラマティックアクセストークン（PAT）を使用する場合、Snowflakeはトークン作成時にROLE_RESTRICTIONの設定を要求します。トークンはROLE_RESTRICTIONで指定した単一ロールに固定的に紐付けられ、トークンの有効期間中に変更することはできません。
同じ専用のPERPLEXITY_ROLEを使用してください：
ALTER USER PERPLEXITY_USER ADD PROGRAMMATIC ACCESS TOKEN PERPLEXITY_PAT
ROLE_RESTRICTION = 'PERPLEXITY_ROLE'
DAYS_TO_EXPIRY = 90;
この理由に加え、有効期限が短いことから、サービスアカウント設定ではPATよりキーペアを推奨します。
（オプション）OAuth経由で使用できるロールの制限
PerplexityのOAuth統合経由でユーザーが認証できるSnowflakeロールを制限したい場合、セキュリティ統合レベルで以下のいずれかを使用してスコープできます：
PRE_AUTHORIZED_ROLES_LIST— このOAuth統合で使用できるロールの明示的な許可リストBLOCKED_ROLES_LIST— このOAuth統合で使用できないロールの拒否リスト
例：
ALTER SECURITY INTEGRATION PERPLEXITY_OAUTH SET PRE_AUTHORIZED_ROLES_LIST = ('ANALYST_ROLE', 'READ_ONLY_ROLE');機密性の高いロール（例：ACCOUNTADMIN）をOAuthフローから完全に除外したい場合に使用してください。
SnowflakeでのPerplexityの操作範囲の制御
SnowflakeコネクターはMergeのSnowflakeコネクターを元にした汎用のexecute_sqlツールを含むツールサーフェス経由でSQLを実行します。execute_sqlはDDLやDMLを含む任意のSQLを受け付けるため、Perplexityの操作を読み取り専用に制限する唯一の信頼できる方法はSnowflake RBACレイヤーで行うことであり、Perplexity UIではありません。
推奨パターン：Snowflakeロールレベルで読み取り専用を強制する。
Perplexityにクエリさせたいデータベース、スキーマ、テーブルに対してUSAGEとSELECTのみを付与した専用の読み取り専用ロール（例：PERPLEXITY_READ_ONLY）をプロビジョニングし、INSERT、UPDATE、DELETE、CREATE、DROP、OWNERSHIP、ウェアハウスのMODIFYは明示的に付与しないでください。その後、ユーザーがそのロールで認証するようにします：
ユーザーの
DEFAULT_ROLEとして設定する、またはOAuth統合を
PRE_AUTHORIZED_ROLES_LIST = ('PERPLEXITY_READ_ONLY', …)でスコープし、BLOCKED_ROLES_LISTで書き込み可能なロールを除外します（上記の（オプション）OAuth経由で使用できるロールの制限を参照）。
このようにRBACを設定することで、どのツールが呼び出されても、Perplexityによる書き込み試行はSnowflakeによって拒否されます。
注意：PerplexityはSnowflakeコネクター設定のツール権限パネルで利用可能なツールを一覧表示します。現在、このパネルは読み取り/書き込み/編集の強制を信頼できる形で提供していません。Perplexityの操作を制御する正しい方法はSnowflakeロールレベルでのアクセス管理です（上記参照）。
プライバシーとデータセキュリティ
Perplexityに接続された場合、Snowflakeコネクターはお客様に代わって以下の操作を実行できます：
Snowflakeデータに対してSQLクエリを実行する
Cortex SearchとAnalystをクエリする
カスタムUDFとストアドプロシージャを実行する
Snowflakeでアクセスを取り消したりロールを削除したりすると、そのデータはPerplexityから即座にアクセスできなくなります。PerplexityでSnowflakeアカウントを切断した場合、キャッシュされたデータを保持するか削除するかを選択できます。
エンタープライズグレードのセキュリティと制御
エンタープライズ組織向けに、PerplexityはSOC 2 Type II認証、エンドツーエンド暗号化、厳格なデータプライバシー対策、きめ細かなユーザーアクセス制御を提供しています。SnowflakeデータはAIのトレーニングに使用されることはありません。
PerplexityとSnowflakeの接続は個人レベルで行われます。組織内の他のユーザーはあなたのSnowflakeデータをクエリできません。ただし、共有スペースにデータを同期した場合、そのスペースにアクセスできる全員が検索できるようになります。
組織管理者は組織設定の権限画面から、すべてのユーザーに対してSnowflakeコネクターを有効または無効にできます。読み取り/書き込みの強制はSnowflakeロールレベルで処理されます（上記のSnowflakeでのPerplexityの操作範囲の制御を参照）。
有効化の手順
注意：ほとんどの組織にはユーザー OAuthを推奨します。ユーザーごとのアイデンティティを提供し、Snowflake自体の方向性とも一致しています。サービスアカウント（キーペア）は個人のSnowflakeアカウントが利用できない場合のフォールバックとして提供されます。ユーザー OAuthを使用する場合は、管理者専用のOAuthセットアップについてステップ7：SnowflakeとPerplexityの接続を参照してください。以下のSQLセットアップステップ1〜6はサービスアカウント/キーペア設定にのみ適用されます。
前提条件
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 = 'XLARGE'
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ロールを使用してSnowflakeワークシートで以下を実行します。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が必要とする権限のみを持つ専用ロールにスコープします。
ステップ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つのビューを使用します：
ビュー | 目的 |
QUERY_HISTORY | クエリメタデータ、パフォーマンス、使用パターン |
ACCESS_HISTORY | オブジェクトレベルの監査証跡（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用：まず管理者がセットアップ（Snowflake (User OAuth) コネクター）
組織がOAuth（個人ユーザー）認証を使用している場合、個々のユーザーが認証できるようになる前に、組織管理者が組織向けにSnowflake (User OAuth)コネクターを一度設定する必要があります。
組織設定 → コネクター → Snowflake (User OAuth)で、管理者は3ステップの設定パネルを確認できます：
ステップ1：OAuthアプリを管理 — OAuthアプリを管理をクリックして、PerplexityをSnowflakeアカウントに対するOAuthクライアントとして登録します。カスタムSnowflake
SECURITY INTEGRATIONを作成し、生成されたクライアントIDとクライアントシークレットをPerplexityに貼り付ける手順を案内します。ステップ2：Snowflake (User OAuth) で認証 — 管理者が一度認証して、統合がエンドツーエンドで機能することを確認します。
ステップ3：データマップを生成する（オプション） — 組織のデータマップをオプションで生成します（下記の データマップを理解する) and add Supplementary context to improve query accuracy.
ステップ1でOAuthアプリを管理をクリックする際、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コネクターではキーペアまたはPAT、Snowflake (User OAuth)コネクターではOAuthです。
設定のコネクターに移動し、SnowflakeまたはSnowflake (User OAuth)コネクターを見つけます。
有効化 → コネクターを追加をクリックします。
コネクターに設定された認証方法を使用して認証します：
キーペア認証（Snowflakeコネクター）
Snowflakeアカウント識別子、ユーザー名、秘密鍵（snowflake_computer_key.p8）を入力します。
プログラマティックアクセストークン（PAT）（Snowflakeコネクター）
SnowflakeアカウントのSnowflake識別子とガバナンス＆セキュリティからのPATを入力します。
OAuth（個人ユーザー）（Snowflake (User OAuth) コネクター）
認証のためにSnowflakeにリダイレクトされます。Perplexityはロール選択UIを提供しません。OAuthセッションはSnowflakeのDEFAULT_ROLEをプライマリロールとして使用し、DEFAULT_SECONDARY_ROLESはOAUTH_USE_SECONDARY_ROLES = IMPLICITにより自動的に有効化されます。管理者によってロールのデフォルトが設定済みの場合、追加の操作は不要です。
セッションでアクセスできるべきデータが表示されない場合は、Snowflake管理者にDEFAULT_ROLEとDEFAULT_SECONDARY_ROLESを確認するよう依頼してください（上記のユーザー OAuth ロール設定を参照）。
許可をクリックしてセットアップを完了します。
接続済みデータの活用
接続後、ComputerのタスクでSnowflakeデータを参照できます。データベース、スキーマ、テーブルに言及すると、Perplexityはセキュアなクラウドサンドボックス内で非同期にマルチステップワークフローの一部としてクエリを実行します。
試してみる
接続後、以下のようなクエリを試してみてください：
「Q4売上テーブルの収益トレンドを要約し、主要指標を強調してください」
「過去30日間に更新されたすべての顧客レコードを検索してください」
「アナリティクススキーマに基づいてパフォーマンスの高い商品は何ですか？」
「今四半期のパイプラインデータを前四半期の数値と比較してください」
トラブルシューティング
組織でSnowflakeが有効になっていない
エンタープライズ組織のメンバーでSnowflakeコネクターを有効にできない場合は、管理者によって無効にされている可能性があります。組織管理者に確認するか、Perplexityサポートにお問い合わせください。
接続と認証の問題
PerplexityのIPアドレスがSnowflakeネットワークポリシーの許可リストに登録されていることを確認する
ロールに必要なウェアハウス、データベース、スキーマへの
USAGE権限があることを確認するポリシー変更後はユーザーにSnowflakeコネクターの再接続を依頼する
「無効な秘密鍵」エラー
秘密鍵（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セッションはユーザーのSnowflakeの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')を設定します。これらの設定変更後は、新しいトークンを発行するためにSnowflakeコネクターを切断して再接続するよう依頼します。
ACCESS_HISTORY ビューがエラーを返す
SnowflakeアカウントがEnterprise Edition以上であることを確認してください。
ACCOUNT_USAGE ビューの権限不足
GRANT IMPORTED PRIVILEGESがACCOUNTADMINとして実行され、PERPLEXITY_ROLEがユーザーに付与されていることを確認してください。
キーペア認証の失敗
DESC USER PERPLEXITY_USERを再実行して公開鍵のフィンガープリントが入力されていることを確認してください。
これらの設定を更新後も問題が解決しない場合は、Perplexityサポートにお問い合わせください。