著者のみのるんさん（@minorun365）から『Amazon Bedrock AgentCore 実践入門 — Strands Agents で構築する AI エージェント [AWS深掘りガイド]』を頂いたので、書評を書きます。
私は、自分の立ち位置——「エージェントを作る側じゃなかったインフラ屋が読んだら、どう感じたか」——という角度で書いてみます。
本書について
| 項目 | 内容 |
|---|---|
| 書名 | Amazon Bedrock AgentCore 実践入門 — Strands Agents で構築する AI エージェント [AWS深掘りガイド] |
| 著者 | 御田 稔（みのるん／@minorun365）、熊田 寛、森田 和明 |
| サンプルコード | https://github.com/minorun365/agentcore-book |
1. はじめに：ちょっとした食わず嫌いの話
私はもともとインフラエンジニアで、Oracle Database や AWS の基盤まわりを見ていることが多かったです。AIエージェントという言葉はもちろん知っていましたが、どこかで「あれはアプリ開発者が"作る側"でやるもので、基盤を見ている自分にはまだ先の話かな」と思っていました。
Claude Code を使い始めてまだ数ヶ月、Bedrock も深くは触れていない——そんな立ち位置です。なのでこの本も、最初は「面白そうだけど、自分が手を動かす日はもう少し先かな」くらいの距離感で開きました。
その距離感が、読み進めるうちに少し変わった、という話を書きます。
2. きっかけ：献本と、発売前日の講演
きっかけは2つあります。1つはもちろん本書を頂いたこと。もう1つが、発売前日に著者本人の話を直接聞けたことでした。
印象に残ったのが、「"問題児"を動かすインフラ選定の課題」という話です。ストリーミング応答、時間のかかる非同期処理、認証認可や監視、なるべく安く済ませたいサーバーレス——AIエージェントの話のはずなのに、出てくる課題が見事に全部"基盤の話"でした。普段インフラ活用時に悩んだりすることが多い内容です。
さらに著者が、Excel の棚卸しみたいな地味な事務作業まで AI にやらせている例を挙げていて、そこが自分にも少し引っかかりました。「これ、"作る人"の特別な話というより、"自分の面倒な仕事が楽になる"話なのでは？」と。
3. インフラ管理の "あの雑務" が、楽になるかも
第1部（基礎編）・第2部（Strands Agents編）で考え方は掴めたので、第3部（AgentCore編）は拾い読みしながら「これ自分のどの仕事に効くかな？」という目で見ていきました。
読んでいて一部には既視感がありました。ここに出てくる課題、最近別の基盤の Claude Desktop の MCP 検証で、手作業でおこなったやつだ、と。あのとき私がやっていたのは、ツールに渡す権限を絞る・認証をちゃんとやる・エージェントのツール選択のブレを実測する、みたいな話でした1。
本書で解説されている AgentCore の主要機能——発売前日の講演では「5つの武器」と紹介されていました——は、こうした運用の課題を、マネージドサービスとしてまとめて引き受けてくれるものでした。下の表のうち、認証（Identity）・権限の切り分け（Policy）・ツール挙動の可視化（Observability）あたりは、私が手作業でやっていたことと重なります。
| 運用で出てくる課題 | AgentCore のこの機能 | インフラ仕事で言うと |
|---|---|---|
| SaaS に同じ権限で触らせていい？ トークン交換の自作が面倒 | Identity | IAM・認証認可の境界 |
| 危険な操作をうっかり承認。if 文を足しては再デプロイ | Policy | 権限・ガードレール |
| ログが多すぎて追えない | Observability | BlackBox化を避けたい |
| 利用者が減る原因が分からない | Evaluation | SLO・品質監視 |
| 野良エージェントが乱立して台帳が破綻 | Agent Registry | 構成管理・棚卸し |
認証まわりもそうでした。MCP を OAuth 2.0 + PKCE で繋ぐのは地味に手こずったんですが2、AgentCore だと Identity がそこを巻き取ってくれます。こういうところがマネージドで用意されていると、正直助かります。
特に Observability が刺さりました。私が Qiita でこだわっていた「BlackBox化を避けて中を覗きたい」が、最初から前提になっています。拾い読みした範囲でも、トレースが標準で用意されているのを見て、「あ、これは後から監視を足して回る世界じゃないんだな」と少しほっとしました。
この段階では拾い読みで、手は動かしていません（それは次の章で少し試します）。それでも「自分が手でやったことに、ちゃんと名前が付いている」と分かるのは、読んでいて一番の収穫でした。
4. 実際に、ちょっとだけ越境してみた
机上で終わると説得力がないので、本書のサンプル（Strands Agents を使った、3行で書けるエージェント）を、踏み台 EC2 の上で実際に動かしてみました。狙いは欲張らず、「Bedrock の Claude に繋がるか」の疎通確認だけです。
環境は東京リージョン（ap-northeast-1）、モデルは Claude Sonnet 4.6（jp.anthropic.claude-sonnet-4-6）です。AWS の認証情報は EC2 のインスタンスロール経由で取得しています。
書いたコードは、本当にこれだけです。(Claude Codeに書いてもらったのですが・・)
import os
from dotenv import load_dotenv
from strands import Agent
load_dotenv()
os.environ.setdefault("AWS_REGION", "ap-northeast-1")
agent = Agent(model="jp.anthropic.claude-sonnet-4-6")
agent("あなたは何ができるエージェントですか？1文で答えてください。")
これを次のコマンドで実行します。
uv run step1_agent.py
返ってきた応答がこちらです。
私はテキストベースの質問への回答、文章の作成・翻訳・要約、アイデア提案など、幅広い言語タスクをお手伝いできるAIアシスタントです。
動かしてみての率直な感想は、「思っていたより手数が少ない」でした。エージェント本体は実質 Agent(model=...) と agent("...") の2行で、「3行で繋がる」は誇張ではありませんでした。推論プロファイル名（jp. で始まる東京向けの名前）とリージョンさえ揃えておけば、認証もモデルアクセスも特に詰まらずに通りました。インフラ屋として身構えていた認証まわりが、ロールを付けておくだけで済んだのは、いい意味で予想外でした。
一方で、uv sync（依存パッケージの取得）で降ってくるライブラリ群は、uvicorn や watchdog などけっこう重厚でした。書く側のコードは数行でも、その下にはちゃんとしたランタイムが控えている——その構造が垣間見えたのは、むしろインフラ屋として安心できるポイントでした。
MCP 化や AgentCore ランタイムへのデプロイ、Identity / Policy での権限統制までやると一冊ぶんの分量になるので、今回はここまで。別の基盤で手作業した MCP の権限分離を AWS 側でどうカバーできるかは、別途じっくり試したいと思っています。
5. こういう人に読んでほしい
もしあなたが、かつての私のように「AIエージェント＝作る人の話」と距離を置いているインフラ／運用の人なら、本書は"自分ごと"として読めると思います。出てくる課題が、普段の運用の悩みとそのまま地続きだからです。
正直に言うと、私自身はどちらかというとずっとインフラ屋で、コードらしいコードといえば、昔 Shell で sed と awk を駆使していたくらいです。Python で何かを作るような経験はほとんどなく、献本をいただいたときも「自分に使いこなせるかな」という気持ちが、正直ありました。
それが、4章のとおり実際に動かしてみると、想像していたよりあっさり動きました。AgentCore を使った本番運用の作り込みという本書の本領はこれからじっくり読みますが、"作る側" に一歩踏み出す入口としては、敷居の低い一冊でした。そんな私でも踏み出せたので、同じようなインフラ／運用の人にこそ、次の道具の一つとして手に取ってみてほしいです。
参考
- 本書サンプルコード: https://github.com/minorun365/agentcore-book
-
OCI DB Tools MCP の3タイプをカスタムロールで権限分離してみた （ちょっと検証の観点が違いますので純粋な比較ではないです） ↩