ニュース
全銀ネットとNTTが全銀システム障害詳細を報告、64ビット化で作業領域の不足が発生
両者が再発防止策もそれぞれ発表、顧客へ約800万円の補償金も
2023年12月4日 06:15
10月10日から11日にかけて発生した全国銀行データ通信システム（全銀システム）の障害について、12月1日、全国銀行資金決済ネットワーク（以下、全銀ネット）と株式会社NTTデータが会見を行った。
全銀ネットとNTTデータは、10月13日と10月27日に、金融庁から受領した「資金決済に関する法律第80条第2項」に基づく報告徴求命令に対して、11月30日、同庁に報告書を提出。今回の会見はその内容をもとに、障害の原因や課題認識、対処方法などについて説明した。
会見では、影響のあった金融機関に再度ヒアリングなどを行った結果、障害による顧客影響は566万件（10月18日当初発表では506万件）となり、10月11日通信終了時点での未処理件数は102万件（同87万件）となったことを明らかにしたほか、ほかの金融機関を通じて手数料を支払った顧客などに対する補償金が、約8000件、約800万円に達していることを公表した。なお調整中のものもあるため、件数や金額が変わることになるとのことで、補償金の負担の割合などについては今後検討する。
全銀ネットの辻松雄理事長は、「2日間に渡り、全銀システムが停止し、金融機関のお客さま、金融機関のみなさまに大変なご迷惑、ご心配をおかけした。あらためておわびする」と陳謝した。
責任については、「委託管理という点で、全銀ネットに責任がある。原因特定や再発防止策を進めているところであり、これをもとに責任の取り方を今後検討していく」（全銀ネットの辻理事長）としたほか、「システム上の直接の原因はNTTデータであると認識している。預金者や金融機関に多大なる迷惑をかけた。再発防止にしっかり取り組んでおり、本格対処を進めていくことになる。責任については今後検討をすることになる」（NTTデータの佐々木裕社長）と述べた。
会見では、障害の原因について、あらためて説明した。
障害は、10月10日のコアタイムシステムのサービスが午前8時30分に開始した直後の、8時33分ごろに発生。中継コンピュータ（RC＝リレーコンピュータ）の新機種「RC23」シリーズへの更改を行った14行のうち、10行でRC本体装置がシステムダウンし、テレ為替業務が全面的に不能となる事象が起きた。障害が発生したのは三菱UFJ銀行、りそな銀行、埼玉りそな銀行、関西みらい銀行、山口銀行、北九州銀行、三菱UFJ信託銀行、日本カストディ銀行、もみじ銀行、商工組合中央金庫の10行。
テレ為替業務では、電文1件ごとに、仕向機関が被仕向機関に支払う「内国為替制度運営費」（銀行間手数料）を付加しており、その際に、仕向（送信時）と非仕向（受信時）ごとに、自行対応とRC対応の2つの方法が存在。今回は、そのうちのRC対応で不具合が発生した。
RCが仕向電文および被仕向電文を受信すると、内国為替制度運営費付加・チェック処理プログラムが起動。このアプリケーションには問題はなかったが、共有メモリ（テーブル）に欠損があり、エラーを検知。中継処理アプリケーションが異常終了し、RC本体装置がシステムダウンした。
この障害発生の原因となったのが、環境構築時に使用する生成プログラムの不具合だ。一時的に確保する作業領域が不足し、生成プログラムのテーブル作成処理の不具合が発生。これにより生成したロードファイルの一部が破損したという。内国為替制度運営費のテーブルは、システム起動時にディスクエリアにあるロードファイルから展開したが、テーブルアクセス時に正常な値を取得できずに異常終了した。
「環境構築において、生成プログラムで確保する作業領域が不足し、商用運用時に各種インデックステーブルが境界線を突破し、外にあふれたものにおいて、番地がきちんと表示されずに、破損した値として混在することになった。これによって金融機関名による処理ができず、インデックステーブルにアクセスした際に正常な処理ができず、異常処理した」（全銀ネットの辻理事長）という。
OSバージョン変更に伴い、旧バージョンから互換性がない対象を洗い出して改造を加え、新してOSでも問題なく動作させる「非互換対応」の作業において、ロードファイルから展開されるインデックステーブルのサイズを、一時的に拡張する必要があったものの、生成プログラムでは、作業領域が確保でき、拡張が不要と判断してしまい、結果として、作業領域が不足して破損につながった。
具体的には、「RC23」シリーズのOSが32ビットから64ビットにバージョンアップしたのに伴い、ロードファイルの非互換対応を実施。ロードファイルとして、金融機関名テーブル、正読金融機関名インデックステーブル、略読金融機関名インデックステーブル、金融機関コードインデックステーブルの4つのテーブルのうち、最も大きい金融機関名テーブルのサイズは拡張したが、その他の3つのテーブルでは一時的に拡張が行われなかった。
ロードファイルを生成するプログラムでは、一時的に確保する領域をまとめて4つのテーブルを展開する仕様となっていたのに対して、NTTデータの開発プロセスにおける製造工程時には、各テーブルが個別に拡張展開されるものと理解し、一時的に確保する領域の拡張が行われなかったため、全体の作業領域の不足が発生したことが原因だとした。
また、NTTデータ内の製造有識者による修正内容の再検証においても、当該拡張の必要性を指摘することができなかったことも、作業領域の不足につながったとしている。
辻理事長は、「RCが内国為替制度運営費のテーブルを参照する際にエラーが発生していることは判明したものの、詳細な原因は不明であったため、対応に時間を要した」としながら、障害発生後の対応についても説明した。
復旧対応では10日午後5時ごろ、NTTデータと全銀ネットは、RCが内国為替制度運営のテーブルを参照せずに、固定値にて内国為替制度運営費の金額を入力するプログラム修正を行う暫定対処することを決定。10日午後11時までにプログラム改修を完了する予定であったが、暫定対処を行うにはプログラムの改修箇所が多いことで想定よりも作業が遅延した。
さらに11日午前1時40分ごろには、プログラム改修の検証においてもエラーを検知。11日午前3時45分ごろにも、さらに異なるエラーを検知したことで、全銀ネットでは、11日午前8時30分のコアタイムシステムのオンライン開始までには、プログラム修正が間に合わないと判断。この方法による復旧を断念している。
新たな暫定対処としては、RCが内国為替制度運営費の金額を一律0円と入力し、テーブルを見に行かない仕組みとする暫定的なプログラム改修を実施することを、11日午後1時ごろに決定した。NTTデータと全銀ネットは、コアタイムオンライン終了前から、先行してプログラム修正に着手し、12日午前3時30分ごろに、この暫定対処が問題なく起動していることを確認したという。
一方で代替対応として、全銀ネットでは10日午前11時ごろまでに、直接影響を受けた10行に、新ファイル転送を利用して、ファイルを授受する手法と、電子媒体でファイルを授受する方法による対応を依頼した。だが、これまで入力していなかった内国為替制度運営費を、自らのシステムで入力する必要が生じたこと、大量データによるファイル作成を行った実績がなく、ファイル作成に時間を要したこと、電子媒体の搬送に時間を要したことなどから、一部の金融機関では、仕向電文の発信が遅延。被仕向電文の受信および後続の入金処理も遅れた。
また10日と11日は、コアタイムシステムの通信時間を1時間延長することで、代替対応のための時間確保を試みたが、予定していたすべての取引を処理することはできなかったという。
NTTデータの発生原因分析・課題と再発防止策
全銀ネットとNTTデータでは、それぞれの立場から、障害発生原因の分析と再発防止策について説明した。
NTTデータでは、障害の発生原因として、「設計・製造工程プロセスの課題」、「試験工程プロセスの課題」、「復旧対応プロセスの課題」の3点を挙げ、それぞれの再発防止策について示した。
「設計・製造工程プロセスの課題」では、OSのバージョンアップ非互換対応の影響調査プロセスにおいて、プログラム修正方針を製造関係者のみで判断し、その誤りを抽出できるプロセスになっていなかったとし、プログラム修正方針を、詳細設計者を含めて判断するようにプロセスを変更するという。
「試験工程プロセスの課題」では、特定機能によらない基盤環境の変化が影響し、予期せぬ非互換による異常を検出する観点に課題があったとし、具体的には、変更を加えていないテーブルが正しく作成されていることの直接確認ができていなかったこと、より本番に近い試験バリエーションが確保されていなかったことを指摘。再発防止策として、新たな基盤環境でテーブルの正当性を確認するため、変更対象外のテーブルについても新旧テーブルのコンペアを実施すること、より本番環境に近い効率的な試験実施方法として、商用で流れている実取引相当のデータを用いた疎通試験を実施することを示した。
NTTデータの佐々木裕社長は、「機能の充足性や処理の分岐に関するバリエーションなどの特定機能に関する試験は、網羅的に十分実施していたが、基盤環境の変化に伴う非互換に関する部分では課題があった。一部のカナで始まる金融機関名が設定されるケースにおいて、異常終了する事象が発生した。金融機関名については網羅的に試験を実施していなかった」と反省した。
「復旧対応プロセスの課題」では、暫定対処の検討着手の遅れや対処に時間を要した理由として、復旧に向けた優先順位の考え方について、あらかじめ全銀ネットと合意していなかったこと、暫定対処において、見積もり精度よりも、スピード優先で対処し、限られた時間でのフィージビリティ検証のまま前進したこと、並走タスク（原因分析、暫定対処、代替対応など）の優先順位の考え方や代替案への切り替え時限の取り決めがなく作業を実施したことを課題に挙げた。
再発防止策としては、「復旧させる業務の優先順位」と「バックアッププランへの切替時限」を全銀ネットと合意した上で、障害発生時の復旧ガイドラインを策定すること、策定したガイドラインの有効性評価の訓練、および最大リスクである東阪同時障害を踏まえた訓練シナリオの検討と、ブラインド訓練を実施することを示した。
NTTデータでは、システム総点検タスクフォースを新設。第三者の立場から原因分析結果や再発防止策の内容を検証し、すでに妥当性の評価を完了しているという。さらに再発防止策を実効的なものにするために、基盤更改などに対する品質保証の観点から、OS非互換の計画段階から、非機能観点の知識を持つ基盤人材を参画させること、NTTデータおよびグループ会社が、重要な開発プロセスを分担することで、当該プロセスの実態を把握し、トラブル時の復旧対応におけるフィージビリティの感度を高めることを掲げた。
「開発拠点における基盤人材の不足が今回の障害につながった要因の1つだと認識している」（NTTデータの鈴木社長）と述べた。
なお、これらの再発防止策は、今後の本格対処において実施するとともに、各開発プロジェクトにおいても展開。システム総点検タスクフォースは、NTTデータ関連の重要システムの総点検も実施している。
全銀ネットの発生原因分析・課題と再発防止策
一方、全銀ネットでは、「委託者としてのマネジメント不十分」、「加盟金融機関も含めたBCPの実効性不足」、「大規模障害を想定した全銀ネットにおける危機管理体制の脆弱性」、「システム人材の不足と組織の脆弱性」の4点から、課題認識とそれに向けた再発防止策を説明した。
「委託者としてのマネジメント不十分」という観点では、委託先に対する設計レビュー体制の確認や試験項目の確認などの牽制が不十分であったことや、移行計画の妥当性判断、暫定対処の判断およびタイムマネジメントなど、委託者として実施すべき管理が十分ではなかったとし、2024年3月末までに、ベンダーにおける設計のレビュー体制と試験内容の十分性の確認、東阪同時障害発生などのリスクや加盟金融機関への影響を踏まえた適切な移行方法や時期の検討、プロジェクトリスクの洗い出し方法のマニュアル化を実施。さらに、障害復旧対応における優先順位の整理、復旧策決定にあたっての複数プランの比較検討、適切なタイムマネジメントの実施についてのマニュアル化を進める。
2つめの「加盟金融機関も含めたBCPの実効性不足」では、プロジェクト固有のBCPが未整備であったこと、BCPの発動基準や代替手段を使う際の詳細ルールが未整備であったこと、実践的訓練が不足しており、プランの有効性の把握、検証がされていないため、実効的なBCPを確立していなかったことを挙げ、2024年3月末までに、移行計画において必要なコンティンジェンシープランの策定、移行時における必要十分な人員体制の整備、センター代行発信依頼や受信代行にかかる留意事項の取りまとめ、障害発生時の初動および全銀ネット、ベンダー、加盟金融機関の三者間連携の整理、BCP対応の所要時間の確認および時限などの明確化と訓練を実施することを示した。また、2024年度中に、センター代行発信および受信代行運用訓練のシナリオの見直し、欠送および二重発信確認対応の訓練を新たに実施する。
3つめの「大規模障害を想定した全銀ネットにおける危機管理体制の脆弱性」では、「過去に実績のない両系同時障害を想定した訓練が実施できていなかった」（辻理事長）とし、障害発生時における対外告知などに関する各種マニュアルの整備が不十分であったこと、大規模障害時の役割分担などが明確化されていなかったこと、平時からの実践的な訓練が不足しており、障害対応力が十分ではなかったことと指摘。2024年3月末までに、大規模障害発生時における原因調査、復旧対応にかかる情報連携や優先度の整理、事業継続対策本部の役割の明確化、加盟金融機関とその顧客を意識した対外公表内容の事前整理とマニュアル化を進める。
このほか、大規模障害時の全銀ネットにおける対応体制および役割分担の明確化と、障害の影響を受けた金融機関との情報連携方法の整理およびマニュアル化を行う。また2024年度上期中には、内部研修へのシステム障害対応の追加、東阪両系障害対応にかかる内部訓練の新設および実践的な訓練を実施する。
4つめの「システム人材の不足と組織の脆弱性」では、専門性や経験値が十分に蓄積されておらず、今回発生した課題を担うことができるシステム人材が不足していたこと、システム開発および運用に関する検討部会や委員会などの役割も不明確で、金融機関の知見も十分に活用されていなかったとし、2024年4月以降に、全銀協などとの人事ローテーションを通じた人材の強化および加盟金融機関からの出向受入や外部採用などにより、システム人材を確保。2024年4月には、新たにCIOを設置し、事務局体制を強化するとともに、IT・システム関連の所管の明確化、第三者評価におけるプロジェクトや全銀ネットの特性を踏まえた実効性あるチェックを重視することに取り組むという。
また全銀ネットでは、全銀ネット有識者会議から、ガバナンス、システム、顧客目線の観点において3人の外部有識者が、再発防止策等検証有識者会議に参加。専務・常務によるRC障害対応タスクフォース、次課長クラスのRC障害対応ワーキンググループを設置したことも報告した。
システム改修の対応方針
さらに、システム改修などの対応方針についても説明した。
「障害の影響を受けた金融機関のRC23シリーズ本格対処」として、NTTデータでは、影響した10行に対して、RCで動作している領域確保を実行するすべての処理に、同様の不具合が混入していないことを確認済みであることに加え、障害の影響を受けた金融機関などから商用データを借用し、内部試験を実施していることを説明した。また、試験結果に問題ないことを確認したのちに、改修プログラムを2023年12月以降に順次リリースする予定であり、東阪別日程での分散リリースについても、リスク確認を含めて検討するという。
また、「今後のRC23シリーズの移行対応」では、2024年1月に移行を予定していた3つの金融機関のうち、1つの金融機関が移行を延期したことを公表。2金融機関は暫定対処版で移行する方向で調整中しており、そのうち1つの金融機関は自行対応で内国為替制度運営費を付加する仕組みを採用するとした。
「移行を延期した1つの金融機関は、RCの保守期限が残っており、暫定対処でなく、本格対処の段階で移行したいという理由から、延期の申し入れがあった。今後の移行を予定している金融機関からも問い合わせがある。お客さまに影響を与える障害を発生したことに対する不安を取り除くことが大切であり、今回発表した再発防止策などをしっかりと説明し、相談に対応をしていきたい。個別の移行スケジュールに変更はあっても、全体の移行スケジュールは大きく変化はないと考えている」（全銀ネット 事務局長兼業務部長の小林健一氏）と述べた。
さらに、「APIゲートウェイ開発・次期全銀システム開発プロジェクト」においては、今回の障害の再発防止策を踏まえて、プロジェクト管理および各種検討を行い、APIの活用やオープン化の実施を念頭に置いたプロジェクト管理や試験の十分性確保、大規模障害のリスクを考慮した移行方法の検討を行うとともに、プロジェクト推進体制の強化を図るとした。今回の障害により、次期全銀システム開発プロジェクトは停止しており、「これによってプロジェクトが遅延するのかどうかの判断はつかない」（全銀ネットの辻理事長）としている。
全銀システムは、1973年の稼働以来、運用時間中にオンライン取引を停止したことがない安全性、信頼性を誇り、世界各国の関係者の間からは、「ZENGIN」の名称で、安全性を象徴する大規模システムとして高い評価を持っていた。
その全銀システムの2日間に渡る停止は、世界中に大きな衝撃を与えた。
そうした意味からも、安全性の象徴であった全銀システムが打ち出した今回の各種再発防止策が、大規模システムの安定稼働と安全性を維持するための新たなひな型になることを期待したい。それを証明するのは、全銀ネットの辻理事長、NTTデータの佐々木社長が異口同音に語るように再発防止策の実効性となる。全銀システムが、再び信頼性を持った大規模システムとして評価されるための新たな挑戦が始まったともいえる。