Amazon Bedrock Agents に EC2 停止のおつかいをたのんでみる

クラウドソリューション部の荒木です。チャット形式の生成 AI の発展形として「AI エージェント」という言葉を目にする機会が増えてきています。今回は AWS で利用できる AI エージェントを動かしてみたお話です。

AI エージェント、って何ですか？

AI エージェントとは「ユーザと対話し、自律的に意思決定を行い、特定のタスクを実行する AI システム」を指します。例えば、現在の AI に「旅行に行きたい」とリクエストすると、おすすめの観光地やその魅力を要約して返してくれると思います。これに対して、 AI エージェントに「旅行に行きたい」とリクエストすると

• ユーザに予算や日程の希望を聞く
• ユーザの嗜好に関するデータや時期から行先候補を決める
• 宿泊先や交通機関を予約する
• スケジューラに日程を保存して「○○への旅行を手配しました」と教えてくれる

という一連の働きをするようなイメージでしょうか。人間の代わりにタスクの洗い出しや実行までやってくれる、という違いがあります。スマートウォッチのバイタルデータに疲労感が表れていれば、温泉旅行なんかを手配してくれるかもしれませんね。

OpenAI は AI の発展を評価する5段階のスケールを発表しています。これは生成 AI の発展の5つの段階と各レベルでの AI の特徴を示したもので、AI エージェントはレベル3に位置付けられています。

参考記事：OpenAI Sets Levels to Track Progress Toward Superintelligent AI – Bloomberg

Amazon Bedrock Agents について

Amazon Bedrock Agents （以降、Bedrock エージェント）は AWS が提供する AI エージェントの機能です。基盤モデルを使用してユーザの入力を解釈し、希望を達成するためのタスクを選定して実行します。この「実行」とは API の呼び出しか、予めバックエンドに作成しておいた AWS Lambda （以降、Lambda）の呼び出しです。つまり、Amazon Bedrock が直接他のシステムに干渉する機能を持っているわけではありません。Bedrock エージェントがどのようなスキルを持つかは、裏側の API や Lambda の作りこみ次第ということになります。

作ってみました

実際に Bedrock エージェントを使ってみます。マネジメントコンソールにログインすることなく、Slack のチャットスペースから直接 Amazon EC2（以降、EC2）が停止できるような仕組みを作ってみました。動作の流れは次のようになります。

1. 構成図の灰色の矢印：起動中の EC2 を Slack に通知するリマインダー
   1. 決まった時間に Amazon EventBridge が起動し、Lambda をトリガーする
   2. Lambda が EC2 の起動状況をスキャンして、EC2 インスタンス ID やインスタンス名情報を Amazon SNS へ送信する
   3. Amazon SNS から AWS Chatbot を経由して、メッセージが Slack に到達する
2. 構成図の赤色の矢印：Slack から AI エージェントに EC2 の停止をリクエストする
   1. Slack のチャット上で EC2 を停止するリクエストを送信する
   2. リクエストが AWS Chatbot を経由して Bedrock エージェントに到達する
   3. Bedrock エージェントが Lambda を実行する
   4. Lambda は対象の EC2 を停止する

※各サービスの詳細な設定手順は割愛します。
※AWS Chatbot は Amazon Q Developer に名称が変わりましたが、検証当時の情報でそのまま記載しています。

EC2 を停止する Lambda は、対象のインスタンスを一意に検出できる必要があります。そこで、Bedrock エージェントの設定で、受け取るリクエストに EC2 インスタンス ID （インスタンスごとにユニークなパラメータ）を含めることを必須としました。これによって、EC2 停止のリクエストに ID が含まれていなかった場合に Bedrock エージェントはチャットでの会話を継続し、ユーザに ID の情報を催促します。

動かしてみました

ここからは実際の動作をご紹介します。まず、EC2 実行中のリマインダーが Slack に送信されました。このメッセージは Lambda のプログラム内に記述されている文章で送信されています。

続いて、ユーザ側から EC2 インスタンス停止リクエストのメッセージを送信（返信）します。 “@aws ask” は AWS Chatbot に向けたメッセージ送信コマンドで、 “sonnet” は Bedrock エージェントとの接続名を指定しています。「EC2 を停止してください。」とだけ送信すると、必須情報である EC2 インスタンス ID が含まれていないため、Bedrock エージェントは ID を返信するよう返信してきました。改めて ID を送信すると、対象の EC2 が停止した旨のレスポンスが届きました。（AI の処理と Lambda の実行時間が含まれるため、停止完了のレスポンスが届くまで20～30秒程度待つ必要がありました。）

EC2 のダッシュボードを確認すると、ID を伝えたインスタンスが停止されたことが確認できました。いい感じですね。

次は英語でリクエストを送信してみましょう。チャットで送信した言語にあわせて AI がレスポンスを生成してくれます。最初のリクエストと同様、あえて EC2 インスタンス ID を抜いてメッセージを送信してみましたが、Bedrock エージェント側で ID 情報が必要な設定は変わらないため、返信で ID を要求する流れは変わりません。ちなみにこのあと、フランス語、アラビア語などでもリクエストを試してみましたが、問題なくスムーズに動いてくれました。

構築中にハマったところ

Lambda のコードを調整しているとき、Bedrock エージェントに EC2 停止をリクエストすると  “EC2 の停止は成功するが、Slack にはエラーのレスポンスが返ってくる” という状況に長らく悩まされました。Lambda の実行ログを CloudWatch ログイベントで確認しても、EC2 を停止するという処理自体は成功しているため、このエラーレスポンスの原因となりそうなエラーログが確認できません。また、Bedrock エージェントの CloudWatch ログイベントを確認しても Slack へのメッセージ送信のログしか確認できず、なぜエラーとなるのか、何がエラーの要因なのかを解決するのに時間がかかってしまいました。

最終的に AWS サポートに問い合わせてエラーを解消できたのですが、結論として、Lambda のレスポンスデータの形式が Bedrock が期待している形式と異なっている（リファレンスでオプションと説明されているフィールドを省いてしまっていた）ことが直接の原因でした。

リファレンス：Amazon Bedrock エージェントがユーザから取得した情報を送信するように Lambda 関数を設定する

関連情報

ここまで “AIエージェントとは何か”、“ Bedrock エージェントでなにができるか” を簡単にご紹介してきました。

この記事でご紹介した AI エージェントはシングルエージェントと呼ばれる方式で、1つの AI エージェントが単独でタスクを遂行するシステムです。運用がシンプルで、小規模なタスクに適していますが、複雑なタスクには限界があります。今回で言えばエージェントのスキルである Lambda に多岐に渡る処理能力を持たせる構成にすると、プロンプトやコードの複雑化、処理が遅くなる、適切なアクションを呼び出せなくなる可能性があるといった逆効果を生むリスクがあるようです。

一方、複雑なタスクを分割して複数のエージェントが協力しながらタスクを遂行するマルチエージェントという方式もあります。こちらは各エージェントが異なる役割を担い、協調して目標を達成するため、複雑なタスクや大規模なプロジェクトに適しています。マルチエージェントシステムは柔軟性と拡張性が高く、システム全体の効率を向上させることができます。また、マルチエージェントのなかでも、エージェントの配置（エージェント間で直列にタスクを受け渡すか、並列で処理を行うか、など）によって成果の精度を上げるのか、解決にかかる速度を重視するのか、というケースバイケースに適した設計手法があり、議論が進められているようです。

AI  エージェントの機能や設計手法の活発な議論を追うように、Bedrock エージェントのアップデート情報も数多く発表されています。

Amazon Bedrock のエージェントでカスタムオーケストレーションのサポートを開始 – AWS

Amazon Bedrock のカスタムオーケストレーション機能では、Lambda を使用してエージェントの行動順序や判断プロセスをカスタマイズできます。これにより、エージェントがどのようにタスクを遂行するか、どのツールを使用するかを細かく制御可能です。さらに、RAG やガードレールなどの機能を連携させることで、エージェントの動作を人間がガイドし、特定のユースケースに最適化されたエージェントを構築できます。これにより、エージェントの回答の精度や効率を向上させることが可能です。

Amazon Bedrock がマルチエージェントコラボレーションのサポートを開始 – AWS

Amazon Bedrock のマルチエージェントコラボレーション機能では、複数の AI エージェントが協力して複雑なタスクを遂行します。各エージェントは専門分野に特化しており、スーパーバイザーエージェントがこれらのエージェントを調整します。スーパーバイザーエージェントはリクエストを分類し、タスクを委任し、アウトプットを最終的な回答にまとめます。これにより、エージェント間の効率的な通信と協力が可能となり、タスクの成功率や正確性が向上します。例えば、投資顧問システムでは、財務データ分析、調査、予測、投資推奨を専門とするエージェントが協力して作業します。

おわりに

いかがでしたでしょうか。Amazon Bedrock Agents を扱うにあたり、そもそも AI エージェントってなんだ？というところから調査を行いましたが、今後のシステム開発において大きな影響を与える機能なのではないかと感じました。また、今後 AI を組み込むシステムにおいて、AI エージェントの設計はスキルとしても重要な領域になるのではないか、とも予想しました。今回はシンプルに EC2 の停止機能として Lambda を作成しましたが、他の AWS サービスを組み合わせれば、さらに多機能な AI アプリケーションも構築できそうです。実際に扱ってみて、今後の発展性や作りこみ要素に面白さを感じたので、引き続き注目していきたいと思います。