9月18日、AWSが「A shared agentic platform for Wood Mackenzie, on Amazon Bedrock AgentCore」と題した記事を公開した。この記事では、エネルギー情報企業Wood MackenzieがAmazon Bedrock AgentCore上に構築した共有エージェント基盤「APEX」のアーキテクチャと設計思想について詳しく紹介されている。
「PoC止まり88%」という現実
エージェントのプロトタイプを動かすのは簡単だ。問題はその先にある。Wood Mackenzie社内の調査によれば、AIのPoC（概念実証）のうち88%が本番展開に至らない。元記事ではForresterの分析も引用されており、エージェント失敗の主因はモデルの性能ではなく、評価・可観測性の欠如、ガバナンス、そして各チームが認証・ガードレール・メモリ・トレースを毎回作り直すという「インフラの重複」だとされている。
Wood Mackenzieも同じ壁に直面した。Woody（社内向けAIアシスタント）、Lens AI（外部向け製品）、ST Trading Appの3チームがそれぞれ独自のエージェントスタックを構築しようとしていた。放置すれば、同じインフラコストを3回払い、メモリもツールも評価基盤も共有できない3つのサイロが生まれる。
この問題を解決するために構築されたのがAPEX（Agentic Platform for Energy eXperience）だ。
なぜAgentCoreを選んだか
APEXの基盤としてAmazon Bedrock AgentCoreを採用するにあたり、Wood MackenzieはLangChain、CrewAI、n8n、フロンティアモデル直接利用などと比較評価を行った。元記事に掲載された比較をもとに整理すると以下のとおりだ。
※編集部の考察：以下の表は元記事の比較評価の記述を編集部が表形式に整理したものだ。
| フレームワーク | ホスティング | モデル非依存 | スケーラビリティ | ガバナンス |
|---|---|---|---|---|
| LangChain | セルフホスト | ○ | 手動 | DIY |
| CrewAI | セルフホスト/クラウド | ○ | 限定的 | 基本的 |
| n8n | セルフホスト/クラウド | × | 中程度 | ワークフロー |
| Bedrock AgentCore | AWSマネージド | ○ | 自動スケール | ネイティブ |
決め手となった5つの要素は以下のとおりだ。
- マネージドインフラ: クラスター運用不要。AgentCoreはVPC、PrivateLink、CloudFormation対応を備える。
- 真のモデル非依存性: Claude、GPT-4.1、Amazon Nova、Mistral、Llamaを単一プラットフォームから利用可能。モデルを切り替えてもビジネスロジックの変更は不要で、会話コンテキストも失われない。
- 自動スケーリング: ゼロから数千の同時エージェント起動まで対応。セッション分離を維持しつつ、最大8時間の実行ウィンドウをサポートする。
- ネイティブのガードレールとID管理: PII検出やコンテンツフィルタリングは各チームが再実装する必要がない。ポリシーはAWSオープンソースのポリシー言語Cedarで記述され、自然言語ルールを変換できる。
- 課金モデル: 使用量ベースの従量課金で、I/O待機中はCPU料金が発生しない。元記事によれば、エージェントのワークロードは実行時間の30〜70%をモデル応答やツール呼び出しの待機に費やすとされており、事前確保型のコンピューティングと比較してコストが大きく変わる。
APEXのアーキテクチャ
APEXはレイヤー構造で設計されている。
フロントエンド層では、製品チームがエージェント機能をUIに組み込むためのSDKを提供する。Woody、Lens AI、ST Trading Appの3アプリケーションが同一のSDKを使う。
バックエンド層はAgentCoreの各機能で構成される。
- AgentCore Identity: OktaをIdPとして使い、エージェント呼び出しのたびにユーザーの権限を引き継ぐ。エッジで一度チェックするだけでなく、すべてのダウンストリームのツール・データ呼び出しに権限が伝播する。
- Orchestrator + Woodmac Agent Registry: 組織横断でエージェント・ツール・スキルを発見・再利用するためのレジストリ。承認ワークフローも内包し、あるチームのエージェントをコピーなしで他チームが利用できる。
- AgentCore Runtime: サーバーレスかつセッション分離された環境でエージェントコードを実行。Strands Agents、LangGraph、CrewAI、n8n、Vertex、OpenAIなど各チームが選んだフレームワークをそのまま動かせる。
- AgentCore Gateway: API、AWS Lambda関数、既存のMCPサーバーをエージェント対応ツールに変換する単一エンドポイント。IAM、OAuth 2.1、APIキー認証をサポート。Wood MackenzieではCode Interpreter（安全なコード実行）とAmazon Nova Actウェブツール（ブラウザ操作）を利用している。
- AgentCore Memory: 短期・長期コンテキストを管理し、セッションをまたいだ会話の継続と、エージェント間の状態共有を実現する。
- AgentCore Observability: OpenTelemetry互換形式でAmazon CloudWatchにテレメトリを送出。セッション数、レイテンシ、トークン使用量、エラー率を単一リクエストからスパンレベルまで追跡できる。
インフラ管理はAWS CDKとGitHubを使ったIaCフレームワークで行い、ガードレールもコードとして定義する。
APEX Studio：チームへの「制御プレーン」
APEXのランタイムを操作するUIがAPEX Studioだ。チームがインフラに触れることなく、エージェントのビルドから本番デプロイ、モニタリングまでを一画面で行える。
主要機能は6つ。
- Agent Builder: テンプレート駆動のエージェント作成。ペルソナ、ツール、ガードレールを設定するだけで動く。
- Workflow Designer: 分岐・ループ・Human-in-the-loopステップを含む多段階オーケストレーションをビジュアルで構成。
- Connector Registry: MCP対応データコネクターのブラウズ・設定・公開を管理。
- Live Chat Testing: 本番デプロイ前にリアルタイムでエージェントを検証する。
- App Deployment: ビルドから本番ローンチまでのライフサイクル管理。
- Monitoring Dashboard: エージェントの健全性、コスト、レイテンシ、精度メトリクスを表示。
内部向けと外部向けを同一インフラで、評価基盤が本番化の鍵
APEXが対応するアプリケーションのうち、Woodyは社内向け、Lens AIは外部の顧客向けという性質の違いがある。両者を同一インフラで動かしながら、IDベースのエンタイトルメント（権限付与）によってデータアクセスを制御している点がアーキテクチャ上の要点だ。セキュリティ境界をチームごとに個別実装するのではなく、AgentCore Identityを通じてプラットフォームレベルで一元管理することで、内部・外部の双方を同一の運用フローに乗せられる。
評価とガバナンスについても、AgentCore Evaluationsを使い、実トラフィックに対してエージェントを「役立ち度」「ツール選択精度」「回答精度」などの軸でスコアリングできる。非決定論的なエージェントの問題は「動くかどうか」ではなく「いつ壊れるかを検知できるか」であり、この評価基盤こそがPoC止まりを防ぐ実装上の核心だとされている。冒頭で挙げた88%という数字が示す失敗の多くは、モデルの限界ではなくこうした観測・評価の仕組みを持たないまま本番化を試みた結果だという点で、APEXの設計はその問題に正面から答える構造になっている。
詳細はA shared agentic platform for Wood Mackenzie, on Amazon Bedrock AgentCoreを参照していただきたい。
