IIoTを巡る覇権争い、正しいプラットフォームの選択に必要な考え方：IIoTの課題解決ワンツースリー（5）（1/2 ページ）

産業用IoT（IIoT）の活用が広がりを見せているが、日本の産業界ではそれほどうまく生かしきれていない企業も多い。IIoT活用を上手に行うためには何が課題となり、どういうことが必要になるのか。本稿ではIIoT活用の課題と成果を出すポイントを紹介する。第5回では、数多くの参入企業があるIIoTプラットフォームについて解説する。

[リンクス 代表取締役 村上慶，MONOist]

　IIoT（産業用IoT）活用を上手に行うためには何が課題となり、どういうことが必要になるのか。IIoT活用の課題と成果を出すポイントを紹介する本連載だが、第5回では、数多くの参入企業があるIIoTプラットフォームについて解説する。

≫本連載の目次

サプライヤーによる覇権争い

　現在、インダストリアルIoT（IIoT）の領域にはさまざまなプレーヤーが参入している。もともと、ファクトリーオートメーション（FA）、プロセスオートメーション（PA）の領域でMES（製造実行システム）やDCS（分散制御システム）といった大型システムを提供してきた総合電機メーカーの他、ロボットや工作機械を提供してきた機械メーカー、SCADA（Supervisory Control And Data Acquisition）などを提供してきたツールベンダーなどが展開している。さらに、これまでFAやPAの世界にあまり縁のなかったIT領域からも多くの企業が参入してきている（表1）。

表1　IIoT分野への参入プレーヤーの例（クリックで拡大）出典：リンクス

　出自はさまざまだが、目指すところは同じ「IIoTプラットフォーム」である。各社の思惑が入り乱れた、まさに覇権争いの状況にある。大手ITベンダーや総合電機メーカーは、上位のERPから現場のセンサーデータ収集の領域までを囲い込むことを目指す。一手に顧客の重要なシステムを抱えることになり、IIoTプラットフォームの構築からデジタルツイン化を進める絵を描いている。大規模な開発案件にもなり、その後の保守運用からの収益なども見込める。

　機械メーカーにとっては従来の機械単体売りから脱却し、データ収集・分析・予兆保全といったサービスを提供することで、自社製品による顧客囲い込みを強化できる点を狙う。自社機械の継続的な販売（競合の排除）に加え、付加的なサービスからの追加収益も見込む。

エンドユーザーの志向は2極化傾向

　一方で、エンドユーザー各社と話をしていると、先述したようなサプライヤーの積極的なアプローチに対し、「囲い込まれたい」もしくは「囲い込まれたくない」と2極化しているように感じる。

　例えば、ロボットの予兆解析、というテーマを取り上げてみよう。例えば、某大手メーカーでは「ロボットは痛いかかゆいかを教えてくれればそれで十分である。あとは自社で解析する」との考えを持っている。そのため、ロボットメーカーに対しては「解析のために必要なデータをロボットから吸い上げられる状態にしてくれればよい」という要求しかしない。自社で解析ロジックを作り上げ、自社で予兆解析を運用していく。こうした企業は、IIoTというテーマにおいて、ツールを自ら使いこなし、ベンダー依存度を下げ、自ら主導権を持つことを望んでいる。

　ただ、別のあるメーカーでは「予兆解析は、ロボットメーカーの予兆解析ツールに依存したい。ロボットのことはロボットメーカーが一番よく分かっているはず」という考えを述べていた。この考えにも一理あるだろう。そもそもソフトウェアエンジニアが不足し、内製化するリソースがない企業も多い。こうしたケースにおいては、積極的に「囲い込まれる」ことも選択肢になる。しかし、もしブラックボックス化したシステムで囲い込まれると、将来的なリスクを抱えることになる。

問題は個別最適化とブラックボックス化

　現在、多くの生産現場が抱えている課題は、個別ニーズに応じて局所開発された、ブラックボックス化した個別システムの乱立である（図1）。「各システムに手を入れられない」「データが一元集約されていない」などの問題を抱える生産現場が多いのが現実だ。そのため、「横連携が難しい（個別にデータを拾ってきてExcelに展開して分析など）」「サーバの数が増え維持が大変」などのIIoTを阻む障壁となってしまっている。

図1　個別最適化されたシステムの乱立（クリックで拡大）出典：リンクス

　例えば、製造情報を現場に表示する「あんどんシステム」で考えてみよう。こうしたあんどんシステムは、多くが地場のベンダーによって受託開発されている。10年以上前にSCADAが表示器としての有用性を評価され、あんどんシステムとして使われたことがあった。しかし、生産ラインのレイアウト変更が少なく、表示内容（画面構成）に手を入れることはないので、わざわざツールを使う必要がないとの結論に至り、その当時は、よりコストの低いスクラッチ開発を行った。

　ただ、こうしたスクラッチ開発によるあんどんシステムは昨今のスマートファクトリー化などの流れを見た場合、限界が来ているといえるだろう。AGV（無人搬送車）などの新しい技術が生産現場に導入されるケースは増えており、新たな機器やツールが日々追加されたり設定変更されたりしている状況だ。あんどんシステムの表示内容も本来はその度に変更されるべきだが、スクラッチ開発によりブラックボックス化されていると「誰も触れない」。変更依頼をかけると時間もコストもかかり、改善のスピードは落ちる。

　そのうえ、連載2回目で述べたように、SCADAは表示器からIIoTソフトウェアプラットフォームへと進化しており、この階層での要求はより高度化している。データ収集、蓄積、分析はその重要な要素だが、この部分こそエンドユーザーが自ら手を入れる機会の多い領域だろう。

　「データ収集する対象の機械を追加する」「データ容量を最適化する（圧縮する）」「新しい角度で見える化・分析する」といったことは頻繁に発生する。ブラックボックス化したシステムでは、この要求にスピード感をもって対応できない。さらに外部の受託開発ベンダーへの依存度が高まると“手の内化”できる領域は減り、現場の自由度は下がり、改善が進まない悪循環を招くリスクがある。繰り返される新製品投入、新しい生産技術の導入など、生産現場の変化が激しいこの時代において、ブラックボックス化に伴うシステムの硬直化はリスクに他ならないのである。