AWS、マルチモデルエージェントのAgentCore移行手順を公開

AWSは機械学習ブログで、マルチモデル構成のAIエージェントを「Amazon Bedrock AgentCore runtime」へ移行する方法を解説した。題材は、以前の記事でAmazon ECSとAWS Fargate上に構築した医療向けAIエージェントだ。コンテナのオーケストレーションやスケーリング、ID、可観測性を利用者が自分で設定していた構成を、エージェントのロジックを保ったままマネージド環境へ移す。

AgentCoreは、任意のフレームワークやモデルでエージェントを構築・接続・最適化するための基盤で、runtimeはそのデプロイ機能にあたる。コンテナのライフサイクル、スケーリング、ID、可観測性を肩代わりする。移行ではエージェントのコードをAgentCore runtimeのデコレーターで包み、AgentCore CLIでデプロイする。既存のエージェントを特定のフレームワークに書き換えずに持ち込める「BYOエージェント」方式で、今回はオープンソースのPythonライブラリHugging Face smolagentsを参照実装として使っている。

エージェントは一つのコンテナの中で三つのモデルバックエンドを使い分ける。Amazon SageMaker AI上のBioM-ELECTRA-Large-SQuAD2は専門的な生物医学の質問、Amazon Bedrock上のMetaのLlama 3.1 70B Instructは幅広い医学的推論を担う。これに、BioM-ELECTRAをセルフホストするコンテナ型モデルサーバーが加わる。Amazon OpenSearch Serviceによるベクトル検索で医療知識を補い、アクセス制御はIAMで行う。Hugging FaceのMessages API互換の形式にそろえることで、どのバックエンドを選んでもリクエストとレスポンスの形は変わらない。

前回の記事ではAnthropicのClaude 3.5 Sonnet V2を使っていたが、今回はLlama 3.1 70Bに差し替えた。AWSは、AgentCore runtimeが特定のモデルに依存しないことを示すためだと説明している。なお、これはデモ用のサンプルで、医療のような機微な質問を扱う本番環境では、Amazon Bedrock Guardrailsによるコンテンツフィルタリングと根拠の検証を標準の対策として使うよう求めている。

エージェント開発では、推論ロジックよりもインフラの運用に時間を取られがちだ。既存のコードを大きく変えずにマネージド環境へ移せる道筋が具体的に示されたことで、自前運用とマネージド運用を比べて判断しやすくなる。