鈴木淳也のPay Attention
第196回
全銀システム障害と、同システムが目指す将来像
2023年10月13日 09:04
10月10日から全国銀行資金決済ネットワーク(全銀ネット)が運用する「全国銀行データ通信システム(全銀システム)」で発生していたシステム障害は、12日朝8時半の営業開始時間(コアタイム)をもって解消された。一部、10日と11日に行なわれた“仕向”の取引データに未処理のものが残っていたが、12日午前10時50分をもって全件処理が完了しており、通常状態へと戻っている。
2023年10月12日 09:23
全銀システムは全国の銀行が接続して送金情報などがやり取りされる仕組みであり、今回は「五十日(ごとおび)」と呼ばれる「日付に“5”や“10”が付く、引き落としなど各種処理が一斉に行なわれやすいタイミング」での障害でもあり、期日までの振り込みやカードの利用額引き落としができないなどの問題が多数散見されることとなった。
システム自体は2日間で復旧したものの、今後補償や障害対応などを巡っての議論が重ねられることになると考えられる。本稿では障害の概要に触れつつ、問題誘因の一端となった「全銀システムの刷新と狙い」について少しまとめたい。
障害を起こした全銀システムの仕組みと流れ
全銀システムは1973年に運用を開始した、銀行間での内国為替取引を中継してオンライン処理するための「インターバンク・システム」と呼ばれるものだ。大量の取引データをオンラインでやり取りしてリアルタイム処理できるという点では世界的に見ても大規模な仕組みであり、これまでほぼ8年周期でシステムの刷新が行なわれてきた。
現在は2019年に稼働を開始した第7次システムであり、次の更改タイミングとなる2027年に向けて順次切り替えが行なわれていたタイミングでの障害だった。なお、全銀協などによれば顧客取引に影響が出るレベルでの障害は運用開始以来初の出来事ということで、その点がクローズアップされたのも今回の特徴といえる。
下図は、全銀協が「次期全銀システム」と呼ぶ第8次システムの構成概念だ。全銀システムに参加する金融機関は各々が勘定系の基幹システムを抱えており、「RC」と呼ばれる中継コンピュータ(Relay Computer)を介して全銀システムとネットワーク接続される。今回障害が起きたのはこのRCの部分で、RCに搭載されたソフトウェアの不具合が原因となって発生した。
図表の用語解説をしておくと、「テレ為替」というのは1件1件振り込み指示を行なう都度送金の仕組みで、「新ファイル転送」とはこうした複数の送金指示をまとめてファイル化することで一気に処理を流す仕組み。用途に応じて使い分けられる。
前述のように、今回の障害の発端となったのはRCの部分であり、第7次から第8次システムへの移行過程での機器のリプレイスによって発生している。全銀協ではこのリプレイス作業を「レベルアップ」と呼んでいるが、第7次システムでは「RC17」と呼ばれていたものが、第8次では「RC23」となっており、機能面の拡充や柔軟性の強化、それと同時に使われない機能の簡素化なども行なわれている。
“レベルアップ”作業は年4回の実施が計画されており、第8次への移行過程の第1弾となるRC23へのリプレイスが行なわれたのが10月7日から9日の3連休のタイミングとなる。
金融機関14行でのリプレイス終了後、10日朝の営業時間開始のタイミングで11行の取引が正常に行なわれていないことが判明し、障害発生の報が打たれた……という流れだ(正確にいうと障害が発生していたのは10行だが、詳細は後述)。
筆者はRC17とRC23の違いについていろいろ調べていたが、両者の変更点をまとめて可視化できるほどの情報を得られなかったため、現時点で判明している2つのポイントで両者の違いを見ていく。1つは下図にあるように、RCの配置に特徴がある。2027年から先の第8次システム以降の話題にも絡むため、詳細は後述するが、これまで参加行側に“アプライアンス”装置として提供されていたRCが、RC23では全銀システム側に置かれる形になった。
全銀システムへの接続要件が「IP-VPNの閉域網を介してRCを中継する形で各行の基幹システムを全銀システムへと接続する」となっていたものが、RCそのものは全銀システムに接続するための閉域網(ネットワーク)の向こうに置かれるため、(推測になるが)参加行の運用管理負担の軽減につながるとともに、将来的な“RCの廃止”への布石となっている。
RC17とRC23の違いの2つめは、今回の障害の原因となった「内国為替手数料のチェックプログラム」の存在にある。これまで全銀システムを介して銀行間のやり取りで発生する手数料については電文の種類に応じて「62円」などの一意の金額が割り当てられていたが、RC23のタイミングではこの金額に柔軟性を持たせるべく、異なる計算手法を導入している(“料金テーブル”のようなものを参照すると思われる)。ただ、問題の洗い出しの過程でRC23へのリプレイスが行なわれた14行でも障害の発生した金融機関とそうでない金融機関における違いを精査したところ、当該機能を利用しているか否かの部分が分かれ目だったため、11日の時点でいったん「すべての手数料を0円にする」形でRC23のプログラムを書き換え、オンラインでの処理が流れる形にすることで問題を解消する方法を選んだ。ここで行なわれなかった手数料計算は後ほど集計の形で処理される。
先ほど、「実際に障害が発生したのは11行ではなく10行」と記したが、この部分について用語解説を含めて少しだけ補足したい。対象行の数が減ったのは、当初数としてカウントされていた「JPモルガン・チェース銀行」では影響がなかったことによる。
全銀システムでは第6次システムの稼働期間である2018年のタイミングで「モアタイム」のシステム運用を開始し、これまで平日日中に限られていた送金処理を夜間帯や祝日などの営業日外でも対応するようになり、実質的な24時間365日での取引が可能になった。ただし通常の営業時間帯である「コアタイム」と「モアタイム」ではシステム系統が分かれており、「モアタイム」での処理が可能なのは対応システムの導入を行なった金融機関に限られている。つまり、送金元である「仕向」と送金先である「被仕向」でモアタイム対応の有無により着金に“ラグ”が生じることになる。
JPモルガン・チェース銀行の場合、今回のリプレイス作業においてRC23を導入したのはモアタイム対応のためであり、コアタイムのシステムとしてはRC17のままで運用していたため、現時点ではまだモアタイム未参加の状態になっており「影響はなかった」と改めて確認された。
「切り戻し」をしなかった判断と全銀システムのこれから
今回のシステム障害の原因となったRC23は2系統で多重化されており、片方で障害が発生しても処理を継続できる仕組みになっていた。ただし、これで想定しているケースは主に「ハードウェア障害で片方の装置が“落ちた”場合」であり、システム内のソフトウェアの“バグ”に起因する問題では対処できない。2つある装置で同じプログラムが動作しているため、障害そのものは同時に発生してしまうからだ。全銀ネットの説明によれば事前テストなどでは問題がなかったとしているものの、結果として本番環境での稼働でトラブルを引き起こしてしまった。
障害対応ではいくつかの選択肢がある。1つはシステムを止めた状態で問題に対処する方法、もう1つは“いったん元のシステムに戻した状態”で対策を行なう方法だ。特に全銀システムのように“止められない”システムにおいて、このあたりの判断は重要となる。
今回のケースでは前者を選び、元のシステムにいったん戻す「切り戻し」は選択されなかった。全銀ネットの説明によれば、すでにRC23が問題なく稼働している金融機関もあり、すべてのシステムを同時にRC17に“切り戻す”リスクを負うよりも、障害の発生している部分を特定して対処した方が迅速で安全だと判断したという。
特に障害の発生した10日の時点で「ハードウェアの問題ではなく、内国為替手数料の処理のソフトウェア部分」と事象の切り分けができていたため、このような判断の一助になったと思われる。もっとも、プログラムそのものの修正は10日から11日にかけての「モアタイム」の時間帯でのテスト運用でも上手くいかず、11日のコアタイムはシステム障害を抱えたまま始まってしまい、結果として「0円ですべての計算を行ない、チェックプログラムを無効化する」という手段を選ぶ形になってしまったが、銀行サービスの利用者そのものには悪影響を与える修正ではないため、当面はこのまま運用する形で進むことになる。
幸い、前述のようにレベルアップ機会は年4回あり、次のチャレンジは2024年1月となるためまだ時間がある。次回までにRC23の当該プログラムの修正や見直しを行なう意向を全銀ネット側では示している。
大規模障害が発生したことで改めて注目された全銀システムの存在だが、いまこの巨大な仕組みは岐路に立っている。
1つは、全銀システムの“コア”機能として動作している中心部分が「メインフレーム」で動作しており、当該製品の販売が2030年に終了、そして保守期限が2035年に迫っているという逼迫した問題だ。
もう1つは新しい潮流への対応で、日本国内でキャッシュレス決済が普及する過程で「資金移動業」などの“非銀行”の金融機関が多数登場し、個人間取引の多くを担い始めている点が挙げられる。PayPayなどのコード決済事業者が典型だが、現在は最終的な精算処理は同社の持つ銀行口座を介して“間接的”に行なわれているが、より利便性を向上させるために「全銀システムに直接接続させる」という方法が模索されている。「全銀システムは銀行にしか門戸が開かれておらず閉鎖的だ」という声に対応したものだが、多額の接続料負担や接続のための“API”整備も含めて、現状ではまだ課題が多くある。システムの耐用期限と合わせ、8年ごとにやってくるシステム更改のタイミングでこうした問題を吸収していかなければならないというのが全銀システムの現状だ。
下図は第7次から第8次システムへの移行におけるロードマップだ。RC17とRC23の移行計画にも触れられているが、基本的に第8次システムではRC23の運用が前提となる。そのため、2027年の第8次の稼働開始のタイミングまでにある程度リプレイスを完了させておく必要がある。もう1つ注目なのが「APIGW(APIゲートウェイ)」の存在で、2025年稼働開始となっている。過去の資料を読む限り、第7次システムが稼働する2019年から2020年のタイミングですでに導入議論が進んでいたが、全銀システムの参加行らへのアンケート調査でAPI導入意向が芳しくなく、このままではAPIGWを用意しても利用されない可能性が高く、開始時期を少しずつ後ろ倒しにして現状で「2025年」となっているようだ。
既存の全銀システムに参加している銀行などの金融機関がAPI導入に積極的ではない理由として、新しいシステムに移行する際のセキュリティや対応面でのリスクを挙げているが、いずれは金融機関側のシステムにも耐用年数によるリプレイスの問題がやってくるため、それを見越して全銀システム側も更新をかけていかなければいけないという判断が行なわれている。第8次システムにおける大きなポイントは「メインフレームの排除によるオープン対応」とAPI導入を含む「新領域の追加」だ。
現在のコアシステムはメインフレーム上で動作するCOBOLのプログラムだが、ベンダーによるメインフレームの提供終了のほか、COBOLエンジニアが将来的に減少してシステムのメインテナンスが難しくなることを見越して、オープン系のシステムとJavaなどの言語を採用していく方針だ。ベンダーロックインがないよう留意してベンダーや技術を選定していくとしているが、Javaなどの言語でも少なからずロックイン要素があり、このあたりをどう回避していくのかが気になるポイントでもある。同時に、第8次システムは接続方式のAPI一本化への布石ともなる。
2025年のタイミングで一部機能はRCを介さずにAPIGWを通じて全銀システムへのアクセスが可能になるが、第8次システムが稼働したタイミングで「アジャイル」領域が設けられ、ゲートウェイを介さず直でのAPIアクセスが可能になる。企業のITシステムが基幹系と情報系に分かれているのと同様に、ビジネスの根幹となる部分のシステムが“ガチガチ”に組まれている一方で、より新しい事象に柔軟に対応するための“新領域”では異なるシステムが運用されているケースがある。全銀システムにおける既存のコアタイムなどのシステムが「ミッションクリティカル」だとすれば、必要な機能を必要に応じて柔軟に追加できる仕組みを新たに設け、8年サイクルの更改時期に依存せずにシステムを拡張できる方策として用意したのが「アジャイル」領域となる。
第8次システムにおいて、コアタイムなどの既存のシステムがオープン系を導入しつつも「(サーバを内部で運用管理する)オンプレミス」方式にこだわっているのに対し、アジャイル領域では「クラウド」も選択肢に入っているなど、システム面での柔軟性も考慮されている。将来的にはすべてを含めてAPI方式へと移管していくことを目指しており、RC23への移行は「RCによる接続方式の廃止」の布石となる。
結果として、RCの運用管理コストの削減につながるほか、APIを介して銀行以外の事業者も全銀システムへの参加が容易になり、「全銀システムは閉鎖的」という意見へのアンチテーゼにもなっている。
以上がシステム面からみた障害の概要と、全銀システムが現在目指している将来的な仕組みの解説だ。ただし、12日時点で解消されたのはあくまでオンラインでのリアルタイム処理と、3連休ならびに障害が発生した2日間で積み残した処理の完了であり、遅延によって発生した損害や利用者へのフォローはまだまだこれからの課題として残っている。各種障害で最も重要なのはアフターフォローと考えているが、全銀協というよりも、銀行を含めた各種事業者がこうした事態を想定して、どのように問題をフォローしていくのかに注目していきたい。このあたりの動向は次回以降に改めてまとめていきたい。
