検証済みユーザーアクセス ​

検証済みユーザーアクセスはランタイムユーザーコネクションを通じて機能し、スキルの実行時に各エンドユーザーが自分の認証情報で認証できるようにします。 これにより、スキルが個々のユーザーのIDと権限を使用してアクションを実行することが保証されます。

検証済みユーザーアクセスは、外部システムの認証IDを確立します。 アクセス制御の目的で、Genie会話内のユーザーのIDを確立するものではありません。 ユーザーIDはWorkato Identityと、Genieに設定されたエンドユーザーグループによって確立されます。

Workato Identityは、誰がGenieにアクセスできるかを決定します。 ユーザーは、会話を開始する前にGenieに割り当てられたエンドユーザーグループに所属している必要があります。

検証済みユーザーアクセスは、ユーザーがスキルを通じて実行できる操作を決定します。 これはターゲットシステムでのユーザーの権限によって決まり、スキルの実行時に適用されます。

この2層モデルにより、Genieへのアクセスを許可されているがSalesforceでの権限が制限されているユーザーは、Genieを使用できますが、Salesforceの権限を超えるアクションをSalesforceで実行することはできません。 Genieはフロントエンドであり、検証済みユーザーアクセスは既存のバックエンド権限を適用します。

親コネクション ​

親コネクションは、ランタイムユーザーコネクションが継承するテンプレートとして機能します。 ユーザーがスキルをトリガーすると、システムは親にリンクされた既存のランタイムコネクションを確認します。 ランタイムコネクションが見つからない場合、ユーザーは認証を求められます。

検証済みユーザーアクセスを使用してランタイムでコネクションを作成すると、ユーザーコネクションはWorkato Identityの親コネクション、Environment、およびユーザーIDにリンクされます。 エンドユーザーがGenieに話しかけてレシピをトリガーすると、Genieは親コネクションを使用するスキルを呼び出します。 Genieは次のいずれかの方法で応答します:

• コネクションプロンプト: ユーザーがすでにランタイムユーザーコネクションを作成している場合、チャットインターフェイスはユーザーにConnectをクリックするよう促します。 スキルはこの子コネクションを使用して実行されます。
• ランタイムコネクション作成プロンプト: ユーザーがまだランタイムユーザーコネクションを作成していない場合、チャットインターフェイスはユーザーにランタイムユーザーコネクションの作成を促します。 スキルはこの子コネクションを使用して実行されます。

チャットインターフェイスのConnectプロンプト

たとえば、検証済みユーザーアクセスが必要なSalesforceコネクションでスキルを実行すると、ユーザー用の子コネクションが作成されます。 この新しいコネクションは、スキルのデフォルトSalesforceコネクションを親としてリンクします。

Genieチャットでのキーワード管理 ​

SlackおよびMicrosoft Teamsのチャットインターフェイスで! list_connectionsキーワードをチャットに直接入力することで、ランタイムユーザーコネクションを管理できます。

! list_connectionsキーワードでは、次の操作を実行できます:

• 現在のランタイムコネクションのリストを表示する
• アクティブなコネクションを切断する
• 保存済みのコネクションを削除する

キーワード管理を使用するには、次の手順を実行します:

検証済みユーザーアクセスを使用する場合 ​

次の1つ以上に該当するスキルでは、検証済みユーザーアクセスを使用します:

• サービスアカウントではなくユーザーとしてアクションを実行する必要がある: 監査、コンプライアンス、または下流ワークフローの目的でcreated byIDが重要になる任意の書き込み操作。 たとえば、レコードの作成、レコードの更新、またはリクエストの送信です。

• 返されるデータをユーザーにスコープ設定する必要がある: ネイティブアプリケーションでユーザーに表示されるデータが、Genieでも表示されるデータであるべき任意の読み取り操作。 たとえば、休暇残高、割り当て済みチケット、または所有している商談です。

• ターゲットシステム独自の権限モデルを適用する必要がある: ユーザーがネイティブアプリケーションを通じて特定のJiraプロジェクト、特定のSalesforceレコード、または特定のHRシステム機能にアクセスできない場合、Genieを通じてもアクセスできないようにする必要があります。 検証済みユーザーアクセスにより、ターゲットシステムのアクセス制御が適用されます。

• ユースケースが規制対象業界にある、または監査証跡コンプライアンスを必要とする: ヘルスケア、金融サービス、政府機関など、規制によりアクションをサービスアカウントではなく特定の個人に帰属させる必要がある任意のコンテキスト。

スキルへの検証済みユーザーアクセスの追加 ​

レシピ構築プロセス中に、スキルに検証済みユーザーアクセスを追加できます。

スキルに検証済みユーザーアクセスを追加するには、次の手順を実行します:

詳細については、Agent Studioドキュメントのスキルの追加セクションを参照してください。

制限事項 ​

検証済みユーザーアクセスは、次の場合には利用できないか、利用できる場合でも適用すべきではありません:

• ターゲットシステムがOAuth 2.0をサポートしていない: 検証済みユーザーアクセスでは、ターゲットシステムがOAuth 2.0認証をサポートしている必要があります。 APIキー、基本認証、またはその他のOAuth以外のメカニズムのみをサポートするシステムでは、検証済みユーザーアクセスを使用できません。 これらのシステムでは、共有サービスアカウントが唯一の選択肢です。

• 一部のユーザーがターゲットシステムに直接アクセスできない: Genieとやり取りするユーザーの一部だけがターゲットシステムにアカウントを持っている場合、検証済みユーザーアクセスは使用できません。 この場合、ターゲットシステムのAPIが、そのユーザーに直接認証を要求せずにユーザーに代わってアクションを実行することをサポートしているか確認してください。 Jiraなど一部のAPIは、アクションの実行対象となったユーザーを記録する報告者フィールドをサポートしており、そのユーザーに認証を要求せずに、サービスアカウントが特定のユーザーに帰属するチケットを作成できます。

• スキルがAssign Task to Genieを通じて呼び出される: Assign Task to Genieアクションを使用してGenieを呼び出すレシピは、会話内にユーザーが存在しないヘッドレス呼び出しを使用します。 認証するユーザーがいない場合、検証済みユーザーアクセスは機能しません。 検証済みユーザーアクセスを使用し、Assign Task to Genieアクションで呼び出されるスキルはすべて失敗します。

• GenieがMCP serverとして公開されている: MCP serverとして公開されているGenieは、Assign Task to Genieアクションを通じた呼び出しを使用します。 MCPレイヤーでの認証は、誰がGenieを呼び出せるかを確立するものであり、スキル実行内での検証済みユーザーアクセスは許可しません。

トラブルシューティング ​

このセクションでは、検証済みユーザーアクセスを使用する際の一般的な問題と解決策について説明します。

• コネクションプロンプトが表示されない: ユーザーが検証済みユーザーアクセスを使用するスキルをトリガーしても、認証を求められません。 これは通常、スキルの検証済みユーザーアクセス切り替えは有効になっているものの、親コネクションが正しく設定されていないことを意味します。 親コネクションがOAuth 2.0認可コードグラント認証を使用していること、およびコネクションがワークスペースでアクティブであることを確認します。

• ユーザーの認証後にスキルが失敗する: ユーザーがOAuthフローを完了しても、スキルがエラーを返します。 これには、次のような一般的な原因があります:

  • ユーザーにターゲットシステムで必要な権限がありません。 これは正しい動作であり、検証済みユーザーアクセスが意図どおりに機能していることを意味します。
  • 子コネクションは正常に作成されましたが、レシピがユーザーコンテキストデータピルを正しく使用していません。 必要に応じて、レシピがStart workflowトリガーのユーザーコンテキスト出力を参照していることを確認します。

• ユーザーが毎回認証を求められる: 子コネクションは初回認証後に保持される必要があります。 ユーザーが繰り返しプロンプトを表示される場合、子コネクションの期限が切れているか、取り消されている可能性があります。 親コネクションに設定されているOAuthトークンの有効期間、およびターゲットシステムが一定期間非アクティブな状態の後にトークンを取り消しているかどうかを確認します。

• 検証済みユーザーアクセスがSlackでは機能するがWorkato GOでは機能しない、またはその逆: 各インターフェイスでOAuthリダイレクトフローの処理方法が異なるため、検証済みユーザーアクセスの動作はチャットインターフェイス間でわずかに異なる場合があります。 デプロイ先の各チャットインターフェイスで検証済みユーザーアクセスをテストしてください。 あるインターフェイスでの動作が別のインターフェイスで完全に再現されると想定しないでください。