ChatGPTとClaudeが読み込み中で止まる原因はQUIC？ERR_QUIC_PROTOCOL_ERRORを確認して解決した事例
ChromeでClaudeを開いたら「このサイトにアクセスできません」と表示され、画面が真っ白なまま進まない。ChatGPTも似たような挙動で、なのにニュースサイトやGmailは普通に開く。キャッシュを消してもシークレットモードにしても変わらない——そんな状況に遭遇しました。
このとき表示されていたエラーが ERR_QUIC_PROTOCOL_ERROR でした。結論から言うと、ChromeとEdgeでQUICを無効化したところ、ChatGPTとClaudeが正常に開くようになりました。
この記事は、同じように「特定のAIサービスだけ開けない」状態にハマったエンジニア向けの備忘録です。何を確認し、何を変えたら直ったのか、そしてその結果から何が言えるのかを順に整理します。
ここがポイント:
ERR_QUIC_PROTOCOL_ERRORが出てChatGPT/Claudeだけ不安定なら、キャッシュではなく通信方式（QUIC/HTTP/3）を疑う価値があります。
まず結論：QUIC無効化で開けるようになった
最初に対応の要点だけまとめます。
- ChromeとEdgeで
ERR_QUIC_PROTOCOL_ERRORが出て、ChatGPTとClaudeの画面が読み込めなかった chrome://flags（Edgeはedge://flags）の Experimental QUIC protocol を Disabled に変更- ブラウザを完全に再起動して再アクセスしたところ、症状が起きなくなった
ただし、これは原因を一発で特定する魔法の設定ではありません。QUIC無効化はあくまで「切り分け兼回避策」として扱うのが安全です。なぜそう言えるのかは、後半で順を追って説明します。
前提条件と確認した環境
この事例で確認できていた条件は次のとおりです。
- ブラウザ: Chrome と Edge（いずれもChromium系）
- 症状が出たサービス: ChatGPT と Claude
- 症状が出なかった対象: 上記以外の通常サイト
- 試して効果がなかったこと: キャッシュ削除、プライベート/シークレットモード
QUICやHTTP/3の細かい仕様、各社の公式ステータス、ブラウザのバージョン依存の挙動などは、記事作成時点での外部確認が必要な領域です。本文ではあくまで「手元で確認できた範囲」と「そこから推測できること」を分けて書きます。
困っていた症状
症状を分解すると、こうなります。
- Claudeにアクセスすると「このサイトにアクセスできません」という画面になる
- 対象URLは
claude.ai/new#settings/usageのような形式だった（これは画面に表示されていた範囲の情報で、個人のアカウント内容とは別物） - ChromeでもEdgeでも同じように起きる
- ChatGPTとClaude以外は問題なく使える
ポイントは、PC全体がネットにつながらないわけではないという点です。他のサイトは普通に開けるので、回線そのものが落ちているわけではありませんでした。
DevToolsのNetworkタブで確認できたこと
「読み込んでいます」のまま止まるとき、原因がページ内のJavaScriptなのか通信そのものなのかで対応が変わります。そこでDevTools（F12キーで開く）のNetworkタブを見ました。
確認できたのは以下です。
- 失敗していたのは document タイプのリクエスト（＝ページ本体のHTML）
- そのリクエストが
failed net::ERR_QUIC_PROTOCOL_ERRORになっていた - 失敗したリクエストのサイズは 0.0KB、つまり中身を一切受け取れていない
- 一方で、一部の画像・フォント・スクリプトは 200 で取得済み、またはキャッシュから読み込まれていた
- Consoleタブには目立つエラーが出ていなかった
この見え方が意味すること
ページの土台になるHTML自体が0KBで失敗している以上、ページ内のスクリプトのバグというより、通信層でつまずいていると読むのが自然です。Consoleにエラーが出ていなかったのも、JavaScriptが動き出す前段階で止まっていると考えれば筋が通ります。
DevToolsに不慣れな場合は、「Networkタブを開いた状態でページを再読み込みし、赤字で failed になっている行のStatus欄を見る」とだけ覚えておけば十分です。
ERR_QUIC_PROTOCOL_ERRORとは何か
QUICは、Chrome/EdgeなどChromium系ブラウザが使う比較的新しい通信方式で、HTTP/3と密接に関係しています。従来のHTTP/2やHTTP/1.1とは別ルートで接続を確立する、と理解しておけば実務上は足ります。
ERR_QUIC_PROTOCOL_ERROR は、ざっくり言えば「QUICで接続しようとしたが、その通信がうまくいかなかった」という状態を指します。
重要なのは、このエラー名だけでは犯人を特定できないことです。考えられる関与先は複数あります。
- ブラウザ側のQUIC実装
- サービス側やCDNのHTTP/3対応状況
- ルーター、プロバイダの経路、IPv6まわり
- セキュリティソフトやVPN、DNS設定
つまり ERR_QUIC_PROTOCOL_ERROR は「QUICのどこかで失敗した」というシグナルであって、「QUICが悪い」と断定する根拠ではありません。
ChromeとEdgeでQUICを無効化する手順
切り分けとして、QUICを一時的に止めてみます。Chromium系なので手順はほぼ共通です。
Chromeの場合
- アドレスバーに
chrome://flags/#enable-quicと入力して開く - 「Experimental QUIC protocol」を Disabled に変更する
- 画面下部に出る再起動ボタン、またはブラウザを手動で完全に再起動する
- 再度ChatGPT/Claudeを開いて確認する
Edgeの場合
- アドレスバーに
edge://flags/#enable-quicと入力して開く - 同じく「Experimental QUIC protocol」を Disabled に変更する
- ブラウザを完全に再起動する
- 再度アクセスして確認する
再起動は「ウィンドウを閉じる」だけでなく、バックグラウンドのプロセスも含めて落とし切るのが確実です。今回はこの変更後、症状が出なくなりました。
QUIC無効化で直った場合に分かること
直ったという事実から、いくつかの可能性の確度が上下します。ここは確定情報（手元で観測したこと）と推測を分けて書きます。
確定しているのは「QUICを無効化したら症状が出なくなった」という一点です。そこから推測できるのは次のようなことです。
- キャッシュやCookieだけが原因だった可能性は低い（削除しても直らなかったため）
- アカウント側の不具合だった可能性は低い（通信方式を変えただけで開けたため）
- Chromium系ブラウザのQUIC/HTTP/3通信と、AIサービス／CDN／通信経路のどこかとの相性問題だった可能性が高いとみられる
ChromeとEdgeの両方で起きていたことも、特定ブラウザ固有のバグというより、Chromium共通の通信挙動が絡んでいた可能性を示唆します。ただし、これらはあくまで観測結果からの推測であり、サービス側の障害やブラウザのバグだと断定するものではありません。
キャッシュ削除やプライベートモードで直らなかった理由
キャッシュ削除やシークレットモードが効くのは、主に「保存されたデータが壊れている」「古いCookieやログインセッションがおかしい」といったケースです。
今回はその層より下、接続を確立する通信方式そのものでつまずいていました。シークレットモードでもブラウザは同じQUICで接続しに行くので、症状が変わらなかったのは整合的です。「データを消す」系の対処が空振りしたら、一段下の通信層を疑う、という切り分けの順番が見えてきます。
直らない場合に確認したい追加項目
QUIC無効化で直らないなら、原因は別の場所にある可能性があります。以下を一つずつ切り分けると範囲を絞れます。
- 別系統のブラウザで試す: Firefoxなど非Chromium系で再現するか確認する
- 回線を変える: スマホのテザリングなど、別経路でつないでみる
- セキュアDNSを一時的にOFFにして挙動を見る
- VPN/プロキシをOFFにする
- セキュリティソフトのWeb保護やHTTPSスキャン機能を確認する
- ルーター再起動、IPv6設定、DNS変更などを検討する
これらはいずれも「可能性の確認」であって、確認なしに原因と決めつけないのが安全です。認証情報やネットワーク設定をいじる操作は、戻し方をメモしてから変更してください。
QUICを無効化したままで問題はあるのか
QUICを切ると、多くのサイトはHTTP/2やHTTP/1.1へフォールバックして接続を続けます。通常利用で大きな支障が出ないことが多い一方、サイトによっては速度や接続挙動に差が出る可能性はあります。
おすすめの運用は次のとおりです。
- しばらくDisabledのまま使い、安定するか様子を見る
- ブラウザ更新や時間経過のあと、
enable-quicを Default に戻して再発するか確認する - 再発しなければ、その時点での経路・CDN設定・ブラウザ実装のいずれかが改善したと推測できる
QUIC無効化はセキュリティ対策でも根本修理でもありません。通信方式を一段落とす回避策だと割り切るのが妥当です。
AIサービス特有の通信トラブルとして見るべきポイント
ChatGPTやClaudeのようなAIサービスは、ログイン認証、WebSocketによる継続的な通信、CDN経由の配信、重めのJavaScript、長時間つなぎっぱなしの通信など、要素が多めです。
こうした構成は、静的なニュースサイトと比べて通信経路の相性問題が表面化しやすい可能性があります。「普通のサイトは開けるのにAIサービスだけ不安定」という偏りが出たら、サービス障害と決めつける前に、自分側の通信方式を一度疑ってみる価値があります。
まとめ：ERR_QUIC_PROTOCOL_ERRORが出たら通信方式を切り分ける
最後に、持ち帰れる判断軸を短く整理します。
ERR_QUIC_PROTOCOL_ERRORが出てChatGPT/Claudeだけ読み込めないなら、まずQUIC/HTTP/3を疑う- DevToolsのNetworkタブで、document リクエストが0KBで失敗していないか確認する
- Chrome/Edge共通で起きるなら、
enable-quicをDisabledにして切り分ける - 直った場合もそれは回避策であり、後でDefaultに戻して再確認する
- 原因は単一ではなく、ブラウザ・サービス側・CDN・回線経路の組み合わせで起きている可能性がある
次に同じ症状が出たときは、QUICをDefaultに戻した状態でまだ再現するか、別ブラウザや別回線でも起きるかを観察すると、原因がブラウザ側に寄っているのか経路側に寄っているのかを、もう一段絞り込めるはずです。
コメント