このユニットの結論
本番で障害が起きたときの重大度は、「どれだけ業務と利用者に影響しているか」で決めます。原因が分かってから決めるものではありません。
情報が少ない最初の時点で、事前に決めた基準で仮の重大度を付けて対応の体制を動かし、情報が増えるたびに見直すことが大切です。
1. 何の話か
このユニットは、本番で起きた障害の重大度の判断の話です。
テストで見つかった不具合の重大度（10-05）は、直す順番を決めるために、落ち着いて付けることができます。本番の障害は違います。業務が止まっているかもしれない中で、限られた情報から、急いで決める必要があります。
重大度によって、誰を呼ぶか、誰に報告するか、どのくらいの間隔で状況を伝えるかが変わります（13-01）。
2. なぜ必要か
重大度の判断が遅れたり、ずれたりすると、
- 本当は重大なのに少人数で対応を続け、影響が広がる
- 逆に、軽い障害で多くの人を集め、ほかの仕事が止まる
- 経営層や利用部門への報告が遅れ、業務側の対応（手作業への切り替えなど）が始められない
- 「原因が分からないので、重大度も決められない」と、判断そのものが止まる
ということが起きます。
3. このユニットで分かること
- 本番の障害の重大度を決める観点
- 最初の判断と、見直しの考え方
- 重大度によって変えること
- 重大度の判断で、AIに任せてよいことと人間が決めること
4. 重大度を決める観点
一般的には、次のような観点で基準を作ります。
- 業務への影響：どの業務が止まっているか。業務の重要度はどうか
- 影響を受ける人：利用者の一部か、全体か。社外（取引先・顧客）に及ぶか
- データへの影響：データの誤り・欠け・漏えいのおそれがあるか
- 広がり：影響が今も広がっているか
- 回避策：手作業などで業務を続けられるか
- 時間の制約：締め切りのある処理（支払い・報告など）に間に合うか
原因は、この観点に入っていません。原因が分からなくても、影響は確かめられるからです。
教材用サンプル基準の書き方を学ぶための例
| 重大度 | 基準（教材上の例） | 対応の例（教材上の例） |
|---|---|---|
| 1（最も重い） | 重要な業務が全体で止まっている。または社外に影響が及んでいる | 指揮役を置き、関係者を集める。経営層へすぐ報告。決めた間隔で状況を共有 |
| 2 | 重要な業務の一部が止まっている。回避策はあるが負担が大きい | 指揮役を置く。責任者へ報告 |
| 3 | 業務は続けられる。一部の機能に不便がある | 担当チームで対応。通常の報告 |
| 4 | 業務への影響がほとんどない | 通常の問い合わせとして対応 |
段階の数・基準・対応は教材上の例で、アステリア案件の基準ではありません。
5. 最初の判断と見直し
障害の最初の時点では、分かっていることが少ないのが普通です。
- 分かっている範囲で、基準に照らして仮の重大度を付ける
- 迷ったときは、重い方に付けて体制を動かし、影響が小さいと分かったら下げる（重い障害を軽く扱って体制が遅れるより、影響が少ないため）
- 新しい情報が入るたびに見直し、変えたときは、いつ・誰が・何を根拠に変えたかを記録する
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件に関係する記載
- M18 本番稼働、M21 初期安定化完了
- システムに SYS-11 監視・ログ基盤がある
- P-011 山下 恵 — 本番移行・運用リーダー
- AIへ最終委任しないことに「重大障害判断」がある
アステリア案件の障害の重大度の段階・基準、重大度を決める人、報告の経路は、正本に記載がありません。未確定
6. THINK — 夜間の連携が一部失敗した
朝、監視の担当者が、夜間に動く連携の処理が一部失敗していたことに気づきました。今のところ、利用者からの問い合わせはありません。担当者は次のように言っています。
「誰も困っていないようなので、重大度は低くしておきます。原因は昼に調べます。」
問題
この判断でよいでしょうか。
判断例を開く
判断
まだ決められません。「問い合わせがない」ことは、「影響がない」ことの証拠ではありません。
確認すること:
- 失敗した連携のデータは、どの業務で、いつ使われるか（今日の締め切りのある処理に使われていないか）
- 失敗したデータの件数と範囲
- 連携先のシステムで、古いデータや欠けたデータのまま業務が進んでいないか
- 再び処理すれば回復できるか。二重に処理されるおそれはないか
影響を確かめるまでは、仮の重大度で体制を動かし、確かめた結果で見直します。
7. よくある失敗
- 原因が分かるまで重大度を決めない
- 問い合わせの数やエラーの件数だけで重大度を決める
- 最初に付けた重大度を、情報が増えても見直さない
- 重大度を下げた理由を記録しない
- 技術の担当だけで判断し、業務への影響を業務の担当に確かめない
8. 成果物との接続
- OPS-004 障害対応計画：重大度の基準と、重大度ごとの体制・報告を事前に決める
- OPS-005 障害報告書：付けた重大度と、見直した記録を残す
- OPS-002 監視・アラート一覧：障害に気づくための監視と、その通知先
誰が障害対応を指揮するかは 13-03 障害対応を誰が指揮するのか で学びます。危機演習 CR12 本番初日に複合障害 では、稼働初日の障害の場面を体験します（学習上の接続です。正式な対応関係ではありません）。
9. AI WORKFLOW — 影響の情報を整理させる
AIは、監視の通知や問い合わせから、影響の情報を整理する下書きに役立ちます。
指示例:
「次の監視の通知と問い合わせの記録を、影響を受けている業務・利用者・データごとに整理し、まだ確かめられていないことを挙げてください。重大度は付けず、原因も推定しないでください。」
10. REVIEW — AIの整理を確認する
- 整理された影響が、元の記録と合っているか
- AIが重大度を付けたり、「影響は小さい」と結論づけたりしていないか
- 「まだ確かめられていないこと」を、誰がいつ確かめるかを人が決めたか
ADVANCED深掘り — 実務者向けに一段深く
深掘り — 重大度の行列と、暫定の判定
3 つの軸で機械的に仮決めする
影響の範囲（全社か、一部門か、一部の利用者か）、業務への影響（止まるか、遅れるか、不便か）、回復の見込み（すぐか、数時間か、分からないか）。この 3 つの組み合わせで重大度を機械的に仮決めする表を、障害の前に作っておきます。その場の判断に頼ると、人によって重さが変わり、連絡が遅れます。
暫定と言い切って動く
最初に入ってくる情報は不完全です。「仮に重大度 A として動く」と宣言し、情報が増えたら見直します。見直しの時刻（たとえば 30 分後）を決めておくと、仮の判定が放置されません。最初から正確に決めようとして動き出しが遅れるより、仮で動いて直す方が被害は小さくなります。
重大度ごとに連絡の階層を決める
重大度ごとに、誰に、何分以内に、どの手段で知らせるかを決めます。重大度が高いほど、連絡は上へ早く届く必要があります。連絡の文面も型を決めておくと、慌てていても必要な項目が抜けません。
重大度と優先度は別
影響が小さい障害でも、締めの処理の直前なら優先度は上がります。重大度は被害の大きさ、優先度はいつ手を付けるかです。混ぜると、小さいが急ぐ障害が後回しになります。
現場で確かめる問い
- 重大度を機械的に仮決めする表が、障害の前に作られているか
- 仮の判定を見直す時刻が決まっているか。最近の障害で見直しは行われたか
- 重大度ごとの連絡先・期限・手段と、連絡の文面の型が決まっているか
- 重大度と優先度を分けて扱っているか。小さいが急ぐ障害が後回しになった例はないか
アステリア案件の重大度の基準と連絡の階層は、正本に記録がありません。記録なし
11. 人間が判断すること
- 障害の重大度（最初の判断と、見直し）
- 重大度に応じて、誰を呼び、誰に報告するか
- 業務側に回避策（手作業など）を始めてもらうか
重大障害判断は、AIへ最終委任しない事項です（正本の方針）。
12. 判断演習
あなたは、障害の連絡を最初に受ける担当です。
重大度を付けるために、最初の数分で確かめる質問を4つ挙げてください。「原因は何ですか」以外の質問にしてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
本番の障害の重大度は、原因ではなく影響で決めます。
情報が少ないうちは仮の重大度で体制を動かし、情報が増えるたびに見直して、その理由を残します。