目次
HTTPへのアクセスをHTTPSへ転送する設定と、ブラウザーへ今後はHTTPSだけを使うよう伝えるHSTSは、異なる仕組みです。導入するなら、効く範囲だけでなく、証明書や古いサブドメインに問題が起きた場合も含めて理解しておく必要があります。
本記事は2026年10月18日にMDNとHSTS Preload Listの一次資料を確認した実務解説です。特定の事件の速報ではありません。既存のHTTPS転送の設定記事とは分け、ポリシーの保持と段階導入の判断を中心に扱います。点検と試験の順序は本サイトの提案です。
スポンサーリンク
転送の前にHTTPの通信が起きる場合がある
HTTPで接続してからサーバーがHTTPSのURLへ転送する方式では、その最初の通信がHTTPになる場合があります。HSTSのポリシーを保持しているブラウザーは、対象へのHTTPのURLを通信前にHTTPSへ切り替えることで、この境界を守ります。
MDNは、Strict-Transport-SecurityをHTTPSの応答で受け取り、ブラウザーがそのポリシーを保持する仕組みを説明しています。HTTPの応答へ同じヘッダーを付けても、同じように信頼されるものではありません。
本サイトの提案は、転送とHSTSをどちらか一方の代わりと捉えず、利用者がどのURLから入り、どの状態のブラウザーで接続するかを整理することです。HTTPSへ接続できる基盤が安定していることが前提になります。
出典：MDN Strict-Transport-Security。
保持期間はサーバーの設定だけの話ではない
max-ageは、ブラウザーがポリシーを保持する期間を指定します。後からサーバーの設定を変えても、すでに保持しているブラウザーへ即座に反映されるとは限りません。長い期間を最初から設定する前に、障害時にどうなるかを検討します。
本サイトの提案は、短い保持期間から代表の利用環境を確認し、問題を直しながら段階的に広げることです。具体的な期間は、変更の責任者、監視、復旧に必要な時間、サイトの特性に合わせて選びます。一般的な一例を、すべてのサイトの正解にしないでください。
HSTS Preload Listの公式な導入案にも、保持期間を段階的に増やす手順があります。前の段階で設定した期間を考慮して観測し、正常なトップページ一回の表示だけで次へ進まないようにします。
スポンサーリンク
サブドメインには内部向けの用途も含める
includeSubDomainsを指定すると、適用先は親の一つのページだけには収まりません。古いキャンペーン、検証、社内向け、外部サービスへ委託した名前など、サブドメインを一覧にしてHTTPSを提供できるか確認します。
本サイトの提案として、DNSの名前、用途、運用者、証明書、HTTPSの提供可否を対応させます。公開していない内部向けの名前も、利用者のブラウザーから使われるなら対象として考えます。管理者が普段見ているサイトの範囲だけで判断しないでください。
今後新しく作るサブドメインも、ポリシーに合う運用が必要になります。部署や委託先が追加する際のルールへ反映し、導入した時点の一覧だけで作業を終わらせないようにします。
証明書の更新を運用の前提にする
HSTSは証明書の問題を修復する仕組みではありません。HTTPSに必要な証明書の期限、名前、信頼関係が正しくないと、利用者が接続できなくなる場合があります。ブラウザーの警告を手動で進める運用へ頼らない設計が必要です。
本サイトの提案は、証明書の自動更新、更新失敗の通知、公開側での有効性確認を先に整えることです。更新コマンドが成功した記録だけでなく、CDNやロードバランサーを経た実際の接続で新しい証明書が提供されているかを確認します。
委託先の証明書も、責任者と連絡方法を明確にします。DNSの移管や配信基盤の変更時に、HTTPSを一時的に外して復旧する計画は、保持済みのHSTSと両立しない場合があります。変更計画へ通信の継続条件を含めてください。
出典：HSTS Preload List Deployment Recommendations。
スポンサーリンク
配信経路ごとにヘッダーの実際を確認する
アプリでヘッダーを設定しても、CDNやプロキシが変更したり、一部の応答へだけ適用したりする場合があります。通常のページ、転送、静的ファイル、エラー応答など、公開側で返す代表の経路を確認します。
本サイトの提案は、どの層がHSTSを管理するかを一つに整理することです。複数の場所で異なる値を付けると、設定の意図と実際の応答を追いにくくなります。アプリの環境変数だけでなく、基盤のテンプレートや配布の設定も点検します。
開発環境と本番の名前を不用意に共用しないことも重要です。試験用に長いポリシーを付ける作業が、実際の利用者のブラウザーへ影響しない構成で試します。この記事は実サイトの設定を変更する指示ではなく、導入前の判断手順です。
初めて接続するブラウザーでは限界がある
ブラウザーがまだポリシーを知らない段階では、通常のHSTSだけで最初の接続をすべて保護できるとは限りません。ブラウザー自体のHTTPSへの切り替え機能もありますが、HSTSの保存状態と同じものではありません。
この最初の接続に対応する方法として、ブラウザーに組み込まれるプリロードの一覧があります。ただし、通常のHSTSを使う判断と、一覧へ登録する判断は分けます。ヘッダーへpreloadと書くだけで、すべてのブラウザーへ直ちに登録されるわけではありません。
確認時点のHSTS Preload List公式ページは、HSTSは推奨しつつ、プリロードの追加の利点は小さく、プリロード自体は推奨しないと説明しています。古い設定例を見て、自動的に登録まで進めないようにしてください。
プリロードは撤回の時間も考えて判断する
プリロードは、一覧の変更がブラウザーの更新を通じて届くため、追加も削除も即時とは限りません。公式ページは削除の反映に長い時間がかかることを説明し、全サブドメインで長期にHTTPSを提供できることを求めています。
本サイトの提案は、特に必要性がある場合だけ、管理範囲と長期の維持能力を確認して別の変更として検討することです。通常のHSTSの段階導入を試すために、本番ドメインをプリロードへ登録する方法は取りません。
ポリシーの保持を解除するためのmax-age=0も、HTTPSの応答を受け取る必要があります。それだけで組み込みの一覧や別に保持された子のポリシーがすべて消えると考えず、現在の状態ごとに復旧の条件を確認します。
委託先の変更と新規の名前を運用ルールに含める
仮想のサイトで、古いフォームだけを外部サービスへ委託しているとします。親ドメインで広いポリシーを導入する前に、その名前でもHTTPSを継続できるか、証明書の責任は誰にあるかを確認します。本体のサイトだけ正常であっても、全体の条件を満たしたことにはなりません。
本サイトの提案は、新しいサブドメインの申請へ、HTTPSの提供と証明書更新の確認を含めることです。新規公開の後に対応するのではなく、名前を追加する時点で既存のポリシーとの整合を確認します。内部の検証用の名前も、同じ親の範囲にあるなら例外として忘れないようにします。
廃止した名前は、DNSや委託先の設定も含めて整理します。HSTSを入れる作業は、使っていない名前が他者へ向く問題を修復するものではありません。台帳を共用しつつ、通信の強制と名前の所有の対策は分けて維持します。
スポンサーリンク
変更計画に観測期間と中止条件を書く
導入の計画には、現在のヘッダー、変更後の値、対象の名前、観測する経路、次へ進む条件を記録します。保持期間の途中で問題が起きた場合に、どの利用者へどの状態が残り得るかを説明できるようにします。
本サイトの提案は、HTTPSへ接続できない経路や証明書更新の失敗が見つかったら、保持期間を延ばす作業を止めて原因を解消することです。導入を急ぐために対象の存在を無視したり、利用者へ証明書の警告を回避させたりしないようにします。
変更を戻す場合も、HTTPの応答だけを変更したら終わりとは考えません。HTTPSで提供されるポリシーと、すでに保存された状態、プリロードの有無を分けて確認し、回復を観測します。サーバーの設定画面が戻ったことと、利用者が接続できることは別の確認です。
新規と保持済みのブラウザーを分けて試す
検証環境では、まだポリシーを持たない状態と、HTTPSでポリシーを受け取った状態を分けます。HTTPのURLを開いたときの通信と、公開側のヘッダーを観察し、意図した範囲へ適用されるかを確かめます。
親と子の名前、代表の転送先、複数の配信経路も確認します。証明書エラーの試験は本番の証明書を壊すのではなく、管理する検証環境で実施します。利用者のブラウザーの状態を一括で消せる前提で復旧計画を作らないようにします。
HSTSの導入は、ヘッダーを一行追加する作業だけでは完成しません。HTTPSを維持する体制、適用範囲、保持期間、障害時の挙動を確認し、運用できる範囲から段階的に進めることが重要です。
スポンサーリンク
参考資料
以下の一次資料を2026年10月18日に確認しました。本文の仮想例と運用手順の提案は、資料の引用とは区別しています。
