AIエージェント版IAMを設計する ― 承認ゲートを組織のゴールデンパスにする
概要
AIエージェントがコードを書き、決済を実行し、外部サービスを操作する時代になった。 だが「このエージェントに何をどこまで任せていいか」を、サービスごとに個別実装 していては、認知負荷は下がらずむしろ増える。 このセッションでは、決済(Amazon Bedrock AgentCore Payments)、Slack上の 承認フロー、iPhone上のMCP経由操作という、性質の異なる3つのドメインで 「AIエージェントに権限を渡し、必要な操作だけ人間の承認を挟む」仕組みを 実装してきた経験から、共通して現れたパターンを抽出する。 主張は一つ。承認ゲートは個々のサービスが都度作り込むものではなく、 人間のIAMと同じように、プラットフォームチームが提供すべき共通プリミティブ になりつつある、ということだ。 具体的には以下を扱う。 ・エージェントの「自律で良い操作」と「承認が要る操作」をどう線引きするか (spending limits、Step Functionsでの待機ステップなど、AWS上での実装選択肢) ・承認ゲートをMCPサーバーとして切り出し、ドメインをまたいで再利用する設計 ・開発者がセルフサービスでエージェントに権限を持たせつつ、組織側の ガバナンスを損なわないための責務分離 決済・チャット・モバイルという異なる現場で同じ設計を繰り返し実装した 失敗と学びをもとに、「エージェント向けIAM」を自分のプラットフォームに どう組み込み始めればよいか、実践的な出発点を持ち帰ってもらう。
AIエージェントガバナンス承認フローゴールデンパスIAMMCPAmazon Bedrock AgentCore認知負荷セルフサービスプラットフォームエンジニアリング
スピーカー
AWS Community Builder(AI Engineering)。個人開発でAmazon Bedrockや AgentCore Runtime/Payments、MCPを使ったAIエージェントアプリを継続的に 開発・公開している。決済・チャット・モバイルなど複数ドメインで 「AIエージェントに権限を渡しつつ人間の承認を挟む」仕組みを実装し、 Qiita Tech Festa Day 2026やAWS Community Day Singapore 2026などで 登壇。自律と承認のあいだにどう境界線を引くか、実装ベースで探っている。