Amazon Bedrock AgentCore実践入門 ～4.4まで読んで印象に残ったこと

『Amazon Bedrock AgentCore実践入門』を読み始めました。

https://www.amazon.co.jp/Bedrock-AgentCore-Strands-Agents%E3%81%A7%E6%A7%8B%E7%AF%89%E3%81%99%E3%82%8BAI%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88-AWS%E6%B7%B1%E6%8E%98%E3%82%8A%E3%82%AC%E3%82%A4%E3%83%89/dp/4815641234?tag=googhydr-22&source=dsa&hvcampaign=books

AWSは普段から触っていますが、AIエージェント開発についてはまだ手探りの状態です。本を読むだけでは理解した気になってしまうので、掲載されているサンプルコードを実際に動かしながら進めています。

この記事では、前回の続きとして第4章のハンズオン（4.4節）まで進める中で躓いたことや、印象に残った学びをまとめます。

といっても、今回は動かしながら「ふむふむ成程」パートが続いたのでつまるところはなかったです。

学びになったところは、特にこの考え方。

マルチエージェントの構成パターン検討のディシジョンツリー

シングルエージェントで実装できないか？
┗ シングルエージェントで十分？
　　OK　→　Single Agent
　　NG　→　Agents as Toolsを検討
　　┗ Agents as Toolsで十分？
　　　　OK　→　Agents as Tools
　　　　NG　→　特性は？
　　　　┗ 固定フローの実行　　→　Workflow
　　　　┗ 分岐やループが必要　→　Graph
　　　　┗ 自律的な協調が必要　→　Swarm

この設計方針を初期段階で要件に合わせて決めたうえで、設計→実装していく必要があるのだろうと思いました。

では何を基準に選ぶのか。

複雑度やルールの自由度、情報取得の範囲あたりが判断材料になるのかなと思い、さらにChatGPTと壁打ちして理解を深めてみました。

ほとんどのケースは Single Agent か Agents as Tools で十分かもしれません。

マルチエージェント・オーケストレーションというキーワードに引っ張られて Swarm を選択するのではなく、まずは単純な構成で実現できないか考えることが重要なのだと感じます。

人は、知れば使いたくなる、それが必要かどうかはさほど重要ではない

...昔誰かが言っていた気がします。

そうならないように、必要最小限のコストで最大限の効果を狙いたいところです。

本日のまとめ

この本は次の5章が超重要なポイントになる章です。

その前段として、「生成AIとは→エージェントとは→作ってみよう」を4章までに実施しました。

「なんとなく理解していた言葉」が、設計の判断軸として整理されていく感覚があって楽しいです。

引き続き読み進めながら、学んだことを記事として残していこうと思います。