AIの群れが家のインターネットを使い切った夜：MAP-Eポート枯渇の記録

自宅でAIエージェントを常時動かしていると、壊れるのはGPUやストレージだけではありません。ある夜、某所ラボでは家中のDNSが分単位で同時に死にました。

回線は10G。実効で見えていた帯域は約3Gbps。数字だけ見ると、まだ余裕があります。それでも新しい通信が通らない。原因は帯域ではなく、MAP-E環境のNATポートプール枯渇でした。

起きたこと

• DNSフィルタ2台が、同じ時間帯に上流DNSへタイムアウトした
• 上流は1.1.1.1と8.8.8.8
• 1〜2分程度のバーストが5回発生した
• 家庭内の複数端末で、同じタイミングに名前解決が不安定になった
• 回線帯域は飽和していなかった

重要なのは、DNSフィルタが2台とも同時に落ちたことです。冗長構成の片側だけなら、個別ノードの不調を疑います。しかし今回は、2台が分単位まで揃って上流へタイムアウトしました。冗長が冗長になっていない。つまり、2台の手前か奥にある共有資源が詰まっている、という手がかりです。

ホームラボのネットワーク全体像やセグメント分けの考え方は、既出のネットワークの土台（セグメント分けと有線/無線・速度の考え方）で整理しています。今回の障害は、その土台の上でさらに外側の出口資源が詰まった例です。

帯域は余っていた

この時点で、所長が最初に見ていたのは帯域でした。10G回線で、実効利用は約3Gbps。単純な速度の観点では、まだ詰まっているように見えません。10G-EPONのONUも、回線契約の名目も、速度だけなら問題の中心には見えにくい状態です。

しかし、インターネット接続の資源は帯域だけではありません。今回の回線はMAP-E、つまりIPv4 over IPv6系の構成でした。MAP-Eでは、IPv4通信で使える外側ポートの範囲が限られます。この環境では、使える外側ポートはおおむね240〜1008個の範囲として扱う必要がありました。

帯域が余っていても、新しいIPv4セッションを張るためのポートが足りなければ、通信は始まりません。特にUDPのDNSは、体感上かなり早く症状に出ます。

犯人はAIエージェントの群れだった

直接の負荷源は、大量並列のAI処理でした。当時はAI処理が18〜20並列で動き、そこに常時収集と監視群が重なっていました。個々の通信は小さく見えても、新規セッションを短時間に大量に作ると、MAP-EのNATポートプールを押しつぶします。

結果として、帯域は3Gbps程度なのに、新しい接続が通らない状態になりました。これは「10G回線なのに繋がらない」という、やや意地の悪い障害です。速度テストだけ見ていると説明がつきません。けれど、同時セッション数と外側ポート数を資源として見ると、かなり素直な現象です。

何が枯渇したのか

家庭内の端末やサーバーは、外に出るときにNATを通ります。MAP-EのIPv4通信では、その外側で使えるポートに上限があります。

大量のAI処理、P2P、スクレイピング、監視、常時収集のように、短時間で多数の通信を作るものは、帯域より先にこのポートを消費することがあります。

観点	一見した判断	実際に効いていた資源
回線速度	10Gなので余裕がある	速度だけでは判断できない
実効帯域	約3Gbpsで飽和していない	帯域は主因ではない
DNS冗長化	2台あるので片系故障には強い	共有出口が詰まると同時に死ぬ
AI処理	計算資源とAPI側の問題に見える	新規セッション数も消費する
MAP-E	普段は意識しにくい	外側ポート数が見えない上限になる

この種の障害では、「通信量が多い」よりも「同時に張る通信が多い」ことが問題になります。

対策1：並列を16から8へ落とす

最初に効いた対策は、AI処理の並列数を半分にすることでした。並列数は16から8へ変更しました。通常なら処理量の低下を疑うところですが、この処理系では別のクォータが律速になっていたため、日次処理量は変わりませんでした。

並列数を上げることは、必ずしも処理量を増やしません。どこか別の制限に当たっている場合、並列数は成果ではなく、家庭内ネットワークへの負債だけを増やします。

所長の運用では、16並列から8並列への変更で、日次処理量を落とさずにNATポート消費のピークを下げられました。これはかなりよい交換でした。

対策2：DNSをIPv6上流へ逃がす

もう一つの対策は、DNSの上流をIPv6側へ逃がすことです。問題はMAP-EのIPv4側ポートプールです。ならば、DNSのような基礎通信は、可能な範囲でMAP-Eを通らない経路へ逃がす価値があります。

DNSが落ちると、実際の通信可否以上に「全部壊れた」ように見えます。名前解決が止まると、ブラウザも、監視も、各種アプリも連鎖して失敗するからです。

DNSをIPv6上流へ寄せるのは、万能薬ではありません。けれど、少なくともIPv4のNATポートプールが詰まったときに、名前解決まで一緒に巻き込まれる確率を下げられます。

向いている対策・向かない対策

今回のようなMAP-Eポート枯渇では、速度を上げるだけでは解決しないことがあります。比較すると、対策の向き不向きはかなり違います。

対策	向いている人	向かない人	見るべき点
AI処理や収集処理の並列数を下げる	日次処理量が別の制限で頭打ちの人	並列数がそのまま成果に直結している人	処理量が本当に落ちるか
DNSをIPv6上流へ逃がす	MAP-EのIPv4側にDNSを巻き込みたくない人	IPv6上流DNSを安定運用できない人	DNSの経路と監視方法
回線や方式を見直す	同時セッション数が継続的に足りない人	まず負荷源を把握できていない人	帯域ではなくセッション数
何もしない	症状が一過性で再発しない人	深夜無人運用を続ける人	再発時に家庭内全体へ波及するか

10G回線を入れていると、つい「足りないならもっと速く」と考えたくなります。しかし今回の詰まり方では、速度の増強だけでは説明が合いません。見るべき数字は、Gbpsだけではなく、同時セッション数とNATポート数です。

メリット・デメリットで見る運用判断

AIエージェントを自宅で常時動かす運用には、明確なメリットがあります。手元の環境で継続処理を回せること、自分の監視・収集・検証を細かく作れること、クラウドだけに寄せない構成を試せることです。

一方で、家庭内ネットワークの出口資源を消費します。深夜に障害が起きると生活側の通信も巻き込みます。帯域以外の上限、特にNATやDNSは見えにくく、冗長化しても共有経路が詰まると同時に落ちます。

つまり、自宅AI運用は「電気代とAPI代を払えば終わり」ではありません。家庭内のNATテーブルにも、静かに請求が来ます。請求書は届きませんが、DNSタイムアウトとして現れます。

再現条件として近いもの

• MAP-E系のIPv4 over IPv6回線を使っている
• AI処理、P2P、スクレイパ、監視、常時収集などが同時に動いている
• 帯域利用率は高くないのに、新規接続やDNSだけが不安定になる
• 冗長化したDNSやサーバーが、なぜか同じ時刻に失敗する
• 速度テストでは問題が見えない

この条件に近いなら、回線速度より先にNATポートと同時セッション数を見たほうがよいです。

失敗から得た運用ルール

• AI処理の並列数を必要以上に上げない
• 16並列から8並列に下げる
• 日次処理量が変わらないことを確認する
• DNSは可能な範囲でIPv6上流へ逃がす
• 10G回線でも、MAP-Eの外側ポート数を別予算として見る

無人運用では、平均値よりピークが問題になります。1日全体では余裕があっても、1〜2分のバーストが5回あれば、家庭内の体感品質は十分に壊れます。

ここで必要なのは、AIを止めることではありません。並列数を成果に対して適正化し、DNSの逃げ道を作り、帯域以外の資源を監視対象に入れることです。

結論：資源は帯域だけではない

今回の障害は、10G回線が遅かった話ではありません。帯域は余っていました。実効で約3Gbps。けれど、MAP-Eの外側ポートという見えない財布が空になり、新規セッション、とくにDNSが先に苦しくなりました。

AIの使いすぎは、token課金だけでなく家庭のNATテーブルにも効きます。自宅でAIエージェントの群れを飼うなら、見るべき予算は計算資源、APIや外部サービス側のクォータ、家庭内ネットワークの同時セッション数です。

10G回線なのに繋がらない。帯域は余っているのにDNSが死ぬ。そういう夜は、速度計だけを見ても足りません。NATポートという見えない財布を、運用設計の表側に出すべきです。所長もそこまでは学習しました。次に忘れないかは、監視の仕事です。