【製造業の経営】＃２５ 考察「オムロン、約1,067億円で米産業用PCメーカーを買収へ」
SuzukiMitsunoriオムロンは2026年10月、米国の産業用PCメーカーOnLogicとその親会社Interlogicの買収で合意した。取得価額は6億7,500万米ドル、オムロンの開示換算では約1,046億円で、買収実行は2027年1月頃を予定している。ただし、関係当局の承認などが前提条件であり、現時点では「完了済み」ではない。オムロン自身が買収目的として掲げているのは、OnLogicの産業用PC（IPC）とオムロンの高精度制御技術を組み合わせた「次世代フィジカルAIプラットフォーム」、さらにセンシング、ロボティクス、IPCを組み合わせたGEMBA DXの展開である。OnLogicのブランド、直販モデル、現経営陣は買収後も維持する方針だ。
この案件を単純な「PCメーカーの買収」と見ると、本質を見誤る。MONOistがオムロン幹部の説明として報じた構想は、PLCを高速・確実に身体を動かす“脊髄”、IPCを大量データから判断する“大脳”として組み合わせるものだ。IPCが製造データを分析し、その結果をPLCが制御へ反映することで、「作った後に分析・改善」する方式から「作りながら最適化」する方式への転換を狙う。両社は共同開発チームを立ち上げ、2030年度までにOnLogicのIPCへオムロンのPLC機能を一体化した新製品の投入を目指すと説明している。
中小製造業にとって重要なのは、「PLCがPCに置き換わる」と考えないことである。少なくとも今後数年の実装では、安全インターロック、I/O更新、モーション制御など決定論的な制御はPLC側に残し、産業用PC側に異常検知、品質予測、最適条件計算、履歴DB、生成AIや画像AIなどを置く二層構造が現実的だと考えられる。これはオムロンが説明するPLC／IPCの役割分担、既存PLCのリアルタイム機能、OnLogicが既に展開しているSoftPLC・AI対応IPCの構成から導ける実装上の推論である。
本稿の結論を先にまとめると、投資優先順位は「AIを買う」ことではなく、停止・不良・速度低下という損失を、設備データから原因までたどれる構造に変えることである。PLC＋IPCの価値は、AIそのものよりも、制御データと計算資源を同じ現場時間軸で結び付け、OEEを「月報の指標」から「その場で改善行動につながる制御指標」に変えられる点にある。オムロンは既に、設備データからOEE、良品率、サイクルタイムをリアルタイム収集・自動算出し、ライン→工程→設備へドリルダウンする仕組みを提供しており、OnLogic買収はその先の推論・最適化レイヤーを厚くする動きと読むことができる。
本稿の試算前提は、ユーザー指定に従い、従業員50名、設備20台、年間稼働時間7,000時間の「典型的な中小工場」を仮定する。既存PLC構成、ネットワーク、保守費、停止損失、予算は不明なため、後段の投資額・故障削減率などは市場価格の提示ではなく、意思決定方法を示すためのモデルケースである。
買収の戦略的意味――なぜ今、PLCと産業用PCなのか
オムロンの公式開示では、OnLogicは構成自由度の高い堅牢な産業用PCを受注生産・直販中心で提供する企業であり、2026年3月時点で従業員301人、7拠点、そのうち製造拠点2カ所を持つ。Interlogicグループの2025年売上高は1億5,420万米ドルだった。オムロンは、OnLogicの売上の9割超が米州・欧州であることも買収理由の一つとして挙げている。
MONOistの報道によれば、OnLogicはCPU、I/O、通信、筐体などの標準モジュールを組み合わせることで約100万通りの構成に対応し、グローバルで約5,500社の顧客を持つと説明されている。オムロン側は北米市場の顧客基盤獲得に加え、PLC＋IPCを「フィジカルAI実行基盤」と位置付けている。
さらに興味深いのは、OnLogicが買収前から既に「PCとPLCの境界」を越え始めていることだ。例えばHelix 524-PLCは、Intel Core Ultraを搭載するファンレス産業用コンピュータに、CODESYSベースのSoftPLCとHilscher netX系フィールドバス機能を組み合わせた製品として販売されている。別系統のKarbon 525はIntel Core Ultraに加えNVIDIA MXM GPU拡張を想定し、エッジAI用途を訴求している。Helix 522では最大96GB DDR5、複数の高速EthernetポートなどPCらしいデータ処理能力を備える。
したがって、オムロンの構想は「PLCの隣に初めてPCを置く」という話ではない。既に存在するSoftPLC／Edge AIという技術潮流に、オムロンが持つモーション、高速I/O、センシング、安全・制御技術をどう統合し、製造業向けに保証可能なプラットフォームへ仕上げるかが焦点になる、と考えるべきだろう。これは現在公表された製品仕様と2030年度の統合製品構想を踏まえた筆者の推論であり、将来製品の確定仕様ではない。
そのアーキテクチャを概念化すると、次のようになる。
ポイントは、AIからモータへ直接命令を出す構造ではなく、AIが提案または計算した設定値を、PLC側の範囲チェック、状態機械、安全ロジック、インターロックを通して実行する設計である。強化学習による産業制御の研究は進んでいる一方、安全制約をどう保証するかが主要研究テーマであり、工場で無制約な探索をさせることは現実的ではない。したがって、実務では「シャドーモード→人による承認→制約付き自動反映」という段階導入が妥当である。
PLCの従来機能を技術的に整理する
PLCの強さは単なる「ラダーが動くコンピュータ」であることではない。一般的なPCと比較した最大の価値は、設備制御の時間制約と故障時の振る舞いを、エンジニアが予測・検証しやすい形で提供することにある。
制御論理では、入力を読み込み、IEC 61131系のLD、FBD、STなどで記述されたシーケンスや演算を実行し、出力を更新する。Siemens S7-1500、Rockwell ControlLogix 5580はいずれもLD、ST/FBD系の産業制御言語をサポートしており、SiemensはIEC 61131準拠のプログラミングを明示している。
I/Oでは、センサ、近接スイッチ、エンコーダ、アナログ入力、サーボ、バルブなどと接続し、リモートI/Oを含め大量のフィールド信号を扱う。単なるI/O点数より、更新周期、時刻同期、分散I/O遅延、ネットワーク障害時の安全状態まで含めて設計する必要がある。Rockwell ControlLogix用I/Oにはイベント用途のタイムスタンプ機能なども用意されている。
リアルタイム性は、「CPUが高速」というだけではない。決められた周期でタスクが実行され、ネットワークI/Oを含めた時間挙動が予測できることが重要だ。例えばオムロンNX502はLD命令0.53ns、EtherCAT周期250μs～8ms、同期ジッタ1μs以下という仕様を持つ。Siemens CPU 1516-3 PN/DPは代表仕様でビット演算6ns、PROFINET RT/IRTに対応する。ただし、命令実行時間と実際の機械制御周期は同じではなく、プログラム量、I/O、通信、モーション軸数などを含むシステム設計で決まる。
冗長性は、CPUや通信、電源などを二重化し、片系故障時も制御を継続するための機能である。SiemensはS7-1500R/Hで同期したCPUによる高可用構成を提供し、RockwellのControlLogix 5580もStudio 5000の対応バージョンで冗長構成をサポートする。三菱電機もiQ-Rにプロセス／二重化系CPUを持つ。
安全機能は通常制御とは別に考えなければならない。非常停止、扉監視、ライトカーテン、安全速度監視などでは機能安全規格に沿った設計が必要であり、SiemensのFail-safe CPUはSIL 3／PL eまでの用途、Rockwell GuardLogix 5580は構成に応じSIL CL 3／PL eまでの用途をサポートする。三菱iQ-RにもSIL2プロセスCPUや安全CPU群がある。AIモデルの精度が高いことと、こうした安全機能が規格上保証されることは全く別問題である。
通信では、PLCメーカーごとに得意な産業ネットワークがあり、現在は上位系との接続も広がっている。Siemens S7-1500はPROFINET、PROFIBUS、OPC UAなど、RockwellはEtherNet/IPを中心にControlNet、DeviceNet等、三菱はCC-Link IE／CC-Link IE TSN、オムロンNX502はEtherNet/IP、EtherCAT、OPC UAなどに対応する。
| メーカー／代表例 | 処理・メモリの代表仕様 | I/O・リアルタイムの目安 | 主な通信 | 冗長・安全の考え方 |
|---|---|---|---|---|
| Siemens SIMATIC S7-1500 CPU 1516-3 PN/DP | ビット演算6ns、プログラム用2MB、データ用7.5MB。 | 入出力アドレス各32kB。PROFINET IRT／RTを利用可能。 | PROFINET、PROFIBUS、OPC UA、Modbus TCP等。 | 冗長はS7-1500R/H系。F-CPUはSIL 3／PL e対応用途。 |
| Rockwell ControlLogix 5580 / 1756-L85E | 最大40MBユーザーメモリ。L85Eは最大300 EtherNet/IPノード。 | 32タスク、1タスク最大1,000プログラム、イベントタスク対応。 | EtherNet/IP中心。ControlNet、DeviceNet、第三者ネットワーク等も構成可能。 | 5580は冗長アプリケーションをサポート。GuardLogixは構成によりSIL CL3／PL e。 |
| 三菱電機 MELSEC iQ-R R120CPU | LD命令0.98ns、プログラム容量1200Kステップ、プログラムメモリ4,800KB。 | 入出力点数4,096点。シリーズには高速周期制御・モーション系を含む。 | Ethernet、CC-Link IE系。CC-Link IE TSNではリアルタイム制御通信とTCP/IP通信を混在可能。 | プロセス／二重化系、安全・SIL2系CPUを別ラインで展開。 |
| オムロン NX502 | LD命令0.53ns、倍精度演算3.3ns、プログラム容量80MB。 | NXユニット最大63台をCPU直結、EtherCATスレーブ最大256。EtherCAT周期250μs～8ms、同期ジッタ1μs以下。 | EtherNet/IP×2、EtherCAT、OPC UA、DB接続サービス等。 | NX502はCIP Safetyルーティングをサポート。安全制御はSafety CPU／安全I/Oを含むシステムとして設計する。 |
この表で注目すべきなのは、PCのCPU性能とは比較軸が違う点である。PLCは巨大なニューラルネットワーク推論や画像処理ではIPCに劣っていても、**高速I/O、周期タスク、フィールドネットワーク、モーション、安全、診断という「機械を止めず、壊さず、危険にしないための機能」**を一つの制御環境にまとめている。一方IPCは、数十GB級RAM、GPU/NPU、高速SSD、コンテナ、Python／C++、AIフレームワーク、大規模時系列DBなどを使いやすい。この相互補完性こそがPLC＋IPC統合の経済合理性である。OnLogic自身がAI向けGPU搭載IPCとSoftPLC IPCの双方を商品化していることは、その方向性を端的に示している。
PLC＋IPC・AIで現場はどう変わるか
変化は「AIが工場を全部自動運転する」という一足飛びのものではない。最初に起きるのは、PLCから既に出ているデータを、より高頻度・高文脈で利用できるようになることである。
| 業務 | 現在の典型 | PLC＋IPC・AI後の姿 | 必要なデータ |
|---|---|---|---|
| 稼働監視 | PLC状態、HMI、日報から停止時間を集計 | サイクル、設備状態、アラーム、電流等を時刻同期し、OEE低下をリアルタイムで設備までドリルダウン。オムロンは既にOEE、良品率、サイクルタイムの自動収集・表示を提供している。 | RUN/STOP、サイクル開始終了、品種、数量、アラーム、PLCタグ |
| 異常検知 | 上下限値、熟練者の音・振動判断 | 正常波形や多変量の相関をモデル化し、故障に至る前の「普段と違う」を検知。オムロンのAIコントローラ研究では制御周期同期データから学習し、リアルタイム外れ値検知を行う方式が示されている。 | 振動、電流、温度、圧力、トルク、位置、サイクル波形 |
| 最適運転 | 経験則で速度・温度・圧力等を設定 | IPCが品質、エネルギー、タクト、摩耗を同時評価し、許容範囲内の設定値を提案。将来的にはPLCへ自動反映。RLによる産業プロセス最適制御研究も進んでいる。 | 設定値、実績値、品質、エネルギー、設備状態 |
| 品質予測 | 工程後の測定・抜取検査 | 加工途中のプロセスデータから完成時品質を推定し、不良になる前に条件修正。Predictive Quality研究では工程データから製品品質を推定するML/DL手法が体系化されている。 | 原料ロット、レシピ、温度、圧力、トルク、画像、寸法・検査結果 |
| 工程自動調整 | 不良発生→原因解析→次ロットで条件変更 | 異常傾向→IPC推論→制約チェック→PLCへ補正値→次ワークまたは同一工程で修正。オムロンが説明する「作りながら最適化」に近い。 | 上記＋許容範囲、安全制約、設備状態 |
| サプライチェーン連携 | ERP/MESと設備が別管理 | 品番・ロット・原料・設備状態・品質を一つの時系列にし、品質リスクや設備能力を生産計画、在庫、調達へフィードバックする方向へ発展。オムロンNX502自体にも上位DBやOPC UAとの接続機能がある。 | 製造指図、品番、原料ロット、在庫、納期、設備能力、品質 |
特に異常検知では、「何Hzでデータを取るか」がモデル選択以上に重要になる。オムロンの技術論文では、制御タスクと同期した0.5ms周期でセンサ波形を取得した例が紹介され、従来の数ms～数百ms間隔では失われる波形情報を保持できるとしている。つまりPLC＋IPCの価値は、クラウドへ大量のデータを送ることではなく、機械に近いところで、制御イベントと同期した高解像度データを選別・解析できることにある。
品質面でも同様で、TercanとMeisenの製造業におけるPredictive Qualityのシステマティックレビューは、工程データと品質測定を結び付け、製品品質をデータ駆動で推定する研究が幅広く行われていることを整理している。したがって、最終検査の合否だけをAIへ与えるより、「その部品がどの設備・レシピ・原料ロット・加工条件を通ったか」を結び付ける方が重要になる。
短期は「AI制御」より可視化と予兆検知の方が費用対効果を出しやすい。Predictive Maintenanceについては、機械学習を利用した故障予測・異常検知の研究蓄積が既に大きく、オムロン自身も状態監視データによる予知保全を商品・技術の両面で展開している。
中期になると、Predictive Qualityと設定値最適化を組み合わせ、「品質を予測する」から「不良になる前に条件を直す」へ進む。ただし設定変更は、設備メーカーが保証する上下限、製品規格、機能安全、工程能力の範囲内に拘束する必要がある。
長期の強化学習は魅力的だが、実工場で自由探索するのではなく、過去データ→シミュレータ／デジタルツイン→オフライン学習→シャドー運転→制約付き本番という順序が有力だ。産業制御におけるSafe RL研究も、制約・安全性の担保を主要課題として扱っている。
OEEは「集計KPI」から「原因推定と制御のループ」へ
OEEは一般に時間稼働率×性能稼働率×良品率で計算される。オムロンも同じ定義を採用し、OEEは工場や工程ごとに指標の前提が異なるため、単純な外部比較より各工場のボトルネック改善に使うことが重要だとしている。
従来型のOEE活動では、停止時間、不良数、速度低下を記録し、日・週・月単位でパレート分析し、人が原因を探すことが多い。既にリアルタイムOEE自動算出は実用化されているため、「従来＝必ず紙の日報」という意味ではない。今後変わるのは、OEEの値を表示するだけでなく、OEE悪化の原因候補を機械状態から即座に推定し、将来のOEEまで予測することである。オムロンの設備監視システムも、現在の段階でライン・工程・設備間のKPIを関連付け、ドリルダウン分析する方向へ進んでいる。
| 観点 | 従来型OEE管理 | PLC＋IPC・AI型 | 主KPI | データ要件 | 実装ステップ |
|---|---|---|---|---|---|
| 停止ロス | 停止後、理由コードを入力して集計 | PLCイベント、アラーム、振動・電流等から原因候補をリアルタイム推定 | Availability、停止回数、MTBF、MTTR | 状態遷移、アラーム、保全履歴、波形 | 自動停止判定→原因分類→予兆モデル |
| 速度ロス | 実績CTと標準CTを比較 | 品種、工具摩耗、負荷、温度等から速度低下要因を推定 | Performance、CT偏差、チョコ停時間 | サイクル時刻、品種、速度、負荷 | CT自動取得→条件別基準→異常推定 |
| 品質ロス | 完成後の不良分析 | 工程中に不良確率を予測し、条件修正候補を生成 | Quality、不良率、FPY、予測Recall/Precision | 品質ラベル＋工程時系列＋材料ロット | トレーサビリティ→モデル→工程内判定 |
| 保全 | 時間基準で定期交換 | 状態監視＋故障確率／RULで交換時期を変更 | MTBF、予兆リードタイム、緊急停止数 | 振動、温度、電流、交換記録 | CBM→PdM→保全計画連携 |
| 最適化 | 会議で設定値変更 | AIが複数KPIを評価し、制約内設定値を推奨／自動反映 | OEE＋エネルギー＋品質＋寿命 | 状態・行動・結果の時系列 | Shadow→Human-in-loop→制約付きClosed-loop |
Predictive Maintenanceの学術レビューでは、MLを設備故障の予測・異常検知に利用する研究が多数整理されている一方、モデル性能は適切なデータ、前処理、モデル選択に依存する。つまり、「振動センサを付けてAIを入れるだけ」で予知保全になるわけではない。故障時の正解ラベルが少ない現場では、正常状態からの逸脱を見る異常検知や、ルールとMLを組み合わせる方式が現実的である。
オムロン自身のAI搭載コントローラ研究でも、まず製造データを収集して特徴量と学習済みモデルを作る「分析フェーズ」、そのモデルを使いリアルタイムに外れ値を検知する「活用フェーズ」という二段階になっている。これは中小工場のPoCにもそのまま適用できる考え方である。
保守は「定期交換」から「状態・予測・遠隔サービス」へ
現在の予防保全では、メーカー推奨周期や過去経験に基づき、壊れる前に部品を交換するTBM（Time Based Maintenance）が一般的な方法の一つである。しかし設備の負荷が低ければ寿命を残して交換し、逆に過酷な運転条件では定期交換日前に壊れることもある。オムロンも、状態を連続監視して保全時期を判断するCBM／予知保全を、不要な保守や突発停止を減らすための方向性として説明している。
PLC＋IPCが浸透すると、保守業務は次のように変わると予測できる。
| 項目 | 従来 | PLC＋IPC・AI後 | 経営インパクト |
|---|---|---|---|
| 保全方式 | 定期点検・定期交換中心 | 振動・電流・温度・PLC波形から状態基準／予測保全へ | 不要交換と突発停止を同時に減らす余地 |
| 故障診断 | 保全員が現地へ行き、HMIやログ確認 | イベント前後の高速ログをIPCに保存し、安全なリモート接続で診断 | 初動時間・出張回数を圧縮 |
| 部品在庫 | 故障確率を見ず安全在庫を保有 | 故障確率、リードタイム、RULに応じて予備品優先度を変える | 在庫金額と欠品リスクのバランス改善 |
| 保守契約 | 点検回数・作業工数ベース | 遠隔監視、ソフト更新、分析サービス、将来的には稼働率／成果ベースへ | CAPEXから継続サービス費へのシフト |
| 技能伝承 | ベテランが音・波形を経験で判断 | 履歴、異常波形、対処内容を紐付け、診断を標準化 | 属人性を低減 |
オムロンは既に、OEE分析から故障要因を絞り込み、状態監視によって故障前に対応し、保全工数や頻度の最適化につなげる考え方を示している。また、状態監視機器を使ったスモールスタートによって投資対効果を早期に確認することを推奨している。
一方、IPCを外部ネットワークへ接続するほどサイバーセキュリティの重要度は上がる。PLC＋IPCを導入した結果、保全会社がいつでもインターネットからPLCへアクセスできる構成にするのは避けるべきである。遠隔診断用の経路、ユーザー認証、操作ログ、OT／ITネットワーク分離、パッチ適用責任、バックアップ／復元手順までPoC段階で設計する必要がある。例えばNX502のOPC UA機能には証明書認証や暗号化の仕組みがあり、RockwellもCIP Securityを含む産業ネットワーク機能を提供しているが、機能が存在することと「工場全体が安全である」ことは同義ではない。
中小工場のコスト試算を示す。以下の金額・効果率はベンダー見積もりや学術論文の平均値ではなく、ROIの計算方法を示すための仮定である。
前提は、設備20台、各設備7,000時間／年稼働、突発停止率を3%とする。すると突発停止は合計で、
20台 × 7,000h × 3% ＝ 4,200設備時間／年
となる。
設備停止1時間当たりの経済影響を、限界利益・残業・納期影響などをまとめた便宜上の係数として8,000円／設備時間と置くと、
4,200h × 8,000円 ＝ 年間3,360万円
が停止損失相当額になる。実際の直列ラインでは各設備の停止を単純加算すると二重計上になるため、ボトルネック設備またはライン停止時間を使って再計算すべきである。
初期投資は次のように仮置きする。
| 費目 | モデル仮定 |
|---|---|
| Edge IPC 5台、ストレージ・予備 | 350万円 |
| 振動・電流・温度センサ、DAQ | 200万円 |
| OTネットワーク、Firewall、時刻同期 | 150万円 |
| PLC接続、DB、ダッシュボード、AI PoC | 400万円 |
| 教育、立ち上げ、予備費 | 100万円 |
| 初期投資合計 | 1,200万円 |
| 年間ソフト・サポート | 80万円 |
| モデル／データ保守 | 100万円 |
| セキュリティ、校正、バックアップ等 | 70万円 |
| 年間運用費 | 250万円 |
さらに、現行の緊急修理・特急部品・保全外注などを年間800万円と仮定する。
| シナリオ | 突発停止削減 | 保守・緊急部品費削減 | 年間粗効果 | 年間運用費控除後 | 単純回収期間 |
|---|---|---|---|---|---|
| 慎重 | 10% | 10% | 416万円 | 166万円 | 約7.2年 |
| 基準 | 25% | 15% | 960万円 | 710万円 | 約1.7年 |
| 上振れ | 40% | 20% | 1,504万円 | 1,254万円 | 約1.0年 |
基準ケースでは、停止損失3,360万円の25%＝840万円、保全関連800万円の15%＝120万円、合わせて960万円の粗効果となり、年間運用費250万円を引くと710万円。1,200万円÷710万円で、単純回収期間は約1.7年となる。
ただし、この表から「AIを入れれば停止が25%減る」と解釈してはいけない。Predictive Maintenance研究はMLが故障予測に利用できることを示しているが、効果は設備の故障モード、データ品質、故障頻度、保全行動までのリードタイムによって変わる。したがってROI計算では削減率を1つに決めず、10%／25%／40%のような感度分析で投資判断する方が安全である。
部品在庫削減も同様だ。RULや故障確率が分かるようになれば、重要部品を「全設備1個ずつ持つ」方式から、共通化・故障確率・調達リードタイムを組み合わせた在庫へ変えられる。ただし、これは予兆モデルが十分成熟した後の効果であり、初期PoCのROIへ大きく織り込まない方が保守的である。
中小製造業が実際に始めるためのチェックリスト
最大の失敗パターンは、「全設備をIoT化してデータレイクを作ってからAIを考える」ことである。中小工場では、最初に経済損失の大きい1～3台を選び、停止・品質・速度のどれを減らすかを一つ決める方が投資対効果を測りやすい。オムロン自身も予知保全についてスモールスタートでROIを確認する考え方を示している。
投資判断チェックリスト
| 確認項目 | Goの目安 | 要注意の状態 |
|---|---|---|
| 課題は金額化できるか | 年間停止損失、不良損失、残業・保全費を算出済み | 「AIを導入したい」が目的 |
| 対象設備は絞れているか | ボトルネック1～3台から開始 | 最初から20台全部 |
| PLCデータを取得できるか | 状態、アラーム、CT、設定値を取得可能 | PLCがブラックボックス |
| 品質との紐付けは可能か | 部品ID／ロットと工程データが結合できる | 不良結果だけ別Excel |
| 時刻同期できるか | PLC、IPC、カメラ、MESで時計を統一 | ログ時刻が数秒～数分ずれる |
| 故障履歴があるか | 日時、故障モード、交換部品、対処を記録 | 「止まった」の一行だけ |
| AIが外れた時の安全策 | PLC側に上下限、インターロック、fallback | AI出力を直接アクチュエータへ |
| Cybersecurity責任者 | 接続経路、アカウント、ログ、更新責任が明確 | ベンダー常時VPNを放置 |
| ベンダーロックイン | CSV/SQL/OPC UA等でデータを持ち出せる | 専用クラウド以外で読めない |
| ROI | 慎重ケースでも許容回収年数内 | 上振れケースだけで採算が合う |
PoC設計チェックリスト
| 項目 | 推奨設計 |
|---|---|
| 対象 | 最も損失が大きく、データ取得しやすい1設備または1工程 |
| ベースライン | 導入前にOEE、停止時間、不良、MTBF/MTTRを同一定義で測る |
| 仮説 | 「主軸振動増加から24時間以上前に異常を検知」など一文で定義 |
| AIなし比較 | 単純上下限・統計管理でも同等効果が出ないか確認 |
| Shadow運転 | AI結果を設備へ反映せず、まず人の判断と比較 |
| 評価指標 | Recall、Precision、誤警報/週、予兆リードタイム、回避停止時間 |
| 本番化条件 | 経済効果、精度、運用負荷、安全性の全てが閾値を満たす |
| 中止条件 | データ不足、誤警報過多、損失額が小さくROIが成立しない場合は撤退 |
PoCでは「AI精度95%」といった抽象的な指標だけをゴールにすべきではない。例えば故障が年2回しか起こらない設備なら、99.9%の正常データを「正常」と言うだけでも見かけのAccuracyは高くなり得る。経営判断に必要なのは、何件の故障を何時間前に捉え、誤警報を何回出し、その結果何円の停止を避けたかである。Predictive Maintenance研究でも、モデル選択とデータ構成が性能に大きく影響することが指摘されている。
最低限収集したいデータ項目
| データ群 | 具体項目 | 用途 |
|---|---|---|
| 時刻 | timestamp、PLC cycle、同期状態 | 全データ結合の基準 |
| 設備状態 | RUN/IDLE/STOP/ALARM、モード | Availability |
| 生産 | cycle start/end、品番、個体ID、数量 | Performance、トレーサビリティ |
| PLC変数 | 速度、位置、トルク、圧力、温度、設定値 | 原因推定、品質予測 |
| 高速センサ | 振動、電流、音、温度 | 異常検知 |
| Alarm/Event | エラーコード、発生・解除時刻 | 故障モード分類 |
| 品質 | OK/NG、寸法、検査画像、欠陥種別 | Predictive Quality |
| レシピ | 温度、速度、圧力等の設定変更履歴 | 最適運転 |
| 保全 | 故障内容、交換部品、作業時刻、原因 | PdMの正解ラベル |
| 材料 | ロット、仕入先、材料特性 | 品質原因分析 |
| 生産計画 | 製造指図、納期、段取り | MES／SCM最適化 |
| 環境 | 室温、湿度など | 季節・環境変動の分離 |
特に重要なのは、「結果」だけでなく「人が何をしたか」を記録することである。アラーム発生後に速度を80%へ落とした、工具を交換した、設定温度を3℃変更した、といった介入履歴がなければ、AIは設備状態の変化と人の改善行動を区別しにくい。
設備選定では、OnLogicのような高性能IPCを必ずしも各設備1台ずつ配置する必要はない。カメラAIや高周波振動解析など計算量の大きい設備にはGPU/NPU対応IPC、単純OEEやデータ収集なら比較的軽量なIPC、極めて高速な制御・安全制御はPLCというように、ワークロードで分ける方が合理的である。OnLogicにはAI向けGPU拡張モデルからファンレスEdge、SoftPLCモデルまで複数の構成が存在する。
製品外観や構成を確認する場合は、以下のOnLogic公式製品ページが参考になる。
- Karbon 525（Edge AI／GPU拡張）：
https://www.onlogic.com/store/k525/ - Helix 524-PLC（SoftPLC Industrial Computer）：
https://www.onlogic.com/store/hx524-plc/ - Helix 522（ファンレスEdge Computer）：
https://www.onlogic.com/store/hx522/
これらは現時点のOnLogic製品例であり、2030年度を目標とするオムロンとの統合製品そのものではない。
結論――「PLCをAI化する」のではなく「制御と学習の閉ループを作る」
オムロンによるOnLogic買収の戦略的意味は、単純な産業用PC事業への参入ではない。公式発表は、OnLogicのIPCとオムロンの高精度制御技術を組み合わせ、センシングやロボティクスまで含めた次世代フィジカルAIプラットフォームを開発する方針を明確にしている。買収実行は2027年1月頃の予定で、取得価額は6億7,500万米ドルである。
そして技術的には、PLCとPCのどちらかが勝つ話ではない。PLCは高速I/O、周期性、モーション、安全、フェイルセーフといった物理世界の決定論を担い、IPCは大容量データ、AI推論、画像、最適化、履歴DBを担う。オムロン自身がPLCを「脊髄」、IPCを「大脳」と説明したのは、この役割分担を端的に表現している。
中小製造業にとって、最も現実的な導入順序は次の通りである。
まずOEEと停止理由を自動取得し、次に異常検知、続いて品質予測、その後に人が承認する設定値最適化、最後に制約付き自動調整へ進む。
いきなり「自律工場」を目指すより、この順序の方が各段階でROIと安全性を検証できる。オムロンが既にリアルタイムOEE、ドリルダウン分析、状態監視、制御周期同期のAI異常検知技術を持ち、OnLogicがGPU/NPUを使えるEdge AI機とSoftPLC IPCを持つことを考えると、買収後の差別化ポイントは、単なるAI演算性能ではなく、「データを取る→判断する→PLCが安全に実行する→結果を再学習する」という閉ループを、製造現場で保守できる形に標準化できるかにある。
投資判断も同じである。経営者が最初に聞くべき質問は「どのAIを使うか」ではなく、
「年間何円の停止・速度低下・不良を、このデータで減らせるのか」
である。OEEはその入口であり、PLC＋IPC＋AIはOEEを単なる結果指標から、原因推定・予測・改善制御へ変えるための技術基盤となる。予測保全やPredictive Qualityには既に相当量の研究蓄積があり、強化学習による最適制御も研究・実装が進んでいる一方、安全制約や実環境での探索には依然慎重な設計が必要である。
