1．SaaS提供可能なIoTの概要

1.1　IoTGOの概要

SaaS提供可能なIoTとして開発したIoTGOは，2018年6月にサービスを開始した．IoTGOは工場稼働データの見える化，分析をサービスとして提供するSaaSサービスであり，新規に構築する部分がないため，申し込み後2週間程度でIoTを導入できる．顧客から見たIoTGOの全体イメージを図1に示す．IoT端末により，生産設備からデータを取得し，Wi-Fiアクセスポイント，LTEルータが構築した通信経路を利用して，クラウドにデータをアップロードする．その処理結果をWebアプリで確認するというシンプルな構成となっている．

IoTをSaaSサービスとして提供し，ITインフラをクラウド上で共用することは，顧客1社あたりのコスト負担を軽くする．

さらに，IoTGOは初期費用として必要となる現場側のIoT機器をレンタル契約としているため，初期費用も必要とせず低リスクでIoT導入が可能になる．また，IoTの対象として，たとえば，プレス機のような生産設備1台だけでも導入できるスモールスタートを実現する．さらに，コスト面だけでなく，サービスを利用することに専念すればよいというSaaSの特性により，顧客はシステム構築などにかかわる技術者不足の障壁を取り除くことができる．

1台からの導入も可能だが，1社あたり，520台の製造設備をサポートする仕様としている．520台の製造設備への接続はロケーションに関係なく可能なため，全国各地にある自社工場設備の稼働状況をリアルタイムに集約しモニタリングできる．リアルタイムモニタリングは，PCだけでなく，スマホ，タブレットなどWebブラウザさえ動作すれば，デバイスを選ばす利用できる．

製造設備に多数のセンサを取り付け，測定，分析を行い故障予兆検知する目的のIoT，あるいは，職人の技をデータ化，モデル化する目的のIoTを狭くて深いIoTと定義するとIoTGOは広くて浅いIoTであると言える．IoTGOは，ロケーションに関係なく保有する製造設備全体，工場全体の稼働状況を見える化し，データ収集，分析を行い，全体を最適化することをテーマとしている．

IoTGOを利用すると，たとえば，製造現場で1つのワークを加工するのに必要な時間であるサイクルタイムの短縮改善を行う際に必要となるデータ測定において，大幅な精度向上効果が得られる．製造業では以前より改善による生産性向上のため，改善活動の要素として工程のサイクルタイムを測定し，分析することが行われてきた．測定は，ストップウオッチを使い人力で行うことも多く，労力がかかる上にサイクルタイムの短いプレス工程のように0.1秒の改善でも意味を持つような工程では，測定精度も満足できるものではなかった．IoTGOは，専用機器が休むことなく，24時間365日連続して，1/1000秒の精度でサイクルタイムを測定することを可能にする．すなわち，改善に必要なデータを高い精度で取り続けていることになる．

1.2　取得信号の種類

SaaSとしてIoTサービスを展開するために，取得する信号はどのような製造機械にも共通して取得できる必要があり，どの製造機械にとっても意味のあるものでなければならない．設計段階で選定したのは，各製造機械1台に付きデジタル入力信号1点である．すなわちON/OFF信号であり汎用的に生産設備から取得できる信号となる．たとえば，ランプの点灯をON，ランプの消灯をOFF，あるいはプレス機でショットした瞬間がON，それ以外がOFFなどと定義できる（接続方法は2.2.2項参照）．これを時系列に取得すれば，そのON/OFFのパターンで，ONになった回数のカウント，連続ONの時間，サイクルタイムのばらつきなどさまざまな指標を計算やアルゴリズムによって生成することが可能である．リアルタイムモニタリングするためには，ON/OFFが切り替わるタイミングでその都度データを送信する必要がある．内部的なデータ送信の効率は落ちるがリアルタイム性を追求するために，あえてこの方法を選択している．

1.3　リアルタイム計算する数値指標

IoTGOの製造設備からの入力は，ON/OFF信号1点であるため，Outputの情報量も少ない印象を持たれることが多いが，時間軸とマスタデータを参照した結果から得られるリアルタイム集計では，多くの役立つ指標を計算し，表示できる．以下にWeb上でリアルタイム表示する項目を列挙する．

また，これらの項目を表示するメイン画面を図2に，メイン画面の説明を図3に，製造設備単位の詳細画面を図4に示す．

• 稼働状況（稼働中／停止中）
• 稼働中になってからの経過時間
• 停止中になってからの経過時間
• チョコ停回数（稼働すべき時間帯に設定時間以上停止した回数）
• 1日の合計稼働時間
• 1日の合計ショット数（ON，OFFの繰り返しパターンの回数）
• 休憩時間などを考慮したある時間までに生産すべき数量
• 稼働率（昼勤／夜勤）
• 直近サイクルタイム
• 平均サイクルタイム
• 時間帯別稼働率
• 停止時間帯抽出データ
• 1日稼働帯グラフ
• ローデータ（タイムスタンプ，ON/OFF状態，累積カウント値，インターバルタイム）

IoTGOメイン画面から以下の各機能を選択した場合に集計し表示する．

• 1カ月稼働率グラフ
• 1カ月稼働時間グラフ
• サイクルタイムのヒストグラム
• 生産安定度分析（サイクルタイムの標準偏差などから分析）
• 停止時間分析グラフ（停止理由の集計グラフ）

稼働率は，事前に登録された以下のデータを参照し，測定データの集計に利用する．

• 稼働時間帯データ（1日の昼勤，夜勤，などの時間帯や休憩時間を登録する）
• 理論サイクルタイム（カウント値から稼働率を算出する基礎データ）
• 停止係数（カウント動作をする場合の稼働／非稼働を判定する）

クラウドサーバ上には，6カ月分のローデータと集計データが蓄積されており，リアルタイムにWeb画面上で参照するだけでなく，過去のデータもWeb画面上で表示可能である．また，専用のソフトウェアでダウンロードした期間データを，ExcelやBI（Business Intelligence）ツールを利用し，Web画面上ではサポートされていない停止要因の分析など独自の分析を行うことやAIモデルの学習データとして利用することができる．

1.4　製造設備の特性による測定方法の違い

稼働率の計算は，製造設備の特性により区別している．プレス機のように，生産の進捗がカウント値によって得られる場合には，カウント値で計算を行う．量産にかかわる製造マシンは主にこのタイプになる．一方，マシニングセンタのように動作している時間が価値を生む場合には，稼働時間による稼働率の計算を行う．量産ではなく試作や型製造にかかわる製造マシンは主にこのタイプとなる．

2．SaaS提供可能なIoTの設計

2.1　汎用的なSaaSサービスとして提供するための課題と解決

SaaS提供可能なIoTを構築するためには，汎用性，拡張性，コストとメンテナンス性に関する課題を解決する必要があった．

2.1.1　汎用性

一口に製造業といってもさまざまな加工方法や製造工程がある中で，SaaS提供するためにはシステムに汎用性を持たせることが必要である．取得する信号については，大多数の製造設備に接続可能な信号で，IoT対応した最新の製造装置だけでなく，何十年も利用されている古い製造設備にも適用，接続できる仕様が理想である．この点については，1.2節で述べたように，入力信号は，デジタル信号1点とすることにした．

2.1.2　拡張性

SaaS提供のIoTの運用を始めると，利用数の増大に応じてシステム能力の増強を必要とするタイミングが出てくる．クラウド上にシステムを構築する利点の1つは，リソースの能力を増強するために，スケールアップ／スケールアウトが可能な点である．スケールアップは，1つの仮想サーバのCPU能力やディスク容量を増強する方法であり，スケールアウトはサーバの数を増加して全体の処理能力を増強する方法である．

しかし，クラウド上にIaaS（Infrastructure as a Service）として仮想サーバを構築し，システムを構築した場合，仮想サーバの能力は，必要に応じて変更可能ではあるが，ある機能要素を拡張するためには，ソフトウェア側の変更が必要となることがある．SaaSサービスを円滑に運用するためには，できるだけリソース能力の変更にかかわるソフトウェア改修を減らす工夫が必要である．

そのため，IaaSではなくPaaS（Platform as a Service）でシステムを構成することとした．PaaSは，システムのパーツがクラウド化されたものであるため，PaaSの組合せでシステムを構成していれば，ある時点でボトルネックになっている必要なパーツのみのスケールアップ／スケールアウトを検討すればよい．

2.1.3　コストとメンテナンス性

クラウドを利用するにあたり，顧客ごとにテナントを作成し提供するのではなく，スケールメリットが出せるよう，1つのテナントで多数の顧客にサービスを提供するマルチテナント方式を検討した．顧客ごとにテナントを作成した場合，テナントごとの能力の最適化はできるものの，どうしてもコストがかさむことになり，顧客に低価格でサービスを提供することが難しくなる．そのため，マルチテナントを実現する方法のうち，コスト面で有利であり，メンテナンスも比較的容易である完全なマルチテナントデプロイ方式[3]を採用した．この方法は，アプリケーションレベルでマルチテナントを実現することになるため，ソフトウェア開発はシングルテナントと比較し複雑となる．

2.2　現場側システム

SaaSシステムとして提供するためには，現場側システムとクラウド側システム，それぞれを最適化した設計を行い連携させる必要がある．まず，現場側システムとして以下の構成とした．

2.2.1　現場側システムの設計指針

現場側システムは，顧客の工場に設置するシステムである．現場側システムは，製造設備のデータを収集し，クラウド側システムに送信するのが目的である．現場側システムは，顧客がSaaSサービスの利用に専念できるよう，できる限り複雑さ，難しさを隠蔽したシステムとすることを設計指針とした．

2.2.2　システムの機器構成とデータの経路

現場側の機器は，図5で示すようにLTEルータ，Wi-Fiアクセスポイント，IoT端末の3種類の機器で構成する．製造設備に取り付けたIoT端末で測定した信号を工場内に設置したWi-Fiアクセスポイントに送信する．Wi-Fiアクセスポイントに送信された信号はLTEルータを経由し，クラウド側システムにLTE通信によって送信する．信号取得の補助として光センサおよびマグネット近接センサも提供する．生産設備から直接ON/OFF信号を取得できない場合には光センサやマグネットセンサを介してON/OFFに信号変換し，IoT端末への入力とする．

2.2.3　信号取得の処理

1.2節で述べたように，取得信号は各製造設備につきデジタル入力1点である．IoT端末でデジタル入力信号（すなわち，ON/OFF信号）は2つの処理モードいずれかによって処理される．1つ目は，ON/OFFの状態が変化したときにパケットを出力するモードである．この処理モードはON時間あるいはOFF時間を測定するために利用する．送信パケットには，前回測定時のタイムスタンプと今回測定時のタイムスタンプの時間差であるインターバルタイムおよび測定時のタイムスタンプが含まれる．2つ目は，OFFからONに変化し，さらにONからOFFに変化したときに，パケットを出力するモードである．この処理モードは生産設備のショット数をカウントする場合に使用する．このときにもインターバルタイムデータと測定時のタイムスタンプは送信パケットに付加される．時間測定は1/1000秒の精度で可能である．クラウド上での時間に関連する計算は，すべてこの送信パケット内のデータをローデータとして演算しており，クラウド上でのパケットの到着時間ではない．また，パケット遅延やパケットロスで間違ったカウント値を計算しないようパケットにシリアル値も付加して修正を行っている．

2.2.4　機器の設定について

LTEルータ，Wi-Fiアクセスポイント，IoT端末の3種類の機器の設定はSaaSサービスとしてすぐに利用を開始できるよう，すべての機器設定を行ってから顧客に出荷する．顧客は設定済の機器を設置し，機器名や基本パラメータなど，アプリケーションレベルのわずかな設定値入力のみで運用を開始できる．この設定は事前調査によって事前に設定することも可能であるが，運用中に変更することも多いため，サポートを行いつつも顧客に設定してもらう．この設定ができると正常稼働を確認できる．

機器設置は，設備保守担当者が在籍する顧客であれば，簡単に設置できる程度の難易度であるが，弊社が請負うことも可能である．

2.2.5　Wi-Fiの採用について

IoT端末は，Wi-Fiアクセスポイントを介してデータ通信を行う．工場内無線通信を利用することで工場内にLAN配線を敷設することなく，データ通信を利用できるメリットがある．802.11g規格のWi-Fiを利用しているため，規格上54Mbpsで通信が可能であり，リアルタイム性を求めるIoTGOの工場内通信に適合すると判断し採用した．反面，無線LANは工場内で既存利用していることがあり，通信チャネルが競合しないようWi-Fiの利用調査を行いIoTGOで使用するWi-Fiチャネルの設定値を決定する必要がある．また，IoTGO端末とWi-Fiアクセスポイント間で電波が確実に到達できるよう，それぞれの設置場所についても考慮する必要がある．

このようなWi-Fi環境の調査は，機器の本番導入前に行う必要があるが，現在ではリモートでサポートすることで，遠隔地の顧客でも調査可能となっている．調査の結果，標準構成ではWi-Fi無線通信が不安定になると判断した場合は，Wi-Fi中継器やWi-Fiアクセスポイントの増設によって対応している．

2.2.6　現場側システムのセキュリティ

現場側システムでは，種類の異なる5つのセキュリティ対策が施されている．

1つ目は，既存顧客ネットワークとIoTGOネットワークの分離である．IoTGOのネットワークは顧客ネットワークと物理的に分離されているため，顧客の既存ネットワークに影響を与えることはない．また，IoTGOネットワークには，ウイルス感染の可能性がある汎用的なPCは配置されていない．

2つ目は認証管理である．IoTGOネットワーク上にあるLTEルータ，Wi-Fiアクセスポイント，IoT端末にはすべて認証機構がある．これらの機器に設定するすべての認証情報はデフォルトではなくすべて書き換えて管理する．また，これらの認証情報は顧客にも公開しない．顧客はIoTGOネットワークが顧客社内で構築されても，そのネットワークを別の目的で利用することはできない．

3つ目はファイヤーウォールである．LTEルータのファイヤーウォールに適切な設定を行い不要な内部／外部からのアクセスを遮断する．

4つ目は，通信の暗号化である．IoT端末からクラウドまでの通信経路すべてにおいて，TLS1.2による暗号化を行っている．

5つ目は可用性に関するもので，IoT端末とWi-Fiアクセスポイント間の通信が不安定になり，接続リンクが切断されたときに備え，再接続のためのアルゴリズムをIoT端末に組み込んでいる．

2.2.7 現場側システムのメンテナンス

現場側システムは，IPSec-VPNを使用し弊社からのみ接続できる．この接続により，機器の診断・不具合時の調査・ファームウェアのアップデート・設定変更をリモートで行うことができる．また，機器のLEDランプを数秒間動画撮影したファイルを入手することによっても機器診断が可能であるため，これらを活用しメンテナンスおよび問題解決を行っている．

2.2.8　現場設置機器の電源確保

3種類の機器のうち，LTEルータについては，標準的な構成では1台設置することになる．LTEの電波状況がよく，AC100V電源がとれる場所に設置する．そのため，AC100Vの電源を採用しても設置に困るケースは少ない．Wi-Fiアクセスポイントについては，PoE（Power over Ethernet）対応でかつ耐環境性能の高い機器を利用する．PoE対応機器ではネットワーク接続と電源をLANケーブル1本で供給できるため，工場の高所でも電源ラインを新たに敷設することなく設置できる．また，粉塵等の環境面を特に意識しなくても良く，設置計画を立てやすい仕様とした．

IoT端末は，製造設備1台に対して1つのIoT端末の設置が必要である．AC100Vの電源を簡単に用意できない場合もあるため，3種類の現場用システム機器の中で，電源についてもっとも考慮が必要である．最初は電池で駆動させることを検討した．しかし，信号を受信するたびにイベント処理でパケットをクラウドに送信する仕様を実現するためには電池の寿命が問題となる．電池方式を採用した場合，電池を数カ月に1回の頻度で交換する必要があり，メンテナンスに手間がかかる上に電源が原因の非稼働時間が増加してしまう．この問題を解決するため，IoTGOではAC100Vの対応に加えて，DC24V対応とした．DC24Vは，生産設備から比較的取得しやすく，機器が稼働しているときは電源供給されている状態を作ることが容易である．

2.3　クラウド側システム

次に，クラウド側システムとして以下の構成とした．

2.3.1　クラウド側システムの設計指針

クラウド側システムは，送信されたデータの受信処理およびリアルタイムモニタリング処理を安定して行うこと，さらにSaaSサービスの利用量の変化に対応するため，容易に処理能力を変更できることが求められる．この2つの要求を満たす設計を行った．

また，クラウド側システムの下り処理（2.3.4項参照）はWebサーバのPaaSであるApp Serviceにおけるプログラミング要素が多く，顧客が利用するUI部分に直結する部分でもあるため，分かりやすいUIとセキュアプログラミングを両立させる必要があった．

2.3.2　システム構成

クラウド側のシステム構成要素と現場システムとの関連を図6に示す．図の矢印はデータの流れを示している．クラウド側システムは，Microsoft Azureの複数のPaaSとそれぞれのPaaSに対応したパラメータやプログラムよって構成されている．それぞれのPaaS部品が疎結合している状態で全体を構成する．この構成により，各PaaS部品単位で，スケールアップ／スケールアウトが可能になり，効率的にシステムの増強が可能になる．

どちらの増強方法も簡単に処理能力を高めることが可能である．ただし，スケールアウトを行う場合はソフトウェアの設計に注意する必要がある．たとえばWebサーバ機能をスケールアウトすると処理が複数のサーバに割り振られることになるが，1台のサーバを前提とした処理は不具合を起こす可能性が高くなる．

クラウド側システムは，上り側処理と下り側処理の2つの機能に分けることができる．上り側処理は，現場側システムから送信されたデータの受信とストリーム解析，保管のためのデータ処理および，データ保管機能である．

下り側処理は，リアルタイム集計を行い，Webブラウザによるリアルタイムモニタリングを提供する機能である．上り側処理と下り側処理は疎結合であるため，プログラミング要素の多いリアルタイムモニタリング機能で不具合があり，この下り側処理が停止したとしても，上り側のデータ受信・保管処理は独立した処理として動作が可能である．

2.3.3　上り側処理

現場側システムから送信されたデータは，クラウド側システムのIoT Hub[4]で受信する．IoT Hubは管理対象デバイス間の安全で信頼性の高い通信を行うだけでなく，大量のデータ受信にも特化したPaaSサービスである．IoT Hubは事前にデバイスIDをクラウド上に登録した信頼済みの機器としかHTTPS通信を行わない．IoT Hubで受信したデータは，Stream Analytic[5]に送られる．Stream Analyticsは，ミリ秒未満の待機時間で大量のストリーミングデータを分析および処理できるように設計されたストリーム処理エンジンである．ここでデータの分類，データの正常性の判定，データの分析を行い，取り出したデータをPaaSサービスとしてのSQL Databaseにローデータとしてストアする．データストアと平行して，Service Bus Queue[6] サービスを通じQueueデータとして下り側処理にデータを渡す．

2.3.4　下り側処理

下り側処理の中心はApp Service[7]である．App ServiceはWebアプリケーションをホストするためのHTTPベースのサービスである．ここで演算処理を実行し，顧客向けのリアルタイムモニタリングUI画面を生成し提供する．App ServiceはService Bus Queueから渡されたデータと過去のデータを蓄積しているSQL Databaseのデータを使用し，1.3節で示した表示用データを計算する．顧客は，WebサーバであるApp Serviceにアクセスすることでモニタリング画面を表示することができる．App Serviceにアクセスするためには，ID認証を必要とする．ID認証ではAzure Active Directoryを使用したSAML認証[8]を利用できるため，生体認証を含む多要素認証を使用したID認証も利用可能とする．

リアルタイムモニタリングを実現するためには，アクセスするWebブラウザとクラウド側システムが常時接続し，セッションが継続していなければならない．通常のブラウジングに用いるHTTP通信やHTTPS通信は1回の接続で1つのリクエストしか処理することができない．また，サーバ側から通信を始めることはできない．この問題を解決するためにWebSocketプロトコルを使用した．WebSocketプロトコルは，一度セッションを確立すると，そのセッション上で継続して通信を行うことが可能になり，サーバからも通信を行うことができる．本システムではWebSocketプロトコルを利用することでリアルタイムモニタリングをブラウザ上で実現した．WebSocketはAzure PaaSであるSignal R[9]を利用し実装している．

2.3.5　UI設計

Webブラウザで利用する画面のルックアンドフィールは利用者の使用感につながるため，UI設計は重視し慎重に行った．

IoTGOリリース前の9カ月間は，関連会社の工場で実証実験を行った．そして，現場担当者が直感的に工場全体の生産設備の稼働状況を把握できることなど現場からのニーズに基づき迅速にUI実装を行い，その評価を繰り返し行い最終的な設計とした．リリース後も顧客の要望に基づき継続的にバージョンアップを行っているため，UI設計はそのつど微調整を行っている．

2.3.6　クラウド側システムのセキュリティ

Microsoft AzureのPaaSを利用して構築していることで，PaaSクラウドサービスモデルのセキュリティ上の利点の恩恵を受けることができる[10]．物理インフラ部分については，Microsoftによって継続的に監視されているため攻撃は困難である．ただし，Webアプリケーションでは，コーディングレベルでなりすまし，改ざん，情報漏洩，権限の昇格などの脅威に対策する必要がある．そのセキュリティ上の防御を検証するために，第3者による侵入テストや脆弱性検査を行っている．

3．DX推進支援サービスとしての取り組み

導入前の顧客にはIoT SaaSサービスがDX推進に役立つことを啓蒙し，導入した顧客に対しては，より具体的な活用方法を提案する活動を行っている．

3.1　検討フェーズにおける取り組み

2019年5月より，リアルイベントとしてIoTGO導入工場見学会を毎月開催してきた（図7）．2020年5月からは，新型コロナウイルスの影響で，リアルイベントをバーチャルイベントとしてリニューアルした．リニューアルしたイベントはIoTGOバーチャル工場見学会と名付け，Microsoft TeamsライブイベントによりIoTGOの導入事例の紹介を続けている．疑似見学する導入事例工場は関連会社の久野金属工業（株）である．システム開発時には9カ月間にわたりIoTGOの現場テストを実施，その後，本番運用のために60台のIoT端末を設置し，システム運用した結果を工場見学の疑似体験を踏まえて紹介している．

バーチャル工場見学会では，IoT機器の取り付け状況の紹介，効果的な利用方法，導入効果，利用コストについて詳しく解説する．顧客はSaaSサービスとしてのIoTとはどのようなもので，どのように役立つのかということを具体的に実感できる．顧客が自社の工場に導入した場合の具体的なイメージを持つことがIoT導入の最初のステップとなる．

イベント参加者にはトライアル導入特典が付与され，サービス申込み前に，自社の生産設備の計測を1カ月間試みることができる．生産設備1台だけの接続となるが，IoT導入効果を実証できる機会を持つことで導入イメージがより明確になる．

3.2　導入フェーズにおける取り組み

現場用IoT機器はすべて設定後に出荷するため，顧客は機器を取り付け，マスタデータを入力すればすぐに運用を開始できる．取り付けや配線方法については，図解の詳細なマニュアルを提供する．また，事前にトライアル導入を実施していれば，その時点で工場内のWi-Fi環境調査も実施済であるため，導入はより円滑に行うことができる．

3.3　データ活用フェーズにおける取り組みと効果

IoT端末で収集，蓄積したデータはリアルタイムモニタリング以外にも改善活動，現場担当者への稼働率の意識付け，設備投資の経営判断等，幅広く活用可能である．

3.3.1　改善活動の効率化

製造業で生産性向上を推進する有効な方法の1つとして改善活動がある．改善活動を推進，評価するためには信頼できるデータが必要である．サイクルタイムの短縮を改善の目的とする場合には，改善前のサイクルタイム測定と改善後のサイクルタイムに有意差があるかが評価のポイントになる．また，チョコ停を減らして稼働率を上げることを目的とする場合には，チョコ停回数を正確に把握している必要がある．いずれの場合も正確なデータが必要である．IoTGOは，24時間，生産設備の稼働状況を正確に記録，分析し続けるため，収集したデータを使っていつでも改善の効果を検証できる．改善活動は直接的な生産性向上の源泉となるが，従来のストップウオッチを使用した時間測定による改善活動と比較し正確性，長期のデータ収集，データ収集の自動化という点において，IoTの利用は改善活動に大きな効率化をもたらす．

3.3.2　現場担当者への稼働率の意識付け

IoTのリアルタイムモニタリング機能により，刻々と変化する稼働率を見える化できても，人がモニタを見て内容を認識しなければその意味は薄れる．これを解決するため，リリース前の9カ月の実証実験中に実施したデジタルとアナログを併用する運用を，顧客にも実施してもらうよう提案している．

この運用方法は次のようなものである．作業者は現場に設置されたモニタで担当設備の稼働状況，稼働率を確認し，それを毎日，手書きでグラフにプロットする．そして，このグラフを現場に掲示する．生産設備単位にグラフを作るため，昼勤と夜勤は同じ用紙上にプロットする．その結果，担当設備の数だけ手書きグラフが作成される．すると，担当現場間や昼勤，夜勤の稼働率の差や推移が一目瞭然となる．グラフへのプロットはモニタを1日に1回見ることで可能であるが，担当者はより多くの回数モニタを見るようになったと報告された．デジタルとアナログを併用することで，現場の稼働率への意識付けが効果的に行われ，モチベーション向上による生産性向上も実証実験中に示された．

3.3.3　データによる経営判断に活用

IoTGOには過去6カ月のローデータを含むすべてのデータをクラウド上に蓄積しており，ダウンロードして活用することができる．たとえば，製品増産に対応する必要があり，経営判断をする場合を考えてみる．この場合，設備を拡張する，あるいは稼働率の伸びしろから設備拡張は見送る，といった選択肢がある．IoTでデータを収集していれば，このような経営判断をデータで裏付けることを可能にする．中小企業において各製造設備の正確な稼働率を把握していることは少なく，IoTによって収集されたデータは，このようなデータによる経営判断に役立てることができる．

3.3.4　活用支援活動

顧客におけるIoTGOの活用を支援するために，2つの支援を行っている．1つ目は，IoTGO寄り添いサービスである．顧客がIoTGOを効果的に利用できるよう個別に運用アドバイスを行う．2つ目は，IoTGOを利用した現場の改善コーチングサービスである．現場改善コンサルタントと手を組み，IoTGOで収集したデータを活用した改善手法を教育するプログラムを構築，提供している．

1つ目は，主に経営層や管理者に対するサービスであるが，2つ目は現場担当者に対する教育サービスとなる．

4．今後の課題と展望

今後，2つの課題に対して取り組むことを計画している．1つ目はSaaSサービスのオプションとして，生産性向上だけでなくカーポンニュートラルに役立つツールとしても提案できるようにすることである．

IoTGOは2019年に愛知環境賞優秀賞[11]を受賞した．関連会社の久野金属工業（株）で実証したものであるが，生産性向上による環境負荷の低減と，低炭素社会の形成に大きく貢献するものと評価された．このときは，生産性向上による全体の残業時間の減少から電力使用量の減少を間接的に導きだした結果であったが，今後はより直接的に電力使用量を製造設備単位に可視化することを計画している．各設備の電流値を測定し電力使用量に換算するしくみは，これまでのデジタル入力とは異なり，アナログ入力の測定も可能にする必要がある．ハードウェア構成から見直しの必要があるが，顧客のコスト増をできるだけ押え，SaaSとして手軽に利用できるサービスとして提供できるようにしたい．

2つ目は，SaaSサービスであるため，顧客固有のカスタマイズができないという問題の解決である．顧客がIoTGOを利用し始めると標準機能にはない顧客固有の要望がでてくることがある．このうち，汎用的な要望に対しては，SaaSサービスの定期的なバージョンアップによって機能を実現し対応できるが，個別のカスタマイズにはこれまで応じることができなかった．今後は共用のSaaSクラウド環境とは独立した専用のクラウド環境を要望に応じ提供することを計画している．クラウド環境を共用することで，コストを抑えたサービス提供が可能というコンセプトとは相反するが，柔軟にカスタマイズできるもう1つのIoTGOとして提供する．また，専用クラウド環境であっても顧客からはSaaSサービスとして見えるようシステム運用管理は弊社が行う計画である．

アナログ入力への対応と個別カスタマイズを可能にすることにより，多種のセンサへの対応や，故障予兆検知，CO2排出量測定，稼働状況データから改善の優先順位の高い生産設備の提案や改善ポイントを提案するAI機能など，今後応用範囲を広げることができる．今後もSaaSサービスの優位点を活かしつつ，多くの製造業で利用される役立つサービスを提供し，DX推進の一翼を担いたいと考えている．