Chrome 154 が HTTP の読み込み前に確認を求める: 開発・ステージング・テスト自動化の変更点

もし http:// で始まるステージングリンクを共有したことがあるなら、Chrome はそれについて意見を持つようになりました。Chrome 154 はデフォルトで「Always Use Secure Connections」を有効にしました。Chrome は最初に HTTPS を試み、HTTPS で到達できない公開サイトへ初めてアクセスする前にユーザーの許可を求めます。

現代のウェブサイトを訪れる一般の訪問者には、何も変わりません。開発者にとっては話が違います。痛みは免除されている localhost には起こりません。実際のワークフローの静かな隅、公開ホスト名を持つステージングサーバ、証明書を誰も設定していないプレビュー環境、古いリダイレクトチェーン、そして人がいなくて「続行」をクリックできない CI ジョブに現れます。

このガイドは、出荷済みの内容、警告の挙動がどこで動くか、開発者と QA のワークフローをどこで壊すか、テスト自動化における正確なフラグ、そして根本原因をどう修正するかを解説します。

要約

• Chrome 154 は 2026 年 9 月 22 日に安定版チャンネルへ到達し、公開サイト専用の「Always Use Secure Connections」オプションがデフォルトで有効になっています。Google 自身のローンチ投稿は 2026 年 10 月 21 日に続きました。
• Chrome は最初に HTTPS を試みます。仮にそれが失敗して HTTP が機能する可能性がある場合、HTTP 経由でのページ読み込み前に確認を求めます。
• localhost、ローカル IP アドレス、単一ラベルのホスト名、staging.local のような非一意名は警告を引き起こしません。
• 平文 HTTP で提供される公開ホスト名はこの警告を引き起こす場合があります。人間が操作すればクリックして進むことはできるため、邪魔にはなる程度であり、壁にはなりません。自動化の監視なし運用では、壁になることもあります。
• テスト自動化には、Chromium の公式な回避策として --unsafely-treat-insecure-origin-as-secure が用意されています。
• 永続的な解決策は、すべての公開ホスト名で HTTPS を適用することです。リダイレクトの各ホップも含めてです。

Chrome 154 が実際に変更した点

The “Always Use Secure Connections” 設定は新しいものではありません。Chrome は 2022 年にオプトイン機能として導入しました。Google は後に、公開サイトのみに制限されたバリアントを追加しました。これは private サイトへの HTTP がもたらすリスクが少ないためです。Chrome 154 で変わったのはデフォルトです。

Here is the rollout, as Google described it:

いつ	発生した内容
2022	「Always Use Secure Connections」はオプトイン設定として開始
2024	公開サイト専用のバリアントが導入
Chrome 141	Google が公開サイト用バリアントを少数のユーザーに対して有効化する実験を実施
2025年10月28日	Chrome セキュリティチームがデフォルト化の計画を発表
Chrome 147 (2026年4月)	Enhanced Safe Browsing に登録済みのユーザーに対してデフォルト有効化、グループは 10 億人超と発表
Chrome 154 (2026年9月22日)	全ユーザーにデフォルト有効化、Chrome 154 のリリースノートより
2026年10月21日	Google が「Chrome Now Warns Before Insecure HTTP Connections」を公開、全ユーザーへのロールアウトを確認

最初の報道を読んだとき、1つ訂正すべき点があります。元の発表は変更が 2026 年 10 月に到来すると言っていました。Chrome 154 は実際には 2026 年 9 月 22 日に安定版へ到達しました。Chrome は 153 から 2 週間サイクルへ移行したためです。Chrome 154 のリリースノートには「デフォルトで HTTP について尋ねる」とあり、管理者は HttpsOnlyMode エンタープライズポリシーで制御できると記載されています。安定版リリースと同様、全機械への展開は徐々に進むため、野生環境でまだ古いビルドに出会うことがあります。

なぜ Google はこれをしたのですか？ Chrome Security Team の説明によれば、HTTPS を使用したページ読み込みの割合は 2015 年頃の約 30% から 2020 年頃には約 95–99% の範囲へと上昇し、それ以降はほぼ停滞しています。残りの部分が重要になるのは次の2つの理由です:

• 攻撃者は安全でないナビゲーションを1回行わせるだけで足場を得られることがあり、例えばナビゲーションを乗っ取り、攻撃者が制御する資源を読み込ませることができます。
• 多くの平文 HTTP 接続はユーザーには見えません。HTTP サイトは直ちに HTTPS へリダイレクトするため、古い「Not Secure」バッジが表示される機会はほとんどありません。

Chrome 141 の実験では、警告はナビゲーションの 3% 未満に留まりました。中央値のユーザーは週あたり 1 回未満、95 百分位のユーザーは 3 回未満です。2026年10月の投稿は早期展開データを追加します。デスクトップ版 Chrome の約 95% のユーザーは特定の週に HTTP 警告を見ず、1%未満が3 回以上を見ます。モバイルでの警告率はさらに低く、Chrome がこの変更をデフォルトにする初のブラウザであることも指摘されています。

警告の挙動

仕組みを理解することは、幽霊を追いかけるのを防ぐのに役立ちます。これは Chromium の採用ガイドが示す内容です。

トリガー。 Chrome が HTTPS 経由で接続できなかったが、HTTP 経由で接続できる可能性があると信じる場合に警告が表示されます。Chrome はページを読み込む前にユーザーに確認を求めます。

記憶。 Chrome はユーザーの決定を 15 日間覚えており、サイトを再訪するたびに例外が更新されます。HTTP サイトを定期的に利用する場合、警告は一度しか表示されないことがあります。Google のローンチ投稿は、サイトを 2 週間以上訪問していない場合に新しい警告が表示されなくなると説明しています。

HTTPS の明示的な使用は決してフォールバックしません。 もしリンクやアドレスバーが https:// を指定していて接続が失敗した場合、通常のネットワークエラーページが表示され、Chrome は HTTP を試みません。

HSTS が勝つ。 サイトに HTTP Strict Transport Security が設定されている場合、Chrome は HTTP へフォールバックしません。HSTS は自動アップグレードと新しい警告より優先されます。

リダイレクトのカウント。 リダイレクトチェーンのいずれかの段階が HTTPS をサポートしていない場合、最終先が HTTPS であっても警告が表示されます。ガイドの例では https://www.example.com は問題ありませんが、http://example.com が http://www.example.com にリダイレクトされ、 apex に HTTPS がない場合があります。訪問者が example.com を入力すると警告に遭遇します。短いホップが複数あると、1つのナビゲーションで複数の警告につながることがあります。

証明書エラーは変わりません。 有効期限切れの証明書や設定ミスのあるサーバーは、従来の証明書警告を引き続き出します。新しい警告タイプは追加されません。

既存の選択は尊重されます。 以前に設定をどちらの方向にしていたとしても、Chrome はその選択を保持します。

何が適用除外され、なぜ開発者が気にするのか

Chrome は世界を公開サイトと私有サイトに分け、警告は公開サイトのみに適用されます。私有サイトが除外されるのは次の2つの理由です:

• 例として 192.168.0.1 のようなローカル IP アドレス、intranet/ のような単一ラベルのホスト名、内部のショートリンクなど。
• 公開サイト向けの信頼された証明書を、非一意名に対して検証・発行する現実的な方法はなく、攻撃者は通常同じネットワークにいる必要があります。

ローカル開発については、採用ガイドが次のように説明しています:

• http://localhost は安全とみなされ、警告は表示されません。
• staging.local のようなローカル名、非一意名、ローカル IP アドレス、単一ラベルのホスト名にも警告は表示されません。
• HTTPS を使わない公開ホスト名を持つ開発サーバは警告を表示することがあります。クリックして進むと開発は今日と同様に続きます。

この最後の項目が重要です。あなたのノートパソコンは大丈夫です。http://staging.yourcompany.com のような共有ステージングボックスはそうではありません。

企業は逆の方向にも進めます。HttpsOnlyMode ポリシーを force_balanced_enabled に設定して新しいデフォルトを固定するか、force_enabled に設定して厳格モードにユーザーを誘導し、私有サイトにも警告を表示するようにします。

実際に影響が出る箇所: staging、プレビュー、共有環境

ほとんどの開発者はノートパソコン上でこれに気づきません。誰かがリンクを開くときに気づくことが多いです。典型的なトラブルスポット:

• 公開ホスト名を持つステージングサーバ。QA エンジニアやクライアントが http://staging.example.com を開くと、アプリの代わりにインタースティシャルが表示されます。回避は可能ですが、見た目は不安を煽ります。
• プレビューおよびデモ環境。アドホックのプレビュー箱や“一時的な”デプロイは証明書をスキップするサイトであり、チーム外の人と共有されます。
• リダイレクトチェーン。短いリンク、 apex から www へのリダイレクト、古いトラッキングリダイレクトは HTTP のホップを隠します。ユーザーには見えませんが、Chrome は認識します。
• ドキュメントとチケットの古いリンク。公開 DNS 名のツールへの http:// リンクは人々に警告を出し始めます。
• 放置されたもの全般。人間ならクリックして進めますが、スケジュールされたブラウザー ジョブはできません。

自分側の何かが警告を引き起こすかどうか分からない場合、Chrome のガイダンスはシンプルです: 設定を有効にして、通常のワークフローを使います。chrome://settings/security で「Always Use Secure Connections」を有効にし、公開サイトでの安全でない場合に警告するオプションを選択します。次に自分の staging、プレビュー、内部ツールを閲覧し、すべての警告をメモします。DevTools の Network パネルを使って、あまり明らかでない各リダイレクトホップを検査します。

テスト自動化: 必要なフラグ

自動化されたブラウザテストは、この変更の最も鋭い端です。人間は一度だけ「サイトへ進む」をクリックして進みます。Selenium、Playwright、Puppeteer の実行は通常新しいブラウザプロファイルで開始され、クリックする人がいないため、インタースティシャルがアプリケーションの妨げになります。

Chromium の公式の解決策は、コマンドラインフラグ --unsafely-treat-insecure-origin-as-secure です。これは origin のカンマ区切りリスト（例: http://example.com）またはホスト名のワイルドカード（例: *.example.com）を受け取ります。ガイドの例では特定のホストとワイルドカードを許可リストにしています：

--unsafely-treat-insecure-origin-as-secure=http://insecure.example,*.example.com

以下は実際の適用例です。

Playwright (TypeScript), in playwright.config.ts:

import { defineConfig } from '@playwright/test';

export default defineConfig({
  projects: [
    {
      name: 'chromium',
      use: {
        launchOptions: {
          args: [
            '--unsafely-treat-insecure-origin-as-secure=http://staging.example.com,*.preview.example.com',
          ],
        },
      },
    },
  ],
});

Selenium (Python):

from selenium import webdriver

opts = webdriver.ChromeOptions()
opts.add_argument(
    "--unsafely-treat-insecure-origin-as-secure="
    "http://staging.example.com,*.preview.example.com"
)
driver = webdriver.Chrome(options=opts)

同じパターンは Puppeteer や他の Chrome 起動引数を渡せる任意のツールでも機能します。

実務的な注意点:

1. リストは絞っておく。 フラグ名が“unsafely”とされているのには理由があります。テストで必要なホストだけを許可し、 blanket pattern は使わないでください。これを専用のブラウザプロファイルとペアで使うとよいです。
2. 副作用を理解する。 このフラグは HTTP の origin をセキュアコンテキストのように振る舞わせるため、セキュアコンテキスト専用の API がそこで動作する可能性があります。これは転送の暗号化を追加するものではありません。許可リストにある HTTP origin での緑のテストが、production の HTTPS パスが機能することを証明するわけではありません。
3. 古いオプトアウトに注意。 ローンチ前、ガイドはデフォルト機能をオフにする方法として --disable-features=HttpsFirstBalancedModeAutoEnable を挙げていました。事前ローンチのオプションとして説明されていたので、依存する前に現在の Chromium のドキュメントを再確認してください。
4. ブラウザを固定しておく。 Chrome は現在、安定版のメジャーリリースを2週間ごとに出します。そのため自動更新 CI イメージはこのような変更を静かに取り込みます。バージョンを固定し（例えば Testing 用の Chrome を使うなど）、意図的にバージョンを上げてください。企業は Extended Stable チャネルを使用することもでき、8 週間サイクルで新しいデフォルトを別のスケジュールで取り込みます。
5. 管理下のフリート。 HttpAllowlist エンタープライズポリシーは、 [*.]example.com のようなホスト名またはパターンを取り扱い、アップグレードや警告の対象にしません。

このフラグは実際のユーザーには影響しません。ステージングが公開されている場合、外部のレビュアーには依然としてプロンプトが表示されます。

原因を修正する: すべての公開ホスト名で HTTPS を有効にする

許可リストはテスト実行環境のための応急処置に過ぎません。実際の修正は公開ホスト名を HTTP で提供するのを止めることです。

証明書の自動化。 Chromium のガイドは ACME ベースの自動化を指しています。Apache は mod_md、Nginx はネイティブ ACME サポート、Caddy は自動的に証明書を扱います。多くの証明書機関は現在無料証明書を提供しており、Let’s Encrypt は最もよく知られた例です。コストはもはやステージングを回避する理由にはなりません。自分でサーバを運用していない場合は、ホスティングプロバイダに HTTPS を有効にしてもらってください。現代のホストは通常サポートしています。サーバー設定には Chromium は Mozilla SSL Configuration Generator を推奨しています。

すべてのリダイレクトのホップを修正。 アペックスドメイン、www 変種、バニティドメイン、URL 短縮サービス、トラッキングリダイレクトを点検します。チェーンの各ステップは HTTPS で応答する必要があります。途中にドメイン転送サービスがある場合、HTTPS 対応かどうかを提供元に確認してください。あなたのドメインがプロバイダへの CNAME の場合、通常プロバイダが代わりに証明書を取得できます。

localhost はローカル作業用に使う。 ローカル作業ではすでに安全として扱われています。ローカルで実際の HTTPS が必要な場合、Chromium は web.dev のガイド「ローカル開発で HTTPS を使用する時期」と「ローカル開発で HTTPS を使用する」を参照するよう案内しています。

非本番ホストでの HSTS に注意。 HSTS は最も強力な信号で、Chrome は HTTP へ戻さないため、本番環境には適しますが、ヘッダを一度見てしまうと後の証明書問題はクリックを超えて厳しくなります。すべてのサブドメインが準備できるまで、広範なサブドメインルールは避けてください。

トンネルの役割

上記の手順はうまく解決できないケースもあります。自分のマシンで開発サーバを走らせており、チームメイト、クライアント、ウェブフック送信者が外部から到達する必要がある場合です。throwaway 環境の HTTPS を自分でホストするのは手間が掛かり過ぎることがあります。

ここで HTTPS トンネルが役に立ちます。InstaTunnel はデフォルトで HTTPS でトンネルを提供するため、共有する URL は最初のクリックから https:// アドレスになります。レビュワーがそれを開いても HTTP 警告には遭いませんし、明日削除するホスト名の証明書を用意する必要もありません。安定したカスタムサブドメインも、チケットに貼るリンクをセッションごとに新しい URL に変更せずに機能させ続けます。

この話には2つの正直な注意点があります。どちらも私たちのトンネルに限られた話ではありません:

• あなたのアプリはローカルで依然 HTTP を話します。 トンネルはエッジで HTTPS を終端し、開発サーバへ転送します。フレームワークが絶対 URL を構築したり、リクエストのスキームに基づくリダイレクトを強制したりする場合、転送されたプロトコルヘッダを正しく信頼するようにしてください。そうしないとリダイレクトループや混在コンテンツの問題が発生する可能性があります。多くの開発サーバは未認識の Host ヘッダをデフォルトで拒否するため、トンネルのホスト名を allowed-hosts 設定へ追加する必要があるかもしれません。

• トンネルは実際のステージング環境の代替にはなりません。 共有環境が数か月も続く場合は、実際のホスト名と自動証明書を用意してください。トンネルは短期間の“今すぐ共有”が必要なケースに適しています。

補足: これは Chrome の Local Network Access プロンプトとは別の仕組みです。Local Network Access は公開ページがローカルネットワークに到達することに関するものです。Chrome 154 はこの領域を拡張します。WebSocket のコンストラクターに targetAddressSpace オプションを追加して、公開ホスト名への接続をローカルまたはループバック先として扱えるようにします。Chrome 154 のリリースノートは、HTTPS なしでローカルサーバと対話する場合の混在コンテンツ制限を回避する方法としてこれを説明していますが、ユーザーがローカルネットワークの許可を与えた場合に限ります。一方、Ask-before-HTTP は、HTTPS のない公開ページをナビゲートすることに関する話です。

よくある質問

Chrome 154 は HTTP サイトをブロックしますか？ いいえ。公開 HTTP サイトへ初回訪問前に許可を求め、警告は回避可能です。Chrome はその選択を 15 日間記憶し、訪問のたびに更新します。

http://localhost は警告を表示しますか？ いいえ。Chrome はそれを安全とみなします。localhost、ローカル IP アドレス、単一ラベルのホスト名、staging.local のような非一意名も除外されます。

自分の環境でこれをオフにできますか？ はい。chrome://settings/security で「Always Use Secure Connections」を無効にしてください。Chrome 154 の前にどちらかを設定していても、Chrome はあなたの選択を維持します。

Selenium や Playwright で警告を止めるには？ テストで使用する特定の origin やワイルドカードホストを指定して --unsafely-treat-insecure-origin-as-secure を渡します。

Firefox、Safari、Edge は？ Chromium のガイドによれば、3つはすでに HTTP のナビゲーションを HTTPS にアップグレードしており、HTTP にフォールバックする前に警告するオプションモードを提供しています。違いは Chrome がこの警告をデフォルトで有効にした点です。

結論

Chrome 154 はウェブを壊すことはなく、多くのサイトで目に見える変更はありませんでした。しかし、公開は HTTPS が前提という明確な線引きを引きました。開発者は localhost や私有名には引き続き自由ですが、公開ホスト名を使うステージングサーバ、プレビュー環境、テスト自動化は、適切な証明書を用意するか、限定的な例外を設ける必要があります。設定を一日かけて有効にし、環境を確認し、警告を出すホストを修正してください。デモリンクを開くすべてのクライアントに警告を説明するより安価です。

出典

• HTTPS by default, Chrome Security Team (Oct 28, 2025)
• Chrome Now Warns Before Insecure HTTP Connections, Chrome Secure Web and Networking Team (Oct 21, 2026)
• Adapting your website for Chrome’s “Ask-before-HTTP” warning, Chromium docs
• Chrome 154 release notes, Chrome for Developers
• Get features faster with Chrome’s two-week release cycle, Chrome for Developers Blog (Mar 3, 2026)
• Fresher features, faster fixes: The two-week release cycle is here, Chrome for Developers Blog (Sep 8, 2026)
• Google Chrome starts two-week release cycle with version 153, 9to5Google
• Chrome to Turn HTTPS on by Default for Public Sites, SecurityWeek
• Chrome Will Default to HTTPS for All Public Sites Starting October 2026, CyberInsider