全3452文字
PR

 本当の問題はメモリーの故障でも、切り替え機能が作動しなかったことでもない――。東京証券取引所で2020年10月1日に発生した大規模システム障害を筆者なりに分析するとこうなる。

障害翌日朝刊の株式相場表。値付かずを示す「―」で埋め尽くされた
障害翌日朝刊の株式相場表。値付かずを示す「―」で埋め尽くされた

 真因はどこにあるのか。東証のシステム問題について、2005年のシステム障害、旧ジェイコム株の誤発注問題、2006年の「ライブドア・ショック」による売買停止、2012年のシステム障害と、継続的に取材してきた立場から検証してみる。

午前9時過ぎには共有ディスク2号機に切り替わっていた

 今回のトラブルの引き金は機器の故障だった。10月1日午前7時過ぎに東証の取引システム「arrowhead(アローヘッド)」で共有ディスク装置のメモリー障害を検知した。共有ディスクは2台あり、通常なら故障した1号機の役割がもう1台の2号機に切り替わるはずだった。だがフェイルオーバー機能がうまく作動せず切り替わらなかった。相場情報の配信や売買監視の業務ができず、円滑な売買ができないと判断し、東証は売買停止を決めた。

 午前9時過ぎには共有ディスク2号機への強制切り替えを完了していたが、売買を再開するにはシステムを再起動する必要があった。受け付け済みの売買注文が失効となるなど影響が大きいことから、東証は再開を断念。正午前に終日売買停止を発表した。

 「東京証券取引所の役割は、公平で信頼でき、使いやすく分かりやすい市場を提供することです」。東証のWebサイトにはこう書いてある。取引の場、つまりプラットフォームの提供が証券取引所の最大の使命であり、この使命を丸1日にわたり果たせなかったという点で、東証の責任は重い。

 ただ、その責任を果たせなかった原因がどこにあるか、という点について、多くのメディアがうまく整理しきれていないように感じる。10月1日以降、各種メディアが「バックアップが機能しなかった」と繰り返し伝えている。テレビのニュース番組では経済の専門家が「何のためのバックアップなのか」と憤っていた。

 システムの設計や信頼性に不備があったかのような指摘は、終日全面停止問題の本質を捉えているとは言えない。

フェイルオーバーの失敗は珍しくない

 ハードウエアの故障は一定の確率で発生する。そこで、信頼性が求められる場合、故障が発生してもシステムが稼働を続けられるよう、故障した機器の役割を待機系など別の機器に自動で切り替える「フェイルオーバー」機能を用意しておく。だがフェイルオーバー機能が作動しないトラブルも、実はよくある。IT業界に身を置く人なら実感としてよく分かるのではないか。

 例えば2019年に発生したAmazon Web Services(AWS)の大規模障害は、空調設備を管理する制御システムのフェイルオーバー機能が正常に機能しなかった。2017年に東京商品取引所の売買システムで発生したシステム障害も、サーバーの部分的な故障をシステムが故障と判別できず、フェイルオーバーに失敗した。このほかにも、フェイルオーバーの失敗による大規模なATM障害などが発生している。

 要は確率の問題である。対策を何重に講じても100パーセント安全にはならない。トラブルが発生してから「機械が壊れたのがおかしい」「バックアップ機能が働かなかったのはおかしい」と批判しても、それは建設的な批判とは言えず、再発防止につながりにくい。

 こう書くと「システム障害を肯定するのか」と反論されそうだ。もちろん肯定するつもりはない。システム障害の影響が拡大した真因は、フェイルオーバー機能の不具合とは別にあると筆者はみる。それは緊急時における対応の不備だ。

緊急対応と復旧への準備に問題があった

 システム障害の原因は朝のうちに特定でき、共有ディスク装置を交換してシステムを再起動すれば売買を再開できた。だが再起動すると証券会社側で通常と異なる対応が必要になるため、対応が難しいと東証は判断、終日の売買停止を決めた。

 もちろん証券会社の意見を聞いて混乱を避けるのは、公正な取引を担う観点から必要な処置だ。東証は非常時の対応についてコンティンジェンシープラン(緊急対応計画)を用意しており、それに基づいて決断を下した。ただ、停止の条件や対応策については決めてあったものの、取引を再開するための取り決めや準備が十分ではなかった。