![「保護されていない通信」が出る 4 パターン](/blog/chrome-not-secure-warning-fix/four-patterns.svg)

**結論（30 秒で）**: Chrome で「保護されていない」と出る原因は ① HTTP 配信 ② SSL 証明書期限切れ ③ 証明書のドメイン不一致 ④ mixed content の 4 つだけ。URL バー左の警告をクリックして詳細を読めば、どのパターンかは数秒で特定できます。あとは該当パターンの復旧手順（数分〜数時間）に進むだけです。

## この記事でわかること

- 「保護されていない通信」が表示される 4 つの原因パターン
- それぞれの直し方と所要時間
- 警告が出ている間に起きるビジネスインパクト
- 再発を防ぐためのチェック体制

## 「保護されていない通信」は何を意味するか

Chrome のアドレスバー左に「保護されていない通信」「Not secure」と表示されるのは、Web サイトが HTTPS ではなく HTTP で接続されている、あるいは SSL/TLS の検証に失敗していることを示します。

通信が暗号化されていないため、フォーム入力（名前・パスワード・問い合わせ内容）が経路上の第三者に盗み見られる可能性があります。鍵マークの仕組みは[ブラウザの鍵マークの仕組み](/blog/ssl-padlock-mechanism)で整理しています。

放置すると、検索結果での順位下落・お問い合わせ離脱・取引先からの信用低下に直結します。原因の切り分けと復旧を最優先で進めます。

## 原因を 4 つのパターンに分ける

警告が出る原因は次の 4 つに大別できます。どこに該当するかをまず特定します。

### パターン 1: そもそも HTTP でアクセスしている

URL が `http://` で始まっている、または HTTP で配信しているページに直接アクセスしている場合。本来 HTTPS で配信している側で、HTTP → HTTPS のリダイレクト設定が漏れていることが原因です。

### パターン 2: SSL 証明書の期限切れ

証明書の有効期限が切れた状態で配信し続けると、Chrome は警告を出します。これは別記事[SSL 期限切れ警告の直し方](/blog/ssl-expired-warning-fix)で詳しく扱っています。

### パターン 3: 証明書のドメインと URL の不一致

`example.com` 用の証明書で `www.example.com` を配信している、サブドメイン用の証明書がないなど、証明書がカバーしていないホスト名でアクセスされているケース。サブドメインの方式は[サブドメイン SSL は個別取得が必要？](/blog/ssl-subdomain-policy)を参照。

### パターン 4: mixed content（HTTPS ページに HTTP 資源）

ページ自体は HTTPS だが、内部で読み込んでいる画像・CSS・JavaScript が `http://` から始まる URL になっている状態。ブラウザは部分的に警告を出します。WordPress でよく起きる典型ケースは[WordPress SSL 化後の表示崩れ対処](/blog/wordpress-ssl-fix-mixed-content)を参照。

## 直し方の手順

![原因別の対処フロー](/blog/chrome-not-secure-warning-fix/fix-flow.svg)

### 手順 1: 警告の詳細を確認する

Chrome の URL バー左の「保護されていない通信」をクリックすると、警告の理由が表示されます。「証明書が無効」「Mixed content」など、具体的なメッセージで原因の絞り込みが進みます。

### 手順 2: パターンに応じて対処する

**パターン 1（HTTP 配信）**: サーバー側で HTTP → HTTPS の 301 リダイレクトを設定します。レンタルサーバーの管理画面で「常時 SSL」「HTTPS 強制」のスイッチがあれば有効化するだけです。

**パターン 2（期限切れ）**: SSL 証明書を再発行・更新します。Let's Encrypt なら自動更新の設定を確認し、商用 SSL なら認証局の管理画面から手動更新します。

**パターン 3（不一致）**: 不足しているホスト名の証明書を追加発行します。3 つ以上のサブドメインがあるならワイルドカード SSL も検討候補です（[ワイルドカード SSL はいつ必要？](/blog/wildcard-ssl-when-needed)）。

**パターン 4（mixed content）**: ページ内の `http://` リンクを `https://` に書き換えます。Chrome DevTools の Console タブで該当ファイルが特定できます。

### 手順 3: 全ページで警告が消えたか確認

トップページだけでなく、お問い合わせ・記事・カート画面など主要動線を一通りクリックして、警告が出ないことを確認します。

## 警告が出ている間のビジネスインパクト

「直し方が分かれば数時間で復旧できるから後回しでいい」と判断しがちですが、警告が出ている時間が長引くほど次の影響が積み上がります。

- 検索結果での順位下落（Google は HTTPS を順位要素にしている）
- お問い合わせフォーム入力中の離脱率上昇
- カート投入後の決済離脱
- 既存顧客から「乗っ取られた？」という不安の問い合わせ

特に EC サイトや問い合わせフォームを持つサイトは、警告 1 日あたりの売上機会損失が無視できない規模になります。

## 再発を防ぐチェック体制

「直したつもりが別のタイミングで再発する」のはこの領域の定番です。次の 3 点を社内ルールにします。

- SSL 証明書の有効期限を 30 日前にアラート（[SSL 証明書 有効期限の確認方法](/blog/ssl-expiration-check)）
- Web サイトの URL を変更した日 / サーバー移転した日は、必ず主要ページを Chrome で再確認
- CMS で記事を投稿するとき、画像は必ず HTTPS の URL で挿入（古い記事の `http://` リンクも年 1 回棚卸し）

## まとめ

- 「保護されていない通信」の原因は HTTP 配信 / 期限切れ / ドメイン不一致 / mixed content の 4 つ
- パターン特定 → 該当の手順で復旧、所要は数分〜数時間
- 放置すると検索順位・問い合わせ・売上に直結する
- 再発防止は期限アラート + 主要動線の定期確認 + 記事内 URL の棚卸し

## まずは現状を把握しましょう

自社の SSL 証明書の有効期限と設定状況は、ドメイン番人の[SSL 単発チェック](/ssl/check)で確認できます。メール認証も含めた総合点検は[無料診断](/diagnose)をご利用ください。