対象レベル：Level 2〜3
想定読了時間：20分
身につく成果：HTTP/1.1・HTTP/2・HTTP/3が混在する環境で、遅延箇所を根拠付きで切り分けられる
前提知識：TCP/IP、DNS、HTTP・HTTPSの基礎
関連スキル：HTTP/3／QUIC／UDP／curl／Chrome DevTools／パケットキャプチャー／分散トレーシング

「ネットワークが遅いので確認してください」

アプリケーションの画面表示に時間がかかる。

APIの応答が遅い。

ファイルのアップロードが終わらない。

このような問題が発生すると、ネットワーク担当者には次のような依頼が届きます。

アプリ側では問題が見つかりません。
ネットワークが遅い可能性があるので確認してください。

しかし、「画面が遅い」「APIが遅い」という現象だけでは、ネットワークが原因とは判断できません。

遅延が発生する場所には、次のような候補があります。

• 利用者のPCやブラウザー
• 無線LANや社内LAN
• VPNやインターネット回線
• DNS
• プロキシやファイアウォール
• CDN、WAF、ロードバランサー
• Webサーバーやアプリケーション
• データベースやキャッシュ
• 外部API
• JavaScriptや画面描画
• HTTP/3接続の失敗とHTTP/2への切り替え

ネットワーク担当者が行うべきなのは、感情的に「ネットワークは悪くありません」と反論することではありません。

重要なのは、次の問いに証拠で答えることです。

実際にはどの通信方式が使われ、どの区間で何ミリ秒待っているのか。

結論：「ネットが遅い」は原因ではなく症状である

2026年現在のWeb通信では、HTTP/1.1・HTTP/2・HTTP/3が混在しています。

HTTP/1.1とHTTP/2のHTTPS通信は、基本的にTCP上でTLSを使用します。一方、HTTP/3はQUICを使用します。QUICはUDP上で動作し、ストリームの多重化、フロー制御、低遅延の接続確立、経路変更への対応といった機能を備えています。HTTP/3は、そのQUIC上へHTTPの仕組みを載せたプロトコルです。

したがって、次の確認だけでは不十分です。

pingは正常
TCPの接続も正常
だからネットワークに問題はない

対象通信がHTTP/3なら、そもそもTCP接続を使用していません。

2026年の切り分けでは、最初に実際のHTTPバージョンを確認し、その通信方式に合わせて調査を進める必要があります。

1．最初に実際のHTTPバージョンを確認する

同じURLへアクセスしていても、すべての利用者が同じプロトコルを使用するとは限りません。

例えば、次のような違いが発生します。

利用者A：HTTP/3
利用者B：HTTP/2
社内LAN：HTTP/2
モバイル回線：HTTP/3
初回アクセス：HTTP/2
2回目以降：HTTP/3

HTTP/3の接続先は、Alt-Svcなどを通じてクライアントへ通知されることがあります。また、QUIC接続に失敗した場合、クライアントはTCPベースのHTTPへ切り替えることがあります。

そのため、「同じ画面を開いた」という情報だけでは、正確な比較になりません。

最低限、次の情報を確認します。

2．Web通信の遅延を区間に分ける

HTTP/1.1・HTTP/2の場合

DNS名前解決
　↓
TCP接続
　↓
TLSハンドシェイク
　↓
HTTPリクエスト
　↓
エッジ・アプリケーション処理
　↓
HTTPレスポンス転送
　↓
ブラウザーでの画面描画

HTTP/3の場合

DNS名前解決
　↓
QUIC接続・TLSネゴシエーション
　↓
HTTP/3リクエスト
　↓
エッジ・アプリケーション処理
　↓
HTTP/3レスポンス転送
　↓
ブラウザーでの画面描画

HTTP/3では、TCP接続とTLS接続を完全に独立した工程として扱うことはできません。QUICの接続確立にはTLSが統合されているため、TCP通信と同じ式で機械的に分解すると、誤った説明になる可能性があります。

3．まず「いつ・誰が・どこで・何を」を確認する

技術調査を始める前に、現象を再現可能な形へ変換します。

悪い申告例は次のとおりです。

昨日から何となくネットが遅いです。

この情報では、ネットワークログやアプリケーションログと突き合わせられません。

調査できる形へ変換すると、次のようになります。

7月21日10時15分ごろから、東京拠点の有線LAN利用者5名で、顧客検索ボタンを押した後に8〜10秒待たされます。通常は1秒以内です。ログイン画面とトップページには遅延がありません。

最低限、次の項目を確認してください。

4．Chrome DevToolsで確認する

Web画面が遅い場合は、Chrome DevToolsのNetworkパネルを確認します。

Networkパネルの「Protocol」列には、実際に使われたプロトコルが表示されます。

Chromeの公式ドキュメントでも、Protocol列にはHTTP/2のh2やHTTP/3のh3などが表示されると説明されています。

確認手順

1. 対象ページを開く
2. F12キーでDevToolsを開く
3. 「Network」を選択する
4. 項目名の部分を右クリックする
5. 「Protocol」を有効にする
6. ページを再読み込みする
7. 遅いリクエストのProtocolとTimingを確認する

あわせて、次の項目も確認します。

• どのリクエストが遅いか
• WaitingまたはTTFBが長いか
• Content Downloadが長いか
• 同じAPIを繰り返し呼び出していないか
• リダイレクトが発生していないか
• APIの終了後に画面描画で待っていないか
• 接続先IPアドレスが利用者間で異なっていないか

h3でもアプリサーバーまでQUICとは限らない

ブラウザーにh3と表示されても、アプリケーションサーバーまでHTTP/3が使われているとは限りません。

一般的には、次のような構成もあります。

ブラウザー
　↓ HTTP/3
CDN・WAF・ロードバランサー
　↓ HTTP/2またはHTTP/1.1
アプリケーションサーバー

この場合、少なくとも次の区間を分けて考えます。

• クライアントからエッジまで
• エッジ内部の処理
• エッジからオリジンサーバーまで
• アプリケーション内部

「ブラウザーがh3だから、すべての区間が正常」とは判断できません。

5．curlでHTTP/3とHTTP/2を比較する

curlを利用すると、使用プロトコルや応答時間をコマンドラインから確認できます。

ただし、使用しているcurlがHTTP/3に対応している必要があります。

まず、次のコマンドで対応機能を確認します。

curl -V

FeaturesやProtocolsの表示にHTTP/3関連の対応がなければ、--http3や--http3-onlyは使用できません。

HTTP/3だけで接続する

curl -sS -o /dev/null \
  --http3-only \
  -w 'http_version=%{http_version}\nremote=%{remote_ip}:%{remote_port}\npretransfer=%{time_pretransfer}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://example.com/api/search

--http3-onlyはHTTP/3だけを使用し、QUIC接続に失敗してもHTTP/2やHTTP/1.1へ切り替えません。純粋にHTTP/3の成否を確認したい場合に使用します。

HTTP/3を試し、失敗時は以前のHTTPへ切り替える

curl -sS -o /dev/null \
  --http3 \
  -w 'http_version=%{http_version}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://example.com/api/search

--http3はHTTP/3を試しますが、接続が失敗したり遅かったりした場合は、HTTP/2またはHTTP/1.1による接続も試します。そのため、--http3を指定しただけでは、実際にHTTP/3が使われたとは限りません。必ずhttp_versionの値を確認します。

HTTP/2で比較する

curl -sS -o /dev/null \
  --http2 \
  -w 'http_version=%{http_version}\nremote=%{remote_ip}:%{remote_port}\npretransfer=%{time_pretransfer}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://example.com/api/search

--http2を指定した場合も、最終的に使われたバージョンはhttp_versionで確認してください。

6．curlの測定値を正しく読む

代表的な項目は次のとおりです。

curlの時間項目は、多くがコマンド開始からの累積時間です。また、time_starttransferには、転送前の処理に加えて、サーバーが結果を生成する時間も含まれます。

HTTP/1.1・HTTP/2でのおおよその見方

DNS
= time_namelookup

TCP接続
≈ time_connect - time_namelookup

TLS接続
≈ time_appconnect - time_connect

接続準備完了後から最初の応答まで
≈ time_starttransfer - time_pretransfer

レスポンス転送
≈ time_total - time_starttransfer

ただし、接続再利用、リダイレクト、プロキシ、認証などがあると、単純には分解できません。

HTTP/3での見方

HTTP/3では、time_connectとtime_appconnectの差をそのまま「UDP接続時間」「TLS時間」として説明しないほうが安全です。

優先して確認する項目は次のとおりです。

• 実際に使われたHTTPバージョン
• HTTP/3接続が成功したか
• time_pretransfer
• time_starttransfer
• time_total
• HTTP/2との比較結果
• 初回接続と再接続の差
• 接続先IPアドレスの差

curlの結果だけで原因を断定せず、ブラウザー、ネットワーク機器、エッジ、アプリケーションのログと組み合わせます。

7．HTTP/3からHTTP/2への切り替えを疑う

HTTP/3はUDP上のQUICを使用します。

経路上でQUIC通信が成立しない場合、クライアントはHTTP/2やHTTP/1.1による接続を試すことがあります。curlの--http3も、HTTP/3接続が遅い場合や失敗した場合に、少し遅れてTCPベースの接続を開始します。

利用者から見ると、最終的にはページが表示されるため、「通信できている」ように見えます。

しかし、次のような順番になっていれば、切り替えまでの待ち時間が加算されます。

HTTP/3接続を試す
　↓
QUICの応答を待つ
　↓
HTTP/3接続に失敗
　↓
HTTP/2接続を開始
　↓
ページが表示される

比較する3パターン

A：--http3-only
B：--http3
C：--http2

Aは失敗、Bは遅れて成功、Cはすぐ成功

優先して確認する対象は次のとおりです。

• UDP/443の通信
• ファイアウォール
• VPN装置
• プロキシ
• CDNやロードバランサーのHTTP/3設定
• QUICの証明書・ALPNネゴシエーション
• NATのUDPセッション管理

ただし、「UDP/443が遮断されている」と即断してはいけません。

接続先のHTTP/3設定、証明書、DNS、エッジ側の障害でも同様の結果になる可能性があります。

AとCの両方が遅い

HTTP/3とHTTP/2の両方で同じ遅延が発生する場合、次の共通部分を優先して確認します。

• CDNやWAFの処理
• エッジからオリジンまでの接続
• アプリケーション処理
• SQL
• キャッシュ
• 外部API
• サーバー側のキュー

Aだけ遅く、Cは速い

次の可能性があります。

• QUIC経路固有のパケットロス
• UDP通信の制御
• HTTP/3終端装置の負荷
• UDPセッションタイムアウト
• 特定のエッジへの接続
• QUIC実装や設定の問題

8．HTTP/3だから必ず高速とは限らない

HTTP/3では、複数のHTTPリクエストをQUICの別々のストリームで処理できます。

HTTP/2は一つのTCP接続上で複数ストリームを扱うため、TCPレベルでパケットが欠落すると、後続データが届いていても欠落部分の回復を待つことがあります。HTTP/3では、QUICのストリーム単位で処理されるため、あるストリームの損失が別のストリームを同じ形で停止させる問題を抑えられます。

ただし、HTTP/3でもパケットロスの影響がなくなるわけではありません。

パケットロスが発生すれば、再送や輻輳制御によって通信時間は増加します。

また、アプリケーションやSQL処理に8秒かかっている場合、接続確立が数十ミリ秒短縮されても、画面全体の遅さはほとんど改善しません。

9．パケットキャプチャーだけでは判断できない

TCPでは、パケットキャプチャーから次の情報を比較的確認しやすい傾向があります。

• SYN、SYN/ACK、ACK
• TCP再送
• Duplicate ACK
• Zero Window
• シーケンス番号
• TCPウィンドウ

一方、QUICではペイロードだけでなく、多くのトランスポート制御情報も暗号化されます。

QUICの運用管理に関するRFCでも、QUICはTCPと比べてネットワーク上から観測できる情報が限定されることが説明されています。

それでも、パケットキャプチャーから次の情報は確認できます。

• UDP/443通信が発生しているか
• 接続先IPアドレスとポート
• パケットが双方向に流れているか
• 途中で通信が途絶えていないか
• 初期接続を繰り返していないか
• パケットサイズや通信間隔
• 特定経路だけ応答がないか

QUICの調査では、次の情報を組み合わせる必要があります。

パケットキャプチャー
＋
クライアント側ログ
＋
CDN・WAF・ロードバランサーのログ
＋
アプリケーションログ
＋
分散トレース

「パケットだけで全工程を証明する」のではなく、各レイヤーの観測情報を同じ時間軸で突き合わせます。

10．Request IDとTrace IDでアプリ内部を確認する

マイクロサービスやクラウド環境では、一つの画面操作から複数のサービスが呼び出されます。

ブラウザー
　↓
CDN・WAF
　↓
API Gateway
　↓
認証サービス
　↓
業務API
　↓
データベース
　↓
外部API

分散トレーシングを利用すると、一つのリクエストが各サービスを通過した経路と処理時間を追跡できます。

OpenTelemetryのトレースは、リクエストがアプリケーション内を通る経路を複数のSpanとして記録します。Trace IDやコンテキストをサービス間で引き継ぐことで、プロセスやネットワーク境界をまたいだ処理を関連付けられます。

調査時は次の情報を共有します。

発生時刻：2026-07-21 10:15:32 JST
Request ID：req-7f31c82a
Trace ID：4f13c7b2d91a
送信元IP：10.10.20.35
対象API：POST /api/customer/search
HTTPステータス：200
総応答時間：8.24秒
利用プロトコル：HTTP/3

これにより、ネットワークログ、ロードバランサー、アプリケーション、データベースの記録を同じリクエスト単位で確認できます。

11．症状別の責任分界早見表

この表は原因を断定するものではありません。

あくまで、次に調べる場所の優先順位を決めるために使用します。

12．15分で行う初動切り分け

0〜3分：現象を具体化する

次の情報を確認します。

• 発生時刻
• 対象ユーザー
• 対象拠点
• 対象URL・API
• 通常時と異常時の応答時間
• 毎回か断続的か
• 初回だけか再アクセスでも遅いか

3〜5分：実際のプロトコルを確認する

Chrome DevToolsまたはcurlで、次を記録します。

• HTTPバージョン
• 接続先IPアドレス
• 接続先ポート
• プロキシの有無
• HTTP/3接続の成否

5〜8分：HTTP/3とHTTP/2を比較する

curl --http3-only ...
curl --http2 ...

比較する項目は次のとおりです。

• 接続成功・失敗
• 実際のHTTPバージョン
• 接続先IPアドレス
• TTFB
• 総応答時間

8〜11分：ネットワーク側を確認する

• 回線使用率
• インターフェースエラー
• パケットドロップ
• UDP/443の通信
• TCP/443の通信
• ファイアウォールやVPNのログ
• HTTP/3終端装置の状態

11〜13分：エッジ・アプリのログを照合する

• Request ID
• Trace ID
• CDN処理時間
• オリジン応答時間
• アプリケーション処理時間
• SQL実行時間
• 外部APIの応答時間

13〜15分：暫定見解を共有する

原因を断定できなくても、事実と次のアクションを共有します。

対象通信はHTTP/3で接続していることを確認しました。接続準備は約90ミリ秒で完了していますが、最初のレスポンス受信まで約6.8秒かかっています。HTTP/2でも同程度の遅延が再現するため、現時点ではQUIC経路固有の問題より、両プロトコルに共通するエッジ以降の処理を優先して確認します。

13．実践ケース：HTTP/3でもHTTP/2でも8秒かかる

顧客検索画面の結果表示に約8秒かかっているとします。

HTTP/3の測定結果

http_version=3
pretransfer=0.082
ttfb=8.143
total=8.150

HTTP/2の測定結果

http_version=2
pretransfer=0.094
ttfb=8.167
total=8.174

ネットワーク側の確認結果

回線使用率：通常範囲
インターフェースエラー：増加なし
パケットドロップ：増加なし
HTTP/3接続：成功
HTTP/2接続：成功

アプリケーショントレース

API全体：8.02秒
認証処理：0.03秒
業務処理：7.91秒
SQL実行：7.72秒
レスポンス生成：0.04秒

HTTP/3とHTTP/2のどちらでも、接続準備は100ミリ秒未満で完了しています。

一方、最初のレスポンスまで約8秒かかっています。アプリケーショントレースでは、SQL実行が7.72秒を占めています。

この結果から、少なくともクライアントからエッジまでのHTTP/3経路だけが主要因とは考えにくい状況です。

ただし、「アプリが悪い」とだけ報告するのは適切ではありません。

次のように伝えます。

HTTP/3とHTTP/2の両方で比較測定を行いました。接続準備はいずれも100ミリ秒未満ですが、最初のレスポンス受信まで約8.1秒かかっています。

プロトコルを変更しても同じ遅延が発生するため、クライアントからエッジまでのQUICまたはTCP経路固有の問題である可能性は低いと考えます。

Trace IDの確認では、API処理8.02秒のうちSQL実行が7.72秒を占めています。アプリ・DB側でSQL実行計画、ロック、対象データ量の確認をお願いします。

14．アプリ開発者への確認依頼テンプレート

対象APIについて、HTTP/3とHTTP/2の比較測定を実施しました。

【HTTP/3】
接続準備：約80ミリ秒
最初のレスポンスまで：約7.9秒
総応答時間：約8.0秒

【HTTP/2】
接続準備：約95ミリ秒
最初のレスポンスまで：約8.0秒
総応答時間：約8.1秒

プロトコルを変更しても同程度の遅延が再現しています。遅延の大部分は、接続準備完了後から最初のレスポンスを受信するまでの区間です。

以下の情報をもとに、アプリケーション内部の処理時間をご確認ください。

・発生時刻：2026-07-21 10:15:32 JST
・Request ID：req-7f31c82a
・Trace ID：4f13c7b2d91a
・対象API：POST /api/customer/search
・HTTPステータス：200

特に、アプリ内部処理、SQL、キャッシュ、外部API、キュー待ちの内訳確認をお願いします。

15．ネットワーク側の一次報告テンプレート

対象通信について、現時点の確認結果を共有します。

【発生条件】
発生時刻：
対象ユーザー・拠点：
対象URL・API：
通常時の応答時間：
発生時の応答時間：

【利用プロトコル】
HTTPバージョン：
接続先IP・ポート：
HTTP/3接続：成功／失敗／未確認
HTTP/2への切り替え：あり／なし／不明

【比較測定】
HTTP/3の応答時間：
HTTP/2の応答時間：
初回接続：
再接続：

【ネットワーク側の確認結果】
回線使用率：
パケットドロップ：
インターフェースエラー：
UDP/443：
TCP/443：
FW・VPNログ：
HTTP/3終端装置：

【暫定見解】
現時点では、遅延の大部分が○○から○○の区間で発生しています。HTTP/3とHTTP/2の比較では○○という結果が確認されています。

【次の確認】
ネットワークチーム：
基盤・クラウドチーム：
アプリケーションチーム：
DBチーム：

16．やってはいけない切り分け

TCPだけ確認して終了する

TCP接続が正常なので、ネットワークは正常です。

対象通信がHTTP/3なら、TCP接続の確認だけでは証明になりません。

最初に実際のHTTPバージョンを確認します。

pingだけで調査を終了する

pingでは、HTTP/3、QUIC、TLS、WAF、ロードバランサー、アプリケーション処理まで確認できません。

pingは到達性を確認する一つの手段であり、システム全体の正常性を証明するものではありません。

HTTP/3なら高速だと決めつける

HTTP/3には通信条件によって有利になる仕組みがありますが、すべての環境でHTTP/2より高速になるとは限りません。

接続先、ネットワーク品質、エッジ構成、アプリ処理などによって結果は変わります。

一回だけ測定する

初回接続、接続再利用、キャッシュ、接続先エッジなどによって結果が変わります。

最低でも次を比較します。

• 初回アクセス
• 2回目のアクセス
• HTTP/3
• HTTP/2
• 社内ネットワーク
• 別ネットワーク

「異常なし」とだけ報告する

悪い報告：

ネットワーク異常なし。

良い報告：

発生時刻の回線使用率、パケットドロップ、インターフェースエラー、UDP/443、TCP/443を確認しました。HTTP/3とHTTP/2はいずれも接続準備が100ミリ秒未満で完了しています。遅延は両プロトコルで、接続準備完了後から最初のレスポンスまでの区間に集中しています。

確認した事実を具体的に示すことが重要です。

17．責任分界切り分けチェックリスト

現象の確認

• 正確な発生時刻を確認した
• 対象URL・APIを確認した
• 対象ユーザーと拠点を確認した
• 通常時と異常時の時間を確認した
• 初回と再アクセスを区別した

プロトコルの確認

• 実際のHTTPバージョンを確認した
• 接続先IP・ポートを確認した
• HTTP/3だけで接続テストを実施した
• HTTP/2でも比較した
• HTTP/3からの切り替えを確認した

ネットワークの確認

• 回線使用率を確認した
• パケットドロップを確認した
• インターフェースエラーを確認した
• UDP/443を確認した
• TCP/443を確認した
• FW・VPNログを確認した
• HTTP/3終端装置を確認した

アプリケーションの確認

• Request IDを確認した
• Trace IDを確認した
• エッジ処理時間を確認した
• オリジン応答時間を確認した
• アプリ処理時間を確認した
• SQL実行時間を確認した
• 外部APIの応答時間を確認した
• 画面描画時間を確認した

報告

• 事実と推測を分けた
• 使用プロトコルを記載した
• HTTP/3とHTTP/2を比較した
• 遅延区間を時間で示した
• 次の担当者と確認事項を明確にした
• 原因確定前に責任を断定していない

まとめ

2026年の「ネットが遅い」問題では、TCPだけを前提にした切り分けでは不十分です。

最初に確認すべきなのは、実際に使われたプロトコルです。

HTTP/1.1なのか
HTTP/2なのか
HTTP/3なのか
HTTP/3から別のHTTPへ切り替わったのか

責任分界を整理する基本は、次の6つです。

1. 実際のHTTPバージョンを確認する
2. HTTP/3とHTTP/2を比較する
3. クライアント、エッジ、オリジン、アプリを分ける
4. 初回接続と再接続を区別する
5. Request IDとTrace IDで処理を追跡する
6. 「誰が悪いか」ではなく「どこで何秒かかっているか」を示す

冤罪回避に必要なのは、強い反論ではありません。

最も早く、最も具体的な証拠を提示すること。

ネットワーク担当者がTCPとQUICの両方を理解し、アプリケーションの処理時間まで同じ時間軸で整理できれば、単なる「回線を見る担当者」ではなく、システム全体の問題解決を前へ進められるエンジニアになれます。