システム障害対策の進め方｜予防・検知・復旧の3段階で整理する

システム障害の対策は、予防・検知・復旧の3段階に分け、それぞれを運用ルールとして決めておくことで、障害が起きても被害を小さく抑えられます。本記事では、システム障害の種類と影響を整理したうえで、予防では冗長化と変更管理、検知では監視項目とアラートの設計、復旧では一次対応と連絡体制、そして再発防止と体制づくりまでを、情報システム部門や運用担当者が現場でそのまま使える形で解説します。2026年10月時点の情報に基づいています。

システム障害の種類と影響

システム障害は、機器やソフトウェアの不具合のように仕組みの側で起きるものと、設定や操作の誤りのように人の側で起きるものに分かれ、どちらも業務の停止という同じ影響につながります。

障害の種類を分けて考える理由は、種類によって効く対策が違うためです。機器の故障には冗長化、操作の誤りには手順とチェックの仕組みが効きます。IPA(独立行政法人情報処理推進機構)が事業者の取り組みを調査した報告書では、障害記録に残す原因分類として、アプリケーションの欠陥、IT基盤の故障・欠陥、ネットワークの故障・欠陥、運用に関するドキュメントの欠陥、運用オペレーションのミス、外部調達したITサービスの欠陥、付帯設備の異常・故障が挙げられています。まずは自社の障害をこの粒度で分類できる状態にしておくと、対策の優先順位が付けやすくなります。

ハードウェア・ソフトウェア障害

ハードウェア・ソフトウェア障害とは、サーバーやネットワーク機器の故障、プログラムやファームウェアの不具合、期限切れの証明書など、仕組みそのものが原因で起きる障害です。

IPAの教訓集ダイジェストには、サーバーのSSL証明書が期限切れになり、仮想端末とのSSL通信ができなくなって仮想端末上の業務が使えなくなった事例が載っています。根本原因は、証明書の有効期限をシステムの所有者も構築・運用の委託先も管理していなかったことでした。機器が壊れたわけではなく、期限という管理項目が抜けていただけで業務が止まった例であり、障害の原因は故障だけではないことがわかります。

人的要因による障害

人的要因による障害とは、保守作業や設定変更の際の操作ミス、手順の不備、確認不足が引き金になって起きる障害です。

同じIPAの教訓集ダイジェストでは、基幹業務システムの運用環境を変更した際にトラブルが複数回発生した事例の原因として、人為的な作業ミス、実施内容への組織的なチェック不足、万一システムが停止した際の対策不足が整理されています。作業した個人の注意力だけを問題にせず、チェックの仕組みや停止時の備えが組織として足りていたかを見る視点が、人的要因への対策の出発点です。障害の影響は、システムが止まる時間の長さだけでなく、その間に業務や顧客対応がどこまで止まるかで決まります。

予防の対策

予防の対策は、機器の故障に備える冗長化とバックアップ、そして人の作業に起因する障害を減らす変更管理の2本柱で組み立てます。

予防は、障害を完全になくすためではなく、起きる頻度と影響を下げるために行います。完全に防げない前提で、次の検知と復旧の対策と組み合わせて考えることが現実的です。

冗長化とバックアップ

冗長化とバックアップは、構成を作っただけでは機能せず、切替えが実際に動くことを日常の運用で検証してはじめて効果を持ちます。

IPAの教訓集ダイジェストには、冗長化構成を取っていたにもかかわらず、障害時にバックアップへの切替えが正常に機能しなかった事例があります。稼働系のパラメータ設定を変更した際に待機系への反映が漏れたことが直接の原因で、根本原因には、待機系システムを本番運用の重要な機能と捉える観点の不足と、日常の運用での待機系の検証不足が挙げられています。対策として、稼働系と待機系のパラメータとプログラムのバージョンを確認する運用と、障害復旧の訓練が整理されています。また、全サーバーを網の目のようにつなぐ構成では局所の障害が全体に波及するため、グループに分けて波及を抑える見直しも示されています。

変更管理

変更管理とは、システムの設定やプログラムを変える作業を申請と承認の手続きに乗せ、影響範囲と切り戻し手順を事前に確認する仕組みです。

IPAの教訓集ダイジェストは、テスト環境では問題がなかったのに本番環境で障害が起きた事例を取り上げ、テスト環境と本番環境の差異を体系的に整理してリスク対策を練ることを示しています。変更の申請書には、目的、影響を受けるシステム、実施手順、切り戻しの手順、実施者と確認者、実施時間帯の6項目を最低限そろえます。編集部の実務の観点では、承認の条件に切り戻し手順の記載を必須にすると、変更の準備段階で「戻せない変更」に気づきやすくなります。作業の途中で想定外のことが起きても、サービスを継続させる側に戻せる状態を保つことが、保守作業時の基本です。システム全体のリスクの考え方はシステム開発のリスクと管理の進め方も参考になります。

検知の対策

検知の対策は、利用者に影響が出る前に異常を見つけるための監視項目と、見つけた異常を適切な人に届けるアラートの設計で構成します。

監視項目の決め方

監視項目は、利用者が体感するサービスの状態と、それを支える機器の状態、そして期限のある管理項目の3つに分けて決めると抜けを防げます。

機器の状態だけを見ていると、機器は正常なのにサービスが遅い、という状況を見逃します。IPAの教訓集ダイジェストには、負荷分散装置のファームウェアの不具合でシステムの応答速度が低下したものの、サービス監視の条件が妥当でなく、利用者から指摘を受けるまで障害に気づかなかった「サイレント障害」の事例があります。応答時間やエラー率のようなサービス側の指標を、機器側の指標と並べて持つことが重要です。次の表は、架空のWebシステムを想定した監視項目の記載例です。

IPAの報告書では、運用状況の把握の施策として、サービスレベルの変動、特に予め定めたしきい値からの逸脱とその予兆を監視することが挙げられています。しきい値は一度決めて終わりにせず、システムの利用状況が変わるたびに見直すことが前提です。

アラートの設計

アラートの設計では、重要度を段階に分け、段階ごとに通知先と対応の期限を決めておくと、重要な通知が大量の通知に埋もれることを防げます。

すべての異常を同じ重さで通知すると、担当者は通知に慣れてしまい、本当に重大な異常への反応が遅れます。IPAの教訓集ダイジェストでも、サービスの重要度を識別し、それに応じた連絡体制と障害検知のしくみを作ることが教訓として示されています。重要度は3段階程度に絞り、通知先と対応の期限を表にしておきます。

復旧の対策

復旧の対策は、原因の究明より先にサービスを許容できる時間内に戻すことを目的に、一次対応の手順と連絡体制をあらかじめ決めておくことです。

一次対応の手順

一次対応の手順は、事象の確認、影響範囲の把握、暫定復旧、経過の記録、関係者への報告の5ステップで固定しておくと、障害時に迷わず動けます。

IPAの教訓集ダイジェストは、障害対策とは、許容できる時間内の回復や、停止中の業務の継続まで具体化することだと整理しています。復旧を急ぐ場面では、原因を突き止める作業と、サービスを戻す作業を分けて考えることが重要です。まずは切り戻しや待機系への切替えで暫定的に戻し、原因の分析は復旧後に進めます。

1. 事象の確認:いつから、どの機能に、どのような症状が出ているかを確認します。
2. 影響範囲の把握:影響を受ける利用者、業務、連携先システムを洗い出します。
3. 暫定復旧:切り戻しや待機系への切替えで、サービスを先に戻します。
4. 経過の記録:実施した操作と時刻を、後から追える形で残します。
5. 関係者への報告:現状、影響、次の報告予定時刻を関係者に伝えます。

障害の重大度をどう区分するかはシステム障害のレベル(重大度)定義の考え方、手順を文書にする進め方は障害対応フローの作り方で詳しく扱っています。

連絡体制

連絡体制は、誰が誰にいつ何を伝えるかを役割単位で決め、連絡先を最新の状態に保っておくことで機能します。

IPAの教訓集ダイジェストには、障害対応のマニュアルが十分に整備されていなかったため、関係者が意思疎通をはかるのに多くの時間を費やし、停止時間が長引いた事例があります。担当者の名前ではなく役割で連絡先を管理しておくと、異動や休暇があっても連絡が止まりません。

再発防止

再発防止は、復旧した後に原因を分析して恒久対策を決め、その結果を記録して組織で共有するところまでを1つの流れとして行います。

原因の分析

原因の分析では、直接の原因だけでなく、その原因が作り込まれた背景と、事前に見逃された理由まで分けて整理します。

IPAの報告書が示す障害記録の項目では、原因の分析結果を、根本原因、作り込み原因、見逃し原因に分けて記録する形になっています。たとえば証明書の期限切れであれば、直接の原因は更新の漏れ、作り込み原因は管理の担当者が決まっていなかったこと、見逃し原因は期限を監視する項目がなかったことです。同じ障害でも、この3つに分けると打つべき手が変わります。障害の原因と対策の全体像はシステム障害の主な原因と対策の基本でも整理しています。

恒久対策の進め方

恒久対策は、担当者が再発防止策を立案し、責任者が妥当性を確認し、他のシステムへの展開まで検討する手順で進めると、同じ種類の障害を減らせます。

IPAの報告書は、障害の原因分析と再発防止策の立案と展開の流れとして、次の手順を示しています。個別の情報システムの担当者などが、障害の検出、原因の分析、暫定対策と再発防止策の立案を行い、障害データベースに記録します。そのうえで管理責任者が暫定対策を承認し、分析結果と再発防止策の妥当性を検討し、他のシステムへの展開を検討して担当者に指示します。1つの障害から得た対策を、似た構成の他のシステムにも広げることが、恒久対策の実効性を高めます。

体制づくり

体制づくりでは、障害対応の役割を明確に分け、訓練と振り返りを定期的に回すことで、これまでの対策が実際に動く状態を保ちます。

役割分担

役割分担は、障害の指揮を執る人、技術的に切り分ける人、利用部門へ連絡する人、記録を残す人の4つを最低限分けておくと、障害時の混乱を抑えられます。

1人が指揮も作業も連絡も担うと、判断が遅れ、記録も抜けます。小さな組織で人数が足りない場合も、1人が複数の役割を兼ねる際に、どの役割として動いているかを明確にしておく運用が有効です。

運用や障害対応の一部を外部のコンサルタントや専門人材に任せる場合は、契約の形態に注意が必要です。フリーランスのコンサルタントが関わる案件では準委任契約のケースが多く、準委任では成果物の完成義務がなく、報酬は月額と稼働率で決まるのが一般的です。障害を直すという結果ではなく、対応の業務を委ねる契約であるため、障害時の判断と最終責任は自社の指揮者に残し、外部の担当者には作業と助言の範囲を明確に伝えておきます。契約や責任に関する個別の判断は、弁護士などの専門家に確認してください。外部の運用保守案件の選び方はシステム障害対応・運用保守のフリーランス案件の選び方で扱っています。

訓練と振り返り

訓練と振り返りは、手順書があるだけでは分からない弱点を、実際の障害が起きる前に見つけるための活動です。

IPAの教訓集ダイジェストは、バックアップ切替えの失敗への対策として障害復旧訓練の実施を挙げ、システムが利用できない場合の手作業による代替業務マニュアルを作成して定期的に訓練することも教訓として示しています。訓練では、切替えの実施、連絡の伝達、代替手段での業務継続のいずれかを題材にし、終了後に手順の抜けや連絡先の古さを洗い出して手順書に反映します。実際の障害の後も同様に振り返りを行い、再発防止の記録に残すことで、体制そのものが改善されていきます。実際の大規模障害から学ぶ視点はドコモのシステム障害の事例から押さえたい教訓も参考になります。

本記事の内容は2026年10月時点の公開資料に基づく一般的な整理であり、自社のシステム構成や契約によって適した対策は異なります。個別の判断が必要な場合は、社内の責任者や専門家に確認したうえで進めてください。

出典・参考情報

1. IPA 情報処理システム高信頼化教訓集 ダイジェスト(ITサービス編・組込みシステム編)(2026-10-07参照)
2. IPA 情報システム障害の再発防止のための組織的マネジメントの調査WG報告書(平成24年4月5日)(2026-10-07参照)

本記事のデータは2026年10月時点の情報に基づきます。最終更新日:2026年10月7日。