HSTS Preloadの登録・削除手順｜サブドメイン影響と切り戻しを安全に管理する

HSTS Preloadは、ブラウザが対象ドメインへ初めて接続する前からHTTPSを強制する仕組みです。初回のHTTP通信を残さない強い保護になる一方、親ドメインで登録すると、公開・非公開を問わず配下のサブドメインもHTTPSで到達できる状態を長期間維持しなければなりません。古い機器、委託先の管理画面、検証環境など一つでもHTTP依存が残ると、そのホストへブラウザから接続できなくなるおそれがあります。

結論から言うと、HSTS Preloadは「HTTPS化できたらすぐ登録する設定」ではありません。全サブドメインの棚卸し、証明書とHTTP→HTTPSリダイレクトの確認、短いmax-ageからの段階適用、監視と復旧手順を終えた後にだけ登録を判断します。登録後に問題が起きた場合は、まずHTTPSを復旧し、preloadを外した有効なHSTSヘッダーを配信して削除申請を行い、ブラウザ更新へ反映されるまで運用を継続します。

---

本記事のポイント

1. HSTSとHSTS Preloadは別の判断です。通常のHSTSは応答ヘッダーを受け取った後に有効になりますが、Preloadはブラウザ組み込みリストによって初回接続前からHTTPSを強制します。
2. 登録前にはベースドメインだけでなく、すべてのサブドメイン、内部ホスト、委託先サービス、古いDNSレコードまで調べ、HTTPSと証明書を継続できることを確認します。
3. 削除申請は即時の切り戻しではありません。Chrome利用者への反映にも時間がかかるため、申請後もHTTPSを維持し、対象ホストの復旧と監視を続けます。

---

HSTSとHSTS Preloadの違いを理解する

HSTS（HTTP Strict Transport Security）は、HTTPSで返すStrict-Transport-Securityレスポンスヘッダーによって、ブラウザへ「このドメインは一定期間HTTPSだけで接続する」と知らせる仕組みです。RFC 6797では、必須のmax-ageが保持期間を秒数で示し、任意のincludeSubDomainsが配下のホストにもポリシーを広げます。ブラウザは有効なHSTSポリシーを持つホストへのHTTP URLをHTTPSへ変更し、証明書エラーがある場合も安易な例外操作を許しません。

通常のHSTSには「最初の接続より前はポリシーを知らない」という空白があります。HSTS Preloadは、Chromeなどのブラウザへドメイン一覧を組み込むことで、この初回接続からHTTPSを強制します。Chromiumの公式ツールでは、登録された情報が静的なtransport security stateとしてブラウザへ組み込まれます。preloadディレクティブはRFC 6797本体の必須要素ではなく、Preload Listへの登録意思を示す運用上の合図です。ヘッダーへ追加しただけで登録完了にはならず、公式フォームから申請し、リストとブラウザの更新へ反映される必要があります。

観点	通常のHSTS	HSTS Preload
有効になる時点	ブラウザがHTTPS応答のHSTSヘッダーを受け取った後	対象ドメインへ初めてアクセスする前から
適用情報の持ち方	各ブラウザが受信したポリシーを期限付きで保持	ブラウザに組み込まれた静的リストを利用
サブドメイン	includeSubDomainsを付けた場合に対象	登録要件としてincludeSubDomainsが必要
解除の速度	HTTPS応答でmax-age=0を受け取れば、そのホストの動的ポリシーを削除できる	リスト削除とブラウザ更新の普及を待つ必要がある
向く状態	HTTPS運用を段階的に成熟させる段階	全サブドメインを長期にHTTPS専用で維持できる状態

HSTS Preload公式サイトは、HSTS自体を推奨しつつ、Preloadの効果はHSTSに比べて限定的であり、Preloadを一律には推奨していません。2026年8月16日時点でも、登録はセキュリティ要件や脅威モデル上の必要性と、全サブドメインをHTTPSへ固定する運用負荷を比較して決めるべきです。セキュリティヘッダーを小さく試してから制限を強める考え方は、CSP Report-Onlyの段階導入にも共通します。

登録前に全サブドメインと証明書を棚卸しする

最初に判断すべきなのは、ベースドメインのWebサイトがHTTPSかどうかではなく、その配下にHTTPSへ固定できないホストが一つもないかです。公式要件は、公開されていない内部サブドメインも対象に含めています。DNSで現在応答しない名前でも、古いドキュメント、社内ブックマーク、証明書ログ、過去のDNSエクスポート、SaaS設定に残っている場合は、将来再利用したときに影響します。

棚卸しでは、DNSゾーン、Certificate Transparencyログ、証明書管理台帳、CDN・WAF・ロードバランサー、クラウド管理画面、メールやファイル転送などWeb以外の用途を照合します。ワイルドカード証明書があるだけでは十分ではありません。各ホストでHTTPSが終端し、証明書チェーンが有効で、SNIやTLSバージョンが利用ブラウザに対応し、HTTPで待ち受ける場合は同一ホストのHTTPSへ転送されることまで確認します。証明書の発行先を制限する変更管理は、CAAレコードの運用と合わせて設計すると整理しやすくなります。

棚卸し対象	確認すること	登録前に解消すべき状態
公開Web・API	証明書、TLS、HTTP→HTTPS、CDNやWAF経由の応答	一部パスや旧ホストだけHTTPへ戻る
内部・検証ホスト	社内DNS、VPN内URL、自己署名証明書、開発機器	ブラウザで証明書例外を許可して使っている
委託先・SaaS	CNAME先、カスタムドメイン、証明書更新責任、解約時の扱い	委託先がHTTPSや更新期限を保証できない
休止・古いDNS	過去のゾーン、サブドメイン発行履歴、廃止予定、再利用方針	所有者不明のA・AAAA・CNAMEが残る
証明書運用	自動更新、失敗通知、秘密鍵、緊急再発行、失効	更新担当や復旧時間が決まっていない

ドメインの登録期限切れや権限喪失もHTTPS復旧を妨げます。レジストラ、DNS、証明書、CDNの所有者と緊急連絡先を結び付ける方法は、企業ドメインの更新期限管理を参照してください。Preload登録の変更責任者だけでなく、証明書障害を復旧できる実行者と、削除申請を判断する承認者も事前に決めます。

段階適用から登録までを7ステップで進める

いきなり1年以上のmax-ageとincludeSubDomainsを本番へ入れると、見落としたホストを長期間ロックします。HSTS Preload公式サイトは、5分、1週間、1か月と保持期間を段階的に伸ばし、各段階で問題を修正した後、その段階のmax-ageを満了するまで待つ進め方を案内しています。登録要件を満たすことと、安全に到達したことを分けて記録します。

1. 対象ドメインと変更責任を固定する：登録するベースドメイン、対象の全サブドメイン、DNS・証明書・CDN・アプリの所有者、緊急連絡先、変更窓、停止条件を台帳へ記録します。
2. HTTPSとリダイレクトを検査する：ベースドメインと全ホストで有効な証明書を返し、HTTPで待ち受けるホストは同一ホストのHTTPSへ転送します。HTTPS側でさらに転送する場合も、その応答自体にHSTSヘッダーがあることを確認します。
3. 短い保持期間でHSTSを開始する：max-age=300; includeSubDomainsから始め、アクセス不能、証明書警告、監視エラー、問い合わせを確認します。問題時はHTTPSを直し、必要に応じて短いポリシーのうちに見直します。
4. 1週間と1か月へ段階的に伸ばす：604800秒、2592000秒へ順に伸ばし、各段階の全期間を通して定期処理、月次アクセス、委託先更新、証明書自動更新まで観測します。
5. 登録要件のヘッダーへ進める：ベースドメインのHTTPS応答で、少なくともmax-age=31536000、includeSubDomains、preloadを指定します。wwwのDNSレコードがある場合は、そこでもHTTPSを利用できるようにします。
6. 公式フォームで状態を検査して申請する：hstspreload.orgで要件判定を確認し、影響範囲を理解した担当者が申請します。ヘッダー追加とフォーム申請の日時、判定結果、承認者を証跡に残します。
7. pendingから組み込みまで追跡する：申請状態、Chromium側リスト、利用ブラウザのstable版反映を監視します。登録後も証明書更新、DNS変更、新規サブドメイン作成のゲートへHTTPS必須チェックを組み込みます。

登録直前には「HTTPでしか使えない新規サブドメインを作らない」「証明書発行前にDNSだけ公開しない」「委託先のカスタムドメインを解約時に放置しない」を変更ルールにします。既存ホストの棚卸しだけでは、登録後の運用変更で再び障害を作るためです。外部スクリプトやWebサービスの所有者を継続的に追う方法は、企業サイトの外部スクリプト棚卸しも参考になります。

登録後の監視と削除・切り戻しを設計する

登録後は、HSTSヘッダーだけを監視しても不十分です。ベースドメインと主要サブドメインのHTTPS GET、証明書の有効期限とチェーン、DNS応答、HTTP→HTTPSリダイレクト、HSTSヘッダー、includeSubDomainsとpreloadの有無を別々に監視します。新規サブドメインをDNSへ追加する前には、証明書発行とHTTPS疎通を先に完了する変更ゲートを置きます。

障害時の第一目標はHTTPへ戻すことではなく、影響ホストのHTTPSを復旧することです。Preload済みブラウザはHTTP URLをHTTPSへ変更するため、DNSをHTTPサーバーへ向けても利用者は復旧できません。証明書の緊急再発行、CDNやロードバランサーの既知正常設定への復元、DNS切替、該当ホストの一時停止ページなど、HTTPSのまま到達できる復旧先を用意します。

Preload Listから削除する場合、公式フォームの現行要件では、対象が登録済みまたは登録待ちであること、有効な証明書でHTTPSを提供すること、有効なHSTSヘッダーからpreloadディレクティブを外すことが必要です。HSTS自体も完全に止める場合はmax-age=0を配信できますが、それは動的に保存されたポリシーの削除指示であり、ブラウザ組み込みリストから即座に消す操作ではありません。

公式サイトは、削除が多くのChrome利用者へ届くまで6〜12週間かかり、他のブラウザではさらに長くなる可能性があると案内しています。したがって、削除申請後も、Preloadが有効な利用者を前提にHTTPSを維持します。申請状態、Chromiumリスト、stable版、主要ブラウザの実機確認を追い、削除反映を確認する前に証明書やHTTPS終端を撤去しません。

事象	直ちに行うこと	してはいけないこと
証明書期限切れ・チェーン障害	有効な証明書へ再発行・切替し、全終端を検査	HTTPへ逃がせば見えると判断する
特定サブドメインがHTTPS非対応	HTTPS対応の一時復旧先へ向けるか、DNSと利用導線を安全に停止	証明書例外のクリックを利用者へ求める
Preload登録を撤回したい	ヘッダーからpreloadを外し、HTTPSを維持して削除申請	申請直後に証明書やHTTPS終端を廃止する
誤ったincludeSubDomains	影響ホストを特定し、HTTPSを復旧しながらヘッダーと削除方針を見直す	親ドメインのmax-age=0だけで全利用者が即時復旧すると考える

よくある質問

HSTS Preloadとは何ですか？

HSTSポリシーをブラウザへあらかじめ組み込み、対象ドメインへの初回アクセス前からHTTPSを強制する仕組みです。通常のHSTSはブラウザがHTTPS応答のヘッダーを受け取ってから有効になるため、その最初の接続の空白を埋めます。

HSTS Preload Listへ登録する前に何を確認しますか？

ベースドメイン、www、すべてのサブドメインと入れ子のホスト、内部DNS、委託先CNAME、休止ホストを洗い出し、有効な証明書とHTTPS応答を継続できるか確認します。HTTPで待ち受ける場合は同一ホストのHTTPSへ転送し、短いmax-ageから段階適用して障害がないことを確かめます。

includeSubDomainsは既存のサブドメインへどう影響しますか？

親ドメインのポリシーを配下のすべてのホストへ適用します。公開サイトだけでなく、社内専用、検証、古い機器、将来作る名前もHTTPS前提になります。自己署名証明書の例外操作やHTTP専用の管理画面に依存していると、ブラウザから到達できなくなる可能性があります。

HSTS Preloadを削除してHTTPS障害から復旧するにはどうしますか？

最初に有効な証明書とHTTPS終端を復旧します。そのうえでHSTSヘッダーからpreloadを外し、公式の削除フォームから申請します。削除はブラウザ更新の普及を待つため即時ではなく、反映までHTTPSを維持します。

preloadディレクティブを付けるだけで登録されますか？

いいえ。ディレクティブは登録意思を示す要件の一つですが、公式フォームからの申請と審査、リスト更新、ブラウザへの反映が必要です。申請後も公式サイトで状態を確認し、要件を継続して満たします。

HSTSは使ってもPreloadしない選択はありますか？

あります。通常のHSTSだけでも、ポリシーを受け取った後のHTTPS強制、ダウングレードやCookieへの攻撃の抑制に役立ちます。全サブドメインを長期間HTTPSへ固定できない場合や、Preload固有の効果が自社の脅威モデルに対して小さい場合は、段階適用したHSTSを維持し、Preload申請を見送る判断が適切です。

HSTS Preloadの解除申請は復旧そのものではなく、HTTPSを維持したままブラウザ組み込みリストから外れるまでを管理する長期の変更作業です。登録前の全ホスト棚卸し、短い保持期間からの段階適用、証明書とDNSの継続監視、HTTPSの緊急復旧、削除反映の追跡までを一つの運用としてつなげることで、強い保護を障害へ変えずに維持できます。