アラーム洪水はなぜ起きるか：「追加は無料」という錯覚
DCS・SCADAの時代になって、アラームの追加は設定画面の数クリックになりました。計器ごとに上下限を入れれば警報が出ます。コストがかからないため、設計時に「念のため」で足され、トラブルのたびに再発防止として足され、誰も削除しないまま増え続けます。その結果が、1人のオペレーターが対応できる量を桁で超えるアラームの洪水です。
洪水状態の害は、うるささではありません。確認応答（アクノリッジ）が作業ではなく反射になることです。鳴る→内容を見ずに消す、が習慣化した制御室では、重大な警報も同じ反射で消されます。プラント事故の調査報告書に「事故前に警報は出ていたが、多数の警報に埋もれていた」という記述が繰り返し登場するのは、この構造のためです。
この問題を体系化したのが、プロセス産業のアラーム管理標準 ANSI/ISA-18.2（Management of Alarm Systems for the Process Industries、現行版は2016年改訂）です。同標準の中心思想は明快で、「アラームとは、オペレーターの対応（アクション）を要求する通知である」と定義した点にあります。対応が定義できない通知はアラームではない、この一行が、以下のすべての設計の根拠になります。
合理化と優先度付け：全アラームに「対応」と「猶予」を問う
ISA-18.2が要求する中核の活動が合理化（Rationalization）です。既存・新規のすべてのアラーム候補に対して、次を文書化します。
- このアラームが示す異常は何か（何が起きている）
- オペレーターが取るべき対応は何か（何をすべきか）
- 対応しなかった場合の結果は何か（安全・品質・設備・環境への影響）
- 対応に使える時間はどれだけか（猶予時間）
対応が書けないアラームは、記録やイベントログに格下げして警報から外します。優先度は「結果の重大性×猶予時間」のマトリクスで機械的に決めます。重大かつ猶予が短いものが最高優先度です。重要なのは、優先度を「担当者の感覚」や「声の大きい部署の要求」で決めない仕組みにすることです。感覚で付けた優先度は高側に偏り、最高優先度が多数を占めて再び差が消えます。優先度の分布（最高は数%、大半は低優先度になるのが健全）を合理化の成果指標として使います。
この合理化の成果物（対応手順・結果・優先度）は文書で終わらせず、アラーム発生時に画面へ表示される情報として実装します。鳴った瞬間に「何をすべきか」が出ることが、合理化の投資を現場の価値に変えます。
抑制とシェルビング：「黙らせ方」を区別して設計する
アラームを一時的に黙らせる機能は必須です。設計の要点は、性質の違う3つの黙らせ方を区別して実装することです。混ぜて1つの「無効化フラグ」で作ると、統制不能になります。
| 方式 | 意味 | 発動の主体 | 設計上の統制 |
|---|---|---|---|
| 状態ベース抑制（Suppression by design） | プラント状態により無意味なアラームを自動で出さない（停止中の設備の低流量警報など） | システム（設計されたロジック） | 抑制条件自体を合理化の対象として文書化・承認する |
| シェルビング（Shelving） | オペレーターが一時的に棚上げする（既知の対応中で鳴り続ける警報など） | オペレーター | 期限付き（時間で自動復帰）、棚上げ中の一覧が常時見える、対象と件数に制限 |
| 保全時の取り外し（Out-of-service） | 工事・保全のため計画的に無効化する | 保全・運転の承認プロセス | 承認と期限、復帰確認を伴う。無期限の取り外しを許さない |
3つに共通する原則は、黙っているアラームが「見える」ことです。いま何が抑制され、何が棚上げされ、何が取り外されているかの一覧が1画面で確認でき、シフト引継で必ず伝わる。黙らせた事実が見えなくなった瞬間、それは安全上の穴になります。とくにシェルビングの「自動復帰」は譲れない仕様です。人が戻す設計は、戻し忘れという最悪の失敗モードを持ち込みます。
MESとSCADAの役割分担：管理のループはレベル3の仕事
アラームの検知と一次表示はDCS・SCADAの仕事であり、MESが警報の応答時間を競う場所はありません。ではMES層（レベル3）は何を担うのか。答えはアラーム管理のマネジメントループです。
第一に、分析です。アラーム履歴を蓄積し、発生頻度の高いアラーム（バッドアクター）のランキング、オペレーターあたりの発生率、洪水（短時間の大量発生）の頻度、常時鳴りっぱなし（stale）の警報、シェルビングの多用状況を定期レポートにします。ISA-18.2はこうした性能監視をライフサイクルの一部として要求しており、改善対象の特定はこの分析から始まります。バッドアクター上位の少数が全体の大半を占めるのが通例で、上位から順に「合理化し直す・設定値を直す・設備を直す」ことで総量が大きく下がります。
第二に、変更管理です。アラーム設定値の変更・追加・削除を、承認と履歴を伴うプロセスに載せます。合理化の成果は、現場の設定変更が野放しなら数年で溶けます。設定のマスタ管理と承認フローはMES/上位層の得意領域です。
第三に、文脈の付与です。アラーム履歴を工程実績・品目・ロットと突き合わせられるのはMESだけです。「この品目の切替時に必ず出るアラーム」「このロットの品質異常と同時刻の警報」という分析は、ダウンタイムの記録と分析やSPCの傾向監視と組み合わせることで、アラームを品質・稼働の改善データに変えます。
よくある質問
既存プラントのアラームが数千個あります。合理化はどこから手を付けるべきですか。
全数の一斉見直しは計画倒れになりがちです。実務的な順序は、まず現状測定（直近数か月の履歴からオペレーターあたり発生率・洪水頻度・バッドアクターを算出）、次にバッドアクター上位への集中対応です。発生の大半を占める上位数十個を合理化するだけで、総量は目に見えて減ります。並行して、新設・変更のアラームには合理化プロセスを必須化し、これ以上増えない構造を先に作ります。残りの全数見直しは、ユニット単位・系統単位に区切った複数年計画にするのが現実的です。最初の測定値を残しておけば、改善の効果を数字で示し続けられます。
アラームの発生率は、どの程度なら健全と言えますか。
ISA-18.2は性能監視の枠組みと測るべき指標（発生率、洪水の頻度、優先度分布、stale警報など）を定めており、具体的な目標値は各社がベンチマークを参考に設定します。重要なのは絶対値の当てはめよりも、「1件のアラームには確認・判断・対応の時間が必要である」という原点から、自工場のオペレーターが実際に対応しきれている率を測ることです。応答までの時間が計測されておらず、確認応答が数秒で連打されているなら、数値目標以前に洪水状態です。まず履歴データで現状を測り、対応可能な水準へ下げる改善サイクルを回すことが、標準への適合よりも先に立つ実務です。
品質パラメータの逸脱アラームは、SCADAとMESのどちらで出すべきですか。
判定の性質で分けます。計器値が設定値を超えたという単純な閾値判定で、秒単位の対応が必要なら制御層（DCS/SCADA）です。一方、「この品目のこの工程では管理幅が異なる」という製品文脈に依存する判定、統計的な傾向（管理図のルール違反）に基づく判定、ロットの状態を変えるべき判定（逸脱発生でホールドをかける等）はMES層が適しています。実装上は、MESがオーダー開始時に品目別の管理値を制御層へ書き込み、検知は制御層で行い、発生イベントをMESが受けて記録・状態変更・分析につなげる、という分業が最も堅い形です。
