製造業の設計・調達・品質・生産技術の現場で、こう感じたことはないでしょうか。「ERPも入っている。PLMも入れた。それでも図面探しは続いているし、設計変更の連絡漏れも消えない。承認の押印待ちで案件が止まる日も変わらない」と。

過去20年で、製造業は基幹システムとしてERPを、設計データ管理としてPLMを導入してきました。それでも現場の業務はそれほど軽くなっていません。理由は単純で、ERPは「お金とモノの記録台帳」、PLMは「図面とBOMの保管庫」であり、いずれも「業務そのもの」を実行する仕組みではないからです。そこで近年、第3の基盤として注目されているのが「業務OS」という考え方です。

製造業の現場業務はどこで詰まっているか

業務が詰まる場所は、おおむね3つあります。

第1に、情報の所在がバラバラです。図面はPLM、見積書はExcel、是正処置はWord、品質データは紙の検査表、サプライヤとのやり取りはメールに散在しています。検索しても見つからず、誰かに聞き、見つかった頃にはもう半日過ぎています。

第2に、業務フローと情報がつながっていません。設計変更が発生したとき、「誰に通知し、どの図面のどの部分が影響を受け、調達と品質はどう動くか」をシステムがガイドしてくれることはありません。経験者の頭の中だけにフローがあり、退職や異動でブラックボックス化します。

第3に、AIを使う前提のデータ構造になっていません。Excelで管理された仕様書やFMEAは、人間が見れば読める一方、AIに「この製品の過去の不具合パターンを抽出して」と問うても、構造化されていない散文データから意味を取り出すのは困難です。生成AIを業務に効かせるには、まず帳票・文書・記録の構造化が必要です。

これら3つの詰まりを、ERP単体・PLM単体で解こうとすると、現場は「またシステムが増えた」と感じるだけで終わります。必要なのは、情報・業務フロー・AI実行を1枚で扱う基盤です。

業務OSという新しい層の正体

業務OSとは、設計・調達・品質・生産技術といった「業務領域ごと」に、その領域の文書・データ・フロー・AIエージェントをパッケージとして束ねた基盤です。OSと呼ぶ理由は、PCのOSが「ファイルを開く」「アプリを起動する」「権限を管理する」といった共通機能を提供するように、業務OSは業務領域内の「情報を呼び出す」「フローを進める」「AIに判断させる」を共通化するからです。

ERP・PLM・業務OSの位置関係

3者の関係は次のように整理できます。

ERPとPLMは「データの保管と参照」が中心です。業務OSはその上に乗り、「日々の業務をどう進めるか」を担います。互いに置き換えるのではなく、補完する関係です。

業務OSの構成要素

具体的には、業務OSは次の4要素で構成されます。

1. 業務文書のデジタル基盤（仕様書・FMEA・是正処置・見積書・各種ログなど、Excel帳票全般を構造化）
2. 業務フローのデジタル化（承認、変更通知、レビュー、振り返りまでをシステム上で進行）
3. 業務エージェント（過去の文書・履歴・実績を参照して判断を支援するAI）
4. 既存システムとのコネクタ（ERP・PLM・MES・グループウェアと相互参照）

このうち1の「業務文書のデジタル基盤」は、製造業の業務がいまだExcelで動いているという現実から始める必要があります。Excelをやめさせるのではなく、Excelで作られた仕様書・FMEA・是正処置・見積書・各種ログを構造化したまま扱える形に乗せ替え、AIが意味を読み取れる状態にすることが第一歩です。

業務OSが想定する4領域

業務OSは業務領域ごとに分かれています。設計OSは、図面・部品表・設計変更を一気通貫で扱い、設計部門の業務エージェント基盤になります。調達OSは、見積依頼・サプライヤ評価・契約・納期管理を統合します。品質OSは、不適合・是正処置・FMEAをひとつの業務として連結します。生産技術OSは、工程設計・治具・標準作業を扱います。

各OSは独立して導入可能ですが、共通のデータ層を持つことで、設計変更が発生したときに調達と品質と生産技術が同じ情報を見て動ける状態をつくります。これが「部署横断で動く業務OS」の意味です。

自己診断ミニチェックリスト

次のうち3つ以上当てはまる場合、業務OSの考え方が役に立つ可能性が高いと考えられます。

• 図面・仕様書・是正処置がExcelやWordで管理されており、検索性が低い
• 設計変更が発生したとき、調達・品質・生産技術への通知が属人的に行われている
• 過去の不具合事例を「誰が知っているか」に依存して呼び出している
• ERPやPLMを入れたが、現場の作業時間はあまり減らなかった
• 生成AIを業務に使いたいが、何から構造化すれば良いか分からない

よくある反論への答え

「ChatGPTで十分ではないか」という意見があります。確かに、調べごとや要約、文案作成にはChatGPTで十分です。しかし、自社の過去の図面・FMEA・是正処置を踏まえた判断は、汎用LLMの学習データには含まれていないため対応できません。社内文書をAIが意味を取れる形で構造化し、その上で対話できる状態をつくることが、ChatGPTでは届かない領域です。

「内製で作れるのではないか」という意見もあります。設計部門の若手が業務改善ツールを内製する事例は増えています。一方で、業務OSは情報の所在の統一・フロー駆動・既存システムとの連携を含むため、単発のツール内製の範囲を超えます。内製と業務OSは対立せず、業務OSが土台をつくったうえで、現場が個別ワークフローを内製する形が現実的です。

「PLMを更新すれば足りるのではないか」という意見もあります。PLMの最新版は確かに進化していますが、設計データの管理が中心であり、調達・品質・生産技術の業務フローまで広く扱う設計にはなっていません。PLMを土台にしつつ、その上の業務層として業務OSを置く構図が自然です。

次のアクション

業務OSという言葉は新しいですが、求めているのは「ERPでもPLMでもない、業務そのものを進める基盤」という、製造業の現場が長年欲しかったものです。導入の第一歩は、自社の業務フローのうちどこが詰まっているかを業務分解で見ることです。

業務OSが自社にどう適用できるかを30分で整理する、業務診断（無料）を提供しています。現状の業務フロー・既存システム・想定課題を一緒に棚卸しし、最初に手をつけるべき領域を明確にします。

関連記事

• 設計OSとは——図面・部品表・設計変更を一気通貫させる業務エージェント基盤
• 設計部長が知らないと損する、図面検索の本当のコスト——年間1,200時間が消える理由
• 業務診断（無料）の申込はこちら