金融業務
Videos
動画コンテンツ
2023/12/1 全銀ネット会見②【主な質疑応答】 全銀システム障害の再発防止に関する共同記者会見
配布資料（全国銀行データ通信システムの障害について）
※全国銀行資金決済ネットワークHPに遷移します
※会見時使用の報道機関向け説明資料とは異なります
（出席者）
辻松雄理事長（中央）／小林健一事務局長兼業務部長（左から２人目）／千葉勇一企画部長（左）／佐々木裕NTTデータ代表取締役社長（右から２人目）／鈴木正範NTTデータ取締役副社長執行役員（右）
Q.製造工程で勘違いをしていたということか。また、原因は初歩的なものだったのか。
佐々木社長／NTTデータ まず、今回の不具合は左側の下にございます生成プログラムというプログラムで混入をしております。いわゆる商用運用における右側の上に黄色いアプリケーションと書いてありますが、このアプリケーションには不具合は混入はしてなかったというところでございます。生成プログラムというところで先ほど申し上げました通り領域を確保した上で、このロードファイルというのを作成し、共有メンバーに展開していくわけですが、その時のプログラム上で領域確保するプログラムにおいてその確保量を誤ったというのが、実際の問題不具合でございます。
それによりまして右側に境界と書いてあるところの下に、エ銀行・カ銀行のところにいわゆる数字でない番地が入っておりますが、領域を確保した境界以外のところは他のアプリケーションがそのメモリを使いに行くことによって一部破損する可能性が出てまいります。実際今回のケースにおきましては、特定の一部のカナで始まる金融機関のインデックスが壊れていたということで、エ銀行・カ銀行はアルファベットで書いてあるアドレスを処理の時に見に行きますので、そうしますといわゆるアプリケーションが見てはいけない領域だということで、システムが異常終了したというのが実態でございます。
これがなぜ発生したのか、それは初歩的だったのかというご質問だと思いますが、実際これがですね詳細設計書から、いわゆる設計書が段々詳細化していくわけなんですけども、その後に製造工程と言われておりますけども、プログラムを作る工程に移ってまいります。プログラムを作る時に今回この領域をですね、拡張すべきかどうかという判断をプログラムの担当者がすべきところなんですが、今回の金融機関名テーブルがこの境界の中に収まっていることで判断を誤ったというのが実際の現場で起きたことでございます。
製造の有識者とのレビューの中で本来見つけるべきところであったんですが、そのレビューにおいても、インデックステーブルも含めたこの四つがまとめて展開されているということについて、十分に認識されないままにレビューも行われたことによって、この境界の中にこの黄色いテーブルが収まってることで、レビューでもこの誤りが見つからなかったというのが実態でございます。
より基盤に詳しいメンバーが詳細設計も含めて再度レビューをすることによって、場合によっては十分混入工程の中で見つけることができたんではないかというふうに考えております。初歩的かどうかという意味ではですね、決して初歩的というレベルではないとは思います。ただ、組織的にはしっかりとこういった点については混入工程で押さえるべきことであったのではないかというふうに認識をしております。
辻理事長／全銀ネット 今の説明に関して開発から運用までのプロセスっていうのをちょっと映してしていただきますと、佐々木社長からお話がありました、開発のところの要件定義それから基本設計、その後の詳細設計とありますけれども、こちらの詳細設計書にはですね、先ほどお話がありました四つをまとめて作業領域のところに入るか入らないかをチェックしなければいけないというふうに書かれておったわけですけども、残念ながらソースコードを見て判断されて、ソースコードを見た段階では詳細設計書を正しいというふうに思われたわけですから、本当はさらにその先の詳細設計書も見れば、もしかしたらこの事象については防げる可能性はあったということでございます。
Q.共同会見を開催した理由は。
辻理事長 まさに障害発生時からですね、NTTデータさんとは車の両輪ではないですけども、原因究明それから今回お話をさせていただいおります再発防止策についてかなり打ち合わせの回数も増やさせていただきまして、原因究明と再発防止策を取りまとめさせていただいました。その方向性につきましてはいずれも一致しておるもんですから、今回私どもとNTTデータさんとで共同で説明書を作成させていただいきこの場で共同で記者会見をさせていただいているということでございます。
佐々木社長 システムで何が起きたという話、あるいは移行の問題、運用の問題、その全容を共同記者会見という形でご説明をすることでですね、しっかりと全容をご理解いただけるのではないかということを考えたところでございます。そうした意味で再発防止も含めましてご理解をいただきまして、皆様方に今後安心していただけるようご説明をさせていただきたいと思います。
Q.生成プログラムをロードするテーブルは、なぜ四つまとめて展開する仕様となっていたのか。
鈴木副社長／NTTデータ その点私の方からご説明させていただきます。まず、金融機関名テーブルとインデックステーブルについてご説明させていただければと思うんですけれども、この金融機関名テーブルに関しましては今、全銀システムをご利用の金融機関は1132金融機関あるんですけれども、最大それだけのエントリー数になってきますと。それで先ほどからご説明させていただいておりますようにいわゆる手数料のチェックに使うんですけれども、いわゆる電文上入ってきた金融機関名をキーにして、どの金融機関名の手数料がどうなってるかっていうのをチェックするような仕掛けになります。ですので1000以上ある金融機関のテーブルですので非常に効率よく検索しなくちゃいけないっていうことで、それを補足するためにこのインデックステーブルというのを使っております。先ほど佐々木の方から説明ありました通りに、いわゆる金融機関名がカナ文字で入ってきた時の最初の、例えばアとイで入ってくればそれぞれが1000いくつの何番目のエントリーから始まるのかっていうのを指し示すということで、テーブルの検索効率を上げるということで、言ってみますとこの金融機関名テーブルは全体のテーブルの本体で、インデックステーブルはインデックス部っていうか補足みたいな形で、一つのテーブルとして扱う思想でやらせていただいてるっていうのが、バックボーンです。ですのでこの生成プログラムの中でも、このいわゆる金融機関名テーブルを作りながらその作ったエントリーのどこに何があるかを見ながらこのインデックスの内容を埋めていくっていうことで、生成自身も一体でやらなくちゃいけないということで、作業領域もこの四つを一つにして扱って作っていかなくちゃいけないと。そういうような考え方になっております。
Q.設計書に記載はあったが、設計段階では見逃したということか。
鈴木副社長 設計書に書いてあったんですけど、製造の段階では金融機関名テーブルっていう本体のところのサイズだけを見てしまったんで、残念だったんですけれども作業領域の不足に至ってしまったっていうようなことになります。
Q.単体テストはやらなかったのか。
鈴木副社長 単体テストはやっておりました。一見、単体レベルではテーブルとしては出来上がってしまうんですね。プログラム的には作って、ここの不足した作業領域にも正規で正しく作って書き込みます。ただ書き込んだんですけども、分かりやすく言えばこの作業領域の不足って言っている上の実線と下の点線の間は、このプログラムが使える領域では正式にはないですから、実は他のプログラムが使ってる領域になりますが、この他のプログラムが上書きしてしまったというようなことになります。
単体テストとしましては、あくまでも一つのプログラムのテスト環境でやりますから、そこではうまくできたっていうふうになりますけど、いわゆる結合試験環境、総合試験環境など他のプログラム処理が多重で動いてる時になって初めてここの破損っていう状況が出てしまいます。ただ、そこのところでやはりここのインデックステーブルも例えば総合試験の環境の中でいわゆるコンペア、新旧のいわゆるRC17と23の突合の検証をすればよかったんですけどもそれができてなかったんで、ここのところが検出できなかったというようなことになります。
Q.責任についてはどう考えているか。処分は検討しているのか。
辻理事長 現在ですね、まさにこの時点におきまして、何が原因なのかということ、それから再発防止策をですね、こういったアクシデントが起きないように再発防止策を取りまとめたところでございまして、責任につきましてはこれを基にですね、今後検討していくということでございます。
佐々木社長 まずシステム上の直接の原因につきましては、NTTデータ、当社の責任という認識をしておりまして、この度預金者の皆様ならびに接続されてる金融機関の皆様に、多大なるご迷惑をおかけしましたことを改めましてお詫びを申し上げたいと思います。現在まず再発防止をしっかりと取り組んでいくということと、本格対処を行っていくということを進めておりますので、今後具体的な責任、処分については整理をしていくことになるというふうに考えております。
辻理事長 当然のことながら、佐々木社長からお話ありましたけど、プログラムのところに残念ながら不具合があったということでございます。このプログラムにつきましてはNTTデータさんや委託先会社さんがお作りなってるわけでございますけども、その委託先への管理という意味ではですね、私どもの責任はございますので、私どもにも責任があるということでございます。
Q.暫定対処からの復旧の目安は。
辻理事長 まず10行さんにつきましては領域を確保するプログラムというものは既にできておりまして、申入展開も終わっているところでございます。先ほどもご説明をちょっとさせていただいたところはございますけれども、プログラム改修が終わりまして、それから先ほど実際の商用データがやはりあった方がいいというお話もございました。そこでこちらの直接の影響を受けた10の金融機関さんの方とは実際の商用データを使って、今現在テストをしている最中でございます。多分来週のですね、前半には終わる予定でございまして、そのテストがうまくいけば、12月以降順次リリースをしていこうという予定でございます。ただし、それは相手銀行さんのスケジュールもございますし、それから万が一ですね、失敗した際にはですね、代替処理ですね。それをきちんとできるという状態を確認してから実際には技術に入っていくという形になります。
Q.10行については年内改修が可能ということか。
小林事務局長／全銀ネット 今ですね辻の方から12月以降という説明をさせていただいたんですが、これから始めてるということになりますので、最速で12月というふうな感じでご理解をいただければと思っております。1月以降に対応という可能性もございます。そこはこれから各金融機関と調整をしてまいりたいと思っています。現段階で確定したスケジュールはございません。
Q.次期全銀システムの開発プロジェクトへの影響は。
辻理事長 まだ後ろずれ込むかどうかわか分からないですけれども、例えば次期全銀システムの開発プロジェクトについて言えば開発プロジェクトを一旦今停止している状況でございます。ですので今後の状況にもよりますけれども、それが遅くなるのかそうではないのかっていうのは現時点ではまだ判断がつきません。
Q.補償について、現状分かっている件数や金額は。
辻理事長 補償の金額・件数ですけれども、11月17日時点でございます。ですのでまだ補償件数・金額は変わる可能性はございますけれども、11月17日時点では約8000件、約800万円でございます。ただ、これにつきましては、今申し上げたという速報値でございます。それから、まだ現在調整中といったようなものもございますので、今後この数字は増える可能性はあるとは思います。現時点では約8000件・約800万円でございます。
Q.設計・製造工程における製造関係者と詳細設計関係者とは。
鈴木副社長 まずあの製造関係者というところに関しましては、実際にそのプログラムをコーディング・製造するいわゆるプログラマーという人間と、あと今ご質問の際にお使いになったシステムエンジニアのようないわゆる製造の修正方針ですとかそういったところを見るような人間も入ってます。私達、そういった、あの経験者、そこら辺のいわゆる僕らプログラム修正方針を決めて、こういうふうにプログラミングしますよっていう時にレビューっていうそこの再点検をするわけですけど、それの相手になる人間を製造有識者のシステムエンジニアなるものがチェックすると。そういった相互間でのチェックっていうところまでは今回やったんですが、そのメンバーでは今回のここのプログラムの修正方針の不具合を見つけきれなかったというところになります。
一方この詳細設計関係者というのは実際にその詳細設計を執筆している人間。主にはプログラマーというよりも、今の言葉を借りればばシステムエンジニアになるわけですけれども、そういった人間。またその詳細設計書の経験年数が高い、言ってみればベテランですけど私達は有識者と言っておりますけれども、そういった有識者がおります。やはり今回のこの見直しっていうところに関しましては、その設計書、詳細設計書を書いたメンバーもしくはその詳細設計の有識者がこのプログラム修正方針のところにも参画していればこの四つのテーブルは一体として扱っているから詳細設計もそういうふうに書かれているんだから、サイズもその分を確保しなくちゃいけないように修正しなくちゃいけないということを摘出できただろうということで、やはりそういった詳細設計者がしっかりそういったプロセスに参画するっていうことをしなくちゃいけないと、そういうような考え方になっております。
Q.全銀ネットでCIOの設置は初めてか。
辻理事長 CIOにつきましては、全銀ネットの規定の中で明示的に定めていたということはございません。それとCIOでございますけどもチーフ・インフォメーション・オフィサーということで、ここに記載させていただいておりますけれども、理事会とその下の委員会に出席するということでございますので、理事会について申し上げますと頭取・社長級ということでございますので、役員クラスでですね、システムに詳しい方、特にそのリスク管理も含めてシステムに詳しい方にご就任いただこうというふうに考えております。
小林事務局長 補足をさせていただきますと、まさに一般にイメージされておりますですね、ITシステム領域の専門家というようなイメージで捉えていただければと思います。私どもこれまで設置してなかったということで、今後ですね、私どもの全銀システムの安定稼働、高度化へ寄与いただくためにですね、専門知識を活用して各会議体で検討に参画をしていただくということをイメージしております。
Q.候補者は外部・内部からなのか、何人体制を考えているか。
辻理事長 候補者につきましてはまだ現在候補者選定中でございます。内部の可能性もありますし、対応の可能性もあるという段階でございます。CIOにつきましては、現時点では1名を予定しております。
Q.顧客対応上の課題についての認識は。
小林事務局長 私どもはこれまでですね、50年間安定稼働していたということで、一番反省すべきはですね、やはり50年間の安定稼働に依拠をしてですね、満足な備えができていなかったことが反省点だというふうに思っております。それに起因してですね、今回例えばということですが、お客様への情報開示、これがやはり本来あるべきポイントよりもやはり遅かった、それから情報の更新頻度も十分ではなかったというふうな反省点もございます。加えまして、今回障害が発生して元々そのBCP手段としてもですね、代替対応。これは先ほどの説明にもございましたけれども、備えてはおったんですが実際今回ですね、起きてしまったところ私どもの方から加盟銀行さんの方にですね、ご案内するタイミングというのも、適切では必ずしもなかった。
それから各行の方でもですね、今回も非常に五十日（ごとうび）ということでかなりデータ量が多かったんですが、そういった取引が多いところでもですね、実践的な訓練もできていなかった。これによって先ほど件数・金額ということで、お伝えしておるところでございますけども当日未処理となったですねものが発生してしまいまして、お客様にご迷惑をおかけする結果となったということでありまして、その点についてはですね、私どもの方からご説明をさせていただいた再発防止策のところ。特に2番目のBCPの実効性不足、この辺りを反省をしてですね、ルールの整備等を強化をして、実際障害が起きた時に、できる限り早期の復旧ができるような形、障害が起こるものというふうに考えを改めてですね、しっかりとそれに向けた対策をして日頃から備えることでレジリエンスを高めていくという形でお客様への影響を最小限にするよう努めてまいりたいと考えております。
Q.2023年から29年に24回に分けてRCのシステム更新の作業を進める計画に変更はないか。
小林事務局長 保守期限というのはやはりございますので、基本的に各行さんとも6年使い切るという前提でスケジュールを組んでいただいております。けれども、今回の件を受けて例えば東阪（東京・大阪）別に分けてやるということをできる金額ができない金融機関っていうのは恐らく出てくると思いますけれども、仮にできる金融機関については東阪別にやろうとした時には6年が経つ前のどこかのタイミングで先に東京系か大阪系を移行する。その後問題なく移行できたことを見極めた上で最終的に両方を移行するというような形で対応するということも検討しております。今後ですね、全体のスケジュールというのは大きくは変わらないとは思ってんですが、今申し上げたような形で工夫をすることでですね、スケジュール的なところを個別に見た場合にですね、変わってくるようなケースというのもあるという風に思っております。
辻理事長 小林からご説明した通り、全体のスケジュールはなるべく変わらないということでございますけども、実際に来年の10月にRC23が五十日（ごとうび）にあたっておりまして、これにつきましては日にちを前倒しできないかというようなことは検討しております。
Q.日本の金融インフラを支える上で今後はどのように対処していきたいか。
辻理事長 まさに2日間、10月10日と11日にですね、仕向け・被仕向け銀行さんのいずれにもご迷惑をおかけし、かつ当然のことながら顧客の皆さんにも大きなご迷惑をおかけしたということでございますので、それにつきましては責任を感じているところでございます。今後につきましては、先ほどからご説明させていただいておりますけども、今暫定対象という状況になっておりますので、暫定対象を本格対象に変えるべく努力をしていくということでございます。その際の条件は、あくまでもその本格対象であっても失敗する可能性はあるということを前提に、意識のパラダイムシフトなんですけども、そういう考え方を持ってですね、代替処理も含めて、さらに代替処理につきましてもすでに検討しておりますけれども、実は東阪分離ができない銀行さんというものもございますし、そういったものも既に課題として出てきておりますので、そういうものも考えながら代替策を考えていきたいと。そういう形を通じて皆さんがたにご迷惑をかけないようにしようという意欲であります。
Q.再発防止のためのタスクフォースとワーキンググループの詳細について。
小林事務局長 このタスクフォース、有識者会議のいずれも今回の障害を受けまして再発防止策を取りまとめるにあたってですね、私ども全銀ネット内部だけではなく、やはり横串を刺して対応に漏れがないかどうか、それからガバナンスも含めて問題がないかどうかこのあたりを検証する必要があるということで、そのタスクフォースにつきまして、RC障害対応タスクフォース、それからワークンググループについてはですね、主にその企画部門の方々が行ってプラスアルファ今回の障害を受けてですね、専門的なシステム的なところの知見も必要になりますので、各行のですねCIOような方にもご参加をいただいて、企画としてガバナンス的な目線、それからシステムの専門家としての目線、この両方をそれぞれの各行さんの方からメンバーとなっていただいて、今回の私どもの再発防止策が本当に実効性があるかどうか、抜けや漏れがないのかどうかというところを見ていただいております。メンバーの数としてはですね、15名程度ということで、ご認識いただければと思います。
Q.今回の共同会見の発案者や、開催意義は。
佐々木社長 今回の会見の主催はですね基本的には全銀ネットさんが主催をしておりまして、今回はサポートする形で同席をさせていただいてるっていうような位置づけというふうに認識をしております。一つのトリガーとしてましては、11月30日に金融庁様にご報告をさせていただいたというのが私どもも報告徴求命令を受けて同じようにご報告をさせていただいただタイミングということもございまして、このタイミングでこの報告書のサマリーをしっかりと皆様方に公表するのがふさわしいだろうということと、その両者からご報告をしてますのでこのタイミングにおいては両者揃ってご説明するのがふさわしいんではないかというふうに考えたところでございます。
今回はですねやはり社会的な影響の大きさというのが非常に私どもとしても一番重く受け止めておりまして、その発生の起因がシステムにおける直接的な不具合だということがその背景にあるというふうに考えております。決算発表においての会見につきましても、今回こういった場でご同席をさせていただいてる件につきましても、特に大きなですね障害というのは認識はしていないというございますので、社会的な影響が大きな事案につきましてはしかるべき形で対外的にも説明する機会が必要なんではないかというふうに考えております。
やはり正しい情報をですね、正しくお伝えしていくっていうことが何より大切なのかなというふうに考えておりますので、今回10月10日、11日に何が起きたのか、あるいはそこに対して反省点があったのか、なかったのかということについてしっかりと当事者であるシステム開発を受託をしているNTTデータとしての認識についてもですね、ご説明するということが非常に重要だというふうに考えております。
どうしてもこういった事案につきましてはですね、いろんな風評といいますか推測といいますか、いろんな形での情報が出回るケースも多くございますので、そこに対して事実をしっかりとお伝えをする。あるいはそういったことがですね、その他のシステムベンダーにとっても新たな知見になるというようなことになればいいのかなというふうに考えているところございます。具体的な手応えというのは特にございませんが、そういったことを意図してですね、私どももご説明をさせていただいているというふうにご理解いただければと思います。
Q.最後の挨拶
辻理事長 私の方から一言、最後にご挨拶をさせていただいます。今回の反省を踏まえまして、本日ご説明をさせていただきました再発防止策はですね、その障害の未然防止策は当然のこと、障害発生時のですね、早期の復旧や影響範囲の最小化をですね、その実現に向けて策定したものでございます。再発防止策を速やかに今後ですね、実行に移しまして、これを組織内に根づかせまして、常にその実効性の高い状態を維持・保持することが重要であると認識しております。今後も環境や状況に応じまして、見直しも行ってまいる次第でございます。
それから我が国のその内国為替取引制度ですね、根幹を担います私ども全銀システムでございますけれども、加盟金融機関やお客様から信頼される決済インフラシステムとなるように尽力していきたいと思っております。全銀協とそれからNTTデータさん、一体となって引き続き取り組んでまいりたいというふうに思っております。本日は誠にありがとうございました。
金融業務
2023/12/1 全銀ネット会見①【冒頭発言】 全銀システム障害の再発防止に関する共同記者会見
配布資料（全国銀行データ通信システムの障害について）
※全国銀行資金決済ネットワークHPに遷移します
※会見時使用の報道機関向け説明資料とは異なります
（出席者）
辻松雄理事長（中央）／小林健一事務局長兼業務部長（左から２人目）／千葉勇一企画部長（左）／佐々木裕NTTデータ代表取締役社長（右から２人目）／鈴木正範NTTデータ取締役副社長執行役員（右）
事務局より説明
登壇者、ご紹介申し上げます。中央におりますのが全銀ネット理事長の辻松雄でございます。皆様から見て左側におりますのが、事務局長兼業務部長の小林健一とその隣企画部長の千葉勇一でございます。
また、本日は株式会社NTTデータ様にもご同席いただいております。辻の右側にいらっしゃいますのが、代表取締役社長の佐々木裕様。その隣に取締役副社長執行役員の鈴木正範様でございます。
続きまして会見の進行ですが、当法人からご説明させていただいた後、NTTデータ様から補足いただいた上で、質疑応答とさせていただきます。それでは辻理事長よろしくお願いいたします。
※質疑応答は別動画になります。
１．障害の概要と発生要因について
辻理事長
はい、資料説明の前に一言、既にご案内の通り、金融庁から資金決済法に基づく報告徴求命令を受領しておりまして昨日、本件に関する原因分析、課題認識、改善再発防止策等を取りまとめました報告書を金融庁に提出しておりますので、この場をお借りしましてご報告いたします。
それではお手元の資料A4のスライドの資料を使ってご説明をさせていただきます。まず資料3ページになります。前回の説明と重複する所がございますけれども、今回初参加の方もいらっしゃいますので簡単に説明させていただきます。10月10日火曜日に私どもコアタイムシステム、これは8時半からサービスを開始しているものでございますけども、そのサービス後にですね、開始後に中継コンピューターRC、リレーコンピューターと申し上げてますけども、その新機種、これはRC17からRC23でございます。
更改を行いました14行のうち10行でRC本体の装置がシステムダウンいたしまして、テレ為替業務が全面的に不能となったという事象が生じたわけでございます。今申し上げました10行は記載の三菱UFJ銀行さんから始まりまして、商工組合中央金庫様でございます。発生の起因でございますけれども、テレ為替業務では電文の1件ごとに仕向け銀行が被仕向け銀行に支払う内国為替制度運営費、皆さん銀行間手数料の方が馴染みがございますかもしれませんけども、これにつきまして付与をしているところでございます。
その付与の方法その下に表がございますけれども、二つ方法がございまして、自己システムによって付与するケースと、私どものRCによって付与するケースがあるということでございまして、今回不具合が発生いたしましたのは、RCで対応している、RCのまさにコンピュータということでございます。ここにですね、下のところに図を掲載させていただいておりますけれども、この10行、左側に影響行がございまして、真ん中に私どものRCがございますけれども、こちらに書かせていただいております内国為替制度運営費付加チェック処理というこちらのアプリケーションには問題はなかったんですけども、下にございますこの共有メモリー、ケーブルと記載させていただいております方にですね、実際にはですね、欠損がございまして、それによりましてRCのアプリケーションを作動させたところ、エラーが検知されたということによりましてRCがシステムダウンしたということでございます。
1枚めくっていただきまして4ページになります。上の部分につきましては前回ご説明をさせていただきましたけども、もう少し詳細に説明をさせていただいます。左側のこの図のですね、環境構築というところでございます。
まずですね、こちらの環境構築の方でですね、実はロードファイルというものを作っておりまして、それを実際の商用運用ですね、10月10日以降にはですね、右側の共有メモリーに移して運用していくという仕組みでございます。ところが環境構築している際にですね、実は下のところに生成プログラムというのが記載されていると思います。生成プログラムのメモリーというところをご覧いただきますとですね、生成プログラムで一時的に確保する領域という記載のところと、右側に金融機関名テーブル、それからインデックステーブルというものがございまして、実はこの右側のですね、金融機関名テーブル並びにインテックステーブル等がですね、こういった形でですね、実は境界線を突破して外側に出てしまったということでございます。
この境界を超えて外側に出てしまった結果どういうことが起きたかといいますと、実は右側に各種インデックステーブルという記載がございます。まさにそのインデックスを使って金融機関名を見に行くわけでございますけれども、ここの境界内に収まってますアからウの銀行につきましては、きちんと金融機関名テーブルの番地が1781番地から0877番地という記載になっておるわけでございますけども、境界を増えてしまった部分ですね、作業領域が不足している部分につきましては、残念ながらこういった形で例えばエ銀行だとかですね、タ銀行につきましては、番地がきちんと表示されていないという形になってしまったわけでございます。
ご存知の通り、銀行間手数料というのは金融機関名を見て処理する仕組みでございますので、ここのデータアクセス、インテックステーブルにアクセスした際、エ銀行やタ銀行のケースがあってですね、実は正常な取引が、処理ができずに異常終了してRCがダウンしてしまったということでございます。ということでございまして、右側に記載のアプリケーション、内為運営費付加チェック処理というのがございますけども、このアプリケーションの問題ではございません。それからメモリーにつきまして言いますとそこに共有メモリーと記載させていただいておりますけども、物流メモリーが不足したということでもございません。あくまでも作業領域の不足のところの問題ということでございます。もう少し詳しく申し上げますと、次の5ページになります。どうしてこういうことが起きたかということでございますけれども、一番上の黒丸のところでございますけども、OSのバージョン変更でございます。
これは中身的には32bitから64bitに変更いたしました。それに伴いまして非互換対応というものが必要になります。非互換対応というのは、下のところにアフターリスクでちょっと記載させていただいておりますけども、OSのバージョン変更に伴い、旧バージョンから互換性がない対象を洗い出して改造を加え、新しいOS上でも問題なく動作できるようにする対応ということでございます。これが今回の非互換対応でございました。その非互換対応を行ったところ、ロードファイルに含まれる金融機関テーブルのサイズを拡張する必要が出てきたわけでございます。
これはこの図で言いますと、RC17とRC23というところがございますけれども、今申し上げた通りですね、32bitから64bitにしたことを契機といたしまして、この金融機関名テーブルの拡張が必要になったということで、実際にこの再拡張という矢印があると思いますけども、こういった形で金融機関名テーブルは拡張されたわけであります。それでその下のですね、精読それから略読金融機関コードインデックス、こちらはサイズ変更はございませんでした。それでそのまんまサイズ変更なしということで右側に来たわけですけれども、実は左側の生成プログラムで一時的に確保する領域を超えてしまったということでございます。ですので、本来ならば、この作業、生成プログラムの作業領域の方のですね、領域をですね、一番左側にありますけども、この実線の境界から点線のところにですね、広げる必要があったということでございます。
どうしてこういうことが起きたかということでございますけれども、これは実際の製造担当者が残念ながらテーブルにつきましては、四つ一遍で金融機関名テーブル、それからインテックステーブル、四つ一遍で実はこの境界の線のところまでに収まらなければいけないということが条件だったんですけれども、それを残念ながら一つ一つを見ると金融機関名テーブルも境界の上のところに収まってる、それから、一つだけ取り出して例えば、精読金融機関名インデックステーブルを取り出しても、比べてみれば境界のなかには入っていたわけであります、いずれも大きさとしては入ってたわけでございます。しかし、実際には一つ一つをカウントする、それが境界の中に含まれてるかどうかをカウントするのではなくて、四つまとめてこの境界の中に入ってなきゃいけない、先ほど言いました、生成プログラムで一時的に確保する領域に入ってなければいけなかったということでございました。それによりまして３つ目になりますけども、実際にはロードファイルに含まれる他のテーブルも含め、作業領域に展開するため、作業領域が不足し破損に繋がったということでございます。もう一つ考えられるのは、その右側の下のところですね。精読それから略読、それから金融機関名テーブル、このインテックテーブル、これがですね変更は加えられていないテーブルではございましたけども、これにつきましてもですね、実は正しく作成されているかどうかを見る必要があったということでございます。
次のページ、6ページになります。それでは障害発生後の事実認識ということでございますけれども、まずですね復旧対応をいたしました。実際に今申し上げたそのテーブルを参照する際にエラーが発生してるんじゃないかということは10日にある程度わかったんですけども、その詳細な原因がなかなかつかめていなかったものですので、時間を要したということでございます。それで復旧対応といたしましては、前回もお話をさせていただきましたけども、暫定対象①とそれから暫定体制②ということを行ったわけであります。10日に行いました暫定対象①は、このRCがですね、テーブル、先ほど申し上げました通り、そのインデックステーブルが壊れておりましたんで、これを参照せずにですね、取引の種目、要するに振り込みだとか、給振だとか、そういったものをですね、判別して金額入力するプログラム改修をしたわけであります。
ところがですね、その表の下のところでございますけれども、10日に実施しました暫定対象①のプログラムですけども、残念ながら思ったよりプログラムの改修箇所が多くてですね、作業が遅延いたしまして、さらにあのプログラムを作った後にテストを行ったわけなんですけども、残念ながらその時にはエラーが発生てしまったということで、11日のシステムの営業開始には間に合わなかったということでございます。
10行の銀行の中にはもう朝4時から準備されているという銀行もあったものですから間に合わなかったということでございます。それで、11日に今度は内国為替の運営費、銀行間手数料を一律0円にして、そこを見に行かないという形にしまして、いったんプログラム改修をいたしましてそれにつきましてはうまく稼動いたしまして、10月12日から復旧したということでございます。それからその間のテレ為替が実際に使えなかった間におけます代替対応でございますけれども、こちらは下に記載の通りですね。一つは新ファイル転送を利用してファイルを授受する手法ということでございまして、こちらの図で言いますとですね、左側のとこにRC代替対応①というものがございます。テレ為替が使えない分ですね、要するにバルクで電文を送るという形式の方ですけれども、そちらを利用する、あるいは電子媒体を使って全銀システムに持ち込むというようなこの二つの方法が代替対応として取られたわけでございます。
しかしながらですね、こちらの二つ目の黒丸の通りですね、大量データが発生したことによってファイル作成を行った実績がなくて、ファイル作成に時間を要したというようなことから一部の金融機関におかれましては、仕向け電文の発信が遅延したり、また仕向け電文の受信およびですね、その後続の入金処理も遅延したということが発生したわけでございます。
その影響でございますけども次のページ7ページになります。こちらにつきましてはですね、一度件数をご報告をさせていただいております。ただしですね計数自体が若干変わっております。あの表の下のところに数字について再度影響のあった金融機関にヒアリング精査し更新ということでございまして、もう一度精査させていただいたところ数字に変化がございます。簡単に言いますとですねこれは全体については、横から141から始まりまして、その全体の数は10日分の仕向け・被仕向け、11日の仕向け・被仕向けにつきまして506万件と前回はお話させていただいたんですけども、一部件数が増えたことによりまして、566万件というふうになっております。
それから、未処理でございますけれども、前回のときには87万件というふうにですね、お話をさせていただいたわけですけども、こちらにつきましては102万件という形になっております。なおですね、こちらの処理済みの、真ん中のところでございますけど処理済みのところにですね、二つ内訳が記載されております。10日処理111人分処理という記載でございますけども、これは一部の金融機関さんの各日の詳細件数の内訳が不明でございますのでこのような記載をさせていただいております。件数の修正がございましたのでご報告であります。
補償の対応でございます。これは18日に全銀ネット加盟銀行のお客さんに損失の補償に係る申し合わせを実施し公表したところでございます。
２．発生原因分析と再発防止策について
辻理事長
次に2番の発生原因分析と再発防止策についてご説明いたします。まずNTTデータの発生源分析それから課題と再発防止策でございます。詳細は後ほどNTTデータから説明がございますけども、私どもも一緒に議論をしてきました立場でございまして、私の方からまず簡単にご説明をさせていただきます。
左側に発生原因分析課題と、それから再発防止策とございます。それで１番目の設計、製造工程プロセスへの課題ということにつきましては、混入原因の課題の認識ということでございます。OSのバージョンの非互換対応、先ほどご説明させていただきましたけども、ですね、影響調査プロセスにおきまして、プログラムの修正方針をその製造関係者のみで判断し抽出できるプロセスになっていなかったということでございます。
それから2番目の試験工程プロセスの課題でございます。これはすり抜けの原因の課題認識でございます。先ほど言いました基盤環境の変化による影響といった、その予期せぬ非互換による異常を検知する観点に課題があったということでございまして、これにつきましては下に具体的に記載がございますけども、変更を加えていないケーブルが正しく作成しされていることの直接確認ができていなかった。先ほどインデックスてーテーブルの話でございますけども、それとより本番に近い試験バリエーションが確保されていなかったということでテスト不足ということでございます。後ほど再発防止策につきましては、NTTデータの方から説明をいただきます。
それから次のページ10ページになります。こちらは3番目の復旧対応プロセスの課題でございます。以下の通り、暫定対象の検討着手が遅れ、かつその対処に時間を要したということでございます。これにつきましては、まず復旧に向けた優先順位の考え方ですが、例えばテレ為替を新ファイル転送もですね、優先させるといったようなことでございますけども、これにつきまして全銀ネットと合意をしていなかったと、それから作業時間の見積もりの話でございますけれども、作業見積もりの制度、下の作業時間だとか、障害の解消の時間とかそういうものでございますけども、そちらの制度よりもスピード優先で対処し、限られた時間でのフィジビリティ検証のまま前進したということでございます。
それから併走タスク、これはあの原因分析をするチーム、それから暫定対処をするチーム、それから代替運用をする、指導するチームといういくつかのタスクが動いておったんでございますけども、その優先順位のつけ方、それから代替案への切り替え時限ですね、この取り決めなく作業実施しまったというございます。
こちらも後ほど再発防止策につきましてはＮＴＴデータから報告いたします。11ページ、最後になりますけども今回の障害を踏まえて立ち上げましたシステム総点検タスクフォース。これは後ほど組織図を見せいたしますけれども、これ実は11月6日のＮＴＴデータの記者会見で既に公表されたものでございます。
このタスクフォースが、原因分析結果および再発防止策の内容を検証しその妥当性を評価するということです。それから２つ目でございますけれども再発防止策をより実効的なものにするため、以下の二つの取り組み、必要性を提言するということでございまして、１点目はＯＳの非互換の計画段階から、非機能観点の知識を持つ基盤人材を参画させるということでございます。要するにこのプログラムを生かした実はここが影響を受けるんではないかというようなことの非機能関係を持った方の基盤人材を参画させるということ、それから、NTTデータおよびグループ会社がですね、重要な開発プロセスを分担するということでございます。こういったことが再発防止策による歯止めということでございます。
続きまして、全銀ネット側の発生原因分析、再発防止策でございます。これまでの検討を通じまして４つの課題認識をしているところでございます。まず一つ目は、委託者、私どもなりますけども、マネジメントが不十分ではなかったかということでございます。
右側に再発防止策を記載させていただいております。それぞれいつまでに行うかという目標も記載させていただいておりますけれども、まず、各工程におけるベンダーマネジメントの向上ということでありまして、ベンダーにおける設計のレビュー体制、これは具体的にはベンダーにおける人員体制ですとか、それからスキルの習熟状況等、業務の遂行能力の確認ということであります。
それから試験内容の十全性といったものになります。それから二つ目がリスクを前提とした移行計画等の妥当性判断に係る対応ということでございまして、ここに記載の通り、東阪同時障害発生時のリスク、それから移行方法、適切な移行方法、移行時期の検討といったことの検討およびその他のマニュアル化でございます。それから次が障害の復旧対応における優先順位の整備ということで先ほど、これはご説明いたしました。それから２つ目加盟金融機関も含めたBCPの実効性不足という課題に対しましては、右側に記載しましたけれども、切り戻しをですね含めました必要なコンティンジェンシープランの作成、それからその下にありますけど、センター代行発信依頼、それから受信代行に係る留意事項の取りまとめ、その取りまとめを踏まえまして最後にですね、そちらのセンター代行発信・受信代行運用訓練シナリオの見直しそれから新規の話ではございますけども、欠送・二重発信確認対応訓練の実施といったものを再発防止策として考えております。
それから次のページ13ページになります。３つ目の課題といたしまして大規模障害を想定した全銀ネットにおける危機管理体制の脆弱性ということでございます。これにつきましては右側に記載の通り、個別の金融機関の障害につきましては対応が行われてきたわけなんでございますけど、大規模障害につきましてはですね、なかなかそういった経験のなかったこともございまして、こういったことにつきまして原因調査、復旧対応に係る情報連携や優先度の整備等を行っていく予定でございます。それから2点目、大規模障害時の対応体制等でございます。こちらにつきましては、全銀協からの応援も含めまして体制を強化していく予定でございます。それから実戦的な訓練の実施につきましては、東阪両系障害対応に係る内部訓練の新設・実施を考えているところでございます。それから4番目のシステム人材の不足と組織の脆弱性につきましては、右側に記載の通り、全銀協等との人事ローテーションを通じた人材の強化や、加盟銀行からの出向受け入れ、外部採用等を再発防止策として考えているところでございます。
それから次のシステム開発運営に関する各検討体の役割明確化でございますけども、これは後ほど図でご説明をさせていただきます。ここまでが全銀ネットの課題と再発防止策でございます。今後の見通し、システム改修等の見通し、対応方針が次のページ14ページになります。まず直近で取り組まなければいけないのが、今回の障害の影響を受けた10金融機関のＲＣ３シリーズの本格対処であります。こちらにつきましては、既にの対処を進めておりまして、NTTデータにおきまして、先ほど申し上げました領域の確保のですね、実行する全ての処理に同様の不具合が混入していないかということの水平展開をして確認済みという状況でございます。それで時期も絡んでくるわけでございますけれども、今回エラーが発生いたしました改修プログラムを12月以降、順次リリースする予定でございます。それにあたりましては東阪別日程での分散リリースということも考えております。
現在10機関の実際の商用データを使ったテストを実施している段階でございます。それから、次に今後のRC3シリーズの対応でございますけども、10行以外の件でございますけども、まず来年の1月以降を予定いたしました3金融機関ですね、1金融機関は移行を延期されております。そうしますと2金融機関となるわけでございます。その2金融機関につきましては、暫定対処まだ本格対処ではなく、暫定対処0円設定ということで対象ということになります。ただそのうち1行はRCではなく自行側で手数料を付与するということでございます。それから最後にAPIゲートウェイ、次期全銀システムの開発プロジェクトでございますけども、こちらにつきましては今時の障害の再発防止策を踏まえまして、引き続きプロジェクト管理および各種の検討を行っていくということでございます。
さらにご参考でございます。16ページでございます。こちらは11月6日NTTデータの会見の際にですね配布されたものでございます。詳細は当日ご説明がありますので、この場での説明は省略させていただきます。一点だけ申し上げますと、代表取締役社長本間様の直轄で、タクスフォース事務局ができてそこの中心メンバーは、品質保証部と技術革新統括本部となります。後ほど説明があるかと思います。それから17ページになります。
全銀ネットの今後の体制見直しイメージであります。こちらにつきましては第三者の目、外部識者の目が必要だろうということでございまして、一番左側に、現在の全銀ネット有識者からですね、3名につきましてはガバナンス、システム、顧客目線の観点からこちらの再発防止等検証有識者会議に参加していただきまして、ご意見をお伺いしているところでございます。なお今回のRCの障害対応につきましては、真ん中にありますけども、システムに詳しい専務、常務クラスのRC障害対応タスクフォースというものを設けてございます。それからその下にありますけども次課長級のワーキンググループというものを設けまして、右側のですね、現在ございます全銀ネット委員会の方ですね。見ていただくというようなことを考えて、実際にそういった形で既に動いております。
それから、全員事務局のとこでございますけども、先ほど申しました通り、プロパー職員の育成、それから加盟銀行からの人材の育成や外部採用を考えているところでございます。最後のページは、実はあの本日説明する際にですね、使用する可能性があると思いましたので、これもあの先般NTTデータの会見のときに利用されました資料を掲載させていただいております。私からは以上でございます。先ほどの9ページから10ページにつきましてデータさんからご説明いただきます。
NTTデータ・佐々木社長
それでは9ページをご覧いただければと思います。こちらNTTデータによる発生原因分析課題並びに再発防止策について記載をさせていただいております。
課題と差別防止策ということで左側にですね設計製造工程のプロセスの課題と試験工程のプロセスの課題というのを記載をさせていただきました。設計、製造工程のプロセスについてでございますがOSのバージョンアップに伴いまして非互換対応ということでアプリケーションにどういった影響があるのかということを、影響調査を行っていくわけですが、その影響調査のプロセスにおきまして、プログラムの修正方針を製造の関係者のみで判断をしてしまいまして、その誤りを抽出できないプロセスとなっておりました。
この点における再発防止策としては影響調査を行う際必ずですね、詳細設計関係者も含めて、判断をするプロセスへと変更するということにしております。また試験工程におきましては特定機能における関する試験は十分に実施しておりましたが、これは具体的に申し上げますと、いわゆる機能の充足性、いわゆる処理の分岐に関するバリエーションについては網羅的にですね試験を実施していたところでございますが、基盤環境の変化に伴う予期せぬ規模感による異常検知の観点で課題があったというふうに考えております。
今回のケースにおきましては、特定のですね一部のカナで始まる金融機関名が設定されるケースにおいて、異常終了するという事象となっておりまして、金融機関名につきましては、業務アプリケーションにおいては処理判断をしていないということで網羅的な試験を実施していなかったということでございます。この点につきましては変更対象外の今回変更対象ではないテーブルだったわけですが、そうした点につきましても新たな基盤の環境下のもとでですね、テーブルの正当性をですね、新旧で比較すること、並びに商用で流れている実取引相当のですねデータを用いた試験をですねしっかりと計画に組み込むことで改善を図りたいとしております。
これは取り組みにつきましては今後の本格対象並びに各開発プロジェクトの計画に対してもしっかりと実施をしてまいります。10ページにご覧ください。復旧対応プロセスにおける課題につきまして再発防止策についてご説明をさせていただきます。
ご説明の通り10日、11日とですね、復旧まで2日を要したということでそこで何が課題であったかについて整理をさせていただいております。まず1点目は復旧させる業務ですね。テレ為替を優先するのかどうかといったような判断につきまして、あるいは代替案への切り替え時限、いつまでにどういった対応していくかということにつきまして、十分に全銀ネットと取り組めていなかったということもありまして、暫定対処の検討着手が遅れたということがございます。
また暫定対処を行うにあたっていわゆるスピードを優先したためにですね、限られた時間の中でその実現性についての検証が不十分なままですね。対処を進めてしまったということで対処に時間を要したと認識をしております。
再発防止策としまして、復旧させる業務の優先順位とバックアップの切り替時限をですね、しっかりと全銀ネットと合意した上でですね、それらを盛り込んだ障害発生時の復旧ガイドラインというものを策定してまいりたいと考えております。さらには最大リスクを考慮した訓練の実践の中で策定したガイドラインの有効性を評価していきたいというふうに考えております。
11ページをご覧いただければと思います。今回先ほど辻理事長からも少し触れていただきましたが、NTTデータグループ並びにNTTデータにおきまして今回の障害を踏まえまして、システム総点検タスクフォースというものを立ち上げております。そのタクスフォースにおきまして、今回の全銀システムにおけるトラブルにつきましても、第三者の観点で検証をさせていただいております。その妥当性についても評価をしているというところでございます。再発防止策をより実効的なものとするためにですね、以下2点についても併せて取り組むということを提言を第三者の方からいただきまして、この２点についてもあわせて取り組むこととしております。
1点目は基盤更改等に関するですね品質保証の観点から、OS非互換の計画段階から基盤人材というのを参加させるということで、やはり開発工程における基盤人材の不足が今回のトラブルに陥った一つの要因だというふうに認識をしております。2点目はNTTデータおよびグループ会社が重要な開発プロセスをしっかりと分担をいたしまして、当社グループ社員が実務的に踏み込む領域を広げることで、当該プロセスの実態をしっかりと把握し、トラブル時のですね、旧対応におけるフィージビリティの感度をしっかりと高めてまいりたいというふうに考えております。NTTデータからのご説明は以上となります。
金融業務
2023/10/18 全銀ネット会見②質疑応答 銀行間の資金決済におけるシステム障害について
配布資料①（システム障害に係る対応状況について）
配布資料②（全銀システム障害に伴うお客さまへの補償にかかる申し合わせについて
※いずれも全国銀行資金決済ネットワークHPに遷移します
（出席者）
辻松雄理事長（中央）／小林健一事務局長兼業務部長（左）／千葉勇一企画部長（右）
冒頭約40分程度の質疑応答から、障害の原因やBCP、今後の対応について
Q.障害がなぜ起きたのか、原因についてもう少し詳しく。
私ども先週、障害が発生して以来ですね、まずはその障害の原因、真因を突き止めるべくサービス提供ベンダーとともに原因の追究を進めているところでございます。現時点ではまだ途上でございまして、詳細についてご説明できる状況にはなく、申し訳ございません。
Q.一部メモリー不足との指摘もあるが。
その点も含めまして、現在原因について私どもとベンダーの方で真因の追究を進めているところであります。
Q.RCについて簡易的な改修のまま銀行間手数料が発生しない状況が続いているが、今後どう処理していくのか。
いまご指摘の通り、これらの障害の対象になっている銀行については、銀行間手数料がゼロという形で電文を送っている状況です。本来、被仕向け銀行に対してお支払いすべき内国為替制度運営費がお支払いできていない状況でございます。これらについては、システム的に各対象となる銀行の件数を把握することができますし、銀行の方でも件数を把握することができます。その件数、種目に応じて金額が変わるのですが、それを事後で計算をして個別に銀行同士で通常の振込電文とは別の形でやり取りをして清算をするということで、具体的な方法については加盟銀行になるべく負荷をかけない形でできないかというところも含めて検証をしております。いずれにしても手段としては、今回のような障害が発生する前から付け替えの電文というのは私どもの機能として具備をしています。それを利用して銀行間で決済をするということでございます。
Q.RCを計画通りの仕様に更新する時期や、来年1月に更新を検討する金融機関への影響は。
現在はいわゆるゼロ、記入でない方式のプログラム修正を急いでやっているところであります。それが本格対応という形になるものでございます。実際にいつまでかかるのか、プログラム改修しただけでは障害が発生しないか分からないので、当然のことながらデストを行うということになりますし、先ほどお話がございました1月に23へのレベルアップを検討している銀行さんもいますので、そうしますとその方とのリレーションシップが必要になりますし、その方々との相互の通信といったものも必要なりますのでもうしばらく、1月にできるのかどうか検討しているところであります。
Q.RCを計画通りに戻す時期も分からないということですね。
仰る通りで、現在原因そのものについて究明している段階でございます。それを明らかにしたうえでさらに必要な対処をしていく。それによってほかに不具合が発生しないと確認をしたうえでテストを経てリリースする段取りになりますので、当然早期に対応したいと思っているのですが、その前提となるのは次なるレベルアップ行にもご迷惑をおかけしないというところを確実に確認した後だと思っています。そこをしっかりと対応していきたいと思っているところでございます。
Q.単純なミスだったのか現時点で分かっていることは。
今回オペレーション的なミス等ではないと思っておりまして、先ほど図でご説明をさせていただいた通りですね、このRCの中でアプリケーションが手数料をチェックしにいく機能ですね。この機能自体は銀行間手数料というのは今も現在動いている23シリーズの前の17シリーズ、こちらでも使っている機能でありまして、そこのところの機能を今回流用してるところあるんですけども、何かそこでおっしゃるような単純なミスがあったかどうかというのははっきりはしませんけれども、オペレーション的な、いわゆるヒューマン的なエラーというものではないとは思っております。
ちょっと補足しますと一応その原因がですね、こういった形でだんだん究明ができておるんですけど先ほどお話があった64bitの話ですとか、それから他に人的なミス、オペレーションではなかったんですけれども、他にその人的なミスがなかったかも含めて、もう一度洗い出しをしてるところです。
Q.復旧までに2日間かかったが、障害を想定したBCPはあったのか。
今回、まさにその代替対応という形でお示しをして、6ページですね、お示しをしているもの。つまりRCが今回のように使えなくなった事態に陥った場合にはですね、直接私ども真ん中にあるコアタイムシステム、電源システム本体ですけれども、こことですね、RCを使わずにデータをやり取りするというのがまさにBCPの対応でございまして、これは今回のRC 23シリーズへの移行に関わらず、私ども常時RC等々に何かあった場合にはですね、銀行と直接、媒介、データファイルを使った送信をやるということでこれは日頃からですね毎年全加盟銀行に原則として参加いただく訓練というのを実施しておりまして、今回もまさに障害が起きたということで、私ども当日ですねこういった対応に障害行については対応していただこうということで協議をしてですね、いずれかの方法でデータファイルを使ってファイル転送というもので、システム的に送っていただく。もしくは媒体これLTOというものなんですけども、いわゆる磁気テープですね。これにデータを入れて送っていただく。それから各銀行に対して私どもの方から渡すという、これは元々用意していたBCP対応でございましてこれを発動して対応したというところでございます。
Q.50年障害がなかった中で認識の甘さがあったのでは。
当日はまずは媒体ということで、先ほどご説明申し上げた通り、7ページの最初のところにございます通り、当然のことながら翌日は通常の形でシステム起動できるようにサービス提供できるように復旧に努めたところでありますけれども、今回残念ながらですね、ちょっとこのプログラムがかなり複雑だということで改めてエラーが発生してその対処がですね、翌日までに間に合わなかったというところでありまして。ここがうまくいっていれば復旧できたんですけども、そこが機能しなかった、うまく対応できなかったというところでございまして、そこについてはプログラムの修正を確からしさ、あるいは複雑さですね、当初はやり切れるというふうに思ってたんですけれども、ここがちょっと見込みが甘かったというところはあるかと思う。
50年ですね、一度もオンライン上でですね、お客様にご迷惑を直接おかけするような障害が発生してなかったというところにつきまして、私どもとしてこれからも守っていこうということで日々加盟銀行との訓練ですとか、今回のテストもですね事前準備等々含めてやってきたところなんですけれども、大変残念と思っております。
ちょっと補足をさせていただきますと、プログラム対応は今7ページより小林が説明した通りなんですけども、ご質問のその代替対応が残ってしまったという点につきましてはBCP訓練はやっておったんですけれども、実は先ほどちょっと読み上げさせていただきましたけれども、内国為替制度運営費（銀行間手数料）の欄を実は0円としなければいけないということがございまして、そこは今まで実は皆さんやられたことがないことでございましたので、そのゼロ円設定をするのに時間がかかったというケースもございます。
さらに補足をさせていただきますと、ご指摘いただきました通りBCPの観点は重要な観点でございます。今後、原因究明と再発防止の策定を取りまとめてまいるところでございますが、その過程の中で足元のBCPが実際どうだったのかなどにつきましては、しっかりと検証をですね、行ってまいりたいというふうに思っております。以上でございます。
※（不要）ベンダーに関する質問
Q.エラーの予見性について、事前の試験などで予期することはできなかったのか。
今回ですねこの試験の過程で今回の件が発見できなかったということ。これについてはですね、私どもとしても今後検証していく上での非常に重要なポイントだと思っておりまして、そこについては今後、テストのあり方を含めて改善すべき点がないかどうかしっかりと検証してまいりたいと思います。
Q.なぜ予見ができなかったのかの原因を究明しているということか。
はい、その通りです。予見ができなかったこと、それからテストで今回のようなことをあらかじめ拾えなかったというところ、この2点でございます。
Q.最初から一律0円にしておけば良かったのではとも感じるが、暫定対処の優先順位を決めた経緯について。
私どもとしてはですね当然のことながら、まず目指すべき姿として翌日まずは復旧させること。それもできる限り本来あるべき姿に復帰をさせたいという思いがございます。ですのでまずはそれができないかということで、今回、当日の障害が発生した後に、また提供ベンダーと協議をした結果、それに一番近い形、すなわちテーブルを参照しないものの適正な内国為替制度運営費、これをセットできればですね、先ほどご説明を申し上げたのちのちの付け替え電文で銀行間で資金のやり取りということをすることなく業務を開始できますので、それであればできるんではないかという見込みだったんですけども、結果的にそれが甘かったというふうに考えてます。
そしてそれができない。次の日も同じような状況になっておりまして、これはやはり初日のところについてはなかなかハードルが高いということで、次に優先すべきは一旦その銀行間のところでの追加での対応が必要になるものの、一般の振り込みをご利用いただいているお客様にご迷惑をおかけしないようにするところをまず最優先にしていこうということで、11日はシンプルな形でこれであればいけるというところを見込んで対応したというところでございます。
Q.試験時にエラーが発生した時点で次の暫定対策に移行する議論はあったか。
おっしゃる通りでございまして、次の日に対処した方法を思いつけばよかったとは思っておるんですが、そもそも10日の障害が発生した後、我々としては未明までこの対処それから試験というのを実施しておりまして、このエラーが発生した時刻自体がかなり遅い時間帯でございましたので、翌日までに次のプラン、まさにプランBをですね、考えて対処するというところまでも含めて、ちょっとその時点では間に合わなかったということ。そもそも次のRCの起動、これも深夜帯、ある程度の通信開始の一定前までには障害が発生していない銀行さんも含めて全体のRCを起動する必要がありましたものですから、8時半までの時間があればもしかしたらというところあるんですが、その早朝のRCを立ち上げる時間に間に合わない時間帯でこのエラー等も発生していたというふうにご理解いただければと思います。
補足をさせていただきますと先ほど小林からも話がありましたけども、どうしてもですねこの全銀システムの場合ですね、日中帯の処理が終わらないと、実際には10時過ぎぐらいになるんですけども、システムのプログラム改修を行ったとしましても、その後の実際の試験といったものをやらないといけないものですから、それが夜中の3時ぐらいまでかかったと。ところが、銀行さんの方では朝の4時から次の日の立ち上げをしなければいけないというようなことがあったものですから、時間がもう既にないということでこの日は残念ながら諦めたということであります。
Q.今回のシステム障害についてベンダーの責任は。
現時点ではすいません、法的責任について、どこまでが可能かということについてはまだ検討中でございます。そもそものその原因ですね、真因といいますか、それがまだ判明してないものですから、それが判明した後にそういった動きになるということでございます。
Q.RCの更新に際して事前のテストをどのように行い、内容は十分だったのか。
試験につきましては、今回サービス提供ベンダーでありますベンダーさんにおける試験、一般的な流れになるんですけどもまず製造単体試験というのがございます。それに続いて結合試験、さらには総合試験という形でまずは定義を完成していただく。その上で、私どもで今回のこのRC23、これを全銀ネットとして受け入れることができるかという、我々の方として受入試験というのがございます。これがいくつかの試験項目に分かれているんですけども、この試験も分割するとその試験も4種類ほどございまして、そのうち2種類が加盟銀行と接続する試験となっております。最後に受入試験で製品に問題がないだろうということで受け入れを理事長の判断で決定をいたしまして、それを用いた総合運転試験、これは銀行と私ども全銀センターを繋いでですね、一気通貫で運用の部分も含めて問題がないかどうか、これを確認するという総合運転試験は基本今回に関わらず必ずやっておりまして、こういったものを経て今回最終的に移行というところに移ったものでございます。
私どもとしては従前の品質を確保すべくですね、しっかりと取り組んでまいったつもりではあるんでけども、結果的にですね、今回のような重大な障害を引き起こしてしまったということで、改めて今回のその試験の内容や方法について問題がなかったとか、しっかりと検証してまいりたいと考えております。
Q.事前の試験の中ではエラーは起きていなかったのか。
はい、ご理解の通りです。
Q.RCで障害が発生した際のバックアップ体制は。
RCに限らず全銀本体も含めてですね、東阪と呼んでいる東京と大阪で必ず二重化しております。いずれかが障害トラブルが発生しても生きているもう片方で業務継続を行うという思想でやっております。ですので、過去いわゆる片系のところで障害が発生するということはレベルを問わずあったんですけども、そこはもう片系で業務を継続することで一時的も含めて全体の業務に支障がないようにやってまいりました。今回もですね、例えば何かハード的な故障であれば恐らくもう一方の片方のRCで業務継続ができたと思ってるんですが、初日の会見で辻の方から申し上げた通りソフトの故障だったということでありまして、両系において同じような不具合が発生してしまったということで、我々が東阪（東京・大阪）を二重化してることのBCPとしての機能というのは、今回のケースでは残念ながら機能しなかったというところです。
Q.1台ずつ切り替えることによって、今回の事態は変わったのではないか。
ご指摘の通りだと思っておりまして、片系ずつ移行をすれば今回の事態を防げた可能性はあると思っております。今回はRCの保守期限というものが東阪（東京・大阪）同時に迎えるということで、過去もこのような同じような形でやってきたということはあるのですが、東阪を同時にやるという判断・方式自体についても今後検証してまいりたいと思っています。
すいません、一つだけ補足をさせていただきますと、この1系2系とも対応年数と保守期限が同じだったものですから、こういう措置をさせていただいたということでございます。ただ今、小林からも話がありましたけれども、片系ずつできるのかどうかは検討していく予定です。
（不要）障害が発生している部分を特定して対処する判断は妥当だったのか。
Q.事前の試験でRCだけが落ちる場合は想定したか。また、銀行側には原因はなかったのか。
RC自体が試験において色々なパターンを当然想定をしております。その試験の中でRCが機能しなくなるというところが起きるのかどうかというところも確認をしてそれが起こり得ないというところを一応私ども試験の中で確認してやっております。ただ、今回のように実際にRCが落ちてしまうということが絶対ないということは言えませんので、それへのBCPということで、代替手段を備えていたというところでございます。
それから2点目のご質問のところですね。これ私ども確かに銀行と接続している部分のものではございますけれども、RC自体は私ども全銀ネットとしてのサービス責任の範囲でございまして、加盟金融機関側には特に責任はないと今のところでは判断しています。
Q.顧客への補償について具体的な対象や方法は。
補償につきましては本日公表させていただきました資料をお手元にもお配りしているところでございます。まずはですね、加盟金融機関とともに障害によって大変お客様にご迷惑をおかけいたしましたので、その補償にかかる申し合わせを執り行ったところでございます。
基本的には補償の対象というところにございます通り、直接的な、例えばご負担をいただいた振込手数料でございますとか組み戻しをした手数料でありますとか、また入金が遅れたことによります各種費用などについてですね、補償を行うということにしているものでございます。最もですね、こちらにつきましてはあくまで申し合わせというところでございますので、基本的にはですね、各加盟金融機関さんがお客様のご事情に応じてですね、これを踏まえた形でご対応いただくということを想定しているところでございます。
Q.コアタイムからモアタイムに切り替えるなどの緊急手段はなかったのか。また、10行も被害者だと思うが事務負担や残業などで生じる費用は誰が負担するのか。
一点目につきまして私からご説明をさせていただきます。ご指摘の通りモアタイムシステムにつきましては、不幸中の幸いで特に問題がなく稼働していたということで、実際一部の加盟銀行におかれてはモアタイムを使っての処理というのを実施をされていたというふうに伺っております。ただこのモアタイムシステムというのは一部の種目、つまり通常の1件1件のテレ為替振込しか取り扱うことができないという形になっておりまして、それ以外の給与の振り込みや、あるいはそもそもモアタイムでは当日の振り込みしかできないということでありますので、翌日の振り込み等はコアタイムしか送れないことで、そもそもモアタイムでお送りできる電文が限られてるという制約もあってモアタイムのみで処理を継続するというのは、全体の業務継続という意味ではちょっと取り得ない形になるというところでございます。
あとは最終的な資金決済というところにつきましてもコアタイムが動いていないとできないというところがございまして、その辺りについて（モアタイムは）かなり軽いシステムということで、一定のやはり制約があってですね、今申し上げたようなことでコアタイムを代替するというところまでの機能はないと思います。
続きまして2点目の質問につきまして私の方からご回答申し上げます。まず先ほど補償の件につきましてはお客様のご負担を最優先で検討を進めてまいってきたところでございます。他方でですね、これまでのご説明の通り原因の方はまだ明らかになっていないというところもございまして、まさに法的責任のところにつきましては今後所在につきましては現地で明らかになっていないというところでございます。こうした点が明らかになってくればですね、今ご指摘いただきましたような論点、今後議論になっていくものというふうに思っておりますが、まずはお客様の対応を最優先という形で各金融機関が前面に立って、補償いただくという方針を取りまとめたものとなっております。
金融業務
2023/10/18 全銀ネット会見①冒頭発言 銀行間の資金決済におけるシステム障害について
配布資料①（システム障害に係る対応状況について）
配布資料②（全銀システム障害に伴うお客さまへの補償にかかる申し合わせについて
※いずれも全国銀行資金決済ネットワークHPに遷移します
（出席者）
辻松雄理事長（中央）／小林健一事務局長兼業務部長（左）／千葉勇一企画部長（右）
辻理事長による冒頭発言
全国銀行資金決済ネットワーク、全銀ネット理事長の辻です。本日はお忙しい中お集まりいただきまして誠にありがとうございます。ご存知の通り、10月10日、11日と私どものシステムのRCと呼んでおります中継コンピュータですけども、こちらの方の不具合がございまして、多くの預金者の方々、金融機関、ならびに関係者の方々に多大なご迷惑、ご心配をおかけいたしました。本日この場をお借りいたしまして、お詫びしたいというふうに思っております。
現在の状況でございますけれども、10月10日、11日と改修いたしましたプログラムをRC（中継コンピューター）の中に組み込みまして、10月12日の営業時間帯、朝の8時半からは通常通り、上り電文、下り電文ともテレ為替通信が行える状況となっております。
しかしながら、この問題につきましては当法人の問題のみならず、我が国におけます決済システム全体の信頼性を揺るがす大きな問題であると私どもは認識しております。このため現在、原因の追究・究明ならびに完全復旧、再発防止策、それから残された問題につきまして、鋭意検討を行っているところでございます。本日は、本日までの状況ならびに今後の対応も含めましてご説明をさせていただきます。
お手元に資料を配付させていただいておるかと思います。右下にページ数がございますので、そちらをご覧いただければと思います。まず2ページ目になります。私ども全銀ネットの概要でございます。こちらに記載の通り、資金決済法に基づく資金清算機関でございます。参加金融機関数、ならびに取り扱い件数等はこちらの下の表に記載の通り、利用金融機関数は1133機関、これは9月末時点でございます。それから取り扱い件数、金額でございますけれども、これは1営業日平均約911万件、約14兆円というふうになっております。これは2022年度の実績でございます。以下、処理能力等も記載してございますので、後ほどご覧いただければというふうに思います。
次に全銀システムの概要でございます。全銀システムはこちらの下の図の通り、平日の日中の処理を行います「コアタイムシステム」と、平日の夜間および休日の処理を行う「モアタイムシステム」、および先ほどからお話をさせていただいております、各金融機関を繋ぐ中継コンピュータから成る形となっております。
先ほど申し上げましたコアタイムにつきましては、1件ごとの振り込みに対応しましたテレ為替と、複数の振り込みを一括で送信するバルクのような形になりますけども、新ファイル転送の二つの機能を具備してございます。それが下の図のところでRCと新F転の端末と書いてあるところでございます。それぞれのシステムにつきましては、東京と大阪で冗長化、二重化しているところでございます。
次に4ページになります。今回の発生事案でございます。10月の7日土曜日から9日月曜日の祝日におきまして、RC（中継コンピュータ）と言っておりますけれども、この新しい新機種、23シリーズと呼んでおります。この公開を14の金融機関で実施いたしました。しかしながら、10月10日火曜日のコアタイムシステム通信開始日であります、8時半以降ですね、10行におきまして公開いたしましたRC、こちらの図で言いますと黄色い部分になりますけども、こちらで電文の送受信ができなくなったという状況でございました。実際にはこちらに記載させていただいております10行で障害が発生したということでございます。
次に現時点で判明しております障害の原因でございます。5ページになります。電文を1件ごとに仕向け機関（発信銀行）から被仕向機関（受信銀行）に支払う内国為替制度運営費（銀行間手数料）につきまして、二つのパターンがございまして、まず①といたしまして、金融機関があらかじめ自行で電文に金額を入力しまして、RCに送信するパターン。自行で銀行間手数料が含まれた電文を作成するパターンと、もう一つ、あらかじめRCに設定されたテーブルを参照して、RCの方で電文に金額を入力するという二つの方法があるわけでございます。
今回はですね、今申し上げました二つ目の方式を採用している10行におきまして、あらかじめRCに設定されたテーブルをRCが参照する処理、こちらの下の図の真ん中にRCというふうに黄色で囲ってある部分がございますけれども、こちらのアプリケーション、これは内国為替制度運営費（銀行間手数料）の入力やチェックをするアプリケーションですけども、これがテーブルを読みに行った際にエラーが生じたということでございます。
右側にございます通り、このテーブルにつきましては事前準備の段階でテーブルを作成しておりまして、こちらのRCの中に展開いたしましたが、残念ながらこの事前準備の段階でテーブル上に一部不具合があったということでございます。なお、先ほど申し上げました、自行システムで電文を作成している銀行、①の方法でございますけども、3行につきましては影響がなかったということでございます。続きまして6ページとなります。
今申し上げた通りですね、そうした障害が発生したものでございますので、今回のRC公開におけます計画に基づきましてバックアップ手段で対応したところでございます。これは先ほどのRCが障害になっているものですから、RCを利用せずにデータファイルや媒体で影響行とやり取りをしたというものです。下の図を見ていただきますと、A銀行からコアタイムシステム、これは全銀センターになりますけれども、そこをRC経由ではなくてデータファイルにつきましては一括して、バルクのような形で新ファイル転送の端末を利用して、全銀センターに送ったということでございます。
それからもう一つ、媒体の持ち込みということでA銀行のコンピュータ内にある計数を電子媒体に落とし込んで全銀センターに持ち込んだというものでございます。この二つのバックアップ手段で対応したということでございます。
ただ、その下の図のところに記載の通り、障害の影響によりまして、内国為替制度運営費（銀行間手数料）のゼロ設定が必要となると通常の想定以上に電子媒体やデータファイルの用意等に時間を要したということもありまして影響を受けました銀行さんの仕向け、発信とする取り引きにつきまして、媒体やデータファイルの用意が間に合わなかった等の理由から当日中に処理が完了しない取引が発生したということでございます。概算の件数は以下の表の通りでございまして、今申し上げました処理が完了しなかった取引というのは、この表の一番下のところの未処理ですね、49万件と38万件の合計87万件ということでございます。
それからですね、私どもの復旧対応でございますが、先ほど冒頭でも申し上げましたけれども、プログラムの修正を行ったということでございます。それで10月10日と11日の2回にわたりましてRCに対するプログラム修正を行っております。
まず初日の10月10日でございますけれども、この右側に記載の通り、あらかじめRCに設定されたテーブルをRCが参照する処理において不具合があったことを踏まえまして、RCのテーブルを参照せずに取引の種類、例えば振り込みですとか、給与ですとか、そうした種目をですね、判別して金額入力する方法にプログラム修正をしたところでございます。
しかしながら、残念ながらこの方法をもってもですね、右の通り、結果の通り取引の種目を判別して金額を入力する回収処理というものはロジックがかなり複雑でございまして、残念ながら夜間の試験時にエラーが発生いたしまして翌日の営業開始日までにはそれが修正されなかったということで断念をしたということでございます。翌営業日のRC起動時刻までの対応が困難であったため、こちらの対応は中断したということでございます。
そして翌日、10月11日でございますけれども、前日の状況を踏まえまして、今度はRCが内国為替制度運営費（銀行間手数料）の入力欄、こちらに0円を一律で入力するシンプルな形に改修いたしまして、銀行間手数料の金額欄を見に行かないというシステムを作りまして、この簡易型のですねプログラム修正によりまして実際にこのプログラム修正をRCに入れて稼働をさせたところ、12日の朝の8時半からテレ為替電文につきましては通常通りの運行が開始できたということでございます。
これにつきましては、結果のところの下の方にアスタリスクがありますけれども、この内国為替制度運営費（銀行間手数料）の金融機関間で受け渡す資金でございまして、これによりまして何か顧客への影響はないということでございます。ただ、銀行さんにおかれましては0円を入力している形でございますので、それぞれの銀行間手数料の決済はまた別の資金付替電文を使って行う必要があるということでございます。
ただそれは銀行間の決済でございますので、お客様の方の入金につきましては影響がないということでございます。私の説明の最後でございますけど、今後の対応でございます。10月13日、先週金曜日でございますけれども、金融庁から資金決済に関する法律第80条第1項に基づきまして、報告徴求命令を受理しております。
本報告徴求命令に基づきまして、本件に関する事実認識、課題認識、障害の発生原因分析、預金取扱金融機関等との連携、システムリスク管理体制に対する経営管理、認識、課題認識、ならびに改善再発防止策等につき、金融庁へ中間報告も含めまして11月末までに報告をする予定でございます。
あわせまして、本件の障害に伴いましてお客様に発生いたしました損害に対する補償の考え方につきまして、本日、全銀ネットならびに全銀協のホームページに全銀ネット加盟金融機関による申し合わせというものを公表させていただきました。今後とも我が国の経済取引の基盤となる決済システムを運営していくということを今一度自覚いたしまして、社会の皆様からの信頼を早期に取り戻すべき全力を尽くしてまいりたいというふうに考えております。
