参考資料２－３

平成 29 年 8 月に発生した大規模なインターネット接続障害に関する検証報告

平成 29 年 12 月
電気通信事故検証会議

目次
第１章

発生した事象 .................................................................................................... 2

１．グーグル............................................................................................................... 2
２．NTT コミュニケーションズ株式会社 .................................................................... 2
３．KDDI 株式会社 ...................................................................................................... 3
４．利用者、その他電気通信事業者........................................................................... 5(1)楽天証券株式会社 ........................................................................................... 5(2)その他電気通信事業者.................................................................................... 6

５．小括 ...................................................................................................................... 6
第２章

電気通信事業者による対策 .............................................................................. 8

１．人為的ミスの未然防止 ......................................................................................... 8２．誤送信された経路情報の受信防止及び不要な経路情報の送信防止 ..................... 9３．障害に関する情報の電気通信事業者間での共有 ............................................... 10(1) 日常での情報交換........................................................................................... 10(2) 電子メールによる問い合わせ方法 ................................................................. 10(3) ネットワーク技術者間の情報共有 ................................................................. 10(4) ICT-ISAC の取組 ............................................................................................. 11(5) 総務省による電気通信事業者への情報共有の仕組みの構築 .......................... 11第３章

本事案から得られた教訓等 ............................................................................ 12

１．人為的ミスの未然防止 ....................................................................................... 12
２．誤送信された経路情報の受信防止及び不要な経路情報の送信防止 ................... 12
３．障害に関する情報の電気通信事業者間での共有 ............................................... 13
４．利用者周知 ......................................................................................................... 14

1

第１章

発生した事象

平成 29 年８月 25 日の正午過ぎから夕方にかけて、一部のウェブサイトにつながりにくくなるなど、国内で大規模なインターネット接続障害が発生した。
本事案については、電気通信事故検証会議において、発生した事象の把握、電気通信事業者による対策について、関係者へのヒアリング等を通じて検証を行い、そこから得られた教訓を取りまとめた。
まず、発生した事象について、各社からのヒアリング結果は以下に示すとおりである。
１．グーグル
グーグルによると、本年 8 月 25 日 12 時 22 分に、本来、配信する予定ではなかった経路
情報1を、誤設定によりネットワークプロバイダーに配信した。当該誤設定は、グーグルのネットワークオペレーションセンター（NOC）の検知システムで検知されたことから、NOC スタッフが８分で修正し、グーグルの対応は終了したとのことであった。
なお、誤設定は、通常のトラフィックエンジニアリングの作業中に、起きたものであった。
自律したネットワークの集合であるインターネットの性質上、影響の全容を即座に把握することは難しいが、障害発生後、複数のネットワーク事業者から、グーグル NOC の窓口に問合せがあり、適宜情報提供を行ったとのことであった。
また、今後も引き続きシステムの改善等にも取り組むとのことであった。
２．NTT コミュニケーションズ株式会社
NTT コミュニケーションズ株式会社（以下「NTT コム」という。）によると、12 時 22 分頃から 12 時 45 分頃までの約 23 分間、東日本電信電話株式会社及び西日本電信電話株式会社が提供する光回線フレッツを用いて NTT コムのインターネットサービスである OCN サービスに接続している利用者において、インターネットを利用したデータ通信がつながりにくくなるという事象が発生したとのことであった。

1

インターネットの通信を成立させるため、接続する事業者間であらかじめ送受信される通信経路の設定に必要な BGP（Border Gateway Protocol）による情報をいう。

2

なお、NTT コムは、グーグルが誤設定により海外ネットワークプロバイダーに配信した経路情報を直接受信してはいないが、当該経路情報には NTT コム宛て通信に関する経路が含まれていたため、国内電気通信事業者から NTT コム宛ての通信が海外ネットワークプロバイダー、グーグルを経由することとなり、一部の通信に過大な負荷による逼迫と遅延が発生したことによるものとのことであった。
12 時 22 分以降、NTT コムの電気通信設備に異常は見られなかったものの、接続しているISP との間のトラヒックが急激に約 20％減少していることを検知したことと、利用者からの問合せが急増した状況から、OCN サービスの利用者に何らかの不具合が発生していることを認知した。その後、12 時 45 分頃には、減少したトラヒックが回復したことを確認できたため、復旧したものと判断したとのことであった。
NTT コムは、23 分間で障害が解消したため、正常化したものと認識していたが、その後も利用者から、インターネットがつながらない、一部のウェブサイトがつながらない、といった問い合わせが多く寄せられていたことを踏まえ、故障情報のホームページに情報を掲載し、コーポレートサイトのトップにバナーのリンクを貼って周知を行ったとのことであった。
障害情報のホームページに掲載した情報は、当初は原因が確たるものではなかったため、13 時 20 分に、海外向け通信の一部において断続的に利用できない状況が発生していたが、現在は回復している旨を掲載した。その後 13 時 54 分には、海外の経路不安定事象により通信の一部が断続的に利用できない状況が発生していたこと、及び OCN 設備には異常が発生していない旨を続報として掲載し、原因が判明するまでさらに２回の掲載情報の更新を行い、最終的には、18 時 51 分に、インターネット上において大量の経路変動が発生し通信が不安定となったが、12 時 45 分頃に復旧したこと、及び再度 OCN 設備には異常がなかった旨を掲載したとのことであった。
本事象の発生原因は、ネットワーク技術者レベルでの非公式な情報交換を通じて、グーグルによる経路情報の誤設定によるものと推定はできたが、判断がつかなかったため、利用者への情報提供に苦慮したとのことであった。
３．KDDI 株式会社
KDDI 株式会社（以下「KDDI」という。）によると、大量かつ詳細な経路情報が海外ネット
ワークプロバイダーから KDDI に配信されたことにより、12 時 24 分から 12 時 39 分まで、NTT コム宛ての通信が国内経路ではなく海外経由の遠回りのルートとなったことで遅延が3発生したとのことであった。
これに加えて、海外ネットワークプロバイダーから配信された経路情報が大量であったことにより、12 時 24 分から 16 時 47 分まで、KDDI 側の一部のルータが不安定となり、国内のインターネット接続サービスを提供する電気通信事業者（以下「ISP」という。）及び法人向けのインターネットゲートウェイサービスの利用者において通信が不安定となる事象が発生したとのことであった。
なお、上位 ISP から受信する経路情報は、通常国内電気通信事業者においてフィルタリン
グ等により選別されるものではなく、全ての情報を受け取り、一部の利用者を除いた下位ISP やインターネットゲートウェイサービス利用者に全て配信する契約体系としているとのことであった。
また、通常、インターネットの経路情報は、図１のとおり毎月約５千件のペースで増えているところ、今回 KDDI に配信された経路情報は約 10 万件を超える情報であり、一度に約２年分の経路情報が配信されたことになるとのことであった。
KDDI は、12 時 50 分にルータが高負荷状態となったことを示すアラームが発報されたことにより、何らかの異常があることを認知し、原因特定に係る切り分け作業の中で、ルータのトラヒックを確認するも、KDDI 網内のトラヒックの減少は見られず、また、接続先の死活監視を行ったが、接続断はなく正常に接続されている状況に見えていたとのことであった。さらに、経路情報収集システムにより経路情報の確認を行ったが、確認を行った時には既に元の正常な経路に戻っていたことや、他の電気通信事業者等への確認を行ったが確かな情報がなかったことから、原因の特定及び対処に時間を要したとのことであった。
再発防止策としては、上位 ISP から受信する経路情報の上限を設定するとともに、大量の経路情報を受け取った場合であっても、その影響を最小化するルータへの置換を実施するといった対策を実施しているとのことであった。さらに、法人利用者への周知が遅れたことを踏まえ、法人専用の支援サイトを常設し、障害発生の可能性が生じた場合は速やかに障害情報の掲載を行うとともに、利用者には能動的にメール等で連絡することとしたとのことであった。

4

（図１）経路情報数の推移（KDDI 提供）

４．利用者、その他電気通信事業者(1) 楽天証券株式会社
楽天証券株式会社（以下「楽天証券」という。）によると、12 時 24 分から 15 時 49 分までの間、楽天証券 Web サイトへログインできない、またはログインしづらい事象が発生した。これにより、東京証券取引所の午後の取引の時間帯（12 時 30 分から 15 時 00 分まで）において、一部利用者においてインターネットを通じたサービス全般に支障が生じ、取引が実施できず利用者や市場へ大きな損害を与えたとのことであった。
楽天証券は、KDDI のインターネットゲートウェイサービスを主回線及び副回線において利用しているが、当該契約を締結した際には、障害が発生すると主回線及び副回線両方に障害が発生するリスクに関する説明はなく、それぞれ独立した二重化された回線であるため問題ない旨の説明を受けたとのことであった。
障害発生時、楽天証券から KDDI に問合せを行ったが、明確な回答が得られなかったことから、顧客に対して十分な説明を実施できなかったとのことであった。このとき、楽天証券には顧客から通常時よりもはるかに多い問い合わせを受けたが、KDDI からの情報開示がなかったことにより、顧客対応に苦慮したとのことであった。
後日、KDDI からの説明で判明したこととしては、KDDI の法人契約に係るシステムでは各社用にルータのグループを複数構成しており、グループにより異なるメーカのルータを用いていたところ、楽天証券の回線が収容されていたルータは、仕様が異なり、大量の経路情報を受信した結果、処理が逼迫し、正常なサービスの提供ができなかったとのことであった。

5

なお、他のグループのルータは、経路情報に対するフィルタリングが設定されていたことにより、影響がなかったとのことであった。
楽天証券では、今回の事象を受け、平成 29 年 11 月から 12 月にかけて、冗長化している回線を複数の電気通信事業者の回線に切り替え、マルチホーム化により広域インターネット網への接続先を複数にして自律的な運営を図るとともに、ログインサーバを広域インターネット網内にクラウドサービスを用いて設置し、冗長化を図っていくとのことであった。
また、顧客側の立場に立ってサービスの提供や情報開示を進めているところ、回線も含めた外部委託先についても評価基準を設け、定期的に評価を行い、フィデューシャリー・デューティー2を果たしていくとのことであった。
(2) その他電気通信事業者3KDDI のインターネットゲートウェイサービスを利用してインターネット接続サービスを提供している電気通信事業者によると、利用者からインターネットにつながりにくい旨の申告が寄せられたことにより、何らかの異常を認知し、確認したところ、利用者とのリンクやセッションは切断されていないが、一部のウェブサイトにつながりにくい状態を確認したため、すぐに他の電気通信事業者の回線に切り替えたことにより、つながりにくい状態は解消されたとのことであった。
５．小括
ヒアリング等の結果から、今回の事象は以下のとおりとなる。
グーグルが、12 時 22 分に大量かつ詳細な経路情報を、誤設定により、海外ネットワークプロバイダーに誤って配信し、受信した海外ネットワークプロバイダーにより、KDDIをはじめとする事業者に配信されたが、NTT コムには配信されていない。



当該経路情報には、NTT コムのネットワークに割り当てられた経路情報が多く含まれており、これにより、NTT コムの設備に支障はなかったものの、NTT コム宛て通信が、海外ネットワークプロバイダー及びグーグルを経由する設定となってしまったことから、経由した回線が逼迫し、NTT コム宛ての通信がつながりにくい状態となった



当該経路情報の量については、KDDI からのヒアリングを踏まえれば、約 10 万を超える経路が配信されたと見ることができる。



当該経路情報を受信した KDDI においては、法人向けインターネットゲートウェイサー2

顧客本位の業務運営をいう。近時では、他社の信認に応えるべく一定の任務を遂行する者が負うべき幅広い様々な役割・責任の総称として用いる動きが広がっている、（金融庁「顧客本位の業務運営に関する原則」平成 29 年 3
月 30 日より） （http://www.fsa.go.jp/news/28/20170330-1.html）

3

KDDI から法人利用者の同意を得て情報提供いただいた電気通信事業者に電話による調査を行ったもの。

6

ビスのルータに過大な負荷がかかり、不安定となった。また、当該ルータの一部において、大量の経路情報を受け取った場合の動作に差異があったことから、一部の当該サービス利用法人において、16 時 47 分まで当該法人のインターネットを利用したサービスに、利用者がアクセスしづらいといった事象が発生した。
これらをまとめると、図２のようになる。
（図２）8 月 25 日に発生したインターネット接続障害の概要

7

第２章

電気通信事業者による対策

インターネットの経路情報に不具合が発生した場合、その原因が海外で発生した場合であっても日本国内で影響が出るなど、想定されない影響が出る可能性があるとともに、インターネット全体に甚大な影響が出るおそれがある。このような事態を発生させない、また発生したとしてもその影響を最小限にするために、電気通信事業者がどのような対策を講じるべきかについて、関係者からのヒアリングを踏まえ、以下の観点から検証を行った。
経路情報の設定における人為的ミスの未然防止

誤送信された経路情報の受信防止及び不要な経路情報の送信防止

インターネット障害に関する情報の電気通信事業者間での共有



利用者周知

検証の結果について、項目ごとに以下のとおり整理した。
１．人為的ミスの未然防止
経路情報の設定作業は、自動処理で行われる部分はあるものの、新規接続先情報の入力など人間の手作業は必ず含まれる。経路情報の誤設定による障害は、過去にも複数発生しており、主なものを表１にまとめている。また、いくつかの事業者によれば、小規模な経路情報の誤設定は、頻繁に発生しており、発生の都度、技術者が修正し対応しているとのことであった。
（表１）経路情報の誤りによるインターネット障害の発生状況
発生年月

発生場所

発生事象
米国の Tier1 事業者である Level3 Communications が、本来配信する予定で米国、カナダ、
2017 年 11 月

ブラジル、アルゼンチン、アラブ首長国連邦

なかった数千もの詳細な経路情報を誤設定により契約事業者に配信したことにより、米国大手 ISP である Comcast、カナダ大手 ISP である Bell Canadaや 、 大 手 コ ン テ ン ツ プ ロ バ イ ダ で あ る Netflix 宛 て の 通 信 が Level3Communications を回り込むこととなり、Comcast や Bell Canada だけではな
く、ブラジル、アルゼンチン、アラブ首長国連邦の ISP に約 90 分のインターネットの遅延が発生。

4

マレーシアの ISP である Telekom Malaysia が、米国の Tier1 事業者である
2015 年 6 月

マレーシア

Level3 Communications に約 17 万 9 千もの経路情報を配信したが、当該経路情報は Telekom Malaysia を回り込む経路となってしまったため、世界中で約2 時間インターネット接続の遅延が発生。

5

4

出典：Dyn (Doug Madory) ”Widespread impact caused by Level 3 BGP route leak” Nov7,2017https://dyn.com/blog/widespread-impact-caused-by-level-3-bgp-route-leak/5

出典：BGP MON “Massive route leak causes Internet slowdown” Jun12, 2015
https://bgpmon.net/massive-route-leak-cause-internet-slowdown/

8

大手 ISP のルータのグローバルルーティングテーブルに 15,000 件の新しい経2014 年 8 月

米国及びカナダの一部地域

路情報が追加されたことにより、ルータのメモリ容量が不足し、ルータの処理遅延が発生。
これにより、インターネット通信が不安定となり、一部のサイトが全く読み込まれない事象が発生。

6

カナダの ISP である Dery Telecom Inc が VIDEOTRON から配信された 10 万超の AS パスの長い経路情報を Bell に配信し、Bell（あるいは Dery Telecom）
2012 年 8 月

カナダのフィルターが最適に稼働しなかったことにより、ピア接続しているインドの Tata をはじめとする事業者にそのまま配信され、Bell や Tata のインターネット接続に障害が発生。

7

オーストラリアの大手 ISP である Telstra とトランジット契約をしている
2012 年 2 月

オーストラリア

Dodo が、設定誤りにより Telstra への経路をインド経由する設定としてしまい、約 30 分インターネットに接続しづらい状況が発生。

8

チェコの ISP がルータのバグあるいは設定不良により、同じ AS 番号を多く連結された不適切な AS Path を配信したことにより、一部の処理能力の低いル2009 年 2 月

チェコータが機能停止。
これにより、一部の ISP において約 1 時間インターネットが接続できなくな
9った。（Long AS Path 事件）

２．誤送信された経路情報の受信防止及び不要な経路情報の送信防止
NTT コムによると、ネットワークの安定的な運用を目的に、通信装置において一定の経路情報をフィルタリングする仕組みや、リミッターにより一定以上の経路情報を受け取らないようにする仕組みを設定しているとのことであった。また、これらの設定は電気通信事業者の接続形態や設備の運用状況にもよるが、経路情報の受信防止又は送信防止の有効な手段になり得るとのことであった。
また、KDDI によると、法人向けインターネットゲートウェイサービスにおいて提供していたルータは、機種によって、大量の経路情報を受け取った場合に、処理が一部遅延する機種と遅延が生じない機種が存在し、本事象において影響が生じたのは前者のルータであったことから、必要に応じて後者への置換を行っているとのことであった。

6

出典：ZDNet Japan「米国全土でインターネットサービスの途絶が発生-BGP ルーティングテーブルの巨大化で」Aug15,2014
https://japan.zdnet.com/article/35052352/

7

出典：BGP MON“A BGP leak made in Canada” Aug8, 2012https://bgpmon.net/a-bgp-leak-made-in-canada/8

出典：BGP MON“How the Internet in Australia went down under” Feb27, 2012https://bgpmon.net/how-the-internet-in-australia-went-down-under/

9

出典：（独）情報処理推進機構 情報セキュリティ技術動向調査（2009 年上期）
https://www.ipa.go.jp/security/fy21/reports/tech1-tg/a_05.html

9３．障害に関する情報の電気通信事業者間での共有(1) 日常での情報交換
普段からやりとりのある電気通信事業者同士であれば、その問い合わせルートで問い合わせを行い、迅速に情報を得ることができる可能性がある。実際、本事象においては、普段から付き合いのある電気通信事業者に問い合わせを行ったところ、国内電気通信事業者間の経路が米国から一時的に流れてきたとの情報を得ることができたという話を聞いている。
また、NTT コムによれば、本事案ではないが、相互接続関係のある電気通信事業者であれば、契約に基づく運用の取り決めとして、自社で障害が発生した場合は相互接続先の窓口にその旨を通知するなど、情報交換を行っているとのことであった。
(2) 電子メールによる問い合わせ方法
IETF（Internet Engineering Task Force：インターネット技術の標準化を推進する任意団体）の標準化ドキュメントである RFC（Request For Comments）2142 において推奨されているネットワーク運用に関するメールアドレス（noc@xxxxx.com）を各事業者が保有し、問い合わせを行うことができるようになっている。
また、ピアリングに必要な情報を登録・公開しているウェブサイトである「PeeringDB」
において、事業者がピア接続に必要な AS10の情報やコンタクト先の情報を掲載することで、問い合わせを行うことができる。
(3) ネットワーク技術者間の情報共有
JANOG（JApan Network Operators’ Group：ジャノグ）は、インターネットにおける技術的事項及びそれにまつわるオペレーションに関する事項を議論、検討、紹介することにより、日本のインターネット技術者及び利用者に貢献することを目的としたグループであり、明らかな営業活動を目的とした参加を除き、参加者の制限はなく、ネットワーク技術者間の情報交換にも用いられており、日常のやりとりや面識がなくとも情報交換を行うことができる。
本事案においても、複数の電気通信事業者から、JANOG のメーリングリストを用いて情報交換が行われていたとのことであった。また、一部の電気通信事業者では、担当者が参加している NANOG（North American Network Operators Group）においても情報交換を行ったと

10

AS（Autonomous System）とは、ある経路制御方針によって運営されるネットワークのことをいう。
AS の識別は、各国のネットワークインフォメーションセンター（NIC)などが発行する AS 番号により行われる。

10

のことであった。
(4) ICT-ISAC の取組
一般社団法人 ICT-ISAC（以下「ICT-ISAC」という。）では、2005 年から、会員 ISP をはじめとする日本国内から提供される BGP 経路情報を元に、経路ハイジャック事象11によりインターネット運用に支障をきたす異常な経路情報の発生を検出する「経路奉行」を一般社団法人日本ネットワークインフォメーションセンター（JPNIC)と連携して運用している。
経路奉行は、会員 ISP から提供される BGP 経路情報とインターネットの経路情報データベースである IRR（Internet Routing Registry）に登録されている経路情報と比較して、AS が不一致の場合に、経路ハイジャック事象と判定し、アラームとしてメールで対象者12に通知するシステムである。
本事案においては、AS が一致していたため、アラームを通知しなかった。本事案のように、AS が一致する場合であっても、Prefix13が不一致の場合、経路の正当性は疑われるものの、経路ハイジャック事象とは限らないため、これをアラームの通知対象とすると、経路ハイジャック事象発生時と同量又はそれ以上のアラームが通知されることが予想され、重大な事象かどうかを判断することが難しくなる可能性があるといった課題があり、アラームの通知対象としていなかった。課題を解決しつつ、経路奉行の改善の検討を行っていく予定とのことであった。
なお、経路奉行では、流入する全ての経路情報をログとして記録していたため、本事案の対応にログを役立てることができたとのことであった。
(5) 総務省による電気通信事業者への情報共有の仕組みの構築
今回のヒアリングでは、電気通信事業者間の情報連携だけではなく、複数の電気通信事業者に発生するような事案については、総務省が電気通信事業者から報告を受け、集まった情報を選別して、電気通信事業者に共有するような仕組みを構築することも影響の度合いを把握する上では非常に参考になるとの意見があった。

11

本来の IP アドレス所有者ではない AS が、インターネット上に BGP で広告をすること。また、それに伴う通信不具合事象をいう。

12

ICT-ISAC によると、アラームの通知内容には生の経路情報など ISP のビジネスモデルに影響する機微な情報が含まれるため、送信先を限定しているとのことである。

13

事業者間で経路情報の交換を行う場合に、アドレス空間を指定するための情報

11

第３章

本事案から得られた教訓等

本事案の検証から得られた教訓について、「人為的ミスの未然防止」、「誤送信された経路情報の受信防止及び不要な経路情報の送信防止」、「障害に関する情報の電気通信事業者間での共有」及び「利用者周知」の観点で以下のとおり整理した。
１．人為的ミスの未然防止
経路情報の設定作業のみならず、様々な作業工程においても人為的ミスを完全に防ぐことはできない。
情報通信ネットワークの安全・信頼性対策の指標としての基準を定めた「情報通信ネットワーク安全・信頼性基準（昭和 62 年郵政省告示第 73 号。以下「安信基準」という。）」においては、「データ投入等における信頼性の高い作業能力を養うための教育・訓練を行うこと」等を定めている。
また、「平成 28 年度電気通信事故に関する検証報告」では、人為的ミスを防ぐには、担当者同士による二重のチェックや、第三者の目による複線的なチェックといったミスを誘発しない手順の策定とその遵守や、データの自動入力、入力データの自動処理、誤入力時のアラームの発出等、できるだけ人の手によらない仕組みの構築が指摘されている。
経路情報の設定においても、人為的ミスを防ぐための事前・事後のチェック体制の充実を図るとともに、万一誤設定してしまった場合でも、設定が反映される前に自動的に検証し、アラームなどで知らせるような仕組みが有効である。
２．誤送信された経路情報の受信防止及び不要な経路情報の送信防止
経路情報は、その到達性を確保するため、接続する事業者間であらかじめ送受信されているが、本障害のように、１者の誤設定により大量かつ詳細な経路情報が送信されてしまうと、他の事業者に甚大な影響を及ぼすことが想定される。
本障害では、インターネットの安定性を確保するため、一定の経路情報をルータにおいてフィルターする仕組みや、一定量以上の経路情報を受け取らないようリミッターを設定する仕組みがあり、このような設定は、経路情報の受信防止又は送信防止の有効な手段になり得るとの指摘がなされている。

12

この場合、ルータに設定する経路情報に関するフィルターは、経路情報の受信時及び配信時に機能するよう、複数のフィルターを設定する必要がある。
例えば、他の電気通信事業者から経路情報を受信する際は、Prefix フィルター14により、細かい経路情報を受信しないよう設定したり、AS-PATH フィルター15により、長い AS-PATH長の経路を受信しないよう設定したり、リミッターにより、設定した閾値以上の経路情報を受信しないよう設定したりする対応が考えられる。
また、経路情報を他の電気通信事業者等に配信する際は、Prefix フィルターにより、自らの AS 内部で使用している細かい経路情報をそのまま外部に配信しないようにする設定が考えられる。
現在、フィルターやリミッターの設定については、法令上は特に求めていないことから、電気通信事業者がそれぞれのネットワーク構成や運用の考え方に合わせて柔軟かつ適切に対応することを求めるため、例えば、安信基準にルータのフィルター設定について規定することが適当である。
３．障害に関する情報の電気通信事業者間での共有
インターネットにおける障害においては、まず、発生した事象が自社単独で起きている事象なのか、他の電気通信事業者でも同様に起きている事象なのかどうかを把握することが、対応策を検討する上で大変重要である。
本事案においては、複数の事業者において同様の事象が発生しているという状況を的確に把握することができなかったという事例が見受けられた。契約関係等がある電気通信事業者に状況確認を行ったり、JANOG のメーリングリストを用いて情報交換を行ったりしていたことを踏まえると、このような情報交換は、自社以外で発生している障害の状況を把握するには有効であると考えられる。また、ICT-ISAC の「経路奉行」についても、異常な経路情報が流入した場合においてアラートが通知されるものであり、電気通信事業者においては、これを利用することで発生している事象を把握することができるため、有効であると考えられる。
こうした情報共有の取り組みは、一定程度なされているが、発生している事象を迅速かつ14Prefix 長の情報を基にフィルタリングを行うフィルターをいう。

15

宛先に到達するまでに経由した AS のリストを AS-PATH といい、この AS-PATH を基にフィルタリングを行うフィルターをいう。

13

的確に把握し、早期に対応策を実施するとともに、できるだけ早い段階で利用者に周知できるようにする観点から、より緊密に事業者間で連携した情報共有体制を整えることが適当であると考えられる。
また、総務省が情報共有の結節点となることも有効であるとの指摘もある。電気通信事業者間の連携体制と総務省が連携することで、より効果的な情報共有と的確な対応策の検討が可能となると考えられる。このことは、サイバー攻撃によるインターネットの障害が発生した場合も同様である。さらに、海外で発生した事象においては、海外事業者に対して問い合わせを行う必要が生じる場合もある。その場合は、電気通信事業者からの問い合わせと並行して、総務省が海外事業者に問い合わせを行うことにより、円滑に回答が得られる可能性もある。
現在、電気通信事業者に対して、電気通信事業法（昭和 59 年法律第 86 号）及び関係省令に規定する電気通信事故報告制度により、重大な事故が発生した場合は、その旨をその理由又は原因とともに、速やかに報告することを求めているが、本障害は、電気通信事業法、関係省令及び関係ガイドラインにより、電気通信事業法上の重大事故には該当しなかった16ことから、本障害発生時、電気通信事業法上の事故として、総務省への報告はなされていな
い。
このような状況を踏まえると、総務省が本障害のような事象を迅速かつ的確に把握し、情報共有の結節点となるためには、これまで報告対象となっていなかったインターネットの障害についても報告対象とするなど、総務省への報告の在り方を含め、障害に関する情報共有体制の整備を行うことが適当である。
４．利用者周知
本事案については、電気通信事業者において正確な情報を把握できなかったことから、原因の特定が困難であり、利用者からの問い合わせにおいても適切な回答をすることができず、とりわけ、法人利用者は、当該法人で擁する顧客に対し、迅速な説明を行うことができなかった。
この点、原因が特定できていない段階でも、まずは利用者へ何らかの情報提供を行うことは重要である。
「平成 27 年度電気通信事故に関する検証報告」においても、事故の発生時点で原因や故障設備の特定ができなければ、その旨を周知しておけばよい、との指摘を行って

16

ベストエフォートサービスにおいては、停止がない限りは品質の低下と判断していないことから、総務省は、本事案については電気通信事業法上の事故には該当しないと判断している。

14

おり、同様であるといえる。
また、電気通信事業者が、法人利用者において、当該法人が擁する顧客への周知を迅速に行うことができるような取り組みを進めていくことも重要である。法人利用者に対して、法人専用の支援サイトにより、障害発生の可能性が生じた場合に速やかに障害情報の掲載を行い、メール等による能動的な連絡を行うといった取り組みも、法人利用者が擁する顧客に向けての説明を円滑に行うためには有効である。
なお、法人利用者にあっては、電気通信事業者から提供を受けているインターネット接続サービスが、自社のサービスにとって十分なスペックを備えているか、障害発生時におけるサービスへの影響や情報提供の仕組みや、SLA（Service Level Agreement：サービス品質保証）が契約に含まれているかについても、契約時等において確認をしておくことが重要である。また、電気通信事業者においても、SLA を締結しているか否かにかかわらず、法人利用者にも丁寧なサポート体制の充実を図ることが重要である。
いずれにしても、障害発生後、できるだけ速やかに情報を収集し、原因を特定したうえで、利用者に迅速かつ的確に周知をすることは大変重要である。インターネットは、社会を支えるインフラとしてその役割が重要なものになってきており、一旦サービスが止まってしまうと、社会経済活動に大きな影響を及ぼすこととなる。複数の電気通信事業者に影響のある
インターネット障害への対応においては、電気通信事業法第１条の目的に定められている「利用者の利益の保護」の趣旨を踏まえ、利用者への周知の観点からも、電気通信事業者間の連携、そして、電気通信事業者間と総務省の連携強化により、障害への対応とともに迅速な情報収集ができる体制を整備することが必要であると考えられる。

15