Chrome保護されていない通信を許可する手順と危険性

結論（30 秒で）: Chrome の「保護されていない通信」警告は、「詳細設定 → アクセスする」または thisisunsafe の入力で技術的には突破できます。ただしこれは通信が盗み見られるリスクを自分で受け入れる操作です。許可してよいのは「自分が管理するテスト環境」に限られ、心当たりのないサイトでは絶対に行ってはいけません。自社サイトで警告が出ているなら、許可ではなく原因の修復が唯一の正解です。

この記事でわかること

• 警告を一時的に許可して閲覧する具体的な操作手順
• thisisunsafe の正体と、なぜ入力欄がないのに効くのか
• 許可しても安全なケースと、絶対に許可してはいけないケース
• 自社サイトで警告が出ているときの根本対処

「許可」と「修復」はまったく別の話

最初に整理しておきたいのは、「警告を許可して進む」操作と「警告が出ないように直す」作業はまったくの別物だという点です。

許可は、いま自分が見ている端末の、いまのアクセスだけで警告画面をスキップする操作です。サイトそのものは何も変わりません。一方、修復はサイト側の設定を直す作業で、これをすれば訪問者全員に警告が出なくなります。

自社サイトに警告が出ている運営者がやるべきなのは、許可ではなく修復です。許可は自分の端末でだけ警告が消えるだけで、お客様の画面には警告が出続けているからです。この切り分けを誤ると、「自分の画面では直って見えるのに、問い合わせが減り続ける」という事態になります。

許可してよいのは、後述する「自分が管理するテスト環境」など、限られた場面だけです。

警告を一時的に許可して進む手順

訪問先が自分の管理するテスト環境であるなど、リスクを理解したうえで一時的に閲覧したい場合の操作は次のとおりです。

手順1: 詳細設定からアクセスする（標準的な方法）

最も一般的な方法です。

1. 警告画面の下部にある「詳細設定」をクリック
2. 表示されるエラー内容（NET::ERR_CERT_DATE_INVALID など）を確認
3. 「（ドメイン名）にアクセスする（安全ではありません）」のリンクをクリック

これで警告画面を抜けてサイトを表示できます。ただし手順3のリンクは、警告の深刻度によっては表示されないことがあります。

手順2: thisisunsafe と入力する（リンクが出ないとき）

NET::ERR_CERT_INVALID や HSTS（一度 HTTPS を強制したサイトへの常時 HTTPS 化設定）が効いているサイトでは、手順1の「アクセスする」リンク自体が出ないことがあります。

このとき Chrome には、警告画面にフォーカスがある状態でキーボードから thisisunsafe（半角英字、入力欄は不要）とそのままタイプすると突破できる、開発者向けの隠し操作があります。画面のどこかをクリックしてフォーカスを当ててから、見えない状態で打ち込みます。

これは Chrome が警告画面でキー入力を監視し、この文字列を検知すると「リスクを理解した利用者」とみなして先へ進める仕組みです。文字列自体が「これは安全ではない（this is unsafe）」という警句になっており、安易に使うものではないという設計者の意図が込められています。

手順3: 許可後も暗号化が保証されるとは限らない

許可して進んだ後でも、通信が安全になったわけではありません。証明書の期限切れだけが原因なら暗号化そのものは動いていますが、第三者が通信に割り込んでいる場合は、その第三者の鍵で暗号化されているだけで中身は筒抜けです。許可した時点で、暗号化の保証はなくなったと考えてください。

許可してよいケース・絶対にダメなケース

許可操作が許されるのは、ごく限られた場面だけです。

状況	判定	理由
自分が管理するテスト環境	許可してよい	入力を伴わず正体が明確
社内ネットワークの内部サーバ	条件付きで可	IT 部門の指示がある場合に限る
大手 EC / 銀行 / 行政サイト	許可しない	公式の障害告知を待つ
検索・メール・SMS 経由の見覚えなしサイト	絶対に許可しない	盗聴・詐欺被害に直結

特に最後の「心当たりのないサイト」での許可は、最も避けるべき行為です。フィッシングサイトでも証明書を正しく設置していれば警告は出ません。それでも警告が出るサイトは、期限切れの証明書を使い回すなど運用がずさんなケースが多く、警告そのものが「進む価値がないサイト」のシグナルになっています。

許可して進んだ先でログイン情報やカード番号を入力すると、通信を盗み見ている第三者にそのまま渡ってしまいます。「いつものサイトだから」という判断は通用しません。

自社サイトで警告が出ているときの根本対処

自社サイトに警告が出ている場合、許可は何の解決にもなりません。原因を直して、訪問者全員から警告を消す必要があります。

原因は大きく 4 つに分けられます。

• HTTP のまま配信している（HTTPS 化が未対応）
• SSL 証明書（通信を暗号化する電子証明書）の有効期限切れ
• 証明書のドメイン名とアクセス先が一致していない
• ページ内に HTTP の画像やスクリプトが混在している（mixed content）

どのパターンかは、URL バー左の警告アイコンをクリックして表示されるエラー内容で数秒で見分けられます。原因別の切り分けと復旧手順は Chrome「保護されていない通信」警告の直し方 に、有効期限切れが原因の場合は SSL 期限切れ警告の直し方 にまとめています。

復旧は、ビジネスへの影響が大きいページから順に進めるのが鉄則です。決済ページ、問い合わせフォーム、トップページ、その他の順に着手すれば、警告による離脱の損失を最小化できます。SSL のそもそもの仕組みや最低限おさえるべき点は 中小企業のための SSL 入門 で解説しています。

なお「許可するのか、修復するのか、訪問先で突破するのか」をケース別に判定したい場合は Chrome「保護されていない通信」解除方法 も参照してください。

再発を防ぐ運用

自社サイトの警告は、その多くが証明書の有効期限切れという「気づけば防げた」原因で発生します。

• 証明書の有効期限を一覧化し、期限の 30 日前にアラートが届くようにする
• 自動更新（Let's Encrypt など）を設定し、更新の失敗だけを検知する
• テスト環境でも自己署名証明書を使わず、正規の証明書を発行して警告を出さない構成にする

テスト環境で開発者が毎回 thisisunsafe を打つのが面倒、という運用は、突破操作を日常化させ、本番サイトの警告にも鈍感になる悪い習慣を生みます。テスト環境こそ正規の証明書を使い、警告が出ない状態を標準にしておくのが安全です。

よくある質問

許可した状態をずっと覚えさせることはできますか

できません。「このサイトの警告を覚える」のような恒久的な許可機能は Chrome にありません。これはセキュリティ設計上の意図的な仕様で、許可はあくまでその場限りの突破です。

thisisunsafe が効きません

入力欄に打ち込もうとしていないか確認してください。入力欄はなく、警告画面にフォーカスがある状態で、画面に何も表示されないままタイプします。Chrome のバージョンによっては合言葉が変わることもあり、その場合は突破せず原因の修復に切り替えるのが安全です。

許可して進んだサイトでパスワードを入れてしまいました

ただちにそのパスワードを別の安全な環境から変更してください。同じパスワードを他のサービスでも使い回している場合は、それらもすべて変更します。社内端末であれば IT 部門にも共有してください。

自社サイトの警告を一時的に許可で隠して様子を見てもいいですか

おすすめしません。許可はあなたの端末でしか効かず、お客様には警告が出続けます。様子見の間も離脱は発生するため、原因を特定して修復するのが最短の解決策です。

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

自社サイトの SSL 証明書の有効期限と設定状況は、無料で診断できます。警告が出ている原因がわからない、どこから直せばよいか判断に迷う、という場合は 無料診断 からご確認ください。専門家がわかりやすくサポートいたします。