AIエージェントのPoCと本番運用を語る数字は、前提が違う2つの壁を混ぜている

検索して出てくる数字を並べると、状況はかなり厳しく見えます。

  • マッキンゼーの2025年調査：AIエージェントを「実験中」と回答した企業は62%、全社の少なくとも1業務でスケール運用まで到達した企業は23%
  • Gartnerの予測：2026年末までに企業アプリケーションの40%がAIエージェントを組み込む見通しである一方、AIエージェントプロジェクトの40%以上が2027年末までに中止される見通し
  • 総務省「令和7年版情報通信白書」：日本企業の生成AI業務利用率は55.2%。中国95.8%・米国90.6%・ドイツ90.3%と比べて差が大きい

これらはいずれも実在の調査に基づく数字です。ただし、そのほとんどが従業員数百人から数万人規模の企業を対象にしたものであり、回答者の多くは複数部門・複数システムにまたがる導入を前提に「実験中」「スケール中」を判定しています。

個人事業や数人規模の小規模事業に、この数字をそのまま当てはめると判断を誤ります。止まっている理由そのものが違うからです。

大企業の壁の正体 — ガバナンス・稟議・全社プロセスの再設計

大企業でAIエージェントが実験段階から本番運用に進めない主な要因は、技術的な失敗ではありません。Gartnerが中止理由として挙げているのは、コストの膨張・事業価値の不明確さ・リスク統制の不備といった項目です。技術検証の失敗というより、意思決定の階層が多いことに起因する構造的な壁だと言えます。

本番運用に載せるまでに必要な工程

  • 情報システム部門・法務・セキュリティ部門それぞれの承認
  • 既存の業務フロー・権限体系との整合確認
  • 全社展開する場合の教育・サポート体制の構築
  • 予算執行の稟議と、年次の効果報告

1つの業務でPoCが成功しても、それを組織全体へ広げるには、この工程を部門ごとにもう一度繰り返す必要があります。大企業の壁は技術ではなく、組織を横断して合意形成をやり直すコストの大きさにあります。

小規模事業の壁は数字に出ない — 「作ったが、使い続ける運用に載らない」

個人事業や数人規模の事業には、情報システム部門も法務部門も稟議プロセスも存在しません。承認を取る相手は自分自身であることが多く、大企業型の壁はほとんど発生しません。その代わりに、別の壁にぶつかります。

PoCでは動いたのに、本番で使われなくなる

プロンプトを書いて1回か2回、うまく動くところまでは到達します。しかし1週間後には、その業務は結局また手動でやっている、という状態が起きます。エージェントが壊れたわけではなく、単に使う習慣に乗らなかったというだけのことが多いのです。

実際に起きていることの中身

  • 業務フローの中に、エージェントを呼び出す場所が決まっていない
  • 例外が起きたときの扱いを決めていないため、例外が出るたびに手動へ戻る
  • 承認や確認が必要な工程で、誰が最終判断するかを決めていない
  • 検証に使った1回分のデータでは動いたが、実際の業務データの揺れに対応できていない

これらはいずれも、AIエージェント側の技術的な問題ではありません。エージェントを業務の中にどう組み込むかという、運用設計側の欠落です。大企業の壁が組織横断の合意形成コストだとすれば、小規模事業の壁は、事業主自身が日々の業務判断とエージェント運用の両方を同時に抱えきれるかどうかという、まったく別の制約だと言えます。

relmeaが実際に運用している展開順序の設計 — 1業務から広げる

relmeaでは現在、91体のAIエージェントとオーケストレーターコマンド42本を運用していますが、最初からこの規模で設計したわけではありません。1つの業務から検証し、運用に定着したことを確認してから次の業務へ広げるという順序を踏んでいます。

順序1：最初の1業務は「頻度が高く、失敗しても影響が小さい」業務を選ぶ

最初に自動化する業務は、成果の大きさではなく、頻度の高さと失敗時の影響の小ささで選びます。頻度が高い業務は検証回数を早く稼げますし、失敗の影響が小さい業務であれば、運用に組み込む過程で必要になる調整を安全に試せます。

順序2：承認ゲートは最初から人が持つ

AIエージェントの出力をそのまま実行に流さず、重要な判断が伴う工程には人が承認する工程を挟みます。これはAIを信用していないからではなく、業務フローにエージェントを組み込む初期段階では、想定外の出力をその場で止められる仕組みが先に必要だからです。承認を自動化するのは、その業務で出力パターンが安定してからです。

順序3：1業務が「使われ続けている」ことを確認してから次に進む

1つの業務でエージェントを導入したら、次の業務に着手する前に、その業務が実際に使われ続けているかを確認します。動いたかどうかではなく使われ続けているかどうかを基準にするのは、PoCで一度動いただけの状態と、運用に定着した状態がまったく別のものだからです。

順序4：定着した業務の型を、次の業務に転用する

1業務目で承認ゲートの置き方・例外処理の設計・運用フローへの組み込み方が定着すると、その型を2業務目に転用できます。ゼロから設計するのではなく定着済みの型を転用することで、業務を広げるたびにかかる設計コストは徐々に下がっていきます。

展開順序を止めてしまう典型パターン

relmeaが運用してきた中で、展開の順序が崩れる典型的なパターンがいくつかあります。

パターン1：最初から複数業務を同時にPoCする

複数の業務を同時に検証すると、どの業務がなぜうまくいっていないのかの切り分けができなくなります。1業務ずつであれば原因が明確になりますが、並行させると問題が絡み合い、結局すべてが中途半端な検証止まりで終わりやすくなります。

パターン2：承認ゲートを最初から自動化しようとする

早く楽になりたいという気持ちから、承認ゲートを最初から省略してしまうケースがあります。しかし出力パターンが安定する前に承認を外すと、想定外の出力がそのまま実行され、その業務全体への信頼が一度で失われます。信頼を失った業務は、結局また手動運用に戻ってしまいます。

パターン3：「動いた」を「定着した」と混同する

1回動いたことと、1か月後も使われ続けていることは別の状態です。動いた時点で満足して次の業務に進むと、最初の業務は使われないまま放置され、結果としてエージェントは増えたのに業務は変わっていないという状態が積み上がっていきます。

パターン4：例外処理を後回しにする

検証時は正常系のデータだけで動作確認をしがちです。しかし実際の業務では、想定外の入力・欠けたデータ・重複といった例外が必ず発生します。例外が起きたときの扱いを先に決めておかないと、例外に当たるたびに手動へ戻ることになり、いつまでも本番運用に切り替わりません。

まとめ — 展開順序は「広げ方」の設計問題である

AIエージェントが検証止まりになる理由は、大企業と小規模事業でまったく違います。大企業の壁は組織を横断する合意形成コストであり、小規模事業の壁は、1つの業務をエージェントに任せたまま使われ続ける状態へ定着させられるかどうかです。

小規模事業がやるべきことは、検証の数を増やすことでも、一気に多くの業務を自動化することでもありません。1業務を選び、承認ゲートを人が持ったまま運用に定着させ、その型を次の業務へ転用するという順序を守ることです。

relmeaはこの順序で1業務ずつAIエージェントを積み上げ、現在の運用に至っています。展開順序の設計と実際の運用記録はBrain Vol.1（運用編）で扱っています。自社の業務にこの順序で組み込む設計そのものを任せたい場合は、Relmea AI Ops（AIチーム構築代行）でも対応しています。