AIエージェント、78%が着手して14%しか本番に進めない理由
企業がAIエージェントを導入しようとするとき、最初の壁は技術ではない。
田前秀樹氏がQiitaに投稿した記事（2026年8月21日）には、実務に刺さる数字が一つある。「企業の78%がAIエージェントの導入に着手している一方で、実際に本番運用まで進んでいるのは14%にとどまる」という調査結果だ。
この数字、意外に思うか、「やっぱりか」と思うか。
自分の感覚では後者に近い。デモや検証環境ではきれいに動くのに、本番データと本番の権限設計の中に置いたとたん、急に扱いづらくなる。それは技術力の問題ではなく、検証環境と本番環境のあいだに横たわる「前提の違い」に起因することが多い。
PoCは「成功して見えるように」設計されている
PoCの段階では、整形済みのサンプルデータを使う。権限もゆるく設定する。失敗しても誰も困らない。この状態でエージェントがうまく動くのは、ある意味で当然だ。
本番環境はそうはいかない。データには表記揺れがある。部署ごとにアクセスできる範囲が異なる。間違った操作をすれば実際に業務が止まる。
ここで効いてくるのが、Tool Engineeringの設計だ。PoCの段階で「とりあえず全部のツールを使えるようにしておく」という判断をしてしまうと、本番で権限を絞り込む作業が後から重くのしかかってくる。最初の設計判断が、後々の作り直しのコストとして戻ってくる。
ガバナンスは後付けできない、という原則
ここが今回の記事で最も重要な論点だと思う。
データガバナンスの設計は、アーキテクチャ設計と同時に組み込んでおくべきものだ。個人情報や社内機密データを扱う可能性がある以上、アクセス権限の設計、認証情報の管理、動作ログの記録と監査体制は、後から追加できる「付属品」ではない。最初から土台に組み込む部分だ。
これを後回しにするとどうなるか。PoCがうまくいって「では本番に上げましょう」となった段階で、ガバナンス要件を満たすための作り直しが発生する。せっかく動いていたものが一度止まる。田前氏はこの状況を「よく見かける」と書いている。珍しいケースではなく、構造的に繰り返されるパターンだということだ。
権限設計と監査ログ：地味だが、ここで差がつく
権限設計については、一つのシンプルな原則がある。「そのタスクに本当に必要な最小限に絞る」だ。
顧客データを参照するエージェントと、それを更新するエージェントは、役割としても権限としても分けておく。一つのエージェントに何でもできる権限を与えると、想定外の操作が起きたときの影響範囲が読めなくなる。地味な設計作業だが、ここを丁寧にやっておくかどうかで、後々のトラブルの起きやすさがかなり変わる。
監査ログも同じ文脈にある。エージェントが何を見て、何を判断し、何を実行したか。この記録がなければ、問題が起きたときに原因を追えないし、問題が起きたことにすら気づけないことがある。
ここで少し見方を加えると、監査ログには二つの役割がある。一つは開発者のためのデバッグ情報。もう一つは、組織としての説明責任を果たすための材料だ。この二つを意識して設計しておくかどうかで、「なぜこの動きをしたのか」と問われたときに答えられる組織と、答えられない組織に分かれる。
これは技術の話ではなく、組織設計の話だ
少し引いて構造を見てみる。
PoCから本番への壁として挙げられているのは、データガバナンス、アクセス権限、監査ログ、Human-in-the-loopの設計だ。これらはどれも、AIモデルの性能とは無関係の話だ。エージェントがどれだけ賢く動いても、組織側の設計が追いついていなければ本番運用には乗せられない。
「良いエージェントを設計できること」と「それが実務で使われ続けること」のあいだには、思っている以上の距離がある、と田前氏は書いている。この感覚は正確だと思う。
実験フェーズのAIは、精度が高くてデモが映えれば評価される。本番フェーズのAIは、ガバナンスが機能していて、何か起きたときに説明責任を取れる体制があって、はじめて「動いている」と言える。この二つのフェーズで求められる能力は、根本的に違う。
78%が着手して14%しか本番に至らない、という数字は、AI技術の問題ではなく、本番運用に必要な組織能力を構築できていない企業が多い、という事実の反映だと読んでいる。
Human-in-the-loopの配置と段階的な信頼構築
リスクの高い操作にだけ人間の確認を挟む、という設計の話もある。
顧客への一括メール送信、給与データの更新、契約書の外部送付——こうした操作は自動化の恩恵が大きい一方で、間違えたときの被害も大きい。これらにだけ承認ステップを設けておけば、日常的な作業は自動化しつつ、リスクの高い部分だけ人間が最終確認するバランスが取れる。
すべてを自動化しようとすると、かえって現場の信頼を得にくくなる。どこに人間の判断を残すかを最初に決めておくことが、結果的に自動化の範囲を広げやすくする土台になる。
導入のステップも同じ論理で動く。まず一つのチーム、まず読み取り専用の範囲から始めて、実際の運用のなかで信頼を積み上げてから権限とスコープを広げていく。最初から完璧な設計を目指すのではなく、小さく動かして、うまくいかない部分を観察し、改善を積み重ねる。これは個々のエージェント設計の話であると同時に、組織へのAI導入全体の進め方でもある。
判断軸として持っておきたいこと
記事には、ある調査会社が「2027年までにエージェント型AIプロジェクトの4割がROIの不透明さを理由に中止されるだろう」という予測を出しているという話も出てくる。あくまで予測であり、そのとおりになるとは限らない、と田前氏自身も留保している。
ただ、この予測が示す方向性は注目に値する。「技術的に動くこと」と「組織として続けられること」は別問題であり、ROIが測れない・説明できない状態でプロジェクトを続けるのは経営判断として難しい、という話だ。ガバナンス設計の不備は、倫理問題だけでなく、プロジェクト継続の可否にも直結してくる。
実務担当者が次にAIエージェント関連のニュースや製品評価を見るとき、一つ加えてほしい視点がある。「このソリューションは、ガバナンス設計を最初から組み込んでいるか、それとも後付けのオプションか」という点だ。ここを問うことで、実際に本番運用まで持っていけるプロダクトかどうかの輪郭が見えてくる。
IT担当・エージェント設計者へ。 PoCの段階から、本番でどのような権限設計と監査体制が必要になるかを見据えておく。これだけで後からの手戻りをかなり減らせる。権限は最初から広くではなく、必要になったときに広げる順序で。
経営層・事業責任者へ。 AIエージェントの導入議論が「どのツールを使うか」「コストはいくらか」で止まっているなら、次の問いを加える必要がある。「どんなデータを、誰が、どこまでAIに使わせるか」という権限とデータ設計の話だ。これは情報システム部門だけで決められない。事業側の判断が必要になる。
最後に
良いエージェントを設計するだけでは、実務導入は完結しない。
データガバナンス、アクセス権限、監査ログ、Human-in-the-loopの設計。どれも地味な作業だが、PoCから本番運用へ進むための土台になる。エージェントをどう賢く作るか、という話と、組織の中でどう安全に動かし続けるか、という話は、切り離して考えられない。
78%が着手して14%しか到達しない本番運用の扉を開けるのは、結局のところ、組織がどこまで地味な設計作業を丁寧にやれるかにかかっている。
