descope envoy とは？AIエージェントを本人と分けて認証・権限管理する仕組み

Descope Envoyは、消費者向けWebサイトやアプリが、顧客の代わりに訪れる個人AIエージェントを顧客本人とは別の主体として受け入れるための認証・認可機能です。エージェントごとにIDを持たせ、許可する操作をスコープで限定し、購入・寄付などの重要な操作は顧客の端末で承認させる構成を取れます。提供元はアイデンティティ基盤を提供するDescopeです。DescopeのEnvoy製品ページでは、既存の顧客認証を置き換えずに追加できる機能として案内されています。

先に結論をいうと、Envoyを検討すべきなのは「AIエージェントに顧客アカウント上の操作を許可したいが、パスワード・セッションを本人と共有させたくない」サービスです。たとえば、商品検索、予約候補の作成、注文作成といった操作をエージェントへ任せつつ、支払方法の変更、アカウント設定、返金確定などは別権限または人の承認へ残す、といった設計に向きます。

Descope Envoyとは：エージェントを「本人」ではなく「代理人」として扱う

従来のログイン画面は、人がキーボードやスマートフォンを操作することを前提に設計されています。AIエージェントが顧客のパスワードやワンタイムコードを使って本人としてログインすると、サービス側のログでは「顧客本人の操作」と「エージェントによる操作」を区別できません。

Envoyは、この状態をなりすまし（impersonation）ではなく委任（delegation）として記録することを狙います。トークンとログに顧客とエージェントを別々に残し、特定エージェントだけのアクセス取り消し、エージェント単位の権限制限、操作履歴の追跡を可能にします。Descopeは、Personal Agent Protocol（Poppy）への対応、DPoPでエージェントの鍵に結び付けるセッション、Rich Authorization Requests（RAR）による細かな権限要求、CIBAによる帯域外承認をEnvoyの構成要素として説明しています。Descopeの発表資料。

これは、AIエージェントそのものの性能を高める製品ではありません。AIがどの手順を判断して実行するかは、エージェントやアプリケーション側の責務です。AIエージェントの基本的な構造と、固定ワークフローと使い分ける基準は、AIエージェントとは？生成AI・チャットボット・RPAとの違いと導入判断・実践手順で整理しています。

何ができるのか：識別、最小権限、承認、監査を分けて設計する

1. エージェントを識別する

Envoyでは、Poppy対応エージェントがサイト上の/.well-known/poppy.jsonを参照し、認証先を見つけます。エージェントはClient ID Metadata Document（CIMD）で自身を識別し、サービス側は接続を許可するエージェントのドメインを設定できます。Descopeのドキュメントでは、最初からワイルドカードで全エージェントを受け入れることも可能ですが、実トラフィックを確認した後は許可対象を見直すよう案内しています。Descope Agent Loginドキュメント。

2. タスクに必要な権限だけを渡す

最小権限とは、「エージェントだから読み取り専用」と一律に決めることではありません。対象リソース、操作、対象顧客、期間を分けて定義し、業務に必要な権限だけを発行する考え方です。たとえば買い物支援なら、商品検索とカート作成は許可しても、保存済みカードの参照・変更、配送先の恒久変更、アカウント削除は別スコープにします。

Descopeのポリシーは、誰に、どのリソースまたは接続に、どのスコープを、どの認可方式で渡すかを定義します。最初に一致した有効ルールが適用され、初期状態のデフォルトルールは「Block All」と説明されています。これは許可ルールを明示して初めてアクセスを通す、最小権限の出発点になります。Descope Policiesドキュメント。

3. 重要操作だけを人へ戻す

エージェントの操作をすべて止めるか、すべて自動化するかの二択にする必要はありません。EnvoyはCIBAを使い、エージェントのセッション外にある顧客の端末へ承認を送る構成を案内しています。たとえば、エージェントが旅行候補を探し、航空会社・時刻・合計金額を示してから、顧客が翌朝に承認する、といった使い方です。何を承認対象にするかは、サービス提供者が決めます。Envoyの承認機能の説明。

4. 顧客をログアウトさせずに、エージェントだけ止める

顧客が特定エージェントの利用をやめた、エージェントに不審な挙動があった、権限設計を変更した、といったときに必要なのは、顧客アカウント全体の停止ではありません。Envoyのドキュメントでは、エージェントと顧客の組み合わせごとに作られるagentic identityを失効すると、そのエージェントのアクセストークン・リフレッシュトークンを無効化し、顧客自身のアカウントとセッションは維持できると説明されています。Agent Loginの失効手順に関する説明。

AIエージェント認証、MCP認証、通常のOAuthはどう違うか

Envoyの中心用途は、顧客向けサイトへ来るパーソナルAIエージェントの委任ログインです。社内のMCPサーバーへ従業員のエージェントを接続するケースと、目的や利用者は同じではありません。Descope自身も、顧客サイトのエージェント受け入れにはAgent Login（Envoy）を、MCPサーバーの保護には別のMCP Server向け機能を確認するよう案内しています。

API、MCP、A2Aは置き換え合う技術ではなく、接続する対象と責任範囲が異なります。ツール接続の全体像は、API・MCP・A2Aの違いとは？AIエージェントを接続する仕組みやポイントを分かりやすく解説も参照してください。

提供状況・料金・日本での利用可否

• 提供元：Descope
• 正式発表：2026年11月4日
• 提供状況：2026年11月6日時点の公式ドキュメントではEarly accessであり、利用にはEnterpriseライセンスと、DescopeのCSEまたはサポートによるプロジェクト有効化が必要です。公式ドキュメント。
• 料金：Envoy固有の公開定価は確認できません。Descopeの価格ページではEnterpriseは個別見積もりです。したがって、月額だけでなく、想定する同意数・トークン交換・サポート範囲を含めて確認してください。Descope Pricing。
• 日本での提供：公式公開資料では、日本限定の提供開始日、国内料金、日本リージョンでのEnvoy提供可否は確認できませんでした。日本から利用できないと断定する根拠もないため、導入候補の場合は契約窓口へ、利用地域、データ保存先、サポート言語、Early accessの対象条件を確認してください。

導入前に確認する4つの判断基準

以下はMojiによる実務上の提案です。Envoyの採用可否は、製品名ではなく、エージェントが実行する操作、入力品質、評価指標、許容できる失敗の影響で変わります。

1. 外部エージェントを受け入れる必然性があるか：顧客が持ち込むエージェントに、ログイン済みアカウントの操作を求めるか。公開情報の検索だけなら、委任ログインは不要な場合があります。
2. エージェントと本人をログで分ける必要があるか：不正調査、注文・予約の異議申し立て、サポート対応で、誰が操作したかを区別する必要があるかを確認します。
3. API単位で許可範囲を分けられるか：「エージェントを受け入れる」前に、検索、作成、更新、取消、支払、アカウント設定を別スコープに分解できるかを確認します。分解できないモノリシックなAPIでは、最小権限を実効的に強制できません。
4. 承認と取消が業務に間に合うか：金額、取消不能性、個人情報、外部送信の有無から、即時承認・後追い確認・自動実行の境界を決めます。失敗を戻せない操作ほど、承認と停止条件を強くします。

最初のPoCで試す手順

以下もMojiによる提案です。いきなり購入確定や権限変更を対象にせず、可逆性が高く、結果を人が確認できる操作から始めます。

1. 対象操作を1つに絞る：たとえば「架空の例：商品を検索し、カートへ追加する」までとします。決済、注文確定、住所・支払方法の更新は対象外にします。
2. リソースとスコープを棚卸しする：catalog.read、cart.write、order.confirmのように、読み取り・下書き・確定を分離します。名称は架空の例です。
3. 許可するエージェントを限定する：最初はPoppy対応を確認した特定エージェントのドメインだけを許可します。ワイルドカード受け入れは、運用・調査の体制が整ってから検討します。
4. 既存ログインとの接続方法を決める：Descopeを既に使う場合と、別のIDプロバイダーまたは自前ログインを使う場合で構成が異なります。後者では、既存ログインへのフェデレーションまたはExternal Authenticationと、API側のトークン受け入れを設計します。Poppy対応の構成パターン。
5. ドメイン上にディスカバリー情報を公開する：Envoyで生成されたpoppy.jsonとOAuth protected resource metadataを、自社ドメインの所定パスで配信します。Descopeはこれらをホストできず、自社ドメインで配信する必要があります。
6. API側で認可を強制する：UIの表示制御だけで終わらせず、APIでissuer、audience、有効期限、scopeを検証し、状態を持つAPIではPoppy Sessionヘッダーも検証します。Poppyの責任分界。
7. 承認・失効・監査の試験を行う：許可外スコープの要求、承認拒否、期限切れ、エージェント失効後の再試行、同じ顧客が別エージェントを使うケースを試験します。

PoCの合否チェックリスト

• 顧客ID、エージェントID、要求スコープ、承認結果、実行API、結果を1つの追跡単位で検索できる
• エージェントが許可外のAPIまたはスコープを要求したとき、API境界で拒否される
• 顧客が拒否した操作について、トークンや下流処理が発行・継続しない
• 対象エージェントの失効後、顧客自身の通常ログインは継続できる
• 支払、外部送信、個人情報の取得、取消不能な確定操作について、承認要否と責任者が定義されている
• 失敗時に止める条件、問い合わせ先、ログ保存期間、再開条件を決めている

AIエージェントへの委任では、「どこまで任せるか」と「誰が最終確認するか」を、モデルの性能評価とは別に設計する必要があります。委任レベル、承認、停止、監視を具体化する方法は、AIエージェントのガードレール設計｜暴走を防ぎながら自動化を進める権限・承認・停止・監視の実務ガイドで解説しています。

注意点：Poppyは1.0前のドラフトである

EnvoyはPoppyを実装の基盤にしていますが、Poppyはまだ1.0ではありません。Poppyの公式サイトは、2026年11月4日時点で0.3を公開済み、0.4をドラフト中とし、1.0以前は実装から学びながら仕様を更新するため、以前のドラフトとの互換性が壊れる可能性があると説明しています。DescopeのAgent Loginドキュメントは、生成するpoppy.jsonについて0.3を案内しています。したがって本番採用では、対応バージョン、更新時の互換性試験、Poppy対応エージェントの範囲をリリース管理へ含めるべきです。Personal Agent Protocol: Path to 1.0。

Envoyは、AIエージェントを安全にする万能機能ではありません。エージェントに渡す権限が広すぎる、APIがスコープを検証しない、重要操作が承認なしで実行できる、監査ログを調査できない、といった設計ではリスクを減らせません。導入の成否は「エージェントを通すか」ではなく、本人・エージェント・API・承認者の責任境界をどこまで実装できるかで判断してください。