全銀が今回のシステム障害の状況報告を行ったが、文系メディア様には荷が重すぎるので（というか、科学技術に限らず専門性の高い内容には文系メディア様は無能どころか百害あって一理無し：）最近着目の例の方の記事より：
長いのでAI要約を引用させて頂くと：
AIによる要約
全国銀行資金決済ネットワーク（全銀ネット）は、10月18日に前週の全国銀行データ通信システム（全銀システム）の障害に関する記者会見を開催した。今回の障害は、旧世代から新世代の中継コンピュータ（RC）への置き換え作業中に発生したもので、送金の指示書である「仕向」および受信指示である「被仕向」の電文の送受信ができなくなったため、送金が遅延したり行われなかったりする事象が起きた。障害の原因については、参照テーブルのデータが壊れていたことが判明し、RC内のアプリケーションがエラーを起こして異常終了することで障害が発生した可能性が高いとされる。全銀ネットはベンダー名を公表せず、問題の責は全銀ネットにあるとしている。また、障害情報の告知や対応においても改善が必要とされている。今後の対応として、RC23での障害原因の究明を進めつつ、広報手段の改善やマニュアル整備が求められるとされている。
この要約はChatGPTによって自動生成されたものであり、原文の完全性や正確性を保証するものではありません。この機能はベータ運用中です。
原因については調査中の様だが、現時点の被疑対象としてRC23の管理テーブルが破損？していると説明しているが根本原因は調査中らしい、上記記事より引用↓
このあたりについてもう少し詳しく説明していく。銀行間でやり取りされる送金の際の手数料である「内国為替制度運営費」の設定は、RC23においては下図のように「金融機関があらかじめ電文に金額を入力」「RCが事前に用意した“テーブル”を参照してRC自身が電文に金額を挿入」といういずれか2つの手段を選ぶことができる。
今回RC23へのリプレイスが行なわれた14行の金融機関のうち、障害が発生した10行については後者を、それ以外(JPモルガンチェース銀行を除く3行)については前者が選ばれており、ここが障害発生の分岐点となった。今回の障害は、この“テーブル”を参照するRC内のアプリケーションが、“テーブル”を参照した際にエラーが発生して異常終了することで起きたもので、前述のように当初の問題はこのアプリケーション側にあるような印象があったのだが、実際には参照先の“テーブル”そのものに問題があったというわけだ。
異常終了が問題となったアプリケーション(チェックプログラム)が参照する“テーブル”は、RCが再起動されたタイミングなどで(事前に)作成された“テーブル”をコピーする形で利用される。プログラムが動作するメモリ上に“テーブル”は展開されるが、この「コピー前の段階ですでに“テーブル”が壊れていた」というのが18日に新たに判明した事実だ。
上図の赤丸の部分がそれに該当するが、テーブルを作成するプログラムそのものはRC17時代から利用されていたもので、新環境(RC23)においても特に変更はなく、事前テストの段階でも問題は発見できなかった。だがRC23が10日のコアタイムに突入して本番稼働をしたとたんに“テーブル”生成から破壊が起きており、18日時点ではこの原因究明に比重が移ったと考えられる。
全銀ネット側では「メモリが原因かもしれないし、64bit環境への移行が原因といえばそうかもしれない」といった形での曖昧な回答をしていたが、これは“テーブル”が壊れた原因が同時点では判明していないことに由来するとみられる。
ここからがポイントかもしれないが↓
障害発生原因の考察と全銀ネットの対応で不足していたもの
RC17は“アプライアンス”形式で金融機関側に設置される中継装置であり、コアタイム用とモアタイム用の2つに加え、さらに多重化のための分岐が行なわれており、設置コストや管理負担が比較的大きかった。
一方でRC23は全銀システムのセンター側に配置される構造になっており、これまでアプライアンス装置として提供されていたハードウェアは仮想化によって1つの“サーバファーム”上に集約される形となった。管理負担の低減とコスト削減を両立させるための手法だが、これまでアプライアンスとして起動していた機能が“インスタンス”として呼び出される形に変化したことで、先ほどの日経新聞が伝えていたような「メモリ不足で動作しなかった」ということは考えづらく、少なくとも動作に必要なメモリが不足しているのであればインスタンスが必要とするメモリリソースを単純に多めに割り当てるだけでいい。
さらにいえば、前述の事前準備として“テーブル”を作成するプログラムについては、RC17時代からそのまま流用したもので、RC23で特に変更を加えたわけでもないという。ここは筆者の推測となるが、問題の発生原因となったプログラムはRC17とRC23で違いはなく、しかも本番以降前の事前テストはすべてパスしていたということで、「本番環境で諸条件が揃った場合のみに再現される特殊な障害」である可能性が高いのではないかとみている。つまり必要な手順はすべて踏んでおり、事前テストでも特に問題はなく、当初言われたようなケアレスミスに起因する可能性は低いという考えだ。重ねての推察となるが、各種のプログラムそのものには問題なく、RC23の環境で採用されているミドルウェアやOSなど、根本となるシステム自体が内包するバグや何らかの不具合、あるいは仕様で問題が発生してしまったのではないかと現時点では考えている。
今時点では情報もエビデンスも無いが、著者の推測（経験知によるが、根拠が明確でもないので推測と言えよう）が正鵠を射ているのであれば、あるあるなパタン（こういう軽い言葉で表現するのは不適切だが）なのかもしれない。ここまでの洞察をするのは贔屓かもしれないが著者の経歴に拠るものが少なくない（少なくとも駄目テック記者には到底書けない記事：）。そして〆に来るのが：
今回18日の全銀ネットの会見で1つ感心したのは、問題の責はすべて全銀ネット側にあり、ベンダー名を公表したり、ベンダーへの責を問う姿勢を一切見せなかったことだ。ある意味で発注側としてあるべき姿勢だとも思う。
この姿勢を評価して筆者も今回のRC23を担当したベンダー名には触れないが(全体の受注はNTTデータだが、RCの担当はまた別のベンダー)、この担当ベンダーが提供するミドルウェアやシステムなどが問題を内包していた可能性を考えている。この世にバグのないシステムなどほぼ存在しないと考えているが、システム上で動作するプログラムに問題が発見できず、それでも本番環境では問題が発生するケースなど、システム側にバグがあった場合は問題の特定や発見が難しい。今回はそのケースに該当するのではというのが筆者の考えだ。
これには私も一票。最近は日本の銀行さんも余裕が無くて、ベンダを訴える事案や、求償請求が多発している様だが（求償請求処理って大変なんだよねぇ、顧客との信頼関係も失うし、全く良い処無し）、２０世紀の金融システム顧客の矜持を久々に垣間見た様な気がする。
