サーバーサイドの案件でオンコールの当番に入ると、多くの意識は復旧までの時間に向かいます。けれども、復旧した後に何を残し、誰にどう伝えるのかという段取りは、案件に入ってから初めて知ることが少なくありません。総務省が公表しているガイドラインには、電気通信事業者に発生した事故について、報告する基準と項目、期限が明文で示されています。この記事では、その明文を手がかりに、参画前に確かめておきたい記録と段取りの逆算の仕方を整理します。

1. 復旧したら終わり、ではない領域がある

ガイドラインが対象にしているのは、登録・届出をした事業者

サーバーサイドの案件で障害対応を経験してきたエンジニアなら、復旧した瞬間に肩の力が抜ける感覚をよく知っているはずです。しかし総務省が公表しているガイドラインを見ると、電気通信事業者において発生した事故、または事故が生ずるおそれがあると認められる事態のうち、電気通信事故に係るものを対象にしていると示されています¹。復旧はゴールではなく、報告という次の工程の入口にすぎない場面があることが、ここから見えてきます。

ここで押さえておきたいのは、この対象が「事故が起きたすべてのWebサービス」ではないという点です。ガイドラインが指しているのは、あくまで電気通信事業者において発生した事故という枠であり、案件によって当てはまる場合とそうでない場合があります。復旧作業そのものの技術は共通していても、その後に何を求められるかは案件の性質次第で変わってきます。

この「事故が生ずるおそれがあると認められる事態」という書きぶりにも意味があります。実際に利用者への影響が固まる前の段階も、対象として意識されているということです¹。復旧の最中でまだ数字が読めない場面でも、この対象の枠を頭に置いておくと、落ち着いて次の動きを考えやすくなります。

自分の案件が当てはまるかどうかは、確認する事項になる

では、この対象に当てはまる事業者とはどのような者でしょうか。ガイドラインは、電気通信事業者について、電気通信事業法第9条の規定による登録を受けた者、および同法第16条第1項の規定による届出をした者をいうと示しています²。登録や届出という手続きを経た事業者に限られているという点が、ここでの線引きです。すべての事業者が対象になるわけではないことが、この定義から分かります。

つまり、サーバーサイドの案件に参画するときに、自分が関わるサービスがこの対象に当てはまるかどうかは、こちらで断定できることではなく、クライアントや案件の担当者に確認する事項になります。対象に含まれる案件もあれば、含まれない案件もあり、その判断は事業者側の登録・届出の状況によって決まるためです。

下の図は、この対象になる範囲を整理したものです。

図の作成：Remogu編集部。電気通信事業者において発生した事故に関するガイドラインの適用範囲を整理したもので、統計データではありません

2. 線は「人数」と「時間」の二本で引かれている

利用者の数で引かれる線

障害の大きさをどう伝えるかは、報告する立場によって感覚がばらつきやすいところです。ガイドラインはそこに、重大な事故の基準として、電気通信役務の提供の停止または品質の低下を受けた利用者の数が3万以上のものを挙げています³。感覚ではなく、まず人数という一本の線で切り分ける形になっています。この線引きを知っておくと、障害の規模を人に説明するときの言葉が変わってきます。

この基準を知っておくと、障害の規模を振り返るときに「どれくらいの人数に影響したか」を最初に確認する習慣がつきます。サーバーサイドの実装や運用に関わってきた経験があるほど、影響範囲を人数で捉える視点は、次の案件でも活きる整理の仕方になります。

時間の長さで引かれるもう一本の線

人数だけでなく、時間の長さでも線が引かれています。ガイドラインは、電気通信役務の提供の停止時間または品質の低下を受けた時間が2時間以上のものも、重大な事故の基準として挙げています⁴。人数か時間か、どちらか一方が満たされれば線を越える形です。二つの基準がそれぞれ独立して機能している点が、ここでの特徴です。

影響した人数だけを見るよりも、影響が続いた時間まで合わせて振り返るほうが、障害の大きさを立体的に説明できます。復旧までの時間を記録する習慣は、技術的な対応力だけでなく、報告の場面でも役に立つ経験になります。時間の記録は、後から振り返るときの説得力にもつながります。

人数と時間、この二本の線が示しているのは、感覚での重大さの判断ではなく、数で判定する考え方です。自分が担当してきた障害対応を振り返るときも、「大変だった」という印象だけでなく、人数と時間という二つの物差しに置き換えて整理しておくと、案件が変わっても通用する形になります。この整理の仕方は、次に見る記録の項目にもつながっていきます。

自分の案件に当てはめて考える観点

ここまでの二本の線を、実際の案件に当てはめて考える観点を整理しておきます。対象になるかどうかや基準への該当は事業者側の判断領域ですが、サーバーサイドの担当者として振り返っておきたい観点は共通しています。下の表は、参画前や参画中に確認しておきたい項目をまとめたものです。自分の案件と照らし合わせながら読んでみてください。

観点	確認しておきたいこと
影響利用者数の基準	3万以上という基準が案件にどう関わるかは事業者側の判断領域であり、担当者に確認する事項
停止・品質低下の時間	2時間以上という基準に照らして、時間をどう記録し誰が測るかを確認する事項
自分の役務の位置づけ	担当するサーバーサイドの機能が、報告の対象になる役務に含まれるかどうか
記録の粒度	発生時刻や影響範囲を後から追える単位で、ログや記録が残る仕組みになっているか

表に挙げた観点は、どれも「自分で断定すること」ではなく「確認する事項」としてまとめてあります。対象になるかどうかの判断は事業者側にありますが、確認する材料を自分から持っておく姿勢は、参画初期の信頼にもつながります。次の章では、この確認した内容をもとに、実際に何を報告するのかを見ていきます。

3. 報告する項目から、記録の項目を逆算する

第一報に並ぶ項目

対象になる事故が起きたとき、何を報告するのかも明文で示されています。ガイドラインは第一報として、発生日時、発生場所、影響を与えた電気通信役務の内容、影響を与えた範囲、影響利用者数、発生原因、措置模様、利用者からの申告状況その他参考となる事項を速やかに報告すると示しています⁵。項目が具体的に列挙されている点が特徴です。

この列挙を読むと、報告のときに慌てて思い出そうとする項目が見えてきます。発生日時や発生場所は復旧の最中に記録しやすい一方、発生原因や措置模様は、対応の過程を振り返りながら言葉にしていく項目です。項目ごとに、記録のしやすさが違うことが分かります。

サーバーサイドの実装や運用に関わってきた経験がある担当者ほど、この列挙を「後から埋める書類」ではなく「先に用意しておく型」として読み替えられます。次に見ていくのは、その型をどう平常時に落とし込むかという話です。項目を知っているだけでは、いざというときに使える記録にはなりません。

後から集められない項目を、平常時のうちに残す

第一報の項目の中には、発生から時間が経つほど再現しにくいものがあります。たとえば発生に気づいた正確な時刻や、そのとき見えていた症状は、記憶だけに頼ると曖昧になりやすい項目です。平常時からログや記録の残し方を決めておくと、この曖昧さを減らせます。何を、どこに、どんな形で残すかを、あらかじめ決めておく価値があります。

復旧してからまとめて記録を書き起こすよりも、対応の最中に断片的にでもメモを残しておくほうが、第一報の項目を後から埋めやすくなります。完璧な記録を目指すよりも、項目に沿って断片を残す習慣のほうが、実際の場面では機能します。断片であっても、後から並べ直せば十分に使える記録になります。

項目から記録を逆算する考え方が整理できたところで、次はその報告をいつ、どの順番で行うのかを見ていきます。項目が分かっていても、タイミングを誤ると意味が薄れてしまうためです。下の図は、第一報の項目と平常時に残す記録の対応関係を整理したものです。

図の作成：Remogu編集部。第一報の項目を手がかりに、平常時に残しておきたい記録を整理したもので、統計データではありません

4. 確定を待たずに動く順番

分からないうちに、一報を入れる

報告のタイミングについても、明文の示し方が参考になります。ガイドラインは、事故発生直後で影響利用者数や継続時間が不明であっても、重大な事故となる可能性がある場合には速やかに報告すると示しています⁷。数字が固まるのを待たない、という順番です。この順番を知っておくと、発生直後の動き方に迷いが減ります。

この順番は、障害対応の現場感覚とも合っています。発生直後は、影響がどこまで広がるか読み切れないことが多く、そこで数字が出そろうのを待っていると、報告そのものが遅れてしまいます。分からないなりに一報を入れる、という動き方が求められています。

サーバーサイドのオンコール対応に慣れてきた担当者ほど、この「分からないうちに動く」順番に違和感を持たないはずです。復旧の初動と、報告の初動は、実は似た形をしています。どちらも、情報が出そろうのを待たずにまず動くという点で共通しています。

詳細は事故発生日から30日以内に

一報の後には、詳細の報告が続きます。ガイドラインは、詳細については、事故発生日から30日以内に定められた様式により報告すると示しています⁶。速やかな一報と、期限のある詳細報告という、二段構えの形です。この二段構えを知っておくだけで、復旧後の動き方の見通しが立ちやすくなります。

この二段構えを知っておくと、復旧直後にすべてを完璧に記録しようと気負う必要がないことも見えてきます。

時間軸で並べる対応

ここまでの順番を、時間軸に沿って並べ直しておきます。発生直後、復旧後、そして事故発生日から30日以内という三つの段階で、それぞれ何をするのかを整理すると、オンコールの当番に入るときの心づもりがしやすくなります。下の表に、この三段階をまとめました。

段階	対応
発生直後（不明点が多い時点）	影響利用者数や継続時間が確定していなくても、重大な事故となる可能性があれば速やかに一報を入れる
復旧後	発生原因や措置模様など、第一報で並ぶ項目を整理し直す
事故発生日から30日以内	詳細を定められた様式で報告する期限に間に合わせる

下の図は、この一報と詳細の関係を時間の流れで示したものです。

出典：総務省「電気通信事故等に係る電気通信事業法関係法令の適用に関するガイドライン」（2026年4月1日）をもとに作成

5.「落ちていない」も数で見る

トラヒック処理量が50%以上減った状態を、品質の低下とする例がある

完全には停止していなくても、品質が下がっている状態をどう判定するのかも、明文で示されています。ガイドラインは、一部のサービスについて、故障が発生した電気通信設備におけるトラヒック処理量が平常時よりも50%以上減少した状態を「品質の低下」とすると示しています⁸。落ちていないように見えても、数で判定される場面があるということです。

ここで押さえておきたいのは、この基準が「一部のサービス」についてのものだという点です。すべてのサービスに一律に当てはまる基準ではなく、対象になるかどうかは、ここでも案件ごとの確認事項になります。感覚で「動いているから大丈夫」と判断するよりも、平常時との比較で見る視点があることを知っておくと、振り返りの解像度が上がります。この視点は、次の記録の話にもつながっていきます。

平常時の記録がなければ、比べる基準がない

50%以上の減少という基準は、平常時の数値があって初めて意味を持ちます。平常時のトラヒック処理量を記録していなければ、そもそも何を基準に「減少した」と言えるのかが分からなくなってしまいます。比べる相手がなければ、判定そのものが成り立ちません。

落ちてから慌てて過去のログを探すよりも、平常時の値を普段から見える形にしておくほうが、比較そのものがすぐにできます。サーバーサイドの運用に関わってきた経験があるなら、平常時の記録を残す習慣そのものが、次の案件での信頼につながります。普段の記録が、いざというときの判断材料になります。

この章まで見てきた人数・時間・処理量という三つの物差しは、どれも「感覚ではなく数で見る」という一本の考え方でつながっています。障害対応の経験を振り返るときも、この三つを手がかりにすると、整理がしやすくなります。

サーバーサイドの経験を4つの層で書き出す

最後に、ここまでの内容を自分の経験に落とし込むための整理の仕方を示します。検知・初動・記録・振り返りという4つの層に分けて書き出すと、障害対応の経験を、次の案件で伝えやすい言葉に整えられます。下の表を使って、実際に書き出してみてください。

層	振り返る内容
検知	平常時の値との差にどう気づいたか、何を見て変化に気づいたか
初動	確定前に何をどこまで伝え、誰に一報を入れたか
記録	発生日時や影響範囲など、後から使える形で残したものは何か
振り返り	復旧後にどんな整理をし、次にどう活かしたか

この4つの層で書き出した経験は、そのまま次の案件で語れる材料になります。数で見る視点を持って障害対応に関わってきたことは、サーバーサイドの案件で信頼を積み上げる土台になります。

出典：総務省「電気通信事故等に係る電気通信事業法関係法令の適用に関するガイドライン」（2026年4月1日）をもとに作成（対象は一部のサービス）

6. まとめ

サーバーサイドの案件における障害対応は、復旧した瞬間に終わるものではありません。総務省のガイドラインが示す人数・時間・処理量という数の基準と、報告の項目・期限という明文は、報告の対象になるかどうかにかかわらず、記録の設計を逆算するための手がかりになります。

この記事で見てきた対象の範囲は、登録・届出をした電気通信事業者に発生した事故に関するものです。自分が担当する案件がこの対象に当てはまるかどうかは、こちらで断定せず、クライアントや案件の担当者に確認する事項として扱うことが大切です。

人数・時間・処理量という数で振り返る習慣、そして検知・初動・記録・振り返りという4つの層で経験を言葉にする型を持っていることは、次の案件を選ぶときの材料にもなります。Remoguはリモートワーク案件に特化したエンジニアマッチングで、案件の90%以上がフルリモート可能です⁹。積み上げてきた障害対応の経験を、場所に縛られない働き方の中で活かす道を探すことができます。

まずは、これまで担当してきた復旧対応を、発生日時・影響範囲・対応の順番という言葉で書き出してみましょう。その整理は、次の案件を確かめる会員登録の一歩を、より具体的なものにしてくれます。

7. よくある質問

自分の案件がこの制度の対象かどうかは誰に聞くのか

対象になるかどうかは、登録・届出をした電気通信事業者に発生した事故という枠に基づいて判断されるため、自分だけで断定できることではありません²。クライアントや案件の担当者、事業者側の窓口に確認するのが、まず取れる行動になります。

対象でない案件では関係ないのか

対象に当てはまらない案件であっても、人数・時間・処理量という数で障害の大きさを捉える考え方や、第一報の項目から記録を逆算する型は、そのまま振り返りに使えます。制度の対象かどうかにかかわらず、記録の設計として参考になります。

障害の責任はどこにあるのか

責任の所在は契約の内容や案件ごとの取り決めによって決まるものであり、この記事で断定できることではありません。ここで整理しているのは、あくまで記録と報告の形についてです。責任の範囲については、クライアントと事前にすり合わせておく事項になります。

オンコールの当番に入るときに確かめることは何か

当番に入る前に、担当する案件がガイドラインの対象に当てはまるかどうか、第一報として何を報告する想定になっているか⁵、誰に連絡するか、そして平常時の値をどこで確認できるかを、クライアントや案件の担当者に確認しておくと、発生直後に迷いが減ります。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 総務省「電気通信事故等に係る電気通信事業法関係法令の適用に関するガイドライン」Ⅱ 対象範囲（第9版）（2026年4月1日）
＊2 総務省「電気通信事故等に係る電気通信事業法関係法令の適用に関するガイドライン」Ⅱ 対象範囲（2026年4月1日）
＊3 総務省「電気通信事故等に係る電気通信事業法関係法令の適用に関するガイドライン」重大な事故の報告基準（2026年4月1日）
＊4 総務省「電気通信事故等に係る電気通信事業法関係法令の適用に関するガイドライン」重大な事故の報告基準（2026年4月1日）
＊5 総務省「電気通信事故等に係る電気通信事業法関係法令の適用に関するガイドライン」重大な事故の報告（第一報）（2026年4月1日）
＊6 総務省「電気通信事故等に係る電気通信事業法関係法令の適用に関するガイドライン」重大な事故の報告（詳細報告）（2026年4月1日）
＊7 総務省「電気通信事故等に係る電気通信事業法関係法令の適用に関するガイドライン」重大な事故の報告（注記）（2026年4月1日）
＊8 総務省「電気通信事故等に係る電気通信事業法関係法令の適用に関するガイドライン」品質の低下の判定（第二号基礎的電気通信役務・携帯電話等）（2026年4月1日）
＊9 Remoguサイト公開情報（フルリモート可能案件の割合）