AWS Professional Servicesは、大規模な企業向けクラウド移行を自動化するために設計されたマルチエージェントシステムの詳細を公表した。Amazon Bedrock AgentCoreを使って、探索、インフラコード生成、ガバナンス、移行後の運用を連携させる仕組みだ。

このシステムは数百のアプリケーションを含む移行プログラムを対象としており、手作業での受け入れやインフラ開発が実際の移行よりも時間を要することがある。AWSによると、社内フレームワークは300以上のアプリケーションにわたって、アプリごとのInfrastructure as Code開発を3〜4週間から数分へと短縮したという。この結果は社内のプロジェクト追跡データに基づくもので、独立した検証はされていない。

この開示が重要なのは、AgentCoreを単なる個別アシスタントのランタイムとしてではなく、評価、デプロイ、運用にまたがるワークフローの制御層として示しているからだ。企業の技術チームにとってより重要な問いは、エージェント型自動化が、影響の大きいインフラ意思決定から人間の承認を外すことなく、再現可能でガバナンスの効いた移行作業を実現できるかどうかである。

専門エージェントに分割された移行ワークフロー

AWSは、AWS Professional ServicesがStrands Agents SDKを用いて構築したフレームワークを説明している。移行全体を1つの汎用モデルに任せるのではなく、より狭い責務を持つエージェントに仕事を分割するアーキテクチャだ。

Intake Agentは、アプリケーションの発見、依存関係のマッピング、ターゲットアーキテクチャの定義を自動化する。続いてIaC Agentが、組織のセキュリティ実践と標準に従ってInfrastructure as Codeを生成する。Migration Intelligence and Governance Agentは、Jira、Confluence、Webexなどのツールを横断して、ポートフォリオレポート、Well-Architected評価、ガバナンス情報を作成する。

デプロイ後には、SRE Agentが移行済みワークロードを監視し、潜在的な劣化を特定し、自動修復を支援する。AWSは、支援付きのスキーマ変換とデータベース切り替えのためのAWS Database Migration Service、旧来アプリケーションのモダナイゼーション向けのAWS Transformなど、特定の移行タスク向けの隣接サービスも挙げている。

この分担は、移行プログラムにおける異なるリスクプロファイルを反映している。探索には、文書や既存システムから事実を抽出する必要がある。コード生成にはインフラ標準への準拠が必要だ。ガバナンスにはポートフォリオ全体の可視性が必要であり、運用にはライブシステムへのアクセスと慎重に制御された修復が必要となる。これらを別々のエージェント役割として扱うことで、1つのエージェントに広範な権限を与えるよりも、権限管理と評価を扱いやすくできる。

Amazon Bedrock AgentCore がシステムにどう組み込まれるか

AWS Machine Learning Blogによると、各エージェントは基盤モデル、システムプロンプト、ツール群によって定義される。Amazon Bedrock AgentCore Runtimeは、セッション分離とマルチエージェントオーケストレーション対応を備えたサーバーレス環境でエージェントをホストする。

エージェントはModel Context Protocolツールを通じて外部機能にアクセスする。AgentCore Gatewayは、API、AWS Lambda関数、既存サービスをMCP互換ツールに変換できるため、フレームワークは各連携を新しいインターフェースに合わせて作り直すことなく、移行エージェントを企業システムにつなげられる。

ID管理はAgentCore Identityが担い、AWSによれば、スコープを限定したAWS Identity and Access Managementロールと組織のIDプロバイダーを使って呼び出しを認証する。これはインフラ自動化において中心的なポイントだ。実務上の安全境界は、モデルの指示だけでなく、各エージェントが技術的に何を読み、変更し、実行できるかによっても決まる。

AWSは、このフレームワークが移行ライフサイクル全体でセキュリティ制御を適用し、意思決定の責任は人間に残すと説明している。ただし、ソースでは内部展開で使われた具体的な承認ゲート、ロールバック機構、評価しきい値は示されていないため、記載のパターンがあらゆる環境で自動的に本番レベルの制御を提供すると考えるべきではない。

パフォーマンス主張を支える証拠

発表で最も強い効率向上の主張は、ベンダーによるものだ。AWSは、300以上のアプリケーションを含むポートフォリオで、アプリごとのIaC開発が3〜4週間から数分に短縮されたのは社内のプロジェクト追跡データによるものだとしている。ブログには、前後比較の完全な方法論、各アプリケーションの複雑性、人的レビューの量、生成されたコードのうち大幅な修正なしで受け入れられた割合は記載されていない。

この違いは重要だ。「数分」は、承認済みでテストされ、安全でデプロイ済みのインフラに至る全工程ではなく、初期生成を指す可能性がある。企業の移行作業では、コード作成が自動化されても、検証、例外処理、ネットワーク判断、データ依存関係、コンプライアンスレビュー、変更管理が依然として大きな負担になる。

利用可能な証拠が示しているのは、AWSが提示しているもの、つまり目的特化型のAIエージェント、企業ツール、AWS移行サービスを組み合わせた実働する社内アーキテクチャである。ただし、業界やアプリケーションポートフォリオをまたいだ一般的に再現可能な時間短縮は、まだ実証されていない。このクラスターの2つ目のソースはAWS管理下のブログであり、提供された配信記事には追加の本文や独立取材は含まれていない。

クラウド移行チームにとっての意味

開発者にとって、このフレームワークはAIエージェントを既存の移行データや運用システムにつなぐための参考パターンを提供する。最も再利用しやすい考え方は、エージェントをライフサイクル段階と権限範囲で分けることだ。探索エージェントは在庫情報やアーキテクチャ文書にアクセスできる一方、インフラエージェントはファイルを生成できても本番デプロイ権限は持たない、といった具合だ。運用エージェントはテレメトリを確認して修復案を提示し、人間またはポリシーエンジンが変更を承認する。

この構造はテストもより具体的にする。チームは依存関係マッピング結果で探索精度を評価し、生成されたIaCをポリシーやセキュリティチェックと照合し、運用エージェントはアラート精度、修復成功率、ロールバック動作で測定できる。これは、モデル応答の速度だけを見るよりも実用的な指標だ。

企業の買い手にとっての主要なトレードオフは、標準作業の高速化と、エージェントアクセスを統制するコストの間にある。AgentCoreのRuntime、Gateway、Identity機能はデプロイと認可の一部をカバーするが、組織には依然として、モデル選定ポリシー、監査記録、環境分離、シークレット管理、人間の承認、標準パターンに合わないアプリケーションを扱うためのプロセスが必要だ。

このアプローチは、期限が固定されたデータセンター退出プログラムで特に有用かもしれない。そこでは、反復的な探索とコード準備が作業の滞留を生みやすい。一方で、極めてカスタム化されたシステム、文書化されていない依存関係、あるいは大幅なアプリケーション再設計を必要とする移行にどこまで有効かは不透明だ。AWS DMSとAWS Transformの採用は、オーケストレーション層があらゆる移行ツールを置き換えるのではなく、汎用エージェントと特化サービスを組み合わせる意図を示している。

今後注目すべき点

次に有用なシグナルは、IaC生成時間だけでなく、移行全体の時間を示す独立した事例研究だ。購入者は、レビュー工数、デプロイ成功率、ロールバック率、セキュリティ上の指摘、カスタム開発なしで処理されたアプリケーションの割合を含む数値を探すべきだ。

このフレームワークの人間による承認ポイントについての詳細が増えれば、運用成熟度もより明確になる。却下または修正されたエージェント出力の例、AgentCore Identityからの監査証跡、自動修復を管理するポリシーがあれば、チームはリスクを判断しやすくなる。

最後に、再利用可能なリファレンス実装、AWSリージョンごとにサポートされるモデル、ブログで挙げられたツール以外の統合がどこまで用意されるかによって、これがAWS Professional Servicesのパターンのままなのか、広く採用可能なプラットフォームアーキテクチャになるのかが見えてくる。移行パートナーによる採用やAWS外の顧客事例は、現時点の社内結果よりも強い市場シグナルになるだろう。

Creati.ai の視点

AWSはAgentCoreを連携型のエンタープライズAIエージェント向けインフラとして位置づけており、クラウド移行は、作業が反復的でありながら専門的判断に依存するため、説得力のある試験例だ。アーキテクチャの価値は、自律的な意思決定よりも、散在する移行タスクを管理可能で検証可能なワークフローへ変換する点にある可能性が高い。

報告された加速は注目に値するが、これは市場全体の成果ではなく社内ベンチマークとして読むべきだ。AIビルダーや企業チームにとっての持続的な教訓は、狭いエージェント責務を厳格なID境界、測定可能なレビューゲート、運用実績と組み合わせ、生成されたインフラや自動修復が本番システムに影響する前に十分な証拠を確保することだ。