## この記事でわかること

- CA/Browser Forum の議決（SC-081v3）で確定した SSL 証明書の有効期間短縮（47 日化）スケジュール
- 47 日化が現実になったときに Web 担当者が直面する 3 つの実務リスク
- 期限切れを起こさないために今のうちに整えておくべき 2 つの備え
- ドメイン番人の SSL 機能（SSL 番人）で何が自動化できるか

## SSL 証明書はなぜ短くなり続けているのか

公開 SSL 証明書の有効期間は、過去 10 年で段階的に短くなってきました。かつて 5 年だった上限は、3 年、2 年、1 年と縮められ、2020 年からは主要ブラウザが**最大 398 日**の証明書しか受け入れなくなっています。

この流れを決めているのは、CA/Browser Forum という、認証局（CA）と主要ブラウザベンダーが集まる業界団体です。短くする目的は大きく次の 3 つです。

1. **鍵の流出が起きたときの被害期間を短くする**: 古い鍵がいつまでも有効だと、漏れたときに悪用される時間が長くなる
2. **失効情報のずれを減らす**: 失効リスト（CRL / OCSP）の伝搬は完全ではない。短ければ放置リスクが減る
3. **自動更新運用への移行を強制する**: 手動更新が前提のサイトは、短期化されるほど現実的に運用できなくなる

この段階的な短縮ロードマップは 2025 年 4 月の議決（SC-081v3）で確定しており、最終地点が「**有効期間 47 日**」（2029 年 3 月 15 日から）です。年に 1 回どころか、ほぼ毎月の更新サイクルが標準になります。

![47日化までの段階的短縮の流れ](/blog/47-day-problem-ssl/timeline.svg)

## 47 日化が現実になったときの 3 つの実務リスク

「自動更新ツールを使っているから関係ない」と思うかもしれません。しかし実務的には次の 3 つで足を取られる中小企業・制作会社が増えると見ています。

### リスク 1: 監視の頻度が今のままだと間に合わない

期限の 30 日前にアラートを出す運用は、有効期間 398 日のときは余裕があります。47 日になると、30 日前は **発行直後** に当たります。「期限が近い」アラートが鳴り続ける状態になり、本当に切れそうなものを見落としやすくなります。

### リスク 2: 更新失敗時のリカバリ時間が短い

Let's Encrypt のように完全自動化された運用でも、DNS-01 認証の TXT レコード書き換え失敗、API レートリミット、CA 側の障害などで更新が止まることがあります。有効期間 47 日のうち最後の 1 週間で失敗すると、リカバリの猶予は実質 数日 しかありません。

### リスク 3: 手動運用が完全に破綻する

年 1 回ですら忘れる現場で、月 1 回の手動更新は現実的に回りません。Web 制作会社が顧客サイトを複数抱えていれば、件数 × 12 倍の作業発生になります。

![短期化で起きる運用負荷の変化](/blog/47-day-problem-ssl/operational-shift.svg)

## 今のうちに整えておくべき 2 つの備え

47 日化のスケジュールは議決 SC-081v3 で確定しており（200 日: 2026 年 3 月 15 日〜施行済み / 100 日: 2027 年 3 月 15 日 / 47 日: 2029 年 3 月 15 日）、最初の節目である 200 日ルールはすでに施行されています。詳細は [SSL 200日ルール（2026）を中小企業向けに解説](/blog/ssl-200-day-rule-2026) でまとめています。今から準備しておくべきは大きく次の 2 つです。

### 備え 1: 自動更新の仕組みを「全サイト」で揃える

「自社サイトだけ」「メインドメインだけ」自動化していて、サブドメインやキャンペーン用ドメインは手動、というケースが意外と多いものです。

- 自社の管理下にある **すべての公開ドメイン** を洗い出し
- それぞれが Let's Encrypt / ACME 対応の CA で自動更新できるかを確認
- 自動更新が難しいサイト（古いサーバ、レガシー機器）は移行計画を立てる

詳細な手順は [SSL 証明書の自動更新を整えるための実務手順](/blog/ssl-renewal-automation) にまとめています。

### 備え 2: 期限監視と「更新後の正常性チェック」を分ける

更新が走ったかどうかと、**更新後に正しく配信されているか** は別の問題です。証明書ファイルは更新されたのに、ロードバランサや CDN への配布が漏れて旧証明書のまま、というのは珍しくありません。

最低限、次の 3 つを別々に監視しておきます。

- 期限までの残日数（出発点）
- 実際にブラウザから見える証明書の更新有無（コンテンツとの整合）
- HTTPS の応答ステータス（5xx / 4xx の急増）

加えて「自社ドメインで本当にその証明書を自分が発行したか」を [CT log](/blog/ct-log-basics-smb)（Certificate Transparency log）で逆チェックしておくと、47 日化で更新頻度が上がった結果として **不正発行を見逃す** リスクを抑えられます。比較は [CT log 監視ツール 5 選比較](/blog/ct-log-monitoring-tools-guide) を参照。あわせて [DNS CAA レコードの設定](/blog/dns-caa-record-smb-setup) で証明書を発行できる認証局を自社が許可したものだけに限定しておくと、不正発行のリスク自体を下げられます。

![期限監視と正常性監視の役割分担](/blog/47-day-problem-ssl/two-axis-monitoring.svg)

## ドメイン番人の SSL 機能で何が自動化できるか

ドメイン番人の SSL 機能（SSL 番人）は、上で挙げた備えのうち **「期限監視」と「更新後の正常性チェック」** を、Web 担当者が個別に組まずに使える形で提供しています。

- 監視対象ドメインに対して、CT log と HTTPS 応答の両面から証明書状態を継続チェック
- 期限が近づくとメール通知（30 日 / 14 日 / 7 日 / 1 日のステップ通知）
- 更新後の証明書 SAN / 発行 CA / 有効期間を自動的に記録、想定外の変更があれば検知
- /diagnose の SSL カテゴリと連携し、ワンクリックで現状を確認できる

詳細は [/ssl/](/ssl/) のサービスページにまとめています。47 日化に備えるための一次資料として、まず無料の [/diagnose](/diagnose) で現状を可視化することをおすすめします。

## よくある質問

### 47 日化はいつからですか？

CA/Browser Forum の議決 SC-081v3（2025 年 4 月可決）で、証明書の最大有効期間は 2026 年 3 月 15 日に 200 日（施行済み）、2027 年 3 月 15 日に 100 日、2029 年 3 月 15 日に 47 日へと段階的に短縮されることが確定しています。発行元によって前倒し対応の場合があるため、運用上の正確な適用日は主要 CA の最新案内もご確認ください。

### Let's Encrypt の自動更新を入れていれば 47 日化されても問題ないですか？

ほぼ問題ありませんが、更新失敗時のリカバリ猶予が短くなることと、ロードバランサや CDN への配布まで届いているかの監視は別軸で必要です。

### 47 日化されても EV / OV 証明書は別の有効期間になりますか？

これまでの短縮は DV/OV/EV 区別なく適用されてきており、SC-081v3 の段階短縮でも同様に種別を問わず適用されます。最新動向は公式発表をご確認ください。

## まとめ

- SSL 証明書の有効期間は短くなり続けており、業界団体の議決（SC-081v3）で最終的に「47 日」（2029 年 3 月 15 日から）まで短縮されることが確定している
- 自動更新が動いていても、監視頻度・リカバリ時間・運用範囲のどれかが追いつかないと現場で詰まる
- 全ドメインの自動更新を揃え、期限監視と正常性監視を分けて持つことが、47 日時代の最低ラインになる
- まずは [/diagnose](/diagnose) で現状を可視化し、必要に応じて [/ssl/](/ssl/) の常時監視に乗せておくと、47 日化が来ても運用が崩れない