製造業IoTプラットフォームの最適な選び方を徹底解説！おすすめの製品も紹介

選び方に入る前に、この基盤が何を担うのかを押さえます。役割が曖昧なままだと、使わない機能に費用を払うことになりかねません。ここでは3点に絞って確認しましょう。

製造業IoTプラットフォームが担う役割

この基盤は、工場のPLC・センサー・設備から信号を集め、蓄積して可視化する土台です。設備の可動率、停止要因、電力やエアの使用量といったデータを一か所にまとめます。集めた値は時系列で蓄積され、拠点をまたいだ集計にも使える形です。

OPC UAやMTConnectなどの産業用プロトコルにも対応します。制御系のOTと情報系のITをつなぐ役目も担う存在です。可視化ダッシュボードとアラート通知は標準で備わります。その上に予知保全や品質分析のアプリを載せていく形になるでしょう。

スマートファクトリーとの関係

スマートファクトリーは、工場全体をデータでつなぎ改善を回していく考え方を指します。製造業IoTプラットフォームは、その考え方を支える土台のシステムです。

概念だけを追いかけても、何を導入すればよいのかは見えてきません。逆にシステムだけを入れても、使う目的がなければ現場は動かないでしょう。用語の整理はスマートファクトリーの解説記事で扱っています。ここでは基盤を選ぶ視点に絞って進めます。目的と土台は、切り分けて考えることが大切です。

選定でつまずきやすい理由

この分野は製品数が多く、機能一覧を並べても差が読み取りにくいのが実情です。どの製品にも収集・蓄積・可視化ができると書かれています。

差が出るのは、自社の現役設備から実際に信号を取れるか、取ったデータを誰が毎日見るかという運用面です。カタログには載らない部分といえるでしょう。提供体制の再編が続いている分野でもあり、窓口や製品名が変わっている場合もあります。だからこそ、測る軸を先に決めてから製品を見る順序が要ります。

編集部コメント：製品を先に見ると、機能の多さで判断してしまいがちです。どの設備から、どんなデータを、誰のために取るのかを先に書き出してみるとよいでしょう。それだけで必要な条件がかなり絞り込まれます。

この分野の製品は、提供元の立ち位置で4つに分かれます。どの系統を選ぶかで、接続の得意分野も費用の形も変わってきます。まず全体像をつかみましょう。

• 装置メーカー系
• 汎用プラットフォーム系
• クラウド事業者系
• SI伴走型

装置メーカー系

FA機器やCNC、ロボットのメーカーが、自社設備との接続を前提に提供する系統です。制御に近い領域まで踏み込めるため、現場との親和性が高くなります。

自社の主力設備が特定メーカーで揃っている工場では、接続の検証工数を抑えられます。制御機器と同じ窓口で相談できる点も利点のひとつです。導入実績や段階的な展開メソッドが用意されている点も判断材料になるでしょう。一方でマルチベンダー環境では、他社設備をどこまで取り込めるかを選定段階で確かめる必要があります。

汎用プラットフォーム系

メーカーを問わない接続性と、アプリケーション基盤を前面に出す系統です。多数の産業用プロトコルに対応し、ローコードでの画面開発環境を備える製品もあります。

稼働監視から予知保全、品質分析へと段階的にアプリを広げたい企業に適した系統です。海外を含む複数拠点への横展開も想定した設計になっています。ただし機能が広いぶん、構築と運用には一定の体制が必要です。価格帯も高めで、目的を絞らないとコストと工数が膨らみます。

クラウド事業者系

クラウド事業者がIoT向けに用意するマネージドサービスを使い、自社で組み立てる系統です。従量課金が中心で、小さく始めて使った分だけ払う形に向いています。

エッジ側のゲートウェイ経由でOPC UAデータを収集する構成が前提になります。運用をサービス側に任せられるため、インフラの保守負荷は軽くなるでしょう。大規模なスケールにも耐えます。一方で可視化は作り込みが要り、デバイス台数とデータ量が増えると費用が逓増します。

SI伴走型

要件定義から構築、横展開までをベンダーの支援を受けながら進める系統です。ITとOTの両方に実績を持つSIerが、既存設備の取り込みまで含めて伴走します。

内製の人材が限られる企業や、全社規模でデータ活用を進めたい企業に向く選択肢です。自社工場での実証を踏まえた提案を受けられる場合もあります。既存の基幹システムとの連携まで含めて任せられます。ただしSIの比率が高くなるほど費用は上がり、プロジェクトも大規模になりやすい点には注意が必要です。

同じ基盤でも、何をしたいかで優先すべき条件が変わります。製造現場でよくある3つの目的を取り上げました。最初の目的は一つに絞ることをおすすめします。

設備の稼働監視から小さく始めたい

可動率や停止要因の見える化を最初のテーマにするなら、信号取得の容易さと初期投資の軽さを優先します。稼働信号と停止コードが取れれば成立するため、効果が早く出る領域です。

従量課金で始められるクラウド事業者系が候補に挙がります。社内にクラウドとデータの素養があれば、内製で素早くPoCを回せるでしょう。チョコ停や段取り替えのロスを数値で示せれば、次の投資の説明もしやすくなります。ここで作った土台は、後の目的へ発展させる足場にもなります。

突発停止を減らし保全を計画化したい

予知保全を狙う場合は、振動・温度・電流といった連続値を扱えるかが条件です。センサーの追加と分析モデルが必要になり、稼働監視より投資は大きくなります。

効果が出るまでには一定期間のデータ蓄積と現場のノウハウが要ります。そのため、突発停止が多い基幹設備から対象を絞るのが現実的です。保全管理まで含めて評価されている製品を候補に入れると、検討が早く進むでしょう。突発停止の削減額を現状値と目標値で積み上げれば、稟議の根拠になります。

品質改善やエネルギー削減につなげたい

品質を狙うなら、工程パラメータと検査結果を突き合わせられるデータ基盤が要ります。トレーサビリティ要件とも相性がよく、不良発生時の原因究明や顧客説明の根拠として活きます。

エネルギー管理では、電力・エア・ガスの使用量を拠点単位で集める設計です。省エネ目標やコスト削減の目標が明確なら、稟議の数字も組み立てやすいでしょう。どちらも工程データと突き合わせる分析が前提になります。外部のBIやAI分析への拡張性も比較の対象に含めておきましょう。

データを取る・見る・守るのどれを担うかで、確認すべき条件は異なります。導入に関わる3つの部門で整理しました。複数部門で共有する場合は、条件の厳しいほうに合わせます。

生産技術部門

ラインの立ち上げと改善を担う部門で、設備からのデータ取得を実際に設計する立場になります。既存設備との接続性が、ここでは最も重い条件です。

対応プロトコルの一覧ではなく、自社の現役機種で信号が取れるかを確かめることが重要です。信号が直接取れない古い設備には、後付けセンサーやゲートウェイで対応します。必要な台数とセンサー費用を早めに洗い出すと、横展開の予算が現実的になります。最初のPoCは、つなぎやすく効果が見えやすい設備から選んでください。

保全部門

設備を止めない責任を持ち、日々データを見て動く部門です。現場で使える画面が用意できるかが判断を分けます。

アラート通知の条件をどこまで細かく設定できるか、通知を誰が受け取るかを確認することが大切です。予兆の判定にはデータの蓄積期間が要るため、効果が出るまでの時間も見込んでおきます。現場のモニターに何を映すかまで決めておくと、定着が早くなるでしょう。日々の朝礼や定例で数値を見る運用に組み込めば、改善の行動につながります。

情報システム部門

OTネットワークを扱う以上、セキュリティと運用の設計はこの部門が握ります。従来は外部とつながっていなかった設備がネットワークに出るため、攻撃面が広がる点は避けられません。

制御系と情報系の分離、デバイス認証、通信の暗号化、権限管理を要件として整理しておきます。エッジ機器のファームウェア更新や認証情報の運用ルールまで含めて設計します。生産設備が止まれば事業に直結する点も踏まえておきましょう。要件は保全や生産技術も巻き込み、早い段階で握っておくと手戻りが減ります。

企業規模そのものより、規模から来る制約が判断を分けます。専任担当の有無、拠点数、稟議の通し方の3点です。自社の体制に近いところから読み進めるとよいでしょう。

中小企業

データ活用の専任担当がいない前提で選びます。設定も運用も、生産技術や保全の担当者が兼務で抱えることになるためです。

初期費用を抑えられる従量課金型か、スモールスタートの枠が用意された製品が適しています。比較表の中小適合が高い製品ほど、この条件に合います。1ラインまたは数台の設備から始め、効果を数字で示してから広げる進め方が現実的でしょう。分析まで一体で求めるのか、通信や収集だけで足りるのかも先に決めます。

中堅企業

複数ラインや工場単位での展開が視野に入り、目的も稼働監視だけでは収まらなくなります。作ったものを作り直さずに広げられるかが課題です。

PoCで使った構成が、そのまま本番と横展開で生きるかを確認しておきましょう。装置メーカー系のように段階展開のメソッドを持つ提供元も選択肢に入ります。運用を内製に寄せるのか、支援を受け続けるのかも、この規模で決めておきます。人材が限られるなら、伴走支援を受けられる選択肢が現実的です。

大企業

拠点数が多く、海外工場を含む横展開とグローバルでのスケーラビリティが判断を左右します。連携する基幹システムの範囲も広くなりがちです。

情報システム部門の承認は、要件定義の段階で得ておくと進めやすくなります。稟議では単価より数年分の総額と、既存システムへの影響が問われます。全社一斉ではなく拠点単位の段階展開にすると、リスクを抑えながら進められるでしょう。データを社外に出せない工程があるなら、その制約も要件に含めてください。

目的・部門・規模で方向が見えたら、具体的な条件に落とし込みます。ここからは確認の順番が大切です。上から順に見ていくと、手戻りが減ります。

• 解決したい目的を一つに決める
• 現役設備との接続性を実機で確かめる
• エッジとクラウドの分担を決める
• データ基盤と可視化の運用を決める
• セキュリティ・体制・3年の総額を確認する

解決したい目的を一つに決める

最初に決めるのは、稼働監視・予知保全・品質・エネルギーのどれから着手するかです。ここを曖昧にすると、費用対効果を稟議で説明できなくなります。

選ぶ基準は、自社の課題のうちどれが最も金額換算しやすいかです。将来複数の目的へ広げる計画があるなら、拡張できるデータ基盤を持つ製品のほうが総額で有利になります。ただし最初から全目的を狙うと、効果がぼやけてしまいます。目的ごとに別ツールを増やすより、一つの基盤から広げるほうが無駄も出ません。

現役設備との接続性を実機で確かめる

次に見るのは、自社のPLC・CNC・センサーから実際にデータを取れるかどうかです。ここでつまずくと、どれだけ高機能な製品でもデータが一切上がってきません。

OPC UA・MQTT・Modbusへの対応と、主要PLCやNCへの接続実績を確認します。カタログ上の対応と、自社の特定機種で取得できるかは別の問題です。PoCで実機検証し、後付けが必要な台数とセンサー費用を早い段階で見積もります。この見積もりが甘いと、横展開でコストが大きく膨らみます。

エッジとクラウドの分担を決める

どこでデータを処理するかは、通信コストとリアルタイム性を左右します。すべてをクラウドへ送ると通信量と費用が膨らみ、異常検知の遅れも問題になります。

現場のエッジで一次処理と異常判定を行い、必要なデータだけをクラウドへ集約する構成が現実的です。ただしエッジ機器を増やすほど、現地の保守対象も増えていきます。構成の複雑さと運用負荷の釣り合いを見て判断しましょう。通信費が読める範囲に収まるかを試算してから決めると安全です。

データ基盤と可視化の運用を決める

ここは「データを取った後」を決める軸です。時系列データの蓄積方式、標準ダッシュボードの作りやすさ、外部BIやAI分析への拡張性を確認します。

可視化がスクラッチ開発になると工数が膨らむため、テンプレートの有無が運用負荷を大きく変えます。CSVや標準APIで外部に取り出せるかも、ロックインを避けるうえで重要です。誰がどの画面を毎日見るかまで、設計段階で決めておきましょう。ここを軽く見ると、データは取れても活用されない状態に陥ります。

セキュリティ・体制・3年の総額を確認する

最後に、OTとITの分離や認証といったセキュリティ要件を情報システム部門と確認します。あわせて、内製で運用まで回せるのかSI伴走が要るのかを見極めることも大切です。PoCの段階で承認を取っておくと、横展開の稟議が速くなります。

費用は3〜5年の総保有コストで比べると判断が安定します。デバイス台数とデータ量に応じて通信費とクラウド利用料が逓増する点は、この分野に特有のコスト特性です。内訳は製造業向けIoTの費用の解説記事で扱っています。

製品データとして数値化できる5項目を、製造業適合性スコアで横並びにしました。生産管理・多拠点対応・保全管理・現場操作性・中小適合の5つを5段階で評価しています。並びは中小適合の高い順です。上から下へ向かうほど、想定する企業規模と導入の重さが上がります。評価が設定されていない項目は「－」としています。

スコアが「－」の製品は、機能がないという意味ではありません。評価の登録がない項目です。これらは個別のデモや導入事例で確認する形になります。なお提供体制の変化が続く分野のため、商談前に窓口を確かめてください。製品ごとの詳しい比較は製造業IoTプラットフォームの比較記事で扱っています。

導入でつまずく企業には共通したパターンがあります。事前に知っておけば、稟議の段階で対策を示せるはずです。よくある4つを回避策とあわせて挙げます。

目的を広げすぎる

稼働監視も予知保全も品質もと欲張ると、何を解決したのかを説明できないまま終わりがちです。費用対効果を示せないまま、PoCで止まってしまいます。目的ごとに必要なデータや投資規模が異なるため、評価の軸もばらばらになります。

回避策：最初の目的を稼働監視など一つに絞ってください。効果を数字で示してから次の目的へ広げます。順序を守れば現場の納得も得やすく、二つ目以降の稟議も通りやすくなるでしょう。稼働監視で蓄積したデータは、予知保全や品質分析へ発展させられます。

接続性の見積もりが甘い

よくあるのが、カタログの対応表だけで契約し、自社の古い設備につながらない事態です。後付けの台数も費用も、想定を大きく超えて膨らみます。特定機種や特定ファームウェアでは、信号を取得できない例もあります。

回避策：PoCで現役設備を実機検証しましょう。後付けセンサーの台数とコストを早い段階で見積もります。古い設備が多い工場では、この接続コストが全体投資の大きな比率を占めることも珍しくありません。最初のPoC対象は、つなぎやすい設備から選ぶと立ち上がりが速くなります。

データを取ったまま放置する

可視化と運用設計を後回しにすると、データは取れても誰も見ないまま形骸化します。投資に見合う改善が起きません。取得の仕組みを整えるだけでは、現場の行動は変わりません。

回避策：可視化と「誰が見て改善するか」をPoCの段階で明確にします。ダッシュボードと改善サイクルは、セットで設計するのが基本です。現場のモニターに何を映し、管理者が週次で何を見るかまで具体化します。朝礼や定例で数値を確認する運用に組み込むと、データが現場の行動につながります。

PoC専用の構成で進める

PoCのためだけに組んだ仮設構成は、横展開の段階で作り直しになることが少なくありません。かけた時間と費用がそのまま無駄になります。特に接続方式とセキュリティ設計は、後から変えるほど影響が大きくなります。

回避策：PoC構成を最初から本番想定で組んでください。接続方式・データ基盤・セキュリティを拡張前提で設計します。PoCで得た効果と課題を記録に残しておくと、次のラインへの判断も速くなるでしょう。運用体制も、拡張を前提に最初から設計に含めます。

編集部コメント：4つの失敗はいずれも、上流の選定軸を後回しにした結果として生じます。選定ポイントの5項目とPoCの評価基準を、稟議資料に反映しておきましょう。設計の段階で対策を示しやすくなります。

製造業IoTプラットフォームの選定は、最初の目的を一つに絞ることから始まります。次に現役設備との接続性を実機で確かめると、候補の系統を絞り込みやすくなります。種類は装置メーカー系・汎用プラットフォーム系・クラウド事業者系・SI伴走型の4つです。

方向が定まったら、5つの条件を順に確認します。目的、接続性、エッジとクラウドの分担、データ基盤と可視化、セキュリティと体制と総額です。よくある失敗は、目的の拡散、接続性の過小評価、データの放置、PoC専用構成の4つでした。

製品ごとの比較は製造業IoTプラットフォームの比較記事で扱っています。導入の実例はスマートファクトリーの事例記事で扱っています。