製造現場から見たインダストリー4.0とインダストリー5.0 — 実際に変わるのは何か

このページは逆方向から書いています。設備と作業者を起点にして、外側へ向かって説明します。

インダストリー4.0は現場で何を意味するのか

用語を取り払ってしまえば、インダストリー4.0が指しているのは一つの変化だけです。何も報告しない設備から、データが意思決定を動かす設備へ、という変化です。

プレス機が止まった場面で考えます。この変化を経ていない工場では、停止は日報に手書きされ、翌朝に表計算ソフトへ打ち直され、月次報告では原因の付いていない「停止時間」の塊として集計されます。その頃には、何が起きたかを知っていた班長はもう忘れています。数字は正しいのですが、使い道がありません。

変化を済ませた工場では、同じ停止がPLCから数秒以内に検知されます。作業者は原因がまだ目に見えているうちに、機械のそばで停止理由を分類します。計画系はその工程が枠内に収まらないことを把握し、次の指図を組み替えるか、材料の投入を止めます。同じ事象に結果が伴うようになります。

センサーの数は決め手になりません。多くの工場は、使っている量よりはるかに多くのデータをすでに生成しています。カウンタ、ドライブ、PLCは何年も前から信号を出し続けてきました。違いを生むのは閉ループです。事象が起きたその時刻・その場所でデータを取得し、文脈を与え、記録システムに保持し、それを使って動く何かに渡す。この一連がつながっているかどうかです。

生産のデジタル化も同義ではありません。紙の作業指示書をPDFに置き換えて消えるのはプリンタであって、遅れではありません。インダストリー4.0が始まるのは、データが構造化され、タイムスタンプを持ち、指図・設備・治工具・作業者に紐づいたときです。そこで初めて、下流の仕組みがそのデータで計算できるようになります。

階層構造と、それぞれの位置づけ

インダストリー4.0をめぐる議論が噛み合わない原因の多くは、違う階層の話を同じ土俵で戦わせていることにあります。ISA-95は、階層を切り分けるための実用的な語彙を与えてくれます。

設備信号（センサー、PLC、ゲートウェイ）。 実際の工場では、この層は混在しています。OPC UAを話す設備もあれば、Modbus、シリアル、あるいは無電圧接点だけしか出さない古い設備もあります。メーカーが開放しないクローズドな制御装置には、主軸・油圧回路・電源ラインに後付けセンサーを回すことになります。単一のプロトコルで揃うとは考えず、外部計装が必要になる少数の頑固な設備の分を予算に織り込んでおくべきです。IIoTゲートウェイはこの層に位置します。台車・金型・ロットが書類上どこにあるかではなく物理的にどこにあるかを知る必要がある場合のRTLSも、同じ層です。

データ取得と文脈付け。 生の信号は情報ではありません。カウンタの値は、その数量がどの指図のものか、どの治工具で作られたか、誰がそのセルを回していたか、どの直だったかが分かって初めて情報になります。この層は目立ちませんが、上位のすべてが機能するかどうかを実質的に決めています。文脈が直の終わりに手作業で付けられているなら、その不確かさは上の層すべてに引き継がれます。

MES（実行）。 現場が実際に動かされるのはここです。セルへの指図展開、工程の実績確認、機械時間と作業時間の記録、理由付きの不良・手直しの捕捉、工順と段取りの遵守、そしてロットを遡れるようにするトレーサビリティの保持。品質検査（QMS）、保全のトリガ（CMMS）、モノの移動（WMS）は、同じイベントストリームにぶら下がります。MESは、現場で何が起きたかについての記録システムです。分析は後から作り直せますが、記録は作り直せません。

計画系（MRP、APS、SCP）。 MRPとERPは、何を作るか、おおよそいつかを日単位の解像度で答えます。APSは有限能力と、実際に効いてくる制約（共用治工具、段取り替えファミリ、資格を持つ作業者、乾燥や硬化の待ち時間）に対して順序付けを行います。SCPはさらに先、サプライヤと拠点をまたいだ範囲を見ます。計画の品質は、実行側からのフィードバックで頭打ちになります。何年も測り直していない標準時間の上に有限能力計画を組めば、一日のうちに人手で組み直されます。

分析、AI/ML、コンピュータビジョン。 この層は最上位に乗るもので、下の層がなければほとんど価値がありません。下の層が揃っていれば、価値の多くが生まれる場所でもあります。表面欠陥の検査、有無判定、ラベル照合にはコンピュータビジョンが向きます。長い直の終わりには、カメラのほうが目より安定しているからです。振動や電力の波形の異常検知にはAI/MLが使えます。エネルギー監視もここに属し、消費量を生産実績に紐づけたときに有用になります。そうなって初めて、1個あたりのエネルギーを直や設備をまたいで比較できます。

ERP連携。 厳密に言えば、これは実行系と基幹系の間の継ぎ目です。指図、BOM、工順、品目マスタ、実績が双方向にこの継ぎ目を渡ります。プロジェクト工数のかなりの割合をここが消費しますが、最後にスコープされがちな部分でもあります。

インダストリー5.0が加えるもの、そして買えないもの

インダストリー5.0という言葉は、ベンダーのロードマップから生まれたものではありません。欧州委員会の政策文書から出てきたもので、後継というより修正として読むほうが筋が通ります。インダストリー4.0は「どこまで接続し、自動化できるか」を問いました。インダストリー5.0が問うのは、自動化された工場における人間の役割は何か（人間中心）、供給・需要・エネルギー価格が急に動いたとき工場はどう振る舞うか（レジリエンス）、そして生産が金銭に加えてエネルギーと材料の面で何を消費しているか（サステナビリティ）です。

これが実務上重要なのは、「インダストリー5.0」という表記が製品ページに現れはじめているからです。インダストリー5.0は買えません。買えるのはその目的に資する個別の機能であり、どのベンダーに対しても「そのうちどれを指しているのか」を尋ねるのは正当な質問です。

作業をしている人を中心に設計された作業者画面。手数が少なく、機械のそばにあり、入力した内容に対して何か有用なものが返ってくること。

指図単位・設備単位で測られるエネルギー。工程の変更を、サイクルタイムと消費量の両方で判断できること。

制約が変わったとき（サプライヤを失った、ラインが止まった、納期が前倒しになった）に組み直せる計画。しかも、その判断をする会議の場で使える速さで組み直せること。

ロット全体を廃却せずに済むよう、範囲を絞った回収を成立させられる水準のトレーサビリティ。

人間中心という部分は最も飛ばされやすく、そして定着するかどうかを決める部分でもあります。作業者をデータ入力装置として扱うシステムは、一か月のうちに回避策を編み出されます。

どこから着手するか：使われない基盤を買わないために

本当の論点は順序です。実務的に成立する順番は次のようになります。

制約から始める。 ボトルネックのセル、原因不明の停止が最も多いライン、不良が最も多い製品群。その名前を挙げてください。「YについてXが分かっていない。分からないことがZだけのコストになっている」という形で言い表せないなら、そのプロジェクトはまだ着手の段階にありません。

洞察より先に、事実を取る。 設備の稼働状態と停止理由を、可能なところは自動で、できないところは作業者の分類で取得します。後から載せるほぼすべての機能が、これに依存しています。

分析より先に、実行を回す。 MESと現場の記録が、ダッシュボードやモデルより先です。日報から打ち直したデータで学習させたモデルは、日報を学習します。

ERPの継ぎ目を最初にスコープする。 品目マスタを誰が持つのか、指図番号の採番は双方でどう対応するのか、BOM変更はどちらが正なのか、両者が食い違ったとき何が起きるのか。これをパイロットの後回しにすることが、展開が止まる最も一般的な原因です。

横展開を前提としたパイロットを選ぶ。 ラインは一本でよいのですが、設備構成と製品の流れが工場の他の部分と似ているラインを選びます。そのうえで、終了条件を文書にし、展開の責任者を名前で決めてから始めます。

モジュール構成は、使われない基盤を抱え込まないための現実的な防御策です。一モジュールずつ立ち上げられるプラットフォームは、判断が外れたときに捨てるコストが小さく、段階的に予算を付けやすくなります。スマートファクトリー化を一度に片づけようとしないほうが、結果として速く進みます。

うまくいかない典型パターン

誰も信用しないデータ。 同じ直について二つのシステムが違う数字を出し、生産会議は損失そのものより、数字の正しさをめぐる議論に終始します。対処は地味です。展開の前に、各KPIの定義を一つに合意して文書にしておくこと（OEEが計画停止と手直しをどう扱うかを含めて）、そして記録システムを一つ指名することです。

作業者がシステムを迂回する。 端末が機械から遠い、実績入力が記録対象の作業より手数が多い、入力した人に何も返ってこない。直を終わらせる最短経路が「最後にまとめて入れる」ことなら、実際にそうなります。そしてタイムスタンプは作り話になります。入力の手数は、実際の段取り替えの最中に自分で測ってください。

一本のラインから出ないパイロット。 パイロットは好奇心で予算が付きますが、横展開には予算と責任者と現場の時間が要ります。終了条件を事前に書いていなければ、成功したパイロットは恒久的な展示物になります。

後付けでスコープされた連携。 単位が合わない、品番が末尾の枝番だけ違う、BOMが二箇所で維持されている。どれも難しくはありませんが、どれもソフトウェアより時間がかかります。

誰も名指ししていない課題のために買われた基盤。 投資の根拠が「インダストリー4.0にならなければいけないから」であれば、そのシステムは導入され、デモされ、やがて開かれなくなります。

本物のプロジェクトとダッシュボード止まりを見分ける

ダッシュボードが悪いわけではありません。目に見える部分であり、必要なものです。ただ、それが全部なら、買ったのは鏡です。次の六つの問いが両者を分けます。

1. どれか一つでも、数字が行動を起こしていますか。それとも人が気づくだけで終わっていますか。 2. データは事象の時刻と場所で取得されていますか。それともメモから後で打ち直されていますか。 3. 現場が変わったとき、計画は変わりますか。それとも印刷された姿のままで、現実だけが離れていきますか。 4. 何が起きたかの記録システムがありますか。それとも他システムを覗く画面があるだけですか。 5. 作った人が辞めても動き続けますか。一人が維持している表計算ファイルへの依存は警告です。 6. ネットワークが一時間落ちたら何が起きますか。エッジ側で溜めて後から突き合わせますか、それともその直の分は失われますか。

正直な答えが「気づくだけ」「後で打ち直し」「印刷のまま」「画面があるだけ」であれば、そのプロジェクトは報告です。報告は有用です。ただ、冒頭で述べた変化ではありません。

Meta Smart Factoryの位置づけ

Meta Smart Factoryは、ここまで述べた階層をカバーするモジュール型のプラットフォームです。MES、APSとMRP、SCP、WMSと物流、品質（QMS）、保全（CMMS）、コンピュータビジョン、AI/ML、エネルギー、IIoTハードウェア、RTLS、ERP連携を含み、オンプレミスまたはSaaSで導入します。

モジュール名を挙げる理由は、上で述べた順序の議論にあります。名指しした制約一つに対して、モジュール一つから始められます。ボトルネックのセルでの設備データ取得、あるいは不良が集中する工程での品質、といった形です。そして最初のモジュールが実際に使われるようになってから、次を足す。停止理由が一件も入力されないうちにフルスタックを決める必要はありません。

プラットフォームを入れても、本当に難しい部分は消えません。数字の意味を合意すること、マスタデータを整えること、作業者が二度言われなくても実行する入力手順を設計すること。これらは共同で進める作業です。製品デモより先に、特定の工場について順序を一緒に考えるほうが、最初の会話としては有用です。