AIエージェントのROI、なぜ差がつくのか——製造業「80%がPoCで停滞」の裏にあるデータ設計の話

「そのAIエージェント、本当に儲かっているのか」と聞かれた日

先日、ある中堅の化学メーカーの経営会議に、DX推進担当の方と一緒に同席する機会がありました。生産計画を支援するAIエージェントを試験的に導入してから半年が経ち、CFOから飛んだ質問はシンプルでした。「結局、いくら儲かっているんですか」。

担当の方は数字自体は持っていました。稼働時間の短縮率、担当者の作業時間の削減量。ただ、その数字が投資額に対して見合っているのかを、その場で即答できる形にはなっていませんでした。正直に言えば、この場面は珍しくありません。私たちがAIエージェントの導入支援でご一緒する企業の何割かが、同じ壁にぶつかります。

ROIの計算式そのものは複雑ではありません。コスト削減額と売上増加額を足し、そこから運用コストを引いて、投資額で割る。この式を知らない経営者はほとんどいないでしょう。それでも、同じ式を当てはめて、はっきり効果が出る企業と、いつまでも「検証中」と報告し続ける企業に分かれます。この記事では、その分かれ目がどこにあるのかを、私たちの現場経験を踏まえてお伝えします。

「95%」と「80%」——同じAIエージェントでこれだけ差が出る

差の大きさを示す数字があります。システムインテグレーターのCustomertimes社が2026年7月に発表した製造業向けAIエージェントに関するレポートがあります。このレポートによると、製造業のAIパイロットの80%が本番化する前に停滞しているといいます。「製造業 AI PoC 停滞」という言葉での検索が増えているのも、この構造が背景にあると私たちは見ています。

一方で、同じレポートの中で、予測保全に使うAIエージェントに限っては95%が投資対効果でプラスに転じているとも報告されています。同じ「AIエージェント」という言葉でくくられていても、80%が止まり、95%が結果を出す。この差は、AIモデルの性能差だけでは説明がつきません。

同レポートによると、うまくいっている予測保全エージェントは、設備のダウンタイムを15%から30%削減しているといいます。さらに、導入企業の27%が12ヶ月以内に投資回収（ペイバック）に到達しているとも報告されています。うまくいっている領域は、成果が出るまでの期間まで具体的に見積もれる状態にあるということです。

同レポートによると、品質検査のAIエージェントについても報告があります。検査工程を担うエージェントを入れた現場では、目視検査にかかる労働時間を40%から60%削減できたとされています。予測保全と品質検査、この2つの領域に共通するのは、判断の材料になるデータがもともと数値やログとして記録されていた業務だという点です。逆に言えば、AIエージェントが答えを出しやすい業務かどうかは、導入前のデータの状態でかなり見えているということです。

「エージェント・ウォッシング」もROIを狂わせる

差が生まれる背景には、もう1つの事情があります。市場調査会社のGartnerは2025年6月、2027年末までにエージェント型AIプロジェクトの40%以上が中止されると発表しました。理由の1つとして名前が挙がったのが「エージェント・ウォッシング」です。既存のチャットボットやRPA（定型業務の自動化ツール）を、実質的な自律性を持たせずに「AIエージェント」と呼び直しているだけの製品が、市場に多く出回っている状態を指します。

Gartnerは、こうした製品の多くが「複雑な業務目標を自律的に達成し、時間をかけて指示の意図を汲み取るだけの成熟度を持っていない」とも指摘しています。つまり、ROIが出ない一因は、導入企業側だけでなく、渡されたAIエージェント自体が名ばかりだったケースも含まれているということです。この点は、私たちが導入検討のご相談を受けるときに、最初に確認するようにしている観点でもあります。

誤解のないように言えば、ベンダーを疑う話をしたいわけではありません。私たちが伝えたいのは、AIエージェントという言葉の内側には、自律性の水準もデータの前提もまったく違う製品が混在しているという現実です。ROIの計算式を当てはめる前に、まず何を導入しようとしているのかを見極める必要があります。

なぜ差がつくのか、プラットフォームの問題ではない

「AIエージェント ROI」の解説記事の多くは、計算式や測定フレームワークで終わっています。どのKPIを追うか、いつベースラインを取るか。どれも必要な知識ですが、これらは「測り方」の話であって、「なぜ測れる結果とそうでない結果に分かれるのか」には答えていません。

私たちの現場経験では、この分岐点は導入するAIエージェントの種類やベンダーの選び方にはありません。渡しているデータの状態にあります。同じAIエージェントを同じ工場に入れても、データの整理状況によって結果は変わってしまいます。「AIエージェント 導入 効果が出ない」と感じたときに真っ先に見直すべきは、ツールの入れ替えではなく、そのツールに渡しているデータの設計です。ここを見誤ると、計算式は正しくても、測る対象そのものが育っていないという状況に陥ります。

たとえば、同じ「需要予測エージェント」を2つの工場に入れたとします。片方の工場では発注データが商品コードで統一され、欠品・過剰在庫の記録も残っていました。もう片方の工場では、同じ商品が担当者ごとに違うコードで登録され、欠品時の対応は口頭で済まされていました。私たちの経験では、後者の工場でAIエージェントが出す予測は、担当者の「感覚」に届くまで何ヶ月も試行錯誤が必要になります。ツール自体はまったく同じでも、ROIが出るまでの距離はこれだけ変わります。

「データはある程度揃っている」——それでも動かない現場の声

ある大手化学メーカーのAI推進担当の方から、こんな話を伺ったことがあります。「データはある程度揃ってきているが、そのデータを基に人がどう考え、どう動くかを定義・教育するのが難しい。マニュアルだけでは足りず、行間を読むような仕事をしている」。データが存在することと、そのデータをAIエージェントの判断材料として使える形にすることの間には、想像以上の距離があるということです。

同じ会社の生産DX部門のリーダーの方も「基本、システムでは繋がっていない。繋げようとしても縦割りが強く、事業ごとに顧客も機能も全然違う」と話していました。ある鉄鋼・産業機械メーカーのシステムグループマネージャーからは、開発にAIを入れてコール件数を3割削減したと社内で報告しても、なぜか評価されなかったという話も伺いました。データがつながっていない現場では、成果自体が出ていても、その成果を経営に説明できる形で示せないという二重の壁があります。

私たちがBPR（業務プロセス診断）で最初に確認するのも、まさにこの距離です。データが「ある」という報告と、AIエージェントが実際に判断材料として使える状態にあるかどうかは、別の質問だと捉えています。

硬いデータと柔らかいデータを分ける、という設計思想

ここで私たちが実践している設計の考え方を1つご紹介します。基幹システムに入っている「硬いデータ」と、AIエージェントが判断材料にする「柔らかいデータ」を、はじめから分けて設計する方法です。硬いデータとは、在庫、受発注、生産計画など、変更に慎重さが求められるデータを指します。柔らかいデータとは、現場のメモ、判断の経緯、例外対応の記録などを指します。

具体的には、基幹システムの横にAI用のデータ空間を用意し、バッチ処理で定期的にコピーする形を取ります。基幹システム側を直接AIエージェントに触らせないため、既存の業務を止めるリスクを抑えながら、AIエージェントには判断に必要な情報を渡せます。この設計であれば、オンプレミスでもクラウドでも、閉域環境でも動かせるという利点もあります。

データの機密性が高い製造業の研究開発部門ほど、この分離が導入のハードルを下げると私たちは感じています。ある大手化学メーカーの担当者からも「工場のPCが破られると中に入られる。ヒューマンエラーのリスクは技術だけでは拭えないのではないか」という声を伺ったことがあります。硬いデータをAIエージェントから隔離しておく設計は、技術的な対策と人的リスクへの不安、両方に対する現実的な答えになります。

私たちが顧客企業に提案する際は、「AIはインフラを選ばない」という前提も重視しています。クラウドで動かすか、オンプレミスで動かすか、あるいは閉域網の中だけで動かすかは、会社ごとのセキュリティ方針で決めればよいという考え方です。データの置き場所を先に固定してしまうと、後からAIエージェントの選択肢が狭まります。柔らかいデータの層を基幹システムから切り離しておけば、インフラの選択とAIエージェントの選択を、別々のタイミングで判断できるようになります。

マスターデータの品質が最初のゲート

Customertimes社のレポートは、もう1つ具体的な基準を示しています。部品や資材、取引先といったマスターデータの重複率を5%未満に抑えることを、AIエージェント導入の前提条件として挙げているのです。「AI導入 データ品質」という観点は、AIエージェントそのものの話題に比べて後回しにされがちですが、実際にはここが最初のゲートになっています。

これは製造業の現場では意外と見落とされがちな観点です。ある合成樹脂メーカーの営業課長は、社内で「秘伝のタレ」と呼ばれる工賃表について話していました。「細かすぎて、どこに何が書いてあってどのケースはどの工賃を使うのかを理解した人じゃないと使えない」といいます。同社の業務課長も、原価表の7割がブラックボックス化し、部材を1つ変えるたびに全シートのセルを1つずつ探して直していると明かしています。

こうした状態のまま柔らかいデータだけ整えても、AIエージェントが参照する原価や工賃の側が壊れていれば、出てくる答えも信頼できません。データ設計は、AI側だけでなく、マスターデータの棚卸しから始める必要があります。

業務プロセス診断から入った現場では何が起きたか

私たちが公開している導入事例の1つに、建設業の中堅企業があります。この企業では、AIエージェントの導入以前に、まず現場のヒアリング資料から業務の現状をAIで整理することから始めました。業務フロー・改善案・投資対効果（ROI）の試算、さらには省力化投資補助金の申請に使うExcel書類のたたき台まで、この診断のプロセスの中で一気に可視化しています。

このケースで重視したのは、会社ごとにデータが分かれる仕組みと、社内承認・ガバナンスへの対応、そして内製化です。AIエージェントを入れる前に、まず「何をどう判断しているか」を洗い出したことで、ROIの試算も、補助金の申請書類も、後付けの説明ではなく、業務の実態に基づいた数字として提示できました。私たちの実感では、この順番を踏んだ企業ほど、導入後に「思っていた通りに動かない」という手戻りが少なくなります。

ROI計算式を知っていても、稟議が通った後に止まる理由

ROI計算式のガイドの多くは、「稟議をどう通すか」で締めくくられています。ただ、私たちが現場で見てきた課題は、その先にあります。稟議が通り、予算が付いた後に、なぜか展開が止まるという現象です。

ある大手建材メーカーの情報システム部長は、複数のシステムを部署ごとに別々に作る方針について「よろしくない。最適なやり方とセキュリティ要件を見定めないと、正直、一時の投資になってしまう」と警戒していました。稟議の時点では「投資」として承認されたものが、データがつながらないまま個別最適で広がると、結果的に「一時の投資」で終わってしまう。この懸念は、私たちが複数の企業で耳にするものです。

ある大手化学メーカーの執行役員も「一度作ったら、メンテナンスはさすがにできない。ある程度は内製化していかないと世の中の力についていけない」と語っていました。これはAIエージェントに限った話ではありません。稟議の時点で計算したROIは、あくまで導入時点の一時的な見積もりです。データがつながらないまま個別最適で広がっていくシステムは、稟議を通した瞬間から陳腐化が始まります。

ROI計算式は投資判断の入口には有効です。ただ、投資が本当に回収されるかどうかは、その後のデータ設計次第で決まります。稟議書に書いた数字と、現場で実際に動き出した後の数字がずれていく企業ほど、この後工程のデータ設計を後回しにしていたケースが目立ちます。より広い費用対効果の考え方については、製造業AI導入のROI——費用・投資回収・失敗コストを正直に公開するでも詳しく触れています。

私たちがPoCの前にBPRから入る理由

こうした背景があるため、私たちAI-Pathは、AIエージェントのPoC（概念実証：小規模な検証で効果を確かめること）を始める前に、まず業務プロセス診断（BPR）から着手することを基本にしています。使うのは代表が自作した業務整理ツールです。現場へのヒアリングから、業務フロー・改善案・ROIの試算までを、たたき台としてまず可視化する進め方です。

誤解のないように言えば、これは「まずコンサルティングを売る」という意味ではありません。むしろ逆で、PoCの段階で無駄な投資をしないための下準備です。硬いデータと柔らかいデータの分離、マスターデータの品質確認は、この診断の中で同時に見えてきます。

私たちの実感では、ここを飛ばしてAIエージェントの選定から始めた案件ほど、後から「データがつながらない」という理由で止まりやすいと感じています。PoC止まりから抜け出す進め方については、製造業でAI導入が失敗する本当の理由——PoC止まりを脱した現場が実践した定着化の3ステップでも整理していますので、あわせてご覧ください。

ある特注プラントメーカーの技術主事は「全部任せるより、ノウハウを共有して二人三脚で作りたい」と話していました。同社ではすでに、AIサーバーを自社に置いてローカルでLLM（大規模言語モデル）を動かす検証にも着手しているといいます。私たちが伴走する目的は、AIエージェントを納品して終わることではありません。データ設計の考え方そのものを、顧客企業のチームに残すことです。技術顧問として月次の定例を回しながら、現場の担当者が自分たちでデータの状態を点検できるようになるまでを、伴走の範囲に含めています。

まず試すなら

冒頭の化学メーカーのCFOの質問に、その場ですぐ答えられる会社とそうでない会社の違いは、突き詰めれば「聞かれる前からデータの設計ができていたか」に尽きます。いきなり全社展開を考える必要はありません。私たちが推奨するのは、次の3つです。

• 直近のAIエージェント導入（検討中含む）で、判断に使わせているデータが「硬いデータ」と「柔らかいデータ」のどちらに当たるか、一度棚卸ししてみること
• 対象業務のマスターデータ（部品・取引先・製品コードなど）の重複や表記ゆれを、まず1つの部門だけでチェックしてみること
• ROIを計算する前に、その業務の「今のやり方」を担当者にヒアリングし、行間に残っている判断基準を書き出してみること

どの項目も、大掛かりなシステム改修は必要ありません。棚卸しとヒアリングだけで、次にどこへ投資すべきかの優先順位が見えてきます。

AI-Pathでは、無償の業務プロセス診断（BPR）を実施しています。自社のAIエージェント導入が、データ設計の観点からどこに課題を抱えているか、まずは診断から始めてみませんか。

よくある質問

Q. データ設計を先にやると、AIエージェント導入までの時間が延びませんか。

私たちの経験では、逆の結果になることが多いです。データが未整理のままAIエージェントを入れると、後から「使えない」と判明してやり直しになるケースの方が、結果的に時間を要します。診断自体は数週間で完了し、たたき台は1日で動くプロトタイプとしてお見せできます。稟議のスケジュールに合わせて診断を先行させる進め方をとる企業も、実際には少なくありません。

Q. マスターデータの整備は自社でどこまでやるべきですか。

すべてを一度に整備する必要はありません。私たちの現場経験では、まず1つの業務・1つの部門に絞ってマスターデータを見直し、そこでAIエージェントの効果を確かめてから範囲を広げる進め方が、最も確実です。全社のマスターデータを一括で直そうとすると、着手までに時間がかかりすぎてしまいます。

Q. ROI計算式を使うタイミングはいつが適切ですか。

データ設計が一定整った後です。データが整っていない段階でROI計算式だけを先に固めても、測定対象そのものが安定していないため、数値の信頼性が下がってしまいます。稟議用の試算と、運用後の実測は分けて考えるほうが現実的です。稟議用の試算は「見込み」として提示し、運用後3ヶ月から6ヶ月のデータで実測値に更新する、という2段構えを私たちは推奨しています。

Q. 「エージェント・ウォッシング」かどうかは、導入前にどう見分ければいいですか。

私たちが確認するのは、提示された製品が「業務目標を自律的に達成できるか」「例外的な状況で人に判断を戻す仕組みがあるか」の2点です。既存のRPAやチャットボットの延長線上にある製品は、この2点のどちらかが弱い傾向があります。デモの段階で、想定外の入力を与えてみると、実際の自律性が見えてきます。

参考リンク

• Customertimes「AI Agents in Manufacturing: 2026 Report」
• Gartner「Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027」