SSOの概要
当社のSSOプラットフォーム(WorkOS)は、組織がユーザーアクセスを効果的に管理するのに役立ちます。 組織は、IDプロバイダー(IdP)を介してドメイン制御のログインを実施することで、Perplexityにアクセスできるユーザーを管理します。
ユーザープロビジョニングの仕組み
デフォルト: 組織の管理者は、Perplexity でユーザーを招待する必要があります。
ジャストインタイムプロビジョニング: ユーザーは、IdPに追加されたときではなく、SSO/IdPを介して最初にログインしたときにPerplexityで作成されます。 JITプロビジョニングを有効にする手順は、 こちらでご確認ください。
オプションのエンジニアリング機能:
組織のメールドメインを持つユーザーの自動ログインを有効にします。
所有しているメールドメインのユーザーをすべて、Perplexity アカウントに自動的に取り込みます。
SCIM(System for Cross-domain Identity Management): ユーザーのプロビジョニングとプロビジョニング解除を自動化します。 Perplexityは、50人以上のユーザーを持つ組織、またはEnterprise Maxユーザーが1人以上いる場合にSCIMをサポートします。
ユーザーのプロビジョニング解除の仕組み
IdPから削除されたユーザーは、Perplexityから 自動的に削除されません 。
SSOが適用されている場合、プロビジョニング解除されたユーザーはログインできませんが、管理者が削除するまでPerplexityに表示されます。
推奨事項: 管理者は、記録を正確に保つために、プロビジョニング解除されたユーザーを定期的に確認し、手動で削除する必要があります。
トラブルシューティングの主な手順
一般的なトラブルシューティング
組織でSSOに問題が発生している場合は、まず SSOを必須にする が有効になっていることを確認してください。 このオプションをオンにすると、組織に対してIdPを介したドメイン制御のログインが強制されます。
これを行うには、組織設定の Identity 画面に移動し、Require SSO をオンにします。
組織にSSOが必要であるにもかかわらず、組織のSSOフローが表示されない場合は、使用しているドメインまたはサブドメインが認証されていることを確認してください(以下を参照)。
キャッシュの問題が原因の場合は、ブラウザをハードリフレッシュ(WindowsではCtrl+F5、Macではcommand+shift+Rを押す)するよう依頼することもできます。
ドメイン認証に関する問題
組織がSSOログインに使用するすべてのドメインとサブドメインは、個別に認証する必要があります。
ドメインの認証が「保留中」または「失敗」と表示されている場合は、DNS TXTレコードがドメインのDNS設定にまだ追加されていない可能性があります。
ドメインを確認するには:
組織設定の Identity 画面に移動します。
ドメイン セクションの横にある 「追加」 をクリックします。
組織のドメインを入力します(例: yourdomain.com)。
提供されたDNS TXTレコードをコピーします。
このレコードを、両側に二重引用符を付けて完全な
"verification_token=string"を含むドメインの DNS 構成に追加します。 TTLを60秒に設定します。少なくとも1分間待ってから、
nslookup -q=text yourdomain.comを使用して、新しいDNS TXTレコードがインターネットに反映されていることを確認します。DNS TEXT レコードが追加されたら、「Verify」をクリックします。
組織が使用するすべてのドメインで繰り返します。
ドメインが正常に検証されたら、TTL設定を12時間または24時間(43200秒または86400秒)に増やすことができます。
ジャストインタイムプロビジョニング
自動ログインまたは自動キャプチャ機能を有効にするには、組織のジャストインタイムプロビジョニングを有効にする必要があります。
これは、組織設定の Identity 画面で、「Just-in-time account provisioning」 のトグルを「Enabled」に切り替えることで行えます:
組織でJITが有効になっているにもかかわらず、特定のユーザーの ジャストインタイムプロビジョニング に問題が発生している場合は、新しいユーザーでログインをテストしてみてください。
新しいユーザーでは動作するのに特定のユーザーでは動作しない場合、進行中のユーザー オンボーディングの問題は、組織側の SSO やプロビジョニングの設定ミスが原因ではない可能性が高いです。 代わりに、問題は個々のユーザーの割り当て、権限、IdPのグループメンバーシップ、またはそれらのアカウントに固有の問題に関連している可能性があります。
それでもうまくいかない場合は、IdPとPerplexity間のSSO/JIT設定に問題がある可能性があります。 一般的な原因には、属性の設定ミス、アクセス許可の欠如、SAML/OIDCパラメータの誤りなどがあります。
プロビジョニング解除の問題:
組織でSCIMが有効になっていない場合、ユーザーがIDプロバイダー(IdP)から削除されると、SSOが適用され、IdPがログインを拒否した場合、そのユーザーはPerplexityにログインできなくなります。 ただし、ユーザーのアカウントとデータは、管理者が手動で削除または除外するまで、Perplexity システムに残ります。 標準のSSOは、ログイン時の認証のみを制御し、ユーザーのライフサイクル管理や削除は制御しません。
SCIMは、自動化されたライフサイクル管理を追加します。 ユーザーがIdPからデプロビジョニングされると、SCIMはPerplexityにリクエストを送信して、ユーザーアカウントを自動的に無効化または削除します。 つまり、SCIMを使用している組織は、ユーザーの作成と削除の両方を自動化できるため、手動でのクリーンアップ作業を最小限に抑え、セキュリティ体制を向上させることができます。
SCIM は、50シート以上、または少なくとも1つの Enterprise Max シートをお持ちの組織でご利用いただけます。
一般的なエラーメッセージと修正
エラーメッセージ | 意味 | 解決方法 |
AADSTS50105 (Microsoft Entra ID) | ユーザーは、権限のあるグループの直接のメンバーではないか、直接アクセス権がありません。 | ITまたはEnterprise Proの管理者に連絡して、直接追加するか、アクセス権のあるグループに追加してもらいます。 同期後に再度ログインしてみてください。 |
ユーザーはこのアプリケーションに割り当てられていません (Okta) | アカウントがOktaのPerplexityアプリケーションに割り当てられていません。 | ITまたはEnterprise Pro管理者に、OktaのPerplexity Enterpriseアプリにアカウントを割り当てるよう依頼してください。 |
エラー408:App_not_enabled_for_user (Google SSO) | Google管理者コンソールで、アカウントまたはグループに対してアプリへのアクセスが有効になっていません。 | 管理者は、Google Workspace管理コンソールの アプリ > ウェブおよびモバイルアプリで、あなたまたはあなたのグループのユーザーアクセスを有効にする必要があります。 その後、再度ログインしてください。 |
ドメインの移行
組織が新しいドメインに移行する際、Perplexityでユーザーアカウントまたはドメイン設定が更新されていない場合、シングルサインオン(SSO)が機能しなくなる可能性があります。
ドメイン移行中のSSOの失敗を防ぐためのベストプラクティスは、IDプロバイダーまたはユーザーのメールアドレスに変更を加える前に、 Perplexity内で新しいドメインを積極的に追加して検証すること です。
また、IDプロバイダーの構成を更新して新しいドメインを含め、それに応じてグループまたはユーザーの割り当てを調整することも重要です。これにより、ユーザーは切り替え後に必要なSSO権限を保持できます。
新しいドメインを確認する前にドメインを移行し、管理者権限を持つ以前のメールにまだアクセスできる場合は、そのメールでログインしてください。 これにより、新しいドメインを確認できます。 ただし、古いメールアドレスにアクセスできなくなった場合は、お問い合わせください。SSOを一時的に無効にして、新しいドメインを確認できるようにします。
さらにサポートが必要ですか?
その他の問題がある場合、またはこれらのトラブルシューティング手順で問題が解決しない場合は、 お問い合わせください 。サポートエンジニアが喜んでお手伝いします。


