全銀ネットのシステム障害で銀行振り込みができない！原因は何だったのか

こんにちは。COBOLユーザーのきーちゃんです。ここ2日ほど他行への銀行振り込みが出来ないトラブルが世間を騒がせました。これは全銀システムという銀行間決済システムのシステム障害によるものでした。

全銀ネットと全銀システム

一般社団法人 全国銀行資金決済ネットワーク（全銀ネット）が提供している銀行間の資金決済を担うシステムが全国銀行データ通信システム（全銀システム）です。全銀システムは、1973 年（昭和 48 年）４月に稼働を開始して50年（！）もの間、大きなトラブルもなく国内のほぼ全ての金融機関が参加している広範なネットワークとして信頼性の高いシステムを提供してきました。

全銀システムを支えている技術

全銀システムは、取扱量や接続先の増加、セキュリティ対策等への対応を行うため、概ね８年毎にシステム更改を行ってきたシステムです。この安定したシステムを支えてきた動作プラットフォームはオンプレミスで稼働する富士通製のメインフレームで、COBOLプログラムによってシステム構築されています。

COBOLとは

COBOLというプログラミング言語は、1959年に事務処理用に開発されたプログラミング言語です。英語を読んでいるような自然言語に近い構文を持つため、そのソースコードは記述が冗長になりますが、可読性が高いという特徴があります。特に金額計算など事務処理用に広く使われてきた言語であるため金融機関のシステムや中小規模のオフコンで稼働するシステムで多く利用されてきた背景があります。

奇しくも私が新卒で勤めたIT企業で携わった業務も、まさに全銀システムと同じく汎用機（メインフレーム）と呼ばれた大型コンピュータで稼働するCOBOLプログラムで書かれていたシステムでした。かなり昔に取った資格ですが、基本情報処理技術者試験の選択問題でもCOBOLを選択するなど私にも縁のある言語です。（現在の試験では実在の言語ではなく疑似言語による試験問題になっているようです。）

システムの構成やプログラミング言語にもトレンドがある

今回システム障害が起きてしまった全銀システムはメインフレーム上でCOBOLプログラムを稼働させるシステムとなっていますが、このようなシステム構成は1980年代から90年代前半のトレンドを彷彿とさせるほどかなり古いシステム構成です。COBOLというプログラミング言語も現在では情報処理系の学科でも名前を習う程度で恐らく言語自体に触れる事はなく、書籍を探そうにもほとんど見当たらないような古い言語です。

90年代後半にはメインフレームからC/S（クライアント・サーバ）システムに移行する事でシステムをダウンサイジングしていくようなトレンドとなっていましたし、VMwareでシステムを仮想化するといった流れもありました。最近ではAmazonの提供するAWSを活用してシステムをクラウド化するとか、インターネットなどのネットワークを経由してSaaS（Software as a Service）を利用するといった方向に進んでいます。

このため2023年という年にメインフレームやCOBOL等という単語を耳にする事は時代錯誤であると感じざるを得ません。

今回影響が出た銀行は？

今回のシステム障害は、3連休中にシステム更新した14の金融機関のうち11の銀行で障害が起きました。システム更新自体は無事成功し、翌営業日の「2023年10月10日」に正常に稼働・・・するはずだったのですが、システム障害が発生してしまい以下の11銀行で他行への振込が出来ない障害が発生してしまいました。

• 三菱UFJ銀行
• りそな銀行
• 埼玉りそな銀行
• 関西みらい銀行
• 山口銀行
• 北九州銀行
• 三菱UFJ信託銀行
• 日本カストディ銀行
• JPモルガン・チェース銀行
• もみじ銀行
• 商工組合中央金庫

「5・10日」（ごとうび）での障害

今回のシステム障害は10月10日に発生しました。この10日は、「5・10日」（ごとうび）と呼ばれ、ひと月の中で取引が多い日である事が知られています。金融の世界では、投資家が外国為替のトレードを行う際などに、この「ごとうび」の決済タイミングを利用して利益を上げようとするほどです。

今回のシステム障害は、この給与振り込みや決済が集中する「ごとうび」に障害が起きてしまった事でより社会に多大な影響が出てしまいました。

システム更新を行うタイミング

私もIT企業でシステムを見ておりましたので、その当時の経験から思うのですが、全銀システムのシステム担当者もシステム更改の翌営業日が「ごとうび」に当たる事は百も承知で、このタイミングでのシステム更改はしたくなかったはずです。

しかしシステムを更改するタイミングは、システムの利用者が使用していないタイミングで行う必要があります。また万が一システムの更改が正常に完了しなかった場合、システムを前の状態に戻すロールバックを行う必要があります。この時間を確保するために、実施日をゴールデンウィークや年末年始といった連休に更改日を設定する事が通例なのです。

他国と比較して祝日の多い日本でも、システム更改計画に設定できる連休の数はそれほど多くありません。また、今回の全銀システムのように他システムの連携があるシステムでは、システム間連携テストを行ったり基本的な導通確認を行う必要もあるため、おいそれと日程変更を行う事も出来ません。

このため翌営業日が取引の多い「ごとうび」だと分かっていても、次の連休が来るのを待つというのは難しいのです。

システム障害の原因は？

全銀システムが稼働してから50年目で初めての大規模システム障害が起きてしまいました。

それでは今回システム障害が起きてしまった原因は何だったのでしょうか。

現時点では正確な障害発生ルートは特定できていないようですが、今回の障害は中継コンピューター（RC）のシステム更改に伴って発生し、銀行間の取引の手数料である｢内国為替制度運営費｣（旧銀行間手数料）を参照するプログラムで不具合が発生したという事は判明しました。

3連休中にシステム更新した14の金融機関のうち11の銀行で今回の障害が発生したわけですが、障害が発生しなかった残りの3行は自前のシステムで手数料を計算していたため影響がなく、その事も不具合を起こした機能を特定する手がかりになったようです。

根本原因についての調査結果（2023/10/17追記）

日経XTECHによれば、今回起きたシステム障害の原因はメモリー領域が不足した事に起因する不具合だったと以下のように報じています。

全銀システムと各金融機関のシステムをつなぐ中継コンピューター（RC）において、メモリー不足に起因し、金融機関名などを格納したインデックステーブルに不正な値が紛れ込んだ。

 

インデックステーブルはRCのディスク上にあるファイルから展開する。このファイルを作成するプログラムを実行したタイミングで、一時的に確保するメモリー領域が不足し、ファイルの内容が不正確になったという。

出典：日経XTECH https://xtech.nikkei.com/atcl/nxt/news/18/16109/

プログラムを記述した事がある方は理解しやすいと思いますが、プログラムで何か処理をする際には、変数を定義します。「変数を定義する」とは、プログラムが計算を行う際に一時的に使用するメモリー領域を確保するという事を意味します。

具体的には、ハードウェアで構成されている物理的なメモリー領域をここからここまでの範囲で使用しますよという宣言をプログラム上で行うわけですね。ここで確保したメモリー領域がプログラムの処理に必要な範囲より少なかったら、何が起こるでしょうか。

例えば、プログラムで変数を定義して、メモリー上で「１～１０００」までのメモリー領域を確保したとします。しかし実際のプログラムの処理を行うのに必要なメモリー領域が「１～１２００」まで必要だったとしたらどうなるでしょうか。

プログラムを実行すると変数で宣言した範囲外である「１００１～１２００」のメモリー領域にもデータが書き込まれることになります。その領域は本来別のプログラムが処理に使うようになっている領域のはずです。そこにデータが書き込まれたら・・。これが日経XTECHが報じている「不正な値が紛れ込む」という内容です。

このような不具合を内包したままプログラムを実行すれば、プログラマーが想定したメモリーの中身と異なる内容が書き込まれて、その内容を別のプログラムが処理してしまいます。結果として、プログラムが異常終了してしまったり、場合によってはハードウェアそのものが壊れてしまうような事態になります。

今回取ったリカバリー方法

現時点では正確な不具合箇所の特定は出来ていないようですが、社会的な影響の大きさを考慮し、復旧を優先する選択が取られました。

具体的には、不具合の原因と思われる費用のチェック機能をスキップさせるよう｢費用をすべて0円とみなす｣という暫定処理で処理を継続させて、他行への振り込み処理を可能させる簡素化パッチを適用させました。

暫定的なものではありますが、この簡素化パッチを適用することで、全銀システム障害で影響を受けた金融機関でも他行への振り込みができる状態にもっていったわけですね。

ロールバックではなくプログラム修正を選択した理由

システムの世界では、システムの更改により不具合が発生した場合には、システムそのものを前の状態に戻すロールバックを行うというリカバリー方法がよく用いられます。しかし今回の不具合対応では、ロールバックではなくプログラムの修正により障害を乗り切るという方法が取られました。

全銀ネットの発表では「新たな障害が起きるリスクが小さい」という判断でプログラム修正を選択したという事ですが、時間的な問題も影響したのではないでしょうか。この方法を選択した理由は、システム更改した14銀行のうち3銀行は不具合の影響がなかったという事も影響しています。

システムをロールバックさせる場合には、影響がなかった3銀行も含めて銀行側と協議しながらリカバリーを行う必要があります。そうなると調整に非常に時間がかかってしまい社会的な影響が大きいため、問題のプログラム処理部分を回避させる暫定処理を行うようにプログラムを修正することで正常化を図ったのではないかと思われます。

今回のシステム障害の本質はどこにあるのか？

全銀システムは50年という途方もない昔から稼働しているシステムです。このため、メインフレーム上でCOBOLを動かすという時代錯誤なレガシーシステムとなってしまっており、これがシステム障害を起こす問題の本質になっています。

レガシーシステムを使い続けることが問題の本質

今回のような全銀システム障害だけではなく、比較的規模が大きい企業で稼働しているシステムも同様の問題を抱えています。

例えば2023年現在、私が携わった事がある某大企業の製造工場で稼働する製造管理システムでさえ、未だに他システムと連携する事すら出来ないオフコン（オフィスコンピュータ：1960年代から作られた事務処理に特化した小型コンピュータのこと）上でCOBOLプログラムを稼働させて製造管理しているという現実があります。オフコンという特性上、事務処理に必要な数値でさえ電子データで出力出来ずに、目視した数値を紙にメモしてExcelに手入力で転記するといった有り様で、あまりにも時代錯誤すぎて衝撃を受けた事を覚えています。

そのオフコンシステムを管理している某ITベンダーも技術者が代替わりしており、担当技術者でさえ偶然発生した障害対応もなかなか対応出来ず、もたもたしている姿を横目に見ていました。30代ほどの若い技術者だったため、古い技術の技術継承が進んでおらず複雑化したシステムを読み解くことが難しくなっていることを肌で感じた出来事でした。

今現在も、メガバンクや大手メーカーの基幹ITシステムとしてメインフレーム上で稼働を続けているわけです。基幹システムやメーカーの生産管理システムというのは企業の生命線になっている中核システムなんですね。これが使えなくなるという事態は、企業経営に致命的なダメージを与える程の衝撃を与えます。

レガシーシステムを刷新できない理由

メインフレームやオフコンを使い続けてきたツケ

古くから利用されてきたメインフレームでは、メーカー独自方式のハードに独自OS（基本ソフトウエア）、独自業務アプリケーションを積んだシステムです。ハードもソフトウェアも独自のものであるため、一度導入すると他社に乗り換えることが難しいという事情があります。このため古い仕組みの上に古いプログラミング言語で記述されたアプリケーションを継ぎはぎ修正しながら騙し騙し使用してきたわけですね。

古いプログラミング言語は保守できる「人材がいない」という現実

私自身もIT企業で担当した最初のシステムがCOBOLという古い言語を使用したものでした。私が新卒だった頃はもう20年ほど前なのですが、その時点でさえCOBOLは古いプログラミング言語になっており、大型書店でもCOBOLの解説書籍が見当たらないような状態でした。教育機関である大学でも今更COBOLという古い言語を教えるということはないので、短い外部研修で必死に学んだ事を覚えています。

あれから20年近く経っていますが未だに多くの大規模システムでCOBOLを使っているという現実。しかしながら、新規にシステム構築する際の開発言語選択で今更COBOLを選択する事はあり得ません。つまり新たにIT技術者を目指す人が将来的に消えていく未来がない技術を新たに学ぼうというインセンティブは働きません。

しかも情報処理推進機構（IPA）は2019年1月24日に、国家試験「基本情報技術者試験」の出題を見直すと発表しました。それによると2019年秋期以降の試験でCOBOLを廃止し、Pythonを追加するという変更を行っています。つまり国家方針としてもCOBOLを使用しない方針に進んでいるわけです。

そうなるとCOBOLのような古い言語を理解して保守できる実質的なエンジニア層は年齢が50代以上のエンジニアしかいないのが実態で、時間とともに保守できる人材がいなくなっていくわけです。

「保守できる人材がいない」と何が起こるのか

未だに大企業を支える多くの中核システムにCOBOLなどの古い技術が使われている現実があります。これらの古いシステムを維持管理できる人材は残り10年もしたら退職してしまうためシステムの維持ができなくなります。

しかも継ぎはぎにプログラムを修正し続けた結果、システムが非常に複雑化しているためシステム全体を理解できるような人材はさらに限られるでしょう。このため本来はシステムを刷新する事でコアエンジニアから若いエンジニアに技術継承していく事が望ましいわけです。

ITベンダーの立場では、複雑化したシステムの改修を行えば想定外のシステム障害が起こりやすくなるため、このような古いシステムを継ぎはぎ対応する事は嫌がります。ですが、システム利用者である大企業側の立場では、基幹システムのような中核システムの場合、システムを刷新するには莫大なシステム開発費用が必要になるため、新規のリプレースを避けて継ぎはぎ修正する事で先延ばしして凌いできたという事情があります。

しかし、古いプラットフォームを支えるメーカーもサポート限界を迎えている今、企業の屋台骨を支える中核システムをリプレースしなければならない環境的な外圧が高まっています。メインフレームという大型汎用コンピュータはあまりに古いため、製造メーカーのサポート期限が終了してしまっている事も多々あります。

今回問題になった全銀システムが使用しているメインフレームのメーカーである富士通でも、「メインフレームの生産を30年で終了し、サポートも35年で終えることを発表」しており、同社のメインフレームを未だに利用している大企業に大激震が走りました。

これにより今まで運用してきた古いシステムのリプレースがやっと進んでいきますが、あまりに継ぎはぎに保守して複雑化してきたシステムのツケを払うことになり、今後は様々な企業で想定外のシステム障害が頻発してくるようになるでしょう。

2025年問題（2025年の崖）について

最近では「2025年問題」とか「2025年の崖」という言葉がマスコミでも話題になっています。「2025年の崖」とは、経済産業省の「DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～」で提示された言葉です。

現在ある喫緊の課題として、既存システムが抱える課題をDXを推進する事により解決する事が求められています。その課題解決が思うように進まなかった場合、2025年以降には、既存システムが残存するという課題に伴う経済損失が、最大で年間12兆円（現在の約3倍）にまで増加する可能性が指摘されています。これがいわゆる2025年の壁と呼ばれるものです。

多くの企業でレガシーシステムが残されたまま必要なIT技術者も不在となれば、今回のような大規模システム障害が頻発するのは明らかです。危機を放置せず、業務フロー改革も含めた速やかなDX推進が今後日本が発展していくための鍵となるのかもしれません。