Wood Mackenzie、Amazon Bedrock AgentCore上に共有エージェント基盤を構築
Wood Mackenzieは、運用環境のAIエージェント向けにID、ランタイム、可観測性、ガードレールを標準化するため、Amazon Bedrock AgentCore上にAPEXを構築しました。
Wood Mackenzieは、APEXと呼ばれる共有型のエージェントAIプラットフォームをAmazon Bedrock AgentCore上に構築し、各アプリケーションごとにランタイム、ID管理、可観測性、保護策を作り直すのではなく、運用環境のエージェントを展開するための共通基盤をチームに提供している。
AWSが公開した同社の事例では、APEXがWoody、Lens AI、ST Trading Appの3つのアプリケーションを支えていると説明されている。このアーキテクチャは、標準化された運用レイヤーを利用しながら、製品チームが異なるエージェントフレームワークやモデルを選べるように設計されている。これはエンタープライズAIの中心的な課題に対応するものだ。つまり、プロトタイプは素早く作れても、非決定的なシステムをユーザー、ツール、データをまたいで安全に運用するのははるかに難しい。
同じAWSブログ群では、Abnormal AIがメールセキュリティシステムでAgentCore Code Interpreterを使っていることも紹介されている。これらの事例を合わせると、AWSがAgentCoreを単なる開発サービスではなく、隔離、ポリシー適用、実運用ワークフローでの制御された計算アクセスを必要とするエージェント向けインフラとして位置付けていることが分かる。
Wood Mackenzieのエージェント向け共通基盤
Wood Mackenzieによれば、APEX以前はWoody、Lens AI、ST Trading Appがそれぞれ独自のエージェントスタックを開発していた。このやり方では、認証、スケーリング、トレース、モデルアクセス、ガードレールを個別に実装する必要があった。さらに、チーム間でツール、メモリ、評価手法を共有しにくくなっていた。
APEXはこれらの機能を集約する。バックエンドはAmazon Bedrock AgentCore Runtime、Identity、Gateway、Memory、Observabilityに加え、オーケストレーター、検索基盤、Amazon Bedrockモデルカタログ経由のモデルアクセス、Amazon Bedrock Guardrailsを利用している。フロントエンドのソフトウェア開発キットが、プラットフォームとユーザー向けアプリケーションをつないでいる。
この設計では、すべてのチームが同じエージェントフレームワークを使う必要はない。Wood Mackenzieは、Strands Agents、LangGraph、CrewAI、n8n、Vertex、OpenAIのエージェントツールを環境でサポートできるとしている。AgentCoreはModel Context Protocol（MCP）とAgent-to-Agentプロトコルもサポートしており、外部システムやエージェントが単発の統合ではなく標準化されたインターフェースを通じて接続できる。
この柔軟性は、プラットフォームの魅力の重要な部分だ。Wood Mackenzieによれば、チームはアプリケーションロジックを書き直さずにモデルを切り替えたり、計画用と実行用で別のモデルを使ったり、プロバイダー間で価格と性能を比較したりできる。同社はClaude、GPT-4.1、Amazon Nova、Mistral、Llamaをプラットフォーム経由で利用可能なモデルとして挙げているが、投稿ではモデル品質や切り替えコストの独立測定は示していない。
ID管理と運用がプラットフォーム層に移行する
APEXでは、認可をユーザーがアプリに入る時だけのチェックではなく、各エージェント呼び出しの属性として扱っている。Wood Mackenzieによると、AgentCore Identityはユーザーの権限を下流のツール呼び出しやデータ呼び出しに引き継ぎ、エージェントがユーザーの代理として、あるいは別途定義されたアクセス制御の下で動作できるようにする。同社はOktaをIDプロバイダーの信頼できるソースとして使用している。
また、プラットフォームにはWoodmac Agent Registryも含まれ、チームはガバナンスと承認ワークフローの対象となるエージェント、ツール、スキルを発見し再利用できる。このレジストリは、既存の機能を共有できるのにコードを複製してしまうことを防ぐことを目的としている。
AWSはAgentCore Runtimeを、セッション分離されたサーバーレス環境であり、ゼロから同時数千件の呼び出しまでスケールでき、実行時間は最大8時間まで対応すると説明している。AWSによれば、AgentCoreサービスは、2025年10月の一般提供開始後に、Amazon Virtual Private Cloud、AWS PrivateLink、CloudFormation、リソースタグ付けなどの機能もサポートする。
コスト管理については、このサービスは事前のコミットメントや最低料金のない従量課金を採用している。AWSは、ランタイムの課金は秒単位のアクティブなCPUとメモリの使用量に基づき、入出力待機中のCPU料金は除外されるとしている。同社は、エージェントのワークフローは時間の30%から70%をモデル応答、ツール、データベース待ちに費やすことがあり、この課金モデルは、プロビジョニングされた計算資源を遊休させがちなワークロードに関連性が高いと述べている。
証拠は詳細だが、ベンダー管理下にある
この話で最も強い主張は、独立監査ではなくAWSとWood Mackenzieによるものだ。Wood Mackenzieは社内で、AIの概念実証の88%が広範な展開に至らないと報告している。また、同記事は業界調査やForresterの研究を引用して、評価、可観測性、ガバナンス、ID管理がエージェント拡張の大きな障壁だと論じているが、より広範な統計を独立して評価できるほどの出典情報は記事内にない。
アーキテクチャ自体は、認証からオーケストレーション、ランタイム、モデルアクセス、ツール呼び出しまでのリクエスト経路を含め、実務的な観点で説明されている。しかし、APEXの本番トラフィック、エージェント数、レイテンシ、エラー率、運用コスト、測定可能なビジネス成果は開示されていない。したがって、読者はこの事例を実装の参考例およびベンダー後援のケーススタディとして見るべきであり、AgentCoreが別の企業でも同じ結果を生む証拠とは考えるべきではない。
Abnormal AIの事例は、別の規模の主張を示している。AWSによれば、Abnormal AIはAgentCore Code Interpreterを、数十億件のメッセージに対するリアルタイムのメール脅威検知に関わるエージェントで使用しており、より広い検知システムでは難しいケースにのみ、段階的により高コストな分析を適用している。AWSはさらに、Fortune 500の25%以上がAbnormal AIを使用しており、同社のコード変更の80%が何らかの形でエージェントを含むと報告している。これらは会社またはベンダーの報告値であり、記事は独立検証を提示していない。
Code Interpreterは、AgentCoreの物語に別の能力を加える。エージェントがPythonやNode.jsコードを実行し、ファイルを処理し、計算を行い、出力を作成し、生成された作業を検証できる一時的なMicroVMサンドボックスを提供する。AWSによれば、セッションは15分から8時間まで継続でき、パブリックネットワークまたはVPCモードをサポートし、CloudWatchとCloudTrail経由でログを提供する。Abnormal AIのユースケースは、エージェントが言語モデルの推論だけに頼るのではなく、制御された実行環境を必要とする理由を示している。
このプラットフォームがビルダーと企業にもたらす意味
AIビルダーにとって最大の変化は、エンジニアリングの労力をどこに割くかが変わることだ。チームは、共通プラットフォームが反復的なインフラ面を扱う間、ドメインのワークフロー、検索品質、ツール設計、評価に集中できる。これにより、成功したデモから、複数ユーザーや同時セッションを支えるサービスへの移行が短縮される可能性がある。
一方で、中央のプラットフォームチームへのアーキテクチャ依存という代償がある。共有レジストリ、共通ポリシー層、標準化された可観測性は重複を減らせるが、オンボーディング、承認、フレームワーク対応が遅ければボトルネックにもなり得る。Wood Mackenzieがフレームワークとモデルの選択肢を維持する決定はこのリスクを下げるが、慎重なインターフェース設計とプラットフォームガバナンスの必要性をなくすものではない。
企業にとっては、長いモデル一覧よりも、IDの伝播とセッション分離の方が重要だ。社内ツールを呼び出せるエージェントには、ワークフロー全体で理解可能で取り消し可能な権限が必要になる。AgentCore Identity、Gatewayポリシー、Cedarベースのルールはその要件に対応することを目的としているが、組織は珍しいプロンプト、連鎖したツール呼び出し、部分的な障害に対するポリシー動作を引き続きテストする必要がある。
Abnormal AIの導入は、エージェントシステムにおける段階的コストモデルも裏付けている。軽量なルールと分類器が大量処理のケースを扱い、より高コストなエージェントやコード実行は不確実または複雑なケースに限定される。このパターンは、特にレイテンシと1操作あたりのコストが重要な場面では、すべてのタスクを大規模モデルに送るより実用的かもしれない。
今後注目すべき点
次に重要なシグナルは、宣伝的なものではなく運用面のものになる。Wood MackenzieのAPEXは、アプリケーション全体での採用状況、エージェント失敗率、評価カバレッジ、レイテンシ、ポリシー違反、ワークフローあたりのコストに関する公開データがあれば、より評価しやすくなる。
ビルダーはまた、チームが孤立した実験から共有ツールやマルチエージェントのワークフローへ移行する中で、AgentCoreのフレームワークおよびモデル非依存性が引き続き実用的かを注視すべきだ。MCPとAgent-to-Agent接続のサポートは再利用を広げる一方で、プラットフォームチームが監視しなければならない信頼境界の数を増やす可能性もある。
企業の買い手にとって重要なのは、独立した顧客事例、継続的な同時実行時のより明確な料金、インシデント対応制御、そして接続されたアプリケーションを妨げずにエージェントを無効化またはロールバックできる証拠だ。Code Interpreterの導入では、データ保持、ネットワークアクセス、パッケージ制御、生成コードの隔離について追加の精査が必要になる。
Creati.aiの視点
Wood MackenzieのAPEXが注目されるのは、別のエージェントアプリを導入したからではなく、不足していた運用レイヤーを再利用可能な製品として扱っている点にある。同社の事例は、エンタープライズチームが、ID、ランタイム挙動、可観測性、ポリシーを標準化する社内エージェントプラットフォームへ向かっており、事業部門には独自のモデルやフレームワークを選ぶ余地を残していることを示している。
証拠は依然としてベンダー管理下にあり、APEXを実証済みのひな形として確立する性能データや財務データは開示されていない。それでも、このアーキテクチャはエンタープライズAIに向けた実用的な方向性を示している。エージェント導入の成否は、次の印象的なプロトタイプを作ることよりも、権限、評価、隔離、コストを日々運用できるほど可視化することに左右される可能性が高い。
