エージェントの無秩序な拡大問題:なぜ企業は自律性の前に制御を必要とするのか
.png)
Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
企業のテクノロジーリーダーは、このパターンを以前にも見てきました。
SaaSのスプロールはビジネスチームにスピードをもたらしましたが、重複、シャドーIT、アクセスリスク、ベンダーの複雑さを生み出しました。APIのスプロールは再利用性を向上させましたが、管理されていないエンドポイントと一貫性のない制御をもたらしました。クラウドのスプロールは開発者に柔軟性をもたらしましたが、その後、企業はID、コスト、コンプライアンス、可観測性に関する規律を再構築することを余儀なくされました。
AIエージェントは、この問題の新たな形です。
違いは、エージェントが単なるアプリケーション、API、インフラストラクチャではないということです。それらは ソフトウェアアクターです。彼らは推論し、ツールを使用し、データにアクセスし、ワークフローをトリガーし、ユーザーやビジネスプロセスに代わって行動できます。
それが、エージェントのスプロールをこれまでのエンタープライズテクノロジーの波よりも複雑にしています。SaaSアプリケーションはデータを保存し、処理します。APIは機能を提供します。クラウドサービスはインフラストラクチャを実行します。エージェントはこれら3つすべてを連携させることができます。
企業にとっての問題は、もはやエージェントを構築するかどうかではありません。構築するでしょう。本当の問題は、それらが爆発的に増える前に統制できるかどうかです。
エージェントは統制よりも速く広がるでしょう
エージェントはプロトタイプ作成が容易です。
チームは、モデルをフレームワークに接続し、検索機能を追加し、いくつかのツールを公開し、数日でワークフローを自動化できます。初期の結果は魅力的です。例えば、チケットを要約するサポートエージェント、アカウント概要を作成するセールスエージェント、コードをレビューするエンジニアリングエージェント、インシデントをトリアージするオペレーションエージェントなどです。
その作成の容易さこそが、スプロールが発生しやすい理由です。
すべての機能部門が独自のエージェントを求めるでしょう。すべての製品チームが組み込みエージェントを求めるでしょう。すべてのエンジニアリングチームがコーディングエージェントと運用エージェントをテストするでしょう。すべてのデータチームが分析エージェントを検討するでしょう。これは、AI開発の民主化の自然な結果です。
市場はすでにその方向に動いています。Forresterは、AIプラットフォームがエージェントAIにますます焦点を当てており、ベンダーがAIアシスタント、エージェント、AIアプリケーションの開発と展開をサポートしていると指摘しています。しかし、この同じ変化は生産上の課題を提起します。エンタープライズグレードのAIには、依然として可観測性、継続的なガバナンス、コンプライアンス、ライフサイクル管理、コスト最適化が必要です。
その緊張がエンタープライズAIの次の段階を定義します。つまり、エージェントを構築する能力は、それらを管理するための運用モデルよりも速く広がっているということです。
エージェントスプロールが異なる理由
エージェントは複数の行動レイヤーを組み合わせます。
単一のエージェントは、基盤モデル、プロンプト、システム指示、検索パイプライン、API、MCPサーバー、メモリ、ユーザーID、権限、人間の承認経路、トレース、評価データセット、コストポリシーを含む場合があります。
それは、リスクが単一のコンポーネントに限定されないことを意味します。リスクは完全な実行パス全体にわたって移動します。
エージェントは、モデルがハルシネーションを起こした、プロンプトが不十分だった、取得したコンテキストが誤っていた、ツールスキーマが曖昧だった、ユーザーが過剰な権限を持っていた、ワークフローに承認ゲートがなかった、またはリトライロジックがコストの暴走を引き起こした、といった理由で失敗する可能性があります。
従来のソフトウェアは、コード、アクセス、デプロイメントを制御することで管理されます。エージェントシステムでは、 動作の制御が必要となります。
ガートナーはAIエージェントを、デジタルまたは物理環境において認識し、意思決定し、行動し、目標を達成する自律的または半自律的なソフトウェアエンティティと定義しています。また、現在の多くのLLMベースのエージェントは、完全に適応的なシステムというよりもLLMを拡張したワークフローに近い状態であり、その準備状況はエージェントの種類によって大きく異なると指摘しています。
これは重要です。なぜなら、多くのシステムがエージェントとしての運用上の成熟度を持つ前に、市場はすでにエージェントという言葉を使っているからです。エージェントが完全に自律的になる前でさえ、それらはすでにガバナンスのギャップを生み出すのに十分なほど複雑なのです。
最初のギャップ:インベントリ
エージェントの無秩序な増加の最初の兆候は、インベントリ管理の失敗となるでしょう。
ほとんどの企業は当初、いくつのエージェントが存在し、誰がそれらを所有し、どのモデルを使用し、どのデータにアクセスし、どのツールを呼び出せるか、あるいはそれらのコストはいくらかを知らないでしょう。
SaaS時代には、インベントリに関する問いは「従業員はどのアプリケーションを使用しているか?」でした。
エージェント時代には、インベントリに関する問いは次のようになります。
- どのエージェントが存在するか?
- 各エージェントの所有者は誰か?
- その目的と自律レベルは何か?
- どのユーザーまたはシステムがそれを呼び出せるか?
- どのモデル、データソース、ツールにアクセスできるか?
- どのようなアクションを実行できるか?
- どのポリシーが適用されるか?
- タスクまたはワークフローあたりのコストはいくらか?
- 最後に評価されたのはいつか?
これは単なる目録作成ではありません。説明責任を果たすための基盤です。
ForresterのAIガバナンスソリューションランドスケープは、AIインベントリを主要な課題として特定しており、組織がビジネス、規制、責任あるAIの目標を達成するために、AI資産の可視化と管理を求めていると述べています。
エージェントは受動的な資産ではなく、自律的に動作するため、インベントリの問題をより緊急なものにします。
ツールへのアクセスがリスクを現実のものにする
コンテンツを作成するエージェントは、あるレベルのリスクを伴います。ツールを呼び出せるエージェントは、別のレベルのリスクを伴います。
エージェントがデータベースの照会、CRMの更新、ワークフローのトリガー、メッセージの送信、インフラストラクチャの変更、チケットの作成、コードの実行ができるようになった瞬間、それはエンタープライズの制御対象の一部となります。
Model Context Protocolのような標準は、ツール接続を容易にします。しかし、接続が容易になったからといって、自動的にエンタープライズ対応になるわけではありません。
GartnerのMCPゲートウェイに関する調査によると、MCPを導入している企業は、登録、発見可能性、強制認証、認可、アカウンティング、監査に関してギャップがあることを発見しています。また、企業は数千に及ぶ可能性のあるMCPサーバーを一元的に登録、発見、監視する方法が必要であるとも述べています。
より広範な教訓は単純です。エージェントが使用できるすべてのツールは、登録され、許可され、監視可能で、監査可能でなければなりません。
将来は「エージェントがあらゆるものに接続されている」状態であってはなりません。「統制された制御ポイントを通じて、承認された機能に接続されたエージェント」である必要があります。
コスト曲線はチームを驚かせるでしょう
エージェントの無秩序な増加もコストリスクを生み出します。
チャットボットとの対話では、1回または数回のモデル呼び出しで済むかもしれません。しかし、エージェントワークフローでは、計画、情報検索、ツール選択、ツール実行、検証、再試行、要約、最終応答生成といった多くのプロセスが関与します。1つのユーザーリクエストが、モデル呼び出しとツール呼び出しの長い連鎖に変わる可能性があるのです。
これが、エージェントの経済性がチームを驚かせる理由です。Gartnerは、特にエージェントが計画、ツール使用、再試行、またはループを行う場合、エージェントワークフローが単一のユーザーリクエストを数十または数百のLLM呼び出しに変える可能性があると指摘しています。ポリシーやガードレールがなければ、エージェントはそれらのアクションのコストを自然に考慮しません。
それはトークンレベルのレポートの単純さを打ち破ります。
より良い指標は、トークンあたりのコストだけではありません。成果あたりのコストです。
コストリスクは理論上の問題ではありません。Gartnerは、不適切なアーキテクチャの選択と運用ノウハウの不足により、2028年までにGenAIプロジェクトの少なくとも50%が予算を超過すると予測しています。また、2028年までに、推論がモデルの総ライフタイムコストの少なくとも70%を占めるだろうとも予測しています。
エージェントの無秩序な増加は、支出が多くのチーム、ワークフロー、ツール、モデルから発生するため、このリスクを増幅させます。ランタイムのコスト管理がなければ、アーキテクチャがすでに断片化された後に、リーダーは請求書を発見することになるでしょう。
可観測性は説明責任へと進化しなければなりません
従来の可観測性は、システムが利用可能か、遅いか、飽和状態か、障害が発生しているかをチームに伝えます。
エージェントの可観測性は、説明する必要があります。 エージェントがなぜそのように振る舞ったのかを。.
エージェントの重要なアクションごとに、チームは元の目標、プロンプトのバージョン、使用されたモデル、取得されたコンテキスト、選択されたツール、渡された引数、適用されたガードレール、行われたポリシー決定、消費されたトークン、ステップごとのレイテンシー、ステップごとのコスト、人間による承認ステータス、および最終的な結果を知る必要があります。
ガートナーの「AI評価および可観測性プラットフォーム市場ガイド」によると、GenAIとエージェントAIにおける非決定性は、信頼性と信用性を測定し改善することを困難にしています。同ガイドは、これらのプラットフォームを、信頼性とアライメントを向上させるために、評価とログ、メトリクス、トレースを組み合わせたツールと定義しています。
これは重要です。なぜなら、エージェントの障害が常にインフラストラクチャの障害であるとは限らないからです。
エージェントは利用可能であっても、間違っている可能性があります。高速であっても、安全でない可能性があります。タスクを完了しても、ポリシーに違反する可能性があります。許可されたツールを間違った理由で呼び出す可能性があります。
エージェント時代において、可観測性はデバッグのためだけではありません。それは説明責任のためです。
評価は手動のままであってはなりません
多くのチームは、AIシステムを手動レビュー、アドホックテスト、またはデモ品質を通じて評価しています。何十、何百ものエージェントがプロンプト、モデル、ツール、コンテキストソースを変更している場合、それではスケールしません。
従来のテストは、出力が決定論的である場合にうまく機能します。エージェントの出力は確率的であり、コンテキストに依存します。問題は、常に正確な答えが1つ生成されたかどうかではありません。意図された用途に対して、応答やアクションが十分に適切か、十分に安全か、十分に根拠があるか、十分に整合しているか、ということです。
評価のギャップは依然として大きいです。ガートナーの報告によると、現在、カスタム構築されたAIエージェントの出力と動作をテストするためにAI評価ツールを使用している回答者はわずか18%です。エージェントが増加するにつれて、手動レビューやデモに基づく信頼性ではスケールしないため、これは重要です。
エージェントをスケールさせる企業は、タスク完了、根拠性、ツール使用、安全性、セキュリティ、ポリシー順守、コスト、および信頼性にわたる継続的な評価が必要になります。
重要なパターンはフィードバックループです。本番環境のトレースが評価データセットとなり、障害が回帰テストとなり、人間による修正が将来の動作を改善します。
そのループがなければ、各チームは孤立して学習し、エージェントの無秩序な増加は管理不能になります。
ガバナンスは実行可能なものにならなければなりません
AIガバナンスは、しばしば文書化とレビューの機能として扱われてきました。具体的には、モデルカード、リスク評価、コンプライアンスチェックリスト、承認委員会、監査証拠などです。
それは依然として必要ですが、エージェントにとっては十分ではありません。
エージェントは実行時に意思決定を行います。変化する状況に遭遇し、ツールを使用し、コストを発生させ、システムと動的に連携します。静的な承認プロセスでは、エージェントが試みる可能性のあるあらゆる行動を予測することはできません。
ForresterのAIガバナンスソリューションに関するWaveレポートは、企業がAIのユースケース、所有権、リスク評価、コンプライアンス監査、およびサードパーティAIの信頼性を拡大するにつれて、ガバナンスツールがスプレッドシートや委員会によるガバナンスの限界を超えて進むのに役立つことを強調しています。
ガバナンスはAI導入の足かせと見なされるべきではありません。Forresterの報告によると、AI意思決定者の79%が、AIガバナンスが組織が変化する市場および規制状況に迅速に適応するのに役立つことに同意しています。エージェント時代は、そのガバナンスがポリシーの意図から実行時の制御へと移行できるかどうかを試すことになるでしょう。
エージェントAIはこれをさらに推し進めます。ガバナンスは実行可能でなければなりません。
これは、監視としてのガバナンスと、インフラとしてのガバナンスの違いです。
エージェントの無秩序な増加は、すべてのチームにさらなるフォームの記入を求めるだけでは解決しません。制御されていないパスよりも、統制されたパスを容易にすることで解決されます。
リーダーシップの問い:どの程度の自律性が適切か?
企業のエージェントに関する最も重要な決定は、どのモデルやフレームワークを使用するかではありません。どの程度の自律性を許容するかです。
ドキュメント要約エージェント、営業調査エージェント、コード生成エージェント、財務承認エージェント、インフラ修復エージェントは、同じ権限を持つべきではありません。それぞれが、ビジネス、セキュリティ、コンプライアンス、コストに関して異なるレベルのリスクを伴います。
正しい道筋は、段階的な自律性です。範囲を限定したユースケースから始め、すべてを計測し、継続的に評価し、エージェントが信頼性、費用対効果、および統制可能性を証明した場合にのみ権限を拡大します。
エージェントを拡大する前に、リーダーシップチームは問いかけるべきです。
これらのほとんどに「いいえ」と答える場合、その組織はエージェントの実験には準備ができているかもしれませんが、広範なエージェント展開にはまだ準備ができていないかもしれません。
リーダーが今すべきこと
エージェントの無秩序な増加は避けられないものではありませんが、それを防ぐには早期のアーキテクチャ上の決定が必要です。
まず、エージェント、ツール、モデル、プロンプト、ワークフローのインベントリモデルを作成します。所有権、目的、自律性レベル、データアクセス、ツールアクセス、評価ステータスは最初から可視化されるべきです。
次に、モデルアクセスを一元化します。各チームが独自の認証情報、プロバイダーロジック、ルーティング、予算、ログを管理させないでください。
第三に、ツールアクセスが管理不能になる前に統制します。エージェントは任意のツールに直接接続すべきではありません。ツールは登録され、権限が付与され、監視され、監査されるべきです。
第四に、本番エージェントには可観測性と評価を義務付けます。すべての重要なエージェントは、モデル呼び出し、コンテキスト、ツール使用、ポリシー決定、コスト、および最終結果を説明するトレースを生成すべきです。
5つ目に、自律性の階層をリスク別に定義します。リスクの低いエージェントはより迅速に動けます。リスクの高いエージェントには、承認、より厳格なガードレール、そしてより強力な監査可能性が必要となります。
最後に、エージェントの経済性を成果に基づいて測定します。トークンあたりのコストだけでは不十分です。リーダーは、タスクあたりのコスト、ワークフローあたりのコスト、意思決定あたりのコスト、そしてビジネス成果あたりのコストを把握する必要があります。
結びの言葉
エージェントはエンタープライズソフトウェアの主要な一部となるでしょう。これは議論の余地がありません。
議論の焦点は、企業がエージェントを、かつてSaaS、API、クラウドがそうであったように、迅速に、有用に、そしてその後カオス的に広がるのを許すかどうかです。
エージェントの無秩序な拡大は防ぐことができますが、それはリーダーがエージェントを、アイデンティティ、ポリシー、可観測性、コスト管理、ガバナンスを必要とする、行動を起こすソフトウェアエンティティとして認識した場合に限られます。
エンタープライズAIの未来は、組織が立ち上げるエージェントの数によって決まるものではありません。
それは、それらのエージェントがいかに安全に行動できるかによって決まるでしょう。
自律性は価値を生み出します。制御がそれをスケーラブルにするでしょう。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
The fastest way to build, govern and scale your AI


Recent Blogs
Frequently asked questions
What is agent sprawl?
Agent sprawl happens when teams create AI agents across functions without centralized visibility, ownership, governance, cost controls, or auditability.
Why is agent sprawl riskier than SaaS or API sprawl?
Agents can reason, call tools, access data, trigger workflows, and act on behalf of users. That makes their risk behavioral, not just operational.
What should enterprises govern first?
Start with agent inventory, model access, tool permissions, traceability, evaluation, budgets, and approval workflows for high-risk actions.
Why does MCP increase the need for governance?
MCP makes tool connectivity easier, but enterprises still need registration, authentication, authorization, observability, and auditing for every tool an agent can access.
How should leaders think about agent autonomy?
Autonomy should be progressive. Start with bounded use cases, evaluate behavior continuously, and expand authority only when reliability, cost, and governance are proven.










.webp)




.png)








.webp)
.webp)








