🙇 お詫びと訂正：Bedrock Agents と AgentCore を混同していました
私は Bedrock Agents と AgentCore を同じものとして書いていました。
両者は名前は似ていますが別物です。
- 旧版で使っていた
AWS::Bedrock::Agentやinvoke_agent()は Bedrock Agents（2023年〜・設定ベース） のもの - これから本格的にエージェントを運用する基盤は AgentCore（2025年10月GA・コードファースト）
深掘りはしませんが、混同を避けるための最小限の違いだけ置いておきます👇
アドバイスいただきました先駆者の方に感謝いたします。そういうこともあり、単語に溺れないよう、簡単に学べるよう入り口を伝えていきたい気持ちは継続していきます。
[共有] Bedrock Agents ≠ AgentCore（全くの別サービスです）
Amazon Bedrock は基盤モデルアクセス・ナレッジベース・ガードレール等を含む生成 AI プラットフォーム全体を指します。その中にエージェント関連サービスとして Bedrock Agents と AgentCore の両方が存在します。Bedrock Agents は設定ベースのマネージドなエージェント構築サービス、AgentCore はコードファーストで任意のフレームワーク・モデルを使い、より細かい制御を可能にするエージェント運用プラットフォームです。
| BedrockAgents | AgentCore | |
|---|---|---|
| 登場 | 2023年 | 2025年 GA |
| アプローチ | 設定ベース（ノーコード寄り） | コードファースト |
| フレームワーク | AWS が固定 | 何でも使える（Strands / LangGraph / CrewAI…） |
| MCP対応 | ❌ ネイティブ非対応 | ✅ 対応 |
| 自由度 | 低い（AWS管理範囲が広い） | 高い |
| 更新 | 止まり気味 | 活発に拡大中 |
- Bedrock Agents では標準機能として MCP サーバーにアクセスできませんが、これは Bedrock Agents が MCP（2024年登場）よりも先に登場したためと考えられます。
Agents で IAM 認可を自動化する
📍 はじめに：パターンの統一性
記事1で学んだことを覚えていますか？
API Gateway / Cognito + IAM Role で、「誰が」「何を」できるかを制御する（PassRole を覚えよう）
この記事で言いたいのはたった1つ。
その認可パターンの"考え方"は、AI エージェントの世界でもそのまま効く。
同じ原則で考えられる = 覚えることが1つで済む。これが伝えたいことです。
別記事 全てのリソースはIAMで制御できる〜PassRoleを覚えよう〜 を読んだら、次は「AI もただ使うだけじゃなく、ちゃんと統制して使い倒す」段階。でも身構えなくて大丈夫、新しい認可の概念を覚え直す必要はありません。
⚠️ なお本記事は AgentCore や Gateway の実装ハンズオン記事ではありません。 「認可の考え方が地続きだよ」という話に絞ります。各サービスの中身は後述の書籍がとても良いのでそちらへ。
🚦 用語の交通整理（"差"だけ・深掘りはしない）
「AgentCore とか Strands とか Gateway とか Identity とか、単語が増えてもう分からん」となりがちなので、それぞれが何なのか・何が違うのかだけ1行ずつ。
| 用語 | ひとことで | 作った |
|---|---|---|
| MCP | AI ↔ ツール接続の"USB規格"（標準仕様） | Anthropic |
| Strands Agents | エージェントをコードで書くOSSフレームワーク | AWS |
| AgentCore | 書いたエージェントを本番運用する基盤（≠ Bedrock Agents） | AWS |
| AgentCore Gateway | 既存 API / Lambda をツール化する AgentCore の一機能 | AWS |
| AgentCore Identity | エージェントが外部SaaSにユーザー代理アクセスする時のトークン管理（IAMとは別レイヤー） | AWS |
| （参考）Bedrock Agents | 旧来の設定ベースエージェント。更新は鈍化気味 | AWS |
頭の中の地図としてはこれで十分です：
MCP（規格）の上で
└ Strands（書く）→ AgentCore（運用する）
├ Gateway … ツールへの入口
└ Identity … 外部SaaSへの代理アクセス
🌾 この辺りを**腹落ちさせたい人は、ぜひ書籍を！
なんでか？どうやって学ぶか：（先に答えを書いてしまいます）
生成AIアプリ開発入門の本で、おーつきもAIは一通り使いこなせるようになりました。そんななClaudeが文章をはじめ「誤字・脱字」「なにいってるかわからないよ、お・お・つ・き くん！」なんて指摘も減りまくり。LoveAWSのつぎにくるのはLoveAI。
去年は、re:invent で 「エージェンティックAI」という単語「AIエージェントの英語版か？Alexaくるなー❤️」とおもってましたが、この人間のやりたいこと「誤字・脱字・伝わる」能力を引き出してくれているのがMCPというものが出たことによって性能がぐーんと上がってきています。今年は、そのえージェンティックな部分がいくつも生まれ・整備され始め・セキュリティ事故も整備され始めなんてところです。
AWSではじめるMCP実践ガイド――基礎からAIエージェント構築まで徹底解説
発売日に購入しておいたら、同僚だった森田さんが 「いいもの書いたから、読んでみて。送るから」神のようなパイセン森田さんからMCPとその周り特に、この書籍では ４行でかけるBedrockから入門した生成AIの先にくる、特技や性能を上げるための仕組みと使い方、実際使いはじめると「AgentCoreとかStarandsAgentとかだんだんまた単語が増えてきて、Bedrockのなかにいろんなサービスも増えて、なんだかわかならないくなりそうを整理もしてくれます」作ったわいいがはまりそうな壁についてまで要所要所かいてある。そこから森田さんの得意なサンプルコード盛りだくさんが詰め込まれていて まず、皆が２歩目に立つことができるようになります。
🌾会社の同僚だった森田さんたちの買いた本（宣伝ではありません。めちゃくちゃ導入で復習するのに、わかりやすい本なのでまずお勧めします。）
🔗 StrandsAgentやAgentCoreは 別記事に移動します
（本件は、 API GatewayとCognito利用する際にIAM素晴らしい！って覚えたら、AIも同じようなことできんじゃね？特に LLMの拡張をしていくとカオスになるMCPたちの制御やアクセス関連）
についての説明をしたいと思います。
一応絵だけのこしておく
- MCPというものがある
- 色々作法に従って書くの大変だから Python でOSSとして StrandsAgentが出た
- そのStrandsAgentをコンテナイメージ化してデプロイしやすくしたのが AgentCore
- このデプロイされた機能をAIに所属させるとスキルだとか自立型Agentが強くなる
- QDeveloperやKiro、Claudeからもよべる （もともとMCPはClaudeがLinuxに寄与したもの）
- MCPたちをまとめないと 色々な制御がまた大変になってきてる・・・（それでAgentCoreが登場するとシンプルになります）
- ※MCPをUSB-Cに例えられても「おーつき」はさっぱりわかんなかったw
🎯 本題：持ち越せるのは"仕組み"ではなく"設計の型"
ここが記事の核です。細かい仕組みをそっくり移すのではなく、「認証と認可を分けて考える」という設計の型がそのまま効く、という話です。
記事1で学んだ型は、たった2段でした：
① 認証（誰か） … Cognito でログイン → 「あなたは誰か」を確定
② 認可（何ができる）… 実行する主体にロールを与え、その範囲だけに絞る
AI エージェントの世界でも、考える型は同じ2段です：
① 認証（誰か） … Cognito でログイン → 「あなたは誰か」を確定 ← 同じ
② 認可（何ができる）… エージェントにロールを与え、その範囲だけに絞る ← 同じ
並べるとこうなります。「誰か」は Cognito、「何ができるか」はロール。この対応が崩れません。
| 段 | API Gateway パターン（記事1） | AI エージェント |
|---|---|---|
| ① 認証（誰か） | Cognito でログイン | Cognito でログイン（同じ） |
| ② 認可（何ができる） | 実行する主体にロールを与える | エージェントにロールを与える（同じ考え方） |
| 範囲の絞り込み |
LeadingKeys で「その人の分だけ」 |
同じ |
| 監査 | CloudWatch Logs | CloudWatch Logs |
つまり「実行する主体が Lambda から AI エージェントに変わっただけ」。
設計時に考えることは、記事1から1つも増えていません。これが言いたかったこと。
🔧 もちろん、トークンをどう検証するか・ロールをどう渡すか（記事1でいう PassRole 的な部分）・外部 SaaS 連携をどう扱うか（AgentCore Identity）といった配線の作法はサービスごとに違います。ただ、それは"型"を覚えた後の実装ディテール。そこは書籍と公式ドキュメントが詳しいので、本記事では「型は同じ」までに留めます。（論点をぼかさないため、あえて深入りしません）
🎯 結論：「1つ覚えたら2つできる」
API Gateway / Cognito で覚えた IAM の認可パターンは、そのまま AI エージェントの設計にも持ち込めます。
Cognito で「誰か」を確認 ─→ AI でも同じ
IAM Role で「何ができるか」 ─→ AI でも同じ
LeadingKeys / CloudWatch ─→ AI でも同じ
| 観点 | 利点 |
|---|---|
| 学習効率 | API の認可を理解すれば AI エージェントも自動的に理解できる |
| 実装効率 | ロール定義の考え方を流用できる |
| 保守効率 | 認可ロジックが IAM に一元化されている |
| 監査効率 | 全て CloudWatch Logs に記録 |
✍️ 最後に（ここからは考察）
API 開発も AI エージェント開発も、AWS IAM の"考え方"は同じ。
これが 「シンプルに、細かいことができる」 AWS の本当の価値。なんどもいう、BuildingBlock って素晴らしい。
プログラマは、さまざまなライブラリをつなぎ、組み合わせ、いろいろ考慮して、挙げ句の果てに徹夜してまで書くことがあります。ただ、この思想を覚えると「プログラムを書くべきところ」と「AWS の機能を使って、作り込まないことを選択するところ」を切り分けられるようになる。
ちょっと昔の自分なら、「なんでも書けちゃうから、そんなもの使わずに書いちまおう」という考えでした。でも——セキュリティの観点、セキュリティおじさんのマウントとマサカリ、サービス間連携、ログ設計、ACL とは何か、「おーつきくん見積もり終わった？えっ高くない？」——そういう諸々から解放されたのが、この設計思想の一番ありがたいところでした。
これって、横道に逸れますが AWS の認定資格（Practitioner など）で設計思想を学ぶときに腹落ちするやつで、改めて「良い試験だな」と気付かされます。
そして AI エージェントが自律的に動く時代だからこそ、「誰の権限で・何に・どこまで」を IAM で明示することの価値はむしろ上がっています。新しい単語（AgentCore, Gateway, Identity…）に圧倒されても、認可の芯は記事1から変わっていない。 ここを押さえれば、エージェント時代のセキュリティ設計も怖くありません。
その根っこにあるのは「セキュリティを最優先する」「お客様（使う人）を起点に考える」という思想。昔よく言われた"責任分界点"とはまた違う、責任を共有できる土台を最初に作る——これが 「0を1にする」「1を10にする」 設計の本質だと思っています。
アプリエンジニアに「AWS って何が便利？」と聞かれたら、記事1とこの記事を見せてあげてください。きっと、AI の時代になっても AWS の本当の価値が地続きで伝わるはずです。