はじめに
インターネットに接続できないとき、最初に疑うのは通信回線でしょうか。それともDNSやネットワーク機器でしょうか。
利用者から「つながらない」「つながりづらい」という報告があっても、それだけでは通信経路が完全に停止しているのか、一部の通信だけが失敗しているのか判断できません。さらに、複数の地域やサービスで同時に障害が発生している場合、利用者からは見えない共通基盤に原因が存在する可能性もあります。
2026年9月23日、J:COMのインターネット接続サービスなどで広域の通信障害が発生しました。J:COMは障害の発生と復旧を公表していますが、本稿執筆時点で、公開情報だけから具体的な事故原因を特定することはできません。1
そこで本稿では、この障害を題材として、外部へ公開されている情報だけを材料に「ネットワーク障害をどこまで切り分けられるか」を考えてみます。DNS、共通ネットワーク基盤、加入者認証、SSO、設定変更、DNSキャッシュなどを候補として、観測された事象との整合性を順番に確認します。
なお、本稿はJ:COMの事故原因を独自に断定するものではありません。企業内部のネットワーク構成、ログ、設定変更履歴などにはアクセスできないため、実際の原因についてはJ:COMおよび関係事業者による公式発表を正とします。
本稿で扱う「設定ミス」「DNS障害」「機器故障」などは、公開情報から技術的に成立し得るシナリオを検討するための仮説です。特定の企業や担当者に過失があったことを示すものではありません。
1. まずは原因を考えず、観測された事象を並べる
障害調査では、いきなり原因を決めに行くと判断を誤りやすくなります。最初にやるべきなのは、「何が起きたか」と「どこまで確認できているか」を分離することです。
1.1 公開情報から確認できること
今回の障害について、J:COMや関係事業者の公開情報から確認できる内容を整理すると、概ね次のようになります。
| 観測項目 | 公開情報から確認できる内容 | 切り分けの着眼点 |
|---|---|---|
| 障害発生 | 2026年9月23日8時55分頃 | 共通して影響した設備やサービスは何か |
| 復旧 | 同日18時頃に復旧、20時に全サービスの復旧を確認 | 復旧操作とサービス回復の時間差 |
| 影響範囲 | 全国の一部地域 | 特定地域のアクセス設備だけで説明できるか |
| 関連事業者 | J:COMのネットワークを利用する他のケーブルテレビ事業者にも影響 | 複数事業者が依存する共通部分の存在 |
| 影響サービス | インターネット接続のほか、一部の関連サービスにも影響 | L3通信だけか、上位サービスまで含むのか |
| 復旧順序 | 一部事業者ではインターネット接続復旧後もメールなどに影響 | サービスごとに依存先が異なる可能性 |
J:COMの障害発生・復旧状況については公式の障害情報を基準とします。1
また、一部のケーブルテレビ事業者では、インターネット接続が暫定復旧した後も、メール送受信や関連サービスへの影響が継続したことが公表されています。2
これは切り分け上、かなり重要な情報です。
単純に一本の回線が切れただけなら、その回線を使用するサービスは概ね同時に停止し、同時に復旧することが想定されます。しかし、実際にはサービスによって復旧時刻に差があります。
ここから「障害箇所が複数あった」と断定することはできませんが、少なくとも、一般的なインターネット接続とメールなどのサービスが、完全に同一の依存関係ではなかった可能性を考える材料になります。
1.2 関連事業者も影響したという意味
J:COMは、ケーブルテレビ事業者向けに「ケーブルインターネットZAQ」を提供しています。公式資料では、ISPサービスについて、DNS、DHCP、上位回線、プロビジョニングなどを含む機能を事業者向けに提供できることが示されています。3
ISPはInternet Service Providerの略で、利用者をインターネットへ接続するためのサービスを提供する事業者です。
つまり、契約先のケーブルテレビ会社が異なっていても、その先にあるインターネット接続機能の一部を共通の事業者から提供されている構成は成立します。
概念的には、次のような構造です。
利用者A ─ ケーブルテレビ会社A ─┐
│
利用者B ─ ケーブルテレビ会社B ─┼─ 共通ISP基盤 ─ インターネット
│
利用者C ─ ケーブルテレビ会社C ─┘
この場合、各地域のアクセス回線がそれぞれ同時に故障しなくても、共通ISP基盤側に問題が起きれば複数の事業者へ影響が波及します。
ただし、今回影響を受けた各事業者が、実際にどの設備、DNS、DHCP、上位回線を共用していたのかまでは公開情報から確認できません。
したがって、「共通ISP基盤に原因があった」と断定するのではなく、「複数事業者への同時影響を説明する候補として、共通基盤を調査対象に置ける」と考えるのが適切です。
1.3 DNSを変更すると改善したという利用者報告
今回の障害では、利用者がDNSをGoogle Public DNSなどへ変更すると、一時的に通信できるようになったという報告も紹介されています。4
DNSはDomain Name Systemの略で、example.comのような名前を、通信に使用するIPアドレスへ変換する仕組みです。
Webブラウザーから見れば、概ね次のような順番で通信します。
example.com にアクセス
↓
DNSでIPアドレスを問い合わせる
↓
203.0.113.10 などのIPアドレスを取得
↓
そのIPアドレスへ通信
DNSに問題があれば、通信回線そのものが生きていても、利用者からは「インターネットにつながらない」ように見える場合があります。
そのため、DNS変更で改善したという報告は有力な手掛かりです。
しかし、これも事故原因を直接示す証拠ではありません。
DNSサーバー自体に障害があった可能性もあれば、DNSサーバーまでの通信経路に問題があった可能性もあります。あるいは、一部の利用者だけに成立した事象かもしれません。
利用者報告は「仮説を作る材料」であり、「原因を確定する証拠」とは分けて扱う必要があります。
2. DNS、ネットワーク、認証のどこを疑うか
ここからは、公開情報から成立する障害仮説を並べます。
大切なのは、一つの仮説に早い段階で固定しないことです。それぞれについて、「説明できる事象」と「追加条件が必要な事象」を見ます。
2.1 DNS基盤の異常
まず考えやすいのがDNSです。
仮に、J:COMまたは関連するISP基盤で使用しているDNSリゾルバーが正常に応答できなくなった場合、利用者はドメイン名からIPアドレスを取得できなくなります。
利用者
│
├─ J:COM側DNS ── × 名前解決失敗
│
└─ 外部DNS ───── ○ 名前解決成功
この構成であれば、外部DNSへ変更すると通信できるという観測を説明できます。
一方で、DNSだけの障害では、すべての影響サービスを説明できない可能性があります。
例えば、IPアドレスを直接指定した通信まで失敗していたのであれば、DNSより下位の通信経路も疑う必要があります。
2.2 DNSサーバーではなく、DNSまでの通信経路
「DNSで問題が起きている」ことと、「DNSサーバーが壊れている」ことは同じではありません。
例えば、ルーティングやファイアウォール設定に問題があり、特定のDNSサーバー宛ての通信だけが届かなくなっていた場合でも、利用者から見ればDNS障害に見えます。
利用者
│
├─ 通常DNSへの経路 ── ×
│
└─ 外部DNSへの経路 ── ○
この場合、DNSサーバーそのものは正常です。
したがって、「外部DNSへ変えたら直った」という情報から分かるのは、DNS周辺を重点的に疑えるというところまでです。
DNSサーバー、ルーティング、ACL、ファイアウォール、ロードバランサーなど、複数の候補が残ります。
2.3 冗長構成の一部だけが正常に動作しないケース
ネットワーク設備では、可用性を高めるために複数台構成を取ることがあります。
しかし、冗長化されているからといって、障害時に必ず完全停止か完全正常の二択になるとは限りません。
例えば、3台で通信を処理していたとします。
┌─ 設備A ○
利用者 ─ LB ──┼─ 設備B ×
└─ 設備C ○
設備Bだけが異常になっても、ロードバランサーのヘルスチェック上は正常と判定され続ければ、一部の通信だけが設備Bへ送られ続けることがあります。
利用者側では、「つながるときとつながらないときがある」「サイトによって違う」という症状になる可能性があります。
ただし、今回そのような冗長構成が存在したことや、一部設備だけが故障したことを示す公開情報はありません。
あくまで「つながりづらい」という症状を説明できる一般的な故障パターンです。
2.4 セッションや通信資源の不足
もう一つ考えられるのが、セッション数やNAT資源などの不足です。
例えば、ファイアウォール、CGNAT、BNGなどでは、多数の通信状態を管理します。
設備の一部が停止し、残った設備に通信が集中した場合、処理できるセッション数の上限に達する可能性があります。
通常時
A 30%
B 30%
C 30%
B故障後
A 50%+
C 50%+
容量に十分な余裕がなければ、新規通信だけが失敗することも考えられます。
この場合、すでに確立している通信は継続する一方、新しいWebアクセスなどが失敗する、といった症状も成立します。
ただし、今回の障害でセッション数やNATポートが枯渇したことを示す公開情報はありません。
2.5 DHCPや加入者認証
J:COMのISPサービスにはDHCPなどの機能も含まれます。3
DHCPは、利用者の機器へIPアドレスやDNSサーバーなどの設定を自動配布する仕組みです。
例えば、誤ったDNSサーバー情報がDHCPから配布された場合、新しい設定を取得した利用者から影響が発生する可能性があります。
DHCP
↓
IPアドレス
デフォルトゲートウェイ
DNSサーバー
↓
利用者端末
また、加入者認証やプロビジョニングに問題が発生すると、再接続した利用者だけが通信できなくなるケースも考えられます。
ただし、今回DHCPや加入者認証に問題があったという情報は確認できていません。
2.6 SSOや認証基盤は原因になり得るか
J:COMでは、パーソナルIDなど、ログインを必要とするサービスにも影響が報告されています。
ここからSSOや認証基盤を疑うこともできます。
SSOはSingle Sign-Onの略で、一度の認証によって複数のサービスを利用する仕組みです。
ただし、SSOが停止しただけなら、通常は一般のインターネット通信まで停止しません。
インターネット通信 ── ○
Webサービス
↓
SSO
↓
×
そのため、SSO障害だけですべての事象を説明するのは難しくなります。
逆に、DNSや共通ネットワークに問題があり、認証サーバーへ接続できなくなったのであれば、インターネット障害と認証障害を同じ原因から説明できます。
┌─ DNS
│
共通NW障害 ──┼─ 認証
│
└─ 各種サービス
Microsoft Entra IDやEntra Connectのような仕組みを例として想像することもできますが、今回J:COMがこれらを使用していたことを示す情報は確認できていません。
製品名まで推定するのではなく、「共通認証基盤への到達性」という抽象度で考える方が安全です。
3. 設定ミスとDNSキャッシュという仮説を考える
ここからは一段踏み込み、「設定変更を起点とした事故だったらどう見えるか」を考えてみます。
繰り返しますが、これは今回の事故原因を示すものではなく、公開された事象を説明できる仮想シナリオです。
3.1 共通基盤に誤った設定を反映した場合
例えば、共通DNS基盤の設定を変更した際、意図しない設定が反映されたと仮定します。
対象はDNSレコードそのものかもしれませんし、DNSリゾルバーの転送先、ACL、ルーティングなどかもしれません。
正常な設定
↓
設定変更
↓
一部通信で異常
↓
ロールバックまたは修正
共通基盤であれば、その設定変更が複数地域や複数事業者へ同時に影響する可能性があります。
また、複数台の設備があっても、同じ設定管理システムから同一設定を一括配布している場合、物理的に冗長化されていても論理的には同時障害となり得ます。
これはネットワーク設計でよく問題になる「共通障害点」です。
冗長化とは台数を増やすことだけではなく、障害原因まで分離できているかを見る必要があります。
3.2 DNSレコードならTTLによる時間差が生まれる
設定変更がDNSレコードに関係する場合、TTLが重要になります。
TTLはTime To Liveの略で、DNSの問い合わせ結果をキャッシュとして保持できる期間です。5
例えば、正しいDNSレコードが次の状態だったとします。
service.example.jp
↓
192.0.2.10
TTL 3600秒
ここで誤った値が設定されたと仮定します。
service.example.jp
↓
192.0.2.99
利用者全員が同じ瞬間に新しい値へ切り替わるわけではありません。
正常なレコードをキャッシュしている利用者は、TTLが切れるまで以前の正常な宛先へ接続できます。
一方、キャッシュが切れた利用者は権威DNSへ問い合わせ直し、誤ったレコードを取得する可能性があります。
その後、設定が修正された場合は逆の現象が起こります。
| 状態 | 起こり得る現象 |
|---|---|
| 正常な情報をキャッシュ中 | 誤設定後もしばらく正常に通信できる |
| 正常キャッシュが失効 | 誤設定された情報を取得し障害が発生する |
| 誤った情報をキャッシュ中 | 設定修正後も障害が残る |
| 誤ったキャッシュが失効 | 正常な情報を再取得し復旧する |
つまり、同じ事故でも利用者によって「障害になった時刻」や「復旧した時刻」が異なる可能性があります。
3.3 「TTLが長い方が障害になりにくい」と「復旧が遅い」は両立する
DNS障害を考える際に少しややこしいのがここです。
TTLが長ければ、正常なキャッシュを持っている間は誤設定の影響を受けにくくなります。
一方、一度誤った値をキャッシュしてしまうと、その誤った情報も長時間残る可能性があります。
つまり、TTLが長いことには二面性があります。
正常キャッシュ × 長TTL
→ 障害を回避できる時間が長い
誤キャッシュ × 長TTL
→ 復旧後も影響が残りやすい
したがって、「TTLが長かったから影響しなかった利用者」と「TTLが長かったから復旧が遅れた利用者」が同時に存在しても、仕組みとしては矛盾しません。
ただし、今回の障害に関係する実際のDNSレコードやTTLは公開情報から確認できていません。
3.4 インターネットとメールで復旧時刻が違う理由
一部事業者では、一般のインターネット接続が暫定復旧した後も、メールなどのサービスに影響が残りました。2
ここから、一般通信とメールで異なるDNSや通信経路を利用していた可能性も考えられます。
例えば、利用者がWebへ接続するときとメールサーバーへ接続するときでは、名前解決するホスト名が違います。
メールの場合には、さらにサーバー間配送でMXレコードなども利用します。
| DNS利用箇所 | 主な役割 |
|---|---|
| Webアクセス | WebサーバーのA・AAAAレコードを参照 |
| メールソフト | メールサーバーのA・AAAAやCNAMEなどを参照 |
| メール配送 | MXレコードから配送先メールサーバーを特定 |
| サービス内部 | 認証や外部APIなど別ホストを名前解決 |
そのため、同じDNSシステムを利用していたとしても、参照するレコードやキャッシュ状態が違えば、サービスごとに影響時間が異なる可能性があります。
逆に、メールサービス側だけ別のDNSリゾルバーや通信基盤を使用している構成も成立します。
ただし、今回実際にどのようなDNS構成だったのかは確認できません。
また、メールサーバー自体の障害や、メール配送キューの滞留などでも復旧時間差は発生します。
したがって、「メールの復旧が遅い＝TTLが原因」と短絡しないことが重要です。
3.5 約9時間の障害はTTLだけでは説明しにくい
今回の障害は、発生から復旧まで約9時間に及んでいます。1
仮に誤ったDNSレコードを投入し、数分後に正常値へ戻しただけなら、短いTTLのレコードについては、キャッシュだけで9時間もの障害を説明するのは難しくなります。
可能性としては、例えば次のような条件が必要になります。
- 誤設定そのものが長時間残っていた
- 誤った情報に長いTTLが設定されていた
- 複数のDNSやサービスに異なる設定が存在した
- DNS以外の共通ネットワーク設備にも問題が残っていた
- 一般通信を暫定迂回させた後も個別サービスの復旧作業が継続していた
ここから分かるのは、DNS説そのものを否定できるわけではないものの、TTLだけですべてを説明しようとすると無理が出るということです。
仮説は、説明できない事象が出てきたら広げる必要があります。
4. 公開情報だけでどこまで切り分けられるか
内部のネットワーク担当者であれば、DNSログ、ルーティングテーブル、ファイアウォールログ、設定変更履歴などを確認できます。
しかし、外部から確認できるのは公開情報と利用者の観測程度です。
そこで重要になるのが、「事実」「観測」「仮説」を混ぜないことです。
4.1 情報を3段階に分ける
今回の情報を分類すると次のようになります。
| 区分 | 例 | 扱い |
|---|---|---|
| 事実 | J:COMが障害を公表した | 公式発表を根拠に記載 |
| 観測 | DNSを変更すると改善したという利用者報告 | 原因候補を考える手掛かり |
| 仮説 | 共通DNS基盤の設定異常だった可能性 | 技術的な成立条件として検討 |
この3つを混ぜると、「DNSを変えたら直った人がいる」から「J:COMがDNS設定を間違えた」という飛躍が起きます。
正しくは、
外部DNSで改善した報告がある
↓
DNS周辺を疑う材料になる
↓
DNSサーバー自体か、経路か、設定かは不明
↓
別の観測と照合する
という順番です。
4.2 今回の事象から作れる障害モデル
公開情報だけから、今回の障害を一つのモデルとして表現するなら、次のようになります。
┌────────────────────┐
│ 何らかの共通基盤異常 │
└──────┬─────────────┘
│
┌───────────┼───────────┐
│ │ │
DNS 通信経路 認証・サービス
│ │ │
└─────┬─────┴─────┬─────┘
│ │
J:COM利用者 関連CATV事業者
│ │
└──────┬────┘
│
利用者ごとに異なる症状
この「共通基盤異常」が何だったのかは分かりません。
DNSサーバーの不具合かもしれませんし、ネットワーク機器かもしれません。ソフトウェアの異常、リソース不足、設定変更なども候補になります。
しかし、複数事業者に影響したことや、DNS変更で改善した利用者がいることから、少なくともこのような依存関係を考えるところまではできます。
4.3 設定ミス説をどう位置付けるか
設定ミスという仮説は、今回の事象を説明する候補の一つとして成立します。
例えば、
共通基盤へ設定変更
↓
一部または全部の設備へ反映
↓
DNS・通信経路などに異常
↓
広域障害
↓
設定修正・ロールバック
↓
キャッシュやサービス依存関係により順次復旧
というシナリオです。
一つの変更が複数地域へ同時に影響し得ること、修正後もDNSキャッシュなどによって復旧時刻に差が生まれ得ることから、技術的には成立します。
一方で、設備故障やソフトウェア障害でも同様の現象は発生します。
今回、設定変更が事故の起点だったことを示す公開情報は確認できていません。
したがって、本稿では設定ミスを「推察される事故原因」ではなく、より正確には公開情報と矛盾しない事故シナリオの一つとして扱います。
4.4 仮説の評価で見るべきポイント
障害切り分けでは、「それっぽいか」ではなく、「どれだけ多くの事象を少ない追加条件で説明できるか」を見ると整理しやすくなります。
今回の候補を整理すると、次のようになります。
| 仮説 | 説明しやすい事象 | 説明に追加条件が必要な事象 |
|---|---|---|
| DNSリゾルバー異常 | 外部DNSで改善した報告 | 認証・メールなど広範な影響 |
| 共通ネットワーク異常 | 複数事業者・複数サービスへの影響 | 外部DNSだけで改善した理由 |
| DHCP・プロビジョニング異常 | 利用者ごとの影響差 | モバイルや別サービスへの影響 |
| SSO・認証異常 | ログインサービスの障害 | 一般のインターネット接続障害 |
| セッション資源不足 | つながりづらい、新規接続失敗 | DNS変更で改善する事象 |
| 共通基盤の設定異常 | 広域・複数サービスへの同時影響 | 実際に変更が行われた証拠がない |
一つの仮説ですべてを説明できない場合、「仮説が間違っている」と即断する必要はありません。
一次障害と二次障害が存在する場合もあります。
例えば、
共通ネットワーク異常
↓
DNSへ到達できない
↓
名前解決失敗
共通ネットワーク異常
↓
認証基盤へ到達できない
↓
ログイン失敗
であれば、利用者からはDNS障害と認証障害が同時に起きているように見えます。
しかし、実際には同じネットワーク障害から派生している可能性があります。
おわりに
今回、J:COMの通信障害を題材として、外部へ公開された情報だけで障害箇所をどこまで切り分けられるかを考えてみました。
複数地域や関連事業者に影響しているのであれば、まず共通して利用する基盤を探します。
外部DNSへの変更で改善したという利用者報告があるのであれば、DNSリゾルバーやDNSまでの通信経路を調査候補に加えます。
インターネット接続とメールで復旧時刻が異なるのであれば、それぞれが依存するDNS、通信経路、認証、バックエンドサービスなどの違いを考えます。
そして、設定変更という仮説を置いた場合には、DNSキャッシュやTTLによって障害発生・復旧のタイミングが利用者ごとに異なる可能性も検討できます。
ただし、本稿で検討したDNS設定、ネットワーク機器、セッション数、認証基盤、設定変更などについて、今回のJ:COM障害の実際の原因だったと判断できる公開情報はありません。
公開情報だけで障害を分析する場合、最も避けたいのは、技術的に成立する仮説をそのまま事実として扱ってしまうことです。
「この症状なら、この原因でも説明できる」と「実際にそれが原因だった」は別物です。
障害切り分けでは、仮説を立て、観測と照合し、説明できない事象があれば仮説を修正します。最終的な事故原因については、設備ログや設定履歴などを確認できる当事者による調査結果を待つ必要があります。
今回のように原因を特定できなくても、公開情報から障害範囲、共通する依存関係、原因候補を段階的に絞り込むことはできます。
そして、後日公式な原因報告が公開されたときに、今回の仮説と照合して「どこまで読めていたのか」「どの観測を過大評価したのか」を再検証するところまで含めて、障害分析のよい教材になると思います。
参考
-
J:COM 障害・メンテナンス情報 - J:COMによる障害・復旧情報。具体的な事故原因については、最新の公式発表を優先してください ↩ ↩2 ↩3
-
伊那ケーブルテレビジョンによる2026年9月23日の障害情報 - インターネット接続の暫定復旧後もメールなどに影響が残った事象の確認に使用。本稿では各事業者による公式障害情報を事実関係の基準としています ↩ ↩2
-
JCOM株式会社「ケーブルインターネットZAQ、提携拡大 全国で計48社に提供」 - ケーブルテレビ事業者向けISPサービスと提供機能を確認するための公式資料 ↩ ↩2
-
ITmedia NEWSによる2026年9月23日のJ:COM障害報道 - 外部DNSへ変更すると通信が改善したという利用者報告の確認に使用。J:COMがDNSを障害原因として公式発表した資料ではありません ↩
-
RFC 1035: Domain names - implementation and specification - DNSおよびTTLの基本仕様 ↩