東京証券取引所（以下、「東証」と呼称する）で2020年10月1日に発生した重大障害¹に対して、株式会社日本取引所グループ（JPX、東証親会社）の独立社外取締役による調査委員会が報告書（2020年11月30日付け）を公表しています²。本記事では、この調査報告書を読み解くことを通じて、同様の重大障害に対処するための所見や教訓を得ることを試みています。

調査委員会報告書の読み解き

読み解きの対象とする調査委員会報告書は、以下に示す7編により構成されています。うち、第2編～第6編は事実関係の確認を主とした記述となっており、それら事実関係の確認結果を踏まえた上での調査委員会としての所感が第7編に提言として示される文書構成となっています。

当委員会及び本調査の概要
現物株式売買システム(arrowhead)の概要
本障害に関する事実経過
本障害発生の原因
障害発生当日中の取引再開ができなかった原因
再発防止措置
将来に向けた提言

以降では、報告書で取り上げられている障害経緯、および、その原因と再発防止策について取り上げている第3編～第7編のエッセンスを要約することを通じて、その内容についての読み解きを行っていきます。

障害に関する事実経過（報告書第3編）

障害事象の概要

報告書に示される障害事象の概要は以下の5点として要約されます。

午前7時頃共有ディスク装置（以下、「NAS」と呼称する）1号機に障害が生じた上で、2号機への自動切り替えが失敗した
NAS障害に起因して、売買監理機能、および運用管理機能に障害影響が波及した
運用管理機能への障害影響の波及に起因して、業務停止のためのシステム操作も含めた、各種のシステム運用手順の遂行に制約が生じた
障害に伴う業務影響の状況、および、運用管理システムを用いた運用手順の遂行に制約が生じている状況を踏まえて、システムにおける業務処理の継続をロードバランサを停止することを通じて（システム運用上予期せぬ形で）強制的に停止した。
業務処理の継続が遅れたこと、また、システムによる業務処理を強制的に停止したことに起因して、業務観点での整合を伴う形での業務の早期復旧に困難が生じた

時系列上での障害対応経緯

障害の発生を受けた時系列上での対応経緯は以下の通りとなります（時系列の範囲は2020年10月1日同日）。この対応経緯からは、早朝時間帯（午前7時4分）でのNAS障害発生を受けた復旧を試みたものの、システムを用いた業務の開始時刻までの復旧に失敗したことによりなし崩し的な業務停止を余儀なくされた上で、かつ、業務停止処理をイレギュラーな形で行ったがためにシステムの早期復旧が難しくなった、という流れを読み取ることが出来ます。

午前7時4分: NAS1号機のアクセス異常を示すメッセージを大量に検知
午前7時10分: arrowheadの売買監理及び運用管理画面への一部ログインが不可である事象を確認
午前7時10分: 東証から保守ベンダ（富士通）に発生事象を連絡
午前7時11分: 富士通の基盤担当及び業務担当が東証と共同で、業務影響の切り分け等の作業を開始
午前7時30分以降: 経路維持電文や通信開始電文といった定時点での情報の配信が行えていないこと、および銘柄情報の遅延を確認
午前7時37分: JPX CIOを本部長とする障害対策本部を設置
午前7時37分: システム運用部門から障害を知らせるメールを社内に送信
午前7時55分: 富士通から東証に対して、NAS1号機での障害事象がNAS制御機構のダウンを示すものである旨を連絡
午前8時0分: 日次業務スケジュールに基づき、注文受付処理を開始
午前8時1分: 通信開始の電文が送信できていない旨を通知[^3]
午前8時16分: （NAS1号機から2号機への切り替えを目的として）NAS1号機の強制電源断を指示（NAS切り替えには失敗）
午前8時26分: （NAS1号機から2号機への切り替えを目的として）NAS1号機からNAS2号機へ制御を遷移させるための操作を試行（NAS切り替えには失敗）
午前8時28分: （NAS1号機から2号機への切り替えを目的として）NAS1号機⇔NAS2号機間での死活通信を遮断（NAS切り替えには失敗）
午前8時36分: 全銘柄の売買をコンティンジェンシー・プランに従い立会開始から停止することを決定し、その旨を通知
午前8時42分: （NAS1号機から2号機への切り替えを目的として）NAS1号機からNAS2号機へ制御を遷移させるための操作を再試行（NAS切り替えには失敗）
午前8時54分～午前8時56分: arrowheadと取引参加者をつなぐネットワーク上のコネクション振分装置であるロードバランサを遮断
午前9時0分: 相場情報配信のネットワーク遮断のタイミングが9時の立会開始をまたいだため、一部の相場情報配信サービスにおいて9時から約1分間、約定情報が配信された。
午前9時11分: ロードバランサの遮断と合わせて、配信された約定情報については無効である旨を通知
午前9時26分: NAS1号機からNAS2号機へ制御を遷移させるための強制切替コマンドによるNAS切り替えに成功（NAS切り替えの成功を受けて各種機能が復旧）
午前11時: JPX CEO、および東証代表取締役社長が出席した臨時リスク管理委員会を開催し、当該委員会における議論を踏まえ、終日売買停止とする旨を決定
午前11時45分: 終日売買停止とする旨をJPXウェブサイト等において対外公表
午後17時: 翌日には売買再開できる見通しであることについて、JPXウェブサイト等に掲載
午後19時25分: 翌日には売買再開できることについて、JPXウェブサイト等で正式発表
午後22時: （呼称を生じていた）NAS1号機マザーボード交換完了

本障害発生の原因（報告書第4編）

報告書に示される（システム観点での）障害事象と障害原因との対応関係は、以下の通り要約されます。

障害事象: NAS1号機の機能停止: 原因: メモリカードに対する読み書きが不可となる部品故障（ロット障害ではない旨の最終報告が富士通により為されている）。
障害事象: NAS1号機⇒2号機への自動切り替え失敗: 原因: 切り替え設定の不備（ただし、切り替え設定をガイドするマニュアル記述自体に誤りがあった）
障害事象: NAS1号機⇒2号機への手動切り替え失敗: 原因: 切り替え手順が十分に整備されていなかった
障害事象: 売買監理機能、および運用管理機能の利用不具合: 原因: それらシステム機能がNASに依存していたため、NAS障害時におけるそれら機能を用いた業務継続に支障が生じた

障害発生当日中の取引再開ができなかった原因（報告書第5編）

報告書における事実経過の記述からは、当日の午前9時26分におけるNAS1号機⇒2号機への強制切替コマンドによる切り替え成功を契機として、システム機能それ自体の復旧には一定の目途が立っていた様子を見て取ることが出来ます。一方で、業務観点での整合を伴う形でのシステムの早期復旧には困難が生じていたことにより当日中の業務再開が見送られた経緯があるため、より早期での業務再開を阻害した原因（および背景）についての分析が報告書にて為されています。それら原因についての報告書上での分析結果は以下のように要約されます³。

問題事象: 同時間帯に障害が発生しているのにも関わらず、（業務観点での不整合を招き得る）注文受付を開始・継続する判断が行われた: 原因（背景）: 障害に際して、注文受付を停止する判断をいつ、いかなる手続により行うのかという点について、明確なルールが定められていなかった。なお、①注文受付を開始する当日8時前の段階では本障害の内容や影響範囲等を十分に把握することができなかったこと、②売買監理及び運用管理画面がいずれも利用できないという当時の状況で注文受付を停止しようとすれば、ロードバランサ遮断等のイレギュラーな手順を用いる必要があったこと、③注文受付を開始する当日8時の時点では通常の売買停止を行うことができないことを想定すべき事態にまでは至っていなかった、④過去の障害発生時には売買停止中も注文を受け付けてもらいたいとの要請がなされたという経緯があった、という4点が、行われた判断（注文受付を開始・継続する判断）の背景として挙げられる
問題事象: 緊急用売買停止を含めて売買停止をできず、ロードバランサ遮断の方法を余儀なくされた: 原因（背景）: 緊急用売買停止機能は、他機器の故障や障害発生により通常の売買停止や市場停止を使用できないような事態に対処するためのものであるにも関わらず、いかなる事態においても確実に機能するような構成として設計・実装されていなかった。
問題事象: 売買再開に向けた業務手続等の措置が速やかに行われなかった: 原因（背景）: 通常でない売買停止後の売買再開という場面を想定した、手順の策定、取引参加者への周知、および、そうした事態を想定したテストの実施等といった方策が事前に講じられていなかった

再発防止措置（報告書第6編）

東証が調査委員会に対して提示した再発防止策は以下の通り要約されます⁴。

A. 再発防止に向けたシステム対応

再発防止措置A-①: NASの設定値の修正: 障害の直接的な原因となったNASの切替え機能の設定値を修正した上で、実機確認を通じて設定値の妥当性を確認した。
再発防止措置A-②: NASの設定値の総点検: NASの全設定値を机上で精査すると共に、実機を用いた動作確認の実績が無い設定値については、設定値の動作仕様が期待に合致しているかを実機を用いて確認した。
再発防止措置A-③: 確実に切替えを実施する手段の整備: 切替機構を有する機器について、機器切替えが不調になった場合に使用する手順を新設する。
再発防止措置A-④: 継続的なテスト・訓練の実施: 市場参加者を含めた障害テスト・訓練を継続的に企画し、実施する。

B. 売買停止をするための手段の拡充

再発防止措置B-①システム障害が起きた場合に、終日の売買停止ではなく当日中に売買を再開できるように、既に発注された注文の取扱い等、必要となるルールの整備: 1つの機器故障又は1つの機能不全によって売買停止指示が機能しなくなるリスクが現在のシステムに含まれていないかを確認・整理する。
再発防止措置B-②: 緊急用売買停止機能の変更: NASの切替え不全等でも売買停止指示が機能するよう、NASを経由しない売買停止指示の実現方式を開発する。

C. 市場停止及び再開に係るルールの整備等

再発防止措置C-①: 売買停止指示の経路と状態の整理: どのような場合に注文を受け付けないこととするかについて、障害発生の時間・障害のパターン等に応じて場合分けしたうえで、整理・検討・規定化する。
再発防止措置C-②: 通常ではない売買停止が行われた場合における売買の再開に向けた手順の整備: 通常ではない売買停止が行われた場合における売買再開のためのシステム・運用手順を、東証及び取引参加者により確立するとともに、再立ち上げのために必要となる時間を効率化するための対応を検討する。
再発防止措置C-③: 売買の再開手順に基づく訓練の実施: 通常ではない売買停止が行われた場合における売買再開のためのシステム・運用手順を、取引参加者・相場ユーザを交えた形で、定期的に訓練する。
再発防止措置C-④: コンティンジェンシー・プランにおける売買再開の基準の明確化: 売買再開のための基準についても改めて検討を行い、コンティンジェンシー・プランにおいて記載して明確化を図る。
再発防止措置C-⑤: コンティンジェンシー・プランにおける売買再開の基準の明確化: 売買再開のための基準についても改めて検討を行い、コンティンジェンシー・プランにおいて記載して明確化を図る。また、コンティンジェンシー・プランに取引参加者の意向を適切に反映するための意見聴収の体制を整備する。
再発防止措置C-⑥: システム障害等不測の事象が発生した場合における適時適切な情報発信の体制整備: 「システム障害時における情報発信ポリシー」（仮称）を策定し、策定したポリシーに基づく形で情報発信手段を整備する。

将来に向けた提言（報告書第7編）

報告書第7編では、報告書第2編～第6編に列挙された事実関係を踏まえた上での調査委員会による提言が記述されています。それら提言の内容は以下の5点として要約されます。

提言項目①: 「想定外」の障害やトラブルに備えるための検討: 障害の経緯を踏まえた上で、障害当日での対応については不合理な点は認められなかった。問題は、「想定外」の事象に対する、システム面、対応措置の手順策定、関係者を含めたテストの実施等に代表される必要十分な措置が事前に講じられていなかったことにあり、それを踏まえた改善が求められる。
提言項目②: 一定の障害発生は避けられないことを前提とした対応の検討: 「Never Stop」というスローガンに過度に捉われた対応に起因して、業務停止の判断が遅れたことが、結果的に、業務再開が遅延する本末転倒な事態を招いた。本来は、あってはならないことは必ず起きるという現実を前提として受け止めた上で、対策の立案にあたって思考停止に陥らないことこそが肝要である。
提言項目③: 障害等のトラブル発生時における適時適切な情報発信: 有事に際していかなる手段によりいかなる情報発信を行うかを検討し、手順を定め、関係者にも周知しておくという対応が必要である。また、関係者の種別が多様であり、範囲も広範であることを踏まえ、より多くの情報発信チャネルの活用を検討すべきである。
提言項目④: 非常事態における社内対応体制の強化: 非常事態に際してシステム担当者及び重要事項の判断権者との間で直ちに連絡をとり、十分な検討及び意思疎通を行うことのできるように、十分な社内対応体制を確立しておくことが重要である。例えば、システム担当者及び重要事項の判断権者等が速やかに検討本部に集まることのできるように、緊急時の交通手段の確保や居住環境の整備についても早期に検討し、実現を図るべきである。
提言項目⑤:システム関連に更なる経営資源の投入を: JPX及び東証の市場における重要性に鑑みれば、独自のシステム開発能力、設計監理力、保守運用力をさらに高めるための検討が必要である。そのため、中長期的には、JPXグループ内におけるシステム設計・監理機能の向上、IT・システム研究部門の創設、IT部門の能力増強・人員強化に向けた計画的な投資増大等、抜本的なIT体制改革も選択肢の一つとして検討することが望まれる。

調査委員会報告書を踏まえた、本記事執筆者としての所見

ここまで読み解いてきた調査委員会報告書の内容を踏まえた上での本記事執筆者としての所見を、教訓も交える形で以下に示します。

業務継続性確保に関わる困難

システム提案、開発、運用の現場においては、とかく、システムを用いた業務継続性の確保に関わる困難が軽視されがちです（その結果として、「稼働率99.99%」や「障害時RTO～1時間」といった、現実には達成に困難が伴いうる要件水準が安易に設定されてしまう）⁵。こうした現状に際して、システムを用いた業務の継続性確保に関わる各種の困難の実態を示した貴重なケーススタディーとして、この報告書が（困難が軽視されがちな）事態に一石を投じることが期待されます。

報告書により示された困難事項①: 人為的なミスを排除することに伴う困難: 本障害の直接の引き金となったのは、NAS製品における高可用性構成を実現するための製品マニュアル記述の不備、という人為的なミスでした。こうした人為的なミスを完全に排除することは労力面、費用面で非常に大きな負担が生じるため、その実現は非常な困難が伴うことが実情です（例えば、今回障害の発生を踏まえて東証はNASの設定値を総点検するという「再発防止策」を採っている一方で、逆に捉えると、NAS以外のシステム構成要素における人為的なミスの可能性は未だに排除出来ていないともみなせます）。
報告書により示された困難事項②: 障害時RTO短縮に伴う困難: （調査委員会からも同様の見解が示されている通り）東証での障害当日での対応についてはベストが尽くされていたと本記事の執筆者は捉えています。そうしたベストの対応が為されたのにも関わらず、システムレベルでの復旧所要時間としては3時間程度（午前7時頃障害発生～午前10時頃システム機能回復）を要しており、事前に想定し得なかった論理障害が生じた際での復旧時間の短縮が如何に困難であるかが、今回の障害経緯により示されています。
報告書により示された困難事項③: 業務観点での状態（および業務関係者間での状況認識）の不整合を解消する上での困難: 今回障害において、システムレベルでの機能復旧は3時間程度で為されたのにも関わらず、業務レベルでは終日の業務停止が余儀なく為されました。その背景には、「注文受付処理」と「売買処理」、および「東証」と「市場参加者」を横断した形での業務観点での状態（および業務関係者間での状況認識）の不整合を短時間で解消することが出来なかったという事情があります。つまり、システムレベルでのRTO短縮への手当てが仮に為されたとしても、業務レベルでの対策が不十分である限り、業務継続性の確保には強い限界が生じます。

システム「運用系」の重要性

今回の障害においては「運用系（運用管理機能）」が機器障害の影響を受けて停止したことが業務継続に大きな影響を及ぼしました。ここで問題視したいのが、単一NAS筐体レベルでの局所的な障害⁶により、運用系での重大な機能停止（および、それに伴う広範な業務影響）が引き起こされたという事実です。つまり、障害を生じた東証システム（arrowhead）の基幹部分においては「サーバを三重化し、サーバ間でデータを同期することによってデータ信頼性を高めている」⁷ような高コストな高可用性構成が採られていた一方で、運用系においては単一NAS筐体レベルでの障害により機能が停止する程度の可用性レベルに機器構成が留められていたのが、今回障害を振り返った上での、システム設計上の最大の問題点である（可用性確保のための施策においてバランス感が欠如している）と本記事の執筆者は捉えています⁸。
確かに、従来におけるシステム設計の思想においては、「基幹系」と比較して、「運用系」（および「情報系」）における可用性レベルは一段低く捉えられがちであったという歴史的な背景はありますが、業務のシステムへの依存が高まり、かつ、システム機能が高度化、複雑化する今日においては、システムの挙動を制御する役割を受け持つ「運用系」においてもより高い可用性が求められ得ることが、今回障害より得られた大きな教訓となります⁹。

フェイルセーフ思想と業務のITシステム依存の高まりとの両立のために

調査委員会からも「一定の障害発生は避けられないことを前提とした対応の検討」が提言されている通り、障害に伴う影響が甚大であるシステムにおいては、最悪ケースを想定したフェイルセーフ思想に基づく信頼性設計を行うことがあるべき対応となります。しかしながら、業務のITシステムへの依存度がより高まるにつれてITシステムの障害に伴い生じる業務影響の規模がより大きくなるため、必然的に、フェイルセーフを実現するための仕掛けもより大きくならざるを得ません。つまり、今回のITシステム障害の影響を受けた株式市場について言うと、本来あるべき対応は、「株式市場が終日停止したとしても経済影響が生じないような市場システムの開発」だという発想も成り立ちます。
今回の10月1日の東証障害においては、幸い、株式市場の終日停止に伴う致命的な経済影響は生じませんでした。一方で、状況によっては、多くの法人や個人の存続に関わるような重大な事態が生じ得たと捉えるならば、必ずしもITシステムに依存しないフェールセーフ施策（例: 市場停止に伴い生じた関係者の損失を補填するための保険制度の整備）を検討する余地が生じ得ます。

「非難無しのポストモーテム」は実現されるのか？

本記事で取り上げている調査報告書の発行（2020年11月30日）とタイミングを同じくして、東証の代表取締役社長が辞任する旨の公示が為されました¹⁰。この辞任を取り上げて、多くの報道機関は引責辞任であるとみなした論調を採っています¹¹。
当該の人事の妥当性はさておき、近年におけるシステム運用のベストプラクティスの1つとしてみなされるSRE（Site Reliability Engineering）においては、障害の記録と振り返り（ポストモーテム）に際して特定の個人やチームへの非難を行わないことを原則としています（「非難無しのポストモーテム」）¹²。そうした観点では、今回の障害を受けた東証による対応が当該のSRE原則を受け入れたものになるのか？、もしくは、SRE原則を受け入れた、もしくは受け入れなかった結果として、来るべき次回の障害の際にどのような影響が生じるかは、多くの関係者が注目するところであると考えています¹³。

本記事の内容についてのお断り

本記事の執筆者は当該障害に対して一切の関わりを持たない全くの第三者です。
本記事の内容は執筆者個人の見解であり、必ずしも所属する組織の立場、戦略、意見を代表するものではありません。

10月1日に株式売買システムで発生した障害について | 日本取引所グループ ↩
システム障害に係る独立社外取締役による調査委員会の報告書について | 日本取引所グループ ↩
列挙された事象の内、調査委員会が問題視した事象を抽出の上で要約している。 ↩
各防止策への付番は本記事が独自に行ったものである。 ↩
（残念ながら）問題の東証システムについても「99.999%」の可用性確保が謳われていた経緯がある（参考情報: 東証次世代システムの取り組みについて）。 ↩
富士通によるリリース「東京証券取引所様の株式売買システム「arrowhead」で発生した障害の原因と対策について」によれば、障害を生じたNAS製品の機種は「ETERNUS（エターナス） NR1000」（NetApp社NAS製品のOEM）である。そのため、今回のNAS障害の実態は、NetApp社NAS筐体内のコントローラー障害であるとみなせる。 ↩
報告書第2編「現物株式売買システム(arrowhead)の概要」にて、その旨に言及されている。 ↩
ただし、一概に設計プロセスに不備があったと見なしている訳ではなく、むしろ、「東証Arrowheadの開発と要求実現プロセス」資料のp.24（「22. 工程別信頼性マネジメントの作業内容」）記述を読む限りでは、設計時における相応の対策が為されていたようにも捉えられ得る。 ↩
例えていうならば、飛行機の制御系を高可用化するのと同様の発想となる（「安全な飛行のためには、エンジンを多重化するのみでは不十分」）。 ↩
代表執行役の異動等に関するお知らせ ↩
例えば、NHKによる「東証システムトラブルの責任取り東証の宮原社長辞任」報道がそれにあたる。 ↩
SRE思想のより具体的な内容については、書籍「SRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチーム」を参照のこと（ポストモーテム文化のあり方については、同書籍の第15章で解説されている）。 ↩
システムでの信頼性を高い水準で確保するためには、高度な知識を備えたナレッジワーカーの協力が（設計局面に留まらず、運用局面においても）必要とされる以上、「人をムチ打つ」ことを通じて事態が改善する見込みは限りなく小さい、というのが、本記事の執筆者による私見となります。 ↩