金融機関のシステム障害に関する
分析レポート2023 年６月

第１部 はじめに ................................................................ 1
第２部 障害分析概要 ............................................................ 3
第１章 集計期間 ............................................................. 3
第２章 主な障害傾向 ......................................................... 3
第１節 サイバー攻撃・不正アクセス等の意図的なもの.......................... 5Ⅰ

外部委託先への不正アクセスによる情報漏えいに係る事案 ................. 5Ⅱ

マルウェア感染に係る事案 ............................................. 5

Ⅲ

DDoS 攻撃に係る事案 ................................................... 5

第２節 日常の運用・保守等の過程の中で発生したシステム障害.................. 6Ⅰ

冗長構成が機能しない等の障害 ......................................... 6Ⅱ

システム障害発生時の復旧に関する不芳事案 ............................. 6

第３節 システム統合・更改等に伴って発生したシステム障害.................... 7
第４節 プログラム更新、普段と異なる特殊作業等から発生したシステム障害 ...... 7
Ⅰ

設定ミス・作業の誤り ................................................. 7

第３章 今後の金融庁の対応 ................................................... 7
第１節 サイバーセキュリティ管理態勢に関するモニタリング.................... 8
第２節 システム障害の発生を踏まえたモニタリング............................ 8
第３節 システム統合・更改等に関するモニタリング............................ 8
第３部 事例集 .................................................................. 9
第１章 業態全体の障害傾向（事象別） ......................................... 9
第２章 事例 ................................................................ 10
第１節 サイバー攻撃・不正アクセス等の意図的な要因から発生したシステム障害 . 10
第２節 日常の運用・保守等の過程の中で発生したシステム障害................. 20
Ⅰ

ハードウェア・回線等の不具合 ........................................ 20

Ⅱ

設定ミス・操作ミス等の管理面・人的要因 .............................. 29Ⅲ

サードパーティの提供するサービス等の要因 ............................ 39

Ⅳ

取引量増加に伴う容量不足等 .......................................... 45

第３節 システム統合・更改に伴い発生したシステム障害....................... 48
第４節 プログラム更新、普段と異なる特殊作業等から発生したシステム障害 ..... 59
Ⅰ

設定ミス・操作ミス等の管理面・人的要因 .............................. 59

Ⅱ

ソフトウェアの不具合 ................................................ 66

第５節 システム障害後の対応が円滑に行われた事例........................... 71

第１部

はじめに

金融庁では、法令、監督指針等に基づき、発生した IT システムの障害（以下、「シ
ステム障害」という。）について金融機関から「障害発生等報告書」を受領するとともに、金融機関に対し障害の復旧状況の確認やヒアリング等を行い、金融機関で分析・検討した障害の真因、事後改善策の報告を受けている。これらの報告等に基づく分析
結果や事例を纏め、2019 年以降、「金融機関のシステム障害に関する分析レポート」（以下、「分析レポート」という。
）として公表している。
近年、金融機関の IT システムの複雑化、IT システムの委託関係の複雑化、サイバー攻撃の高度化等により、多くの顧客に影響を及ぼす事案が発生している。こうした状況の下、金融機関は、サイバーセキュリティを含めた IT リスク（以下、「システム
リスク」という。
）管理態勢を強化する必要があるが、特に、障害の未然防止にとどまらず、障害発生時の業務の早期復旧や顧客影響の軽減（以下、「レジリエンス」という。）の強化が一層求められている。1
本レポートでは、障害の端緒ごとに障害事例を分類し、代表的な事例について、発生した事象、障害の原因、再発を防止するうえで取り組むべき課題について分析している。今回のレポートでは、上記に加え、IT レジリエンス強化の参考となるよう、障害対応の好事例も記載した。2
金融機関においては、本レポートに加え、サイバーセキュリティを含むシステムリ
スク管理に関する各種標準、ガイドライン等3を参照し、自組織の体制及び対策について見直し、求められる IT セキュリティ又は IT レジリエンスとの差異を特定し、解消することが望ましい。
留意事項
本レポート第３部事例集は、2018 年７月から 2023 年３月までに報告された「障害発生等報告書」のうち、主な事案を取りまとめたものであるが、掲載していない事例を当局として重視していないということを必ずしも意味するものではない。
本事例集が、金融機関において、自己責任原則の下、創意・工夫をもって、それぞれの規模・特性等に応じたシステムリスク管理を行う際の参考となることを期待して
1

例えば、バーゼル銀行監督委員会「オペレーショナル・レジリエンスのための諸原則」（2020 年６月、同委ウェブサイト https://www.bis.org/press/p200806.htm 及び金融庁ウェブサイト
https://www.fsa.go.jp/inter/bis/20210402/20210402.html）、金融庁「『オペレーショナル・レジリエンス確保に向けた基本的な考え方』（案）に対するパブリック・コメントの結果等の公表について」（2023 年４月 27
日、金融庁ウェブサイト https://www.fsa.go.jp/news/r4/ginkou/20230427.html）、金融庁「『主要行等向けの総合的な監督指針』の一部改正（案）の公表について」（2023 年４月 27 日、金融庁ウェブサイト
https://www.fsa.go.jp/news/r4/ginkou/20230427-2.html）。
2
第３部第２章第５節参照。
3
公益財団法人金融情報システムセンター「金融機関等コンピュータシステムの安全対策基準・解説書」（2023年５月）及び「金融機関等のシステム監査基準」（2019 年３月）
、情報システムコントロール協会「Control
Objectives for Information and related Technology」、経済産業省「システム管理基準」（2023 年４月 26日）、「システム監査基準」（2023 年４月 26 日）及び「サイバーセキュリティ経営ガイドライン Ver 3.0」
（2023
年３月 24 日）、米国立標準技術研究所「重要インフラのサイバーセキュリティを向上させるためのフレームワ
ーク」等。

1

いる。

2

第２部

障害分析概要第１章

集計期間

金融機関のシステム障害については、法令、監督指針等に基づき、金融機関から障害発生等報告書を受領しているが、第２部は 2022 年４月から 2023 年３月までに受領したものを分析したものである。
第２章

主な障害傾向

前回のレポートでは、2021 年度の主な障害傾向として、以下の点を挙げていた。
・ 速やかなセキュリティパッチの適用を実施しなかったことに起因した脆弱性に対する外部からの不正アクセスにより、複数の金融機関のホームページが閲覧不可となる事案や、アクセス制限を設定していなかったことによる顧客情報の漏えい等の事案が発生した。
・ 外部からの不正アクセスによるランサムウェアの被害や、なりすましメールに添付されたファイル内のマクロ実行により、エモテットに感染する事案が発生した。
・ 広範囲にわたって ATM、インターネットバンキング（以下、「IB」という。）が利用できなくなる障害が発生し、多くの顧客に影響が及んだ。
・ 障害発生時に、準備していたシステムの冗長構成4が機能せず、復旧に想定以上の時間を要した。
・ 障害発生時に、障害復旧手順・体制の整備が不足（人材不足を含む。）し、復旧に想定以上の時間を要した。
上記の傾向から、2021 年度においては、・ サイバーインシデントについては、速やかなセキュリティパッチの適用及び不審メール受信時の対応といった基本的な対策を着実に実施するための態勢強化、
並びに、経営陣も参加するサイバーインシデント対応の訓練の実施を通じ、業
務及び顧客への影響の最小化、重要な業務の継続又は早期復旧等の IT レジリエ
ンスを高める必要があることが課題となっていた。
・ システム障害（サイバーインシデントを除く。）関連については、経営陣の主体的な関与の下、IT レジリエンス強化のための必要なリソースを確保すること、障害発生の未然防止にとどまらず、システム障害のパターンを想定した上で、冗長構成に係る実効性の確保や、障害復旧手順・復旧体制の見直し、訓練等によるシステムリスク管理態勢の高度化が課題となっていた。
2022 年度の主な障害傾向としては、以下の点が挙げられる。
4

システム障害に備えて設備や装置を複数用意しておき、一部障害が発生しても運用が継続できるようにしたシ
ステム構成。

3

・ 外部委託先のシステムへの外部からの不正アクセスにより、大量の顧客情報が漏えいするといった重大なインシデントが発生した。
・ サポート期限切れの機器を使用したことに起因した脆弱性に対する外部からの不正アクセスによるランサムウェア被害や、なりすましメールに添付されたファイルを開封したことにより、エモテットに感染する事案が発生した。
・ 外部委託先を含む金融機関への DDoS 攻撃により、金融機関のホームページの閲覧ができなくなる等の事案が発生した。
・ データセンターの障害によるシステムの全面停止や地域金融機関の共同センタ
ーの障害により、同時に複数の金融機関で障害が発生する等、多くの顧客に影響が及んだ。
・ 昨年と同様に、障害発生時に準備していたシステムの冗長構成が機能せず、復旧に想定以上の時間を要した。
・ 障害発生時に、顧客対応を迅速に行う等の好事例も認められたが、昨年と同様に、障害発生時の障害復旧手順・体制の整備が不足（人材不足を含む。）し、復旧に時間を要した。
上記の傾向から、2022 年度においては、・ サイバーインシデントについては、外部委託先への不正アクセスによる顧客情報の漏えいが発生していること、外部委託先を含む金融機関への DDoS 攻撃により、金融機関のホームページの閲覧ができなくなる事案が発生していること等から、重要な外部委託先も含めたサイバーセキュリティ対策等の整備状況の把握及びその実効性の検証といった IT レジリエンスの向上が必要であることが見て取れる。
・ また、IT 資産の適切な管理や不審メール受信時の対応といった基本的な対策を実施するための態勢整備が引き続き課題となっている。
・ システム障害（サイバーインシデントを除く。）関連については、障害発生時に、顧客対応を迅速に行う等の好事例も認められ、金融業界において障害対応への意識が高まっている面も垣間見えたが、他方、引き続き、障害復旧に関する不芳事案も認められた。
・ サイバーインシデントやシステム障害（サイバーインシデントを除く。）関連の障害傾向から、経営陣がサイバーセキュリティを含む IT レジリエンスの強化（重要な外部委託先を含む。
）を主導すること、その下で、経営上の計画における施策を策定するとともに実施すること、必要なリソース（予算及び人材）を確保するとともに適切に配置すること、インシデント対応においては顧客目線での対応、インシデントの影響の最小化、重要業務の早期復旧等を実現させるための態勢整備を行うことが、依然として金融業界の課題となっている。
以下では、システム障害を主な端緒（①サイバー攻撃・不正アクセス等の意図的な行為、②システムの日常的な保守・運用、③システム統合・更改プロジェクト、④シ
ステムのプログラム更新等の普段と異なる特殊作業）ごとに特徴的な事例を取りまと

4

め、それぞれの課題を分析している。
第１節
Ⅰ

サイバー攻撃・不正アクセス等の意図的なもの
外部委託先への不正アクセスによる情報漏えいに係る事案

外部委託先において、クラウドサービス環境の認証機能の設定を誤ったことにより、
不正アクセスを受け、顧客情報が漏えいする事案が発生している。
委託元において、認定機能の設定に関する作業結果の検証が十分に実施できていな
かったことに起因し、設定の誤りを検知できなかったことから、委託元における外部
委託先の情報セキュリティ管理態勢に関する実効性の検証が課題となっている。
また、本事案により、外部委託先において使用期限が経過し、削除すべき顧客情報が残存していたことが判明していることから、委託元における外部委託先のデータ管理態勢の実効性の検証も課題となっている。
Ⅱ

マルウェア感染に係る事案以前の分析レポートでは、金融機関、その海外現地法人等において、マルウェアに感染した事案を取り上げたが、2022 年度においてもサポート期限切れの機器の使用を継続したことに起因した脆弱性に対する外部からの不正アクセスにより、ランサム
ウェアに感染し、データを暗号化される事案や不審メール受信時の対応不備により、
エモテットに感染する事案が引き続き発生している。5
これらの対応として、IT 資産の適切な管理等といった基本的な対策を組織全体に浸透させる取組を行うことが課題となっている。加えて、不正な通信を検知するためのシステム・体制の整備や、不正な外部サーバーとの通信制御等のマルウェア対策、
不審メール受信時等の対応態勢整備はもとより、重要な外部委託先を含め、定期的な訓練等による実効性の確保が課題となっている。
Ⅲ

DDoS 攻撃に係る事案

金融機関を標的とした DDoS 攻撃と思われるサービス不能攻撃が発生している。特に外部委託先への DDoS 攻撃により、金融機関のホームページの閲覧ができなくなる事案やインターネットで提供しているサービスへの接続が困難となるとともに、サイバー攻撃を受けた際の部署間の連絡体制が不明確だったことにより、DDoS 攻撃の検知から IP アドレス遮断までに時間を要する事案が発生している。
これらの対応として、アクセス制限や DDoS 対策ツール6の導入といった基本的な対
52023 年３月 20 日「マルウェア Emotet の感染再拡大に関する注意喚起」
https://www.jpcert.or.jp/at/2022/at220006.html
6
例えば、WAF（Web サイト上にあるアプリケーションの通信状態を監視し、異常があればすぐに報告や遮断をす5

策はもとより、外部委託先を含め、障害発生時の部署間の連絡体制等をあらかじめ整備することが課題となっている。
第２節
Ⅰ

日常の運用・保守等の過程の中で発生したシステム障害
冗長構成が機能しない等の障害

これまでに公表した分析レポートでは、障害に備えた冗長構成が意図どおりに機能しない障害について取り上げたが、2022 年度も同様の事例（ハードウェア障害が発生したにもかかわらず副系に切り替わらなかった事例等）が複数認められた。例えば、
ネットワーク機器の間欠障害7により、副系に切り替わらず取引がエラーとなる等の事例が認められた。
また、冗長構成が機能しなかったため、手動で副系に切り替えたものの、この間に滞留したデータ等の対応手順が未整備であったことから、復旧に時間を要した事例もあった。
こうしたことから、意図どおりに機能するように冗長構成の実効性を確保すること、ネットワーク機器の障害の予兆監視を行うこと、冗長構成が機能し、副系へ切り替えるまでの間に発生したエラーデータ等の対応手順を整備すること等が課題となっている。
Ⅱ

システム障害発生時の復旧に関する不芳事案

以前の分析レポートでは、障害からの復旧に際し、復旧手順の未整備や作業手順の誤りにより、復旧までに想定以上の時間を要した事例を取り上げた。2022 年度においても同様の傾向が認められ、特に、外部委託先が運営するデータセンターの電源故障によるシステム停止や地域金融機関の共同センターの障害により、複数の金融機関において、同時に障害が発生し、復旧手順の未整備や復旧対応を行う有識者の不足等により、復旧に時間を要したことや、通帳、現金等の取込みも発生したことで、多くの顧客に影響を及ぼす事例が見られた。
また、外部委託先での復旧作業において、作業手順の検証が不足していたことに加え、金融機関での検証も十分に行われなかったことに起因して作業を誤り、ATM や IB
で長時間取引ができなくなった事例も複数認められた。
こうしたことから、システム停止等の不測の事態を踏まえ、金融機関のみならず、
外部委託先を含めた復旧作業手順・体制の整備（人材不足への対応を含む。）、不断の情報連携の取組が課題となっている。加えて、定期的な訓練等により、実効性を確保ることができるツール。
「Web Application Firewall」の略。
）や IPS（不正を検知して通信を遮断するシステ
ム。
「Intrusion Prevention System」の略。
）といったツール。
7
ハードウェアの部品の接触不良等により、断続的に異常の発生と復旧を繰り返す障害。

6

すること、顧客目線に立った対応を行うこと8等が引き続き課題となっている。

第３節

システム統合・更改等に伴って発生したシステム障害

金融機関のシステム統合・更改は、大規模なものとなるため、障害が発生した場合の影響が大きく、かつ、システムの統合又は更改に必要な知識の専門性が高いため、プロジェクト遂行の難度が高い。こうしたプロジェクト特性を背景に、システム統合・更改に伴って発生した障害事案では、金融機関は、プロジェクト特性に基づいたプロ
ジェクト管理態勢の整備、旧システムの仕様に係る理解、テストケース不足に係る対応強化といった面で課題を抱えていた。
昨今も、新たな勘定系システムへの移行等の様々な大規模プロジェクトが進められているが、引き続き旧システムの仕様に係る理解の不足やレビュー態勢の未整備等に起因した障害が発生し、その結果、顧客の決済に影響を及ぼす事例が認められた。
金融機関は、システム統合・更改に当たっては、システム仕様書等の開発文書の整
備、レビューアとしての有識者の配置等によるレビュー態勢の整備が必要である。
第４節
Ⅰ

プログラム更新、普段と異なる特殊作業等から発生したシステム障害
設定ミス・作業の誤り

外部委託先における為替関連情報の更新作業において、関係部署間の情報連携が実施されていなかったことに起因した設定ミスにより、他行宛の振込等ができなくなる事例が認められた。また、プログラムの本番リリース作業において、関係部署間の情報連携が実施されなかったことや、本番リリース作業手順の実効性の確認を事前に実施しなかったことに起因した作業の誤りにより、一部の ATM が利用不可となる事例も認められた。こうしたことから、関係部署の連携による作業手順の整備や作業手順の実効性確認が課題となっている。また、金融機関における外部委託先で作成した作業
手順の事前検証等の外部委託先管理の強化も課題となっている。
第３章

今後の金融庁の対応金融機関は、創意・工夫をもって、サイバーセキュリティを含めたシステムリスク
管理態勢を強化する必要があるが、特に、障害の未然防止にとどまらず、レジリエン
スの強化が一層求められている。
金融庁としては、金融システムの安定及び利用者保護の観点から、以下のとおり、検査・モニタリングを通じ、サイバーセキュリティを含む金融機関のシステムリスク
8

例えば、ATM における媒体等のくわえ込みの設定の見直し、ATM 停止を想定した職員による駆付けやその際の掲示物の事前準備、暫定払いのオペレーションの整備等の取組。

7

管理態勢の強化を促していく。
第１節

サイバーセキュリティ管理態勢に関するモニタリング

サイバー攻撃の高度化・巧妙化により、金融機関において、大規模な顧客情報の漏
えい、顧客資産の不正出金及びランサムウェア攻撃によるデータの暗号化・業務の停止といった重大なインシデントが発生している。こうしたサイバーリスクの趨勢を踏
まえ、金融機関のサイバーセキュリティ管理態勢の実効性について検査を通じて検証するとともに、地域金融機関、証券会社、保険会社等に対しては、サイバーセキュリ
ティに関する自己評価の実施を求める。加えて、金融業界横断的なサイバーセキュリ
ティ演習を実施し、金融業界のインシデント対応能力の底上げを図る。
第２節

システム障害の発生を踏まえたモニタリング

デジタライゼーションの進展とともに、金融機関は IT システムへの依存度を高めており、大規模なシステム障害が頻繁に発生すれば、金融機関に対する信頼が揺らぎかねない。そのため、金融機関におけるシステムリスク管理の重要性は高まっている。
金融庁では、重大な顧客被害の発生や金融機関のシステムリスク管理態勢（外部委
託先を含む。）に重大な問題が見られる場合は、機動的に検査・モニタリングを行い、その実態を検証し、金融機関に改善を促している。今後もこうした取組を継続する中で、障害の未然防止にとどまらず、IT レジリエンスに向けた対応が行われるよう金融機関を促していく。
第３節

システム統合・更改等に関するモニタリング

システム統合、システム移行等の大規模な IT システムのプロジェクトが金融機関
において進められている。これまで、金融機関のモニタリングにおいては、単に進捗状況の把握にとどまらず、過去の事例も踏まえて、問題となりやすい事項について詳
細に検証・議論する等しており、対話を通じて金融機関の自律的な改善を促すことに力点を置いてきた。
今後も、こうした取組を継続するとともに、リスクの高いプロジェクトについては、検査を含め、更に深度ある検証を行うこと等により、リスクに応じた効果的かつ効率的なモニタリングを進めていく。

8

第３部

事例集

第１章

業態全体の障害傾向（事象別）

2022 年度の業態全体9の障害傾向（事象別）として、「管理面・人的要因」と「ソフトウェア障害」による障害が全体の約７割を占めている。10「管理面・人的要因」による障害について、金融機関から、有識者が適切にアサイ
ンされなかったことにより、レビューの観点の網羅性が不十分なものとなり、設計時の誤りを検出できなかった事案、システム開発部門とシステム運用部門の連携ミスにより、誤った認識の下で作業を実施した事案等が認められ、その結果、ATM、IB の障害が引き起こされたこと等が報告されている。
「ソフトウェア障害」について、金融機関から、設計時の考慮不足により、誤った仕様の下でプログラムを作成し、ソフトウェア障害を引き起こした事案、有識者が適
切にアサインされなかったことにより、テスト時のレビューの観点の網羅性が不十分なものとなり、その結果、必要なテストケースを実施しなかったことに起因するソフ
トウェア障害等が認められ、その結果、ATM、IB の障害等が報告されている。

9

本集計期間（2022 年度）に金融機関から報告されたシステム障害の件数は、約 1,900 件であった（金融機関：
預金取扱等金融機関（主要行等、地域銀行、信用金庫・信用組合等）、保険会社等、金融商品取引業者、貸金業
者、資金移動業者等（資金移動業者、前払支払手段発行者）、暗号資産交換業者）。
10
障害報告において金融機関が選択した障害事象を集計した結果に基づく。

9

第２章

事例

システム障害の事例については、2019 年以降公表しているが、本事例については、
これまで公表した主な事例を障害発生の端緒別等に整理した上で11、前回公表時に取りまとめた以降に発生した障害事例を追加（初めて掲載した事例には新規と表示）したものである。
第１節
害

サイバー攻撃・不正アクセス等の意図的な要因から発生したシステム障１. 外部委託先における認証設定の不備による情報漏えい新規
＜業態＞
保険会社等
＜事象＞
○ 再委託先による、サーバーの認証を不要とする誤った設定に起因して、外部からの不正アクセスを受け、個人情報漏えいが発生した。
＜原因＞
 再委託先において、使用目的を達成後、本来削除すべき個人情報が残存していた。
 委託先において、再委託先の情報セキュリティ管理態勢の実効性確認が十分に行われていなかった。
 委託元において、委託先・再委託先に対する情報セキュリティ管理態勢の実効性の検証が十分行われていなかった。
＜対策＞
 委託する個人情報のデータ管理（データへのアクセス権限、データ保管場所、データ保管期限等）に関する確認項目の詳細化と証跡による検証の実施
 委託先における情報セキュリティ管理態勢の変更（システム変更含む）
に関する要件の詳細化
 委託先（再委託先含む）の情報セキュリティ管理態勢の委託元（金融機関）における委託開始前評価及び委託中の定期点検の強化 等

２. 外部委託先への DDoS 攻撃新規
＜業態＞
信用金庫・信用組合等
11

なお、過去に掲載した事例については、できる限り判りやすくするため記載を修正している場合がある。

10

＜事象＞
○ ホームページが閲覧不可となり、IB、電子記録債権サービス、投信イン
ターネットサービス及び外為 Web サービスへホームページからログイン
できなくなる事象が発生した。
○ 当金庫が提供するアプリが利用不可となる事象が発生した。
＜原因＞
 外部委託先が運営するホスティングサービス上で稼働している特定のサ
イトに大量のトラフィックが流入したため、回線帯域が逼迫し、ホスティングサービス全体のインターネット接続に影響が発生した。その結果、ホームページ及びアプリも閲覧不可、利用不可となった。
＜対策＞
 障害発生時の連絡体制、復旧が長期化した場合の対応策等、障害対応に係るマニュアル見直しの実施
 外部委託先における大量通信発生サイト特定の迅速化

３. 金融機関のエモテット感染の疑い新規＜業態＞
信用金庫・信用組合等＜事象＞○ 経営企画部にて受信した Web メールに添付されているファイルを開封したところ、不審な画像が表示され、エモテット感染の疑いが発生した。
＜原因＞
 メールで受信したファイルを信用金庫内環境に取り込む場合、無害化できないものは、担当者と上席者がクロスチェックをした上で無害化せずに取り込むこととしているところ、受信メールの本文をよく確認しなかったこと、無変換でのファイル取込みを担当者のみで行ってしまったこと等が重複した。
＜対策＞
 取り込むファイルの無害化・無変換に関するルールの再周知及び徹底 パソコンのデスクトップ画面に、不審なファイルを開いた場合の初期対応を表示

４. 顧客口座に対する不正アクセス新規＜業態＞
金融商品取引業者等

11

＜事象＞
○ 悪意を持った第三者から顧客口座への不正アクセスがあり、各種保有商品一覧画面や入出金画面等を参照された（不正な取引、入出金、属性変
更等はなし。）。
＜原因＞
 顧客の端末がマルウェアに感染したことにより、認証情報が漏えいしていた。
＜対策＞
 他の顧客口座へのアクセス有無の確認実施
 不正アクセスの際に利用された端末識別情報について、不正アクセスの早期検知を実現するためのモニタリングシステムのブロックリストへの登録
 顧客本人によるログイン ID 及びパスワード変更の実施

５. 多数の IP アドレスを使用した DDoS 攻撃新規
＜業態＞
金融商品取引業者等＜事象＞○ サービスを提供するシステム共通基盤のネットワーク機器の CPU 負荷が増大し、各サービスの接続に通常より時間を要する、エラーとなる等の事象が発生した。
○ DDoS 攻撃の検知から対応方針の確定及び IP アドレス遮断によるネット
ワーク機器の CPU 負荷低下の効果確認完了までに時間を要した。
＜原因＞
 サービスを提供するシステムの IP アドレスに対する DDoS 攻撃により、想定以上のアクセスが集中した。
 サイバー攻撃を受けた際の連携体制が十分に理解されていなかった。
 IP アドレス遮断に係る手順が不明確だった。
＜対策＞
 攻撃内容を分析し、導入済みの DDoS 攻撃対策サービスを補完する追加機
能等の実装
 速やかに対応するための部署間の連携体制、会議体の役割の再確認
 IP 遮断対応の手順改善の実施

６. 他社システムへの DDoS 攻撃の波及によるホームページ利用不可新規

12

＜業態＞
地域銀行
＜事象＞
○ 外部委託先がホームページのシステム基盤をホスティングサービスとして複数の事業者や業態に提供している。そのサービスを利用する他社のホームページに対し、大量の通信が発生しシステムの負荷が高騰したことにより、長時間にわたりホームページへのアクセスが不可となった。
＜原因＞
 外部委託先の提供するサービスを利用する他社のホームページへの大量通信が発生した。
＜対策＞
 外部委託先において、トラフィック流入元のサイトの早期特定のための分析機能を改善すること、特定した流入元サイトを速やかに停止するための手順や連絡体制等の態勢整備
 迅速に顧客周知を行う方法及び顧客に対して代替手段へ誘導する方法の確立

７. 二要素認証設定未済利用者への不正アクセスによる暗号資産不正出庫新規＜業態＞
暗号資産交換業者＜事象＞○ 現物取引サービスに対し、攻撃者が不正に得たと思われる大量のメール
アドレスとパスワードでログインを試行するリスト型攻撃が発生した。
○ 利用者の一部で第一認証が突破され、二要素認証設定が未済であった利
用者において、攻撃者による暗号資産の不正出庫が行われた。
＜原因＞
 利用者が口座開設後、銀行口座連携済みでかつ二要素認証設定が未済の状態における不正利用リスクを検討しておらず、攻撃者が不正ログイン
後に二要素認証を設定できるようになっていた。
＜対策＞
 利用者の状態遷移を考慮した不正利用リスクシナリオの検討
 重要な登録情報を変更する際は、二要素認証の導入等により、本人認証を厳格化すること
 不正利用リスクを踏まえた暗号資産出庫時の取引内容の確認

８. ランサムウェア感染に伴う情報漏えい新規
13

＜業態＞
信用金庫・信用組合等＜事象＞○ ファイアウォールの脆弱性を悪用した外部からの不正アクセスにより、
ファイルサーバーがランサムウェアに感染し、データが暗号化されて身代金を要求されるとともに、情報漏えいが発生した。
＜原因＞
 ファイルサーバーへの接続元を制限する設定としていなかった。
 サポート期限切れの古いサーバーを利用していた。
＜対策＞
 認証強化（二要素認証）、ネットワーク機器の接続先 IP アドレス等制御の実施
 サポート期限切れのサーバーの利用中止
 ツール導入による脆弱性管理の実施

９. 開発環境に対する不正アクセス
＜業態＞
主要行等
＜事象＞
○ 外部委託先がパブリッククラウド上に構築した開発用サーバーにおいて、リモートアクセスするための接続箇所に、悪意をもった第三者から不正アクセスされランサムウェアに感染した。
＜原因＞
 接続箇所の認証方法が ID・パスワードのみであり、総当たりの解析を行われ特定された。
＜対策＞
 開発環境のリモートアクセスに関するセキュリティ対策（二要素認証や端末認証等）のルール徹底

１０. 脆弱性情報の収集および対応の不備に起因したホームページの閲覧不可＜業態＞
信用金庫・信用組合等＜事象＞○ ホームページを更新する際に利用するプログラムの脆弱性により、第三者による不正アクセスを受け、ホームページが閲覧不可となった。

14

＜原因＞
 利用ソフトウェアの脆弱性情報の収集や対応を適時に実施していなかった。
 インターネットに公開する必要のないプログラムが公開状態であった。
＜対策＞
 脆弱性情報の収集や対応（脆弱性試験、パッチ適用等）に関する態勢の整備
 公開するソフトウェアの精査と基本的なセキュリティ対策の実施

１１. インターネット利用に関する基本的な対策の不備による個人情報漏えい
のおそれ
＜業態＞
金融商品取引業者等＜事象＞○ ホームページの管理者用ページに対して本来設定されるべきアクセス制
限機能が長期間解除されていたことにより、保存されていた個人情報が窃取されるおそれがあった。
＜原因＞
 管理者はブラウザに記憶された ID、パスワードを利用していると誤認し、認証していないことに長期間気付かなかった。
 認証機能自体は存在することから、ホームページのセキュリティは十分であると誤認し、定期的なシステムリスクアセスメントが実施されてい
なかった。
＜対策＞
 ログイン時の認証手順の見直し、IP アドレスの指定等によるホームペー
ジ管理用ページへのアクセス制限
 インターネットに接するシステムに対する定期的なシステムリスクアセ
スメントの実施

１２. 要件変更時の対応不備等に起因したランサムウェア感染＜業態＞
金融商品取引業者等
＜事象＞

15

○

インターネットを経由して顧客のシステムが接続して利用するサービス
において、運用上不要である RDP 機能12が設定ミスにより開放されていたことに起因し、顧客の利用システムがランサムウェアに感染した。
＜原因＞
 本サービスは、当初インターネット接続を不要とする環境を前提としていたが、機能追加の結果、インターネット接続することとなった。その際に行った構成変更のレビューが不十分であったため、必要な通信制御の設定や外部からの不正アクセス監視等を実施していなかった。
＜対策＞
 本番リリース時の判定基準に、インフラ構成やセキュリティ機能を確認する項目を追加

１３. 悪意のある第三者からの不正アクセスによる顧客資産の流出＜業態＞
金融商品取引業者等＜事象＞○ 身に覚えのない取引があったとの顧客からの申し出を端緒に、悪意のある第三者による不正アクセスにより顧客資産が流出したことが判明した。悪意のある第三者は、何らかの方法で取得したログイン ID やパスワ
ード等の情報を用いて、証券会社 Web サイトで出金先銀行口座等を不正な銀行口座に変更した上で出金を行った。
＜原因＞
 ログイン ID やパスワードが不正入手されたことを前提とした対策が不足していた。
＜対策＞
 不正アクセス（不正ログイン）に対するモニタリングの強化 本人認証の強化

１４. 外部委託先従業員による不正送金＜業態＞
金融商品取引業者等＜事象＞

12

リモートデスクトップ機能。コンピュータのデスクトップ画面を、ネットワーク経由で他のコンピュータに転送し、遠隔から操作する機能。

16

○

外部委託先の従業員が不正取得した認証情報を使い、委託元の証券会社の顧客資産の売却を行い、その売却金等を不正に取得した。当該職員は、業務上付与された権限を不正に使用し、顧客 ID やパスワード等を不正に取得していた。
＜原因＞
 悪意のある内部不正を前提とした権限管理やモニタリングが不足していた。
＜対策＞
 権限管理及びモニタリングの強化 外部委託先の管理強化

１５. マルウェア被害対策の不備に起因したエモテット感染
＜業態＞
保険会社等
＜事象＞
○ マルウェア（エモテット）に感染し、個人情報等のメール情報が窃取された。
＜原因＞
 標的型攻撃メール訓練は行っていたが、最新のサイバー攻撃の実例等を踏まえた訓練シナリオになっていなかった。また、全役職員への最新のサイバー攻撃に関する教育が不十分であった。
 システム運用において、休日にマルウェア感染の警告メッセージを確認する体制を整備していなかったことから、感染端末のネットワークからの隔離が翌営業日となり初動対応が遅れたことで、二次被害が発生した。
＜対策＞
 最新の実例等を踏まえた訓練や注意喚起の実施や全役職員への教育の徹底 緊急時における社内外の連絡体制の整備や定期的な見直し

１６. スマホ ATM 機能の悪用に関する不正アクセス
＜業態＞
貸金業者
＜事象＞

17

○

フィッシングサイト等を経由して窃取された会員のスマートフォンサイ
トの ID・パスワード等の情報をもとに、スマホ ATM 機能を悪用されキャ
ッシングされた。
＜原因＞
 顧客の秘匿情報が漏えいしたことを想定した対策が不足していた。
＜対策＞
 多要素認証等の実効性ある認証方式の採用
 取引発生時等に真の利用者に対する通知機能の実装
 不正取引等に対するモニタリングの強化

１７. パブリッククラウドサービスのバージョンアップに起因した個人情報等の不正アクセス＜業態＞
資金移動業者等＜事象＞○ パブリッククラウドサービスのアクセス権の設定不備により、悪意の第三者が、収集された個人情報等に不正アクセスできる可能性があった。
＜原因＞
 パブリッククラウドサービスのバージョンアップ時、アクセス権限の見直しの必要性を理解していなかった。
 パブリッククラウドサービス導入時のリスク評価が未実施であった。
＜対策＞
 パブリッククラウドサービス利用時の管理態勢の強化
 有識者によるアクセス権限設定の確認（必要に応じて第三者機関によるセキュリティ評価・脆弱性診断の実施）

１８. 秘密鍵の災害・障害復旧に関する情報を悪用した暗号資産の流出＜業態＞
暗号資産交換業者＜事象＞○ 暗号資産を管理するウォレットシステムへの不正アクセスにより、当社の自己保有暗号資産が流出した。
＜原因＞
 自己保有暗号資産を管理する秘密鍵の災害・障害復旧に関する情報を用いて不正な資産移転が行われた。

18

 当該情報に対する十分なアクセス管理が行われていなかった。
＜対策＞
 秘密鍵の災害・障害復旧に関する情報に対するセキュリティ管理態勢（情報の暗号化及び分散、職務分掌によるけん制機能等を含む）の整備
 外部からの不正アクセス及び内部不正リスクを考慮したアクセス権限管理の徹底、モニタリング態勢の整備

１９. ドメイン名登録情報への不正アクセスを端緒とした情報漏えい＜業態＞
暗号資産交換業者＜事象＞○ ドメイン管理事業者へアクセスする際の認証方式の設定不備により、第三者のなりすましにより当社のドメイン名登録情報が書き換えられたため、顧客等からの電子メールが漏えいした。
○ 窃取されたドメイン登録情報を用いて、当社システムに不正に侵入され、当社の顧客情報が漏えいした。
＜原因＞
 ドメイン管理事業者のドメイン管理サイトには、ログイン時の二要素認証の機能があったにもかかわらず、それを設定していなかった。
 当社システムにアクセスする認証設定も不十分であった。
＜対策＞
 外部サービス利用時の認証機能の強化とセキュリティの評価
 当社システムのアカウントへの二要素認証の設定及びアクセス制御の強
化

19

第２節
Ⅰ

日常の運用・保守等の過程の中で発生したシステム障害
ハードウェア・回線等の不具合

１. データセンターの障害による勘定系システム停止新規＜業態＞
主要行等、地域銀行＜事象＞○ 外部委託先が運営する共同センターのデータセンター内の設備が点検作
業中に故障したことに起因し、共同センターの全加盟行の勘定系システ
ムへの給電が停止し、その復旧に時間を要したことで、ATM や営業店等での全取引が長時間利用不可となった。また、通帳等の取込みも多数発生した。
＜原因＞
 全加盟行のシステム一斉停止を想定したシステムの復旧対応に関する態勢を整備していなかった。
 データセンター内の設備に対する点検作業の安全性等の評価やチェック
態勢が十分ではなかった。
＜対策＞
 全加盟行のシステム停止、複数のシステムの停止を想定した各種復旧手順の作成や有識者の育成、障害訓練の実施等の復旧態勢の整備
 点検作業のリスクや作業プロセスの確認・評価態勢の整備

２. ネットワーク機器の故障に起因する決済業務の復旧対応遅延新規
＜業態＞
主要行等
＜事象＞
○ 外部委託先によるネットワーク設定変更作業に誤りがあったためネットワークが高負荷となり、約４時間、顧客の決済がエラーとなった。
＜原因＞
 本番環境に影響があるにもかかわらず、影響を過小評価して本番環境稼働中にネットワーク設定変更作業を行ってしまった。
 作業手順を整備していなかった。
 システム復旧手順を整備していなかった。
＜対策＞
 本番環境に対する設定変更作業等の禁止事項・ルールの整備 作業手順の整備

20



システム復旧手順の整備

３. ネットワーク機器の故障に起因する未処理取引の復旧対応遅延新規
＜業態＞
主要行等
＜事象＞
○ 全銀システムと勘定系システムとの間の一部経路切断により、取引が滞留し、仕掛り中の処理が発生した。当該ネットワークの一部経路が一時切断していたため、顧客の仕向取引及び被仕向取引の電文が滞留し、未処理の取引が発生した。また、未処理の取引が発生した際の業務影響有
無の特定に時間を要した。
＜原因＞
 未処理の有無を確認する作業手順を整備していなかった。
 未処理発生時の対応手順を整備していなかった。
＜対策＞
 未処理有無の確認手順の整備
 未処理発生時の対応手順の整備

４. ネットワーク機器の故障に起因するサービス復旧対応遅延新規
＜業態＞
主要行等
＜事象＞
○ 交換を予定していたネットワーク機器が故障したにもかかわらず、通信が断続的に正常応答したため、他系統への自動切替えが行われず、法人向けサービスの一部で取引エラーが発生した。また、ネットワーク機器のエラー解消後にサービスを早期に復旧できなかった。
＜原因＞
 機器交換までに期間が空くことを踏まえ、交換実施までの間にエラーが発生した場合の対処方針を策定していなかった。
 ネットワーク機器のエラー時に電文破棄や処理待ち状態が発生する際の対応手順をあらかじめ準備していなかった。
＜対策＞
 予兆点検における交換対象機器のエラー発生時に向けた対応手順の整備
 電文破棄や処理待ち状態発生時の対応手順の整備

21

５. ネットワーク機器の故障に起因する決済業務の復旧対応遅延新規
＜業態＞
主要行等
＜事象＞
○ ベンダーが提供するプライベートクラウドのネットワーク機器の間欠障害により、自動で副系統に切り替わらなかったことに起因し、決済業務が不可となった。また、当該機器の故障により、データベースサーバーに不要なトランザクションが蓄積し、その原因特定に手間取ったことか
ら勘定系システムの復旧まで時間を要した。
＜原因＞
 ネットワーク機器の予兆監視を十分に実施していなかった。
 ネットワーク障害時の復旧手順書を整備していなかった。
 データベースサーバーの不要なデータの蓄積状況を確認していなかった。
＜対策＞
 ネットワーク機器を予兆監視対象として追加
 ネットワーク障害時の復旧手順の整備
 ネットワーク障害時にデータベースサーバーの状態を確認・対処する手順の整備

６. OS の不具合により冗長構成が機能せず ATM が停止新規
＜業態＞
地域銀行
＜事象＞
○ 勘定系システムと接続しているネットワーク機器が故障した際、当該ネットワーク機器の OS の不具合により、待機系に制御機能が引き継がれず、勘定系システムとの通信が停止し、ATM や IB が利用不可となった。
＜原因＞
 購入したネットワーク機器の OS の不具合であり、導入時のテストや検証
では、製品そのもののテストは行わないため、不具合を発見できなかった。
＜対策＞
 重要ネットワーク機器の特定、OS のバージョン管理の実施

22

７. ネットワーク機器の異常による IB 利用不可新規
＜業態＞
地域銀行
＜事象＞
○ ネットワーク機器がハードウェアの異常を検知し、待機系への自動切替えが発生した。その影響を受けて IB 等で利用しているネットワーク一部
経路が閉塞し、該当経路での IB 等が利用不可となった。
＜原因＞
 ネットワーク機器が待機系に切り替わるまでの時間だけでなく、その後のリカバリー対応が完了するまでの間、一部の IB 等が停止したままになってしまう影響を把握できておらず、復旧手順の整備ができていなかった。
＜対策＞
 リカバリー対応が完了するまでの間の影響把握、復旧手順の整備

８. ネットワーク機器故障による ATM 利用不可新規
＜業態＞
地域銀行
＜事象＞
○ 勘定系システムと対外センターと接続するネットワーク機器にハードウ
ェア障害が発生し、予備機への切替えが行われたものの、通信状態が不安定となり予備機が閉塞し、ATM が利用不可となった。
＜原因＞
 上記とは異なる上位のネットワーク機器の故障が原因で通信が不安定になったが、事象が発生した際にその原因の特定が出来なかった。
＜対策＞
 ネットワーク機器故障の予兆検知実施

９. 障害発生時のバックアップ回線への切替え失敗新規＜業態＞
信用金庫・信用組合等＜事象＞○ メイン回線用のルータ故障により、一部支店のすべてのオンライン取引が停止する事象が発生した。本来であれば即時バックアップ回線へ切替

23

え運用可能となるところ、バックアップ回線への切替えに失敗したため不通の状態となり、復旧までに時間を要した。
＜原因＞
 ルータと通信アダプタが接触不良の状態のままバックアップ回線への切替えを実施し、切替えに失敗した。
＜対策＞
 全店舗にバックアップ回線機器のランプ状態の確認及び再起動手順を整備
 定期点検保守時に毎回メイン・バックアップ回線通信機器のランプ状態を確認し、保守記録に掲載

１０. 復旧手順の準備不足による障害対応時間の長期化
＜業態＞
主要行等
＜事象＞
○ 営業店端末と接続するサーバーで複数のハードウェアが故障し、バック
アップサーバーへの切替えも不可であったため、結果として復旧が業務開始時刻に間に合わず、災害対策用システムを代替活用し、運用を再開した。
○ 来店予定の顧客に、業務開始の直前まで告知できなかったため混乱を招いた。
＜原因＞
 バックアップサーバー単独での起動手順に不備があり、調査等に時間を要した。
 最悪のケースを想定した復旧対応の時限管理を実施していなかった。
＜対策＞
 実態に即した（実効性ある）システム障害の訓練
 影響が顕在化していない初期段階において、最大影響を想定し、対外告知や顧客対応を整備（システムやチャネルを軸とした、影響する業務の把握と業務横断的な BCP の策定）

１１. ネットワーク機器のハードウェア不良に起因する一部 ATM の利用不可
＜業態＞
主要行等
＜事象＞

24

○

ATM システムに関連するネットワーク機器について、既知のバグに起因したログの継続出力による CPU 使用率の高騰やハードウェアエラーに伴う通信の断続的な停止によって、一部の ATM が停止した。
＜原因＞
 重要システムを構成する機器の状態を収集、監視していなかった。
＜対策＞
 リソースやハードウェアエラーの監視にもとづく予兆管理の徹底

１２. 障害箇所等の状態把握に関する対応不備に起因した障害対応時間の長期
化
＜業態＞
主要行等
＜事象＞
○ ATM とデータセンターを接続するネットワーク機器のハードウェア故障により一部の ATM が停止した。故障箇所の切替えが自動で行われたが、以降も通信の遮断・接続が繰り返される不安定な状態が継続し、対象機器の切離し等の対処によって復旧するまで数時間を要した。
＜原因＞
 対象機器の特定等の把握や対応策の検討に時間を要した。
＜対策＞
 ネットワーク機器における発生事象を早期に把握するため、監視内容を見直し

１３. ディスク障害に起因した送金処理等の遅延
＜業態＞
主要行等
＜事象＞
○ 様々な業務システムと連携するシステムにおいて、ディスク障害が発生したにもかかわらず冗長構成が機能せず、送金処理等が遅延した。直接原因はディスク装置とサーバー間の通信を担うプログラムの不具合であったが、復旧に手間取り、ディスク交換作業が完了するまで障害が継続した。
＜原因＞
 サービス復旧手順や対応態勢を構築していなかった。
 システムを横断した障害シナリオを想定しておらず、業務面の影響範囲

25

を特定できなかった。
＜対策＞
 システムの重要度に応じた復旧態勢と手順の確立
 障害発生のタイミングや影響する業務等を考慮した精緻な障害シナリオにもとづく対応手順の整備と訓練の実施

１４. 電源供給停止に伴う通信障害による ATM 等の利用不可
＜業態＞
主要行等
＜事象＞
○ 台風の影響で回線を収容する通信会社の収容局に対する電力供給が途絶
え、加えて非常用電力の枯渇によって通信障害が発生した際、利用回線を経由したサービスが停止する事象が発生した。
＜原因＞
 利用回線は冗長構成であったが、正副回線とも同一地域を通過しており、広域で電力供給が途絶えたことで冗長構成が機能しなかった。
＜対策＞
 正副回線が切断された場合の CP の準備とともに、通信障害リスクの低減に向けたキャリア分散による冗長構成の見直し

１５. 電源喪失に伴う勘定系システム停止
＜業態＞
主要行等
＜事象＞
○ 勘定系システムを設置しているデータセンターにおいて、メンテナンス
作業時の電源機器の障害で電源供給が絶たれたことによって、勘定系システムが停止、併せて関連するサーバーのハードウェアも故障する事象が発生した。また、待機系サイトへの切替え判断や作業にも時間を要した。
＜原因＞
 外部委託先での電源設備の保守点検作業の手順に不備があった（単一障害点のある手順となっていた）。
 必要なメンバーの招集から障害対応までを対象とした災害対策サイトへの切替え訓練を行っていなかった。
＜対策＞

26




保守点検作業においても、単一障害点が発生しない電源設備への移行
切替え決定からの必要メンバーの招集や作業ドキュメントの準備等のより実態に即したシステム切替え訓練の実施

１６. 想定を超えたハードウェア障害に伴う復旧時間の長期化
＜業態＞
地域銀行
＜事象＞
○ 法人 IB の外部委託先において、断続的に複数のディスクが故障し、ディ
スクの三重障害が発生したことに起因し、副系システムへの自動・手動
切替えに失敗したことで、約５時間、利用不可となった。
＜原因＞
 ディスクの三重障害が発生することを想定していなかったため、対応手順を準備しておらず、また三番目のディスク故障に対する迅速な検知ができなかった。
＜対策＞
 想定した二重障害に対する対応手順で復旧しない場合のリカバリープラ
ンの整備

１７. ハードウェアの障害による終日株式売買の停止
＜業態＞
証券取引所
＜事象＞
○ 共有ディスク装置のメモリに故障が発生した際、冗長構成になっていたにもかかわらず、もう一つの装置に切り替わらず一部業務に異常が発生
し、売買を停止せざるを得ない状況となった。
○ 日中にシステムを再起動した場合の市場の混乱を懸念し、終日売買停止することとなった。
＜原因＞
 故障した製品のマニュアルに不備があり、自動切替えがされない設定になっていた。また、当該設定に係る実際の稼働テストが不十分であった。
 システム障害による売買停止後の再開に向けたルールが整備されていな
かった。
＜対策＞
 冗長構成が正常に動作することの確認

27



システム障害発生時の業務再開に向けた手順やルールの整備

28

第２節
Ⅱ

日常の運用・保守等の過程の中で発生したシステム障害
設定ミス・操作ミス等の管理面・人的要因

１. システム開発の検証・管理体制の不足による勘定不突合新規
＜業態＞
主要行等
＜事象＞
○ 勘定系システムと外部接続先を接続するシステムにおいて、外部委託先・再委託先が設計した電文作成処理が不要な電文を検索するロジックとなっていた。このため、当該処理が遅延して特定取引の電文が滞留し、当該システムを経由する取引の一部が約７時間にわたって利用しにくい状態となり、勘定不突合の事象が発生した。
＜原因＞
 設計時の影響調査内容を検証する態勢が不十分だった。
 外部委託先及び再委託先の体制面の検証や開発に対する検証態勢が不十分だった。
 休日に障害が発生したため、開発要員が開発拠点に駆付ける必要があり、連絡に時間を要したことからシステム障害の状況等の詳細な調査を行う
までに時間を要した。
＜対策＞
 設計時の影響調査検討状況と当該検討に係る検証態勢のチェック強化
 外部委託先・再委託先の検証・管理態勢のチェック強化 休日・夜間に顧客影響が大きいシステムで障害が発生したことを想定した障害訓練のバリエーション追加（一斉同報ツール・メーリングリストを活用した連絡の実施、本番環境へのリモートアクセス環境等を活用した調査の実施等）２. 勘定系システムの仕様把握不足による一部取引不可新規
＜業態＞
主要行等
＜事象＞
○ 勘定系システムで管理している各種取引単位で採番される取引通番がシステムの上限値を超過したことにより、超過後のカードローン約定返済処理やデビットカード未精算顧客の銀行取引等が不可となった。
○ 上記の影響を受けた顧客を特定してから影響範囲を特定するまでに時間を要し、顧客に迅速な連絡が実施できなかった。

29

＜原因＞
 取引通番の採番方法を誤認していたことにより、取引通番の増加状況をモニタリングの対象から外していた。
 発生事象（商品・サービス）によって顧客対応判断部署が分かれており、全社共通の統一された対応が確立されていなかった。
＜対策＞
 システム制約（システム上限値、閾値、桁数のある項目等）の明確化
 勘定系システムの有識者育成
 システム障害発生時の顧客影響の範囲を再確認した上で、公開チャネル、
タイミング、告知内容、顧客対応方法を整理

３. 社内の関係部署との連携不足による作業誤りに起因した ATM 停止新規
＜業態＞
主要行等
＜事象＞
○ 本番リリース作業時に本来再起動が不要なサーバーの再起動を行ったことに起因して、すべてのカードローン専用の ATM が利用不可となった。
＜原因＞
 システム開発担当からシステム運用担当へ本番リリース作業の際にサーバー再起動不要の連絡を行っていなかった。
 本番リリース作業の障害による影響（ATM 利用不可等）の把握ができておらず、本番リリース作業に係るテストを実施していなかった。
＜対策＞
 本番リリース作業を行う際の作業手順の整備、作業手順の研修実施
 本番リリース作業の対顧客業務への影響確認実施の徹底、対顧客業務に影響を与える時間帯での本番リリース作業禁止の徹底

４. バージョンアップ方法誤りによる送金取引不可新規
＜業態＞
主要行等
＜事象＞
○ 勘定系システムのデータベース（外部委託先提供）のバージョンアップ
の影響で、IB が利用不可となった。
＜原因＞
 データベースをバージョンアップする際、バージョンアップ前後のデー

30

タ属性、桁数の変更がないものと誤認し、必要なテストを実施していな
かった。
＜対策＞
 データベースのバージョンアップやメンテナンス時におけるデータ属性の変更に伴う桁数増加についてテストケースの追加

５. ネットワーク機器の故障に起因する出金取引エラー新規
＜業態＞
主要行等
＜事象＞
○ ネットワーク機器の故障により他系統に通信経路が切り替わったが、他系統にルート定義情報が設定されていなかったことにより、振込及び振替取引が不可となる事象が発生した。
＜原因＞
 冗長構成として正系と副系で同様のルート定義情報が設定されるべきところ、作業指示書に不備があったことにより、副系のルート定義情報が正しく設定されていなかった。
＜対策＞
 ネットワーク設計時にルート定義情報の作業指示書として定型化したテンプレートを活用した属人的なミスの抑制対策の実施

６. 作業ミスによる誤ったプログラムを本番環境に反映したことに起因する金額表示の誤り新規＜業態＞
金融商品取引業者等＜事象＞○ オンライントレードサービスの注文時に確認画面に表示される金額が誤って表示された。
＜原因＞
 プログラムを本番環境に反映する際の手順ミスにより、テスト工程で不備を検知したプログラムを誤って本番環境に反映してしまった。
＜対策＞ プログラムのバージョン管理及び本番反映手順の見直し
 プログラムのバージョン管理及び本番反映手順遵守の徹底

31

７. テスト観点不足による金額表示の誤り新規＜業態＞
金融商品取引業者等＜事象＞○ スマートフォン用取引アプリの決済注文画面において、遷移前の画面で指定した建玉の評価損益が表示されるべきところ、建玉情報リスト取得
ロジックの不具合により、顧客が保有する建玉が複数ある場合に正しい評価損益を表示することができなかった。
＜原因＞
 リグレッションテスト13において、決済注文画面に遷移する前の画面で指定した条件が正しく表示されることの確認を実施していなかった。
＜対策＞
 遷移前の画面で指定した条件が正しく表示されることをリグレッション
テストの確認観点に追加

８. システム部門以外の有識者をアサインしないことによる設計工程の考慮漏
れ新規＜業態＞
金融商品取引業者等＜事象＞○ 設計工程における口座紐付けパターンの考慮漏れにより、オンライント
レードサービスの取引報告書、運用報告書等で一部の取引を表示できな
かった。
＜原因＞
 設計工程で要員をアサインする際、商品所管部の有識者をアサインせず、商品所管部であれば指摘できた現場事務やパターンを考慮できなかった。
＜対策＞
 商品所管部門を含めた有識者のアサイン実施

９. 機能追加による法人 IB 利用不可新規＜業態＞
13プログラムの一部を変更・修正した際に、その変更によって予想外の影響が現れていないか確かめるテスト

32

地域銀行
＜事象＞
○ IB の共同センターにおいて新機能を導入したが、その影響で利用者端末の電子証明書検証処理がエラーとなり、法人 IB へのログインが不可となった。
＜原因＞
 機能追加によるクライアント環境での検証が不足していた。
 障害発生の可能性の把握及び障害が発生した場合の顧客への代替手段等の周知が不足していた。
＜対策＞
 金融機関も含めた検証項目の十分性の確認と検証結果の確認
 障害発生時のリスク認識の把握と不具合発生時の代替策の顧客周知

１０. 誤った復旧手順を実施したことによる ATM 停止新規
＜業態＞
地域銀行
＜事象＞
○ 外部委託先において、ATM と接続するシステムを起動した際、バックアップ用アプリにおいてエラーが発生し、エラーの復旧対応を実施したが、作業手順の誤りにより、一部の ATM が開局不可となった。
＜原因＞
 外部委託先からは、マニュアルに基づき復旧を実施との報告を受けていたが、本事象に合致するマニュアルはなく、復旧手順の整備を行ってい
なかった。
＜対策＞
 復旧に関する外部委託先と委託元との対応範囲の明確化及び復旧手順の整備

１１. 証明書有効期限切れによるスマホアプリ利用不可新規
＜業態＞
地域銀行
＜事象＞
○ スマホアプリを利用する IB（クラウドサービス上に構築）のサーバーの正当性を証明するドメイン証明書の有効期限切れにより、サービスが利用不可となった。

33

＜原因＞
 クラウドサービスを提供する事業者がドメイン証明書の更新方法を変更
したが、変更の事実を把握していなかった。
＜対策＞
 クラウドサービスにおいて有効期限設定されている項目の管理
 管理項目の定例確認の実施

１２. 冗長構成が機能しなかったことに起因する障害対応時間の長期化
＜業態＞
主要行等
＜事象＞
○ 法人向け IB で、ハードウェア障害に起因して、平日日中の約５時間、利用不可となり、一部取引が翌営業日の処理となった。冗長構成が機能せず最終的に作業員がデータセンターに移動する必要が生じた。
＜原因＞
 自動切替えが行われなかった場合の作業に慣れておらず作業ミスが発生した。
＜対策＞
 強制的な手動起動の手順と当該作業に関する訓練の実施（様々な障害パ
ターンの想定と訓練の実施）

１３. 監視対象漏れに起因した、開局直後の一部ログイン不可事象
＜業態＞
主要行等
＜事象＞
○ 週次のシステム定例作業後に実施された、開局に必要な起動処理が正常終了しなかったため、開局直後から法人向け IB にログインしづらい事象が発生した。
＜原因＞
 開局時に必要となる処理のエラー状態を監視していないことで、原因特定に時間を要し、速やかに対処できなかった。
＜対策＞
 監視するシステムエラーの対象の見直し

34

１４. システム障害における影響範囲の把握不備に起因した為替取引不可＜業態＞
信用金庫・信用組合等＜事象＞○ 口座振替の処理停止により、一部為替発信処理が不可となる事象が発生した。
＜原因＞
 口座振替の処理停止は検知し対応したが、並行処理される為替発信処理の監視機能がなかったため、担当者は正常に処理されていると誤認した。
 口座振替の処理停止が為替発信処理に影響するとの認識が無く、為替発
信処理に対する影響を確認する手段や資料を整備していなかった。また、システム障害発生初期に組織内部での連携が取れていなかった。
＜対策＞
 顧客影響や時限性のある処理に対する、監視機能の実装
 顧客影響や時限性のある処理に対する、停止時の影響確認手順や関係者との連絡体制の整備

１５. 高負荷な検索作業に起因した IB におけるエラー出力
＜業態＞
主要行等
＜事象＞
○ IB のデータベースに対する検索作業に起因して、IB に対するアクセスが高負荷となり約３時間断続的にエラーが発生した。
○ 復旧作業のため対象サーバーを再起動した際に用いた手順書に不備があり復旧までに時間を要した。
＜原因＞
 参照系の検索作業は開発及び運用組織による事前報告やテストを実施していなかった。
 過去に実施したシステム変更時に手順書を改訂していなかった。
＜対策＞
 テスト環境による確認と開発及び運用組織による事前承認のプロセス徹
底 システム変更作業におけるレビュー時に、運用に対する影響確認や対応結果の確認をルール化

35

１６. 社内の他組織との連携不足に起因した IB アクセス不可
＜業態＞
主要行等
＜事象＞
○ Web サイトに掲載する広告の定型的な登録作業で、外部委託先から提供された、誤りを含むプログラムを登録したことで IB にアクセスできない事象が発生した。また、対応にも時間を要した。
＜原因＞
 登録作業において事前のテスト等を行わなかったため、プログラム誤りに気付くことができなかった。
 プログラムの登録作業を特定の部署のみで完結したため、障害対応を担当した関連部署が登録作業を認識できず、原因特定に時間を要した。
＜対策＞
 登録作業に関する、検証やテストの手順確立
 作業依頼からテストや本番作業等のプロセスにおける関連部署の役割を定義

１７. 各システム及び処理の連携・前後関係の認識不足によるサービス開始遅延
＜業態＞
主要行等
＜事象＞
○ システムの定例保守作業における作業ミスを起因とし、夜間バッチ処理
が異常終了。異常終了した処理の復旧に関する手順を誤り、更に影響が拡大。その後の復旧に想定以上の時間を要し、顧客サービスの開始遅延等が生じたほか、通常作業と復旧作業を並行して行う必要から作業量が積み上がり、完全復旧までに相当な日数を要した。
＜原因＞
 定例保守作業において作業順序を誤った。また、再鑑が不十分であり、再鑑者が作業順序相違を看過した。
 一時的に抑止したシステムの再実行の管理が不十分であり、必須処理が漏れたままとなっていた。
 影響範囲の広い大規模障害を想定した CP が策定されていなかった。
＜対策＞
 作業手順書において作業工程を細分化、作業順序を明確化し、再鑑タイ
ミングも細分化後の工程ごとに実施するよう変更

36





必須処理の漏れがシステム的に検知できる機能の追加、一時的に抑止したシステムの再開時には開発及び運用部門の有識者によりタイミングの確認と再開前の必須処理が完了済みかどうかの点検を実施することを手順へ明記
大規模障害発生時にも顧客サービスへの影響を回避できる CP の作成、それにもとづく訓練の実施

１８. 定期メンテナンス後の確認不足による信用情報機関への情報提供遅延
＜業態＞
貸金業者
＜事象＞
○ 一部データベースが使用不可状態となったままオンラインサービスを開始したため、信用情報機関に提供すべきデータが一部作成できず情報提供遅延となる事象が発生した。
＜原因＞
 データベースの定期メンテナンス後、システムを立ち上げる際に、デー
タベースの状態を確認する運用を定めていなかった。
＜対策＞
 定期メンテナンスの確認項目に、システムを再立ち上げする際、データベースの状態を確認し、異常が発生していないことを確認することを追加１９. 連携先におけるシステム障害後の対応不備に起因した二重引き落とし＜業態＞
資金移動業者等＜事象＞○ カード会社から連携される残高引落処理用のデータが機器故障により正常に受信されず、誤って前日処理済みのデータで再度処理が行われたことから、カード利用者において二重の支払いが発生した。
＜原因＞
 リカバリー対応において、前日分のデータをシステム的な確認をせずに取り込んだ。
 当社はカード会社から正常にデータを受信していない旨の連絡を受けていたが、システムの運用管理を行う部署に連携していなかった。
＜対策＞

37




処理対象データについて前日データとの差分チェックを行う等、データの二重処理を防止する機能の実装
データ連携ができなかった際の関連部署や関連会社との情報連携体制の
強化

38

第２節
Ⅲ

日常の運用・保守等の過程の中で発生したシステム障害
サードパーティの提供するサービス等の要因

１. 外部委託先の提供するサービス等の要因新規＜業態＞
資金移動業者等＜事象＞○ 接続先である外部委託先の冗長化されたシステムにおいて、稼働系サーバーで異常を検知し、待機系サーバーへの自動接続が行われたものの、接続に失敗し手動での切戻しを実施した。その際に、顧客アカウントの一部に排他ロックがかかり、当該顧客がサービスを利用できなくなった。
＜原因＞
 稼働系サーバーのハード故障によるパケットロス（通信障害）が発生していた。パケットロスにより、死活監視の通信が途絶したため自動切替えに失敗した。
 排他ロックされたアカウントは手動でロック解除する必要があり、復旧に時間を要した。
＜対策＞
 外部委託先の対応として、迅速な待機系への切替え確保、復旧体制の改善、排他ロック解除の円滑化
 資金移動業者等の対応として、外部委託先の実施状況のフォローアップ、
各対応策の完了確認の実施

２. サードパーティの提供するサービス等の影響を受け決済不可新規＜業態＞
資金移動業者等＜事象＞○ サードパーティ（SaaS 型の決済サービス）が利用しているデータセンタ
ーで実施されたネットワーク機器の増設作業の不備により、障害が発生し、当該サービスを利用する複数の資金移動業者等でサービス全般が利用不可となった。
○ 当該ネットワーク機器の増設作業は、データセンター側判断による実施
であり、サードパーティへの事前のメンテナンス告知等も行っていなかった。
＜原因＞
 データセンターが外部委託先のネットワーク環境を誤認したまま作業を39

実施した。
＜対策＞
 サードパーティへの原因追及及び再発防止策の報告依頼
 サービス障害時の対応マニュアルの整備

３. 様々なネットワーク障害を想定した冗長構成の未整備＜業態＞
主要行等 地域銀行 ほか＜事象＞○ オンプレミスで構築した勘定系システムとクラウドシステム間の通信不良に起因して、IB へのログイン等が断続的に不可となり、各種取引に影
響した。
＜原因＞
 別ルートの通信手段を用意していなかった。
＜対策＞
 様々な箇所のシステム障害を想定した冗長構成の実現と切替え訓練の実
施

４. サードパーティの提供するサービスの障害によるサービス提供不可（１）＜業態＞
主要行等、地域銀行、信用金庫・信用組合等＜事象＞○ 複数の金融機関において、IB に関するワンタイムパスワード認証システ
ムのエラーにより個人 IB 及び法人 IB のログインが不可となる事象が発
生した。
＜原因＞
 サービス提供元のシステム障害が原因（サービス提供元がプログラム修正を行い対処）。
＜対策＞
 認証エラー時の代替手段の構築 障害時の連絡体制強化

５. サードパーティの提供するサービスの障害によるサービス提供不可（２）

40

＜業態＞
主要行等、地域銀行＜事象＞○ エンドユーザー側端末の OS アップデートによって、端末とシステム間の暗号化通信仕様が変更された結果、負荷分散装置で必要なリソースを確保できなくなったことで、法人 IB にログイン不可となる事象が発生した。また、事象検知や対応にも時間を要した。
＜原因＞
 システム監視におけるエラー検知がなく、接続エラーの問い合わせが通常時より増加するまで障害として認知できなかった。
 システム運用側で、検証環境の機器が本番環境と同等ではなく、障害対応のために負荷分散装置メーカーから提供された修正プログラムの妥当性確認ができなかった。
＜対策＞
 障害状況の適時把握を目的とした監視項目の追加や問い合わせ状況の連
携強化 システム運用側での本番環境と同等以上の検証環境構築と修正プログラムの検証

６. サードパーティの提供するサービスの障害によるサービス提供不可（３）
＜業態＞
主要行等
＜事象＞
○ 新規の口座開設等の機能を提供するサードパーティの提供するサービス
において、ハードウェア障害に対する冗長構成が機能せず、利用不可となる事象が発生した。また、復旧作業時に意図しない振る舞い等が発生し復旧に時間を要した。
＜原因＞
 サービス提供事業者において、障害時の作業手順や環境整備方法、外部有識者への連携等の基本的な態勢が整備されていなかった。
＜対策＞
 サービス品質を維持するための態勢確立や監査によるプロセスの改善
 業務委託元として、委託業務に対する代替手段の整備及び可用性や影響度を考慮した外部委託先の決定

７. サードパーティが提供するサービス仕様の理解不足による Web アクセス不可
41

＜業態＞
主要行等
＜事象＞
○ サードパーティがサービスとして提供するサーバー証明書 14の有効期限に対する自動更新機能が、意図しないタイミングで実施され、スマート
フォンアプリに保持された情報との不整合によって、サービスが利用できない事象が発生した。
＜原因＞
 サーバー証明書の期日を管理していたサーバー運用部門が、自動更新機
能による更新タイミングを把握できていなかった。
＜対策＞
 利用するサービスの設定や仕様に関する関係者間での必要な確認と周知

８. サードパーティの提供するサービスの障害によるスマートフォンアプリケーション、一部 Web サービス提供不可
＜業態＞
地域銀行
＜事象＞
○ データ記憶装置が停止状態になった結果、スマートフォンアプリケーシ
ョンによる口座開設新規開設、スマホ・PC による住宅ローン申し込みができない事象が発生した。
＜原因＞
 共同利用しているデータ記憶装置にて機器故障交換を契機に潜在的な不具合が発生し、データ記憶装置がスローダウンし最終的には停止状態になった。
 データ記憶装置のベンダー出荷時に設定初期不良があった。
＜対策＞
 データ記憶装置の監視項目にパフォーマンス傾向「応答速度」を追加
 ベンダー製品の各種初期設定値の開示、機器増強時に設定値の精査

９. サードパーティの提供するサービスの障害によるサービス提供不可
＜業態＞
地域銀行
＜事象＞
14

「通信の暗号化」「Web サイトの運営者・運営組織の実在証明」の 2 つの役割をもつ電子証明書のこと

42○サードパーティ側のメンテナンス作業において設定不備があり、IB（クラウドサービス利用）にログインしづらい状態となる事象が発生した。
＜原因＞
 サードパーティ側の設定不備によって発生するシステム障害を想定していなかった。
＜対策＞
 障害発生箇所をスムーズに特定するためのシステム構成及びリソース監
視項目の見直し

１０. サードパーティの提供するサービスの障害による復旧対応遅延＜業態＞
資金移動業者等＜事象＞○ サービス提供に必要なサードパーティの利用システムが設置されている
データセンターでシステム障害が発生した。事前に準備していた冗長構成が機能せず、障害復旧に時間を要し、決済等取引に影響を及ぼす事象が発生した。
＜原因＞
 冗長構成を事前に検証する等の対策の実効性確保ができていなかった。
 復旧手順の整備、訓練等が実施できていなかった。
＜対策＞
 冗長構成の事前検証の実施
 復旧手順の整備、訓練等の実施

１１. バージョンアップの影響評価不十分による取引システムへのログイン不可＜業態＞
暗号資産交換業者＜事象＞○ クラウドサービス上の構成管理ツールに内在した欠陥(バグ)により、取引システムの再起動処理が失敗したため、顧客がログインできない事象が発生した。
＜原因＞
 構成管理ツールに欠陥があること及び当該欠陥の修正バージョンが提供されていることを認識していたにもかかわらず、影響評価を行うための43

情報収集が不十分であった。そのため、影響がないと誤った判断をし、当該ツールの入替えを実施していなかった。
＜対策＞
 パッケージ製品や外部サービスのバージョンに関する幅広い情報収集と評価プロセスの見直し

44

第２節
Ⅳ

日常の運用・保守等の過程の中で発生したシステム障害
取引量増加に伴う容量不足等

１. ピーク日の処理による法人 IB へのログイン困難新規
＜業態＞
主要行等
＜事象＞
○ 月末ピーク日に処理負荷が高い入出金明細照会を法人 IB で集中的に受け付けたことにより、サーバーの処理能力を超えたため、法人 IB にログ
インしにくくなる事象が発生した。また、復旧までに時間（約８時間）を
要した。
＜原因＞
 メモリの負荷検証が不十分であった。
 障害発生時の復旧手順の整備が不十分であった。
＜対策＞
 リソース（メモリ、CPU）増強及び処理性能検証の実施
 障害発生時の復旧手順の整備

２. 取引集中に備えた対策の不備による送信の時限超過
＜業態＞
主要行等
＜事象＞
○ 外為送金のアンチ・マネー・ローンダリング用システムにおいて、取引の集中に伴う滞留状態に起因して大量のタイムアウトが発生した。結果として外為送金の処理期限までに一部処理が完了しなかった。
＜原因＞
 取引量増加に伴う電文滞留に対してシステム増強等の対策を取らなかった。
 電文滞留時の対応に誤りがあり、タイムアウトの発生を誘発する結果と
なった。
＜対策＞
 リソースの使用率や発生したエラー等のリスク事象を捉えた対策の実施
 タイムアウト等の不芳事象を把握し対応する態勢の構築

３. カウンター上限値超過によるシステム停止
45

＜業態＞
主要行等、資金移動業者等＜事象＞○ 取引量の増加（キャンペーン等のイベントによる一時的な取引量増加を含む。）により、システムで保有する取引件数等のカウンターやメールのファイル格納数等のシステムカウンターが上限値を超過し、システムが停止したため、顧客がサービスを利用できない事象が発生した。また、システム設定値の上限を超過した場合の対応を備えていたが機能しなかった事象も発生した。
＜原因＞
 システムで保有する取引件数カウンターやメールのファイル格納数等のシステム設定値の上限の把握や監視ができていない。
 取引量等の増加（キャンペーン等のイベントによる一時的な取引量増加を含む）によるシステム設定値の上限の事前検証、見直しができていな
い。また、システム設定値の上限を超過した場合の対応が正しく動作するかの検証ができていない。
＜対策＞
 システムで保有する取引件数カウンターやメールのファイル格納数等のシステム設定値と上限の洗出し
 カウンターの監視、取引量等の増加（一時的な取引量増加を含む）によるシステム設定値の上限（システム設定値の上限を超過した場合措置を含む）の事前検証、見直し実施

４. システムの処理能力不足による決済不可＜業態＞
資金移動業者等＜事象＞○ 取引量の増加（キャンペーン等のイベントによる一時的な取引量増加を含む。）によるシステムの負荷予測を行い、システムの処理能力等の事前検証を行っていたが、検証範囲が適切に設定されておらず、決済が不可となる事象が発生した。
＜原因＞
 取引量の増加に伴うシステムの負荷予測、システムの処理能力等の事前検証が必要な外部接続先等の範囲の認識が誤っていた。
＜対策＞ システムの負荷予測、システムの処理能力等の事前検証を行う先の選定に関して、決済事業者や販売店（POS 会社）の外部接続先を含めた網羅的46

な検討の実施

５. 新規暗号資産販売時の負荷検証不足による処理停止＜業態＞
暗号資産交換業者＜事象＞○ 新規暗号資産販売時において、顧客から大量の発注申込が発生。発注処理遅延からサーバーが一定時間内に応答しないタイムアウトが発生した
ため、処理が失敗した。
○ さらに、この処理遅延解消のためにプログラム修正を行ったところ、プ
ログラムミスによって処理誤りが生じ、復旧までに１週間以上を要した。
＜原因＞
 想定取引量にもとづく負荷検証が不十分であった。
 障害対応として実施した、処理遅延解消のためのプログラム修正の検証が不十分であった。
＜対策＞
 想定取引量の適切な見積り並びに想定取引量にもとづく処理時間計測及びシステム負荷の観点での検証態勢の整備
 障害対応時におけるプログラム修正に対する検証態勢の整備

47

第３節

システム統合・更改に伴い発生したシステム障害

１. 復旧手順の不備による障害対応時間の長期化新規
＜業態＞
主要行等
＜事象＞
○ ネットワーク機器の不具合により、総合振込のエラーが発生した。社内関係各部への情報共有の遅延や複雑な BCP により、時限内に対応が行え
なかった。
＜原因＞
 提供するサービスの障害発生時における初動対応の手順が不明確だった。
 総合振込のエラーをカバーする BCP の網羅性が不足し、BCP が有効に機能しなかった。
 復旧作業にあたり、BCP で定めていない作業手順から検討したため、所要時間の見積りを正しく評価できず、時限を過ぎても対応を終えることができなかった。
＜対策＞ サービス毎（総合振込、口座振替等）の復旧対応手順の整備
 BCP の見直しと訓練の実施
 復旧目標時刻までにシステム復旧が見込めない場合の対応方針の明確化

２. 性能の仕様の理解不足による一部 ATM 停止新規
＜業態＞
主要行等
＜事象＞
○ ATM を利用したキャッシング取引でのタイムアウトにより、一部の ATM で
キャッシング取引が不可となり、当該 ATM が停止した。
＜原因＞
 設計書やテストケースのレビュー時に有識者がレビューに参画していなかった。
 勘定系システムと ATM 等を中継するシステムの性能に関する仕様の理解が不足していた。
 本番同等の ATM の取引量を想定した負荷テストを実施していなかった。
＜対策＞
 開発時におけるレビューアの適切な配置

48




設計書の記載の充実
本番稼働を想定した高負荷テストの実施

３. リリース作業誤りによる仕向振込・被仕向入金一部不可新規
＜業態＞
主要行等
＜事象＞
○ プログラムのリリース作業誤りにより、全銀システム関連機能が意図せず二重起動したことに起因し、当該機能がダウンと再起動を繰り返し、
全銀システムとの通信が不安定な状態となった。これにより、仕向振込
及び被仕向入金が一部不可等となった。また、復旧方法を誤り、仕向振込の二重送信等が発生した。
＜原因＞
 本番環境に準じたテスト環境を構築した上でのリリース作業手順確認を実施していなかった。
 外部委託先からリリース作業が遅延しているという報告を受けていたものの、リリース時間が全銀システムに与える影響を認識しないままリリースを承認してしまった。
 全銀システムとの接続復旧後に電文を送信する際に電文毎に不整合の発生有無を確認していなかった。
＜対策＞
 本番環境に準じたテスト環境の構築とリリース作業手順確認の実施
 リリースプロセス見直しの実施
 障害復旧時の手順の整備

４. メモリ管理不具合による取引遅延新規
＜業態＞
主要行等
＜事象＞
○ 新システム稼働後に大量データの入出力が発生した際、メモリを確保できずサーバー全体がスローダウンしたことにより、仕向振込、被仕向入金が遅延した。
＜原因＞
 バックアップ処理において、不要なファイルをコピーして必要以上の入出力が発生したことにより、データを一時的に保管するメモリを確保で49

きなかった。
 サーバーがスローダウンした際にアラートを送信する仕組みがなかった。
＜対策＞
 バックアップ処理を必要なファイルのみコピーするよう変更
 メモリの開放要求が発生したタイミングでアラートを発出する処理の追加

５. IB サービス提供側の対応漏れによる法人 IB 上の取引不可新規＜業態＞
信用金庫・信用組合等＜事象＞○ 法人 IB 上の取引が不可となる事象が発生した。
＜原因＞
 事前に実施された勘定系システム更改にあたり、IB サービス提供者側の開局・閉局処理プロセスに対応漏れがあった。
＜対策＞
 IB サービス提供者側における死活監視・再起動機能の導入
 開局・閉局要求を送信するタイミングが他の信用金庫と重ならないよう
調整 IB サービス提供者側における複数要員確保、連絡体制等の整備

６. システム更改時のプログラム誤りによる取引エラー（１）新規＜業態＞
信用金庫・信用組合等＜事象＞○ ATM の他行カード振込取引を行った際、振込金額の支払取引のみが成立
し、振込自体がエラーとなる事象が発生した。
＜原因＞
 勘定系システム更改の対応において、通帳振込機能のプログラムに誤りがあり、他行カードを利用した振込処理の際、他行宛振込支払応答処理
でカードを利用した振込実行処理を実施すべきところ、通帳を利用した振込実行処理を実施し、当該振込実行処理で業務エラーが発生した。
＜対策＞
 委託責任者としての各種検証、テスト実施

50



システム更改期間中の緊急時における信用金庫内及び外部委託先を中心とした外部関係機関との情報連携強化

７. システム更改時のプログラム誤りによる取引エラー（２）新規＜業態＞
信用金庫・信用組合等＜事象＞○ 一部地域のクレジット会社のカードを利用した ATM 取引がエラーとなる事象が発生した。
＜原因＞
 勘定系システム更改にあたり、外部委託先が開発した地域クレジット会
社のカード種別を判別するプログラムに不備があった。
 外部委託先において、クレジット会社のカードの利用に係るテストの実
施対象を全国的なクレジット会社のカードに限定し、地域クレジット会
社のカードに対するテストを行わなかったため、本件不備が検知されなかった。
 外部委託先から修正プログラムのテスト結果が良好との報告を受け、修正プログラムのリリースを了承し一時復旧したと認識したが、実際はテスト環境で実施していないカード情報の復号処理プログラムに不備が内包されていたため、再度不備が発生した。
＜対策＞
 システム更改時における網羅性のあるテストの実施
 本番環境とテスト環境の差異の整備

８. システム更改時のプログラム誤りによるキャッシュカード使用不可新規＜業態＞
信用金庫・信用組合等＜事象＞○ ATM で生体認証 IC キャッシュカードが使用不可となる事象が発生した。
＜原因＞
 勘定系システムの更改における IC 認証に関するプログラムに不備があった。
 生体認証 IC キャッシュカード発行開始当初、IC チップ内の一部データ
項目が未設定の状態で発行されたものがあり、当該カードも問題なく利用できるよう更改前のシステムのプログラムに改修を加えていたが、更51

改後のシステムには想定したプログラムが反映できていなかった。
 今回不具合が発生する条件のテスト用の生体認証 IC キャッシュカードが手元になく確認テストができていなかったため、事前に不具合の検出ができなかった。
＜対策＞
 新しいキャッシュカードを発行する際、将来のプログラム改修に備え、テストで使用するキャッシュカード等を準備及び厳格に保管し、テスト実施を徹底

９. 仕様の把握ミスに起因した入金金額相違新規＜業態＞
金融商品取引業者等＜事象＞○ 営業店でのリアルタイム口座振替指示（取引明細指定）において、振替指示画面上の受渡日の前日基準残高が誤って表示されていたことにより、誤った振替指示が実行された。
＜原因＞
 前日基準残高の算出は外部委託先が提供する共同利用型システムの既存仕様にあるロジックを用いて構築したが、旧システムの類似したロジッ
クと利用用途が同様であると思い込んだため、調査・設計の不足がある
ことに気づくことができなかった。
 パターンの網羅性を考慮したテストを実施することができなかった。
＜対策＞
 新旧システムの仕様に関する差分等の検証態勢の強化

１０. 旧銀行カードによる ATM 利用不可新規
＜業態＞
地域銀行
＜事象＞
○ 共同センターへの移行において、 ATM による他行宛振込処理で旧銀行の廃止店発行のキャッシュカードを使用した場合、廃止店のためテーブルに登録がなく異動明細作成処理が異常終了したことにより、他行宛て ATM
振込不可となった。
＜原因＞
 共同センターの仕様に、当行では不要なテーブルを参照する処理が含ま52

れていたが、事前にその処理の必要性を確認していなかった。
＜対策＞
 共同センターのカード取引における機能変更時、廃止店番に対する仕様の確認

１１. プログラム更改時のテスト不足等に起因するオンライン処理の停止
＜業態＞
主要行等
＜事象＞
○ 通帳レス対応に関する営業店オペレーター向けプログラムの改修時の不具合に起因して、オンライン処理で共通的に利用するデータベースの更新等が不可となり、プログラムを切り戻すまでの間、全営業店におけるオンライン処理等が利用不可となった。
＜原因＞
 プログラムの品質チェックにおいて、担当者の思い込みや誤りによって再鑑が機能していなかった。
 プログラム改修が小規模な予算のプロジェクトであったため、テストによる検証が簡易的に行われていた。
＜対策＞
 レガシーシステムの暗黙知を設計書等に明記
 最大リスクに応じた深度あるテストやチェックリストによる確認

１２. 仕様の把握ミスに起因したスマートフォンアプリケーションのログイン
不可
＜業態＞
主要行等
＜事象＞
○ 新勘定系システムに移行後に、旧勘定系システムの仕様を誤認したことに起因して、スマートフォンアプリケーションで約１時間、利用不可と
なった。
＜原因＞
 データベースの設計内容（型指定等）を誤認したまま開発を進めたことで、連携するシステムとの間で不整合が発生した。
 旧仕様を踏襲する設計であったため結合テスト等の工程で試験内容が不
足した。

53

＜対策＞
 連携するシステム側の仕様を確認する点を開発ガイドラインに明記
 旧仕様を踏襲する設計であっても境界値試験等を実施

１３. 大規模プロジェクトに係る知見、経験等の不足による ATM 停止及び残高情
報の誤更新
＜業態＞
主要行等
＜事象＞
○ ATM 取引不能及び勘定不整合が発生した。
＜原因＞
 勘定系システムと ATM の間で発生したネットワーク障害（障害に対する
考慮不足によりネットワークのログを保存していなかったため詳細不明）により勘定系システムからの応答（下り電文）が ATM へ届かなかったため、取引が不能となった。
 ネットワーク障害が発生し応答が正常にできていないことを検知していたにもかかわらず、勘定系システム内では ATM から続々と要求され続ける取引（上り電文）の処理を続けたため、取引が完結していないにもかかわらず勘定系システム内の残高情報が更新された。
＜対策＞
 重要システムでの障害発生時に原因を正確に特定するため、ログの保存を開始
 ネットワーク障害を検知した場合には即時に取引を停止し再起動するよう勘定系システムを改修

１４. システムリスク管理態勢の整備不足によるサービス停止
＜業態＞
主要行等
＜事象１＞
○ 新システム稼働後、大量の処理に伴うサーバーリソースの高負荷、データロック（滞留）の長期化が発生し、IB やデビット機能、ATM 取引が利用不可となった。
＜原因１＞
 システム開発時に想定した以上のトランザクション件数が発生した。
 システム開発時におけるパフォーマンスやキャパシティに係るテストが54

不足していた。
＜対策１＞
 サーバーリソースの高負荷を回避するようシステムレスポンスを改善
 長時間のデータロックを回避するよう処理ロジックを変更
 サーバーの高負荷を防止するよう商品ルールを変更し、アプリケーショ
ンを改修
＜事象２＞
○ 勘定系データベースサーバーがダウンし、ATM で取引エラーが発生した。
＜原因２＞
 基本ソフトウェアの不具合により、勘定系データベースサーバーがダウンした。また、待機系への手動切替え手順の認識（手順実施の必要性、関連ドキュメントの所在等）不足により対応が遅れ、サービス回復までに時間を要した。
＜対策２＞
 基本ソフトウェアのバージョンアップ
 障害対応態勢の整備（知識の共有を含む）
 障害対応に係るドキュメントの参照環境の整備（検索性向上等）＜事象３＞○ 各種処理の実行タイミングの競合等により、他行宛振込や定額自動振込の実行不可、デビット機能の利用不可が発生した。
＜原因３＞
 各種処理（オンライン取引・バッチ処理・顧客操作等）やデータの影響範
囲・利用範囲の把握が十分ではなく、処理の競合に係る考慮が漏れており、テストが不足していた。
＜対策３＞
 網羅的なテストケース設定のためのドキュメント（システム関連図等）の作成
 オンライン取引等の競合防止のための禁止事項・ルールの整備＜事象４＞○ 他行宛振込実施時に、複数行の特定支店が振込先として表示されない障害が発生した。また、データパッチ15により対処を実施したところ、振込
画面に遷移するとシステムエラーとなる２次障害が発生した。
＜原因４＞

15

「データパッチ」とは、不具合の修正を行うために、データベースに適用し、一部の更新データをデータベースに適用すること。

55



支店の住所変更等に係る日付のプログラム誤りにより、当該特定支店が無効となっていた。
 データパッチ適用作業実施時のルールが未整備であり、再鑑も行われていなかった。
＜対策４＞
 チェックリストに日付や曜日の観点を加え、設計レビューやテスト等を実施
 本番環境におけるデータパッチ適用等の作業時のルールを整備し、上長による承認フローを徹底

１５. システム更改時の設計漏れに起因する被仕向送金障害
＜業態＞
地域銀行
＜事象＞
○ 被仕向送金のうち、一部振込に関して、振込資金の入金遅延・仕向銀行への資金の誤返却する障害が発生した。
＜原因＞
 受取人口座番号の変更処理プログラムの誤りで、口座番号相違となった。
 設計担当者・レビュー担当者双方の被仕向為替における口座番号変換処
理仕様に関して理解が不足しており、口座番号の桁数バリエーションまで含めたテストケース設定ができていなかった。
＜対策＞
 業務機能・システム処理方式に関する設計ドキュメントの整備
 周辺システムを意識した勘定系システムの設計レビュー、テスト等の充実

１６. コアタイムからモアタイム切替え遅延に伴う為替未送信
＜業態＞
地域銀行
＜事象＞
○ 障害発生時間帯（約 15 分間）に受け付けた他行宛振込が全銀センターでエラーとなり、当行内に滞留、為替未送信となる事象が発生した。
＜原因＞
 修正プログラムをリリースした際、為替送信処理ステータスがエラーとなり、同時間帯に受付した他行宛振込が滞留した。

56



運用担当者における修正プログラムの反映タイミングの理解や経験が不足していた。
＜対策＞
 周辺システムを意識した勘定系システムの設計レビュー・テスト等の充実

１７. 新旧システムの特性等に対する考慮不足による誤った引落し
＜業態＞
地域銀行
＜事象＞
○ 新旧システムの機能差異の比較不足のため、誤って口座引落しされる事象が発生した。
＜原因＞
 解約等によって口座引落しを行わない明細の扱いが新旧システムで異なることを、設計時やデータ移行時に新旧比較や有識者レビューの不足のため認識できなかった。
＜対策＞
 設計時の新旧システムの各有識者による相互レビューの徹底

１８. プログラムの修正漏れによる振込不可＜業態＞
信用金庫・信用組合等＜事象＞○ IB や ATM 等から振込を行う際の取引電文を書き出す為替発信用ファイル
に関するプログラムに修正漏れがあり、先日付振込が当初予定の期日に行われない事象が発生した。
＜原因＞
 システム開発時における先日付振込を含むテストケースが不足していた。
＜対策＞
 IB や ATM 等を含む対外接続に係る開発において、オンラインで作成されるデータ、センターカットにて作成されるデータ等テストケースを網羅
的に洗い出した上でテスト実施

57

１９. IT 部門と業務部門の連携不足による祝日設定の誤り＜業態＞
暗号資産交換業者＜事象＞○ 取引システムを更改後、本来取引時間外としている祝日において取引が可能な状態となった。
＜原因＞
 取引システムの祝日設定を誤っていた。
 取引システムを更改した際、IT 部門と業務部門による仕様確認やテストの分担や手順が不明確であった。
＜対策＞
 業務に関連するシステムの設定に対する業務部門の確認・指示や IT 部門の作業等のプロセス整備
 システム更改における業務部門の主体的な関与、IT 部門と業務部門との運用に関する役割分担の明確化

58

第４節
Ⅰ

プログラム更新、普段と異なる特殊作業等から発生したシステム障害
設定ミス・操作ミス等の管理面・人的要因

１. 送信元の設定誤りによる IB 等利用不可新規
＜業態＞
主要行等
＜事象＞
○ クラウド環境へ移行する際、本来許可すべき送信元の IP アドレスのセグ
メント設定を誤り、接続エラーとなったことに起因し、一部の顧客が個
人用 IB やホームページを利用できない事象が発生した。また、顧客からの問い合わせがあるまで当該障害を発見できなかった。
＜原因＞
 担当者の作業確認漏れにより、許可すべき IP アドレスのセグメントが本
番環境に反映されていなかった。
 接続エラーが発生した際にアラートを検知する機能を実装していなかった。
＜対策＞
 レビュー体制の整備
 接続エラーのアラート検知機能の構築

２. 設定誤りによるチャージ不可新規＜業態＞
資金移動業者等＜事象＞○ 銀行口座からのチャージを行った際、銀行口座残高の引落しは行われたが、資金移動業者等での残高反映がされていなかった。
＜原因＞
 銀行口座からのチャージは外部システム連携をしており、トランザクシ
ョン負荷を軽減するため処理の改修を実施したが、外部システム連携に係る仕様の理解不足があり設定が間違っていた。
 資金移動業者等は、外部システム連携による作業手順書が未整備だった
ため、テスト環境で資金移動業者等からの応答要求の動作確認は行ったが、外部システムからの応答要求の動作確認を行っていなかった。
＜対策＞
 外部システム連携に係る処理変更時の時の標準作業手順書の整備
 当該手順書及び外部システム連携仕様の周知

59

３. テーブルの最新化作業誤りによる被仕向取引不可新規
＜業態＞
地域銀行
＜事象＞
○ 外部委託先において、新店追加に伴う為替関連テーブルの更新作業を誤り、他行宛振込等の取引が不可となった。
＜原因＞
 テーブルを更新した開発担当者とテーブルのバージョン管理担当間で情報連携が行われていなかった。
 為替関連テーブルの更新作業手順が不明確であった。
＜対策＞
 為替関連テーブルの最新化に関する作業手順の整備
 外部委託先管理の強化（本番リリース前の銀行での事前検証等）

４. 計画停止中の作業誤りによる ATM 利用不可新規
＜業態＞
地域銀行
＜事象＞
○ メンテナンスのためシステムの計画停止を実施したところ、一部の機器の停止手順を誤ったことにより、システムが正常に立ち上がらず ATM 取
引等が不可となった。
＜原因＞
 作業手順書の記載が不十分であり、再鑑者によるチェックも行われていなかったことにより、システム停止の際に誤ったオペレーションを行ってしまった。
 エスカレーションに時間を要したことから有識者の駆付けが遅れ、シス
テムの再起動手順を正しく作成できなかった。
＜対策＞
 システム基盤有識者による運用担当者への研修内容の最新化及び研修の定期的実施
 障害時のエスカレーションの的確なタイミングでの実施

５. ネットワーク機器の交換手順誤りによる IB 取引不可新規

60

＜業態＞
地域銀行
＜事象＞
○ IB の共同センターにおいてネットワーク機器の予防交換の作業を誤り、
個人 IB 及び法人 IB のオンライン取引が一時不可となった。
＜原因＞
 手順書の変更管理ルールが徹底されていなかったことにより、メンテナ
ンス作業の手順書が修正されなかった。
＜対策＞
 変更管理ルールの徹底、作業手順書作成に関する適切な作業者やレビュ
ーアのアサインの徹底

６. モアタイムへの切替えに関する設定ミスに起因した振込エラー
＜業態＞
主要行等
＜事象＞
○ 全銀システムとの接続設定に係る人為ミス（コアタイムシステムからモアタイムシステム16への切替え時刻の設定ミス）により、他行向けの振込
がエラーとなった。
＜原因＞
 作業実施者に向けた切替え時刻に関する伝達内容が不明瞭であった。また再鑑も機能していなかった。
＜対策＞
 維持メンテナンス作業における多層的なチェック態勢の構築（設定項目の明確化、再鑑観点の具体化等）

７. 製品知識の不足に起因する障害に伴う IB の利用不可
＜業態＞
主要行等
＜事象＞
○ 勘定系システムと周辺システムとを接続するハブ機能をもつシステムにおいて、冗長構成の設定不備に起因し、ハードウェア障害時にシステム

16

全国銀行データ通信システムの内国為替取引を処理するオンラインシステムのサブシステムのこと。平日８時半から 15 時半までの即時入金を実現する「コアタイムシステム」と平日夜間・土日祝日の「モアタイムシステ
ム」がある。

61

が停止し IB が利用不可となった。システム改修時にそれまで利用していた製品とは別製品を採用したことに起因し、製品固有の設定についてメーカーに対する確認漏れが発生した。
＜原因＞
 過去の開発実績を踏まえて設計・設定を行った。
 切替えのテスト工程について、利用実績のある製品をもとにしたテストのみを行ったため、設定誤りに気づけなかった。
＜対策＞
 導入実績のないハードウェアやソフトウェアを利用する際の製品メーカ
ーのテクニカルレビューを義務化し、確認漏れを発生させないプロセスを整備

８. 口座情報の更新作業の障害に伴う ATM の利用不可
＜業態＞
主要行等
＜事象＞
○ 口座情報の更新作業時にメモリ容量不足が発生し、勘定系システムの一部機能が停止したことに起因して、多くの ATM が停止し顧客の通帳等が取り込まれる事態が発生した。
＜原因＞
 作業時に直接的な変更箇所以外の影響確認を実施していなかった。
 作業に起因して発生する業務影響の把握が不足したことによって事前準備が不足し障害対応に時間を要した。
＜対策＞
 変更作業に対するチェックやレビュープロセス改善と影響箇所を把握するための有識者の育成
 限定された作業箇所の障害がシステム全体としてどのような影響範囲（最大リスク）になるのか特定し対策する態勢の整備

９. ネットワーク機器の設定ミスに起因した自行 ATM の停止
＜業態＞
地域銀行
＜事象＞
○ 委託先サービスと接続するための作業における設定誤りに起因して自行ATM が停止した。ATM 稼働時間帯に作業したため、数十件の取引が不可と62

なり、現金やキャッシュカードのくわえ込みが発生した。
＜原因＞
 ネットワーク機器の仕様を誤認した状態で構築しており、レビューは書面のみであった。
 作業リスクを見誤り ATM 稼働時間帯に作業を実施した＜対策＞
 実機によるテストとレビューの徹底 顧客影響のリスクを考慮した作業時間帯の設定

１０. 本番作業時の同時処理考慮漏れに起因するオンライン取引不能
＜業態＞
地域銀行
＜事象＞
○ 月次定例処理と随時処理におけるデータベースアクセスが競合し、一部店舗の口座（元帳）オンライン取引が不能となり、取引不能時間帯に利用された自動機（ATM、通帳繰越機）がタイムアウトし自動機が停止する
障害が発生した。
＜原因＞
 運用担当者は定例処理と随時処理を同時実行するときのリスクを正しく認識できておらず、また開発担当者においても処理が競合するリスクに気付くことができなかった。
＜対策＞
 定例処理と随時処理の競合時における問題発生処理の洗い出しと処理可
能時間の明確化
 「実施タイミング」、「処理実施システム」、「参照先データベース」等に問題がないことを事前にチェックする手順の整備

１１. データベース容量拡張時の作業手順誤りによる入金取引不可
＜業態＞
貸金業者
＜事象＞
○ データベース容量拡張時の作業手順誤りにより、一部ローンサービスにおける入金取引が不可となる事象が発生した。
＜原因＞
 データベース容量拡張作業において、作業手順を誤り、データ移行が正63

常に実施できなかった（テストは実施したが、本番との作業手順に相違があった）。
＜対策＞
 テストにおける作業手順の確認は、本番と同一手順でのテスト実施を徹底

１２. 開発メンバーの引継ぎ不十分に伴う仕様の理解不足によるログイン不可＜業態＞
暗号資産交換業者＜事象＞○ 顧客からの依頼により、当社担当者の操作による利用者情報の変更の際、変更の承認を得るための電子メールの送信先が誤っていたため、変更手
続きが完了せず、顧客がログインできない事象が発生した。
＜原因＞
 利用者情報変更のプログラムについて、顧客操作によるものと当社担当
者操作によるもので同一のプログラムが利用されるという認識がなかったため、前者のみを対象に仕様変更した際、後者への影響を考慮できず、
電子メールの送信先の仕様が変更されてしまった。
 同一プログラムが利用される認識がなかったのは、開発メンバー変更の際の引継ぎ不十分に伴う業務仕様の理解不足である。
＜対策＞
 業務を考慮した影響確認に向けたチェック観点及びテスト項目の整備
 開発メンバーによる業務に係る仕様の再確認

１３. アップグレード作業未完による暗号資産の取引停止＜業態＞
暗号資産交換業者＜事象＞○ 当社が取り扱っている暗号資産のノード 17のアップグレードがなされたにもかかわらず、それと接続する外部委託先のノードのアップグレード
がなされなかったため、暗号資産のノードと外部委託先のノードにバージョン差異が発生し、顧客資産の入出庫が実施できなくなった。
＜原因＞
 外部委託先はノードのアップグレードの期日を認識していたものの、作17

暗号資産のネットワークを構成するサーバーや端末等のこと。

64

業依頼者が作業期限を明記しなかったため、アップグレードの期日までに作業実施者によるアップグレード作業が完了しなかった。
 当社はノードのアップグレード期日を認識しておらず、外部委託先の作業状況も把握していなかった。
＜対策＞
 外部委託先による作業管理（期限設定、完了確認等）の徹底
 当社による暗号資産のノードのアップグレードに関する情報の定期的な収集及びアップグレードに係る作業状況の管理

65

第４節
Ⅱ

プログラム更新、普段と異なる特殊作業等から発生したシステム障害
ソフトウェアの不具合

１. プログラム誤りによる ATM 停止新規
＜業態＞
地域銀行
＜事象＞
○ 勘定系システムと ATM を接続するシステムにおいて、過去に発生した障害対応を行うため、勘定系システムと ATM の接続状況を確認するプログ
ラムをリリースしたが、そのプログラムの接続状況を確認する処理の不具合により、一部の ATM や通帳繰越機が利用不能となった。
＜原因＞
 ATM と接続するシステムの起動処理の挙動についてプログラムを開発した外部委託先が、ATM を開発した外部委託先への確認を怠り、誤った認識の下でプログラムを作成してしまった。
 新たに導入するプログラムに関するレビューやテストが十分でなかった。
＜対策＞
 外部委託先共通のプログラムの開発プロセス策定とレビュー態勢の確保

２. 想定を超えた注文数により時間優先での原則が適用されず約定が行われた
システム障害新規＜業態＞
暗号資産交換業者＜事象＞○ 同一価格で一定件数を超える指値買いの新規注文が蓄積した場合、約定
対象の買い注文に時間優先の原則が適用されず、後から注文した指値の買い注文から約定した。
＜原因＞
 当社取引所システムの板寄せ処理は、指値の買い注文を一定件数ずつ取得し売り注文とのマッチングを行っているが、一定件数を超える同一価
格での指値の買い新規注文が発生した場合、直近の一定件数が優先される仕様となっていたため、先に注文した買い注文が後回しにされた。
＜対策＞
 想定以上の注文を受けた際に時間優先の原則が適用されているかという
テスト確認の徹底
66



新規取扱銘柄に対する注文増加予測と事前のシステム影響調査

３. 本番環境を想定したテストケースの不足に起因する IB の利用不可
＜業態＞
主要行等
＜事象＞
○ 法人向け IB に関する新規プログラムのリリースに起因して、約３時間、利用不可となる障害が発生した。
＜原因＞
 本番ピーク時相当の負荷テストと組み合わせたテストケースの検証を実施していなかった。
＜対策＞
 取引が発生しない時間帯でのリリース（対応が難しければ実効性あるテ
ストケースでの検証を実施）

４. 新規プログラムの設計不備及びリリース認証不可
＜業態＞
主要行等
＜事象＞
○ 生体認証プログラムの新規リリース後に、誤ったソフトウェア設計に起因して処理が間に合わず大量の認証エラーが発生した。その後システムの切戻しを実施したが、復旧までに時間を要した。
＜原因＞
 新規プログラム開発時に行った負荷テストが、そもそもシステム要件に合致していなかった。
 システムの安全性に配慮したリリース手順ではなかった。
＜対策＞
 開発委託先の負荷テストの検証結果を確認するプロセスの追加
 システムリリース時における手順の品質向上

５. システム更改（機能追加）時の、仕様の理解不足等によるプログラムミス＜業態＞
信用金庫・信用組合等

67

＜事象＞
○ 共同センター（個人向け IB)において、機能追加による更新時に設計書の記載が不正確であったことにより、プログラムミスによるエラーが発生し、約 10 金庫の個人向け IB において、ログインできない事象が発生した。
○ 共同センター (法人向け IB)において、機能追加による更新時に仕様変更を把握していなかったことにより、データベースのレコード作成に誤りがあり、約 90 金庫の法人向け IB において、取引画面が操作できない事象が発生した。
＜原因＞
 機能追加による更新時に、設計書の記載が不正確であった。
 更改時の仕様変更を把握していなかった。
＜対策＞
 設計書の再点検
 データ構成を変更する際に既存データが変更後の仕様に合致しているかの全件チェックを実施することをルール化
 機能追加・変更があった設定の再検証
 レコード作成要領の整備
 システム更改時の仕様変更について、理解度向上のための講習会を実施

６. システム開発におけるレビュー不足によるサービス提供不可＜業態＞
信用金庫・信用組合等＜事象＞○ 勘定系システムの通信状況を監視するプログラムの不備により、当該システムが停止し、窓口での現金受払、ATM、IB 等の取引が不可となる事象が発生した。また、システムを運用する外部委託先から金融機関への報告に時間を要した。
＜原因＞
 プログラムの不備により、ホストコンピュータのリソースが枯渇し、システムが正常に稼働しなくなった。
 プログラムの初期導入時、検証者によるレビューが有効に機能しなかった。
 夜間・早朝に障害が発生した際の連絡手段に不備があり、また、定義された CP が不徹底であった。
＜対策＞
 ホストコンピュータのリソース監視強化、本番リリース時のチェックリ68

ストの見直し、本事象と同様の不備有無の点検
大規模障害発生時の連絡体制の再検証、大規模障害の訓練の定期的な実施

７. 外部ベンダーのパッケージ製品の仕様確認不足による取引処理遅延＜業態＞
金融商品取引業者（ネット証券会社）＜事象＞○ 改修した口座振替サービスのリリース直後、口座振替処理が遅延した。
＜原因＞
 改修に伴い、利用していたパッケージ製品の仕様確認を自社でしか行わなかった結果、確認に誤りがあり、パッケージ製品が本来対応していな
い処理方式へと改修してしまった。
＜対策＞
 今後の改修時の影響調査においては、製品ベンダーへ確認し、確認結果の証跡を残すようプロセスを変更
 リリースまでに本番同等の環境にてテストを行えるよう開発環境を整備

８. ログ出力仕様の誤りによる取引開始遅延＜業態＞
金融商品取引業者（ネット証券会社）＜事象＞○ データベースサーバーが高負荷の状態で実行された定期バックアップ処
理に時間を要し、FX 取引サービスの開始が遅延。また、復旧作業を行った影響により、取引報告書閲覧開始が遅延。
＜原因＞
 障害発生の数日前にリリースした改修プログラムにおいて、本来はログ出力が不要にもかかわらず、一部のログを高頻度に出力する不具合が内在していた。
 ログ出力がないとの思い込みによりテストでのログ出力確認を実施せず、また、テストでは本番よりも負荷の少ないテストデータ使用したことにより不具合の発見に至らなかった。
＜対策＞
 設計時にログ出力頻度やリソースへの影響について確認することを開発
時のチェックシートへ明記

69

サイクルテスト実施時に不要なログ出力のないこと、予期せぬ性能劣化のないことを確認することを開発時のチェックシートへ明記

９. 外部委託先が招いた設計不備、自社によるテスト不足による送金不可＜業態＞
資金移動業者等＜事象＞○ 性能改善のためリリースした修正プログラムに設計不備があり、送金先へ接続できず、送金不可となる事象が発生した。
＜原因＞
 外部委託先において設計書等の成果物の整備が不十分で知識が属人化しており、また、担当者の異動時の引継ぎが不十分であったため、リリース前に設計不備に気付けなかった。
 当社による受入テストにおいてもテスト項目が不十分であり、設計不備を検知できなかった。
＜対策＞
 知識の属人化防止のための成果物の確実な作成、担当者の異動に備えた体制の整備
 システム変更箇所を考慮した十分なテスト計画を作成の上、受入テスト
を実施

70

第５節

システム障害後の対応が円滑に行われた事例

１. システム障害対応に係る手続きの明確化新規
＜業態＞
主要行等
＜事象＞
○ ハードウェア故障によってネットワーク機器が使用不能となったことにより、別経路に自動で切り替わったものの、自動で経路が切り替わるまで一時的に接続が切断されたことで IB 及び ATM での顧客取引や外為被仕向送金等がエラーとなった。
＜対応＞
 システム障害時における取引エラー内容確認、仕掛取引有無の確認、顧客対応の必要性有無の確認に係る手続きを事前に定めていたため、顧客影響を把握のうえ取引の時限内に対応を完了した。

２. ATM 停止時の円滑な顧客対応の実施新規＜業態＞
信用金庫・信用組合等＜事象＞○ 勘定系ネットワーク機器の不具合により、ATM 機器及び CTM18端末による全取引が約１時間、停止する事象が発生した。
＜対応＞ ATM 取引中に取引が中断した顧客が 13 名いたが、職員による説明、取引の確認、他金融機関への誘導等を実施し、ATM 利用に関する苦情等は発生しなかった。

３. コンティンジェンシープランに則った円滑な顧客対応の実施新規
＜業態＞
地域銀行
＜事象＞
○ 通信回線業者の通信障害により、店舗外 ATM とホスト間の通信が休止状態となった。
＜対応＞
18

郵便貯金、簡易保険の業務で使用される係員操作の端末機。
「カウンター・ターミナル・マシン」の略。

71





障害における顧客対応等について、コンティンジェンシープランに基づき店舗外 ATM に担当者を出動させ、ATM 利用者に対して最寄りの店舗内
ATM や提携先の ATM へ誘導を実施した。また、ATM 利用に関する苦情等は発生しなかった。
今後、より迅速な顧客対応等を可能とすべく、休日における障害発生時の訓練について実施することとしている。

４. コンティンジェンシープランに則った円滑なシステム復旧の実施新規
＜業態＞
地域銀行
＜事象＞
○ クラウドサービスのデータセンター内で通信ネットワーク障害により、ATM 利用不可等となった。
＜対応＞
 顧客が利用中で自動復旧できなかった店舗内 ATM は、コンティンジェン
シープランに基づき行員による手動リセットにより、復旧対応を実施し、店舗外 ATM は、リモート対応あるいは行員の手動リセットにて復旧対応を実施した。
 また、通帳等の取込みが生じ、翌日以降に事後の顧客対応が必要となった事象は、店舗外 ATM 管理店行員が返却等の対応を実施した。
 さらに、店舗外 ATM の対策として、事前に指定した駆付け担当者以外がATM 駆付けする事態を想定し、手動リセットを実施する手順の訓練及びマニュアルの設置を実施した。
 休日の大規模障害発生を想定した対応について、ATM 駆付け訓練を実施
した。

以

72

上