7月17日、AWSが「Managing AI agent sprawl across business units」と題した記事を公開した。複数の事業部門にまたがるAIエージェントの乱立（スプロール）を制御するためのガバナンスフレームワークについて、設計思想から90日間の導入計画まで詳しく解説している。
「AIエージェント乱立」はなぜ起きるのか
複数の事業部門（BU: Business Unit）を持つ組織でAIエージェントを展開し始めると、ある共通の問題が発生する。調達、スケジューリング、レポーティングといった同じ用途のエージェントを、複数のBUが互いに知らないまま独自に開発してしまう「エージェントスプロール」だ。
さらに深刻なのは、SaaSプラットフォーム自体がCRM、サービスデスク、コンタクトセンター向けのエージェントをデフォルト有効で内蔵するようになっており、気づかぬうちにエージェントが増殖している点だ。
AWSはこの問題が引き起こす具体的な症状として以下の5つのパターンを挙げている。
| スプロールパターン | 何が起きるか |
|---|---|
| BU間の重複 | 各BUが同じ機能のエージェントを個別に構築 |
| クロスBUデータ競合 | BU-Aのエージェントが書き込み、BU-Bが古いデータを読んで誤動作 |
| コストの隠れた集積 | BU単位では問題なく見えても、企業全体では過剰支出 |
| シャドーエージェントの増殖 | 中央承認が遅いため、未承認のエージェントが幾何級数的に増える |
| コンプライアンスの分断 | 規制体制が異なるBU間をエージェントが越境して違反が発生 |
この「シャドーエージェント問題」は特に注目に値する。中央ガバナンスの承認プロセスが遅いと、現場チームは迂回路を作る。ガバナンスの抜け穴が増えれば、むしろリスクが高まる——この逆説を解決することが、フレームワークの核心にある。
セルフサービス優先の「ハブ＆スポーク」ガバナンス
AWSが提唱するのは、中央集権と分散の中間に位置するフェデレーテッドガバナンスモデルだ。AWS Organizationsのような階層型の組織管理と親和性が高い設計思想でもある。
- ハブ（中央AI Governance Council）: 企業全体の標準策定、共有エージェントレジストリの管理、セキュリティとコンプライアンスのベースライン定義
- スポーク（各BUのAgent Governance Lead）: 中央が定めたガードレールの範囲内で、自BUのエージェントを自律的に構築・運用
このモデルの設計思想は明快だ。「ガバナンス準拠のパスを、準拠しないパスより速くする」——これが最優先目標である。承認の遅延がシャドーエージェントを生む原因なのだから、ガバナンスプロセス自体を高速化することで、迂回するインセンティブをなくす。つまり「抜け道を塞ぐ」のではなく「正規ルートを最速にする」ことがスプロール抑制の本質だ。
セルフサービスと中央管理の振り分け基準
どちらのパスを選ぶかは、以下の基準で判断する。
| 属性 | セルフサービス | 中央管理必須 |
|---|---|---|
| データアクセス | 単一BU内の読み書き | 複数BUや共有システムへのアクセス |
| 障害の影響範囲 | 自チームのみ | 他BUや外部関係者に波及 |
| 規制対象 | 内部業務のみ | ITAR、輸出規制、顧客向けコンプライアンス |
判定ルールは単純だ。「自分のBU境界の外にあるデータを変更できるか、または障害が他のBUや外部に影響するか」——いずれかが真なら中央ガバナンスが必要。
リスクに応じた4段階のエージェント分類
すべてのエージェントに同一のガバナンスを適用しても意味がない。フレームワークでは、リスクに応じた4段階の分類を採用している。Amazon Bedrockのガードレール機能など、AWSのマネージドサービスはこの階層設計と組み合わせて活用されることが想定されている。
- Tier 1（安全重要・顧客向け）: 完全な中央ガバナンス、ヒューマン・イン・ザ・ループ、正式認定、継続監視。物理オペレーションに影響する本番システム、規制当局への提出物など
- Tier 2（BU横断・共有データ）: 中央標準必須、クロスBUデータアクセスのレビューが必要。サプライチェーン管理、共有アナリティクスなど
- Tier 3（BU内部）: 中央ガードレール内でBUが自律管理。BU固有のワークフロー自動化など
- Tier 4（個人生産性）: 承認済みプラットフォーム上のセルフサービス、自動登録。文書要約、コード補助など
分類は固定ではない。BU境界を越えるデータアクセスを追加した時点で、エージェントは自動的に上位Tierに移行するという考え方が重要だ。また、分類はスコープだけでなく自律性の度合いも考慮すべきとされており、「障害の影響範囲 × 自律性の度合い」がガバナンス要件を決定する。
実装パターンの選択：コストと統治性のトレードオフ
エージェントを構築する際、実装パターンの選択がコストとガバナンスに大きく影響する。
- MCPサーバー: 確定的・監査可能な結果を返すツール呼び出し。既知の処理（データ取得、トランザクション実行）に適する
- ツール・関数統合: 定義されたパラメータ内で特定ツールを呼び出す。ドメイン固有ロジックに適する
- フル・エージェントオーケストレーション: 複雑な多段階推論が必要な場合。最もコストが高く、ガバナンスが難しい
AWSが強調するのは「使用するパターンをユースケースが必要とする最もシンプルなものにとどめる」ことだ。MCPサーバーで十分な用途に全チームがフルオーケストレーションを選択すれば、トークンコストが膨らみ、不必要なガバナンス負荷が増す。
90日で基盤を作る実行計画
記事では90日間の段階的導入計画も提示されており、ガバナンスへの投資を組織の成熟度に合わせてペースを取ることの重要性を説く。3つのフェーズで構成されており、それぞれ明確なゴールが設定されている。
フェーズ1（Day 1〜30：Foundation） では、中央集権型のガバナンス体制を確立することに集中する。具体的には、AI Governance Councilの設置、既存エージェントの棚卸しと前述のTier分類への当てはめ、そして中央エージェントレジストリの初期構築が主な作業だ。この段階では「何があるかを把握する」ことが最優先とされる。
フェーズ2（Day 31〜60：Repeatable） では、セルフサービスの仕組みを整備し、BUが中央承認を待たずに動けるルートを開通させる。Tier 3・Tier 4向けのセルフサービス申請フロー、ガードレールのテンプレート化、BUごとのAgent Governance Lead任命がこのフェーズの中心になる。正規ルートを最速にするための実務的な整備期間といえる。
フェーズ3（Day 61〜90：Scale） では、体制を組織全体に拡大しながら、継続的な改善サイクルを回す仕組みを組み込む。モニタリングダッシュボードの整備、クロスBUのエージェント重複検出の自動化、そして廃止プロセスの制度化がここに含まれる。
エージェントの「計画的な廃止（Planned Retirement）」を明示的にライフサイクルに組み込んでいる点は見落とせない。利用率が低下したエージェント、ロジックが陳腐化したエージェント、機能が重複したエージェントを積極的に廃止しなければ、エージェント人口は増え続け、スプロールは複利で悪化する。
詳細はManaging AI agent sprawl across business unitsを参照していただきたい。
