【テンプレート付】予知保全AIの要件定義｜機能要件・非機能要件チェックリストと進め方

予知保全AIの要件定義とは

予知保全AIにおける要件定義とは、振動・温度・電流・音響などのセンサーデータや稼働ログから設備の劣化・故障を予測するために、対象設備・故障モード・予測リードタイム・許容する見逃し率と誤報率を文書化する工程です。単なる異常検知の導入ではなく、保全業務（CBM／TBMの切り替え判断、作業指示、部品手配）にどう接続するかまでを定義します。データの欠損・偏りや故障ラベルの不足を前提に、どこまでをルールベース、どこからを機械学習で扱うかの境界も決めます。

なぜ要件定義で予知保全AI導入の成否が決まるのか

予知保全AIは、故障という稀少事象を限られたラベルデータで学習する難しさを抱えており、要件定義で対象設備と故障モードを絞り込めないと、精度が出ないまま現場に不信感だけが残ります。誤報が多すぎれば現場は警報を無視し、見逃せば事故につながるため、許容ラインの合意が導入の成否を分けます。

• 正常データばかりで故障ラベルがほとんど無く、教師あり学習が成立しないまま見切り発車する
• 誤報（過検知）が頻発して現場が警報を信用しなくなり、アラート無視が常態化する
• 予測が出ても交換部品や保全要員の手配が間に合わず、リードタイムの定義漏れで価値が出ない
• 対象設備を絞らず全ライン一括導入を狙い、設備ごとに異なる故障モードを学習しきれず精度が崩れる

要件定義で決める5つの範囲

1. 対象設備と故障モード — 軸受・モーター・ポンプ・コンプレッサーなど対象を特定し、ベアリング摩耗・ミスアライメント・絶縁劣化等の故障モードを列挙する範囲
2. センシングとデータ取得 — 振動（FFT）・温度・電流・音響・潤滑油分析など計測項目とサンプリング周波数、既設センサーの流用可否を定める範囲
3. 予測・診断ロジック — 異常検知（教師なし）、余寿命予測（RUL）、故障分類のどれを採用し、しきい値判定とAIの役割分担を決める範囲
4. 保全業務連携 — アラートから作業指示・部品手配・CMMS登録までのワークフローと、CBMへの切り替え判断を含む範囲
5. 運用・再学習 — モデルの精度監視、誤報のフィードバック収集、ドリフト発生時の再学習サイクルを定める範囲

予知保全AIでは「設備1台ごとに故障モードと正常範囲が異なる」ため、対象を絞らずスコープを広げると学習データが分散し精度が出ません。

要件定義の進め方：5ステップ

ステップ	内容	アウトプット
①	対象設備と故障モードの特定。過去の故障履歴・MTBF・保全コストから優先設備を選び、予兆が出る故障モードに絞る	対象設備リスト、故障モード一覧（FMEA連携）
②	予兆データの棚卸し。既設センサー・PLC・SCADAから取得可能な計測項目と、故障ラベルの有無・データ期間を確認する	データ可用性マップ、不足センサーの追加計画
③	予測要件の定義。予測リードタイム、許容見逃し率・誤報率、診断粒度（部位特定まで行うか）を現場と合意する	予測要件定義書、KPI目標値
④	PoC計画と検証設計。対象1～2設備で異常検知精度を検証し、現場の保全判断に使える形か確認する	PoC計画書、評価データセット
⑤	業務連携と運用設計。アラートから作業指示・CMMS登録・再学習までの運用フローと体制を定める	運用設計書、再学習ルール

KPIは「検知率（再現率）」「誤報率（適合率）」「予測リードタイム」「計画外停止の削減率」を必ず置き、精度指標と業務効果指標の両面で目標を定めます。

機能要件チェックリスト（予知保全AIの核心）

予知保全AIに求める代表的な機能要件です。自社の状況に照らして「必須／任意／不要」を判断してください。

大分類	主な要件項目
データ収集・前処理	振動・温度・電流・音響データの時系列取り込み, サンプリング周波数の設定, 欠損・外れ値の補完, FFT等の特徴量抽出
異常検知	教師なし学習による正常範囲の自動学習, マハラノビス距離・オートエンコーダによる異常スコア算出, 多変量同時監視, ベースライン（運転条件別）の自動更新
余寿命予測（RUL）	劣化トレンドの外挿による残存稼働時間の推定, 故障到達確率の時系列出力, 運転負荷を考慮した寿命補正, 予測の信頼区間表示
故障診断・部位特定	故障モード分類（ベアリング・アンバランス・ミスアライメント等）, 周波数スペクトルからの原因推定, 過去類似事例の提示, 推奨対処の表示
しきい値・アラート管理	段階的アラート（注意・警告・危険）, 運転条件別しきい値, アラート抑制（チャタリング防止）, エスカレーション通知
保全ワークフロー連携	アラートからの作業指示自動起票, CMMS/EAMへの保全実績登録, 部品在庫の引当・発注連携, CBM切り替え判断の記録
可視化・ダッシュボード	設備別の健全性スコア表示, 劣化トレンドのグラフ, ライン全体のヘルスマップ, アラート履歴と対応状況の一覧
モデル運用・再学習	予測精度のモニタリング, 誤報・見逃しのフィードバック収集, データドリフト検知, 設備改造・部品交換後の再学習トリガー
エッジ・現場処理	エッジでの特徴量計算と一次判定, 通信断時のローカルバッファリング, 高速サンプリングデータの間引き送信, エッジモデルの遠隔更新

見落としがちな要件: 見落としがちなのは「運転条件の正規化」と「故障ラベルの収集設計」です。同じ設備でも負荷・回転数・季節で正常範囲が変わるため運転状態の取り込みが必須で、また故障が起きた際にラベルを後から付与する運用を決めておかないと再学習が回りません。

非機能要件で見落としがちなポイント

機能だけに目が向きがちですが、非機能要件こそ稼働後の満足度を左右します。

区分	確認すべき要件（目標値の例）
性能	高周波振動データ（例: 数kHz以上）のリアルタイム特徴量処理と、異常スコアの算出遅延を数秒以内に抑える
可用性	24時間連続稼働する設備監視のため、監視基盤の稼働率99.9%以上、エッジ側で通信断時もローカル判定を継続
拡張性	対象設備の追加（例: 数十台から数百台規模）にスケールでき、設備タイプ別モデルを横展開できる構成
セキュリティ	OT/IT境界の通信を一方向化（DMZ経由）し、制御系ネットワークへの逆流を防ぐ、データ送信の暗号化
運用保守	モデル精度の継続監視と再学習を保全部門が運用でき、ベンダー依存なくしきい値調整が可能なこと
移行	既設のSCADA/ヒストリアンに蓄積された過去データ（数年分）を学習用に取り込めること
コンプライアンス	労働安全衛生・設備の法定点検記録と整合し、保全実績の証跡をトレーサブルに保持すること

予知保全AIは制御系（OT）に近い領域で動くため、性能やセキュリティの非機能要件はIT系システム以上にOTネットワークの制約を前提に定義する必要があります。

基幹・周辺システムとの連携要件

どのシステムと、何を、どの方式（API/CSV/EDI）で、どの頻度で連携するかを定義します。

連携先	主な連携内容
PLC / SCADA / DCS	設備の稼働信号・運転条件・センサー値をリアルタイムに取得し、運転状態を予測の入力に反映する
ヒストリアン（PIシステム等）	過去の時系列データを学習・ベースライン作成用に取り込み、長期トレンドを分析する
CMMS / EAM（保全管理システム）	アラートから作業指示を起票し、保全実績・部品交換履歴を双方向で連携して再学習に活用する
IoTゲートウェイ / エッジデバイス	後付け振動・温度センサーのデータを収集し、エッジで一次処理して基盤へ送信する
MES / 生産管理システム	生産計画と照合し、計画停止時に保全を割り当てるなど稼働状況を加味した保全タイミングを調整する
通知基盤（メール・チャット・Andon）	段階的アラートを保全員・現場監督へ通知し、現場のアンドン表示と連動させる

予知保全AIの連携で最重要なのはCMMS/EAMとの双方向接続で、ここが切れると予測が保全アクションと実績ラベルにつながらず価値が出ません。

RFP（提案依頼書）に盛り込むべき項目

要件が固まったら、ベンダーへの提案依頼書（RFP）にまとめます。最低限、次の項目を含めます。

• 対象設備の故障モードと、それぞれに対する検知方式（異常検知／RUL／故障分類）の実現方法
• 故障ラベルが少ない・無い状況での学習アプローチと、PoCでの精度検証方法
• 誤報率と見逃し率のトレードオフをどう調整できるか、しきい値運用の柔軟性
• 既設PLC/SCADA/ヒストリアンおよびCMMSとの具体的な連携実績と方式
• OTネットワークのセキュリティ要件への対応（一方向通信・エッジ処理）
• 導入後のモデル再学習・精度監視の運用体制と、自社で調整できる範囲

RFPでは「自社設備の故障モードで本当に予兆が取れるか」をPoC前提で問い、精度の数値約束より検証プロセスの確かさを評価します。

ベンダーを横並び比較する評価マトリクス

ベンダー評価軸は、予知保全AIの核心である「対象設備・故障モードでの検知精度の実証力」を最重視し（重み高）、次いでOT/制御系との連携実績、現場が使えるアラート運用設計、再学習の自走しやすさを重み付けします。回転機械の振動診断など特定設備の知見を持つかも加点軸にします。

汎用AI基盤の機能の豊富さより、自社の設備種別での実績と現場保全への接続力を高く重み付けすべきです。

予知保全AI導入でよくある失敗と回避策

よくある失敗	原因	回避策
故障ラベルが無く精度が出ない	正常データばかりで故障事例が蓄積されておらず、教師あり学習が成立しない	まず教師なし異常検知から始め、運用で故障発生時にラベルを付与する仕組みを要件に組み込む
誤報が多く現場が警報を無視する	運転条件の変動を正常範囲に取り込めず、負荷変動を異常と誤判定している	運転状態（負荷・回転数）別のベースラインを設定し、適合率（誤報率）の許容ラインを現場と合意する
予測が保全行動につながらない	アラートからの作業指示・部品手配・CMMS連携が設計されておらず、検知が宙に浮く	要件定義段階でアラートから作業指示・部品引当までの業務フローとCMMS連携を必須にする
全ライン一括導入で頓挫する	設備ごとに故障モードと正常範囲が異なるのに、一律モデルで横展開しようとした	重要設備1～2種でPoCし故障モード別に作り込んでから、設備タイプ単位で段階展開する

チェックリストの使い方（テンプレートとして使う）

本記事の機能要件・非機能要件・連携要件・評価マトリクスの各表は、そのまま要件定義の雛形（テンプレート）として使えます。表をコピーして自社に必要な項目の「要否」「優先度」を記入し、ベンダー回答を並べて比較してください。

1. 各表で自社に必要な項目の要否（必須/任意/不要）と優先度を記入する
2. 不足する自社固有の要件を追記する
3. ベンダー回答（○標準/△設定・追加開発/×不可）を記入する
4. 評価マトリクスで重みと評点を入れ、加重スコアで横並び比較する

※ 記入と加重スコアの自動集計ができるExcelテンプレート（ダウンロード版）は近日公開予定です。