HTTPS は「盗み見・改ざん・なりすまし」をまとめて防ぐ“前提条件”
まず一番大事なことから。
今どきの Web 開発で
「HTTP でいい場面」はほぼゼロ です。
ログインがあるから HTTPS
クレジットカードを扱うから HTTPS
ではなく、
フォームがある
Cookie を使う
センサーを使う
Service Worker を使う
位置情報・カメラ・マイクを使う
こういうものは、全部 HTTPS 前提 です。
HTTPS は「ちょっとセキュアになるオプション」ではなく、
「現代の Web のスタートライン」 だと思ってください。
HTTP と HTTPS の違いを“手紙”でイメージする
HTTP は「ハガキ」、HTTPS は「封筒＋本人確認付き」
HTTP 通信は、ざっくり言うと「ハガキ」です。
途中で誰が見ても中身が丸見え
途中で書き換えられても気づけない
本当にその差出人かどうかも分からない
一方、HTTPS はこうです。
中身は暗号化されていて読めない
書き換えられると「壊れた」と分かる
証明書で「このサーバーは本物か」を確認できる
つまり HTTPS は、
盗み見防止（暗号化）
改ざん防止（完全性）
なりすまし防止（認証）
をまとめてやってくれる仕組みです。
なぜ「暗号化」がそんなに重要なのか
平文 HTTP は“途中で全部見える”前提
HTTP だと、
リクエストもレスポンスも「そのままの文字列」で流れます。
URL
クエリパラメータ
フォームの中身
Cookie
これらが、ネットワークの途中にいる誰かに
そのまま見えてしまう可能性があります。
例えば、HTTP でログインフォームを送ると、
ユーザー名
パスワード
が、途中のルーターや Wi-Fi アクセスポイントで
丸見えになる可能性があります。
HTTPS では、
ブラウザとサーバーの間の通信が暗号化されるので、
途中の人には「意味不明なデータ」にしか見えません。
ここで重要なのは、
「自分のサイトは大した情報扱ってないから大丈夫」
ではなく、
「ユーザーがどんな環境からアクセスするかはコントロールできない」
という事実です。
カフェのフリー Wi-Fi
よく分からない共有ネットワーク
そういう場所でも「とりあえず安全に」使えるようにするのが HTTPS です。
「改ざん防止」が守ってくれるもの
途中で“勝手に書き換えられる”世界を想像してみる
HTTP では、
途中の誰かがレスポンスを書き換えても、
ブラウザは気づけません。
例えば、こんなことが理論上可能です。
あなたのサイトの HTML に、
勝手に広告の script を差し込まれる
勝手にマルウェア配布用のリンクを埋め込まれる
ユーザーから見ると、
「あなたのサイトが変な広告を出している」
「あなたのサイトからウイルスを配っている」
ように見えます。
HTTPS では、
レスポンスが途中で書き換えられると
「暗号が合わない＝壊れている」と判断されます。
ブラウザは「安全な通信じゃない」と判断して
接続を切ったり、警告を出したりします。
つまり HTTPS は、
「あなたのサイトの内容が、ユーザーに届くまでの間に勝手にいじられない」
ことを保証してくれる仕組みでもあります。
「なりすまし防止」と証明書の役割
本当にそのサーバーと話しているのか？
HTTPS では、
サーバーは「証明書」をブラウザに見せます。
証明書には、
このドメインの持ち主は誰か
いつまで有効か
信頼できる認証局が発行したか
といった情報が入っています。
ブラウザは、
証明書が信頼できる認証局から発行されているか
ドメイン名が一致しているか
有効期限内か
をチェックします。
これによって、
https://example.com にアクセスしたつもりが、
途中で evil.com にすり替えられていた
みたいな「なりすまし」を検出できます。
証明書エラーが出たときに
ブラウザがあれだけ強い警告を出すのは、
「相手が本物かどうか分からない」 状態だからです。
HTTPS は「機能の前提条件」でもある
センサー・Service Worker・HTTP/2…いろいろ HTTPS 必須
最近の Web API の多くは、
「安全なコンテキスト（secure context）」 でしか動きません。
安全なコンテキストとは、ざっくり言うと
https:// で配信されているページhttp://localhost（開発用の特例）
のことです。
例えば、次のようなものは HTTPS 前提です。
位置情報（Geolocation）
カメラ・マイク（getUserMedia）
通知（Notification）
Service Worker / PWA
一部のセンサー API
HTTP のままだと、
API 自体が存在しない扱いになる
権限ダイアログが出ない
ブラウザがブロックする
といったことが普通に起きます。
つまり、
「HTTPS にするかどうか」ではなく
「HTTPS にしないと、そもそもモダンな機能が使えない」
という世界になっています。
パフォーマンス面でも HTTPS は“むしろ有利”
「暗号化は重いから遅くなる」はもう古い感覚
昔は「HTTPS は遅い」というイメージがありましたが、
今はむしろ逆です。
HTTP/2 や HTTP/3 は、
ほぼ HTTPS 前提で使われています。
これらは、
複数リクエストの多重化
ヘッダ圧縮
接続の再利用
などによって、
HTTP/1.1 よりも効率よく通信できる ようになっています。
つまり、
HTTP（暗号化なし・古いプロトコル）
よりも
HTTPS（暗号化あり・HTTP/2/3）
の方が、
実際には速くなるケースが多いです。
「セキュアにしたら遅くなる」は、
今の Web ではほぼ当てはまりません。
開発者として HTTPS をどう意識すべきか
ローカルは http://localhost、本番は必ず https://
初心者としてまず意識してほしいのは、このラインです。
ローカル開発http://localhost:3000 などで OK（特例として secure 扱い）
本番・ステージング
必ず https:// で公開する
そして、コードを書くときに
「この API、HTTPS 必須じゃない？」
「この機能、HTTP だとそもそも動かないのでは？」
と一度立ち止まる癖をつけておくと、
設計の段階でミスに気づきやすくなります。
初心者として「HTTPS の重要性」で掴んでほしいこと
最後に、要点だけギュッとまとめます。
HTTPS は「暗号化」「改ざん防止」「なりすまし防止」をまとめてやる仕組み
HTTP は“ハガキ”、HTTPS は“封筒＋本人確認付き”くらい違う
ユーザーの環境（怪しい Wi-Fi など）を前提にしても安全にするために必須
モダンな Web API（位置情報・カメラ・Service Worker など）は HTTPS 前提
パフォーマンス的にも、HTTP/2/3 とセットでむしろ有利なことが多い
あなたが何かを作るとき、
「とりあえず HTTP でいいや」ではなく
「HTTPS を前提にして設計する」 という感覚を持てたら、
それだけで一段プロ寄りのエンジニアになっています。