あなたの通信の3割は、もうTCPではない——QUICが10年かけて静かに書き換えたインターネット【2026】

朝、スマートフォンで動画を開いた瞬間に、何が起きているでしょうか。画面には何も表示されませんが、その裏では10年前には存在しなかった通信の作法が動いています。QUIC（クイック）と呼ばれる転送プロトコルです。

インターネットイニシアティブ（IIJ）の調査によれば、ブロードバンド利用者のトラフィックに占めるUDPの割合は2020年以降に急増しました。2025年には30.6％に達しています。TCPが当然だった時代の終わりが、数字として表れています。

本記事では、QUICが何を解決したのかを追います。なぜ今も3割で止まっているのか、普及の裏で起きている思わぬ副作用は何かも見ていきます。

2025年、ブロードバンド通信の3割がUDPになった

インターネットの通信は長らくTCPが支えてきました。IIJの堂前清隆氏は「UDPは例外的な存在だった」と振り返ります。それが2020年以降、UDPの比率は目に見えて伸び始めました。TCPの上に成り立つWebが、UDPへと足場を移し始めたのです。最初は一部の大規模サービスだけでしたが、数年で裾野が広がりました。

2025年の実測値は30.6％です。モバイル回線でもほぼ同じ傾向が確認されています。UDPはもともと、届いたかどうかを確認しない軽量なプロトコルでした。音声通話やゲーム、動画のリアルタイム配信など、多少欠けても速度を優先する用途が主な担い手です。遅延を数ミリ秒でも縮めたい場面では、確認と再送の仕組みそのものが重荷になります。だからこそUDPは、速度を優先する用途で選ばれてきました。

ところが近年の増加は、そうした用途だけでは説明できません。主役はWebの通信そのものです。HTTPの世界がUDPへ移り始めたことが、トラフィック構成を静かに変えました。

QUICとは何か——TCPとTLSを1本に畳んだ「UDPの上のTCP」

QUICは、UDPの上に信頼性のある通信を作り直したプロトコルです。到達確認、再送、輻輳制御、暗号化をすべて自前で持ちます。UDPは何も保証しませんが、その何も保証しない土台の上に、TCPが担っていた役割を積み上げた格好です。

最大の特徴は、暗号化の手続きが最初から組み込まれている点にあります。TCPでは接続の確立とTLSのハンドシェイクが別々に走り、往復が積み重なります。QUICはTLS 1.3を前提に設計され、初回接続で1往復、再訪時は0往復で通信を始められます。

歴史は10年単位です。Googleが2010年代初頭に社内実験として始めました。Chromeへの搭載を経て、2021年5月にRFC 9000として標準化されています。HTTP/3はRFC 9114として2022年6月に公開されています。標準化の前から動いていた点が、このプロトコルの性格をよく表しています。

ブラウザ側の対応も早く進みました。Cloudflareは2021年5月28日、全顧客向けにQUICバージョン1とHTTP/3を有効化しています。ChromeとEdgeは2020年11月、Firefoxは2021年4月に安定版へ入りました。Safariはしばらく実験機能の扱いで、対応が出そろうまでに時間がかかっています。

なぜTCPではダメだったのか——3つの構造的な限界

TCPに不満があるなら改良すればよい、という話にはなりません。TCPには設計時点で決まった制約があり、それが三つの形で現れます。

限界1：1本のパイプがすべてを待たせる

HTTP/2は1本のTCP接続の上で複数のリクエストを多重化しました。しかしTCPは、届いたデータを順番どおりにしか上位へ渡せません。1つのパケットが失われると、後続のすべてが足止めされます。これがヘッドオブラインブロッキングです。QUICはストリームを独立して扱うため、欠けたストリームだけが待ちます。

限界2：中間装置がTCPの中身を覗いている

経路上にはファイアウォールやロードバランサー、NAT装置などが多数存在します。これらはTCPのヘッダーを解釈して動作します。新しい拡張を入れても、解釈できない装置が落としたり書き換えたりするため、事実上使えません。この状態をプロトコルの硬直化と呼びます。QUICはヘッダーを暗号化して隠すことで、この干渉を避けました。

限界3：カーネルの中に閉じている

TCPはOSのカーネルに実装されています。新しい仕組みを入れたいなら、OSのアップデートを待つ必要があります。QUICはアプリケーション側の空間で動くため、ブラウザやサーバーソフトの更新だけで改善を配れます。私の環境でも、nginxのビルドオプションひとつで有効になる手軽さがあります。

【比較表】TCP＋TLSとQUICは何が違うのか

両者の違いを、実際の挙動に沿って並べます。速度の優劣ではなく、設計の前提が異なると捉えると理解しやすくなります。

項目	TCP＋TLS 1.3	QUIC（HTTP/3）
接続確立の往復	2往復（TCP＋TLS）	1往復（再訪時0往復）
多重化の待ち	1つ欠けると全体が停止	欠けたストリームのみ停止
接続の引き継ぎ	IPが変わると再接続	接続IDで継続
暗号化の範囲	ペイロードのみ	ヘッダーを含む
実装場所	OSカーネル	アプリケーション空間
中間装置の扱い	解釈・干渉あり	ほぼ不可視
サーバー対応	ほぼ全製品	対応が分かれる

数字で見る現在地——サイトの41.1％、通信の3割

2026年10月時点で、HTTP/3を使うWebサイトの割合は41.1％です（W3Techs調べ）。全サイトの4割強が対応済みという水準まで来ました。Google、YouTube、Instagram、WhatsApp、Bing、Pinterestといった主要サービスはすでに導入しています。

通信量ベースではもう少し低くなります。Cloudflareの観測では、Webトラフィックに占めるHTTP/3の比率は3割前後です。2021年頃は1割程度でしたから、5年で3倍になった計算になります。

興味深いのは、相手によって比率が大きく変わる点です。人間の閲覧に由来する通信では3割半ばまで届く一方、botと判定された通信では2％前後に留まります。普及の波が、人と機械のあいだで分かれているのです。

普及が「3割」で止まった理由——サーバー側の現実

ブラウザはほぼ全員が対応済みです。それでも通信量が3割で頭打ちになるのは、サーバー側に穴が残っているからです。加えて、経路上の設定という見落としやすい障害も待っています。

象徴的なのがApache HTTP Serverです。2026年10月1日リリースのhttpd 2.4.69は、HTTP/3のモジュールを同梱していません。mod_h2が提供するのはHTTP/2までです。QUIC対応のモジュールと、接続を穏当に終了させるためのMPM側の変更（PR #699）は2026年7月28日から未マージのままです。2.4系のコアがTCP前提で設計されていることが尾を引いています。

nginxは1.25.0以降でHTTP/3に対応しました。ただしモジュールは既定ではビルドされず、実験的という位置づけも残ります。Windows版ではビルドできません。LiteSpeedは早くから対応していた数少ない製品です。

もうひとつの壁が、UDPの443番ポートです。ファイアウォールやクラウドのセキュリティグループは、TCPの443を許可していてもUDPは落とす設定が少なくありません。サーバー側の設定は正しいのに繋がらない、という相談の多くはここに行き着きます。CDNを前段に置けば元サーバーの対応は不要になるため、対応コストを避けたいサイトほどCDN頼みになります。

速いのか、遅いのか——「QUIC is not Quick Enough」という反論

QUICは常に速い、という前提には注意が必要です。2024年のACM Web Conferenceで発表された論文は、高速回線では逆転が起きると報告しました。帯域が1Gbpsに達すると、ChromeのQUICはHTTP/2より45.2％遅いという結果です。

原因は受信側の処理負荷にあります。同じファイルを落とす際、UDPのスタックが処理するパケット数はTCPの10倍近くに膨らみました（平均74万4,000対5万8,000）。カーネルを経由する回数の多さと、パケット単位の暗号化が効いてきます。私の手元の検証でも、太い回線ほど差が出にくいという印象でした。

一方で、回線が乱れる場面では強さを発揮します。損失率20％の環境では、QUICのトンネルを経由したTCPが素のTCPより4.6倍のスループットを出したという測定があります。電波状況が変動するモバイルや、海外をまたぐ経路はQUICの得意分野です。速いか遅いかは、回線の質で答えが変わるというのが正確なところです。

思わぬ副作用——ボットはHTTP/3を使わない

普及の偏りは、別の意味も持ちます。自動化されたクローラーや監視ツールの多くは、HTTP/3に対応していません。結果として「HTTP/3で来ない通信は機械の可能性が高い」という推測が成り立ちます。

実際、Cloudflareの観測ではbot判定の通信のHTTP/3比率は2％前後です。人間側の3割半ばと比べると、差は明白です。ボット対策の現場では、この差が新しい判定材料として使われ始めています。スクレイピングを業務で行う立場からすると、対応の遅れがそのまま検知リスクになります。監視ツールがHTTP/2のまま止まっている例も珍しくありません。

別の副作用は可視性の低下です。ヘッダーまで暗号化されるため、経路上の装置からは通信の中身が見えません。障害調査や帯域の内訳分析は、端末側とサーバー側のログに頼るしかなくなります。便利さと引き換えに、運用の道具立てが変わりました。

次の10年——VPNもDNSもQUICの上へ

QUICの上には、すでに新しい用途が積み上がっています。QUIC自体のバージョン2はRFC 9369として標準化され、複数経路を同時に使うMultipath拡張も議論が続きます。

VPN的なトンネルを作るMASQUEは、TCPやIPのパケットをQUICで包みます。Cloudflareは自社のWARPをこの方式へ移行しました。DNSをQUICで運ぶ仕様もRFC 9250として存在します。ブラウザとサーバーのあいだだけでなく、名前解決や経路そのものが置き換わりつつあります。

TCPが消えるわけではありません。長年運用されてきた実装と知見はあまりに大きく、両者は当面併存します。ただ、新しい機能の実験場はQUICへ移りました。次の10年で主役が入れ替わる可能性は十分にあります。

【FAQ】QUICとHTTP/3に関するよくある質問

読者から寄せられやすい疑問を、5つにまとめました。

質問	回答
QUICとHTTP/3は同じものですか？	別物です。QUICは転送の仕組みで、HTTP/3はその上で動くHTTPの版です。
導入すると必ず速くなりますか？	回線次第です。損失の多いモバイルでは効果が出やすく、太い回線では差が出にくい傾向があります。
自分のサイトが対応しているか確認する方法は？	ブラウザの開発者ツールでプロトコル欄を見るか、Alt-Svcヘッダーの有無を確認してください。
セキュリティ上の懸念はありますか？	暗号化が前提のため盗聴には強い一方、経路上での監視や分析は難しくなります。
Apacheで使うにはどうすればよいですか？	本体の対応待ちか、nginxやLiteSpeed、CDNを前段に置く構成が現実的です。

まとめ——見えない土台が入れ替わる静かな10年

QUICは、目に見える新機能ではありません。アプリの画面も変わりません。それでも、通信の3割が別の作法に移り、サイトの4割が対応し、ボット対策の指標まで変わりました。土台の入れ替わりは、いつも静かに進みます。

次にサイトの表示速度を測るときは、サーバーの中身と回線の質をセットで見てください。同じURLでも、経路によって使われているプロトコルは違います。自分の環境がどちらで動いているか、一度確認してください。

そして、QUICが当たり前になった世界の次の変化にも注目したいところです。名前解決もトンネルも同じ土台へ移りつつあります。インターネットの次の10年は、この見えない層から始めましょう。