KYB技報

第63号

2021―10

技術解説

設備予知保全システムの開発
Development of an Equipment Predictive Maintenance System
古 川
輝 ・ 井 指 諒 亮
FURUKAWA Akira・ISASHI Ryosuke

要
旨
製造業において，高い品質のものを安定して生産

Abstract
In the manufacturing industry, maintenance activities for machines and equipment operating at
し続けるためには，生産現場で稼働する機械や設備
production sites are essential for maintaining staの保全活動が必要不可欠である．設備保全の考え方
ble production of high-quality products. The conとしては，故障が発生したときに保全を行う「事後cept of equipment maintenance can be broadly di保全」，一定の回数または期間稼働させたときに保vided into three categories: breakdown
全を行う「予防保全」，故障の兆候が見られたとき
maintenance, preventive maintenance and predicに保全を行う「予知保全」に大別される．近年，tive maintenance. In recent years, predictive mainIoT（Internet of Things：モノのインターネット）
tenance has been attracting attention due to theやAI（Artificial Intelligence：人工知能）の発展に
development of the Internet of Things（IoT）and
伴い，「予知保全」が注目されており，FA機器を提Artificial Intelligence（AI）.
供しているメーカーなど，多くの企業で予知保全のOn the other hand, KYB’s equipment mainte研究開発，サービス提供が行われている．
nance methods focus on breakdown maintenance
一方，KYB社内の設備保全方法は「事後保全」
and preventive maintenance. In the former case,と「予防保全」が中心となっており，前者では設備
equipment failure causes a drop in productivity
故障による生産性の低下や製品不良の発生，後者でand product defects, and in the latter case, excesは過剰保全による保全コストの増加が課題となってsive maintenance increases maintenance costs.
いる．
To solve these problems, we have developed an
そこで，これらの課題を解決するため予知保全の考えを取り入れた設備予知保全システムを開発した． equipment predictive maintenance system. Thissystem utilizes the latest technologies, including
本システムはIoT，AI，クラウドといった最新の技
IoT, AI, and cloud computing, to build a system術を活用してデータ収集，保管，故障予知，見えるwith functions such as data collection, storage, fail化といった一連の機能をシステムとして構築し，実
ure prediction, and visualization and the system is
用レベルで運用を開始している．本報では予知保全
now in operation at a practical level. This paperを実現するために開発した各要素機能とグローバルに展開するために構築した運用管理の仕組みや特徴について解説する．

describes the basic functions developed to realize
predictive maintenance, and the operation management mechanisms and features that have beendeveloped for global deployment.

― 15 ―

設備予知保全システムの開発

１

緒言

３

システムの概要

近年，IoTやAIが急速に発展しており，学術界やIT業界のみならず，医療や製造業などのあらゆる

3. 1 システム構成
予知保全を実現するためには設備の状態を特定する分野において注目を集めている．
製造業においては，IoTやAIを活用して，
「不良
品の検出」
，
「設備の故障予知」，「生産計画の最適化」

ためのデータを収集する必要があるが，対象設備や検知したい故障によって収集項目や方法が異なってくる．
一般的によく利用されているのは「振動」データであなどが取り組まれており，従来よりも高い精度で実現することが可能になっている．
設備の故障予知に目を向けると，設備の状態を監るが，高サンプリング（例えば10kHz以上）で収集されることが多く，その際は大量のデータが発生する．
一方で対象設備によっては，低サンプリング（例えば視し，故障発生時期を予測することで，故障の兆候が見られたときに保全を行う「予知保全」を実現する見込みが立ってきた．予知保全を行うことで適切なタイミングで保全することができ，故障発生の未１ Hz程度）でも十分な場合もあり，その際は発生する
データも少量になる．よって多くの設備に対して汎用的なシステムとして展開していくためには，大量データにも耐えうる構成を持ちながら，少量データの場合で然防止に加え，部品を最大限使用することができる． は低コストに実現できる仕組みの構築が必要であった．
よって，理想的には設備保全にかかる費用を最小限
前記内容を実現するためには，データ量や処理量に抑えることが可能である．
一方，KYB社内の設備保全方法は故障が発生したときに保全を行う「事後保全」と一定の回数または期間稼働させたときに保全を行う「予防保全」が中心となっている．前者では設備故障による生産性の低下や製品不良の発生，後者では過剰保全による保全コストの増加が課題となっている．
そこで，これらの課題を解決するため予知保全の考えを取り入れた設備予知保全システムを開発した．
本システムはIoT，AI，クラウドといった最新の技
術を活用してデータ収集，保管，故障予知，見える化といった一連の機能をシステムとして構築し，実用レベルで運用を開始している．

に応じてストレージ容量や処理能力をスケールさせる必要があるが，従来のオンプレミス注２）では，そういったことは実現できない．そこで本開発ではパブリッククラウドのAWS（Amazon Web Services）上に当社独自のプラットフォームの構築を行った．
図 １ に開発したシステム構成の概略図を示す．
一部を除き，ほとんどをサーバーレス注３）のサービ
スで構築することによって，処理性能もそれに従うコ
ストも「使った分だけ支払う（従量課金）」仕組みにできるため，規模に見合った対応が可能となっている．
注 ２ ）自社内の設備で自社内のシステムを構築すること
注 ３ ）サーバを自前で用意せず，AWSなどが管理するマ
ネージドサービスを活用し，処理に必要なリソースを動的に設定してシステムを構築する考え方のこと

２

要件

予知保全を実現し，システムとして運用していくための要件を以下に示す．
①設備から収集したデータを継続的に蓄積・分析できる環境を構築すること．
②設備の故障予知では正常／異常を判定するだけ
ではなく，故障危険度を数値化できること．
③故 障直前ではなく， ２ 週間以上注１）前に故障予知が可能であること．
④現在の設備の状態を可視化して，事務所からでも確認できること．
⑤一部の設備に特化せず，多くの設備で汎用的に使えるようにすること．
⑥グローバル展開を可能とすること．

3. 2 設備データ収集
データ収集は対象設備の状態を特定するために設置したセンサのデータを定期的にFAコンピュータに取り込んでファイルに保存し，さらにそのファイルを定期的にAWSにアップロードする仕組みを構築した．
参考までに，製品搬送用のオーバーヘッドトロ
リーコンベア装置でデータ収集したときの事例を紹介する．写真 １ はコンベアの駆動源である駆動モータ の 周 辺 を 示 し た も の で， 加 速 度 セ ン サ は 搬 送チェーンの駆動部分（写真 １ の左下）に設置している．写真 ２ が加速度センサの設置場所を拡大したものである．本設備では駆動部分の振動を計測することで搬送時の故障予知を狙っている．
予知保全では長期的な視点で設備の摩耗などによる状態変化を検出する必要があるが，突発的に発生行う期間を考慮して設定した期間，実際には設備にする故障については検知の対象とはしていない．そのため常にデータを収集する必要はなく，例えば「 １

よって必要な期間は異なる

時間毎に10秒間だけデータ収集する」といったよう

注 1）故障予知後，保全準備（部品手配，人員確保）を― 16 ―

KYB技報

図1

第63号

2021―10システム構成図（概略図）

は，AWSの サ ー ビ ス で あ るAWS IoT Core注５）とAWS STS注６）を用いて実装し，最終的にはAWSのストレージサービスであるAmazon S3に保存されるようにした．これらのサービスを用いることでAWS上に登録されたデバイスのみが，一時的な認証情報を用いてセキュアにデータをアップロードすることが可能となっている．
注 ４ ）Programmable Logic Controllerリレー回路の代替装置として開発された制御装置

写真 1

注 ５ ）IoTデ バ イ ス をAWSの 各 種 サ ー ビ ス に 接 続 す る

コンベア装置サービス
注 ６ ）AWS Security Token Service．AWSリ ソ ー ス にアクセスするための一時的なセキュリティ認証情報を提供するサービス

3. 3 設備故障予知機能
3. 3. 1 機能の概要

本開発では予知保全を実現するために，機械学習を用いた故障予知機能の開発を行った．今回のような設備の正常／異常（故障）を判定する場合，一般

写真 2

加速度センサ設置場所に定期的な処理で十分である．よって本開発では一定周期で一定時間のデータを収集してファイル出力するアプリケーションを開発した．なお，収集デー
タを一度ファイルに出力してからアップロードするようにしたのは，PLC注４）など，多くの機器に対して汎用的に使えるからである．
収集ファイルのAWSへのアップロードについて的に「教師あり学習」または「教師なし学習」によって学習を行う場合が多いが，本開発では「教師なし学習」による方法を採用した．理由としては，教師あり学習は学習時に大量の異常（故障）データが必要であるが，故障データを大量に準備することは現実的に困難なためである．そのため，正常データのみを使って学習を行い，正常領域から逸脱を検知する異常検知の考え方を用いている．
また，機械学習でモデル作成を実施するにあたり，「専用モデル」と「汎用モデル」の ２ つの考え方で― 17 ―

設備予知保全システムの開発

おける学習の流れを示したものである．

モデルの作成を行った．
表 １ に ２ つのモデルの比較表を示す．
表1
提供期間
精度
アルゴリズム
特徴量
学習
推論

一般的なAEは入力データと出力データが同じになるようにEncodeとDecodeを行って学習する手法であるが，Spec Masked AEは入力データに対して一部のモデル比較表
専用モデル
数ヶ月
高
任意に選択
任意に選択
手動
自動

汎用モデル
1週間
中注7）
統計的機械学習
統計値ベース
自動
自動

情報を隠すマスクを追加し，そのマスクを除去した出力データが，元の入力データと同じになるように学習する手法である１）．マスクの追加と除去の工程を追加し，あえて問題を難しくすることで過学習注９）を抑制し，汎化性の高いモデルを生成することを狙っている．

注 ７ ） 専用モデルよりは精度が低いが，従来の閾値判定
よりは精度が高いことを示す

専用モデルは特定の設備に特化した機械学習モデルのことである．一般的に機械学習は単純にデータを入力するだけで理想的な結果が得られることは少なく，適切な特徴量の抽出，学習手法の選定，パラメータ設定など，細かいチューニングを行うことでより高い精度の結果が得られる場合が多い．そのため，高い精度が必要な設備においては，その設備に特化した専用モデルの作成を行う．しかし，その反面，細かいチューニングを行うため，モデルの作成に時間がかかるという課題がある．実際に，ある設
備の専用モデルを作成した際は，データの収集を含めてモデルの作成に数ヶ月の期間を要した．
一方，汎用モデルは特定の設備に特化させず，どの設備でも汎用的に使用できるモデルである．汎用
モデルは， １ 週間注８）程度の正常データから，平均値などの統計値を中心とした特徴量を使い，正常データからの逸脱を検知する統計的な機械学習手法
で生成を行う．つまり，シンプルな手法で簡易的な異常検知を行えるようにしたものである．精度は専用モデルより劣るものの，設備によってはこれで十分な場合もある．また，導入当初は即座に適用可能な汎用モデルで運用し，専用モデルが作成できた時点でそちらに切り替えることも可能である．このように ２ つの考え方でモデルを準備することで展開性と精度を両立させた故障予知機能を開発した．
注 ８ ）期間は任意に設定できるようにしている

3. 3. 2 開発事例
任意の設備の専用モデルの開発で考案した手法の一例として，Spec Masked Autoencoderについて紹介する．本手法は，深層学習の手法の １ つである
Autoencoder（以下AE）を応用したものである．
AEは元来次元圧縮や特徴抽出に用いられていた手法であるが，近年はデータ生成，クラスタリング，
異常検知などに活用されており，開発した手法では異常検知の考えを取り入れている．図 ２ が各手法に

図2

AEとSpec Masked AEの学習フロー

注 ９ ） 学習データに適合しすぎて，未知のデータに対して適合できていないこと

3. 3. 3 機械学習モデルの運用管理
機械学習を用いたシステムでは，モデル開発をしたらそれで完了ではなく，システムを継続的に運用するために，全体を正しく管理するための仕組みが必要である．
例えば季節変動や設備の加工条件の変更により，従来から収集データのトレンドが変わった場合，既存のモ
デルでは正しく判定できなくなることがある．その場合，再学習によってモデル更新を行うが，このときモデル評
価，バージョン管理，配布方法などを明確にしていな
いと思わぬ間違いを引き起こしてしまう可能性がある．
本 開 発 で はAWSの サ ー ビ ス のAmazon
SageMaker注10）とAWS Step Functions注11）を活 用してモデル管理と学習・推論のワークフローの構築を行った．例えばモデル管理では開発用か本番用かを示すタグ付けを行い，そのタグを切り替えるだけで本番モデルに切り替えできるようにしている．また，汎用モデルにおいては，学習，配布，推論処理を自動化しており，データを設定した期間収集した時に自動でモデルを生成し，推論が開始されるようにした．
注10） 機械学習モデルを高速に開発，学習，配布するための環境を提供するサービス
注11）AWSの複数のサービスを配置させて，一連のワー
クフローを作成するサービス

3. 4 設備状態の見える化
設備の状態を見える化するため，BIツール注12）で― 18 ―

KYB技報第63号

あるTableauを使った画面を開発した．一部画面について紹介する．
注12）Business Intelligenceツール

企業に蓄積された大量データを集めて分析・可視化をして，迅速な意思決定を助けるためのツール

3. 4. 1 設備異常情報閲覧画面
図 ３ は現在の異常発生中の設備や，故障危険度注13）の分布や推移を表示する画面であり注14），基本的にはメイン画面として常時表示させておく．本画面で異常2021―10
注15）一部の情報は非公開とし，意図的に消去またはぼかしを入れてある3. 4. 3 複数設備統計データ比較画面
図 ５ は複数の設備の収集データに対する統計値の推移を表示する画面である注16）．任意の設備で異常な統計値で推移していたときに，本画面で収集項目や条件が同じ設備と横並びに比較することで，具体的な異常場所を特定することが期待できる．

または故障危険度が高い設備を把握することで，以下に示すようなアクションをとることが可能である．
・設備データ（統計値）を確認する．
・実際の設備を確認する．
・修理に向けて保全計画を立てる．

図5

複数設備統計データ比較画面

注16）一部の情報は非公開とし，意図的に消去またはぼかしを入れてある図3

４

設備異常情報閲覧画面

注13）どの程度故障の危険があるかを数値で示したもの
注14）表示しているデータはサンプルであり，実際とは異なる3. 4. 2 個別設備統計データ閲覧画面
図 ４ は任意の設備から収集したデータに対する各統計値（平均や標準偏差など）の推移やばらつきを表示する画面である注15）．異常または故障危険度が高い設備があったときに，本画面でその設備に対して実際の統計値がどのような値を推移しているかを確認することで，具体的にどのような異常であるかを把握することが期待できる．

設備故障予知事例

本章では開発した専用モデルと汎用モデルによる設備故障予知事例について紹介する．
4. 1 専用モデルを用いた設備故障予知
専用モデルでの事例として，図 ６ にシステム運用
前（データ収集は開始しているがモデルは作成していない状態）に発生した故障に対して，遡って故障予知を実施した結果注17）を示す．図 ６ のグラフは横軸が日付でおおよそ ５ ヶ月分のデータを表示しており，縦軸が機械学習モデルで出力した故障危険度を示している．また， １ 本目の赤破線が，故障が発生
して応急処置を実施した日付， ２ 本目の赤破線が主
要部品を交換した日付である．結果として，機械学
習モデルが出力した故障危険度に対して，最終的に

図4

個別設備統計データ閲覧画面
図6― 19 ―

発生した故障に対する故障予知結果

設備予知保全システムの開発

図のような閾値を設定すれば故障発生の １ ヶ月程度前に予知できるといえる．また，応急処置実施後に故障危険度は減少するものの，ある程度は高い値を推移しており，主要部品交換後に一気に減少する傾向が見られているため，設備の状態に合致した理想的な結果が得られているといえる．
注17）具体的な数値は非公開とし，意図的に消去している

4. 2 汎用モデルを用いた設備故障予知
汎用モデルでの事例として，図 ７ ，図 ８ にシステムが異常検知したときの故障危険度と実際の収集デー
タ（本事例ではいずれも温度）の推移注18）を示す．いずれのグラフも横軸が日付，縦軸が⒜のグラフは故障
危険度，⒝のグラフは温度を示しており，赤丸で囲った部分がシステムで異常検知した箇所である．
図 ７ は通常とは異なる急激な温度下降が見られた
ため異常検知した事例である．通常は自然冷却により緩やかに温度下降していくが，急激に温度下降したことで一気に故障危険度が上昇している．実際は設備の保全作業を実施したことで急激な温度下降が発生し，設備の故障ではなかったが，通常とは異なる変化点を検出することができている．
図 ８ は温度推移に乱れが生じたため異常検知した事例である．通常は温度がほぼ一定か，緩やかに上
昇または下降をしているが，短時間で温度の上昇と下降が連続したことで一気に故障危険度が上昇している．実際は設備の工具交換と調整により，起動と停止を繰り返したことで温度の乱れが生じており，設備の故障ではなかったが，本件も通常とは異なる変化点を検出することができている．
上記で示したように，単純な閾値判定では検出が難しい変化に対しても，汎用モデルを用いることで設備の異常を検知できることが分かる．

図8⒜

故障危険度の推移⒝

実際の温度推移

温度推移の乱れによる異常検知注18）具体的数値は非公開とし，意図的に消去している

５

グローバル展開に向けての取り組み

本開発は図 １ で示した通り，データ分析から可視化までの基盤をクラウド環境で構築している．そのため，従来システムとは異なり，よりスピーディなシステム展開が期待できる．しかし，その利点を活かしつつ安定的なシステム運用を実現するためには
以下の項目を満足する必要がある．
①システムの動作状況が確認できること．
②運用のルールが明確化されていること．
本章では上記の対応について説明する．
5. 1 システム監視機能の開発
本開発ではシステムの動作状況をどこでも把握できるように，Datadogというサーバ監視ツールを駆使してシステム状態の可視化と通知機能を実装した．
図 ９ にシステム監視の一部の構成図を示す．セキュ
リティおよびシステムのログデータをDatadogに全て送信して一括管理し，異常があった場合には，チャットツール（Microsoft Teams）に通知するよ
うに設計しているため，管理者は即座に対応措置をとることが可能である．
システムの監視対象は大きく分けて，①セキュリティ

図7⒜

故障危険度の推移⒝

実際の温度推移

急激な温度下降による異常検知②システムの ２ つが挙げられる．次節にて各監視対象について
具体的に説明する．
5. 1. 1 セキュリティ監視
ここで述べるセキュリティでは，システムに部外者が侵入できる余地がないか，データが漏洩する危険性はないか，攻撃を受けた場合に検知することが― 20 ―

KYB技報第63号

2021―10が安定して稼働しているかを監視する．本開発ではシステムの全体監視機能として，Amazon CloudWatch
注20）（以下CloudWatch）を導入し，メトリクスとログの収集をしている．そして，収集したメトリクスとログはDatadogを利用して可視化を実施している．
Datadogのダッシュボードの一部を図11注21）に示す．
図11は実装している各サービスのメトリクスとロ
図9

グを集中管理しているダッシュボードになっており，どこの処理で失敗したのか，何が原因で失敗したのか，といった状況を把握できるようにしている．

システム監視機能の構成図

できるか，といったセキュアな環境が維持できているかを監視する．設計段階でセキュリティ面を堅牢に構築することが前提条件ではあるが，ネットワー
ク接続している以上いつ外部から攻撃されてもおかしくない．そのため，継続的にセキュリティ監視ができるような環境を構築した．今回はセキュリティの構築と監視の中でも一部の機能について紹介する．
本開発ではAWSへの不審なログインや操作，通信が行われていないかを監視するために，Amazon
GuardDuty（以下GuardDuty）を有効化している．
GuardDutyとは，悪意のある操作や不正な動作を継続的にモニタリングする，フルマネージドの脅威
検出サービスであり，常にAWSを操作するアカウ
ントや通信があったIPなどのログを収集，監視している．これにより，不審なアクセスや操作を監視することが可能である．
また，セキュリティ全体を総括的に確認するためにAWS Security Hub（以下Security Hub）を利用している．Security HubとはAWS上の全てのセキュ
リティ関連情報を集約・管理するサービスであり，前述したGuardDutyの情報も集約の対象である．万が一異常があった場合には，図10注19）の様に発生時
刻，異常の内容，異常が発生した箇所といった情報が通知されるようにしているため，即座にセキュリ
ティの脆弱性に対して対応が可能である．

図11

Datadogのダッシュボード

注20）AWSのリソースやアプリケーションのメトリクス
やログを収集するサービス
注21）システムに関する数値およびログは非公開としている

5. 2 IaCによる運用ルールの明確化
本システムを構築するにあたり，より展開性や保守性を担保するために，Infrastructure as Code（以下IaC）という考え方を採用している．
IaCとは，インフラ構成をコードで管理する考え方であり，従来手動で構築していたサーバ環境やア
プリケーション設定を全てコード化すること指す．
そのため，手動で構築するため手順書は存在せず，代わりに構築する環境をコードで記述した構成管理
ファイルを作成する．図12にIaCと従来運用との違いを示す．IaCによる主なメリットは，手作業が減ることによりヒューマンエラーが減少すること，コード化することでバージョン管理が容易になること，CI/CD注22）の仕組み化が可能になりテストから実装までを自動化できること，が挙げられる．

図10

通知内容

注19）システムに関する数値およびログは非公開としている

5. 1. 2 システム監視システム監視では，正常にシステムが動作しているか，異常が発生した場合に対処が容易かといったシステム― 21 ―

図12

IaCと従来の構築方法の違い

設備予知保全システムの開発

本 開 発 で はIaCの １ つ で あ るHashiCorp社 のTerraformと従来から導入しているバージョン管理ていき，国内外問わずどこにいても全ての設備状態が確認できる環境を提供していく．

ツールのGitLabとを連携することでインフラ構築を自動化し，差分管理できる環境を実現した．これにより，導入拠点が増えた場合でも，同一環境を瞬

また，より有意義な分析ができるよう，様々なシステムとの連携を視野に入れている．直近では保全対応措置の実績データと本開発で収集している設備

時に構築することが可能となった．図13に示した流の振動や温度といったデータの連携を検討している．
れが今回自動化したインフラ構築の仕組みである．
これにより対応措置の効果確認や類似事例の分析と図13内の①，②が従来のマニュアル作成や仕様検討， いったデータ活用の幅が広がることが期待できる．
バージョン管理に該当し，IaC導入によりマニュア
ルの管理は不要となり仕様検討のみとなった．続いて，③のステップでは構成管理ファイルのテストを自動化しており，GitLabにmerge注23）される前に各テストジョブが実施されるようになっている．仮にクリアできなかったジョブがあった場合には，エラー判定となりmergeが出来ない仕様である．

しかし，連携するにあたり課題となるのが，数値デー
タではなく文字データという点である．この問題に対しては，AIを活用したテキスト分析によってより高度な分析ができるようにしていきたい．
最終的には生産情報や品質情報などと連携し，全社を横断するIoT-Platformとして拡大することで，生産性向上や品質向上に貢献していくことが我々の目標である．

７

図13

IaCによるインフラ構築までの流れ

注22）ビルド，テスト，展開を自動化するシステムのこと
継続的インテグレーションと継続的デリバリーの略
注23）編集した内容を元ファイルに統合させることをいう

６

結言

本開発によって，今まで難しかった予知保全を実現し，リアルタイムな設備監視ができるようになった．
また，予知保全が可能になったことで，保守コストの低減も見込まれている．今後は設備保全だけでな
く，様々なシステムと連携することでより高度な分析の実装やデータの付加価値向上を目指していく．
最後に，本開発にあたり多大なるご支援，ご協力を頂いた関係部署の方々に，この場をお借りして厚くお礼申し上げます．

今後の展望

参

考

文

献

本開発により設備故障予知ができるようになり，
さらに設備状態の可視化を通して新しい気付きなどが得られる環境を構築することができた．

１ ）Ayaka Matsui, Shota Asahi, Satoshi Tamura, Satoru

本開発を効率的に横展開していくためには各拠点

vibration using combination of signal processing andとの協力が必要不可欠である．導入拠点と対象設備などを協議しながら，着実に本開発の導入を推進し著

Hayamizu, Ryosuke Isashi, Akira Furukawa,
Takayoshi Naitou, Anomaly detection in mechanicalautoencoder, NCSP’ 20, 2020

者 

古川

輝

井指

諒亮

2005年入社．技術本部DX推進部．

2017年入社．技術本部DX推進部．

データベースを利用した管理シス

データ可視化分析基盤の構築に従

テムの開発に従事．

事．

― 22 ―