突然発生したネットワークの謎の不調
ある日突然、愛用のM1 Macのネットワークが極めて不安定になりました。症状は以下の通り:
- Claude Code: 起動はするものの、すべてのプロンプトでエラー
- Cursor IDE: GPT-5が途中まで動作して突然停止
- 一般的なWeb閲覧: 正常
- 動画や音楽再生: 正常 当然、最初は一般的なネットワークトラブルを疑いました。
試したこと(効果なし)
- Mac本体の再起動 ✗
- Wi-Fiルーターの再起動 ✗
- Wi-Fiルーターの設定見直し – 問題なし
- ONUの電源入れ直し ✗
- Cursorの再起動 ✗
主にAI利用が制限されているため、AI使いすぎでプロバイダ制限されたのか?と疑心暗鬼になりましたが杞憂でした。
原因は意外なところに…UTM!
一晩寝て冷静になって考えてみると、「いつもと違うこと」を思い出しました。
マクロ付きExcelファイルをどうしても開く必要があり、数年ぶりにUTMでWindows 11を起動していた
しかも、Windows Updateを全適用するために長時間起動したままにしていました。
ifconfigでMacのIPアドレスを確認してみると見慣れないサブネットマスクの192.168.1.10になっていることを確認。
問題の核心:UTMの共有ネットワークモード
UTMのネットワーク設定を確認すると「共有モード(NAT/SLIRP)」になっていました。これをブリッジモードに変更したところ、すべての問題が即座に解決!
なぜ共有モードが問題を引き起こすのか?
1. 二重NAT地獄
インターネット
↓
ルーター (192.168.1.1)
↓ NAT変換 #1
Mac (192.168.1.10)
↓ NAT変換 #2 ← ここが問題!
UTM内部ネットワーク (192.168.64.*/24)
↓
Windows 11 (192.168.64.5)
パケットが2回もアドレス変換されることで:
- 遅延が倍増
- パケットロスが発生しやすい
- 接続が不安定になる
2. UTMのNATエンジンの制限(SLIRP)の詳細
共有モードで使用されるSLIRPエンジンの技術的制限:
同時接続数の上限:
- ARPテーブル:16エントリまで(デフォルト設定)
- NDPテーブル:16エントリまで(IPv6用)
- 実質的に同時接続できるデバイス数が極めて限定的
小さなバッファサイズ:
- mbuf(メッセージバッファ)構造による制限
- パケット断片化処理での脆弱性
- 大量データ転送時に頻繁にバッファオーバーフロー
プロトコル制限:
- ICMPサポート無し(pingが使えない)
- IPv6ポートフォワーディング未対応
- WebSocketなど長時間接続に最適化されていない
3. M1 Mac特有の問題の詳細
ARM版UTMのNAT実装の最適化不足:
- x86_64エミュレーション時は「非常に遅い」と公式に記載
- I/O性能が特に問題(ネットワークI/Oを含む)
- Hypervisor Frameworkのネットワーク部分が未最適化
macOS Sequoiaとの相性問題:
- Sequoia実行時に追加ドライバーが必要(MobileDevice.pkg等)
- v4.6.5でカーネルパニック報告により変更が戻された経緯
- macOS 12以降でUSB共有、動的解像度に制限
注: Rosetta 2は無関係(UTMはネイティブARMアプリ)
ブリッジモードが安定する理由
ブリッジモードでは、仮想マシンが物理ネットワークに直接参加します:
インターネット
↓
ルーター (192.168.1.1)
├─ Mac (192.168.1.10)
└─ Windows 11 (192.168.1.20) ← 同じネットワークセグメント!
メリット:
- NATを経由しない直接通信
- 実機と同等のネットワーク性能
- レイテンシが50-70%削減
- スループットが2-3倍向上
なぜWeb閲覧・動画は正常でAI系サービスだけエラーになるのか?
この現象には技術的な理由があります。
AI系サービスの特殊な接続要件
1. WebSocket長時間接続
一般的なWebサービス:HTTPSの短時間接続(数秒)
AI系サービス:WebSocketで数分〜数十分の継続接続
Claude CodeやCursor(GPT-5)は、リアルタイムのやり取りのためにWebSocketを使用します。
WebSocketとは?通常のHTTPとの違い
通常のHTTP通信(リクエスト・レスポンス型):
[クライアント] → リクエスト送信 → [サーバー]
[クライアント] ← レスポンス返却 ← [サーバー]
接続終了
- クライアントからのリクエストが必要
- サーバーから自発的にデータを送れない
- 毎回新しい接続を確立(オーバーヘッド大)
WebSocket通信(双方向リアルタイム型):
[接続確立フェーズ]
クライアント → HTTPアップグレード要求 → サーバー
クライアント ← 101 Switching Protocols ← サーバー
[データ通信フェーズ]
クライアント ⇄ 双方向データ送受信 ⇄ サーバー
(接続を維持したまま何度でもやり取り可能)
WebSocketの技術的な仕組み
- ハンドシェイク(接続確立):
GET /chat HTTP/1.1
Host: api.openai.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
- プロトコル切り替え:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
- データフレーム構造:
- 最小2バイトのヘッダー(効率的)
- ペイロード長の動的調整
- マスキングによるセキュリティ
- Ping/Pongによる接続維持
AI系サービスがWebSocketを必要とする理由
これらの特徴により:
- 双方向通信: サーバーからクライアントへのプッシュ通信が必要
- ステートフル接続: 会話の文脈を保持する長時間接続
- 低レイテンシ要求: 230ms以下のレスポンスタイム
- ストリーミング: トークンを生成次第、即座に送信
2. 大量データのストリーミング転送
YouTube/SoundCloud:バッファリング可能な一方向ストリーム
AI系サービス:リアルタイム双方向の大量トークン転送
- GPT-5: 156〜180トークン/秒の高速ストリーミング
- Claude: 数千トークンの応答を連続送信
- バッファリング不可(リアルタイム応答が必須)
3. SLIRPの制限がAIサービスに致命的な理由
接続数の枯渇:
ARPテーブル:16エントリ制限
→ AI APIの複数並行ストリーム(モデル選択、トークンカウント、本体通信など)で即座に枯渇
バッファオーバーフロー:
YouTube:動画データを事前バッファリング可能
AI応答:リアルタイムストリーミングでバッファ不可
→ mbufバッファが即座にオーバーフロー
NAT変換の遅延累積:
通常のWeb:1往復で完了
AI通信:数百〜数千回の双方向やり取り
→ 各往復で10-20msの遅延が累積し、タイムアウト
具体的な影響の違い
サービス | 接続タイプ | NAT影響 | 結果 |
---|---|---|---|
YouTube | HTTP/単方向 | 小 | ✅ 正常 |
SoundCloud | HTTP/単方向 | 小 | ✅ 正常 |
一般Web | HTTP/短時間 | 小 | ✅ 正常 |
Claude Code | WebSocket/双方向 | 大 | ❌ エラー |
Cursor GPT-5 | WebSocket/双方向 | 大 | ❌ 途中停止 |
解決方法:ブリッジモードへの変更手順
1. UTMの設定変更
1. 仮想マシンを停止
2. 設定 → ネットワーク
3. ネットワークモード:「ブリッジ」を選択
4. ブリッジインターフェース:「en0」(Wi-Fi)を選択
2. Windows 11側の確認
ブリッジモード変更後、Windows 11は自動的にDHCPから新しいIPアドレス(192.168.1.*/24)を取得します。
3. 動作確認
# Windows 11で実行
ipconfig /all
# 192.168.1.* のIPアドレスが割り当てられていることを確認
まとめ:仮想マシンのネットワーク設定は要注意!
今回の教訓:
- 仮想マシンのネットワーク設定は、ホスト全体に影響を与える可能性がある
- 共有モード(NAT)、パフォーマンスと安定性に問題がある
- ブリッジモードは圧倒的に安定する
もしあなたもMacでUTMを使っていて、ネットワークが不安定になったら、まずネットワーク設定を確認してみてください。意外とこれが原因かもしれません。
環境情報
- Mac: M1 MacBook Pro
- OS: macOS Sequoia 15.6
- UTM: Version 4.5.3
- 仮想OS: Windows 11 Pro
この記事が同じ問題で悩んでいる方の助けになれば幸いです!
コメント