「ChromeでHTTPのサイトに警告が出るようになる」と聞いて自社の状況を確認し、「うちはHTTPS対応済みだから関係ない」と結論した——という流れは、おそらく多くの会社で起きています。
この結論は半分正しく、半分は確認漏れを含みます。警告の判定対象は「そのサイトがHTTPSに対応しているか」ではなく、公開サイトにHTTPSで到達できるかどうかです。対応済みのサイトでも、HTTPで始まる到達経路が残っていれば、そこを通った利用者には警告が出ます。
点検の単位が「サイト」ではなく「経路」であること。その経路は自社の管理外にも散っていること。この2点を確認するのが本記事の範囲です。なお、この変更が検索順位や問い合わせ数にどう影響するかは、参照した公式文書のいずれにも記載がないため扱いません。
30秒で要点
- 警告の判定は「サイトがHTTPSか」ではなく「公開サイトにHTTPSで到達できるか」で行われる
- したがって点検の単位は経路になる。旧ドメイン・印刷物・他社サイトのリンクなど、自社の管理外も含む
- 公式告知（2025年10月28日公開）は「2026年10月、Chrome 154のリリースとともに」既定化すると書き、Chrome 154のリリースノートは安定版リリース日を2026年9月22日、機能名を「Ask before HTTP on by default」と書いている。版数は一致し、時期と名称はずれている
- 既定で有効になるのは公開サイト向けの設定。ローカルIPアドレスなどは対象外だが、対象外であることと安全であることは別
- 公式が推奨しているのは、設定を先に有効にして移行が必要なサイトを洗い出すこと
警告が判定しているのは、到達の仕方である
Googleの公式告知は、挙動を次のように説明しています。この設定が有効なとき、Chromeはすべての接続をHTTPSで試み、HTTPSが利用できない場合に、利用者に回避可能な警告を表示します。そして「HTTPSなしの公開サイトへの初回アクセスの前に、利用者の許可を求める」とされています。ここで判定されているのは、サイトの属性ではありません。いま踏み出した1回の遷移が、HTTPで始まっているかどうかです。だから、同じサイトでも入口によって結果が変わります。
https://example.com/のリンクから入る → HTTPSで到達。警告なしhttp://example.com/のリンクから入る → HTTPで始まる遷移。HTTPSが利用できなければ警告の対象- 旧ドメイン
http://old-example.jp/が新ドメインへリダイレクトしている → 最初の1歩はHTTP
3つ目が見落とされやすい箇所です。公式告知も、HTTPのまま残っている用途として「すぐにHTTPSサイトへリダイレクトするだけのHTTPナビゲーション」を挙げ、これを従来は利用者に見えなかった安全でないやりとりだと説明しています。リダイレクトが機能していることは、HTTPで始まった事実を打ち消しません。
常用サイトについては繰り返し警告されません。公式は、利用者が定期的に訪れている安全でないサイトについては繰り返し警告せず、警告が出るのは新しい（または最近訪れていない）サイトにHTTPSを使わず接続したときだとしています。つまり、既存顧客より、初めて来た人のほうが警告を見やすいことになります。
「うちはHTTPS対応済み」で止まってしまう理由
この確認漏れは、注意不足というより、HTTPS移行という作業の形が原因です。
HTTPS対応は、ほとんどの会社でプロジェクトとして実施されました。証明書を取得し、サーバーに設定し、内部リンクを書き換え、完了を報告する。終わりの日付がある作業です。終わった作業は、終わったものとして記憶されます。この記憶は「サイト単位」で残ります。
さらに確認の方法も「サイトを開いて鍵アイコンを見る」という形になりがちです。これはサイトの対応状況しか確かめられず、利用者が実際にどの経路で来ているかは教えません。手元で確認できることと、確認すべきことがずれています。
そして経路の多くは自社の管理外にあります。3年前に配った紙のパンフレット、取引先サイトの事業者一覧、古い記事に貼られたリンク。http:// で始まるURLが載っていても書き換えられません。管理できないものは点検リストに載りにくくなります。
結果として、「サイトは対応済み」と「経路は未確認」が同居した状態が残ります。Chromeの更新サイクルが2週間に短縮されたことで、こうした前提の確認が追いつかなくなる構造については、Chromeが2週間ごとに更新される時代｜「速くなった」ではなく前提が変わったでも扱っています。
公式文書どうしで、時期と名称がずれている
この題材で最も注意が必要なのは、変更そのものではなく、変更の時期と名称が公式文書間で一致していない点です。
表が収まらない場合は、横にスクロールできます
| 確認した文書 | 時期の記述 | 機能名 |
|---|---|---|
| Google公式告知（2025年10月28日公開） | 「2026年10月、Chrome 154のリリースとともに」既定で有効にする | Always Use Secure Connections（public-sites variant） |
| Chrome 154 リリースノート | Stable release date: September 22nd, 2026 | Ask before HTTP on by default |
版数（154）は一致しています。ずれているのは時期と名称です。
確かなこと：両文書がそれぞれこの記述をしていること。告知は2025年10月28日公開で、そこに書かれた「2026年10月」はその時点の予定であること。リリースノートは機能を「Chromeは既定で、安全でない（http）接続でサイトに接続するときユーザーに確認する」と説明し、管理者が HttpsOnlyMode エンタープライズポリシーでこの既定の挙動を制御できると記載していること。
まだ確かではないこと：どちらの時期が「正しい」のか。本記事では判定しません。告知が予告していたChrome 147での先行適用が実際に行われたかどうかも確認していません。Safari・Firefox・Edgeの挙動も未確認です。
片方を選んで断定すると、社内で「いつから」の認識が分かれた状態が固定されます。社内資料に書くなら「Chrome 154で既定化」という版数を軸にし、時期は判断する時点のリリース情報を参照する形が安全です。
対象外のものと、安全なものは別である
既定で有効になるのは public-sites variant、つまり公開サイトを対象にした設定です。公式はプライベートサイトの例として、ローカルIPアドレス（192.168.0.1など）・単一ラベルホスト名・intranet/ のようなショートリンクを挙げています。対象外になる理由は、プライベートな名前が一意でないためです。192.168.0.1 には単一の所有者が存在せず、認証局が所有を検証できないため証明書を取得できません。
ここで「社内システムは対象外だから何もしなくてよい」と読むと、公式の記述を半分だけ採ったことになります。同じ文書は、プライベートサイトへのHTTPにもリスクがありうる——同一ローカルネットワーク上の攻撃者に悪用されうる——と明記しています。警告が出ないことは、通信が保護されていることを意味しません。
なお公式は、ローカルネットワーク上の機器にアクセスするためにHTTPが残っている事例を挙げ、最近導入した local network access permission によって、許可が与えられたHTTPSページからローカルネットワークへアクセスできるようになり、HTTPS移行の障害が取り除かれうると述べています（導入時期や対応バージョンは「最近」とのみ書かれています）。
数字を読むときは、分母を確認する
公式告知には2種類の数字が出てきます。どちらも分母を見ないと意味を取り違えます。
1つめはHTTPSの比率です。公開サイトに限定して集計すると、Linuxは84%から約97%へ、Windowsは95%から98%へ、AndroidとMacはいずれも99%超になります。この分母は、Chrome の HTTPS transparency report に基づくページ本体（最上位フレーム）の読み込み数であり、サイト数ではありません。「HTTP対応のサイトが減った」話ではなく、「集計対象をどう限定したか」の話です。
2つめは警告の頻度です。Chrome 141で一部の利用者に対して公開サイト向けの既定有効化を実験した結果、警告は全ナビゲーションの3%を大きく下回り、中央値の利用者は週1件未満、95パーセンタイルの利用者は週3件未満だったとされています。分母は利用者のナビゲーション数、単位は件／週です。これは既定化後の実績ではなく、実験時点の観測値です。
分母を飛ばして「警告はほとんど出ない」と要約すると、流入経路に偏りがある場合（たとえば印刷物からの流入が多い場合）の見立てを誤ります。全体の平均は、自社の分布を教えません。
洗い出しの単位を「経路」に変える
公式は、サイト運営者やIT担当者に対して、影響を受けうる利用者がいる場合は、移行が必要なサイトを洗い出すために設定を先に有効にすることを強く推奨しています。推奨されているのは修正手順ではなく洗い出しです。この順序に沿うと、作業はこうなります。
- 自分のChromeで設定を有効にする。これで、自分が警告の出る経路を踏んだときに気づけるようになる
- 自社サイトへの入口を、経路として書き出す。サイトの一覧ではなく、入口の一覧を作る。例：主要ドメイン、旧ドメイン、キャンペーン用ドメイン、短縮URL、印刷物・名刺・QRコードのURL、取引先サイトの紹介ページ、埋め込みタグ（フォーム・地図・解析）
- 各経路の先頭が
http://かhttps://かを確認する。リダイレクトが設定されているかは、ここでは判断材料にしない。先頭がHTTPなら対象である - 書き換えられるものと、書き換えられないものに分ける。自社管理下のリンクは直せる。印刷済みの資料や他社サイトのリンクは直せない。直せないものについては、HTTPでの到達そのものを減らす手段（HTTPSへの誘導の整備、関係先への連絡）を検討する
- 社内資料には版数と確認日を併記する。「Chrome 154で既定化（2026年10月13日時点の公式文書では、時期の記述が告知とリリースノートで異なる）」のように書く
この手順の価値は、完了させることではなく直せない経路が存在すると分かることにあります。それが分かっていれば、警告の報告が上がったときに原因の候補を絞れます。
1週間で終わる最小の確認
まず、自分のChromeで「Always Use Secure Connections」に相当する設定を有効にしてください（版によって表示名が異なります）。そのうえで1週間、普段の業務のまま過ごします。
警告が出たら、URLをメモします。1週間後、メモを見ます。自社に関係するドメインが1つも出てこなければ、少なくとも自分の経路にHTTPは残っていません。出てきたら、それが最初に直すべき経路です。
この確認が効くのは、推測ではなく実際の遷移で判定される点です。「たぶんHTTPSになっている」が、1週間で「警告が出なかった」に置き換わります。
判断の土台として押さえておくこと
- 警告は、サイトの属性ではなく到達の仕方（1回の遷移がHTTPで始まったか）を判定している
- だから点検の単位は経路になる。経路は自社の管理外にも散っている
- 時期と名称は公式文書間でずれている。版数を軸にし、時期は判断時点の情報で確認する
- プライベートサイトは既定の対象外だが、公式はリスクがありうると明記している。対象外＝安全ではない
- 数字は分母を確認する。HTTPS比率はページ読み込み数ベース、警告頻度はChrome 141での実験時点の観測値
自社サイトの前提が外から変わる事例は、ブラウザの既定値以外にもあります。どこに確認が必要かを洗い出すところから整理したい場合は、状況を言語化するところから始めることができます。
状況を整理する（15分）より深く学ぶ
- Chromeが2週間ごとに更新される時代｜「速くなった」ではなく前提が変わった：版数と時期の確認を、運用の習慣にする考え方
- セキュリティとは？超初心者向け完全ガイド：通信の保護を含む、基本の整理
参考資料・引用元
- Google, HTTPSの既定化に関する公式告知（Google Blog, 2025年10月28日公開）. https://blog.google/security/https-by-defau/ （2026年10月11日確認）
- Google, Chrome 154 リリースノート（Chrome for Developers）. https://developer.chrome.com/release-notes/154 （2026年10月11日確認）