Amazon Bedrock、AIエージェントの外部連携に同意画面 GitHubとSlackの許可を一元管理
- Amazon Bedrockに、AIエージェントの外部サービス利用を本人が許可する画面が加わりました。
- 企業は自社の認証基盤で社員を確認し、GitHubとSlackへの接続を個別に許可できます。
- 対象はAmazon Bedrockでエージェントを動かす企業と、その社員です。
AWSは「Amazon Bedrock」のエージェント基盤に、利用者の許可を集める「同意ポータル」を追加しました。AIエージェントがGitHubやSlackを本人の代わりに操作する前に、その許可を受け付ける画面です。
これまでは、この許可の受け皿を企業が自前で用意する必要がありました。許可を求めるページの表示や、戻ってきた利用者の本人確認を自社で組む形です。同意ポータルは、この部分をAWS側で引き受けます。
管理者はゲートウェイ(エージェントと外部サービスをつなぐ入り口)ごとにポータルを作り、そのURLを社員に配ります。利用者は自社の認証基盤でログインし、エージェントが使える外部サービスの一覧を確認します。GitHubとSlackは別々に許可でき、発行された鍵(トークン)は本人と結び付けて保管されます。
この仕組みが効くのは、Kiro、Claude Code、Cursor、Visual Studio Codeなどの開発ツールから使う場面です。これらはMCP(外部ツールと連携するための規格)でエージェントにつながります。一度許可すれば、次からの呼び出しは保存済みの鍵を使います。
誰がどのサービスを許可したかは、AWS CloudTrail(AWSの操作履歴を記録する仕組み)で後から確認できます。許可した本人と鍵がひも付くため、社員ごとの利用状況をたどれます。
つまり、AIに社内の道具を触らせるときの「本人の許可」を、AWSが用意した窓口で済ませられるという話です。これまでは、その受付窓口を各社が自分で作っていました。
新入社員にツールを渡すとき、本人名義でアカウントをひもづける作業に近いです。誰が何を許可したかが残るので、後からたどることもできます。
地味な機能に見えて、ここが詰まると社内展開は止まります。AIエージェントの話題は性能や賢さに寄りがちですが、実務で先に困るのは「誰の権限で動くのか」の方だという印象です。
筆者が引っかかったのは、許可を求める画面を各社が自前で作っていたという前段です。ログイン、戻り先のページ、ブラウザの状態管理。どれも本業と関係のない作業で、ここで止まっていた会社もあったのではないか、と思っています。
そういえば、名前が挙がったのはKiro、Claude Code、Cursor、Visual Studio Code。開発ツール側から社内のシステムをつつく使い方を前提に置いているのが分かります。同じ形の同意画面は、他のクラウド各社も数か月のうちに出してきそうです。
いまはGitHubとSlackだけ。ここに勤怠や経費のシステムが並ぶようになったら、AIエージェントの導入検討は一気に現実的になります。次のre:Inventで、つなげる外部サービスがどこまで増えるかを見たいです。
社内でAIエージェントにGitHubやSlackをつながせたい人は、社員一人ひとりの許可を自前の仕組みなしで集められるようになります。
