複数の対外向けWebサービスをオンプレとクラウドに分散運用し、TLS証明書（Webサイトの通信を暗号化し、運営者の実在性を保証する電子証明書）の更新を情シス担当が手作業で管理している、従業員数千人規模企業の担当者は、この数年で運用サイクルの前提そのものが崩れることになる。業界団体CA/Browser Forum（主要な認証局とブラウザベンダーで構成され、証明書発行のルールを定める団体）が2025年4月に可決した新ルールにより、証明書の最長有効期間は、2026年3月15日に398日から200日へすでに短縮されており、2027年3月に100日、2029年3月には47日になる[1][2]。同じ時期にAWS Certificate Manager（ACM、AWSの証明書管理サービス）は2026年7月、証明書の発行・更新を自動化する標準プロトコルACMEへの対応を発表した[3][4]。年1回や四半期ごとの手動更新運用では、有効期間47日の証明書には追いつけない。本稿では有効期間短縮のスケジュールとACM ACME対応の中身を踏まえ、情シスが自動化整備をいつまでに終えるべきかを整理する。
予備知識
- TLS証明書: Webサイトの通信を暗号化し、運営者の実在性を保証する電子証明書。有効期限があり、切れるとブラウザ警告やアクセス不能につながる。
- ACME: Automated Certificate Management Environment。証明書の発行・更新・失効をAPI経由で自動化する標準プロトコル（RFC 8555）。Let’s Encryptが普及させた。
- CA/Browser Forum: 認証局とブラウザベンダーで構成される業界団体。証明書発行ルール（Baseline Requirements）を策定・改定する。
- DCV（ドメイン検証）: 証明書申請者がそのドメインを実際に管理していることを確認する手続き。一度検証した結果は一定期間、再検証なしで使い回せる。
証明書の発行・検証・失効の仕組みを一通り体系立てて理解したい担当者向けの基礎書
証明書の有効期間はなぜ47日まで縮むのか
CA/Browser Forumは2025年4月、証明書の最長有効期間とDCV再利用期間を段階的に短縮するBallot SC-081v3を、賛成29・反対0で可決した[1][2]。適用は3段階に分かれる。
| 適用期間 | 証明書の最長有効期間 | DCV再利用期間 |
|---|---|---|
| 〜2026年3月14日 | 398日 | 398日 |
| 2026年3月15日〜2027年3月14日（現行） | 200日 | 200日 |
| 2027年3月15日〜2029年3月14日 | 100日 | 100日 |
| 2029年3月15日〜 | 47日 | 10日 |
短縮の狙いは、秘密鍵が漏えいした場合の悪用可能期間を縮めることと、失効済みドメイン情報や古い所有者情報が証明書に残り続けるリスクを減らすことにある[1][2]。398日から47日への移行は一度に起きるのではなく、2026年3月・2027年3月・2029年3月の3回の刻み目を経る。最初の刻み目はすでに過ぎており、手動運用の企業は200日サイクルでの更新頻度増加をいま体感している段階にある。次の刻み目は2027年3月15日の100日化だ。
証明書を軸にした認証基盤刷新を、日本企業の導入プロセスに即して解説しており本稿の移行計画と接続しやすい
ACM ACME対応で何が変わるのか
AWSは2026年7月、ACMにACMEv2互換のサーバーエンドポイント機能を追加したと発表した[3][4]。PKI管理者はACM上にACMEエンドポイントを作成し、Certbot、Kubernetes向けcert-manager、acme.shなど既存のACMEv2対応クライアントから証明書を要求できるようになった[3][4]。このエンドポイントが発行する証明書はAmazon Trust Servicesが発行元となり、有効期間は45日に固定される[5]。標準的なACM証明書の198日と比べても大幅に短い[6]。
ガバナンス機能も備える。発行できるドメイン範囲の制限、ワイルドカード証明書利用可否の設定、DNS認証情報を配布せずにアプリケーションチームへ発行権限だけを委譲する仕組みが用意されている[3][4]。発行・更新の履歴はAWS CloudTrailに記録され、Amazon CloudWatchでメトリクスとして監視できる[3]。全ての商用AWSリージョンで利用可能[3]。既存のACMEクライアント資産をそのまま転用できる点が、独自スクリプトでの自動化より導入障壁を下げている。
社内向けのDNS運用は、長らくVPN専用機器やActive Directory統合DNSサーバーなど、パブリックDNSとは別建ての基盤で行われてきた。ネットワーク・インフラ運用チームにとって、この二重構成は監査ログの分断や設定ドリフトの温[…]
手動更新運用はどこで限界を迎えるか
47日運用になると、単純計算で年8回以上の更新作業が発生する。稟議や承認を経る手動フローでこの頻度をこなすのは現実的ではない。
| 項目 | 手動更新運用 | ACME自動更新 |
|---|---|---|
| 更新サイクル | 年1回〜四半期 | 有効期間の途中で自動実行（日次〜週次でチェック） |
| 作業内容 | 申請書作成・承認・発行・設置を都度手作業 | クライアントがAPI経由で発行から設置まで完結 |
| 47日運用時の年間作業回数 | 8回以上（現実的でない） | 無人で継続、人手は監視のみ |
| 失敗時の猶予 | 数週間〜数カ月単位で気づける | 数日で検知しないと失効に直結 |
自動更新に切り替えると、更新作業そのものは消えるが、新しい課題として「更新失敗の早期検知」が浮上する。45〜47日サイクルでは、更新失敗を放置した場合の猶予が短く、これまでのような月単位の余裕はない。監視の仕組みを持たないまま自動化だけを導入すると、サイレント障害のリスクがむしろ増える。
数百人規模で自社LLM基盤や生成AIサービスをAWS上に構築し、年次予算策定サイクルを持つ企業のインフラ担当・調達担当が対象になる。GPUインスタンスを一定期間確保できるCapacity Block（GPUインスタンスを予約購入できるAW[…]
移行までに情シスが整備すべきこと
200日化はすでに適用済みで、次は2027年3月の100日化、その次が2029年3月の47日化という順になる。47日到達を待たずに準備を進めるのが現実的で、次の刻み目である2027年3月までに自動化のPoCを完了させておく設計が望ましい。
棚卸で明確にすべきは、証明書の枚数・設置先・現在の更新担当者の3点。次にACMEクライアント（Certbot/cert-manager/acme.sh）を用途別に選定し、非本番環境でPoCを行う。DNS認証情報を各チームに配らずに発行権限だけを委譲する設計と、更新失敗を数日以内に検知するアラート整備まで含めて「移行完了」とする必要がある。
SIer保守契約下でのACME移行、判断は誰が持つか
米国のクラウドネイティブ企業であれば、自動化はエンジニアの裁量で数週間のうちに導入できる。日本企業では同じ移行にもう一段階の調整が必要になる場合が多い。
| 観点 | 米国先行企業に多い型 | 日本企業に多い型 |
|---|---|---|
| 運用体制 | 自社エンジニアが直接実装 | SIerとの保守契約範囲内で運用、契約外の変更は追加交渉が必要 |
| 変更の承認 | チーム内の裁量で先行導入 | 変更管理委員会の承認、稟議を経て本番反映 |
| 統制要件 | 監視ログの整備が中心 | 監査・内部統制（J-SOX等）向けに権限委譲の証跡設計が必須 |
| 移行の起点 | 課題認識から即着手 | 保守契約更新のタイミングに合わせやすい |
保守契約がACMEクライアント運用や監視追加を明示的にカバーしていない場合、契約変更や追加見積もりの調整が先に必要になる。証明書発行権限をアプリケーションチームへ委譲する設計は、監査上「誰が何をいつ発行したか」を追跡できる形で記録することが前提になる。IT部門の判断としては、次の刻み目である2027年3月の100日化を目安にPoCを開始し、保守契約側の対応可否を先に確認しておくべきだ。決裁側は、契約変更コストと自動化を先送りした場合の運用負荷増大リスクを比較し、次の保守契約更新時期を待たずに予算を確保するかを判断材料にするとよい。
まとめ
情シス担当者の次の一手は、証明書の棚卸とACMEクライアントのPoCに着手することだ。200日化はすでに適用済みで、次の刻み目である2027年3月の100日化が実質的な期限になる。決裁側の判断材料は、SIer保守契約の対応範囲確認と自動化導入コストを、47日到達を待たずに検討することにある。証明書の有効期間短縮は一度きりのイベントではなく2029年3月まで続く既定路線であり、対応を先送りするほど後の刻み目で作業が集中する。
よくある質問（FAQ）
Q1. 証明書の有効期間はいつから47日になりますか。
2029年3月15日から適用される。2026年3月15日に200日、2027年3月15日に100日と段階的に短縮される[1][2]。
Q2. ACM ACMEは既存のCertbotやcert-managerでそのまま使えますか。
ACMEv2互換クライアントであれば利用できる。AWSはCertbot、Kubernetes向けcert-manager、acme.shでの動作対応を案内している[3][4]。
Q3. 手動更新のままではいけませんか。
47日運用では年8回以上の手作業が必要になる計算で、稟議を伴うフローでは追いつかない。早期に自動化を検証しておくことが望ましい。
