Agents for Amazon Bedrock の「Return of Control」機能の可能性を考察する

# はじめに
2024/4/23のAmazon Bedrock (AWSの生成AIプラットフォームサービス) のアップデートでは「Agents for Amazon Bedrock」の新機能として **「Return of control」(ROC)** が発表されました。

当記事は、このROCの本質を紐解き、有益な活用法を導くことを目的として執筆したものです。

なお、ROCを理解するために、以前の記事で紹介したAgentsの実装例との動作の違いに着目しています。
以下の記事は、最も簡単なAgentsの実装例として比較的容易に理解できると思われますので、まず目を通していただくことを推奨します。

**「Agents for Amazon BedrockでWeb上のブログやニュースを要約する」**
https://qiita.com/nasuvitz/items/c34419150eaee78544cc


# Return of controlとは?
ROCを理解するために、まずは公式の解説を紐解いていきます。

## 原文
> Return of control – You can skip using an AWS Lambda function and return control to the application invoking the agent. In this way, the application can directly integrate with systems outside AWS or call internal endpoints hosted in any Amazon Virtual Private Cloud (Amazon VPC) without the need to integrate the required networking and security configurations with a Lambda function.

## 日本語訳
> Return of control – AWS Lambda 関数の使用をスキップして、エージェントを呼び出すアプリケーションに制御を返すことができます。このようにして、アプリケーションは、必要なネットワークおよびセキュリティ設定をLambda関数と統合することなく、AWS外のシステムと直接統合したり、Amazon Virtual Private Cloud(Amazon VPC)でホストされている内部エンドポイントを呼び出したりできます。

これは直訳ですが、一回読むだけでは分かりにくいと感じる方が多いのではないでしょうか。
特に分かりにくいポイントは **「AWS Lambda 関数の使用をスキップ」と「設定をLambda関数と統合することなく、AWS外のシステムと直接統合」** の2点ではないかと思います。

# Lambda関数を呼び出す方式 (Select an existing Lambda function) との違い
一旦、マネジメントコンソールに移動し、[先日に作成したAgents](https://qiita.com/nasuvitz/items/c34419150eaee78544cc)の設定を開いて確認していきます。
前の記事でも解説していますが、AgentsのAction Groupで、記事のURLを開く前処理を実行するLambda関数が設定されています。

改めて、この時のAgentsのAction Groupの設定値をマネジメントコンソールで確認すると **「Select an existing Lambda function」** であることが分かります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/211986/d190ee0d-2a28-c651-b0d5-ee8f33867b06.png)

これを **「Return control」** に変更すると、何がどのように変わるのかを見ていきます。
僅か1操作、オプションを選び直すだけで変化が分かります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/211986/a3637dce-21e3-5755-42f5-d0ae22d73359.png)

**「Return control」を選んだ瞬間、Lambda関数を選択するプルダウンが消えました。**

元々の設定では、記事のURLを開く役割を担っていたのはLambda関数なので、この操作を行った瞬間、**どこで記事のURLを開く処理を行うのか**という疑問が生まれます。

ここで、画面上における「Return control」の解説を読んでみましょう。
マネジメントコンソールにおける機能の使用方法ですが、本質を捉えています。

> テスト ウィンドウでのエージェントの応答では、応答を生成するための機能の詳細をユーザーに求めるプロンプトが表示されます。それ以上の構成は必要ありません。

この解説では、先ほどの例で言えば**URLを開くのはクライアント側 (Agentsを呼び出す側)** だということが説明されています。

実際にプロンプトを発行して試してみると、URLを開くLambda関数が設定されていれば同期的に連続して処理が行われて応答が返るのに対して、「Return control」ではAction Groupのアウトプットに相当する値 (従来であればLambda関数が実行して返す結果) をフォームで与えるように指示されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/211986/7851ebf5-9024-5669-dd75-18bf99e415cd.png)

なお、要約および解説させようとしている記事は以下です。

**「Amazon Bedrock のカスタムモデルを使用して Amazon Titan Image Generator G1 モデルをファインチューニングする」**
https://aws.amazon.com/jp/blogs/news/fine-tune-your-amazon-titan-image-generator-g1-model-using-amazon-bedrock-model-customization/

そこで、クライアント側 (今回はブラウザ) でこの記事のURLを手作業で開いて内容を取得し、その結果をフォームから手入力で以下のように与えます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/211986/7a91a272-9392-234d-26f4-07a1eb9ee74b.png)

Submitを押して待つと、以下のように結果が返ってきました。
フォームから与えた記事の内容を要約し、解説できていることが確認できました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/211986/dd0f0479-6ae3-ddbd-2489-6a9762c5fef6.png)

ここまでの検証結果から、2つのオプションの違いをまとめると、以下になります。
* 「Select an existing Lambda function」では、クライアントがAgentsを呼び出した後、AgentsがLambda関数を呼び出して前処理を実行し、AgentsはLambda関数の結果を使用してLLMを呼び出す。一連の処理は同期的に実行される。
* **「Return control」では、クライアントが予め(※)前処理を実行して結果を得ておく。クライアントはAgentsを呼び出し、前処理の結果を使用してLLMを呼び出す。前処理とAgentsの呼び出し以降の処理は非同期的に実行できる。**

※ 厳密には、LLMを呼び出すまでの間に、前処理が終わっていれば良い。

# Return of Control を活用したアーキテクチャ
ここまでの解説で、AgentsでROC機能を使用するには、LLMを呼び出す前に前処理を実行し、その結果をLLMを呼び出す時に与える必要があると分かります。

基本に立ち返ると、Agentsを呼び出す方法は、マネジメントコンソールで実行するか、何らかのプログラムやツールで実行するかのどちらかです。
先ほどはマネジメントコンソールから実行したので、手作業でURLを開いて、その結果を与えましたが、次は、クライアント用のLambda関数からAgentsを呼び出すことを考えます。
(以下の図を見ながら、前処理用のLambda関数と混同しないように注意してください)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/211986/3e0f1fb7-22c3-f121-46c2-807170fb19ce.png)

ここで、クライアント用のLambda関数が、どのように前処理の結果を得るかを考えます。

**重要なのは、クライアント用のLambda関数に前処理のコードを全て同居させたり、依存させたりしなくて良いことです。**
これは、OpenAIのFunction Callingとも異なる特徴であり、ROCを使用する最大のメリットと言えます。

例えば、以下のようなAmazon EventBridgeを使用したアーキテクチャを考えてみます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/211986/300b8996-0cee-8555-fe80-1d9b598efaa0.png)

このアーキテクチャでは、EventBridgeを挟んで、前処理とLLMへのリクエスト処理が分離している (両方の処理は非同期である) ことが分かります。

**従来のLambda関数を呼び出す方式 (Select an existing Lambda function) では、Agentsを呼び出した後、Agentsが同期的にLambda関数 (必須) を呼び出して前処理を実行しますので、15分以上かかる前処理はLambda関数の制約で実行できません。**

ROCであれば、Agentsを呼び出す前に時間のかかる前処理を終わらせておくことができます。**(Agentsの呼び出しと前処理の実行順序を逆転させることが可能)**
**Lambda関数が実行している前処理 (図中のEventBridgeの左側) は、例えばEC2やECSに置き換えることができ、15分以上かかる前処理も実行できるようになります。**

例えば、日中に前処理を終わらせておき、夜間にバッチ処理的にAgentsを実行することができます。
他には、前処理が終わったドキュメントから順に、EventBridgeのイベントトリガーで発火し、Agentsで処理するといったこともできます。

# まとめ
冒頭に分かり辛かった2点の解説を振り返ると **「AWS Lambda 関数の使用をスキップ」** は、Agentsを呼び出す時に同期的にLambda関数を呼ばなくて良くなったことと、前処理のためにLambda関数が必須ではなくなったと理解すれば良さそうです。

また **「設定をLambda関数と統合することなく、AWS外のシステムと直接統合」** は、Lambda関数を介さずとも様々なAWSサービスを参照し、前処理に相当する結果を得ることが可能と考えれば、すっきりするでしょう。

まとめると、Agents for Amazon Bedrockの「Return of Control」機能を使用すると、Agentsの呼び出しと前処理を非同期で実行でき、さらにこれらの実行順序を逆転させることができるため、Agentsを実行する上でのアーキテクチャの選択肢が大幅に広がると言えます。
Amazon BedrockとAWSの様々なサービスとの間の連携が進み、生成AIをより効果的に使用するための一助となるでしょう。

# 関連記事
* [Agents for Amazon BedrockでWeb上のブログやニュースを要約する](https://qiita.com/nasuvitz/items/c34419150eaee78544cc)
* [Amazon Bedrock Agents simplifies agent creation and launches Return of Control capability](https://aws.amazon.com/jp/about-aws/whats-new/2024/04/amazon-bedrock-agents-agent-creation-return-control-capability/)
* [Agents for Amazon Bedrock: Introducing a simplified creation and configuration experience](https://aws.amazon.com/jp/blogs/aws/agents-for-amazon-bedrock-introducing-a-simplified-creation-and-configuration-experience/)
* [Define return of control functions for your agent's action groups in Amazon Bedrock
](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-returncontrol.html)