想定読者
更新作業を特定の担当者の記憶や過去のメールに頼っている中小企業の経営者・情報システム担当者・総務担当者の方です。
ドメイン、SSL証明書、回線・プロバイダー契約、ネットワーク機器の保守契約の期限を、誰が見ても分かる形で管理したい方に向けて書いています。
要点
- 期限が来ると業務が止まる更新物(ドメイン・証明書・回線・保守契約)を洗い出し、「何を・誰が・いつ確認するか」を1枚の表にまとめる手順がわかります
- 年末年始や期末をまたぐ更新は、通常より早い確認日と代替の連絡先を決めておくことで、休業中の失効を防げます
- 担当者個人のメールやカレンダーに頼らず、共有の通知先と二重の確認役を置くことで、異動・退職があっても回る仕組みを作れます
更新切れで止まるのは「忘れた」からではなく「誰も見ていない」から
更新期限の事故というと「うっかり忘れた」という話にされがちですが、実際には「誰が見る前提だったのか、決まっていなかった」ことが原因の大半です。
契約した人は覚えているつもりでも、異動や退職、組織変更を経ると、期限の情報は誰の手元にも残らなくなります。
この記事では、期限が来ると止まるものだけに絞り、期限・担当・通知の運用を整える方法を解説します。
機器や設定の台帳づくり、使っていない契約の見直し、休業中の遠隔アクセスの備えといった話題は別の記事で扱っているため、ここでは触れる程度にとどめます。
期限が来ると業務が止まる更新物の実例

更新切れの影響は、ネットワーク担当者が普段目にしている範囲を超えて、社内LAN・メール・Web・遠隔接続のすべてに及びます。
代表的なものを見てみましょう。
- ドメインの失効:ドメイン(インターネット上の住所にあたる名前)が失効すると、そのドメインを使ったWebサイトとメールが同時に止まります。たとえば小売業なら、ネットショップが表示されなくなるうえ、取引先からの注文メールが届かなくなります。士業の事務所なら、依頼者からの問い合わせや書類のやり取りが滞ります。失効後の猶予期間や復旧にかかる手数料・日数は事業者によって異なり、復旧するまでメールが届かない状態が続くこともあります。
- SSL証明書の期限切れ:SSL証明書は、Webサイトやメールサーバー、VPN(遠隔接続)の通信が正しい相手につながっていることを示す電子的な証明書です。切れると、お客様のブラウザに「安全ではありません」という警告が出て、サイトを開いてもらえなくなります。社内の予約システムや受発注システムを証明書付きで公開している場合は、業務そのものが止まります。
- 回線・プロバイダー・保守契約の切れ目:回線やプロバイダー契約の更新手続きが漏れると、最悪の場合は接続が止まります。またルーターやUTM(複数のセキュリティ機能をまとめた機器)の保守契約が切れていると、故障したときに交換や問い合わせの対応を受けられず、復旧が大幅に遅れます。製造業で工場と事務所をつなぐ拠点間接続が止まれば、生産指示が届かなくなることもあります。
いずれも「期限当日」に突然止まるのが厄介な点です。前日まで普通に動いているため、気づく機会がありません。
担当者の記憶に頼ると起きる3つの落とし穴

更新管理が属人化している組織では、次のような落とし穴が繰り返し起きます。
- 通知が退職者宛てのまま:ドメインや証明書の更新案内は、登録時の担当者のメールアドレスに届きます。その人が退職して受信箱が閉じられると、案内は誰にも読まれないまま消えます。
- 自動更新のカード期限切れ:自動更新にしていても、支払いに使うクレジットカードの有効期限が切れたり、カードが再発行されたりすると、更新は失敗します。失敗の通知が前述の退職者宛てであれば、気づけません。
- 契約者名義と実際の管理者が違う:契約は以前の担当者の個人名義や、すでに使っていない部署名義になっていて、今の管理者がログインできない、問い合わせしても本人確認で断られる、というケースです。いざという時に手続きができず、復旧が遅れます。
これらはどれも「人」に情報を紐づけていたことが根本原因です。次の章から、人ではなく「一覧」に情報を持たせる方法を見ていきます。
更新物を1枚の一覧にまとめる|何を・誰が・いつ確認するか
対策の中心は、期限のあるものを1枚の表にまとめ、組織として見られる場所に置くことです。ここでは洗い出しの範囲、表の項目、書く内容と書かない内容を順に説明します。
洗い出す対象の範囲と見つけ方

対象は、期限が来ると業務が止まる、あるいは復旧が難しくなるものです。まず次の範囲を確認します。
- ドメイン(自社サイト用、メール用、過去に取得した予備のものを含む)
- SSL証明書(Webサイト、メールサーバー、VPN、社内システムの公開用など)
- インターネット回線と、プロバイダー契約
- ネットワーク機器の保守契約とライセンス(ルーター、UTM、Wi-Fi機器、スイッチなど)
- クラウドサービスやレンタルサーバーの契約
見つけ方のコツは、「システム側」と「お金の側」の両方から探すことです。システム側では、自社サイトやメールの設定を確認して、使っているドメインや証明書を洗い出します。
お金の側では、請求書、クレジットカードの明細、銀行の引き落とし記録を見直すと、担当者が把握していなかった契約が見つかることがあります。
さらに、過去の担当者や取引先の業者に「御社が更新窓口になっているものはありますか」と聞くのも有効です。
一覧に載せる項目と表の作り方
洗い出したものは、次の項目で整理します。
- 更新物(名称)
- 期限
- 確認する人(担当と確認役)
- 確認の頻度
- 更新方法(自動更新か、手動で手続きか)
- 費用の支払い元
次の表は、記入のイメージです。セルは短い語句にしてあります。
| 更新物 | 期限の目安 | 確認する人 | 確認の頻度 | 止まる業務 |
|---|---|---|---|---|
| ドメイン | 年次更新 | 担当+確認役 | 四半期ごと | Web・メール |
| SSL証明書 | 年次または短周期 | 担当+確認役 | 月次 | サイト表示・VPN |
| インターネット回線 | 契約満了時 | 総務+確認役 | 四半期ごと | 全通信 |
| プロバイダー契約 | 契約満了時 | 総務+確認役 | 四半期ごと | 接続・メール |
| ルーター・UTMの保守 | 年次更新 | 担当+確認役 | 四半期ごと | 故障時の復旧 |
| Wi-Fi機器のライセンス | 年次更新 | 担当+確認役 | 四半期ごと | 管理・無線接続 |
期限の目安や頻度は、あくまで書き方の例です。実際の期限は契約書や管理画面で確認して、自社の内容に置き換えてください。
証明書のように期間が短い傾向があるものは、確認の頻度を細かくしておくと安全です。
表の下には、表に入りきらない補足を書くための欄(備考)を用意しておくと便利です。たとえば「更新の手続きは年度末の決裁が必要」「更新の通知は期限の何日前までに出す必要がある」といった注意点を、文章で残しておきます。
なお、Xserverなどの主要なレンタルサーバー会社では、ドメインの更新(利用者側での設定が必要)や、Let’s Encryptによる無料SSL証明書の更新を、自動で行ってくれることが多くあります。
ただし、「自動だから知らなくてよい」わけではありません。自動更新は、支払い用カードの期限切れや設定の変更などで止まることがあり、万が一に備えて、人が内容を把握できる状態にしておく必要があります。
そのため、自動で更新されるものも一覧から外さず、更新内容(ドメインかSSL証明書か)、期限、契約先、支払い方法を記録しておきます。
更新方法の欄には「自動更新」と書き、確認の頻度の欄で、実際に更新されたかを確かめる日を決めておきます。
自動更新のために利用者側の設定が必要なものは、設定済みかどうかも備考に残しておくと、担当者が替わっても迷いません。
名義・ログイン先・支払い方法まで書く理由と、パスワードを書かない運用

更新に困るのは、期限が分からない時だけではありません。「誰の名義で契約しているか」「どこにログインして手続きするか」「何で支払っているか」が分からないと、期限に気づいても手続きに進めません。
そのため、一覧には次の情報も載せます。
- 契約者の名義と、契約先の窓口
- ログイン先(管理画面のURLなど)
- 費用の支払い方法(カード、請求書払い、口座振替など)
一方で、パスワードやIDの認証情報は、一覧に直接書きません。一覧は多くの人が見る前提のため、そこに認証情報があると漏えいの危険が高まります。
代わりに「パスワード管理ツールのこの項目」「金庫に保管した書類のこの番号」というように、保管場所だけを書きます。
こうすれば、担当者が替わっても必要な情報にたどり着けて、一覧自体の安全性も保てます。
年末年始・期末をまたぐ更新の注意点
更新漏れが起きやすいのは、通常の営業日ではなく、休業や決算が絡む時期です。担当者が不在、承認者も不在、業者も休業という状況が重なります。
休業中に期限が来るものを前倒しで更新する

休業をまたぐ更新では、通常の確認日ではなく、休業を前提に逆算した確認日を決めます。次の3点を考えます。
- 契約先の業者の休業日(問い合わせや手続きを受け付けない期間)
- 承認者や決裁者の不在期間
- 手続き完了までにかかる日数(審査や発送、反映を含む)
休業中に期限を迎えるものは、休業に入る前に更新を終えておくのが原則です。確認日の目安を表にすると、次のようになります。
| 更新物 | 確認日 | 理由 |
|---|---|---|
| ドメイン | 休業の2週間前 | 復旧に時間がかかる |
| SSL証明書 | 休業の2週間前 | 発行に日数がかかる |
| 回線・プロバイダー | 休業の1か月前 | 手続きに日数がかかる |
| ルーター・UTMの保守 | 休業の1か月前 | 業者の休業と重なる |
| クラウド・サーバー | 休業の2週間前 | 支払い確認が必要 |
確認日は目安であり、契約先の受付状況や自社の承認フローによって変わります。「休業の2週間前」と書いたのは、問題が見つかっても修正する余裕を残すためです。
確認だけでなく、休業中に何か起きた時の代替の連絡先(業者の緊急窓口、社内の連絡担当者)も、一覧の備考に書いておきます。
期末・予算の切り替えと自動更新・支払い方法の落とし穴
期末や予算の切り替え時期にも、特有の落とし穴があります。
- カードの有効期限:自動更新に使っているカードの有効期限が、期末や年度替わりのタイミングで切れることがあります。
- 請求書払いの締め日:請求書払いは、締め日までに支払い手続きが終わらないと更新されない場合があります。期末は経理が忙しく、支払いが後回しになりやすい点にも注意が必要です。
- 契約更新の通知期限:契約によっては「更新しない場合は一定期間前までに通知」というルールがあり、期限を過ぎると自動で次の期間に更新されます。逆に、更新の意思表示が必要なものもあります。
こうした条件は契約ごとに異なるため、一覧の備考に「いつまでに何をする必要があるか」を書いておきます。
最新の条件は必ず契約先の案内で確認してください。
証明書の有効期間が短くなる傾向への備え
SSL証明書の有効期間は、短くなる方向にあると言われています。期間が短くなるほど更新の回数は増えるため、手作業で更新していると、更新のタイミングを逃しやすくなります。
具体的な期間や移行時期は変わりうるため、最新の情報は証明書の発行元や契約先で確認してください。
更新の回数が増える場合は、自動更新の仕組みを使うのが現実的です。
ただし、自動更新を設定したから安心、とはなりません。更新が失敗していることに気づけないためです。
たとえば、設定変更で更新の手順が動かなくなる、認証の条件が変わる、といった理由で、静かに失敗することがあります。
そのため、自動更新を使う場合でも、更新後に結果を確認することを運用に入れます。ブラウザで証明書の有効期限を見る、監視ツールで期限を確認する、といった方法で、更新が実際に反映されているかをチェックします。
担当者が替わっても回る通知の仕組み
一覧を作っても、誰も見なければ意味がありません。期限が近づいたら自動的に知らせが届く仕組みを作ります。
通知の作り方|共有の通知先・三段階・二重化

通知は、次の3つの考え方で設計します。
- 個人でなく共有の通知先に入れる:更新の案内メールは、個人のアドレスでなく、複数人が見られる共有アドレス(例:情報システム用の共通アドレス)宛てにします。カレンダーも、個人のものでなく共有カレンダーに予定を入れます。これで、誰かが退職しても通知は残ります。
- 期限の90日前・30日前・7日前の三段階:一度だけの通知では、見落としや後回しが起きます。90日前は予算や承認の準備、30日前は手続きの実行、7日前は最終確認、というように段階ごとに役割を分けます。
- 担当と確認役の二重化:更新する「担当」とは別に、ちゃんと進んでいるかを見る「確認役」を置きます。担当が不在でも、確認役が気づいて動けます。担当と確認役は、異なる部署や立場の人にするとより安全です。
更新後に一覧を書き換える手順と四半期ごとの見直し

更新が終わったら、一覧を必ず書き換えます。更新しても一覧が古いままだと、次の確認時に混乱が起きます。
更新後の手順は次のとおりです。
- 新しい期限を一覧に記入する
- 通知の予定(共有カレンダー)を、新しい期限に合わせて登録し直す
- 費用の支払い元や、更新方法に変更がないかを確認して反映する
- 更新した日と、実施した人を記録する
さらに、四半期ごとに一覧全体を見直す習慣を作ります。この見直しでは、次の点を確認します。
- 新しく契約したものが、一覧に載っているか
- 解約したものが、一覧から外れているか
- 担当者や確認役が、今の体制と合っているか
- 通知先の共有アドレスが、正しく届いているか
見直しの日も、共有カレンダーに繰り返しの予定として入れておくと、忘れずに済みます。
点検チェックリスト
現在の管理状況を、次のリストで確認してみてください。
更新期限の管理状況チェックリスト
洗い出し
- [ ] ドメイン・証明書・回線・保守契約・クラウド契約を、1枚の一覧にできている
- [ ] 各項目の契約者名義と、手続きをするログイン先を一覧に書けている
運用
- [ ] 通知の宛先が個人でなく、共有アドレスと共有カレンダーになっている
- [ ] 期限の90日前・30日前・7日前に知らせが届く設定ができている
- [ ] 休業や期末をまたぐものについて、前倒しの確認日を決めている
引き継ぎ
- [ ] 担当と確認役の2人を、それぞれの項目に割り当てられている
- [ ] パスワードは一覧に書かず、保管場所だけを記録できている
- [ ] 更新後に一覧を書き換える手順を、文書にして共有できている
まとめ
更新切れによる事故は、うっかりというより、期限の情報が人の記憶に閉じていたことで起こります。対策の流れを整理すると、次のとおりです。
- 期限が来ると止まるものを洗い出し、「更新物・期限・確認する人・頻度・更新方法・支払い元」を1枚の一覧にまとめる
- レンタルサーバー会社が自動で更新してくれるドメインやSSL証明書(Let’s Encrypt)も、万が一に備えて更新内容・期限・契約先・支払い方法を一覧に記録しておく
- 名義・ログイン先・支払い方法まで書き、パスワードは書かずに保管場所だけを記録する
- 年末年始や期末をまたぐものは、業者や承認者の不在を逆算して、確認日を前倒しにする
- 通知は共有アドレスと共有カレンダーに入れ、90日前・30日前・7日前の三段階と、担当・確認役の二重化で回す
- 更新後は一覧を書き換え、四半期ごとに見直す
最初から完璧な一覧を作る必要はありません。まずは、止まると一番困るドメインと証明書、回線の3つから書き出して、少しずつ広げていくのが現実的です。
一覧が1枚あるだけで、担当者が替わっても、休業をまたいでも、組織として更新を回せる状態に近づきます。
























