🏭 製造担当

アラーム管理¶

30秒まとめ¶

アラーム管理（Alarm Management）は、DCS/PLC が出すアラームを「オペレータが確実に対応できる量と質」に保ち続けるための管理・設計の体系です。アラームは1つ1つが「オペレータに1つの操作を要求する異常通知」であるべきなのに、実際の現場では設定のしっぱなしで数が膨れ上がり、平常時から鳴りっぱなし・重大事象時には数百件が一斉に出るアラーム洪水（Alarm Flood） に陥りがちです。洪水は本当に重要な1件を埋もれさせ、過去の重大事故でも「警報は出ていたが埋もれて気づけなかった」構図が繰り返されてきました。アラームは LOPA（防護層解析）でオペレータ介入という独立防護層を支える土台であり、その1層が機能する前提が「意味のあるアラームだけが鳴る」ことです。本ページは個別の「アラームが消えない」の切り分け（PLC/DCS トラブル参照）ではなく、アラームを設計・運用・監査でどう管理するかを扱います。

なぜアラーム管理か¶

アラーム洪水が事故につながる構図¶

アラームは「異常を知らせて人を動かす」ためにありますが、数が過剰になると逆に人を止めます。

平常時から鳴りっぱなし（スタンディングアラーム） だと、オペレータはアラーム表示を常時無視する習慣がつき、本当の異常も見逃します
重大事象時に数十〜数百件が一斉に出る（洪水） と、初発事象（first-out）の1件が後続の波及アラームに埋もれ、原因把握と処置が遅れます
埋もれを嫌ってオペレータがアラームを抑制・無効化したまま放置すると、必要なときに鳴らない状態を自ら作ってしまいます

過去の大規模プロセス事故の調査では、「アラームは発報していたが、洪水の中に埋もれて運転員が異常の意味を掴めなかった」という共通の教訓が繰り返し指摘されています。アラーム管理は快適さの問題ではなく、安全の問題です。

独立防護層としての位置づけ¶

機能安全（SIS/SIL）の LOPA（Layer of Protection Analysis：防護層解析）では、危険シナリオを止める独立防護層（IPL）を積み重ねます。その1つがオペレータ介入、すなわち「アラームで気づいた運転員が手動で処置する」層です。

アラームが埋もれれば、その防護層は数えられない

LOPA でオペレータ介入を防護層に数える前提は、「アラームが確実に認知され、対応する時間がある」ことです。洪水でアラームが埋もれる／平常時から鳴っていて無視されている状態では、この層は有効な IPL として成立しません。アラーム管理は、LOPA で見込んだリスク低減を実際に成立させるための土台です。SIS（安全計装システム）が最後の砦だとすれば、アラームはその手前でオペレータに処置の機会を与える層であり、SIS とは独立に働くべきものです。

規格体系（EEMUA 191 / ISA-18.2 / IEC 62682）¶

アラーム管理には広く参照される国際的な指針・規格が3つあります。位置づけを1行ずつ整理します。

規格	位置づけ	補足
EEMUA 191	アラームシステムの設計・管理・調達のガイドライン。実務的なベンチマーク指標を早くから示した先駆け	英国 EEMUA 発行。ガイドライン（強制規格ではない）
ISA-18.2（ANSI/ISA-18.2）	アラーム管理のライフサイクルを規定した米国の標準。フィロソフィ策定〜監査までの工程を体系化	規格一覧に掲載（ISA 発行・有償）
IEC 62682	ISA-18.2 を土台にした国際規格。プロセス産業のアラームシステム管理	内容は ISA-18.2 とほぼ整合。国際案件で参照される

本ページの数値は有償規格の原文照合ではなく二次資料ベース

EEMUA 191・ISA-18.2・IEC 62682 はいずれも有償で、本ページ執筆時点で原文を直接照合できていません。以下のベンチマーク指標は、複数の公開二次資料（技術誌・ベンダー技術資料・業界解説）で一致して引用されている値のみを「目安」として掲載しています。自社のアラームフィロソフィや実際の運用目標を定める際は、必ず原規格の最新版を入手して確認してください（各規格の現行版と照合状況は下記「根拠と適用上の注意」参照）。

ベンチマーク指標¶

以下はすべて EEMUA 191 等が示す「目安」であり、法定値・強制基準ではない

ここに挙げる数値は業界で広く引用される目標値の目安です。法令や規格が義務づける値ではありません。プラントの特性・オペレータ配置・プロセスの動特性によって適正値は変わります。自社の目標は原規格とアラームフィロソフィに基づいて定めてください（法定値と社内目安を区別して明示する、という本 Wiki 共通の考え方です）。

「1オペレータ（1操作ポジション）あたり」が評価の基本単位です。複数のオペレータで持つ盤なら人数分の余地があります。

定常時の平均アラーム率¶

状態	目安（1オペレータあたり）	評価
定常運転時の平均	1件/10分以下（＝6件/時・144件/日以下）	十分に対応可能（望ましい）
—	1件/5分程度	対応可能（許容範囲の上限に近い）
—	1件/2分程度	過負荷ぎみ（要改善）
—	1件/分超	対応不能（明らかに過剰）

ISA-18.2 系の二次資料では、目標として 1〜2件/10分・6〜12件/時・150〜300件/日 の範囲が広く引用されます（1〜2件/10分を 24 時間に引き直すと 144〜288 件/日で、引用されている 150〜300 は丸めた値です。2026-09-19 に再計算）。12件/時を超えると管理困難、30件/時超は深刻に不良とされます
EEMUA 191 系では、定常時 1件/10分以下なら「十分に対応可能な可能性が高い」 とされ、上表のように率が上がるほど許容度が下がる段階評価が示されています

アラーム洪水（Alarm Flood）の定義と目標¶

指標	目安
洪水の開始	10分間に 10件超の新規アラーム
洪水の継続	以降の10分区間で新規アラームが5件未満に落ちるまで洪水とみなす
目標	システムが洪水状態にある時間が全体の1%未満

洪水は「結果」であり、原因は最初に起きた1点です。洪水時の初発事象（first-out）の追い方は PLC/DCS トラブルの SOE（事象記録）を参照してください。

優先度分布とその他の指標¶

指標	目安	意図
優先度分布（低:中:高）	おおむね 80 : 15 : 5（高優先度は5%以下）	高優先度が多すぎると「全部が重要＝どれも重要でない」に陥る
優先度の段階数	3〜4段階まで	段階を増やしすぎるとオペレータが区別できない
スタール（スタンディング）アラーム	24時間以上有効なアラームが 1日あたり5件未満	鳴りっぱなしの常態化を防ぐ
チャタリング／フリートアラーム	0 を目標	短時間に付いたり消えたりする無意味な発報をなくす
上位10アラームの寄与	全アラームに占める割合が数%以下	少数の「うるさい」アラームが総数を押し上げていないか

書かなかった値

「確認済み（acknowledge）アラーム率」などの一部の運用 KPI は、二次資料間で目標値の引用が一致しなかったため、本ページでは具体値を掲載していません。これらは各社のアラームフィロソフィで定めるべき項目です。

アラームライフサイクル¶

ISA-18.2 はアラーム管理を単発の改善活動ではなく、継続的なライフサイクルとして回すことを求めます。一度合理化しても、プロセス変更・設備増設で必ず劣化するためです。

flowchart TD
    P["① フィロソフィ策定（Philosophy）<br>全ての土台。優先度定義・目標値・運用ルールを文書化"]
    I["② 特定（Identification）<br>どの異常をアラームにするか同定"]
    R["③ 合理化（Rationalization）<br>1件ずつ「本当に要るか・設定値・優先度」を精査"]
    D["④ 詳細設計（Detailed Design）<br>HMI表示・優先度色・抑制ロジックの設計"]
    O["⑤ 運用（Operation / Monitoring）<br>実績KPIを常時測定"]
    A["⑥ 監査・MOC（Audit / Management of Change）<br>定期監査で劣化を検知、変更は必ずMOC"]
    P --> I
    I --> R
    R --> D
    D --> O
    O --> A
    A -- フィードバック --> P

①フィロソフィ策定 が全ての起点です。「アラームとは何か・優先度をどう定義するか・目標 KPI は何か」を文書で定め、以降の全工程が従います
③合理化 がアラーム管理の核心で、次章で詳述します
⑥監査・MOC を欠くと、せっかく合理化しても数年で元の氾濫状態に戻ります。アラームの追加・整定値変更・優先度変更は必ず MOC（変更管理）を通します（DCS の MOC 枠組みと同じ考え方です）

合理化の実務¶

合理化（Rationalization）は、既存の全アラームを1件ずつ「本当に必要か・設定値は妥当か・優先度は正しいか」の観点で棚卸しする作業です。

大原則: 1アラーム = オペレータの1操作¶

アラームの定義を全員で共有する

アラームは「オペレータが認知して対応行動を取るべき異常」に限ります。次のどれかに当てはまらないものは、アラームにせず単なる表示（ログ・トレンド）に格下げします。

オペレータが取るべき明確な対応操作がある
放置すると望ましくない結果（トリップ・品質逸脱・設備損傷）に至る
対応するための十分な時間的余裕がある

「一応知らせておきたい」程度の情報はアラームにしません。これが総数を膨らませる最大の原因です。

アラーム数を減らす設計手段¶

手段	内容	効果
設定値の見直し	実運転の正常変動域の外側に整定値を置く	正常変動での不要発報を止める
デッドバンド（不感帯）	復帰しきい値に幅を持たせる	しきい値付近の振動によるチャタリングを防ぐ
遅延（オンディレイ）タイマ	一定時間継続して初めて発報	瞬時的なノイズ・過渡変動での発報を抑える
優先度付け	高/中/低を対応の緊急度で割り当てる	洪水時に「まず何を見るか」を明確化
状態依存の抑制（後述）	運転モードに応じて無関係なアラームを隠す	起動/停止/バッチ切替時の一斉発報を抑える

チャタリング対策は、デッドバンドと遅延タイマの併用が基本です。しきい値ちょうどでアナログ値が振動すると付いたり消えたりを繰り返すため、復帰側にヒステリシス（デッドバンド）を設けます
優先度は緊急度と結果の重大さで決めるもので、「なんとなく重要そう」で高優先度を乱発しないことが、前章の分布目安（高5%以下）を守る鍵です

不良アラームのパターンと対策¶

現場のアラーム氾濫は、いくつかの典型パターンの積み重ねです。パターンごとに狙って潰します。

パターン	症状	対策
スタンディング（スタール）	平常時から鳴りっぱなし。24時間以上有効のまま	整定値が実運転域に食い込んでいないか見直し。不要なら削除
チャタリング	短時間に付いたり消えたりを繰り返す	デッドバンド拡大＋オンディレイタイマ。しきい値付近の振動を吸収
フリート	チャタリングより頻度は低いが断続的に再発	発生条件をトレンドで分析し、根本の変動源（制御・機械）を是正
重複（ダブル）	1つの異常で複数アラームが連鎖発報	因果関係のある下流アラームを抑制（親アラームだけ残す）
状態依存の不要発報	起動/停止/バッチ切替時に無関係なアラームが一斉に出る	状態依存抑制（state-based suppression）で運転モードに応じて隠す

状態依存の抑制（Suppression）¶

運転モードによって「今は鳴っても意味がない」アラームがあります。例えば設備停止中の「流量低」アラームは、止めているのだから当然で、意味を持ちません。

運転状態（起動中・運転中・停止中・バッチ工程 N など）を条件に、その状態で無意味なアラームを自動的に抑制します
抑制は「消す」のではなく「その状態の間だけ隠す」もので、状態が変われば自動復帰します
手動での恒久的な無効化（後述）とは区別します。状態依存抑制はロジックで管理された正当な手段です

抑制は設計された仕組みで。手動放置と混同しない

状態依存抑制は「フィロソフィと設計に基づいてロジック化された」抑制です。オペレータがうるさいからと手動でアラームを無効化して放置するのは、これとは全く別物で、必要なときに鳴らない危険な状態です。抑制の設計と、無効化の放置を混同しないでください。

現場の落とし穴¶

落とし穴	何が起きるか	対策
アラームの無断追加・整定値変更	フィロソフィ外のアラームが増え、分布・総数が崩れる	追加・変更は必ず MOC。フィロソフィとの整合を審査
手動無効化（抑制の乱用）の放置	うるさいアラームを消したまま復帰忘れ。必要時に鳴らない	無効化は時間管理・見える化・復帰確認。恒久無効は MOC で審査
高優先度の乱発	「全部が重要」で優先度が機能せず、洪水時に判断できない	高優先度5%以下を KPI で監視。優先度は結果の重大さで機械的に
合理化しっぱなしで監査を欠く	数年でプロセス変更により氾濫状態へ逆戻り	定期監査で KPI を測定し、劣化アラームを再合理化
状態依存抑制のロジック未整備	起動/停止のたびに洪水が発生し、オペレータが慣れて無視	運転モード条件で抑制を設計。抑制対象は文書化
KPI を測らずに「問題ない」と思い込む	実際の発報率・洪水頻度を知らないまま放置	DCS のアラーム集計機能で発報率・上位アラーム・洪水頻度を定期測定

アラーム管理は「作って終わり」ではなく「測って回す」

アラームシステムは放置すると必ず劣化します。発報率・洪水頻度・優先度分布・上位アラームを定期的に測定し、悪化を見つけたら合理化に戻るライフサイクルを回し続けることが、オペレータ介入を有効な防護層に保つ唯一の方法です。

根拠と適用上の注意¶

規格の存在と現行版（発行元カタログで 2026-08-01 に確認。規格本文は未照合）¶

規格	現行版（発行元での確認結果）	照合状況
ANSI/ISA-18.2	ANSI/ISA-18.2-2016 "Management of Alarm Systems for the Process Industries"（ISA 製品カタログで現行版として確認）	番号・名称・版のみ確認。本文は有償で未照合
IEC 62682	IEC 62682:2022（Edition 2.0、2022-12-08 発行。IEC Webstore で現行版として確認）	同上
EEMUA 191	EEMUA Publication 191 "Alarm systems - a guide to design, management and procurement" 第4版（2024年。EEMUA 製品ページで確認。初版は 1999 年）	同上

本文の「IEC 62682 は ISA-18.2 を土台にした国際規格」「内容はほぼ整合」という位置づけ、および3者の整合性は、発行元の解説記事・複数の二次資料レベルでの確認であり、条・節単位の照合ではありません。

ベンチマーク数値の性格（すべて二次資料ベースの目安）¶

本文のベンチマーク（定常時 1件/10分・6件/時・150件/日、洪水＝10分間に10件超、洪水時間 1 % 未満、優先度分布 80:15:5、スタンディング 5件/日未満、チャタリング 0 など）は、複数の公開二次資料で一致して引用されている値のみを載せた目安です。有償規格の原本を照合していないため、どの規格の第何節の規定かは本ページでは特定せず、逐語引用もしていません（原本未照合の規格の扱いは SIS・SIL の根拠節と同じ方針です）。法定値・強制基準ではありません。
版の古さに注意: EEMUA 191 は第4版（2024年）で全面的に更新・再構成されており、流通している二次資料の多くはそれ以前の版に依拠している可能性があります。ISA-18.2 も 2009 年初版→2016 年版と改訂されています。目標値を自社のアラームフィロソフィに採用する際は、必ず原規格の最新版で確認してください。

正典参照¶

LOPA・IPL・SIS の枠組み → SIS・SIL が正典（IEC 61511 も原本未照合のため、本 Wiki では条番号・逐語引用をしない方針）
初発事象（first-out）の追跡・SOE → PLC/DCS トラブル
規格番号一覧上の位置づけ → 規格一覧

限界の明示¶

本ページのみを根拠に、自社のアラームフィロソフィの数値目標・優先度定義・抑制ロジックの設計を確定しないでください。原規格（最新版）の入手・照合と、自プラントの動特性・オペレータ配置の評価が前提です。
過去の重大事故で「警報が埋もれた」構図が指摘されたという記述は、公開されている事故調査の解説に基づく一般的な教訓の要約であり、特定の事故報告書の逐語引用ではありません。