【解決】UTMが原因でAIネットワークが不安定になった話

突然発生したネットワークの謎の不調

ある日突然、愛用の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

この記事が同じ問題で悩んでいる方の助けになれば幸いです！