用語比較
HTTPとHTTPSの違い
一言でいうと
http://はTLSによる保護を要求しないURL方式、https://はHTTP通信をTLSで保護するURL方式です。HTTPS化は通信の機密性・完全性と接続先の認証を支えますが、詐欺サイトや不正な依頼まで排除しません。運用では証明書だけで終えず、転送・内部の資源・業務機能・検索用URLとHSTSの影響を確認します。
HTTPとHTTPSの違いと常時HTTPS化の確認方法を解説。通信保護とサイトの正当性を区別し、301・308転送、混在コンテンツ、CDN区間、canonical・sitemap、HSTSの条件を比較表で整理します。初心者とWeb担当者が、移行後のログイン・画像・検索導線まで確認できます。
- 難易度
- 初級
- 想定読者
- Web担当者・情シス・開発者・初心者
- 所要時間
- 約12分
- 最終確認
- 2026-11-02
- 1｜対象URLを整理
通常ページ、ログイン、資源、API、サブドメインと所有者を確認する。
- 2｜通信と機能を確認
証明書・転送・混在コンテンツ・各区間と主要業務を検証する。
- 3｜検索と継続運用
正規URL・sitemap・HSTSの範囲を確認し、監視と担当を残す。
HTTP（http://）とは
HTTPはWebの要求・応答の仕組みです。この比較のHTTP側はhttp:// URLを指し、TLSによる暗号化・接続先の認証を要求しません。既定ポートは80です。
HTTPS（https://）とは
HTTP通信をTLSで保護するURL方式。通常の利用では証明書の検証により接続先を認証し、通信の機密性・完全性を保護します。既定ポートは443ですが、サイトの内容の安全性は別に確認します。
違いの比較表
| 比較軸 | HTTP（http://） | HTTPS（https://） |
|---|---|---|
| 比較範囲 | http://で参照するWebの通信 | https://で参照する、TLSで保護されたHTTPの通信 |
| 通信保護 | URL方式としてTLSの保護を要求しない | 機密性・完全性と、接続先の認証を支える |
| 既定ポート | 80。構成により別の番号も使う | 443。番号だけで接続の安全性は判定しない |
| 入力・機能 | 認証情報や個人情報を送る経路にしない | フォーム・API・ログインと関連資源まで保護を確認する |
| 移行 | 旧URLを、対応する新しいHTTPS URLへ転送する | 新URL、証明書、内部リンク、混在コンテンツを確認する |
| 検索 | 旧URLから新URLへの対応を残す | canonical・sitemap等を整合させる。順位上昇の保証はない |
| 限界 | 安全な内容や正規の依頼であることを保証しない | HTTPSでも詐欺はあり得る。接続先と依頼を別に確認する |
移行条件を整理したら、利用者側の確認へ
既知のURLから、ホスト名・証明書・警告を確認する手順です。判断表で不足した条件を、次の記録へ引き継げます。
無料のHTTPSブラウザ確認手順を開く使い分け
- 閲覧者：既知の正規URLから開き、ホスト名と警告を確認する。HTTPSだけで送金やパスワード入力の依頼を正当と判断しない。
- Web運用者：ログイン画面だけでなく、通常ページ・画像・スクリプト・フォーム・APIを含めてHTTPS化の結果を確認する。
- 移行担当者：旧URLと新URLを対応付け、301／308等の転送、検索用URL、主要機能を確認してからHSTSの適用範囲を判断する。
HTTPSで何が安全になる？ポートと通信区間の限界
RFC 9110で扱うhttps方式は、HTTPの通信を保護し、対象のホストとして応答できる相手の認証を支えます。HTTPという仕組み自体が不要になるわけではなく、HTTPの版とhttp／httpsのURL方式も別の軸です。既定ポートは80と443で、別ポートの構成もあります。
HTTPSはサイトの販売内容や送金先を審査する仕組みではありません。閲覧者は既知のURLとホスト名を照合し、警告が出たら入力せず正規窓口へ確認します。警告の回避や、出所不明な証明書の導入は勧めません。
CDNやLBでTLSを終端する場合は、オリジン側の接続と証明書検証を別に確認します。CloudflareのFull (strict)等は機能例であり、ブラウザのHTTPS成功だけで全区間の検証が終わったとは判断しません。
常時HTTPS化の手順：301・308転送と混在コンテンツ
まず対象のページ、資源、ログイン、API、委託先とサブドメインを一覧化します。新しいHTTPS URLが有効な証明書で表示できることを確認し、旧URLから対応する新URLへ恒久転送を設定します。Googleは可能なら301／308等のサーバー側転送を推奨しています。
閲覧ページの転送と、フォーム・APIの送信は分けて試験します。301ではクライアントがPOSTをGETへ変えることがあり、308はメソッドを維持するため、送信の仕様・互換性を確認して選びます。秘密のデータをHTTPで送ってから転送する設計にはしません。
HTTPSページ内のHTTP資源は混在コンテンツです。ブラウザは種類によって自動更新や遮断を行うため、一部の画像が見えるだけで解決とは判断しません。スクリプト、CSS、画像、埋め込み、通信先をHTTPSへ整え、開発者ツールの警告と実際の機能を確認します。
HTTPS移行とSEO：canonical・sitemap・検索の確認
新URLのcanonical、内部リンク、sitemap、必要ならhreflangを同じ正規URLへ揃えます。検証用のnoindexやクロール制限を公開対象へ残さない一方、元から非公開にすべきページまで公開しません。
旧URLをすべてトップページへ転送せず、目的の内容へ対応付けます。転送ループ、長い転送経路、404、旧ホストへのリンク、フォームの送信先を確認します。移行時にデザインや内容まで一度に大きく変えると、原因の切り分けが難しくなります。
公開後はSearch Consoleとアクセス・エラーログで、意図する新URLの登録、旧新URLの流入、主要機能の失敗を確認します。HTTPS化だけで検索順位やアクセス増を保証せず、移行日・対象・変更点を残して前後を比較します。
HSTSの注意点と移行費用：サブドメインを先に確認
HSTSのmax-ageは、ブラウザがHTTPSのみを使う方針を覚える秒数です。includeSubDomainsは配下のサブドメインにも及びます。例として86400秒は1日ですが、本番の推奨期間を一律に示す値ではありません。全対象と復旧条件を確認して段階的に判断します。
ヘッダーを外すだけでは既に保持された方針が即座に消えません。max-age=0も安全な接続で受信される必要があり、preloadは別の仕組みで即時解除を前提にできません。HTTPS化が終わっていないサブドメインがあれば、includeSubDomainsやpreloadの一括導入を急ぎません。
見積項目は証明書、ホスティング・CDN、URL対応表、混在コンテンツ修正、フォーム・API試験、監視と更新担当です。「対象URL／転送先／機能結果／canonical・sitemap／HSTSの範囲と期間／残件・担当」を社内で記録し、下記の無料教材で利用者側の確認も行います。
よくある誤解
- 「HTTPSならフィッシングではない」ではありません。通信の保護と相手の依頼の正当性は別です。
- 「トップがHTTPSなら移行完了」ではありません。内部の画像・スクリプト・フォーム・APIや別ホストも確認します。
- 「301なら全アクセスをトップへ送ればよい」ではありません。対応する新URLへ転送し、利用者が目的の内容へ到達できるか確認します。
- 「HSTSヘッダーを消せば即座にHTTPへ戻せる」ではありません。保持済みの方針やpreloadの反映を考慮します。
よくある質問
HTTPSなら安全なサイトだと判断できますか？
判断できません。HTTPSは通信の保護と接続先の認証を支えますが、サイトの内容や依頼の正当性は保証しません。既知のURL、ホスト名、依頼を別に確認します。
HTTPSにしたのに画像やログインが動かない時は？
証明書だけでなく、HTTPの資源による混在コンテンツ、転送ループ、フォーム・APIの送信先、CDNからオリジンの接続を確認します。警告回避やHTTPへの安易な復帰で解決しません。
HSTSはHTTPS化と同時に全サブドメインへ設定すべきですか？
一律には設定しません。includeSubDomainsの対象すべてがHTTPSへ対応し、期限・監視・復旧を確認できるかを先に調べます。ブラウザの保持やpreloadの反映を考慮し、即時解除を前提にしません。
編集・確認情報
CyberLens編集部がRFC 9110、Google Search Central、MDNの混在コンテンツ・HSTS、Cloudflareのオリジン検証資料を照合し、移行前後の判断と確認項目を改訂しました。個別サイトの移行実験、検索順位の計測、専門家監修は実施していません。 最終確認日は 2026-11-02 です。
参考資料は用語・設計・機能例の確認先です。製品ごとの範囲は異なり、特定製品の推奨や比較全体の公式認定ではありません。資料の公開時点と現行の公式案内も合わせて確認してください。
新しい解説を見逃さない
CVE・KEVの初動対応や実務チェックリストは随時追加しています。使いやすい方法で更新を受け取れます。