10月29日、AWSのMachine Learningブログが「Building an Agentic AI Platform on Amazon Bedrock AgentCore」と題した記事を公開した。この記事では、Amazon Bedrock AgentCoreを基盤としたマルチアカウント対応のエンタープライズ向けアジェンティックAIプラットフォームのアーキテクチャと実装パターンについて詳しく紹介されている。
エージェントを本番に持ち込む際の障壁
AIエージェントの開発において、モデルの選定やツール呼び出しの実装はもはや主たる難所ではない。本番環境への持ち込みを阻む主要な壁の一つは、それらを取り巻く「ガバナンス」と「運用の仕組み」だ。
複数チームが安全な環境で開発できるか、どのチームがどのモデル・ツールを所有するか、コストと稼働状況を複数アカウントにまたがって把握できるか——こうした課題が積み重なって、プラットフォームとしての設計・運用が必要になる。
本記事が紹介するのは、このプラットフォームをAWSのAmazon Bedrock AgentCore上に構築するためのリファレンスアーキテクチャとブループリントだ。
フェデレーテッドモデルという選択
エンタープライズ向けアジェンティックAIの運用モデルには、大きく3つのパターンがある。
- 集中型（Centralized）: 中央のAI/MLチームが全エージェントを構築・運用。ガバナンスは一貫するが、ユースケースが増えるとボトルネックになる。
- 分散型（Decentralized）: 各ビジネスユニットが独自にエージェントを構築。スピードは出るが、統制が崩れ、コスト可視性が失われやすい。
- フェデレーテッド型（Federated）: 中央のプラットフォームチームが共有サービスを提供しつつ、ドメインチームがエージェントとツールの所有権を持つ。
このブループリントはフェデレーテッドモデルを採用する。プラットフォームチームがテンプレート・バージョン・ポリシーを定義し、各ワークストリーム（Workstream）チームはそれを消費する形だ。
アーキテクチャの核：4つのプレーン
アーキテクチャは開発者体験・プラットフォーム制御・ワークストリーム実行・保証と運用の4つのプレーンで構成される。それぞれの役割を順に説明する。
1. 開発者体験プレーン
ワークストリームチームがエージェントを開発・デプロイするための「ゴールデンパス」を提供するプレーンだ。プラットフォームチームが公開するバージョン管理済みのエージェントテンプレートカタログを通じて、開発者はフレームワーク（Strands、LangGraph、CrewAI）ごとのリファレンス実装をそのまま出発点にできる。インフラ構成やポリシーの詳細を個別に把握しなくても、承認済みの構成から始められる点がポイントだ。
2. アジェンティックAIプラットフォーム制御プレーン
プラットフォームアカウントが管理する中枢。具体的には次の機能を持つ。
- バージョン管理されたエージェントテンプレートのカタログ公開
- AWS Agent Registryによるガバナンス記録の管理
- 共有推論ゲートウェイ（Inference Gateway）の運用——エージェントはモデルプロバイダーに直接アクセスできず、必ずこのゲートウェイを経由する
- Amazon Bedrock Guardrailsの適用と、ワークストリームごとのレート制限・トークンクォータ・予算の強制
- フリートシグナルの集約
3. 繰り返し可能なワークストリームセル
各プロダクト・ドメインが独立した「セル」として分離される。1つのセルは他のチームのリリースと協調することなく、デプロイ・障害・ロールバック・廃止を完結できる。
各セルが持つコンポーネント：
- チーム所有のソースリポジトリとワークロードパイプライン
- AgentCore Runtime（エージェント実行環境）
- AgentCore Memory（アクタースコープのメモリ）
- AgentCore Gateway（AWS_IAM認証を使用し、承認済みツールターゲットのみを公開するMCPゲートウェイ）
- カスタマー管理のAWS KMSキー、アラーム、予算、CloudWatch OAMソースリンク
4. 保証と運用プレーン
エージェントが本番で安全に稼働し続けることを担保するプレーンだ。評価パイプラインによる昇格ゲートの管理、CloudWatch OAMシンクを通じた複数アカウントにまたがる集中観測性の確保、そして廃止時のリソース残存ゼロの検証がこのプレーンの責務となる。プラットフォームチームはここで収集したフリートシグナルをもとに、テンプレートの改訂やポリシーの調整を行う。
マルチアカウント構成とSCP
アカウント構成は以下のレイヤーに分かれる。
| 役割 | 目的 |
|---|---|
| 管理・ガバナンス基盤 | AWS Organizations、IAM Identity Center、予防的ポリシー |
| セキュリティ・監査・可観測性 | CloudTrail、Config、Security Hub、GuardDuty、CloudWatch OAMシンク |
| プラットフォーム | ゴールデンパス、ガードレール、推論ゲートウェイ、パイプライン |
| ワークストリームフリート | チーム所有のRuntime・Memory・Tool Gateway |
サービスコントロールポリシー（SCP）による強制が設計の核心の一つだ。具体的には：
- モデルとリージョンの許可制: 推論は承認済みモデルと対応リージョンに限定。新規追加にはIAM、品質、コスト、可用性、ロールバック、観測性の検証が必要。
- パイプライン経由のみの変更: ワークストリームチームはプルリクエストを開いてワークロードパイプラインを使う。開発者が直接インフラに書き込むパスは遮断される。
- 職務分離: プラットフォームがモデル・ガードレール・レジストリへのアクセスを管理し、ワークストリームはアプリケーション動作を管理する。ワークストリームアカウント内の管理者であっても、これらの制御を迂回できない。
評価ゲートによるリリース管理
ブループリントは評価パイプラインを組み込んでおり、エージェントが本番に昇格する前に以下の境界ごとの証拠を要求する。
- モデルアクセス: 承認済みモデルへの呼び出しが成功し、未承認モデルへの呼び出しが拒否されること
- ツールアクセス: 購読済みツールの呼び出しが成功し、購読外ツールへの呼び出しが期待通りのエラーで拒否されること
- アイデンティティ: 別ワークストリームのアカウントや認証情報からのリクエストが拒否されること
- リリース: 前バージョンのエージェントランタイムを復元できること
- 廃止: 依存関係の順序でRuntime・Memory・Tool Gateway・ツール許可が削除され、残存リソースがないことを確認すること
実装の出発点
ブループリントはGitHubで公開されており、まず1つの代表的なセルから始めて、オンボーディング・本番昇格・ロールバック・集中観測性・ゼロ残存の廃止を確認してからベースラインを繰り返すことを推奨している。既存のAWS Control Towerランディングゾーンに統合できる構成になっており、固定の3アカウント構成を新たに組む必要はない。
詳細はBuilding an Agentic AI Platform on Amazon Bedrock AgentCoreを参照していただきたい。
