AWSが、AIコーディング支援ツールと企業内ツール群（MCPサーバー）をつなぐ際に、利用者本人を確認してからアクセスを許可する仕組み（OAuth認可コードフロー）の構築手順を、Amazon Bedrock AgentCore Gatewayを入口として公開した。
AWSが、AIコーディング支援ツールと企業内ツール群（MCPサーバー）をつなぐ際に、利用者本人を確認してからアクセスを許可する手順を公開した。中継役のAmazon Bedrock AgentCore GatewayをOAuthの保護対象サーバーとして動かし、有効な本人トークンがなければツールへのアクセスを拒否する。
連携できるID基盤としてOkta・Microsoft Entra ID・Amazon Cognitoが示され、既存のシングルサインオン環境をそのままAIエージェント認証に流用できる。トークンのない要求にはHTTP 401を返し、クライアントであるKiro IDEが自動で認証手続きを開始する。推奨設定はアクセストークン1時間、更新トークン90日で、実装はID基盤・Gateway・MCPクライアントの3構成に分けて整理されている。
認証を新規に作らず手元の基盤を使える点が、AIツールの業務導入を進める情報システム部門にとっての実務上の判断材料になる。
この変化で何が要点か。図解と出典つきで一目で。
構造化された事実を最初に。誰が何をいつどこでなぜどのように。
近年、Kiro IDE のような自律型コーディング支援ツールが、外部のツールやサービスを呼び出して開発作業を代行するようになっている。これらの支援ツールと企業内ツール（MCP サーバー）の接続には、誰がアクセスしているかを確実に確認する認証の仕組みが必要となる。Amazon Bedrock AgentCore は、AI エージェントを本番環境で配備・運用するためのフルマネージドサービスで、その構成要素である AgentCore Gateway がツールとの通信を一元的に中継・保護する役割を担う。AWS は 2026 年 4 月にも MCP サーバーと Gateway の接続に関するブログを公開しており、本記事はその認証部分を具体化したものである。
AI エージェントを業務に導入する企業にとって、誰がどのツールを呼び出したかを本人確認できる仕組みは、セキュリティと統制の前提条件となる。Okta や Microsoft Entra ID、Amazon Cognito といった既存の社内 ID 基盤と連携できるため、自前の認証を作り直さずに済む点が実務上の判断材料になる。AI 支援ツールの利用拡大に伴い、こうした認証設計の標準化が現場で求められている。
AWSが公開したのは、AIコーディング支援ツールと企業内ツール群をつなぐ際に、利用者本人を確認してからアクセスを許す手順だ。中継役を担うのがAmazon Bedrock AgentCore Gatewayで、これをOAuthの保護対象サーバー（リソースサーバー＝有効なトークンを持つ要求だけ通す側）として動かす。
By the end of this guide, you will have a production-ready setup where each AI assistant request is authenticated with a valid user identity token issued from your organization's identity provider.
引用が示すのは「AI支援ツールからの各リクエストを、組織のID基盤が発行した本人トークンで検証する本番運用向けの構成」だ。AIエージェントが自律的にツールを呼ぶ時代に、その呼び出しが誰の権限で行われたかを確認できる仕組みは、業務導入の前提条件になる。
今回の手順の実務的な核は、認証を新規に作らない点にある。連携できるID基盤としてOkta・Microsoft Entra ID・Amazon Cognitoが挙げられており、多くの企業が既に持つシングルサインオン環境をそのままAIエージェント認証に流用できる。
動作はこうだ。トークンを持たない要求にはGatewayがHTTP 401（認証が必要という応答）を返す。すると支援ツール側のクライアント（Kiro IDE）が自動で認証手続きを開始し、ユーザーがログインして本人トークンを取得する。寿命の目安も具体的で、アクセストークンは有効期間1時間、更新トークンは90日が推奨設定として示された。実装手順は ID基盤・Gateway・MCPクライアント の3つの構成要素に分けて整理されている。
既にOktaやMicrosoft Entra IDを運用している国内企業の実装担当は、その基盤をAIエージェント認証に流用でき、認証を一から作り直す手間が消える。
AIコーディング支援の業務導入を進めたい情報システム部門も得をする。誰がどのツールを呼んだかを本人単位で確認でき、社内展開の統制条件をクリアしやすくなるからだ。
一方、独自の認証ゲートウェイを自作してきたチームは、標準化された手順が公開されたことで自作維持の正当化が薄まる。さらに、本人確認のないままAIツールを試験導入した現場は、その接続が統制上の指摘対象になりやすく、設計のやり直しが生じる。
立場別、明日から動ける一手。
自社のID基盤（Okta/Entra ID/Cognito）がAgentCore Gatewayの認可コードフローに連携可能か、公式ブログの3構成手順を確認する。
認証を自作する場合と既存ID基盤を流用する場合の運用コスト・展開速度を、AIツール導入計画の前提として比較する。
トークンなしの要求がHTTP 401で拒否され、Kiro IDEが自動で認証を開始する挙動を、サンプルリポジトリで試す。
公開直後で、争点はまだ本人トークン検証の運用設計に集中している。
公式発表と各所の反応から編集部が要約した主な論点です。個別のX投稿そのものは下部のセクションに表示されます。
「HTTP 401で拒否してKiro IDEが自動認証を開始する」
実装者の関心は「HTTP 401で拒否してKiro IDEが自動認証を開始する」挙動が既存のシングルサインオン環境で素直に動くか、アクセストークン1時間・更新トークン90日という寿命設定が自社の業務に合うかに向いている。Okta・Microsoft Entra ID・Amazon Cognitoという既存ID基盤を流用できる点には、認証を自作しなくて済むという実務的な評価がある一方、3構成要素（ID基盤・Gateway・MCPクライアント）の連携設定の手間を見積もる必要があるとの慎重な見方も並ぶ。
※トレンド検出時刻付近の人気投稿を表示
