WEBサイトChrome 154は、HTTPのページを開く前に既定で確認を出す。最終ページがHTTPSでも、転送の途中がHTTPなら出る ── 自社の入口を1つずつ開いて確認する13項目（2026年10月時点）
Chrome 154は、HTTPのページを開く前に既定で確認を出す。最終ページがHTTPSでも、転送の途中がHTTPなら出る ── 自社の入口を1つずつ開いて確認する13項目（2026年10月時点）
目次
01 何が起きたか — Chrome 154のリリースノートに「Ask before HTTP on by default」が載った
リリースノートに書かれたこと
Chrome 154のリリースノートには、「Privacy and security」（訳: プライバシーとセキュリティ）の項目に、「Ask before HTTP on by default」（訳: HTTPの前に確認を出す機能が、既定でオン）という見出しがある。同じページには「Stable release date: September 22nd, 2026」（訳: 安定版の公開日: 2026年9月22日）と書かれ、ページ下部の最終更新は「2026-09-22 UTC」だった。この記事は、2026年10月3日にこのページを開いて確かめた。
"Chrome prompts users by default when they connect to a site over an insecure (http) connection. Administrators can control this default behavior using the HttpsOnlyMode enterprise policy."
（訳: Chromeは、安全でない（http）接続でサイトに接続するとき、既定で利用者に確認を出します。管理者は、HttpsOnlyModeという企業向けの設定で、この既定の動作を制御できます。）
導入ガイドに書かれた、転送についての1文
Chromeの開発チームは、サイト運営者向けに「Adapting your website for Chrome's "Ask-before-HTTP" warning」（訳: Chromeの「HTTPの前に確認」の警告に、自分のサイトを合わせる）というガイドを公開している。冒頭には、Chrome 154から、既定でHTTPのページに進む前に利用者の許可を求め始めるという趣旨の文がある。ガイドが運営者に注意を促すのは、次の1文である。
"If in the process of navigating to an HTTPS site there were any redirect steps that do not support HTTPS, Chrome will show an Ask-before-HTTP warning."
（訳: HTTPSのサイトへ移動する途中に、HTTPSに対応していない転送の段が1つでもあれば、Chromeは「HTTPの前に確認」の警告を出します。）
ここが、この記事の中心である。最終的に着くページがHTTPSであっても、途中の転送の段がHTTPのままなら、警告は出る。ガイドは、警告を出したあと利用者が先へ進むと、移動はHTTPSのサイトへ続く、とも書いている。つまり、警告は「最終ページが危ない」という意味ではなく、「途中にHTTPで通る段があった」という意味である。
いつ、誰に届くのか
日付については、公式の文書が2通りの書き方をしている。2025年10月に公開されたGoogleのセキュリティブログ（HTTPS by default）は、「Chrome 154のリリース（2026年10月）で、既定の設定を『Always Use Secure Connections』（訳: 常に安全な接続を使う）の有効に変える」と書き、その前にChrome 147（2026年4月）で、拡張セーフブラウジングを使う10億人以上の利用者に先に有効にする、とも書いている。一方、Chrome 154のリリースノートは、安定版の公開日を2026年9月22日としている。この記事は、すべての利用者にいつ届くかを断定しない。段階的に広がる仕組みであり、公式の文書に、利用者ごとの届く日は書かれていないためである。
出典（Chrome公式）
Chrome 154 release notes（訳: Chrome 154のリリースノート）と、Adapting your website for Chrome's "Ask-before-HTTP" warning（訳: Chromeの「HTTPの前に確認」の警告にサイトを合わせる）。引用した英文は、どちらも原文から取った。2026年10月3日に開いて確かめた。
この記事が扱うこと
扱うのは、検索順位の話ではなく、読者のブラウザが警告を出す条件である。自社サイトの入口になっている古いURL、ドメインの転送、メールの署名、QRコード、SNSのプロフィールのリンクを1つずつ開き、転送の各段がHTTPSで動くかを確かめる手順をまとめる。HTTPSの被リンクや混在コンテンツは参照元ページの更新とHTTPSの被リンク — リンク切れと混在コンテンツを自分で点検する（2026年8月時点）、301の転送のたどり方は301リダイレクトは被リンクの評価を引き継ぐか？ チェーンと着地点の落とし穴（2026年8月時点）で扱った。ここでは繰り返さない。
02 なぜ・背景 — 利用者に見えなかった「HTTPで通る一瞬」を、見えるようにする
HTTPSはほとんど普及したが、残りが問題になっている
セキュリティブログによれば、Chromeの移動のうちHTTPSの割合は、2020年ごろに95〜99%の範囲に達したあと、ほとんど伸びていない。公開サイトだけで見ると、Windowsで98%、AndroidとMacで99%を超える、とも書かれている。残りの数%について、セキュリティブログは、攻撃者は安全でない移動が1回あればよいので、多くのサイトがHTTPSにしていても関係がない、と書いている。原文は"any single HTTP navigation may offer a foothold"（訳: HTTPでの移動は、1回でも、足がかりになりうる）である。
"What's worse, many plaintext HTTP connections today are entirely invisible to users, as HTTP sites may immediately redirect to HTTPS sites."
（訳: さらに悪いことに、今日の暗号化されていないHTTP接続の多くは、利用者にまったく見えていません。HTTPのサイトが、すぐにHTTPSのサイトへ転送することがあるためです。）
この文が、転送の途中の段を警告の対象にした理由を最もよく表している。利用者は最終ページしか見ない。途中でHTTPを通ったかどうかは、アドレスバーに残らない。見えない段が、警告によって初めて見えるようになる。
警告は、同じサイトに何度も出ない
公式は、利用者の負担を抑える工夫も書いている。導入ガイドによれば、Chromeは利用者の選択を15日間覚えており、そのサイトを再び訪れるたびに、この例外は更新される。HTTPのサイトを日常的に使う人は、そのサイトの警告を1回しか見ないこともある、と書かれている。セキュリティブログも、ふだん訪れているHTTPのサイトについて、同じ警告を繰り返さない、と説明している。
一方で、運営者の側から見ると、「初めて来た人」には毎回出うる。新しい読者、検索から来た人、QRコードを初めて読み取った人は、そのサイトの警告をまだ見ていない人たちである。
実験の数字
公式は、Chrome 141での小規模な実験の結果を書いている。警告を見る人は、移動全体の3%よりかなり少なく、中央値の利用者で、1週間に1回未満だったという。ただし、これは一部の利用者での実験の結果であり、すべての利用者の将来の数字ではない。自社の読者に何%の警告が出るかは、公式の文書から読み取れない。
注意
この機能が検索順位に影響するかについて、公式の文書は何も述べていない。この記事も、順位への影響は書かない。確かめるのは、読者のブラウザで警告が出る条件だけである。
03 用語 — 警告の名前と、設定の名前をそろえる
Always Use Secure Connections（常に安全な接続を使う）
Chromeの設定の名前である。設定の画面は、アドレスバーにchrome://settings/securityと入れて開く。導入ガイドは、Chrome 154から、HTTPのページに進む前に利用者の許可を求めることが既定になる、と書いている。公開サイト向けの形（public-sites variant）が既定でオンになる、という書き方は、導入ガイドではなく、セキュリティブログ（HTTPS by default）にある。オフにする場合は、利用者がこの設定を自分で切り替える。以前に自分で設定を決めていた人は、その選択が尊重される、とも導入ガイドに書かれている。
Ask-before-HTTP（HTTPの前に確認）
導入ガイドが使う、警告の名前である。ガイドは、警告が出る場合を「Chromeが、そのサイトにHTTPSで接続できなかったが、HTTPなら接続できると考えられるとき」と説明している。Chromeはまず、HTTPSでの接続を試みる。その接続が成り立たないときに、HTTPで進んでよいかを利用者に尋ねる、という順序である。
転送の段（redirect step）
あるURLを開いたとき、サーバーが「こちらへ移動してください」と返し、次のURLへ進む、その1回1回を指す。たとえば、http://example.com から http://www.example.com へ、さらに https://www.example.com へ、という移動なら、3つのURLで、転送の段は2つである。警告の対象は、この「途中の段」にもある。
apexドメイン
wwwなどのサブドメインがつかない、ドメインそのものを指す。ガイドの例では、https://www.example.com でサイトを公開し、http://example.com から http://www.example.com へ転送している場合に、example.com 側でHTTPSの接続を受け付けていなければ、利用者に警告が出る、と書かれている。
HSTS（HTTP Strict Transport Security）
サイトが「このサイトには、HTTPSだけで接続してほしい」とブラウザに伝える仕組みで、Strict-Transport-Securityというヘッダーで送る。ガイドには、HSTSが設定されたサイトでは、ChromeはHTTPへの切り替えを試みない、HSTSは自動のHTTPS化や警告より優先される、と書かれている。
用語
公開サイトと、非公開の名前。ガイドによれば、ローカルの開発に使うlocalhost、固有でない名前、ローカルのIPアドレス、ドットのない1語の名前（社内の短い名前など）では、警告は出ない。この記事が扱うのは、インターネットに公開している自社サイトの入口である。
04 型別 — 誰に関係し、何を、どの順で確かめるか
🅰 適用範囲 — 自社サイトがHTTPSでも、入口は別に確かめる
自社のサイトの本体が、すべてHTTPSで動いていても、入口になっているURLが別にある。ガイドの言葉では、「すべての入口と転送の連なりが、最終ページだけでなく、途中の1段ごとにHTTPSに対応していること」が条件である。確かめる入口は、次の6種類である。
ガイドは、追跡のために使う転送や、ドメイン転送のサービスにも触れている。転送を挟むサービスを使っている場合は、そのサービスがHTTPSに対応しているかを、提供元に確かめる必要がある、と書かれている。
🅱 この記事が確かめていないこと
注意
この記事は、Chrome 154の画面で警告を実際に出して確かめてはいない。確かめたのは、公式の文書に書かれていることだけである。警告がどのくらいの利用者に出るか、いつ全員に届くか、ほかのブラウザでの扱い、検索順位への影響は、公式の文書から読み取れなかったため、書かない。
🅲 手順 — 入口を洗い出し、1段ずつ開く
手順は3つの段階である。1つ目は、入口を集める。2つ目は、各入口の転送を1段ずつ確かめる。3つ目は、Chromeの設定を使って、警告が出るかを試す。
段階1 — 入口を、紙に書き出す
次の表の6種類を目安に、自社の入口を書き出す。数は多くなくてよい。5つ見つかれば十分な出発点になる。
| 入口の種類 | 探す場所の例 | 見るもの |
|---|---|---|
| 古いURL | 名刺、古いチラシ、古い記事内のリンク | http:// で始まるURLが、HTTPSに着くまでの段 |
| ドメイン名だけ | wwwのつかない入口、別に取った旧ドメイン | HTTPSで接続できるか。証明書が入っているか |
| wwwの有無 | wwwあり・なしの両方のURL | どちらからも、1回でHTTPSの正規のURLに着くか |
| メールの署名 | 全員の署名、自動返信の定型文 | リンクが https:// で書かれているか |
| QRコード | 印刷物、看板、名刺 | 読み取った先のURLが、https:// で始まるか |
| SNS・被リンク | SNSのプロフィール、提携先のサイト | 貼られているURLが、http:// のままでないか |
表の2列目と3列目は、この記事の提案である。公式のガイドが指定した分類ではない。
段階2 — 転送を、1段ずつ見る
ガイドは、転送の各段を調べる方法として、Chromeの開発者ツールのNetworkパネルで、移動のたびに起きる転送を1つずつ見ることを挙げている。ほかに、コマンドでURLを1つずつ取得して、返ってくる転送先を見る方法もある。どちらの方法でも、見るのは「転送先のURLが、http:// か https:// か」と、「その段が、HTTPSの接続を受け付けるか」の2点である。
段階3 — Chromeの設定で、警告が出るかを試す
ガイドは、サイトを試す方法として、chrome://settings/securityで「Always Use Secure Connections」を有効にして、ふだんの作業をしてみることを勧めている。想定していなかったHTTPの利用があれば、警告として見つかる、と書かれている。警告が出たら、そのときのURLを見て、HTTPSに対応させる必要のあるホストを特定する、という進め方である。
サイト内のリンクをまとめて見たいときは、当サイトの無料ツール🔧 WEBサイト内のリンク漏れ・チェックツールが使える。自社サイトの中に、http:// のまま残るリンクが無いかを探す入口になる。
05 自分のサイトで確認するチェックリスト
下の13項目は、1項目5分ほどでできる作業である。項目1〜2は公式の文書を読む作業、項目3〜6は入口を集める作業、項目7〜11は転送を1段ずつ見る作業、項目12〜13は直す順番を決める作業である。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。
- Chrome 154のリリースノート（developer.chrome.com/release-notes/154）を開き、「Ask before HTTP on by default」の段落と、安定版の公開日を、そのままメモに書き写す
- Chromeの導入ガイドを開き、「redirect steps」という語を含む段落を探して、メモに書き写す
- 自社サイトの名刺・パンフレット・メールの署名から、URLが書かれているものを5つ選び、書かれているURLが「http://」か「https://」で始まるかを表に記入する
- 自社のドメインについて、「wwwあり」「wwwなし」「http://」「https://」の4通りのURLを書き出す
- QRコードを使っている印刷物や看板があれば、1つ選んでスマートフォンで読み取り、読み取った先のURLが「https://」で始まるかを記録する（無ければ「無し」と書く）
- SNSのプロフィールと、提携先のサイトに貼られている自社のURLを3つ探し、「http://」のまま貼られているものの数を数える
- 手順4の4通りのURLを、ブラウザの開発者ツールのNetworkパネルを開いて1つずつ表示し、転送が何段あるかを数えて、表に書き込む
- 手順7で転送が2段以上あったURLについて、途中の各段のURLを書き出し、「http://」で始まる段が1つでもあるかを記録する
- 途中の段が「http://」だったURLについて、そのホスト名の「https://」版をブラウザで開き、接続できるか、証明書のエラーが出るかを記録する
- chrome://settings/security を開き、「Always Use Secure Connections」を有効にして、手順3〜6で見つけたURLを1つずつ開き、確認の警告が出た数を数える
- 自社のドメインへの外部の転送サービス（ドメイン転送・短縮URL・計測用の転送）を使っているか確かめ、使っていれば、提供元に「HTTPSに対応しているか」を問い合わせる文面を1通書く
- ここまでに見つかったHTTPの段を、「自社で直せる」「提供元に頼む」「印刷物の差し替えが要る」の3つに振り分けて、件数を書く
- 振り分けた3つのうち、手を付ける順番を1つ決め、担当者の名前と日付をカレンダーに登録する
チェックリストの使い方
時間が限られているときは、項目4・7・8の3つだけでも、自社の4通りのURLが、1回でHTTPSに着くかが分かる。そこで、途中に「http://」の段が見つかったら、項目9で、その段のHTTPS版が開けるかを確かめる。項目10は、Chromeの設定を変えて試すため、普段使いのChromeではなく、確認用のChromeのプロファイルで行うと、自分の設定を変えずに済む。
転送の連なりが長いサイトでは、サーバー側の301が使えないとき、次に選ぶべきはどれか ── meta refreshとJavaScriptリダイレクトの判定基準を確認する13項目（2026年9月時点）も参考になる。サーバー側の301が使えないとき、転送の種類をどう選ぶかを扱った記事である。
06 代替・他の選択肢 — HTTPの段が見つかったときの直し方を表で比べる
公式が書いている範囲で比べる
次の表は、HTTPの段が見つかったときの直し方を、公式の導入ガイドの記述と並べたものである。「向くとき」「注意」の列は、この記事の提案で、公式の文書が指定した基準ではない。
| 直し方 | 公式の説明で読み取れること | 向くとき | 注意 |
|---|---|---|---|
| その段をHTTPSに対応させる | 転送のすべての段が、HTTPSの接続に対応するよう設定する。ドメイン名だけの入口にもHTTPSを足す | 自社のサーバーで直せるとき | 証明書の取得と更新の仕組みも、一緒に確かめる |
| 提供元に頼む | ドメイン転送のサービスを使う場合は、提供元に、HTTPSへの対応と、追加の設定の要否を問い合わせる | 転送を外部のサービスに任せているとき | 回答が来るまでの間、警告が出うる |
| HSTSを設定する | HSTSを設定したサイトでは、ChromeはHTTPへの切り替えを試みない。自動のHTTPS化や警告より優先される | HTTPSが安定して動いているサイト | 設定した内容は、ブラウザが一定期間覚える。設定の前に、全入口のHTTPS対応を確かめる |
| 入口そのものを替える | 入口になるリンクと転送の連なりが、最終ページだけでなく、途中の1段ごとにHTTPSに対応していることが条件、と書かれている | 印刷物やQRコードを差し替えられるとき | 古い印刷物は、差し替えまで出回る |
組織の側で、警告を抑える設定もある
導入ガイドには、企業や学校のように、Chromeを管理する組織向けの設定も書かれている。特定のHTTPのサイトを、警告の対象から外す「HttpAllowlist」と、警告の方針を組織で決める「HttpsOnlyMode」である。これは、自社を訪れる読者の側の設定であり、運営者が読者に求められるものではない。自社の社内で、社員のChromeを管理している場合の話として読むのが適切である。
証明書の警告は、別のもの
導入ガイドは、証明書の期限切れやサーバーの設定の誤りで出る警告は、今回の変更の対象外で、変わらない、と書いている。「HTTPの前に確認」の警告と、証明書のエラーの警告は、別のものである。HTTPSに対応させたあとも、証明書の更新が止まっていないかは、別に見る必要がある。
HSTSを設定する前の確かめ方や、サーバーでの転送の設定の組み合わせについては、サイト移転は4パターンある ── URL変更を伴う移転で確認する15項目（2026年9月時点）で、URLが変わる移転の確認項目を扱っている。
07 このサイトでの記録 — HTTPSは、一度入れたら終わりではなかった
この記事は、当サイトがChrome 154の警告の対象かどうかを報告するものではない。確かめたのは、公式の文書と、そこに書かれた手順である。そのうえで、HTTPSの設定が、入れたあとにも続く作業であることは、当サイトでも経験している。
2026年9月19日、当サイトは、HTTPSの証明書の自動更新が、9月4日から毎日失敗していたことを見つけて直した。原因は、アクセスを絞るための設定が、証明書の発行元が確認のために送ってくるアクセスまで止めていたことだった。更新は、期限が近づくまで失敗しても、サイトの表示には何も出ない。見つかったのは、記事に書いた確認項目を自分のサイトに当てたときだった。記事に書いた確認項目を自分のサイトに当てて、弱点が見つかった別の例は、記事に書いた弱点が、自分のサイトにあった ── 公開した日にチェック項目を当てたら、エラー画面の返し方と、サイトの名前の書き方がそろっていなかったに書いている。
この経験から言えるのは、「HTTPSに対応した」という状態は、入口と転送の段だけでなく、証明書の更新まで含めて続くということである。この記事のチェックリストでも、項目9で、途中の段の証明書のエラーの有無を確かめるようにしている。
08 このテーマの、これまで
HTTPの警告をめぐる、公式の動き
次の表は、この記事で開いた公式の文書から、日付が読み取れたものだけを並べたものである。記載のないものは、確かめていない。
| 時期 | 出来事 |
|---|---|
| 2025年10月28日 | Googleのセキュリティブログが、Chrome 154で「Always Use Secure Connections」を既定にすると発表する。拡張セーフブラウジングの利用者には、Chrome 147（2026年4月）で先に有効にする、と書かれた |
| 2025年10月29日 | Search Engine Journalが、この発表を伝える |
| 2026年9月22日 | Chrome 154のリリースノートに、安定版の公開日として記載される。「Ask before HTTP on by default」の項目がある |
表のChrome 147の件は、2025年のブログに「予定」として書かれていたものであり、実際に行われたかは、この記事では確かめていない。
当サイトの、関連する過去の記事
- 参照元ページの更新とHTTPSの被リンク — リンク切れと混在コンテンツを自分で点検する（2026年8月時点） — HTTPSの被リンクと、混在コンテンツの点検を扱った。
- 301リダイレクトは被リンクの評価を引き継ぐか？ チェーンと着地点の落とし穴（2026年8月時点） — 301の転送が、被リンクの評価を引き継ぐかを扱った。
- サーバー側の301が使えないとき、次に選ぶべきはどれか ── meta refreshとJavaScriptリダイレクトの判定基準を確認する13項目（2026年9月時点） — サーバー側の301が使えないときの、転送の選び方を扱った。
- canonicalタグは『ヒント』であって『命令』ではない ── Search Consoleで、Googleが選んだ正規URLを自分のサイトで確認する15項目（2026年9月時点） — 正規のURLをGoogleがどう選ぶかを扱った。
当サイトのブログで、近い話を書いた回
- 「リンク切れ0本」も「200が返る」も、まだ2段目だった ── 番号が変わるサイトで見つけた、リンクの3段目のずれ — リンクの確認を、3つの段階に分けて行った記録。転送の各段を見る考え方に近い。
- Google が求める 4 層整合性 — sitemap・canonical・内部リンク・末尾スラッシュを curl 3 行で揃える — サイトマップ・正規URL・内部リンク・末尾のスラッシュをそろえる確認を扱った。
- 「リンク切れ0本」を確認して、安心しかけた ── 自社ブログの内部リンク、59.2%はnoindexへの飛び先だった — 「リンク切れ0本」でも、飛び先に問題が残っていた例を扱った。
- 毎朝の「警告1,415件」を、初めて種類別に数えた ── 96.7%は見なくていいもので、唯一の「本物」は自分で叩くまで分からなかった — 警告の件数を合計だけで見ず、種類別に数え直した例。今回の確認で、警告が出た入口を種類ごとに分ける考え方に近い。
現在の貴方のIPアドレス
このサイトで書いている人
