はじめに
「アドレスバーに“保護なし”って出てるけど大丈夫？」「このまま問い合わせフォームを使っていいのかな？」と、不安になりますよね。
まず最初に確認してほしいのは、SSL証明書がきちんと入っているか、そして有効期限が切れていないかどうかです。サーバー管理画面や証明書の情報を開いて、発行元と有効期限をチェックしてみてください。ここで期限切れや未設定が見つかれば、それが原因です。
それでも「保護なし」が消えない場合は、ページの中に“http”のまま読み込まれている画像やスクリプトがないかを確認します。たとえば、昔アップした画像のURLが「http://〜」のままになっていると、サイト全体はhttpsでも警告が出ることがあります。
そして大切なのは、「保護なし」と表示されたまま問い合わせフォームやログイン画面を使い続けないことです。個人情報を入力するページで警告が出ている状態は避けましょう。原因が分かるまで、一時的に公開を止めることも選択肢に入れてください。
見るポイントは3つだけです。
この順番でひとつずつ確認していけば、「どこを直せばいいのか」が自然と見えてきます。焦らなくて大丈夫です。順番に見ていきましょう。
アドレスバーの警告表示を確認する
サイトが「安全ではありません」と表示されたとき、まず確認すべきなのがアドレスバーの表示です。URLが「http」のままになっていないか、鍵マークが表示されているか、証明書エラーが出ていないかで原因はほぼ絞れます。さらに、同じページでもChromeとFirefoxで警告内容が異なることがあるため、表示の違いも確認します。まずはブラウザ上の表示情報から切り分けていきます。
通信方式がHTTPのままになってない？
ブラウザのアドレスバーに「http://」と表示されていないか確認します。正しく設定されている場合は「https://」で始まり、鍵マークが表示されます。もし「保護されていない通信」「安全ではありません」と表示されている場合、そのページは暗号化されていません。
ログイン画面や問い合わせフォームがあるページでHTTPのままだと、入力した名前やメールアドレス、パスワードが暗号化されずに送信されます。まずはアドレスバーをクリックしてURLを確認し、「https://」になっているかを見ます。HTTPのままなら、サーバーにSSL証明書が設定されているか、WordPressなどの管理画面でサイトURLがhttpsに変更されているかを確認します。
SSL証明書の状態は？
アドレスバーの左側に表示される鍵マークをクリックし、証明書の情報を開いて確認します。正常な場合は「この接続は保護されています」と表示され、発行先のドメイン名と有効期限が確認できます。有効期限が切れていると「証明書の有効期限が無効です」といった警告が出ます。
また、証明書の発行先が現在表示しているドメインと一致しているかも確認します。たとえば「example.com」の証明書なのに「www.example.com」で警告が出る場合、証明書が対応していない可能性があります。警告画面に「NET::ERR_CERT_DATE_INVALID」や「証明書が信頼されていません」と表示されている場合は、期限切れや設定ミスが原因です。まずは有効期限と発行先ドメインを具体的に確認します。
ChromeとFirefoxで表示内容が違わない？
同じURLをGoogle ChromeとMozilla Firefoxの両方で開いて、アドレスバーの表示を見比べます。Chromeでは「保護されていない通信」や「この接続ではプライバシーが保護されません（NET::ERR_CERT_〜）」と表示されることがあります。一方、Firefoxでは「安全な接続ではありません」「SEC_ERROR_〜」といった別の文言で警告が出ます。
Chromeでは鍵マークの有無や「保護されていない通信」という文字表示を確認します。Firefoxではアドレスバー左側の鍵アイコンに赤い斜線が入っていないかを見ます。どちらか一方だけで警告が出る場合、ブラウザのキャッシュや証明書ストアの違いが原因のことがあります。両方で表示内容を具体的に確認し、警告文に書かれているエラーコードまで確認します。
同じURLでもブラウザによって警告文が変わる
同じURLをGoogle ChromeとMozilla Firefoxで開くと、表示される警告文が変わることがあります。たとえば、SSL証明書の有効期限が切れている場合、Chromeでは「この接続ではプライバシーが保護されません」と表示され、画面下に「NET::ERR_CERT_DATE_INVALID」と出ます。Firefoxでは「安全な接続ではありません」と表示され、「SEC_ERROR_EXPIRED_CERTIFICATE」というエラーコードが出ます。
また、自己署名証明書を使っている場合、Chromeでは赤い警告画面が表示されますが、Firefoxでは「詳細へ進む」というボタンが表示されるなど、画面構成も違います。見た目や文言が違っても、原因が同じ証明書エラーということがあります。必ず両方のブラウザで実際に開き、表示されている具体的な警告文とエラーコードを確認します。
SSL証明書が正しく設定されているか確認する
アドレスバーで警告が出ている場合、次に確認するのはSSL証明書そのものの状態です。証明書がそもそも発行されているのか、有効期限が切れていないか、そして現在アクセスしているドメイン名と一致しているかによって、原因ははっきり分かれます。設定ミスなのか期限切れなのかを切り分けるために、証明書の基本項目を順番に確認します。
ドメインにSSL証明書が発行されているか確認する
まず、対象のドメインをブラウザで「https://ドメイン名」で直接開きます。アドレスバーの左側に鍵マークが表示されるかを確認します。鍵マークが表示されない場合や「保護されていない通信」と出る場合、そのドメインにはSSL証明書が発行されていないか、正しく適用されていません。
次に、鍵マークをクリックして証明書情報を開きます。そこに表示される「発行先（Common Name）」が、確認しているドメイン名と一致しているかを見ます。たとえば「example.com」を確認しているのに、証明書の発行先が別のドメイン名になっていれば、そのドメイン用の証明書は発行されていません。
サーバーの管理画面でも確認します。レンタルサーバーを使っている場合は、コントロールパネルの「SSL設定」や「独自SSL」メニューを開き、対象ドメインのステータスが「有効」や「発行済み」になっているかを見ます。「未設定」「失敗」「申請中」のままになっている場合は、証明書がまだ発行・反映されていません。
証明書の有効期限が切れていないか確認する
ブラウザで対象のページを「https://」から始まるURLで開き、アドレスバーの鍵マークをクリックします。表示される「接続は保護されています」などの表示から「証明書」または「証明書は有効です」を開き、有効期限（有効期間）の終了日を確認します。
終了日が今日より前の日付になっていれば、その証明書は失効しています。期限切れの場合、画面に「この接続ではプライバシーが保護されません」や「証明書の有効期限が無効です（NET::ERR_CERT_DATE_INVALID）」と表示されます。
レンタルサーバーを利用している場合は、サーバー管理画面の「SSL設定」や「証明書一覧」を開き、対象ドメインの有効期限を確認します。Let’s Encryptを利用している場合は通常90日ごとの更新が必要です。自動更新が失敗していないかも、管理画面のステータスで確認します。
証明書が現在のドメイン名と一致しているか確認する
ブラウザで対象のページを「https://」から始まるURLで開き、アドレスバーの鍵マークをクリックします。表示された画面から「証明書」や「証明書は有効です」を開き、「発行先（Common Name）」または「SAN（Subject Alternative Name）」に記載されているドメイン名を確認します。
たとえば、表示しているURLが「https://example.com」なのに、証明書の発行先が「www.example.com」のみになっている場合、ドメインが一致していません。この場合、「NET::ERR_CERT_COMMON_NAME_INVALID」といったエラーが表示されます。
「example.com」と「www.example.com」は別ドメインとして扱われるため、両方に対応した証明書が必要です。確認しているURLと、証明書に記載されているドメイン名が完全に一致しているかを、文字単位で確認します。
HTTPSなのに警告が出る場合は？
URLが「https」になっているのに警告が消えない場合は、単純な未設定ではなく“中身”に原因が残っている可能性があります。見た目は安全な通信でも、ページ内の一部ファイルがHTTPで読み込まれていたり、証明書の設定が不完全だったり、ブラウザが古い情報を表示していることがあります。表面の表示だけで判断せず、内部の読み込み状況まで確認します。
ページ内にHTTPで読み込まれているファイルがある
ページのURLが「https://」で始まっていても、画像やCSS、JavaScriptなどのファイルを「http://」で読み込んでいると警告が出ます。これを「混在コンテンツ（Mixed Content）」といいます。
確認方法は、対象ページを開いてキーボードの「F12」を押し、開発者ツールを表示します。「Console」タブをクリックすると、「Mixed Content: The page at ‘https://〜’ was loaded over HTTPS, but requested an insecure resource ‘http://〜’」というエラーが表示されます。そこに具体的なHTTPのURLが表示されます。
たとえば、画像タグが <img src="http://example.com/image.jpg"> になっている場合、その画像だけが暗号化されずに読み込まれています。WordPressを使っている場合は、記事内の画像URLやテーマ設定内のスクリプトURLが「http://」のままになっていないかを確認します。すべての読み込みURLを「https://」に修正すれば、警告は消えます。
SSL証明書はあるが設定が完全ではない
SSL証明書が発行されていても、サーバー側の設定が不完全だと警告が表示されます。たとえば、証明書ファイルだけを設定し、中間証明書（CA証明書）を設定していない場合、「この接続は完全に保護されていません」と表示されます。
また、「https://example.com」には証明書が設定されていても、「https://www.example.com」には設定されていない場合、片方でアクセスすると警告が出ます。実際に「wwwあり」「wwwなし」の両方をブラウザで開いて確認します。
サーバー設定でHTTPからHTTPSへのリダイレクトが正しく設定されていない場合も問題になります。アドレスバーに「http://ドメイン」を直接入力し、自動的に「https://」へ転送されるかを確認します。転送されない場合は、.htaccessやサーバーの常時SSL化設定が未完了です。
証明書があるだけでは不十分です。中間証明書の設定、対象ドメインの網羅、常時HTTPSリダイレクトの3点を具体的に確認します。
ブラウザが古いキャッシュを参照している
SSL証明書を正しく設定しても、ブラウザが以前のHTTPページや古い証明書情報をキャッシュとして保存していると、警告が消えないことがあります。
まず、対象ページを開いた状態で「Ctrl＋F5」を押して強制再読み込みを行います。これでキャッシュを使わずに最新の情報を読み込みます。それでも警告が出る場合は、ブラウザの設定から「閲覧履歴データの削除」を開き、「キャッシュされた画像とファイル」を選択して削除します。
さらに、シークレットウィンドウ（プライベートブラウジング）で同じURLを開いて確認します。シークレットウィンドウでは既存のキャッシュを使わないため、ここで警告が出なければ原因はキャッシュです。
設定を修正した直後は、必ず強制再読み込みとキャッシュ削除を行い、古い情報を参照していないかを確認します。
HTTPSに統一するための設定を行う
警告の原因を特定できたら、次はサイト全体をHTTPSに統一します。一部だけではなく、すべてのページが常に「https」で表示される状態にし、httpでアクセスされた場合も自動でhttpsへ転送されるように設定します。さらに、内部リンクが混在しないよう出力URLも統一します。表示の揺れをなくすことが最終段階です。
すべてのページがhttpsで表示される状態にする
まず、ブラウザのアドレスバーに「http://ドメイン名」を直接入力し、自動的に「https://ドメイン名」へ転送されるか確認します。転送されない場合は、サーバー側で常時SSL化の設定ができていません。
レンタルサーバーを使っている場合は、管理画面の「常時SSL化」や「HTTP→HTTPSリダイレクト」設定を有効にします。自分で設定する場合は、.htaccessにHTTPSへ転送する記述を追加します。設定後は、トップページだけでなく、下層ページ（例：https://ドメイン名/about など）も含めてすべてhttpsで表示されるか確認します。
さらに、WordPressを使用している場合は、「設定」→「一般」から「WordPressアドレス（URL）」と「サイトアドレス（URL）」が両方とも「https://」になっているかを確認します。どちらかが「http://」のままだと、一部ページがHTTPで表示されます。
トップページだけでなく、記事ページ、固定ページ、画像URLまで含めてすべてhttpsで始まっている状態にします。
httpでアクセスしても自動でhttpsへ転送される状態にする
ブラウザのアドレスバーに「http://ドメイン名」を入力したとき、自動的に「https://ドメイン名」に切り替わる状態にします。切り替わらずにHTTPのまま表示される場合は、リダイレクト設定がされていません。
レンタルサーバーを利用している場合は、管理画面の「常時SSL化」や「HTTPS転送設定」を有効にします。自分で設定する場合は、サーバーの .htaccess にHTTPからHTTPSへ転送する設定を追加します。設定後は、「http://example.com」「http://www.example.com」など複数パターンでアクセスし、すべてhttpsに転送されるか確認します。
トップページだけでなく、下層ページ（例：http://ドメイン名/sample-page）も直接入力して確認します。どのURLでアクセスしても最終的に「https://」から始まるURLに変わる状態にします。
サイト内部リンクがすべてhttpsで出力される状態にする
まず、ページを表示した状態で、本文内のリンクにマウスを合わせ、ブラウザ左下に表示されるURLを確認します。そこに「http://」が含まれていないかを見ます。内部リンクが「http://ドメイン名/〜」になっている場合、そのリンクをクリックするとHTTPでアクセスされます。
WordPressを使用している場合は、「設定」→「一般」で「WordPressアドレス」と「サイトアドレス」がどちらも「https://」になっているかを確認します。そのうえで、データベース内に残っている「http://ドメイン名」を「https://ドメイン名」に置換します。置換後は、記事ページや固定ページを実際に開き、リンク先がすべてhttpsで始まっているか確認します。
画像URLやメニューリンク、フッター内リンクも含めて確認します。サイト内のリンクを1つでもhttpのまま残すと、混在コンテンツの警告が出る原因になります。内部リンクがすべて「https://」で出力される状態にします。
警告が出ている状態で公開を続けていい？
「とりあえず表示できているから大丈夫」と考えて公開を続けるのは危険です。警告が出ている状態は、利用者に不安を与えるだけでなく、入力情報の安全性にも影響します。特に個人情報や決済情報を扱うページは判断を先延ばしにできません。サイトの内容に応じて、公開を続けるか一時停止するかをすぐに決めます。
フォームやログイン画面があるなら公開を続けない
問い合わせフォームやログイン画面がある場合は、警告が出ている状態で公開を続けません。名前、メールアドレス、電話番号、パスワードなどを入力するページで「保護されていない通信」と表示されていると、入力内容が暗号化されずに送信される可能性があります。
実際にフォームページを開き、アドレスバーに鍵マークが表示されているか確認します。警告が出ている場合は、フォーム送信先のURLが「http://」になっていないか、SSL証明書が有効かを確認します。ログイン画面も同様に確認します。
個人情報を扱うページで警告が出ている状態は、そのまま公開しません。SSL設定とhttps統一を完了させ、警告が完全に消えてから公開を続けます。
商品購入や決済ページがあるなら公開を止める
商品購入ページや決済ページがある場合は、警告が出ている状態で公開を続けません。クレジットカード番号、有効期限、セキュリティコード、住所、電話番号などを入力するページで「保護されていない通信」や赤い警告画面が表示されていると、利用者は入力をためらいます。
実際に購入ページを開き、アドレスバーに鍵マークが表示されているかを確認します。表示されていない場合は、決済ページのURLが「https://」で始まっているか、証明書が有効かを確認します。外部決済サービスを利用している場合も、遷移先URLがhttpsで始まっているかを必ず確認します。
決済情報を扱うページで警告が出ている状態は、売上以前に信用問題になります。SSL設定とHTTPS統一が完了し、警告が完全に消えてから公開を再開します。
情報閲覧だけのページでも長期間は放置しない
会社案内やブログ記事など、読むだけのページであっても、警告が出ている状態を長期間放置しません。アドレスバーに「保護されていない通信」と表示されていると、閲覧者はそのサイト自体を危険だと判断します。
実際にトップページや記事ページを開き、鍵マークが表示されているかを確認します。表示されていない場合、検索結果からアクセスした利用者にも同じ警告が表示されています。その結果、ページを開いてすぐに閉じられる可能性が高くなります。
フォームや決済がなくても、サイト全体の信頼性に直結します。閲覧専用ページであっても、SSL設定とHTTPS統一を行い、警告が出ない状態にします。
まとめ
アドレスバーに「保護されていない通信」や鍵マークなしの表示が出たら、感覚で判断しません。必ず順番で確認します。
最初に見るのはSSL証明書の状態です。証明書が発行されているか、有効期限が切れていないか、現在のドメイン名と一致しているかを具体的に確認します。ここで問題があれば、まず証明書の再発行や設定修正を行います。
次に確認するのは混在コンテンツです。ページ自体はhttpsでも、画像・CSS・JavaScriptがhttpで読み込まれていないかを開発者ツールで確認します。Consoleに表示されるエラーURLを特定し、すべてhttpsへ修正します。
その後、HTTPからHTTPSへの自動転送が正しく設定されているかを確認します。httpで直接アクセスしても必ずhttpsに切り替わるか、下層ページも含めてチェックします。さらに、内部リンクや画像URLがすべてhttpsで出力されている状態にします。
フォーム、ログイン画面、決済ページがある場合は、警告が出ている状態で公開を続けません。個人情報やカード情報を扱うページは、鍵マークが表示される状態になってから公開します。
判断基準は一つです。「httpsで暗号化され、証明書が正しく適用され、警告が出ていない状態かどうか」。この基準に沿って、証明書→混在コンテンツ→https統一の順で確認すれば、修正箇所で迷いません。
