HTTPS（SSL化）ってなに？
HTTPS（いわゆるSSL化）は、ブラウザとサーバー間の通信を暗号化し、盗聴・改ざん・なりすましのリスクを下げる仕組みです。今は「入れていると良い」ではなく、Web運用の標準装備。SEO上もHTTPSはランキングシグナルとして明言されており、Chrome等のブラウザ表示でもHTTPは“不安全”として扱われます。この記事では仕組みから移行・運用まで、実務で使える形で整理します。
HTTPS（SSL化）とは？（まず結論）
HTTPSは、HTTP通信をTLSで暗号化したものです（HyperText Transfer Protocol Secure）。 これにより、ブラウザとサーバーの間のやり取りが保護され、第三者に盗み見・改ざんされにくくなります。
いわゆる「SSL化」は、現在の実態としては「TLSでHTTPSにすること」を指す場面がほとんどです。
HTTPSで何が守られる？3つの役割
- 暗号化：通信内容を第三者が読みにくくする（盗聴対策）
- 改ざん防止：途中で内容を書き換えられにくくする
- なりすまし防止：「本物のサイト（ドメイン）」に接続していることを証明書で確認する
「HTTPSでも守れないこと」も理解しておく
- サーバー自体の脆弱性（侵入・改ざん）をゼロにするわけではない
- 入力フォームの設計ミスや漏えい（運用・権限管理）が原因の事故は別対策が必要
- ユーザー端末のマルウェア等はHTTPSだけでは防げない
「SSL」と「TLS」の違い（なぜSSL化と呼ぶ？）
現在、Webの暗号化通信は主にTLSが使われています。 ただし慣習的に「SSL」という呼び方が広く残っており、「SSL化＝HTTPS化」という意味で使われがちです。
SEOへの影響：HTTPSはランキングシグナル
GoogleはHTTPSを検索ランキングのシグナルとして利用すると公式に発表しています（当初は軽量なシグナルとして位置づけ）。
重要なのは「HTTPSにしただけで順位が上がる」という単純な話ではなく、 同程度の内容・同程度の評価のページが並んだときに差がつきやすい土台になる、という点です。
ブラウザ表示：HTTPは「Not Secure」になりやすい
Chromeは、HTTPページを「保護されていません（Not Secure）」と表示する方針を段階的に強化してきました。 2018年7月公開のChrome 68で「すべてのHTTPサイトをNot Secureとして扱う」方針が示されています。
これにより、ユーザーは「このサイト大丈夫？」と感じやすくなり、フォームの離脱やCVR低下につながることがあります。
HTTPS化に必要なもの：証明書・CA・種類
HTTPS化には、サーバーに証明書（TLS証明書）を設定する必要があります。 証明書は信頼できる発行元（CA：認証局）によって発行され、ブラウザはそれを検証して安全な接続を確立します。
証明書の種類（目的別の考え方）
| 種類 | 確認内容 | 主な用途 | 補足 |
|---|---|---|---|
| DV | ドメイン所有の確認 | ブログ/コーポレート/一般サイト | 最も一般的。導入・更新が速い |
| OV | 組織実在の確認 | BtoB/取引先向けなど | 発行に審査が入る場合が多い |
| EV | より厳格な組織確認 | 金融/重要取引 | 表示仕様はブラウザで変遷あり（要件確認推奨） |
Let’s Encryptの有効期間（運用の現実）
Let’s Encryptの標準証明書は90日有効で、運用上は自動更新が前提です。
HTTP→HTTPS移行の基本手順（失敗しない順番）
HTTP→HTTPSは「URLが変わる（http→https）」ため、実務上はサイト移転（URL変更）と同じ注意が必要です。 GoogleはHTTPS移行の実務ガイドをまとめています。
手順（おすすめ順）
- 証明書を発行・設置（本番/サブドメイン/ワイルドカード等の範囲確認）
- HTTPSでページが表示できることを確認（主要テンプレ・フォーム・決済など）
- HTTP→HTTPSを301リダイレクト（全URL）
- 内部リンク・画像・CSS/JSのURLをHTTPSへ統一（混合コンテンツ対策）
- canonical/hreflang/構造化データのURLもHTTPSに更新
- サイトマップをHTTPS版で出力し送信（必要ならrobots.txtのSitemapも更新）
- Search ConsoleでHTTPS側を確認（サイトマップ、インデックス、エラー）
「リダイレクト品質」だけは厳密に
- 301で統一（移行の意図を明確に）
- リダイレクトチェーン（A→B→C）を極力避け、最短で目的URLへ
- http→https と www有無 の正規化を一貫させる
移行で起きがちな落とし穴（混合コンテンツ等）
1) 混合コンテンツ（Mixed Content）
HTTPSページの中で、画像やJS/CSSなど一部がHTTPで読み込まれている状態を混合コンテンツと呼びます。 表示崩れ・機能不全・警告表示の原因になります。
- 対策：すべての参照URLをHTTPSへ置き換える（外部サービスもHTTPS対応へ）
- 確認：DevTools Console、PSI/Lighthouse、実機ブラウザ
2) canonicalがHTTPのまま
- 影響：Googleに「HTTPが正規」と伝わり、評価統合がブレる
- 対策：canonical/hreflang/構造化データ/OGP/AMP等、URLが入る箇所を一括点検
3) 外部タグ・広告・計測が原因で崩れる
- HTTPの計測タグや埋め込みが混在すると、混合コンテンツになりやすい
- 移行後は「フォーム送信」「計測（GA4等）」「CVタグ」「チャット」などの動作確認を必ず実施
HTTPSで「速くなる」？HTTP/2・HTTP/3の話
HTTPSは暗号化の仕組みですが、実務上はHTTPSを前提にHTTP/2やHTTP/3を有効化できる環境が多く、 結果として体感が良くなることがあります（サーバー/CDN設定次第）。
- HTTP/2：同一接続での多重化などで効率化しやすい（環境に依存）
- HTTP/3：QUICベースで、モバイル回線のような不安定環境でメリットが出ることがある
ただし「HTTPSにしたら必ず速くなる」ではありません。画像最適化・JS削減・キャッシュなどの基本施策とセットで考えるのが現実的です。
（任意）HSTSとは？使うときの注意点
HSTSは、ブラウザに「このドメインは常にHTTPSで接続する」ことを指示する仕組みです。 強力ですが、設定ミス時の影響も大きいので段階導入がおすすめです。
- おすすめ：まずは短いmax-ageから運用し、問題がないことを確認して延長
- 注意：HTTPSが不安定な状態で強制すると、アクセス不能のリスク
運用・監視：更新切れ/警告/計測の確認
証明書の更新切れを防ぐ（最重要）
- Let’s Encrypt等は短期更新が前提なので、自動更新の監視を仕組み化する
- 期限切れはブラウザ警告→離脱につながりやすい
移行後のチェック（最低限）
- Search Console：HTTPSのプロパティでサイトマップ/インデックス/エラー確認
- アナリティクス：参照元が崩れていないか、自己参照が増えていないか
- 重要導線：フォーム送信、決済、ログイン、資料DLなどの実機確認
- 速度：PSI/Lighthouseで主要ページを再計測（大きな悪化がないか）
セキュリティを一段上げるなら（任意）
- Secure / HttpOnly / SameSite などCookie属性の点検（ログインや問い合わせフォームがある場合）
- Content-Security-Policy（CSP）の検討（サードパーティが多いサイトほど効果が出やすい）
FAQ
Q1. HTTPSにすると順位は上がりますか？
GoogleはHTTPSをランキングシグナルとして明言していますが、単独で順位が決まるものではありません。 ただし、信頼性・CVR・ブラウザ表示の観点で導入価値は大きいです。
Q2. 「常時SSL」は何が違う？
以前はログインや決済ページだけHTTPSのサイトもありましたが、 今はサイト全体をHTTPSにする（常時HTTPS）が一般的です。混合コンテンツやURL統一の面でも管理が楽になります。
Q3. HTTP→HTTPS移行で一番やりがちなミスは？
（1）混合コンテンツと（2）canonical/内部リンクのHTTP残りが多いです。 「301だけで終わり」にせず、サイト内の参照URLをHTTPSに統一すると安定します。
まとめ：HTTPSは“標準装備”。移行は丁寧に
- HTTPSは通信を保護し、盗聴・改ざん・なりすましのリスクを下げる
- GoogleはHTTPSをランキングシグナルとして明言
- Chrome等のブラウザはHTTPを「Not Secure」と表示する流れ
- 移行は301・canonical・サイトマップ等をHTTPSへ統一するのが要点
- 証明書は更新運用が重要（Let’s Encryptは90日）