HSTSのmax-ageは、ブラウザがHTTPSだけで開くと覚えておく秒数で、出典ごとに勧める長さが違う ── 担当サイトの値を秒から日に直して、延ばす前に戻せるかを確かめる13項目（2026年11月時点）

目次

1. 01 何が書いてあるか — max-ageは「HTTPSだけで開くと、ブラウザが覚えておく秒数」で、出典ごとに勧める長さが違った
   1. 6つの出典が書く、max-ageの長さ
   2. 秒を日に直す
2. 02 なぜ・背景 — 覚える長さは、守れる期間と、引き返せない期間を、同時に決める
   1. HSTSが防ぐもの
   2. 覚えている間だけ、守られる
   3. 最初の1回は、守られない
   4. 受け取らなくなっても、前の指示は残る
   5. 長くしたら、その間、HTTPSを保つ約束になる
3. 03 用語 — 出てくる言葉を、先にそろえる
   1. 「ホスト」と「サブドメイン」の違い
   2. 「秒」「日」「月」の書き分け
4. 04 型別 — 適用範囲、書かれていないこと、手順
   1. 🅰 どのサイトが当てはまるか
   2. 🅱 出典が書いていないこと
   3. 🅲 手順1 — 応答から値を取る
   4. 🅲 手順2 — 日に直して、近い出典を書く
   5. 🅲 手順3 — 同じ値が、ホストごと・応答ごとに返るか
   6. 🅲 手順4 — httpの応答には、見出しが付いていないことを確かめる
   7. 🅲 手順5 — サブドメインを数える
   8. 🅲 手順6 — 戻せる準備を、先に決める
5. 05 明日、担当サイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — 値を延ばす、延ばさない、使わない
   1. 状況ごとに、表で並べる
   2. ブラウザ側の自動の格上げは、HSTSの代わりではない
   3. 調べる道具
7. 07 当サイトで確かめたこと — 応答は30日で、httpの転送の応答にも同じ見出しが付いていた
   1. 当サイトの応答の値
   2. httpの転送の応答にも、同じ見出しが付いていた
   3. 30日を、出典に並べると
   4. 確かめていないこと
8. 08 このテーマは、ここまで — 転送と証明書から、ブラウザに覚えさせる期間へ
   1. これまでの記事
   2. 今回の記事の位置
   3. 2026年11月7日 — この記事の確認日
9. 09 この記事のまとめ

01 何が書いてあるか — max-ageは「HTTPSだけで開くと、ブラウザが覚えておく秒数」で、出典ごとに勧める長さが違った

HSTS（HTTP Strict Transport Security）は、サーバーが「このホストは、HTTPSだけで開くこと」とブラウザに伝える仕組みである。伝え方は、HTTPSの応答に付けるStrict-Transport-Securityという見出し（ヘッダー）で、その中のmax-ageが、ブラウザが覚えておく秒数を決める。この記事は、その秒数を、担当サイトの運営の側から読む。値の決め方はサイトごとに違うが、先に「どの出典が、どれだけの長さを書いているか」を並べておくと、自分のサイトの値を読みやすくなる。

6つの出典が書く、max-ageの長さ

読んだページのうち6つが書く長さを、表に並べた。右から2番目の列は、筆者が秒を86400（1日の秒数）で割って、日に直した値である。

出典	書かれていた長さ	日に直すと	書かれ方
hstspreload.org（延ばす手順）	300→604800→2592000の3段階	5分→7日→30日	各段階で、壊れたページが無いか調べ、その段階の長さの分だけ待ってから次へ進む手順として書く
hstspreload.org（申請の条件）	31536000以上	365日以上	事前登録の申請に必要な条件の1つ。includeSubDomainsとpreloadも付ける
MDN	31536000以上（事前登録を使うとき）。例に31536000と、2年の例	365日以上。730日の例	事前登録を使うときの最小の値と、例として書く。includeSubDomainsも付ける
Mozillaの手引き	15768000以上。63072000も勧める	182.5日以上。730日も勧める	最小の値として「6か月」を書き、より長い2年を勧める
OWASPの手引き	63072000（例）。86400（初期の例）	730日。1日	例として挙げる。86400の例は、最初の展開で間違えたときのために短くする、と書く
Chromiumのページ	16070400（例）	186日	例として挙げる
RFC 6797（6.2節と11.2節）	31536000／15768000／7776000（例）	365日／182.5日／90日	例として挙げる。筆者が読んだ範囲では、規格は、この長さにせよとは書いていない

同じHSTSでも、5分から2年まで、長さの幅がある。幅が出る理由は、読んだ範囲では2つに分けられる。1つ目は、「延ばしている途中の値」と「落ち着いたあとの値」の違いである。hstspreload.orgは前者を書き、Mozillaは後者を勧め、OWASPは後者の例を書く、というのが筆者の読みである。2つ目は、事前登録（プリロード）という別の目的で、1年以上と決まっていることである。

秒を日に直す

max-ageは、日ではなく秒で書く。担当サイトの応答にmax-age=2592000とあれば、86400で割って30日である。値を日に直す作業は、5分もかからないが、この作業をしないと、「長いのか短いのか」を台帳に書けない。下の図に、表に出てきた値を日に直して並べた。

02 なぜ・背景 — 覚える長さは、守れる期間と、引き返せない期間を、同時に決める

HSTSが防ぐもの

hstspreload.orgは、HSTSが、ネットワークの途中にいる攻撃者（on-path attacker）から守るものとして、3つを挙げている。1つ目は"Browsing history leaks"（訳: 閲覧履歴の漏れ）で、HTTPのリンクを押すと、途中の観察者にそのURLが見える。HSTSが効いていれば、ブラウザがURLをHTTPSに上げてから送るので、パスは見えない。2つ目は"Protocol downgrades"（訳: プロトコルの引き下げ）で、HTTPからHTTPSへの転送を、途中で書き換えられて、HTTPのまま使わされる。3つ目は"Cookie hijacking"（訳: Cookieの乗っ取り）で、HTTPの要求では、途中の攻撃者がCookieを見て書き換えられる。

覚えている間だけ、守られる

MDNは、この見出しは、受け取った応答の扱いを変えるのではなく、これからの要求の作り方を変えると説明している。HTTPSの応答でこの見出しを受け取ったブラウザは、そのホストの名前を、HSTSを使うホストの一覧に入れる。以後、httpのURLを読み込む前に、この一覧を調べて、一致すれば、URLの頭をhttpsに替える。

覚えている期間は、受け取るたびに延びる。MDNは、"Every time the browser receives a Strict-Transport-Security header, it updates the host's HSTS expiration time by adding max-age to the current time."（訳: ブラウザは、この見出しを受け取るたびに、そのホストの期限を、現在の時刻にmax-ageを足した時刻に更新する）と書く。毎日来る利用者なら、30日の値でも、期限は毎日先へ延びる。一方、30日を超えて来なかった利用者は、覚えが切れる。次の図は、30日の値で、0日目・20日目・80日目に接続した場合の、筆者の例である。

最初の1回は、守られない

MDNは、HSTSの弱点として、"One weakness of HSTS is that it does not take effect until the browser has made at least one secure connection to the host and received the Strict-Transport-Security header."（訳: HSTSの弱点の1つは、ブラウザが、そのホストへ少なくとも1回、安全な接続をして、この見出しを受け取るまで、効かないことである）と書く。RFC 6797も、14.6節で、この弱点を「ブートストラップのMITM」と呼び、利用者が知らないホストを、httpのURLで開いたときの最初のやり取りが、攻撃を受けうると説明している。覚えが切れた利用者は、この最初の1回に戻る。筆者の読みでは、長い値は、「最初の1回」に戻る人を減らすことになる。

受け取らなくなっても、前の指示は残る

見出しを付けるのをやめても、すぐには戻らない。MDNは、"If the Strict-Transport-Security header is missing in a response from a host that previously sent one, the previous header remains in effect until its expiration time."（訳: 以前にこの見出しを送ったホストの応答に、この見出しが無いとき、前の見出しは、期限まで効き続ける）と書く。やめたいときは、max-age=0を送る。ただし、MDNは、"This only takes effect once the browser makes a secure request and receives the response header."（訳: ブラウザが安全な要求をして、その応答の見出しを受け取ったときにだけ、効く）と書く。HTTPでは止められない作りで、そのホストに戻ってこない利用者には、届かない。

長くしたら、その間、HTTPSを保つ約束になる

Mozillaの手引きは、"Note that once this value is set, the site must continue to support HTTPS until the expiry time has been reached."（訳: 注意: この値を設定したら、期限になるまで、サイトはHTTPSに対応し続けなければならない）と書く。さらにMDNは、HSTSのホストで、証明書の誤りなどのTLSの警告や誤りが出たとき、ブラウザは、利用者に「進む」手段を出さないと書く。証明書の更新が漏れた日に、利用者が「それでも開く」を選べなくなる、ということである。長い値は、守る期間を延ばすと同時に、HTTPSを保てない日の影響を、長い間、利用者に残す。証明書の更新の仕組みを確かめる記事は、「Let's Encryptの証明書は2027年2月10日から標準で64日になる ── 更新の設定の「日数の決め打ち」とARI対応を確かめる13項目（2026年10月時点）」にある。

03 用語 — 出てくる言葉を、先にそろえる

「ホスト」と「サブドメイン」の違い

MDNは、HSTSは、ホストをドメイン名だけで見分け、ポートは区別しないと書く。ポートを指定したhttpのURLも、そのポートのまま、httpsで接続される。一方、example.comの値は、www.example.comには効かない。includeSubDomainsを付けない限り、サブドメインは別のホストとして、別々に覚えられる。MDNは、サブドメインに入る人が、親のドメインを経由しない場合があるので、サブドメインも、それぞれこの見出しを返すほうがよいと書く。

「秒」「日」「月」の書き分け

この記事は、max-ageの秒数と、その日数を、必ず並べて書く。「1か月」は、hstspreload.orgの例では2592000秒（30日）、「6か月」は、Mozillaの手引きでは15768000秒（182.5日）である。月という書き方は、日数が一定でないので、台帳には、秒と日を書く。

04 型別 — 適用範囲、書かれていないこと、手順

🅰 どのサイトが当てはまるか

当てはまるのは、HTTPSで配信しているホストのすべてである。筆者の読みでは、ログインやフォームがあるホスト、サブドメインごとに別の画面を出しているサイトで、値の決め方が効いてくる。RFC 6797の11.4節は、サブドメインごとに別のウェブアプリを提供する場合、利用者が親のドメインに触れないままサブドメインを開くことがあるので、includeSubDomainsには、よく考える価値があると書いている。

🅱 出典が書いていないこと

• 担当サイトにとっての、正しい日数。出典は、例と、最小の値と、延ばす手順を書いているだけである。
• 検索順位への影響。読んだページには、書かれていない。
• 利用者が、サイトに戻ってくる間隔。担当サイトのログで数えないと、30日で足りるかは分からない。
• ブラウザごとの保存の仕組みの違い。読んだページには、書かれていない。

したがって、「何日が正しいか」は、この記事では言えない。言えるのは、出典が書く長さと、確かめ方と、延ばす前に確かめることである。

🅲 手順1 — 応答から値を取る

ブラウザの開発者ツールの通信の画面で、トップのURLを開き、応答の見出しにStrict-Transport-Securityがあるかを見る。コマンドが使える人は、curl -sIでも取れる。見つかったmax-ageの秒数は、そのまま台帳に書き写す。

🅲 手順2 — 日に直して、近い出典を書く

秒数を86400で割って日にする。日数を、01章の表の長さ（5分・7日・30日・約6か月・1年・2年）のどれに近いかで、1行にして、台帳に書く。「近い」ことは、正しいことの証拠にならない。位置を知るための印である。

🅲 手順3 — 同じ値が、ホストごと・応答ごとに返るか

wwwの有り無し、サブドメイン、存在しないURLの画面（404）、httpから転送される応答で、見出しが同じかを調べる。CDNやホスティング会社の画面で設定している場合は、サーバー側の設定と、2か所で同じ見出しを付けていないかも、見る。これは、筆者の案である。

ホスト	応答	max-age（秒）	日数	includeSubDomains	確認日
example.com（例）	https・200	2592000	30	無し	2026年11月7日
www.example.com（例）	https・404	2592000	30	無し	2026年11月7日
example.com（例）	http・301	（見出し無し）	—	—	2026年11月7日

🅲 手順4 — httpの応答には、見出しが付いていないことを確かめる

RFC 6797の7.2節は、"An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport."（訳: HSTSのホストは、安全でない通信で運ばれるHTTPの応答に、この見出しを含めてはならない）と書く。受け取るブラウザ側も、8.1節で、安全でない通信で受け取ったこの見出しは無視しなければならないと書く。MDNも、HTTPの応答には付けない形を書いている。付いていても、ブラウザの動きは変わらない形だが、規格の書く形とは違うので、台帳に書いて、直すかを決める。

🅲 手順5 — サブドメインを数える

includeSubDomainsを付ける前に、ドメインの下にあるサブドメインを、DNSの管理画面で全部数える。Mozillaの手引きは、"Extreme care is needed when setting the includeSubDomains flag, as it could disable sites on subdomains that don’t yet have HTTPS enabled."（訳: includeSubDomainsを設定するときは、細心の注意が要る。まだHTTPSにしていないサブドメインのサイトが、使えなくなるおそれがある）と書く。hstspreload.orgも、事前登録は、一般に公開していない内部のサブドメインにも及ぶと書く。

🅲 手順6 — 戻せる準備を、先に決める

長くする前に、2つを決める。1つ目は、期限が来るまでHTTPSを保つ人と、その連絡先である。2つ目は、証明書の更新が自動か手作業か、失敗したときに誰が気づくかである。証明書の更新の確認の記事は、「Let's Encryptのドメイン確認の使い回しは30日から10日に縮む。通常の更新は、寿命の約3分の2で動くなら毎回確認し直している計算になる ── 確認の方法が毎回通るかを自社で確かめる14項目（2026年10月時点）」にある。

05 明日、担当サイトで確認できることチェックリスト

以下は、担当サイトのHSTSの値を、秒から日に直し、延ばす前に戻せるかを確かめる13項目である。1〜4番目は値を読む確認、5〜9番目はホストと応答を広げて見る確認、10〜11番目は戻せるかの確認、12〜13番目は事前登録と記録の確認である。チェックの状態は、使っているブラウザに保存され、サーバーには送られない。

• 担当サイトのトップのURLを3つ選び、ブラウザの開発者ツールの通信の画面で、応答の見出しにStrict-Transport-Securityがあるかを見て、ある・無いで台帳に書く
• 見出しがあるサイトは、max-ageの秒数を、そのまま台帳に書き写す
• 書き写した秒数を86400で割り、日数を、台帳の隣の列に書く
• 日数が、01章の表の長さ（5分・7日・30日・約6か月・1年・2年）のどれに近いかを、1行で台帳に書く
• 同じサイトのwwwの有りと無しの2つのURLを開き、max-ageが同じ値かを、同じ・違うで書く
• 存在しないURLを1つ開いて（404の画面）、同じ見出しが付くかを、付く・付かないで書く
• http://で始まるトップのURLを開き、転送の応答に見出しが付いていないかを、付いていない・付いているで書く
• includeSubDomainsが付いているかを、付いている・付いていないで、台帳に書く
• ドメインの下のサブドメインを、DNSの管理画面で数え、HTTPSで開けないものの数を書く（0なら0と書く）
• 証明書の期限の日付を、ブラウザの鍵のマークから開いて書き、更新が自動か手作業かを、担当者に聞いて書く
• max-ageを延ばす場合の次の値と日付を台帳に書き、HTTPだけで動く古い画面が無いかを、担当者に1通のメッセージで聞く
• 事前登録を申請したいサイトがあれば、hstspreload.orgの「Submission Requirements」を開き、3つの条件を台帳に書き写して、満たしているものに印を付ける
• 次の確認日を台帳に書き、その日に、日数と各ホストの値を、もう一度取る

06 代替・他の選択肢 — 値を延ばす、延ばさない、使わない

状況ごとに、表で並べる

表の根拠は、MozillaやhstspreloadなどのページとRFCである。どの行を選ぶかは、担当サイトの事情で決まり、出典が決めてくれるものではない。

状況	選べる設定	利点	注意すること	出典
まだ付けていない・試す段階	300秒（5分）から始める	間違えても、数分で覚えが切れる	守られる期間も短い	hstspreload.org
短い値で付けている	段階を上げ、各段階で、その長さの分だけ待つ	壊れたページを、小さな範囲で見つけられる	待つ間に、サブドメインも含めて調べる	hstspreload.org
30日で落ち着いている	約6か月（15768000）以上へ	覚えが切れて、最初の1回に戻る利用者が減る	その間、HTTPSを保ち続ける	Mozillaの手引き
サブドメインも守りたい	includeSubDomainsを付ける	サブドメイン側のCookieの攻撃を、証明書の確認で防げる	HTTPSでないサブドメインが、開けなくなる	OWASP／Mozilla／RFC 6797
事前登録に載せたい	1年以上＋includeSubDomains＋preload	最初の1回も、HTTPSで始められる	削除のページは、削除が多くのChrome利用者に届くまで6〜12週間、ほかのブラウザはさらにかかりうると書く。hstspreload.org自身が、事前登録は勧めないと書く	hstspreload.org
HSTSを使わない	HTTPからHTTPSへの転送だけを置く	設定が増えない	ブラウザに覚えさせる仕組みが無いので、http://で開く利用者の最初の接続は、毎回HTTPになりうる	MDN

ブラウザ側の自動の格上げは、HSTSの代わりではない

hstspreload.orgは、"Many browsers (Chrome, Safari) will automatically upgrade all HTTP navigations to HTTPS, regardless of the domain's HSTS policy."（訳: 多くのブラウザ（ChromeとSafari）は、ドメインのHSTSの方針にかかわらず、すべてのHTTPの移動を、自動でHTTPSに上げる）と書き、"HSTS preloading only provides value when these upgrades fail in the presence of an active attacker."（訳: HSTSの事前登録が価値を持つのは、能動的な攻撃者がいる中で、これらの格上げが失敗するときだけである）と説明している。Chromium Blogの2023年8月16日の記事は、Chromeがhttp://の移動を自動でhttps://に上げると書き、"This works very similarly to HSTS upgrading, but Chrome will detect when these upgrades fail (e.g. due to a site providing an invalid certificate or returning a HTTP 404), and will automatically fallback to http://."（訳: これはHSTSによる格上げによく似ているが、Chromeは、この格上げが失敗したとき（たとえば、サイトが無効な証明書を出した、またはHTTPの404を返した）を見つけ、自動でhttp://に戻る）と続ける。この告知は2023年のもので、いまの挙動は、この記事では確かめていない。ブラウザの動きに頼る前に、サーバーの値を、台帳に書いておく。HTTPの入口を調べる記事は、「Chrome 154は、HTTPのページを開く前に既定で確認を出す。最終ページがHTTPSでも、転送の途中がHTTPなら出る ── 自社の入口を1つずつ開いて確認する13項目（2026年10月時点）」にある。

調べる道具

当サイトの🔧 【SEO/UX】WEBサイト総合分析・レポートツール — セキュリティヘッダー（HSTSなど）を診断するは、ページの説明によれば、HTTPS対応とセキュリティヘッダー（HSTS・CSP・X-Frame-Options）を診断できる。値が秒でどう出るかや、includeSubDomainsまで読むかは、説明に書かれていないので、確かめていない。証明書やプロトコルを外から調べるときは、🔧 【セキュリティ】WEBサイトの 外からできるセキュリティ対策監査ツール★ミエルン — 証明書とプロトコルを外から見る（利用には無料の会員登録が必要です）が使える。説明にはSSL/TLSの包括分析とあるが、HSTSを読むかは書かれていないので、確かめていない。

07 当サイトで確かめたこと — 応答は30日で、httpの転送の応答にも同じ見出しが付いていた

当サイトの応答の値

2026年11月7日に、当サイトの応答を外から見ると、strict-transport-security: max-age=2592000だった。30日である。includeSubDomainsとpreloadは、付いていない。筆者は同じ日の11時13分に、当サイトのトップ、解説記事の一覧、存在しないURLの画面（404）の3つのHTTPSの応答と、http://で始まるトップの転送の応答を取った。HTTPSの3つの応答には、どれも同じ見出しが付いていた。

httpの転送の応答にも、同じ見出しが付いていた

http://で始まるトップのURLは、301でhttps://のトップへ転送された。その301の応答にも、同じStrict-Transport-Securityの見出しが付いていた。04章の手順4に書いたとおり、RFC 6797は、HTTPの応答には付けてはならないと書き、受け取るブラウザは無視しなければならないと書く。ブラウザの動きが変わる形ではない、というのが筆者の読みだが、規格の書く形とは違う。直すかどうかは、まだ決めていない。

30日を、出典に並べると

30日は、hstspreload.orgが書く、延ばす段階の3つ目（1か月）と同じ長さである。ただし、その段階の例にはincludeSubDomainsが付いているが、当サイトには付いていない。Mozillaの手引きの最小の値（約6か月）には届かず、事前登録の条件（1年以上）にも届かない。延ばすかどうかも、まだ決めていない。決める前には、05章の9番目（サブドメインの数）と10番目（証明書の更新）を、当サイトでも数える必要がある。まだ数えていない。

確かめていないこと

• 当サイトのドメインの下にある、ほかのホストの応答。見ていない。
• サブドメインの数と、HTTPSの対応状況。数えていない。
• 利用者が、当サイトへ戻ってくる間隔。ログで数えていない。
• 値を延ばしたときの、証明書の更新への影響。

08 このテーマは、ここまで — 転送と証明書から、ブラウザに覚えさせる期間へ

これまでの記事

• HTTPからHTTPSへの転送と、正規のURLの扱いは、「HTTPSは「ごく軽い」順位の信号として始まり、いまの文書は正規URLに選ぶ条件を書く ── http→httpsの転送で確かめる13項目（2026年10月時点）」で書いた。
• 転送の途中がHTTPのときの、Chromeの確認は、「Chrome 154は、HTTPのページを開く前に既定で確認を出す。最終ページがHTTPSでも、転送の途中がHTTPなら出る ── 自社の入口を1つずつ開いて確認する13項目（2026年10月時点）」で書いた。
• 証明書の更新の日数は、「Let's Encryptの証明書は2027年2月10日から標準で64日になる ── 更新の設定の「日数の決め打ち」とARI対応を確かめる13項目（2026年10月時点）」で書いた。
• 証明書の鍵の種類と、受け付けるTLSの版は、「Cloudflareは、Keyless SSLのECDSA証明書でTLS 1.3に対応した。RSA証明書の接続はTLS 1.2までのまま ── 担当サイトの証明書の鍵の種類と受け付けるTLSの版を外から確かめる13項目（2026年11月時点）」で書いた。
• 信頼する証明書の経路の確認は、「認証局eMudhraの中間証明書8枚の秘密鍵が漏れた。テスト用サイトによればブラウザは遮断済みで、残るのはブラウザの外の通信 ── 自社と担当サイトの信頼の経路を確かめる13項目（2026年10月時点）」で書いた。

今回の記事の位置

これまでの記事は、証明書そのものと、HTTPSへの転送を扱った。今回は、HTTPSを使うと、ブラウザに覚えさせる期間を扱った。転送や証明書は、サーバーの側で見える。覚えさせる期間は、利用者のブラウザの中に残るので、値を変えた日と、前の値が、記録に無いと、あとから追えない、というのが筆者の読みである。

2026年11月7日 — この記事の確認日

hstspreload.orgの事前登録の条件（1年以上、includeSubDomains、preload）と、延ばす段階（300秒、604800秒、2592000秒）は、2026年11月7日に開いた内容である。この日以降に条件が変わった場合は、05章の12番目の項目で、書き写した条件を、もう一度比べる。当サイトの値は、2026年11月7日の応答の値で、延ばした場合は、この章に日付つきで書き足す。当サイトのサーバーからつなぐ通信と、漏れた証明書の記録は、ブログの「認証局の中間証明書8枚の秘密鍵が漏れた週、当サイトのサーバーの中からつなぐ通信は、漏れた証明書を通していた ── AIの知らせを自分で測り直して、塞いだ記録」に書いた。