SSL化（常時SSL）とは？必要な理由・設定の流れ・確認方法

SSL化を「証明書を取得すれば終わる作業」と考えると、フォーム送信不能、計測漏れ、検索設定の不整合などを見落とすおそれがあります。実務では、公開ページからログイン、資料ダウンロード、外部連携までをHTTPSへ統一する移行として計画することが重要です。

この記事では、SSL化の意味、証明書の対象範囲、費用の目安と比較の条件、設定から完了確認までの流れを整理します。読後には、HTTPS移行の対象・担当・完了条件を判断できるようになります。

SSL化は証明書の設定だけで終わらせず、対象の棚卸し、移行、主要導線の確認、更新監視までを一連の運用として管理します。

01SectionSSL化（常時SSL）とは

SSL化は、現在では主にTLSを使ってWebサイトをHTTPSで提供することを指す実務用語です。SSLという呼び方は残っていますが、現行のWeb通信で中心となる技術はTLSです。

HTTPSは、サイトと利用者の間の通信を保護し、接続先の確認を支える仕組みです。問い合わせ内容やログイン情報などを扱うBtoBサイトでは、フォームだけをHTTPS化するのではなく、公開サイト全体を同じ方針で運用します。

HTTPSで保護できることと、別途必要な対策

TLSは、通信経路上の盗聴や改変への対策、接続先の確認の基盤になります。MDNのTLS解説でも、HTTPSでは有効なデジタル証明書によるサーバー認証が必要であることが説明されています。

一方、HTTPSはWebサイト全体の安全性を単独で保証するものではありません。たとえば、CMSやプラグインの脆弱性への対応、不正ログインを防ぐ認証・権限管理、障害や改ざんに備えるバックアップは、別途運用が必要です。SSL化はこれらに代わる施策ではなく、通信を安全に提供するための土台と捉えるとよいでしょう。

また、HTTPSページ内で画像、CSS、JavaScript、iframeなどをHTTPで読み込む状態は「混在コンテンツ」と呼ばれます。ブラウザはリソースの種類に応じて読み込みを更新またはブロックする場合があり、表示崩れや機能停止につながる可能性があります。

02SectionSSL化が必要な理由とSEOの位置付け

SSL化の優先度は、SEOだけで決めるものではありません。情報保護、利用者が安心して操作できること、外部連携を安定して運用できることをまとめて考える必要があります。

フォーム・ログインをHTTPで扱う実務上の課題

問い合わせ、資料請求、ログイン、会員ページなどは、入力情報や認証情報を扱います。こうした導線をHTTPのまま運用すると、通信保護の観点だけでなく、利用者が送信をためらう要因にもなり得ます。

Chromeでは、HTTPで読み込んだ主オリジンを開発者ツールのSecurityパネルで安全ではない接続として確認できます。Chrome DevToolsのSecurityパネルを使えば、証明書や接続状態を確認する際の補助になります。ただし、アドレスバーの文言やアイコンはブラウザとバージョンで異なるため、特定の表示をすべての利用環境に共通する仕様として扱うべきではありません。

特に優先して確認したいのは、次の導線です。

• 問い合わせ・資料請求フォームと完了ページ
• ログイン、パスワード再設定、会員向けページ
• 資料ダウンロードや申込フォーム
• メール、広告、外部サービスから流入する主要URL

HTTPS化だけで順位・流入・CVは保証されない

GoogleはHTTPSをランキングシグナルとして扱うことを公表してきましたが、検索順位は多数のシステムや要因によって決まります。HTTPS化だけで順位、流入、問い合わせ数の改善を約束することはできません。Google Searchのランキングシステム解説も踏まえ、HTTPS化は安全なサイト運用と検索移行の整合性を確保する施策として位置付けるのが適切です。

HTTPからHTTPSへの変更はURL移行として扱う

HTTPからHTTPSへの切り替えは、検索エンジンにとってURL変更を伴う移行です。Google Search Centralのサイト移転ガイドでは、事前テスト、URL対応、canonical、サイトマップ、移行後の監視が案内されています。

検索関連の仕様は更新され得るため、移行を進める際は公式資料の最新版を確認してください。

移行時は、少なくとも次をHTTPSに統一します。

• canonical：検索エンジンに正規URLを伝える設定
• XMLサイトマップ：検索エンジン向けのURL一覧
• サイト内リンク、ナビゲーション、メール内の主要リンク
• 解析・広告などの計測設定とタグ発火
• クロールとインデックス状況：URLを一覧化した確認と検索対象としての認識状況

HTTP URLからHTTPS URLへの恒久的な転送も確認対象です。実装方法は利用環境に依存するため、詳細は301リダイレクトの基礎と設定時の注意点を参照してください。

03Section証明書の対象名・認証要件・更新方法の選び方

証明書は、必要なホスト名をカバーできるかと、組織上必要な確認・更新運用を満たせるかを分けて検討します。

証明書を選ぶ前に、HTTPSで利用するホスト名を確定します。example.jpとwww.example.jpは別の名前として扱い、form.example.jpのようなサブドメインや、外部サービスで使う独自ドメインも漏れなく棚卸しします。

TLSでのDNS名照合は、証明書内のsubjectAltNameに含まれるDNS名を基準に行われます。RFC 9525を確認し、実際にアクセスされるホスト名と証明書の対象名が一致することを確認してください。

DV・OV・EVは、主に発行時に何を確認するかという区分です。DV・OV・EVを通信の暗号強度の序列として捉えないことが重要です。公開信頼TLS証明書の要件はCA/Browser ForumのBaseline Requirementsで確認できます。社内規程、取引先との取り決め、調達・監査要件がある場合は、証明書の発行前に照合しましょう。

04Section費用と期間は何で変わるか

SSL化の費用は、証明書の発行費だけで比較すると判断を誤りやすくなります。費用は大きく、証明書発行費、初期の設定・改修・テスト・公開支援費、継続の更新・監視・再テスト費の3つに分かれます。無償の証明書を利用できる場合でも、TLS設定、サイト改修、テスト、更新監視の作業が不要になるわけではありません。

このうち証明書発行費は、認証の区分ごとにおおむね次のレンジです（2026年8月13日時点の目安）。

• DV（ドメイン認証）：無料〜年額4万円程度（税抜）。Let's Encryptなどの無償の認証局や、レンタルサーバーの標準機能として無償提供される場合があります。
• OV（企業認証）：年額およそ3万〜10万円程度（税抜）。
• EV：年額およそ6万〜20万円程度（税抜）。

いずれも認証局・販売経路・契約年数・対象名のカバー方式（SAN・ワイルドカードなど）によって変わる、証明書単体の発行費の目安です。設定・改修・テストの費用は含みません。金額は変わり得るため、契約前に各認証局・販売代理店の現行価格と、見積もりに含まれる作業範囲を確認してください。

期間についても、一般的な標準納期としての数値を置くことはできません。サイト構成や権限、外部サービスとの調整で必要な作業が変わるためです。公開予定日は、変更権限の確認、証明書の対象名と設定先の確定、必要な改修の完了、テストと切り戻し準備、最終承認者の判断という完了条件を順に満たせるかで決めます。費用は総額だけで比較せず、初期費用と継続費用を分け、対象ホスト名、構成、改修・テスト・保守範囲をそろえて比較します。

05SectionSSL化の設定から公開までの流れ

HTTPS移行は、対象と権限を固めてから設定・改修・テストへ進み、公開後の更新監視までを完了範囲に含めます。

実施手順はサーバー、CDN、CMS、契約条件によって異なります。ただし、移行を安全に進めるための確認順序は共通します。証明書の棚卸し、所有者の割り当て、設置、監視までを管理対象とする考え方は、NIST SP 1800-16も参考になります。

HTTPからHTTPSへの転送は、旧URLと新URLの対応関係を確認して進めます。設定方法は環境ごとに異なるため、実装の詳細は301リダイレクトの基礎と設定時の注意点を参照してください。

自社で進めるか、外部へ依頼するか

自社で進められるかどうかは、担当者の技術知識だけでは決まりません。DNS・サーバー・CMSなどの変更権限が明確か、TLS終端を把握できているか、主要導線の改修とテストを担えるか、切り戻しと公開判断の体制があるか、の4点で判断します。いずれかが欠ける場合は、その部分を制作・開発担当やサーバー会社へ依頼し、対象ホスト名、TLS終端地点、改修対象、テスト項目、更新監視、緊急時の連絡先と切り戻し権限を文書で共有してください。保守契約で確認すべき役割分担は、Webサイト保守の内容と依頼先の選び方も参考になります。

06Section混在コンテンツを防ぎ、SSL化を確認する方法

混在コンテンツとは、HTTPSで開いたページがHTTP経由のリソースを読み込む状態です。画像だけでなく、CSS、JavaScript、フォント、iframe、フォーム送信先、計測タグなどにも起こり得ます。MDNのMixed content解説を参考に、HTTP固定の参照を公開前に洗い出してください。

証明書警告が出る場合は、アクセス先のホスト名と証明書対象名が一致しているか、有効期限が切れていないか、想定したTLS終端地点で設定されているかを優先して確認します。表示上の警告だけでなく、フォーム、ログイン、資料ダウンロード、計測、外部連携までを同時に確認することが必要です。

公開前・公開直後・公開後監視に分けて確認する

確認は一度の表示確認で終えず、公開前の準備、公開直後の主要導線テスト、公開後の検索設定と更新監視に分けて実施します。

確認は3段階に分けます。公開前は、CMSの公開ページ一覧、XMLサイトマップ、主要流入URL、CV導線、サブドメイン一覧を突き合わせて確認対象URLを確定し、証明書対象名、TLS終端地点、HTTP固定リソース、切り戻し条件を確認します。公開直後は、全ページのHTTPS表示と警告の有無、HTTP URLからの転送、フォーム・ログイン・ダウンロード・タグ発火・外部連携をテストします。公開後は、canonical・XMLサイトマップ・Search Consoleの状況、計測推移、証明書の自動更新と失敗通知を継続して監視します。

Search ConsoleのHTTPSレポートは有用ですが、全URLを網羅する一覧の代わりにはなりません。Search ConsoleのHTTPSレポートと自社のURL一覧を併用してください。XMLサイトマップにはHTTPSの完全なURLを記載し、検索結果に表示したい正規URLを含めます。詳細はGoogle Search Centralのサイトマップ作成ガイドで確認できます。

SSL化の完了は、証明書を設定した時点ではなく、主要導線と計測を含めてHTTPSで安定運用できる状態で判断します。公開後も更新失敗や外部連携の変更で不備が生じる可能性があるため、定期確認の担当を残しておくことが重要です。