Amazon Bedrock AgentCoreに「Consent portal」が追加、AIエージェントの外部サービスOAuth同意管理をフルマネージド化

要点

• AWSは、Amazon Bedrock AgentCoreの機能「AgentCore Identity」において、エンドユーザーのOAuth同意管理を担う「Consent portal」の提供を開始した。

• AIエージェントがGitHubやSlackなどにアクセスする際の認可フローと、認可をユーザーに紐付けるセッションバインディング基盤をマネージドで提供する。

• ユーザーごとの認証トークンは専用のトークン保管庫に安全に保存され、CursorやVisual Studio Code、Claude CodeなどのMCPクライアントからシームレスに利用可能となる。

• 管理者は社内IdPやGatewayターゲットを設定してポータルURLを配布でき、一連の連携アクティビティはAWS CloudTrailを通じて監査できる。

• アマゾン ウェブ サービス（AWS）は2026年9月14日、生成AIアプリケーション開発向けサービス「Amazon Bedrock AgentCore」の認証機能「AgentCore Identity」において、エンドユーザー向けの同意画面とセッション管理を提供する「Consent portal」を発表した。

• 本機能により、開発者が認証・認可に関する専用インフラを独自にホストすることなく、AIエージェントがユーザーの代理として外部サービスへアクセスするためのOAuth同意フローを安全かつ容易に運用できるようになるという。

外部連携で不可欠だった「セッションバインディング」の自前構築課題

AIエージェントがユーザーに代わってGitHubやSlackなどの外部SaaSを操作する際、ユーザー自身が対象サービス上で認証を行い、アクセスの要求を明示的に承認する必要がある。さらに、アプリケーション側では承認によって得られたOAuth許可（grant）と、それを承認したユーザーの身元を安全に関連付ける処理が求められ、このプロセスは「セッションバインディング（Session Binding）」と呼ばれる。

従来、AgentCore Identityで3LO（3-legged OAuth：ユーザー、クライアント、プロバイダーの3者間で認可を行うOAuth 2.0の認可コードフロー）を利用する場合、セッションバインディングに必要な基盤をユーザー側で独自に構築・ホストしなければならなかった。具体的には、認可URLの提示をはじめ、公開HTTPSコールバックエンドポイントの設置、リダイレクトで戻ってきたユーザーの認証、ブラウザセッションの管理、さらには認可フローを完了させるためのAPI（CompleteResourceTokenAuth）の呼び出しといった一連の仕組みをすべて自前で実装する必要があり、導入の障壁となっていた。

マネージドWeb画面「Consent portal」の仕組みとトークン保管

今回追加された「Consent portal」は、Amazon Bedrock AgentCoreの接続制御機能「AgentCore Gateway」向けに提供されるマネージドなWebエクスペリエンス兼セッションバインディングエンドポイントである。

管理者はGatewayに対してポータルを作成し、生成されたURLをエンドユーザーに共有する。ユーザーがそのURLにアクセスすると、組織のIdP（Identity Provider：ユーザーの認証情報を一元管理する認証基盤）でサインインが行われる。ユーザーはポータル画面上でエージェントが利用可能な外部サービスの一覧を確認し、個別のサービスプロバイダーに対してアクセス同意を付与する仕組みとなっている。

ブラウザのリダイレクト処理やセッションバインディングはConsent portal側がすべて自動で処理し、取得されたOAuthトークンはAgentCore Identity内の専用トークン保管庫（token vault）にユーザー単位で安全に格納される。

IDEやMCPクライアントにおける認証体験の効率化

AWSによると、このConsent portalは、統合開発環境（IDE）やModel Context Protocol（MCP：AIモデルやエージェントが外部ツールと通信するためのオープン標準規格）クライアント経由でエージェントを利用するシナリオにおいて特に高い効果を発揮するという。

対応するクライアントの例として、Kiro、Claude Code、Cursor、Visual Studio Codeなどが挙げられている。開発者はツールを実行する前にあらかじめConsent portal上で外部サービスへの同意を完了させておくことができるため、その後のツール呼び出し時にはAgentCore Identity内に保存されたユーザー固有のトークンが自動的に適用される。これにより、コーディング中などにツールを呼び出すたびに認証プロンプトが表示される煩わしさが解消される。

開発アシスタントを想定した運用シナリオと監査対応

AWSは具体的な活用例として、社内開発者向けにAIコーディングアシスタントを提供する架空企業「Example Corp」のシナリオを提示している。このアシスタントには、リポジトリ一覧の取得やIssue作成を行う「GitHubターゲット」と、パブリックチャンネル一覧の取得やメッセージ投稿を行う「Slackターゲット」の2つが設定されている。

同シナリオにおける各ロールの役割は以下の通りに整理されている。

• 管理者（Administrator）: 社内IdP、GitHubおよびSlackのGatewayターゲット、IAM実行ロール、Consent portalを設定し、生成されたポータルURLを開発者に配布する。
• エンドユーザー（End user / 開発者）: 配布されたURLを開き、社内IdPでログインした上で、必要に応じてGitHubやSlackのアクセス連携を個別に行う。一度連携を済ませれば、IDE上で繰り返しプロンプトを求められることなく作業を継続できる。

なお、Consent portalを通じて行われた一連の接続や認可アクティビティは、AWSの運用監査ログサービスであるAWS CloudTrailを通じて確認・追跡できるよう設計されている。管理者やセキュリティ担当者は、AWS Management Console上で設定状況を管理するとともに、監査ログによる安全な運用監視を行えるとしている。