生成AI動向n8n×Claudeで装置仕様書を自動生成——設計業務を半減するワークフロー構築ガイド
Co-pilotからAgentic AIへ——温度異常検知が単発で終わる工場と、計画参照→機械調整→保全WO発行まで自動連鎖する工場の構造的な差
2024〜2025年は、製造業の生産現場が「生成AIを試しに入れる」段階でした。2026年に入って各社のIRや展示会発表を見ると、論点は明らかに次の段階に移っています。Hannover Messe 2026では、NVIDIAやSiemensが「指示を出して文書を作るAI」ではなく、「異常を検知したら、生産計画を読み、機械パラメータを調整し、保全ワークオーダーを自動発行するAI」を前面に出し、Bain & CompanyやMicrosoftも同じ論点を整理しました。本稿では、温度異常検知という1つの題材を入口に、「Co-pilot型のAI」と「Agentic AI」がなぜ別物なのか、そしてその差が業務OSの完成度をどう決めるのかを、4つの自動連鎖の構造で分解します。
もくじ
Co-pilot型AIが工場で定着しない構造的な理由
2024〜2025年に多くの製造業が導入したのは、いわゆる「Co-pilot型」のAIでした。設計者の隣にいて、文書ドラフトを出してくれる。品質担当の隣にいて、過去トラブル事例を要約してくれる。ここまでは確かに動きます。ただし、ここから先に進めずPoC（実証実験）段階で止まる現場が圧倒的多数です。原因は3つに整理できます。
- 検知だけで「次の判断」を担えない：温度異常を検知してもアラート通知が出るだけで、誰がいつ何を判断するかは人間任せ。判断の起点が人間のまま動かない
- 既存システム（MES／ERP／PLM）と業務がつながらない：AIは独立した「便利な相棒」のままで、計画系・記録系のシステムを参照したり書き換えたりしない。結果、AIの提案を人間が手作業で再入力する二度手間が発生
- 業務フローの中に組み込まれていない：標準作業手順書（SOP）の中にAIの介入位置が定義されていないため、現場担当者の余裕がない時に真っ先に使われなくなる
この3つを別の角度から言い換えると、「現場の業務そのものを実行する仕組みが手付かずのまま、知的アシスタントだけを追加した」状態です。この構造は、業務基盤の議論でも繰り返し指摘されてきました。
ERPは「お金とモノの記録台帳」、PLMは「図面とBOMの保管庫」であり、いずれも「業務そのもの」を実行する仕組みではない
業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体
Co-pilot型AIはここに「便利な助手」を1枚追加するに留まり、業務そのものを実行する層を空白のままにしてしまいます。だから現場で2〜3か月使うと「結局Excelに戻った」「人手で再入力している」という声が出始め、PoC終了とともに静かに消えていきます。
業務OSを完成させる「4つの自動連鎖」
Agentic AIが業務OSとして機能するためには、検知→参照→判断→実行→記録の連鎖が、業務単位で動かなければなりません。製造現場で先行的に検証されている4つの自動連鎖を、ここで一つずつ整理します。いずれも単発の機能ではなく、複数の既存システム（MES／ERP／PLM／CMMS）に参照・書き込みする「業務単位」のAgent設計になっている点が共通しています。
連鎖1：温度異常検知 → 計画参照 → 機械調整 → 保全WO発行
生産技術部にとって最も身近な題材です。プレス加工の金型温度が閾値を超えた瞬間、Agentが本日の生産計画（残ロット・段取替え予定）を読み、製品仕様の許容温度帯を参照し、機械を安全値へ調整する一方で、CMMSに保全ワークオーダーを発行します。人間担当者は例外時（複数異常の同時発生、上長承認が必要な停止判断）のみ介入します。Co-pilot型では「アラート→人間判断」までで止まるため、休日夜間に通知が滞留することがあります。
連鎖2：設計変更通知 → 影響部品自動抽出 → 調達先連絡 → 単価見直し
設計OSと調達OSをつなぐ連鎖です。設計変更（ECN）が確定した瞬間、Agentが部品表（BOM）を遡って影響する子部品と組立体を自動抽出し、調達先別の取引リストと突き合わせ、単価見直しが必要な品番をリストアップして調達担当者の承認画面に提出します。設計DXと調達DXを別々のシステムで持っていると、変更通知の漏れが品質トラブルにつながる構造があります。
設計者が一日のうち4割を、図面を探したり、部品表をメンテしたり、設計変更を関係部署に伝えたりすることに使っている
設計OSとは——図面・部品表・設計変更を一気通貫させる業務エージェント基盤
連鎖3：品質トラブル → FMEA再評価 → 設計フィードバック → 次回DR議題化
品質OSと設計OSをつなぐ連鎖です。市場で発生した不具合がCRM／問い合わせ管理に登録されると、Agentが該当製品のFMEAを開き、再評価が必要な故障モードを特定し、設計者に「次回DRの議題として登録すべき項目」を提案します。従来は品質→設計フィードバックが「Excel報告書を月次で回覧」する形式で、再現性のない情報伝達になっていました。
連鎖4：予兆検知 → 在庫照会 → 部品手配 → 停止計画調整
生産技術と保全をつなぐ連鎖です。設備の予兆データ（振動・電流・温度）から「3週間以内に故障の確率が高い部品」を特定し、Agentが補修部品の在庫を照会し、不足分を自動手配する一方で、生産計画の停止可能枠を提案します。CMMS単独や生産管理単独では実現できない、複数システムをまたいだ業務単位のAgentが必要になります。
想定される反論と、現時点での回答
反論1：「ChatGPTやCopilotの業務版で十分では？」
ChatGPT／Copilot系は「人間の作業を加速させる」道具として優秀ですが、業務単位の自動連鎖を担うには、社内システム（MES／ERP／PLM／CMMS）への参照・書き込み権限の管理、業務ルールの定義、例外時の人間介入フローの設計、監査ログの維持が必須です。これらは汎用LLMの責務範囲を超えており、業務OSという別の基盤レイヤが必要になります。
反論2：「PLMやMESのアップグレードで対応できる」
PLMは図面・BOMの記録、MESは生産実績の記録を担う「記録層」であり、業務実行層（業務OS）とは設計責任が分かれます。PLM／MESの上に業務OSを置く構成のほうが、既存システム投資を活かしつつ業務エージェントを増減させやすく、現実的な移行経路になります。
反論3：「自社で内製して育てたほうが安い」
内製と外注の境界線は、「業務エージェントの抽象化（業務ルール×AI×システム連携）の設計力」をどこから外部に頼るかで決まります。多くの製造業は、現場の業務知見は社内にありますが、Agent設計の経験値が薄いケースが目立ちます。最初の1〜2連鎖は外部と組み、内製化チームを育てながら3連鎖目以降を自走に切り替える流れが現実的です。
自己診断ミニチェックリスト
自社が「Co-pilot型で止まっている状態」か「Agentic AIの自動連鎖に踏み出せる状態」かを確認するための5項目です。3つ以上「いいえ」なら、業務OSの設計から手を付ける段階です。
- 異常検知の通知が出た後、誰が・いつ・どのシステムを参照して判断するかが、SOPに明文化されている
- AI／ChatGPT類が提案した内容を、人間が再入力せずにMES／ERP／PLMへ書き込める仕組みがある
- 業務単位（領域横断）のAgentを設計・運用するチームと、責任分担が定義されている
- Agentが書き込みする操作には、人間承認の介在ポイントと監査ログが設計されている
- 業務OSとPLM／MESの責任境界（記録層と業務層の分離）を、社内で説明できる
FAQ
Q1. Agentic AIと生成AIの違いは何ですか？
生成AIは「テキスト・画像・コードを生成する」モデルそのものを指します。Agentic AIはそれを部品の1つとして使いつつ、検知・参照・判断・実行・記録の業務連鎖を自律的に回す仕組み全体を指します。LLM単独では業務連鎖は完結せず、業務OSという基盤の上で、業務ルール・システム連携・承認フローと組み合わさることで初めてAgentic AIになります。
Q2. 内製と外注の判断軸はどこに置けばよいですか？
「業務知見」は内製、「Agent設計の最初の経験値」は外注、「3連鎖目以降の自走」は内製、という分担が現時点では現実的です。Agent設計の経験は、業務OSのアーキテクチャ、業務ルールの抽象化、システム連携の権限管理など、汎用ITスキルとは別の専門領域として育っています。
Q3. スモールスタートは可能ですか？最初の1連鎖は何にすべき？
可能です。むしろ4連鎖を同時に始めるのは現実的ではありません。「業務単位の連鎖が一本通る」体験を6〜10週間で作るのが第1ステップです。多くの現場で最初の1本目に選ばれているのは、参照系のシステムが2〜3個に収まり、人間承認の介在ポイントが明確な連鎖2（設計変更→部品抽出→調達連絡）または連鎖4（予兆→在庫→停止計画）です。
次のアクション
本記事で示した4つの自動連鎖のうち、自社で最初の1本目を立ち上げる場合、業務領域・参照システム数・承認フローの3点で6〜10週間の実装計画を組むことが現実的です。業務OS設計と最初のAgent実装を一緒に検討したい方は、業務診断（無料・60分）で現状の業務領域とシステム構成を整理しています。
関連記事：次に読むべき3本
