調査報告書（公表版）

2021 年 6 月 15 日

システム障害特別調査委員会

2021 年 6 月 15 日

株式会社みずほフィナンシャルグループ

御中

シ ス テ ム 障 害 特 別 調 査 委 員 会

委

員 長

岩

村

修

二

委

員

鵜

瀞

惠

子

委

員

西

川

清

二

委

員

角

谷

直

紀

2

調査報告書目次
第１ 調査の概要 .............................................................. 9
１

委員会の設置経緯......................................................... 9２

調査の目的 .............................................................. 9３

本委員会の構成及び調査体制............................................... 9４ 本委員会の独立性........................................................ 11５ 本委員会 MHFG 事務局..................................................... 11６

調査期間 ............................................................... 11７

調査の方法・範囲........................................................ 11（１）関係資料の精査......................................................... 12（２）ヒアリング及び現地調査................................................. 12（３）デジタルフォレンジック調査............................................. 12（４）アンケート調査......................................................... 12（５）ホットラインの設置及び申告への対応 ..................................... 12（６）その他の調査 .......................................................... 13８

委員会の会議開催状況.................................................... 13９

本調査の前提と限界...................................................... 13

第２ 組織、事業内容及び内部統制.............................................. 13
１

MHFG 及び MHBK の概要並びに両社の沿革 .................................... 13（１）MHFG の概要 ............................................................ 13（２）MHBK の概要 ............................................................ 14（３）MHFG 及び MHBK の沿革 ................................................... 14２

本障害に関係するグループ会社の概要 ...................................... 15（１）MHRT の概要 ............................................................ 16（２）MIDS の概要 ............................................................ 16
３

内部統制 ............................................................... 17（１）MHFG、MHBK、MHRT 及び MIDS の相互関係 ................................... 17（２）本システムに関連する組織............................................... 17ア

MHFG 等グループ各社のシステムに関する組織体制 ......................... 17（ア）MHFG について ........................................................ 17（イ）MHBK について ........................................................ 18（ウ）MHRT について ........................................................ 19（エ）MIDS について ........................................................ 19
イ グループ全体及び MHBK におけるシステムリスクの管理方法 ................. 19
ウ

MHFG 等における内部監査 ............................................... 20（３）緊急事態発生に備えた体制と有事対応の流れ ............................... 20
3

ア

緊急事態発生に備えた体制について ...................................... 20（ア）MHFG の体制 .......................................................... 20（イ）MHBK の体制 .......................................................... 21
イ 緊急事態発生後の有事対応の流れについて ................................ 21（ア）緊急事態等の発生可能性が認識された段階 ............................... 21（イ）緊急事態等への移行後、非常対策 PT 等が設置されるまでの段階 ............ 22（ウ）非常対策 PT の設置とその後の対応 ...................................... 26
第３ 本システムの概要........................................................ 26
１

MINORI 開発の経緯 ....................................................... 26

２

MINORI の仕組み ......................................................... 27（１）MINORI の設計思想 ...................................................... 27（２）MINORI を基盤とする本システムの構成要素 ................................ 28（３）具体的な取引における本システムの動作 ................................... 29
３ 本システムの運用・保守体制.............................................. 31（１）システム運用・保守に関する契約......................................... 31（２）システム運用・保守に係る人的体制 ....................................... 32（３）エラー検知がなされた場合の手順......................................... 32
４ 顧客取引における ATM 及びダイレクトの取引チャネルとしての意義 ............ 33
第４ 本障害の事実概要及び原因................................................ 33１

2 月 28 日障害 ........................................................... 33（１）事実概要 .............................................................. 33
ア 障害の発生状況........................................................ 33（ア）障害の概要........................................................... 33（イ）障害発生、障害影響及びシステム復旧対応等の全体推移 ................... 36（ウ）障害発生機序の詳細................................................... 42ⅰ

取消情報管理テーブルの INDEX FILE 容量超過 ........................... 42

ⅱ

二重エラー及び CIF 排他の解除不可 .................................... 43ⅲ

ATM 処理区画及びダイレクト処理区画の閉塞 ............................ 45

ⅳ

通帳・カードの取込み................................................ 46

イ

障害発生後の状況...................................................... 47（ア）システムの復旧に向けた対応状況 ....................................... 47ⅰ

エラーメッセージの監視・連絡体制 .................................... 47ⅱ

エラーメッセージについての具体的な取扱い状況 ........................ 50

ⅲ

取引サービス禁止機能に係る作動条件の緩和 ............................ 51（イ）顧客への障害影響及び対応状況 ......................................... 54ⅰ

顧客に及んだ影響.................................................... 54
4

ⅱ

事業継続管理統括部門による対応 ...................................... 56

ⅲ

ATM に関する顧客対応（事務企画部及び BCSOL） ......................... 57

ⅳ

ATM に関する顧客対応（RB 部門） ...................................... 59ⅴ

コールセンター等における顧客対応（個人マーケティング推進部） ........ 60ⅵ

広報対応（CC 部） ................................................... 62

ⅶ

顧客に負担を掛けたこと.............................................. 63（２）原因 .................................................................. 64
ア

障害の発生について.................................................... 64（ア）取消情報管理テーブルの INDEX FILE の「厳密なキャパシティ管理の必要性」に係る認識の欠如、連携の不足............................................. 64（イ）エラー設計の不備及び MINORI 構築時の障害回復テストでのリスク洗出しの不足.................................................................... 67（ウ）e-口座一括切替処理のスケジュール決定におけるリスク認識の不足 ......... 68（エ）MHRT による予兆の見逃し .............................................. 68（オ）ATM の「通帳・カード取込み」範囲を縮小する仕様変更の遅れ ............. 69

イⅰ2018 年 6 月のシステム障害による通帳・カード取込み ................... 69

ⅱ

2019 年 12 月のシステム障害による通帳・カード取込み .................. 70

ⅲ

その他の「通帳・カード取込み」事象及びこれに関連する外部の動き ...... 70

障害発生後のシステム復旧遅延及び顧客影響の拡大について ................. 71（ア）システム対応関係..................................................... 71ⅰ

システム運用上の問題................................................ 73

ⅱ

システムリスクへの対応体制の問題 .................................... 76（イ）顧客対応関係......................................................... 76ⅰ

2 月 28 日障害による顧客影響の想定・認識の甘さ ....................... 76

ⅱ

休日の ATM 障害に対する顧客保護の備えの薄さ .......................... 81ⅲ

顧客の待ち時間を短くする措置の遅れ .................................. 84

ⅳ

通帳・カード取込みを防ぐ措置の遅れ .................................. 86（ウ）組織全体関係......................................................... 86ⅰ

システム担当部署と顧客対応部門が連携して情報共有し、各自主体的・積極的に対応する姿勢の不足.................................................. 86ⅱ

システム障害に係る情報を一元的に集約・分析して対策を立案・実施する危機管理体制の弱さ........................................................ 87ⅲ
ウ

初動対応における 2 月 28 日障害影響の過小評価 ......................... 88
上記ア及びイに通じる構築後の MINORI 運用管理体制の脆弱化 ............... 89

２ 3 月 3 日障害 ............................................................ 90（１）事実概要 .............................................................. 905ア障害の発生状況........................................................ 90

イ

障害発生後の状況...................................................... 91（ア）システムの復旧に向けた対応状況 ....................................... 91（イ）顧客への障害影響及び対応状況 ......................................... 91（２）原因 .................................................................. 92
ア

障害の発生について.................................................... 92

イ

障害発生後のシステム復旧遅延及び顧客影響の拡大について ................ 93（ア）システム対応関係..................................................... 93（イ）顧客対応関係......................................................... 93３

3 月 7 日障害 ............................................................ 94（１）事実概要 .............................................................. 94
ア 障害の発生状況........................................................ 94
イ 障害発生後の状況...................................................... 97（ア）システムの復旧状況................................................... 97（イ）顧客への対応状況..................................................... 97（２）原因 .................................................................. 98
ア

障害の発生について.................................................... 98（ア）各工程におけるミスの看過............................................. 98（イ）IT マネジメントの観点 ................................................ 98
イ 障害発生後のシステム復旧遅延及び顧客影響の拡大について ................ 99
４

3 月 12 日障害 ........................................................... 99（１）事実概要 .............................................................. 99
ア 障害の発生状況........................................................ 99（ア）ストレージ装置の故障................................................. 99（イ）センター集中記帳処理遅延（外為システムの送金等処理遅延を除く。
） ..... 101（ウ）外為システムの送金等処理遅延 ........................................ 102
イ 障害発生後の状況..................................................... 102（ア）システムの復旧に向けた対応状況 ...................................... 102ⅰ

ストレージ装置及び統合ファイル授受の復旧 ........................... 102

ⅱ

外為システムにおける処理の復旧対応 ................................. 103（イ）顧客への障害影響及び対応状況 ........................................ 110（２）原因 ................................................................. 111
ア障害の発生について................................................... 111

イ 障害発生後のシステム復旧遅延及び顧客影響の拡大について ............... 111（ア）システム対応関係.................................................... 111ⅰ

復旧手順の準備不足................................................. 111
6

ⅱ

復旧対応の誤り..................................................... 111ⅲ

サービス契約における復旧時間に関する合意欠如 ....................... 112

ⅳ

人材育成及び配置並びに訓練等に関する問題 ........................... 113（イ）顧客対応関係........................................................ 113
第５ デジタルフォレンジック調査等の結果概要 ................................. 114
１ デジタルフォレンジック調査について ..................................... 114
２ アンケート調査及びホットラインについて ................................. 114
第６ 過去の障害事例の概要................................................... 116
１

2002 年及び 2011 年のシステム障害とそれらへの対応 ....................... 116（１）2002 年のシステム障害の概要 ........................................... 116（２）2011 年のシステム障害の概要 ........................................... 117（３）上記システム障害に対する再発防止策 .................................... 118
ア2002 年のシステム障害の原因とそれへの対応 ............................ 118イ

2011 年のシステム障害の原因とそれへの対応 ............................ 119

２

その他のシステム障害等................................................. 121（１）2016 年 2 月のシステム障害 ............................................. 121（２）2018 年 6 月のシステム障害 ............................................. 121（３）2018 年 7 月から 2020 年 7 月までの期間における通帳・カードの取込み ...... 122（４）2019 年 12 月のシステム障害 ............................................ 122
３

本障害との共通項の分析................................................. 122（１）過去にとられたシステム障害の再発防止策の評価 .......................... 122（２）過去事例と本障害の共通項.............................................. 122
ア

ソフトウェア及び事前のテストの問題 ................................... 122

イ 事後対応の問題....................................................... 123
ウ システム障害発生時に通帳・カードを取り込む ATM の仕様 ................. 123
エ 月末の繁忙日のシステム上リスクのある行為の実行 ....................... 124
オ まとめ .............................................................. 124
第７ 原因の総括 ............................................................ 124
１ 「危機事象に対応する組織力」に係る課題 ................................. 124
２ 「IT システム統制力」に係る課題 ........................................ 125（１）IT 人材の再配置問題について ........................................... 126（２）システム安定稼働への備えについて ...................................... 126（３）過去に発生した障害の原因との共通項について ............................ 127
３「顧客目線」に係る課題................................................. 127（１）ATM の通帳・カード取込み仕様に係る問題意識について .................... 127（２）障害対応における顧客利益への配慮について .............................. 128
7

（３）ATM 利用顧客への関心について .......................................... 128
４「企業風土」に係る課題................................................. 128

第８ MHFG 及び MHBK 策定の再発防止策の評価及び提言 ........................... 130
１

MHFG 及び MHBK 策定の再発防止策の概要及びその評価 ....................... 130（１）システムに関する再発防止策について .................................... 131
ア

概要 ................................................................ 131

イ

評価 ................................................................ 132（２）顧客対応・危機管理に関する再発防止策について .......................... 134
ア

概要 ................................................................ 134

イ

評価 ................................................................ 134（３）組織・カルチャーに関する再発防止策について ............................ 134
ア

概要 ................................................................ 134

イ

評価 ................................................................ 135

２

再発防止策実施に係る提言............................................... 135

第９ 結語 .................................................................. 135
別紙１ 委員略歴 ............................................................ 137
別紙２ 用語の定義 .......................................................... 139
別紙３ MHFG グループ事業系統図 .............................................. 151
別紙４ MHFG 組織図（2021 年 4 月 1 日現在） .................................... 152
別紙５ MHBK 組織図（2021 年 5 月 31 日現在） ................................... 153
別紙６ MHRT 組織図（2021 年 4 月 1 日現在） .................................... 154
別紙７ MIDS 組織図（2021 年 4 月 1 日現在） .................................... 155
別紙８ 取引チャネル別取引件数・取引金額 ..................................... 156
別紙９ 障害発生の可能性を減少させるために考慮に値する事項 ................... 157
別紙 10 顧客への影響の極小化・局所化のために考慮に値する事項 ................ 161
別紙 11 顧客対応に関する再発防止策の実施に際しての留意点 .................... 167

8

第１
１

調査の概要
委員会の設置経緯2021 年 2 月 28 日から同年 3 月 12 日にかけて、MHFG（略語・用語等については別紙 2 の用語の定義を参照。以下同じ。
）の子会社である MHBK において本障害が発生し、その結果、ATM が利用不能になる、顧客の通帳・カードが ATM の内部にとどまったまま、長時間にわた
り顧客に返還がなされないなど、顧客に多大な影響を与えたこと、2002 年及び 2011 年にもシステムに起因する大規模障害が発生していたことなどを踏まえ、MHFG は、本障害について、再発防止・信頼回復のために原因を究明し、再発防止策を策定することとした。
そこで、MHFG は、MHFG 及び MHBK と利害関係を有しない外部の有識者・専門家により構成される外部調査委員会を設置し、中立・公正な立場から、原因究明並びに MHFG 及び MHBK が策定した再発防止策の妥当性評価・提言を受けることとし、2021 年 3 月 17 日に外部調査委
員会委員長を、同月 22 日にその他委員を各選任し、本委員会を設置した。
２

調査の目的

本調査の目的は、中立・公正な立場から、①本障害に関する事実確認及び原因究明、②MHBK策定の再発防止策の妥当性の評価及び提言、③MHFG における本障害への対応状況の課題究明、並びに④MHFG 策定の再発防止策の妥当性の評価及び提言、を行うことにある。
本委員会は、本障害に関連する法人及び個人である関係者（本システムの外部委託先を含む。
）の法的責任や MHFG 等の経営陣の経営責任の有無・内容を追及し、認定することを目的とするものではない。
３

本委員会の構成及び調査体制

本委員会の構成は下記のとおりである。
委員長 岩村 修二（弁護士、T&K 法律事務所）
委員 鵜瀞 惠子（学校法人東洋学園、元公正取引委員会経済取引局長）

委 員 西川 清二（元株式会社 NTT ドコモ常務執行役員 CIO 情報システム部長）
委員 角谷 直紀（弁護士、T&K 法律事務所）

上記各委員は、日弁連ガイドラインに準拠して選任され、いずれもこれまで MHFG 及び MHBKとの間に利害関係を有しておらず、MHFG 及び MHBK の株式も保有していない。
各委員の略歴は別紙 1 のとおりである。また、本委員会は、下記の弁護士を選任し本調査の補助をさせた。いずれの補助者も MHFG 及び MHBK との間に、本調査及び本障害に関する利害関係を有していない。
なお、T&K 法律事務所及び長島・大野・常松法律事務所に所属する弁護士等であって下記調査補助者以外の者も、MHFG 及び MHBK との間に、本調査及び本障害に関する利害関係を有しておらず、また、当該弁護士等と下記調査補助者との間には厳格な情報障壁措置が採られ、本委員会に係る情報が当該弁護士等に開示されることがないことを確認した。したがって、
9下記調査補助者の独立性に問題はないと考えられる。
（T&K 法律事務所 弁護士）
戸澤晃広

道垣内正人

鈴木佑脩

良田郁也

根鈴久志

中村壮志

曽羽達貴

古

瀬高嗣 平澤遼大 増井瑞希
（長島・大野・常松法律事務所 弁護士）
井上聡

梅澤拓

深水大輔

福原あゆみ

工藤靖

高山徹

勝伸幸

勝俣安登武

内藤卓未 朝日優宇 大野仁寛 入山稜平 渡辺聡太郎
本委員会は、システムに精通したドコモ・システムズ株式会社を選任し、システム関係の専門的な知見・経験を基に主に本障害の直接的な原因に関する調査補助をさせた。同社において現に調査補助に従事した者は下記のとおりである。なお、同社及び下記従事者はいずれも MHFG 及び MHBK との間に利害関係を有していない。
長谷川正之 齋木守通 小倉勉 小金沢寛之 櫻井達也
加えて本委員会は、銀行業の IT システムに精通したアクセンチュア株式会社を選任し、本委員会が行うシステムに係る原因分析（及び再発防止策の在り方の検討）につき、側面から専門的知見に基づく助言や指摘を受けた。同社において現に調査補助に従事した主な者
は下記のとおりである。同調査補助者は、MHFG 及び MHBK との間に本調査及び本障害に関する利害関係がないことを確認した。また、アクセンチュア株式会社に所属する役職員であって同調査補助者以外の者と同調査補助者との間には厳格な情報障壁措置が採られ、本委員会に係る情報が当該役職員らに開示されることがないことを確認した。したがって、同調査補助者の独立性に問題はないと考えられる。
相原寛史 谷岡真 松濤真人
本委員会は、下記第 1・7・
（3）
「デジタルフォレンジック調査」及び同（4）「アンケート調査」の実施に当たり、KPMG FAS に所属する専門家 19 名を選任し、デジタルフォレンジッ
ク及びアンケート調査業務の補助をさせた。同調査補助者は、MHFG 及び MHBK との間に本調査及び本障害に関する利害関係がないことを確認した。また、KPMG FAS に所属する役職員であって同調査補助者以外の者と同調査補助者との間には厳格な情報障壁措置が採られ、本委員会に係る情報が当該役職員らに開示されることがないことを確認した。したがって、
同調査補助者の独立性に問題はないと考えられる。

10

４

本委員会の独立性

本委員会の運営は、日弁連ガイドラインに全ての点において準拠するものではないものの、その趣旨を踏まえ、独立性を確保しつつ実効性のある調査を実施するため、以下の事項
を MHFG と合意し、本調査の実施に際し、いずれも遵守された。
①

MHFG は、本調査において、本委員会の活動に全面的に協力し、自ら又は MHBK 等の役職員が保有する情報への本委員会のアクセスを確保するとともに、同役職員に対し本委員会への優先的な協力を業務として命令し、また、子会社に対して、本調査への優先的な協力を要請すること。
② 調査報告書の起案権は本委員会に専属すること。
③

本委員会は、本調査の過程で本委員会が収集した情報及び資料等についての処分権を専有し、当該情報及び資料等を MHFG に開示しないことができること。
５

本委員会 MHFG 事務局

本委員会は、本調査の効率的な実施のため、MHFG が従業員 9 名をもって臨時に構成した「MHFG 事務局」に対し、本調査に関係する資料及びデータの収集・整理、並びにヒアリン
グ対象者との連絡・日程調整その他の事務を要請した。
本委員会は、MHFG に対し、本調査の過程で上記「MHFG 事務局」又はヒアリングの対象者が知ることとなった調査状況等に係る情報を、本委員会の要請又は同意がない限り、他のMHFG 又は MHBK の役職員を含む第三者に開示しないこと、及び上記「MHFG 事務局」及びヒア
リング対象者に対し開示するよう求めないことを要請し、MHFG はこれに同意した。
本調査及び本報告書の作成に関し、上記「MHFG 事務局」を含む MHFG の役職員は、本委員会の独立性を一貫して尊重し、本委員会の調査に全面的に協力しており、これを妨げるような行為は認められなかった。
６

調査期間

本調査の期間は、2021 年 3 月 22 日から同年 6 月 15 日までである。
７

調査の方法・範囲

本委員会は、以下のとおり、各種関係資料等を検討・分析するとともに、関係者のヒアリングを行うなどの調査を実施した。
なお、本調査による情報収集の対象となる期間は、本障害の影響については 2021 年 2 月
28 日から同年 3 月 15 日（本障害が終息したと判断される日）まで、本障害発生後の MHFG
及び MHBK の対応については同年 3 月 31 日（）

までとした。

11

（１）関係資料の精査
本委員会は、本調査に当たり、先行して MHFG 及び MHBK が実施していた本障害に関する社
内調査において収集された資料の提供を受けたほか、ベンダーとの契約書類、システムに関する監査報告書、MHFG 及び MHBK の組織図、社内規程、金融庁への報告資料、各会議体等の議事録、本障害に関係するシステムに関する資料、内部統制に関する資料、その他本委員会が本調査の目的のため必要と判断した資料等を幅広く収集し、その内容を精査した。
（２）ヒアリング及び現地調査
本委員会は、2021 年 3 月 30 日から同年 6 月 11 日までに、MHFG 及び MHBK の役職員を始め、必要に応じて業務委託先である MHRT1、MIDS 等の関係会社の役職員等合計 116 人に対して合計 282 回のヒアリングを実施した。
また、本委員会は、本システムを管理する MHBK のデータセンターA、ATM センター（東京）、MHRT の品川シーサイド事務所及び MIDS の業務部署（上記データセンターA 内）について、現地を調査した。
（３）デジタルフォレンジック調査
本委員会は、MHFG、MHBK 及び MHRT の役職員合計 44 名についてデジタルフォレンジック調査を実施した。まず、これらの対象者が保有する電子メールをメールサーバ及び PC に保全し、これにキーワード検索を実施して抽出した合計 14,166 件について確認を行った。その結果、本障害に関連するものと判定された 753 件について、その内容を精査した。また、
うち 38 名については、携帯電話でやり取りされた電子メールのデジタルフォレンジック調査も実施し、本障害に関連するものと判定された 190 件についてその内容を精査した。
（４）アンケート調査
本委員会は、MHFG、MHBK 及び MHRT の役職員 557 名を対象に、本障害及びその対応に係る問題点等に関するアンケート調査を実施した。その際、「回答者の氏名等については本委員会限りとし、MHFG、MHBK 及び MHRT に開示しない」、「アンケート調査への回答により、回答
者が MHFG、MHBK 及び MHRT から不利益処分を科されることはないとの MHFG の確認を得ている」旨を周知した。結果、対象者中 534 名から回答を得て、その内容を分析した。
（５）ホットラインの設置及び申告への対応
本委員会は、2021 年 4 月 15 日から同月 30 日までの間、MHFG、MHBK、MHRT 及び MIDS の全役職員を対象として、本障害に関連する情報の申告を要請するために本委員会直結のホットラインを設置した。その際、「ホットラインへの申告者の氏名等については本委員会限り

1

下記のとおり、本障害発生当時は MHIR であったが、その後 MHRT に商号変更している。

12

とし、MHFG、MHBK、MHRT 及び MIDS に開示しない」、「ホットラインへの申告により、申告者が MHFG、MHBK、MHRT 及び MIDS から不利益処分を科されることはないとの MHFG の確認を得ている」旨を周知した。結果、上記期間中 39 件の申告を得て、本委員会が必要であると認めたものについて精査した。
（６）その他の調査
本委員会は、2 月 28 日障害について発生当日の対応状況を精査するため、主に顧客対応
部門の役職員 64 名に対し、各人の当日の対応等について文書で報告を求めた。また、MHBKで把握している情報を基に、本障害（特に 2 月 28 日障害）につき顧客から MHBK が受領した苦情、相談等及び各営業部店でとった対応等を把握・分析した。
８

委員会の会議開催状況

本委員会は、2021 年 3 月 22 日の本委員会発足日から、同年 6 月 14 日まで、合計 12 回開催した。本委員会には、委員及び必要に応じて調査補助者のみが出席し、MHFG 及び MHBK の役職員は、上記「MHFG 事務局」を含め出席していない。
９

本調査の前提と限界

本委員会は、本報告書及び本委員会の調査結果が、上記第 1・2 の目的以外の目的のために用いられることを予定しておらず、MHFG からの委託の範囲内において MHFG に対し負う責務のほかには、何らの責任を負うものではない。
また、本調査及び本報告書については、①限られた日時及び人的体制等の条件の下で実施された強制権限のない任意の調査であり、関係者のヒアリング及び資料等の収集は、MHFG 及
び MHBK 等の任意の協力を得ることができた範囲に限り実施されたものであるため、本委員会がアクセスできなかった資料又は事実の中に重要な点が存在し、本報告書に反映されておらず、結果、本報告書における事実認定や評価に変更が生じる可能性があること、②本報告書の技術的な事項に関する記載の一部は、セキュリティ等の観点から、必要に応じ簡略化したものとなっていること、③本報告書の技術的又は専門的な用語や説明は、MHFG 及びそのグループ会社内部のみで用いられる用語法等であっても、特に重大な支障がない限りそのまま用いている場合があること、に各留意されたい。
第２１

組織、事業内容及び内部統制
MHFG 及び MHBK の概要並びに両社の沿革（１）MHFG の概要
MHFG の会社概要は、以下のとおりである。
会社名

株式会社みずほフィナンシャルグループ

代表者の役職氏名

執行役社長 坂井 辰史
13本店所在地東京都千代田区大手町一丁目 5 番 5 号

設立年月日

2003 年 1 月 8 日

資本金2,256,767 百万円（2021 年 3 月 31 日現在）

従業員数

[MHFG の従業員数]
1,949 名（2021 年 3 月 31 日現在）
[連結会社における従業員数]
54,492 名（2021 年 3 月 31 日現在）

事業内容

銀行持株会社として、銀行持株会社、銀行、証券専門会社、その他
銀行法により子会社とすることができる会社の経営管理及びこれに附帯する業務、その他銀行法により銀行持株会社が営むことのできる業務を行うことを事業目的とし、グループの経営効率の向上と事業分野、機能面における特色・強みの結合を実現するために必要な経営管理等を行っている。

（２）MHBK の概要
MHBK の会社概要は、以下のとおりである。
会社名

株式会社みずほ銀行

代表者の役職氏名

取締役頭取 藤原 弘治

本店所在地

東京都千代田区大手町一丁目 5 番 5 号

設立年月日

1923 年 5 月 7 日

発足年月日

2013 年 7 月 1 日

資本金1,404,065 百万円（2021 年 3 月 31 日現在）

従業員数

27,659 名（2021 年 3 月 31 日現在）

事業内容

預金業務、貸出業務、商品有価証券売買業務、有価証券投資業務、内国為替業務、外国為替業務、社債受託及び登録業務並びに附帯業
務を主な業務の内容とする。

国内ネットワーク464 拠点（本支店及び出張所等）（2020 年 6 月 30 日現在）

海外ネットワーク

86 拠点（支店、出張所、駐在員事務所及び海外現地法人）（2020 年6 月 30 日現在）

（３）MHFG 及び MHBK の沿革
1999 年 12 月

旧 3 行による全面的統合に関する契約の締結

2000 年 9 月

旧 3 行が株式移転によりみずほホールディングス設立、
勘定系基幹システムとしては、STEPS（第一勧業銀行）、TOP（富士銀行）
ITIS（後に「C-Base」に改称）（日本興業銀行）が併存

14

2002 年 4 月

会社分割及び合併により、旧 3 行を MHBK、MHCB に統合・再編

2003 年 1 月

みずほホールディングスの出資により MHFG を設立

2003 年 3 月

MHFG がみずほホールディングスと株式交換を行うことにより同会社を直接子会社化するとともに、MHTB 等を直接子会社化するなど、MHFG が主要
グループ会社に対して直接的な経営管理を行う体制を整備するなどの「事業再構築」を実施

2005 年

2004 年 12 月までに TOP を STEPS に統合し、その時点での勘定系基幹シ
ステムは、STEPS（MHBK）、C-Base（MHCB）及び BEST（MHTB）が併存

2013 年 4 月

MHFG の連結対象子会社であったみずほ証券を MHFG の直接出資子会社とし、銀行・信託・証券その他の主要グループ会社を持株会社の直下に設置する新たなグループ資本ストラクチャーに移行

2013 年 7 月

MHCB が、MHBK を吸収合併し、商号を「株式会社みずほ銀行」に変更

2014 年 6 月

MHFG が委員会設置会社（現在の指名委員会等設置会社）へ移行

2017 年 6 月

MHBK、MHTB、みずほ証券は、監査等委員会設置会社に移行

2018 年～2019

勘定系基幹システムとして C-Base を 2018 年 7 月に、STEPS を 2018 年 9年月から 2019 年 2 月にかけて、BEST を 2019 年 7 月にそれぞれ MINORI に移行

２

本障害に関係するグループ会社の概要

MHBK は、主にシステム開発、保守業務を MHRT に委託し、MHRT からベンダーに再委託する
ことにより MINORI に係るシステム開発、保守を行っている。また、MHBK は、システム監視業務等のシステム運用業務を MIDS に委託することにより MINORI の運用を行っており、
MHBK・MIDS 間の運用に係る「システム受託サービス契約書」において、監視上のエラーメ
ッセージの伝達先は「関連部署」とされている。当該契約書における運用（監視）に係る具体的な作業手順を記載した手順書である運用マニュアルに基づき、上記「関連部署」として
MHRT 各部署（IT インフラ第 1 部、第 1 事業部第 1 部、プロジェクト企画部等）がエラーメ
ッセージの伝達先に指定されている。これは、MHBK・MHRT 間の「業務委託基本契約書」及びこれに基づく各個別の業務委託契約の締結により、「関連部署」となる MHRT の各部署が保守（維持・メンテナンス）業務の委託先となっていることによる。MIDS と MHRT との間に直接的な契約関係はないが、MHRT の各部署が、MHBK・MIDS 間の「システム受託サービス契約書」
上の「関連部署」となっていることにより、MIDS は MHBK に対して負担する当該契約書上の義務として MHRT に対しエラーメッセージを伝達する義務を負っている。そして、具体的な障害復旧対応においては、MHBK からの障害復旧対応を含む保守業務の受託者たる MHRT が、
MIDS と連携し、また、MHBK から MHRT に対する指示に基づき、MIDS に対して確認・指示等を実施して対応にあたることとなっている。

15

（１）MHRT の概要
MHRT の会社概要は、以下のとおりである。
会社名

みずほリサーチ＆テクノロジーズ株式会社（旧商号：みずほ情報総研株式会社）

代表者の役職氏名

代表取締役社長 大塚 雅広

本店所在地

東京都千代田区神田錦町二丁目 3 番地

設立年月日

1970 年 5 月 11 日

資本金1,627.5 百万円（2021 年 4 月 1 日現在）

株主

MHFG（100％）

従業員数

4,605 名（2021 年 4 月 1 日現在）

事業内容

調査・研究事業、コンサルティング事業、システム開発事業

沿革
1970 年 5 月

株式会社芙蓉情報センター設立

1989 年 10 月

（旧）株式会社富士総合研究所、株式会社富士銀コンピューターサ
ービスを株式会社芙蓉情報センターが吸収合併し、株式会社富士総合研究所に商号変更

2004 年 10 月

株式会社富士総合研究所が株式会社第一勧銀情報システム及び興銀システム開発株式会社を吸収合併し、MHIR に商号変更

2021 年 4 月

MHIR がみずほ総合研究所株式会社を吸収合併し、MHRT に商号変更2（２）MIDS の概要
MIDS の会社概要は、以下のとおりである。
会社名

MI デジタルサービス株式会社

代表者の役職氏名

代表取締役社長 藤原 一夫

本店所在地

東京都中央区日本橋箱崎町 19 番 21 号

設立年月日

1985 年 6 月 24 日

資本金

20 百万円（2021 年 3 月 31 日現在）

株主

日本 IBM（65％）
、MHFG（35％）

従業員数

846 名（2021 年 3 月 31 日現在）

事業内容

システム運用管理業務、IT サービス業務、運用基盤開発業務、新規業務領域の取組み（IT 技術・IT サービスに係る調査分析）

沿革21985 年 6 月

富士銀オペレーションサービス株式会社設立

2003 年 9 月

MHBK の完全子会社となり、MHOS に商号変更

本障害発生時点での商号は MHIR であったが、本報告書では、時点を問わず MHRT と呼称することとする。

16

2020 年 6 月

MHOS の発行済み株式の 65％を日本 IBM へ譲渡、MIDS に商号変更

2020 年 7 月

MIDS として事業開始

３

内部統制

（１）MHFG、MHBK、MHRT 及び MIDS の相互関係
いわゆる「みずほフィナンシャルグループ」は、持株会社 MHFG の下に MHBK を含む連結子会社 160 社及び持分法適用関連会社 28 社等で構成され、銀行業務、信託業務、証券業務、その他の金融サービスに係る業務を行っており、MHFG の下で、銀行・信託・証券等グルー
プ横断的な顧客セグメント別の戦略を策定・推進する 5 つのカンパニーとカンパニー横断的に機能を提供する 2 つのユニットを設置し、グループ運営を行っている。
MHFG は、グループのコーポレートガバナンスにおいて主体的な役割を果たしている。具
体的には、MHFG の取締役会を中心としたグループ全体の企業統治システムを構築するとともに、MHFG が定めるグループ経営管理規程及び各社との間で締結するグループ経営管理契
約等に基づき、主要グループ会社（MHBK、MHTB 及びみずほ証券の 3 社ほか、MHRT、MIDS 等
6 社の計 9 社が、MHFG が直接経営管理を行う主要グループ会社と位置づけられている。
）の経営管理を行っている。なお、MHFG の取締役会、指名委員会及び報酬委員会は、主要グループ会社のうち MHBK、MHTB 及びみずほ証券に対する経営管理として、これら各社の取締役の選解任、役付執行役員の選定及び解職等並びに取締役の個人別の報酬等の承認等を行っている。また、主要グループ会社以外の子会社等については、MHFG が定めた子会社等の経営管理に関する基準に従い主要グループ会社が経営管理を行っている。
MHFG グループ事業系統図は別紙 3 のとおりである。
（２）本システムに関連する組織
ア

MHFG 等グループ各社のシステムに関する組織体制（ア）MHFGについて
MHFG には、執行役社長の下に IT・システムグループが設置され、MHFG 全体の IT・システ
ムに関する事項を所管している。その中に、IT・システム企画部、IT・システム統括部、セキュリティ＆データマネジメント部の 3 部が設置されている。
IT・システム企画部は、IT 戦略及び IT 関連投資計画に関する事項並びに所管するグルー
プ会社の経営管理に関する事項を所管し、同企画部に設置されたシステムリスク管理室がシステムリスク管理に関する事項を取り扱っている。IT・システム統括部は、所管システム
及びグループ全体のシステム開発・管理に関する事項等を所管している。そして、セキュリ
ティ＆データマネジメント部は、経営管理、事業戦略等におけるデータ等の整備・活用に係る企画・推進・調整に関する事項やサイバーセキュリティに関する事項を所管している。また、IT･システムグループ長が、システムリスク管理の企画運営に関する事項を所管するとともに、IT･システム企画部において、システムリスクのモニタリング・報告と分析・提言
17等を担い、システムリスク管理に関する企画立案及び推進を行っている。
また、執行役社長の下に設置した経営政策委員会の一つである IT 戦略推進委員会では、
IT 戦略の基本方針や、IT 関連投資計画及びその運営方針、IT・システムのグループ一元化、
個別 IT 投資案件の方針、システムプロジェクト及び個別システム案件の管理、システムリ
スク管理、IT 関連投資案件の投資効果の評価等について、総合的に審議・調整等を行っている。
そのほか、オペレーショナルリスクの観点から、リスク管理グループが設置され、リスク管理グループ長がシステムリスクを含むオペレーショナルリスク管理の企画運営に関する事項を所管するとともに、同グループのリスク統括部において、オペレーショナルリスクのモニタリング・報告と分析・提言等を担い、オペレーショナルリスク管理に関する企画立案
及び推進を行っている。
上記に加え、経営政策委員会の一つであるリスク管理委員会において、執行役社長の下にオペレーショナルリスクを含むリスク管理に係る基本方針や運営・モニタリングに関する事項等につき、総合的に審議・調整等を行っている。MHFG の組織概要（MHFG 組織図）は別
紙 4 のとおりである。
（イ）MHBKについて
MHBK には、頭取の下に、IT・システムグループが設置され、その中に、IT・システム企画部以下 8 部が設置されている。具体的には、IT・システム企画部が IT 戦略・IT 関連投資計
画に関する事項を、同企画部に設置されたシステムリスク管理室がシステムリスク管理に関する事項を取り扱っている。また、IT・システム統括第一部及び IT・システム統括第二部がシステムの開発・管理に関する事項等を、IT サービス推進部がシステムの運用に関する事項をそれぞれ取り扱うとともに、IT サービス推進部は、複数のデータセンターを管理しており、システム運用業務に関する事項及び所管業務に係る運営・管理等に関する事項を取り扱っている。システムリスクの観点から、IT･システムグループ長が、システムリスク
管理の企画運営に関する事項を所管するとともに、IT・システムグループの IT･システム企
画部が、システムリスク管理に関する企画立案及び推進を行っている。また、頭取の下に設置した経営政策委員会の一つである IT 戦略推進委員会では、IT 戦略の基本方針や、IT 関
連投資計画及びその運営方針、IT 関連投資案件の投資方針・進捗管理・リリース・投資効
果の評価、システムリスク管理、特定の大型プロジェクト案件の実行計画等について、総合的に審議・調整等を行っている。
そのほか、頭取の下に、リスク管理グループが設置され、リスク管理グループ長がシステ
ムリスクを含むオペレーショナルリスク管理の企画運営に関する事項を所管するとともに、同グループのリスク統括部が、オペレーショナルリスクのモニタリング・報告と分析・提言等を担い、オペレーショナルリスク管理に関する企画立案及び推進を行っている。
上記に加え、頭取の下に設置した経営政策委員会の一つであるオペレーショナルリスク
18

管理委員会で、オペレーショナルリスク管理及びオペレーショナルリスク事象の再発防止策等に関する審議・調整を行っている。MHBK の組織概要（MHBK 組織図）は別紙 5 のとおりである。
（ウ）MHRTについて
MHRT には、社長の下に IT インフラ本部や、IT 開発本部、プロジェクトデザイン本部等が設置され、たとえば、IT インフラ本部の中には、第 1 部ないし第 4 部、IT サービス推進室
及びマイグレーション推進 PT が設置されている。MHRT の組織概要（MHRT 組織図）は別紙 6のとおりである。MHRT の 1.5 線はプロジェクトデザイン本部プロジェクト企画部、2 線はコーポレート部門のシステムリスク管理部（本障害発生時は品質管理部）が担っている。
（エ）MIDSについて
MIDS には、サービス事業部門副社長（COO）の下にサービス管理部、技術サービス推進部、システムサービス第 1 グループないし第 5 グループ及び業務サービスグループが設置されている。MIDS の組織概要（MIDS 組織図）は別紙 7 のとおりである。
イ

グループ全体及び MHBK におけるシステムリスクの管理方法

MHFG は、「総合リスク管理の基本方針」を制定し、リスク管理の基本的な方針を定めている。同基本方針では、業務上発生するリスクの一つとしてオペレーショナルリスクを挙げ、その一つとしてシステムリスクを挙げている。また、MHFG は「オペレーショナルリスク管理の基本方針」及び「システムリスク管理の基本方針」を定めて、管理を行うに当たっての基本的な方針を定めている。
このような基本方針に従い、MHFG は、主要グループ会社の管理を行い、併せて、MHFG 全
体のオペレーショナルリスク、システムリスクの状況をモニタリングし、管理することにより、グループ各社のシステムリスク管理やシステムリスクを含めたオペレーショナルリス
ク管理を統括している。
また、MHBK を含む主要グループ会社でも、「オペレーショナルリスク管理の基本方針」や「システムリスク管理の基本方針」を定め、オペレーショナルリスク、システムリスクを適切に把握・管理することとされている。具体的には、MHBK は、MHFG の「総合リスク管理の基本方針」、「オペレーショナルリスク管理の基本方針」及び「システムリスク管理の基本方針」を受けて、MHBK における「総合リスク管理の基本方針」、「オペレーショナルリスク管理の基本方針」及び「システムリスク管理の基本方針」を制定し、システムリスク管理を行うに当たっての基本的な方針を定めている。さらに、MHBK は、その「システムリスク管理の基本方針」を、より詳細に具体化するため、システム障害発生時の報告及びシステム障害
原因分析と予防・再発防止策の実施等についての管理体制や実務手順を定めた「システム障害管理運営要領」を制定し、システム障害発生時にはこれに従い対応することとされている。
19

ウ

MHFG 等における内部監査

MHFG は、内部監査について、取締役会が承認した計画等に基づき、被監査部門・業務から独立した立場で、ガバナンス、リスクマネジメント及びコントロールに係る各プロセスの有効性・適切性を客観的・総合的に評価し、課題解決のための改善提言・是正勧告等まで実施する一連の活動として位置づけている。
このような基本的な考え方のもと、MHFG は、執行役社長が委員長を務める業務監査委員会を設置している。同委員会は、取締役会で定める基本方針に基づき、内部監査に関する重要な事項の審議・決定を行い、同委員会の決議事項及び重要報告事項は、MHFG の監査委員
会及び取締役会に報告される。なお、内部監査機能の被監査業務からの独立性確保を目的として、内部監査グループを被監査部門から分離の上、業務監査委員会傘下の独立部門とし、MHFG の監査委員会に報告し指示を受ける体制としている。MHFG の内部監査の具体的な手続
は、MHFG の「内部監査の基本方針」、「内部監査の基本方針細則」、「内部監査の実施に関する基準」及び「内部監査運営要領」に規定されている。
また、MHBK においても、業務部門から独立した業務監査委員会を設置して、内部監査グ
ループの独立性を確保し、MHBK の監査等委員会に報告し指示を受ける体制とするとともに、業務監査部を設置して、国内外営業拠点・本部各部室・グループ会社等の内部監査を実施している。具体的には、コンプライアンスやリスク管理等に関する業務運営状況の適切性・有効性等を検証している。MHBK の内部監査の具体的な手続は、
MHBK の「内部監査の基本方針」、「内部監査の基本方針細則」、「内部監査の実施に関する基準」及び「内部監査運営要領」に規定されている。
このような体制の下、MINORI を含むシステム全般及び事業継続管理に関する監査も実施されている。近時では、MHFG において、グループ監査として、2018 年度に IT ガバナンス監
査、2019 年度に事業継続管理態勢監査、IT ガバナンス/IT マネジメント監査、2020 年度に
IT 全般統制監査が実施されている。また、MHBK において、2018 年度に IT ガバナンス態勢
監査、2019 年度にインフラ系システム監査、勘定系システム監査（預為、融外、業共）、IT
ガバナンス/IT マネジメント監査、2020 年度に IT 全般統制監査が実施されている。
（３）緊急事態発生に備えた体制と有事対応の流れ
ア

緊急事態発生に備えた体制について（ア）MHFGの体制
MHFG は、緊急事態発生時等における対応及び事業継続管理を行うに当たっての基本的な方針を定め3、主要グループ会社の事業継続管理を一元的に把握・管理し、主要グループ会
社以外の子会社等の事業継続管理は、原則として主要グループ会社を通じて行うこととし

3

MHFG「事業継続管理の基本方針」、「事業継続管理の基本方針細則」及び「事業継続管理運営要領」。

20

ている。MHFG は、システム障害や大規模な地震等の緊急事態が発生した場合に備え、各緊急事態に応じた緊急時対応の行動計画（要因別行動計画）を定めることとし、行動計画が整備されている4。また、緊急事態の発生に備えて、継続すべき重要な業務について、業務影
響度、関連システム、初期対応、暫定対応、本格復旧時対応等を記載した、事業継続のための計画である BCP が整備されており5、インシデント判明後、関係部署はあらかじめ定めた
緊急時対応の行動計画（要因別行動計画）及び BCP 個票に基づいて事象に即した対応を行うことが規定されている。
（イ）MHBKの体制
MHBK は、緊急事態発生時等における対応及び事業継続管理を行うに当たっての基本的な方針を定め6、事業継続管理を行うに当たっての運営方法を定めている。具体的には、MHBK
は、緊急事態発生時等（コンピューターのハードウェア、ソフトウェアの故障等）に備えた
SCP を整備するための運営体制・運営方法及び SCP の発動権限を定め7、障害シナリオ、作業概要、所要時間及び作業時限等を定めた SCP を整備している。また、MHBK においても、システム障害や大規模な地震等の緊急事態の発生に備え、各緊急事態に応じた緊急時対応の行動計画（要因別行動計画）が定められており、所管部はそれぞれの役割や初動内容に応じて事象の共有・報告を実施することとされている8。
イ

緊急事態発生後の有事対応の流れについて（ア）緊急事態等の発生可能性が認識された段階
MHBK においては、緊急事態・非常事態に至る可能性が認識された場合（危機警戒フェー
ズ）、それがシステム障害に起因するときは、IT・システム企画部、IT・システム統括第一部等が事実確認、関係部署への連絡をし、企画管理部が各所管部からの報告を受け、集約し

4

MHFG「事業継続管理運営要領」に基づき策定される。
「ビジネスコンティンジェンシープラン運営要領」に基づき策定される。
6
MHBK「事業継続管理の基本方針」、「事業継続管理の基本方針細則」及び「事業継続管理運営要領」。主要
グループ会社のうち MHFG が特に指定する会社（MHBK を含む。
）は、MHFG「事業継続管理の基本方針」に基づき、個別に事業継続管理に係る基本方針を MHFG に申請の上定めることとされている。
7
MHBK「事業継続管理運営要領」、「システム・コンティンジェンシー・プラン運営手続」及び「システム・
コンティンジェンシー・プラン運営要領」。
8
MHBK では、「事業継続管理運営要領」にて緊急事態の発生状況に応じて、①予兆管理フェーズ、②危機警
戒フェーズ、③非常事態フェーズ、④緊急事態フェーズの 4 つの危機管理フェーズを定め、フェーズごとに必要に応じて会議体等を設置し、関係役員に報告する体制をとっている。各フェーズの会議体等は、①なし、②危機警戒対策会議、③非常対策 PT（PT 長：要因別に規定）、④緊急対策本部（本部長：頭取）とさ
れている。
5

21

た情報に関する対応策の検討を行うこととされている9。
（イ）緊急事態等への移行後、非常対策PT等が設置されるまでの段階
システム障害の発生により、緊急事態等に移行するとき、下記の非常対策 PT や緊急対策本部が設置されるまでの間の具体的な対応の在り方や役割分担等は、各緊急事態に応じた
緊急時対応の行動計画（要因別行動計画）のほか、その下位規程にあたる「システム障害対応の手引き」（2019 年 7 月改訂 MHBK 企画管理部）に定められている。
上記「システム障害対応の手引き」では、主に企画管理部危機管理室が、情報、影響分析
結果の取り纏め、関係部署の役割分担の調整、役員への報告協議総括を行うとされ、IT・シ
ステム企画部や IT・システム統括第一部はシステムの運用状況及び原因等、本格復旧に関する対応方針の検討状況等に関する情報収集と SCP 対応を行い、事務企画部その他の関係部署も、顧客対応に向けた情報収集や営業部店等への指示・連絡、BCP 対応等のあらかじめ定められた役割に応じて行動するものとされている。このような役割分担の下で、障害内容とその影響（対顧・行内）の把握及び共有を行い、障害発生システムの復旧や顧客対応のための各施策の立案・実施及び各役員への協議・報告を行うものとされている。上記「システム障害対応の手引き」では、障害対応の基本方針として、障害内容やその影響に関する情報の収集・集約・共有化が初動対応における最重要事項であるとされ、とりわけ、初動としてスピードを重視し、躊躇せず報告・共有、迷ったら集まることといった点が強調されている。
このようなシステム障害発生時の有事対応において、MHBK の IT・システム企画部や IT・
システム統括第一部により構成される IT・システムグループ並びに MHRT・MIDS を含む開発
部署・運用部署におけるシステム復旧対応体制（システム障害発生時における基本的な障害対応体制）及びその具体的な取組みは、「システム対策 PT 運営マニュアル」（2020 年 11 月
（第 5-10 版））に定められている。当該マニュアルによれば、SCP 発動者はシステム障害ラ
ンクに応じて、IT・システムグループ副担当役員・障害発生システム所管部長又は副部長・障害発生システム所管チーム次長が担当し、IT・システムグループ内の障害対策方針を決定するとされている。システム障害ランクについては、システム障害管理運営要領第 1 章第 2
節（1）に、下記図 1 のように定義されている。

9

MHBK「事業継続管理運営要領」14 条、15 条。なお、緊急事態とはコンピューターのハードウェア、ソフ
トウェアの故障等やオペレーションミス等の過失によるシステム障害その他の要因により「人命および施設等の安全が脅かされた場合、業務の遂行が困難になった場合、または当行グループの評価に重要な影響を及ぼすおそれがある場合をいう」と定義され（MHBK「事業継続管理の基本方針」3 条）、非常事態とは「緊急事態には至らないものの、経営に影響を及ぼす重要な事象が発生した場合」とされている（MHBK「事業継続管理運営要領」16 条）。

22

【図 1】
影響範囲
障害ランク

S

定義

経営に影響を

未
然
検
知

経
営

行
外

行
内

シス
テム
所管
部内

○

○

○

○

×

×

○

○

○

×

及ぼす障害。
又は、行外に重大な影響を及ぼす障害。

A

A1

行外に軽微かつ広範な影響を及ぼす障害※1。又は、行
内に重大な影響を及ぼす障害。

影響度合の具体例

・勘定系・決済系オンラインの全面ダウン、又はその一部サービス・機能（預金支払・為替送金）のダウン。
・決算等ディスクローズ内容あるいは当局報告
内容の大幅な修正が必要なもの。
・不特定多数の顧客に重大な迷惑をかけたもの。
（支払不能、残高相違、利息・手数料相違、誤送金）
・マスコミ報道されるもの。
・株価に影響を与えるようなもの。
・訴訟のおそれがあるもの。
・勘定系・決済系オンラインの一部サービス・機能（除く預金支払・為替送金）のダウン。
・勘定系・決済系オンラインに影響を与えない業
務系システムの全面ダウン。
・顧客・リスク（含、当局報告）に関係するシステムの全面ダウン。
・不特定多数の顧客に軽微な迷惑をかけたもの。
・特定の顧客に重大な迷惑をかけたもの。（多額の支払不能、残高相違、利息・手数料相違等）
・電子メールやグループウェア等社内インフラの長時間（例えば 3 時間以上）にわたる全面ダウン。
※1 以下に相当する場合は「A1 以上」とする－100 社・100 名以上の取引先・顧客の決済・資金繰りに支障をきたす場合
尚、影響した顧客数をログ等で特定できない場合は、顧客からの問合わせ件数で判定する。

A2

行外に軽微か

×

○

○

○

×

つ限定的な影響を及ぼす障・顧客・リスク（含む当局報告）以外の情報系システムの全面ダウン。
・特定の顧客に軽微な迷惑をかけたもの。
・電子メールやグループウェア等社内インフラの短時間（例えば 3 時間以内）の全面ダウン。
※2 行外／顧客に対して影響を及ぼした場合は、影響内容に拘らず「A2 以上」とする。
－1 社・1 名以上の取引先・顧客に影響が発生した場合※3 行内の業務影響にとどまる場合においても、以下に相当する場合は「A2 以上」とする。
－利用部門として、営業店（拠点数）の 50％以上、又は本部（部署数）の 50％以上の業務に影響を及ぼす場合－利用部門への影響が、営業店（拠点数）の 50％
未満、かつ本部（部署数）の 50％未満の場合であっても、重要な業務影響が発生した場合害※2。又は、行内に軽微かつ広範な影響を及ぼす障害
※3。

23

影響範囲
定義

障害ランク

B

行内に軽微か

未
然
検
知

経
営

行
外

行
内

シス
テム
所管
部内

×

×

○

○

×

×

×

×

○

○

つ限定的な影響を及ぼす障害C

行内外に影響がない障害。

影響度合の具体例

・勘定系・決済系オンラインに影響を与えない業
務系システムの一部ダウン。
・顧客・リスク（当局報告を含む。
）に関係する情報系システムの一部ダウン。
・顧客・リスク（当局報告を含む。
）以外の情報系システムの一部ダウン。
・電子メールやグループウェア等社内インフラの一部ダウン。
・顧客影響は無かったが、BCP を発動した場合。
・障害をユーザーが検知した場合。

・影響がシステム所管部内に止まった障害。
・障害が発生する前に机上で発見された潜在バグ。

尚、未然に発見された不良を含む。

障害ランクが流動的である際は原則として｢懸念｣を使用するものとされ、「●ランク懸念」とは下記の「障害報告メール」を発信する時点の最大影響を考慮したランクづけであり、その判定は（障害発生）システム所管部署が、必要に応じ関係部署と協議した上で、行うものとされている。
障害発生システム所管チーム次長又は SCP 発動者が指名する者は、障害対応責任者として、システム全体に関わる復旧の優先順位付け・復旧方法を検討し、関係部署等とも調整の上、障害対策案を SCP 発動者に提案し、SCP 発動者・企画管理部の指示に従い関係部署等へ指示を出すこととされている。さらに、障害対応責任者は障害発生検知後、速やかに当該要領に従い「障害報告メール」を発信することとされている。この「障害報告メール」では、経営陣を含む関係者に、業務影響内容、システム復旧目処等を報告することとされ、発生報
告（検知報告）、続報（経過報告）、復旧報告が含まれる。発信時期としては、障害発生・検知後速やかに（原則 1 時間以内を目処に）報告をするものとされ、報告先及び報告ルート
は、障害ランク別に下記図 2 のとおりとされている。
【図 2】
報告ルート（●は報告者、○は報告先）

24

システム所管

一部

報

報告時の暫定
障害ランク

シス

所管

チー

部署

部長

担当
役員

IT･シ

画部

テム

室･

ム

IT･システム企

ステ
ムグ

SR 室･
企画チ

部長

ルー
プ長

ーム

副頭
取
常務
監査

頭取

等委
員

S（含む懸念）

●

○

○

○

○

○

○

○

A1（含む懸念）

●

○

○

○

○

○

○

○

A2（含む懸念）

●

○

○

○

○

○

-

-

B（含む懸念）

●

○

-

○

○

-

-

-

また、この障害ランクに応じて、IT・システム企画部企画チーム次長又は（障害発生）シ
ステム所管チーム次長は、対外報告・連絡責任者として、企画管理部へ状況連絡・報告を行うとともに、同部からの指示を障害対応責任者へ連絡するなどの対応を行うものとされている。
MHRT の障害発生システム開発担当部長（事業部を跨る場合は障害発生元システムの事業部長が対応し、部長はこれを補佐する。
）は、複数システムに跨る影響調査、原因究明のとりまとめを行い、収集した情報を障害対応責任者に提供するとともに、障害対応責任者及び運用部署対応責任者（障害ランクに応じて MHBK/IT サービス推進部部長又は MHBK/IT サー
ビス推進部企画チーム次長）と協働し、障害対策の検討を行うこととされている10。運用部
署対応責任者は、データセンターにおけるシステム稼動状況を一元的に把握し、収集した情報を障害対応責任者に提供し、障害対応責任者と協働して障害対策のセンター運用への影
響確認を行うこととされている。
上記の「システム対策 PT 運営マニュアル」に基づく IT・システムグループその他関係部

10

MHRT は MHBK の「システム対策 PT 運営マニュアル」に基づき、MHBK からの指示に従い、早期にシステム
障害復旧を進めることを目的として「システム障害対策本部運営要領」を策定している。当該要領においては、MHBK からのシステム障害対策本部設置要請に基づいて MHRT は対応体制を発動するものとされている。また、システム障害対策本部は MHBK のシステム復旧対応体制と連携するものとされ、原則として障害発生システムを所管する部の部長及びその部長により指名されたメンバーから構成するとされているものの、障害発生システムが複数に跨る場合は、例外的に関係する本部長・事業部長間で協議の上、対応する部長を指名するものとされていた。なお、「システム障害対策本部運営要領」は 2021 年 4 月 30 日付で改定が行われ、「システム障害対策本部」は「システム障害対応本部」に名称変更が行われた。また、システム
障害対応本部の構成メンバーについて、上記メンバーに加え、統制責任者として MHRT プロジェクトデザイ
ン本部プロジェクト企画部部長が追加されている。

25

署及び MHRT・MIDS による対応体制（障害ランク：S（含む懸念））については、概ね、下記
図 3 のとおりとなっている。
【図 3】（ウ）非常対策PTの設置とその後の対応
このようなシステム障害発生時における有事対応が開始された後、MHBK「事業継続管理の基本方針」に基づく緊急対策本部の設置までには至らないものの、一定の要件11に該当する
場合には、非常対策 PT が設置される。原則として頭取が指名する非常対策 PT 長は、各種規程類の定めにかかわらず、当該非常対策に関して頭取から全権を委任され、情報収集や影響分析、対応方針の決定及び対策の実行指示、対外・対内広報、当局報告等に係る対応方針の決定等の措置を講じるものとされている12。
第３本システムの概要

１

MINORI 開発の経緯

MHFG は、2011 年に発生した大規模なシステム障害（下記第 6・1・（2））を受け、2011 年
5 月に発表した「信頼回復に向けた取り組みについて」の具体的な取組みの一つとして、システムの完全一元化（次期システムの構築）に着手した。具体的には、MHFG にて 2012 年 3月 30 日付で「基本計画」を策定し、①勘定系を主体にグループのシステムを一元化し新し

11①影響が大きく緊急かつ迅速に情報を確認し対応を行う必要がある場合又は②対応部室が多岐にわたり、情報の収集・発信、対応方針策定等を一元化して行う必要がある場合。
12
MHBK「事業継続管理の基本方針」9 条、10 条、11 条等。

26

い基盤の下で再構築すること、②システムプラットフォームの完全一元化の推進を行うこと、③信頼回復に向けた、安定性・堅確性のレベルアップを行うこと、を狙いとして MINORIの開発・移行を行った。
そして、2002 年の統合前から使用していたシステム（MHBK の STEPS、MHCB の C-Base、
MHTB の BEST）について、8 年超の年月及び総額 4,000 億円超の費用を投下し、2019 年 7 月に「MINORI」と称する新しい基幹システムへの移行を完了した。このような MINORI の開発・移行プロジェクトは、開発規模・参加した IT ベンダー数ともに過去に類を見ない大規模なものとされている。
２

MINORI の仕組み

（１）MINORI の設計思想
MINORI の設計思想は、概要以下のとおりである。
①

システムの完全一元化（勘定系システムの統合）②

SOA により、商品・サービス開発の機動性・効率性を向上③

顧客管理・業務管理のキーを取引部店単位から全部店共通の CIF 番号とし、店舗・店籍制約からの解放を実現④ 情報系システム基盤の構造変革により、経営管理・マーケティングに要求されるスピー
ド・データコンテンツへの対応力を向上⑤ シンプルな要件定義を目指した業務フロー標準化・簡素化の徹底追及と、システム間連携の向上と機能配置の最適化を通じた二重入力・チェック回避やペーパレス化等により、事務軽量化を実現⑥

システムの安定性・堅確性のレベルアップ－障害発生回避の観点
・大量処理時の異常終了回避（リミット値管理、処理仕様の改善等）－障害発生時の事後対応力強化の観点
・集中記帳処理のオンライン化によるオンライン・バッチ並行稼働の実現
・処理プロセスのシンプル化及び機能の独立性向上
2011 年の障害時に利用されていた従前の勘定系システムでは、求められる機能・役割の大部分が一つの基盤上に実装され、同時に、同種あるいは類似した機能が複数箇所で実装されているなど、長期間にわたり、2002 年の統合前のシステムを繋ぎ合わせて使用してきたことにより、システムの複雑化による保守性の低下、及び新サービス提供における対応力や効率性の低下を招いていた。そのことを反省点に、MINORI の開発・移行プロジェクトでは
MHBK、MHCB、及び MHTB のシステムを一元化することが狙いの一つとされた。
また、SOA の手法を取り入れ、「みずほ SOA」と呼ばれる構造が採用された。すなわち、従前の勘定系システムには、上記のような複雑化による保守性の低下、及び新サービス提供における対応力や効率性の低下という問題があったほか、顧客情報も統合されておらず、業務27

システムごとに分散保有されており、それらの整合性を維持するための機能も分散して配置されているという問題が存在した。それを解消するため、MINORI においては、アプリケ
ーションやその機能をサービス（取引サービス、商品サービスの 2 種類で構成される。）としてコンポーネント化し、必要な情報や必要な処理を整理された各サービスにて呼び出したり、実行したりする手法である SOA を採用することで、各コンポーネントの独立性が高い
疎結合の状態を実現し、修正・新規開発時の影響範囲の限定やプログラム部品の再利用を可能とするという目的があったとされている13。
【図 4】MINORI におけるみずほ SOA 構造のイメージ

この「みずほ SOA」を採用することにより、システムをサービス（部品）ごとに独立させることで、システム変更が生じた際の影響範囲を限定できるというメリットがあるとされ、MHFG では、SOA 手法の採用により、2011 年の障害のようなシステムの全面的なダウンが起きる前に、障害が発生しているサービス（部品）を切り離すなど、連鎖障害による影響範囲の拡大回避、為替発信機能等の独立化による決済業務停止リスク軽減、顧客取引データの保有機能の分担による特例払い対応のサポート強化、取引チャネル機能の独立化によるオン
ライン障害発生時のサービス停止範囲の縮小ができると考えられていた。
（２）MINORI を基盤とする本システムの構成要素

13

実際に、SOA の思想を取り入れるシステムは MINORI 以外の一般システムにも存在しており、SOA 自体は有意義な設計思想であると評価できる。

28

【図 5】本システムの構成図（イメージ）

MINORI は、主に、①取引の起点となる各取引チャネルからの通信を受信し、MINORI 内の各システムに接続するための機関であるメインハブ、②MINORI 内の各システムの全体的な動作や取引の流れを管理・制御する中心的機関である取引共通システム、③MINORI 内でのデータの授受を担う統合ファイル授受、④融資外為基盤、定期性基盤などの各種業務システ
ムから構成されている。
このうち、②の取引共通システム内には、②-1「各業務アプリケーション」（流動性預金等）のほか、②-2「取引メイン」、②-3「CIF」等のシステムが存在している。顧客が何らかの取引（たとえば、口座への入出金や残高照会等）を開始したり、MINORI 内において顧客に関する何らかの処理を行ったりする場合（たとえば、下記の e-口座一括切替処理等）には、各業務アプリケーション（流動性預金や定期性預金）が CIF に記録された顧客データを参照して処理を行う仕組みになっている。
（３）具体的な取引における本システムの動作
以上のような構成の本システムの具体的な取引時における動作の推移は、下記図 6 のとおりである。

29

【図 6】本システムの動作イメージ（下記①・②）

たとえば、①顧客が ATM で普通預金口座からの出金取引を行った場合、②顧客がダイレク
トで普通預金口座から定期預金口座への振替取引を行った場合を想定すると、システムの動作は以下のとおりとなる。
上記①の場合、まず、顧客が取引チャネルである ATM の画面で普通預金口座からの出金取引の操作を行うと、システム上は、ATM から処理要求（普通預金口座からの出金処理）が自動機サーバを経由し MINORI 本体に入力されることとなる。MINORI 本体内では、取引共通システム内の ATM 処理区画、取引メインを経由し、CIF にアクセスし、他の取引との競合による顧客情報の更新等の不整合が生じることを避けるため、当該出金取引が終了するまで CIF
排他と呼ばれる機能により、顧客情報を更新等ができない状態にし、固定化する。その後、流動性預金システムを通過し、出金の処理（残高を減少させる処理）がなされ、CIF に処理完了の情報が送信され、CIF 排他の状態が解除される。その後、取引メイン・ATM 処理区画・
自動機サーバを経由し、ATM に出金処理成功の情報が送信され、実際に ATM から現金が出金されることになる。
また、上記②の場合、顧客が取引チャネルであるダイレクトの画面を操作して普通預金口
座から定期預金口座への振替取引を行うと、ダイレクトから処理要求がダイレクトサーバ
を経由し MINORI 本体に入力されることとなる。MINORI 本体内では、メインハブを経由し、取引共通システム内のダイレクト処理区画、取引メインを経由し、CIF にアクセスし CIF 排他がなされる。その後、流動性預金システムを通過して普通預金の残高を減少させる処理がなされ、さらに定期性預金システムを通過して定期性預金の残高を増加させる処理がなされ、再度電文が CIF に戻ってきた後、CIF 排他の状態が解除される。その後、取引メイン・ダイレクト処理区画・ダイレクトサーバを経由し、ダイレクトに振替処理成功の画面が出力されることになる。
30

このように、本システムにおける取引は、本システムを構成する複数のシステムにて入力が処理され通過することにより行われる。本システムでは、このような処理要求の一連の流れを「トランザクション」と称し、特に上記のように、各システムに跨がって処理がなされる一連の流れを「グローバルトランザクション」と呼んでいる。
上記「グローバルトランザクション」及び MINORI が上記の SOA の手法を採用していることもあって、本システムが何らかの処理を行う場合、基本的には複数のシステムに跨がって情報の呼出しや処理がなされることとなる。
３

本システムの運用・保守体制（１）システム運用・保守に関する契約
MHBK は、MHRT との間の 2013 年 7 月 1 日付「業務委託基本契約書」に基づき、個別の業務
委託契約を締結することにより、システム開発のほかにシステム保守に係る業務も MHRT に委託している。システムの保守に関しては、システム・基盤別に、四半期ごとに個別の業務
委託契約を締結し、MHRT に対し、MINORI 及び周辺システムの保守（維持・メンテナンス）
業務を委託している。維持・メンテナンス業務の内容は、対象とするシステム・基盤ごとに異なるものの、基本的に、定型保守作業14、障害対応15、リソース監視16、予防保守17等が含まれる。MHRT は、上記の個別の業務委託契約の別表で特定したその他委託先に保守業務を再委託している。
また、MHFG 及び MHBK は、2020 年 6 月 19 日に、MIDS18との間で「受託サービス基本契約書」及び「システム受託サービス契約書」を締結し、MHBK は MIDS に対して具体的なサービ
ス対象システム、作業内容、手順及びサービスレベル等を定めた上で MINORI の運用（監視を含む。以下同じ。
）を委託している。当該契約において、運用業務の具体的な手順は、運用マニュアルに定められており、MHRT に対し所要のエラーメッセージの伝達等を行うこととされている。
MHBK のデータセンターは、平常時に実際に稼働するシステムが設置されているメインセ
ンターであるデータセンターA と、災害があった場合の予備のシステム等が設置されている
データセンターB が存在するところ、MIDS は、上記契約に基づき、データセンターA 及びデータセンターB 等において、MINORI の運用業務を行っている。

14

本番稼働確認、本番環境管理、設計・開発環境、不定期定型作業、セキュリティ対策、プログラム・資源管理、システムリスク評価、インベントリリスト（保有するシステムを記載した台帳・リスト）見直しなど。
15
障害対応統制、障害の調査、復旧対応、原因分析、再発防止策策定など。
16
システムを稼働させるための CPU（中央演算装置）、メモリ、データベース、ハードディスク等の各資源（リソース）の状態をモニタリングすること。
17
システムが容量超過を起こさないようにあらかじめ容量を増加させる、機器故障を予防するために定期的に機器を交換する等、情報システムに関連する機器やソフトウェア等をメンテナンスすること。
18
契約締結時点での商号は MHOS であったが、本報告書では、時点を問わず MIDS と呼称することとする。

31

（２）システム運用・保守に係る人的体制
MIDS は、MINORI 及び周辺システムの多くについてデータセンターA において運用を行っている。データセンターA においては、4 班にわかれ、監視員・オペレーターは常時 8 名で24 時間、MINORI の運用を行っている。MIDS は、データセンターA において、「システム監視業務」として MINORI 及び周辺システムの稼働状況の監視を実施し、検知したインシデントの判別、関係部署への当該インシデントの連絡、記録等、一連の作業を行い、必要に応じて対策会議へ参加する。上記監視については、MINORI 及び一部のその周辺システムについて、
リアルタイム監視を行う統合運用基盤システム等を利用している。
（３）エラー検知がなされた場合の手順
MIDS の実際の運用業務は、MHRT からの運用引継ぎ19として、上記のとおり運用マニュア
ルに基づいて行われている。MIDS は、たとえば、データセンターA においてエラー検知がなされた場合、以下の手順のとおり行動することとなっている。
① データセンターA において、MINORI のエラーが検知された場合、統合運用基盤シス
テムの画面上にエラーメッセージ ID が表示される。
② データセンターA の監視員は、当該画面に表示されたエラーメッセージ ID を目視で確認し、「対処不要のメッセージ」（特別作業依頼書で当日の対応を MHRT が行うとしているもの等）か否かを確認する。
③ エラーメッセージ ID の確認の結果、「対処不要メッセージ」ではない場合、データセンターA の監視員は、エラーメッセージ ID が表示された画面を印刷し、オペレーターに対して手交することにより、エラーメッセージ ID をオペレーターに伝達する。
④ 上記印刷物の交付を受けたオペレーターは、マニュアルの記載に従い、エラーメッ
セージ ID に応じてあらかじめ設定された MHRT の連絡先に電話連絡をし、エラー
メッセージ ID の伝達及び対応の照会を行う。
⑤ MIDS は、MHRT の指示に基づき対応し、MHRT への上記伝達の内容や上記対応の内容
を、「インシデント管理表」に記載する。
上記のほか、MHRT の担当者にエラー発生状況のシステムログをメール等により伝達する
NOI システム20も存在する。
上記により、MIDS から連絡を受けた MHRT は、障害対応として原因調査、影響調査、原因分析等の必要な対応を行うとともに、MHBK に対して状況及び調査・分析結果を報告し、復19

運用会社による本番システムの恒常的な運用管理・オペレーション業務、本番環境の変更管理及び特別作業（引継未済オペレーション、本番データ借用・修正・参照等）の実行を目的に開発会社が各種依頼書、
運用マニュアル類、プログラム及びオペレーション実行の依頼等を引き渡すこと。
20
下記第 4・1・
（1）
・イ・
（ア）
・ⅰ参照。なお、NOI システムには下記のメール配信機能に加えて、NOI ダ
ッシュボードという機能がある。当該機能は、ダッシュボード上でシステムログによるエラー発生状況を一覧できる機能であるが実態として利用されることはなかったとのことであるため、本報告書においてはメール配信機能についてのみ言及する。

32

旧対応策を提案する。MHRT においては、大きな障害等が発生した場合、対策本部を設置し、ホワイトボード等で情報共有を行った上で、関係各部署が連携し、対応を行っている。
なお、上記の運用マニュアルに基づき、MIDS からの電話連絡先は、基本的には、エラーが発生したシステムの種類に応じて分類されており、MHRT/IT インフラ本部第 1 部21等やMHRT 第 1 事業部の各部門等が、その連絡先となっている。ただし、MINORI 移行後当面の期間（本障害発生時を含む。
）は、照会連絡票により、一部のシステムで発生したエラーについては、MHRT プロジェクトデザイン本部22に連絡先を一元化することとされている。この場
合、MIDS より連絡を受けたプロジェクトデザイン本部が MHRT 各事業部に連絡を行う。各事
業部にて事象等の確認・対応方針の検討を行い、プロジェクトデザイン本部が各事業部と連携して MHBK に提案する対応方針を確定させ、また、MHRT 内の対策本部の設置要否を判断する。
MHRT から報告を受けた MHBK は、実際にシステムを使用しているユーザー部門との調整を含め、関係各部署において必要な対応を行い、復旧対応策を承認し、実施の指示を出す。
MHBK は、MHBK が策定している「システム対策 PT 運営マニュアル」に則り、MHFG、MHRT 及
び MIDS 等とテレビ会議及び WEB 会議システム等により連絡をとり、必要な指示を出す。
４

顧客取引における ATM 及びダイレクトの取引チャネルとしての意義

銀行取引を行う個人の顧客には、店頭での取引、ATM 及びダイレクトという取引チャネルが用意されており、全体の取引に占めるそれぞれの件数、取引金額の割合の概要は別紙 8 のとおりである。概算値で、ATM は取引件数では 87.2％（祝休日では 89.3％）、取引金額では
38.7％（祝休日では 76.9％）を占め、ダイレクトは取引件数では 8.5％
（祝休日では 10.7％）、
取引金額では 8.6％（祝休日では 23.1％）を占めている。このように、個人の顧客にとって、ATM 及びダイレクトは、取引チャネルとして大きな割合を占めており、その重要性が見て取
れる。
第４
１

本障害の事実概要及び原因
2 月 28 日障害（１）事実概要
ア

障害の発生状況（ア）障害の概要
2 月 28 日障害は、MHBK が MHRT に委託して開発しリリースした「みずほ e-口座案件」のe-口座一括切替処理をトリガーとして発生した。

21

MINORI や決済系を中心としたインフラ開発・管理等を行う部署。
IT 部門とコンサルティング部門に跨る戦略企画機能を担い、両者の一体的運営を推進するとともに、プロジェクトマネジメントオフィス（PMO）業務、クオリティマネジメントデスク（QMD）業務を行い、プロジ
ェクト企画段階から組成に至るプロセスを推進し、アーキテクチャ統制を行う部署。

22

33

MHBK は、銀行取引のデジタル化及び通帳に係る印紙税の負担削減等を目的として、口座開設時に通帳発行を行わないいわゆる「みずほ e-口座」の取扱いを 2021 年 1 月に開始するとともに、2020 年度以降、毎年 1 月末時点において、直近 1 年間以上にわたって通帳記帳がない口座をみずほ e-口座へ一括して切り替えることとした。
みずほ e-口座の取扱い開始に関する MINORI の機能改修自体は、2021 年 1 月 17 日にシス
テムリリースを完了し、e-口座一括切替処理は、同年 2 月から 3 月にかけて MINORI におけるセンター集中記帳のオンライン処理により実行されることとなっていた。
e-口座一括切替処理に関する上記スケジュールは、次年度の通帳に係る印紙税納付額を削減するという前提のもと、2021 年 1 月 17 日のシステムリリース以降、印紙税納付額の算定基準日である同年 4 月 1 日までの約 2 ヶ月の間に切替処理を完了させることとして設定した。
「みずほ e-口座案件」によるコスト削減効果は、MHBK において印紙税年間約 16 億円
程度及び通帳新規発行に係る削減コスト年間 1,000 万円程度と想定されていたところ、同日までに e-口座一括切替処理を完了するためには、「みずほ e-口座案件」の対象となる口座を抽出する基準日が同年 1 月 31 日であり、当該口座に関するユーザー部門での抽出作業が完了し、e-口座一括切替処理を行うことができるのは同年 2 月 12 日以降となるため、平日に比べ取引量の少ない土曜日及び日曜日に実施するとの前提で、他の休眠預金口座の移管や未記帳合算処理（同月 13 日及び 14 日）、普通預金決算（同月 20 日及び 21 日）、3 月の期
末最終週を回避するため、同年 2 月 27 日、28 日、3 月 6 日、7 日、13 日及び 14 日の合計 6
回の土曜日及び日曜日に実施することとされた。最終的に、切替初回である 2020 年度においては、切替対象口座である定期性預金口座、約 259 万件につき23、データ容量の制限24か
らおよそ 45 万件ずつの 6 回に分け、実施する予定となっていた。
この全 6 回のうち、2 回目に当たる 2021 年 2 月 28 日の作業中に、まず、MINORI 内の定期性預金システムに障害が発生した。
定期性預金システムの取消情報管理テーブルは、センター集中記帳並びに ATM 及びダイレクトからのオンライン取引で共用しており、月末の日曜日である 2 月 28 日には、通常の月末処理及び ATM、ダイレクトからのオンライン取引に加えて、e-口座一括切替処理が実施されていた。
同日の e-口座一括切替処理では、当該取消情報管理テーブルの INDEX FILE の使用率が100％となる容量超過が発生した。そして、これに起因し、定期性預金システムにおいて取消情報管理テーブルの更新ができなくなり、以降の定期性預金取引の更新取引が不能となる障害が発生した。
そのため、定期性預金システムにアクセスする更新取引が全て不能となり、同システムに

23

2020 年度の一括切替対象口座は約 1,400 万件あり、うち定期性預金口座が約 259 万件、流動性預金口座が約 1,158 万件であった。
24
定期性預金システムとセンター集中記帳システム間のファイル授受は、統合ファイル授受を経由して行
われるところ、統合ファイル授受の設計基準上の容量制限により、およそ 45 万件が 1 回の処理上限とされた。

34

アクセスした ATM 内に通帳・カードが取り込まれる事象が発生するとともに、ダイレクトによるものを含めて定期性預金システムにアクセスし更新取引を行った顧客や e-口座一括切替処理対象の一部顧客は CIF 排他状態となり、CIF 排他が解除されるまで全ての更新取引等ができない状態となった。
そして、定期性預金の更新取引が不能となる更新取引エラーにおいて、エラーの内容が元帳の整合状態が不明という内容であったため、自動取消が実行された。しかし、これも取消対象となるデータ（更新取引）が取消情報管理テーブルに存在せず、自動取消が不能25となって、自動取消エラーを引き起こした。
このような状況下、MINORI の取引共通システムは、二重エラー26によりパーコレートエラーが生じたと判断し、MINORI 全体の負荷の増大を回避し、システムの全面的な停止を防止する目的から、ATM やダイレクト等の各取引チャネルからの取引の入口となっている ATM 処
理区画及びダイレクト処理区画をそれぞれ閉塞し始めた。
加えて処理区画閉塞までの動作として、パーコレートエラーが発生する度に、発生した処理区画が属する系統内全ての処理区画のトランザクションの停止・起動（約 1 秒間）が行われた。
ATM 処理区画は 1 系統 20 区画で全 3 系統計 60 区画存在するところ、閉塞が進んで 1 系統
及び 2 系統は 20 区画の全てが閉塞するに至り、3 系統は 17 区画が閉塞した（合計 57 区画
閉塞）。これらにより、処理区画が全閉塞された 1・2 系統に振り分けられた取引は、定期性預金取引を含め全ての取引がエラーとなった。なお、ダイレクト処理区画は、1 系統 13 区画で全 3 系統計 39 区画あり、合計 30 区画が閉塞したものの各系統の全区画閉塞までには至らなかった。
これらに起因して、ATM では通帳・カード取込み、ダイレクトではエラー画面に遷移する
事象が発生した。

25

実際には自動取消に必要な更新処理が動作しており、これが不能となった。
MINORI で採用している制御機能 A（パーコレートエラーと判断する機能を有するミドルウェア）の詳細
な動作については、説明の便宜上、省略又は要約している。

2635

【図 7】障害の概要

上記一連の障害事象の発生機序及び各障害事象の因果関係の概要を簡潔に図示したもの
が下記図 8 である。
【図 8】（イ）障害発生、障害影響及びシステム復旧対応等の全体推移
上記一連の障害事象、その後の復旧対応や顧客対応も含めた全体推移の概要は、下記表のとおりである。

36

時間
8 時 24 分

状況
e-口座一括切替処理を含む定期性預金取引データのセンター集中記
帳処理の開始9 時 50 分

定期性預金システムにおける取消情報管理テーブルの INDEX FILE の容量超過
取引共通システムでパーコレートエラーが発生
取引共通システムにおける複数のシステムエラーを検知

10 時 0 分

MIDS が MHRT/IT インフラ第 1 部に対しエラーメッセージを検知した
旨を伝達

10 時 0 分

ATM 処理区画 1 系の最初の区画閉塞発生

10 時 1 分

ATM 処理区画 2 系の最初の区画閉塞発生

10 時 3 分

ATM 処理区画 3 系の最初の区画閉塞発生

10 時 6 分

MIDS が MHRT プロジェクトデザイン本部に対しエラーメッセージを検知した旨を伝達

10 時 11 分

MHRT/IT インフラ第 1 部が定期性預金システムの取消情報管理テー
ブルが自動拡張できない旨のエラーを検知

10 時 15 分

ATM センターが MHBK/IT・システム統括第一部、事務企画部、個人マーケティング推進部、CC 部等に対し、監視システム上は ATM 正常稼
働ながら ATM のエラーが多発している旨、エラーを 430 件検知した
旨、原因については不明である旨の「緊急一報メール」（以下「緊急一報メール」という。）を発信
MHBK システム対策 PT 運営マニュアルに基づきシステム復旧対応体
制を立ち上げ

10 時 19 分

ATM 処理区画 2 系において、取引サービス（対象：定期預金通帳を記帳する）禁止が自動設定

10 時 20 分

ATM 処理区画 1 系及び 3 系において、取引サービス（対象：定期預金
通帳を記帳する）禁止が自動設定

10 時 22 分

MHBK/IT・システム統括第一部が MHRT 第 1 事業部第 1 部及び同第 3部に対し、センター集中記帳処理の停止を指示

10 時 48 分

MHBK/IT・システム統括第一部が、MHRT 第 1 事業部第 3 部・プロジェ
クト企画部に対し、取引サービス禁止状態となっているサービスの有無の確認を指示

10 時 50 分

MHBK/IT・システム統括第一部部長から MHBK 常務執行役員（IT・シス
テムグループ副グループ長）に対し架電、複数のシステムエラーが発生している旨を報告
センター集中記帳処理を停止完了
37

時間

状況

10 時 56 分

ダイレクト処理区画 3 系の最初の区画閉塞発生

10 時 57 分

ダイレクト処理区画 1 系の最初の区画閉塞発生

10 時 59 分

MHRT 第 1 事業部第 1 部がセンター集中記帳処理の停止後も定期性預金取引にてエラーを検知

11 時 0 分

MHBK/IT・システム統括第一部から ATM センターに対し架電。ATM エ
ラー件数 1,000 件超、呼損多数発生している旨を確認した後、MHRT
第 2 事業部第 1 部に対し ATM エラー発生状況を確認

11 時 9 分

ダイレクト処理区画 2 系の最初の区画閉塞発生

11 時 14 分

MHRT/IT インフラ第 1 部及び同第 3 部が 281 件の CIF 排他が解除されない状態を検知・確認し、MHBK/IT・システム統括第一部へ報告
取引サービス（対象：定期預金通帳を記帳する）禁止が設定されていることを MIDS が MHRT 第 1 事業部第 3 部及びプロジェクト企画部に報告
MHBK/IT・システム統括第一部は MHRT 第 1 事業部第 3 部から報告を受領し、上記を認識

11 時 28 分

ATM 処理区画 3 系において、取引サービス（対象：定期性預金通帳を表紙見返し作成する）禁止が自動設定

11 時 30 分頃

MHBK/IT・システム統括第一部部長から MHBK 常務執行役員（IT・シス
テムグループ副グループ長）に対し架電。取消情報管理テーブルのINDEX FILE の容量拡張が必要となり、拡張に当たっては ATM・ダイレ
クトの定期性預金のサービス抑止が必要となる旨を報告
CIF 排他の解除について検討開始

11 時 35 分

MHBK/IT・システム統括第一部から MHBK 企画管理部危機管理室に対し、定期性預金取引を中心にエラーが発生している旨をメールにて発信

11 時 37 分

MHBK/IT・システム統括第一部の指示で取引サービス禁止機能の作動条件の上限引上げによる緩和の作業を開始

11 時 48 分

ATM 処理区画 2 系において、取引サービス（対象：定期性預金通帳を表紙見返し作成する）禁止が自動設定

12 時 2 分

取引共通システム 1 系において、取引サービス（対象：定期預金通帳を記帳する）の禁止の作動条件を緩和

12 時 5 分

取引共通システム 2 系において、取引サービス（対象：定期預金通帳を記帳する）の禁止の作動条件を緩和

12 時 8 分

取引共通システム 3 系において、取引サービス（対象：定期預金通帳を記帳する）の禁止の作動条件を緩和
38

時間

状況

12 時 14 分

ATM 処理区画 1 系の全区画が閉塞

12 時 27 分

ATM 処理区画 2 系の全区画が閉塞

12 時 37 分

MHRT 第 2 事業部第 1 部が自動機サーバにて 2,000 件以上のエラーを検知し、MHBK/IT・システム統括第一部へ報告
休止状況等が不明なため、エラー内訳の確認等を実施

12 時 45 分

ATM センターが ATM 画面上の定期性預金のメニュー抑止完了

12 時 47 分

MHBK/IT・システム統括第一部が MHBK システム障害管理運営要領に基づく「障害報告メール」（以下「障害報告メール」という。）を発信（A2 ランク懸念）
その概要は以下のとおり
・ダイレクト及び ATM の定期性預金取引にエラーが発生
・検知日時：10 時 59 分
・10 時 59 分時点エラー件数：197 件
・（障害）対象システムは定期性預金システム

12 時 50 分

ATM 処理区画 3 系の 17 区画が閉塞

13 時 0 分

MHBK/IT・システム統括第一部にて ATM の広範停止を把握

13 時 1 分

MHBK 個人マーケティング推進部がダイレクトの画面上にダイレクトにおける定期性預金取引の取扱いができない旨を掲載

13 時 2 分

取引共通システム 2 系において、取引サービス（対象：定期性預金通帳を表紙見返し作成する）の禁止の作動条件を緩和

13 時 13 分

取引共通システム 3 系において、取引サービス（対象：定期性預金通帳を表紙見返し作成する）の禁止の作動条件を緩和

13 時 15 分

CC 部が、ホームページの画面上に ATM・ダイレクトにおいて「一部のお取引がご利用いただけない状態となっている」旨を告知

13 時 18 分

ダイレクト処理区画 3 系において、取引サービス（対象：定期預金を入金する）禁止が自動設定

13 時 20 分

MHRT/IT インフラ第 1 部が定期性預金システムの切離し、取消情報管
理テーブルの INDEX FILE の容量拡張の手順整備・テストを完了

13 時 22 分

ダイレクト処理区画 3 系において、取引サービス（対象：定期預金を入金する）の禁止の作動条件を緩和

13 時 40 分

MHBK 事務企画部部長から MHBK 副頭取執行役員（事務グループ長兼
IT・システムグループ長）に対し架電、ATM で異常が多発している状況であり、今から内幸町本部へ参集する旨を報告

13 時 54 分

MHRT/IT インフラ第 1 部が定期性預金システムの切離し完了

14 時 0 分

MHRT/IT インフラ第 1 部が MHBK/IT・システム統括第一部からの指示
39

時間

状況
に基づき取引共通システムのログ調査を開始

14 時 10 分

MHRT 第 2 事業部第 1 部及び MHBK 個人マーケティング推進部がダイレクト画面上の定期預金のサービス抑止完了
MHBK 及び MHFG 企画管理部危機管理室が関係部長会の招集連絡を発信14 時 12 分

CIF 番号の特定等の確認作業開始

14 時 20 分

MHRT/IT インフラ第 1 部が取消情報管理テーブルの INDEX FILE の容量拡張作業開始

14 時 25 分

MHBK/RB 推進部が、全拠点の部店長・職員に電話連絡の上営業部店に出勤するよう指示を開始

14 時 30 分

関係部長会開催

14 時 54 分

MHRT/IT インフラ第 1 部が取消情報管理テーブルの INDEX FILE の容量拡張を完了MHBK/IT・システム統括第一部が MHRT 第 2 事業部第 1 部に対し、定期性預金システムのサービス再開を指示

15 時 30 分頃

MHBK 副頭取執行役員（IT・システムグループ長）から MHBK 常務執行役員（IT・システムグループ副グループ長）に対し架電、障害状況について共有

15 時 58 分

CC 部が、ホームページ上に、ATM に通帳・カードが取り込まれた場合には後日連絡の上返却する旨を告知

16 時 22 分

MHRT/IT インフラ第 1 部が定期性預金システムのサービス再開を完了

16 時 37 分

CIF の排他解除を開始（対象：463 件27）

17 時 0 分

MHBK 及び MHFG 企画グループ長・企画管理部が非常対策 PT を招集し、第 1 回非常対策 PT 開催

17 時 10 分

MHRT/IT インフラ第 1 部が、ログ調査の結果、上記の ATM 処理区画の閉塞を認識、処理区画の再起動に着手

17 時 30 分

MHBK/RB 推進部から、営業部店に対し、近隣 ATM への誘導や店頭ポス
ターの掲示等の具体的な顧客対応を指示
MHRT/IT インフラ第 1 部が ATM 処理区画の復旧作業を開始

27

17 時 56 分

ATM・ダイレクト処理区画 1 系の再立上げを完了

18 時 23 分

ATM・ダイレクト処理区画 2 系の再立上げを完了

18 時 39 分

ATM・ダイレクト処理区画 3 系の再立上げを完了

このうち 20 件は自動解除されている。

40

時間
18 時 51 分

状況
MHBK 個人マーケティング推進部が、ダイレクトの画面上に、一部のATM が停止していること及びダイレクトの一部取引が停止している旨を掲載

19 時 25 分

CIF の排他解除を完了（対象：463 件）

20 時 11 分

残存していた CIF の排他解除を開始（対象：100 件）

22 時 0 分

第 2 回非常対策 PT 開催

23 時 21 分

残存していた CIF の排他解除を完了（対象：100 件）

翌0時0分

ダイレクト画面上の定期性預金のサービス抑止が自動復旧により解除

翌 0 時 31 分

MHBK 個人マーケティング推進部が、ダイレクトの画面上に、ダイレ
クト復旧の旨を告知

翌 0 時 53 分

CC 部が、ホームページ上に、ダイレクト復旧の旨を告知

翌7時0分

ATM 画面上の定期性預金のメニュー抑止が自動復旧により解除【図 9】通帳・カード取込みの発生状況
処理区画閉塞（全 3 系統の系統別）の発生状況及び通帳・カード取込み件数の推移（9 時
50 分～18 時 38 分）

上記図 9 について注目すべき点は、ATM 処理区画の全区画閉塞に伴い ATM の通帳・カードの取込み件数が短時間のうちに増加している点である。ATM 処理区画の閉塞は、1 系につき
10 時 0 分、2 系につき 10 時 1 分にそれぞれ始まったところ、下記第 4・1・
（1）
・イ・
（ア）
・

41

ⅲのとおり「取引サービス禁止機能」に係る作動条件の緩和等を 12 時 2 分28に実施したのを契機に当該閉塞が一気に進み、1 系は 12 時 14 分、2 系は 12 時 27 分に全区画が閉塞され、3 系もその大半が閉塞した。これに伴い、12 時 0 分頃に約 1,000 件であった通帳・カード取込み件数が短時間のうちに増加し、12 時 40 分頃には 4,000 件を超えた。
（ウ）障害発生機序の詳細
ⅰ

取消情報管理テーブルの INDEX FILE 容量超過

e-口座一括切替処理は、障害発生前日の 2021 年 2 月 27 日に 1 回目が行われ、同日 6 時
30 分から 7 時 55 分にかけて、対象口座に対する同切替処理を含む処理ロットのセンター集
中記帳処理が問題なく実施された。
翌 28 日 6 時 8 分から、月末取引分のうち、3.1 万件（下記図 10 の①）、0.2 万件（下記図10 の②）、10.6 万件（下記図 10 の③）の処理ロットのセンター集中記帳処理が順に開始され、6 時 54 分に完了した。次に、8 時 0 分から ATM 及びダイレクトのオンライントランザ
クション29（下記図 10 の⑥）が開始された。その後、8 時 24 分から、e-口座一括切替処理の 45 万件（下記図 10 の⑤）と月末取引分 11.2 万件（下記図 10 の④）の計 56.2 万件のセンター集中記帳処理が開始されたところ、9 時 50 分、定期性預金システムの取消情報管理
テーブルの INDEX FILE の容量超過が発生した。
取消情報管理テーブルは、定期性預金システムにおいて、成立済取引の事後取消等をするために必要な取引情報を格納しており、取引を制御する上で更新処理が必須のテーブルであるところ、取消情報管理テーブルの INDEX FILE は、メモリ領域に常駐する仕組みとなっている。これは、MINORI 構築の終盤30である 2017 年 11 月に定期性預金システムで実施される「おまとめ処理」における処理時限への影響懸念が判明し、MHBK 及び MHRT の性能 WG で、この課題への対応策として、同月 17 日、MHRT の再委託先の開発ベンダーからの提案を踏まえ、「本件メモリ常駐」への仕様変更を決定した31ことによる。このように、処理速度が高速なメモリ領域に対象テーブルを常駐させることで、「おまとめ処理」についてレスポンス32を改善する効果が期待された。
上記の仕組みの下で、日次の累積での更新処理によってファイルの上限サイズを超過した時点、すなわち、メモリ使用率 100％に至った時点以降、新たな書込みができなくなり、

28

各系における実施時間の詳細は、上記第 4・1・
（1）・ア・（イ）の時系列表のとおり。
オンラインで行われる処理。たとえば、ATM やダイレクト、営業店端末等で、預金の入出金や融資、外国為替等の取引を入力し、それをシステムが元帳を更新するなどといった一連の処理のこと。
30
UAT（User Acceptance Test の略称。ユーザー部門が主体となり、システムが本番業務に耐える品質を確保していることを確認するために、関連システムも含め本番環境と同等のテスト環境と体制で一連のユーザー業務を想定したテストを実施する工程）は 2017 年 12 月まで予定されており、同月末に MINORI 全体のリリースバージョンの確定を行うこととなっていた。
31「本件メモリ常駐」化された INDEX には、「おまとめ処理」のみで使用する「業務テーブル」の INDEX（定期明細、定期取引履歴、定期口座残高、個別明細計数）以外に、他の更新処理でも使用する「取消情報管理
テーブル」の INDEX が存在していた。
32
コンピューターの処理要求に対する応答又はその速度。
2942

取消情報管理テーブルの更新処理が不能となった。
【図 10】

ⅱ

二重エラー及び CIF 排他の解除不可33

上記のとおりメモリの容量超過が発生したことにより、その後、定期性預金システムに更新処理が発生した際に取消情報管理テーブルへの更新が不可となるエラーが発生した。この際、定期性預金システムで使用しているソフトウェア A から取引メインに対し更新状態
が不明であることを示すエラーが送信され、これを受信した取引メインは、定期性預金シス
テムに対する取消が必要なシステムエラー（元帳不整合不明）として、自動取消を実行した。
これを受けて定期性預金システムが当該取引の取消を行ったが、取引取消に必要な情報がINDEX FILE の容量超過により存在しなかったため、自動取消処理も不能となった。これにより下記図 11 のとおり、二重エラーの状態が生じた。

33

CIF 排他機能が作動したまま解除ができないこと。

43

【図 11】

これは、取消情報管理テーブルの INDEX FILE が容量を超過し書込み不能となっている状
態で取消情報管理テーブルの更新処理を行おうとする場合、ソフトウェア B からのコミッ
ト処理時にエラーとなるが、定期性預金システムのエラー設計において、取消情報管理テー
ブルの情報は、下記図 12 のとおり、ロールバックされた状態であるにもかかわらず、かかる状態にあることがエラー内容に反映されない設計となっていたため、後続処理でソフト
ウェア A から取引メインへ更新状態が不明であることを示すエラーを送信し、取引メイン
が「システムエラー（元帳不整合不明）」を受信することとなる。その結果、取引メインでは「自動取消」処理を実行したが、取引取消に必要な情報が INDEX FILE の容量超過により存在しなかったため、当該自動取消処理自体もエラーになった。
【図 12】

44

このように、定期性預金システムの自動取消についてもエラーとなったため、下記図 13のように、ATM 又はダイレクトから定期性預金システムにアクセスし更新取引を行った顧客
や e-口座一括切替処理対象の一部顧客は、各自の CIF 排他機能が作動したまま解除されない状態34となり、それが解除されるまで、最大で 563 人35の顧客の全ての更新取引等が実施不能となった。これにより取引エラーとなったダイレクト等を利用した取引件数は延べ
6,114 件36である。
なお、この CIF 排他の状態を解除する措置は、11 時 14 分に当該状態の解除不可が検知されて 11 時 30 分から検討が開始されていた。もっとも、下記第 4・1・
（1）
・イ・
（ア）
・ⅲの
ように取引サービス禁止機能に係る作動条件の緩和などを優先的に検討しており、対象となる CIF 番号の特定等の確認作業が開始されたのは 14 時 12 分であり、その後 16 時 37 分に解除措置が開始された。これにより 19 時 25 分には 463 人分の CIF 排他状態の解除が完了したが、当該解除の完了確認中にシステムログに表示されていない CIF 番号が存在した等の理由から、100 人分の CIF が排他状態のまま残存していることが判明し、これらの解除に着手したのは 20 時 11 分となり、最終的に全ての CIF 排他状態の解除が完了したのは 23
時 21 分となった。
【図 13】

ⅲ

ATM 処理区画及びダイレクト処理区画の閉塞

上記「二重エラー」が生じた結果、MINORI の制御機能 A において、パーコレートエラー

34

CIF 排他の解除不可は累計 563 件発生した。内訳は、定期性預金の更新取引不可による排他：469 件（ATMからの取引：291 件、ダイレクトからの取引：178 件）、センター集中記帳による排他：35 件、営業店端末
によるオペレーションによる排他：2 件、パーコレートエラーによる処理区画のトランザクションに起因す
る排他：57 件（ATM からの取引 38 件、ダイレクトからの取引 19 件）である。
35
同一顧客において二つ以上の CIF 番号を有している場合がありこの人数は最大値である。
36
取引を試みた顧客は 423 人であり、大部分の顧客が取引を多数回試みている。

45

が生じることとなった。MINORI の制御機能 A では、上記「二重エラー」によりパーコレー
トエラーが生じると、当該パーコレートエラーの回数がカウントされ、累計 5 回に達すると、取引の入口となった ATM 処理区画やダイレクト処理区画が閉塞される仕様となっていた。
上記制御機能 A は、ATM やダイレクト等の各取引チャネルからの取引の入口となっている
ATM 処理区画やダイレクト処理区画をそれぞれ閉塞させた。
【図 14】

その結果、上記図 14 のとおり、ATM 処理区画の 1 系統及び 2 系統は 20 区画の全てが閉塞し、3 系統は 17 区画が閉塞した。
各系統への振分けはラウンドロビン37となっており、系統内の処理区画が全て閉塞している場合にも振り分けられる。したがって、全閉塞された 1・2 系統に振り分けられた取引は、定期性預金か否かにかかわらず全ての取引がエラーとなった。なお、ダイレクト処理区画は、
計 30 区画が閉塞したものの各系統の全区画閉塞までには至らなかった。
ⅳ

通帳・カードの取込み

通帳・カード取込みが多数に及んだのは、システム復旧の遅れ等の要因のほか、MHBK のATM が、広範囲にこれを行う仕様であったことによる。
2 月 28 日時点の仕様では、通帳・カードが取り込まれるケース及びその目的は、下記表の 5 通りであった。

37

複数の系統について、系統の番号に従って循環的に振り分ける仕組み。

46

番号

通帳・カードが取り込まれるケース

目的

1

・顧客の通帳・カード取忘れ

・次の利用者に迷惑をかけない

・紙詰まりによる機器故障の発生

・利用者に通帳・カードの現物を正しく返却する2

不正通帳・カードの利用

通帳・カードの不正利用拡大を防止
する

3

ネットワーク機器故障等の通信障害発生4

元帳不整合懸念のあるシステムエラー

5

ATM 処理区画の閉塞等、勘定取引に到達する前のエラーの発生

顧客の預金残高を正しく管理する（特に下記のリスクを回避）
・後続取引リスク（二重払出）
・誤認リスク（取引完了誤認）

2 月 28 日に発生した通帳・カード取込みは、上記の障害が発生した定期性預金システム
及び全ての ATM 処理区画が閉塞している 1・2 系統に顧客が ATM からアクセスしたことで、元帳不整合懸念のあるシステムエラー（上記表 4）及び ATM 処理区画の閉塞（上記表 5）のケースに該当し発生した。
【図 15】ATM の取込み仕様

イ

障害発生後の状況（ア）システムの復旧に向けた対応状況ⅰ

エラーメッセージの監視・連絡体制

MINORI 及び周辺システムにおけるエラーメッセージの検知は、上記第 3・3・（2）のとおり、第一次的にはデータセンターA で行われ、MHRT は、MIDS の監視員により検知された情47

報の伝達をオペレーターから受けてこれを集約し、調査・分析を行って、復旧対応策を検討
し、MHBK に対しエラー発生状況・調査結果の報告を行い、復旧対応策等につき承認や確認
を求める。
また、
ATM で発生した具体的な障害影響については、
東京及び大阪にある ATM センターが、各 ATM に設置されたオートフォンや ATM からのエラー電文を通じて情報収集し、MHBK の各担当部署へ報告する38（下記図 16 参照）。
【図 16】

MIDS の MHRT に対するエラーメッセージの伝達は、上記第 3・3・
（3）のとおり、MHRT の担当者39に対して電話で行われる。これを受けた MHRT の担当者は、営業日の営業時間中など品川シーサイド事務所にいる場合には、本番環境から当該拠点の開発環境へ転送40される
システムログに含まれるエラーに関するログを検索・確認する。営業日外又は営業時間外等、
品川シーサイド事務所に不在の際には、リモートワークの環境で設計書の確認はできるが、全てのシステムログを確認することは不可能な場合があり、基本的に品川シーサイド事務
所に駆け付けた後に同様の調査を開始することとしている。
なお、MHRT の担当者が品川シーサイド事務所外からエラー発生状況を把握する手段として、NOI システムというクラウドを経由したメール等によりシステムログのエラー情報を受信するシステムも存在する。しかし、同システムは、クラウドを経由することによりタイムラグが生じ、システムログのエラー情報は 1 メールあたり最大で 15 件しか記載できないことから、受信する側は全てのシステムログのエラー情報を把握することはできない。そのた38

ATM センターにおける ATM 監視業務については下記第 4・1・
（1）
・イ・
（イ）
・ⅲ・
（ⅰ）参照。
2020 年 6 月 19 日付 MHBK 及び MHRT 間のシステム受託サービス契約書別添サービス仕様及び運用マニュ
アルに基づき、エラーメッセージ内容に応じて MIDS 担当者から MHRT 担当者（開発担当（基盤）（MHRT/IT
インフラ第 1 部等）や開発担当（業務）（MHRT 第 1 事業部第 1 部等））へ連絡することとなっている。ただし、2 月 28 日障害においては、開発担当（業務）へ連絡することとなっているメッセージについては照会
連絡票に従い MHRT プロジェクトデザイン本部担当者へ連絡することとされていた。
40
転送により 10 分程度の時間差が生じる。
39

48

め、NOI システムは MIDS からの伝達の補助システムという位置づけにとどまり、データセ
ンターA からの電話連絡は、当時の体制上は必須であった（下記図 17、18 参照）。
【図 17】【図 18】

2021 年 2 月 27 日及び 28 日は、定期性預金システムから出力される一定のエラーメッセージ（メッセージ内容に「VGZ」というコードを含むものであり、容量超過メッセージも含む。
）については e-口座一括切替処理の際の立会のために MHRT から MIDS に対して出された

49

特別作業依頼書41に基づき、センター集中記帳処理の作業実施中は MHRT/IT インフラ第 1 部
が、品川シーサイド事務所から統合運用端末を使用してシステムログにてエラー発生状況を調査し、同拠点内の MHRT 各関係部署と共有することとなっており、MIDS の対応は不要とされていた。
ⅱ

エラーメッセージについての具体的な取扱い状況

2021 年 2 月 27 日のセンター集中記帳の開始後、同日終了時点で、上記取消情報管理テー
ブルの INDEX FILE の使用率は 87％に達しており、それが閾値（80％）を超過している旨のシステムログ42が、品川シーサイド事務所の統合運用端末にて確認できる状況にあった。しかし、定期性預金システムに係る当該エラーメッセージへの対応を行うこととされていた
MHRT/IT インフラ第 1 部は閾値を超えた警告であったことを見逃していた、又は確認はしたものの対応の必要があることの認識をしていなかった。その結果、当該システムログのエラ
ー発生状況は MHRT 関係各部及び MHBK/IT・システム統括第一部へ共有されず、MHRT 及び
MHBK において何らかの対応が採られることはなかった。また、MIDS の統合運用基盤システ
ムにも当該エラーメッセージは出力されていたものの、上記第 4・1・
（1）
・イ・
（ア）
・ⅰの
とおり当該エラーメッセージへの対応は不要とされており、また、MIDS が使用する運用マ
ニュアル上は MHRT/IT インフラ第 1 部の担当者に翌営業日（2 月 27 日（土）及び 28 日（日）の場合は、3 月 1 日（月））に電話連絡することとされていたため、当該閾値に達しているとの情報が MHRT/IT インフラ第 1 部へ伝達されることもなかった。
2 月 28 日は、9 時 50 分に、当該 INDEX FILE の容量超過による自動拡張不能に係るシス
テムログのエラーを含む複数のエラーが MHRT の品川シーサイド事務所に設置されている統合運用端末に出力されていたところ、MHRT がこれを認知し直ちに対応したことは確認できなかった。一方、10 時 0 分頃、データセンターA の統合運用基盤システムでエラー監視をしていた MIDS のオペレーターからは、MHRT/IT インフラ第 1 部の担当者へ電話によるエラー
メッセージの伝達がなされた。しかし、その具体的な内容については、MIDS 側と MHRT 側とで認識に齟齬が認められる。すなわち、9 時 50 分から 10 時 5 分の間に約 6,400 件のエラー
メッセージが発生し、その類型は、定期性預金システムに関するもの 4 種類、自動機システ
ムに関するもの 2 種類、取引共通システムに関するもの 18 種類の合計 24 種類であったところ、そのシステム上の出力時刻は①18 種類が 9 時 50 分、②2 種類が 9 時 51 分、③1 種類
が 9 時 54 分、④1 種類が 9 時 59 分、⑤2 種類が 10 時 5 分であり、①の中には、定期性預金システムに関し「メモリ常駐の INDEX FILE の容量が超過している」旨のエラーメッセー
ジ、取引共通システムにおける「パーコレートエラー」に関するエラーメッセージ等が含まれていた。上記 MIDS のオペレーターは、手順書に従いその伝達に当たったところ、当日中

41

運用マニュアルには記載されていない開発担当から運用担当への期間限定の作業依頼のこと。
この閾値を超過しているというエラー発生については、MHRT/IT インフラ第 1 部が対応することとなっ
ていた。
42

50

に MIDS の監視員が当該伝達内容を記録したとされる「インシデント管理表」には、10 時 0分にこれらエラーメッセージのうち 21 種類を伝達した旨が記録されている。その内容を、MIDS の電話発信記録も併せて整理すれば、具体的には、①10 時 0 分に MHRT/IT インフラ第1 部担当者に対し 10 種類、②10 時 6 分に MHRT プロジェクトデザイン本部担当者に対し 11
種類の各エラーメッセージを、いずれも電話で伝えたことになる。前者①には上記パーコレ
ートエラーに関するエラーメッセージも含まれる。これらによれば、取引共通システムに関する 2 種類、定期性預金システムに関する 1 種類の合計 3 種類のエラーメッセージが上記「インシデント管理表」に記載されておらず、それらの伝達には遺漏があったものと思われ、また、当該管理表記載の伝達時刻にも正確性に欠ける点がある。一方、MHRT/IT インフラ第1 部の担当者は、「上記①の電話連絡において伝達を受けたのは取引共通システムに関する「プロダクト MQ 通信エラー」の 1 種類のみである」旨、また、上記②の伝達を受けた MHRT
プロジェクトデザイン本部の担当者は、「上記②の電話連絡では、定期性預金システムや自動機システムに関するエラー5 種類程度のほか、種別の ID は示されなかったが取引共通システムに関しても多くのエラーが出ているとの連絡を受けた」旨であるところ、MHRT 側には、伝達を受けた内容を記録したメモや録音は存在しない。また、メール配信による伝達がなされた形跡もない。上記の伝達内容を特定する上では、上記「インシデント管理表」が物証として基本的に重要な証憑ではあるものの、その記載には正確性に欠ける点がある上、混乱した状況下で記録されたものでもあること、関係した担当者の供述内容も各自区々であること等を踏まえ、本調査においても、その特定には至らなかった。
しかし、いずれにせよ、MIDS が障害発生の初期段階で多数検知したエラーメッセージの重要な部分を MHRT が組織として的確に認識し、復旧に活かすことができていなかったことは否定できない。エラー種類の詳細はともかく、少なくとも、取引共通システムに関し多くのエラーメッセージが出ていること自体は MHRT に伝達されたものと認められ、それを契機に MHRT が MIDS に詳細を問い合わせたり、MHRT においてシステムログを確認したりすることで自らその内容を迅速・正確に確かめることは可能であったと思われるが、そのような対応をした形跡はない。
ⅲ

取引サービス禁止機能に係る作動条件の緩和

エラー検知後、上記第 4・1・（1）・ア・（イ）のとおり、障害の原因の解明とともに復旧に向け、センター集中記帳処理の停止、取引サービス禁止機能に係る作動条件の緩和、ATM 及
びダイレクト画面上の取引メニューからの定期性預金に関するメニューの削除、INDEX FILEの容量拡張、CIF 排他の解除等の各措置が採られた。このうち、取引サービス禁止機能の作動条件の緩和措置が採られた経緯は次のとおりである。
「取引サービス」は、普通預金出金や通帳記帳等の顧客サービス単位であり、今回、ATMにおいて自動で禁止となった取引サービスは「定期性預金通帳を記帳する」ことと「定期性51

預金通帳を表紙見返し作成する43」ことである。取引メインにおいて、同一の取引サービス
で 1 系統 30 回エラーが発生すると、当該取引サービスを禁止（取引メインの入口で止める）する MINORI 特有の機構があり、これは、MINORI の負荷を低減することで正常終了可能な処理のスローダウン等の二次災害を未然に防止することを目的としている。
取消情報管理テーブルの INDEX FILE の容量超過が発生した 9 時 50 分からパーコレート
エラーが急激に発生（1 分間に 4.14 回発生）し ATM 処理区画の閉塞が始まっていたが、10時 19 分から自動で取引サービスの禁止機能が順次作動し（上記第 4・1・
（1）
・ア・
（イ）の
時系列表のとおり、ATM 処理区画の各系統における各取引サービス（対象：「定期預金通帳を記帳する」及び「定期性預金通帳を表紙見返し作成」）禁止機能は、10 時 19 分から 11 時
48 分にかけて作動している。
）、パーコレートエラーの発生頻度が一気に低減（1 分間で 0.93
回）した。しかし、12 時 2 分から 12 時 8 分にかけて、ATM 処理区画の各系統における取引サービス（対象：「定期性預金通帳を記帳する」）禁止機能の作動条件となっているエラー回数の上限を大幅に引き上げる変更（30 回から 999 回）、すなわち取引サービス禁止機能の作動条件の緩和（事実上の取引サービス禁止の解除措置）を行った結果、再びパーコレートエ
ラーの発生頻度が高まり（1 分間で 4.33 回）、ATM 処理区画の閉塞に拍車がかかり、多くの処理区画が短時間に閉塞されて ATM に係る顧客影響が急激に拡大した（下記図 20 参照）。
当面の障害対応策としてこのような措置をとった理由は、過去にも取引サービス禁止機
能の作動条件を緩和し対応した同種の経験があった点にあるとされる。
上記第 4・1・（1）・ア・（イ）の処理区画閉塞の発生状況の図 9 にパーコレートエラーの発生状況を重ねてみると、下記図 19 のとおりであり、取引サービス禁止の作動条件の緩和によりパーコレートエラーが急増し、ATM 処理区画の閉塞が進んだことが見て取れる。なお、
ATM 区画ごとにパーコレートエラーが発生（赤■）し、5 回発生すると区画閉塞（グレー■）に至っている模様（9 時 50 分～12 時 59 分）を示すのが下記図 21 である。

43

通帳発行時に、通帳表紙の口座名義の印字、店番号、科目、口座、残高等の情報を保有する磁気ストラ
イプの書込み、表紙見返しへ口座番号やカナ名等の印字をすること。

52

【図 19】パーコレートエラー及び区画閉塞の発生状況【図 20】通帳・カード取込みの発生状況

53

合計

5,244 件48（5,170 名）

2,940 件

2,304 件（229 件）

通帳・カード取込みに対しては、障害発生当日（2 月 28 日）、ATM センターからのリモー
ト操作、警備会社の出動や営業店職員の駆付け対応により、取り込まれた通帳・カードの回
収、顧客への返却及び ATM の復旧（再立上げ）を行った。もっとも、障害発生当日が日曜日であったことから、顧客との連絡がつかないため、又は、店舗外 ATM が所在する施設の営業
時間が終了してしまったためなどの理由で通帳・カードの回収が完了しなかった事例が多く、当日に返却できた件数は一部にとどまった（当日返却分 1,244 件）。障害発生翌日以降、引き続き ATM 内に取り込まれた通帳・カードの回収を行うとともに、顧客に希望の返却方法（来店、郵送等）を確認した上で、返却対応を行った（翌日以降の返却分合計 4,000 件）。
返却状況は、障害発生当日から一週間後の 3 月 7 日までに 5,152 件、全ての返却を終えたのは 4 月 22 日であった。全 5,244 件の返却方法の内訳は下記表のとおりである。
郵送

店舗（翌日以降

訪問

計

は来店）
当日返却

4

1,167

73

1,244

翌日以降返却

1,797

1,606

597

4,000

合計

1,801

2,773

670

5,244

ⅱ

事業継続管理統括部門による対応（ⅰ）MHBK におけるシステム障害時の対応体制
MHBK においては、企画管理部危機管理室が事業継続管理統括に関する事項を所管している。上記第 2・3・
（3）・イ・（ア）のとおり、MHBK においてシステム障害に起因して緊急事
態・非常事態に至る可能性が認識された場合には、IT・システム企画部、MHBK/IT・システ
ム統括第一部等が事実確認、関係部署への連絡をし、企画管理部が各所管部からの報告を受け、集約した情報に関する対応策の検討を行うこととされている。
（ⅱ）当日の対応
企画管理部危機管理室の担当者は、遅くとも 2 月 28 日 11 時 12 分の CC 部からの連絡で一部の ATM でカードが取り込まれているとの複数件の SNS 書き込みを認識し、MHBK/IT・シ
ステム統括第一部に照会した後、11 時 35 分の同部からの返信により、カードが取り込まれる事象が発生していることを認識した。また、11 時 57 分には、企画管理部危機管理室の担
当者が、ATM センターが通帳・カード取込みの問合わせでパンクしている旨の情報を RB 部

48

取込み件数 5,244 件の内、ATM 処理区画閉塞に基づく取込みは 4,915 件、元帳不整合懸念のあるシステム
エラーに基づく取込みは 329 件である。

56

門から得て、通帳・カード取込み事象が広範囲で発生している旨を認識した。これを受けて、IT 部門が対応に当たる内幸町本部へ移動し、14 時 10 分に企画管理部危機管理室として関係部長会の招集連絡を発信した。
その後、14 時 30 分に関係部長会を開催し、参加部署（企画管理部、IT･システム企画部、
MHBK/IT･システム統括第一部、事務企画部、RB 業務部、RB 推進部、個人マーケティング推
進部、CC 部等）から ATM 停止台数（約 3,500 台：13 時時点）や ATM センターの状況（受電件数、呼損発生等）が共有され、CIF 排他状態の解除、ATM の通帳・カード取込み解消（通帳・カード返却）を優先することが決定された。
17 時 0 分には、システム障害による顧客影響が広範囲に及んでいることを踏まえ、企画
グループ・企画管理部は、IT・システムグループ長及び企画グループ長を PT 長とする非常対策 PT49を設置した。同時刻に開催の非常対策 PT 会議においては、システム障害内容、ATM
稼働状況、顧客影響、広報対応等が報告され、通帳・カード取込みの対象顧客特定、ATM 使
用可能・不可拠点のリスト化、原因究明等が決定された。非常対策 PT 会議は同日 22 時 0 分にも開催され、状況確認、翌朝までの最優先事項の確認がされた50。
ⅲ

ATM に関する顧客対応（事務企画部及び BCSOL）（ⅰ）ATM センターにおける ATM 監視業務
MHBK においては、事務企画部業務統括チームが MHBK の店舗内 ATM 及び店舗外 ATM の集中監視業務を所管し、東京及び大阪の ATM センターが当該業務を担当している。当該業務は、
MHBK から BCSOL に委託され、BCSOL が OKI に再委託し、さらに OKI が JBO に再々委託している。
各 ATM センターは、稼働状態の常駐監視、ATM 備付けのオートフォン経由での照会に対する電話対応、障害時の警備・保守出動手配等の役割を有し、顧客等からのオートフォン経由の照会に対して受電席のオペレーターが ATM の稼働状況等を確認し、必要に応じて警備会
社への出動依頼等の対応を行う51,52。通帳・カードが ATM に取り込まれた場合、通常は、顧客がオートフォンで ATM センターに連絡し、ATM センターのオペレーターが取引内容を確認の上、本人確認等が実施でき、かつ、現金返却が伴わない場合には、リモート操作で通帳・カード返却処理を実施する。他方、現金返却が伴う場合等、リモート操作のみで返却が完了しない場合は、ATM センターが警備会社に当該拠点への警備員出動を要請し、警備員が現地
49

事業継続基本方針第 9 条。
なお、2 月 28 日障害に関して、翌 3 月 1 日以降も非常対策 PT 会議は複数回開催されており、ATM 稼働状
況、通帳・カード返却状況等が報告され、通帳・カードの返却対応方針、対外告知方針等が協議された。
51
オペレーターのみによる対応が困難な場合には、SV 等が対応を支援する体制となっている。また、ATMセンターの監視システム上、端末から検索を実行すれば正常稼働している ATM 台数等の状況は確認可能であるものの、検索しない限りはそのような情報は一覧できない。
52
業務手続上、店舗内 ATM にかかわる警備出動については、警備会社から MHBK に対して費用が請求された
後、BCSOL において出動依頼内容と齟齬がないことを確認する手続が定められている。また、店舗外 ATM に関しては、MHBK と BCSOL との契約上、BCSOL 及び再委託先が委託業務に関連する費用の低減に努める旨が合意されている。
50

57

に赴いて返却対応を実施する。このような ATM センターにおける実務対応は JBO が担い、
BCSOL は ATM センターの運営企画及び管理、MHBK からの各種照会対応等を担当している。
ATM 監視の業務運用については BCSOL が内容をとりまとめた上で、事務企画部に報告することとされている53。また、ATM 取引の不能が頻発するなどの緊急時には、発生事象ごとに「緊急一報メール」の宛先となる部署や第一報及び続報メールの内容に含めるべき情報等を定めたルール54が策定されている。さらに、BCSOL 及び JBO は、ATM センターBCP を策定
し、MHBK に提出しており、BCSOL 及び JBO において定期的な BCP 訓練等を毎年計画、実施している。
（ⅱ）当日の対応内容
ATM センターでは、2 月 28 日は、通常の休日体制55がとられており、9 時 0 分時点で東京と大阪で合計 8 名のオペレーター体制であった。9 時 50 分に ATM センターにて受信電文解析エラーの事象を多数検知し、当該エラーに伴う ATM での通帳・カード取込みが発生していることを認識した。顧客からの通帳・カード取込みの連絡に対しては、オペレーターが 1 件
1 件リモートでの返却、復旧、警備出動手配を行ったが、その後受電数が急増し、SV も加わって 14 名で対応したものの、10 時 0 分以降は呼損率 90％台で推移した。BCSOL 運用管理セ
ンターは、10 時前頃に、ATM センターから電話で ATM が複数台停止していること、受電が多発していること等の連絡を受け、ATM センターに対して、MHBK 関係部署に対する「緊急一報メール」を送信するよう指示し、10 時 15 分に、ATM センター副所長から、MHBK 関係部署に
対して「
（件名）
「MH【一報】ATM 取引不能頻発、（本文）監視システム上は ATM 正常稼働な
がら、ATM のエラー発生が多発しています。発生 ATM センター：東京/大阪（430 件）検知時
刻：2 月 28 日 9:50 原因：現状不明（MINORI の障害？データセンターA オペ情報）苦情申し
出等は続報にて報告します」との「緊急一報メール」56が送信された。
また、ATM センター及び BCSOL 運用管理センターは、MHBK/IT・システム統括第一部から断続的にエラー件数、呼損状況等の問合わせを受け、同担当者はその都度端末確認を行い、MHBK/IT・システム統括第一部に対してその時点での状況を報告した57。なお、この間、ATM
センター本部長は、事務企画部 ATM センター担当者に対して、10 時 33 分頃に架電したもの

53

業務手続上、休日に至急の報告事象があり、BCSOL 不在の場合には、JBO から事務企画部に直接報告することとされている。
54「緊急メールの種別と銀行様送信先」と題するルール。
55
2 月 28 日に e-口座一括切替処理が行われることは事務企画部業務統括チームに対して事前に通知されていたものの、ATM 監視業務に影響のあるものとして認識されていなかった。
56「緊急一報メール」の送付ルールとして定められていた定型文 A-⑥「ATM 取引不能が頻発」に基づき、
MHBK の IT・システム統括第一部チャネル系システム推進チーム、個人マーケティング推進部営業開発チー
ム、個人マーケティング推進部コンタクトセンター業務チーム、事務企画部事務リスク管理室、事務企画部業務統括チーム・企画チーム、CC 部広報室及び MHRT に対して送信された。
57
MHBK/IT・システム統括第一部は、10 時 20 分時点でエラー630 件、呼損発生等の情報を、11 時 0 分時点
でエラー1,000 件超、呼損多数発生の情報を入手した。

58

の繋がらなかったため、留守番電話58を残した。
事務企画部は、「緊急一報メール」を受け、情報収集及び関係部署との共有を行った。特に、ATM センターに関しては部員を派遣して ATM 停止状況等の実態把握に努め、またオペレ
ーターの増員を依頼した。
具体的には、事務企画部次長から状況確認の指示を受けた事務企画部 ATM センター担当
者は、ATM センターの所長席や喪失受付センター59に対して電話で状況を確認し、11 時 0 分
頃に、事務企画部次長に対して電話で報告した。その後、同次長から当該内容の報告を受けた事務企画部リスク管理室調査役は、11 時 7 分に、事務企画部部長以下の事務企画部員に対して、当該内容を含む情報をメールで共有した。これを受けた事務企画部部長は、11 時
34 分に事務企画部副部長に対して事務企画部員の ATM センターへの派遣を指示し、11 時 49
分に事務企画部次長に対して ATM センターへの警備出動要請を指示した。
事務企画部 ATM センター担当者は、13 時 0 分頃に ATM センターに到着し、ATM センター
本部長に対して、障害発生拠点には躊躇わず警備出動要請を行うように指示した。また、同担当者は、BCSOL 運用管理センター担当者に対して ATM 停止状況等の説明を求め、13 時 42分に、事務企画部リスク管理室調査役らに対して「ATM センター（13：35 時点）入電件数：
約 16,250 件 カード取込み件数：3,079 件 通帳取込み件数：2,948 件」とのメールを送信した。なお、同様の内容は事務企画部リスク管理室調査役から 13 時 46 分に事務企画部部
長、13 時 48 分に関係部署にも共有された。
また、断続的に情報共有を受けていた事務企画部部長は、13 時 20 分に事務企画部次長に対して、状況について不透明な部分が多いことから、障害発生拠点か否かにかかわらず警備員を出動させるよう指示した。さらに、同部長は、オートフォンによる障害問合わせ対応に関する態勢を強化するため、13 時 45 分に、BCSOL との個別契約に基づき、ATM センターに対してオペレーターの増員を依頼し、ATM センターは、14 時 0 分頃以降、遅番者の早出出勤や休暇者の出勤指示を実施した60。
なお、事務企画部部長は、13 時 40 分に、上司の事務グループ長（IT・システムグループ
長）に架電し、メールで報告のとおり異常が多発している状況である旨及び今から内幸町本部へ参集する旨報告した。
ⅳ

ATM に関する顧客対応（RB 部門）（ⅰ）緊急時における RB 推進部・営業部店の役割
MHBK の「緊急時対応の行動計画」（要因別行動計画）においては、システム障害が発生した場合、RB 推進部に、営業部店等の情報収集、対顧影響情報集約、顧客対応の役割が当てられている。

58

ATM センターへの入電が増えているため、システム側の障害について情報共有を依頼する内容であった。
顧客が通帳・カードを紛失した場合の問合わせ窓口である。
60
ただし、18 時 0 分時点では 35 名まで増員したものの、呼損率は終日概ね 90％台の推移であった。
59

59

営業時間中に店舗内 ATM に障害・トラブルが発生し、機械内に顧客の通帳・カードが取り込まれた場合、各営業部店において、その都度利用者に当該通帳・カードを直接返却する。
直接利用者に返却できない場合は、①顧客に電話等で連絡し、原則、当日中に簡易書留郵便で返却する、②顧客からの来店申出があった場合は、本人確認を行い、受領書の提出を受け返却する、③顧客と連絡がとれず案内状を出状して返却する場合は、本人確認を行い、受領書の提出を受け返却する等の対応を行うこととされている。
なお、店舗外 ATM に障害・トラブルが発生した場合、原則として、警備会社が対応に当たることとされていたが、警備会社において対応が困難な場合には、ATM センターの依頼により、当該 ATM の管理部店（営業部店）の職員が出動し、障害の状況等を ATM センターに伝達しつつ、顧客対応に当たることとなっている。
ATM での各種取引の不能時の対応については、事務企画部所管の BCP として、銀行休業日
におけるオンライン全面障害又は預金システム障害により ATM での流動預金支払が不能となった場合を想定事象とした BCP（事務 736）及び ATM のハード障害により ATM 機器を使用した取引が不能となった場合を想定事象とした BCP（事務 333）が存在し、BCP 発動後の具体的な対応として、ATM コーナーへのポスターの掲示、窓口等への誘導（＝利用可能な他取引チャネルへの誘導）、障害が長期化する場合のホームページへの掲載要否の検討等を行うことが定められており、RB 推進部は、営業部店に対しポスターの掲示や利用可能な他取引チャネルへの誘導に係る指示を行う役割を担っている。
（ⅱ）2 月 28 日当日の対応
2 月 28 日障害発生当日、営業部店を統括する RB 推進部は、ATM が広範囲に停止しているという一部営業部店からの情報や、マスコミ情報、関係部からの情報により、多数の顧客がATM の前で立ち往生をしている事実を把握したことから、顧客対応が必要と判断し、14 時
25 分に全拠点の部店長・職員に対し出勤を指示した。
エリアによっては、RB 推進部からの指示を待たずに、エリア業務役が出勤指示や具体的な顧客対応の指示を行った。しかし、全拠点に対する出勤指示が完了したのは、17 時 0 分頃であった。
RB 推進部から営業部店に対し具体的な顧客対応（通帳・カードが取り込まれた顧客への返却対応、正常稼働している近隣 ATM への誘導や、店頭ポスターの掲示及び店舗外 ATM の巡回）を明確に指示したのは 17 時 30 分であった。
ⅴ

コールセンター等における顧客対応（個人マーケティング推進部）（ⅰ）個人マーケティング推進部の役割等
個人マーケティング推進部は、主として、ATM のサービス企画・推進に関する事項や店舗
外 ATM の運営に関する事項、他社提携戦略企画、コールセンター（横浜及び札幌）の企画・運営・管理、及びダイレクトに関する商品企画・顧客対応等の業務を所管している。システ
60

ム障害に伴う ATM 障害が発生した場合、個人マーケティング推進部は、所管する BCP 等に基づき、障害の発生していない自行 ATM やコンビニエンスストアの ATM を含む他行の ATM へ顧客を誘導する役割を負うことに加え、同部が所管するコールセンターは、顧客からの苦情「コールセンターマニュアル」や Q&A に基づいて顧客からの照会に対応の受け口となり61、することとされている。
コールセンターは、平時から個人顧客からの種々の問合わせに対応する業務を担っているところ、コールセンターの受電要員の人数は、集計された過去の入電数やイベント・キャ
ンペーン等から予測される入電数を根拠に決定されている。緊急事態が発生し、呼損率が高まることが予測される場合には、コールセンターマニュアルに基づき、個人マーケティング
推進部の部付部長の判断で受電要員を増員することとされていた62。なお、具体的な基準はないが、実態として、呼損率が 3、4 割を超える状況や特異な内容の入電が多い場合、CSV の裁量で、受電状況を個人マーケティング推進部の同センター担当者に報告していた。
（ⅱ）当日の対応状況
2 月 28 日障害発生当日は、e-口座一括切替処理が予定されていたことから、入電数がやや増えると予測され、コールセンターには 32 名の受電要員が配備されていた。しかし、2 月
28 日障害に伴う通帳・カードの取込みが発生し始めた時点から入電数は急増し、10 時 0 分
から 11 時 0 分までの呼損率は 66.1％、11 時 0 分から 12 時 0 分までの呼損率は 71.3％に上昇した63。
個人マーケティング推進部のコールセンター担当者は、12 時 30 分頃、コールセンターに対する顧客からの問合わせに対し、事務企画部の担当者と個別に相談の上、通常時のように
オートフォンに誘導するのではなく、「カードや通帳は後日返却するため、その場を離れていただいても構わない」旨の案内をすることとした。
また、ダイレクトについて、個人マーケティング推進部担当者は、ダイレクト画面に、13時 1 分に、ダイレクトにおいて定期性預金取引の取扱いができない旨を掲載し、18 時 51 分に、ATM が一部サービスを停止している旨及び ATM に通帳・カードが取り込まれた場合に後日顧客に対して連絡・返却する旨の追加掲載を行っている。
さらに、14 時 10 分に、ダイレクト内の定期預金、グローバル口座メニューをサービス時
間外に設定した。
また、関係部長会において、他行誘導の方針が決定されたことを受け、個人マーケティン
グ推進部担当者は、17 時 30 分頃、RB 推進部経由で営業店職員宛に他行誘導の指示を出し

61

ATM で問題が発生した顧客からの問合わせについては、原則として、オートフォンで ATM センターに連絡するよう、案内することとしている。
62
コールセンターマニュアルに、緊急時の受電要員の増員順位が記載されているものの、コールセンター
マニュアルは、平日における緊急時を想定して作成されており、休日の派遣体制は特に規定されていなかった。
63
その多くは、オートフォンが繋がらない顧客からの架電であったと考えられる。

61

た64。
ⅵ

広報対応（CC 部）（ⅰ）CC 部の役割等
CC 部は、メディアからの問合わせに対する回答等の広報対応を行う「広報室」とコーポ
レートサイトの管理や広告宣伝の制作等を行う「ブランドマネジメント室」に分かれている
ところ、緊急事態発生時には、広報室が、発生した緊急事態に関する対外広報のための情報収集、ホームページでの情報発信、関係部への指示・連絡等の責務を負い、対外広報のための中核的役割を担うこととされていた65。
緊急事態に関してホームページでの告知を行う場合には、当該緊急事態の所管部と広報室とが協議の上66、確定された告知内容が広報室からブランドマネジメント室に共有され、ブランドマネジメント室から MHRT にアップロードの依頼がなされる方法がとられており67、
アップロード作業やプレビュー画面の事前確認、プレビュー画面の本番化等に 30 分程度の時間を要することが通常であった。
（ⅱ）当日の対応
ａ

緊急事態の認識からホームページでの第一報を掲載するまでの状況

10 時 15 分、「緊急一報メール」を受信した CC 部担当者は、この内容をすぐに他の CC 部
員に共有し、CC 部として、ホームページでの対外告知を見据えた準備及び SNS での情報収「緊急一報メール」の内容を企画管理部、RB 業務集を開始した68。また上記 CC 部担当者は、部、RB 推進部、事務企画部及び個人マーケティング推進部と共有した。
10 時 55 分、CC 部は、MHBK の ATM で通帳・カード取込みが発生しているという趣旨の SNS
アラートメール（SNS 投稿 8 件）を受信し、11 時 12 分、このことを企画管理部危機管理室、
RB 業務部、RB 推進部、事務企画部にメールで展開した69。また、CC 部は、11 時 3 分、事務企画部担当者に対し、過去のホームページにおける告知文例を添付した上、ホームページで対外告知を行うことについての確認を求めるメールを送付したが、その後同担当者からの返信がない状態が続いたため、11 時 49 分、企画管理部、RB 業務部、RB 推進部の担当者らに対し、改めて、ホームページでの対外告知は第一報より遅くとも 2 時間以内に実施したい

64

他行誘導方針は、個人マーケティング推進部が単体で決定可能であったが、14 時 30 分の関係部長会までは、定期性預金取引に関する障害であると認識しており、他行では定期性預金取引が不可能であり、他行への誘導が問題の解決に繋がらないことから、他行誘導の方針決定はされていなかった。
65
緊急時における広報室の役割は、「情報発信対策 PT 運営マニュアル」、「緊急時対外広報マニュアル」等に詳細に記載されている。
66
告知内容については、所管部との協議を行うことが通常であるものの、最終的な決定権限は CC 部部長にある。
67
詳細な手順は「WEB サイトに関する手続書」で規定されている。
68「緊急時対外広報マニュアル」7 頁には「緊急性や速報性を有する事案の告知については、発生から 1 時
間以内を目処とする。
」との記載があるところ、上記 CC 部担当者は、かかる記載を念頭に指示を出した。
69
なお、この時点での SNS の書き込みは 20 件程度になっており、その旨が伝えられた。

62

旨のメールを送付した。しかし、かかるメールに対してもどの部署からも返信がなかったた
め、CC 部で自ら対外告知文案を作成した上、各部に文案の確認を依頼する趣旨のメールを再送し、RB 業務部及び企画管理部から文案に異存のない旨確認がとれたことから、13 時 15
「ATM・ダイレクトにおいて一部のお分70、ホームページ（個人トップページ等）71において、取引がご利用いただけない状態となっている」旨が掲載された。
ｂ

通帳・カードの取込みが起きた顧客に対する対外告知を行うまでの状況

13 時 48 分、事務企画部から、通帳・カードそれぞれ 3,000 件ずつの取込みが確認されている旨のメールが CC 部に共有された72。
14 時 10 分、RB 推進部から CC 部に対し、通帳・カードが取り込まれた顧客に対し、「確認の上後日返却するのでお帰り下さい」とのメッセージをホームページに載せられないかとの打診があり、CC 部は、かかるメッセージ掲載の可否を事務企画部に問い合わせた。事務企画部からの明示的な返信がなかったため、CC 部は、14 時 46 分、「通帳・カードを取り込
まれた方は後日ご連絡・ご返却する」旨の告知文案を自ら作成し、事務企画部、RB 推進部、
個人マーケティング推進部にメールで送付したが、同メールに対する返信もなかった。その後、14 時 30 分から開催されていた関係部長会の場において、15 時 40 分頃に同告知文案の確認がなされたことから、15 時 44 分、CC 部担当者は、アップロード作業を開始した。最終的に ATM に通帳・カードが取り込まれた場合、後日連絡の上返却する旨の告知がホームペー
ジ等に掲載されたのは 15 時 58 分であった。その後、翌日 0 時 53 分には、ホームページ（総合トップページ等）にダイレクト復旧の旨の追加掲載を行った。
ⅶ

顧客に負担を掛けたこと以上に見た顧客対応では、特に、5,000 人以上もの顧客が、ATM を通常どおり操作しただ
けで通帳・カードが突然取り込まれ、その場で長時間待たされ、返却のため来店する等の負担があったことが、大きな問題であったと認められる。最終的に通帳・カードが無事返却されれば済むという事柄ではない。
多数の取込みが発生したためにリモート返却や警備員による対応では追い付かず、一部の顧客を除き、多くの顧客の通帳・カードが ATM に取り込まれたままの状態となった。MHBKと連絡が取れるまで、顧客は何の情報もないままその場を離れることができず、ATM の前で
長時間立ち往生せざるを得なかった。

70

上記第 4・1・
（1）
・イ・
（イ）
・ⅵ・
（ⅰ）のとおり、ホームページへのアップロードには 30 分程度の時間が必要であった上、アップロード作業中に告知文案に形式的な誤りが確認されたことから一からアップロード作業をやり直すこととなり、最終的なアップロードが 13 時 15 分となった。
71
個人マーケティング推進部の所管であるが、ダイレクト画面についても、CC 部広報室は個人マーケティ
ング推進部と連携をとり、ホームページでの対外告知と同様の情報をダイレクト画面に 13 時 1 分に告知していた。
72
なお、11 時 12 分の第一報以降、SNS での書き込みの状況が関係各部に共有されたのは 14 時 2 分であった。

63

また、5,244 件の通帳・カードの取込みのうち、4,000 件が当日中に返却されず、翌日以降に、来店、郵送、訪問の方法により返却された。
このような事態に対し、顧客からは多数の苦情が寄せられている73。その内訳は、通帳・カード取込みに対する苦情が約 300 件、ATM の前で待たされたことに対する苦情が約 238 件、ATM センターに連絡がつかなかったことに対する苦情が約 146 件、コールセンターに連絡がつかなかったことに対する苦情が約 49 件、ATM が利用できなかったため不要な金銭負担が生じたという苦情が約 133 件、ATM の前で長時間立ち往生せざるを得なかったことから、予定に対する支障が生じたという苦情が約 89 件であった。中には、①通帳・カード取込みにより 7 時間以上待たされた、②5 時間待ち続け駐車場代がかかった、③携帯電話で銀行に電話をかけ続けてパケット料が上がった、④ATM センターに電話が繋がらないため喪失受付窓口に 196 回電話してようやく繋がった、⑤重要な試験の受験を見送った、⑥仕事をやむなく休んだ、⑦コンサートや予約したイベント等に行けなくなった、⑧寒い中飲まず食わずで立ちっぱなしの状況であった、⑨長時間トイレに行けなかった、⑩当日中の家賃の振込ができなかったこと等により延滞利息等の損失が別途発生した、⑪後日通帳・カードを引き取るに当たり有給休暇を消化した等、様々な身体的、精神的、経済的負担を指摘するものが含まれ
ている。
（２）原因
本システム障害は、直接、間接の様々な要因が相互に関連して発生した。以下では、便宜上、分析対象を「障害の発生」、「障害発生後のシステム復旧遅延及び顧客影響の拡大」に分
け、体制面、運用面、意識面などの観点から検討する。
ア障害の発生について（ア）取消情報管理テーブルのINDEX FILEの「厳密なキャパシティ管理の必要性」に係る認識の欠如、連携の不足
障害発生のトリガーとなった、メモリ領域におけるファイルの容量超過という一見初歩的な原因は、以下のようなものであった。
対象ファイルがメモリ領域にあってもディスク領域にあっても、ファイルの上限サイズを超過するとその後の DB 更新が不可能になることは変わらないが、一般的に、ディスク領域の場合は、複数のファイルを合算したトータル容量に見合った共通の空き容量を確保できるので、一つのファイル容量が急激に増加したとしても共通の空き容量で吸収できる場合が多い。一方、メモリ領域の場合は、個々のファイルごとに空き容量を確保することになるので厳密な容量設計74が必要になる。

73

2021 年 3 月 31 日までに MHBK に寄せられた苦情、WEB 窓口及び電話相談窓口の申出内容を基に集計した、
延べ約 955 件の苦情を把握している。
74
テーブルに格納するデータの容量を決める作業。

64

特に MINORI では、多数のシステムにわたる処理が生じるため、定期性預金システムにおいて e-口座一括切替処理のように多数のオンライントランザクションが発生することが想定されること、また、ATM やダイレクト等の取引チャネル、センター集中記帳からのオンラ
イントランザクションが発生する度に、取消情報管理テーブルの INDEX FILE のデータ量が増加する仕組みとなっていることから、作業の内容によってはメモリ内のデータ量が通常日の数倍以上に急激に増加することがある。このような MINORI のシステム特性上、上記の取消情報管理テーブルの INDEX FILE に係るメモリ容量の超過が生じることがないよう厳密なキャパシティ管理が必要となる。したがって、「本件メモリ常駐」を行うのであれば、MINORI のシステム特性に合わせた十分なメモリ容量の確保と、急激な容量の使用量増加を考慮したメモリ使用率の閾値の設定、及び常時監視が必要であった。しかし、MHBK 及び MHRTにはこのようなリスクの認識がなく、「本件メモリ常駐」への仕様変更の際に、このようなリスクの顕在化の可能性や当該リスクに応じた措置の必要性について、詳細に分析・検討がなされた形跡は見あたらなかった75。また、MINORI のリリース前においても、この点に着目したテスト等は行われなかったため、この問題は検出されなかった。
なお、基本設計書作成後の仕様変更76が発生した場合には、「速やかに仕様に関するドキュメント（たとえば、業務要件定義書77、基本設計書、詳細設計書、プログラム仕様書等）
を漏れなく更新し、更新した部分を関係者に漏れなく配布し共有」しなければならないとさ「本件メモリ常駐」への仕様変更はこれに該当するにもかかわらず、下れている78。しかし、記図 22 のとおり、仕様変更後の MHRT 開発本部第 1 事業部第 1 部が管理・使用する定期性
預金システムに関する基本設計書（物理テーブル一覧79）には「本件メモリ常駐」への変更と MINORI のシステム特性に合わせた厳密なキャパシティ管理が必要である旨の記載はされなかった80。

75

なお、2017 年 11 月 16 日に性能 WG において「本件メモリ常駐」を決定した際には、MHBK 及び MHRT の担
当部署は、メモリ容量の上限が固定であることによる問題の発生があり得ることを認識していたが、MINORIのシステム特性に合わせた取消情報管理テーブルの INDEX FILE に係るメモリ容量に関する厳格なキャパ
シティ管理の必要性までは認識していなかった。
76
MHBK の開発工程管理手続において、仕様変更は原則回避するものとされ、仕様変更の必要性やプロジェ
クトへの影響を検証し、真にやむを得ない場合に限り仕様変更を許可するとされていた。
77
業務要件を記述した文書。
78
MHBK の開発工程管理手続第 6 節第 5 項において、「ユーザー部門等から仕様変更の要望が挙がった場合、推進部門と開発会社は、仕様変更の必要性やプロジェクトへの影響を検証し、真にやむを得ない場合に限り仕様変更を許可すること。
」との記載及び「推進部門と開発会社は、仕様変更が生じた場合は、速やかに仕様に関するドキュメント（例：業務要件定義書、基本設計書、詳細設計書、プログラム仕様書等）を漏れなく更新し、更新した部分を関係者に漏れなく配布し共有する。
」との記載がある。
79
データベースの各テーブルの物理的な配置を示すリスト。
80
MHRT/IT インフラ本部第 1 部において使用する詳細設計書には、取消情報管理テーブルの INDEX FILE の所在は記載されていた。

65

【図 22】キャパシティ管理の記載等について

このような「厳密なキャパシティ管理の必要性」の認識の欠如と関係部署間の連携の不足が、「本件メモリ常駐」に係る影響調査が行われなかった主たる原因といえる。すなわち、「みずほ e-口座案件」の開発時、MHRT 開発本部第 1 事業部第 1 部は、当該部署で使用する
基本設計書等に記載がなかったため「本件メモリ常駐」の事実を認識しておらず、また、取消情報管理テーブルが「みずほ e-口座案件」において改修対象に含まれるテーブルではなかったことから、MHRT/IT インフラ本部第 1 部に対し、e-口座一括切替処理において想定されるオンライントランザクション数等の情報を伝えることなく、処理時間についての質問のみを行った。MHRT/IT インフラ本部第 1 部は、「本件メモリ常駐」の事実自体は認識していたが、オンライントランザクションが発生する度に、取消情報管理テーブルの INDEX FILEのデータ量が増加すること自体を認識していなかったため、「本件メモリ常駐」による影響があることを回答しなかった。結果、MHRT 第 1 事業部第 1 部は、MHRT/IT インフラ本部第 1部に対し、積極的に情報を提供せず、また、MHRT/IT インフラ本部第 1 部も、MHRT 第 1 事業部第 1 部に対し、「みずほ e-口座案件」につき、キャパシティに関する影響調査を行うような提案をしなかった。このように、関係する部署間での十分な情報の連携が行われなかったことから、e-口座一括切替処理に係るメモリ容量に関する影響調査は実施されなかったものと認められる。
もっとも、影響調査で問題が検出されなかった場合でも、システムテストによって問題が検出されることはあり得る。しかし、「みずほ e-口座案件」におけるシステムテストは、MHRTが計画書を作成し、これを MHBK/IT・システム統括第一部で確認したものの、上記のように、「本件メモリ常駐」への仕様変更が、業務担当部が使用する基本設計書に反映されておらず、
かつ、引継ぎもなされていなかったこと、「本件メモリ常駐」に係るリスクを認識していた者や認識することができた可能性のある者がシステムテストの計画の策定に参加していな
かったことから、システムテストではかかる問題を発見することができなかった。
66

また、MHRT の 1.5 線である銀行システムグループ横断本部横断推進部（現プロジェクト
デザイン本部プロジェクト企画部）、2 線であるシステムリスク管理部、その他 MHBK/IT・シ
ステム統括第一部や内部監査部門も、それぞれ、横断的に仕様統制を行う役割や、性能面での「確認が行われていること」を確認する役割等を担っているが、いずれも、その役割上、自己の所掌する役割に則った確認を行うこととなっていたため、かかる問題を発見するに至らなかった81。
以上の各段階における確認を経て、上記の IT 戦略推進委員会にて本件「みずほ e-口座案
件」リリースに係る審議が行われたが、性能面（スケジュール管理を目的とした処理時間）
での確認は行っているものの、容量面での確認を行わないまま、「テスト工程が全て完了し、残課題なく品質に問題ないこと」、「大量データを取り扱う e-口座一括切替処理では、センター集中記帳を含め性能評価を実施していること」、「切替日を複数に分割していることにより、案件固有のリスク軽減対策済であること」、「システムリスク管理室がプロジェクト審査を実施、品質、リリース準備状況に問題なしと評価していること」の確認がなされ、リリースを是とする判定がなされた。
その結果、システムテストにおいても、e-口座一括切替処理の対象口座データ 8 万件を超える実機テストは実施されず、限定的な実機テスト結果を基に、本番想定件数82のセンター
集中記帳について、同時間帯に稼働するほかのセンター集中記帳処理による負荷も考慮した上での「処理時間」を机上で検証したのみとなった。また、処理時間の確認は上記の机上テストを実施したものの、テスト前後の「容量」増減確認を怠っていたため、問題を発見す
る機会を逸した。
以上のように、基本設計、確認、テスト、リリース判定の各段階において、問題を洗い出し、障害の発生を未然に防止することはできなかった。
（イ）エラー設計の不備及びMINORI構築時の障害回復テストでのリスク洗出しの不足
上記のとおり、定期性預金システムで使用しているソフトウェア A での処理におけるエラー設計は、不備があったと考えられるが、この不備を MINORI 設計時のレビューや検証、障害回復テストで検出できなかったことが、原因の一つであると考えられる（下記図 23 参照）
。定期性預金システム構築時に取引メインを接続した状態での障害回復テストは実施していたものの、これに加え、システムを相互に連結した上で多様な障害回復テストを十分に実施していれば、上記エラー設計の問題が結果として検出され、2 月 28 日障害のようなシステム相互の連結的な障害を阻止できた可能性も考えられるところ、MINORI のリリース前に障害回復テストを十分に実施した形跡は見あたらない。

81

たとえば、MHRT のプロジェクトデザイン本部プロジェクト企画部は、各システムの容量設計を仕様統制の対象外としていたし、MHRT システムリスク管理部は、書面方式による審査で、形式面の確認を主な対象としていた。
82
本番環境で発生することが想定される取引・データ等の件数。

67

【図 23】（ウ）e-口座一括切替処理のスケジュール決定におけるリスク認識の不足
最終的に「みずほ e-口座案件」のリリースの決定及び e-口座一括切替処理のスケジュー
ルを決定するのは、MHBK であるところ、MHBK は、月末実施は気になるものの、定期預金の月中処理ピークは月末ではなく 25 日であり、ピーク日を回避している、更新する項目が少なく難易度が高くない作業である、不具合発生時は直ちに作業を中止し予備日に繰り越すことができる、といった点を考慮の上、リリース判断をした。
一般的に、様々な処理がピークを迎える可能性が高く、翌日が月初となり重要な取引が集中する月末に大規模な処理を行う場合、そのリスクを慎重に判断すべきであるところ、これに加えて通常の月末処理及びオンライン取引と同時並行で 45 万件の e-口座一括切替処理を行うとすれば、そのリスク判断は一層慎重になるべきであった。しかし、当該リスクの検討が十分に行われたとはいえない。また、リスクを覚悟して実施するのであれば、生じ得る
様々なリスクを想定し、通常よりも水準を上げた監視を行うべきであった。しかし、2 月 27
日及び 28 日当時の立会において監視体制の強化が十分になされたとはいえず、それが、同
月 27 日の閾値オーバーの警告メッセージの見落としや、同月 28 日のエラーメッセージの迅速かつ正確な伝達や確認の欠如に繋がった可能性が高い。
（エ）MHRTによる予兆の見逃し
上記のとおり、MHRT/IT インフラ第 1 部が、2 月 27 日の e-口座一括切替処理の時点で、取消情報管理テーブルの INDEX FILE の使用率は 87％に達しており、同取消情報管理テーブ
ルの INDEX FILE の使用率が閾値（80％）を超過している旨のエラーメッセージが出力されていた以上、同月 28 日の一括切替処理を実施する前に、INDEX FILE の使用率を緩和させる
措置等の速やかな対応を実施しなければならないことに気が付くことができた可能性はあったと言わざるを得ない。しかし、上記のようなリスク認識の欠如や知見のある担当者の不68

在により、そもそも対応の必要があったことの認識ができず、同月 27 日の時点で発せられていた予兆を見逃した。
（オ）ATMの「通帳・カード取込み」範囲を縮小する仕様変更の遅れ
2 月 28 日障害の特徴の一つは、大量の通帳・カード取込みが発生した点にあるところ、その主な原因は、他行に比し、ATM 仕様において通帳・カードが取り込まれる要件が広かったにもかかわらず、それが 2 月 28 日障害発生に至るまで変更されなかったことにある。通帳・カード取込みについて、他行は、その障害経験を踏まえて、これまでに取込みの要件を見直してきたようである。しかし、MHBK は、下記ⅰからⅲのとおり、MINORI 稼働後 3 回にわたり多くの通帳・カード取込みを発生させているが、その教訓が必ずしも活かされず、2月 28 日障害以前にその仕様を見直すべきか否かの検討が、十分に行われた形跡は見あたらなかった。その結果、他行に比し広範囲の通帳・カード取込み仕様が特段の問題意識もない
まま継続された。また、この問題の影響を強く受けるであろうサービス時間の夜間休日拡充
等の動きに対応しようとする視点も欠けていたと言わざるを得ない。そこには、通帳・カー
ド取込みが顧客に与える不便・不利益などの影響に対する感度の低さが見て取れる。
ⅰ2018 年 6 月のシステム障害による通帳・カード取込み2018 年 6 月 16 日及び 17 日に実施された STEPS の MINORI への移行リハーサルにおいて、営業店端末等を MINORI リハーサル環境へ接続し、その後 STEPS への戻し作業を共通ファイ
アウォール83に対して実施する際に、接続/戻しに必要なネットワーク定義を対象店舗ごとに設定・削除したが、「件数が大量の場合に設定・削除に関する処理が長時間化する場合がある」という製品既存バグが顕在化し、かつ当該処理が長時間化して高負荷状態になったことに伴い、機器の正常稼働を監視する死活監視機能が正しく機能せず、同月 18 日 9 時 20 分
頃から 11 時 47 分頃にかけて、稼働系と待機系の系切替えが複数回発生した。これにより、同日、当該系切替えの間に行われた ATM 取引でエラーが発生し（エラー検知 ATM 台数：1,234台）、通帳・カード取込みが 1,821 件（店舗内 1,285 件、店舗外 536 件）発生した。
当該取込みの発生が平日の昼間であったことから、店舗内 ATM の通帳・カード取込みについては営業店にて個別に対応し、店舗外 ATM のそれについては ATM センターによるリモー
ト返却及び警備会社による個別の駆付け（合計 512 件）により対応した。同日の呼損率は最大で 96％に達しており、店舗外を中心に合計 68 件の通帳・カード取込みについては顧客に当日返却ができず、翌日に返却を完了した。
これに対し、顧客から 30 件程度の苦情（オートフォンに連絡しても繋がらない、ATM の前で長時間待たされた等）が寄せられていたが、同日以降の IT 戦略推進委員会（同月 25 日
実施）
、次期システム管理委員会（同月 25 日実施）
、次期システムプロジェクト統括会議（同83

外部のネットワークと社内のネットワークを遮断するための仕組み。

69

月 27 日実施）
、金融庁への報告（）においては、いずれも当該苦84

情等に係る顧客対応に関する情報が報告、議論されず 、MHFG/MHBK は、当該事象が突発事象であるとして、改善策が必要な恒常的な問題とは認識しなかった。
そのため、顧客対応部門やシステム部門からの顧客対応に係る提案はなく、またホームページ等での公表措置も実施されず、あくまでも当該事象を踏まえた対策としてはバグ精査等を主とする再発防止策にとどまり、結果、当該仕様が継続された。
ⅱ

2019 年 12 月のシステム障害による通帳・カード取込み2019 年 12 月 15 日 15 時 8 分頃、ATM での通帳・カード取込みが 187 件発生した。その原因は、MINORI 共通基盤 A ハード故障に伴って自動機サーバにエラーが発生したことにあった。当日は日曜日であったため、全てオートフォンにより対応したが、呼損率は最大で93.1％となっていた。
しかし、これを契機に ATM 仕様を変更することの当否を検討するには至らず、経営陣に対する報告もなされなかった85。
ⅲ

その他の「通帳・カード取込み」事象及びこれに関連する外部の動き

通帳・カードの磁気不良のために ATM で読み込めない事象や、ATM では読み込めたものの、読み込んだ内容に不良がある事象が、STEPS から MINORI への移行前後を問わず発生していた。STEPS においては、このような場合には業務エラーによる取引取消とされ、通帳・カード及び現金は返却する仕様であったところ、MINORI においては、システムエラーとされ、通帳・カード及び現金を ATM に取り込む仕様となっており、これを 2020 年 7 月まで約 2 年間にわたって仕様変更していなかった。その結果、MINORI 稼働後、毎月 140 件程度の取込
みエラーが発生した（1 日あたりの最大値は 2018 年 10 月 5 日の 34 件）。
この点、MHBK も関与したコンビニ等の共同利用 ATM の仕様策定に際して、他社が通帳・カード取込み仕様をなるべく返却する仕様に変更したという経緯があったほか、他社例ではあるものの、通帳・カード取込み事例は金融庁の「金融機関のシステム障害に関する分析（2020 年 6 月公表）においても紹介されており、通帳・カードの取込みによりレポート86」
顧客影響が発生するケースがあることについて、監督当局の問題意識が提示されていた状況にあった。しかし、MHFG/IT・システム企画部システムリスク管理室リスク管理企画チー
ムは、チーム内で当該レポートを踏まえた分析を一応行ってはいたものの、当該レポートで84

2018 年 6 月の通帳・カードの ATM への取込みに関する苦情については、企画グループ担当役員宛四半期
定例報告の中で、ATM 関連の苦情件数の内訳として「6 月 18 日発生システム障害関連 28 件等」と件数を報告したのみであった。また、「一部の ATM にて休止や仕掛り、営業店端末の一部で接続できない事象が発生したが対応済み」の旨のみが MHFG の経営会議及び関係部署等に報告されている。
85
苦情自体が 2 件しかなかったため、企画グループ担当役員宛四半期定例報告でも言及がなされなかったとのことである。もっとも、いうまでもないが、苦情の件数が少ないからといって、必ずしも報告の必要がない軽微な事象であるということにはならない。
86
https://www.fsa.go.jp/news/r1/20200630-2/system_01.pdf

70

紹介されている個別事例ごとの自社とのギャップ分析のような緻密な分析は行っていなかった。
このように、自社の過去事例のみならず、他社との協働事例や監督当局が情報発信を行っている他社事例を端緒として ATM の仕様を見直す機会が数回にわたり存在したにもかかわらず、MHBK においては、そのような「気付き」の機会が活かされてこなかった。
なお、仮に顧客の預金残高を正しく管理する目的が重要であるとしても、ATM 処理区画にエラーが生じた場合や、通信障害（ネットワーク機器故障等）が生じた場合には、顧客情報の更新は行われておらず、顧客の預金残高の食違いが起こる可能性はほとんど考えられない。そのため、仮に ATM 内に取り込むのではなく、通帳・カードを返却する仕様に変更した
としても、支障はなかったはずである。しかし、上記のように ATM の仕様に起因する問題につき経営陣に対する報告が適切になされておらず、経営陣においても、このような問題意識を持つに至らなかった。
なお、下記のとおり、2021 年 5 月 9 日現在、MHBK は本障害を受けた再発防止策として、
通帳・カードの取込み仕様を大幅に変更（下記図 24 の 3．通信障害及び 5．ATM 処理区画エ
ラーにおける勘定取引の場合を返却する仕様に変更）しており、これが本障害前に実施されていたと仮定すれば、2 月 28 日障害における上記「通帳・カード取込み」全 5,244 件のうち 4,915 件は発生しなかったものと推定される。
【図 24】

イ

障害発生後のシステム復旧遅延及び顧客影響の拡大について（ア）システム対応関係
2 月 28 日障害によるシステムの復旧遅延及び顧客影響の拡大の主要な要因として、障害復旧対応の過程において、①ATM 処理区画閉塞の確認が当日の 17 時 10 分にまで遅延したこと、②取引サービス禁止機能の作動条件を緩和したこと及び③定期性預金システムの切離
し又はメニュー抑止（ATM 画面上の取引メニューからの定期性預金に関するメニューの削除）
71

の措置が遅れたこと、が挙げられる。なお、ダイレクト等からの取引へ影響をもたらした CIF
排他の解除までに時間を要した点については、その対応に独自の問題があるとまでは認められなかった87。
上記①について、ATM 処理区画閉塞が確認された経緯は以下のとおりであった。取引共通システムのログ調査は 14 時頃まで行っていなかったところ88、その後、16 時 22 分に定期性
預金システムのメモリ拡張が完了し、定期性預金システムのサービスを再開した後も ATM が復旧しないことを契機としてようやく、取引共通システムの過去に遡ったログ調査が開始された。これらのプロセスを経て、パーコレートエラーに関するシステムログを認識し、さらに、ATM 処理区画のログを調査した結果、17 時 10 分に ATM 処理区画閉塞の事実を確認するに至り、復旧作業を開始することとなった。その結果、全ての ATM 処理区画の再立上げが完了したのは、18 時 39 分となった。
しかし、上記のとおり、MIDS においては 9 時 50 分に検知された取引共通システムにおけるパーコレートエラー等に関するエラーメッセージを認知していること、及び ATM センターにおいても 9 時 50 分に検知された ATM からのエラーメッセージを認知していることから、これらのエラーメッセージが MHBK/IT・システム統括第一部に迅速に認識され、障害復
旧対応において考慮されていれば、より早期に取引共通システムの担当である MHRT/IT イ
ンフラ第 1 部の担当者が、システムログの解析の必要性を認識し、結果、相当程度早期にATM 処理区画閉塞の事実を確認できた可能性が高い。また、そもそも、MHRT においても、品川シーサイド事務所に設置されていた統合運用端末に、パーコレートエラー等に関するエラーメッセージが検知されていたのであるから、これを直ちに認識して、対応に活かすべきであった。さらに、取引共通システムの担当者が、システムログの調査においてパーコレー
トエラーを早期に確認できた場合、上記②の取引サービス禁止機能の作動条件の緩和を行わなかった可能性及び上記③の定期性預金システムの切離し又はメニュー抑止の措置を早めることができた可能性もある。
上記②について、前記のとおり、10 時 19 分に取引サービス禁止がシステムにより自動的に設定されており、この時点で一部の定期性預金システムに関する取引が抑止され、ATM 処
理区画の閉塞の増加数は一定程度抑えられていたが、MHBK/IT・システム統括第一部において、11 時 14 分に取引サービス禁止が設定されていたことを認識し、12 時 2 分から 12 時 8分にかけて障害復旧対応として、取引サービス禁止機能の作動条件であるエラー回数の上限を大幅に引き上げる緩和措置89を行っている。これにより、MINORI の防御機能の一つである取引サービス禁止機能の発動によるパーコレートエラーの発生数を抑制することができ

87

上記②の取引サービス禁止機能の作動条件の緩和を優先したことに関する問題は上記第 4・1・
（1）
・イ・
（ア）
・ⅲのとおりである。
88
なお、14 時以降も当初は OS の状態等を確認するため、近接する時間帯の現状のログ調査を主に行っていた。
89
30 回から 999 回への変更を行っている。

72

なくなり、多くの ATM 処理区画が短時間で閉塞されるに至り90、顧客影響が拡大したといえる。仮に取引サービス禁止機能の作動条件の緩和を行わなければ、通帳・カード取込みの数は減少した可能性がある。
上記③について、前記のとおり、MHBK/IT・システム統括第一部は、定期性預金システムの取消情報管理テーブル INDEX FILE の容量拡張を実施するための前処置を目的として、12時 45 分にメニューの抑止及び 13 時 54 分に定期性預金システムの切離しを行っている。しかし、定期性預金システムに障害が発生し、それに起因して他のシステムに影響が及んでいる可能性があることを踏まえ、端的に他のシステムへの影響を遮断する目的で、より早期に定期性預金システムの切離し等を行うことを検討すべきであった。これらを実施する判断が早期にできていれば、定期性預金システムを端緒とするパーコレートエラーの発生及びATM 処理区画閉塞の発生を大幅に抑制できた可能性があるが、そのような対応や検討はなされていなかった。
なお、上記②で述べた取引サービス禁止機能には限界があり、上記のような遮断機能は期待できなかった。すなわち、定期性預金システムに関わる取引サービスの全てが直ちに同機能によって禁止されるものではなく、2 月 28 日障害においても、定期性預金に関する 2 つのサービスのみが禁止されているにすぎず91、パーコレートエラーの増加数は減少している
ものの依然として発生し続けていたからである。
上記①から③の要因として、以下のような問題もあったと考えられる。
ⅰシステム運用上の問題

システム運用の監視に当たる MIDS 及び MHRT の体制や伝達・調査手法には、以下に述べる不備や限界があり、その結果、ATM 処理区画閉塞の確認が遅延した可能性がある。
（ⅰ）障害発生時における調査体制及び対応の迅速性の問題
MIDS においては、システム運用の監視対応を 4 班体制・12 時間交替で行うことにより、
24 時間 365 日監視を実現している。しかし、MIDS が検知したエラーメッセージの伝達を受ける MHRT のプロジェクトデザイン本部や IT インフラ本部の各担当者は、MIDS の担当者とは異なり、MHRT 品川シーサイド事務所において 24 時間 365 日体制で対応することまでは求められていない。そのため、MHRT 担当者が営業日外又は営業時間外である等の理由で当該拠点外にいる場合、MIDS からの伝達を受けた後、リモートワーク環境下での対応又は当該拠点への駆付けによる対応が行われることになる。
上記のとおり、MHRT/IT インフラ本部では、16 時 22 分に定期性預金システムのメモリ拡張が完了し、定期性預金システムのサービスを再開した後も ATM が復旧しなかったために

90

12 時 14 分までに ATM 処理区画 1 系の全区画、12 時 27 分までに ATM 処理区画 2 系の全区画、12 時 50 分
までに ATM 処理区画 3 系の 17 区画がそれぞれ閉塞した。
91
ATM に関するものに限る。

73

ようやく取引共通システムの過去ログの調査が開始されたが、ATM 処理区画閉塞の事実の認識まで時間を要した要因の一つには、当該ログ調査を行うことができる知識のある担当者の MHRT 品川シーサイド事務所への到着が 14 時頃となったことも挙げられ、障害発生時における調査体制に ATM 処理区画閉塞の確認が遅延した一因がある。
（ⅱ）MIDS におけるエラーメッセージの検知体制及び MHRT への伝達手法に限界があること
上記のとおり、9 時 50 分から 10 時 5 分の間に、およそ 6,400 件のメッセージ（2 月 28 日
全体ではおよそ 9 万件）が発生し、24 種のエラーメッセージがシステム復旧対応を迅速・的確に行う上で重要であった。仮に、10 時 0 分頃にエラーメッセージが全て伝達されていれば、取引共通システムにおけるパーコレートエラーの発生が認識され、早期に 2 月 28 日
障害の原因が特定された可能性が高い。
この点、これら全てのエラーメッセージが MIDS から MHRT に正確に伝達されたのか否かについては、電話による口頭の伝達であったこと、電話のメモや録音が残されていなかったことから、本調査によっても明らかにすることはできなかった。しかし、結果的には MIDS
において検知された 24 種のエラーメッセージのうち、取引共通システムにおけるパーコレ
ートエラー発生を示す重要なメッセージは、MHRT において組織として認識されていなかった。
この点、大量のメッセージが極めて短時間のうちに生じた場合、MIDS では僅か 2 名の監視員が一画面に 34 メッセージまでしか出力されない仕様となっている統合運用基盤システ
ムの画面をスクロールしながら目視で確認した上、初報とすべきエラーメッセージを抽出して印刷し、オペレーターに対し当該エラーメッセージの ID が印刷された紙を交付し、オペレーターは、マニュアル上のメッセージ一覧表に記載された対処方法に従い、指定された
MHRT 担当者の電話番号に電話し、口頭で、当該エラーメッセージの内容を伝達することとされていた。他方、電話を受けた MHRT の担当者は、伝達を受けたエラーメッセージ ID の記
録をするなどの義務は課されていなかった。
上記の MIDS における監視体制や MHRT への伝達体制では、特に大量のエラーメッセージが一斉に生じるような場面においては、エラーメッセージを迅速、正確かつ網羅的に検知し、伝達すること、そして、MHRT 担当者においてもこれを網羅的かつ正確に受領することは、
いずれも容易でなかったものと思われる。すなわち、その伝達手法には限界があったといえる。
MHRT が使用している NOI システムを通じてシステムログのエラー発生状況をクラウド経
由でメール等により受領する仕組みも、上記のとおりクラウド上の情報流通に制限があり、また、リアルタイムで全量を共有するシステムではなかったため、当日もシステムログのエ
ラー発生数が上記のとおり短時間のうちに大量に出力されたことにより、9 時 50 分頃の状況が 12 時頃に初めて当該メールで共有されたものもあり、迅速かつ正確な情報の伝達手法
74

とまではいえない。
（ⅲ）MHRT 内での調査手法の不備・限界
2 月 28 日障害発生時、MHRT においては品川シーサイド事務所に設置された統合運用端末に検知されるエラーに関する情報を、迅速・確実に認識して対応に当たることを可能とする
人的態勢をとるべきであったが、それがなされていなかった。前記のとおり、9 時 50 分に、
MHRT の品川シーサイド事務所に設置されている統合運用端末に出力されているパーコレー
トエラーに関するエラーメッセージ等について、MHRT がこれを認知し直ちに対応したことは確認できなかった。
その後、MHRT の各担当者は、本番環境から開発環境へ転送されるシステムログを確認し各担当分野（定期性預金システム、取引共通システム等）に関する調査を開始したものの、大量のエラー発生状況に対しシステムログを一つひとつ確認していくこととなり、また、重大エラーについて、アラートを発出するなどの仕組みやツールが準備されていなかったた
め、大量のシステムログの検証には時間を要することとなった。そのため、各担当分野においてある程度の想定を行った上で、個別に調査・対応をしていかざるを得ず、MHRT における情報の集約・分析と MHBK/IT・システム統括第一部への共有が困難な状況となっていた。
また、MHRT/IT インフラ本部 IT インフラ第 1 部においては、14 時 0 分に取引共通システムのログ調査を開始した後、過去のシステムログから 9 時 50 分に発生していたパーコレート
エラーの発生に係るエラーを発見し、ATM 処理区画の閉塞を認識する 17 時 10 分までに 3 時
間以上を要することとなった。このように、MHRT 内での検知・調査手法には限界があり、エラー発生状況を迅速・正確かつ網羅的に把握した上で、俯瞰的な障害発生状況の認識と原因分析に繋げることができず、それが ATM 処理区画の閉塞の確認及び復旧措置を遅延させた原因の一つであることは否定できない。
（ⅳ）システム運用監視の実効性を検証し高める訓練等の不足
上記の MIDS によるエラー検知、MHRT への伝達に係る体制や手法が大規模な障害への対応
において実効性を持つか否かは、訓練等により、最も対応が困難な体制において大規模障害が発生する事態も含め様々な事態を想定して検証し、必要な改善を図るなどの工夫が必要であったが、MHBK・MHRT・MIDS においてそのような訓練等がなされた形跡は見あたらなかった。
また、2019 年 8 月 19 日付 MHBK の IT 戦略推進委員会では、本システム構築後の障害対応につきシステム障害管理運営要領に基づき MHBK や MHRT の横断組織にて一元的に管理し必要な対処を実施するとともに、関係各部に対する迅速かつ緊密な連絡･連携を継続する旨が確認されていた。しかし、このような MHBK、MHRT 及び MIDS 各社における緊密な連絡・連携体制の実効性を検証するために有用なグループを横断した関係各部によるシステム障害対応を想定した訓練は、2018 年 4 月及び 5 月に行われた C-Base 及び STEPS からの移行に備え75

た各グループ共同訓練以後は実施されていなかった。さらに、MHBK「システム障害対応の手引き」に従った訓練も実施されていなかった。
このような訓練等の不足も、2 月 28 日障害で運用監視体制が十分に機能せず、結果として閉塞した ATM 処理区画の再起動の遅延に繋がった可能性がある。
ⅱ

システムリスクへの対応体制の問題

上記②及び③の取引サービス禁止機能に係る作動条件の緩和又は定期性預金システムの切離し及びメニュー抑止に関する措置の遅れ（システムに対する入力の制限措置対応の問題）の原因としては、以下の点が考えられる。
2 月 28 日障害発生時においては、
定期性預金システムの取消情報管理テーブル INDEX FILEの容量超過は関係者で共有・認識していたものの、定期性預金システムからの詳細なエラー
状況、取引サービス禁止、CIF 排他等の情報、ATM における通帳・カード取込み、ダイレク
トのエラーといった複数の情報を関係者で集約しないまま、自らの担当分野において個別に調査を実施した。その状況下で、その時点までに得た情報や各担当者が有する知識を基に、それぞれがある程度の想定を行った上で、対応及び指示がなされ、結果として、各担当者レベルでは不足した情報の中での対応を迫られており、その結果、俯瞰的な障害発生状況の認
識とその認識に基づく正確な原因分析を行うことができなかった。
また、取引サービス禁止機能の作動条件の緩和が実施された背景には、過去事象の対応でそれが有効であった旨の記憶が当該変更等を行った担当者に残っていたとのことであるが、2 月 28 日障害に関して個別に取引サービス禁止機能の作動条件の緩和の影響を具体的に検討した形跡は確認できておらず、一方でその後に取引サービス禁止機能の作動条件の緩和と矛盾するともいえるメニュー抑止や定期性預金システムの切離しを行っており、障害復
旧対応に一貫性がない。また、取引共通システムのログ調査についても、原因分析に直結する部分のログ調査を開始したのはログ調査開始後から相当の時間を経てからとなっており、この点も対応が適切であったとはいえない。
これらは、俯瞰的な障害発生状況の認識と適切な障害復旧対応のリスク分析ができていないこと、それを担う体制が機能していなかったこと、が要因となっていたと考えられる。
（イ）顧客対応関係ⅰ

2 月 28 日障害による顧客影響の想定・認識の甘さ

システム障害は一定程度避けられないとしても、2 月 28 日障害には、顧客影響の想定や認識の甘さが全社的に見て取れる。すなわち、ATM センターが発出した「緊急一報メール」を受領した MHBK 本部の各部署において、その重大性の認識が甘く、これを顧客影響の拡大防止に繋げることができなかった（下記（ⅰ））
。次に、MHBK/IT・システム統括第一部を含む MHBK 本部の各部署が、ATM における通帳・カードの取込みの仕様や取込みに対処する ATM
センターの体制を十分に理解しておらず、ATM エラーが通帳・カードの取込みに繋がること、
76

及び取込みが広範囲に発生した場合に ATM センターの対応に限界があることを想起できなかった（下記（ⅱ））
。さらに、MHBK 本部の各部署は、「緊急一報メール」受領後も、早期に顧客影響を把握し、その拡大を防止するための具体的な措置を採らなかった（下記（ⅲ））
。
このような MHBK 本部の各部署の認識・対応は、下記に見るように、銀行に社会的役割として求められる、顧客の利益を最大限に尊重する責務を十分に果たしたとは評価できないものであった（下記（ⅳ））
。
（ⅰ）
「緊急一報メール」の意味がよく理解されなかったこと
上記第 4・1・
（1）
・イ・
（イ）
・ⅲ・
（ⅱ）の「緊急一報メール」は、10 時 15 分、MHBK の企
画管理部、事務企画部、IT・システム統括第一部、個人マーケティング推進部、CC 部等の担当者に送信され、さらに、RB 業務部、RB 推進部に回付されたが、このメールから顧客影響を想起して顧客対応に動く担当者はいなかった。
そもそも「緊急一報メール」は、上記第 4・1・
（1）
・イ・
（イ）
・ⅲ・
（ⅰ）のとおり、ATM
取引不能が頻発した場合に限って送付されるものであり、同メールが送付されること自体が、緊急かつ深刻なインシデントの発生を意味する。したがって、「緊急一報メール」を受信した MHBK 担当者の顧客影響に対する感度が高ければ、同メールを受信しただけでも、重大な顧客影響が発生している可能性に思い至り、より迅速に顧客影響に対応できたはずである。さらに、その後、MHBK 本部の各部署は、ATM で通帳・カードの取込みが発生していることやそのことにより立ち往生を余儀なくされている旨の SNS 投稿があること、また、ATM
センター及びコールセンターでの受電状況等を把握したことから、「緊急一報メール」とこ
れらの情報を合わせれば、顧客影響の存在を認識できたはずであった。しかし、実際に「緊急一報メール」を受領しその後対応に当たったいずれの部署も、顧客影響に対する認識が十分でなく、適時に顧客影響の拡大を防止する対応をとることができなかった。
むしろ、「緊急一報メール」の「監視システム上は ATM 正常稼働ながら」の文言に引きずられ、ATM は正常稼働だと思った、という担当者が多かった92。
（ⅱ）通帳・カードの取込み仕様の理解が不十分であったこと
顧客対応部門及び IT システム所管部署において、どのような場合に ATM が通帳・カードを取り込むのか、理解している担当者は少なかった。ATM の仕様を所管する個人マーケティ
ング推進部の担当者でさえ、データの不整合が起きる懸念のないケースにまで取込みが起きるとは知らなかったなどと述べている。したがって、ATM エラーとの報に接しても、取込みを想起することが難しかったのではないかと思われる。

92

実際に ATM 自体の故障でないことが本件の顧客影響を拡大している。すなわち、残高照会及び暗証番号の変更を除き、「いらっしゃいませ」との画面表示のある ATM を顧客が操作すると、その取引が閉塞区画に割り振られた場合に通帳・カード取込みが発生して ATM が稼働停止となる（画面表示は「現在取扱いを停止しています」となる。
）。そして、取り込んだ通帳・カードが回収されて ATM が復旧した際には、再度「いらっしゃいませ」との画面表示に切り替わる。

77

仮に想起できたとしても、「その場合は、顧客がオートフォンで ATM センターに連絡して、必要なら警備員が対処する」との認識であった。しかし、実際には、ATM センターは、休日に平均 7 名が 8 時間勤務する受電体制であったところ、オートフォン経由でのオペレータ
ーによる通帳・カードの返却対応に 1 件あたり平均 15 分程度を要することを踏まえれば、
リモートでの対応が可能な件数は、ATM センターで 1 日あたり 224 件にとどまる（4 件×8
時間×7 名）。
また、ATM センターでは、通常どおり、オートフォンが繋がった顧客に対してリモートで取り込まれた通帳・カードの返却と復旧を行っており、復旧後に次の顧客がその ATM を操作すると、再び取込みが発生するという事態が生じた。ATM センターは、あくまでマニュアルに従って上記対応を行っていたものであるが、再度の取込みの事実は認識しており、同セン
ターを所管する事務企画部が、積極的に ATM センターから情報を得ようとしていれば、再度の取込みの事実も捕捉できたはずである。仮に、再度の取込みの事実を捕捉できなかったとしても、積極的に情報収集をして、大量の取込みが発生していることを認識していれば、個別の回収作業で解決するような日常的な単発の取込み事象とは異なる状況であると認識できたはずであり、返却と復旧により、取扱い停止表示が消え、同じ ATM で再度の取込みを誘発する可能性があることも想像できたはずである。
上記第 4・1・
（2）
・ア・
（オ）
・ⅰのとおり、2018 年 6 月に、1,821 件の通帳・カードが ATMに取り込まれる事象があり顧客からの苦情も発生したところ、その際、適切に検討が行われた上で各所管部署に展開されていれば、この点に関する社内の意識を喚起する契機となったはずであったが、そのような動きはなく、取込み仕様に関する理解は進まなかった。
（ⅲ）顧客影響の想像力が不足していること「緊急一報メール」は、上記第 4・1・
（2）
・イ・
（イ）
・ⅰ・
（ⅰ）のとおり、その内容が十分理解されなかったが、MHBK の各部署は、何らかの問題が発生したことを認識して、部内で情報共有したり、出勤したり、それぞれに対応を開始した。しかし、どの部署も、IT シス
テム所管部署から情報を収集することに注力し、顧客への影響やその拡大を抑止することにはなかなか思いが至らず、取り組まなかった。
まず、ATM センターを所管していた事務企画部では、「緊急一報メール」受領後にシステムエラーの内容把握を優先し、ATM センターの入電状況に関する問合わせはしていたものの、11 時 12 分に通帳・カード取込みについての SNS 投稿を把握した後も、すぐに ATM センターに対して顧客影響に直結する通帳・カード取込みの件数等を問い合わせなかった。
次に、ATM のシステムを所管していた MHBK/IT・システム統括第一部は、障害対策の立案、提案、関係先への連絡等の対応のとりまとめを行うこととされており、上記第 2・3・（3）・イ・（イ）のとおり、システム障害管理運営要領上、システム障害のランクや業務影響等を78

「一報93」として経営陣を含む必要な関係者に報告することとされていた。しかし、MHBK/IT・システム統括第一部は、「緊急一報メール」で ATM のエラーを把握した後、主にシステムのエラー原因究明・復旧について優先して対応した結果、ATM 停止台数や通帳・カードの取込
み件数、呼損率といった顧客影響に直結する業務影響に関する情報の収集は午前中には行われなかった。そして、上記第 4・1・（1）・ア・（イ）のとおり、12 時 47 分に、ATM における業務影響に関する内容が不明確な「障害報告メール」を発信するにとどまった94。
さらに、店舗外 ATM を所管する個人マーケティング推進部は、12 時 30 分頃にはコールセ
ンターにおける顧客への対応を「取り込まれた通帳・カードについては、必ず後日返却する
ため、ATM を離れてもらって構わない」という方針に変更していたが、コールセンターに電話が繋がらず、障害を生じた ATM の前で待たされている顧客に上記方針を伝えるという発想に至らず95、関係部署に同様の対応を促すこともしなかった96。
RB 推進部でも、上記 10 時 15 分の「緊急一報メール」受領後、遅くとも正午までに、通帳・カードの取込みの発生や SNS での投稿、ATM センター及びコールセンターでの受電状況を把握していたが、14 時 25 分に営業部店長への出勤を要請するまで営業店に対して具体的な指示を出さなかった。しかし、遅くとも正午の時点で、通帳・カードの取込みの発生と ATM
センターやコールセンターの高い呼損率を把握していたのであるから、ATM の前で立ち往生
せざるを得ない顧客がいたことは想像できたはずである。
以上のように、MHBK が休日夜間も含めて ATM を通じて多くの顧客にサービスを提供しているにもかかわらず、MHBK 本部の各部署は、いずれも顧客影響に思いが至らず、これを最小限にとどめる対応をとらなかったことは、顧客影響の認識の鈍さの表れである。
加えて、ダイレクトにおいて、決済取引に関して当日中に処理ができず保留となった取引
が 224 件生じているところ、これについての顧客への説明の連絡が当日中に行われず、翌日以降の対応となっている。この保留となった取引の明細は、当日中に MHBK において把握できたものであり、この顧客への連絡の遅れも、一人ひとりの顧客に対する意識が希薄であったことの表れといえる。
93

規程上、「一報」の趣旨は、「システム障害により、当行やみずほグループのお客さま、営業店（拠点）、ユーザー部署に影響が出た場合、システム所管部門のみならず、銀行全体・グループ全体として迅速・適切な対応を行い、業務影響（特に対顧影響）を極小化する必要があるため、システム所管部署から、経営陣を含む必要な関係者に、業務影響内容、システム復旧目途等を報告する」点にあり、「詳細な業務影響や復旧目途が調査中や不明であったとしても、できる限り速やかに検知報告を行うこと」とされていた。
94
12 時 47 分の一報には、当時原因と推測されていた、定期性預金取引関連のエラーが 197 件（検知日時とした 10 時 59 分時点で認識していた取引がエラーとなった CIF の件数）発生しているという内容の報告にとどまり、業務影響として、ATM エラー件数、ATM 停止台数、通帳・カード取込み件数といった情報は記載されていなかった。
95
上記第 4・1・
（1）
・イ・
（イ）
・v・
（ⅱ）のとおり、ATM センター同様、コールセンターでも多くの呼損が発生しており、2 月 28 日 12 時から 15 時までの呼損率は約 90％であった。
96
本件取込みに対して WEB 窓口に寄せられた苦情の中には、耳が聞こえないためそもそもオートフォンの使用が困難であるとの申告も見受けられた。上記第 4・1・
（1）
・イ・
（イ）
・ⅲ・
（ⅰ）のとおり、ATM 障害が発生した場合、ATM に設置されたオートフォンを使用して ATM センターに架電をすることが原則的な対応となるが、何らかの理由でオートフォンを使用できない顧客が活用できる代替手段は用意されていなかった。この事実からも、MHBK の顧客に対する意識の希薄さを読み取ることができる。

79

（ⅳ）本来銀行に求められる顧客利益を尊重する姿勢からの乖離
上記第 4・1・
（2）
・イ・
（イ）
・ⅰ・
（ⅰ）及び（ⅱ）のとおり、本件取込みに関する MHBKの対応からは、事前準備及び当日の対応のいずれの局面でも、顧客影響に対する意識の鈍さが見て取れる。この点、銀行は、私企業として経営される経済主体である一方で、社会イン
フラとして利用される公共性から、一般公衆が安心して資金を預けられる環境を整備することが求められる97。
これは、銀行に対して金融庁等が提示する種々の監督指針等にも表れている。本件取込みに関連するものをいくつか例示すると、FISC「金融機関等のシステム監査基準」（2019 年 3月）によれば、策定されたコンティンジェンシープランにおけるリスク分析の十分性の判断のチェックポイントとして、ユーザー部門等がリスクの発現による影響の評価や業務の優先順位づけに参画しているかという視点が示され、顧客により近い立場からリスク評価に（2020参画することが要求されている98。また、金融庁「主要行等向けの総合的な監督指針」
年 12 月）によれば、システム統合に伴うリスクについて「単にシステムの開発にかかわるリスクに限られるのではなく、事務（ユーザー）部門における事務処理対応、営業店における顧客対応等の『事務リスク』の分野を広く包摂したものであって、対象銀行の経営陣の責任において、『顧客利便』を最重要視した複合的なリスク管理が求められている点が重要である。」と記されている99ところ、その点はシステム更改等に伴うリスク管理にも妥当すると考えられる100。さらに、同監督指針は、システム障害発生時において「顧客に対し無用の混乱を生じさせないよう、適切な措置を講じているか」という着眼点で対応を検討する必要があることを明記している101ところ、日本銀行「金融機関における業務継続体制の整備について」（2003 年 7 月）では、危機時に銀行が優先してリソースを投入して業務を維持するべ
き重要事項として、「顧客に対する現金払出や送金依頼の受付」という顧客に直接関連する業務が例として掲げられている102。
このように、銀行はその社会的役割として、顧客の利益を最大限に尊重する責務を負っており、システム障害に対しシステムを復旧すればよい（復旧を待つ）との発想ではなく、並行して顧客への影響をいち早く解消するという対応が求められる。本件取込みのような緊急事態においては、顧客の混乱や顧客への影響が生じやすいことから、顧客利益への感度が97

小山嘉昭「銀行法精義」（一般社団法人金融財政事情研究会、2018 年 5 月）55 頁等。
FISC「金融機関等のシステム監査基準」（2019 年 3 月）385 頁。それによれば、コンティンジェンシープ
ラン策定時におけるリスクの洗出しに際しても、「広範囲に重大な影響等を及ぼすようなシステム等の障害については、時限性や社外への影響等にも留意されているか」という視点が要求されている（同頁）。
99
金融庁「主要行等向けの総合的な監督指針 本編」（2020 年 12 月）267 頁（Ⅲ-3-9-1-2（1）③）
。
100「システム統合リスク管理態勢に関する考え方・着眼点（詳細編）」（2019 年 3 月）1 頁。
101
金融庁「主要行等向けの総合的な監督指針 本編」（2020 年 12 月）255 頁。
102
日本銀行「金融機関における業務継続体制の整備について」（2003 年 7 月）4 頁。また、現時点では廃止されているが、金融庁「金融検査マニュアル（預金等受入金融機関に係る検査マニュアル）」（2017 年 5月）の「オペレーショナル・リスク管理態勢の確認検査用チェックリスト」でも、危機時の業務継続に関す
る BCP において上記事項が重要業務とされているかが検査対象とされていた。
98

80

とりわけ重要となる。
この点、MHBK は、ホームページに掲載した「経営からのメッセージ」において「役職員一人ひとりが“お客さま起点”を徹底し、自ら考え・行動すること」を標榜している103。また、
MHFG も、その企業理念として謳う「みずほ Value：役職員が『ビジョン』を追求していくう
えで共有する価値観・行動軸」の第 1 番目に、「お客さま第一」を掲げている104。
しかしながら、本件取込みに対する実際の対応が顧客利益を尊重する姿勢に基づいていたと評価できないのは上記のとおりである。情報の不十分性や下記のマニュアルの不足など、顧客対応が後手にまわった個別の理由があることは理解し得るが、システム障害に限らず、原因や経過が直ちに判明しない事象による顧客影響は起こり得る。顧客の利益を最重要事項の一つとして深く認識していれば、マニュアルが整備されておらず、断片的な情報しかなかったとしても、いかなる顧客影響が発生し得るのかという点に思いを馳せ、より積極的な対処ができたはずである。
ⅱ

休日の ATM 障害に対する顧客保護の備えの薄さ（ⅰ）リスクの洗出し・事前準備が不十分であったこと
BCP 策定に際しては、自然災害や重大な自社システムの障害等のリスクが発現することにより、業務にどのような影響を与えるのかというリスクの洗出しを行うことが重要である。
その際には、時期・時間帯による差異や影響が段階的に進展したり、長期にわたって継続したりする状況等も考慮する必要がある105。
MHBK は平日の夜間や休日も含めて ATM サービスを提供しており、休日のインシデントであっても ATM サービスに直接影響を与えることは明らかである。加えて、MHBK の ATM 仕様
上、システム障害によって通帳・カード取込みが広範に発生する以上、それが休日に発生した場合には、通常の対応窓口である ATM センターの対応能力を超え、通常の手順では適時の顧客対応（通帳・カードの返却等）ができない事態に至る可能性があった。しかし、MHBK では、自然災害により ATM 取引業務が不能となる場合を想定した BCP は多数存在するものの、それが業務時間外（休日）に発生することを想定した BCP は 1 件（事務 736）のみであった。
また、上記事務 736 を含む BCP の内容も、システム障害等による影響が段階的に進展し、それが休日等業務時間外であることにより、ATM センターのオートフォンによる顧客対応ではカバーできない規模の通帳・カード取込みが発生するリスクを想定した内容とはなっていなかった106。さらに、ATM 監視業務の委託先である BCSOL、JBO においても、休日に入電過
103

MHBK ホームページ（https://www.mizuhobank.co.jp/company/info/management/index.html）
MHFG ホームページ（https://www.mizuho-fg.co.jp/company/policy/ci/index.html）
105
FISC「金融機関等のシステム監査基準」（2019 年 3 月）385 頁参照。緊急事態（リスク）の洗出しに関しては、FISC「金融機関等におけるコンティンジェンシープラン策定のための手引書（第 3 版追補 2）」87 頁
以下も参照。
106
ATM センターの通常の体制では対応しきれない規模の通帳・カード取込みが発生するリスクについて洗出し・評価ができていれば、ATM センターの待ち呼や呼損数増加、ATM 稼働停止台数といった兆候を正確に10481

多となった場合を想定した十分な BCP は策定されていなかった107,108。このように、原因となるインシデントの内容にかかわらず、
MHBK の ATM 仕様や ATM センター体制等を踏まえて、通常の体制では対応できない規模の通帳・カード取込みが発生するという顧客影響までを想定した事前準備が十分ではなかった。
また、MHBK（事務企画部、個人マーケティング推進部、IT・システム統括第一部）は、BCSOL及び JBO との間で毎月 1 回、ATM 監視業務に関する会議を実施しており、上記第 4・1・
（2）
・
ア・
（オ）
・ⅰの 2018 年 6 月のシステム障害を含む呼損が発生した場合の報告や、コンティ
ンジェンシープラン等の定期的な見直しが検討されていたものの、2018 年 6 月のシステム障害の後も、休日のシステム障害等により、通帳・カードの取込み件数が ATM センターの対応能力を超える事態に至るリスクについての議論、それを踏まえた BCP の見直し等の事前準備・対応策の検討も十分になされていなかった。
以上のように、BCP において、ATM 障害が休日に発生した場合のリスクを十分に把握できておらず、それを踏まえた対応が準備できていなかったといえる。
（ⅱ）危機対応に関するルール・運用及び訓練が不十分であったこと
MHBK では、システム障害が発生した場合の具体的な対応や役割分担等について「システム障害対応の手引き」が定められており、顧客対応等、関係部署はあらかじめ定められた役
割に応じて行動する一方、障害発生時の具体的な初動対応として、情報共有のために設置される「総合対策ルーム」への参集109後に、企画管理部を中心に、関係部署との協議の上で当該障害の内容等を踏まえた各部の役割分担を改めて決定することも可とされている。当該手引きでは障害対応の基本方針として、障害内容や影響（対顧・行内）といった情報の収集・集約・共有化が初動対応における最重要事項であるとされ、とりわけ、初動としてスピード把握して、そのような事態の変化を速やかに把握できるような体制を整備し、取込みの規模によっては、オートフォンで対応できない顧客に対し、何らかの手段で取り込まれた通帳・カードの後日返却が可能である旨の情報を届けるため、コールセンター等による応援や、他の手段による告知（ATM 画面による告知、
オートフォン自動音声による音声案内等）を検討するといった事前準備が可能であった。
107
BCSOL 及び JBO が策定した ATM センターBCP には、入電過多の場合に東京と大阪で補い合うプランが存在したものの、本件のように、ATM センターいずれも入電過多、呼損率上昇となった場合が想定されていなかった。
108
事務企画部は、委託した業務を円滑及び適正に運営する観点から、委託先である BCSOL 及び JBO が行う業務の遂行状況を管理する必要があり、具体的には、ATM 監視業務における委託先のリスク管理等に対する評価や、ATM センター側における業務遂行状況の定期的なモニタリングを行うことが求められる（FISC「金融機関等コンピュータシステムの安全対策基準・解説書第 9 版」132 頁～135 頁、141 頁～142 頁参照）
。また、外部委託先で発生した問題やリスク管理について、定期的に報告を受け、委託元として十分な分析、評価をする必要があり、また、コンティンジェンシープランに伴う訓練実施を取り決めている場合には、訓練実施の報告を受け、その内容に有効性が伴っているのかを確認する必要がある（「システム監査基準」
373～374 頁参照）。
109
システム障害発生の一報後の初動として、障害内容の把握・共有化及び影響（対顧・行内）の把握・共有化の体制構築として、IT・システム企画部は IT・システムグループ間における情報収集・集約や対策の検討を行うシステム対策ルームを決定・指定して、企画管理部に連絡し、企画管理部は、システム障害の影響が複数部署に跨がる場合など必要に応じて、IT・システムグループ以外の本部部室における情報収集・
集約や対策検討を行う総合対策ルームを決定し、関係部署を参集させることとされていた。

82

を重視し、躊躇せず報告・共有、迷ったら集まることといった点が強調されている。もっとも、当該手引き上は、総合対策ルームとして会議室等を指定するなど、物理的参集を前提とするようにも読める記載となっていた点で、特に休日や業務時間外等、物理的な参集が難し
いようなケースにおいては、初動におけるスピード重視に必ずしも繋がっていなかった。また、MHBK と BCSOL 及び JBO との間で取り決められていた緊急連絡先について、一部の部署
は連絡先が 1 名のみであり、主管の事務企画部の連絡先情報が一部更新されていなかった
110など、緊急時における BCSOL 及び JBO から事務企画部等の関係部署への連絡体制に不十分な点があった。さらに、緊急時の営業店職員への参集指示について、個別の電話連絡が行われたのみ111であり、連絡完了に約 2 時間 30 分を要したなど、休日や業務時間外等における営業店への即時連絡体制に不十分な点があった。このように、休日や業務時間外等、物理的参集が難しいようなケースにおいて、速やかな情報共有や対策の協議・決定・実行等に必要なルールが十分でなかったことは、顧客影響の拡大を招いた一因であったと考えられる。
次に、MHBK においては、休日に通帳・カードの取込みが多数発生することを想定した BCPが策定されていなかったものの、銀行休業日に、オンライン全面障害又は預金システム障害
により、ATM で預金支払が不能となるケースや、停電、災害及びその他の事由により店舗外
ATM の使用が不可となるケースで、顧客への告知や利用可能 ATM への誘導等の具体的な顧客対応を定める BCP は存在した。そのため、2 月 28 日障害に既存の BCP を応用することで、より早期に顧客影響の拡大を防ぐことができた可能性がある。しかしながら、個別の BCP において、関係部署がとるべき行動は、初期対応、暫定対応及び本格復旧後対応として区別されていたところ、初期対応は BCP 発動前の対応と位置づけられており、初期対応段階では各関係部署に対して特定の BCP 個票の適用を通知する運用となっていなかった112。このように、BCP 発動に関するルールの運用が不十分であったことにより、各関係部署が特定の BCP
個票を参照して初期対応を行うことができず113、顧客影響の拡大を招いた可能性がある。
さらに、緊急事態発生時に危機対応体制が十分に機能するためには、平時から緊急事態を想定した実効的な訓練を行い、状況判断と意思決定力を強化することが重要である。その際、訓練をする者に対し、何を優先順位として行動するかを意識させることが実効性の向上に

110

MHBK の緊急連絡先として事務企画部、IT・システム統括第一部、個人マーケティング推進部等が規定されていたところ、IT・システム統括第一部、個人マーケティング推進部の連絡先は 1 名のみであり、事務企画部の連絡先は 2 名であったものの、うち 1 名は更新されていなかった。
111
本件障害の発生が休日であり、社内アドレスへのメール送信の場合、部店長がタブレット端末を携行しておらず即時の社内メール閲覧はできないとの判断から、個別の電話連絡という方法が採られた。
112「ビジネスコンティンジェンシープラン運営マニュアル」では、初期対応段階において、発信部署が関係部と協議の上、速報掲示板への掲載や電話等の発信ツールを判断し、営業部店宛の障害連絡、事務処理
等指示を行うとされているものの、実際にはこのような運用がされていなかった。
113
実際に、上記第 4・1・
（1）
・イ・
（イ）
・ⅲ・
（ⅱ）のとおり 11 時 49 分及び 13 時 20 分に事務企画部部長
が部下に対して ATM センターへの警備出動要請を指示した際、事務企画部部長は、事務 736 の BCP 個票に基づく対応を想定していた旨供述しているものの、当該 BCP 個票は示されておらず、当該部下においても特定の BCP 個票は参照されなかった。そのため、当該部下から ATM センターに対しては障害発生拠点に対して警備出動を躊躇しないよう指示したにとどまり、事務 736 の BCP 個票に基づく対応は行われなかった。

83

繋がる114。しかし、MHBK では、システム障害の業務影響や顧客影響が不透明な段階における危機対応フローについて、要因別行動計画や「システム障害対応の手引き」に従い、実際に企画管理部が情報集約、統括の役割を果たす訓練は実施されておらず、BCP 訓練としては、
地震発生時（休日を含む。
）における参集訓練を中心に実施され、休日や業務時間外等速やかな連絡や物理的参集が難しいようなシステム障害のケースを想定した顧客影響の拡大を回避するための訓練は実施されていなかった。また、MHBK では BCP 個票ごとに原則年 1 回以上の訓練が実施されるが、システム障害等が業務時間外（休日）に発生することを想定した BCP（事務 736）の訓練は過去 5 年にわたって省略されていた115。さらに、ATM センターにおいても、BCSOL 及び JBO との間で年に 2 回 BCP 訓練が行われ、MHBK に対して訓練報告書が提出されていたものの、「緊急一報メール」の送受信を確認するなど形式的な訓練にとどまっていた116。加えて、MHBK、BCSOL 及び JBO の共同訓練も 2016 年117以降実施されておらず、上記第 4・1・
（2）
・イ・
（イ）
・ⅰ・
（ⅰ）のとおり、「緊急一報メール」の重要性が周知徹底されていなかった118。このように、MHBK、BCSOL 及び JBO において、業務時間外（休日）に ATM に係る障害が発生した場合の顧客対応を想定した実効的な BCP 訓練が行われていなかったと言わざるを得ない。
ⅲ

顧客の待ち時間を短くする措置の遅れ

上記第 4・1・（1）・ア・（イ）のとおり、9 時 50 分以降、通帳・カード取込みが次々と発生した。これに対する苦情内容を見ると、顧客は、システム障害そのものに対する怒りより

114

緊急事態発生時における BCP の機能不全や対応の遅延等を防ぐために、BCP に基づく教育・訓練計画を作成した上、全役職員に対する定期的、継続的な教育・訓練の実施、訓練の実施結果に対する有効性評価等を行うことが重要である（「システム監査基準」388 頁参照）。
115
訓練省略事由として「訓練を実施する他の項目と実施内容が同一である場合」が定められているところ、
事務 46（「当行オンライン全面障害、預金システム障害により、窓口での流動性預金システムの支払が不能となる（ATM も稼働していない）」ケースを想定した BCP 個票）の訓練を実施していたため、事務 736 の訓練は省略されていた。この点、システム障害等が業務時間外（休日）に発生し、ATM 取引に影響が生ずることを想定した BCP 訓練が行われていれば、「緊急一報メール」の重要性を十分に理解し、顧客影響拡大防止のための迅速な対応を行うことができた可能性がある。
116
外部委託契約等で BCP に伴う訓練実施を取り決めている場合には、訓練実施の報告を受け、その内容に有効性が伴っているのかを確認する必要がある（「システム監査基準」373 頁及び 374 頁参照）ところ、緊急事態において ATM センターから MHBK に対して具体的な顧客影響に関する情報が共有される体制になっているかといった観点から訓練の有効性が評価されていれば、上記で述べた緊急連絡先の不備や「緊急一報メール」の内容が不十分であること（MHBK、BCSOL 及び JBO の間で取り決められていた「緊急一報メール」の定型文に「ATM 正常稼働」という正常化バイアスを助長しかねない表現が含まれ、顧客影響の具体的範囲の明確化を促す内容になっていなかった等）等を把握できた可能性がある。
117
MHBK から BCSOL 及び JBO に対して ATM 監視業務の委託が開始された 2016 年に行われた初回訓練である。
118
FISC「金融機関等コンピュータシステムの安全対策基準・解説書第 9 版」23 頁において、金融機関等は委託先と共同で定期的に訓練を実施することが重要であるとした上で、訓練では、システム障害が発生した場合に、具体的な状況について即時に報告を受けられる体制となっているかを確認し、緊急事態において BCP の発動に係る意思決定を速やかに行える状態にしておくことが重要であるとされている。このような観点から共同訓練が行われていれば、MHBK において当該訓練時に、上記で述べた緊急連絡先の不備や「緊急一報メール」の内容が不十分であること等を把握できた可能性もある。

84

も、待たされたこと等銀行の対応に関する怒りの方が大きい。
通帳・カードが取り込まれた顧客に対し、「通帳・カードが急に吐き出されるおそれはな
く、立ち去って構わない。後日銀行から連絡して返却する。
」との情報が適時に提供されれば、顧客の待ち時間は大幅に縮減できたといえる。
コールセンターでは 12 時 30 分の時点で、そのような応答要領に変更しており、コール
センター以外の場（ATM センター、営業部店、Web サイト等）でも、同様のタイミングで発信できたはずである。
また、13 時 1 分には、ダイレクト画面上に「ダイレクトにおいて定期性預金取引の取扱いができない」旨、13 時 15 分には、ホームページ上に「ATM・ダイレクトにおいて一部取引が利用できない」旨の掲載がそれぞれなされたが、ここでも、立ち往生している顧客への対応はなされなかった。13 時 20 分には、事務企画部部長から同部担当者に対して、障害発生拠点か否かにかかわらず警備員を出動させる旨の指示がなされた119が、顧客対応についての具体的な指示はなされなかった120。
その後、14 時 25 分になり、ようやく、RB 推進部が、全営業部店に対する出勤指示をした
ものの、ここでもなお、単なる出勤指示にとどまり、具体的な顧客対応の指示はなされなかった。
14 時 30 分には、企画管理部が招集した関係部長会が開催され、参加部署から ATM 停止台
数（約 3,500 台：13 時時点）や ATM センターの状況（受電件数、呼損発生等）が共有されたものの、CIF 排他状態の解除及び ATM の通帳・カード取込み解消（通帳・カード返却）を優先するとの決定がされるにとどまった。
さらに、この間には、各担当者間において、ホームページ上に、通帳・カードが取り込まれた顧客に向けて、通帳・カードは後日返却可能であることや、帰宅を促す内容のメッセージを掲載することが打診されたものの、掲載文の文案の作成の過程で、作案者が定まらない、
作成された文案について各部署からのアクションがないなど判断が停滞し、結局、15 時 58分まで掲載されなかった。
そして、非常対策 PT 会議が開催されたのは 17 時 0 分であった。
以上のように、障害検知後、比較的早期の段階で、ATM 前で立ち往生せざるを得なかった顧客の存在を認識できたといえる上、実際にこれを認識し、必要な対応を行っていた部署も一部存在したにもかかわらず、ホームページ等顧客がアクセスしやすい情報源でのアナウ
ンス、営業部店への顧客対応の具体的な指示といった必要な対応を行う判断が大幅に遅れ、これが、顧客影響の拡大に繋がったといえる。

119

ATM における顧客の状況を把握する目的で、店舗内 ATM 及び店舗外 ATM（一部）には監視カメラがあり、定められた手続に従って本部においてモニタリングすることが可能であった。
120
13 時 48 分に、ATM センターへの照会が 16,000 件、カード取込みが 3,000 件及び通帳取込みが 3,000 件発生していることが関係部署に共有された。

85

ⅳ

通帳・カード取込みを防ぐ措置の遅れ

本件では、ATM は、外観上は一見正常に見え、顧客が操作することにより取込みが発生し、
なおかつ、取り込んだ通帳・カードを回収して外観が復旧した場合に、次の顧客に繰り返し
同様に取込みが発生した例が相当数見られた。
したがって、影響の拡大を防ぐには、ATM を使用停止にする措置が考えられてしかるべきであったし、このような繰返しの取込み発生は、ATM センターへの照会等により容易に知ることができ、かかる措置を検討することは十分に可能であった。しかし、取込み仕様の理解のなさや、情報収集の不十分さ等の理由から、本部において、早期にそのような検討が行われることはなかった。
この点、一部の営業部店においては、RB 推進部の指示を待たずに、ATM 停止を告知するポスターを貼る、ATM 前の自動ドアを閉鎖する、シャッターを下ろすなど、システム障害の原因や内容はわからないながら、自発的に ATM 利用を防止する措置を採っていた121。これにより、少なからず影響の拡大が防止されたと思われる。
さらにいえば、全 ATM を停止することも実施されなかった。重大な判断であり、検討に時間を要することは理解できるものの、より早期にその検討が開始されていれば奏功した可能性があり、ここでも顧客対応に向けた判断の遅れが認められる。
（ウ）組織全体関係
ⅰ

システム担当部署と顧客対応部門が連携して情報共有し、各自主体的・積極的に対応する姿勢の不足

2 月 28 日障害に際し、システム担当部署は、システム復旧に向けてシステム上の原因究明に尽力したものの、外部で生じている顧客影響の実情には十分に目を向けず、その情報収集・分析は専ら情報収集ツールから得られるシステム上の問題という視点にとどまるものであった。その中でも定期性預金システムの問題であるとの意識から脱却できない状況が当初から継続した。そのため、ATM の現状など顧客影響をも踏まえた総合的視点からの原因分析を行うことができず、顧客対応部門を含む他の部署との連携や情報共有が不十分であったことが原因分析の遅れに繋がった可能性がある。
他方、顧客対応部門も、顧客影響の状況に関する詳細、正確な情報を収集してシステム担
当部署へ提供して原因究明に資する意識を欠いたまま、システム復旧を待つ姿勢を基本としていたように見受けられる。システム上の原因究明ができない段階であっても、顧客影響
が時々刻々と拡大している現状を深刻に受け止めて、その究明を待つまでもなく、主体的・
121

RB 推進部の指示を待たずに参集した店舗が 46 店舗、同部からの出勤指示後、具体的な顧客対応の指示
がなされないうちに、独自に、ATM 停止を告知するポスター、看板等の掲示を行った店舗が 162 店舗あった。ポスターは各地の店舗で作成されたが、エリア業務役の判断でエリア内の各店舗に展開されたポスターもあった。そのほか、ATM の前で立ち往生する顧客に対し椅子や飲料を用意、店舗外 ATM を巡回し対応に窮している顧客がいないかを確認、近隣のコンビニエンスストアの ATM が利用可能かを確認するなどし、利用可能な ATM に顧客を誘導する、通帳・カードの返却の際に謝罪とともにノベルティーを交付するといった対応を自発的に行った営業部店も見られた。

86積極的に顧客影響の最小化に尽力するのは当然であって、「待ちの姿勢」は許されるものではなかった。このような部門間の連携不足や主体的・積極的な姿勢・対応の不足が、システ
ム復旧遅延及び顧客影響の拡大を招いた可能性が高い。
2 月 28 日障害においては、MIDS は、上記のとおり、10 時 0 分及び 10 時 6 分に自動機システムに係るエラーを含むエラーメッセージの検知を MHRT へ伝達したものの、MHRT では組織として自動機システムや ATM に発生している具体的な障害状況までは認識できなかった。
他方、ATM において発生したエラーは、10 時 15 分に ATM センターからの MHBK・MHRT の担当部署へ「緊急一報メール」がなされたことにより、初めて認識された。その後、MHBK/IT・システム統括第一部のチャネル系システム推進チームの担当者らは、ATM センターの担当者
から ATM におけるエラー件数等を都度確認し、MHRT 第 2 事業部第 1 部も ATM におけるエラ
ー件数を検知し MHBK/IT・システム統括第一部へ報告していたものの、MHBK/IT・システム
統括第一部内で情報共有が適切に行われなかった。その結果、システム障害管理運営要領上、MHBK/IT・システム統括第一部は、障害発生・検知後速やかに（原則 1 時間以内を目途に）、システム障害のランクや影響する可能性のある対応部室・顧客数の最大影響等を含む業務影響等を「一報」として展開することが求められていたにもかかわらず、12 時 47 分に同部
勘定系システム推進チームの担当者が発信した「障害報告メール」には、「A2 ランク懸念」（A2 ランク：行外に軽微かつ限定的な影響を及ぼす障害）の判定が件名に記載され、ATM のエラー件数やその内容に関する具体的な情報が欠落していた。このように、MIDS における統合運用基盤システム上のエラーメッセージと ATM センターが ATM のオートフォンや電文
メッセージを通じて収集した情報が適時・適切に集約されず、MHBK/IT・システム統括第一部内では ATM における障害発生状況に関する迅速・正確な認識が形成されなかった。他方、
顧客対応部門の対応の遅れは、上記第 4・1・（2）・イ・（イ）・ⅲ及びⅳのとおりである。
ⅱ

システム障害に係る情報を一元的に集約・分析して対策を立案・実施する危機
管理体制の弱さ

2 月 28 日障害に際しては、システム復旧を担う部署、ATM 等の顧客対応を担う部署その他の関係部門から、全社的に関連情報を一元的に、幅広く、かつ迅速・正確に収集・分析し、その結果に基づき、必要な対策を状況の変化に応じて機敏に立案・指示する組織的な危機管理が十分に行われたとは言い難い。これを担うべき危機管理室、IT・システムグル
ープ長を始めとする経営陣が各自の役割を十全に果たしたとも言い難い。その経緯は以下のとおりである。
MHRT が自ら又は MIDS から収集した本システム上のエラー発生状況に加えて、ATM センタ
ーからも ATM 障害発生の情報共有をうけた MHBK 内では、IT・システム企画部や同統括部、事務企画部や企画管理部危機管理室といった関係部署間の情報提供と照会が錯綜し、障害の発生及びその後の推移に係る情報を適時適切に共有し、障害の全体像を俯瞰的に把握することが困難な状況となっていた。また、MHBK/IT・システム統括第一部内においても、上87

記第 4・1・
（2）
・イ・
（ウ）
・ⅰのとおり関係各所から収集した情報の分析が迅速には行われておらず、同部がシステム障害管理運営要領に基づく「障害報告メール」を発した時点で、複数のシステムエラーが検知された 9 時 50 分から既に 3 時間もが経過し、また、その内容も ATM 障害の発生・拡大状況に係る情報を共有するものとしては不十分であった。その結果、ATM 障害の現状は、SNS で拡散された情報の収集により把握されるにとどまり、IT・シ
ステムグループ長への架電による状況報告は 13 時 40 分になって初めて行われ、MHBK 事業
継続管理運営要領に基づく非常対策 PT 会議も、システムエラー検知後およそ 7 時間が経過した 17 時まで開催されなかった。
事業継続管理を統括する企画管理部、特にその内部に設置されている危機管理室は、事業継続管理運営要領等の規程により、緊急事態が発生した場合には「各所管部からの報告を受け、集約した情報に関する対応策の検討を行うこと」とされていたが、企画管理部や危機管理室は、「緊急一報メール」を受領した後、自ら本件取込みに関する情報収集を試みるにとどまり、関係部署の「役割分担の調整・決定」や「対策の立案・実施の推進」を行ったとは評価できない。
また、IT・システムグループ長を始めとする経営陣も、率先して障害の対処に積極的に介入しようとする姿勢や顧客影響の詳細把握とその最小化を最優先とする姿勢は見られず、概ね現場からの報告を待つ受け身の姿勢にあった。
ⅲ

初動対応における 2 月 28 日障害影響の過小評価システム障害管理運営要領に基づく障害判定は「A2 ランク懸念」とされ、その一報は 12時 47 分に「障害報告メール」にて関係各部署に発信されている。しかし、障害の顧客に対する影響の当時の現状に照らし、過小評価であり、それが事後の対応の遅延等に繋がった可能性がある。また、システム障害管理運営要領において「障害報告メール」にはその種類として事後的に把握した情報を踏まえた経過報告（続報）を行う場合も含まれており、ATM における取込み状況を続報として再度発信すべきであったところ、システム復旧対応が後手に回る中で、続報の発信に思いが至らず、その点も極めて重大な問題であった。
上記の障害判定につき、IT・システムグループを担当する役員は、「早く伝えることを意識し、その判定内容は厳密に考えていなかった」旨を述べている。しかし、上記要領において「懸念」とは「一報する現時点の状況に見合う最大影響を考慮すると当該ランクであろうと考えるケース」とされており、可能な限り影響を大きく見積もった判断をすることが求められている。2 月 28 日障害では、当初のシステムエラー発生検知が 9 時 50 分で、システム
復旧体制は 10 時 15 分に立ち上げられていたのであり、その立上げから約 2 時間も経過した 12 時 47 分時点では、それまでに収集した情報を整理した上でより正確な判断、すなわ
ち A1 以上の判定をすべきであった。
このように、ランクが A1 以上でないと判定された結果、当該一報の共有範囲には MHBK 頭
取及び副頭取（ただし IT・システムグループ長を除く。
）は含まれないこととなり、MHBK 経
88

営陣への情報共有が遅れ、MHBK 頭取は自らインターネットニュースを見ることにより 13 時
30 分に自行 ATM に障害が発生している旨の情報を認識するに至った。
ウ

上記ア及びイに通じる構築後の MINORI 運用管理体制の脆弱化

2 月 28 日障害発生の契機となった e-口座一括切替処理の開発工程には、MINORI 開発の知
識・経験のある者など、e-口座一括切替処理の直接的な原因となった取消情報管理テーブルの INDEX FILE について厳密なキャパシティ管理が必要である旨を認識し得た者も少ないながら参加している。しかし、実際には、一括切替処理に係るメモリ容量に関する影響調査を行わないなど、MINORI 開発時であれば当然に着目したはずのリスクを検討しておらず、そこには MHRT の各部署における技術力の低下が窺われる。
その背景には、MHRT の経営陣が、MINORI 稼働後の開発案件が減少しているなどの諸事情を踏まえ MHFG、MHBK と協議の上、MINORI 業務に従事する人員を他の組織へ異動させる人事などを進めて今日に至った点があるように思われる。
すなわち、2019 年 8 月 26 日、MHFG 経営会議において次期システムプロジェクトに係る推進・管理体制の終了・廃止を審議し（同日 MHBK 経営会議にて報告）、これを受けて、MHFG、
MHBK 及び MHRT の組織再編が行われた。MHRT の組織改編では、2019 年及び 2020 年の 2 回にわたり、MHRT 横断本部横断推進部がプロジェクトデザイン本部プロジェクト企画部へと改組された。その際、MHRT 横断本部横断推進部において担っていた故障統制の役割がプロジ
ェクトデザイン本部プロジェクト企画部に引き継がれた事実が確認できず、重大故障時に必要な故障統制の役割を担う部門が欠落した可能性がある。
また、MINORI 稼働後、MINORI に関する大規模開発が減少し、各業務に係る業務アプリケーション開発や小規模な修正が中心となっていくことに伴い、MHRT の MINORI 業務に従事する人員が減少し、グループ外の顧客を対象とするシステム関連業務や他のグループ企業への異動が行われていった122。MINORI 開発時において参加していた各ベンダーの有識者サポートも廃止された。
このような MINORI 稼働後の一連の施策が、システム開発及び運用に不可欠な技術力を次第に弱めた可能性を否定できない。

122

MHFG 及び MHBK のシステムの開発に携わる部署及び開発に関わる重要委託先である MHRT における MINORI
稼働前の 2018 年 3 月末時点と本事象①発生後の 2021 年 3 月末時点を比較すると、以下のとおり IT 人材の異動があることが認められる。
・MHRT の MINORI 業務従事者のうち、2018 年 3 月末時点で MINORI 業務に従事していた者は、1,051 名から345 名に減少（約 67％減少）。
・MHRT の MINORI 業務従事者のうち、一定職階以上の者が、253 名から 86 名に減少（約 66％減少）。
・MHFG、MHBK 及び MHTB の MINORI 業務従事者のうち、2018 年 3 月末時点で MINORI 業務に従事していた者が 92 名から 146 名に増加（約 59％増加）。
・MHFG、MHBK 及び MHTB の MINORI 業務従事者のうち、一定職階以上の者は 76 名から 65 名に減少（約 14％減少）。なお、MHRT の外向け開発（MHBK 以外の金融機関等向けの開発）の人員については、2018 年 3 月末
時点で MINORI 業務に従事していた者は 1 名から 143 名に増加、うち一定職階以上の者は 1 名から 18 名に増加となっている。

89

２

3 月 3 日障害

（１）事実概要
ア

障害の発生状況2021 年 3 月 3 日 19 時 58 分より、データセンターB において、本件ネットワーク機器内の本件ネットワークカードが故障した。それにより、同日 20 時 1 分に他系統のネットワー
クカードへ自動で切り替わるまでの 3 分間、本件ネットワーク機器が通信の遮断・接続を繰
り返し、通信状態が不安定となる障害が発生した。
【図 25】

本件ネットワークカードは、上記図 25 のとおり、データセンターB 内のデータセンターB
向け ATM 及びダイレクトに接続されている各サーバと、データセンターA に設置されている
勘定系システム（MINORI）及びナンバーズ中継システムとの間の通信に利用されている123。
そのため、本件ネットワークカードとデータセンターB 向け ATM に接続されているサーバとの通信状態が不安定になることにより、データセンターB 向け ATM からの取引の際に、MINORI との通信が行えなくなった。
ATM は、当該サーバとの通信が行えない場合にも、一定時間応答を待つ設定となっており、一定時間を経過しても通信が行えない場合は、通信障害が発生したものとして、通信を中断する（タイムアウト設定）。この点、MHBK の ATM においては、上記タイムアウト設定の時間

123

データセンターB 向け ATM から取引を行う際は、本件ネットワーク機器を含むネットワーク機器を介して、MINORI と通信を行うこととなる。

90

を 1 分と設定していたところ、3 月 3 日障害においては、下記図 26 のとおり、本件ネット
ワーク機器の切替に 3 分を要したため、ATM のタイムアウト設定の時間を超過し、これが原因となり、ATM において通信エラーを認識し、通帳・カード取込み124が発生した（ATM による取込み仕様は、上記第 4・1・（1）・ア・（ウ）
・ⅳのとおり。）。
【図 26】

イ

障害発生後の状況（ア）システムの復旧に向けた対応状況
本件ネットワークカードの稼働状況を監視していた本件ネットワーク機器内の制御機能が作動し、不安定な通信状態が発生した 3 分後に自動的に副系に切り替わる仕様に基づき、同日 20 時 1 分に他系統のネットワークカードへ自動で切り替わったことにより、通信状態
は正常に回復した。
（イ）顧客への障害影響及び対応状況
3 月 3 日障害により、通信状態が不安定となった約 3 分間に、①データセンターB 向け ATMから行われた取引について、通帳・カード取込みが 29 件（うち通帳 8 件、カード 18 件、通帳及びカード 3 件）発生し、②データセンターB 向け ATM やダイレクトを通じたナンバーズ

124

タイムアウトとなった取引のうち、更新系取引（残高照会等のデータを参照するだけの取引でなく、振込等顧客データに更新のある取引）については、上記第 4・1・
（1）
・ア・
（ウ）
・ⅳの表の 3 の事態が生じたものとして、通帳・カード取込みが発生した。

91

の購入取引が一部不成立となる事象が 7 件（うちダイレクト経由 5 件、データセンターB 向
け ATM 経由 2 件）発生した。
【図 27】

障害の検知後、MHBK の各関係部署に連絡が行われ、対象拠点が特定された（28 拠点・ATM29台）。また、同日 20 時 55 分から開催された非常対策 PT の開催前に、各対象拠点を管理する
営業店職員に対し拠点への急行が指示され、当日中に全対象拠点への営業店職員の駆付けが完了した。そして、当日中に警備会社、ATM センター、駆け付けた営業店職員の対応により取り込まれた通帳・カード 14 件の返却が完了し、同月 8 日までに残りの 15 件の返却（取り込まれた現金の口座への戻し作業も含む。
）が完了した。
不成立となったナンバーズ購入取引については、当日中に宝くじ部において顧客の口座からの引落としがないことを確認し、翌 4 日には、外部センターにて 7 件の取引不成立を確認した。また、同月 5 日には、全 7 件について顧客への連絡を完了した。
対外告知として、当日中に障害の経緯及び顧客対応状況に係るホームページ上の告知並
びにマスコミ各社への説明を実施した。
上記のとおり、29 件という 2 月 28 日障害時のそれに比しかなり小規模な通帳・カード取込みの件数であるにもかかわらず、3 月 3 日当日の返却件数が 14 件にとどまり、「当日にATM センターへの連絡が繋がらず帰宅した」旨の苦情が 4 件寄せられ、また、12 件の顧客は当該 ATM から離れた管理店に返却のため来店したという影響があった。
（２）原因ア

障害の発生について

故障した本件ネットワーク機器は、2010 年 3 月に導入されたシステムベンダーA の製品（販売元・保守担当はシステムベンダーB）であるところ、機器の選定経緯において故障の原因に繋がる事実は確認できていないものの、本件ネットワークカードについてシステム
ベンダーA において解析を行った結果、カード内メモリの故障が原因であることが判明した92とのことである125。
本件ネットワークカードの保守を行うシステムベンダーB からは、この種のネットワーク
カードの故障自体は避けられず、かつ、それぞれ別筐体での個別障害であり、10 年間で 4 回（3 月 3 日障害を含む。
）の故障回数は低水準であるとの報告を受けているとのことである126。
したがって、本件ネットワークカードの故障については、一般的に発生し得る機器故障の範囲内であると考える。
また、ATM のタイムアウト時間は 1 分、自動機サーバのタイムアウト時間は 55 秒であり、ATM と自動機サーバ間のタイムアウト時間についても不整合はない。
イ

障害発生後のシステム復旧遅延及び顧客影響の拡大について（ア）システム対応関係
本件ネットワークカードは、正系・副系の二重化構造となっており、ネットワークカードが完全に停止した場合には 10 秒以内に副系に切り替わる設定となっていたが、一方で、ネットワークカードが完全に停止せず、遮断・接続を繰り返す等、不安定な状態が続く場合には、通信状態を監視している本件ネットワーク機器内部の制御機能により、3 分で副系に切り替わる仕様となっていた127。3 月 3 日障害においては、本件ネットワークカードが完全に停止せず、不安定な状態が続く事象が生じたことから、副系への切替までに 3 分を要したことを原因として、その 3 分間がそのまま通信障害時間となったが、本仕様自体は不合理なものではないと考えられる。
なお、2 月 28 日障害と同様、ATM の通帳・カード取込み範囲を縮小する仕様変更が行われて来なかったことが顧客影響に繋がったことは否定できないと考えられる。
（イ）顧客対応関係
上記第 4・1・
（2）
・イ・
（イ）
・ⅰ・
（ⅳ）のとおり、MHBK には、銀行として、顧客利益を尊重する姿勢が求められている。そのため、MHBK において、3 月 3 日障害のように窓口対応

125

本件ネットワークカードは、過去に、2019 年 1 月、2020 年 6 月、同年 9 月の計 3 回故障（MHBK によると、これら過去 3 回の障害は、それぞれ別筐体における異なる個別障害であり、3 月 3 日障害と同じ不具合を抱えていたことによる障害ではないとのことである。
）を起こしているが、その際はネットワークカードが完全に停止したため、3 月 3 日障害とは異なり、10 秒以内に別系統のネットワークカードへの自動切替が行われ、業務影響は出ていない。
126
機器故障の発生率は、バスタブ曲線（時間が経過することによって起こってくる機械や装置の故障の割合の変化を示すグラフのうち、その形が浴槽の形に似ている曲線のこと。故障率曲線ともいう。
）といわれており、初期故障期と摩耗故障期に故障率は上がるものとされている。この点、MHBK は、システムベンダ
ーB から、本件ネットワークカードは摩耗故障期には移行しておらず、依然として安定稼働期にあるとの報告を受けているとのことである。なお、本件ネットワーク機器の導入時期は 2010 年 3 月、保守期限は 2021
年 7 月である。
127
タイムアウト時間 3 分という仕様は、システムベンダーA 社の設定に基づくものであり、同社のポリシ
ー上、外部からの変更は不可能とのことである。3 月 3 日障害においては、タイムアウト後は正常に副系への自動切替ができていることから、制御機能は仕様どおりに作動したものと考えられる。

93

の時間外に ATM を利用する顧客に同時多発的に通帳・カード取込みの影響が生じる可能性
及びそのような影響が生じた場合に原則的な対応として設定されているオートフォンを介した ATM センターへの受電が一時的に過密になることは想定されて然るべきであった。
しかし、実際には、上記のとおり、29 件という比較的小規模な取込みにとどまったにもかかわらず、少なくともオートフォンを介した受電で 5 件以上の呼損が発生しており、また、営業店職員又は警備会社が駆け付ける前に顧客が当日返却を諦めて帰宅し、翌日以降の来店（多くは取り込まれた ATM から離れた営業店まで出向く。
）という負担を強いられていることからすれば、上記のような顧客影響を想定した対策が欠如していたと言わざるを得ない。
このことは、2 月 28 日障害と同様に、顧客影響に対する意識の鈍さの現れであり、インフラ基盤を担う銀行である MHBK にとって、3 月 3 日障害における通帳・カード取込み件数が比較的小規模であったとしても決して軽視すべきではない。
３3 月 7 日障害

（１）事実概要
ア

障害の発生状況

MHBK は、その取り扱うカードローン商品について、一部商品を除き、カードローン規程
上に、返済が遅延した場合の遅延損害金利率を定めていたが、これまで、実際には延滞者に対して遅延損害金利率を適用せず、借入適用利率を適用していたところ、今般、これらの一部に遅延損害金利率の適用を開始するため、遅延損害金利率の適用要否を判別するための項目である「延滞フラグ」を貸越明細テーブルに追加し、カードローン商品の延滞利息徴求機能を新規構築することとした。かかる経緯において、MHBK は、2021 年 3 月 7 日に、上記
延滞利息徴求機能のプログラムリリースを行った。
このカードローン案件は、総合口座定期預金の処理自体に直接の変更をもたらすものではないが、貸越明細テーブルは、カードローンのみならず、総合口座定期預金の処理においても共通して使用されており、また、貸越明細テーブルを更新するための DB 更新用共通プ
ログラムも総合口座定期預金で使用されていたため、カードローン案件に伴い、総合口座に係るプログラムの初期化処理も必要な状況にあり、その手順としては、本来以下のものが想定されていた。
①

総合口座に係るプログラムにおいても、便宜上、「延滞フラグ」についてプログラム上正式に利用される変数として「定義128」する。

②

他方で、総合口座にはカードローンと異なり延滞という概念はないため、「延滞フラグ」
については、個別的な初期化を行い、「スペース」を代入させることで、実質的には「延滞フラグ」を利用しない形とする。

128

プログラム上で使用する変数として定義すること。定義しない変数を有するテーブルを参照すると、プ
ログラム上解釈ができずにエラーを起こしてしまうリスクがある。

94

③

この初期化処理によって、「スペース」が代入される。

④

総合口座変数値チェックが正常となり、後続の DB 更新共通プログラム呼出しが正常に行われる。

【図 28】

しかしながら、上記のカードローン案件のプログラム設計には、本来必要であった当該初期化処理の組込み漏れというミスが存在し、それに従ってプログラムが作成された。その結果、下記図 29 の変数代入処理の段階で「延滞フラグ」項目について「スペース」ではない
想定外の値が代入され、結果として総合口座に係るプログラムにおけるデータ処理チェッ
クの際に、「延滞フラグ」項目に予期しない値が代入されるケースが生じることとなり、総合口座定期入金に係る集中記帳処理時にエラーが発生した。

95

【図 29】

具体的には、下記図 30 のとおり、3 月 7 日 6 時 8 分に総合口座定期入金に係る集中記帳処理のエラーが発生し、定期預金入金取引が成立しない事象が発生した。また、同日 8 時 1分に発生したダイレクトによる総合口座定期入金でのエラーを始めとし、①ダイレクトを通じて定期預金入金取引をしようとした 14 名の顧客（うち MHBK 関係者 5 名）、②ATM を通じて定期預金入金取引をしようとした 10 名（全て MHBK 関係者）の顧客について、取引が不成立となった。
なお、本事象において当該初期化漏れのミスがあったプログラムは 8 件あったが、下記図
31 のとおり、「総合口座に係るプログラム」以外については結果的に顧客影響が無かった。
【図 30】

96

【図 31】

イ

障害発生後の状況（ア）システムの復旧状況
3 月 7 日障害において、MHBK は、同日 6 時 10 分に MHRT 開発本部第 1 事業部からエラー検知の一報を受け、8 時 20 分に緊急関係部長会を開催し、状況を確認した。MHBK 及び MHRTは、13 時 16 分に初期化処理の組込み漏れについて修正プログラムをリリースし、13 時 42分には定期預金入金取引が復旧した。かかる復旧対応について、特に問題は見受けられなかった。
（イ）顧客への対応状況
ATM 及びダイレクトにおいて定期入金取引が不成立となった顧客に対しては、エラー画面の表示、電話、メールでの連絡等の方法により、障害の発生及び取引が不成立となったことの告知や、事情説明がなされた。
また、MHBK は、取引不成立の障害が発生している状況を踏まえ、顧客の通帳・カードがATM に取り込まれる可能性も否定できないと判断し、それを防止する目的で、顧客が ATM を通じて定期預金入金取引を行うことのないように、一部のサービスを一時停止した。具体的には、MHBK は、ATM の操作画面における「定期預金」及び「振替」のメニューボタンを非表示として両サービスを一時停止する措置を講じ、同日 9 時 22 分に同措置が完了した。その後、MHBK は、通帳・カードが ATM 内部に取り込まれないことを確認できたため、11 時 27 分に「定期預金」及び「振替」のメニューボタンを再表示した。
上記のとおり、一部サービスの停止による顧客の利便性への影響があったことは否定できないものの、大規模な通帳・カード取込みの発生を未然に防止すべく、当該時点において対策を実施しており、顧客対応の観点からは、2 月 28 日障害及び 3 月 3 日障害での経験が活かされ、特に問題は見受けられなかった。

97

（２）原因ア

障害の発生について

3 月 7 日障害の直接的な発生原因は、上記のとおりカードローン案件に係るプログラムの設計ミスである。
【図 32】

具体的には、設計担当者は、既に総合口座に係るプログラム内に実装済みの初期化処理において、追加した「延滞フラグ」に関してもまとめて初期化処理が実施されると誤って認識し、個別の初期化処理の実装が必要であることを詳細設計書に記載していなかった（上記図32 参照）。
その背景には以下のような要因があった可能性が否定できない。
（ア）各工程におけるミスの看過
2020 年 1 月から 8 月中旬頃の設計・開発工程は、MHBK の開発委託先である MHRT の再委
託先（MHBK の再々委託先）が担当し、MHRT は成果物の承認を行う体制となっていた。作成
されたプログラムは、MHRT の再委託先にて再鑑者によるレビューが実施され、その結果を委託元である MHRT が確認したが、当該ミスを検知できなかった。
その後の確認工程においても、テストでは一時的な処理情報をクリアする作業を都度実施していたため、プログラムの初回起動時は「スペース」が設定されることになり、プログ
ラムミスの検知に至らなかった。また、MHRT の 1.5 線、2 線や MHBK の 2 線でのチェックも、
役割上、テストが実施済みであることの形式的な確認等を行うにとどまった。
（イ）ITマネジメントの観点
カードローン案件に係る追加開発のテスト等は、このような比較的初歩的な設計ミスを98

検知することができない程度の表層的なものとなっており、MHRT における外部委託先の管理は不十分なものであったと考えられる。また、MHRT 自身も、当該設計ミスを検知するに足りる体制構築がなされていなかったと言わざるを得ない。
イ

障害発生後のシステム復旧遅延及び顧客影響の拡大について

上記のとおり、3 月 7 日障害に関しては、システムの復旧対応・顧客対応いずれにも特段の問題は見受けられなかった。
４3 月 12 日障害（１）事実概要
ア

障害の発生状況（ア）ストレージ装置の故障
2021 年 3 月 11 日 23 時 39 分、MINORI 共通基盤 B に存在するストレージ装置内の通信制御装置が故障した。
MINORI 共通基盤 B には、下記図 33 のように、ストレージ装置が 1 号機から 4 号機まで合計 4 台あり、それぞれに複数の物理サーバ129が接続されている。物理サーバ上では仮想化ソ
フトウェアにより、複数の仮想サーバで業務システムを稼働させている（以下、単に「サーバ」という場合、物理サーバを指す。）130。
【図 33】

129

仮想サーバに対する概念として、物理的に存在しているサーバを指す。
仮想化ソフトウェア機構は 1 台の物理サーバに対して仮想的に複数サーバの稼働を実現する。仮想サー
バは仮想的に稼働するサーバを指す。
130

99

上記ストレージ装置のうち、「統合ファイル授受131」、「印鑑照合132」及び「財形金融債シ
ステム133」の 3 つの業務システムが稼働するサーバが接続されているもの 1 台（上記の 4 号機）の通信制御装置が故障したことにより、ストレージ装置とサーバの接続が切断され、当該 3 つの業務システムが停止した。
本来、通信制御装置が故障した場合には、ストレージ装置のファームウェアの機能で、自動的に他の正常な通信制御装置に接続され、業務システムによる処理に影響を与えない設計となっていた。すなわち、通信制御装置の故障時においては通常、①ストレージ装置のファームウェアがサーバからデータ取得要求を受ける、②故障した通信制御装置を切り離す、③サーバに対し正常な別の通信制御装置へ振り分けるための再接続要求を実施する、④サーバ側のドライバ134がストレージ装置への再接続を実施する、⑤ストレージ装置のファーム
ウェアが正常な通信制御装置へ振り分ける、という流れで、他の正常な通信制御装置に接続される（下記図 34 参照）。
【図 34】

しかし、サーバ側のドライバにストレージ装置からの再接続要求を続けて特定の回数以上受信すると接続不可となる不具合135が潜在していたため、3 月 12 日障害の発生時におい131

基盤（取引共通システム、融資外為基盤、定期性基盤）間のファイル送受信のハブ（中継）機能を果たす。基盤間で異なる文字コード等の変換を実施し、ファイルの受渡しを行う。
132
あらかじめ登録した印影と取引ごとに提出される伝票等に押印された印影を照合すること。
133
財形預金プラスの契約情報を管理するシステム。
134
ストレージ装置等の外部記憶装置やディスプレイモニター、プリンター等の機器を利用するためコンピューターに導入するソフトウェア。
135
上記図 34 では、通信制御装置故障後に、サーバがストレージ装置にデータ取得要求をした場合のフロ100

ては正常な通信制御装置への切り替えができず、サーバとストレージ装置の間の通信が遮断され、業務システムの停止を引き起こした。
（イ）センター集中記帳処理遅延（外為システムの送金等処理遅延を除く。
）
統合ファイル授受は、基盤の異なるシステム間でファイルを受け渡すためのシステムであり、センター集中記帳処理においては、融資外為基盤上の各システム及び定期性預金シス
テムから取引共通システム上のセンター集中記帳システムに集記依頼データを受け渡す役割を担う。上記のストレージ装置の故障に伴い、統合ファイル授受が停止したことでセンタ
ー集中記帳システムにデータの受渡しができず、後続のセンター集中記帳処理が停止した（下記図 35 参照）。
【図 35】

その後、故障した通信制御装置の交換が 3 月 12 日 3 時 50 分に完了し、4 時 20 分にサーバの再起動によりストレージ装置とサーバの接続が開始され、6 時 20 分には全サーバの再起動を完了した。上記通信制御装置の故障から約 7 時間後の 6 時 38 分に統合ファイル授受の復旧が完了した。
その後にセンター集中記帳処理を順次再開したため、関連する業務につき、平常時に比べて処理遅延が発生した。
具体的には、バンクレポートサービス136において、通常、2 時頃時点の情報で行われる口ーを示しているが、故障前に受けたデータ取得要求についてのデータ取得処理中にストレージ装置内の故障が発生した場合、当該データ取得処理について、ストレージ装置からサーバへの再接続要求が行われる。
136
主に海外に拠点のある顧客が、インターネットバンキング等において、日本国内口座の残高・入出金明細を照会するためのサービス。

101

座残高・入出金明細データの作成が行われず、顧客 186 社の合計 217 口座において 3 月 11
日 15 時以降の取引明細が欠落した形で配信されるという配信遅延、法人 EB/WEB の入出金明細配信サービス137において 3 月 12 日の朝までに更新されるべき 3 月 11 日付の明細（顧（1）・ア・（ウ）の外国為客 95 社分）が更新されない138という更新の遅延及び下記第 4・4・
替送金処理の遅延が発生した。
（ウ）外為システムの送金等処理遅延
外為システムにおいては上記センター集中記帳処理の遅延に加え、下記第 4・4・
（1）
・イ・
（ア）
・ⅱのとおり、統合ファイル授受復旧後に適切な復旧手順が取られなかったため、外国為替送金処理において、国内他行向け仕向送金 263 件が 3 月 12 日当日中の時限に間に合わず、また、外為被仕向送金139の入金案内処理 761 件が 3 月 12 日当日中に完了できなかった。
イ

障害発生後の状況（ア）システムの復旧に向けた対応状況
ⅰストレージ装置及び統合ファイル授受の復旧

下記表のとおり、ストレージ装置及び統合ファイル授受の復旧対応が行われたが、3 月 11
日 23 時 39 分に MINORI 共通基盤 B でのエラーを検知後、上記全サーバ復旧までは 6 時間 41分、上記統合ファイル授受の復旧までは 6 時間 59 分を要した。
日時

内容

3 月 11 日

MINORI 共通基盤 B のストレージ装置が故障したことを MIDS 及びデータセン

23 時 39 分

ターA に常駐している日立ハードウェア保守担当が検知

3 月 12 日

MIDS から MHRT へストレージ装置故障を報告。MHRT は日立ハードウェア保守

0 時 34 分

担当に障害部品の調査並びにストレージ装置とサーバの接続状態及び装置の交換タイミングの確認を指示

1時0分

MHBK 及び MHRT へ装置の交換タイミング及びサーバからストレージ装置への通信経路遮断を報告

2時8分

本番環境がある MHRT 品川シーサイド事務所へ日立製作所開発担当が駆付け

137

入出金明細配信サービスとは、勘定系システムで処理された入出金明細を、法人顧客が利用する各種 EB
サービスを通じて、照会又はデータ取得するためのサービスである。
138
勘定系システムで処理された入出金明細を、法人顧客が利用する各種 EB サービスを通じて、照会又はデータ取得するためのサービス。法人 EB/WEB において入出金明細を提供する方法には、リアルタイムでデータを還元する「リアル型」と、あらかじめ銀行側で定めたタイミングでデータを還元する「ファイル型」
があり、「ファイル型」のサービスにおいては、法人が、データ還元のタイミングを、「当日」と「翌日一括」で選択できる。3 月 12 日障害においては、「翌日一括」を選択している法人につき、本来 3 月 12 日朝に還元される 3 月 11 日分の入出金明細が 3 月 12 日中に還元されなかった。
139
海外又は国内のコルレス銀行から、顧客宛の送金を受領することを指す。

102

2 時 18 分

通信経路の手動での再接続に失敗140

2 時 32 分

通信経路の強制切断後再接続を試みるも再び失敗

3時0分

故障したストレージ装置内の通信制御装置の交換作業開始

3 時 50 分

通信制御装置の交換完了

4時2分

再度ストレージ装置への手動での再接続を試みるが失敗

4 時 20 分

サーバの再起動を行った結果、ストレージ装置との接続が回復

4 時 35 分

残りのサーバの再起動を手動で順次実行

6 時 20 分

全サーバの再起動完了

6 時 38 分

統合ファイル授受の復旧完了

ⅱ

外為システムにおける処理の復旧対応（ⅰ）国内他行向け仕向送金
国内他行向け仕向送金処理は、センター集中記帳処理を利用して行われるところ、大要、（b）作成（a）各システムにて集記依頼データを作成するジョブ141（集記依頼データ生成）、したデータを各システムからセンター集中記帳システムへ送信するジョブ（集記依頼デー
タ送信）、（c）センター集中記帳システムにて同データを用いて集中記帳処理を行うジョブ（集記処理）により行われる。
国内他行向け仕向送金処理における通常時のジョブの流れは以下のとおりである。
【図 36】

140
141

ドライバソフトウェアの不具合によりストレージ装置に接続できない状態が継続。
コンピューターが処理する仕事の単位を指す。

103

まず、上記（a）の集記依頼データ生成として、CIF の 0 時 0 分時点のファイル（上記図36 の①）が統合ファイル授受を経由して外為システムに受け渡された後、外為システムにて、通常 0 時 45 分から 2 時 0 分頃までに、当該ファイルに基づく国内他行向け送金データ（集記依頼データ）の作成を完了する（上記図 36 の②）。
次に、上記（b）の集記依頼データ送信として、通常 5 時 0 分から 6 時 0 分の間に行われるセンター集中記帳システムの日付変更処理及び 6 時 0 分に定刻起動される外為システムのバッチ日付変更処理の終了後、定刻 6 時 30 分に、国内他行向け送金データが外為システ
ムから統合ファイル授受を経由してセンター集中記帳システムへ送信される（上記図 36 の③）。
これらの完了により、上記（c）の集記処理として、定刻 7 時 0 分及び定刻 9 時 30 分に国、
内他行向け仕向送金142（公示レート未使用）の集記処理が実行され（上記図 36 の④及び⑤）
また、10 時 30 分頃に主要通貨の国内他行向け仕向送金（公示レート使用）、11 時 15 分頃に主要通貨以外の通貨の国内他行向け仕向送金（公示レート使用）の集記処理が実行される（上記図 36 の⑥及び⑦）。
3 月 12 日障害の発生時においては、統合ファイル授受の停止により外為システムにファイルが受け渡されず、上記（a）の集記依頼データ生成が実行されなかったため、後続の定
刻 6 時 30 分実行の上記（b）の集記依頼データ送信が異常終了した。統合ファイル授受の復
旧後、上記（a）の集記依頼データ生成は実行したものの、上記（b）の集記依頼データ送信の再実行が漏れており、上記（c）の集記処理を定められた処理時限（外貨決済につき 13 時
0 分、円貨決済につき 14 時 55 分）までに完了することができなかった。
詳細な事実経過は以下のとおりである。

142

仕向送金の集記処理は公示レート（通常 10 時過ぎに確定）を使用する取引、使用しない取引に大別され、公示レートを使用しない仕向送金は 7 時 0 分、9 時 30 分の集記処理、公示レートを使用する取引は 10
時 30 分、11 時 15 分の集記処理にて実行される。

104

【図 37】3 月 11 日 23 時 39 分から 3 月 12 日 6 時 38 分までの間、統合ファイル授受が停止していたため、CIF の 3 月 12 日 0 時 0 分時点のファイルが外為システムに受け渡されず（上記図37 の❶）、外為システムにおいて通常は 0 時 45 分に開始される国内他行向け送金データの作成が開始されなかった（上記図 37 の❷）。
外為システムの担当部署である MHRT 第 1 事業部第 2 部の要員は、MHRT 品川シーサイド事
務所に 2 時 30 分頃参集143し、復旧対応の検討に入った。具体的には、（1）障害の影響で起動できていないジョブの把握、（2）障害復旧後の当該ジョブ実行手順（リカバリ手順）の準備及び（3）バンクレポートサービスの欠落状況の調査、を行っていた。
調査の結果、上記（1）障害の影響で起動できていないジョブの把握については、障害の影響で起動できていないジョブとして、国内他行向け送金データの作成（上記図 37 の❷）及び下記第 4・4・
（1）
・イ・
（ア）
・ⅰ・
（ⅱ）の外為被仕向送金のデータ送信ジョブを把握したものの、4 時前までには統合ファイル授受が復旧するとの想定で、集記依頼データ送信が定刻実行される 6 時 30 分までに国内他行向け送金データの作成を完了できると見込み、上記（2）障害復旧後の当該ジョブ実行手順（リカバリ手順）の準備に関して、特段の措置を講じなかった。
外為システムでは、6 時 0 分のバッチ日付変更処理後、定刻 6 時 30 分の集記依頼データ送信が動作したが、この時点では統合ファイル授受は復旧しておらず、依然として集記依頼
データ生成が完了していなかったため、送信対象が存在せず異常終了した144（上記図 37 の❸）
。この間、参集した外為システムの担当は、下記第 4・4・
（1）
・イ・
（ア）
・ⅰ・
（ⅱ）の

143
その後も順次、要員が参集しているが、2 時 30 分頃に、次長と課長が到着し、既に到着していた担当を含め集結し、役割分担・指示が可能となった。
144
厳密には、データ送信ジョブが作動したが、「国内他行向け送金データ作成処理」の未起動により、当該ジョブが異常終了したものであるが、本報告書では説明を簡潔にするため、プロセスの起動については触れていない。

105

外為被仕向送金のリカバリ作業等に注力しており、異常終了を検知できていなかった。
統合ファイル授受が 6 時 38 分に復旧した後、外為システムが、統合ファイル授受を経由して CIF の 3 月 12 日 0 時 0 分時点のファイルを受領し、7 時 2 分に、国内他行向け送金データの作成（集記依頼データ生成）を自動実行し、8 時 29 分にこれを完了した（上記図 37の❹）。
センター集中記帳システムの日付変更処理が 11 時 46 分に完了し、センター集中記帳シ
ステムにおいて、遅延していた集記処理が順次、自動実行された。国内他行向け仕向送金処理については、集記依頼データ送信が異常終了しており、集記処理に必要なデータがセンタ
ー集中記帳システムに受け渡されていないため、本来であれば、この時点で、集記依頼デー
タ送信を再実行し、外為システムからセンター集中記帳システムへの国内他行向け送金データの受渡しを行う必要があった。しかし、MHBK/IT・システム統括第一部は、上記のとおり、異常終了発生時に集記依頼データ送信の異常終了を検知しておらず、また、この時点で送金処理に係るジョブのステータス確認を行わなかったため、送金処理は順次適切に実行されていくものと誤認しており、再実行（リカバリ手順）を行わなかった（上記図 37 の❺）。
集記依頼データ送信が異常終了となっており、外為システムからセンター集中記帳シス
テムへの国内他行向け送金データの受渡しがなされていなかった結果、通常定刻 7 時 0 分
起動の送金処理は 11 時 55 分、通常定刻 9 時 30 分起動の送金処理は 12 時 3 分に、それぞれ送金データ未受領の状態で実行（0 件実行）され、これにより、送金処理は完了していな
いものの、各ジョブのステータスは「実行済」となった145。
その後、MHBK/IT・システム統括第一部は、13 時 30 分頃より、国内他行向け仕向送金が未処理である旨の照会を事務企画部から繰り返し受けていたが、端末等でジョブの実行結
果とシステムエラー有無を確認し、センター集中記帳システムにて通常は定刻 7 時 0 分及び 9 時 30 分にそれぞれ実行される集記処理のジョブ実行のステータスが「実行済146」であることの確認がなされていたことを根拠に、処理の完了を待つよう事務企画部へ回答した。
MHBK/IT・システム統括第一部は、事務企画部より再度 15 時頃に照会を受けたことを契機として、初めてシステムログを見て、センター集中記帳システムの集記処理の実行状態及びその前提となる外為システムの集記依頼データ送信の実行状態を確認したところ、7 時 0 分及び 9 時 30 分にそれぞれ定刻起動される集記処理は処理件数 0 件で実行されたこと及びデー
タ送信は異常終了となっていることを認識した。これにより、外為システムからセンター集
中記帳システムへのファイル受渡しが実行されていないことがわかり、17 時 40 分に集記依。
頼データ送信の再実行が行われた（上記図 37 の❻）その結果、外為システムからセンター集中記帳システムへの「国内他行向け送金データ」

145

主要通貨での仕向送金処理、主要通貨以外の通貨での仕向送金処理については、送金データ受領が実行条件となっており、この時点で送金処理は行われなかった。
146
主要通貨での仕向送金処理、主要通貨以外の通貨での仕向送金処理については、上記のとおり、未実行
であったが、MHBK/IT・システム統括第一部は、この時点では、一定時間待てば順次実行されると考えていたとのことである。

106

のファイル受渡しが行われ、以降、18 時 7 分に主要通貨の仕向送金の集記処理（上記図 37の❼）、18 時 18 分に主要通貨以外の仕向送金の集記処理、18 時 31 分に仕向送金の集記処理、がそれぞれ実行された（上記図 37 の❽）。
（ⅱ）外為被仕向送金
外為被仕向送金処理においては、他の金融機関から、SWIFT 電文を使用した国際間送金を受領し、顧客に到着案内を行うことが基本的な処理の内容である。具体的には、RMA、残高確定処理（前日最終残高ファイルから当日初期残高をセットする処理）、外決接続トリガー等が含まれ、これらの処理を、センター集中記帳処理を利用して、（a）集記依頼データ生成、（b）集記依頼データ送信、（c）集記処理という 3 種類のジョブにより行う。
外為被仕向送金処理の通常のジョブの流れは以下のとおりである。
【図 38】

外為被仕向送金処理が行われる日の前日 22 時 0 分から、上記（a）の集記依頼データ生成
として、外為システムにおいて（A）残高確定等及び（B）外決接続トリガーの処理につき、データが作成される（上記図 38 の①）。次に、上記（b）の集記依頼データ送信として、外為被仕向送金処理が行われる日の当日 0 時 0 分頃から、外為システムにおいて上記の集記
依頼データの送信処理が実行され、統合ファイル授受を介して外為システムからセンター
集中記帳システムへデータが送信される（上記図 38 の②）。
その後、上記（c）の集記処理として、0 時 30 分頃に、センター集中記帳システムにおいて、（A）残高確定等及び（B）外決接続トリガーの集記処理が実行される（上記図 38 の③）。
107これにより、1 時頃に外為システムと外決システムが接続される。なお、データ未受領により集記処理が遅れた場合、（A）残高確定等については、4 時 0 分を超過した時点で受信済
みのデータで自動実行するのに対し、（B）外決接続トリガーについては、データ受領が実行条件となっており、データ未受領の場合、集記処理は実行されない。
上記一連のジョブの実行が完了すると、外決システムから被仕向送金データが外為シス
テムに連携される。
3 月 12 日障害の発生時においては、統合ファイル授受の停止により上記（b）の集記依頼
データの送信を行うことができなかったが、（A）残高確定等の上記（c）の集記処理はデー
タ未受領の状態で時限実行され、実際には残高確定処理未済の状態でステータス上「実行済」となった。これにより、統合ファイル授受の復旧以降に（b）集記依頼データ送信を実施した際に、（B）外決接続トリガーのみ、上記（c）の集記処理が実行され、（A）残高確定等については実行されなかった。その結果、残高確定がなされていない状態で外決システムと外為システムが接続され、外決システムから送信された被仕向送金データに対する外為シス
テムでの処理で取引エラーが発生した。その後の取引エラーの復旧作業にも時間を要し、被仕向送金の到着案内を当日中に処理することができなかった。
詳細な事実経過は以下のとおりである。
【図 39】

外為システムにおいては、3 月 11 日 22 時 0 分に開始した（A）残高確定等及び（B）外決
接続トリガーの集記依頼データ生成は、ストレージ装置故障の影響を受けずに完了していた。
統合ファイル授受の障害により、3 月 12 日 0 時頃から実行されるはずであった外為シス
テムからセンター集中記帳システムへの集記依頼データの送信が実行できなかった（上記
図 39 の❶）。
上記のとおり、2 時 30 分頃、品川シーサイド事務所に参集した MHRT 第 1 事業部第 2 部の108

要員が復旧対応の検討を開始したところ、障害の影響で起動できていないジョブとして集記依頼データ送信（上記図 39 の❶）を把握した。
（A）残高確定等については、データ未受領の場合でも定刻 4 時 0 分にセンター集中記帳システムにて集記処理が実行されることか
ら、外為被仕向送金処理の復旧対応として、「残高確定処理がステータス上「実行未済」となっている場合の手順147」及び「残高確定処理がステータス上「実行済」となっている場合の手順148」を確認した上で、4 時前までには統合ファイル授受が復旧するとの想定で、3 時
10 分頃、残高確定処理がステータス上「実行未済」となっている場合の手順を選択し、統合ファイル授受復旧後、手順に従い作業を行う予定としていた。
しかし、実際には、4 時 0 分時点では統合ファイル授受は復旧せず、3 月 12 日の定刻として定められた 4 時 0 分の残高確定の集記処理が自動実行（処理件数 0 件で実行）され、実際には残高確定していない状態でジョブステータスは「実行済」になった（上記図 39 の❷）。
ここで、残高確定処理がステータス上「実行済」となっている場合の手順への差替えが行われる必要があったが、行われなかった。
6 時 38 分の統合ファイル授受の復旧後、MHRT 第 1 事業部第 2 部は、残高確定処理がステータス上「実行未済」の場合の手順に従って、未実行となっていた（A）残高確定等及び（B）
外決接続トリガーの集記依頼データ送信を 7 時 1 分に実行した（上記図 39 の❸）が、この際、後続の集記処理の実行ステータスの確認は行われていなかった。外為システムからセン
ター集中記帳システムへ受け渡された集記依頼データを基に、（B）外決接続トリガーの集記処理が実施されたが、（A）残高確定等の集記処理は 4 時 0 分に「実行済」であったため、この時点では実行されなかった（上記図 39 の❹）。8 時 24 分に残高確定が未済の状態で外決システムと接続され、外決システムから送信された被仕向送金データに対する外為システ
ムでの処理で取引エラーが発生した（上記図 39 の❺）。同時刻に、MHRT 第 1 事業部第 2 部
からエラー発生の報告を受けた MHBK/IT・システム統括第一部は、被仕向送金データが取引
エラーとなった場合の復旧手順として、事前に準備していた「取引エラーとなった被仕向送金データについて外決システムから外為システムに再投入する手順」の本障害時における有効性の確認に着手した。
8 時 35 分、MHRT 第 1 事業部第 2 部は、エラーの原因が外為システム上で残高確定がなされていないことにある旨を認識し、MHBK/IT・システム統括第一部に報告した。
9 時 36 分、MHRT 第 1 事業部第 2 部は、さらなる取引エラーの発生を回避するため外決シ
ステムと外為システムの切離しを完了した。
次いで、外為被仕向送金にて発生した取引エラーを分析した結果、外決システムから外為システムに再投入する手順では復旧できないことが 12 時 0 分に判明したため、複数の取引情報を入力する打鍵入力による復旧方法を実行することとし（上記図 39 の❻）、外為システ147（A）残高確定等及び（B）外決接続トリガーにつき、データ送信の実行を行う復旧作業の手順書をいう。
（A）残高確定等の集記処理についてはステータス上「実行済」となっているため、データ送信からの自動実行ではなく、別途臨時の処理ロットを設けて手動で実行する復旧作業の手順書をいう。
148

109

ムにおいて、残高確定がステータス上「実行済」となっている場合の手順に従って、12 時
20 分に（A）残高確定等の集記依頼データの送信、12 時 32 分に集記処理を再実行し、12 時
55 分に外為システムと外決システムの再接続を完了した（上記図 39 の❼）。
外為被仕向送金の取引エラーについてログを解析した結果、対象となる取引の通番情報が確定したため、打鍵入力による復旧のため 16 時 15 分に通番情報を MHBK 事務企画部に還元したが、通番情報のみではリカバリ困難との回答があった。そのため、打鍵での入力に必
要な情報の還元準備を実施したが、MINORI の当日オンライン締めである 19 時までに外為被仕向送金の打鍵入力に必要な情報還元に至らず、
取引エラーとなった外為被仕向送金 761 件について当日中の到着案内が未了となった。
（イ）顧客への障害影響及び対応状況
3 月 12 日障害の発生時には、通信制御装置の交換が終了した後も、上記第 4・4・
（1）・イ・（ア）のとおり、統合ファイル授受の復旧が完了せず、通常 5 時 0 分から 6 時 0 分の間に行われる日付変更処理が未済であり、当日分のセンター集中記帳処理の開始が遅延した
ことから、顧客影響が発生する可能性が高まった。そのため、6 時 4 分に営業部店の部店長
席宛に即時出勤が指示された。また、6 時 0 分から非常対策 PT が開催された。以降も、MHBK
本部で把握した情報を基に、営業部店に向けて連絡・指示（部店長席に障害の影響範囲の共有及び営業部店向けの速報発信）が行われた。11 時 1 分には、部店長席に店頭外為の取扱いについて、「店頭外為は、その場処理ではなくセンター処理としてお預かりすること及び当日中に処理が必要な取引については、処理が明日以降になる可能性がある旨をご案内すること」との指示がなされた。
3 月 12 日障害における顧客影響への対応は、以下のとおりである。
まず、国内他行向け仕向送金（263 件）の発信時限への対応として、3 月 12 日付入金処理を行うに際して発生する金利・為替手数料等のバックバリューコスト149を MHBK が負担する前提の下、受取銀行と入金日を含め交渉が行われた。
次に、外為被仕向送金（761 件）の 3 月 12 日当日中の入金案内処理未了について、受取人に連絡し、入金日について意向確認を行い、3 月 31 日時点で全ての入金済みが確認された。
バンクレポートサービス（186 社/217 口座）については、欠落データ（3 月 11 日 15 時以降の取引明細）は 3 月 13 日配信のバンクレポートに含めて配信し、対応が完了した。また、
3 月 12 日障害後、対象顧客全先に対する連絡が行われた。
さらに、法人 EB の入出金明細のうち、更新が遅れた 3 月 11 日の入出金明細（ファイル型）（顧客 95 社）の「翌日一括」の明細は、同月 12 日分と併せて同月 15 日朝に更新された。また、3 月 12 日障害後、対象顧客全先に連絡し、特段問題は生じていないことが確認

149

締め後処理の際の顧客の逸失利益等を補填するためのコスト。

110

された。
なお、3 月 12 日中に支払指図を発信済みの海外送金や、同日中に到着案内を実施済みの外為被仕向送金についても、通常の処理に比べて処理が遅れたことに関して、営業部店を通じて謝罪と説明を実施し、顧客から要望があった場合には、個別対応した。
（２）原因ア

障害の発生について

上記ストレージ装置及びサーバはいずれも、MINORI 共通基盤 B として MHBK が日立製作所
からサービス提供を受けているハードウェアであるところ、3 月 12 日障害については、特定のドライバとファームウェアとの組合わせの問題で発生したものである可能性が高い。
日立製作所の報告によれば、このような障害事象は本件が初めてであるとのことである。他に、保守管理等に遺漏があった形跡も見あたらない。
なお、MINORI 共通基盤 B の導入製品に関わる既知の不具合への対策については、月に一度、日立製作所から MHBK 及び MHRT へ報告する運用となっている。これらに照らし、3 月 12日障害の発生自体について、MHBK 及び MHRT の対応に問題があったとは認められない。
イ

障害発生後のシステム復旧遅延及び顧客影響の拡大について（ア）システム対応関係ⅰ

復旧手順の準備不足

上記のとおり、ストレージ装置とサーバとの接続は、サーバを再起動することにより復旧しており、障害発生から全サーバ復旧まで 6 時間 41 分を要した150主たる原因は、サーバの再起動に至るまでに時間を要したことにあると考えられる。
この点、早期にサーバの再起動に至らなかった理由としては、①既存のマニュアル（障害復旧手順）に定められた手順では対応できず、現地への駆付け対応が必要となったこと及び②現地に駆け付けた担当者がストレージ装置・サーバ間の接続不具合を既存の手順で対処できず、現場で試行錯誤する形となったこと151があり、その要因として十分な復旧手順を準備していなかったことが挙げられる。
ⅱ

復旧対応の誤り150

ストレージ装置故障に関する日立製作所の報告において、3 月 12 日障害と同様の事象発生時にサーバ再起動を優先する場合は、復旧作業の実施開始から当該ストレージ装置に接続されている全サーバの再起動までを 53 分で行う準備がある旨の記述がある。当該記述を前提とすると、仮に、2021 年 3 月 12 日 2 時
18 分に、ストレージ装置とサーバの接続経路の手動での再接続ではなく、サーバの再起動を優先して復旧対応を行っていた場合、最も早ければ、3 時 11 分頃には全サーバの復旧が完了していた可能性がある。
151
再起動までの間、ストレージ装置とサーバの接続経路の再接続を手動で繰り返し行っていた。具体的には、上記のとおり、2 時 18 分に、通信経路の手動での再接続に失敗し、2 時 32 分に通信経路の強制切断後、再接続を試みるも再び失敗し、また、4 時 2 分に再度ストレージ装置への手動での再接続を試みるが失敗
した。

111

（ⅰ）障害対応時の確認不足
3 月 12 日障害への対応においてはデータ送信が成功したことの確認及びセンター集中記帳システムにおけるセンター集中記帳処理の件数の確認といった基本的な事項の確認が十分でなかった。これらの確認がなされていれば、データ送信が成功していないことや、集中記帳処理が実際には処理件数 0 件で実行されたという事実を発見し、早期に復旧作業の誤りに気付いた可能性がある。
（ⅱ）外為システムの復旧における全体統括機能不足
統合ファイル授受が 6 時 38 分に復旧した後、外為システムの国内他行向け仕向送金処理
及び外為被仕向送金処理の復旧作業を開始したが、リカバリ手順の選択に誤りがあるまま、リカバリ作業を実施していた。
3 月 12 日障害では外為システムやセンター集中記帳システムのリカバリ作業に必要な体制を確保しリカバリ作業を開始したが、リカバリ作業に必要な準備行動をした形跡が見あたらなかった。
障害発生後のリカバリ作業は、それに必要な体制を確保して、全体統括機能を発揮させる必要がある。すなわち、同体制の下、システム状況（罹災状況、ジョブステータス等）を調査し、復旧シナリオ（リカバリ作業手順準備、作業開始予定時刻、作業終了予定時刻、進捗管理方法、チェックポイント、連絡体制等）を組み立て、復旧作業に当たる担当者及び統括者にてこれらを共有及び確認して、リカバリ作業を計画的かつ効率的に行うことが重要である。かかる復旧作業全体を統括する機能を発揮することにより、想定外の事態が発生した際にも、思込み等による場当たり的な対応や見落とし等を回避することが可能となる。
3 月 12 日障害への対応にあたっては各担当分野において各自が自らの作業を遂行する行
動にとどまり、上記のような外為システムにおける全体統括機能、それによる計画的かつ効率的な対応がなされなかった可能性がある。
（ⅲ）外為システムの復旧における関連部門との情報連携の不備
3 月 12 日障害の復旧作業では、事務企画部と MHBK/IT・システム統括部第一部が情報連携してシステムが復旧しなかった場合の代替措置を行う必要があったが、外為システムの復旧作業開始前の 7 時頃までに障害連絡は行われたものの、復旧作業が開始された 7 時頃
から電話照会が開始された 13 時 30 分までは、基本的にはシステムの復旧により滞留したセンター集中記帳処理が正常処理されるのを待って対応するというスタンスで、対応時限までに処理できないことを念頭に置いた事務企画部と復旧作業における代替措置に関する情報連携が実施された形跡が見あたらなかった。
ⅲ

サービス契約における復旧時間に関する合意欠如

MINORI 共通基盤 B に係る保守サービスに関する外部委託業務管理態勢の不備を原因の一112

つとして指摘できると考えられる。
すなわち、MINORI 共通基盤 B は日立製作所がハードウェアを保有し、維持・メンテナン
スを含め MHBK にサービスとして提供しているものであるが、上記のとおり、3 月 12 日障害の影響が拡大した原因として復旧対応開始から全サーバの復旧まで長時間を要していることが挙げられる。
この点、保守を担当する日立製作所と MHBK の間において、たとえば障害発生時の具体的な復旧時間に関する取決め等はない。
システムに関する各種業務を外部へ委託する場合、委託者たる銀行は当該業務を委託先任せにすることなく自らが主体的に関与し、委託の対象となっている業務を適切に管理していくことが重要である。障害発生時の具体的な復旧時間等を取り決めることは業務の委託先に対する管理の意味を持つことに加え、その速やかな復旧に向けた委託者及び受託者の体制・手順の整備につき両当事者の間で具体的な検討を促す意味もある。MHBK においては MINORI 導入時に日立製作所との間でストレージ装置の故障時の具体的な復旧時間について検討していないとのことであるが、復旧時間を取り決めるか、少なくともその検討の提案をすることで速やかな復旧のための体制・手順の検討が促された可能性がある。
ⅳ

人材育成及び配置並びに訓練等に関する問題

上記のとおり、外為国内他行向け仕向送金処理の遅延は本来であれば日付変更処理が実行された後にジョブを手動で再実行すべきであったにもかかわらず、かかる再実行が行われなかったことが原因となっている。また、外為被仕向送金処理の遅延は、ファイル未受領の状態で後続のジョブが部分的に定刻起動されジョブのステータスが「実行済」となったにもかかわらず「実行済」のステータスに合わせた復旧手順が行われなかったことが原因となっている。このように、3 月 12 日障害に関してはいずれも復旧対応を行った者の復旧手順の誤りが原因となって復旧までにより時間を要する結果となり、顧客影響の発生に繋がった。
この点、障害発生時の復旧対応にミスが生じるリスクを完全に払拭することはできないと考えられるものの、かかるリスクを適切に管理するという観点からは、経営陣の主導の下、システムの復旧に精通した人材を育成及び配置するとともに、あらかじめ多くの障害シナリオを想定した十分な訓練の実施と適切な復旧手順の整備を通じて将来顕在化し得るリスクを可能な限り低減・制御することができるよう態勢整備を行っておくことが重要であると考えられる。3 月 12 日障害に係る上記第 4・4・
（1）の事実経過を前提とする限り、かかる態勢整備に不十分な面があったことは否定できない。
（イ）顧客対応関係
3 月 12 日障害における顧客対応の主な問題点としては、外為取引に関し、当日中に大量の取引が終わらないという事態（他行向け仕向送金と外為被仕向送金に関して 1,024 件の113

積み残し）を発生させ、また、一部当日対応した顧客を除き、顧客に対する説明が翌営業日に持ち越された点にある。当日中に大量の外為取引が完了しなかったという点に関しては、大口の顧客で特別対応すべきであると決定されたものや、顧客から要望があり外為営業部
から直接連絡が入ったもの等、システム復旧作業を待たずに個別に対応したケースがある。
すなわち、顧客対応部門において、当日顧客に対する個別対応は可能であり、実際に一部行われていたという事実がある。
他方で、顧客対応部門では、基本的にはシステムの復旧により滞留した取引が正常処理されるのを待つというスタンスであり、非常対策 PT は早期に設置されたものの、顧客への説
明の大部分が翌営業日に持ち越され、また、個別対応はあくまで例外的な対応と位置づけられていた。その理由として、システムが復旧する目途が立っていると認識しており、かつ、
システムが復旧すれば個別対応したものとの二重処理が発生するリスクがあるため慎重に行っていたという事情がある。しかし、上記のとおり個別対応は実際に行われており、対応が可能であったのは事実であり、当日中に時限のある取引を顧客のために必ず間に合わせるという意識が不足していたことは否めない。また、システム復旧の目途が不確定の段階で、時限のある取引に関しては、一定の時点で復旧の見込みが立たないと判断して個別対応に切り替えるという判断も可能であったと解されるが、二重処理のリスク等汲むべき事情はあるものの、システムの復旧作業の完了を徒に待ってしまった顧客対応部門の決断力が足りなかったと言わざるを得ない。
加えて、顧客対応部門において時限取引に影響が出る障害への対応の事前シミュレーシ
ョンが十分されていないこと、システムの復旧作業のリスケジュールや影響範囲の正確な情報の共有が行われなかったことも対応の遅れの原因となっている。
また、外為への影響については、一部の顧客を除き、当日に顧客に対する個別の連絡・説明ができず、翌営業日である 3 月 15 日以降での説明となっている。この点、システム復旧
対応に関してシステム部門と顧客対応部門の連携が十分なされておらず、顧客に対する影響の範囲が正確に把握できていなかったことが、顧客に対する正確な説明に遅れが生じた
ことの原因となっていると考えられる。
第５１

デジタルフォレンジック調査等の結果概要
デジタルフォレンジック調査について

デジタルフォレンジック調査の結果として、本障害への対応やその後の調査過程において、関係者が本障害に関して事実を隠蔽し、あるいは歪曲したことを窺わせるような形跡は見あたらなかった。
２

アンケート調査及びホットラインについて

アンケート調査及びホットラインにおいて受領した、本障害の原因や対応策に関わると思われる意見の概略は、以下のとおりである。
114

なお、これらの内容は、必ずしもその全てが本障害についての回答ではなく、自由記述を含むことから、統計的な処理にはなじまないものである。また、その真偽確認を本調査で逐一行ったものではないことに留意されたいが、多くの職員の認識や意識を推し量り、本障害の発生に結びついた可能性のある MHFG、MHBK 及び MHRT 等の実態の一端を知る上で参考になるものと思われる。
① MINORI のリリース前後の体制の縮小及び費用削減を指摘する意見が多数あった。
たとえば、コスト構造改革で、開発部門は大幅に要員が削減され、維持メンテ体制が恒常的に要員不足であること、保守の工数やスケジュールがギリギリまで詰められ、逼迫していること、特定の職員に負荷がかかっていること、保守予算を得るための書類作成に時間を取られること等である。
②

MHRT 及び協力会社を含め、MINORI の構築・設計に携わった有識者が異動や退職でいな

くなり、ドキュメントの作成・引継ぎが十分でなく、再委託先も変更され、担当者の研修機会が少なく、スキル・ノウハウが伝承されていない、との指摘が多い。
③

MINORI 自体については、非常に大きなシステムであり、様々なサブシステムに分割され、それぞれが複雑な機能・制約を有しているため、網羅的に把握できている人間が少ない、みずほ SOA の疎結合の考え方が領域間の機能・影響の確認を難しくしている、という意見があった。
④ 障害発生後の対応における組織力の弱さについても、多くの指摘があった。
たとえば、障害対応方針の決定主体・決定プロセスが明確でない、非効率的である、システムに関する責任の所在、指揮命令系統が曖昧である、開発部門・運用部門・ユーザー部門・営業店の情報共有・発信が遅い、連絡手段が貧弱、指示待ちとなっているなど、反省を含む意見は多岐にわたる。
⑤

ATM については、取込み仕様の詳細を知らなかった、店舗外 ATM が増加し、24 時間 365
日稼働となり、提携先が増え、サービスが拡大・高度化する中で、管理面を見直していな
かった、店舗外 ATM の管理権限、モニタリングシステム、トラブル対処法の訓練等、障害対応に必要な仕組みが整備されていなかった、との意見があった。

⑥

経営陣や組織の在り方について、お客様第一ではなく、効率化最優先・経営層の意向第一になっているのではないか、特に収益の低いリテール部門のコスト削減圧力が強く、システム費用の切り詰めに繋がっている、IT 部門・事務部門が軽視されている、余裕のな
いスケジュールが現場に押し付けられる、経営陣における人材の配置が非合理的である、
115

現場の感覚と本部の施策との間に乖離が生じている、などの意見があった。
⑦

必ずしも直接の原因とはいえないが、現場の意見が本部に上がらない、経営陣に忖度して各種判断がなされる、内向きの姿勢、リスクを取らず前例踏襲する管理職、事なかれ主
義、最前線の支店への情報出し渋り、障害発生時にお客様には積極的に説明しないようにとの指示があったなど、会社の体質や風土に関する指摘もあった。

第６過去の障害事例の概要

MHBK では、過去にも 2002 年及び 2011 年に大規模なシステム障害が発生しており、本障害が起きた原因を分析する上で、それら障害の際の事実経過、原因分析及び提言、その他過去に生じたシステム障害時の対応等についても検討することが有用であると考えられる。
なお、以下記載のシステム障害に係る事実関係については、特記しない限り、「株式会社
みずほ銀行システム障害特別調査委員会」の 2011 年 5 月 20 付調査報告書に依拠しており、また、その他の過去の障害に関する事実関係についても MHFG 及び MHBK から提供された資料等に依拠するものであり、本委員会独自の認定ではない。
１

2002 年及び 2011 年のシステム障害とそれらへの対応（１）2002 年のシステム障害の概要
2002 年 4 月 1 日、旧 3 行が MHBK 及び MHCB に統合・再編された。勘定系システムについては、MHBK のシステムは第一勧業銀行が 1988 年に稼働させたシステムをベースとして、リ
レーコンピューターにより富士銀行のシステムと繋ぐという暫定的なシステムとされ、本格的な一本化は先送りされた。
新銀行としてのスタートの初日である同年 4 月 1 日、勘定系システムの障害が発生した。
これにより同日以降、MHBK における口座振替の手続が遅延したことから、MHBK、MHCB 両
行における引落処理が遅延するとともに、収納企業等の口座への代り金入金、引落結果デー
タの引渡しも遅延した。
また、同日及び同月 8 日に、MHBK の ATM オンラインシステムに障害が発生し、デビット
カード、コンビニ ATM 等も含めたカード取引の一部が取扱いできなくなった。さらに、この障害に伴い、現金が未払いにもかかわらず通帳に引落しが記載される支払誤記帳が発生した。
そのほかに、MHBK 及び MHCB において振込遅延、取立手形関係の遅延、外為事務処理の遅延等も発生した。また、上記の口座振替の事務処理遅延等の中で、顧客口座から二重引落しが発生した。なお、事務の混乱の影響で、内部勘定の一部に未整理が残った。
このように、2002 年の上記システム障害では、MHBK 及び MHCB において、250 万件に上った口座振替の事務処理遅延等、社会的インフラともいえる決済システム等に障害を引き起こし、収束するまでに数ヶ月を要するなど、顧客及び社会経済に多大な影響を与えた。
116

（２）2011 年のシステム障害の概要
2002 年のトラブルから約 9 年後、2011 年 3 月 14 日夜から同月 24 日にかけて、MHBK は大規模なシステム障害を起こし、給与振込等の為替送信が遅延し、ATM が利用停止になるなど、顧客の経済活動に多大な影響を与えた。
これは、2011 年 3 月 11 日に発生した東日本大震災に伴い特定の義援金口座への振込入金処理が集中したことにより、勘定系システムの夜間バッチにおいて、処理件数が一口座あたりの処理可能な件数のリミット値を超え、同月 14 日の夜に異常終了し、その際、処理結果
データの一部が欠落したことに起因する。この異常終了の原因となったリミット値を拡大し、夜間バッチを再実行するシステム復旧処理が実施されたが、欠落したデータの復元作業が難航し、実施されるべき一連の夜間バッチが翌 15 日の営業店業務の開始時刻までに終了
しないことが濃厚となった。そこで、MHBK は、同月 15 日早朝、夜間バッチを中断し、営業
店端末の開局処理を実施するとともに、いったん中断した夜間バッチの影響により業務提供が不能となる取引の抑止オペレーションを実施した。しかし、これらの作業に時間を要したため、15 日の営業店業務の取引開始は遅延した。さらに、営業店端末の開局処理に必要なバッチの日替り処理（DJS 切替）により、通常自動化されているシステム運行が手動に切り替わったために、処理失念や誤処理による多数の副次的障害を引き起こした。結局、夜間バッチを終了できず、終了後に予定していた為替送信ができなかった。
同月 16 日早朝、同月 14 日分の夜間バッチが終了し、同月 15 日分の夜間バッチを開始したが、同月 14 日に振込入金処理が集中した口座とは別の義援金口座においても振込入金処
理の集中が発生し、再び夜間バッチが異常終了した。そのため、再び取引抑止を実行する必要が生じたことに加え、同月 14 日分の夜間バッチの異常終了に起因した ATM の停止障害への対応も必要となったために、同月 16 日の営業店業務の取引開始は遅延した。このようなことから、同月 15 日 17 時の時点で同日指定日分の為替送信について、約 31 万件の未送信
為替が発生した。
以後、夜間バッチの未処理が蓄積され、手動によるシステム運用の過程での人為的ミスも多発し、影響が拡大していった。同月 17 日には、夜間バッチの手動化により抑止されていた不要データの削除処理を実施した。この削除処理に先立って必要なデータを退避させていたはずであったが、実際には後続作業で必要なデータが喪失していることが判明し、そのデータの特定と再作成に長時間を要した（同月 15 日分の夜間バッチが終了したのは同月 19
日の夜であった。
）。
その後も、処理時間不足や人為的ミスが続き、仕向為替の未送信、被仕向為替の未処理、営業店業務の取引開始遅延・取引停止、ATM の利用停止・利用制限、ダイレクト・チャネルの利用制限、取引明細の欠落、口座振替における処理不能及び誤った結果データの還元・処理漏れ等、顧客に影響を与える副次的事象が多発した。

117

（３）上記システム障害に対する再発防止策
ア2002 年のシステム障害の原因とそれへの対応

2002 年 4 月に発生したシステム障害の発生原因は以下のとおり報告されている。
口座振替の事務処理遅延の主要原因として、①移行作業の事前準備において、MT 交換テーブル152に誤った情報が入力されるなどの不備があったこと、②スケジュールトランズ153のデータ入力作業の一部に誤りがあったこと等により、エラーが発生したこと、③ジョブコン
トロールランゲージ154に不具合があったこと、④口座振替の MT の受付業務に使用するサポートシステムにおいて、移行作業の事前準備における情報の登録に一部誤りがあったこと
や、システム変更の設計自体に問題があったために受付事務の混乱が生じたことの 4 点が挙げられた。
ATM 障害の原因は、グローバル・プロセッサーのプログラムに不具合があったことによる。
グローバル・プロセッサーは第一勧業銀行のホストコンピューターである STEPS を起点として、富士銀行の TOP 及び外部のコンピューターセンターとの接続を担うシステムであり、そこに不具合が生じたため、ATM 障害が発生した。
振込遅延等その他の障害の発生原因は、主としてコンピュータープログラムの水準確保が十分でなかったことや、新事務フローへの事前の訓練不足等により事務処理ミスが発生したこと等による。また、大量事務処理を支えるシステムの機能追加や事務インフラの整備が不十分であったことが事務の混乱を招いた面もあった。
総括として、2002 年の一連のシステム障害は、各種テストやリハーサル等の事前準備が十分でなかったこと、システム統合プロジェクトの管理体制に問題があったこと等によるものとされた。
以上について、金融庁は、2002 年 6 月 19 日付の「業務改善命令」の中で、「システム障害が発生した原因は、①システムの機能を確認するシステムテストや運用テストが適切に実施されていなかったなど、最低限必要な準備ができていなかったこと、②テストが不十分であった等の重要な情報が、一部の開発責任行のシステム開発部門内にとどまっていたこと等、グループ内での報告・連絡態勢に重大な問題があり、十分なチェックが働かなかった
こと、③MHCB において大量の事務処理を支える事務インフラが不十分であったこと、等にある。
」と総括している。また、同命令においては、「このような最低限の準備ができなかった根本原因は、旧経営陣がシステム統合に係るリスクを十分認識していなかったことから、統合に伴うシステム開発等の前提となる基本的事項の意思決定が遅れ、システム開発・テス
ト、事務の訓練に必要な期間が十分に確保できなかったことにある。」、「また、・・・事前準備段階の不適切な対応はもとより、障害発生以後、顧客対応に適切性を欠き情報開示に迅速152

口座振替に関わる委託者名、収納企業が持ち込む通帳・カードの種類、通帳・カードごとのファイル数等の収納企業に関わる情報を取り込んだデータファイル。
153
口座振替システムにおいて作業工程を管理するためのもの。
154
コンピューターに対して処理方法を指示する際に用いるコンピューター専用の言語。

118

性・正確性を欠くなど緊急時対応においても不適切な対応が認められた。
」と指摘されている。
そして、上記の業務改善命令には、金融庁による報告書提出の求めを受け、みずほホール
ディングス等が 2002 年 6 月 18 日に金融庁に提出した改善・対応策のポイントとして、顧客の信頼回復（「グループの一体感の醸成」を含む。
）、責任の明確化とともに、再発防止策
として、「①システム、業務運営の更なる安定化（原因分析、システムリスクの総点検、改善策の立案と実行、人員の再配置、システムの追加開発）、②プロジェクト管理体制、シス
テム開発・運用体制の強化（オペレーショナルリスク管理体制の強化、IT 戦略委員会の強化、コンティンジェンシープランの充実、システム関連子会社の共同開発体制を構築、合併・統合の推進、システム監査機能の整備）、③プロジェクト統括管理機能の強化（ホールディ
ングスの統括機能、コントロールの強化）、④今後のシステム開発プロジェクト管理の強化」が掲げられていた。
これを受け、MHBK は、直接的な原因であるシステム統合プロジェクトの管理体制強化を中心とした再発防止策を策定するとともに、大規模障害の教訓や経営統合による新体制発
足を踏まえた行動規範の設置等全 30 施策を設定した。
さらに、顧客対応に関して、「お客さま第一主義」の意識の浸透の徹底を掲げ、①事前検討段階における対応（事前検討の段階から顧客や RM（Relationship Management）担当者、
IT 部門等からの幅広い意見の収集やニーズの把握に努め、想定される事象エラーについて幅広く検討を行い、きめ細かく対応を行うこと。）、②「お客さまの声カード155」の活用強化、③苦情・トラブル情報の一元管理と情報発信（お客さまサービス部で受け付けた苦情・トラ
ブル情報に加え、ダイレクトバンキングセンター等に寄せられる苦情・トラブル情報や本部各部が受け付けた苦情・トラブル情報を一元管理し、関係各部に適時適切に情報発信する体制を整備すること。
）、④「アイデア提案活動156」「CS サークル活動157」の運営強化に加え、新たに「営業店からの声カード158」の開始による営業店・本部間のコミュニケーション強化という改善・対応策が策定された。
イ

2011 年のシステム障害の原因とそれへの対応

2011 年のシステム障害の原因としては、上記のとおり、MHBK の勘定系システムは旧第一勧業銀行が 1988 年に稼働させたものを基盤としているところ、その後、情報量は増大し、短期集中的な処理を求められることとなり、異常が発生した場合のシステム復旧のために許される時間的余裕が減少する中、システムがこれに対応できない状況となっていたこと

155

店頭チャネル経由で寄せられた顧客の意見・苦情等を把握するためのツール。
顧客の視点に立った商品・サービスの改善要望等を行員自らが本部に提案する制度。
157
顧客の視点に立ったサービス品質向上を目的とした小集団（サークル）活動を行い、効果のあった取組
みを本部に提案する制度。
158
本部・本部行員の営業店・営業店行員に対する対応（業務・施策の運営方法、日常の言動・態度・姿勢
等）に対する営業店の生の声を幅広く収集するツール。
156

119

にあった。
障害発生の直接のきっかけである夜間バッチのリミット値の超過に関し、この値の引上
げはシステム稼働時から一度もされず、値の適否のチェックは定期点検項目にも入っていなかったため、担当者はこの値を超過すれば問題を引き起こすことの認識すらなかった。また、異常発生に対するシステム復旧のための緊急時態勢については事前に準備されていた
ものの、その復旧対応手順書が実効性を伴っておらず、想定すべき事象が不足していた。この背景として、2002 年のシステム障害後に再発防止策として、新規開発システムに対する品質向上策や、障害発生の未然防止に重点を置いていたことから、異常時の復旧対応に取り組む意識が希薄になっていたことがあった。さらに、当時の MHBK・MHRT・MIDS の合同実地訓練の不実施のほか、既存の勘定系システムの設計全体の見直しが次期システム構築時に行うこととされていたこと等もあり、勘定系システム全体への影響の分析能力、多重障害の復旧見通しが立てられる人材が不足していたという事情もあった。
MHBK は、「システム障害等に関する発生原因分析、改善・対応策」を 2011 年 4 月 28 日に策定し、同年 5 月 23 日に公表した。これによれば、経営責任を明確化するとともに、具体的なシステム障害の再発防止策として、大量取引が想定される口座について管理・徹底等の障害発生の未然防止の取組み、センター集中記帳処理が遅延した場合の対応案の整理等の障害発生後の不適切な事後対応の改善・対応策、緊急時行内体制の見直し等の事業継続管理態勢に対する改善策等が策定された。
なお、MHBK は、同年 4 月 11 日に外部の識者・専門家から構成されるシステム障害特別調査委員会159を設置し、当該委員会は、同年 5 月 20 日に「調査報告書」を MHBK に提出した。
これによれば、MHBK の再発防止策を基本的に妥当なものと評価しつつ、再発防止策の継続的実行及びシステム統合の早期実現が提言されている。
以上の MHBK による原因究明・再発防止策の策定と並行して、金融庁はこのシステム障害について調査を進め、同年 5 月 31 日付で業務改善命令を発した。これによれば、MHBK のこのシステム障害の原因として、「直接的な原因は、①特定の義援金募集口座が、法人・リー
フ口（無通帳方式）160との取扱いとなっていなかったこと等から、振込件数がバッチ処理上
限値を超過したこと、②こうした一次障害に加え、障害に対する初動対応の遅滞、システム
障害報告態勢の不備、為替送信の対応不備、関係会社・部署間の連携不備及び適切な人員投入・配置の指示の遅れがあったこと等により二次障害が発生・拡大したこと、等にある。」とされ、「また、初動の遅れ等に起因して、顧客への周知の遅延や不十分な情報伝達といった事態も発生した。
」と指摘されている。さらに、対応の不備が生じた原因として、
「①経営
159

構成は以下のとおり。委員長：甲斐中辰夫（弁護士・元最高裁判所判事）、委員：門口正人（弁護士・元
名古屋高等裁判所長官）・後藤順子（公認会計士・有限責任監査法人トーマツパートナー金融本部長）・武田安正（アクセンチュア株式会社代表取締役副社長）、調査委員会補助者：アンダーソン・毛利・友常法律事務所・有限責任監査法人トーマツ・アクセンチュア株式会社。
160
通帳を発行せず、取引明細を「リーフ（普通預金明細表）」にて提供する普通預金口座。
なお、センターでリーフを作成するセンターリーフ口は未記帳明細情報を保有しないため、保有するレコード数を抑制することができる。

120

陣の初動の遅れを要因とした危機管理体制上の問題があったこと」、「②経営陣において、『グループ内連携・報告態勢の整備』、『システム・コンティンジェンシー・プランの整備』、『システムへの投資戦略』、『人材育成と適材適所の人材配置』、及び『顧客対応態勢の整備』等に対する取組みが不十分であったことにある。
」と指摘された。
なお、MHFG に対しては、「持株会社として、①システム・コンティンジェンシー・プランの整備、②現行システムに内在する課題を踏まえた IT 投資戦略、③人材育成や適材適所の人材配置、④子会社等の管理・グループ内連携態勢、等について、経営陣の機能発揮等に係る問題が認められ、改善が必要である。
」等と指摘された。
２

その他のシステム障害等（１）2016 年 2 月のシステム障害
2016 年 2 月 29 日、MHBK は、アジア拠点における送金業務管理を行う外貨送金管理シス
テムを更改した新しいシステムをリリースした。同日 10 時 35 分頃、中国各地の拠点・マニ
ラ支店等のオペレーターがこのシステムにログインしようとしたが、画面が正しく表示されず、取引打鍵が行えない状態となった。そこで、MHBK は、手作業での打鍵を行いつつ、原因調査を行い、また、アプリケーションの再起動を複数回実施するも復旧はできない状態が続いた。そして、同日 19 時 10 分に障害の原因特定ができ（アプリケーション A セッション、同日 22 時 30 分になって外貨送金管理システムは復旧した。このシ数設定値161の問題等）
ステム障害により、19 の部店で 101 の顧客の 565 件の取引に影響が発生した。
上記のセッション数設定値に問題が生じた原因は、環境構築時における設計値と実際の環境への設定値の確認が不十分であり、個別設定を行う必要がないとの思込みがあったこと等システム開発の委託先のスキルが不足していたこと、同委託先の障害対応能力が低かったこと、さらに、MHBK としても、委託先を適切に管理するスキルが不足していたことに加え、取引量の多い月末に新しいシステムをリリースしたことで多くの顧客に影響を与えてしまったという経営管理上の問題もあったとされている。
（２）2018 年 6 月のシステム障害
上記第 4・1・
（2）
・ア・
（オ）
・ⅰのとおり、2018 年 6 月 16 日、同月 17 日に実施された
MINORI への STEPS 移行リハーサルにおいて、通帳・カード取込みが 1,821 件（店舗内 1,285
件、店舗外 536 件）発生した。この際、ATM センターの応答率は約 13％（入電件数 2,913 件、呼損 2,528 件）にとどまり、店舗外を中心に計 68 件の通帳・カード取込みについては顧客に当日返却ができず、翌日に返却を完了した。
当該事象に対し、顧客から 30 件程度の苦情（オートフォンに連絡しても繋がらない、ATMの前で長時間待たされた等）が寄せられていたが、MHFG 及び MHBK は、当該事象が突発事象

161

Web アプリケーションの動作を行うための基盤技術である、システムベンダーC のアプリケーション A
において設定するパラメータの値。

121

であるとして、今後の改善策が必要な恒常的な問題とは認識しなかった。
（３）2018 年 7 月から 2020 年 7 月までの期間における通帳・カードの取込み
上記第 4・1・
（2）
・ア・
（オ）
・ⅲのとおり、MINORI 稼働後、カードの磁気不良等により毎
月 140 件程度の取込みが発生した（1 日あたりの最大値は 2018 年 10 月 5 日の 34 件）。
（４）2019 年 12 月のシステム障害
2019 年 12 月 15 日 15 時 8 分頃、ATM での通帳・カード取込みが 187 件発生した。この原因は、MINORI 共通基盤 A ハード故障に伴って自動機サーバにエラーが発生したことによるものであった。当日は日曜日であったため、全てオートフォンにより対応し、通帳・カードを返却した。
３

本障害との共通項の分析（１）過去にとられたシステム障害の再発防止策の評価
上記の 2002 年及び 2011 年のシステム障害後にとられた再発防止策については、それぞれの時点で、社会から批判を浴び、金融庁による調査及び業務改善命令を受ける中で、経営陣がその責任を果たすべく最善を尽くしたものであろうと推認され、適切性に疑問があるとは思われない。
また、当該再発防止策の実施についても、それらシステム障害が MHBK に与えたダメージの大きさを踏まえ、その後の経営陣及びシステムに関わる行員・関係者が真剣に取り組んだ
ことは、IT 戦略委員会による業務改善計画の進捗状況のモニタリング等からも窺われる。
（２）過去事例と本障害の共通項
このように過去の障害につき多くの再発防止策を幾度も策定・実施してきたにもかかわらず、本障害が発生し、障害対応にも様々な遺漏があったのはなぜか、その点を検討することは、本障害に通底する原因を掘り下げる上で有効である。
ア

ソフトウェア及び事前のテストの問題

上記のとおり、2 月 28 日障害及び 3 月 7 日障害は、システムの開発・テストが不十分（メモリ容量確認不十分及びプログラム不良看過）であったことに起因して発生した。
他方、2002 年のシステム障害は、上記のとおり、合併前から第一勧業銀行と富士銀行が稼働させていたシステムを繋ぐリレーコンピューターと論理的な接続経路を維持するために追加したプログラムに、特殊な条件が重なった場合に限って表面化するバグがあった。そして、合併後のシステムを円滑に繋ぐ作業が遅延し、経営陣はこの問題が惹起するリスクの重大性を十分に認識せず、負荷テスト・異常テスト等のテスト及び事務の訓練に必要な時間が十分に確保できなかったために、バグが修正されないまま稼働に至り、初日から障害が発122

生するというソフトウェアの問題に起因するものであった。
また、2011 年のシステム障害は、上記のとおり、義援金の振込先とされた一口座への振込入金処理が集中した結果、勘定系システムの夜間バッチにおいて、処理件数が一口座あたりのリミット値を超えたことに起因するものであり、これも、この値の引上げはシステム稼働時から一度もなされず、値の適否のチェックは定期点検項目にも入っていなかったため、担当者はこの値を超過すれば問題を引き起こすことの認識すらなかったというソフトウェ
アに関連する問題であった。
このように、2002 年及び 2011 年にソフトウェアの問題からシステム障害を惹起させ、顧客及び社会経済に大きな影響を与えていながら、2021 年のトラブルもソフトウェアに問題があり、また、事前のテストも不十分であったという同じ問題が原因となっている。2011 年のシステム障害後に策定された業務改善計画（2011 年 6 月 29 日）では、「商品毎のリミッ
ト値を意識した運営の確立とリスク統制」という項目において、取扱いをしている全商品・サービス（497 商品）における決済系商品（27 商品）のうち、瞬時かつ大量取引の発生可能性がある商品（8 商品）を抽出し、それらに大量取引が発生した場合のシステム対応による検知・対応手順を確立し、実施済みであったはずである。
イ

事後対応の問題

上記のとおり、MHBK は、2 月 28 日障害及び 3 月 12 日障害の発生後、原因の特定、復旧作業に長時間を要した上、顧客への影響を把握するのに手間取り、タイムリーな告知等ができなかった。
他方、2002 年のシステム障害後の対応については、顧客対応に適切性を欠き情報開示に迅速性・正確性を欠くなど緊急時対応においても不適切な対応が認められたとされた。
また、2011 年のシステム障害後の対応については、上記のとおり、システム復旧のための緊急時態勢が事前に準備されてはいたものの、その復旧対応手順書が実効性を伴っていなかったこと及び想定すべき事象が不足していたという問題があった。それらの背景には、2002 年のシステム障害後に再発防止策として障害発生の未然防止に重点を置く新規のシステムが開発されたことから、その安定的な稼働に安住し、異常時の復旧対応に取り組む意識が希薄になっていたこと、さらには、異常時の勘定系システム全体への影響の分析能力、多重障害の復旧見通しが立てられる実務人材の不足、外注先との合同実地訓練の不実施等の問題があった。
このように、事後の復旧作業の遅れ及び顧客対応の不備において、過去の障害事例との共通項が認められる。
ウ

システム障害発生時に通帳・カードを取り込む ATM の仕様

2 月 28 日障害では、多数の通帳・カードの取込みが発生し、顧客に多大な影響を与えた。
他方、過去のシステム障害においても、上記の 2018 年 6 月のシステム障害、2018 年 7 月
123

から 2020 年 7 月までの期間における障害、2019 年 12 月のシステム障害のそれぞれにおいて、通帳・カードの取込みが発生していた。しかし、そのいずれの障害後においても、通帳・カードの取込みに係る ATM 仕様の改善やその使用を前提とした対応方法について検討された形跡は見あたらなかった。
エ

月末の繁忙日のシステム上リスクのある行為の実行

2 月 28 日障害は、上記のとおり、e-口座一括切替処理を月末の日曜日に行う過程で発生した。
他方、過去のシステム障害を省みると、2016 年 2 月 29 日、すなわち月末に新しい外貨送
金管理システム（ソフトウェア）のリリースを行い、顧客への影響を大きくしていた。同事
例を踏まえ、月末には新システム（ソフトウェア）のリリースをしないことが改善策の一つ
とされた。
オ

まとめ

このように、本障害には、過去の障害事例との共通項がいくつも認められ、かつ、その一部は再発防止策の中で謳われた事項であるにもかかわらず、再度同じ原因により障害が発生しており、危機対応力や IT ガバナンス等の面に根深い問題があることを窺わせる。
第７

原因の総括

本委員会は、第 4 の原因分析及び第 6 で示した過去の障害事例と本障害の共通項等に照らし、一連の本障害に通じる原因として、①危機事象に対応する組織力の弱さ、②IT シス
テム統制力の弱さ、③顧客目線の弱さ、の 3 点が存在し、さらにその根底に④企業風土の問
題があると考える。これらはいずれも、今後の再発防止への取組みにあたり、基本的な課題として認識されるべきである。
１「危機事象に対応する組織力」に係る課題

一連のシステム障害という銀行の危機事象を通じて観察されるのは、MHFG、MHBK、MHRT 及
び MIDS の組織間連携及び組織内連携が十分機能しなかったことによる組織としての危機事
象への対応力の弱さである。
一般に、組織としての危機事象への対応力は、組織における各部門の横の連携、上下各層の縦の連携がいずれも緊密に保たれ、全体として有機的に一体として機能することで有効に発揮される。この組織としての対応力は、特に、想定外の事態（不測の危機事象）が生じた際に、その真価が試されることになる。
MINORI は、一箇所で生じた障害が波及し、MHBK の業務の様々なシステムに影響が及ぶ仕組みである以上、追加開発を行う際には、これに伴う事後的な処理等の局面を含む影響範囲の確認を慎重に行う必要がある。また、障害発生時は、システム関連部署以外からの情報も124

迅速・効率的に集約し、危機時における統括チームが、一元的かつ俯瞰的に実態を把握するという横の連携が適切に機能することが重要であり、その上で、経営陣にいち早く情報を伝え、経営陣及び権限を持つ者が迅速・的確に判断を下すという縦の連携も重要となる。
しかし、実際には、たとえば 2 月 28 日障害においては、上記のとおり、①取消情報管理
テーブル INDEX FILE のメモリ容量が影響調査の対象とされず、また、システム障害による顧客影響のリスクについてシステム担当部門と顧客対応部門とが連携して検討することもなかったなど、MINORI の開発時及び追加開発時に横の連携が不十分で影響調査に不備があり、②障害発生時に、他の部署からの情報を適切に把握するための連携がうまく機能しなかっただけでなく、一元的な情報集約を担うべき上記第 2・3・
（3）
・イ記載の有事対応に係る体制が機能せず（横の連携）、また、③経営陣への報告が遅く非常対策 PT の設置も遅れたな
ど経営陣に対する情報の連携も十分ではなかった（縦の連携）。
このように、不測の危機事象である本障害においては、横の連携、縦の連携のいずれも十分に機能せず、またこれらを統括すべき司令塔が本来の役割を果たせていないという、MHFG
及び MHBK を中心とする組織としての危機対応力の弱さが顕著に表れたものといえる。
また、
特に横の連携をスムーズに行えるようにするためには、その前提として、各部署が相互にその役割・機能を理解していることが必須であるが、役職員に対するヒアリング結果等からす
ると、MHBK では、システム担当部門と顧客対応部門の双方において他方の役割・機能に対する理解が不足していることが否めない。
２「IT システム統制力」に係る課題

MINORI は、システムとして巨大であるが故にその全体像を完全に把握することは容易でなく、不測の障害がシステムの別の箇所に波及して大きな影響を及ぼす可能性がある。また、人事異動や退職等による MINORI 開発段階から関与していた担当者の減少等も相俟って、時を経るにしたがってシステム構造がブラックボックス化し、その一方で、大規模開発がない
ことから新たな担当者の知識・経験が不足する、といった構造的なジレンマを抱えている。
また、MINORI の膨大な開発規模を考えると、障害発生を完全に未然防止することは困難であり、障害が発生することも想定した上で、障害からの回復までの時間の短縮及び障害による顧客への影響の極小化及び局所化のための方策を適時に実施する必要がある。
MINORI の安定稼働はもはや経営戦略上の最重要テーマであり、これに適切に対処する不断の努力が必須となり、人材及び予算等のリソースがリスクベースの考え方の下で適切に配分され、強力な IT ガバナンスに基づく適切な IT マネジメントが行われることが重要であるといえる。
しかし、2 月 28 日障害においては、取消情報管理テーブルの INDEX FILE の容量超過のリ
スクの看過、「みずほ e-口座案件」の追加開発のプロセスにおける基本設計、確認、テスト
及びリリース判定の各段階での担当部署による影響確認の甘さ、当日の立会態勢の不備、障害復旧対応における情報収集態勢等の問題、3 月 7 日障害では、カードローン案件に係る追125加開発の再鑑及びテスト並びに外部委託先の管理体制の問題、3 月 12 日障害では、障害発生時の復旧対応に関し、人材育成及び配置並びに訓練に関する問題並びに外部委託先の管理体制及び顧客対応における情報共有体制の問題がそれぞれ生じており、結果として IT ガ
バナンス及び IT マネジメントが十分機能せず、IT システムの統制力に脆弱性があると言わざるを得ない。
その背景には、以下のような問題点があるものと思われる。
（１）IT 人材の再配置問題について
このような IT ガバナンスの不備の顕れの一つとして、MINORI 移行後の IT 人材の再配置上の問題がある。
上記のとおり、MHFG の事業方針において、業務効率化の要請等を考慮しても、よりきめ細やかな人材のリソース配分の方針が示されないまま、MINORI 業務への人的リソースとコストの削減が計画されたことは、MHFG のグループ・ガバナンス上注視すべき点である。
この点、MINORI は 2019 年 7 月の移行から 2021 年 2 月 28 日の障害発生まで 1 年半ほどの「若い」システムであり、継続的な稼働の中で障害となり得るパターンが一定程度出尽くすような、「枯れた」システムとなるまでには、一定の時間を要するといえ、その間は、MINORIについての十分な理解のもと、障害の発生を阻止できるスキルのある人材を適切な部署に維持し、育成することが重要であり、これは経営陣の重要なミッションである。しかし、実際には、MHFG、MHBK 及び MHRT における、MINORI 稼働後の MINORI 業務に従事する人員減少、異動等により、2 月 28 日障害の発生時点で、MINORI の全体を理解できるスキルのある人材や MINORI 構築時のノウハウを有している人材の関与が減少していた。
この点と本障害との因果関係を明確に立証することは困難であるものの、本障害に関する事前及び当日の IT マネジメントの不備に鑑みると、このような人材配置及び人材育成上の問題が、本障害の背後にある要因の一つになった可能性は否定できない。
（２）システム安定稼働への備えについて
IT マネジメントの面で指摘すべき重要な視点として、2 月 28 日障害において、障害や顧客影響が拡大した大きな要因の 1 つに、障害が起きたのが休日であったという点がある。本
調査の過程でのヒアリングを通じて、障害発生が休日であったことが事態の悪化を招いた、
平日であればより迅速に対応できたなどという声が散見された。しかし、営業店が稼働しておらず、障害発生への体制も手薄となる休日や営業時間外における危機対応こそ、むしろより深くリスクマネジメントがなされるべきであり、そのことは誰もが容易に予測できたはずである。大規模なシステムリリースや一括切替処理は、今後も休日夜間に実施されることが多いと考えられるが、万一の場合を想定し、万全の立会体制で臨み、大規模障害が疑われるときは速やかに全体障害統制態勢に入るという基本徹底に重きを置くべきと考えられる。
また、上記第 4・1・
（2）
・イ・
（ア）
・ⅰ・
（ⅰ）のとおり、MHRT の各担当者は MIDS の担当
126

者とは異なり、品川シーサイド事務所において 24 時間 365 日体制で対応することまでは求められていないこと等から、実質的に 24 時間 365 日の監視体制に基づく迅速な本システム
障害復旧対応が行えない可能性がある状況であった。
MHBK では、24 時間 365 日のシステムを稼働させ、顧客に対し銀行としてのサービスを提供することを経営判断として行っている以上、公共インフラを担う側面がある銀行としては、その間の安定稼働を維持することが必須となるが、上記の事情に鑑みれば、休日や時間
外のシステムリスクに対する対応体制が十分機能していなかったことは明らかである。
（３）過去に発生した障害の原因との共通項について
上記第 6 のとおり、本障害のうち 2 月 28 日障害、3 月 7 日障害及び 3 月 12 日障害について、事前のテストの不備、緊急対応が適切さを欠いたこと、月末に大規模な処理を行ったこと、通帳・カード取込みといった過去事案との共通項が存在する。本障害の原因に通じる問題は過去にも生じており、これらを改善する契機はあったといえる。にもかかわらず、本障害が発生し、かつ、その対応に遺漏があったことに照らし、IT マネジメントの弱さが根本的に改善されずに体質として根付いている可能性を否定できない。
このように同様の障害事例を繰り返してきた根底には、経営陣以下組織全般に、システム
リスクに対する感度の低さがあると言わざるを得ない。
３「顧客目線」に係る課題

MHFG は、その企業理念として謳う「みずほ Value：役職員が「ビジョン」を追求していく
うえで共有する価値観・行動軸」の第 1 番目に、「お客さま第一」を掲げている。そうである以上、あらゆる事項について顧客の視点からの検討がされなければならないし、顧客に悪影響が生じる場合は、その抑止を最優先課題として対応すべきである。しかし、以下の点に顕れているとおり、顧客目線が弱く、これが本障害における顧客影響の拡大を招いていると考える。
（１）ATM の通帳・カード取込み仕様に係る問題意識について
ATM が広範囲に通帳・カードを取り込む仕様自体、何の責任もない顧客に不親切な設計であるが、IT 部門のみならず、ATM を担当する部署においてさえ、このような仕様であることをよく認識しておらず、顧客に与える不便に関する評価がされた事実は見あたらなかった。
そして、上記第 6 のとおり、過去数回にわたり、通帳・カードの取込みによって、顧客に迷惑をかけた事態が生じていたのであるから、顧客に不親切な仕様であることに気づく契機は存在していたが、MHFG 及び MHBK において、これを見直そうとする動きや少なくとも顧客に不便をもたらさないための方策を検討した動きは確認されなかった。
また、取込み仕様を前提としたとしても、取込みが大量に発生してオートフォンでの対応が追いつかない事態があり得ることは予測できたはずであるが、顧客の不利益を意識した
127

リスクの評価、規範の構築、周知（訓練）、見直しといったリスクマネジメントの各ステッ
プがいずれも不十分であった。
このように、ATM の通帳・カード取込み仕様とそれがもたらす顧客影響についての問題意
識のなさが、顧客の被害の拡大を招いた原因といえる。
（２）障害対応における顧客利益への配慮について
上記第 4・1・（2）
・イのとおり、2 月 28 日障害においては、関係部署は情報収集に努めた
ものの、どの部署も、システム障害の原因解明と復旧に注意が偏り、想像力を働かせて、あるいは実際に現場の情報を取りに行って、いち早く顧客の置かれている状況を確認することができず、顧客影響の拡大を防ぐ措置がなかなかとられなかった。顧客影響を最小化する
観点からは、取り込んだ通帳・カードを回収・返却するだけでなく ATM を停止させるなどの措置がより早期に検討されるべきであったが、それも具体的な検討・実施には至らなかった。
特に、取り込まれた通帳・カードを回収した ATM で、「復旧→取込み」の流れを繰り返したものが多数あること、2 月 28 日障害のみならず件数の少ない 3 月 3 日障害でも、取り込んだ通帳・カードの返却が翌日以降にずれ込んだことに顕著に表れたように、一連の対応は、
顧客の時間コスト等の負担を重視することからおよそ乖離しており、これが影響拡大を招いたという評価を免れない。
この顧客目線の弱さの一因として、過去の事象、平時の人事評価や人事育成の際に、顧客目線で積極的に行動することが評価されてこなかった可能性も否定できない。
（３）ATM 利用顧客への関心について
今回 MHBK の顧客対応として、システム障害について情報が少ないはずの営業店の方が、顧客影響の拡大防止に尽力している例（独自の判断によりいち早く ATM を使用停止として、
通帳・カードの取込み発生をゼロとした拠点もあった。
）が 2 月 28 日障害では散見されており、これは、営業店が ATM の管理を担っており、また、日々多くの顧客に接しているからであると考えられる。他方で、銀行業務では、従前から単純な入出金や送金が営業店の窓口
から ATM の利用に誘導されており、リテール部門における多くの顧客は、ATM でしか銀行と接しておらず、特に本部からすると「顔の見えない顧客」である。そのため、本部において、営業店が持っているような顧客に対する機動的な現場対応力が低下する結果となっているのではなかろうか。銀行の関心が、収益の大きな資産運用商品やローン取引に向くのは致し
方ないものの、圧倒的に多い ATM 利用客の利害への関心が薄れていることが、今回のようなシステム障害の対応において、問題を大きくしている。
４「企業風土」に係る課題

本調査には時間の制約もあり、役職員の主観的な意識や無意識にすり込まれた行動様式について踏み込んだ検証を行うには至らなかったものの、本障害を通して、システム障害等
128

の有事において、自らの持ち場を超えた積極的・自発的な行動によって、問題を抑止・解決するという姿勢が弱い場面がしばしば見受けられた。また、障害の内容・顧客への影響の全容が完全に明確ではない時点において、リスクがあるものとして、発言し行動することを控えるような状況も観察された。特に後者は、上記のとおり、2018 年 6 月の取込み事案において対応済みの旨を報告するにとどめた事実や、2 月 28 日障害の「障害報告メール」では「A2 ランク懸念」として「行外に軽微かつ限定的な影響を及ぼす障害」の懸念のみが記載
され ATM のエラー件数等の ATM 障害に関する具体的な情報が欠落していた事実等、これまでの度重なるシステム障害により、リスクの重大性を強く認識しているはずの MHFG 及びMHBK において、実際の行動ではあたかもリスクを低く見積もっているかのような、一見すると矛盾する行動として表れている。
企業において、役職員にこのような積極的・自発的姿勢が欠ける要因としては、積極的に声を上げることでかえって責任問題となるリスクをとるよりも、自らの持ち場でやれることはやっていたといえるための行動をとる方が、組織内の行動として合理的な選択になってしまう企業風土が挙げられる。そして、これとは逆に、たとえ間違っていたとしても改善の声を上げ、組織の持ち場を超えて意見を述べ、積極的に連携をするなどの行動が高く評価されず、間違いがあれば大きく評価を下げるような企業風土において、上記のような役職員の積極的・自発的姿勢が欠ける例がしばしば見られる162。いわゆる縦割りの組織構造において、あらかじめ決められた行動のみを行い、それ以外の行動をとることを禁じる（又は禁止まではされないものの評価されない。
）という組織においては、一般的には上記のような積極的な組織間連携を期待することは困難である。その結果、そういった企業においては、事前に想定しなかった事態が突発的に生じると、組織間連携の欠如により、いわゆるポテンヒ
ットが生じることとなり、環境の変化時や危機時においてこれが露呈することになる。また、前例がないことについて、新たな提案を行うことが困難となり、根本的な改善提案や業務におけるイノベーションを期待することも難しい状況となる。
本調査において、このような企業風土があったことを論理的に立証することには限界があるものの、特に過去の障害事例と本障害に共通項が存在し過去指摘された問題が依然存続していると考えられること、2 月 28 日障害の当日の対応において、顧客に対して後日通帳・カードを返却するためその場から帰ってよい旨の説明をするという対応が広がらなかったことや、ATM の利用を止めるという抜本的な決断がされずに繰り返し取込みが生じたこと等、これを裏付ける事実が数多く発見されたことからすると、失点を怖れて積極的・自発的な行動をとらない傾向を促進する企業風土が根底にあることが、合理的に推定されると162

いわゆる心理的安全性（psychological safety。対人関係において、従業員が恐怖や不安を感じずに率直に意見を表明できる状態。
）が確保されないような組織においては、声を上げること自体に対する不利益が、何もしないことの利益を上回るため、組織内連携の実効性が失われるだけでなく、より望ましい組織への改善やイノベーションの促進が期待できないこととなる。心理的安全性については、職場における健
全 な 文 化 の 特 徴 と し て 英 国 Financial Conduct Authority の ホ ー ム ペ ー ジ で も 言 及 さ れ て い る（https://www.fca.org.uk/culture-and-governance/psychological-safety）。

129

考える。このような企業風土と改革の必要性は、MHBK 及び MHFG 自身が自覚する必要があることは勿論であるが、それが容易ではないことも今回実証されたと言わざるを得ない。
第８１

MHFG 及び MHBK 策定の再発防止策の評価及び提言
MHFG 及び MHBK 策定の再発防止策の概要及びその評価

MHFG 及び MHBK は、本障害の原因分析を踏まえて、2021 年 6 月 2 日時点において、主に、以下を骨子とする再発防止策を実施し163、又は実施を予定し若しくは検討しているとのことである。
（1）システム関係① ATM 仕様変更、ハードウェア機器の改修
・顧客の取引が不整合になる場合を除き、原則通帳・カードを返却する仕様に改修
・障害発生時の顧客へのアナウンス方法につき、顧客向けの告知を可能とする ATM 画面の改修等② 監視システムと連携態勢の見直し
・現行監視機器の範囲内での監視機能改善に加え、自動化技術等も活用した監視システムの更なる高度化に着手③ MINORI 関連の総点検の実施
・未稼働の取引サービスや通常運行以外の稼働の確認④ システム部門における障害時訓練等の高度化⑤ 人材ポートフォリオの可視化と組織的な牽制態勢の強化
・人材ポートフォリオの可視化と人員再配置－スキルの可視化、IT 関連部門の人材配置状況の総点検と追加配置
・組織態勢の整備－1 線に「レビュー専門チーム」「インフラレビューチー
ム」を設置するとともに、ベンダーとの連携により「技術アドバイザリーデスク」を再設置、1.5 線として「技術・品質統括組織」新設、等
・開発プロセス（設計・開発・テスト・リリース）におけるチェック態勢の強化（多層的にチェックすべき案件の基準の設定）－リスクに応じたプロジェクト態勢の構築－開発工程における規程・チェックリストへの確認観点追163

2021 年 4 月 5 日時点における MHBK 及び MHFG の再発防止策の概要及び実施状況については、下記参照。
https://www.mizuhobank.co.jp/release/pdf/20210405_2release_jp.pdf

130

加（月末等、顧客・業務の影響が懸念される日程でのリリースを回避することを明示）－システムテスト工程の見直し－オンサイト立ち合いルールの明確化等（2）顧客対応・危機管① 顧客の声を把握し施策に活かす組織対応
・顧客や営業店の声、システム障害等を踏まえた商

理関係

品・サービスの総点検を実施
・今後も多面的に外部動向を収集・分析し、環境変化を捉えてサービス改善に繋げるための組織新設② 顧客や決済への影響を踏まえた平時からの態勢整備・有事の備え
・BCP を顧客影響や業務影響の大きい 30 程度の重要業務に大括り化、SCP と融合し、有事での顧客目線での迅速な対応に活用
・修正 BCP に基づく取引チャネル基点の訓練の実施、顧客影
響を自ら考える実戦型訓練の拡充
・危機管理担当役員の設置、危機管理室長の専担化（3）組織・カルチャー関係① 人と組織態勢の強化
・広い視野を持つ専門人材の積極的な活用－関連部門横断のキャリア開発、外部人材登用
・必要な経営資源配分には引続き十分に留意しつつ、構造改革を着実に推進（2021 年度において人員・経費枠等を予備的に拡充）② 行動様式の変革
・自ら考え動く行動様式の確立に向け、まずは役員から業務スタイルを変革・一人ひとりの学びや気づきを自律的に顧客サービスに活かしていくために、現場・本部一体となった運営を推進－ミスや失敗を減点評価するのではなく、前向きな提案・提言を積極的に評価－顧客対応の工夫・知見を、支店間、支店・本部間で日常的に双方向で共有するネットワーク運営－オープンで緊密なコミュニケーションの浸透（１）システムに関する再発防止策について
ア

概要
131

システムに関する主な再発防止策は、上記表（1）のとおり、①ATM 仕様変更、ハードウェ
ア機器の改修、②監視システムと連携態勢の見直し、③MINORI 関連の総点検の実施、④シ
ステム部門における障害時訓練等の高度化、⑤人材ポートフォリオの可視化と組織的な牽制態勢の強化等である。
イ

評価

MINORI の膨大な開発規模と障害の波及可能性の大きさに鑑み、システムの全体像を確実に把握しておくことが必要である。また、システム障害の発生を完全に未然に防止することは容易ではないことから、再発防止策として、仮にシステム障害が発生しても適時・適切な対応をとることができるように、組織知として MINORI に係る知識・ノウハウを保有することができる仕組みを整備することが極めて重要である。
この観点からは、上記表（1）・⑤のとおり、「レビュー専門チーム」「インフラレビューチ
ーム」「技術アドバイザリーデスク」の設置及び人員の増員等その他システム部門の人材の強化を行うとともに、システム横断的なレビューを実施することは、MINORI がまだ若いシ
ステムであり、障害の発生パターンをある程度絞ることができる状況にはないことを考慮すると、「IT システム統制力」を高めるものとして有益である。
他方、上記第 7・1 で述べた、「危機事象に対応する組織力」の観点からは、これらのチームの設置や、レビューの実施という外形的な枠組みを作るだけでなく、MINORI に関わる個々の役職員の意識改革がより重要となる。すなわち、自らの部署・担当範囲の内外において目的意識やミッションを共有し、十分な連携を心掛け、部署・担当範囲内外への声掛けやブレーンストーミング、相互の指差し確認による抜け漏れの防止等といった、有機的なコミュニ
ケーションを充実させ、相互の理解を深めることが重要となることに留意が必要である。
また、人員の再配置も、単純な人数の増加とともに「質」の確保が重要である。MINORI の全体を理解できるスキルのある人材や MINORI 構築時のノウハウを有している人材の関与が減少傾向にある中、そのスキルの承継と後継の育成に加え、それらの者に対するキャリア形
成上のインセンティブ等も考慮する必要があり、下記の専門性評価等の人事制度と併せて、適正な人材配置を図るべきである。
また、今後実施が予定・検討されている現行監視機器の範囲内での開発、運用部門間の連携態勢の見直しや新たな運用手法・自動化技術の活用については、MIDS に対する MHFG の出資比率が 35％にとどまることを踏まえると、その実施可能性には一定の制約が伴う可能性がある。そのような場合には、代替措置の検討等、柔軟な対応がなされることが期待される。
さらに、上記表（1）・⑤の開発プロセスにおけるチェック態勢の強化に関する各再発防止策は、いずれもそれ自体は有益なものと評価できる。他方、追加・修正プログラムのリリー
スだけに着目するのではなく、その後の移行処理（一括切替処理等）にも着目することを当然の前提とし、かつ、システムの修正が発生していない箇所についても十分に検討することとし、影響箇所の特定を行った上でのチェック及びシステムテストがなされることが重要132である。また、これらの再発防止策は、単に規程類に記載すれば足りるわけではなく、チェックやテストの範囲を拡大すれば良いというわけでもない。そのようなルールやチェックリストを新設するだけでは、想定外の危機事象に対し、そのチェックリストに記載がなかったなどの理由で問題が再発することとなる。開発工程に携わる全ての者が、自己が担当する部署の業務範囲に限った問題意識のみを持つことで足りるとしないよう、MINORI 全体に関する理解を深め、MINORI を含む銀行としてのシステム全体及び顧客へのサービス全体への波及効果を常に考えるべきである。
また、2 月 28 日障害においては、閾値に抵触した旨のエラーメッセージは当日の立会を実施していた MHRT が対応し、MIDS での対応は不要とされていたものの、実際には当該エラーメッセージに対する対応が MHRT ではとられなかったという事情もあったことから、多層的にチェックすべき案件基準の設定が適切に行われ、オンサイトでの稼働状況確認による立会が実効性を持ったものとなるよう、その確認内容についての検討が必要となると考えられる。
次に、テストのあり方について、2002 年及び 2011 年のシステム障害、2 月 28 日障害、3
月 7 日障害の各障害に共通した弱さがみられるところであり、正常系テスト164、準正常系テ
スト165や異常系テスト166等の採用も検討することが望ましい。また、月末等、顧客・業務の影響が懸念される日程でのリリースを回避するという点は、2016 年の過去事例及び 2 月 28
日障害に共通する問題への直接的な対応であり、システム障害の発生を防ぐために実効性ある施策であると考えられるが、2016 年の障害時も同様の確認がされていたことから、再度の周知徹底が必要であるほか、システムのリリースだけでなく、移行処理についても同様の考慮が必要となる。
上記表（1）
・①の再発防止策のうち、2 月 28 日障害において顧客影響の拡大に繋がる最大の問題であった通帳・カードの取込み仕様が改修される点は、区画閉塞やネットワーク障害の場合にも原則として通帳・カードを返却する仕様に変更されたことにより、同種の問題が発生した場合の影響の拡大を直接的に防止できることから、目に見える有効な再発防止策であると評価できる。また、障害発生時の顧客へのアナウンス方法の見直しは、顧客に対しいち早く情報提供し顧客の不便や不利益を最小化する、顧客に代替的な対応を促すといった視点での施策であり、上記第 7・3 で指摘した顧客影響への意識が足りなかったことへの反省に立ったものといえる。
なお、各再発防止策について、「現行監視機器の範囲内での監視機能の改善」等、現時点
では抽象的な内容にとどまるものも散見されることから、その部分については、今後より具体的なタスクとして精緻化していくことが望まれる。

164

テスト対象が、定常時に仕様どおりに正常に動作するかを確認するテスト。
テスト対象が、異常発生時に仕様どおりに正常に動作するかを確認するテスト。
166
テスト対象に仕様外の異常が発生した際に、どのように振る舞うのか（暴走の有無、被害の範囲）を確認するテスト。
165

133

（２）顧客対応・危機管理に関する再発防止策についてア

概要

顧客対応・危機管理に関しては、上記表（2）のとおり、①顧客の声を把握し施策に活かす組織対応及び②顧客や決済影響を踏まえた平時からの態勢整備・有事の備え等の、平時・有事において顧客目線を徹底する態勢整備に関する再発防止策が提示されている。
イ評価

顧客の声を把握し施策に活かす組織対応（①）については、本障害や過去の顧客からの苦情等を踏まえて顧客目線で業務を考える意識を根付かせるための方策として有益であると考える。特に、2018 年 6 月の通帳・カードの ATM への取込み事案等過去の通帳・カードの取込み事象が十分に組織内で共有化されず、問題点の検討も不十分であったことに鑑みれば、顧客の声やシステム障害を踏まえた商品・サービスの総点検は、サービスの問題点を顧客目線に立って洗い出すものとして非常に重要である。今後もこのような顧客からの苦情等及び顧客に近い営業店等の現場の意見の吸上げとそれに対する真摯な検討を継続的に行うことが強く望まれる。
顧客や決済への影響を踏まえた平時からの態勢整備・有事の備え（②）については、障害対応において組織力を結集し高める上で不可欠であり、有益である。特に、危機管理担当役
員の設置や危機管理室長の専担化は、システム障害を含む危機に際して、全社的に関連情報を一元的に集約・分析し、初動対応を含め迅速かつ的確な危機対応にあたることを可能にするものとして高く評価できる。その実施に当たっては、適材の配置が肝要であり、強い権限を持たせる必要がある。また、危機管理にあたる者は、特に休日・業務時間外に、しかも想定外の緊急事態が発生する可能性を常に念頭におく必要がある。加えて、従前の BCP では、
休日のシステム障害等により通帳・カードの取込み件数が ATM センターの対応能力を超える事態に至るリスクについての議論、それを踏まえた BCP の見直し等の事前準備・対応策の検討も十分になされていなかったと認められる。この点、BCP の見直し等に関する再発防止策も、リスクの洗出しや有効な BCP の不足を改善し、また訓練等によりその実効性を確保するものとして重要である。
（３）組織・カルチャーに関する再発防止策についてア

概要

組織・カルチャーの強化の観点からは、上記表（3）のとおり、①広い視野を持つ専門人
材の積極的な活用、また②行動様式の変革としてミスや失敗の減点評価の廃止、予防的観点からの前向きな提案・提言を積極的に評価する制度の導入等の再発防止策が策定されてい
る。

134

イ

評価

上記の再発防止策は、いずれも人事制度・従業員教育等の側面から、横の連携・縦の連携を促すカルチャーの向上を図るものであり、危機事象に対応する組織力の強化、システムリ
スクに対する感度及び対応体制の強化の観点から有益といえる。組織の上下を問わず、また部署を問わず、システムに対する理解を深め、また、システム部門でも一人ひとりの顧客影
響を具体的にイメージできるように、これらの施策を継続的に行っていくことが有効であると考える。また、失敗事例をマイナス評価せず、これを広く共有し次に活かそうとする人事制度や、オープンなコミュニケーションを推進する方策は、上記第 7・4 で指摘した失点を怖れて積極的・自発的な行動をとらない傾向を促進する企業風土を是正するために有効であり、かつ、顧客対応部門において、本部からの指示を待たずに率先して臨機応変に顧客対応することを促すものであり、顧客を第一に考えた運用の観点からも有用なものと評価できる。
特に、要所への「外部人材の登用」は、MHFG やそのグループ会社に現状足りない点を補完し、あるいは専門性を高める即戦力として機能するのみならず、組織に新しい風を吹き込
み、内部者とは異なる視点で様々な問題提起をしてくれることが期待され、ひいては、上記の企業風土を根本から変える契機になり得るものとして、高く評価できる。その実施にあたっては、組織として、その闊達な職務遂行を積極的に尊重・サポートすることが重要であり、適材の確保が求められる。
なお、本委員会は、以上のほか、別紙 9 ないし 11 記載の各点を、状況に応じて選択的、
あるいは補完的な方策として考慮するよう付言する。
２

再発防止策実施に係る提言

上記のとおり、MHFG 及び MHBK により実施され、又は実施が予定・検討されている再発防止策は、多角的視点から網羅的に策定されており、いずれも本事象の再発防止のために有効であると評価できる。
これらの再発防止策は、組織、ルールや手続を表面的に変更すれば足りるものではなく、その実効性と継続性の確保が不可欠である。そのためには、当該方策の趣旨、目指すものが何であるかを経営陣が明確に示して、あらゆる部門、全役職員に周知させ、目的意識を持って主体的に事にあたらせる必要がある。上記第 7 の基本的課題 4 点は、そのような再発防止に向けた取組みにおいて指針とされるべきである。その継続的な努力の積重ねと定期的なフォローアップの実施によって初めて、企業風土の変化とともに、その実効性を確保できるものと思われる。
第９結語

銀行を取り巻く環境は大きく変化している。その一つは、かねて店頭で行われてきた業務の多くが IT システムに代替され、今や IT システムの稼働自体が銀行業そのものとさえい135

える状況になっていることである。そして、24 時間 365 日の利用も可能な ATM やネットバ
ンキングを利用した送金や預金の入出金がそれらの過半を占め、顧客との接点が店頭から
IT システムへ、平日昼のみから休日夜間まで、大幅に移行していることからも伺えるように、IT システムは、現代社会において人々の社会生活や経済活動の基盤、すなわち社会的インフラの一部を構成している。これらの傾向は今後もさらに進むものと思われる。
このような変化は、銀行業における IT システムの構築、運用の重要性を飛躍的に増大させた。
銀行業を営む上で、
いつでも起こり得る IT システムの障害をできる限り未然に防ぎ、発生した障害には迅速・的確に対応してその顧客への影響を最小化し、また、IT システムに対するサイバー攻撃による被害を防いで、安定的な稼働を続けつつ、顧客サービスの質的向上、利便性を高めることは、銀行業を営む者の社会的責任であり、かつ、競争力の源泉である。銀行業を営む者は、堅牢で利便性に優れた IT システムの構築と、その安定的な運用につき、企業の存亡をかけて戦略的に取り組む必要があるのではないか。その際、IT シス
テムの向こう側にいる数多くの「顔の見えない顧客」への最大限の配慮こそが「顧客第一」の理念に沿うのであり、重要な経営課題であるともいえる。その追求によって、MHBK が強
靭な「システム運用力」を手に入れたとすれば、それは MHBK の強みになる。
MHBK は、
そのような中、2002 年及び 2011 年に続いて 2021 年にも本障害を発生させた上、対応を誤って顧客に多大の不便を強いるなどの顧客影響を拡大させた。MHFG は、そのことを真摯に深く受けとめるとともに、IT システムの銀行業における上記重要性を再認識して、その再発防止に多角的視点から誠実かつ継続的に取り組むことが、強く求められる。
以

136

上

別紙１ 委員略歴
岩村 修二 （いわむら しゅうじ）
1973年3月

中央大学法学部法律学科卒業

1976年

検事任官

1997年～2005年

東京地検特捜部副部長、同特別公判部長、同特捜部長、松山地検検事正2005年～2008年

最高検検事、東京地検次席検事、最高検刑事部長

2008年～2010年

東京地検検事正2010年～2012年

仙台高検検事長、名古屋高検検事長

2012年～2019年

長島・大野・常松法律事務所顧問

2020年～2021年

東京フレックス法律事務所

2021年～現在

T&K法律事務所

鵜瀞 惠子 （うのとろ けいこ）
1977年3月

東京大学経済学部卒業

2000年～現在

専修大学大学院経済学研究科非常勤講師

2004年～2012年

公正取引委員会事務総局首席審判官、経済取引局取引部長、官房総括審議官、経済取引局長

2013年～2020年

東洋学園大学現代経営学部教授

2012年～現在

弁護士法人大江橋法律事務所アドバイザー

2019年～現在

規制改革推進会議投資等WG専門委員

2020年～2021年

東洋学園大学現代経営学部特任教授

2021年～現在

公安審査委員会委員
学校法人東洋学園理事長補佐137西川 清二 （にしかわ せいじ）
1980年3月

電気通信大学大学院電気通信学研究科修了

2003年～2006年

株式会社NTTドコモ情報システム部長

2006年～2012年

同社執行役員情報システム部長

2012年～2014年

同社常務執行役員CIO情報システム部長

2013年～2020年

ドコモ・システムズ株式会社代表取締役社長

2020年～2021年6月11日

同社取締役

角谷 直紀 （かどたに なおき）
2004年3月

東京工業大学大学院総合理工学研究科修了

2005年～2016年

長島・大野・常松法律事務所

2011年5月

Duke University School of Law修了

2016年～現在

T&K法律事務所

2019年～現在

第一東京弁護士会弁護士業務の適正化に関する委員会委員

2019年～現在

東京三弁護士会合同非弁護士取締委員会委員

2020年～現在

一般社団法人日本商事仲裁協会（JCAA）仲裁人・調停人

2021年～現在

第一東京弁護士会綱紀委員会委員

以

138

上

別紙３ MHFG グループ事業系統図（2021年４月１日現在）＜主な関係会社＞●当社が直接経営管理を行う主要グループ会社（セグメント）その他（略）

公金大
共融企
法・業
人
・

その他（略）

ー

カ事リ
ン業テ
パ法
ニ人ル
・
ー

ー

カグ
ンロ
パ
ニバ
ル
コ

ー
ー

ポ
レ
ト

ー

●
み
ず
ほ
証
券
株
式
会
社

その他（略）

ー

カマグ
ン
ロ
パケ
ニッバ
ツル

●
株
式
会
社
み
ず
ほ
銀
行

●みずほ信託銀行株式会社

ー

該当なし

ー

ー

株
式
会
社
み
ず
ほ
フ
ィ
ナ
ン
シ
ャ
ル
グ
ル
プ

マア
ネセ
ジッ
メト
ン
ト

その他（略）

（その他）

ー

ユプグ
ニロロ
ッダ
トクバ
ツル

その他（略）

ー

ユコリ
ニンサ
ッサ
トルチ
テ＆
ィ
ン
グ

●みずほリサーチ＆テクノロジーズ株式会
社
その他（略）その他●ＭＩデジタルサービス株式会社（※）（※）持分法適用関連会社

その他（略）

151

別紙４

MHFG 組織図（2021 年 4 月 1 日現在）

株

主

総

会

指名委員会

リスク委員会

報酬委員会

取締役会

人事検討会議

監査委員会

社外取締役会議

監査委員会室

取締役会室

経営会議

執行役社長

業務監査委員会

経営政策委員会

リテール・事業
法人カンパニー

コ

フ

タ
マ
ネ
ジ
メ
ン
ト
部

ョ

シ

ン
部

お
客
さ
ま
相
談
室

フ

デ

シ

リ
ス
ク
管
理
室

リ

ュー

・
デ

グ
ロ

バ
ル
室

シ
ス
テ
ム
リ
ス
ク
管
理
室

セ
キ

プ
ロ
ジ

リ
ス
ク
管
理
室

ェ

ブ
ラ
ン
ド
マ
ネ
ジ
メ
ン
ト
室

ー

ク
推
進
室

広
報
室

ー

危
機
管
理
室

ャ

推
進
室

プ
経
営
管
理
室

デ
ジ
タ
ル
ワ

ュー

ィ

タ
企
画
室

グ
ル

ィ

ー

プ
デ

事
業
開
発
室

ー

サ
ス
テ
ナ
ビ
リ
テ

ー

グ
ル

ー

人
材
戦
略
室

Ｉ
Ｔ
・
シ
ス
テ
ム
統
括
部

ク
ト
総
括
室

リ
テ

内部監査
グループ

事
務
企
画
部

業
務
監
査
部

＆
デ

ー

＆
デ

Ｉ
Ｔ
・
シ
ス
テ
ム
企
画
部

ィ

ー

ニ
ケ

ビ
ス
部

リ
テ

ー

マ
ネ
ジ
メ
ン
ト
部

セ
キ

事務
グループ

ュ

ィ

ト
・
コ
ミ

お
客
さ
ま
サ

ィ

シ
リ
テ

ュ

管
理
部

ポ
レ

ー

企
画
管
理
部

ァ

戦
略
企
画
部

ュ

ア
ビ
ジ
ネ
ス
推
進
部

資
産
運
用
ビ
ジ
ネ
ス
戦
略
部

ー

フ
ロ
ン
テ

ー

ル
・
事
業
法
人
業
務
部

個
人
業
務
部

ィ

法
人
業
務
部

ー

リ
テ

ＩＴ・システムグループ

企画グループ

タ
マ
ネ
ジ
メ
ン
ト
部

人
材
マ
ネ
ジ
メ
ン
ト
室

事
務
リ
ス
ク
管
理
室

ィー

テ

推
進
室

大企業・金融・
公共法人
カンパニー

グローバル
コーポレート
カンパニー

グローバル
マーケッツ
カンパニー

アセット
マネジメント
カンパニー

グローバル
プロダクツ
ユニット

リサーチ＆
コンサルティング
ユニット

財務・主計
グループ

152

リスク管理
グループ

人事
グループ

コンプライアンス
統括グループ

デジタルイノベーション部

秘書室

別紙５ MHBK 組織図（2021 年 5 月 31 日現在）
株

取締役会室

経営会議

主

総

会

取締役会

監査等委員会

頭 取

業務監査委員会

監査等委員会室

内部監査グループ

経営政策委員会

リテール・事業法人部門
リテール・事業法人業務部

企画グループ

人材戦略室

戦略企画部

事業開発室

企画管理部

グループ経営管理室

個人業務部

デジタルワーク推進室

法人業務部

危機管理室
コーポレート・コミュニケーション部

フロンティアビジネス推進部

広報室

リテールデジタル開発部

リテールデジタル室

個人マーケティング推進部

ローン営業推進室

管理部

ブランドマネジメント室

業務管理室

ファシリティマネジメント部

ライフデザインサポート室

お客さまサービス部

お客さま相談室

セキュリティ＆データマネジメント部

フィデューシャリー・デューティー推進
室
リスク管理室

総合ローン業務センター
無担保ローン業務センター
宝くじ部
ウェルスマネジメント部
コンサルティング部

IT・システムグループ

法人推進部

国際営業推進室
法人ソリューション戦略室

リテール法人推進部

グローバル室ＩＴ・システム企画部

システムリスク管理室

ビジネス金融センター

イノベーション企業支援部

ＩＴ・システム統括第一部

リテール・事業法人コンプライアンス部

営業店管理室ＩＴ・システム統括第二部

審査第一部

与信業務モニタリング室

ＩＴサービス推進部

システムセンター

審査第二部

米州システム部

企業戦略第二部

欧州事務・システム部

融資部

アジア事務・システム部
セキュリティ＆データマネジメント部

プロダクツ審査部

リスク管理室企業調査部
エリア

事務グループ

営業店

事務企画部

人材マネジメント室
事務リスク管理室
事務センター

その他（略）

大企業・金融・公共
法人部門

グローバル
コーポレート部門

グローバル
マーケッツ部門

アセット
マネジメント
部門

グローバル
プロダクツ
ユニット

リサーチ＆コンサル
ティング
ユニット

153

財務・主計
グループ

リスク管理
グループ

人事グループコンプライアンス統
括グループ

デジタル
イノベー
ション部

秘書室

別紙６ MHRT 組織図（2021 年 4 月 1 日現在）

154

別紙７ MIDS 組織図（2021 年 4 月 1 日現在）
株主総会
監査役
取締役会

代表取締役社長(CEO)

業務監査委員会

業務監査部

(CRO)

サービス事業部門
副社長(COO)
サービス管理部
企画グループ

技術サービス推進部(CHRO)

多摩管理部

システムサービス
第１グループ

多摩業務部

人事グループ(CFO)
管理グループ

千葉管理部

システムサービス
第２グループ

千葉業務部

ユーザーサポート部

システムサービス
第３グループ

ＥＵＣサービス推進部
西葛西運用第１部

システムサービス
第４グループ

西葛西運用第２部

国領信託運用部

システムサービス
第５グループ

国領公共業務部

渋谷管理部

業務サービス
グループ

渋谷業務部

155

別紙８ 取引チャネル別取引件数・取引金額

チャネル別取引件数・個人（21年3月）【平日+祝休日】
取引件数（件）

取引金額（円）

ア ネ

ル

ル

別

別

全チャネル

ャ

ア ネ

ェ

ャ

シ チ

ェ

シ チ

27,558,875

100.0%

4,718,261,534,418

店頭／窓口（WING端末）

1,180,560

4.3%

2,482,861,874,124

52.6%

非対面（ダイレクト／ATM）

26,378,315

95.7%

2,235,399,660,294

47.4%

2,350,049

8.5%

407,915,936,428

8.6%

2,330,569

8.5%

407,484,032,235

8.6%

18,5980.1%

237,696,990

0.0%

882

0.0%

194,207,203

0.0%

24,028,266

87.2%

1,827,483,723,86638.7%

みずほダイレクト
インターネットバンキング
モバイルバンキング
テレフォンバンキング
ATM
当行ATM

100.0%

17,295,281

62.8%

1,467,280,918,449

31.1%

店舗内ATM

8,302,081

30.1%

791,038,940,267

16.8%

店舗外ATM

8,884,009

32.2%

667,526,966,603

14.1%

109,191

0.4%

8,715,011,579

0.2%

532,320

1.9%

33,466,181,312

0.7%

その他（企業内ATM等）
統合ATM
共同利用ATM

2,118,994

7.7%

129,456,531,105

2.7%

CAFIS

4,081,671

14.8%

197,280,093,000

4.2%※取引件数・取引金額は、個人保有の口座の入金・支払を集計したもの

チャネル別取引件数・個人（21年3月）【祝休日】取引件数（件）

取引金額（円）

ア ネ

ル

ル

別

別

全チャネル
店頭／窓口（WING端末）
非対面（ダイレクト／ATM）
みずほダイレクト
インターネットバンキング

ャ

ア ネ

ェ

ャ

シ チ

ェ

シ チ

3,445,843

100 0%

209,937,616,555

362

0 0%

5,663,000

100 0%
0 0%

3,445,481

100 0%

209,931,953,555

100 0%

368,691

10 7%

48,485,811,979

23.1%

366,177

10 6%

48,429,518,988

23.1%

モバイルバンキング

2,403

0.1%

18,719,684

0 0%

テレフォンバンキング

111

0 0%

37,573,307

0 0%

3,076,790

89 3%

161,446,141,576

76.9%

1,667,238

48.4%

98,479,778,046

46.9%

ATM
当行ATM
店舗内ATM

618,060

17.9%

42,374,275,709

20 2%

店舗外ATM

1,047,603

30.4%

56,041,745,436

26 7%
0 0%

その他（企業内ATM等）

1,575

0 0%

63,756,901

統合ATM

108,869

3 2%

4,733,705,471

2 3%

共同利用ATM479,646

13.9%

27,063,853,059

12.9%

CAFIS

821,037

23 8%

31,168,805,000

14 8%※取引件数・取引金額は、個人保有の口座の入金・支払を集計したもの156

別紙９ 障害発生の可能性を減少させるために考慮に値する事項
以下は、各本障害の再発防止策としてシステムの修正を検討する際に、状況に応じて選択的に、あるいは補完的な方策として検討に値する事項（個別修正）、及び MINORI の総点検を実施する際に同様に検討に値する事項（個別修正の水平展開）である。
第１１

2 月 28 日障害について
個別修正

2 月 28 日障害に対する個別修正としては、以下のような対応が考えられる。
（１）定期性預金システム DB 更新ができない場合のエラー設計の見直し
定期性預金システムにおける DB の更新失敗時に、DB がロールバックされている状態の場
合は、取引メインが不要な自動取消を実行しないよう、ソフトウェア A から取引メインに対してロールバックされている状態であることをエラーとして送信するように見直す。
ただし、処理結果詳細コード167とコミット・ロールバック結果種別168の変更方法は、現状の処理判定を踏まえて検討することを要する。
【図 40】（２）処理区画全閉塞の防止
パーコレートエラーが多発することにより、ATM 処理区画の閉塞が発生し、ATM を起点とする全ての取引が利用できないといった事態が生じないように各種パラメータ169の調整を
行う。

167

ソフトウェア A 上で使用する処理結果の状態をコードとして体系化したもの。
DB の更新処理において、コミット（更新処理が確定した。）したかロールバック（更新処理が失敗して元に戻った。
）したかの状態を表す。
169
システムの動作に影響を与える、変更可能な値。
168

157

調整に際しては、全ての処理区画閉塞までの時間を調整できる各取引チャネルの「処理区画数」、取引サービスを禁止することでエラーの発生頻度を調整する「取引サービス禁止の作動条件となるエラー数」、
個々の処理区画閉塞処理の発生頻度を調整する制御機能 A の「処理区画閉塞条件となるパーコレートエラー数」に加え、「各取引チャネルの画面上のメニュ
ー抑止」、「障害発生元システムの切離し」を加味し、MINORI 全体のシステム負荷とリソー
スを総合的に考慮する。
【図 41】

２

水平展開（１）取消情報管理テーブルの INDEX FILE に係るメモリ容量超過の防止① サービスリリース時やイベント時の影響調査方法を改善し、MINORI における全ての開発案件（一括切替処理等の移行作業を含む。
）において、業務担当及びインフラ担当の両方が影響確認し、調査範囲を決定する。
② トランザクション量が増加した場合に、システム上のボトルネックや障害になり得る
ポイントが他にないかテーブルごとに検証する。
③ 各テーブルについて、それぞれ、常時監視及び予兆監視を行うとともに、キャパシティ
管理がシステムや業務特性に応じた設計となっているかを確認する。
④ 本番環境リリースを行う際に、リソース及びログを確認する。また、本番環境リリース時に想定したリソース以上の変動がないか、想定外のメッセージの出力がないかの確認も行う。
⑤ 作業実施に際して、本番環境における作業影響、作業日等を決定する際のリスク検討を行う。
（２）定期性預金システム DB 更新失敗時のエラー設計の見直し
158

各システムが取引メインへ送信する MINORI 共通電文の処理結果コード及び当該コードを受信した際の取引メインの動作を改めて確認し、業務上想定外のパターンがないか洗出しを行う。その際、準正常系の処理を含めた動作が正常に行われることを確認するため、有識者が有する知見と想像力でパターンを検討する。
第２3 月 7 日障害について（水平展開）

１

プログラムミスに関する検査の強化① 処理内容に変更がない場合においても、MINORI に関連した何らかのプログラム改修を行う際は、該当プログラムの呼出し元、呼出し先を含めた事前の影響調査を十分に行う。
② 一般的な変数初期化を行う場合、既存ツールや機能を有効活用したチェックの強化を図る。
③ 既存のツールや機能では網羅できない範囲については、担当者の裁量が介在しない機械的なチェック機能を導入することを検討する。
２

プログラムミスを発見する方策① 設計担当者と再鑑者を分離するルールに則ったレビューができているかのチェックを行うことで、プログラムレビューにおける検出精度の向上を図る。
② 共通で利用しているプログラムに対する改修については、本来の目的外の利用についても正常系テスト、準正常系テスト及び異常系テストを実施する。
③ テストを実施する際の前提条件（初回実行か複数回実行時の場合か等）を見直し、テス
トによる障害検出の向上を図る。
第３１

3 月 12 日障害について（水平展開）
ディスク装置内制御装置のハードウェア故障に係る水平展開① サーバ、ストレージのドライバ及びファームウェアの組合わせによる不具合発生事象の有無及びベンダーでの試験実施状況の確認を行う。
② ベンダーが提供しているサービスを利用するような形態の基盤においては、サービス
契約上のサービスレベルに係る条項の有無及び内容を再確認し、特に、故障発生時における回復時間の規定や時間超過時の対応等の内容を見直す。
③ ハードウェアベンダーより提供されているドライバ及びファームウェアの不具合情報について、保守運用における管理面から、同一製品に関しては極力バージョンを統一した運用が望ましく、利用している同一製品においてドライバ及びファームウェアの定期的なバージョンの確認を行う。
２

外為システムにおける処理遅延に係る水平展開① ジョブ実行ステータスの誤認を防ぐため、ジョブ実行時の手順書にステータスや処理
159

結果の確認等の項目を記載し、これをジョブ再実行における基本的な行動指針とする。
② ジョブの再実行時に、人手による復旧作業を極力なくすため、ジョブの仕様や実行条件の見直しを行う。マニュアルオペレーションによるリカバリが必要な場合、発生し得る
障害パターンごとに復旧に必要となる入力情報や手順の整備を行う。
③ 実際の故障に倣った故障対応復旧訓練を定期的に行い、必要に応じて、各ジョブの実行
条件やリカバリ方法の再点検を定期的・継続的に行って、復旧にかかる時間の短縮化及びオペレーション精度の向上を図る。
④ 障害発生時においては、リカバリ作業に必要な体制を確保し、システム状況（罹災状況、
ジョブステータス等）を調査し、復旧シナリオ（リカバリ作業手順準備、作業開始予定
時刻、作業終了予定時刻、進捗管理方法、チェックポイント、連絡体制等）を組み立て、障害復旧に際してこれらを共有し確認した後に、リカバリ作業を開始する。

160

別紙 10

顧客への影響の極小化・局所化のために考慮に値する事項

以下は、障害発生からの復旧までの時間の短縮及び障害発生による顧客影響の極小化・局所化のため、状況に応じて選択的に、あるいは補完的な方策として検討に値する事項である。
第１

運用ツールの改善案

適切な判断、一次措置対応に繋げる目的から、以下のような運用ツールの改善検討を行う。
１

エラーの見落とし防止

監視ツールについて、エラーの見落としが発生することを防止する目的から、以下のような改善を行うことが考えられる。
・NOI システムのパフォーマンス向上を図ることでメールの配信遅延をなくす。
・エラーの重要度に応じて真に通知すべきメッセージか否かの再選定を行い、NOI システムにおけるメールの配送遅延を軽減する。
・重大エラーを別画面に表示し、見落としの防止を図る。
・MHRT の開発部門にも MIDS と同様の監視端末、重大エラー端末170を設置し、エラーメッセージが即時に確認できるようにする。
２

システム全体のエラー発生状況を俯瞰的に確認するための改善

複合的な問題を有する障害発生時に対する改善として、システム全体のエラー発生状況を俯瞰的に確認することができるよう、以下のような改善を行うことが考えられる。
・トランザクションの処理状況、重大エラーの発生箇所をリアルタイムで俯瞰的に確認可能とする（下記図 42 の①）。
・重大エラーの種別とその発生件数を定期的に確認できるようにする（下記図 42 の②）。

170

重大なエラーを表示するための端末。

161

【図 42】

３

顧客の声活用に向けた改善

顧客の状況をシステムの故障復旧対応に活用するため、以下のような改善をすることが考えられる。
・ATM センターにて監視している ATM の稼働状況を反映する画面をデータセンターA にも設置し、運用部門においても ATM 取引チャネルの状況を個別検索で確認できるようにする。
・ATM 稼働状況を個別検索なしで一元的に表示できるようにする。
・インターネットのニュース、顧客の声（SNS の書き込み等）を迅速なシステム対応に活用する。
４

情報連絡ツールの導入

ビジネスチャット等を活用することで、運用部門からビジネス部門、経営層まで迅速かつ職位にかかわらない情報連携とコミュニケーションを行う。これにより、運用部門や開発部門から即時発信することで、情報共有を速やかに行うことが可能となる。

162

【図 43】５

電話受付方法の改善

既存の音声応答装置を利用することで、障害時専用の「緊急音声ガイダンス」を準備し、障害発生時は迅速にこれに切り替えることで、顧客の再度の架電を抑止するとともに、重大障害が発生していることを顧客に通知する。
これにより呼損率が上昇した場合においても顧客へ不要な負担を強いることを防止できる。
【図 44】

また、下記図 45 のような IVR171というコールセンターの既設設備を活用し、オートフォ

171

Interactive Voice Response の略称。自動音声応答のこと。

163

ンからの架電先・架電フローを IVR に追加することができれば、上記の対策がより効率的に実現できる。
【図 45】

第２１

役割分担の改善案
早期の障害復旧へ向けた体制の構築

システム障害への対処において、重要なエラーを把握し、問題のある箇所を切り分け、迅速に対処することで顧客影響の極小化・局所化を図る。
上記の観点から、サービス全面復旧までの障害復旧対応を、障害発生の検知、分析、一次措置（関連作業の停止、サービス抑止、閉塞の解除、二次措置に向けた情報収集）、二次措置（障害原因を取り除いた上での全面復旧）に分け、一次措置のうちあらかじめ定められた範囲の措置については、現場の担当者において能動的にその判断・実行をする権限を有する体制とする172。

172

ただし、対処に関して詳細な調査を要する場合については開発部門の協力を仰ぐ。

164

【図 46】２

24 時間 365 日の即時の障害復旧対応

現状は、夜間、休日又は祝日等に障害が発生した場合には、MHBK や MHRT の役職員が駆け付けた上で対応することとなり、参集までに一定程度の時間を要し、即時の調査や障害対応を行うことは物理的に困難である。
そこで、一次措置のうちあらかじめ定められた範囲の措置を行う体制を 24 時間 365 日体制とし、障害復旧対応の要否を判断し実施できるようにする。
３

迅速な一次措置のための運用体制

中長期的には、迅速な一次措置のためのシステム運用体制として、24 時間 365 日体制とし、①障害時の統率及び陣頭指揮を行う責任者（コントローラ173）、②情報の集約及び伝達を司る情報統制者（情報統制者）、並びに③障害の監視、調査、分析及び措置を行う要員（監視・調査・分析・措置担当）で構成する。迅速な一次措置のためのシステム運用体制を目指
すため、これらの者は同一の場所で活動する。
このような障害復旧対応統括体制は、以下の役割を果たすことを想定。
①

システムのエラー等の情報収集②

あらかじめ定められた範囲内の一次措置の実行③

関係部署との情報連携④（一次措置に係る権限を超過した場合）全体統制の立上げに向けた報告⑤

障害復旧対応に係るタスク管理

173

銀行システムに関する深い知見を有し、重要サービスの内容とそのサービスを実現するためのシステム
間連携や構成要素等に知見を有している人材であること、障害復旧対応に関する一次措置に係る権限のう
ち一定程度の権限はコントローラに一元化して委ねることが望ましい。

165

⑥

（全体統制立上げ後）ジョブの状況やエラーの状況等の情報収集と全体統制への報告⑦

実施した障害復旧対応を踏まえての知識及びノウハウの集約及び整理【図 47】■障害発生時の対応フロー
・障害発生後、「監視・調査・分析・措置担当」は「コントローラ」へ報告し、「顧客窓口担当」は ATM 等に関する顧客窓口への申告や問合わせ状況等を「コントローラ」へ報告する。
・「コントローラ」は MINORI 全体のエラー等の情報を収集、把握する。詳細な知識やスキルが必要な場合には「開発担当」へ協力を要請する。
・「コントローラ」は把握した全体状況から、全体統制体制の必要性を判断し、あらかじ
め定められた範囲で、一次措置の実行を「監視・調査・分析・措置担当」へ指示する。
また、顧客サービス影響の報告を「情報統制者」へ指示する。
・対応が難しい場合又は定められた範囲外の重大障害時の場合は「全体統制担当」へエス
カレーションを行う。
・エスカレーション後は、障害のタスク管理及びエラーの状況等の情報収集等を行い「全体統制担当」を支援する。
・障害発生時に得た情報及び知識をまとめ、爾後の障害対応等に活用する。

166

別紙 11
第１

顧客対応に関する再発防止策の実施に際しての留意点

お客様第一の徹底① 再発防止策の実施に当たっての姿勢として、各部署が「お客様第一」の理念を具体的な対応レベルで徹底して考え抜く。
② 顧客影響が発生する障害等のインシデントに対し、全ての役職員がまずは「お客様第一」を考え、実現するという姿勢で臨む環境を作り出す。たとえば、指示がなくても自発的にお客様第一の行動をとった部署（営業店を含む）を顕彰すること及び現場において指示を待たずに顧客対応を行った者に対する積極的な人事評価を取り入れる。
第２

想定外を想定内にする仕組み作り① 今回発動した BCP について検証し、実効性に乏しい部分があれば見直す。
② BCP の見直しに当たっては、使いやすく実効性あるものとする。
③ 障害の原因ごとに細かな想定シナリオを増やすことはむしろ慎重であるべきであり、それよりむしろ、原因が不明であっても顧客影響を最小化する目的から何を行うべきかという視点をもつことに留意する。
第３タイムリーな判断ができる組織作り① 本障害等をサンプル事例として、自らを顧客に置き換えて顧客影響（長時間待たされるといった時間的負担等）を考える訓練を行う。
② 資料作りや会議がいたずらに決断を遅らせることのないような仕組みを作る。
③ 顧客対応部門においてシステム復旧を待たずに顧客影響を最小化する行動をとれるよ
うな手順を確立しておく、また各部署及び営業店の担当者に顧客対応に関する一定の裁量を与えることも検討に値する。

167