予知保全：予測型メンテナンスを支えるデータプラットフォーム

計画外のダウンタイムは、製造業で最も高くつく時間です — そしてその大半には予兆があります：上昇する振動値、ドリフトする電流、じわじわ上がる温度。予知保全（Predictive Maintenance）は、これらの前兆を計画可能なメンテナンスに変えます。しかし多くのプロジェクトが失敗するのはモデルではなく、その手前 — インフラです：状態データがそもそも収集されておらず、履歴がなく、得られた知見が保全チームに届かないのです。

本ガイドでは、IronFlockで予知保全の土台を築く方法を紹介します — センサーの後付けから、データ履歴、そしてアラームとAIエージェントまで。

課題：予知保全は分析で失敗するのではない

ほぼすべてのプロジェクトに、4つのハードルが現れます：

• 状態データがない。 振動、消費電流、温度は、既設マシンではそもそも計測されていないことが多く、コントローラが知っている値は制御盤の外に出てきません。
• 履歴がない。 異常は正常状態との比較でしか検出できません。数か月にわたる欠損のない時系列がなければ、参照点がまったくないのです。
• 設備ごとの孤立ソリューション。 ベンダー縛りの状態監視システムが監視するのは1台のマシンです — マシン群全体ではなく、拠点をまたぐことはなおさらありません。
• ラストワンマイルの欠如。 誰にも届かない予測は、故障を防ぎません。知見はアラーム、ダッシュボード、作業指示として、チームに届かなければなりません。

ステップ1：状態データを収集する — 既設マシンでも

データ基盤を作るのは、マシンネットワーク内のエッジPC（ゲートウェイ）上でコンテナとして動作する、工場データ抽出のコレクターアプリです：

• IO-Linkによる後付け。 IO-Link Collectorは、後付けの振動・電流・圧力・温度センサー（ifm、Balluff、Pepperl+Fuchsなど）を接続します — 自動センサー検出と自動IODDデコード付きで、アカウントもAPIキーも不要です。コントローラに手を触れることなく、既設マシンに状態データを持たせられます。
• コントローラからの値。 Industrial Collectorは、PLCや可変周波数ドライブから電流、回転数、状態を読み取ります — OPC UAとModbusは現在利用可能で、Siemens S7とAllen-BradleyはEarly Accessです。アクセスはデフォルトで読み取り専用です：コレクターが設備に書き込むことは決してありません。
• CNCマシン。 MTConnect Collectorは、工作機械から状態、プログラム、軸データを提供します。

すべての測定値は正規化され — 名前、単位、タイムスタンプ、品質フラグ、セマンティック型付き — 接続断の際にはローカルにバッファリングされます。デバイスエージェントが、ゲートウェイを常時オンラインかつリモート管理可能に保ちます。

ステップ2：履歴を構築する — 自分自身のデータベースの中に

各プロジェクトは、単一の信頼できる情報源として専用のTimescaleDB時系列データベースを持ちます。予知保全にとって、これは次のことを意味します：

• 欠損のない時系列 — 数か月、数年にわたって。そもそも異常を異常と認識できるようになるための基準です。
• データ主権。 データの所有者はプロジェクト所有者であり、アプリ開発者ではありません。分析パートナーへのアクセス権は細かく付与でき、いつでも取り消せます。
• オープンな標準。 ベンダーロックインではなく、標準のTimescaleDBとオープンなフォーマット — 既存の分析ツールをそのまま載せられます。

ステップ3：しきい値からAIエージェントへ

予知保全は機械学習から始める必要はありません。IronFlockは段階的な導入を可能にします：

• ステージ1 — しきい値とアラーム。 組み込みのアラームシステムが、重大度レベル（マイナー、メジャー、クリティカル）ごとの条件でライブテレメトリを監視し、メールまたはSMSで通知します — 例えばISOの経験則に基づく振動しきい値の超過などです。自動解決とコメント機能も備えています。
• ステージ2 — 可視化とトレンド。 Board Studioでは、コードなしでトレンドダッシュボードが作れます：振動の推移、週次比較の消費電流、設備ごとのスプリットチャート。しきい値を破る前に、怪しいドリフトが見えてきます。
• ステージ3 — アプリとしての分析。 分析アプリは、クロスアプリデータアクセスを通じて蓄積された履歴に読み取り専用で乗ります — 振動・電流・温度の履歴を分析する予知保全アプリは、このアーキテクチャの文書化された模範例です。こうしたアプリはApp Storeからインストールするか、自分で開発します。
• ステージ4 — AIエージェント。 Physical AIを使えば、状態データに自然言語で質問できます。さらにアプリは独自のアプリエージェントを同梱でき、故障予測を説明し、異常スコアを解釈し、保全アクションを提案します。これらの機能は、アプリをインストールするだけで自動的にAIアシスタントで利用可能になります — 設定は不要です。

注意: 分析と予測モデルは、意図的にアプリとして設計されています — プラットフォームのブラックボックスとしてではなく。どのロジックがどのデータの上で動いているかが常に追跡可能であり、専門家の知見をアプリとして、どのプロジェクトにも持ち込めます。

代表的な状態量 — そこから何が分かるか

導入時にどの状態量を選ぶべきかは、設備によって異なります。定番を一覧にまとめます：

この一覧を実用的なものにしているのは、2つの点です。第一に、すべての状態量が同じ正規化スキーマで保存されるため、トレンドボードやアラームは、振動でも圧力でもまったく同じように機能します。第二に、一度に全部やらないこと。最重要設備の1つの状態量を確実に収集するほうが、履歴のない10の状態量に勝ります。

機械メーカーの皆様へ：予知保全をサービスとして展開する

マシンを製造する企業は、予知保全をデジタルサービスとして提供できます — 予知保全は、アプリディストリビューターの文書化された代表例の1つです：あなたが提供するのはエッジロジックとドメイン知識であり、アプリ配布、ロールバック付きアップデート、セキュアなリモートアクセス、メッセージング、データ保管はプラットフォームが担います。デプロイオプションにより、同じサービスがクラウドでも、顧客先のアプライアンスでも、顧客のプライベートクラウドでも動作します — コード変更なしで。

よくある質問

導入にはどんなデータが必要ですか?

一般に思われているより少なくて済みます。設備ごとに継続的に収集された1つの状態量 — 消費電流、振動、温度のいずれか — があれば、数週間の履歴で信頼できるトレンドと意味のあるアラームしきい値が得られます。拡張はいつでも可能です：コレクターは共通のテーブルスキーマを使用し、ダッシュボードや分析もそのまま一緒に成長します。

独自の機械学習モデルを開発する必要がありますか?

いいえ。段階的な導入は、しきい値アラームとトレンドダッシュボードから始まります — モデルは一切不要です。分析はアプリとして追加します：App Storeから、専門家から、あるいは自社開発で。そうしたアプリのAIエージェントは、その後自動的にアシスタントで利用可能になり、異常や保全推奨に関する質問に答えます。

最新のインターフェースを持たない既設マシンでも機能しますか?

はい — それが最も多いケースです。後付けのIO-Linkセンサー（振動、電流、温度）は、コントローラに手を加えることなく、自動的に検出・デコードされます。コントローラのデータが利用できる場合は、OPC UA、Modbus、MTConnect経由で補完的に追加できます。

収集と分析はどこで動きますか — クラウドかエッジか?

収集は常にエッジで動きます。マシンネットワーク内のゲートウェイ上のコンテナで動作し、接続断の際はローカルにバッファリングします。履歴と分析はプロジェクトデータベースにあります — クラウド（EUデータセンター）、ローカルネットワーク内のアプライアンス、プライベートクラウドから選べます。機能はすべてのモデルで同一です。

次のステップ

現実的なスタートはこうです：はじめにガイドでゲートウェイを接続し、IO-LinkまたはIndustrial Collectorをインストールして、最初の状態量をボードに表示する — デモモードなら、ハードウェアなしでも可能です。構成要素の詳細はこちら：工場データ抽出、IoTアラーム、Physical AI。