LASSIC Media らしくメディア
システム障害の事例｜金融庁と総務省の公表資料にみる原因と対策
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- 金融庁と総務省は、報告されたシステム障害を分析し、原因と対策を毎年公表しています。
- 金融機関の障害は、ソフトウェア障害と管理面・人的要因で全体の約7割を占めます。
- 事例の多くは試験・承認・手順書・監視の抜けが原因で、外部に頼むときもこの4点を確かめます。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
他社で起きたシステム障害の事例を集めて、自社の保守運用を見直したい。障害の再発防止策をまとめるときや、保守運用の体制を見直すときに、こうした場面が出てきます。ただ、報道やSNSで流れる事例は原因が書かれていなかったり、推測が混じっていたりして、そのまま社内の資料には使いにくいものです。
実は、官公庁は業界から報告を受けたシステム障害を分析し、原因と対策を毎年公表しています。本記事では、金融庁と総務省の公表資料だけをもとに、システム障害の事例から原因の型を整理し、予防策と外部に頼めることをまとめます。個別の会社の評価はせず、資料に書かれた事実の範囲で紹介します。
目次
システム障害の事例はどこで読めるか
システム障害の事例を原因まで追うなら、法令にもとづく報告をまとめた官公庁の資料が確かです。金融庁は、金融機関から受け取る「障害発生等報告書」をもとに、2019年から分析レポートを公表しています。2026年7月公表の版では、2025年度に報告されたシステム障害は約1,600件でした。*1 総務省の電気通信事故検証会議も、電気通信事業者から報告された事故を検証し、教訓を毎年まとめています。*3
| 資料 | 公表元 | 読みどころ |
|---|---|---|
| 金融分野におけるITレジリエンスに関する分析レポート（2026年7月） | 金融庁 | 2025年度の障害の傾向と、きっかけごとの主な事例と課題 |
| 金融機関のシステム障害に関する分析レポート（2024年6月） | 金融庁 | 2023年度の障害の傾向と、2018年7月以降の事例集 |
| 令和7年度電気通信事故に関する検証報告 | 総務省 電気通信事故検証会議 | 事故の発生状況と、事前防止・発生時の対応の教訓 |
金融庁の資料は、障害のきっかけ（端緒）ごとに事例を分け、原因と課題を並べて書いています。*2 どの会社かを探すより、「どんな作業や仕組みで止まったか」を読むのに向いた資料です。総務省の報告書は事業者ごとの検証も載せていますが、本記事では会社名を出さず、教訓として書かれた内容だけを使います。
障害の原因で多いもの
金融庁が2025年度の報告を事象別に集計した結果では、「ソフトウェア障害」と「管理面・人的要因」で全体の約7割を占めました。*1 外からの攻撃よりも、作るときと動かすときの誤りのほうが多いということです。
| 障害の事象 | 割合 |
|---|---|
| ソフトウェア障害 | 39.2％ |
| 管理面・人的要因 | 29.3％ |
| その他の非意図的要因 | 11.3％ |
| 外部からの不正アクセス、DoS攻撃 | 8.2％ |
| ハードウェア障害 | 6.7％ |
この集計は、報告のときに金融機関が選んだ事象にもとづくもので、調査中などの約100件は含まれていません。電気通信の分野でも傾向は似ています。総務省の報告書によると、令和7年度に起きた重大な事故6件のうち、3件が人為要因、2件が設備要因、1件が外的要因でした。*3 人の作業や設計の考慮漏れが、重い障害の半分を占めています。
公表資料にみる障害事例と原因
では、具体的にどのような障害が起きているのでしょうか。公表資料に書かれた事例を、原因の型ごとに並べると次の表のようになります。事例の文は資料を要約したもので、会社名は省いています。
| 原因の型 | 公表資料に書かれた事例 | 資料が挙げる対策 |
|---|---|---|
| 仕様の認識ずれとテスト不足 | 外国送金の新しい電文方式に対応する改修で、関係者の認識が揃わず不要な処理が加わり、リリース後に電文処理が滞った*1 | 変更していない部分に影響がないかを確かめる試験（無影響確認テスト）の基準を明確にする |
| 委託先の承認のない作業 | 再委託先が委託元の許可を得ずにネットワーク機器の保守作業をし、冗長構成の機器すべてに誤った設定が配られて全台が通信不能になった*1 | 委託先への監査と統制を厳しくし、予備のデータセンターへの切替テストを行う |
| 本番作業のリスクの見落とし | 本番稼働中の災害対策環境の作業で通信の遮断が漏れ、一部のATM取引に影響した。経営承認が必要な作業が部内決裁だけで行われた*1 | 本番への影響を踏まえた変更管理とリスク評価を徹底する |
| 手順書にない作業 | 電源設備の点検で、委託先の作業担当者が手順書にない作業をして電源断が起きた*3 | 承認の仕組みや複数人の二重チェックを入れ、委託先にも同じ手順を守ってもらう |
| 実環境を想定しない試験 | 性能試験に多数のIPアドレスが接続する項目がなく、メモリ領域の設定誤りに気づかないまま障害につながった*3 | 実環境を想定した負荷試験と、メモリ領域の利用状況の監視を行う |
| 原因を特定しないままの復旧 | データベースサーバーの再起動で一時的に復旧したものの、原因が分からないまま障害が再発した*2 | 原因の分析に必要な情報と、その取得手段を前もって用意しておく |
6つの型を見比べると、障害そのものより「確かめる仕組みが抜けていたこと」が共通しています。テストの基準、作業の承認、手順書、監視のどれかが欠けたところで、普段なら止められる誤りが本番まで届いています。冗長構成（予備の機器を用意して止まらないようにする構成）があっても、同じ誤った設定が全台に届けば一緒に止まる点にも注意が必要です。
原因の型ごとの予防策
金融庁は、システム障害をきっかけによって4つに分けて分析しています。自社の障害の記録も同じ4つに分けてみると、手当てが薄いところが見えてきます。図は、2026年7月のレポートが4つのきっかけごとに挙げた課題を短くまとめたものです。
図の課題を、日々の作業に置き換えると次のようになります。どれも新しい仕組みを入れる話ではなく、いまの作業の中に「確かめる場面」を入れる話です。
- 改修の前：変更していない部分まで影響がないかを確かめる試験の範囲を、関係者で合意しておく
- 本番作業の前：作業の影響と承認者を決め、手順書を2人以上で確かめる
- 運用中：冗長構成が本当に切り替わるかを試験で確かめ、ディスクやメモリの使われ方を監視する
- 障害のとき：一時的に戻っても原因の調査を続け、そのために必要なログを残しておく
総務省の報告書も、設備の冗長化や停電対策をしていても障害は起こり得るとして、復旧の手順をあらかじめ整えておくことを求めています。*3 予防と同じくらい、止まったときにどう戻すかを決めておくことが大切です。障害のあとの振り返りの進め方はポストモーテム（障害の振り返り）の進め方で扱っています。
外部に頼むときに確認しておきたい点
公表された事例の多くには、外部委託先や再委託先が関わっています。保守運用を外部に頼んでも、委託先の作業を確かめる役目は自社に残ります。金融庁は、委託契約でインシデントの報告義務や事業継続の対応義務を明確にすることを求めています。*1 契約の前に、次の点を確かめておきます。
- 範囲：監視、定期作業、障害対応、改修のうち、どこまでを任せるか
- 再委託：再委託先がいるか。本番に触れる作業の承認を誰がするか
- 事前の連絡：本番に影響し得る作業を、いつまでに誰へ知らせるか
- 障害時の報告：何分以内に誰へ報告するか。夜間や休日はどうするか
- 試験と手順書：切替試験や負荷試験を誰が行い、手順書を誰が確かめるか
総務省の報告書は、委託先からのサービスの保証や、障害時の速やかな通知、現用設備に影響するおそれのある作業の事前通知を、SLA（サービスの水準を決める合意）などで決めておくことを勧めています。*3 夜間や休日の障害対応を外部に頼むときの体制は障害対応・オンコールの外部委託で整理しています。
まとめ：システム障害の事例から確かめたい3つの点
官公庁が公表したシステム障害の事例から、自社で確かめたい点は3つに整理できます。第一に、改修のときに変更していない部分への影響まで試験しているか。第二に、本番に触れる作業に承認と手順書の確認があり、委託先や再委託先にも同じ決まりが届いているか。第三に、冗長構成の切り替えや復旧の手順を試したことがあり、原因を調べるためのログが残るか。障害はゼロにはできませんが、公表された事例と同じ抜けを自社に残さないことはできます。保守運用の体制に不安があれば、外部の手を借りて点検するのも一つの方法です。
よくある質問
システム障害の事例はどこで調べられますか
金融庁の「金融分野におけるITレジリエンスに関する分析レポート」（以前は「金融機関のシステム障害に関する分析レポート」）と、総務省の「電気通信事故に関する検証報告」が、報告された障害を分析して毎年公表しています。どちらも原因と対策まで書かれているので、社内の資料に使いやすい事例集です。
システム障害の原因で多いのは何ですか
金融庁の2025年度の集計では、ソフトウェア障害が39.2％、管理面・人的要因が29.3％で、2つで全体の約7割でした。*1 外からの攻撃よりも、設計や作業の誤りによる障害のほうが多くなっています。
冗長構成にしていれば障害は防げますか
防げるとは言えません。公表資料には、誤った設定が冗長構成の機器すべてに配られて全台が通信不能になった事例があります。切替テストで本当に切り替わるかを確かめ、それでも止まったときの復旧手順を用意しておくことが求められています。
システム障害に備えた保守運用のご相談
監視の設計から本番作業の変更管理、障害時の復旧手順づくりまで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：金融庁「金融分野におけるITレジリエンスに関する分析レポート」（2026年7月）（https://www.fsa.go.jp/news/r8/sonota/20260730/01.pdf）。出典：第2編「システム障害に関する分析」（2025年度の報告件数、障害事象別割合、きっかけごとの事例と課題、委託契約での報告義務の明確化）を参照（2026年10月確認）
- *2 参考：金融庁「金融機関のシステム障害に関する分析レポート」（2024年6月）（https://www.fsa.go.jp/news/r5/sonota/20240626/01.pdf）。出典：第2部「障害分析概要」（障害の端緒による分類、原因の特定前に復旧して再発した事例）を参照（2026年10月確認）
- *3 参考：総務省 電気通信事故検証会議「令和7年度電気通信事故に関する検証報告」（https://www.soumu.go.jp/main_content/001082649.pdf）。出典：1章（事故の発生状況と発生要因）と2章「令和7年度に発生した事故から得られた教訓等」（手順書にない作業、試験項目、復旧手順書、SLAでの事前通知）を参照（2026年10月確認）
