常時SSL化の費用とは｜B2Bサイトに不可欠な対策【2026年版】

「常時SSL化って、結局いくらかかるの」。見積もりを見ても、無料と書いてあったり数万円と書いてあったりで、何が正解なのか分かりにくいですよね。

この記事では、常時SSL化にかかる費用の正しい考え方と、自社サイトに合った証明書の選び方、移行の手順、つまずきやすいポイントまでを現場目線でまとめました。読み終わるころには「うちの場合はこれでいい」と判断できる状態を目指します。

Contents / 目次

1. 常時SSL化の費用は「証明書代＋作業＋更新」の3点で考える
2. 常時SSL化のやり方。移行を失敗させない6つの手順
3. 常時SSL化で得られる効果。B2Bでは「信頼の前提条件」になっている
4. 常時SSL化でよくある失敗と回避法
5. 見落としがちな落とし穴と、内製と外注の線引き
6. よくある質問

常時SSL化の費用は「証明書代＋作業＋更新」の3点で考える

結論からお伝えします。常時SSL化の費用は「証明書そのものの料金」だけで判断してはいけません。証明書代・初期の移行作業・継続的な更新管理の3つを合計したコストで考えるのが正解です。

常時SSL化とは、サイト全体の通信を暗号化し、すべてのページをhttpsで表示する状態にすることです。かんたんに言うと、サイトに入る入口から出口まで、まるごと鍵をかける対策です。

「証明書は無料」と聞いて安心してしまう方が多いのですが、無料なのは証明書の発行料金だけです。実際には、サイト内のURL書き換えやリダイレクト設定、移行後の確認といった作業の手間がかかります。ここを見落とすと「無料のはずが、結局けっこう手間がかかった」となりがちです。

まず、自社がどのタイプの証明書を選ぶべきかを整理しましょう。証明書は大きく3種類あります。

種類	証明する範囲	費用の傾向	向いているサイト
ドメイン認証型（DV）	ドメインの保有のみ	無料で使えるものが多い	一般的なコーポレートサイト・ブログ
企業認証型（OV）	ドメイン＋会社の実在	DVより高め	取引先に信頼性を示したいB2Bサイト
EV認証型（EV）	会社の実在を厳格に審査	審査が厳格な分もっとも高め	金融・大手・厳格な審査が要る業種

費用は時期や認証局によって大きく変わります。正確な料金は各認証局の公式ページで確認してください。

多くのB2Bサイトは無料のDVで十分です。会社の登記情報まで証明する必要がある一部の業種を除けば、レンタルサーバー付属の無料SSLでセキュリティ面の要件は満たせます。「B2Bだから高い証明書が必要」とは限りません。

暗号化の強度は、無料のDVも有料のOV・EVも基本的に同じです。違うのは「誰が運営しているサイトかをどこまで証明するか」という点だけです。常時SSL化の基本的な考え方は、ドメイン登録を管理するJPRS（日本レジストリサービス）の常時SSL化についての解説でも整理されています。

常時SSL化のやり方。移行を失敗させない6つの手順

常時SSL化の進め方は、次の6ステップで整理できます。順番を守ることが、SEO評価を落とさず安全に移行するコツです。

STEP1〜2 証明書を準備してサーバーに設定する

まず証明書を用意します。多くのレンタルサーバーは管理画面から無料SSL（Let’s Encryptなど）をボタン操作で有効化できます。有料のOV・EVを使う場合は、認証局に申し込み、CSR（証明書署名要求。つまりサーバー側で作る申請用の鍵情報）を作成して審査を受けます。

ボタンの名称や設定画面はサーバーごとに違います。具体的な操作は、契約中サーバーの公式マニュアルで確認してください。

STEP3 サイト内部のURLをhttpsに書き換える

ここが移行作業の山場です。ページ内の画像・CSS・JavaScript・内部リンクのURLが「http://」のまま残っていると、混在コンテンツ（Mixed Content）という状態になり、鍵マークが表示されません。

WordPressの場合は、サイトアドレスの設定をhttpsに変更したうえで、本文中に直書きされたhttpのURLをすべて置き換えます。データベース内のURLを一括置換する作業が必要になることが多いです。

STEP4 httpからhttpsへ301リダイレクトを設定する

httpでアクセスしてきた人を、自動でhttpsへ転送する設定です。301リダイレクト（恒久的な転送）を使うことで、これまで積み上げたSEO評価を新しいURLへ引き継げます。Apacheサーバーなら、.htaccessファイルに次のように記述します。

# .htaccess の先頭付近に記述（Apache環境向け）
# ※既にRewriteEngine Onがある場合は重複して書かないこと
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

このコードは「httpsでないアクセスを、同じURLのhttpsへ転送する」という意味です。サーバーがNginxの場合は設定ファイルが異なるため、この記述は使えません。環境に合わせて確認してください。

STEP5〜6 解析ツールを再設定して動作を確認する

Google Search Consoleを使っている場合は、httpsのURLを改めてプロパティとして登録しておきましょう。Google Analyticsや外部の連携ツールに登録したURLも、httpsへ変更が必要です。

最後に、移行前のチェックリストで確認します。

• 鍵マーク：トップページと主要な下層ページで鍵マークが出るか
• リダイレクト：古いhttpのURLにアクセスして正しくhttpsへ飛ぶか
• 混在コンテンツ：画像やCSSにhttpのまま残っているものがないか
• フォーム：問い合わせフォームが送信エラーにならないか
• 解析タグ：アクセス解析が正しく計測を再開しているか

混在コンテンツの洗い出しは、手作業だと見落としが出ます。ここはAIを使うと楽になります。

ブラウザの開発者ツールで出る警告メッセージをコピーし、Claudeのデスクトップアプリ（Mac/Windows）などに貼り付けて「このページに残っているhttpのリソースを一覧にして、修正すべき箇所を教えて」と頼むと、整理してくれます。ブラウザでも使えますが、ファイルを扱いながら日常的に使うならデスクトップアプリが便利です。

AIは候補の抽出が得意な一方、本当に直すべきかの最終判断は人が行う、という役割分担で進めるのが安全です。

常時SSL化で得られる効果。B2Bでは「信頼の前提条件」になっている

常時SSL化の最大の効果は、取引先からの信頼を損なわないことです。B2Bサイトでは、常時SSL化は「やっておくと有利」というより「やっていないと不利」に近い、最低限の対策だと私たちは考えています。

Google Chromeをはじめとするブラウザは、httpのままのサイトに「保護されていない通信」「安全ではありません」という警告を表示します。 商談前にサイトを確認した担当者がこの警告を見ると、「セキュリティ意識が低い会社かもしれない」という印象を持たれかねません。これはB2Bでは致命的です。

取り組んだ企業に共通するのは、次のような変化です。

• 信頼性の向上：ブラウザ警告がなくなり、鍵マークで安心感を与えられる
• 安全性の明示：通信が暗号化され、訪問者やブラウザに安全な通信であることを示せる
• 解析精度の向上：リファラー情報が正しく取得でき、流入元の分析が正確になる
• 表示速度の改善：HTTP/2など新しい通信規格が使え、ページ表示が速くなる余地が生まれる

セキュリティを重視する取引先のなかには、自社サイトのセキュリティ対応状況を確認するところもあります。常時SSL化していないことが、取引を見送られる一因になることも考えられます。

逆に言えば、まず無料SSLでも常時SSL化を済ませておくだけで、この「足切り」を避けられます。費用対効果という意味では、最初に手をつけるべき対策の一つです。

ドメインとSSLの期限管理を仕組み化する考え方は、ドメイン・SSL期限切れでサイト停止を防ぐ中小企業の更新管理でも詳しく解説しています。

常時SSL化でよくある失敗と回避法

常時SSL化は手順自体はシンプルですが、現場では決まったところでつまずきます。代表的な3つの失敗と防ぎ方を紹介します。

失敗1 混在コンテンツで鍵マークが出ない

サイトをhttpsにしたのに鍵マークが付かない、という相談がいちばん多いです。原因のほとんどが混在コンテンツです。本文に直書きされた画像URLや、外部から読み込むスクリプトがhttpのまま残っていると起きます。

防ぐには、移行後に主要ページをブラウザの開発者ツールで開き、警告に出るhttpのリソースを一つずつhttpsに直します。古いテンプレートやプラグインがhttpを出力していることもあるので、本文だけでなくテーマファイルも確認しましょう。

失敗2 リダイレクト設定のミスでSEO評価が下がる

301リダイレクトの設定を誤ると、検索評価が一時的に大きく落ちることがあります。よくあるのは、転送が無限に繰り返されるリダイレクトループや、下層ページのリダイレクト忘れ、canonicalタグ（正規URLを示すタグ）の修正漏れです。

この状況は、トップページだけ確認して「移行完了」と思い込むと起こります。回避するには、移行後に必ず複数の下層ページでhttpのURLにアクセスし、正しくhttpsへ転送されるかを一つずつ確かめます。canonicalタグもhttpsを指しているか合わせて確認してください。

失敗3 証明書の期限切れでサイトが止まる

意外と多いのが、証明書の更新漏れです。期限が切れると、訪問者の画面に「この接続ではプライバシーが保護されません」という警告が出て、実質的にサイトが見られない状態になります。商談中の取引先がこの画面を見たら、信頼は一気に揺らぎます。

手動更新だと更新漏れのリスクが高まるため、自動更新の仕組みづくりが欠かせません。

防ぐには、証明書の自動更新機能を有効にするのが基本です。Let’s Encryptに対応したレンタルサーバーは自動更新に対応していることが多いので、設定がオンになっているか確認しましょう。あわせて、有効期限をカレンダーに登録し、更新の前にアラートが届くようにしておくと安心です。

見落としがちな落とし穴と、内製と外注の線引き

ここからは、教科書的な解説では触れられにくい現場のリアルをお伝えします。常時SSL化は「やれば終わり」ではなく、運用が始まってからの落とし穴があるからです。

証明書の更新は自動化を前提にする

証明書には有効期限があり、定期的な更新が必要です。手動運用だと更新漏れが起きやすく、その間はサイトに警告が表示されて見られなくなるリスクがあります。更新の手間を考えると、最初から自動化を前提に運用設計しておくのが安全です。

証明書の有効期間や更新ルールは変わることがあるため、最新の情報は認証局の公式発表で確認してください。重要なのは「更新作業は定期的に発生する前提で、自動化の仕組みを先に用意しておく」という考え方です。証明書の選定や運用については、サイバートラストのiTrust SSL/TLSサーバー証明書の公式サイトのように、認証局の一次情報を見ておくと判断がぶれません。

サーバー移管時にSSLが一時的に外れることがある

意外と知られていない落とし穴が、サーバーの引っ越し時です。無料のドメイン認証型証明書は、移管の途中で一時的にSSLが外れ、エラー画面が表示されることがあります。リニューアルと同時にサーバーも移す場合は、エラー表示が出る時間帯を見込んでおくか、事前にサイト上で作業告知をしておくと、取引先の不安を避けられます。

内製と外注、どこで線を引くか

「自社でできるか、プロに任せるか」は費用に直結する判断です。率直な線引きをお伝えします。

• 自社でできる範囲：レンタルサーバーの無料SSLを有効化するだけの小規模サイト。ボタン操作とリダイレクト確認で完結する
• プロに任せた方が早い範囲：ページ数が多く混在コンテンツが大量にある、複数サイトをまとめて移行する、SEO評価を絶対に落としたくない、サーバー移管も同時に行う場合

外注費用を惜しんで自社で進めた結果、リダイレクトミスで検索評価が一時的に落ちることがあります。回復にかかる期間は状況によって大きく異なります。

証明書代を惜しんだ結果、順位低下による機会損失の方が大きくなることもあります。自社のリソースと、失敗したときの損失を天秤にかけて判断するのが現実的です。

WordPress全般のセキュリティ運用はWordPress乗っ取りを防ぐ更新と二段階認証の最低限設定もあわせて確認しておくと、SSLだけでなく守りの全体像が整います。

よくある質問

ここまで読んで、自社だけで移行を進めるのは不安だと感じた方もいるかもしれません。コレットラボでは、サイト制作・運用をAIで効率化しながら、移行作業や混在コンテンツの整理まで一緒に進める伴走支援を行っています。「まず現状を整理したい」という段階でも大丈夫です。AI業務システム化の詳細はこちらから、お気軽にご相談ください。