「HTTPS・TLS・HTTP/3」とWeb通信の裏側
鍵マークがついているから安全…は本当？
この記事の目次
スマホやパソコンでWebサイトを見ているとき、アドレスバーのURLの左端にある「鍵マーク（🔒）」や「https://」という文字を意識したことはあるでしょうか。
「鍵マークがついているから、このサイトは安全！」
「暗号化されているはずだから、クレジットカード情報やパスワードを入れても大丈夫！」
そう信じている人も少なくないでしょう。今や、コーポレートサイトからECサイト、公共サービス、教育機関のサイトにいたるまで、インターネット上のほぼすべてのWebサイトに鍵マークがついています。
しかし実際には、「ブラウザに鍵マークが表示されている ＝ そのWebサイトの通信全体が100%安全かつ高速である」とは限らないという不都合な事実が存在します。
現代のWebサイトの多くは、Cloudflare（クラウドフレア）に代表される「CDN（コンテンツ配信ネットワーク）」を利用して配信されています。そのような構成では、鍵マークが付いている表側に対して、ユーザーから見えない通信の裏側が、安全性とスピードに大きく関わる鍵を握っているのです。
ここでは、専門用語だらけで難しく見えがちなHTTPS、TLS、HTTP/3といったWeb通信の仕組みを、身近なたとえ話を交えながら、エンジニアでない人にもスッキリと確実に理解できるように解説します。
通信の信頼性を担保する「HTTPS」と「TLS」
まずはじめに、基本中の基本として、「HTTPS」と「TLS」という技術用語の意味を確認しておきましょう。そのためには、まずHTTPSの元になった「HTTP」の意味を知る必要があります。これは、「Hyper Text Transfer Protocol」の頭文字を取ったもので、インターネットの比較的初期から使われている、一種の通信プロトコルです。簡単に言えば、ウェブページの根幹であるhtml（hyper text markup language）で書かれた文書や、それに付随するデータを、インターネット経由で配信するための規約ということになります。
それに対して「HTTPS」は、それに「安全な」という意味の形容詞、「Secure」を付けた略語です。形容詞の位置としてはやや不自然ですが、安全なバージョンのHTTPという意味で、同じ「HTTP」で始めるための命名だと考えられます。
ということは、裏を返せば、HTTPは危険だということになります。実はHTTPの場合、通信が途中で読み取られると、中身が丸見えになってしまうのです。それに対してHTTPSでは、たとえ途中で読み取られても、中身は暗号化されているため、暗号を解読しない限り、第三者に通信の内容を知られることはありません。たとえるなら、同じ手紙のやりとりでも、HTTPはハガキによるもの、HTTPSは封印された封書によるものと考えられるでしょう。
一方のTLSは、「Transport Layer Security」の頭文字を取ったもので、通信を暗号化するためのプロトコル＝規約のことです。いわばHTTPとHTTPSの違いを生み出すための技術です。上の郵便のたとえを当てはめれば、通信内容が見えないようにする封筒の仕様や、それを封印、開封するための手順を定めたものと言うことができるでしょう。TLSによって、通信データを暗号化し、盗み見られたり、改ざんされたりすることを防ぎます。
さらに、TLSには「証明書（SSL/TLS証明書）」という身元確認の仕組みがあります。アクセスしているWebサイトが本物の公式サイトであり、偽物のフィッシングサイトではないということを電子的に保証してくれます。これはネット世界で、安全と信頼を確保するパスポートのような役割を果たしているのです。
ところで、TLSと聞くと「SSL」という用語を思い出す人もいるかもしれません。SSLは、「Secure Sockets Layer」の頭文字を並べたもので、用途は、TLSと同じ、通信の暗号化です。しかし、同じ暗号化のためでも、SSLは古い技術、規格で、脆弱性が発見されたため、現在では使われていません。SSLとTLSは混同されがちですが、世代が異なるもので、以前にSSLが使われていた部分も、現在はすべてTLSに置き換えられています。
出典：RFC 8446 The Transport Layer Security Protocol Version 1.3
Cloudflareによって２つに分割される通信経路
ユーザーがWebサイトを見る時、従来は「自分のスマホ → Webサイトのサーバー（オリジンサーバー）」のように直接つながるのが基本でした。しかし、人気のあるサイトのサーバーに世界中からアクセスが集中したりすると、サーバーがパンクして落ちてしまうこともあります。DDoS攻撃を受けたような場合も同様です。
そこで登場したのが、Webサイトとユーザーの間に入って通信を仲介してくれるCDN、あるいはプロキシと呼ばれるCloudflareのようなサービスです。いわば「巨大な警備員兼、配達中継拠点」のような役割を果たすものです。
Cloudflareは、世界中に張り巡らされたネットワークを使って通信を高速化すると同時に、サイバー攻撃を防いだり、その影響を緩和したりしてくれます。
ところでCDNを利用すると、ユーザーとWebサイトの間の通信経路が、以下のように2つの区間に分かれることにお気づきでしょうか。
- 区間①： ユーザー（あなたのスマホ） ⇔ Cloudflare
- 区間②： Cloudflare ⇔ オリジンサーバー
このように、通信経路がCloudflareを挟んで２つに分かれていることが、Webの安全性を考える上でとても重要なポイントになってきます。どういうことか、詳しく見ていきましょう。
「鍵マークがあるのに危険!?」： 2つの暗号化モードの罠
ユーザーのスマホのブラウザーに「鍵マーク」が表示されているとき、それは区間①（ユーザー ⇔ Cloudflare）の通信が暗号化され、安全な通信が確保されていることを意味しています。そのとき、区間②（Cloudflare ⇔ オリジンサーバー）の方はどうなっているのでしょうか？
実はCloudflareの設定次第では、ここが暗号化されていないHTTP通信による「丸見え状態」になっているケースがあるのです。Cloudflareでは、このような状態を「Flexible（フレキシブル）モード」と呼んでいます。それに対して、Cloudflareの前後、２つの通信経路とも暗号化された状態を「Full strict（フル・ストリクト）モード」と呼びます。それぞれの状態を整理しておきましょう。
- Flexible（フレキシブル）モード：偽りの安全
区間①のユーザーからCloudflareまでは、暗号化されたHTTPSによる通信となりますが、区間②のCloudflareからオリジンサーバーまでは暗号化されていないHTTP通信になります。
ユーザーの画面には「鍵マーク」が表示されるため、一見安全に見えます。しかし、後半の区間②を通るデータは、いわゆる「平文」となるので、その間で盗聴されたり改ざんされたりする危険が生じます。
これをまた郵便にたとえるなら、差出人が手紙を封印された封書としてポストに投函したのに、郵便局の職員が封書を開封し、中の手紙をハガキとして受取人まで運んで配達するようなものです。
- Full strict（フル・ストリクト）モード：本物の安全
区間①のユーザーからCloudflareまでと、区間②のCloudflareからオリジンサーバーまで、全区間を完璧に暗号化します。さらに、オリジンサーバーが提示する「証明書」が偽物でないか、有効期限が切れていないかまでも、Cloudflareが厳密にチェックします。
これをたとえるなら、差出人がポストに投函した封書を回収した郵便局で、差出人の封書をさらに別の封筒に入れて封印し、配達員の身元もしっかり確認した上で、完全に鍵をかけたまま受取人まで届けることに相当するでしょう。
企業のWeb担当者やシステムエンジニアは、単に「ブラウザに鍵マークが出たからOK！」と安心するのではなく、区間①と②の両方が、しっかり暗号化されているか、つまりFull strictモードになっているかどうかを確認しなければなりません。
実際、2026年8月には、OpenAIの共同創業者であるグレッグ・ブロックマンが、自身の個人サイトをセキュリティAIに診断させたところ、CloudflareからAWS（オリジンサーバー）への通信が暗号化されていなかった、つまりFlexibleモードになっていた、という事象が報告されています。どんなに優れたエンジニアや技術リーダーであっても、インフラ全体の入り口から目的地までを一貫した設計、設定で貫いていなければ、このような死角が生まれてしまうという笑えない教訓でしょう。
一方、Cloudflareには、追加したドメインに対して、SSL/TLS証明書を無料で自動発行、更新してくれる「Universal SSL」という非常に便利な機能が備わっています。これにより簡単に鍵マークをつけることができるようになりました。ただし、証明書をオンにしただけで満足し、Cloudflareの「Always Use HTTPS」機能を使ってHTTPアクセスをHTTPSへ強制的に切り替える「自動転送（リダイレクト）」を設定することを忘れていると、暗号化されない通信経路を狙う攻撃者に隙を与えてしまうことになります。
出典： Cloudflare Docs: Encryption modes
出典： Cloudflare Docs: Full strict
出典： Cloudflare Docs: Get started with SSL/TLS
出典： Cloudflare Docs: Universal SSL
TLSは安全性だけじゃない！通信を爆速にする「TLS 1.3」
通信を暗号化すると、暗号化や復号化の処理のために、Webサイトの表示が遅くなるのではないか、と思う人も少なくないかもしれません。かつては、確かにそうした傾向がありました。セキュリティを強固にすると表示速度が犠牲になる、というのが避けて通れない常識だったのです。しかし、現在その常識は、最新の暗号規格である「TLS 1.3」によって完全に覆されています。TLS 1.3は、安全性を極限まで高めると同時に、接続を確立するのに要する時間を短縮することで、通信のスピードを大幅に改善することに成功したのです。
インターネットでHTTPSによる安全な通信を開始する際には、ユーザーのブラウザーとWebサーバーの間で、「これ以降は暗号化して通信しよう」、「どの暗号の鍵を使う？」といった事前準備のやり取りが行われます。これを「TLSハンドシェイク（握手）」と呼びます。
従来のTLS 1.2では、お互いが合意して実際にWebページのデータを送り始めるまでに、メッセージを2往復させる必要がありました。そのためにかかる時間を「2RTT（2Round-Trip Time）」と呼びます。それに対して、最新のTLS 1.3では、技術的な合理化によって、これが1往復（1RTT）で済むようになりました。さらに、過去に接続したことのあるサイトの場合は、それがゼロ往復（0-RTT）で済むのです。つまり、いきなり暗号化されたデータによる通信を始めることすら可能になったというわけです。
CloudflareはもちろんTLS 1.3に標準対応しています。ただし、ここでWebサイトの運営者に突きつけられるのが、「古いスマホや古いブラウザー（レガシー環境）をどこまでサポートするか？」という判断です。
TLS 1.0や1.1のように、あまりにも古い通信プロトコルをサポートし続けると、セキュリティ上の抜け道になりかねません。しかし、サポートを止めれば、そうした古いプロトコルにしか対応していない古い端末を使っているユーザーを切り捨てることになります。
新しい技術のサポートを追加するだけでなく、セキュリティを強化するために、古い技術をどこで切り捨てるか、という決断もプロのWeb運営者には求められるのです。
出典： Cloudflare Docs: TLS protocols
通信の土台を根本から変える「HTTP/3」と「QUIC」の衝撃
安全性の次は、スピードについて話を進めましょう。Webの基本的な通信プロトコル、HTTPの進化についてです。
HTTPとひとくくりに言っても、その中身は「HTTP/1.1」、「HTTP/2」と徐々に進化してきました。HTTP/1.1がリクエストを１つずつ順番に処理するのに対し、HTTP/2では、複数のリクエストを同時に処理できるようにすることで、通信の高速化を図っています。
とはいえ、これらはいずれも、インターネットにとってもっとも基本的な「TCP（Transmission Control Protocol）」と呼ばれるプロトコルの上で動くものです。TCPは、データが相手に正しく届いたかを１回毎に確認しながら確実に進める、非常に真面目で信頼性の高い通信方式です。しかし、この真面目さゆえに、通信が不安定な環境では、通信結果が確認できずにフリーズしてしまうことがある、という弱点も存在します。たとえば、電波が不安定なモバイル環境などでは、画面の表示が固まって、操作を受け付けなくなることもあります。これは「Head-of-line blocking（先頭詰まり）」と呼ばれる現象です。
Head-of-line blockingは、「列の先頭をせき止める」といった意味です。１車線の道路をイメージしてみてください。ユーザーのスマホはWebサイトを表示するために、文章や画像に加えてスタイル（CSS）、プログラム（JavaScript）など、多くのデータを、それぞれ別々のトラックで運んでもらっているとします。ここで、それらのトラックの車列の先頭が事故を起こして道路の真ん中に止まってしまったとしましょう。その後ろを走るトラックは、事故には巻き込まれなかったとしても、先頭車両の事故処理が済むまで、通行することができず、その間運搬は止まってしまいます。これが先頭詰まりです。
HTTP/1.1やHTTP/2が採用しているTCPでは、もし先頭を走っている画像データのトラックが、電波障害などによるパケット損失といった事故を起こして止まってしまうと、後続の文章のトラックやプログラムトラックが、すべて足止めを食らってしまうのです。
このような問題を解決するために作られたのが、最新の「HTTP/3」です。そしてその土台を支える通信プロトコルが「QUIC（クイック）」というわけです。QUICは、TCPの代わりに、細かな確認を省略し、スピードを重視する「UDP（User Datagram Protocol）」と呼ばれるプロトコルをベースに作られました。最大の特徴は、データの種類ごとに道路の車線を完全に分け、「マルチストリーム化」することにあります。たとえ画像データを運ぶトラックが事故を起こして遅れても、別の車線を走っている文章やプログラムを運ぶトラックは事故の影響を受けずに、スピーディにデータを運ぶことができます。
HTTP/3が本領を発揮するのは、特に、電波が不安定になりがちな移動中のスマホ（4G/5G回線）や、駅の構内、カフェなどの混雑したフリーWi-Fi環境など、通信条件がよくない場合です。逆に言えば、安定した通信環境下では、特に大きな高速化の効果は得られません。
またHTTP/3の効果については、誤解しやすいポイントもあります。サイト内の画像データ自体が巨大だったり、サーバー自体の処理が遅かったりした場合は、HTTP/3を採用したからと言って、Webサイトの表示速度を改善することはできません。というのも、HTTP/3は「道路を増やし、配送をスムーズにする」ものであって、「運んでいる荷物の重さ（データサイズ）を減らしてくれる」ものではないからです。
出典： RFC 9114: HTTP/3
出典： Cloudflare Docs: HTTP/3 (with QUIC)
CloudflareのHTTP/3は「全区間」である必要がない!?
Cloudflareを導入すると、管理画面のボタンひとつで、Webサイトを「HTTP/3対応」にすることができます。「これでWebサイト全体がHTTP/3対応になった！」と安心しがちですが、ここにもう一つ知っておくべき「技術的な割り切り」があります。
現在（2026年時点）のCloudflareの仕様では、HTTP/3が使われるのは、上で説明した区間①に限られています。つまり、ユーザーとCloudflareのエッジサーバーとの間だけです。では、残り半分、区間②のCloudflareとオリジンサーバーの間はHTTP/3化されなくても大丈夫なのか、と思われるかもしれません。しかし、実質的にはこれで十分なのです。
なぜなら、通信エラーや電波の途切れなどによるパケット落ち、その他の障害が発生しやすいのは、ノイズや混雑、通信機器の移動、無線区間を含む区間①の方が圧倒的に多いからです。一方で、区間②の方は、ほとんどデータセンター同士の通信となり、高品質で安定した光ファイバーなど、有線の専用バックボーン回線で結ばれています。そのため、従来のTCP通信でもエラーは極めて起きにくく、十分な高速性が担保されます。
Cloudflareを既存の通信経路の間に挟む最大のメリットは、自社の古いWebサーバーを買い替えたり、複雑な最新プロトコルを自力で設定したりしなくても、ユーザーに対して世界最先端の高速、安全な通信体験（HTTP/3やTLS 1.3）を即座に提供できることにあるのです
DOMOの視点
鍵マークではなく、利用者からオリジンまでを見る
Webサイトを確認する際に、ブラウザーの表示がHTTPSになっているかどうかだけを見ても、通信設計のごく一部分しか分かりません。DOMOとして確認したいのは、区間①のユーザーからCloudflareまでと、区間②のCloudflareからオリジンサーバーまで、という通信全体です。
ブラウザー側ではHTTPSになっていても、Cloudflareからオリジンサーバーまでは暗号化されていない、ということは容易に起こり得ます。こうした状態を避けるためにも、２つの分かれた通信経路それぞれを確認する必要があります。
また、HTTPS、TLS、HTTP/3を、それぞれ独立した機能として考えない、ということも重要です。HTTPSとTLSで安全な通信を確保する。TLS 1.3やHTTP/3など新しい通信方式を積極的に利用する。CDNやキャッシュで配信距離やオリジンサーバーへのアクセスを減らす。こうした対策を適切に組み合わせてこそ、ユーザーに対して安全で高速なWeb体験を提供できるのです。
通信の設定は、ユーザーからはほとんど見えません。だからこそ、ユーザーが目にする鍵マークにこだわるだけでなく、その裏側までを慎重に設計することが重要です。
まとめ
まとめとして、これまでに強調してきた重要なポイントを整理しておきましょう。
- HTTPSとTLS
- HTTPSは安全な「状態」、TLSはそれを支える「暗号化技術」
- 通信の2つの区間
- Cloudflareを使うと「ユーザー ⇔ Cloudflare」と「Cloudflare ⇔ オリジンサーバー」の2つの接続が発生
- 暗号化モードのチェック
- ブラウザーに鍵マークがついていても、オリジン間が裸（HTTP）の「Flexible」ではなく、最後まで保護する「Full strict」を選択
- 速度と安全性の両立（TLS 1.3 & HTTP/3）
- TLS 1.3で接続の握手を高速化し、HTTP/3（QUIC）でスマホ通信のパケット詰まりを解消
覚えておきたい用語
- HTTP： Webページをやり取りするための基本的な「会話ルール」
- HTTPS： 暗号化（TLS）で保護された安全なHTTP通信の「状態」
- TLS： 通信の暗号化、改ざん防止、相手の身元確認を行う「セキュリティ技術」
- TLS 1.3： 安全性を高めつつ、接続時の握手（会話）を1往復で終わらせる最新のTLS規格
- 証明書： 「このサイトは本物ですよ」と証明するデジタルな身分証明書
- オリジンサーバー： Webサイトの実際のデータやプログラムが置いてある「本拠地サーバー」
- Flexibleモード： 入口（ユーザー側）だけ暗号化し、奥（サーバー側）は裸のままにする危険な設定
- Full strictモード： 入口から奥まで完全に暗号化し、相手の身元も厳しくチェックする安全な設定
- HTTP/3： QUICを使ってデータの遅延や詰まりをなくした最新のHTTP規格
- QUIC： UDPをベースにして作られた、HTTP/3の土台となる超高速プロトコル
- TCP： データが届いたか1つずつ確認する、真面目だが詰まりやすい伝統的な通信方式
- UDP： 確認作業を省略して、とにかくスピードと効率を重視した通信方式
- Head-of-line blocking（先頭詰まり）： 先頭のデータが事故を起こすと、後ろのデータまで全部止まってしまう現象
- Universal SSL： Cloudflareが自動で無料発行・更新してくれる便利な証明書機能