Amazon Bedrock、AgentCore移行を2段階で提示 LangGraphをRuntimeなどへ
- LangGraphのサポートエージェントを移行する内容です。
- Stage 1でRuntime、Gateway、Memoryに移します。
- Stage 2でStrands Agentsのモデル駆動計画に移します。
AWS Machine Learning Blogは、LangGraphで作られたカスタマーサポートエージェントをAmazon Bedrock AgentCoreへ移行する手順を示しました。対象のエージェントは問い合わせを分類し、怒っている顧客をエスカレーションし、それ以外には3つのツールで回答します。モデル呼び出しはすでにAmazon Bedrockへ向いています。
Stage 1では、グラフを変えずにAmazon Bedrock AgentCore Runtime、Gateway、Memoryへ移します。Runtimeはエージェントをホストし、GatewayはAWS LambdaターゲットをModel Context Protocolのツールとして公開します。Memoryは会話状態をアクターとセッションにひも付けて保持します。
Stage 2では、ループをStrands Agents上のモデル駆動計画として作り直します。手書きの分岐を外すことは選択肢として示されています。Stage 3ではAgentCore harnessにループを渡す機能が説明されていますが、記事内では構築していません。
Runtimeはコンピュートを受け持ち、OSパッチ適用、自動スケーリング、セッション分離を運用対象から外します。Gatewayはツール認証を扱い、Memoryはターン、プロセス、日をまたいだ会話状態を保持します。一方でIAMポリシー、VPC設定、WAFルール、シークレットローテーションは各段階で利用者側に残ります。
つまり、自社で用意したサーバーで動かしていた問い合わせ対応のAIを、AWSが管理する場所へ引っ越しさせる手順です。
第1段階では、AIの受け答えの中身は変えず、置き場所と外部ツールを呼ぶときの認証、それに会話の記憶だけを預けます。OSの更新や、利用者ごとの会話を混ぜない仕組みは、自分で面倒を見る対象から外れます。第2段階では、手書きの場合分けをやめて、次に何をするかをモデルに決めさせる形に作り替えます。
移行の手順書なのに、手放せるものと手元に残るものを並べて見せているところが目を引きます。OSの更新や自動スケーリング、利用者ごとの分離は預けられる一方、IAMポリシーやVPC設定、WAFルール、シークレットローテーションはどの段階でも自分持ち。この線引きを先に示す記事はかなり親切です。
そういえば、段階を2つに割った狙いも分かりやすいです。置き場所だけ先に動かして、考え方には手を付けません。変えるものを1つに絞る進め方は、社内の仕組みを入れ替えるときにもよく使われます。
試している途中の人なら、第1段階で止めておくのも十分ありだと思います。
ただ、第3段階のAgentCore harnessは説明だけで、手を動かす部分は残されたまま。ここまで組み上がるサンプルが公開されるかどうかを見ておきたいです。
LangGraphなどで本番向けエージェントを運用する開発チームに関係します。
