　次に障害が起きた原因と、実際にその際の対応がどうだったのかについてみていく。全銀ネットから報道関係者への説明が行われた記者会見は10月10日、11日、18日、そして12月1日の4回にわたって行われた（最初の10月10日は記者クラブ所属メディア向けの『記者レク』という扱い）。このほか、NTTデータが11月に別途記者会見を開催しているが、問題となったシステムのプログラムを担当したベンダーがNTTデータであることを明言した以外、10月18日までに説明されていた情報から特にアップデートはないので詳細は割愛する。

　10月10日の時点でRC内の「内国為替手数料チェックプログラム」に問題があることは、同じタイミングでRC17からRC23へ移行した14行のうち、同プログラムを利用せずに全銀システムに送信する電文内に直接手数料を書き込む仕組みを採用していた4行では特に問題がなかったことからすぐに判明していた。一方で、10日のモアタイム突入時点からプログラム修正を試みていたものの、11日早朝のコアタイム開始の準備時間には対応が間に合わないと判断していったん作業を保留し、11日のモアタイムでは方針を転換して同プログラムを利用せず、全て0円で強制的に置き換えるプログラムで問題がないと判断し、12日のコアタイム開始を迎えることになった。

　11日に行われた会見では、チェックプログラムで参照する「金融機関テーブル」がRC23の本番稼働を開始した際に破壊されることが判明しており、異常なデータを読み込んだチェックプログラムがその動作を停止していることから、テーブルが破壊される原因を調べている段階との報告だった。後の18日に行われた会見では、直前に日本経済新聞の「メモリ不足が原因」という報道があったことから「システム移行時にメモリ容量をケチったことがトラブルの原因ではないか」という臆測が出たことで、この部分に質問が集中することになった。

　だが同日の全銀ネット側の見解によれば「事前作成された金融機関テーブルは作業用のメインメモリに転送される前段階ですでに破壊されており、テーブル作成プログラムそのものはRC17時代からあるもので事前テストでは問題がなかった」という。後述するが、RC23の仕様上は少なくとも物理メモリが不足することは考えづらく、なぜこのような問題が起きたのか原因をまだ探っている状態との返答だった。ただ複数の関係者の話によれば、根本的な問題自体は13日時点ですでに判明しており、どのような形で今後の対策を行って金融庁や関係機関に報告していくかをNTTデータと全銀ネットの間で協議していたため、報告に時間がかかったという。

内国為替手数料チェックプログラムで使用する金融機関インデックスが本科同時に破壊されていたことが障害の要因となる

なぜテーブルは破壊されたのか

　実際、なぜテーブルの破壊が発生したかだが、RC17からRC23の置き換えに伴うOSの変更がその原因となる。RCの移行ではいくつかの大きな変更点があり、最も大きなものが配置の変更だ。これまでRC17では各金融機関にRCが“アプライアンス”形式で提供され、全銀システムに接続するための閉域網（IP-VPN）の直前に置かれる形を採っていた。

　これがRC23では全銀システムのセンター側に置かれる形になり、各金融機関は閉域網を通じて直接センター内のRCに接続する形になる。下図はRC17からRC23への移行中の併存期間を図示したものだが、おおよその構成が分かるだろう。加えて、RC23では複数のサーバを“インスタンス”として収容する仮想化の仕組みを採用している。なぜこのような構成を採用したかだが、理由は主に2つあり、1つはRCが全銀センター側に集まることで管理が容易になること、もう1つは仮想化で物理ハードウェアを集約することでコスト削減につながる効果が期待できることにある。

　また仮想環境内で動作するOSの種類について全銀ネットでは「Linux」としか明かしていないが、複数の情報源によれば採用されているのは「Red Hat Enterprise Linux（RHEL）」だとみられる。RCの移行に伴い、OSも32bitから64bitへと変更されているが、これはRHELのサポート期限に由来するものと思われる。

RC17とRC23のネットワーク構成の違い（出典：全銀協）

　先ほど「物理メモリの不足が原因たり得ない」と説明したが、仮想環境ではCPUやメモリを含む“リソース”はリソースプールから順次必要に応じて割り当てが行われるため、ハードウェア構成を“ケチった”ことでの物理メモリ不足は起きにくい。そもそもリソースの利用状況をみて必要なリソースプールが用意されるため、実際に使用されるメモリ容量をみて多めにメモリを搭載するだろうし、特定のプログラムのみが動作不良を起こすことは考えにくいからだ。しかも問題となったテーブル作成プログラムはRC17時代から利用されていたもので、RC23においても基本的には「（32bitで動作していたものを）64bitでも動作するようプログラムに修正を加える」形でほぼそのまま流用されている。実際、事前テストでは問題が発見できなかった。

　だがNTTデータの説明によれば、OSの64bit化に伴ってプログラムが生成するテーブルのサイズが拡大されており、それに気付かずに確保済みのワークエリア（作業領域）の範囲を飛び出してテーブルが生成されたことで、当該部分のデータが破壊されて異常なデータが紛れ込み、それがそのまま内国為替手数料チェックプログラムで参照される領域へとコピーされ、異常なデータを検出したチェックプログラムが動作を停止するという一連の流れにつながった。

　先方によれば、このテーブル生成プログラムはC言語で記述されているという。おそらくだが、金融機関の名前などが記述されたテーブルで名称のサイズがOSの変更で可変するとは考えづらく、先ほどのスライド図にもあるように参照先を示したインデックスの番地がC言語でいう“ポインタ”で示されており、OSが32bitから64bitに変更されたことでポインタのサイズが一気に倍に拡大（あるいはポインタそのものではなく整数型のサイズなど）、それに伴ってテーブル全体のサイズが「2％ほど」（NTTデータ）従来のサイズをはみ出たものと推定される。

　プログラム上のミスとして、事前にテーブル作成用に確保された作業領域のサイズが従来の32bit環境時代のままで64bit用に再計算が行われず、事前のテスト時点ではテーブルの破壊が起きなかったが、本番環境ではこの2％の“はみ出し分”が他のプログラムと同時に動作することで破壊されて異常なデータを含んでしまうために、コピー後のデータも異常値を含んだままになってしまうというわけだ。