2026.06.05

Web運用

「サイトが保護されていません」と言われる前に。SSL証明書更新を見落とさない保守運用の作り方

「お客さまから“サイトに『保護されていません』と出ている”と言われて、慌てて確認しました」

Webサイトの保守運用に関わっている方なら、このような場面にひやっとした経験があるかもしれません。

SSL証明書の期限管理は、保守契約の中では基本中の基本です。
それでも、管理表の更新漏れや担当者の引き継ぎ漏れ、サイトごとに異なる更新タイミングが重なると、手作業だけではどうしても見落としが起きることがあります。

私たちも過去に、クライアントからの指摘でSSL証明書の期限切れに気づいたことがありました。

証明書を再発行して反映すれば、警告表示そのものは解消できます。
しかし、「クライアントや来訪者に先に気づかれてしまった」という事実は、保守を任されている側にとって大きな反省点として残ります。

さらに、2026年3月15日からSSL/TLS証明書の有効期間は398日から200日に短縮されました。今後は2027年3月15日に100日、2029年3月15日には47日まで短くなる予定です。

つまり、これまで年1回程度だった更新対応が、年2回、将来的には年7〜8回のペースに増えていくということです。

この記事では、SSL証明書の期限切れや更新後の異常を、クライアントから指摘される前に自分たちで検知するために、私たちが保守フローをどう見直したかを紹介します。

なぜこの課題が起きるのか

SSL証明書の管理で問題が起きる理由は、単に「うっかり忘れたから」だけではありません。

保守対象のサイトが増え、証明書の更新頻度が上がり、さらに更新後に確認すべき項目も増えているため、従来の管理方法では追いつきにくくなっているのです。

背景1：SSL/TLS証明書の有効期間が短くなり、更新頻度が増えている

2026年3月15日から、SSL/TLS証明書の有効期間は398日から200日へ短縮されました。
この変更は、CA/Browser Forumの「SC-081v3」という投票で決まったものです。

今後は段階的にさらに短くなり、2027年3月15日には100日、2029年3月15日には47日まで短縮される予定です。

また、短くなるのは証明書の有効期間だけではありません。
証明書を発行する際のドメイン認証、いわゆるDCV情報を再利用できる期間も段階的に短くなり、2029年には10日まで縮む予定です。

つまり、これからのWebサイト保守では、次の2つがこれまでより頻繁に発生します。

SSL証明書の更新
ドメイン認証のやり直し

更新頻度が増えれば、その分だけ確認漏れが起きる可能性も増えます。
スプレッドシートで期限を管理し、通知を設定しておくだけでは、運用の負担が大きくなっていくと感じました。

背景2：期限管理だけでは、更新後の不具合まで見つけられない

SSL証明書の更新は、新しい証明書を発行してサーバーに反映すれば終わり、というわけではありません。

更新作業そのものが完了していても、サイト側では別の問題が残ることがあります。

たとえば、私たちの現場では次のような不具合が起きたことがありました。

HTTPでハードコードされていた画像やスクリプトが残り、mixed contentの警告が出た
相対パスで書かれていた画像が、HTTPS環境で読み込めなくなった
広告タグやチャットウィジェットなどの外部スクリプトがHTTP参照のままで、ブラウザ側でブロックされた
旧サブドメイン向けの証明書を使っていた箇所が残り、特定ページで警告表示になった

これらは、証明書の有効期限だけを見ていても検知できません。

「証明書は更新済み」と管理表にチェックが入っていても、実際にサイトを巡回し、HTTPSで正しく表示されているかを確認しなければ、来訪者側で起きている異常には気づけないことがあります。

2026年5月には、Cloudflareが一部のLet’s Encrypt証明書に関して、中間CAの組み込み、いわゆるチェーンが原因で、一部の来訪者にTLS接続の問題が出る事象を報告していました。

このように、サーバー側では更新済みに見えていても、ブラウザや環境によっては警告や接続失敗が起きる場合があります。

だからこそ、SSL証明書の保守では「期限を管理する」だけでなく、「更新後にサイト側で何が起きているかを確認する」ことが重要になります。

解決するためのSTEP

私たちは、SSL証明書の期限切れや更新後の異常に気づくタイミングを、「クライアントからの指摘」から「自分たちの定期チェック」へ前倒しするために、保守フローを見直しました。

大きく分けると、次の3つのSTEPです。

STEP 1：現状を可視化する

まず行ったのは、保守対象サイトごとにSSL証明書の状態と確認項目を整理することです。

以前は、SSL証明書の有効期限をスプレッドシートで管理していました。
期限が近づくと通知が出るようにしていましたが、サイトごとに更新タイミングが異なり、担当者の異動や管理表の更新漏れによって、見落としが起きたこともありました。

そこで、単に「期限日」を見るだけではなく、次のような観点で確認するようにしました。

どのサイトがいつ更新対象になるのか
更新前後でどのページを確認すべきか
過去にどのページでSSL関連の不具合が起きたか
mixed contentや画像読み込み失敗が起きやすい箇所はどこか
外部スクリプトやタグの参照先にHTTPが残っていないか

この段階で大切なのは、SSL証明書の管理を「期限日の一覧」だけで終わらせないことです。

期限を把握するだけでなく、更新後に確認すべきページや要素まで含めて可視化することで、保守の抜け漏れを減らしやすくなります。

STEP 2：月次運用として記録・一覧化する

次に、SSL証明書の更新前後でサイトを巡回し、異常の候補を一覧化する流れを月次運用に組み込みました。

ここで活用しているのが、MONJI+の「Webサイト異常検知&改善機能」です。

MONJI+では、URLを入力するだけで、サイト内のページをPC・スマホ両方の表示で自動的に巡回し、異常の候補を一覧化できます。

SSL更新後に確認したい項目としては、たとえば次のようなものがあります。

HTTPSアクセス時のリンク切れ
画像の読み込み失敗
mixed contentによる表示崩れ
タグ未設置
HTTP参照のまま残っている外部スクリプト

以前は、1サイトあたり月間5時間以上かけていた手動チェック工数の中で、SSL関連の確認と対応が一定の割合を占めていました。

しかし、SSL/TLS証明書の有効期間が200日に短縮され、今後さらに短くなる前提では、同じ人力のやり方だけでは管理が追いつきにくくなります。

そのため、機械的に検知できる項目はMONJI+のような仕組みに任せ、人が確認すべき項目に時間を使えるようにしました。

STEP 3：数カ月分の実績をもとに交渉・提案する

SSL証明書の保守運用では、検知して終わりではなく、対応と記録までつなげることが重要です。

私たちの月次サイクルは、次のような流れです。

証明書の更新予定日の前後で、異常検知を手動または定期実行する
検知結果から、対応が必要な項目を修正依頼として起票する
担当者を割り振って対応する
対応後にGoogle Analyticsで影響範囲を数値で確認する
「次回の更新で気をつけること」をWikiに蓄積する

特に効果を感じているのが、Wikiへの蓄積です。

たとえば、過去に特定のページでmixed contentが出た、特定の外部タグでHTTP参照が残っていた、あるサブドメインで証明書まわりの確認が必要だった、といった情報を残しておくことで、次回のSSL更新時に最初から確認項目に含められます。

更新頻度が年2回、さらに将来的に年7〜8回へ増えていくと、過去の巡回結果を次回の確認項目に反映することの意味は大きくなります。

また、こうした運用実績が残っていると、クライアントに対しても「何を確認し、どの異常に対応し、次回にどう活かしているか」を説明しやすくなります。

保守費用や運用範囲を見直す際にも、単なる作業時間ではなく、リスクを先回りして検知するための運用として伝えやすくなりました。

実際に起きた変化

保守フローを見直してから、もっとも大きく変わったのは、SSL証明書の異常に気づくタイミングです。

以前は、SSL証明書の期限をスプレッドシートで手作業管理し、期限が近づくたびに人力でサーバー・DNS・Webサイト側の表示を確認していました。

期限切れや更新設定のミスがあった場合、ブラウザの警告表示やクライアントからの指摘で初めて気づくこともありました。

MONJI+を保守フローに組み込んでからは、SSL更新後に自動巡回を走らせることで、HTTPSアクセス時のリンク切れ、画像の読み込み失敗、mixed contentによる表示崩れなどを検知できるようになりました。

検知結果は、そのまま修正依頼として起票できます。
さらに、再発防止のポイントはWikiに蓄積されていきます。

その結果、期限切れや更新後の異常に気づくタイミングを、「クライアントからの指摘」から「自分たちの定期チェック」へ前倒しできるようになりました。

SSL証明書の更新回数が増えるほど、見落としの母数も増えます。
その前提で、気づき方を先に組み替えておけたことは、現場として大きな意味があったと感じています。

また、精神的な負担が減ったことも、保守担当者にとっては大きな変化でした。

「何か起きてから連絡が来るかもしれない」という状態ではなく、「定期的に見に行っている」という状態を作れるだけで、運用の安心感は変わります。

注意点・限界

ただし、自動検知ですべてをカバーできるわけではありません。

自動検知で拾いやすいのは、機械的に判定できる範囲の異常です。

たとえば、次のような項目です。

HTTPステータスコード
画像ファイルの読み込み成否
タグの有無
リンクの到達性
mixed contentの候補

一方で、人の目や手で確認すべき項目も残ります。

たとえば、デザインの微妙なズレ、アニメーションの動き、フォーム送信時の挙動、証明書チェーンの中間CAに関する細かい問題などは、機械的な成否判定だけでは判断しきれません。

また、SSL証明書の発行・更新そのものの自動化は、サーバー会社や証明書の管理方式、ACME対応の有無などに依存します。
この部分は、MONJI+の機能で直接カバーする範囲ではありません。

そのため、私たちは次のように役割を分けています。

証明書の発行・更新そのものは、ACMEなど既存の自動更新サービスを活用する
更新後のリンク切れ、画像読み込み失敗、mixed contentなどの影響確認はMONJI+で巡回する
デザインやフォーム挙動など、人の判断が必要な項目は担当者が確認する

有効期間がさらに短くなる2027年・2029年に向けて、「発行は自動化し、影響確認は巡回で受け止める」という線引きは、より重要になっていくと考えています。

現場から生まれたWebサイト運用支援プラットフォーム【MONJI+】

SSL証明書の更新後確認に限らず、Webサイト運用の現場では、細かな確認・修正依頼・再発防止の記録が日々発生します。

その現場で感じてきた課題を解決するために生まれたのが、Webサイト運用支援プラットフォーム【MONJI+】です。

【MONJI+】は、Webサイト運用に携わる「人」を1つの「チーム」にまとめ、Webサイト運用のあらゆるフェーズを横断して、課題を解決するプラットフォームです。

私たちは、最初から“完成されたプロダクト”を開発することを目指していません。

本当に向き合うべき課題はWebサイト運用の現場にあり、だからこそ私たちは、現場のリアルな声と向き合い続けてきました。

一つひとつの声を受け止めながら、小さな違和感を解消するアップデートを重ね、現場の課題から新たな機能も生まれてきました。

そうした積み重ねを経て、【MONJI+】は世界77ヶ国のユーザーさまに支えられる存在となりました。

▼【MONJI+】について、詳しくはこちらをご覧ください
https://monji.tech/ja/plus/

Webサイト運用の現場で働く人が、誇りを持って「この仕事が好きだ」と言える世界。

▼その実現のために、あなたの声をお待ちしております
https://monji.tech/ja/plus/co-creation/

まとめ

SSL/TLS証明書の有効期間は、2026年3月15日から398日から200日に短縮されました。
今後は2027年3月15日に100日、2029年3月15日に47日まで短くなる予定で、ドメイン認証情報の再利用期間も段階的に短縮されます。

これにより、Webサイト保守におけるSSL証明書の更新頻度は、年1回から年2回、将来的には年7〜8回へ増えていきます。

だからこそ、これからの保守運用では、単に期限を管理するだけでは足りません。

大切なのは、次の3つです。

SSL証明書の期限と更新予定を可視化する
更新後にサイトを巡回し、リンク切れ・画像読み込み失敗・mixed contentなどを確認する
検知結果を修正依頼やWikiに残し、次回の更新に活かす

SSL期限切れやHTTPSまわりの異常は、「気づけるかどうか」で結果が大きく変わる領域です。

クライアントから「保護されていませんけど」と言われてから対応するのではなく、自分たちの定期チェックで先に気づける状態を作る。

そのために、私たちはMONJI+の「Webサイト異常検知&改善機能」を保守フローに組み込み、SSL更新後の確認を月次運用の中に位置づけています。

証明書の有効期間が短くなるこれからの時代ほど、こうした地道な運用設計が、クライアントとの信頼を守る土台になると感じています。

一覧に戻る