AIエージェント、本番化した後に何が起きるか——「agent sprawl」とコスト暴走を防ぐ運用設計
「本番運用中と答えた日本企業はわずか17%」——前回の記事でお伝えした数字に、驚いた読者もいらっしゃったはずです。しかし、その17%に入って安心するのはまだ早いというのが、私たちの実感です。Gartnerは2027年末までに、エージェントAIプロジェクトの40%以上が中止されると予測しています。本番化はゴールではなく、新しい種類の壁の始まりです。この記事では、PoC(概念実証:小規模な検証で効果を確かめること)を脱した後に何が起きるのか、私たちがFDE(フォワードデプロイドエンジニア:顧客の現場に入り込んで開発するエンジニア)として現場で見てきた運用課題と設計をお伝えします。
- 01「もう一つの壁」——本番化した後に何が起きているか
- 02見えなくなる「何個あるか分からない」——agent sprawlという新しい問題
- 03コストは「後から効いてくる」——本番リリースで届く請求書
- 04「簡単すぎて逆に怖い」——現場が本番化の後に抱く不安の正体
- 05従来型の監視は、エージェントの「挙動のドリフト」を捉えられない
- 06私たちがイシュードリブンで運用を回す理由
- 07モデルは「審判」に使う——精度を多段で担保する設計
- 08誰が本番化後の「運用責任者」であり続けるか
- 09PoC止まりを脱した企業が、また止まる企業とどう違うのか
- 10自己診断: 本番化後の運用を止めているのはどれか
- 11よくある質問
- 12まず試すなら
- 13参考リンク
「もう一つの壁」——本番化した後に何が起きているか
「AIエージェント 本番運用 課題」「AIエージェント 監視」と検索してこのページにたどり着いた方も多いはずです。私たちも商談の場で「AIエージェント運用 コスト管理」や「AIエージェント ガバナンス」についての相談を、本番化を終えたばかりの企業から受けています。
前回の記事では、AIエージェントを本番運用中と答えた日本企業がわずか17%、14カ国中最下位だという調査結果をお伝えしました。この数字だけを見ると、課題は「本番化するかどうか」の一点に見えます。ですが私たちがFDEとして本番化後の現場に入ると、そこにはまったく違う種類の悩みが待っています。
Gartnerが2025年6月に発表した予測によれば、2027年末までにエージェントAIプロジェクトの40%以上が中止されます。理由として挙げられているのは、コストの膨張、不明瞭なビジネス価値、不十分なリスク統制の3つです。技術的には動いている。なのに止められる。これは、私たちが前回お伝えしたPoC止まりとはまったく別の失敗パターンです。
正直に言えば、私たちもこの数字を最初に見たとき意外に感じました。本番化さえできれば、あとは運用に乗せるだけだと考えがちだからです。ですが実際には、本番化した瞬間に新しい種類の管理対象が生まれます。エージェントの数、エージェントが消費するコスト、エージェントの挙動。これらは、PoCの段階では気にする必要すらなかったものです。
見えなくなる「何個あるか分からない」——agent sprawlという新しい問題
私たちが本番化後の現場でもっとも頻繁に耳にする悩みがあります。「今、社内にいくつのAIエージェントが動いているか誰も把握していない」というものです。海外ではこの状態を「agent sprawl」と呼びます。各部署が個別にAIツールを契約する。誰かが個人的にプロンプトを組んでエージェント化する。気づけば全体像を誰も描けなくなっている状態です。
海外のカンファレンスレポートでも、まず「何個あるか分からない」を解消することが運用の出発点だと指摘されています。これは海外の大企業だけの話ではありません。私たちがVibeCoding内製化の現場で見てきた光景そのものが、放置すればagent sprawlの初期段階になります。ある担当者が個人的に作ったツールが便利で、周囲に広がっていく。この積み重ねが、誰も把握できない状態を生みます。
厄介なのは、agent sprawlが技術的な失敗として現れないことです。個々のツールは、それぞれ正常に動いています。問題が表面化するのは、経理が「このAI関連費用は何に対応しているのか」と尋ねたときです。あるいは、セキュリティ部門が「このエージェントは誰の承認で、どのデータにアクセスしているのか」と確認しようとしたときです。私たちの経験では、この問いに即答できる企業は、本番運用中の企業の中でもまだ少数派です。
海外では、こうした管理外のエージェントを「シャドーAI」と呼ぶこともあります。承認されたシステムの外側で、個人や部署が勝手にAIツールを使い続ける状態です。私たちが製造業の現場で見てきた「担当者が自分のPCで便利に使っているツールが、いつの間にか業務の一部になっている」という状況も、この延長線上にあります。悪意があるわけではありません。ただ、誰かが棚卸しをしない限り、増え続けるのです。
私たちが業務プロセス診断(BPR)で現場に入ると、この「誰も把握していないエージェント」に最初に出会うことが少なくありません。ある製造業の現場では、複数の部署がそれぞれ別のAIチャットツールを契約し、似たような議事録要約や資料作成を、部署ごとに別々のやり方で回していました。統合すれば一つで済む機能が、部署の数だけ存在していたのです。担当者に聞くと「いつ契約したのか覚えていない」という答えが返ってくることもあります。棚卸しは、地味な作業に見えて、実は最も費用対効果の高い最初の一手だというのが私たちの実感です。
コストは「後から効いてくる」——本番リリースで届く請求書
私たちが技術顧問として現場に入ったある案件で、こんな経験がありました。開発環境では無料で使えていたライブラリが、公開環境に切り替えた途端に課金対象になっていたのです。本番リリースの直前になって、まとまった金額を請求されました。慌てて自前のライブラリに差し替え、事なきを得ました。VibeCodingの速さの裏側では、こうした本番コストの見落としが起きがちです。
AIエージェントの場合、この問題はさらに大きくなります。エージェントは推論のたびにトークン(AIモデルが文章を処理する際の最小単位で、消費量が利用料に直結する)を消費します。判断が複雑になるほど呼び出し回数も増えます。PoCの段階では利用回数が少ないため気づきにくいものです。ですが本番運用で利用者が増えると、コストは掛け算で膨らみます。私たちの現場経験では、月次のAPI(異なるシステム同士がデータをやり取りする仕組み)利用料が想定を大きく超えてから、初めて気づいたという相談を複数の企業から受けています。
ある大手建材・シャッターメーカーの情報システム部長は、複数のAIシステムを別々に作る方針について、こう語っていました。「AIの利用料はやり方によっては上がる可能性もゼロではない」。投資が無駄にならないかを、気にしていたのです。この懸念は的外れではありません。むしろ、本番化を検討する段階でこの懸念を持てている企業のほうが、後になって慌てずに済むというのが私たちの実感です。
私たちが運用コストを設計するときに欠かさず行うのが、業務ごとの許容コストを事前に決める作業です。すべての業務に同じ精度を求めれば、コストは際限なく膨らみます。逆に、優先度の低い業務は多少の誤答を許容し、優先度の高い業務にだけ高精度なモデルを充てる。この配分の設計こそが、AIエージェント運用のコスト管理の本質だと私たちは考えています。
「簡単すぎて逆に怖い」——現場が本番化の後に抱く不安の正体
ある大手化学メーカーのDX推進担当者は、AI導入の手軽さについて「簡単すぎて逆に怖い」と漏らしていました。「セキュリティ対策がトゥーマッチにならないか」「自社のリテラシーが低すぎないか」。過剰投資とスキル不足への懸念を、同時に口にしていたのが印象的でした。同じ担当者は別の場面で、こうも語っています。「工場のPCが破られると中に入られる。ヒューマンエラーのリスクは拭えないのでは」。
この二つの発言に共通しているのは、技術そのものへの不安ではありません。「自分たちがこの技術を制御し続けられるのか」という不安です。誤解のないように言えば、これは悲観的な反応ではありません。本番化した後も自分たちで制御し続けられるかを問い続ける姿勢こそが、本番化後の失敗を防ぐ最初の一歩だと私たちは考えています。楽観的に「入れて終わり」と捉えている企業のほうが、後になって足元をすくわれがちです。
従来型の監視は、エージェントの「挙動のドリフト」を捉えられない
本番化した後、多くの企業がまず整えるのは稼働率やレスポンス速度の監視です。ですが、これだけでは不十分だというのが私たちの実感です。エージェントは、稼働率の数値上は健全なまま、判断の質だけが少しずつ変わっていくことがあります。プロンプトの解釈が微妙にずれる。参照するデータの鮮度が落ちる。想定していなかった入力パターンに遭遇して、誤った判断を返す。これらはシステムのエラーログには現れません。
従来のシステム監視は、CPU使用率やHTTPのエラー率を教えてくれます。しかし、エージェントが「間違った道具を選んだ」ということまでは教えてくれません。「事実と異なる回答をした」ということも同様です。私たちがFDEとして本番運用の伴走を続けているのは、まさにこの部分のためです。コードは動いているが、判断の質が落ちていないか。この監視を、外部のツールだけに任せきれないからです。

私たちがイシュードリブンで運用を回す理由
私たちの現場では、こんな経験をしました。AIによる議事録の自動起票をそのまま使うと、すべての変更履歴が一つの名前に丸め込まれてしまいます。後から何が本当に直っていて、何が直っていないのかが分からなくなるのです。そこで私たちは、管理しやすい単位でイシューを切り、順番に検証するという運用に切り替えています。
現場からのフィードバックをイシューとして登録する。翌週にはプロトタイプへ反映する。この積み重ねが、本番化後も「今、何が起きているか」を追える状態を保つ土台になっています。これは特別な技術ではありません。むしろ、PoCの段階から本番化までを同じ人間・同じチームが担うFDEモデルだからこそ、無理なく続けられる運用だと私たちは捉えています。
作った人と運用を引き取る人が違えば、イシューの粒度をそろえる作業自体が余分なコミュニケーションコストになります。同じチームであれば、そのコストが最初から発生しません。私たちがエージェントの運用体制を設計するときに大切にしている考え方も、根っこは同じです。エージェントを「新入社員」として迎えるなら、誰かが継続的に育て、評価し続ける必要があります。
モデルは「審判」に使う——精度を多段で担保する設計
本番化した後にもう一つ見落とされがちなのが、モデル自体の精度をどう継続的に担保するかです。私たちが実践している方法の一つは、あるモデルが出した回答を、別のモデルに採点させるという二段構えです。特定のモデルにハルシネーション(AIが事実と異なる内容をもっともらしく生成してしまう現象)が多いと分かっていれば、より精度の高いモデルに審判役を任せます。コストは一時的に増えますが、より正しい回答を出す設計に寄せるのです。
この考え方の背景には、私たちの基本姿勢があります。「AIは信用するのではなく、こちらの考えをぶつけ続けることで深い対話が生まれる」というものです。一つのモデルの出力を無条件に信じるのではなく、複数の視点で検証し続ける。この体制そのものが、本番運用後の精度低下を防ぐガードレールになります。
ただし、この二段構えにもコストという代償が伴います。どの業務にどこまでの精度が必要かを見極める判断は、結局のところ人間が担うべきだというのが私たちの立場です。すべての業務に審判役を置けば、コストは倍増します。優先度の高い業務から順に導入するという判断が欠かせません。
私たちがこの設計を勧める理由は、もう一つあります。精度の低下は、ある日突然起きるわけではありません。少しずつ、じわじわと進行します。月次で審判役のモデルにサンプルの回答を採点させ続けていれば、精度が落ち始めた兆候を早い段階でつかめます。逆に、審判の仕組みを置かずに「動いているから大丈夫」と判断していると、現場から苦情が相次いでから初めて気づくことになりがちです。私たちの現場経験では、この気づきの遅れこそが、本番運用を止めてしまう直接の引き金になっています。
誰が本番化後の「運用責任者」であり続けるか
前回の記事で、私たちはPoCを始める前に運用責任者を仮でも決めておくことの大切さをお伝えしました。ですが本番化後の現場では、もう一段厄介な問題が起きます。運用責任者は決まっていたはずです。ですが、エージェントの数が増えるにつれて、その責任者一人では全体を把握しきれなくなるのです。
ある大手化学メーカーの執行役員は、こう語っていました。「一度作ったら、メンテナンスはさすがにできない。ある程度は内製化していかないと世の中の力についていけない」。保守の自走化への関心を、口にしていたのです。一方で同社の別の所長は「私はAIは苦手な方で。DX統括の新トップも、多分ほとんど分からないと思う」と、経営層の理解と現場実態の乖離を率直に明かしていました。
本番化後の運用責任は、一人の担当者に固定するものではありません。内製チームへ段階的に権限を移していく設計として捉える必要があります。これが、私たちがこの二つの声から得た教訓です。私たちが並列でエージェントを動かす働き方についてお伝えしたときも、同じ問題意識がありました。エージェントの数が増えるほど、それを束ねる人間の役割設計が先に問われるのです。
具体的には、私たちは「誰が、どのエージェントを、どこまでの権限で動かしているか」を一覧化した台帳を作るところから始めます。特別なツールは必要ありません。表計算ソフトで十分です。大切なのは、新しいエージェントを追加するたびにこの台帳を更新するという運用を、担当者任せにせず仕組みとして組み込むことです。私たちの現場経験では、この台帳作りを後回しにした企業ほど、後になって棚卸しに何倍もの時間を取られています。

PoC止まりを脱した企業が、また止まる企業とどう違うのか
私たちの現場経験では、本番化した後に再び止まる企業には共通点があります。本番化そのものをゴールに設定してしまい、運用フェーズの体制設計を後回しにしていることです。逆に、本番化後も安定して価値を生み続けている企業は違います。PoCの設計段階から「本番化した後、誰が何を監視し、コストの上限をどう設定するか」まで織り込んでいるのです。
これはAIエージェント特有の問題ではないかもしれません。従来型のシステム開発でも、運用フェーズを軽視したプロジェクトは同じように失速してきました。ただし、AIエージェントは確率的に出力が揺れます。コストも利用状況によって非線形に変動します。この性質上、従来型のシステム以上に「運用フェーズの設計」が結果を左右するというのが私たちの見立てです。私たちがFDEとして本番化後も伴走を続けているのは、この運用フェーズこそが、実は最も専門性を必要とする局面だと考えているからです。
私たちがSaaSではなくオーダーメイドにこだわってきたのも、根っこは同じ理由です。既製のパッケージに業務を合わせるやり方は、導入した瞬間の姿には最適化されていても、運用しながら変わり続ける現場には追いつきません。会社ごとに業務も文化も違う以上、運用フェーズの設計もまた、会社ごとに作り込む必要があるというのが私たちの一貫した立場です。
自己診断: 本番化後の運用を止めているのはどれか
ここまでの内容を、自社に当てはめてチェックしてみてください。
- 現在稼働しているAIエージェントの数を、誰か一人が正確に答えられるか
- 各エージェントの月次コストの上限を、事前に設定しているか
- エージェントの回答精度が落ちていないかを、稼働率とは別に確認する仕組みがあるか
- 運用責任者は、内製チームへの権限移譲の道筋まで含めて決まっているか
- 新しいエージェントを追加する際の承認フローが、部署ごとにバラバラになっていないか
私たちの現場経験では、5つのうち3つ以上に「いいえ」がつく企業ほど、本番化後にプロジェクトが縮小・凍結されるリスクが高い傾向にあります。技術的な精度そのものよりも、この運用フェーズの設計が、本番化を維持できるかどうかを分けています。
よくある質問
Q1. agent sprawlは、大企業だけの問題でしょうか。 規模の大小は関係ありません。むしろ人員に余裕のない中小企業ほど、担当者一人が複数のツールを個人的に運用しがちです。引き継ぎのないまま異動してしまうケースも目立ちます。エージェントの数が少ないうちに台帳を作る習慣をつけておけば、後から棚卸しに追われることもありません。棚卸しは早いほど楽です。
Q2. コストの上限設定は、具体的にどう決めればよいですか。 私たちは、業務の重要度に応じて許容できる誤答率とコストのバランスを最初に決めます。上限を超えた場合は自動で止めるのではなく、一度人間の判断を挟む設計を推奨しています。止めるより、人を介在させるほうが現場の納得感を得やすいためです。
Q3. モデルの精度低下は、どのくらいの頻度で確認すべきですか。 月次の定例で確認する企業が多い状況です。業務の重要度が高い場合は、週次に切り替えることをお勧めします。頻度よりも、誰が確認するかが決まっているかのほうが重要です。
Q4. 運用責任者を内製チームに引き継ぐタイミングの目安はありますか。 本番化から3〜6ヶ月が一つの目安です。私たちは技術顧問契約の中で、マニュアル作成と勉強会を通じて段階的に権限を渡していく進め方を取っています。
Q5. 本番化後にコストが想定以上に膨らんだ場合、まず何をすべきですか。 エージェントごとの利用ログを洗い出します。どの業務がどれだけのコストを生んでいるかを可視化することから始めます。原因を特定せずに一律で利用を制限すると、本当に価値を生んでいた業務まで止めてしまうことがあります。まずは可視化、その後に絞り込みという順番を私たちは崩しません。
まず試すなら
- 現在稼働しているAIエージェントとツールを、部署をまたいで一度棚卸ししてみること
- 各エージェントの月次コストに、上限とアラートの仕組みがあるかを確認すること
- 本番化後の運用チェックリストの5項目に自社を当てはめ、「いいえ」がいくつつくかを数えてみること
AI-Pathでは、無償の業務プロセス診断(BPR)を実施しています。本番化した後の運用に不安があれば、何が足りていないのかを一緒に見極めませんか。
参考リンク
櫻井 文雄(さくらい ふみお) 株式会社AI-Path 代表取締役CEO
関西大学法学部法律学科卒業。財務コンサルティング会社(エフアンドエム)、外資系生保営業(Prudential)でコンサルティング営業の経験を積んだ後、起業し様々な企業のCTO/CMOを歴任。その後、デロイトトーマツコンサルティング(Big4)、ABEJA(AI研究開発の国内リーディングカンパニー)にて官公庁・製造業・金融業・小売業・不動産業を中心に延べ20社以上のDX推進や業務システム刷新をPM/SMとしてリード。利用者目線での現場の課題解決にフォーカスしたものづくりに拘り、導入ではなく「定着化」を目的とした伴走型のプロジェクト推進・システム導入を得意とする。2025年にAI駆動開発(VibeCoding)と出会い、より多くの人・企業に価値提供するためにAI-Pathを創業。
関連コラム
「ブランチは汚していい、DBは触るな」——非エンジニアが安全にVibeCodingするための線引き設計
非エンジニアによる内製化が広がるほど、AIエージェントが本番データベースを壊す事故は他人事ではなくなります。2026年に相次いだ実際の事故と、私たちが顧客の現場で引いている『どこまで任せてよいか』の線引き設計をお伝えします。
製造業のAI導入、何から始めるべきか——よくある5つの疑問に答える2026年の実践ガイド
製造業のAI導入は「検討」から「実装」へ移行していますが、PoC止まりや現場に定着しないケースも依然多くあります。費用感・進め方・失敗パターンなど、よくある5つの疑問にまず答え、そのうえで領域別の選び方と実践のポイントを解説します。
AIエージェントが『PoC止まり』で終わる本当の理由——日本は14カ国中最下位
AIエージェントを本番運用中と答えた日本企業はわずか17%。世界平均32%を大きく下回り、14カ国中最下位という調査結果が出ました。PoCで止まる構造的な原因と、私たちがFDEモデルで本番化まで到達している理由をお伝えします。