共通基盤チームと業務チームの責任を分け、アカウント境界、評価、配備、費用の帰属を構成します。推論とツールの入口を分けて統制する設計です。 モデルの選択に加え、誰が公開・復旧・廃止を担うかが焦点です。参考実装を使っても、自社の業務と権限の設計は必要になります。 個別の試作から複数チームの運用へ AWSは10月28日、Amazon BedrockとAgentCoreを使う企業向けエージェント基盤の設計と参考実装を公開しました。課題として挙げるのは、モデルがツールを使えるかだけでなく、複数のチームが統制された環境で開発と運用を続けることです。共通サービスを担うPlatformチームと、業務のエージェントを所有するWorkstreamチームを分けています。アカウントの境界、配備の手順、観測、費用の帰属、廃止までをインフラのコードとして構成する方針です。単一のエージェントを試す手順より広い運営範囲を扱います。参考実装の公開であり、導入企業の責任分担が自動的に決まるものではありません。 推論と操作の入口を別々に管理する 設計では、承認済みのモデルへアクセスする推論の入口と、許可したツールを見つけて呼ぶMCPの入口を分けます。業務チームごとに使えるモデルや地域、トークン枠、予算を制限し、本人識別の情報を持たせます。配備前には、許可された呼び出しが通るだけでなく、許可外のモデルや他チームの権限が拒否されることを確認します。前の版へ戻せることや、廃止時に関連資源が残らないことも検証の対象です。影響するのは開発者だけでなく、運用、セキュリティ、費用を管理する担当者です。各チームの独立した更新を支えながら、共通の境界を維持する狙いがあります。すべてを一つの担当へ集める場合も、完全に各チームへ任せる場合も課題があると説明し、その間をつなぐ形として示しています。実際の組織に合わせた調整が前提になります。 評価と廃止を継続的な仕事にする 企業が検討する際は、公開前の評価を誰が更新し、不合格のときに何を止めるかが論点になります。モデルやツールが変われば、以前に通った試験が十分とは限りません。共通基盤を維持する担当者が、例外の申請と承認を扱える体制も必要になると見られます。費用はアカウント全体の総額だけでなく、どの業務が何を使ったかへ結び付けることで、利用の継続を判断しやすくなります。一方で、詳細な観測と評価そのものにも運用費がかかります。参考実装を配備できたことを本番運営の完了とせず、障害時に戻す手順と、不要になった資源を片付ける手順まで試す方法が考えられます。業務チームの変更が共通基盤へ与える影響を見える形にし、責任者を決めることが重要です。境界ごとの証拠を残せるかが、規模を広げる前の判断材料になります。不要な接続の権限が残っていないかも、廃止後の確認対象になります。