データ、モデル、協調、保護、運用などの責任を分離します。特定サービスを必須にせず、差し替え可能な契約と部品で構成する設計です。 試作で動くことと継続運用の信頼性を分けます。権限、観測、評価、変更時の回帰確認を最初から設計することが焦点です。 動く試作から運用できる構成へ AWSは11月9日、Pluggable Agentic AI Frameworkを解説しました。本番で複数のエージェントを運用するための7層の参照構成です。試作ではモデルが課題を解けても、並行する要求、費用、安全性、継続する品質への対応は別に必要です。各チームが経路制御や監視を毎回作る負担を減らすため、責任を分けた共通構成を示しています。原文は登場するサービスを必須の選択とはしていません。既存の基盤や要件に合わせて部品を置き換える前提です。新しい単独のマネージド製品を提供開始する告知ではなく、組織が設計へ使う参照モデルです。小売の顧客支援を例に実装の流れも説明しています。設計の再利用と運用の責任をそろえるための資料です。 モデルと専門エージェントを疎結合にする データと知識を参照する層では、問い合わせと関連情報の返却を明確にします。モデルは設定で選び、アプリ本体へ特定事業者のAPIを固定しない考え方です。協調では単純な仕事を一つのエージェントで処理し、複雑な仕事は監督役と専門役へ分けます。専門役のツールと責任を限定し、登録簿から発見して標準的な方式で呼び出します。安全性では要求を認証し、個々のツール実行前に細かく許可を判定します。機密情報が出力やログへ残ることへの対策も含みます。基盤担当者には、エージェントを再利用しながら所有者と権限を追える仕組みが関係します。モデルを高性能にするだけで解消しない、運用上の責任の配置を整理する内容です。登録情報の更新も管理の対象です。 継続評価と部品交換の条件を決める 参照構成は本番セッションの根拠性、正確さ、安全性を継続して評価し、変更時の品質低下を止める工程を説明しています。導入直後の成功だけで品質を判断しない考え方です。実務では評価指標を持つ担当、費用を管理する担当、問題を止める担当の関係が論点になると見られます。共通部品を増やすと再利用しやすい一方、更新が複数の仕事へ影響する可能性があります。部品ごとの入出力を定義し、変更時に代表的な仕事を確かめることが判断材料です。すべての処理へ複数エージェントを導入する必要はなく、原文も単純な仕事では一つを選ぶよう説明しています。階層を増やすことを目的とせず、待ち時間、費用、権限の管理が実際に改善するかを確認することが重要です。参照構成の採用自体を、品質が保証された状態と扱わないようにします。小さな業務単位で担当と接続を明確にし、失敗時にどの層を調べるかを共有することも論点です。