製造業がレガシーシステムに AI をつなぐ方法：ERP 置き換えではなく、レポートと作業指示から始める

製造業で AI の話をすると、会話はよく一文で止まります。

「うちのシステムは古すぎる。」

ERP は 10 年動いている。MES は何年も前にカスタマイズされた。倉庫管理と設備記録は別ツールにある。生産レポートはまだ Excel でつなぎ合わせている。AI をつなぐ方法を聞くと、ベンダーは新しい基盤、データ基盤、大規模再構築を提案しがちです。

それは正しく聞こえるかもしれません。しかし重すぎます。

多くの製造業にとって、実用的な第一歩は ERP の置き換えでも MES の再構築でもありません。早く価値を示せる二つの入口を選ぶことです。

レポートと作業指示です。

なぜ製造業は単純に「AI を足す」ことができないのか

製造 IT には三つの特徴があります。

第一に、システムが多い。 受注は ERP、生産計画は MES、在庫と倉庫移動は WMS、設備修理は作業指示システム、品質データはスプレッドシートや別ツールにあります。一つの業務質問が三つ四つのシステムにまたがります。

第二に、古いシステムが多い。 何年も前のプロセスに合わせてカスタマイズされ、今も動いているが大きく触りたくない。インターフェースは不完全で、フィールド名は一貫せず、ドキュメントは古い。

第三に、運用が重い。 すべての操作が停止、手戻り、在庫圧力、納期遅れ、設備故障、品質問題という実コストにつながります。AI を個人向けツールのように実験させるわけにはいきません。

だから完全自律のスマートファクトリーから始めるべきではありません。既存データ上で、より速く見て、正確に問い合わせ、例外を早く見つけることから始める方がよいです。

入口 1：レポート

製造業は毎日レポートを作っています。納期状況、在庫回転、生産計画達成、設備停止、欠陥率、作業指示完了率、サプライヤー遅延例外。

問題は二つです。第一に遅い。データを書き出し、整形し、結合し、ピボットに入れる。レポートができたときには問題が数日前のものになっています。

第二に、固定質問にしか答えにくい。「なぜこの顧客の注文はまた遅れているのか」と聞かれても、レポートは遅れていることは示しても、受注、在庫、生産、購買の連鎖をたどることは難しい。

製造レポートにおける AI の最初の価値は、美しいチャートではなく自然言語の追質問です。

「今週の遅延注文のうち、在庫が原因で止まっているものは？」

「今後 2 週間で必要なのに安全在庫を下回る材料は？」

「過去 30 日で停止時間が多かった機械はどれで、理由は？」

「どのサプライヤー遅延が生産計画に影響しているか？」

これは汎用チャットではありません。AI は ERP、MES、WMS、作業指示データを権限の下で問い合わせ、集計し、何が起きているか説明する必要があります。読み取り専用で十分始められます。

入口 2：作業指示

作業指示は製造業の AI パイロットに適しています。すでに構造化されているからです。

誰が問題を登録したか。
どの設備か。
問題内容。
重要度。
現在ステータス。
担当者。
修理履歴。
クローズ理由。
生産影響。

最初の能力は実用的です。設備故障履歴の要約、繰り返し問題の検出、説明文からカテゴリを推奨、期限超過作業指示の発見、ライン別の頻出例外要約、保全週報、類似過去ケース検索。

これは予知保全よりずっと近い場所にあります。作業指示データがあれば始められます。

自動化は後から

製造チームが慎重なのは正しい姿勢です。生産システムは気軽に変更すべきではありません。AI 自動化は段階化する必要があります。

レイヤー 1：読み取り専用分析。 レポートを問い合わせ、作業指示を要約し、例外を見つける。運用システムには書かない。

レイヤー 2：提案。 作業指示のエスカレーション、担当者へのリマインド、サプライヤーレビューを提案し、人が確認する。

レイヤー 3：低リスク自動化。 4 時間未確認なら監督者へ通知、同じ問題が 7 日で 3 回出たら再発としてマーク、部品が閾値を下回れば購買提案を作る。

レイヤー 4：高リスク承認。 生産計画、購買発注、在庫ロック、顧客納期、停止判断を変えるものは人間確認と監査が必要です。

保守的に聞こえるかもしれませんが、製造業では安定が派手さに勝ちます。

ERP を置き換えずに AI が理解するには

既存 ERP やデータベースを接続し、重要データを業務オブジェクトとしてモデル化するのが軽い道です。

Sales order
Production order
Material
Inventory
Purchase order
Supplier
Equipment
Work order
Quality record

オブジェクトがあれば、AI は生のテーブル名やフィールド名ではなく、注文、材料、在庫、作業指示、設備とその関係を扱えます。

権限も同じくらい重要です。工場監督者は自工場だけ、購買はサプライヤーと購買データ、営業は機密コストを見ない、経営層はロールアップを見る。AI はユーザー自身の権限を超えられません。

概念図

30 日パイロット

1 週目：シナリオ選定。 工場全体ではなく、レポート 1 件と作業指示 1 件を選ぶ。例：遅延注文分析と設備修理作業指示要約。

2 週目：データ接続。 必要な ERP、MES、WMS、作業指示テーブルや API を読み取り専用で接続する。

3 週目：オブジェクトモデル化。 注文、材料、在庫、設備、作業指示をモデル化し、意味、関係、権限を加える。

4 週目：読み取り専用 AI アシスタントを開始。 マネージャーが自然言語でレポート質問をし、保全監督者が作業指示と故障履歴を問い合わせる。

最初の 1 か月でレポート準備時間、例外調査時間、問題発見速度が改善すれば価値があります。

鍵はモデルではなく境界

製造業に必要なのは、すごく聞こえる AI ではありません。何を見られ、何を見られず、どのデータを問い合わせられ、どのデータを変更できず、すべての操作がどう監査されるかを知っている AI です。

読み取り専用から始め、既存権限を継承し、高リスク操作は確認を求め、重要操作を監査し、全面移行を要求せず、コア取引書き込みではなくレポートと作業指示から始める。派手ではありませんが、着地しやすい道です。

ObjectOS のアプローチ

ObjectOS は製造業にやり直しを求めません。ERP、MES、WMS、作業指示システムはすでに動き、実プロセスとデータを持っています。より実用的なのは、それらを接続し、重要なテーブルと API をオブジェクトとしてモデル化し、AI が権限の下で問い合わせ、分析し、提案し、低リスク workflow を起動できるようにすることです。

古いシステムは動き続けます。データはその場に残ります。AI はレポートと作業指示から始め、徐々に生産、サプライチェーン、設備管理へ進みます。