Let’s Encrypt は、2026年3月17日に ACME Renewal Information（ARI）の導入事例として、 Shopify の更新運用を紹介しました。 固定的な「残り30日で更新する」方式ではなく、 認証局が返す推奨更新ウィンドウに従うことで、 大量証明書の更新をより安定して回しやすくなる、という内容です。
※本記事は公開情報をもとに整理した内容です。記事内容に関する個別のお問い合わせにはお答えいたしかねますので、正確な内容や最新情報は必ず公式ソースもあわせてご確認ください。
要点
- Shopify は固定の更新閾値ではなく、ARI が返す推奨期間を使う方式へ移行しました。
- これにより、失効対応、短期証明書化、更新集中の緩和に備えやすくなると説明されています。
- Ruby の
acme-clientへ ARI 対応を追加し、その成果を広く使える形で公開しています。
日本語要約
記事によると、Shopify では従来、 90日証明書に対して「有効期限の30日前になったら更新対象にする」という固定ルールを使っていました。 更新の偏りを減らすために 0 から 72 時間のランダム遅延も入れていたものの、 その方法では認証局側の都合や失効時の緊急更新までは吸収しにくかったとされています。
そこで ARI を利用し、
認証局が返す suggestedWindow を見て更新タイミングを決める方式へ切り替えました。
クライアントは固定日数ではなく、CA が提示する更新期間を基準に動くため、
証明書寿命の短縮や失効イベントが起きても、硬直した閾値に縛られにくくなります。
運用上の見どころ
この記事の重要な点は、 ARI が単なる「便利なヒント」ではなく、 大量証明書を抱える環境での更新時刻の基準そのものになっていることです。 Shopify は ARI 情報を定期的に再取得し、 その時点の推奨期間を一次情報として扱うことで、 将来の 45 日証明書移行や、失効対応時の前倒し更新にも備えやすくしたと説明しています。
あわせて、Let’s Encrypt は既存の ARI 統合ガイドも案内しています。
ACME クライアント実装側では、
`renewalInfo` エンドポイントの検出、
推奨期間の取得、
期間内での更新時刻選定、
更新対象証明書を示す replaces の送信といった流れが重要になります。
このページ向けの読み替え
ACME 証明書の運用では、 「残り何日前で更新するか」を固定値で持つ設計は分かりやすい反面、 証明書寿命の変更や認証局都合の更新誘導に追随しづらくなります。 今後の短期証明書化を見据えると、 ARI に対応したクライアントや監視設計を前提にしておく意義はさらに大きくなりそうです。
既に ARI 対応クライアントを使っている場合、 更新が「まだ時期ではない」と判定される場面が増えても、 それは異常ではなく CA の推奨タイミングに従った自然な挙動である可能性があります。