メインコンテンツまでスキップ

異常検知・インシデント対応

PlantPulse AI は異常を検知し、AI が診断して対処を提案し、人が承認して対処を実行し、その結果を自動で検証します。 画面上ではこの案件をインシデントと呼びます — 故障だけでなく、アラームや異常信号からも起票されるためです。2026-10-14 より前の画面では «故障受付» と表示されます。API・設定キーの名称は incident です。

감지 (이상탐지 · 알람 · 고장 전조)
  → 확인할 이상 · 이상 접수 + 알림 (화면 · 메일 · Slack · 푸시)
  → AI 진단 (원인 후보 · 제안 조치)
  → 사람이 승인 (고쳐서 승인 · 거절) · 조치 실행
  → 자동 재발 검증 (기본 1시간 뒤)
  → 결과 기록 · 종결

画面で行うこと — 確認・承認(修正して承認・却下)・対処の実行・結果の記録・終結 — はすべて提案(/tasks)の詳細画面で行います → 提案 — タスク・異常・インシデントを最後まで。こちらでは、その裏でサーバーがいつ何をするかを記します。

旧画面からの変更点

«異常診断» ・ «解決» メニューとモバイル専用版(/m)は廃止されました。確認すべき異常とインシデントは提案 › タスク › 突発にあり、 新しい画面はスマートフォンでもそのまま使えます(ホーム画面にアプリとして追加できます)。旧 URL からのリダイレクトはありません → コパイロット画面マップ — 旧 URL

異常検知 — いつ何を測るか​

対象周期(既定)設定
全体スキャン — 全設備。センサーは直近でタグが動いた設備のみ2時間ごとanomaly.schedule.cron
ターゲット検知10分ごとanomaly.targeted.cron
ERROR アラーム受信(MQTT 購読) → インシデント常時(購読確認は毎分)incident.mqtt.subscribe.cron
故障予兆の早期警報受信 → インシデント毎時incident.precursor.poll.cron
エンジンが自ら記録した AI 発見の取り込み1分ごとfinding.poll.cron

時刻はすべて、設置先の工場タイムゾーン基準です。

1設備・1時間 = 1行​

設備異常は1設備につき1時間ごとに1行として記録されます。センサー・OEE・RAM・エネルギーはその行の中の分類であり、タイトルと重大度は 異常タグ数と異常分数(直近1時間のうち異常だった分数)で決まります。

重大度直近1時間の異常分数(既定)設定
低10分以上 — これ未満なら行を記録しませんanomaly.asset.min.minutes
中20分以上anomaly.asset.medium.minutes
高40分以上anomaly.asset.high.minutes
  • 提案の確認すべき異常の1行がこの行です。同一原因に由来する異常は1行にまとめて表示されます。
  • anomaly.exclude.assets(既定 TEST_*,ASSET_TEST_*)に含まれる設備は検知から除外します。
  • 検知対象は、エンジンが設備ごとに判定した適格性に従います — センサー検知・生産(OEE・RAM・作業オーダー)・エネルギー。該当する検知が一つもない設備はスキップします。
  • しきい値は anomaly.detector.score.threshold(センサー、空欄ならエンジン既定値)・anomaly.detector.domain.score.threshold(その他、既定 0.5)です。 設備ごとのセンサーしきい値は AI が自動で調整します → AI 発見と精度

故障予兆の早期警報​

時系列エンジンは現在の波形を過去の ERROR アラーム直前の波形群と突き合わせて故障リスクを測ります。コパイロットはその結果を毎時取り込み、 故障として起票します — 異常が «すでに発生した» ではなく «発生しそう» な段階でインシデントが先に作られます。チャットで「この設備の故障予兆リスクを確認して」 と直接尋ねることもできます → 時系列インサイト

インシデントが作られる経路​

経路条件
設備異常重大度高以上で自動的に(下限 incident.source.anomaly.minSeverity)
ERROR アラームPlatform のアラームを受信した時点で即時
故障予兆上記の早期警報
人提案の確認すべき異常からインシデントに昇格
自動化自動化が結果に付けたインシデント起票を人が承認したとき → 自動化 — 承認アクション
  • 同じ問題がすでに開いている場合は新規作成せず、そのインシデントに統合します(発生回数のみ増えます)。
  • 作成されたインシデントは診断キューに入り、AI が順に診断します(原因推定と対処案を最大4件)。
  • ソースごとに有効・無効を切り替えます — incident.enabled ・ incident.source.*。
  • 旧来のウォッチは廃止され、インシデントを起票しなくなりました。以前ウォッチが起票したインシデントはそのまま残っています → 自動化

通知チャネル​

チャネル受信条件設定
画面 — サイドバーの通知ベルと通知一覧(/alerts)常時。直近24時間以内の範囲の確認すべき異常・インシデント—
プッシュ — スマートフォン・ブラウザ重大度高(既定)以上。端末ごとに設定 › 通知で有効化しますpush.enabled ・ push.notify.severity
メール宛先・等級を設定した場合anomaly.notify.email.* ・ incident.notify.email.*
SlackWebhook・等級を設定した場合anomaly.notify.slack.* ・ incident.notify.slack.*
  • 画面通知とプッシュは、利用者ごとにその人の設備範囲内のものだけが届きます。
  • プッシュを有効にする場所は設定(/settings) › 通知 › スマートフォン・ブラウザ通知です。HTTPS の URL でのみ動作し、iPhone・iPad はホーム画面に追加したアプリからのみ利用できます → コパイロット画面マップ — 設定 ・ コパイロットの開き方
  • プッシュをタップすると提案 › タスク › 突発が開きます。以前受け取った通知・メールの旧リンクはリダイレクトされず「該当する画面がありません」と表示されます — 提案から探してください。
  • 異常・インシデント通知のメール・Slack は、管理コンソールのシステム設定(/admin/config)で上記のキーを使って設定します → コパイロット管理コンソール
管理 › 通知チャネルは自動化の送信先です

管理コンソールの通知チャネル(/admin/channels)に登録する Teams・Slack チャネルとメール許可ドメインは、自動化の «送信» が使うものです — 自動化が結果をメッセンジャーチャネルや社内メールへ送る際、ここで登録したチャネルと許可したドメインにのみ送信されます。上表の異常・インシデント通知はこの画面を使わず、 システム設定のキーに従います(メッセンジャーは Slack Webhook)。 → コパイロット管理コンソール ・ 自動化 — 送信

対処の4種類 — 実行すると実際に起こること​

AI 診断が出す対処案は4つの類型で、提案詳細で対処の実行を押すと以下が起こります。

類型押すと実際に起こること
アラーム確認 (ack_alarm)Platform の該当アラームを確認済みにします
担当者への通知 (notify)受信者(下記)へインシデント概要のメールを送ります。メールサーバー(SMTP)のないインストールでは実行できません(下記)
現場点検の指示 (inspect)実行提案に点検カードを発行して受信者(下記)を割り当て、結果登録リンク入りのメールを送ります。メールは付加的なものなので、SMTP がなくてもカードは発行します
追加調査 (investigate)外部への動作はありません — «調査項目を受け付けた» という事実のみを実行者・時刻とともに記録します
  • 受信者 — 通知・点検を受け取る人は管理コンソールの担当者名簿から来ます(ログインアカウントとは別)。 対処案の役割(整備・運用・安全)と担当者の通知役割が同じで、担当範囲(サイト・設備 — 空なら全体)がこのインシデントをカバーする人がちょうど 1 人のときだけ自動で決めます。 いないか複数なら実行せず、実行する人が画面で選びます。«名簿の最初の人» に送ることはありません → コパイロット管理コンソール — 担当者
  • SMTP のないインストール — メールサーバー(smtp.host・smtp.username)が空なら、担当者への通知はこのインストールでは使えません。AI 診断にもこの対処を出さないよう伝え、 それでも出た通知の対処は画面で理由とともにブロックされ、失敗記録は残しません — 何度押しても同じです。他のチャネルに切り替えて送ることはしません。 メールサーバーが送信を拒否すると「メールサーバーが通知メールを送信できませんでした(…)。メール設定を確認してください。」で失敗します → システム設定
  • 誰が — «対処の実行» 権限(approve:incident_action)を持つ人にのみボタンが表示されます(既定は班長・保全・工場長・管理者) → 権限 対処案の承認・修正して承認・却下は、インシデントを見られる人(menu:resolve)なら行えます → 提案 — 措置案の検討
  • 重複防止 — 二人が同時に押しても片方のみ実行されます。実行済みの対処は再実行できず、失敗した対処のみ再実行できます。
  • 安全範囲 — 設備制御コマンドは実行対象ではありません。アラーム確認・通知・カード発行のような、元に戻せる対処のみ実行します。
  • 実行・失敗・終結はすべて、詳細の経過に実行者・時刻とともに残ります。
  • 点検指示メールを受け取った担当者は、メール内のリンクからログインなしで対処結果(完了・該当なしとメモ)を登録できます。

再発の自動検証​

対処を実行すると、1時間後(既定、incident.verify.delay.minutes = 60)に同じ設備で異常が再発したかどうかをサーバーが自動で確認します。確認は毎時実行されます。

結果画面
再発なし完了タブに «再発なし»、ヘッダー行の検証合格 % に算入されます
再発完了タブに «再発» と表示され、ヘッダー行の再発件数に算入されます — 追加対応が必要なサインです

提案の完了タブのヘッダー行(対処・処理時間・検証合格・再発・結果待ち)が、この検証の成績です。

手付かずのインシデントは自動的にクローズされます​

ケース既定設定
異常検知が起票したインシデント(人がまだ着手していないもの)が再発なく静穏6時間後に «解消» として終結incident.autoresolve.quiet.hours
処理中のインシデントが再発・状態変化なく長期化7日後に終結incident.stale.close.days
診断を受けられないまま残ったインシデント24時間後に終結incident.diagnose.expire.hours

0 以下に設定すると、前の2つは無効になります。クローズした事実は経過に残ります。

AI 発見から始まる対処​

時系列エンジンが自ら見つけた AI 発見(オーダー目標未達・部品遅延の回復案・故障リスク …)も同じ原則に従います — AI は提案し、人が決めます。 いずれのボタンも設備を制御したり、オーダー・スケジュールを変更したりしません。発見の種類と通知ルールは AI 発見と精度にあります。

AI 提案カード — 受諾・却下・効果​

人の判断が必要な発見 — オーダー目標未達・部品遅延の回復案・故障リスク — は提案 › 計画に AI 提案カードとして上がります (故障リスクはその判定が現場で有効な場合のみ)。詳細の AI 提案判断欄で受諾・却下し、受諾後は 効果あり・効果なし・まだ不明を記録します → 提案 — AI 提案判断

  • 受諾・却下は記録のみです — オーダー・スケジュール・設備が自動で変わることはありません。
  • 同じ設備・同じ種類の発見は、その日1枚のカードにまとめられます。
  • まとめられた発見がすべてクローズされ、人が手を付けていないカードは一覧から外れます(記録は残ります)。

修理後の自動確認​

却下理由として**「すでに実施しました」**を選ぶと、サーバーはその対処が効いたかを自動で測定します(finding.repair.enabled、既定は有効)。

結果意味
効果を確認タグが基準範囲に戻った、または条件が解消して再発しませんでした
効果なし同じ異常が再び現れた、またはタグが基準範囲外のままでした
判定不可稼働中のデータが不足していたか、条件の解消を確認できませんでした

確認時間は種類によって異なります — 多くは安定化30分 + 確認120分、データ断・電力ピークは15分 + 60分。結果はその提案の効果記録として残り、人が付けた記録を上書きすることはありません。

承認 → ドラフト​

提案が他システムのアクションに対応している場合、カードに承認すると作成されるドラフト欄が表示されます。現在対応しているのは2つです。

提案作成されるもの対象
部品遅延の回復案発注ラインの督促依頼ドラフトサプライチェーン(SCM)
故障リスク設備の保全依頼MES
  • そのアクションを発行する有効なコネクタがデジタルスレッドに登録されている必要があります。無い場合、カードでは受諾・却下・効果のみ行えます。
  • 作成されるのは、そのシステムのドラフト・依頼 1件です。確定はそのシステム内で人が行います。同じ提案を二度承認してもドラフトは1件です。
  • 承認理由・2人承認・権限は 提案 — 承認すると作成されるドラフトにあります。
  • コネクタの登録は AI 管理コンソールのデジタルスレッドで行います → デジタルスレッド

関連ドキュメント​