885番目の執事(butler885)

enひかりクロス XpassのIPv4瞬断問題その後。9日待って進捗確認、ポート割当やAFTR/CGNの設定変更は「なし」との回答

執事885 — Wed, 30 Sep 2026 14:21:14 +0000

こんにちは、執事です。

今回は、

enひかりクロス XpassのIPv4瞬断・ポート上限問題を総務省へ情報提供。現在はenひかりの回答待ち

こんにちは、執事です。今回は、この記事の続き。前回の記事では、enひかりクロス10G＋Xpassで発生しているIPv4瞬断と、契約単位のTCP/UDPポート数上限問題について、総務省にも相談してみる予定。というところまで書きました。で、連休...

この記事の続き。

前回の記事では、

enひかりクロス10G＋Xpassで発生しているIPv4瞬断・ポート上限問題について、総務省へ情報提供。

そして、

enひかり側にも追加質問を投げて、回答待ち。

というところまで書きました。

で。

enひかりから最後に、

ご質問いただいた事項につきまして社内確認いたしますため、回答まで今しばらくお時間いただけますようご了承お願いいたします。

と連絡をもらったのが、2026年9月20日。

そこから待つこと9日。

……。

返事が来ない(´・ω・`)

まぁ、今回聞いている内容が普通のサポート窓口で即答できるような話じゃないのは分かっています。

でも、さすがに9日経って何もないと、

「これ、ちゃんと確認進んでるよね？」

とは思う。

なので、9月29日に進捗確認のメールを送りました。

9日経ったので進捗確認してみた

送った内容はこんな感じ。

9月20日に、

「ご質問いただいた事項につきまして社内確認いたしますため、回答まで今しばらくお時間いただけますようご了承お願いいたします。」
とのご連絡をいただいております件について、進捗状況を確認したくご連絡いたしました。
社内確認に時間を要する内容であることは承知しておりますが、前回のご連絡から9日ほど経過しているため、現在どのような状況か、回答時期の目安だけでも分かりましたらご教示いただけますと幸いです。
なお、IPv4通信が断続的に利用できなくなる症状については、現在も継続して発生しています。

別に、

「早く答えろ！」

って言いたいわけではなく、

今どこまで確認が進んでるのかだけでも知りたい。

という感じ。

で、翌日の9月30日。

enひかりから返事が来ました。

質問1～5は、まだ確認中

回答がこちら。

本件につきまして進捗確認しましたが、ご質問1～5については現在も確認中です。

……。

まだ確認中だった(´・ω・`)

ちなみに質問1～5というのはざっくり言うと、

具体的なポート上限値、または概算
その上限値を非公開にしている理由
利用者側で現在のポート使用量を確認できる方法
「一般的な利用」として想定している端末数や通信量
通常のWeb閲覧やDNS通信まで失敗する可能性について、契約前にどう案内しているのか

この辺。

つまり、

今回自分が一番知りたいところは、まだ回答待ち。

という状態です。

まぁ、逆に考えるとこれだけ時間が掛かっているという事は、

少なくともカスタマーセンターの担当者がその場で回答できるような簡単な内容ではない、という事なんでしょうね。

ただし1つだけ回答が来た

今回、全部が「まだ確認中」だったわけではありません。

1つだけ確認が終わった質問がありました。

それが、

今回の調査中に、我が家の回線について何か設定変更をしたのか？

という質問。

以前の記事でも書いたんですが、9月18日頃から一時的にIPv4瞬断の発生頻度が減った時期がありました。

なので、もしかすると、

割当ポート数を増やした
収容先を変更した
AFTR/CGN側で何か調整した

とか、

調査中に何か変更されたのかな？

と思っていたんですよね。

そこで、

今回の調査に伴い、当方回線について割当ポート数、収容先、AFTR/CGN側の設定その他の変更・調整を実施された事実があるか

と確認していました。

これについてenひかりからの回答は、

確認の結果変更・調整を実施した事実は御座いませんでした。

とのこと。

つまり、

少なくともenひかり側の確認では、今回の調査に伴って我が家の割当ポート数を増やしたり、収容先やAFTR/CGN設定を変更したりした事実はない。

という事になります。

じゃあ、何で一時的に症状が減ったんだろう？

これで一つ、以前考えていた可能性は消えました。

問い合わせ後に何か設定を変えてくれたから、瞬断が減ったんじゃないか？

という線。

少なくとも、enひかりからの今回の回答を見る限り、

そういう人為的な変更・調整は行っていない。

とのことです。

じゃあ、なんで一時的に症状が減ったのか？

……。

分からん(´・ω・`)

家庭内の通信量がたまたま減っていたのか。

CGN側のセッション解放タイミングなのか。

Xpass側の利用状況や設備負荷なのか。

それとも全然別の要因なのか。

現時点では分かりません。

実際、その後はまたIPv4瞬断が発生しています。

なので、

「一時的に症状が減った＝問題が解決した」

ではなかった事だけは確か。

もしかしてenひかり側でも全部は分からない？

今回の回答を見て、ちょっと気になったのがここ。

enひかり側では、

「この契約がポート上限に達した」

という事自体は確認できています。

実際、

9月16日11時35分頃
9月18日15時03分頃

に上限到達していた、という回答まで出ています。

でも、その一方で、

具体的なポート上限値や、「一般的な利用」の基準、現在の使用量確認方法

なんかについては、10日ほど経ってもまだ確認中。

となると、

enひかり側でも、Xpassの細かい仕様までは即座に把握できる情報ではないのかな？

とは思います。

もちろん、これは現時点では自分の推測。

enひかりが社内の別部署へ確認しているのか、Xpass側へ確認しているのか、

そこまでは分かりません。

なので、

「enひかりも知らない」

と断定するつもりはありません。

ただ、利用者が知りたいと思っても分からない。

問い合わせ窓口でも即答できない。

そして回答にかなり時間が掛かっている。

というのは、今回改めて分かったところです。

今の状況

というわけで、2026年9月30日現在の状況はこんな感じ。

enひかり

質問1～5
→ まだ確認中
調査中に割当ポート数・収容先・AFTR/CGN設定を変更したか
→ 変更・調整した事実なし
総務省
9月24日
→ 情報受付フォームから送信済み
→ 現在回答待ち
IPv4瞬断
→ 現在も発生

つまり、

まだ終わらない(´・ω・`)

まとめ

今回分かったのは、

9月18日以降に一時的に症状が減ったのは、enひかりが我が家の割当ポート数や収容先、AFTR/CGN設定を変更したからではなかった。

という事。

これは一つ切り分けできました。

でも肝心の、

結局何ポート使えるの？
何でその数字は非公開なの？
利用者は使用量を確認できないの？
「一般的利用」って結局どの程度？
契約時の説明としてこれで十分なの？

この辺はまだ回答待ち。

そして、総務省からもまだ回答なし。

なので今は、

両方からの回答を待つしかない。

という状態です。
しかし、最初はただ

「Yahooとかが時々開かない」

だけだったんですよ。

そこから、DNS、MTU、XG-100NE、DS-Lite、CGN、ポート上限、総務省

そして今度は、

「そのポート上限って誰なら分かるのさ？」というところまで来ました。

さて。

次は、enひかりから先に回答が来るのか。

総務省から先に来るのか。

もう少し待ってみたいと思います(´・ω・`)

光クロス(10Gbps回線）のXpassとXG-100NE運用でipv4が瞬断する問題についてあれこれ検証

こんばんは、執事です。今回は、これらの記事の続きです。ファンを取り付けて落ち着いたと思ったんだけど、やっぱり瞬断が発生する。しかも、主にipv4接続でのみ発生。Xpass(DS-Lite)ではIPv6はIPoEでそのまま通信し、IPv4はD...

XG-100NE交換後もIPv4瞬断が再発。Xpass（DS-Lite）のAFTR・CGN側を疑って調査中

こんばんは、執事です。今回は、この記事の続き。前回、en光クロスに変更してから続いている謎のIPv4瞬断について色々切り分けをしていたところ、XG-100NEのLAN4（10Gbpsポート）が完全に通信できなくなるという、なんとも分かりやす...

enひかりクロス XpassのIPv4瞬断の原因がほぼ判明。DS-Liteのポート数上限到達でWeb通信まで失敗していた

こんにちは、執事です。今回は、この記事の続き。前回まで、enひかりクロス10G＋Xpass環境で、IPv4通信だけが突然遅くなる、というかほぼ繋がらなくなる。という謎の障害を追い続けていました。Wi-Fi？ASUS RT-BE18000？D...

enひかりクロス XpassのIPv4瞬断とポート上限問題。10Gbps化後に通信品質が低下した件を総務省にも相談予定

こんにちは、執事です。今回は、この記事の続き。前回の記事では、enひかりクロス10G＋Xpass環境で長いこと悩まされていたIPv4瞬断について、我が家の1契約に割り当てられているTCP/UDPポート数が、実際に上限へ到達していたことがen...

enひかりクロス XpassのIPv4瞬断・ポート上限問題を総務省へ情報提供。現在はenひかりの回答待ち

執事885 — Thu, 24 Sep 2026 07:07:02 +0000

こんにちは、執事です。

今回は、

enひかりクロス XpassのIPv4瞬断とポート上限問題。10Gbps化後に通信品質が低下した件を総務省にも相談予定

この記事の続き。

前回の記事では、

enひかりクロス10G＋Xpassで発生しているIPv4瞬断と、契約単位のTCP/UDPポート数上限問題について、総務省にも相談してみる予定。

というところまで書きました。

で、連休も終わったので、

実際に総務省へ相談してみました。

まず総務省の電気通信消費者相談センターへ電話

今回電話したのは、

総務省電気通信消費者相談センター

です。

前回は祝日だったので電話が繋がらなかったんですが、

連休明けに改めて電話。

今回の、

enひかりクロス10G＋Xpassを利用していること
IPv4通信だけが断続的に利用できなくなること
enひかり側で、実際に契約単位のTCP/UDPポート数上限への到達が確認されていること
ポート上限到達時にIPv4通信が制限されること自体は「仕様上想定される動作」と回答されていること
しかし具体的な上限値や現在の使用量は利用者から確認できないこと

なんかを説明しました。

ただ、

電話なので当然ながら、

こちらが話した内容がそのまま文章として残るわけではありません。

自分としては今回、

単に電話で相談して終わりではなく、こちらが何を問題としているのかを文章としてきちんと残しておきたい。

と思っていました。

なので、

「電話ではなく、メールみたいに内容が残る問い合わせ方法はありませんか？」

と聞いてみたところ、

こちらを案内されました。

電気通信サービスに関する情報受付フォーム

「電気通信サービスに関する情報受付フォーム」

今回は電話だけで終わらせず、情報受付フォームから送信

電話で聞いたところ、

このフォームから送った内容については、

回答まで2週間程度かかる場合がある
送信内容が必ず事業者へ伝達されることを確約するものではない
必要に応じて情報提供として確認される

という感じの説明でした。

それでも、

今回はこちらを使うことにしました。

理由は単純。

文章として残したかったから。

今回の件、

技術的な話だけでも、

DS-Lite、

AFTR、

CGN、

TCP/UDPポート、

IPv4、

IPv6、

とか色々出てくる。

更に、

「何が一番問題だと思っているのか」

まで電話だけで正確に伝えようとすると、

かなり長くなる。

なので、

自分なりにこれまでの経緯を整理して、

総務省へ送信しました。

総務省へ伝えた内容

全部載せるとかなり長いので、

大きくまとめるとこんな内容。

enひかりクロス10Gbps＋Xpassを利用中、IPv4通信が断続的に利用できなくなる症状が繰り返し発生している。

宅内環境についてはLANケーブル、有線接続、DNS、MTU等を確認し、XG-100NE本体についてもNTTに交換してもらったが、交換後も同じ症状が再発した。

enひかり側の調査では、我が家の契約について、実際に契約単位のTCP/UDPポート数上限へ到達していたことが確認されている。

しかし、

・具体的なポート上限値は非公開
・現在何ポート使用しているのか確認できない
・あとどれだけ余裕があるのか確認できない
・どの程度の端末数や通信量を「一般的な利用」としているのか分からない

という状態。

そして、実際に我が家で確認してきた症状としては、通常のIPv4 Web閲覧やDNS通信まで利用できなくなる場合がある。

で、

今回自分が一番伝えたかったのは、

やっぱりここ。

「10Gbps出ない」という相談ではない

総務省への申告文にも、はっきり書きました。

自分が問題に感じているのは「10Gbps契約なのに10Gbps出ない」という話ではありません。

以前使っていたenひかり1Gbpsでは、

最大速度は今より当然遅い。

でも、

普通にInternetへ繋がっていました。

Yahooを見る。

Googleを見る。

DNS問い合わせをする。

HTTPS通信をする。

そんな普通の通信で、

「今日は繋がるかな？」

なんて考える必要はなかった。

ところが、

10Gbpsへアップグレードして、

最大速度そのものは速くなった。

その一方で、

普通のIPv4 Web通信が断続的に成立しなくなる。

という状態になった。

なので、

1Gbps → 速度は低い → でも普通に繋がる

10Gbps＋Xpass → 速度は速い → でもIPv4通信が繋がらない事がある

という状態。

自分としては、

速度は向上したけど、可用性・接続安定性・通信品質は実質的に低下した。

と感じています。

これが、

いち消費者として一番納得できていないところ。

ポート制限そのものを否定したいわけじゃない

これも総務省にはちゃんと書きました。

IPv4アドレスが足りない。

だから複数利用者で共有する。

そのため、

利用できるTCP/UDPポート数にも制限がある。

この仕組みそのものは理解しています。

自分が聞きたいのは、

その制限によって「普通のWeb閲覧まで利用できなくなる可能性がある」という事を、契約時に利用者が十分理解できる状態だったのか？

というところ。

契約時、

自分は、

v6プラス
transix
Xpass

の違いについて電話で聞いています。

その時に自分が受け取った説明としては、

「大きな違いはなく、どれも10Gbps回線で使える」

という程度。

だから、

「じゃあXpassでいいかな」

くらいで決めました。

後から調べれば、

IPv4アドレスを共有すること、

ポート数に制限があること、

自体はWebサイトや重要事項説明にも書いてある。

なので、

「一切書いてなかった！」

と言いたいわけではありません。

でも、

ポート数に制限があります → 契約単位の上限があります → 具体値は非公開です → 使用量も見えません → 上限に達すると普通のWeb閲覧やDNS通信まで失敗する場合があります

ここまで一般利用者が読み取れるのか？

という疑問。

なので総務省には、

こうした制約は、サービス選択に影響する重要な提供条件として、もっと具体的に説明されるべきものではないのか？

という点について見解を聞きたい、

と伝えました。

そして連休明けからIPv4瞬断がまた増えている

ちなみに通信状況ですが、

改善していません。

従来と同じようなIPv4瞬断が再発。

その後も断続的に発生しています。

そして、

連休明けの2026年9月24日15時16分までに、自分が確認できた範囲だけでも3回以上、IPv4通信が正常に利用できない状態を確認しました。

なので、

過去に一時的にポート上限へ達したことがあった。

というだけの話ではなく、

利用者側から見える「Internetが突然繋がらなくなる」という症状自体は、今現在も続いています。

なお、

連休中は体感的に瞬断の発生頻度が少なかったように感じています。

そして連休が明けた9月24日から、

また明確に増えた。

ただ、

これが利用者数や設備負荷なんかと関係しているのかは分かりません。

そこは利用者側から確認する手段がないので。

総務省への送信は完了

で、2026年9月24日。

総務省の、

「電気通信サービスに関する情報受付フォーム」

から送信完了。

送信後は、

「登録を完了いたしました」

と表示され、

受付番号も発行されました。

一応、

送信完了画面はPDFで保存。

こういうのは後で、

「いつ送ったっけ？」

「何て書いたっけ？」

になるので、

記録は残しておいた方がいいですね。

ちなみに送信後の確認画面、

入力時の改行や段落がほぼ全部消えて、文章がギッチギチに詰まって表示されました

ちゃんと内容は入ってるんだけど、

まぁ読みづらい(´・ω・`)

それでも登録自体は完了していて、受付番号も発行されています。

送信した本文についても、確認画面上には今回整理した経緯や総務省へ確認したい4項目まで記録されていました。

今の状況をまとめると

現時点では、

enひかり → 社内確認中 → 回答待ち

総務省 → 電話相談 → 情報受付フォームを案内される → 2026年9月24日送信完了 → 回答待ち

という状態。

なので、

今度こそ本当に両方の回答待ち。

になりました。

まとめ

今回、

総務省へ相談したからといって、

すぐ何かが変わるとか、

enひかりへ必ず何か指導が入るとか、

そういう話ではありません。

それでも、

今回自分が一消費者として感じている疑問について、

行政側へ正式に情報提供として残すところまではできました。

これは一つ進んだかなと思っています。

あとは、enひかりがどう回答してくるのか。

総務省からどんな回答が返ってくるのか。

ここを待ちたいと思います。

最初は、

「Yahooが時々開かない」

だけだった話が、

XG-100NEを交換し、

Xpassのポート上限が判明し、

ついには総務省へ情報提供するところまで来ました。

光回線のトラブルシューティングで霞が関まで辿り着くとは思わんかったわｗ

またenひかり、

もしくは総務省から回答があれば、

続きを書きたいと思います。

さて、

今度はどんな回答が返ってくるんでしょうかね(´・ω・`)

光クロス(10Gbps回線）のXpassとXG-100NE運用でipv4が瞬断する問題についてあれこれ検証

XG-100NE交換後もIPv4瞬断が再発。Xpass（DS-Lite）のAFTR・CGN側を疑って調査中

enひかりクロス XpassのIPv4瞬断の原因がほぼ判明。DS-Liteのポート数上限到達でWeb通信まで失敗していた

enひかりクロス XpassのIPv4瞬断とポート上限問題。10Gbps化後に通信品質が低下した件を総務省にも相談予定

執事885 — Wed, 23 Sep 2026 05:50:09 +0000

こんにちは、執事です。

今回は、

enひかりクロス XpassのIPv4瞬断の原因がほぼ判明。DS-Liteのポート数上限到達でWeb通信まで失敗していた

この記事の続き。

前回の記事では、enひかりクロス10G＋Xpass環境で長いこと悩まされていたIPv4瞬断について、

我が家の1契約に割り当てられているTCP/UDPポート数が、実際に上限へ到達していた

ことがenひかり側の調査で確認されたところまで書きました。

更に、

ポート数上限へ到達した場合にIPv4通信の一部が利用できなくなること自体は、Xpass可変IPサービスの「仕様上想定される動作」

との回答。

で、

じゃあ、その上限って何ポートなの？
今何ポート使ってるの？
あとどのくらい余裕があるの？
「一般的な利用」って具体的に何台なの？
普通のWeb閲覧やDNSまで失敗する可能性って、契約時にちゃんと分かるように説明されてた？

というところを更にenひかりへ質問しています。

今回は、その後の途中経過。

ちなみにその後、2026年9月19日23:40頃にも、従来と同様のIPv4瞬断が再発しています。

一時的に症状が出ていない時間帯はあったものの、少なくとも問題そのものが解消したわけではありませんでした。

ただし、この23:40頃の瞬断について、同時刻にポート数上限へ到達していたかどうかは現時点では確認できていません。

enひかりからは「社内確認するので少し待ってほしい」との返答

2026年9月20日、enひかりからこんな返信がありました。

お世話になっております。

enひかりカスタマーセンターでございます。

ご質問いただいた事項につきまして社内確認いたしますため、回答まで今しばらくお時間いただけますようご了承お願いいたします。

引き続きよろしくお願いいたします。

まぁ、これは仕方ないかなと思っています。

今回聞いている内容って、

単に、

「ルーター再起動してみてください」

とか、

「LANケーブルを交換してみてください」

みたいな一般的なサポートの範囲ではなくなっていて、

Xpassの具体的なポート割り当て仕様
上限値を非公開としている理由
契約時の説明方法
利用者側で使用状況を確認できないこと
サービスの提供条件としてどう扱っているのか
今回の調査で何らかの設定変更を行ったのか

みたいな話になってます。

なので、カスタマーセンターの担当者がその場で即答できる内容ではないのは分かる。

おそらく上位部署だったり、場合によってはXpassを提供している側にも確認が必要になるんじゃないかな？

と思っています。

しかも今はシルバーウィーク期間中。

常駐しているカスタマーサポート以外の部署は休みだと思うので、

本格的な回答は連休明けの9月24日以降かな？

くらいに考えています。

なので、ここは一旦待ち。

その間に総務省にも相談してみようと思った

で、

enひかりからの回答を待っている間に、

この件を総務省にも一度相談してみよう。

と思いました。

別に、

「enひかりを怒ってもらおう！」

とか、

「違法だ！処分しろ！」

とか、

そういう話ではありません。

今回の件について、

一消費者として感じている疑問が、通信サービスの提供条件や説明として妥当なのか。

第三者の立場から見た意見を聞いてみたい。

というのが目的。

……。

どっちも連休でやってなかった(´・ω・`)

まぁ、そりゃそうか。

この記事を書いている2026年9月23日は祝日。

なので、こちらも連休明けに改めて相談してみようと思います。

で、総務省に何を相談したいのか？

ここまでの記事を読んでもらうと、

「ポート上限が非公開なのが問題なんでしょ？」

と思うかもしれません。

もちろん、それもかなり気になっています。

でも色々考えた結果、

一消費者として自分が一番納得いっていない部分は、そこだけじゃない。

という事に気付きました。

自分が一番引っ掛かっているのは、

1Gbpsから10Gbpsへアップグレードしたのに、通信の安定性が悪くなった

ここなんですよね。

以前使っていたenひかり1Gbpsでは、

当然ながら最大速度は1Gbps。

10Gbps回線に比べれば遅い。

でも、

普通にInternetへ繋がる。

これが当たり前でした。

Yahooを開く。

Googleを開く。

DNS問い合わせをする。

普通にWebを見る。

それが、

「今日はポートを使い過ぎてるから開かないかもしれません」

なんて意識する必要はなかった。

ところが、

より高速な10Gbpsサービスへアップグレードした結果、最大通信速度は上がった。

でもその一方で、

普通のWeb閲覧すら断続的に失敗するようになった。

というのが今回の状況。

速くなったけど「繋がる」が不安定になった

これって、

単純な、

「10Gbps契約なのに5Gbpsしか出ません！」

みたいな話とは全然違うと思うんですよね。

ベストエフォート回線なのは理解しています。

10Gbpsと書いてあるからといって、

24時間いつでも必ず10Gbps出るわけじゃない。

混雑していれば5Gbpsになるかもしれない。

1Gbpsになるかもしれない。

500Mbpsになることだってあるかもしれない。

そこは分かる。

でも今回起きているのは、

速度が遅いのではなく、通信そのものが成立しないことがある。

という話。

 1Gbps回線 → 最大速度は低い → でも基本的には普通に繋がる 10Gbps＋Xpass → 最大速度は大幅に上がった → でもポート上限に達すると 通常のIPv4通信まで失敗する場合がある

これ、

通信サービスとしての快適性は本当に向上したと言えるの？

って思うんですよね。

今回は「可用性・接続安定性」の問題

今回問題に感じているのは、

可用性とか接続安定性、通信の継続性。

こっち。

つまり、

「必要な時に普通に使えるか」

という部分。

自分の感覚では、

 速度 ↑ でも 可用性・接続安定性 ↓

になった。

10Gbps回線へのアップグレードって、

普通の消費者感覚なら、

今までより高性能になる。

と思うじゃないですか。

少なくとも、

「最大速度は上がりますが、代わりに普通のWeb通信が断続的に成立しなくなる可能性があります」

なんてサービス変更だとは思ってなかった。

そして、そのトレードオフを契約時に認識できていなかった

ここが総務省に聞いてみたい部分。

自分がenひかりクロスへ変更した時、

IPv4 over IPv6方式として、

v6プラス
transix
Xpass

なんかが選べました。

で、

電話で、

「これって何が違うんですか？」

って聞いています。

その時に受けた説明として自分が認識しているのは、

「大きな違いはない。どれも10Gbpsで使える」

という程度。

だから、

「じゃあXpassにしようかな」

くらいで選んだ。

もちろん、

Webサイトや重要事項説明を後から確認すると、

IPv4アドレスを共有することや、

ポート数に制限があること自体は書いてあります。

なので、

「どこにも書いてない！」

という話をしたいわけじゃない。

でも、

「ポート数に制限があります」

という一文から、

普通の利用者が、

 一定数以上のTCP/UDP通信を行う → 契約単位のポート上限に達する → 新しいIPv4通信に制限が生じる → DNS問い合わせ失敗 → HTTPS接続失敗 → 普通のWebサイトまで開かなくなる

ここまで具体的に想像できるのか？

って話。

しかも、

その上限値は分からない。

現在の使用量も分からない。

残りも分からない。

利用者側から監視する方法も今のところ分からない。

障害が起きた後に問い合わせをして、事業者側で初めて「ポート上限に達してます」と確認できる。

これで、

「利用者はサービスの違いを理解した上で選択できていました」

と言えるんだろうか？

というのが、自分の疑問。

総務省には「10Gbps出ない」という相談はしない

なので、連休明けに総務省へ電話する時は、

最初にここをちゃんと伝えようと思っています。

「10Gbps契約なのに10Gbps出ない」という速度の相談ではありません。

と。

相談したいのは、

1Gbpsサービスから、より高速な10Gbpsサービスへアップグレードした結果、最大通信速度は向上したものの、以前は普通に利用できていたWeb閲覧やDNS通信が、契約単位のポート上限によって断続的に成立しなくなる状態になった。

つまり、最大速度は向上した一方で、インターネット接続サービスとしての可用性・接続安定性・通信品質は実質的に低下したと感じている。

このような重要なサービス特性について、現在のWebサイトや重要事項説明、契約時の説明だけで、利用者が十分理解してサービスを選択できる状態と言えるのか。

この辺を中心に聞いてみたい。

ポート上限そのものが悪い、と言いたいわけではない

ここも誤解されないようにしたいところ。

IPv4アドレスが枯渇してる。

だから複数人でIPv4アドレスを共有する。

そのために使えるポート数にも限界がある。

これは仕組みとして理解できます。

もちろん、IPv4アドレスを複数利用者で共有する以上、利用できるポート数に制約が生じるという仕組み自体は理解しています。

ここで「Xpassという仕組みそのものがおかしい」と言いたいわけではありません。

自分が問題に感じているのは、

その制約によって利用者が実際に受ける影響がどの程度なのか。

そして、

その影響を契約前にどこまで具体的に理解できるよう説明されているのか。

です。

例えば最初から、

Xpass可変IPでは契約単位でIPv4用ポート数に上限があります。

多数の端末や通信を同時利用すると上限に達し、通常のWeb閲覧やDNS通信を含むIPv4通信が一時的に利用できなくなる可能性があります。

具体的なポート数は○○です。

とか説明されていたら、

「じゃあ自分の環境だと他方式にしようかな」

って選べる。

でも実際には、

ポート数上限はある。

具体値は非公開。

使用量は見えない。

超えた時はWebすら開かない事がある。

という事を、

障害が発生してから初めて理解した。

ここが一番引っ掛かっています。

enひかりを責めたいわけではない

何度も書いていますが、

自分はenひかりを3年以上使っています。

1Gbps時代は普通に満足してました。

料金も比較的安い。

今回のサポートについても、

ちゃんと通信状況を調べて、

「あなたの契約は実際にポート上限まで達しています」

というところまで確認してくれています。

今回の追加質問についても、

すぐ適当な回答を返すんじゃなくて、

「社内確認するので待ってほしい」

と返してきた。

これはむしろちゃんと対応しようとしていると思っています。

なので、

「enひかり最悪！」

みたいな記事にするつもりはない。

ただ、

一消費者として納得できないものは納得できない。

それだけ。

ちなみに宅内側の切り分けも一通りやっています

この記事から読み始めた方からすると今回の件、

「LANケーブルとか宅内環境が悪いんじゃないの？」

と思う人もいると思います。

もちろんそこも疑っていて、

LANケーブルの交換、

有線接続、

DNS変更、

MTU確認、

XG-100NE本体の交換、

までやっています。

10Gbps環境なので、今回の切り分けではCat6A対応品を使用。

自分が使っているのは、以前から使っているBUFFALOのCat6Aケーブルです。

バッファローツメの折れないLANケーブルモデム用カテゴリ6a ストレートフラットタイプブラック BSLS6AFU10BK

バッファロー

絶対にツメの折れないLANケーブル!!持ちやすく挿抜しやすいケーブル。

もちろん今回のIPv4瞬断は、LANケーブルを交換しても改善しませんでした。

なので、このケーブルを買えば今回の問題が直る、という話ではありません。

ただ、10Gbps回線で通信トラブルを切り分けるなら、物理層を疑う時にCat6A対応ケーブルを1本持っておくと確認はしやすいと思います。

今はenひかりの回答待ち。総務省へは連休明けに相談予定

というわけで、

2026年9月23日現在、

enひかり

については、社内確認中。

おそらく連休明け以降に回答。

そして、

総務省

についても、

九州総合通信局と電気通信消費者相談センターへ連休明けに改めて相談予定。

なので今は、

連休明け待ち(´・ω・`)

という状態です。

今回のシリーズ、

最初はただ、

「Yahooが時々開かないんだけど？」

というところから始まったのに、

Wi-Fi、

DNS、

MTU、

DS-Lite、

AFTR、

CGN、

TCP/UDPポート、

そして遂には、

電気通信サービスの提供条件や消費者への説明ってどうあるべきなの？

というところまで来てしまいました。

いやぁ……。

10Gbps回線にしただけなのに、ホントどこまで勉強させる気なんだｗ

enひかりから正式な回答が来たら、

それもそのまま紹介したいと思います。

そして総務省にも実際に相談して、

どういう見解だったのか、

また続きを書きます。

さて、

このシリーズ、

本当にどこまで続くんでしょうかね(´・ω・`)

光クロス(10Gbps回線）のXpassとXG-100NE運用でipv4が瞬断する問題についてあれこれ検証

XG-100NE交換後もIPv4瞬断が再発。Xpass（DS-Lite）のAFTR・CGN側を疑って調査中

enひかりクロス XpassのIPv4瞬断の原因がほぼ判明。DS-Liteのポート数上限到達でWeb通信まで失敗していた

執事885 — Sat, 19 Sep 2026 09:26:09 +0000

こんにちは、執事です。

今回は、

XG-100NE交換後もIPv4瞬断が再発。Xpass（DS-Lite）のAFTR・CGN側を疑って調査中

この記事の続き。

前回まで、

enひかりクロス10G＋Xpass環境で、IPv4通信だけが突然遅くなる、というかほぼ繋がらなくなる。

という謎の障害を追い続けていました。

Wi-Fi？

ASUS RT-BE18000？

DNS？

LANケーブル？

MTU？

XG-100NE？

DS-Lite？

Xpass側？

と、まぁ色々疑ってきたわけですが。

ちなみに今回使用している無線LAN環境はASUS RT-BE18000。

現在はXG-100NEをルーター、RT-BE18000をAPモードで使用しています。

今回のIPv4瞬断の原因そのものではありませんでしたが、我が家のWi-Fi環境についてはこの機種を使用しています。

ASUS WiFi RT-BE18000 無線ルーター最新規格WiFi7 11529+5764+688Mbps v6プラス/OCNバーチャルコネクト/クロスパス/transix/IPv6オプション対応トライバンドデュアル10Gポート 10G光クロスペアレンタルコントロール&ネットワークセキュリティ機能家中をカバーエコパッケージモデル

ASUS

【Amazon限定】環境に配慮した包装でお届けします。保証期間は+1年の3年保証

前回の記事の最後では、

XG-100NEのLAN4（10GbE）まで完全に通信できなくなる。

という別のトラブルまで発生。

「これもうXG-100NE本体が壊れてるんじゃね？」

って事でNTTに来てもらって、XG-100NEそのものを交換してもらいました。

これで流石に直るだろ。

と思ってたんですよ。

XG-100NEを新品交換！LAN4も復活！これで終わり！！

……と思うじゃん？

またIPv4が落ちた(´；ω；`)

しかも交換したその日の夜。

2026年9月16日23時32分頃。

新品になったXG-100NEでも、今までと全く同じような症状が発生しました。

今度はちょうど障害が発生している真っ最中にPCを触っていたので、すぐに確認。

まず、

 ping -4 8.8.8.8

を実行。

すると、

連続でタイムアウト。

しばらくすると、こっちでは何もしてないのに突然19ms前後で応答が復帰。

次に、

 nslookup www.yahoo.co.jp 8.8.8.8

これも、

DNS request timed out。

更に、

 curl -4 -I https://www.yahoo.co.jp/

を実行すると、

約21秒待った後、

Failed to connect。

つまり今回は、

IPv4 ICMP
IPv4 DNS
IPv4 HTTPS

がまとめて通信できなくなっている瞬間を捕まえる事ができました。

それでいて、機器の再起動なんかはしていないのに、その後勝手に復旧する。

やっぱり今までと同じじゃないか。

XG-100NEを新品にしても直らないなら、旧XG-100NEだけの故障ではない

ここは結構大きな切り分けになりました。

旧XG-100NEでは実際にLAN4が通信不能になっていたので、

旧XG-100NEに何らかの故障があった

というのはほぼ間違いないと思います。

実際、新品へ交換したらLAN4は普通に使えるようになりました。

なお、宅内側の切り分けではXG-100NE～ASUS間のLANケーブルも交換して確認しています。

10GbE接続なので、切り分けにはCat6A対応ケーブルを使用しました。

今回のIPv4瞬断そのものはケーブル交換では改善しませんでしたが、10GbE環境で物理層を切り分けるなら、まずここはCat6Aになっているか、Cat7とかCat8になっていないかは確認しておいた方がいいです。

バッファローツメの折れないLANケーブルモデム用カテゴリ6a ストレートフラットタイプブラック BSLS6AFU10BK

バッファロー

絶対にツメの折れないLANケーブル!!持ちやすく挿抜しやすいケーブル。

ただ、

IPv4の瞬断は新品交換後も再発。

となると、

「IPv4瞬断も全部旧XG-100NEの故障でした」

では説明できない。

XG-100NEという機種共通のDS-Lite処理やファームウェアの問題、という可能性はまだ残るものの、

少なくとも、

旧XG-100NEという個体だけが悪かった線はかなり薄くなった。

という事。

そこで、再びenひかりへ障害発生時刻と各種ログを送って再調査をお願いしました。

そしてenひかりから返ってきた回答

で、返ってきた回答がこちら。

要点だけ抜き出すと、

お客様の通信状況を確認した結果、調査時点で可変IPサービスにおける払い出しポート数の上限に達していることを確認いたしました。

ご申告の通信不安定事象については、上記ポート数制限の影響を受けている可能性が考えられます。

……。

ん？

ポート数の上限？

最初読んだ時、

「Xpass設備全体のポートが足りてないって事？」

と思ったんですが、そうではありませんでした。

更に聞いてみたところ、

ウチの1契約に対して割り当てられているTCP/UDPポート数の上限。

とのこと。

そんな上限に引っ掛かってたんかい！

Xpassの可変IPではIPv4アドレスを複数ユーザーで共有している

ちょっとここは仕組みの話。

Xpassの可変IPv4では、一人一人に専用のグローバルIPv4アドレスが与えられているわけではありません。

ざっくり書くと、

 執事885宅 192.168.1.x → XG-100NE → IPv4をIPv6にカプセル化 → Xpass / DS-Lite → AFTR / CGN → 共有グローバルIPv4 → Internet

という感じ。

グローバルIPv4アドレスを複数ユーザーで共有するので、

各契約者には、IPv4通信で利用できるTCP/UDPポート数に上限が設けられている。

で、その割り当てられたポートを全部使い切った。

これが今回enひかり側で確認された事。

あれ？これって今までの症状にめちゃくちゃ当てはまらない？

ここで過去の症状を思い返してみる。

以前は、

 ping -4 8.8.8.8 →17msで正常 nslookup www.yahoo.co.jp 8.8.8.8 →失敗 curl -4 Yahoo →失敗

という状態がありました。

ICMPのpingは通ってる。

でもTCP/UDP通信が新しく確立できない。

そして時間が経つと自然に戻る。

これ、

ポート枯渇と考えると結構きれいに説明できる。

TCPやUDPの通信に使っていた変換情報が時間経過で解放されれば、また空きポートができる。

空きが出来れば新しい通信が始められる。

だから、

 Yahoo開かない → 何度かリロード → 突然開く

みたいな事も起こり得る。

しかもIPv6はこのIPv4用ポートを使わないので、

IPv4は死んでいるのにIPv6サイトは普通に開く。

これも今までの症状と合う。

もちろん、障害中にIPv4 pingまで落ちたケースもあるので、全ての挙動が単純に「ポート枯渇」の一言だけで説明できるかまでは分かりません。

なお、ICMPのpingにはTCP/UDPのようなポート番号自体がありません。

そのため、IPv4 pingまでタイムアウトしたケースについては、TCP/UDPのポート数上限だけでは説明し切れません。

ポート上限とは別の要因が同時に発生していたのか、Xpass側でIPv4通信全体に影響する状態になっていたのか、その点については現時点では不明です。

ただ少なくとも、

実際に我が家の契約でポート上限に達していた。

これはenひかり側で確認されています。

しかも1回じゃなかった

前回の調査時点で、

お世話になっております。
ご調査ありがとうございます。

その後、NTTにてXG-100NE本体を新品交換していただきましたが、交換後も同一のIPv4通信障害が再発しました。

今回は障害発生を確認した直後に下記試験を実施しております。

・ping -4 8.8.8.8
複数回連続してタイムアウト。その後、機器再起動等を行わず自然に19ms程度へ復旧。

・nslookup www.yahoo.co.jp 8.8.8.8
8.8.8.8をDNSサーバーとして直接指定しましたが、DNS request timed out。

・curl -4 -I https://www.yahoo.co.jp/
約21秒後に接続失敗。

XG-100NE交換後も同一現象が発生していること、またDNSだけではなくIPv4のICMP・DNS・HTTPSが同時に通信不能となることから、宅内DNS設定のみの問題ではないと考えております。

今回事象の最初の発生時刻は 2026年9月16日 23:32～23:34頃（JST） です。

その後も同様の状況が散発的に発生しています。

お手数ですが、「調査時点で正常であるか」だけでなく、上記障害発生時刻について、クロスパス側の収容設備、AFTR、CGN/NATセッション、IPv4側出口設備等にパケットロス、セッション異常、設備負荷、収容逼迫等の記録がないかご確認いただけますでしょうか。

また、ご依頼いただきました「通信先から通信元へのトレースルート」について確認させてください。

DS-Liteでは当方のIPv4通信はAFTR/CGNを経由し、グローバルIPv4アドレスを共有する構成と認識しております。そのため、一般利用者側からYahooやGoogle等の通信先を起点として自宅側への逆方向tracerouteを実施することは困難です。

御社で想定されている具体的な測定方法、利用する測定サイト、または通信先をご指定いただけますでしょうか。

必要であれば、次回事象発生時にもIPv4/IPv6双方のping、traceroute、DNS問い合わせ、HTTPS接続結果を取得いたします。

よろしくお願いいたします。

という内容でenひかりへメールを送り、2026年9月16日23:32～23:34頃に実際に発生した障害について確認をお願いしていました。

その後、enひかり側で更に調査したところ、この時間帯とは別に、以下の日時にも我が家の契約でポート数上限への到達を確認していたとのこと。

2026年9月16日 11:35頃
2026年9月18日 15:03頃

つまり、単に「ポート上限に達している可能性があります」という推測ではなく、実際に複数回、我が家の契約でポート数上限に到達していた記録が残っているという事です。

ちなみにログそのものや具体的な使用ポート数については開示できない、との回答でした。

そしてもっと気になったのが「これは正常な仕様です」という回答

そこで、

「ポート数上限まで達して、普通のWebサイトやDNS通信まで失敗する状態って、設備異常なんですか？それとも仕様なんですか？」

と聞いてみました。

回答は、

可変IPサービスの仕様上、想定される動作となります。

とのこと。

つまり、

ポート上限に達するとIPv4通信に制限が生じること自体は、**「仕様上想定される動作」**。

という回答。

なるほど。

いや、仕組みとしては分かる。

IPv4アドレスが枯渇してるから共有して使ってる。

だから使えるポート数にも限界がある。

そこまでは分かる。

でもさ。

じゃあ、その上限って何ポートなの？

ここですよ。

今回、

実際にウチが上限まで到達した。

と言われてるわけです。

じゃあ、

「一体何ポート使ったら上限なの？」

と思うじゃないですか。

でも、

具体的な割り当てポート数は非公開。

なんです。

しかも、利用者側からは、

自分に何ポート割り当てられているのか分からない
今何ポート使っているのか分からない
上限の何％まで来ているのか分からない
どの端末がどの程度ポートを使っているのか分からない
あと何台繋いだら危ないのかも分からない

という状態。

それなのに上限に達すると、

普通のIPv4 Web通信まで断続的に失敗する可能性がある。

そして障害が出た後に問い合わせをして初めて、

「ポート数上限まで到達してますね」

と分かる。

……。

利用者側では対策のしようがなくない？(´・ω・`)

「一般的な利用を想定して必要十分なポート数」とのこと

この辺も気になったので、

「一般家庭でPC、スマホ、Webカメラ等を複数使っていたら上限に達する事も想定しているの？」

と聞いてみました。

回答は、

一般的な利用方法を想定して、必要十分なポート数の割り当てを行っております。

なお、ポートの利用状況は、同時に利用される端末・アプリケーション数や通信状況によって異なります。

そのため、ご利用状況によってはポート数の上限に達する場合がございます。

とのこと。

うん。

言ってる事は分かる。

でも、

「一般的な利用方法」って何台なの？

ってなる。

我が家には、

PC、

スマホ、

タブレット、

Fire TV、

ゲーム機、

ATOM Cam、

その他IoT機器、

なんかが繋がっています。

確かに昔ながらの、

 PC 1台 スマホ 2台

みたいな家よりは多いと思う。

でも今どき、

スマート家電やネットワークカメラ、TV、ゲーム機、タブレットなんかを全部合わせたら、

20台、30台ネットワークにぶら下がっている家庭ってそこまで珍しくないと思うんですよね。

少なくとも、

特殊なサーバーを何十台も公開してる、とか、

大量のP2P通信を意図的に走らせてる、

とかではない。

そこで更に、

「一般的利用を想定して必要十分」と言うなら、何台・何通信程度を想定しているの？

と問い合わせています。

ちなみに、アイキャッチ画像に置いていますが、記事執筆時点で、XG-100NEのDHCPv4払い出し状況は18件でした。

少なくとも数百台を接続しているような特殊な環境ではありません。

固定IPへ変更してください、と言われても…

enひかりからは、

ポート上限へ達するような利用環境なら、

クロスパス固定IPサービスを検討してください。

とも案内されました。

固定IPならIPv4アドレスを共有しないので、今回のような共有ポート数制限の問題からは解放される。

理屈は分かります。

ただし、

XG-100NEはクロスパス固定IPに対応していない。

とのこと。

……。

10Gbps回線にする。

↓

ひかり電話を使うためXG-100NEを使う。

↓

Xpass可変IPを使う。

↓

ポート上限に達する。

↓

固定IPを使ってください。

↓

XG-100NEは固定IP非対応です。

いや、どないせぇっちゅうねんｗ

そもそも契約時にそんな違いを説明されたっけ？

で、ここからは技術的な話というより、

利用者への説明としてどうなの？

という話になってきます。

自分がenひかりクロスを契約した時、

接続方式として、

v6プラス
transix
Xpass

等が選べるので、

電話口で、

「これって何が違うんですか？」

と聞いています。

その時の説明として自分が受け取った内容は、

大きな違いはなく、どれも10Gbps回線で使える。

という程度のもの。

なので、

「じゃあXpassでいいかな」

くらいの感覚で選びました。

少なくとも、

「Xpass可変IPには契約単位のポート上限があり、その上限に達すると通常のWeb閲覧やDNS通信まで断続的に失敗する可能性があります」

なんて説明は受けた記憶がありません。

もちろん後から調べれば、

Webサイトや重要事項説明には、

IPv4アドレスを共有するのでポート数に制限があります。

という内容自体は記載されています。

なので、

「一切書いてないじゃないか！」

という話ではありません。

そこはちゃんと書いてある。

ただね。

「HPに書いてあります」「規約に書いてあります」で済ませて良い話なのか？

今回、自分自身がここまで調査してみて思うのはここ。

ポート制限があります。

という一文を見て、

普通の利用者が、

 ポート上限に到達 → CGN/NATで新規TCP/UDPセッションが作れなくなる → DNS問い合わせ失敗 → HTTPS接続失敗 → Yahooすら断続的に開かなくなる

まで想像できるのか？

って話。

しかも上限値は非公開。

今何ポート使っているかも見えない。

上限までどれくらい余裕があるのかも見えない。

事業者側では、

「9月16日11:35頃に上限に達してましたよ」

と確認できる。

でも利用者側では分からない。

今回なんて自分は、

Wi-Fiを疑い、

ASUSを疑い、

DNSを疑い、

LANケーブルを交換し、

MTUを調べ、

pingを取り、

tracerouteを取り、

curlを打ち、

nslookupを打ち、

XG-100NEのログを何日も調べ、

最終的にXG-100NEまで新品に交換してるんですよ。

で、原因候補が「実は契約ごとのポート上限まで使ってました」って。

いや、

それそっちでは最初から確認できる情報なんかいｗ

って思いますよね。

9月19日23:40、再びIPv4瞬断が発生

この記事を書いている途中、9月18日頃から、それまで一日に何度も発生していたIPv4瞬断をしばらく確認していませんでした。

enひかり側では9月18日15:03頃にも、我が家の契約でポート数上限への到達を確認しているとのことでしたが、自分自身はその時間帯に従来のような瞬断を認識していませんでした。

なので、

「もしかして今回の調査に伴って、何か設定や収容先が変更された？」

なんて事も考えていたんですが……。

2026年9月19日23:40頃、再び同様のIPv4瞬断が発生しました。

やっぱり直ってなかった(´；ω；`)

少なくとも、9月18日以降しばらく症状が出ていなかったのは、恒久的に改善していたわけではなさそうです。

一方で、今回の23:40頃の瞬断について、enひかり側で同時刻にポート数上限へ到達していたかどうかまでは現時点では確認できていません。

そのため、

「今回の23:40の瞬断もポート上限到達が直接の原因だった」

とまでは断定しません。

ただ、これまでに我が家の契約で実際に複数回ポート上限へ到達していることはenひかり側で確認されており、今回も過去と同様のIPv4瞬断が再発したことになります。

つまり、ポート上限問題については引き続き解決しておらず、症状も継続している状態です。

なお、ポート上限到達＝必ず即座に体感できる通信断、というわけではない可能性もあります。

9月18日15:03にはenひかり側で上限到達を確認している一方、自分自身はその時刻に瞬断を認識していなかったためです。

ポート上限に達した時に、どの通信がどの程度影響を受けるのかについても、もう少し情報が欲しいところです。

enひかりへ更に確認している内容

現在、以下について回答待ち。

ウチ1契約に割り当てられている具体的なポート数、または概算
具体的なポート上限を非公開にしている理由
利用者側で現在のポート使用数を確認する方法があるのか
「一般的な利用」とは何台・どの程度の通信を想定しているのか
一般的なWeb閲覧やDNS通信まで失敗する可能性について、契約前に具体的に案内している場所
今回の調査に伴って、ウチの割当ポート・収容先・AFTR/CGN設定等を変更したのか

この回答は結構重要だと思っています。

特に、

何ポートなのか。

ここ。

例えば、

「一般家庭には○万ポート程度割り当ててあります」

と分かれば、

まだ利用者側でも考えようがある。

でも、

 上限値 → 秘密, 現在値 → 見えない, 残り → 見えない, 目安 → 不明, 超えた時 → Internetが不安定になる

では、

利用者はどうやって自分の使い方が適正なのか判断すればいいの？

と思うわけです。

総務省にも相談してみようと思う

なので今回、

enひかり側にも、

総務省の電気通信サービスに関する消費者相談窓口へ相談し、見解を確認する予定

と伝えています。

別に、

「enひかりは違法だ！」

とか、

「訴えてやる！」

なんて話ではありません。

そもそも自分は、enひかりを3年以上使っていて、料金面やこれまでの1Gbps回線にはかなり満足していました。

今回もサポート自体はちゃんと調査して回答してくれている。

だから、

enひかりを攻撃したいわけでは全然ない。

問題に感じているのは、

サービスの仕様として存在する大きな制限を、利用者が事前にも利用中にも実質的に把握できない状態で良いのか？

という部分。

規約に書いてある。

HPに書いてある。

というのは分かります。

でも実際に何ポート使えるのかは分からない。

使用量も見えない。

上限が近いかも分からない。

そして上限を超えた結果として、

普通のWeb閲覧まで使えなくなる。

今回みたいなケースを、

「利用者が事前に十分理解した上で契約を選べる状態だった」

と言えるのか？

これはちょっと、

第三者である総務省側の見解も聞いてみたいと思っています。

ここまでの時系列を一回整理

長くなってきたので一度まとめます。

9月14日16:55

enひかりへIPv4瞬断の詳細を報告。

↓

9月14日17:33

更にXG-100NEのLAN4（10GbE）が完全通信不能になった事を追加報告。

ただしLAN1～3でもIPv4瞬断は発生。

↓

9月16日11:35頃

後の回答で、この時刻にウチの契約がポート上限へ到達していた事が判明。

↓

9月16日11:39

enひかりから、

「可変IPサービスにおける払い出しポート数の上限に達している」

との初回回答。

↓

NTTがXG-100NEを新品交換。

LAN4は復旧。

↓

9月16日23:32頃

新品XG-100NEでもIPv4瞬断再発。

ping、nslookup、curlでIPv4通信失敗を確認。

↓

9月17日13:42

XG交換後も障害が再発した事と詳細ログをenひかりへ追加報告。

↓

9月17日21:06

ポート上限とは具体的に何なのか、設備全体なのか契約単位なのか等を質問。

↓

9月18日15:03頃

enひかり側で再びウチの契約がポート上限へ到達していた事を確認。

↓

9月19日10:02

enひかりから、

「1契約ごとのTCP/UDPポート上限で間違いない」

「上限到達によるIPv4通信制限は仕様上想定された動作」

「一般利用を想定して必要十分なポート数を割り当てている」

との正式回答。

↓

9月19日17:39

執事885から、

具体的上限値、利用状況を確認する方法、一般利用の想定、契約前説明、設定変更の有無等を更に質問。

総務省への相談も予定している旨を通知。

↓

9月19日23:40頃

再び従来と同様のIPv4瞬断が発生。

9月18日以降しばらく症状を確認していなかったものの、恒久的に改善していたわけではないことが判明。

なお、この瞬断発生時刻にポート数上限へ到達していたかについては現時点では未確認。

↓

現在回答待ち。

まとめ

というわけで、

長いこと追いかけてきた、

enひかりクロス＋XpassのIPv4瞬断問題。

ようやく、

「可変IPv4で1契約に割り当てられているTCP/UDPポート数の上限へ、実際に到達していた」

という具体的な事実まで辿り着きました。

正直、

最初からこれが分かってれば、

XG-100NEのSPIタイムアウトがどうとか、

DNSがどうとか、

MTUがどうとか、

2時間おきのDHCP更新がどうとか、

あんなに追い回してないｗ

ただ、そこまで色々切り分けたからこそ、

今回の回答を見て、

「あー、それなら確かに今までの挙動と合うわ」

とも思える。

でも同時に、

その上限が利用者から全く見えないのはどうなの？

という新しい疑問も出てきました。

そしてこれ、

自分だけの特殊事例ならまだいい。

でも今後、

スマート家電、

防犯カメラ、

ゲーム機、

PC、

スマホ、

タブレット、

テレビ、

その他IoT機器、

なんかが家庭内にどんどん増えていけば、

同じところに引っ掛かる家庭が出てきても全然おかしくないと思うんですよね。

しかもその時、

利用者側から見えるのは、

「なんかInternetが時々繋がらない」

だけ。

これ、原因分からんて。

10Gbps回線にしたら、通信速度よりIPv4のポート管理に詳しくなるとは思わんかったわｗ

enひかりから次の回答が来たら、

具体的なポート上限や、

今回何か設定変更が行われたのか、

そして契約時の説明についてどういう回答になるのか、

また続きを記事にしたいと思います。

それと総務省にも一度相談してみる予定。

さて、

このシリーズ、

一体どこまで続くんでしょうかね(´・ω・`)

光クロス(10Gbps回線）のXpassとXG-100NE運用でipv4が瞬断する問題についてあれこれ検証

XG-100NE交換後もIPv4瞬断が再発。Xpass（DS-Lite）のAFTR・CGN側を疑って調査中

enひかりクロス XpassのIPv4瞬断とポート上限問題。10Gbps化後に通信品質が低下した件を総務省にも相談予定

XG-100NE交換後もIPv4瞬断が再発。Xpass（DS-Lite）のAFTR・CGN側を疑って調査中

執事885 — Thu, 17 Sep 2026 05:20:48 +0000

こんばんは、執事です。

今回は、

光クロス(10Gbps回線）のXpassとXG-100NE運用でipv4が瞬断する問題についてあれこれ検証

この記事の続き。

前回、en光クロスに変更してから続いている謎のIPv4瞬断について色々切り分けをしていたところ、

XG-100NEのLAN4（10Gbpsポート）が完全に通信できなくなる

という、なんとも分かりやすい故障っぽい症状まで出てきました。

LAN1～3の1Gbpsポートなら繋がる。

LAN4だとリンクアップのログ自体は出る。

でも、192.168.1.1のXG-100NE管理画面にすらアクセスできない。

いや、もうお前が原因やろ(´・ω・`)

と思うじゃないですか。

で、NTTに来てもらってXG-100NEそのものを交換してもらいました。

これで全部解決！

……すると思ってたんですけどね。

XG-100NEを新品交換。LAN4は復活した

NTTの業者さんに来てもらい、XG-100NEを交換。

まず、完全に通信できなくなっていたLAN4（10Gbpsポート）は普通に使えるようになりました。

なので、

旧XG-100NEのLAN4側には、少なくとも何らかの不具合があった可能性が高そう。

これはこれで交換してもらって正解だったと思います。

LAN4からASUS RT-BE18000へ繋ぎ、

PCからXG-100NEの管理画面にもアクセスできる。

インターネットも繋がる。

よし。

これで長かった障害調査も終わりかな？

と思いながら使っていたんですが……。

交換したXG-100NEでもIPv4が落ちた

また落ちた(´；ω；`)

症状は交換前とほぼ同じ。

IPv4側のサイトが突然開かなくなる。

でもIPv6側は普通に通信できる。

以前は障害に気付いてからコマンドを打っている間に復帰してしまうことも多かったんですが、今回はちょうど症状が出ている真っ最中に確認できました。

使ったのは前回と同じく、

ping -4 8.8.8.8 nslookup www.yahoo.co.jp 8.8.8.8 curl -4 -I https://www.yahoo.co.jp/

結果はこちら。

まず、

ping -4 8.8.8.8

は連続タイムアウト。

その後、何も再起動していないのに突然19ms程度で応答が戻る。

次に、

nslookup www.yahoo.co.jp 8.8.8.8

こちらもタイムアウト。

これはXG-100NEやプロバイダから配布されたDNSではなく、

Google Public DNSの8.8.8.8を直接指定

しています。

なので、

「XG-100NEのDNS Proxyがおかしいだけ」

とか、

「en光側のDNSサーバーがおかしいだけ」

という話ではなさそう。

更に、

 curl -4 -I https://www.yahoo.co.jp/

も、

 curl: (28) Failed to connect ...

となって約21秒で失敗。

つまり今回は、

IPv4のICMP、DNS、HTTPSがまとめて一時的に通信できない

という状態を確認できました。

新品交換しても再発したという事はどういう事なのか？

ここが今回一番大きいところ。

交換前までは、

XG-100NEのDS-Lite処理がおかしい？
XG-100NE内部のSPIやNAT周辺がおかしい？
LAN4まで死んだし、やっぱり本体故障？
Xpass側の設備がおかしい？

と、色々候補がありました。

ところが、

XG-100NE本体を交換しても同じIPv4障害が再発した。

こうなると、

「前のXG-100NE個体だけが壊れていた」

では説明しづらくなります。

もちろん、

同じXG-100NE、同じファームウェア、同じDS-Lite機能を使っているので、

XG-100NEという機種共通の処理やソフトウェア側に何かある

という可能性までは消えません。

でも少なくとも、

旧XG-100NE固有の個体故障だけが原因

という線はかなり薄くなりました。

LAN4が死んだ件とIPv4瞬断は、

もしかすると別件だったのかもしれません。

改めてXpass（DS-Lite）の通信経路を考えてみる

ここで、そもそもIPv4通信がどこを通っているのかを整理。

自宅側は、

PC → ASUS RT-BE18000 → XG-100NE → ONU → NTT東日本のフレッツ網 → Xpass側 → Internet

という流れ。

ASUS RT-BE18000はAPモードなので、今回のIPv4 over IPv6処理をしているわけではありません。

IPv4通信の場合はXG-100NE側でIPv4パケットをIPv6の中にカプセル化して、

Xpass側のAFTRまで運びます。

ざっくり書くと、

 IPv4通信 → XG-100NE → IPv4パケットをIPv6内にカプセル化 → NTT IPoE網 → Xpass → AFTR → IPv6の殻を外す → CGN/NAT → IPv4 Internet

みたいな感じ。

一方でIPv6通信は、

 IPv6通信 → XG-100NE → NTT IPoE網 → IPv6 Internet

という感じで、IPv4通信で必要になるAFTRやIPv4用のNAT処理を通りません。

で、今回の症状は、

IPv4が止まっている時でもIPv6サイトは普通に見られる。

つまり、

光回線全体が落ちているとか、

Wi-Fiが切れているとか、

XG-100NEとASUS間のLANが死んでいる、

という感じではない。

IPv4 over IPv6固有部分が怪しい。

という切り分けになってきます。

NTTの業者さんから気になる話を聞いた

今回XG-100NEを交換しに来てくれた業者さんと話していた時に、

ちょっと気になる話を聞きました。

enひかりから届いた前回の調査結果

XG-100NE交換前にenひかりへ障害報告を出していました。

その回答がこちら。

以前頂いていたトレース情報で調査完了しました。

該当時間帯にて弊社にて工事故障情報はございませんでした。

また、クロスパス設備を確認いたしましたが、調査時点にて異常は見受けられません。

なお、お手数をおかけいたしますが、次回事象発生時につきましては、

通信元から通信先への経路だけでなく、通信先から通信元への経路を含めた、

双方向のトレースルートをご確認いただきますようお願いいたします。

ここでちょっと気になったのが、

「調査時点にて異常は見受けられません」

という部分。

今回の障害は自然復旧します。

例えば、

 23:32 障害発生 23:34 復旧 翌日 調査 → 正常

なら、

その時点で正常なのは当然なんですよね。

知りたいのは、

障害が発生していた2026年9月16日の23:32～23:34の間にXpass側設備で何が起きていたか。

です。

交換後の再発を受けてenひかりへ再調査を依頼

そこで今回、

XG-100NEを新品交換した後でも同じ障害が発生したことと、

障害発生中に取得したログを追加してenひかりへ連絡しました。

送った内容はこんな感じ。

XG-100NE本体を新品交換後も同一のIPv4通信障害が再発。

障害発生中に、

ping -4 8.8.8.8
→複数回タイムアウト

nslookup www.yahoo.co.jp 8.8.8.8
→Google DNSを直接指定してもタイムアウト

curl -4 -I https://www.yahoo.co.jp/
→約21秒後に接続失敗

を確認。

DNSだけではなくIPv4のICMP・DNS・HTTPSが同時に通信不能となっている。

発生時刻は2026年9月16日23:32～23:34頃。

調査時点の正常・異常だけではなく、障害発生時刻について、クロスパス側の収容設備、AFTR、CGN/NATセッション、IPv4出口設備等にパケットロス、セッション異常、設備負荷、収容逼迫等の記録がないか確認してほしい。

という内容。

これまでよりかなり具体的な情報は渡せたと思います。

「双方向のtraceroute」って一般ユーザー側で取れるの？

あと、enひかりから言われた、

「通信先から通信元への経路を含めた双方向のtraceroute」

について。

自宅からGoogleなら、

 tracert -4 8.8.8.8

で調べられます。

でも、

 Google → 自宅

のtracerouteは、

Google側からコマンドを実行できないと普通は取れません。

しかもDS-Liteでは、

自宅の192.168.1.xというIPv4アドレスがそのままInternetに出ているわけではなく、

Xpass側のAFTR/CGNを経由してグローバルIPv4を共有しています。

なので、

「通信先から自宅までの逆tracerouteを取ってください」

と言われても、

具体的にどうやって？(´・ω・`)

となる。

なのでこの点についても、

具体的にどのサービスや測定方法を想定しているのか、enひかり側へ確認しています。

IPv6セキュリティログにも障害時間帯の記録があった

ちなみにXG-100NEのログをもう一度細かく見ていたところ、

2026年9月16日23:32～23:34頃、

IPv6のセキュリティログにSPIで破棄されたパケットが複数記録されていました。

※ここにIPv6セキュリティログ画像

最初、

「これ、今回の障害と関係ある？」

と思ったんですが、

送信元IPv6アドレスをXG-100NEの端末接続ログから逆引きしてみると、

自分が障害調査に使っていたWindows PCではなく、

別のAndroid端末でした。

しかも、おそらく外出中の家族のスマートフォン。

なのでこのIPv6 SPIログについては、

現時点では今回のIPv4障害との直接的な関連は確認できていません。

同時刻だったから気にはなりますが、

SPIログが出た＝今回の原因、

と決めつけるのは早そう。

ここは一旦保留です。

現在のところ一番疑っている場所

今までの切り分けを全部並べると、

 PC・スマホ → ASUS RT-BE18000 → XG-100NE → NTTフレッツ網 → Xpass → AFTR / CGN → IPv4 Internet

このうち、

ASUSはAPモード。

XG-100NEへのLAN内pingは正常。

XG-100NEは新品交換済み。

IPv6通信は障害中も使える。

でもIPv4側だけ、

ping、

DNS、

HTTPS、

が一時的に失敗する。

となると、

今のところ個人的には、

XpassのDS-Lite固有部分、特にAFTR/CGN周辺またはその先のIPv4出口側

がかなり気になっています。

ただし、

まだ「Xpass設備が原因」と断定できる証拠まではありません。

XG-100NEという機種共通のDS-Lite処理に何かある可能性も残ります。

なので今は、

犯人を決める段階じゃなくて、逃げ道を一個ずつ潰してる段階。

って感じ。

まとめ

今回分かった事としては、

XG-100NEのLAN4不具合については、本体交換で復旧しました。

ただし、

肝心のIPv4瞬断は新品XG-100NEへ交換しても再発。

なので、

「XG-100NEの旧個体が壊れていただけ」

では説明できなくなりました。

そして今回は障害発生中に、

 IPv4 ping → timeout Google DNS直接指定 → timeout IPv4 HTTPS → timeout

というログも取れた。

一方でIPv6通信は利用できる。

となると、

DS-LiteでIPv4だけが通る経路、

特にXpass側のAFTR、CGN/NAT、IPv4出口設備周辺はやっぱり気になります。

enひかりには障害発生時刻を指定して、

その瞬間の設備負荷やセッション異常まで見てもらえないか

と再調査を依頼中。

いやぁ……、

最初は、

「Wi-Fiかな？」

「DNSかな？」

「ASUSかな？」

「LANケーブルかな？」

「XG-100NEかな？」

とかやってたんですが、

まさかここまで長引くとは思わなかった。

10Gbpsにして速くなったはずなのに、回線障害の勉強ばっかり詳しくなっていく(´；ω；`)

まぁでも、

ここまで来たら最後まで原因を追ってみます。

enひかりからクロスパス側の調査結果が返ってきたら、また続きを書こうと思います。

光クロス(10Gbps回線）のXpassとXG-100NE運用でipv4が瞬断する問題についてあれこれ検証

enひかりクロス XpassのIPv4瞬断の原因がほぼ判明。DS-Liteのポート数上限到達でWeb通信まで失敗していた

enひかりクロス XpassのIPv4瞬断とポート上限問題。10Gbps化後に通信品質が低下した件を総務省にも相談予定

光クロス(10Gbps回線）のXpassとXG-100NE運用でipv4が瞬断する問題についてあれこれ検証

執事885 — Mon, 14 Sep 2026 15:44:35 +0000

こんばんは、執事です。

今回は、

enひかりクロス(10GB回線) XpassでASUSのルーターRT-BE18000は使用可能！あと、開通時のトラブルのお話。

こんにちは、執事です。今回は、この時にプロバイダ変更をして安価に、且つ速くなった我が家のインターネットを更に爆速にすべく、ネット環境をenひかりクロス Xpassにした事と、enひかりクロス Xpass接続方式でASUSのルーターは使える！...

続・enひかりクロス(10Gbps回線) Xpassで今度はWAN(0) Connection: WAN was restored.連発事案発生　XG-100NE側でもトラブルが…

こんにちは、執事です。今回は前回のこの記事の続きです。いや、あの後も色々ありまして。すったもんだしてるんですよ…。ASUS　RT-BE18000を外部との切り分けルーターとして使うのを辞めましたまずは、ここから。前回、NTT側からの切り替え...

続・続・enひかりクロス(10Gbps) Xpassで接続が不安定、遅くなる原因判明。ひかりクロス(10Gbps回線)利用者は即この対応をした方が良いです。

こんにちは、執事です。これらの記事から続いた光クロスの件、やっと決着です。いや、まぁ、思い返せば確かにそうかも、とは思うけど、まさかここまでとは思わないじゃん。完全ではないにせよ、回線が10Gbpsになるというなら、同時に扱うデータ量が10...

これらの記事の続きです。

ファンを取り付けて落ち着いたと思ったんだけど、やっぱり瞬断が発生する。

しかも、主にipv4接続でのみ発生。

Xpass(DS-Lite)ではIPv6はIPoEでそのまま通信し、IPv4はDS-LiteによってIPv4パケットをIPv6の中にカプセル化して運びます。

そのIPv4パケットをXpass側のAFTRで取り出し、IPv4側へNATして通信するので、その辺の処理でトラブルが起きているのかな？

つまり、Xpassをやめて別のIPv4 over IPv6方式に変更しないとダメなのかな？

とか思ってたんですが、色々調べてみるとXG-100NEの方が相当に怪しい感じで…。

発生している障害について

まず、発生している障害と状況について書くと、

en光クロス(10Gbps)でインターネットを使用していると主にipv4のサイトが突然遅くなる→開かなくなる
ipv6対応のサイトだと普通に繋がる
ASUSのRT-BE18000をAP設定で無線LAN機器(192.168.1.2）として使用
XG-100NEをホームゲートウェイとして使用（ひかり電話の為に必要だった）
XG-100NE管理画面のルータ設定→高度な設定内で「省電力型イーサネット機能」は無効
ipv4が落ちている時にping -4 -t 192.168.1.1のログを見ても障害無し（ASUS⇔XG100NE間のLANに問題なし）
XG-100NEのLAN側はLAN1~3(1Gbps)でもLAN4(10Gbps)でも同じように瞬断は発生する。
XG-100NE⇔ASUS間のLANケーブルは、cat6Aを使用（当初はCat7にしてたけど変えた）

バッファローツメの折れないLANケーブルモデム用カテゴリ6a ストレートフラットタイプブラック BSLS6AFU10BK

バッファロー

絶対にツメの折れないLANケーブル!!持ちやすく挿抜しやすいケーブル。

といった感じ。

この瞬断の厄介な所は、完全にランダムなタイミングで来る事。

そして、暫くリロードを繰り返すとその内復帰するので、XG-100NEの再起動をしなくても一応戻る。

この障害は7月にen光1Gbpsからen光クロス(10Gbps)に変更して間もない頃から発生していたけど、前述の記事のようになんやかんややってたらちょっと落ち着いていた。

けれど、8月くらいから頻度がどんどん上がっていって、今では一日に10回は落ちる様になってしまったので、これはいよいよちゃんと調べないと、と思った次第。

ipv4とipv6の接続状況を体感ではわかっていたけど、ちゃんと切り分ける。

まず、瞬断が発生するタイミングが読めないので、いつ発生してもわかるように2つのコマンドを使う。

ping -4 -t 8.8.8.8

ping -6 -t 2001:4860:4860::8888

`ping -4 -t 8.8.8.8` の意味

-4：強制的に IPv4 プロトコルを使用して通信を行う。
-t：ユーザーが手動で停止する（Ctrl + C を押す）まで、無制限にpingを送信し続ける。
8.8.8.8：宛先となるGoogleパブリックDNS（IPv4アドレス）。

つまり、「IPv4を使って、止めるまでずっとGoogleのDNSサーバーへ通信テストを続ける」という事。

`ping -6 -t 2001:4860:4860::8888` の意味

-6：強制的に IPv6 プロトコルを使用して通信を行う。
-t：上と同様、手動で停止するまで無制限にpingを送信し続ける。
2001:4860:4860::8888：宛先となるGoogleパブリックDNSの IPv6アドレス。

これらを使って取れたログがこちら。

←のipv6はちゃんとpingは通っているけど、→のipv4はタイムアウトしているのがわかる。

そして、ipv4がタイムアウトしていてもipv6は接続が継続しているのもわかる。

これと前提条件を合わせると、

XG-100NE → Ds-Lite → Xpass AFTR → IPv4 Internet

のどこかが怪しいな、って目星はついたわけです。

一体どの辺までルーティングできているかを調べる

次に使うコマンドがこちら。

tracert -4 8.8.8.8

`tracert`コマンドの意味

tracert：宛先までに経由するネットワーク経路（ルーターなど）を追跡（Trace Route）するコマンド。
-4：強制的に IPv4 プロトコルを使用して経路を追跡する。
8.8.8.8：追跡の宛先となるGoogleパブリックDNS（IPv4アドレス）。

つまり、「IPv4を使って、自分のパソコンからGoogleのDNSサーバーに届くまでに、どのネットワーク機器を経由しているかを調べる」という事。

主な用途と使い方

通信の遅延や切断箇所の特定：インターネットが重いときや繋がらないときに、どこまでの経路が正常で、どこから先に問題があるのかを切り分けるために使います。

で、これがそのログ。

これを見ると、←のtracertのタイムアウトと、→のpingのタイムアウトが重なっているものの、最終的に17msで繋がってはいる。

tracertでは途中に*が出ていますが、途中のルーターがTracerouteへ応答しないだけの場合もあるため、これだけで障害箇所とは判断できません。

最終的には8.8.8.8まで到達していました。

この時点では「IPv4経路が完全に消えているわけではなさそう」というところまでしか判断できませんでした。

ipv4サイトであるyahoo.co.jpを使ってもうちょっと条件を加えて調べる

次に使うコマンドがこちら。

curl -4 -I https://www.yahoo.co.jp/
nslookup www.yahoo.co.jp 8.8.8.8

`curl -4 -I https://www.yahoo.co.jp/ の意味`

Webサーバーが正常に応答しているか、HTTPヘッダー（ステータスコードなど）を確認するコマンド。

curl：ネットワーク経由でサーバーとデータを送受信するコマンド。
-4：強制的に IPv4 プロトコルを使用。
-I：Webページの本棚（本文データ）は取得せず、サーバーの応答ヘッダー情報（HTTPステータスコードなど）だけを取得する。
https://www.yahoo.co.jp/：アクセス先のURL（Yahoo! JAPAN）。

つまり、IPv4でYahoo! JAPANへHTTPS接続し、HEADリクエストに対してHTTPレスポンスが返るか確認するコマンド。

`nslookup www.yahoo.co.jp 8.8.8.8の意味`

ドメイン名からIPアドレスを引く（名前解決）ためのテストを行うコマンド。

nslookup：DNSサーバーにドメインの情報を問い合わせるコマンド。
www.yahoo.co.jp：調べたいWebサイトのドメイン名。
8.8.8.8：問い合わせ先として指定したDNSサーバー（この場合はGoogleパブリックDNS）。

「普段使っているプロバイダなどのDNSではなく、GoogleのDNSサーバー（8.8.8.8）に直接『www.yahoo.co.jpのIPアドレスを教えて』と問い合わせる」という意味。DNSが正常に機能しているかをテストしたいときに使う。

で、これのログがこちら。

障害そのものは瞬断で変わらないんだけど、色々やっている内にログの内容が変わった部分があります。

今までは瞬断発生してからpingを飛ばしてタイムアウトのログが発生するのを確認していましたが、-ｔでpingを流し続けたら、ipv4のpingの応答はあるけど、ipv4サイトに繋がらないっていう状態が確認できるようになりました。

IPv4自体が完全に落ちているのではなく、少なくとも確認したIPv4上のTCP/UDP通信が一時的に成立しない状態。

テスト	プロトコル	障害時
`ping -4 8.8.8.8`	ICMP/IPv4	正常 17ms
`nslookup ... 8.8.8.8`	UDP/53中心	失敗
`curl -4 Yahoo`	TCP/443	失敗
ブラウザ Yahoo	TCP/QUIC等	開かない→何度かで開く

IPv4の経路そのものが消えているわけではないっぽい？

ICMPはDS-Liteを通って普通に往復できているのに、TCP/UDPの新規セッションが一時的に通ってない？

DS-Liteのセッション/NAT状態に関係する不具合かな？

PC
↓
ASUS（AP）
↓
XG-100NE
↓
IPv6網
↓
DS-Lite AFTR
↓
IPv4 Internet

この流れで繋がるはずなんだけど、ICMPが通っている以上、XG-100NE→IPv6網→AFTRまで全部死んでいるわけじゃなくて、

新規TCP/UDPフローの確立・転送に関係する処理がおかしくなっているっぽい。

リロードを繰り返すと自然復旧することから、障害が継続固定しているのではなく、断続的に発生していることは分かる。

Yahooを何回かリロード
↓
ある時突然開く

そして同じ時間でも、

pingはずっと17ms

なので症状としては、

「パケットが全部落ちる」ではなく「一部の新規フローが作れない／作りにくい」

の可能性が高そう。

XG-100NEのログについて

XG-100NEの障害ログ、通信ログ、経路情報取得ログ等も確認しました。

障害発生時間帯にWANリンクダウン等の明確な回線断を示すログは確認できていません。

DHCP関連では、WAN側IPv4アドレスのリース延長要求およびアドレス割り当てが約2時間間隔で記録されていますが、この時刻と実際の通信障害発生時刻は一致しておらず、リース更新直後も正常に通信できていることを確認しています。

つまり、ログ上で障害になってそうなものは何も記載が見当たらない状態でした。

ここまでの切り分けの結果としてen光に送った内容

・ASUS RT-BE18000(192.168.1.2)はルーターモードではなくAPモードで使用
・XG-100NEへの有線接続でも現象を確認
・障害中でもXG-100NE（192.168.1.1）へのLAN内通信は正常
・IPv4の8.8.8.8へのICMP pingは正常な状態でも、IPv4 TCP/UDP通信が失敗することがある
・IPv6通信は正常なケースが多い
・XG-100NE再起動により一時的に改善する
・しばらくすると自然復旧する場合もある
・DHCPリース更新時刻と障害発生時刻には明確な相関なし

以上から、宅内LANやWi-Fiの単純な通信断というより、XG-100NEのDS-Lite処理、またはXpass側のIPv4 over IPv6（DS-Lite/AFTR）通信に関連する可能性を疑っています。

Xpass側設備を含め、該当時間帯の通信状況やセッション等に異常が発生していないかご確認いただけないでしょうか。

障害発生時のping、nslookup、curl等の結果を撮影した画像を添付いたします。

必要であれば、次回障害発生時に追加で実施すべき確認方法・コマンド等をご指定いただければ実施可能です。

よろしくお願いいたします。

って感じで今も絶賛障害対応中。

更に発生した追加の障害

en光に上記の障害報告を済ませて、ヤレヤレと思いながらLANポートを4（10Gbps）に戻したら…。

繋がらない(´；ω；`)

LAN4のままだと192.168.1.1にアクセスしても管理画面すら開かない。

pingを飛ばしてもタイムアウト。

そこでLAN1やLAN2に繋げるとちゃんと開けるし繋がる。

ポートリンクアップ自体は認識されているので、完全な断線ではなさそう。

でも、ケーブル挿してもLEDランプが点灯しない。

これ、

LAN4の10GbE PHY/コントローラ周辺の異常

LAN1/2へ同じ端末・同じ構成で差し替えるだけで192.168.1.1へ接続できるなら、PC→ASUS→XG-100NEという宅内経路そのものは生きてる。差分がXG-100NEのポート側。
10GbEのリンクネゴシエーション異常

LAN4だけ10GbEなので、1GbpsEポートとはPHYもリンク確立処理も異なる。完全故障でなくても、10GBASE-Tのオートネゴシエーションや10GbEのリンクトレーニング周辺で異常があり、リンクアップと判定されても正常なEthernet通信が成立していない可能性。

偶然の可能性もあるけど、

「XG-100NE内部に何らかの不安定要因があり、それが以前は断続的な通信異常として現れ、今回は10GbEポートの完全停止として現れた」

という仮説も無視できない感じ？

まとめ

今回の自分の場合は、LAN4が逝った事も含めてen光のサポートには連絡済。

10Gbps回線で10Gbps使えないなんて本末転倒だから、XG-100NEの交換も並行して動いてもらっています。

あとはサポートからの返事があり次第、また記事にしようと思っています。

XG-100NEについて調べてみると、通信不調や接続トラブルを報告している事例はいくつか見つかりました。

ただし症状や原因はそれぞれ異なるので、今回と同じ原因かどうかは不明です。

今回のケースについては引き続き経過を共有していこうと思います。

XG-100NE交換後もIPv4瞬断が再発。Xpass（DS-Lite）のAFTR・CGN側を疑って調査中

enひかりクロス XpassのIPv4瞬断の原因がほぼ判明。DS-Liteのポート数上限到達でWeb通信まで失敗していた

enひかりクロス XpassのIPv4瞬断とポート上限問題。10Gbps化後に通信品質が低下した件を総務省にも相談予定

enひかりクロス XpassのIPv4瞬断・ポート上限問題を総務省へ情報提供。現在はenひかりの回答待ち

enひかりクロス XpassのIPv4瞬断問題その後。9日待って進捗確認、ポート割当やAFTR/CGNの設定変更は「なし」との回答

こんにちは、執事です。今回は、この記事の続き。前回の記事では、enひかりクロス10G＋Xpassで発生しているIPv4瞬断・ポート上限問題について、総務省へ情報提供。そして、enひかり側にも追加質問を投げて、回答待ち。というところまで書きま...

zepirion（ゼピリオン）のビジネスリュックを購入！自立するし弁当箱も横にして置けるし180°まで開口できるから中へのアクセスも簡単にできます。

執事885 — Sun, 30 Aug 2026 04:25:50 +0000

こんにちは、執事です。

今回は、新しいビジネスリュックを購入したよ、というお話。

３年くらい使っていたビジネスリュックのファスナーの調子が悪くなって、買い替えを考えていたところに丁度自分が欲しかったzepirionが安くなっていたので購入しました。

ビジネスリュックはどれを選べばいい?通勤・PC持ち歩き・出張兼用＆個人の好みで候補を4つに絞ってみる｜執事885

こんにちは、執事です。今回はビジネスバッグの中のビジネスリュックについて、です。ビジネスリュック、PCバッグ、3WAYバッグ。ビジネスにつかうバッグって実はかなりの種類があります。でも、実際に調べてみると、向いている使い方がかなり違...

以前に使っていたものは、もうamazonでも終売しているのですが、弁当箱とか靴を入れられる荷室があるタイプでした。

大容量28Lで、それだけで2泊3日の出張もこなせていました。

それはそれで悪くなかったのですが、普段使いだけで考えるなら大きすぎたので、今度は少し小さ目を選んだ次第。

自分がビジネスリュックに求めた機能

自分がビジネスリュックに求めた機能がこちら。

お弁当箱を横にして置けるか
メイン荷室を180°開けるか
メイン収納へのアクセスは簡単か
折り畳み傘を濡れたままでも入れられる所があるか
800mlの水筒を入れられるか
PC入れは独立しているか
小物入れがメイン以外の場所にあるか
バッグのトップ周辺に車のカギを簡単に出し入れできる場所があるか
USBケーブル系の機能は邪魔だからいらない

大体こんな感じ。

ビジネスリュックに求める機能なんてそれこそ千差万別でしょうが、自分の場合はトップに来るのが弁当箱でした。

以前のバッグはそれを満たす事を基準に選んだので、大きめで弁当箱専用の荷室まで備えたものでしたが、それを3年運用していて思ったのが、

「別に弁当箱を横にして置けるなら別荷室に仕切られてなくていい」

でした。

その為、今回はメインの荷室が大きく開いて＝弁当箱の出し入れを容易にして、且つ余分だったスペースを少し小さくして運用し易いものを選ぼうと思っていました。

いや、28Lってデカすぎなんですよ。

参考までに、そのバッグの画像を置いておきます。

公称縦47㎝、横31㎝、奥行き19㎝だったのですが、実際はもっと大きかったです。

←zepirion →ABIBA

いや、公称値絶対間違ってるでしょｗ

zepirion（ゼピリオン）フラップリュックメンズビジネスリュック Flap Pack

そして、今回購入したのはこちら。

ビジネスリュックメンズ【必要な物にすぐ届くフラップ設計】15.6インチPC 撥水止水ファスナー A4 Zepirion Flap Pack

zepirion

✅【フラップトップ構造で、最短アクセス】上部フラップを開けるだけで中身が一目で確認でき、ファスナーを一周させる手間は不要。PC・書類・小物へ素早くアクセスでき、通常のファスナー式リュックより開閉がスムーズ。閉じれば高い防水性を発揮し、雨の日も安心です。

zepirionのフラップリュックです。

サイズは、45×30×18cm。

重量は、約1.3kg

素材は、1680Dポリエステル複合素材

メイン容量は、約17L

ファスナーは、YKK止水ファスナー、ダブルファスナー式開閉

メイン容量17Lとありますが、大きめの厚みがある荷物は基本的にこのメイン17L内に収める設計です。

で、メインが180°開いて、それを全開するとまるで商品棚みたいに小物を入れるポケットが目の前に現れる感じ。

メインの奥行も15㎝あり、幅も25㎝あるので、大抵のお弁当箱を横にして置けます。

更に結露したものを入れても大丈夫なファスナー付きポケットがサイドに一つあるので、濡れた折り畳み傘もそこに入れられます。

また、PC入れがメインとは別の独立した荷室になっています。

ipadとか入れるなら丁度いい感じ。書類も基本的にここになると思います。

ただ、メイン収納で殆ど奥行を持って行かれているので、そこまで厚いものは入りません。

写真で見るzepirion（ゼピリオン）フラップリュックメンズビジネスリュック Flap Pack

基本的にメインの荷室で収納の殆どを完結させる事ができるリュックになっています。

2枚目が180°オープン時で、3枚目が90°オープン時。

90°オープンでも底まで見る事が可能です。

4枚目の写真ですが、ewinの折り畳みキーボードが縦に、スマスタのペンケースが横に入っています。

Ewin 折りたたみキーボード bluetoothと有線接続ヒンジロック&表示スクリーン搭載日本語配列テンキー付き持ち運び ipadなど用

ewinstore

✅【ヨドバシ・ビックでも取扱実績あり】ヨドバシカメラ・ビックカメラでも採用されるEwinだからこそ、厳しい安全基準をクリアした安心の品質。Amazon限定プライスで、手軽に・お得に。

ソニックペンケーススマ・スタ立つペンケースブラック FD-7041-D

ソニック(Sonic)

スマートにスタンドするペンケース!

ewinのキーボードは縦が12㎝で厚みが2㎝、スマスタのペンケースが高さ20.2cmなので、幅22.2㎝、奥行き12㎝までのお弁当箱なら確実に入ります。(一番下の壁面ポケットをぐっと押せば15㎝あります。）

自分がメジャーで計測した実際のメインコンパートメントの奥行は15㎝、幅は25㎝でした。

で、このメインの正面壁にあたる所のポケットに小物を入れるんですが、これが整理し易くて置き場所を決めやすいので使っていてとても便利。

更に、横のポケットの折り畳み傘ですが、これがピッタリ。

折り畳み傘は28㎝までのものが収納可能です。

そして最後の2枚ですが、荷室をちょっと開けた状態のまま、フラップを閉じる事により、毎回ファスナー操作をしなくても荷室にアクセスできるのがメチャメチャ便利でした。

便利さ素材の良さと頑丈さの引き換えに…

このzepirionですが、この金額の割に使っているパーツや素材の品質が良い。

素材は、1680Dポリエステル複合素材

ファスナーは、YKK止水ファスナー、ダブルファスナー式開閉

フラップの脱着は金属製で磁石タイプ。

どれも値段帯としては2万円代のものから使われだすイメージです。

1680Dポリエステルの特徴は、

① 擦れに強い

② 生地にコシがある

③ ポリエステルなので水を吸いにくい

④ 紫外線にも比較的強い

⑤ 重い

擦れに強いので、毎日使うビジネスバッグ用途としては非常に合理的。

また、太い糸を使っているのでバッグにコシがあって、このzepirionもちゃんと底面を広げたら何も入れてなくても自立します。

また、完全防水ではないですが、素材的に水を吸いにくい。

紫外線にも比較的強い素材です。

ただ、重い。

ぶっちゃけ言って重いです。

17Lで1.3kgというのはサイズ感からしたら重いと感じるのは確実です。

正直言って、女性向けのリュックではない事はお伝えしておきます。

ただ、YKKのファスナーについては動きも防水性も文句無し。

フラップについても操作し易くてとても扱い易いです。

まとめ

というわけで、zepirion（ゼピリオン）フラップリュックの紹介でした。

・お弁当箱絶対入れる

・小物整理をちゃんとしたい＆すぐどれかわかるようにしたい

・折り畳み傘（28㎝まで）収納が欲しい

・毎回ファスナー開閉したくない

・バッグ自立必要

・防水性能必要

代償として重い事だけ認識しておけば、こういった方々にオススメできる良いバッグです。

AMD PCのwifi7子機の選択肢とその速度について　USB接続ELECOM WDC-BE28TU3-BとMediatek MT7927(=RZ738,=MT6639)のどちらの実効速度が上なのか？

執事885 — Mon, 24 Aug 2026 02:35:43 +0000

こんにちは、執事です。

今回は、ちょっと前に新調した自宅のPCのwifiについて。

いままで10年近く頑張ってくれてたSkull CanyonからGMK tecのK12に変更しました。

intelのNUKからミニPCへの引っ越しだったんですが、なんやかんややって、ほぼほぼM.2ストレージの移設とDDR5メモリ16GB×2の購入だけで引っ越しを完了することができました。

メモリやストレージ価格が高騰している2026年7月時点でPC新調とかタイミング最悪でしたが、なんとか安価に済ますことができたのは僥倖でした。

そいでもって、自宅の通信環境をen光クロスに変更したわけですが、

enひかりクロス(10GB回線) XpassでASUSのルーターRT-BE18000は使用可能！あと、開通時のトラブルのお話。

そうなると、問題になるのがwifi子機になってくるんですよね…。

コスパ抜群のミニPC GMK tec K12について

GMKtec K12 ゲーミングミニPC OCuLink搭載 AMD Ryzen 7 H 255（8745HSアップグレード版） Radeon 780M グラフィックスデスクトップ級性能 M.2 2280×3 拡張対応デュアル2.5GbE LAN HDMI 2.1 USB4 ベアボーン/メモリSSD非搭載/OSなし(AMD Ryzen7 255 0GB+0GB)

GMKtec

【OSなしモデル｜自由にカスタマイズ可能】本製品はOS非搭載モデルのため、WindowsやLinuxなど、用途に応じてお好みのOSをインストールしてご使用いただけます。カスタマイズ性を重視するユーザーや、自分に合った構成で使いたい方におすすめです。※初期状態では起動用ストレージが搭載されていないため、OS画面は表示されません。ご使用には別途DDR5メモリおよびSSDのご購入・取り付けが必要です。【メモリ・ストレージ拡張に対応】DDR5メモリ（ Max5600MHz）対応、 Max128GB（64GB×2）まで増設可能。用途に応じてメモリ容量を柔軟に構成でき、作業用・クリエイティブ用途にも対応します。M.2 2280スロットを3基搭載し、 Max24TBまでストレージ拡張が可能です。

自分が購入したのはこのミニPC。

OS無し、メモリ無し、ストレージ無しのモデル。

前述した様に、Skull Kanyonからのお引越しだったので、M.2 SSD 2TBをそのまま移設して、DDR5の16GBメモリ×2を購入して組み上げました。

シリコンパワー DDR5 32GB キット (16GB x 2) 5600MHz (PC5-44800) CL46 1.1V SODIMM Non-ECCノートパソコン RAM コンピュータメモリ SP032GBSVU560F22

SP Silicon Power

DDR5 32GBキット (2 x 16GB) 5600MHz (PC5-44800) CL46 1.1V SODIMM Non-ECCノートパソコン RAM コンピューターメモリ

なんでこのPCにしたかというと、OcuLinkもあって将来的にビデオカードを追加したくなったとしても、それを使ってどんなビデオカードも接続できる拡張性がありつつ、ミニPCなんで省スペースだったから。

USBポートにしてもUSB4.0もあるし、usb3.2もあって、M.2ストレージが3スロットもあるのが特徴的。

普段使いに困らない程度のオンボードグラフィック性能もある。

少なくとも、Steamのメガテン5やったりする程度では困らない位の性能があるのが決め手でした。

でも、実装されているMT7922のwifi性能が6e止まりの5Ghz接続まで、有線も2.5Gポートまでだったので、そこを拡張しようと思った次第。

AMDのCPUに於いてのWifi7子機の選択肢について

さて、このK12に実装されているRyzen7 H255は8745HSとほぼ同じものなのですが、このryzenPCにおけるwifi7のモジュールっていうのが探してみると意外と無い。

intel系列ならBE200

BE 200 NGWネットワークカード、NG FF M.2 WiFi 7カード最大5800 Mbps2.4/5/6 G MU MIMO(WiFi 7カード(アンテナ) (アンテナ内蔵WiFi 7カー)

SkyAloe

高速WiFiカードアダプター:このWiFi 7カードは、574 Mbps、5 Gで2400 Mbps、6 Gで5800 Mbpsのストリーミング、ゲーム、ダウンロードをサポートします。

これでいいのですが、Ryzen系だとドライバの関係でこれが使えません。

ryzen系だと、クアルコムのQCNCM865か

Wi-Fi 7 QCNCM865 Bluetooth 5.4 ワイヤレスカード 5800Mbps トライバンド M.2キーE WiFiカード 4K QAM ノートパソコン Intel AMD 対応 Win 11のみアンテナ付き

OKUZIMI

【Wi-Fi 7 QCNCM865】WiFi 7 QCNCM865 最新のWi-Fi 7規格（IEEE 802.11be）をサポート.2.4GHz/5GHz/6GHzの3バンドに対応し、最大速度は5.8Gbps（理論値）を実現します

MedeatekのMT7927になります。

あとは、外付けUSB式の

エレコム Wi-Fi7 無線LANアダプタ 2880 + 2880 + 688Mbps USB3.0対応 WDC-BE28TU3-B

エレコム(ELECOM)

パソコンに装着することで高速な無線通信を実現するWi-Fi 7 USB 5Gbps(USB3.0)対応 2880Mbps無線LANアダプターです。

エレコムのWDC-BE28TU3-Bみたいなものですね。

まずは、wifiカード交換

左がMT7927で、右がMT7922になります。

端子の足の形が違いますが、挿すときに問題になる事はありません。

実際のメス側の形状は左のMT7927の切り欠き部分と同じ形状になっていますので。

K12のwifiカードとアンテナはこんな風に取り付けられています。

黒と灰色のアンテナ線はスナップオンタイプなので、真っすぐ上に引っ張れば抜けます。（要は、押してパチンと留める服のボタンと同じです）

小さくてやりにくいですが、親指と人差し指の爪で挟んで真っすぐ上に引っ張れば取れます。

つける時も、wifiカードの受け部に押し込むだけです。

ELECOMのWDC-BE28TU3-Bの6Ghz帯の実効速度を計測してみる

既に使用しているELECOMのWDC-BE28TU3-Bの集計リンク速度がこちら。

2882/1921(Mbps)で、このエレコムの最大である2882/2882(Mbps)に近い値になっています。

この前提を元に、各社のスピードテストを行ったら、

大体こんな感じ。

次にMT7927の6Ghz帯の実効速度を計測してみる

…。

おや(・ω・)？

本来なら5774/5774(Mbps)出てないとおかしいのに出ない。

これだと160Mhz帯の値だな、と。

速度計測してみたところ、

性能下のELECOMに負けとるやんけ～(´；ω；`)

MT7927の速度が出ない原因を探ってみる

netsh wlan show interfaces

をコマンドプロンプトに入力して、それぞれの値を見てみました。

MT7927

WDC-BE28TU3-B

どちらも、Rssi（受信電波の強さ）が6ghz帯には厳しい値になっています。

それでも、なぜにELECOM側の方が実効速度が速いかというと、

こんな感じで、USB延長ケーブルを使い、PC本体から離して電波条件の良い高い位置へ設置できているためなんですなぁ…。

まとめ

この後、K12を一階のRT-BE18000がある部屋に持って行ったら、MT7927で5774/5774(Mbps)の値の通信ができる事を確認しました。

結局、このPCを置いている場所が、2階にあって床と壁２枚隔てた場所にある事が問題だったわけです。

今の部屋に置いている限りMT7927の速度がWDC-BE28TU3-Bを超える事はないでしょう。

つまり、今回はwifiカードを購入して、

何の成果もあげられませんでした！！

って感じになってしまった感。

いや、でもいいんだ…。

この記事が誰かに読まれて、

wifi7使うなら、機器性能よりもPC設置場所とルータ間の電波強度と壁と床の枚数が重要！

って事を知ってもらえるなら本望だ…。

次はメッシュ化か…。

トイレの電球用配線をソケットで分岐させて片方のみ無線リモコン動作させる方法

執事885 — Wed, 19 Aug 2026 05:14:41 +0000

こんにちは、執事です。

前回、トイレのガラリを人感センサー付き排気ファンに変えた時にライトも人感センサー式にしたのですが、微妙に運用しづらい。

トイレの角型ガラリをDIYで人感式自動排気ファンに変更したお話　ガラリアタッチメントへの断熱施工も

こんにちは、執事です。今回はお家のお手洗いの排気のお話。ウチのトイレは昔ながらの角型ガラリ（ただの四角い通気口）のみしかなかったのですが、この夏に於いてトイレの暑さが辛い…。一応、ファン付きのLEDライトも電球から置き換えで設置していたので...

入るときにトイレの入り口にあるスイッチをONする、出る時にOFFにするが体に染みつきすぎて家族全員がついつい切らなくて良いスイッチを切ってしまう。

というか、自分もそうだけどなんかスイッチを押す事をやめられない。

結果的に、運用的にスイッチを押す必要はないんだけど、体がスイッチ操作をしたがっているからスイッチ操作を挟む運用に戻した方が良さそうだと判断しまして。

そこで色々調べてこねくり回して、1つしかないトイレの天井の電球ソケット穴を分岐させ、片側は人感センサー排気ファンの為に常時ON、もう片方は天井の電球スイッチの為に無線リモコンでON、OFFできるようにしてみました。

433ｍhzの無線リレーと433mhzの無線リモコンボタン、分岐ソケットを準備する

準備するのはこちらの3点。

上から分岐電球ソケット、左下が433mhzリレー、右下の丸が433mhzリモコンボタンスイッチ。

まず、ソケットですが、なんでこれを選んだかというと配線が剥き出しで加工しやすかったから。

リレーとリモコンが315mhzじゃないのは、どうも110vで使えるのだと433mhzタイプしかなさそうだったから。

ただ、これらの商品が国内だと入手性悪いんですよね。

電球ソケットはある。

Happyyami ライトソケットスプリッター E27 二股電球ソケットアダプター 2個セット LED対応 18cm x 10cm x 3cm 分岐ソケット電球アダプターコンバーター増設照明ガレージ地下室倉庫納戸作業場廊下玄関屋内用取り付け簡単 2個

Happyyami

【照明範囲の拡大】1つのソケットから2つの電球へ分岐させることで、暗いガレージや地下室、倉庫などの照明範囲を劇的に広げることができます。E27口金に対応し、複数のLED電球を同時に点灯させることで、作業スペースを明るく均一に照らします。

リレーとリモコンはamazonにもない事もないんだけど、この433mhzのリモコンとリレーがセットで売られていない。

2個入りワイヤレスライトウォールスイッチ433MHzリレー受信機と1個の2連パネルLEDリモコン（ランプ用）

LYMSXAZOU

製造ロットの違いにより、製品の外観、色、印刷文字に若干の差異が生じる場合がありますが、使用には影響ありません。

このリレーは同一物なんですが、リモコンスイッチが角型で２個セットしかない。

aliexpressなら超安価にあるんですけどね。

ある意味この材料集めが人によっては一番高いハードルになるかもしれません。

実際の加工について

実際の加工そのものは簡単なもので、ニッパーと小さいマイナスドライバーと結束バンドがあればできます。

電球ソケットの分岐の真ん中のキャップを外して配線を取り出す。

スイッチで操作したい側の配線をニッパーで切る。

この画像で言うと右側にリレーを取り付けます。

配線はこんな感じ。

下側が電源ソケット側で、そこからINPUT配線に繋げて、奥側のソケットへの配線をOUT配線に繋げます。

説明書の記載だとこんな感じ。

最後に配線を通す部分だけキャップをニッパーでカットしてキャップを嵌め込んだら加工完了。

リレーは結束バンド150ｍｍ二本を繋げて結束しています。

KT12 433MHz リレーと433MHz round remote EV1527を連携させる方法

このリレーと丸型リモコンを連携させる方法は、

1.分岐ソケットを天井につける
2.リレーについている黒い押しスイッチを二回押す。
3.丸型リモコンスイッチを押す。

これで連携が完了し、リモコン操作ができるようになります。

ちなみに、間違えてリレーを1回押して丸型リモコンを押すと、丸型リモコンを押している時だけON、という設定になってしまうので注意しましょう。

リモコンを常に手に持ちつづけないといけなくなります。

仮にこれで間違って登録されてしまったら、リレーのボタンを8回連打したら設定がリセットされるので、リセット後にもう一度2回押して設定しなおしてください。

実際の運用形態について

トイレの出入り口にある元のスイッチはマステで常時ON状態にしておき、上のONランプの上に100均のネオジム磁石を貼ってその上にリモコンスイッチをセッティング。

これで、この様にリレー側のファン付きLEDランプのみがリモコン操作対象となり、人感センサー付き排気ファンは常時動作となります。

ちなみにこのファン付きLEDライトですが、

【現行モデルは風量アップ】ドウシシャサーキュライトソケットシリーズ E26モデル電球色 60W相当風量3段階リモコン付きホワイト

ドウシシャ(DOSHISHA)

さらに風が強くなりました。角度調節約300度、自在に角度を設定することができる

こちらの商品です。

これの良いところは、スイッチをOFFしても直前の状態を記憶しておいてくれる所です。

例えば、ライト、シーリングファンをONにした状態でスイッチからOFFしても、次にONにしたらライト、シーリングファン共にONになります。

これが安いタイプのファン付きLEDだとそれを記憶できずに、ON、OFFにする度にライトのみON→ファンのみON→ライトとファン共にONをループする事になって運用上不便になります。

まとめ

これで家族全員違和感なくトイレの出入り時にスイッチをON、OFFする形に戻りました。

いや、わかってるんですよ？

所持する電工資格を生かして、人感センサー排気ファン側に電源を追加すればいい、って事は。

VFケーブルだって、3.9mmカメラ＋5ｍケーブルの無線カメラだってあるよ？

でも、でもさ…。

~~面倒くさ~~

時間がなかなか取れなくてね…。

メタクエスト3（Meta quest3）バーチャルデスクトップ（Virtual Desktop)が公式にPCとのUSB接続（有線接続）をサポート開始！

執事885 — Tue, 11 Aug 2026 02:33:25 +0000

こんにちは、執事です。

今回は、メタクエスト3とPCの接続のお話。

自分はメタクエスト3を専ら仕事用のモニター兼PCゲーム（Steam）を寝転がってプレイする用のモニターとして使っている事が多いです。

そして、その際に使っているソフトがVirtual Desktopというアプリなのですが、これが正式にPCとの有線接続をサポート開始しました。

Virtual Desktop 15％割引購入リンク

それがどのような意味を持つのか、というのはメタクエスト3を作業用モニターとして使用している人ならすごく良くわかってくれると思いますが、ものすごく大きな意味があるんですよ！

Virtual Desktop ver.1.34.19から、PCとのUSB接続が解禁！

これができるという事は、メタクエスト3のwifiを切ってもPCとの接続が切れないという事。

これができるという事は、メタクエスト3のバッテリー持ちが良くなるという事。

これができるという事は、インターネット接続はPCのみでいいという事。

これができるという事は、出先でスマホ(テザリング）＋ミニPC＋メタクエスト3＋マウス＋キーボードで作業環境が構築できるという事。

これができるという事は、可搬式モニターとして現状最高に近い画質で作業ができるようになったという事。

これができるという事は、Xreal One Proを別途購入する必要がなくなったという事。

なんだ、オマエ最高かよ！！！

ただ、これを実現するにあたって、

KIWI design リンクケーブル充電可能 4M Meta Quest 3S/3/2/Pro/Pico 4対応 VRアクセサリーブラック

KIWI design

Quest 3/Quest 3S/Quest 2/Pro/Pico 4との互換性:このType C リンクケーブルは、めたくえすとヘッドセットと同時に充電しながらゲームを楽しむために設計されています。USB Aポートをコンピューターに接続し、公式の充電器を専用の充電ポートに差し込むことで、中断のないゲーム体験を実現します。VR ヘッドセットにとって必須のアクセサリーです。

このケーブルだけは必須なんで購入する様に。

また、購入の際、USB2.0を選択しない様に気を付けましょう。

USB3.0以上を選ぶんやで。

外出先で遅延なくV睡したい人とかなら、ここを間違えてはいけません。

モニターとしてのメタクエスト3について

折角なんで、これも書いておこうと思います。

メタクエスト３は2026年夏の時点でヘッドマウントディスプレイとしての解像度は最高峰です。

特に市販品として、現実的に購入できる範囲で考えると圧倒的に画質が良い。

片目:2,064×2,208ピクセル
両目:4,128×2,208ピクセル

という値は伊達ではありません。

現状、同じ目的で考えると出てくるであろうXreal One proだと、

1920×1080ピクセル（1080p、片目）

となり、約倍の解像度となります。

また、レンズもメタクエスト3はパンケーキレンズという高性能なレンズのおかげで、割と雑にかけても焦点が合わない、といった事が少ないです。

だから、IPD（瞳孔間距離）をしっかり設定しなくてもぼやけにくいですし、それどころか、IPDを56～70mmの間で調整する機能までついているので、Xreal One proの様にMサイズかLサイズかで悩む必要がそもそもありません。

更に画像表示範囲である視野角についても、Xreal One Proは水平57°、垂直30°（これでもARグラスとしたら最高峰）に対して、メタクエスト3は、水平110°、垂直96°と、水平で約2倍、垂直に至っては約3倍にもなります。

これを言葉にするならば、

Xreal One Proは目の前に巨大なモニターが浮いている感覚。

Quest 3は視界全体が映像や仮想空間に包み込まれる映画館のような没入感。

Xreal One proは所持していないものの、こういったARグラスの走りである

XREAL AirそっくりのTCL NXTWEAR S レビューレンズ作成やおでこの熱対策、ニンテンドースイッチでの使用方法について

お久しぶりです、執事です。記事作成3ヶ月ぶりです、ヤバいです、仕事忙しいですヤバい:(；ﾞﾟ'ωﾟ'):さて、今回の記事はタイトルの通り、TCL NXTWEAR S　について。巷間話題の XREAL Air(旧 Nreal Air)とそっく...

このTCL NXTWEAR Sは持っているのですが、比較すると文字の大きさ、6DoFによる画面の縮小拡大まで対応するメタクエスト3の方が圧倒的な解像度です。

Prime Videoをスマホ経由で見るくらいならARグラスでも良いと思うのですが、エクセル開いたりするなら圧倒的にメタクエスト3の方が見やすいですし、ディスプレイを複数にもできるので作業効率も上です。

まぁ、そもそもPrime Video見るとかなら、メタクエスト3だけで完結するんですけどね。

そして、自分もそうなのですがド近眼の人用の処方レンズについても、

Favotem Meta Quest3と互換性のあるオーダーメイド専用度付きアタッチメントセット近視遠視乱視プリズム対応 (反射防止＋汚れ防止コート)

Favotem

対応度数をご確認のうえご注文後に必ずご希望のレンズ度数を別途当店までメールにてご連絡ください。メールアドレス:amagasaki@shop-ai.jp

メタクエスト３用の方が安価に作成できます。

また、メタクエスト3を装着していたとしても、パススルー機能のおかげで、周囲の状況も見えるので手元のキーボードやメモを見る事もできます。（カメラ越しなんで、多少ぼやけますが）

つまり、一番画質が良い可搬式モニターを選ぶなら、値段から見ても現状最もコスパの良い選択肢と言えるわけですね。

ただし！

装着している時の外からの見た目については、Xrealなどのサングラス型のものよりもはるかにケッタイな見た目になるので、そこだけ気になる人は気になるかもしれません。

まぁ、ホテルの部屋とかならそんなん気にする必要ないんですけどね。

カフェとかでやるなら勇気は要るでしょうが。

Virtual Desktop ver.1.34.19の有線接続の方法について

手順としては簡単です。

1.PC側にstreamer ver1.34.19をインストール

2.メタクエスト3側に ver1.34.19をインストール（スマホアプリからbeta選択）

3.メタクエスト内のLink設定から、USB接続をONにする

4.virtual desktopのsettingからUSB Connectに☑を入れる

5.PCに有線でつなぐ。

これだけ。

ただ、やっていて微妙にわかりづらい部分が結構あったので、そこをちょっと追記しておきます。

まず、1については、リンク先を設定しているので、上のリンクを踏んだらダウンロードが勝手に始まります。

2については、スマホアプリから選んだ方が早いです。

この様に選択したら、アプリ側でエラー画面がでるかもしれませんが、ここで選択した後にメタクエストを開くと勝手にメタクエストに1.34.19verがダウンロードされます。

3については、メタクエスト内で

赤丸の部分をONにすればOK。（ミラーリングスクショなんで画像が斜めってますが）

4については、Virtualdesktop内のSettingで、

Allow to connect over USB にチェックを入れたらOKです。

あとは、PCとメタクエストをケーブルで接続したら、勝手にUSB接続してくれます。

ちなみに、USB接続か否かの判別ですが、同じPCに対してもUSBマークがある接続とethernet接続で接続先が別に表示されるので、一目でわかります。

尚、確実にUSBの有線接続をしたい場合は、Setting のAuto connect のチェックを外しておいた方がいいかもしれません。

Autoだと、PCに有線接続する前に勝手にwifi接続で接続しちゃう事もあるので。

まとめ

ついにやってきた公式のVirtual Desktop有線接続。

これがず～っとできなかったせいで、メタクエスト3を作業用可搬モニターとして使い倒せずにいました。

でも、これができる様になったおかげで、Xreal One proやRay neoといったARグラスの上位互換機として使用できるようになりました。

XREAL One Pro ARグラス｜X1チップ＆X-Prism光学搭載｜ネイティブ3DoF対応｜3Dリアル変換機能｜57°の広視野角・最大428インチ相当・FHD・最大120Hz表示｜iPhone 17/16/15（※eシリーズ除く）、Steam Deck、ROG、Mac、PC、Android & iOS対応｜IPD（瞳孔間距離）に合わせた2サイズ展開［M (IPD 57-66mm)］

XREAL

【新搭載「X Prism」光学エンジンで、AR映像体験がさらに進化】 XREAL独自開発の超薄型光学システム「Optic Engine 4.0」により、57°の広視野角で、最大428インチ相当のバーチャルスクリーンを鮮明に投影。現実の風景を視認しながら、没入感ある映像体験を実現します。さらに、反射や光の干渉を抑えるアンチグレア設計により、クリアな視界を維持。

サイズや重さ、見た目は不利ですが、画質と視野角、IPDの調整自由度はこちらが圧倒的に上なので、作業のみを突き詰めるなら、可搬式モニターとしてはメタクエスト3が最高の環境となります。

あ、それとSteamでゲームをした時の遅延についてですが、PCとルータの接続が無線環境の人だったら、圧倒的に有線がおススメです。

メガテン5をやっていた時にあった遅延が全くなくなりました。

本来、Virtualdesktop自体がルータとPCの接続は有線で、PCとメタクエストの接続は無線で、としていたのですが、PCとメタクエスト間が有線、ルータとPC間が無線でも遅延は感じられませんでした。

ですので、

「家でも無線じゃないとPCに繋げない環境なんだ！」

といった人にも、今回のVirtual Desktopの有線式対応は最高のアップデートになると思います。

885番目の執事(butler885)

enひかりクロス XpassのIPv4瞬断問題その後。9日待って進捗確認、ポート割当やAFTR/CGNの設定変更は「なし」との回答

9日経ったので進捗確認してみた

質問1～5は、まだ確認中

ただし1つだけ回答が来た

じゃあ、何で一時的に症状が減ったんだろう？

もしかしてenひかり側でも全部は分からない？

今の状況

まとめ

関連記事

enひかりクロス XpassのIPv4瞬断・ポート上限問題を総務省へ情報提供。現在はenひかりの回答待ち

まず総務省の電気通信消費者相談センターへ電話

今回は電話だけで終わらせず、情報受付フォームから送信

総務省へ伝えた内容

「10Gbps出ない」という相談ではない

ポート制限そのものを否定したいわけじゃない

そして連休明けからIPv4瞬断がまた増えている

総務省への送信は完了

今の状況をまとめると

まとめ

関連記事

enひかりクロス XpassのIPv4瞬断とポート上限問題。10Gbps化後に通信品質が低下した件を総務省にも相談予定

enひかりからは「社内確認するので少し待ってほしい」との返答

その間に総務省にも相談してみようと思った

で、総務省に何を相談したいのか？

1Gbpsから10Gbpsへアップグレードしたのに、通信の安定性が悪くなった

速くなったけど「繋がる」が不安定になった

今回は「可用性・接続安定性」の問題

そして、そのトレードオフを契約時に認識できていなかった

総務省には「10Gbps出ない」という相談はしない

ポート上限そのものが悪い、と言いたいわけではない

enひかりを責めたいわけではない

ちなみに宅内側の切り分けも一通りやっています

今はenひかりの回答待ち。総務省へは連休明けに相談予定

関連記事

enひかりクロス XpassのIPv4瞬断の原因がほぼ判明。DS-Liteのポート数上限到達でWeb通信まで失敗していた

XG-100NEを新品交換！LAN4も復活！これで終わり！！

XG-100NEを新品にしても直らないなら、旧XG-100NEだけの故障ではない

そしてenひかりから返ってきた回答

Xpassの可変IPではIPv4アドレスを複数ユーザーで共有している

あれ？これって今までの症状にめちゃくちゃ当てはまらない？

しかも1回じゃなかった

そしてもっと気になったのが「これは正常な仕様です」という回答

じゃあ、その上限って何ポートなの？

「一般的な利用を想定して必要十分なポート数」とのこと

固定IPへ変更してください、と言われても…

そもそも契約時にそんな違いを説明されたっけ？

「HPに書いてあります」「規約に書いてあります」で済ませて良い話なのか？

9月19日23:40、再びIPv4瞬断が発生

enひかりへ更に確認している内容

総務省にも相談してみようと思う

ここまでの時系列を一回整理

まとめ

関連記事

XG-100NE交換後もIPv4瞬断が再発。Xpass（DS-Lite）のAFTR・CGN側を疑って調査中

XG-100NEを新品交換。LAN4は復活した

交換したXG-100NEでもIPv4が落ちた

新品交換しても再発したという事はどういう事なのか？

改めてXpass（DS-Lite）の通信経路を考えてみる

NTTの業者さんから気になる話を聞いた

enひかりから届いた前回の調査結果

交換後の再発を受けてenひかりへ再調査を依頼

「双方向のtraceroute」って一般ユーザー側で取れるの？

IPv6セキュリティログにも障害時間帯の記録があった

現在のところ一番疑っている場所

まとめ

関連記事

光クロス(10Gbps回線）のXpassとXG-100NE運用でipv4が瞬断する問題についてあれこれ検証

発生している障害について

ipv4とipv6の接続状況を体感ではわかっていたけど、ちゃんと切り分ける。

ping -4 -t 8.8.8.8 の意味

ping -6 -t 2001:4860:4860::8888 の意味

一体どの辺までルーティングできているかを調べる

tracertコマンドの意味

主な用途と使い方

ipv4サイトであるyahoo.co.jpを使ってもうちょっと条件を加えて調べる

curl -4 -I https://www.yahoo.co.jp/ の意味

nslookup www.yahoo.co.jp 8.8.8.8の意味

XG-100NEのログについて

ここまでの切り分けの結果としてen光に送った内容

`ping -4 -t 8.8.8.8` の意味

`ping -6 -t 2001:4860:4860::8888` の意味

`tracert`コマンドの意味

`curl -4 -I https://www.yahoo.co.jp/ の意味`

`nslookup www.yahoo.co.jp 8.8.8.8の意味`

zepirion（ゼピリオン）フラップリュックメンズビジネスリュック Flap Pack

写真で見るzepirion（ゼピリオン）フラップリュックメンズビジネスリュック Flap Pack

AMD PCのwifi7子機の選択肢とその速度について　USB接続ELECOM WDC-BE28TU3-BとMediatek MT7927(=RZ738,=MT6639)のどちらの実効速度が上なのか？

メタクエスト3（Meta quest3）バーチャルデスクトップ（Virtual Desktop)が公式にPCとのUSB接続（有線接続）をサポート開始！