製造業の生産管理システムには、いくつもの現場で向き合ってきました。そこで繰り返し見てきたのが、ERPが「導入されているのに回っていない」状態です。製造業 AI 自動化 / ERP AI 連携 / 製造 DXと言葉は変わっても、現場で問われているのは同じ一点――受注はFAXとメールで届き、担当者が内容を読み取ってERPへ手で打ち込む、その手作業をどう外すかにあります。

在庫の数字はシステムにあるのに、いつ何を発注するかはExcelと経験則で決めている。データはそろっているのに、データとデータの「あいだ」に人の手が挟まったままなのです。埋めるには、いきなり全部ではなく現実的な順番があります。受発注、在庫、報告――手作業が集中する工程から一つずつ、6か月というモデルケースで工程を追っていきます。

製造業のERPにAIエージェントをつなぐと、何が自動化できるのか

つなぐことで自動化できるのは、受発注の入力、在庫の引当と発注判断、実績報告の集計という、ERPのデータを読み書きする定型の3工程です。AIエージェントがERPの受注・在庫・実績データを読み、判断し、書き戻すことで、人が転記や集計に費やしていた時間が空きます。

チャットボットとの違いは、答えるだけで終わらないところにあります。問い合わせに文章で応じるのがチャットボットだとすれば、AIエージェントはERPの画面やAPIを操作し、受注を起票し、発注案を作り、レポートを下書きするところまで動きます。人が最後の承認を握ったまま、手前の作業だけを渡すイメージです。

自動化の対象になりやすいのは、判断基準を言葉にできる定型業務です。「この取引先のこの品目は、在庫がこの水準を割ったら発注する」といったルールが決まっている工程ほど、エージェントに任せやすくなります。逆に、例外交渉や新規サプライヤーの選定のように毎回判断が変わる工程は、人が持ち続ける領域として残します。

たとえば受注入力なら、届いた注文書からエージェントが品目コード・数量・希望納期を読み取り、ERPに起票する手前まで進めます。人はエラーになった数件だけを確認すればよく、正常な大半の受注は目視の対象から外れる。作業の総量ではなく、人が見るべき対象を減らすのが自動化の効き方です。

見落とされやすいのが、工程と工程の「つなぎ替え」です。受注が確定したら在庫を引き当て、引当がついたら生産計画へ渡す。この受け渡しを人がメールや口頭で回している現場では、抜けや二重処理が起きます。エージェントを挟むと、前工程の結果をそのまま次工程の入力として渡せるので、工程間の待ち時間と連絡ミスが減ります。

なぜERPは「入っているのに回らない」のか

ERPはデータを「貯める」のは得意でも、システムをまたいでデータを「動かす」部分は人の手作業として残りがちだからです。受注の入力、在庫の判断、実績の集計は、どれもERPの内と外を人が橋渡ししています。

経済産業省がDXレポートで繰り返し指摘してきたのも、基幹システムが老朽化し、データが部門やシステムに分断されたまま活用しきれていないという論点でした。製造の現場に置き換えると、それは受発注・在庫・生産・出荷が別々の仕組みに散らばり、つなぎ目に人が張り付いている状態を指します。

典型的な分断は3か所に現れます。1つ目は受注入力で、取引先ごとに異なるFAX・メール・EDIの様式を、担当者が読み替えてERPに入れています。2つ目は在庫判断で、ERPに在庫数はあっても、引当や発注点の計算はExcelに持ち出されています。3つ目は報告で、ERPとMES、倉庫管理システムの数字を人が集めて資料化しています。

この3か所を回しているのは、担当者の頭のなかにある「暗黙のルール」です。ルールが言語化されていないから自動化できず、属人化しているから休むと止まる。ここを外に出して、機械が読める形にしていく作業が、自動化の実体になります。

もう一段掘ると、回らない理由は「例外の多さ」にも行き着きます。特急注文、仕様変更、返品――標準フローから外れる案件を、担当者がその都度手作業でさばいている。標準の8割をエージェントに任せ、残る2割の例外に人の時間を寄せる。この配分こそが、入っているシステムを実際に回すための出発点になります。

6か月自動化シナリオ：どの工程を、どの順で自動化するのか

順番は、受発注入力 → 在庫引当・発注点 → 実績報告の3段構えが現実的です。手作業が集中していて効果が見えやすく、判断の難易度が低い工程から始め、2か月ごとに対象を広げていきます。

この順にする理由は、リスクと効果のバランスにあります。受発注入力は手作業の量が最も多く、正解が明確なので検証しやすい。在庫は判断が絡むぶん次に置き、報告は複数システムの横断連携が要るので最後に回します。以下は社員200〜400名規模の中堅製造業を想定したモデルケースで、実際の期間は現場のデータ整備状況で前後します。

第1〜2か月：受発注入力を自動化する

はじめに手をつけるのは受注入力です。取引先から届くメールやPDFの注文書、EDIデータをAIエージェントが読み取り、品目・数量・納期を抽出します。抽出した内容は、単価マスタや与信、在庫の情報と照合したうえで、ERPの受注テーブルに起票します。

抽出する項目は最初に固定します。品目コード・数量・希望納期に加え、単価・支払条件・出荷先を注文書から読み取り、単価マスタや与信の情報に突き合わせる。読み取れなかった項目や、マスタと食い違う値には「要確認」の印をつけ、そのまま登録待ちの列へ送ります。

ここで外せないのが、登録前の承認キューです。エージェントが抽出した受注は、いきなり確定させず「登録待ち」に積みます。一定金額を超える注文や、新規の取引先、マスタに無い品目は人が目視で承認する。こうすれば、読み取りミスがそのまま基幹データを汚す事故を避けられます。

取引先ごとに書式が違う点も、この2か月で吸収します。同じ「納期」でも、FAXの手書き、Excel添付、EDIの固定長と、入り口の形はばらばらです。取引先別の読み取りパターンをエージェントに覚えさせ、初めて見る書式や特急・仕様変更のように標準から外れた注文は、通常フローに混ぜず「要確認」の別列へ切り分ける。標準の受注を止めないまま、例外だけを人の目へ寄せるためです。

この2か月で見る数字は、転記に費やす時間と、読み取りの誤りが後工程で見つかる率の2つに絞ります。エージェントの抽出結果と担当者の最終入力の差分を監査ログで毎日ふり返り、単位の取り違えやFAXの手書き誤読といった癖を洗い出す。癖が見えるほど、自動で通してよい範囲を安心して広げられます。

最初の2か月は、精度そのものよりも「どの条件を人が見るか」の線引きを固める期間だと考えています。エージェントの抽出結果と担当者の判断のズレを監査ログで見ながら、自動で通す範囲を少しずつ広げていきます。

第3〜4か月：在庫引当と発注点を自動化する

受注が安定して流れ始めたら、在庫の判断に進みます。AIエージェントがERPの在庫数・受注残・入荷予定・リードタイムを読み、品目ごとの発注点と適正在庫を計算して、発注案を作成します。倉庫の実在庫とERPの理論在庫がずれる場合は、その差異も検知の対象に含めます。

発注点は、平均需要とリードタイム、需要のばらつきから安全在庫を置いて算出します。季節性のある品目は過去の出荷実績で補正し、共通部材は複数製品の受注残を合算して引き当てる。理論在庫と倉庫の実在庫がずれたときは、その差異自体を「棚卸しの合図」として検知の対象に含めます。

リードタイムそのものも、固定値では扱いません。同じ部材でも、サプライヤーや時期で入荷までの日数は動きます。過去の入荷実績からばらつきを見て、遅れがちな品目には安全在庫を厚めに、安定した品目には薄めに置く。この調整を品目ごとに機械が持てば、担当者は勘に頼らず発注点を決められます。

発注案は、あくまで案のまま承認へ回します。安全在庫の係数や、複数サプライヤーの優先順位といった経営判断が絡む設定は、人があらかじめルールとして与えておく。エージェントはそのルールに沿って計算するだけで、最終的な発注ボタンは購買担当が押す形にします。

発注案には、なぜその数量になったのかの根拠――対象の受注残、入荷予定、適用したリードタイム――を並べて添えます。購買担当は数字だけでなく理由を見て承認でき、最低発注ロットやサプライヤーの優先順位といった条件は、あらかじめルールとしてエージェントに渡しておきます。

この段階で効いてくるのが、欠品と過剰在庫の予兆通知です。「このままの受注ペースだと、来週この品目が安全在庫を割る」という警告を先に出せると、担当者は火消しではなく準備に時間を使えるようになります。

第5〜6か月：実績報告と在庫レポートを自動化する

最後は報告です。ERP・MES・倉庫管理システムに散らばった生産実績・在庫・受注状況を、AIエージェントが横断して集計します。日次のサマリーや、納期遅延・欠品予兆といった異常の検知結果を関係者へ通知し、月次レポートの下書きまで作ります。

横断集計でつまずきやすいのは、システムごとに品目コードや単位、締めのタイミングが違う点です。まずコード対応表と単位換算、日付の基準をそろえてから集計に入る。この土台を作らずに数字を足すと、合計は出ても意味が合わない報告になってしまいます。

コード対応表は、一度作って終わりではありません。新しい品目や取引先が増えるたびに、どのシステムのどのコードが同じものを指すのかを追記していく。この対応表の手入れを止めた瞬間から、集計値は少しずつ実態とずれ始めます。

ここでも、確定と配信は人が握ります。エージェントが作るのは下書きで、経営会議に出す数字は担当者が確認して確定させる。どの数値がどのシステムの、いつのデータから来たのかを、すべて監査ログでたどれるようにしておくのが、報告を任せる前提です。

通知は、全員に同じ量を送らないよう宛先と粒度を分けます。現場には欠品予兆と当日の異常、管理層には週次の傾向と遅延の兆し。エージェントが下書きし、経営会議に出す確定値は担当者が承認する――この分担を崩さないことが、報告を任せ続けられる条件です。

6か月を終えると、受発注・在庫・報告という日次の反復作業の多くがエージェント側に移り、人は承認・例外対応・改善の設計に回ります。全部を一度に変えないぶん、どこかでつまずいても切り戻せる――この安全余裕が、製造現場で自動化を続けられるかどうかを分けます。

付け加えると、6か月はゴールではなく起点です。自動で通す範囲、承認を残す条件、通知の宛先は、運用しながら毎月見直していく。工程を固定せず、監査ログで見えた実態に合わせて少しずつ調整し続けることが、製造DXを一度きりの導入で終わらせないための勘所になります。

AIエージェントはERPのデータをどう読み書きするのか

読み書きの経路は、公式API・画面操作（RPA型）・データベースの参照という3つが基本で、それぞれに承認・権限分離・監査ログという制御ポイントを置きます。書き込みは最小権限にとどめ、まず読み取りから始めるのが安全です。

一番望ましいのは、ERPが公式に提供するAPIを使う経路でしょう。入出力の仕様が明確で、権限も細かく設定できます。APIが無い、あるいは古い基幹システムの場合は、画面を操作するRPA型の連携や、参照専用でデータベースを読む経路を組み合わせます。どの経路でも、書き込み権限は必要な範囲だけに絞ります。

制御ポイントは3つに整理できます。1つ目は承認キューで、エージェントの操作を実行前に人が止められる状態にしておく。2つ目は権限分離で、読み取り用と書き込み用のアカウントを分け、エージェントが触れる範囲を限定する。3つ目は監査ログで、いつ・どのデータを・どう操作したかを後からたどれるようにします。

この3つは、運用が始まってから足すのではなく、最初の設計に組み込みます。承認を通らない書き込み経路が一本でも残れば、そこが抜け穴になる。私が連携を設計するときは、エージェント用のアカウントに与える権限を洗い出し、書き込める範囲を一覧にしてから運用に入ります。

読み取りと書き込みで、慎重さの度合いを変えるのも要点です。読み取りは範囲を広げても実害が小さいので早めに広げ、書き込みは金額や取引先の条件で段階を分ける。低リスクな更新から一つずつ開放し、想定外の挙動が出たら承認キューで止める。この非対称が、安全と効率の両立を支えます。

段階を踏むなら、最初はすべて読み取りから入るのが定石です。データを読んで提案するところまでをエージェントに任せ、書き込みは人が実行する。運用に慣れて誤りのパターンが見えてから、低リスクな書き込みを一つずつ開放していきます。kintoneのような業務プラットフォームと基幹システムをまたぐ連携の勘所は、[kintoneとSAP・外部システムをAIエージェントでつなぐ実装シナリオ](/ja/blog/kintone-sap-ai-renkei/)でも別の角度から整理しました。

基幹データを外に出さずに自動化できるのか

できます。オンプレミスや専用環境での連携、扱うデータの最小化、通信の暗号化、監査ログという構成で、基幹データを外部に流出させずに自動化する設計が組めます。

製造業のデータには、原価、取引条件、生産能力といった競争力に直結する情報が含まれます。だからこそ「自動化のために外部にデータを預ける」ことへの警戒は当然で、私自身も設計の最初に境界線を引きます。どのデータがどこまで出て、どこから先は出さないのか。この境界を曖昧にしたまま進める連携は、あとで必ず問題になります。

外部流出を防ぐ基本は、データを最小限しか動かさないことです。エージェントが判断に使う項目を、その工程で要るものだけに絞る。処理をできるだけ自社の管理下に置き、外に出すものは暗号化し、出したログも記録します。学習に使われない・目的外に転用されないという条件は、契約と構成の両面で確かめておきます。

ここで注意したいのは、認証の取得状況を確認しないまま「安全です」と言い切らないことです。どの認証を持ち、どの範囲を第三者が監査しているのかは、導入前に一次情報でたしかめるべき項目でしょう。セキュリティは形容詞で語るものではなく、構成とログで示すものだと考えています。

「作る」ツールと「動かす」プラットフォームは何が違うのか

開発者向けのツールは自動化の仕組みを「作る」自由度が高い一方、作った後の運用・監視・改修は自社の負担になります。完全管理型のプラットフォームは、その運用まで含めて「動かし続ける」ところを引き受ける点が違います。

Difyやn8nのような開発者向けツールは、柔軟で自由度の高い選択肢です。手を動かせるチームが自社仕様に作り込むなら、これほど都合の良いものはありません。ただし、作った自動化は放っておいても動き続けるわけではなく、仕様変更や障害への対応、日本語での運用は自社が持ち続けます。どちらが向くかは、社内に運用できる体制があるかどうかで変わります。

業務チームが運用まで自分たちで抱えるのが難しい場合に向くのが、完全管理型です。ここでWindyFloが立つ位置を一言で言えば、こうなります。ChatGPTは答えます。WindyFloは働きます。答えを返すだけでなく、ERPに触れて受注を起票し、発注案を作り、レポートを下書きするところまでを、日本語の運用込みで引き受ける発想です。

「作る」で止めるか「動かす」まで行くかの線引きは、製品の優劣ではなく用途の違いにすぎません。この判断軸は[DifyとWindyFloの「作る」と「動かす」の境界](/ja/blog/dify-vs-windyflo-jikko/)でより詳しく扱っています。

自動化を始める前に、何を確認すればいいのか

先に確認したいのは、ERPが外部連携できるか（APIや連携手段の有無）、データの権限と承認フローを誰が持つか、現場に運用と例外対応を担う体制があるか、の3点です。この3点が曖昧なまま始めると、途中で止まります。

1つ目は連携の入り口です。使っているERPや生産管理システムに、外部からデータを読み書きする手段があるか。無い場合でも画面操作や参照経路で代替できますが、選べる連携方式で設計も工数も変わるので、最初に棚卸ししておきます。

2つ目は権限と承認の設計になります。どのデータを誰が見てよく、どの操作を誰が承認するのか。この線引きは自動化の前提であって、後付けでは効きません。3つ目は現場の体制で、エージェントが出した提案を承認し、例外を拾う担当を実際に置けるかを確かめます。自動化しても、承認と例外対応の役割は人に残るからです。

自社の生産管理システムで何がつなげて、どこから自動化できるかは、データ構成を見ないと具体的には言えません。製造業ごとの連携シナリオと自社環境での進め方は、WindyFloの無料トライアルと業種別の相談で、実際のデータの流れに沿って確認できます。物流分野で同じ考え方を当てはめた例は[物流3PLの配車・在庫・問い合わせをAIでつなぐ事例シナリオ](/ja/blog/butsuryu-3pl-ai-jidoka/)にまとめました。

よくある質問

出典・情報源

• WindyFlo 製品サイト（https://windyflo.com） — WindyFloの連携方式・運用範囲・業種別の適用に関する記述の出所。
• 経済産業省「DXレポート」（www.meti.go.jp） — 基幹システムの老朽化とデータ分断という背景論点の参照元。具体的な数値は引用していない。
• 本稿の6か月シナリオおよび制御ポイントの記述は、WindyFlo技術チームによるERP連携の実装知見に基づくモデルケースです。特定企業の実在事例ではなく、中堅製造業で一般的に見られる工程を一次情報として構成しています。