Amazon Bedrock AgentCore実践入門 ~3.4までで躓いたこと・学び

Amazon Bedrock AgentCore実践入門 ~3.4までで躓いたこと・学び

Amazon Bedrock AgentCore実践入門 ~3.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エージェント開発についてはまだ手探りの状態です。本を読むだけでは理解した気になってしまうので、掲載されているサンプルコードを実際に動かしながら進めています。

この記事では、第3章のハンズオン(3.4節)まで進める中で躓いたことや、印象に残った学びをまとめます。

最初から戸惑う...

本書ではPythonのパッケージ管理にuvが使われており、この教材ではREADMEの通りに進めれば環境構築が完了します。

そもそもuvとはなんぞや、というところで躓きましたが、ChatGPTと行ったり来たりですぐ解決できるのは本当に現代の恵まれているところだと感じます。

Bedrockが本当に動いているのか分からなかった

最初に実行したコードは Agent( ... と指定しており、モデルを指定しない方法での実行です。

問題なく応答が返ってくるのですが、問題ないというところが既に疑問です。

「これ、本当にAmazon Bedrockを使っているのだろうか?」

コードを見る限り、モデルの指定もありません。

そこでAWS CLIで認証状態を確認してみました。

するとIAMユーザー情報が表示され、AWS認証が通っていることを確認できました。

後から調べて分かったのですが、Strands Agentsは環境に応じて利用可能なモデルを自動的に検出できます。

単純に「動いた」で終わらせず、「なぜ動いたのか」を確認する習慣は大切だと改めて感じました。

モデルIDでエラーに遭遇する

本書のサンプルコードを実行していると、1.5.2で次のエラーに遭遇しました。

botocore.errorfactory.ValidationException: An error occurred (ValidationException) when calling the ConverseStream operation: The provided model identifier is invalid.

書籍内ではsonnet4.6が指定されていましたが、自分の環境では有効にしていないです。

自分の過去記事を見て、あぁこれかと編集してみたところ無事突破。

BedrockでLLMを指定する部分はLLMの利用権限・リージョンは逐一確認するポイントだなと思いました。

公式ドキュメントを読む重要性

本書は非常に丁寧ですが、サンプルコードを追うだけでは理解しきれない部分もあります。

特にStrands Agentsについては、公式ドキュメントを合わせて読むことで理解が深まりました。

例えば、

  • Toolとは何か
  • MCPとは何か
  • Community Toolsには何があるのか

といった内容は、公式ドキュメントを眺めるだけでも全体像が見えてきます。

今後は本を読み進めながら、必要に応じて公式ドキュメントやGitHubの実装も確認していこうと思います。


本日のまとめ

まだ3.4節までしか進めていませんが、すでに多くの学びがあります。

印象的だったのは、AIエージェント開発が単純なプロンプトエンジニアリングではなく、

  • モデル
  • ツール
  • 外部システム連携

を組み合わせて設計する世界だという点ですね。

Bedrockのエージェント機能でもできるのかもしれませんが、Agentcoreの方が細かくチューニングができるイメージですが、どうなのでしょうか。

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