何があった？
2020年10月1日、東京証券取引所の現物株式売買システム「arrowhead」で障害が発生し、東証は全銘柄の立会内取引を終日停止しました。
きっかけは、共有ファイルを管理する記憶装置（NAS）のメモリカード故障でした。NASは2台構成で、1号機に障害が起きれば2号機へ自動的に切り替わる設計でしたが、この自動切替が動きませんでした。
この記事の一次資料は、日本取引所グループの独立社外取締役で構成された調査委員会が2020年11月30日に提出した「調査報告書」です。障害そのものだけでなく、売買停止や当日中の取引再開ができなかった理由、事前のテストや設計も検証しています。報告書の事実経過はJPXと東証から提供された資料・情報に依拠しており、委員会はそれらの見解や認定に対する評価・提言を主な目的としています。
この報告書で気になった9か所
以下のページ番号は、PDF先頭の公表文を除いた調査報告書本文に印字されたページ番号です。
自動切替も手動切替も失敗。最後はケーブルを抜く準備まで進んだ
JPXと東証が報告した経過によると、NAS 1号機から2号機への自動切替が動かなかったため、東証と富士通は強制電源断、制御の移行、ポート閉塞などを試しました。しかし、いずれも切替にはつながりませんでした。
そこで、物理的なケーブル抜線による対応を見据え、機器保守員をサーバ室へ入れる準備が進められました。
並行して強制切替コマンドの試行を続け、9時26分、直前に試したコマンドへオプションを追加することで2号機への切替に成功しました。
要件は30秒以内に切替。実際の設定では自動切替そのものが動かなかった
3代目arrowheadの要件定義書では、NASに関連する機能について、機器故障時にも30秒以内に切替を完了し、処理を続けられることが求められていました。
ところが、NASの「オンパニック」という設定値は「False」でした。東証は、Falseでも標準テイクオーバーは常に有効だと認識していました。
実際の仕様では、パニック通知を先に受信した場合、Falseでは即時テイクオーバーだけでなく標準テイクオーバーも発動しませんでした。
そのため、メモリ障害を起こした1号機から2号機への自動切替は行われませんでした。
初期値はFalseからTrueへ変わった。でもFalse時の動作説明は古いままだった
初代arrowheadで使われた世代のNASでは、「オンパニック」をFalseにしても標準テイクオーバーが動く仕様で、富士通も実機で確認していました。
その後、NASの仕様が変わり、Falseでは特定条件下で標準テイクオーバーが発動しないようになりました。これに合わせて、初期設定値もFalseからTrueへ変更されました。
ところが供給元の仕様書に記載されたのは初期設定値の変更だけで、Falseにした場合の動作変更は反映されませんでした。
富士通の報告によると、False設定での動作を改めて実機確認せず、書面上は問題ないと判断していました。
訂正版マニュアルは、障害の約11か月前に富士通へ届いていた
委員会は、自動切替が動かなかった最大の問題を、NASの製品マニュアルと実際の仕様の食い違いに基づいて設定が行われていた点だと整理しています。
一方、そのマニュアルは障害発生まで誤ったまま放置されていたわけではありませんでした。
委員会によると、富士通は2019年11月には、NAS供給元から訂正版のマニュアルを受領していたとのことです。
委員会は、その時点で訂正版を精査して設定の誤りを認識していれば、設定を変更できたとして、富士通の責任を指摘しています。
本番前に切替テストはしていた。ただし今回と同じ故障状態は作っていなかった
東証と富士通は、本番稼働前にNASの切替に関するテストを行っていました。1号機と2号機の間の生存監視通信を遮断し、その後も業務が継続できることを確認していました。
しかし今回の障害では、NAS本体の機能停止によってパニック通知が先に送られる状態が発生しました。
本番稼働前のテストでは、NAS本体を機能停止させ、今回と同じ状況を再現する障害テストは実施されていませんでした。
委員会は、そのテストをしていれば設定不備に気づけた可能性があるとしています。さらに、製品出荷前にarrowheadの設定値でテストしていれば不備が見つかった可能性があり、NASの重要性からすれば東証も富士通へそのテストを求めるべきだったとも言える、と評価しています。
非常時の「緊急用売買停止」まで、故障した同じNASに依存していた
arrowheadには、通常の売買停止や市場停止が使えない場合に備えて「緊急用売買停止」が用意されていました。
しかし、相場情報配信や複数の売買停止機能は、NASに格納したファイルを利用する構成でした。
緊急用売買停止も、売買停止の対象銘柄を指定するファイルを故障したNASに置いていたため、使うことができませんでした。
委員会は、緊急用売買停止は他の機器が故障した場合に使う機能なのだから、どのような事態でも確実に実行できる構成にしておくべきだったと指摘しています。
「売買停止」したが、ネットワークを切っただけ。中では約定処理が続いた
通常の売買停止も緊急用売買停止も実行できなかったため、東証はarrowheadと取引参加者をつなぐロードバランサを遮断しました。
これは注文や通知の通信を遮断する操作で、約定処理そのものを停止する操作ではありませんでした。
ロードバランサを切るまでに受け付けていた注文については、ネットワーク遮断後もarrowhead内部で約定処理が行われました。
その約定通知は取引参加者へ送られず、システム内に滞留しました。相場情報側では9時から約1分間、約定情報も配信され、東証は9時11分にそれらが無効であると通知しています。
再開できると答えたのは売買代金シェア約38％。しかも外資系証券だけだった
NASの切替に成功した後、東証はarrowheadを再立ち上げして当日中に売買を再開する方法を検討しました。ただし、取引参加者側では既に発注済みになっている注文を再発注するなど、通常とは違う対応が必要でした。
JPXと東証の説明によると、取引参加者へヒアリングした結果、対応可能と答えた参加者は限られました。ここでのシェアは参加者数の割合ではなく、参加者の過去の売買代金に基づくものです。
注文を再発注できると回答した参加者の売買代金シェアは約38％で、その属性も外資系証券に限定されていました。
オンライン証券からは対応不可との回答もありました。さらに、arrowheadを再立ち上げしたうえで売買を再開する方法は、テスト環境でも実施されたことがありませんでした。
「Never Stop」を強調しすぎるのは本末転倒。委員会は「あってはならないことは必ず起きる」と書いた
arrowheadは「Never Stop」を掲げ、停止しないことを重視して運用されてきました。委員会も、その目標自体を否定していません。
ただし、障害発生後も8時の注文受付や9時の取引開始を絶対的なものとして扱い、その前提で対応した結果、回復後の取引再開が難しくなったことを「本末転倒」と評価しました。
委員会は、「あってはならないことは必ず起きる」という現実を前提に、思考停止に陥らないことが重要だと記しています。
障害の発生を完全に排除するだけでなく、影響を限定し、速やかかつ安全に再開するという観点から対応を考える必要があると提言しています。
報告書が指摘した背景
委員会は、メモリカード故障そのものについては偶発的で、耐用年数内でもあり、東証の対応に問題があったとは認めていません。
重大な障害に広がった中心には、実際の製品仕様と食い違うマニュアルに基づいたNAS設定がありました。委員会はこの点について富士通の責任が大きいと評価する一方、本番稼働前に今回と同じ故障状態を再現するテストをしていなかったことなどから、東証にも一定程度の責任があったとしています。
さらに、自動切替が動かない場合の手動切替、NASが使えない場合の売買停止、通常ではない停止後の売買再開まで、障害後に必要になる次の手段が十分に切り離され、準備されていませんでした。報告書の最後で「Never Stop」だけでなく回復力を重視するよう求めているのは、こうした経緯を踏まえたものです。
この記事の訂正
報告書が会社から提供された資料・情報に依拠する事実経過と、委員会の評価を区分しました（p.4–5）。付箋04のマニュアル受領は会社説明に基づく記述として明示し、05では本番稼働前の故障再現試験と、製品出荷前の設定値試験についての別の評価を区別しました（p.21）。付箋07・08の参照を補い、約38％は参加者数の割合ではなく過去の売買代金シェアであることを明記しました。要約を直接引用と誤認させる見出しの引用符も整理しました。