AWSが中継基盤「Amazon Bedrock AgentCore Gateway」のMCP対応を拡張し、利用者本人に代わってトークンを取得する三者間認証（3LO）を正式提供にした。ツール・プロンプト・リソースの3要素のサポートとサーバーの実行時検出も加わった。
AWSは中継基盤Amazon Bedrock AgentCore GatewayのMCP（AIエージェントが外部ツールを呼び出す標準接続規格）対応を拡張した。最大の変更は、利用者本人に代わってトークンを取得する三者間認証3LOのMCPサーバー向け対応が正式提供に達した点である。
ツール・プロンプト・リソースというMCPの3要素すべてを正式サポートし、単一窓口に集約する。ツール探索には、情報を事前キャッシュするデフォルト方式と、呼び出し時に利用者本人の権限でサーバーへ問い合わせる動的方式の2系統がある。実行途中で追加入力を求める仕組み（elicitation）やストリーミング、セッション管理にも対応した。
安全面では、リソースのURIは下流サーバー由来で検証されないため、信頼できないサーバーからのURIは自動取得せず利用側で検証する必要があると明記された。複数MCPサーバーを束ねる企業は、認証情報管理・利用ログ・安全な接続の重複作業を減らせる一方、検証の責任分界を踏まえた運用設計が前提になる。
この変化で何が要点か。図解と出典つきで一目で。
構造化された事実を最初に。誰が何をいつどこでなぜどのように。
企業がAIエージェント用のツール接続規格（MCP）を本番運用する際、各部門が立てたサーバーごとに認証情報の管理、利用ログ、社内ネットワークへの安全な接続をそれぞれ作り込む必要があった。法務の契約レビュー用、財務のデータ取得用、運用の障害対応用といったサーバーが、同じ基盤上の手間を重複して抱えていた。AgentCore Gatewayは、これらの間に立つ単一の入口として認証情報の集中管理・監視・安全な接続をまとめる役割を担う。AWSはこれまでにも本基盤の発表やプライベート接続設定、認可コードフロー連携などを段階的に公開してきた。
AIエージェントが社内システムを動かす実運用では、誰がどのツールを使えるかという権限制御と、外部サービスへ利用者本人の同意付きでアクセスする認証が最大の障壁になる。今回の拡張は、利用者ごとの委任認証の正式提供と、サーバー側の権限を保ったまま実行時にツールを動的検出する仕組みを加え、その障壁を中央集約で解く点が重要である。多数のMCPサーバーを単一の窓口に束ねられるため、セキュリティ審査や運用統制の重複を減らせる。
AWSは中継基盤「Amazon Bedrock AgentCore Gateway」のMCP（AIエージェントが外部ツールを呼び出すための標準接続規格、Model Context Protocol）対応を拡張し、利用者本人に代わってトークンを取得する三者間認証（3LO）のMCPサーバー向け対応を正式提供にした。
企業がMCPサーバーを本番に置くと、サーバーをまたいだ細かい権限制御、どのチームがどのツールを使うかの可視化、データ持ち出しへの安全保証、そして認証情報の集中管理が同時に求められる。公式ブログはこの基盤の役割をこう位置づける。
Amazon Bedrock AgentCore Gateway sits between MCP servers and the clients that consume them, centralizing credential management, observability, and secure access.
つまりGatewayはMCPサーバーと、それを使うクライアントの間に立ち、認証情報の管理・監視・安全な接続を一手に引き受ける中継層である。誰がどのツールを使えるかという権限制御と、外部サービスへ本人同意付きでアクセスする認証——この2つが本番運用の最大の壁だった。委任認証の正式提供は、その壁を中央集約で外す動きだ。
今回の拡張で加わった要素は具体的だ。MCPの3要素であるツール・プロンプト・リソースをすべて正式サポートし、単一の窓口に束ねる。ツールの探し方には2つの方式が用意された。
さらに、実行の途中で追加入力を求める仕組み（elicitation＝処理を止めて利用者に必要な情報を尋ねる動き）や、応答を逐次返すストリーミング、複数のやり取りを束ねるセッション管理にも対応した。長く動くエージェント処理を中継基盤の上で扱えるようになる。
安全面では明確な線引きがある。リソースの場所を指すURI（識別子）は下流サーバー由来で、Gateway側は中身を検証しない。したがって信頼できないサーバーからのURIを自動取得してはならず、利用側で検証する責任が残る。データ持ち出しを防ぐ責任分界が文書として示された点は、運用設計でそのまま使える。
複数のMCPサーバーを抱える社内AI基盤チームが、最も恩恵を受ける。法務の契約レビュー用、財務のデータ取得用、運用の障害対応用——サーバーごとに別々に作り込んでいた認証情報管理・利用ログ・社内ネットワーク接続を、単一窓口に集約できるからだ。セキュリティ審査と運用統制の重複が減る。
委任認証を必要とする業務エージェントの開発者も得をする。OAuth 2.0の三者間トークン交換（3LO）が正式提供になり、本人同意付きの外部サービス接続を自前で組まずに済む。
一方、自前で認証ゲートウェイを内製してきたチームは、その維持理由を問われる。委任認証・動的検出・セッション管理が中継基盤側の標準機能になったためだ。
そして検証を省きたい運用は不利になる。下流サーバー由来のURIは検証されない前提なので、自動取得を放置すればデータ持ち出しのリスクを抱える。検証を組み込む設計が前提になる。
立場別、明日から動ける一手。
公式ブログとドキュメントで委任認証（3LO）の正式提供範囲とリソースのURI検証要件を確認する。
部門ごとに内製してきた認証・監視の運用コストと、Gateway集約方式の運用負荷の差を比較する。
デフォルトのツール事前キャッシュ方式と動的検出方式を1つの業務ツールで切り替え、応答の違いを試す。
企業のAIエージェント本番運用で課題だった「サーバーごとの認証情報管理・権限制御・監視の重複」を、単一窓口に集約できる点に関心が集まる構図である。
公式発表と各所の反応から編集部が要約した主な論点です。個別のX投稿そのものは下部のセクションに表示されます。
「サーバーごとの認証情報管理・権限制御・監視の重複」
利用者本人に代わる委任認証（3LO）の正式提供で、本人同意付きの外部サービス接続を自前で組まずに済む実装負荷の軽減が論点。一方で、リソースのURIが下流サーバー由来で検証されないため、信頼できないサーバーからのURIをどう扱うかという安全設計が、運用側の宿題として受け止められている。
※トレンド検出時刻付近の人気投稿を表示
3 Amazing MCP Servers Every Developer Needs in 2025
AWS Developers
