みずほATM障害（2021）— 取消情報テーブルの飽和

何が起きたか（日時・影響範囲）

2021年2月28日（日）、みずほ銀行の勘定系システム「MINORI」で定期性預金のデータベース更新が不能になり、エラーが行内全体へ連鎖しました。ピーク時には自行ATMの約8割にあたる最大4318台が停止し、通帳・キャッシュカード計5244件がATMに取り込まれました。日曜で店舗は無人、コールセンターも輻輳し、利用者はカードを奪われたままATMの前で長時間立ち往生します。みずほダイレクトの一部取引も止まり、ほぼ全面復旧は翌3月1日。2002年・2011年に続く3度目の大規模障害で、経緯はシステム障害特別調査委員会の調査報告書（2021年6月15日公表）に詳述されています。

タイムライン

• 8:24 1年以上記帳のない定期預金約45万件を、通帳レスの「みずほe-口座」へ一括切替する処理を開始。同日は定例のデータ更新25万件も走り、定期性預金の更新は計70万件
• 9:50 定期性預金システムの取消情報管理テーブルで、インデックスファイルの使用率が100%に到達。以降、定期性預金の更新取引がすべてエラー
• 9:50〜10:05 運用側の統合運行管理端末に約6400件のエラーメッセージが出力。意味を即座に読み解けず、原因特定が難航
• 10:00頃〜 エラー多発を検知したMINORIが、全面ダウン回避のためATM向け処理区画を順次閉塞。閉塞先に接続したATMでは定期預金と無関係な入出金までエラーになり、通帳・カードの取込みが拡大
• 午後〜翌朝 切替処理を中止して容量を確保し、順次復旧。3月1日までにほぼ正常化

根本原因の技術解説

MINORIは取引がエラーで完結しなかった場合、整合性を戻すための自動取消（補償トランザクション）を実行し、その材料を取消情報管理テーブルに保持します。テーブルはデータ本体とインデックスファイルで構成され、インデックスは当初ディスク常駐の設計でしたが、性能が出ずメモリ常駐へ変更されていました。上限が搭載メモリで固く決まる、大量更新に弱い構造です。

当日は70万件の更新が集中して9時50分にインデックスが飽和。DBMS自体は更新をロールバックしていたのに、アプリケーション層はこれを「更新結果不明」と判定して自動取消を起動しました。その取消も同じテーブルへの書き込みを要するため失敗し、エラーがエラーを生む二重エラーとして急増します。

e-口座切替45万件 + 定例更新25万件（計70万件）
 → 取消情報管理テーブルの INDEX FILE（メモリ常駐）が使用率100%
 → 定期性預金の更新取引が全件エラー
 → アプリ層が「更新結果不明」と判定し自動取消を起動
 → 取消も同じ INDEX FILE に依存して失敗（二重エラー）
 → エラー多発を検知した共通基盤が ATM 向け処理区画を閉塞
 → 無関係な取引までエラー化し、ATM が通帳・カードを取込み

エラー率の急騰を受け、共通基盤は全面ダウンを防ぐ防御機構として処理区画を閉塞し、SOAで疎結合のはずの普通預金の入出金まで縮退に巻き込みました。そしてATMは「取引結果が不明なままカードを返すと不正利用や不整合の恐れがある」という銀行側の論理で、エラー時に通帳・カードを取り込む仕様でした。システムを守る縮退設計が、被害を利用者へ転嫁したのです。

なぜ防げなかったか

横にスクロール

事前の容量確認はテーブル本体の空き容量のみで、インデックスファイルは対象外。使用率の閾値監視も未設定で、容量逼迫を示す警告は見過ごされました。背景には、ディスク常駐からメモリ常駐への設計変更が保守・運用へ引き継がれていなかったこと、MINORI稼働後のIT人材削減で仕様を熟知した要員が現場から減っていたことがあります。障害は単発で終わらず、2021年だけで計9回続発しました。

金融庁は2021年9月22日にシステム更改を実質管理下に置く業務改善命令を、11月26日に再度の業務改善命令を発出し、真因を「システムに係るリスクと専門性の軽視」「IT現場の実態軽視」「顧客影響に対する感度の欠如」、そしてその背後にある「言うべきことを言わない、言われたことだけしかしない姿勢」と指摘しました。FG社長・頭取・グループCIOらは引責辞任しています。

教訓（原則として一般化）

• 上限のあるリソースは全部監視する: 容量はテーブル本体だけでなく、インデックス・ログ・カウンタ・コネクション数などの付随領域にもあります。大量処理の前に「件数に比例して何がどれだけ増えるか」を見積もり、使用率メトリクスと閾値アラートを常設します。インデックスの内部構造はデータベース、監視とSREの原則はDevOpsを参照してください。
• エラー処理の依存を断つ: 補償処理が壊れたリソース自身に依存すると、エラーは再帰的に増幅します。エラーパスは正常パスと別資源で完結させ、試験はエラー時挙動まで含めます。
• フェイルセーフはエンドユーザー視点で: 縮退・閉塞・取込みといった防御動作が誰の被害を最小化するのか、設計段階で明示的に問います。
• システムと組織は両輪: 設計変更の引き継ぎ、悪い情報が上がる文化、保守フェーズの専門人材維持——技術的根本原因の背後には、ほぼ必ず組織的根本原因があります。