「AIエージェントを本番環境で大規模にどう運用すればよいのか？」これは最終的にすべての顧客が抱く疑問です。この疑問にはいくつかの質問が付随してきます。何千もの同時ユーザーリクエストを安全かつ確実に処理するにはどうすればよいのか？実際のトラフィックの下でエージェントが静かに失敗するのではなく、確実に信頼性を維持するにはどうすればよいのか？エージェントがテスト時に合格した品質と安全性の基準を依然として満しているかどうかをどう知るのか？エージェントのセキュリティのベストプラクティスとは何か？それは決定論的であるべきか非決定論的であるべきか？その他多くの疑問です。概念実証（PoC）はこれらのいずれにも答えません。なぜなら、PoCはエージェントモデルがタスクを実行できることを示すために構築されており、本番トラフィック、コスト圧力、セキュリティレビューに耐えるようには作られていないからです。
動作するプロトタイプと、大規模に信頼性高く、安全に、経済的に、かつ責任を持って動作するシステムとの間のこのギャップは、ほとんどのエージェントAIの取り組みが停滞する場所であり、それはめったにモデルのせいではありません。エージェントを構築するすべてのチームは、同じ足場（スキャフォールディング）をゼロから再構築する傾向があります。独自のルーティングロジック、独自のガードレール、独自のオブザーバビリティが、最初から組み込まれるのではなく、後から適用されるのです。チームには、すべてのエージェントがその上に構築できる、共有された本番対応のアーキテクチャが必要です。
この記事では、マルチエージェントAIアプリケーションをプロトタイプから本番規模へと移行させるために設計された、7 層コンポーザブルなリファレンスアーキテクチャについて解説します。
コンポーザブルアーキテクチャ
Pluggable Agentic AI Framework は、マルチエージェントアプリケーションのためのリファレンスアーキテクチャであり、次のように構成されています。 7 つのレイヤーはそれぞれ異なる責任と安定したコントラクトを持ちます。各レイヤーに示されているサービスや技術はリファレンス実装を反映したものであり、必須の選択ではありません。組織は、既存のインフラストラクチャと要件に適合する代替手段に置き換えることができます。これらのレイヤーを組み合わせることで、本番規模でエージェントAIアプリケーションを構築、保護、運用するための設計図が得られます。
図 1：Pluggable Agentic AI Framework の 7 つのレイヤー
データとナレッジ はエージェントAIの基盤です。エージェントの性能は、アクセスできる データ に左右されます。エージェントが医療処方集を確認する場合、在庫を追跡する場合、コンプライアンス規則を解釈する場合のいずれであっても、正しく回答するには関連性のある最新の情報が必要です。このレイヤーは、明確なコントラクトとプロトコルを通じて、検索、埋め込み、構造化データおよび非構造化データへのアクセスを担当します。つまり、クエリを受け取り、エージェントのコンテキストとして機能する最も関連性の高い情報を返します。 Amazon Bedrock Knowledge Base, Vector Engine for Amazon OpenSearch Serverless, Amazon S3 Vectors 、そして Amazon DynamoDB は、この基盤のための構成要素の例です。
モデルと推論 の選択は、エージェントやアプリケーションロジックにハードコードするのではなく、設定によって駆動されるべきです。単純なタスクにはより小さく高速なモデルを使用し、より繊細な推論を必要とするリクエストにはより大きなモデルを使用します。構築しているユースケースについて、現実的で代表的なビジネスデータを用いて徹底的なモデル評価を行うことが重要です。モデルルーティング層は、一貫したリクエスト・レスポンスのコントラクトに依存することで、AIエージェントをモデルホスティング環境やプロバイダー固有のAPIから分離（デカップリング）し続けます。 LiteLLM のようなプロキシはプロバイダー間で共通のインターフェースを提供するため、アプリケーションロジックを書き直すことなく、評価結果に基づいてモデルを切り替えることができます。
オーケストレーション は作業の分散方法を決定するものであり、適切なアプローチを選択することが重要です。単純なタスクでは、単一のエージェントで作業をエンドツーエンドで処理します。複雑なドメイン横断的なワークフローでは、スーパーバイザーを使って専門エージェントに委譲し、各エージェントを特定の能力にスコープし、特定のツールセットに紐付けます。すべてをこなす1つのエージェントを構築することは避けてください。ツール、指示、コンテキストが蓄積されるにつれて、コンテキストウィンドウが大きくなり、レイテンシーが増加し、精度が低下する可能性があります。ツールの乱立が起こり、エージェントが意図された境界を超えてしまい、意図しない動作やセキュリティ侵害につながる可能性があります。責任を分割することで、各エージェントのコンテキストが集中し、レイテンシーがより予測しやすくなります。また、各エージェントの動作をテストし、スケールさせ、そのセキュリティモデルを独立して定義することもできます。有界の自律性を強制してください。専門エージェントは、付与されたツールの範囲内で厳密に実行し、それ以上のことは行わないようにします。
特定のスペシャリストへ分解して境界を設定することに加え、スペシャリストエージェントをスーパーバイザーエージェントから分離してください。スーパーバイザーが集中型のエージェントレジストリからスペシャリストを検出し、MCP（Model Context Protocol）やA2A（Agent to Agent）のような標準化されたプロトコルを通じてそれらを呼び出せるようにします。すべてのエージェントのツール、スキル、オーナーをカタログ化する集中型エージェントレジストリを維持してください。これにより、組織は大規模なガバナンスに必要な可視性を得られ、再利用性によってAIエージェント実装の速度が向上し、反復的な開発のコストを回避できます。スペシャリストには Strands Agents を、オーケストレーターには Amazon Bedrock AgentCore harness を、集中型のディスカバリーとルーティングには AWS Agent Registry と Amazon Bedrock AgentCore Gateway の使用を検討してください。
セキュリティとガードレール は最優先の関心事であり、初日から設計に組み込む必要があります。エージェンティックAIは、プロンプトインジェクションやツールの誤用から、メモリやデータのポイズニングに至るまで、従来のセキュリティフレームワークでは対応できなかった新しいクラスのリスクに組織をさらします。すべての外部コンテンツをデフォルトで信頼されていないものとして扱ってください。ユーザー、別のエージェント、自動化されたワークフローのいずれから来たものであっても、すべてのリクエストを Amazon Bedrock AgentCore Identityのようなサービスで認証してください。その上で、きめ細かなアクセス制御により、各ツール呼び出しが許可されているかを実行前に判断します。永続的なシークレットの代わりに、一時的かつスコープ限定の認証情報をエージェントに付与してください。データ保護の面では、エージェントおよびツールのリクエストとレスポンスにおいて、PHI（Personal Health Information、個人健康情報）やPII（Personally Identifiable Information、個人識別情報）のような機密データをマスキングし、機密性の高い顧客情報がエージェントの出力に現れたりメモリに残ったりしないようにします。説明責任のためには、重要な意思決定すべてを改ざん検出可能な監査証跡に記録し、高影響のアクションは人間の承認ゲートを経由させ、異常な動作がエスカレートする前に停止させるサーキットブレーカーを導入してください。ユーザー入力には Amazon Bedrock Guardrails を、認証とアクセス制御には Amazon Bedrock AgentCore Identity と Policy in Amazon Bedrock AgentCore の使用を検討し、多層防御のセキュリティを実現するためにAWSのセキュリティおよびガバナンスコントロールを併用してください。
アプリケーション は、チャットインターフェースであれ、APIサーフェスであれ、組み込みウィジェットであれ、エンドユーザー体験が存在する場所です。このレイヤーは意図的に薄く保ってください。その責務は、会話を提示し、リクエストをその下のオーケストレーションレイヤーに渡すことだけであるべきです。ここにビジネスロジックを埋め込もうとする衝動に抵抗してください。分離がきれいであるほど、バックエンドを不安定にすることなくユーザー体験を反復改善しやすくなります。この境界には、高速で低コストのチェックとして意思決定モデルを配置できます。1回の呼び出しで、リクエストがスコープ内か、人間を必要とするか、緊急かをスコアリングし、自由記述テキストの代わりに確率を返します。コードはシンプルなしきい値でそれらのスコアに基づいて動作し、話題外のリクエストには直接回答し、エスカレーションにはフラグを立てるため、完全なエージェンティックループは価値を追加する場合にのみ実行されます。アプリケーションレイヤーを構築する際には、人間に加えて別のAIエージェントがあなたのAIエージェントを利用し相互作用するために何が必要かを考えてください。それに応じて外部インターフェースを構築してください。
オブザーバビリティ は、最初のインシデントの後ではなく、初日からすべてのレイヤーを監視すべきです。ログやメトリクスに加え、エージェントがタスクを正しく実行したかを測定するにはエンドツーエンドのエージェントトレースが不可欠です。トレースに加えて、リクエストごとのコストとトークン使用量、最初のトークンまでの時間、呼び出しが安全かどうかを収集し、本番稼働前にレイテンシー、エラー率、支出のダッシュボードを公開してください。事前のモニタリングは事後の消火活動よりも低コストです。OpenTelemetryと組み合わせた Amazon CloudWatch に加え、トレーシングとメトリクスには Amazon CloudWatch Omni を使用することで、スタック全体の包括的な可視性を得ることを検討してください。
エージェンティックオペレーション は継続的な評価でループを閉じるものなので、初日から設定してください。すべての本番セッションを根拠性、正確性、安全性についてスコアリングし、品質低下が顧客に届く前に捕捉するリグレッションゲートを設置してください。これがなければ、エージェントがローンチ時に動作したことしかわかりません。これがあれば、その後のすべてのリリース後も動作し続けていることを証明できます。スコアリングには Amazon Bedrock AgentCore Evaluations を、最適化には Amazon Bedrock AgentCore optimization 継続的なパフォーマンスチューニングのための。
小売顧客サポートエージェントのリファレンス実装
図2: 小売カスタマーサポートリファレンス実装の機能フロー
このアーキテクチャを具体化するために、フレームワークには、注文状況と返金適格性をカバーする小売カスタマーサポートのシナリオに基づく、すぐに実行できるリファレンス実装が含まれています。このユースケースを選んだのは、スタックのすべてのレイヤーを動かしながらも、チームが理解し、自分のニーズに合わせて適応できるほど直感的であるためです。
スーパーバイザーエージェントが顧客の返金リクエストを受け取り、OrderエージェントとRefundエージェントに委任します。各エージェントは、限定されたツールセットを持つ専門エージェントです。OrderエージェントはAmazon DynamoDBから配送および購入の詳細を照会します。Refundエージェントはナレッジベースからティア別のポリシールールを取得し、配送日、現在日付、顧客のロイヤルティティアを使用して適格性を計算します。これらの呼び出しはすべてAgentCore Gatewayを通過し、Policy in AgentCoreによってツールの実行前にきめ細かなアクセス制御が適用され、すべての呼び出しがオブザーバビリティレイヤーを通じてエンドツーエンドでトレースされます。そのため、計算に問題が発生した場合、トレースによってどのレイヤー、どの判断ポイントが原因かが正確に示されます。
同様のスーパーバイザー・スペシャリストパターンを構築する人は誰でも、リファレンス実装をクローンし、ドメインロジックをレイヤーごとに差し替えることができます。
なぜレイヤーそのものと同じくらいプラグ可能性が重要なのか
7層アーキテクチャの価値は、責任を分離する方法だけでなく、各レイヤーをどれだけ迅速に進化させられるかにもあります。 プラグ可能性 がそれを可能にします。アイデンティティチェックやアクセスポリシーからテレメトリインターフェースまで、レイヤー境界での安定した契約により、スタックの他の部分を再設計することなく、基盤技術を変更できます。本質的には、技術主導のアプローチではなく、アーキテクチャファーストのアプローチでエージェentic AIシステムを構築することです。
フレームワークは、各レイヤーでサードパーティプロバイダーとの統合を通じてプラグ可能性を実証することで、この原則を実践しています。推論レイヤーでのモデルおよびホスティングプロバイダー、オーケストレーションレイヤーでの検索機能、アプリケーションレイヤーでの決定API、セキュリティレイヤーでのガードレール、そしてオブザーバビリティレイヤーでのエージェントトレーシングおよびモニタリングソリューションとビジネス価値およびコストトラッキングです。各レイヤーで業界標準のプロバイダーをサポートしているため、特定の要件を満たすソリューションを構成できます。
企業にとって、この柔軟性は既存の投資を守ります。チームは既に信頼しているオブザーバビリティ、セキュリティ、推論のツールを維持し、必要な箇所のギャップを埋め、新しい機能を段階的に採用できます。このアーキテクチャは、すべての技術決定を同一ベンダーから調達することを求めずに、一貫した基盤を提供します。
まとめ
動作するプロトタイプはエージェントに何ができるかを証明します。優れた設計のアーキテクチャは、企業がそれを信頼できるかどうかを決定します。AIオペレーションへの移行とは、システム構築後に追加するのではなく、初日からセキュリティ、ガバナンス、可視性、コスト管理、信頼性、適応性を設計に組み込むことを意味します。
Pluggable Agentic AI Frameworkは、こうした懸念事項を、明確な原則を持つアーキテクチャにもたらします。それは、すべての技術選択を固定することなく、安定した基盤を構築するという原則です。モデルは変わります。ツールは進化します。ビジネス要件は変化します。アーキテクチャはそれらの変更を管理しやすくするべきであり、それぞれを再構築に変えてはなりません。
この原則を実践しましょう。まず Workshop Studio体験を試し、 公開サンプルリポジトリを調べ、ハンズオン実装を自身のアーキテクチャの出発点として活用してください。これは本番環境のセキュリティ強化、テスト、レビューの代わりにはなりません。
今日必要な機能と、明日必要になる 柔軟性 を構築しましょう。