運用の年間スケジュールを1枚に｜証明書・EOL・契約更新の期限管理
サーバーの証明書が切れかけていることに気づいたのは、期限の3日前でした。
通知メールは届いていた。ただ、その宛先は2年前に辞めた前任者のアドレスを含む共有メールで、日々の問い合わせに埋もれていた。慌てて購入の稟議を回そうとして、承認者が出張中だと知る——。
こういう「間に合ったけれど、たまたま間に合っただけ」の経験は、一人で運用を持っていると一度はあると思います。日次・週次の作業はチェックリストにできているのに、年に1回しか来ないものだけが、いつも記憶頼みになる。
結論：年間スケジュールは「作業の予定表」ではなく、「期限を持つものの一覧」として作ります。作るときのコツは2つだけ。①切れるものを全部1か所に並べる、②各行に「期限日」だけでなく「予告日」も書く。期限日だけの一覧は、思い出したときにはもう遅い、が起きます。時間がなければ、今日は思い出せる期限を5つ書き出すだけで十分です。
先に言っておくと、これは管理を増やす話ではありません。すでにあなたの頭の中にある管理を、頭の外に出す作業です。中身は増えません。置き場所が変わるだけです。
何が起きているか：年1回の予定だけが、どうしても仕組みに乗らない
日次・週次・月次の作業は、定期作業の手順化で1枚にまとめられます。ところが、期限ものだけは同じやり方でうまくいきません。理由はだいたい次の5つです。
- 情報が最初からバラバラの場所にある。証明書の期限は認証局からのメール、ドメインはレジストラの管理画面、保守契約は総務の契約フォルダ、ライセンスは請求書のPDF。ひとつの台帳から生まれた情報ではないので、集めない限り集まりません。
- 通知が本人に届かない構造になりがち。登録アドレスが前任者、あるいは共有メール。通知は「出ている」のに「読まれない」という、いちばん惜しい形で失われます。
- 頻度が不揃いで、定期作業の枠に入らない。年1回、3年に1回、契約更新月だけ、EOLの年。周期が違うものを同じチェックリストに混ぜると、毎回ほとんどの行が「今回は対象外」になり、見なくなります。
- 年1回の記憶は、そもそも残らない。前回やったのは1年前で、そのときの手順も判断も、細部はもう思い出せません。忘れているのは注意力の問題ではなく、間隔の問題です。
- 一人だと、知っているのが自分だけになる。休んだ日、体調を崩した週に期限が来ると、代わりに気づける人がいません。これは属人化というより、単に共有先がまだ作られていない状態です（→属人化しやすい知識を共有し始める方法）。
そしてもうひとつ、最近になって効いてきた事情があります。証明書の有効期間の上限が、段階的に短くなる方向で動いていることです。CA/Browser Forum（ブラウザと認証局が要件を決めている業界団体）では、TLSサーバー証明書の最長有効期間を数年かけて短くしていく方針が決まっており、2026年時点ですでに「1年に1回」では収まらない運用になっています。今後さらに短くなる予定もあるため、正確な上限は、利用中の認証局の案内で確認するのが確実です。
つまり、「毎年この時期にやること」という覚え方自体が、だんだん通用しなくなっている。だからこそ、記憶ではなく1枚に置く価値が上がっています。
1枚に何を書くか：期限日の手前に「予告日」を置く
まず、1行に何を持たせるかを決めます。期限日だけを並べた一覧は、意外と役に立ちません。気づいたときには、もう動ける時間が残っていないからです。
1行に入れるのは、次の5つです。
- 対象：何の期限か（「本番サイトのSSL証明書」など、あとで見て分かる名前）
- 期限日：切れる日・更新が必要な日
- 予告日：期限から逆算して、動き出す日
- 着手日：実際に作業する日（予告日と同じでも構いません）
- 確認先：どこを見れば現在の期限が分かるか（管理画面のURL、契約書の置き場、担当のベンダー名）
このうちいちばん大事なのは、3の予告日です。そして5の確認先は、未来の自分と後任のために効きます。期限だけ書いてあって「どこで更新するのか分からない」一覧は、結局また探し直しになるので。
予告日は「作業時間」ではなく「待たされる時間」で決める
逆算の幅を決めるとき、つい作業そのものの所要時間で考えてしまいがちです。でも実務で時間を食うのは、作業ではありません。承認、購入、ベンダーの返信、検証——自分では短くできない待ち時間のほうです。
目安として、こんな取り方をしています。
- 証明書（SSL/TLS・コードサイニングなど）：反映作業自体は短くても、社内の購入承認、発行、反映後の確認まで含めて期限の1〜2か月前。有効期間が短い証明書は、そもそも自動更新に寄せられないかを先に検討します。
- ドメイン：失効すると影響が大きく、復旧に手間と費用がかかることがあるため、期限の2〜3か月前。あわせて登録者情報と支払い方法が古くなっていないかも見ます。クレジットカードの有効期限切れで自動更新に失敗するのは、実際によくある入口です。
- 保守契約・SaaSの年間プラン：自動更新の場合、解約や条件変更を申し出られる期限のほうが実質の締め切りになります。契約書に「更新の◯か月前まで」と書かれていたら、そこから逆算して3か月前あたり。
- EOL（サポート終了）：移行の計画・検証・切り替えが必要なので、半年〜1年前。EOL棚卸しの結果を、そのままこの一覧に流し込めます。
- 決められた点検（バックアップのリストア試験、権限の棚卸し、脆弱性チェック）：期限というより実施予定なので、やる月を決めておくだけで十分です。
迷ったら長めに取って構いません。 予告が早すぎて困ることは、ほとんどありません。
期限を持つものを洗い出す：4つの引き出しから拾う
「全部書き出そう」と思うと手が止まるので、探す場所を4つに分けて拾っていきます。順番に開けていくだけで、だいたい出てきます。
① 切れると止まるもの
まずここから。止まったときの影響がいちばん大きい列です。
- SSL/TLS証明書（本番・検証・社内システム・管理画面）
- ドメイン名の登録期限
- コードサイニング証明書、電子証明書、各種クライアント証明書
- 外部サービスのAPIキー・トークンで有効期限があるもの（→外部API連携の切り分け）
- クラウド・SaaSの支払い方法（カードの有効期限）
② 切れてもすぐは止まらないが、後から効くもの
止まらないぶん、後回しになりやすい列です。
- OS・ミドルウェア・言語のEOL（→PHPバージョンアップのリスクと手順）
- フレームワーク・ライブラリのサポート終了
- 有償ライセンス（監視ツール、バックアップソフト、開発ツール）
- ハードウェア・機器の保守期限
③ 契約とお金
自分の担当範囲の外にあることが多く、いちばん抜けやすい列です。
- サーバー・回線・データセンターの契約更新
- 保守契約、SLA付きのサポート契約
- SaaSの年間プラン、レンタル機器
- ベンダーとの委託契約
この列は、一人で埋めなくて大丈夫です。 総務や経理に「システム関連で年1回支払いが発生しているものを教えてください」と聞くほうが、はるかに早く正確です。請求のタイミングは、たいてい経理のほうがよく知っています。
④ 決められてやるもの
期限というより「やると決めた予定」です。
- バックアップのリストア試験
- アカウント・権限の棚卸し（→権限の棚卸しと最小化）
- 脆弱性チェック、パッチ適用の定例
- ドキュメントの見直し（→運用ドキュメントを腐らせない更新ルール）
- 連休前チェック（→連休前にやる運用チェック）
思い出せないときの、拾い方のコツ
記憶をたどっても出てこないものは、痕跡から拾います。
- メールを「更新」「期限」「請求」で検索する。年1回の通知は、去年のメールに残っています。
- カード明細・請求書を1年分ながめる。年額課金は、そのまま期限ものの一覧です。
- ドメイン・DNSの管理画面を開く。ドメインと証明書は、だいたいここで期限が見えます。
- サーバーの中を見る。証明書ファイルの有効期限、cronで動いている更新スクリプト（→cron・バッチの失敗検知）。
- 構成一覧と引き継ぎ資料を突き合わせる。すでに書いてあるものは、そこから写すだけで済みます。
1回で完成させなくて大丈夫です。 この一覧は、思い出すたびに1行足していくものとして持っておくほうが長続きします。
予告を、自分の記憶の外に置く
1枚できたら、最後にひとつだけ。予告日を、自分が見に行かなくても目に入る場所に移します。ここをやらないと、「1枚は作ったけれど、その1枚を見るのを忘れる」という形で、また同じところに戻ってしまいます。
置き方は、手の届くものから選べば十分です。
- カレンダーに終日予定として入れる。予告日と期限日の両方を入れて、タイトルの頭に「【期限】」と付けておくと目に留まりやすくなります。
- 可能なものは監視に載せる。証明書の期限は、有効期限の監視として仕組みで見張れます。人が覚えなくていいものは、人から外すのが基本です。
- 通知の宛先を、いま届く場所に直す。これは地味ですが効果が大きい作業です。前任者のアドレスや、誰も見ていない共有メールが宛先のままになっていないかを、この機会に確認しておきます。
- 月初の作業に「今月と来月の期限を見る」を1行足す。月次報告を作るタイミングと一緒にすると、忘れにくくなります。
カレンダーと監視、どちらか片方だけでも構いません。 大事なのは、気づく役目を、記憶以外の何かにも持たせておくことです。
具体例：ある一人運用の、1枚ができるまで
社内の業務システムと公開サイトを、ひとりで見ている担当の方の例です。作業は3日に分けて、合計90分ほどでした。
1日目（30分）。ノートを開いて、思い出せる期限をとにかく書き出します。出てきたのは6つ。公開サイトの証明書、ドメイン、サーバーの契約更新、監視ツールのライセンス、バックアップのリストア試験、そして「たしか何か秋に更新があったはず」という曖昧な1件。
完璧を目指さず、曖昧な1件も「不明」のまま行に残しました。 ここが後で効きます。
2日目（30分）。メールを「更新」「請求」で検索します。曖昧だった1件の正体が分かりました。社内システムの管理画面で使っている、社内向けの証明書でした。あわせて、想定していなかったものも2つ出てきます。バックアップ保管に使っているクラウドストレージの年額課金と、PDF生成に使っている有償ライブラリのライセンス。
書き出す前は6件のつもりが、実際は9件ありました。 増えたことに落ち込む必要はなくて、これは「知らないうちに管理していたもの」が見えたということです。
3日目（30分）。9行を1枚に並べ、それぞれに予告日を入れます。ここで気づいたことが2つありました。
ひとつ目。サーバーの契約更新が、自動更新で、解約や変更の申し出は3か月前までという条件でした。契約更新日を締め切りだと思っていたけれど、実質の締め切りは3か月手前だった。
ふたつ目。社内向け証明書の通知の宛先が、退職した前任者のアドレスのままだった。届いていたはずの通知は、誰にも読まれていませんでした。
この2つは、期限を一覧にしなければ気づけなかった部類です。作業自体は写すだけでしたが、出てきたのは写した内容ではなく、並べたことで見えたズレでした。
最後に、9行の予告日をカレンダーに終日予定で入れ、証明書2件は監視の対象に追加。1枚は、更新のたびに日付を書き換える運用にしました。
数か月後、この方はこう言っていました。「期限が近いことに気づいて焦る、という日がなくなった」。減ったのは作業ではなく、気づいていないかもしれない、という不安のほうだったそうです。
影響：1枚あると、何が変わるか
- 「たまたま間に合う」が減る。予告日が先に立っているので、承認や購入で待たされても手が残ります。間に合わせる力ではなく、間に合う時間を確保する話です。
- 休みが取りやすくなる。期限が自分の頭の外にあると、休んだ日に何かが切れる心配が減ります。連休前のチェックも、この1枚を見るだけで大半が済みます。
- 抜けていたものが見つかる。実際、書き出すとだいたい想定より数が増えます。増えたぶんは、これまで運任せだった部分です。
- 引き継ぎがそのまま済む。この1枚は、引き継ぎ資料にほぼそのまま入ります。引き継ぐときに作るのではなく、日々使っているものを渡せるのがいちばん楽です。
- 上司や経営に説明しやすくなる。「来期このタイミングで、この費用と作業が発生します」が1枚で示せます。予算とリソースの相談は、期限の一覧があるとぐっと通りやすくなります（→技術的負債の可視化と優先順位づけ）。
- 判断が減る。予告日が来たら動く、と決まっているので、「そろそろやるべきか」を毎回考えなくて済みます。考えなくていいことを減らせるのは、一人運用ではかなり大きいです。
時間でも見ておきます。期限ものが年に10件あるとして、そのうち3件が「気づくのが遅れて慌てる」形になっていたとします。慌てた1件で、確認・調整・急ぎの承認に1件あたり2時間の余計な時間がかかっていたなら、年6時間。1枚を作る初期コストが90分、維持が月10分（年2時間）としても、差し引きで年2.5時間ほど手元に戻る計算です。
正直、劇的な数字ではありません。ただ、その6時間は「焦りながら使う6時間」なので、消耗の度合いが違います。戻ってくるのは時間そのものより、落ち着いて考えられる状態のほうだと思います。
明日やること：思い出せる期限を5つ書くだけ
準備は要りません。明日30分でできる形にしておきます。
- メモでも表計算でも、1枚開く。列は「対象／期限日／予告日／確認先」の4つで十分です。
- 思い出せる期限を5つ書く。証明書、ドメイン、契約、ライセンス、点検。日付が分からない行は「不明」でそのまま残します。
- そのうち1件だけ、正確な期限を確認する。管理画面を開くか、請求メールを検索するか。1件で構いません。
- その1件に予告日を入れて、カレンダーに終日予定で登録する。ここまでで、もう仕組みが1本動き出しています。
- 余裕があれば、その1件の通知の宛先が、いま自分に届く場所になっているかを見ておきます。
1〜4は、30分あれば終わります。 5件全部を正確にする必要はありません。1件でも記憶の外に出れば、その1件はもう自分で見張らなくてよくなります。
すでに期限が迫っているものがあるなら、それを1件目にしてください。目の前の1件を片付けながら、そのまま1行目になります。
「運用の年間スケジュール」チェックリスト
コピーして、手元の1枚と突き合わせてみてください。全部そろえる必要はありません。
まず外せない最低ラインは、この3つです。
- 【最低ライン】証明書とドメインの期限が、記憶ではなく1枚に書いてあるか
- 【最低ライン】各行に、期限日だけでなく予告日が入っているか
- 【最低ライン】予告が、自分の記憶以外の場所（カレンダー・監視など）にも置いてあるか
次の項目は、余裕があるとき・より確実にしたいときに確認します。当てはまらないものは飛ばして大丈夫です。
- 各行に「どこを見れば現在の期限が分かるか」が書いてあるか
- 通知メールの宛先が、いま自分に届く場所になっているか（前任者・不使用の共有アドレスのままでないか）
- 自動更新のものについて、申し出の締め切りが期限日として書かれているか（更新日そのものではなく）
- クラウド・SaaSの支払い方法（カードの有効期限）を確認したか
- OS・ミドル・ライブラリのEOLが、この1枚に入っているか
- 経理・総務に、年1回支払いが発生しているものを確認したか
- 有償ライセンス（監視・バックアップ・開発ツール）を拾ったか
- リストア試験・権限棚卸しなど、やると決めた点検の実施月が入っているか
- 更新作業をしたあと、次回の期限に書き換える手順になっているか
- この1枚の置き場所が、自分以外にも分かる場所になっているか
- 証明書など、仕組みで見張れるものを人の記憶から外せていないかを検討したか
- 月初や月次報告のタイミングで、この1枚を見るきっかけが作られているか
全部に○が付かなくても大丈夫です。最低ラインの3つ、とくに「予告日」さえ入っていれば、慌てる場面はかなり減ります。
よければ、こちらも
1枚ができたら、そこに載る個別の作業を深掘りしていくと形になります。
- 定期作業を手順化する｜日次・週次・月次を1枚のチェックリストに：年1回ではなく、日々の作業を1枚にまとめる側の話です。
- SSL証明書の期限切れを防ぐ｜更新と監視で慌てない仕組み：この一覧でいちばん最初に載る項目の、具体的な手順です。
- EOL棚卸しの手順｜サポート切れのOS・ミドルを一人で洗い出す：EOLの行を埋めるときは、こちらから拾えます。
- 引き継ぎ資料に必ず入れる「アカウント・連絡先・契約」一覧テンプレート：契約と連絡先を、そのまま一覧にする形です。
- 連休前にやる運用チェック｜一人運用でも安心して休むための準備：休む前に、この1枚をどう使うかの話です。
期限を全部覚えていられたのは、すごいことだと思います。ただ、それを覚え続けなければならない状態そのものが、静かに体力を使います。
年間スケジュールを1枚にするのは、管理を厳しくするためではありません。覚えておく仕事を、紙とカレンダーに肩代わりしてもらうためです。忘れてもいい状態を作るほうが、結果的に抜けが減ります。
明日は、5行でも3行でも構いません。思い出せる期限を、ひとつ書き出すところからで十分です。書いた瞬間から、その1件はもう、あなたひとりが見張らなくてよくなります。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。