AIエージェントが企業システムを変える——PoC止まりを超えて定着させる、FDEという答え

AIエージェント 企業導入の現実——なぜ7割のPoCが止まるのか

先日、ある中堅製造業の役員とこんな会話をした。

「去年の夏、大手SIerに頼んでAIエージェントのPoCを3ヶ月やってもらいました。デモは素晴らしかった。でも本番導入の段になったら、現場から『使い勝手が悪い』と言われて、今は誰も触っていない状態です」

正直に言えば、この話は珍しくない。私たちが相談を受ける企業の7割以上が、似たような経験を持っている。

大和総研が2026年1月に発表したレポートでは、国内企業のAIエージェント導入においてパイロットが本番定着に至った割合は依然として低水準にとどまると指摘している。AIエージェントはツールとしての完成度が上がった。問題は「ツールを現場に定着させるプロセス」が設計されていないことにある。

「作る人」と「使う人」の間に誰もいない

従来のAI導入プロジェクトにおいて、SIerやコンサルファームの役割は「提案書を書き、PoCを走らせて、報告書を渡す」ことだった。本番環境での定着を担う人間は、顧客企業の内部にいる情シス部門が引き取るか、あるいは誰も担わないまま終わる。

AIエージェントの特性として、使われながら改善されるという側面がある。最初のバージョンが完璧である必要はない。ただし、「改善を担う人」が組織の内部か外部に常駐していないと、PoC時点のまま固まって陳腐化する。

技術の問題ではなく、構造の問題です——という結論に至るまでに、私たちも多くの現場で試行錯誤を重ねてきました。

AIエージェントとは何か——生成AIと何が違うのか

ここで基礎を整理しておきます。AIエージェントとは、人間が都度指示を出さなくても、自律的に判断し、複数の行動を組み合わせて目標を達成するAIプログラムのことです。

生成AI（ChatGPTやClaudeなど）は「質問に答える」ツールでした。一方、AIエージェントは「目標を渡せば、調査・判断・実行・報告まで自律的にやってくれる」レベルに進化しています。生成AIとの違いを一つ挙げるなら、「一問一答」か「自律実行」かという点です。

比較軸	生成AI	AIエージェント
動き方	人間の質問に答える	目標に向けて自律的に行動する
使い方	チャット形式でやり取り	タスクを渡すと完了まで動く
外部ツールへのアクセス	限定的	データベース・API・システムと連携
人間の介入タイミング	逐一必要	必要な箇所のみ（Human-in-the-Loop）

IBM Research が2026年に発表したエンタープライズAI導入の分析では、LLM（大規模言語モデル）単体での活用には限界があり、エージェントロジックの設計こそが企業規模での導入を成功させる鍵だと指摘している。「AIモデルの性能を上げること」と「業務に組み込むこと」は、まったく別の課題だという指摘は、私たちの実感とも完全に一致する。

なぜ2026年に「AIエージェント」が注目されているのか

背景には2つの技術的な成熟がある。

一つ目は、モデルの推論能力の向上だ。2年前のLLMは「事実を正確に答える」ことも難しかった。今のモデルは複数ステップの推論をこなし、ツールを呼び出しながら問題を解決できる。

二つ目は、MCP（モデルコンテキストプロトコル）に代表される「連携の標準化」だ。AIエージェントが社内のデータベース・ERP・在庫管理システムと接続するための共通インターフェースが整備されたことで、既存システムとの連携コストが大幅に下がった。

ただし——ここが重要なのだが——技術的な壁が下がっても、組織的・業務的な壁は変わっていない。

AIエージェント 製造業での活用——変わる3つの業務領域

私たちがFDE（フォワードデプロイドエンジニア：顧客の現場に入り込んで開発するエンジニア）として製造業の現場に関わってきた経験から、特に効果が大きかった3つの業務領域を紹介する。

1. 品質管理——異常検知から「なぜ起きたか」まで

これまでの外観検査AIは「不良品を見つける」ことができた。AIエージェントはその先まで自律的に動く。具体的には、不良を検知した後に生産ラインのデータ（温度・湿度・設備稼働ログ）と突合し、原因を特定してレポートを生成するところまでをエージェントが担う。

私たちがある大手建材メーカーで構築したシステムでは、品質管理室の担当者が毎朝2時間かけていた「不良品報告書の作成と原因追跡」が、AIエージェントが前夜のうちに完成させたものを朝15分で確認するだけになった。削減工数は月換算で約35時間になりました。

2. 生産計画——需要変動への自律対応

受注データ・在庫データ・設備稼働率を連携させ、需要変動が起きたときにAIエージェントが代替案を複数生成・提示する仕組みだ。人間の判断が必要な箇所（例えば大口顧客の優先度判断や、リードタイムを超えた発注の承認）には確認ステップを設けています。「最終判断は人間がする」という設計を最初から徹底しました。

ある化粧品メーカーのR&D部門では、需要予測AIエージェント導入後、生産計画の修正頻度が週3回から週1回に減少した。計画担当者は「修正作業」から「例外処理の判断」に集中できるようになった。

3. 技術継承——熟練工の知識をシステムに残す

製造業の最大の経営課題の一つが、退職する熟練工の暗黙知をどう引き継ぐかだ。AIエージェントは、ベテラン社員の判断パターンを会話ログ・点検記録・トラブル対応履歴から学習し、若手が「このケースではどうする？」と問いかけると、先輩の判断をベースにした回答を返す。

私たちがある中堅製作所で構築したナレッジプラットフォームでは、ベテラン技術者2名の暗黙知を音声解析とFAQシステムに組み込み、その2名が退職した後も後継者が同等の判断ができる体制を整えた。技術は社員の頭の中ではなく、システムの中に残る。

既存システムとの連携が最大の壁——ERPの現実

AIエージェント導入プロジェクトでもっとも時間がかかるのは、AIモデルの選定でも、プロンプトの設計でもない。既存の基幹システム（ERP・MES・生産管理システム）との連携だ。

製造業の多くは10〜20年前に導入したレガシーシステムを使い続けている。APIが公開されていない、データのフォーマットが部署ごとに違う、「正常値」の定義が課長と係長で異なる——という状況がほとんどだ。

私たちがある製作所で議事録管理AIを構築した際、最初の1ヶ月はシステムの技術的な実装よりも「どの部署のどのデータをどう使うか」の合意形成に費やした。技術よりも人間同士の「ルールの統一」が先に来る、というのは毎回のことだ。

MCPは「接続の問題」を解くが、「業務の問題」は解かない

2025年以降、AIエージェントと既存システムをつなぐ標準規格として「MCP（モデルコンテキストプロトコル）」が普及しつつある。MCPはさまざまなデータソース・ツールへのAPIアクセスを統一インターフェースで管理する仕組みで、接続の技術的なコストを大幅に下げた。

ただし、MCPはあくまでも「接続の技術的な問題」を解くものだ。「接続した後に何をするか」「誰がメンテナンスするか」「エラーが出たとき誰が判断するか」という業務設計の問題は、別途解く必要がある。技術が整った後に残る問いの方が、実は難しい。

データの「品質」という見落とされがちな壁

もう一つ、現場でよく直面する問題がある。データはある。しかし「使えるデータ」ではない、というケースだ。

欠損値が多い、部署ごとに単位が違う、手入力ミスが蓄積されている——製造業のデータには、こうした問題が積み重なっていることが多い。AIエージェントはデータを使って判断するため、入力データの品質が低いと出力の信頼性が下がる。「ゴミを入れればゴミが出る（Garbage in, Garbage out）」は、AIエージェント時代にも変わらない原則だ。

データクレンジングを含めた基盤整備まで視野に入れた計画が、成功する導入の前提条件になる。

PoCで終わらせないために——FDEが果たす役割

ここで私たちが実践しているアプローチを率直にお伝えする。

AI-PathのFDE（フォワードデプロイドエンジニア）モデルとは、コンサルが提案書を渡して終わりにするのではなく、エンジニアが顧客の現場に入り込み、本番コードを書き、定着まで責任を持つというモデルだ。パランティア社が発明したアプローチを、日本の製造業に適用している。

PoCが止まる根本原因は2つに収束します。「作った人が現場を知らない」か「現場の人間がシステムを信頼していない」か、です。FDEがその橋を担います。

私たちが実践する4つのフェーズ

• フェーズ1（診断）: 無償の業務プロセス診断（BPR）で「どの業務がAIに向いているか」を先に特定する。ここを省くと、効果が出にくい業務に投資してしまうリスクが高い
• フェーズ2（プロトタイプ）: 1日で動くプロトタイプを作り、現場の担当者に触ってもらう。机上の議論より、実際に動いているものを見た方が現場の意見が明確になる
• フェーズ3（本番構築）: 現場のフィードバックを翌週には次バージョンに反映しながら、本番稼働を目指す。アジャイルに、小刻みに改善を積み重ねる
• フェーズ4（定着・技術移転）: 本番稼働後は技術顧問として月次定例を継続。改善を積み重ねながら、顧客チームへの技術移転（自走化）まで責任を持つ

報告書ではなく「動いて使われているシステム」が、AI-PathのFDEの成果物です。

「何を任せ、何を任せないか」——Human-in-the-Loopの設計

AIエージェントへの委任範囲の設計は、製造現場において特に繊細な問題だ。誤動作が不良品・設備事故・顧客クレームに直結するからだ。

私たちが現場で実践しているのは「自律度レベルの段階設計」だ。一気に「全自動」にするのではなく、業務ごとにどのレベルの自律性を持たせるかを最初に決める。

レベル	内容	適用例
1: 提案のみ	AIが複数案を提示し、人間が選ぶ	生産計画の代替案、調達先の候補
2: 実行＋報告	AIが実行し、結果を人間に通知	データ集計・レポート自動生成
3: 自律実行	人間の確認なしに実行	定型メール送信・ログ記録
4: 例外時のみ人間	通常は完全自律、異常時のみアラート	在庫自動発注（上限設定内）

製造現場では、最初はレベル1かレベル2から始めることを強くお勧めします。現場の担当者がAIの判断を「信頼できる」と実感してから、徐々に委任範囲を広げる。「AIを信じてもらうプロセス」を省くと、最終的に誰も使わなくなります——これは私たちが実際に経験した失敗から学んだことです。

誤解のないように言えば、これは「人間の仕事を奪うかどうか」の問題ではありません。「人間とAIがどう協働するか」の設計の問題です。その設計を丁寧にやるかどうかで、定着率は大きく変わります。

スモールスタートは正しいか——製造現場での「最初の1手」

「まずスモールスタートで」というアドバイスは多くのAI記事で見かけます。原則として正しいアドバイスですが、製造業では注意が必要です。

製造現場では、ラインと基幹システムが密に結合している。孤立した1つの工程だけでAIを試しても、全社展開のときに「最初からやり直し」になることが多い。スモールスタートのPoCが、本番環境とは切り離された「実験場」になってしまうのだ。

「業務の範囲」を小さくするのではなく「実装の順序」を小さくする

私たちが推奨する「正しいスモールスタート」は、「業務の範囲を小さくする」ではなく「最初から全体像を見て設計し、実装の順序を小さくする」です。

1. まず業務診断で、AIを入れるべき業務を優先度順に特定する
2. 全体のシステム設計をFDEと顧客が共同で行う（最初から本番を前提とした設計）
3. 最も価値が高く、リスクが低い1業務から着手する
4. 成功体験を積んでから次の業務に横展開する

この順序でないと「PoC段階の孤島」が生まれ、後で繋ぎ直す工数が膨大になります。全体像のないスモールスタートは、スモールスタートではなく「行き当たりばったり」です。

AIエージェント 業務自動化で得られた具体的な成果

AIエージェント 業務自動化の現場で、私たちが確認できた具体的な成果を紹介します（すべて匿名化・概算）。

ある大手製作所（従業員800名）: 議事録作成・ナレッジ抽出の工数が月40時間削減。社内FAQ への質問対応をAIエージェントが担い、担当者がゼロから回答する件数が8割超減少しました。

ある化粧品メーカーR&D部門: 需要予測AIエージェント導入後、生産計画の修正頻度が週3回から週1回に減少。計画担当者の残業時間が月平均12時間減った。

ある建材メーカー品質管理部門: 不良品レポートの作成時間が1日2時間から15分に短縮。AIが前日分を夜間処理し、翌朝には完成レポートが届く運用になった。

共通しているのは、「AIが業務の全部を置き換えた」ケースは一つもないという点です。AIエージェントは人間の判断を支援し、繰り返し作業を自動化し、人間が「より価値の高い判断」に集中できる時間を作ります。「置き換え」ではなく「協働」というのが、現時点の正確な表現です。

2026年以降、AIエージェントはどこへ向かうか

Salesforce が2026年に発表したエージェント型エンタープライズの構想では、企業全体の業務システムがAIエージェントを中心に再設計される時代を示している。複数のAIエージェントが連携し、人間と協働しながら企業活動全体を支えるマルチエージェント基盤の時代が来る、というビジョンだ。

これは絵空事ではありません。ただし、現実は段階的に進みます。

2026年の今は「特定業務でのAIエージェント活用」の段階です。全社的なAIエージェント基盤が整うのは、各部門で成功事例が積み上がり、データ基盤・ガバナンスルール・人材育成が揃った先のことになります。「2026年に全社AI化を目指す」よりも「2026年中に1つの業務で着実に成果を出し、2027年に横展開する」の方が、現実的かつ持続可能な戦略です。

セキュリティとガバナンスの問題が次のフロンティア

AIエージェントが企業システムに深く組み込まれるほど、セキュリティとガバナンスの設計が重要になる。特にR&D部門や製造ラインの機密データを扱う場合、クラウドのAIサービスではなく、社内閉域のローカルLLMで構築するニーズが増えている。

私たちも、大手通信企業との協業でソブリン環境（完全自社管理のAI基盤）でのAIエージェント構築に取り組んでいる。技術的には実現可能です。ただし、構築・運用コストはクラウドAIより高くなるため、取り扱うデータの機密性と照らし合わせた設計が必要になります。

よくある質問

Q: AIエージェントの導入費用はどのくらいかかりますか？

スコープによって大きく異なります。私たちのアプローチでは、まず無償の業務プロセス診断（BPR）でどの業務にAIが適しているかを特定し、その後に費用感をお伝えしています。MVP（最初の動くバージョン）の構築は、スコープを絞れば1日でプロトタイプを動かせるレベルから始められます。

Q: 自社にAIエンジニアがいなくても導入できますか？

できます。FDEモデルでは、私たちのエンジニアが顧客の現場に入り、一緒にシステムを作ります。顧客側に必要なのは技術的な知識ではなく「業務を深く知っている担当者」がいることです。技術は私たちが担います。

Q: 既存のSAPやERPが入っていても連携できますか？

連携可能なケースがほとんどです。ただし、レガシーシステムとの連携には設計期間が必要です。まずは業務診断を通じて、どの部分から始めるかを一緒に整理します。連携の技術的な難易度よりも、「どのデータを使うか」の業務合意の方に時間がかかることが多いです。

Q: AIエージェントのセキュリティリスクはどう管理しますか？

特にR&D部門など機密性が高い環境では、クラウドAIではなくローカルLLM（社内に閉じた環境）での構築に対応しています。取り扱うデータの機密性に応じた構成を最初の業務診断でご提案します。

まず試すなら——AIエージェント導入の3ステップ

1. 業務診断から始める: まず「どの業務でAIエージェントが効くか」を棚卸しする。AI-Path では無償の業務プロセス診断（BPR）を実施しており、導入すべき優先業務を特定します。診断結果は、投資判断の材料としてお使いいただけます

2. 1日でプロトタイプを見る: 優先業務が決まったら、1日で動くプロトタイプを作って現場担当者に触ってもらいます。机上で議論するより、実際に動いているものを見た方が現場の意見が明確になり、次のステップへの判断が速くなります

3. 定着まで伴走する: プロトタイプから本番稼働、本番から現場定着まで、FDEが現場に入り続けます。「作って終わり」にしないことが、私たちのスコープの定義です

AI-Path では、無償の業務プロセス診断（BPR）を実施しています。AIエージェントの導入を検討しているが、どこから始めればいいかわからない——まずは無償診断で、どの業務にAIが効くかを明らかにしませんか。

→ お問い合わせ・無償BPR申し込み

筆者プロフィール

櫻井 文雄（さくらい ふみお）/ 株式会社AI-Path 代表取締役

小学3年生からプログラミングを始め、法学部卒業後にコンサル営業（財務・生命保険）を経験。その後、10社以上のCTO・CMOを歴任し、上場企業役員も務めた。大手コンサルファーム・AI研究開発企業でのビジネスデベロップメントを経て、VibeCodingとFDEモデルに出会い、2025年10月に株式会社AI-Pathを設立。製造業・建設業・化粧品・製薬・食品メーカーを中心に、AIエージェントの現場導入と定着を支援している。

参考リンク

• Beyond LLMs: Why Scalable Enterprise AI Adoption Depends on Agent Logic — IBM Research (Hugging Face)

• エージェント型エンタープライズとは？ — Salesforce