2023年10月10〜11日、全銀システムの中継コンピュータ障害で10金融機関のテレ為替業務に支障が出た。国会答弁による影響取引は仕向・被仕向合計566万件で、そのうち約102万件が取引当日中に処理を終えられなかった。
朝8時35分、10の金融機関へ広がった障害
2023年10月10日、三連休明けの火曜日。全銀システムのコアタイムシステムが動き始めた直後、9つの加盟金融機関で異常が生じた。午前8時35分ごろである。午前9時43分ごろ、もう1機関でも中継コンピュータ（RC）が停止した。結果として10金融機関と全銀システムとの間で、個々の振込電文を取り扱う「テレ為替業務」ができなくなった。[Z1, p1]
この出来事を「日本中の銀行振込が2日間、すべて停止した」と紹介するのは正確ではない。支払人が使うアプリや銀行口座自体が一律に停止したわけではなく、特定の中継装置とその機能を利用していた金融機関が影響を受けた事故だった。10月18日の全銀ネット説明資料は、モアタイムシステムへの新機種移行が話題となったJPモルガン・チェース銀行について、コアタイムで影響はなかったと明記している。[Z2, p1][Z3, p4]
中継コンピュータは、加盟金融機関からの送金データを全銀センターに接続する装置だ。いつもの振込が成立する裏側では、各銀行のシステム、RC、全銀センター、相手行のシステムが連動している。送金の仕組みそのものはOtakuwalletのA2A決済解説で扱っている。本稿は、そのインフラが切り替えの瞬間にどう壊れ、何を学んだかの記録である。
何が止まり、何は動いていたのか
全銀ネットの説明によれば、全銀システムは平日日中を扱うコアタイムシステムと、平日夜間・休日を扱うモアタイムシステムの組合せで運用されていた。コアタイムには電文1件ずつを扱うテレ為替と、複数のデータをまとめる新ファイル転送がある。障害中、影響を受けた金融機関とは、新ファイル転送のバックアップ機能や電子媒体を使った代替対応を試みた。[Z3, pp2–3,6]
つまり「銀行の送受金が全面停止」でも「バックアップがあったので影響なし」でもない。通常のルートで送れなかった取引を別の手段へ移すには、当時の仕組みでは銀行側の作業と時間が必要だった。全銀ネットは通信時間を延長したものの、予定したすべての取引をその日のうちに処理することはできなかった。[Z1, p2]
数字をどう読むか。 2023年10月18日の公式説明資料は、10月10日分の仕向（送信）150万件中101万件処理、49万件未処理、10月11日分は105万件中67万件処理、38万件未処理と記載した。いずれも10月11日の通信終了時点の概算であり、受信側の件数とは別集計だった。両日の49万・38万を合計した87万件は「その時点の未処理の概数」であって、恒久的に失われた件数、最終的な被害者人数、全銀行の影響総数ではない。公式資料自体が精査により数値が変動する可能性を付記している。[Z3, p6]
| 対象日 | 送信予定の全体（万件） | 同時点の送信処理済（万件） | 10/11通信終了時の送信未処理（万件） | 受信未処理（万件） |
|---|---|---|---|---|
| 2023-10-10 | 150 | 101 | 49 | 0 |
| 2023-10-11 | 105 | 67 | 38 | 0 |
出典：全銀ネット2023-10-18「システム障害に係る対応状況について」p6。万件単位の概算・暫定スナップショット。受信未処理0は「利用者への入金遅延がゼロ」を意味しない。後続集計との母集団・時点差を確認することが必要であり、この概数を最終値として扱わない。
後続集計では566万件に影響、約102万件は当日中未処理
その後、2023年12月7日の参議院財政金融委員会で、金融庁の伊藤豊政府参考人は、影響を受けた金融機関の取引について、仕向けと被仕向けを合わせて566万件、そのうち約102万件では取引当日中の処理が完了しなかったと答弁した。[Z7, 答弁012。対象は2023年10月10〜11日の障害]
これは10月18日資料の送信側の未処理概数49万件・38万件より後の集計であるが、単純に「87万件が102万件へ訂正された」と同じ母集団の数値改訂とだけ説明するのは適切ではない。566万件には仕向け・被仕向け双方の影響取引が含まれ、約102万件は当日中未完了という時間条件で集計されている。566万件は被害者人数ではなく、102万件は永久に消滅した振込でもない。 また、この国会答弁を以後の改訂が一切ない「最終確定値」とまでは位置付けない。
連休中の更新で、なぜ10機関だけが止まったのか
2017年に導入されたRC17シリーズが保守期限を迎えるため、2023年10月7〜9日に14金融機関で後継のRC23シリーズへの移行を実施した。14のうち10で問題となったのは、RCが「内国為替制度運営費」を電文に付加・確認する処理だった。これを銀行側で事前に入力する方式を採った機関では、同じ事象は発生しなかった。[Z1, p1][Z3, pp4–5]
内国為替制度運営費とは、加盟金融機関間で取り扱う費用であり、利用者がATM画面で見る振込手数料そのものではない。ここを混同すると、障害の技術的な原因も、復旧時の暫定策も誤解してしまう。
障害の直接原因は、RCが参照するインデックステーブルの一部破損だった。では、そのテーブルはなぜ壊れたのか。
RC23開発ではOSのバージョン更新に合わせ、ロードファイルを作る4つのテーブルのうち1つのサイズを大きくした。しかし生成プログラムは4つを一度に作業領域へ展開する設計なのに、開発工程では個別に展開すると理解しており、一時領域を必要な大きさに拡張しなかった。そのためロードファイルの内容が壊れ、起動時に展開されるテーブルが不正となった。[Z1, p3]
OSが単独で決済を止めたのでも、コンピュータの容量が恒常的に足りなかったのでもない。更新による表サイズの変化、作業領域の仕様の誤認、レビューと試験での検出漏れが重なったと理解するのが、共同報告書の説明に近い。
最初の復旧策は間に合わなかった
現場は、原因が分かれば修正してすぐ復旧できるわけではない。
10月10日午後5時ごろ、NTTデータと全銀ネットは、不具合のあるテーブルを参照せず、取引の種別から運営費の額を設定する修正を決めた。しかし改修箇所が多く、夜間の検証でもエラーが続いた。11日午前3時45分ごろ別のエラーを検知し、同日8時30分の通信開始に間に合わせるのは困難と判断して、この案を断念した。[Z1, p2]
11日午後1時ごろ、別案として運営費入力欄へ一律0円を設定する暫定対処を決めた。12日午前3時30分ごろに正常起動を確認した。これは銀行間費用を正しい額で計算する本格対処ではないが、障害のある部分を通さない復旧のための判断だった。[Z1, p2][Z3, p7]
原本が区別しているのは、「装置が正常起動した時刻」と「個々の振込がいつ入金されたか」という2つの事実である。この違いは、カード決済の承認と加盟店入金を分けるのと同様に重要だ。
障害をめぐる時系列
| 日時 | 公式に確認した事象 | 注記 |
|---|---|---|
| 2023-10-07〜09 | RC17からRC23へ14機関が移行 | 障害発生前の更改 |
| 10-10 08:35頃 | 9機関でRCがダウン | テレ為替業務に支障 |
| 10-10 09:43頃 | 追加1機関がダウン | 計10機関 |
| 10-10 17:00頃 | 暫定対処①を決定 | 初回案は検証不具合で中止 |
| 10-11 03:45頃 | 暫定対処①を断念 | 再開見通しと区別 |
| 10-11 13:00頃 | 暫定対処②を決定 | 運営費入力を一律0円とする案 |
| 10-12 03:30頃 | 暫定対処②の正常起動を確認 | 全取引の完了時刻とは異なる |
| 2024-03-04 | 対象機関で不具合修正の本格対処完了を公表 | 一連の再発防止策すべての完了ではない |
2023-12-01全銀ネット・NTTデータ共同報告p1〜2、2024-03-04全銀ネット公表に基づく。
送金が遅れたら、誰が補償するのか
2023年10月18日、全銀ネットの加盟金融機関は顧客補償の考え方を申し合わせた。顧客と直接取引する加盟金融機関が窓口となり、振込不能や着金遅延によって追加で生じた費用など直接的な損害の補償に対応することが望ましい、とした。具体例として、手数料、延滞金・遅延損害金、貸出金利・貸越金利を挙げている。[Z4, p1]
ここで「補償制度がある」と「被害を申告した全員に定額で支払われた」は違う。個別の損害認定、補償支払実績、未補償の理由は、この申し合わせ資料だけでは確認できない。また金融機関間で内部的に誰が費用を分担するかという論点とも区別が必要だ。
2024年の「本格対処完了」と2025年の「改善策進捗」は違う
不具合を修正したプログラムの反映について、全銀ネットは2024年3月4日に、対象金融機関すべてで本格対処を完了したと公表した。これは今回のRC不具合そのものへの本格対処完了を示す。[Z5, p1]
一方で、2025年1月10日公表の再発防止進捗資料には、まだ「予定」「検討中」「継続」とされた項目が残る。例えば、2024年12月末時点の代替運用訓練は8回中7回、140行中111行が実施済みで、情報共有ツールの導入は検討中と記載されている。[Z6, p2]
金融インフラには二重化が必要だ。しかし装置やデータセンターを二重に置くだけでは、同じ設計や手順の誤りが双方へ及ぶ共通原因障害に十分対応できない。実際の共同報告では、東京・大阪の同時障害を想定した訓練不足が課題に挙がった。[Z1, pp4–5]
「止まらない決済」を支えるのは、更新と復旧を設計する力
この障害は、サイバー攻撃で送金データが盗まれた事件ではない。システム更改時のソフトウェア・データ生成の問題が、通常の金融取引と復旧・補償にまで広がった事例だ。2016年のバングラデシュ中央銀行事件における端末悪用とは故障類型が異なる（OtakuwalletのSWIFT事件解説）。
最後に残るのは、誰が障害を予測し、何をテストし、どの時点で別案へ移ると決めるのか、という問いである。新しい機械に取り替えることは技術の更新だ。想定外の失敗を発見し、処理が止まっても利用者を守れるようにすることは、組織と制度の更新だと言える。
FAQ
全国すべての銀行振込が止まったのですか？
いいえ。公式共同報告では、RC23へ更改した14加盟金融機関のうち、特定の機能を使っていた10機関でテレ為替業務ができなくなったと説明しています。全銀行のすべての処理が止まったわけではありません。[Z1]
87万件は、消えてしまった振込件数ですか？
いいえ。これは2023年10月18日付資料で示された、10月11日通信終了時点の送信未処理概算49万件・38万件の合計です。後に金融庁は影響取引566万件（仕向け＋被仕向け）、うち当日中未完了約102万件と答弁しています。両者は公表時点・範囲が異なり、いずれも「消滅した振込」や被害者人数を意味しません。[Z3][Z7]
一次資料一覧（原稿採用範囲）
| ID | 発行・資料名 | 公表日 | 対象期間／採用箇所 | 取得・照合日 | URL |
|---|---|---|---|---|---|
| Z1 | 全銀ネット・NTTデータ「全国銀行データ通信システムの障害について」 | 2023-12-01 | 2023-10-07〜12、pp1–5 | 2026-11-04 JST | 公式資料 |
| Z2 | 全銀ネット「全国銀行データ通信システムの復旧後の対応状況について」 | 2023-10-18 | 2023-10-10〜18、p1（JPモルガン注記） | 2026-11-04 JST | 公式資料 |
| Z3 | 全銀ネット別紙「システム障害に係る対応状況について」 | 2023-10-18 | 2023-10-10〜11、pp2–7、p6の表は概算 | 2026-11-04 JST | 公式資料 |
| Z4 | 全銀ネット「全銀システム障害に伴うお客さまへの補償にかかる申し合わせについて」 | 2023-10-18 | 2023障害の顧客補償、p1 | 2026-11-04 JST | 公式資料 |
| Z5 | 全銀ネット「全国銀行データ通信システムの障害に係る本格対処の完了について」 | 2024-03-04 | 2024-01〜03の修正対応、p1 | 2026-11-04 JST | 公式資料 |
| Z6 | 全銀ネット「改善・再発防止策の進捗状況について」別紙 | 2025-01-10 | 2024-12末時点、p2–3 | 2026-11-04 JST | 公式資料 |
| Z7 | 国立国会図書館『第212回国会 参議院財政金融委員会 第5号』金融庁 伊藤豊政府参考人 答弁012 | 2023-12-07 | 2023-10-10〜11障害の後続集計：仕向＋被仕向け影響566万件、当日中未処理約102万件／答弁012 | 2026-11-13 JST | 公式資料 |
| Z8 | 全銀ネット『プレスリリース』（公開資料索引） | 継続更新・索引に単一公表日なし | 2023障害関連の後続公表を2026-11-13時点で確認。2025-01-10の改善進捗が同索引の直近の専用報告として掲載。全施策完了を証明する資料は未特定 | 2026-11-13 JST | 公式資料 |
