保護されていない通信と表示される原因と直し方【2026】

自社サイトを開いたら、アドレスバーに「保護されていない通信」と出ていた。あるいは全面が警告画面になって、そもそもサイトが開かない。多くの経営者の方が、まずここで「うちのサイトは乗っ取られたのか」「何か情報が漏れたのか」と不安になります。

結論から言うと、この表示のほとんどは攻撃を受けた結果ではなく、設定や証明書の状態を示しているだけです。ただし放置してよいという意味ではありません。原因は大きく4つに分かれ、それぞれ直す人も時間も費用も違います。この記事では、その4つをどう見分けるか、5分でできる確認手順、そして誰に何を頼めばよいかを整理します。

結論：「保護されていない通信」は4つの状態のどれか

Chrome がアドレスバーに出す表示は、大きく「情報アイコン／保護されていない通信」と「全面の赤い警告画面」の2種類です。Google のヘルプでは、前者は「サイトがプライベートな接続を使用していません。このサイトで送受信する情報を第三者が閲覧、変更できる可能性があります」という状態、後者はサイト・ネットワーク・端末のいずれかに問題がある状態と説明されています（Google Chrome ヘルプ）。

この2種類を、実務でよく遭遇する形にほどくと次の4つになります。まずは自社がどれに当たるかを見当づけてください。

①と④は比較的すぐ直ります。②はサーバー会社側の作業になることが多く、③は制作会社の作業です。次章の5分チェックで、自社がどこに当たるかをはっきりさせましょう。

まず5分で確認する手順

専門知識がなくても、ここまでは経営者ご自身で確認できます。この4ステップの結果をメモしておくと、そのまま制作会社への連絡文になります。

1. アドレスバーの表示を読む。ページが開いた上で「保護されていない通信」や情報アイコンが出ているのか、それとも全面の警告画面でページ自体が開かないのか。ここで①③④と②が分かれます。
2. URL の先頭を https:// にして手で開き直す。アドレスバーに https://自社ドメイン と打って開きます。これで鍵が付いて正常に見えるなら、サイト自体は HTTPS に対応しており、原因は④のリダイレクト漏れです。逆に警告や接続エラーになるなら①か②です。
3. 証明書の有効期限を見る。Chrome ならアドレスバー左のアイコンをクリックし、接続の詳細から証明書の情報を開くと、発行者と有効期間（notBefore／notAfter）が確認できます。今日の日付が有効期間を過ぎていれば②で確定です。
4. 別のブラウザ・別の端末・スマホ回線で再現するか見る。社内 PC 1台だけで起きるなら、サイト側ではなく端末の時計のずれ、社内ネットワークの機器、ウイルス対策ソフトの通信検査が原因のことがあります。全員・全端末で再現するならサイト側の問題です。

この4つを踏むだけで、切り分けの精度は大きく上がります。実務では、②だと思って慌てて連絡したら、実は担当者の PC の日付が1年ずれていただけ、というケースが一定数あります。手順4を飛ばさないでください。

「保護されていない通信」と全面警告の違い

この2つは、危険度も、直すまでの緊急度もまったく違います。混同したまま連絡すると、制作会社側の優先順位付けもずれます。

全面警告が出ている状態は、機会損失としては「サイトがダウンしている」のとほぼ同じです。問い合わせフォームも採用ページも、事実上そこで止まります。ドメインやサーバーの契約が切れて起きる停止と並んで、経営インパクトが最も大きい種類の障害です。似た症状で慌てるケースは ドメイン更新忘れでサイトが消えた｜復旧の期限と3つの原因 にもまとめています。

原因別の直し方

ここからは4つの状態ごとに、誰がやるか・どのくらいかかるか・費用の目安を添えて説明します。金額は Mihata が中小企業のサイトを扱ってきた範囲での一般的な目安で、サーバー環境や規模によって変わります。

① そもそも HTTPS に対応していない

URL が http:// のままで、https:// にすると開かない場合はこれです。証明書を一度も設定していない状態なので、まずサーバーに証明書を入れるところから始まります。現在の主要な国内レンタルサーバーは無料の SSL 証明書を標準機能として持っているので、管理画面で対象ドメインを選んで有効化するだけ、というケースがほとんどです。

ただし証明書を入れて終わりではありません。サイト内のリンクや画像のパスが http:// で書かれていると、次の③の混在コンテンツになります。HTTPS 化は「証明書を入れる」「サイト内の参照を https に直す」「http から https へ転送する」の3点セットで初めて完了します。ここを分けずに一気にやるのが確実です。

② 証明書の期限切れ・自動更新の失敗

今は Let's Encrypt をはじめ自動更新が前提の証明書が主流です。Let's Encrypt の標準的な証明書は有効期間90日で、60日ごとの更新が推奨されています（Let's Encrypt FAQ）。自動化されていれば人が触ることはありません。

問題は、自動更新にしていても失敗するときがあることです。実務でよく見るのは次のパターンです。

• DNS を別会社へ移した。証明書の更新時にドメイン所有の確認が通らなくなり、そこから静かに更新が止まる。
• サーバーを移転した。旧サーバーの自動更新は生きているが、実際に配信しているのは新サーバーで、そちらに証明書が入っていない。
• www あり／なしの片方だけ証明書に入っている。普段は気づかず、www 付きで入ってきた人だけが警告に当たる。
• 更新用のスクリプトが止まっていた。サーバーの再起動や PHP のバージョン変更をきっかけに、更新のバッチ処理だけが動かなくなっていた。

さらに注意したいのが、Let's Encrypt の有効期限お知らせメールは2025年6月4日に廃止されているという点です（Let's Encrypt 公式）。以前は「期限が近い」というメールが届いたので気づけましたが、今は自動更新が止まっても誰にも通知が来ません。気づくのは、お客様から「サイトが開かない」と電話が来たときです。監視の置き方は後半の運用の章で扱います。

③ 混在コンテンツ（mixed content）で鍵が外れる

URL は https:// なのに鍵が付かない、あるいは特定のページだけ警告が出る場合はこれです。HTTPS のページの中に http:// で読み込まれる画像・スクリプト・スタイルシートが混ざっている状態を指します。ブラウザ側は、画像・動画・音声は自動的に HTTPS へ引き上げ、スクリプトやスタイルシート、iframe、Web フォントなどはそのまま読み込まずにブロックします（MDN Web Docs）。

「地図が真っ白になった」「フォームのボタンが効かなくなった」「レイアウトが崩れた」という症状は、この自動ブロックが原因であることが多いです。見た目の不具合として相談されるので、セキュリティの話だと気づかれないまま放置されがちな領域でもあります。

見つけ方は決まっています。ブラウザの開発者ツールのコンソールに、どのリソースがブロック・引き上げされたかが警告として出ます。加えてソースコード内の http:// を検索し、img・script・link の参照先を確認します。サイト全体を横断して洗い出したい場合は、Content-Security-Policy の upgrade-insecure-requests を使って残りを拾う方法も公式に案内されています（web.dev）。

WordPress のサイトでは、記事本文に貼られた画像 URL が http:// のまま残っているのが最頻出です。過去記事が多いほど作業量が増えるので、依頼するときは記事数を伝えておくと見積もりが早くなります。

④ リダイレクト漏れ・canonical のずれ

https:// で手打ちすれば正常なのに、名刺やチラシの http:// から入ると警告が出る。これがリダイレクト漏れです。サーバー側で http へのアクセスを https へ 301 転送する設定を入れれば解決します。作業自体は短時間で終わることがほとんどです。

あわせて確認したいのが canonical タグとサイトマップです。Google の Search Console には HTTPS レポートがあり、HTTPS ページがインデックスされない理由として「SSL 証明書が無効」「HTTPS の URL が HTTP へリダイレクトしている」「HTTP ページの canonical が HTTP を指している」「サイトマップが HTTP の URL を指している」などが挙げられています（Search Console ヘルプ）。転送だけ直して canonical が http のまま残っていると、検索エンジンから見た正規 URL が http のままになります。

さらに堅くするなら HSTS（Strict-Transport-Security）という仕組みもありますが、一度有効にすると設定した期間はブラウザ側が HTTPS を強制するため、証明書のトラブル時に逃げ道がなくなります。導入するなら HTTPS が安定してからにしてください。転送設定を変えた後に検索から消えたように見える場合の切り分けは ホームページが検索に出ない｜公開後の原因切り分け6手順 が参考になります。

ここまで読んで「自社がどれに当たるか分かったが、頼む先がない」という状態でしたら、Mihata でも切り分けと修正をお受けしています。まず現状を見て、直すべき箇所と概算をお伝えするところからで問題ございません。

放置するとどうなるか

「今のところ売上に影響していないから」と後回しにされがちですが、ブラウザ側の基準が動いています。Google は2025年10月に、Chrome の「常に安全な接続を使用する」設定を既定で有効にする計画を公表しました。2026年4月の Chrome 147 で拡張保護モードの利用者に対して有効化し、2026年10月の Chrome 154 で全ユーザーに拡大するという段階的な予定です（Google 公式ブログ）。

この設定が有効になると、HTTPS でない公開サイトへ初めてアクセスするとき、ブラウザが事前に許可を求めるようになります。同じ発表では、実験段階で警告に遭遇する頻度は中央値で週1回未満とされており、裏を返せばHTTP のままのサイトは「めったに見かけない例外」として扱われるということです。取引先が自社サイトを開いたときに確認ダイアログが出る状態は、信用の面で軽くありません。

影響が出やすいのは次の3つです。いずれも数字として現れにくく、気づいたときには機会を失っています。

• フォームからの問い合わせ。入力欄に触れた瞬間の警告表示は、送信をやめる理由として十分です。
• 取引先・金融機関からの見え方。与信や取引開始の場面で、サイトを開いて警告が出るのは説明の手間になります。
• 検索まわり。Google は HTTPS を Search Console のページエクスペリエンスの確認項目に挙げており（Google 検索セントラル）、HTTPS レポートで問題として一覧されます。順位が急落するといった単純な話ではありませんが、直す理由としては十分です。

なお、この表示が出ているからといって「サイトが改ざんされている」わけではありません。改ざんや不正ログインへの備えは別の話で、ホームページのセキュリティ対策｜中小企業が最低限やる5つ にまとめています。混同すると必要のない対策にお金を使うことになるので、分けて考えてください。

再発させない運用

証明書のトラブルは、直した後にもう一度起きるのが厄介なところです。前述のとおり Let's Encrypt の期限通知メールは廃止されているので、「更新が止まったことに気づく仕組み」を自前で持たない限り、次も同じ形で止まります。実務では次の3点を置いておけば、ほぼ防げます。

• 期限の外部監視を1本置く。証明書の有効期限を外から見て、残り日数が減ったら通知する監視です。Let's Encrypt 自身も公式に第三者の監視サービスの利用を案内しています。サーバーの中で完結する仕組みだけに頼らないことが要点で、サーバーごと落ちたときに何も鳴らない状態を避けられます。
• DNS 移行・サーバー移転の直後に必ず1回確認する。更新が止まる引き金はほぼこの2つです。移行の完了チェックリストに「https で開く」「証明書の有効期限が更新されている」の2行を入れておくだけで、90日後の事故がなくなります。
• 年1回、ドメイン・サーバー・証明書の棚卸しをする。契約更新月、支払いカードの有効期限、管理会社の連絡先、管理画面のログイン情報をまとめて確認します。カードの期限切れで自動更新が失敗するのは、証明書に限らずよくある止まり方です。

もう一つ実務的な話をすると、証明書が切れているかどうかを社長ご自身が判断できる必要はありません。必要なのは「誰が見ている状態か」を決めておくことです。保守契約の中に入っているのか、サーバー会社の標準機能に任せているのか、誰も見ていないのか。この3つのどれなのかが答えられない状態が一番危険です。運用をどこまで自社で持つかの整理は ホームページ運用・更新代行｜自社と外注の分担と費用相場 でも触れています。

制作会社・サーバー会社への伝え方

最後に、実際に連絡するときの型です。ここが具体的だと初動が速くなり、往復も減ります。逆に「サイトに警告が出ています」の一文だけだと、まず状況を聞き返すところから始まるので半日〜1日ロスします。

1. 画面のスクリーンショット。アドレスバーごと入るように撮ってください。警告の文言とエラーコードが写っていれば、それだけで原因の見当がつきます。
2. 警告が出ている URL。トップページなのか特定の下層ページなのか。複数あるなら2〜3本挙げます。
3. ブラウザ名とバージョン、OS。Chrome か Safari か、PC かスマホか。特定環境だけの問題かの切り分けに直結します。
4. いつから起きているか。「今朝から」「先週サーバーを移してから」など。直前に何をしたかが最大のヒントです。
5. 5分チェックの結果。https:// を手打ちしたらどうなったか、別端末で再現するか。この2行があるだけで、相手はほぼ原因を絞れます。

連絡先が分からない、そもそも誰が管理しているのか不明という場合は、先に管理元を突き止める必要があります。調べ方は ホームページのドメインとサーバーの管理会社がわからない時の調べ方 にまとめました。証明書はサーバー会社、サイト内の記述は制作会社と、担当が分かれているケースが多いので、両方の連絡先を押さえておくと復旧が速くなります。

切り分けまではご自身でできますが、実際の修正は権限のある人でないと触れません。どこに何を頼めばいいか判断がつかない場合や、そもそも頼める相手がいない場合は、状況を伺ったうえで対応をご案内します。