11月10日、AWS公式ブログが「Pluggable Agentic AI Framework: A seven-layer composable enterprise agentic AI reference architecture on Amazon Bedrock AgentCore」と題した記事を公開した。この記事では、マルチエージェントAIアプリケーションをプロトタイプから本番スケールへ引き上げるための7層コンポーザブル参照アーキテクチャについて詳しく紹介されている。
「PoC止まり」問題の核心、そしてオーケストレーション層という答え
「AIエージェントを本番で大規模に動かすにはどうすればいいか？」——この問いにPoC（概念実証）は何も答えてくれない。PoCはモデルがタスクをこなせることを示すためのものであり、本番トラフィック・コスト・セキュリティレビューに耐えることを前提に作られていないからだ。
問題はモデルの性能ではない。チームごとに独自のルーティングロジック、ガードレール、オブザーバビリティを一から構築し直してしまうことにある。AWSはこのギャップを埋めるために、7層コンポーザブル参照アーキテクチャ「Pluggable Agentic AI Framework」を公開した。
7層のうち、設計上の肝となるのがOrchestration（オーケストレーション）層だ。「何でもこなす1つの万能エージェント」を作ることへの警告がこのフレームワーク全体の出発点であり、後述するスーパーバイザー／スペシャリスト分離の思想がPoC止まり問題への直接的な回答となっている。
7層アーキテクチャの全体像
各層は明確な責務と安定したインターフェース契約（コントラクト）を持つ。技術選択は固定ではなく、既存インフラに合わせて差し替え可能な設計になっている。
1. Data and Knowledge（データ・知識層）
エージェントの品質はアクセスできるデータの質に直結する。クエリを受け取り、最も関連性の高い情報をコンテキストとして返すことが責務だ。Amazon Bedrock Knowledge Base、Amazon OpenSearch Serverless（Vector Engine）、Amazon DynamoDB が構成要素として示されている。
また、Amazon S3 Vectorsもこの層のコンポーネントとして挙げられている。S3 Vectorsは、Amazon S3上でベクトルデータを直接格納・検索できるAWSの新機能であり、別途ベクトルDBを立てることなくRAG（検索拡張生成）パイプラインを構成できる点が特徴だ。
2. Model and Inference（モデル・推論層）
モデル選択はハードコードしない。単純なタスクには小さく高速なモデル、複雑な推論には大規模モデルを使い分ける。**LiteLLM** のようなプロキシで共通インターフェースを提供し、プロバイダーを切り替えてもアプリケーションロジックの書き換えが不要になる。
3. Orchestration（オーケストレーション層）——最重要
この層が設計の肝だ。AWSは以下を明確に推奨している：
- 単純なタスク：シングルエージェントで完結させる
- 複雑なクロスドメインワークフロー：スーパーバイザーエージェントが専門エージェント（スペシャリスト）に委譲する
「何でもこなす1つのエージェントを作ってはいけない。ツール、指示、コンテキストが蓄積するにつれてコンテキストウィンドウが膨張し、レイテンシが増加し、精度が低下する。ツールの肥大化は、エージェントを意図した境界を超えて動かし、意図しないアクションやセキュリティ侵害を招く」
スペシャリストエージェントはスーパーバイザーから切り離し、MCP（Model Context Protocol）やA2A（Agent to Agent）などの標準プロトコルで通信させる。また、全エージェントのツール・スキル・オーナーを管理する集中型エージェントレジストリを維持することで、ガバナンスと再利用性を確保できる。実装候補としてStrands Agents、Amazon Bedrock AgentCore、AWS Agent Registryが挙げられている。
4. Security and Guardrails（セキュリティ・ガードレール層）
AIエージェント特有のリスク——プロンプトインジェクション、ツール悪用、メモリへのデータポイズニング——は従来のセキュリティフレームワークで対処できない。外部コンテンツはすべてデフォルトで「信頼しない」扱いにする。
具体的な対策として以下が示されている：
- 永続的な秘密情報の代わりに一時的・スコープ付きの認証情報をエージェントに付与
- PHI（医療情報）・PII（個人識別情報）をエージェントのリクエスト・レスポンス内でマスク
- 重大なアクションは人間の承認ゲートを通過させる
- 異常な動作を検知した時点で即座に停止するサーキットブレーカーを実装
Amazon Bedrock Guardrails、Amazon Bedrock AgentCore Identity and Policyが推奨コンポーネントだ。
5. Application（アプリケーション層）
チャットUI、API、埋め込みウィジェットなど、エンドユーザー体験が存在する層。意図的に薄く保つことが原則であり、ビジネスロジックをここに埋め込まない。リクエストのスコープ判定・人間へのエスカレーション要否を1回のAPIコールで確率として返す「決定モデル」をこの境界に置くと、フルのエージェントループを本当に必要な場合にのみ実行できる。
6. Observability（オブザーバビリティ層）
インシデント発生後ではなく、初日から全層を監視する。エンドツーエンドのエージェントトレース、コスト・トークン使用量、TTFT（Time to First Token）をリクエスト単位で収集する。推奨ツールはAmazon CloudWatch + OpenTelemetryに加え、Amazon CloudWatch Omniが挙げられている。CloudWatch Omniは複数のオブザーバビリティデータソースを統合的に照会できるAWSの新サービスであり、エージェントのトレース・メトリクス・ログを横断的に分析する際に活用できる。
7. Agentic Operations（エージェント運用層）
本番セッションを継続的に評価し、根拠性・精度・安全性をスコアリングする。リグレッションゲートを設け、品質低下をユーザーに届く前に検出する。Amazon Bedrock AgentCore EvaluationsとAgentCore Optimizationが対応コンポーネントだ。
参照実装：小売カスタマーサポートエージェント
アーキテクチャを具体化するため、注文状況と返金可否を扱う小売カスタマーサポートシナリオの参照実装が用意されている。
フローはこうだ。スーパーバイザーエージェントが返金リクエストを受け取り、Orderエージェント（DynamoDBから配送・購入詳細を取得）とRefundエージェント（ナレッジベースからティア別ポリシーを取得し、配送日・現在日・ロイヤルティティアで返金可否を算出）に委譲する。全ツール呼び出しはAgentCore Gatewayを通じてアクセス制御され、エンドツーエンドでトレースされる。サンプルリポジトリは公開されており、ドメインロジックを差し替えて自チームのユースケースに適用できる。
「プラガビリティ」が本質
7層に分離することよりも、各層が独立して進化できることがこのフレームワークの価値の核心だ。層境界に安定したコントラクトを設けることで、基盤技術を入れ替えてもスタック全体の再設計が不要になる。モデルは変わる。ツールは進化する。ビジネス要件もシフトする。その変化を「再構築」ではなく「差し替え」で吸収できる設計にすることがゴールだ。
詳細はPluggable Agentic AI Framework: A seven-layer composable enterprise agentic AI reference architecture on Amazon Bedrock AgentCoreを参照していただきたい。
