ホームページ保守の自動化｜更新・バックアップ・死活監視の範囲とRPO/RTOの決め方（2026年）

サイトの保守は、何も起きない月が続くほど後回しになります。更新通知は溜まり、バックアップは「たぶん取れている」状態になり、証明書の期限は気づいた日に慌てて対応します。そして、問題が起きた日に初めて、戻せるかどうかが分かります。

この記事では、ホームページの保守のうち、CMS・プラグイン・PHPの更新、バックアップと復元テスト、死活監視、SSL証明書とドメインの期限、障害時の連絡の5つを、どこまで自動にし、どこを人に残すかを整理します。自動化の全体像は「サイト運用のAI・自動化は棚卸しから」、公開前の確認は「記事更新の自動化は品質ゲートで決まる」、解析は「Search Console と GA4 の定点観測を自動化する」で扱いました。今回は、サイトを止めない・壊さない・戻せる状態に保つ工程に絞ります。

この記事が主に根拠にした情報：WordPress.org の公式ドキュメント（自動更新・バックアップ・動作環境）、PHP 公式のサポート期間の表、Let's Encrypt と CA/Browser Forum の証明書の告知、米国 CISA・オランダ NCSC・日本 IPA のバックアップの指針、Google 検索セントラルのサーバーエラーの扱い。いずれも2026年10月24日に確認しました。

1. いま何が起きているか：保守の前提が変わった1年

保守の手間を左右する変更が、2025年から2029年にかけて続けて入ります。

証明書の有効期間が、段階的に47日まで縮む

ブラウザと認証局の業界団体 CA/Browser Forum は、2025年4月11日に決議 SC-081v3 を可決しました。サーバー証明書の最長有効期間は、2026年3月15日以降の発行分で200日、2027年3月15日以降で100日、2029年3月15日以降で47日になります。それまでは398日でした。日本の JPRS も同じ日程でサービスを改定すると告知しています。

無料の証明書を出す Let's Encrypt は、現在の90日から2027年2月10日に64日、2028年2月16日に45日へ移ります。ドメインの確認結果を使い回せる期間も、30日から10日、最終的に7時間へ縮みます。

もう1つの変化は、通知です。Let's Encrypt は2025年6月4日で、期限切れが近いことを知らせるメールをやめました。多くの利用者が自動更新に移ったことと、プライバシーと費用が理由です。期限の見張りは、利用者側の仕事になりました。

PHP 8.2 のセキュリティ修正が、2026年12月31日に終わる

PHP 公式のサポート期間の表では、8.2 のセキュリティ修正は2026年12月31日まで、8.3 は2027年12月31日まで、8.4 は2028年12月31日まで、8.5 は2029年12月31日までです。各系列は、公開から2年の通常サポートと、その後2年のセキュリティ修正だけの期間を持ちます。緊急対応は「PHP2Shell とオランダ政府の警告」で扱いました。ここでは計画して上げることを扱います。

WordPress は 7 系へ、自動更新の失敗を戻す仕組みもある

WordPress の配布ページでは、2026年10月6日に 7.1.3 と 7.0.7 が出ています。動作環境のページは PHP 8.3 以上を推奨し、7.1 が動く最低限は PHP 7.4 です。また WordPress 6.6 からは、プラグインの自動更新でPHPの致命的エラーが出たとき、元の版に自動で戻す仕組みが入っています。自動更新を勧めやすくなった一方、この仕組みが拾えない失敗もあります（第3章）。

年1回だった手作業の更新は、2027年3月以降は年4回近く、2029年3月以降は年8回近くになります。この頻度を人が覚えておくのは無理があるので、自動化と監視が前提になります。

2. 保守の自動化とは何か：4つの領域と、ほかの工程との境界

保守の自動化とは、機械に任せる作業と、機械が失敗したときに人が気づく仕組みを、組で作ることです。片方だけでは、失敗が静かに積み重なります。4つの領域は、それぞれ守る対象が違います。

どの領域でも「判断」は人に残ります。自動化で減らせるのは確認と転記と通知の手間で、ほかの工程の土台にあたります。

3. 更新を自動にする範囲の決め方

WordPress の更新は、自動にするかどうかを種類ごとに選べます。まず、何がどこまで自動になっているかを確かめます。

WordPress の4種類の自動更新

WordPress の公式ドキュメントによると、自動更新はコア・プラグイン・テーマ・翻訳の4種類です。仕組み自体は 3.7 で入り、プラグインとテーマを1つずつ自動にする画面は 5.5 で加わりました。

5.6 より前からのサイトは、メジャー更新が手動のままの場合があります。wp-config.php の WP_AUTO_UPDATE_CORE は、true（すべて）、false（すべて止める）、'minor'（マイナーだけ）を取ります。定義すると画面の設定より優先されます。AUTOMATIC_UPDATER_DISABLED を true にするとすべての自動更新が止まりますが、公式ドキュメントは強く勧めていません。

プラグインとテーマの自動更新は、既定で1日2回動き、結果は管理者にメールで届きます。この処理は内部の予定実行（WP-Cron）に頼るため、動かない環境もあります。「ツール」→「サイトヘルス」でエラーの有無を確かめます。

判断の基準：壊れたときの影響と、戻しやすさ

どのプラグインを自動にするかは、壊れたときの影響と戻しやすさの2軸で決めます。影響が小さく戻しやすいものは自動、影響が大きいか戻しにくいものは確認してから適用します。

決済や会員のプラグインは、更新でデータベースを変えることがあり、ファイルを戻してもデータは戻りません。戻しにくさは、ファイルではなくデータで決まります。放置されたプラグインは修正が出ないので、置き換えます。

6.6 の自動ロールバックが拾うもの、拾わないもの

WordPress 6.6 で入ったロールバックは、プラグインの自動更新の後にサイトのトップページへ内部から接続（ループバック）し、PHP の致命的エラーが出たら元の版に戻し、管理者にメールで知らせます。

一方で、この仕組みが拾わない失敗もあります。

ロールバックは安全網の1枚目にすぎません。表示とフォームの確認、更新前のバックアップを組み合わせて、初めて自動更新を広げられます。

更新の流れ：退避・検証・確認・本番

影響の大きい更新は、次の4段で進めます。検証環境（ステージング）は、本番サイトの複製を別のURLに置いたものです。多くのレンタルサーバーやWordPress向けのホスティングは、複製の機能を持っています。

2と3は自動で回せ、人が見るのは差分が出たときだけです。4の後の24時間は、監視の間隔を短くし、エラーログを確認します。

4. PHP とサーバーの更新を計画する

PHP は WordPress を動かす言語で、サーバー側にあります。WordPress の画面からは自動更新されず、レンタルサーバーの管理画面か、サーバーの管理者が切り替えます。

PHP のサポート期間と WordPress の対応

次の表は、PHP 公式のサポート期間と、WordPress の PHP 互換表をあわせたものです。

8.2 のサイトは、2か月あまりで修正が届かなくなります。上げるなら 8.4 か 8.5 を選ぶと、2〜3年の余裕が取れます。PHP 8.5 には WordPress 6.9 以降、8.4 には 6.7 以降が必要です。

PHP を上げる手順と、よくある失敗

PHP の切り替えは、古いプラグインが新しい PHP で使えない書き方を含むことがあり、コアの更新より壊れる範囲が広い作業です。

1. プラグインとテーマの対応状況を確かめる。各ページの更新履歴を見る
2. 検証環境の PHP だけを先に上げる。多くのレンタルサーバーはサイトごとに版を選べる
3. エラーログを有効にして、主要ページとフォームを開く。警告（Deprecated）は次の系列で壊れる候補
4. 前日にバックアップを取り、本番を上げる。管理画面で版を戻す方法も確かめておく
5. 上げた後の24時間はエラーログを見る。予定実行やメール送信の不具合は遅れて出る

よくある失敗は、予約投稿やメール送信だけが止まる形です。画面はふつうに見えるため、数日後に「問い合わせが来ない」で発覚します。第7章のフォーム送信の監視が効きます。

サーバーのOSとミドルウェア

VPS などでは、OS・Webサーバー・データベースの更新も保守に入ります。IPA の「安全なウェブサイトの運用管理に向けての20ヶ条」は、これらを最新に保つことと、クラウド利用時の責任範囲の把握を挙げています。どこまでが事業者の担当かを、契約で確かめておきます。

5. バックアップを設計する：3-2-1 と RPO/RTO

バックアップは先に「どこまで戻れればよいか」を決めます。決めないと、頻度も保管先も何となくの設定になります。

3-2-1 とは何か

3-2-1 は、データのコピーを本体を含めて3つ以上持ち、2種類の異なる媒体に置き、そのうち1つを別の場所に保管する考え方です。米国の CISA、オランダの NCSC（国家サイバーセキュリティセンター）、日本の IPA が、いずれもこの形を勧めています。IPA は「中小企業の情報セキュリティ対策ガイドライン」で、はじめに取り組む項目に「バックアップを取ろう！」を加えました。

サイトでは次のようになります。

最後の行は、CISA と NCSC がランサムウェアへの備えとして勧める、オフラインの複製や本番からの分離にあたります。サーバーの管理画面から一緒に消せる場所は、別の場所に数えません。

RPO と RTO を先に決める

RPO（目標復旧時点）は、米国 NIST の用語集で「障害の後、データを戻すべき時点」とされます。言い換えると、失ってよいデータの幅です。RTO（目標復旧時間）は、止まってよい時間の上限です。NCSC は、午前3時にバックアップを取るサイトで午後4時に障害が起きれば、その間の13時間分を失う、という例で RPO を説明しています。

RPO を短くするほどバックアップの頻度が上がり、RTO を短くするほど復元の手順と練習が要ります。サイトの種類ごとの目安は次のとおりです。

表は DevNJ の目安です。WordPress の公式ドキュメントは、更新の少ないサイトは毎週、更新の多いサイトは毎日を目安とし、最終的には「どれだけ失ってよいか」で決めるよう書いています。問い合わせや注文がデータベースに入るサイトは、ファイルよりデータベースを頻繁に取ります。

何をバックアップするか

WordPress の公式ドキュメントは、ファイルとデータベースの両方が必要だとしています。ファイルには、コア・プラグイン・テーマ・アップロードした画像、wp-config.php、.htaccess が含まれます。データベースは WordPress のフォルダの外にあるので、ファイルをダウンロードしても含まれません。

見落としやすいのは、サイトの外にある設定です。

DNS の設定は、サーバー移転や事業者の変更で消えやすい部分です。画面の控えでもよいので、変更のたびに残します。

保持期間と世代

世代は、いくつ前のバックアップまで残すかです。WordPress の公式ドキュメントは最低でも3〜5世代を残すよう勧め、CISA は少なくとも7日前まで戻せるようにすることを挙げています。改ざんや不正なコードの埋め込みは、気づくまでに日数がかかるためです。

DevNJ では、毎日の取得を14日分、毎週の取得を8週分、毎月の取得を12か月分残す形をよく使います。個人データを含むバックアップを長く持つと、GDPR（EU一般データ保護規則）の保存期間の考え方とぶつかることがあるため、保持期間はプライバシーポリシーと合わせて決めます。

6. 復元テスト：戻せて初めてバックアップになる

NCSC は、バックアップが必要になったときに初めて試されることが多いと指摘しています。成功メールは、戻せることを保証しません。

技術的なテストと、機能のテスト

NCSC は、復元のテストを2種類に分けています。技術的なテストは、バックアップのソフトが成功を報告しているかを見ます。機能のテストは、実際に丸ごと戻し、業務が回るかを確かめます。

容量の急な変化は自動で見られます。前日の半分なら、取得の中断かデータの消失を疑います。

四半期の復元テストの手順

丸ごとの復元は、本番ではなく、別のURLの検証環境に戻して確かめます。所要時間を測ると、それが実際の RTO になります。

1. 1週間前の世代を選ぶ。古い世代も使えるかを同時に確かめられる
2. ファイルを先に、データベースを後に戻す。WordPress の公式ドキュメントが示す順番で、接続情報が変わったら wp-config.php を直す
3. 主要ページ・管理画面・フォームを確かめる。画像が欠けていないか、日本語が文字化けしていないかを見る
4. かかった時間を記録する。目標の RTO を超えたら、手順か保管先を見直す
5. 手順書をその日のうちに直す

CISA は、復元の練習の結果をもとに RPO と RTO を見直すよう勧めています。目標は、試して初めて現実の数字になります。

7. 死活監視：何を、どの間隔で見るか

死活監視は、サイトが動いているかを外から確かめ、止まったら知らせる仕組みです。サーバーの中からの確認は、サーバーごと止まると通知も止まります。

監視する項目

応答は返っても中身が空、という壊れ方があるため、トップページの応答だけでは足りません。

最後の行は報告が来ないことを異常とみなすもので、バックアップや予定実行が黙って止まる失敗を拾えます。

稼働率と止まる時間

約束される稼働率は、30日の月の停止時間に直すと比べやすくなります。

年間に直すと、99% で約87.6時間、99.5% で約43.8時間、99.9% で約8.8時間、99.95% で約4.4時間、99.99% で約53分です。99.5% までなら5分間隔、それより上は1分間隔、99.99% では複数地点からの監視が目安です。

5分間隔で2回連続の失敗を条件にすると、気づくまでに最大10分ほどかかります。99.9% を約束しているのに10分遅れて気づくと、月の許容の4分の1近くを、通知を待つだけで使います。約束する稼働率と監視の間隔は、組で決めます。

誤報を減らす

よくある失敗は、誤報が多すぎて通知を読まなくなることです。次の3つで減らします。

• 連続の失敗で知らせる。2回連続か、2地点以上からの失敗を条件にする
• 予定の作業中は監視を止める。更新や移転の時間帯が対象
• 急ぎの度合いで通知先を分ける。「止まった」は携帯に、「証明書の残り日数」はメールに

止まると検索にどう響くか

Google 検索セントラルによると、5xx や 429 が返るとクロール（巡回）が減り、サーバーエラーが続く URL は、いずれインデックスから外れます。2xx に戻ればクロールは徐々に戻ります。

robots.txt が 5xx を返した場合の扱いは、時間で分かれます。

計画した停止なら、Google は1〜2日は 503、それより長いときは 200 の説明ページを勧め、数日を超える停止は検索での回復に時間がかかると書いています。

8. SSL 証明書とドメインの期限を見張る

証明書とドメインは、期限が来ると確実に止まります。日付が前もって分かるので、監視でほぼ防げます。

証明書：短くなる期間と、更新の目安

Let's Encrypt は、有効期間の3分の2あたりで更新することを目安に挙げ、更新の時期を認証局が知らせる ARI（ACME Renewal Information）への対応を勧めています。60日ごとに固定で更新する設定は、45日の証明書では足りなくなります。

最長期間は CA/Browser Forum の日程、目安は Let's Encrypt の考え方を当てはめた計算です。有料の証明書を手作業で入れ替えている会社は、2027年3月までに自動化の方法を決める必要があります。ACME（証明書の自動発行の手順）に対応した認証局とサーバーへ移るのが一般的です。

監視は有効期間の3分の1を切ったら注意、7日を切ったら警報の2段にすると、期間が変わっても使えます。DNS の変更、移転、CDN（配信網）の導入の後は、手でも確かめます。

ドメイン：期限が切れると何が起きるか

ドメインの期限切れは、サイトだけでなくメールも止めます。扱いはドメインの種類で違います。

gTLD の通知は ICANN の規則（ERRP）、.nl は SIDN の quarantaine（クアランテーネ、保留期間）、.jp は JPRS の規則によります。回復の期間や手数料は事業者ごとに違い、手続きの間はサイトとメールが止まります。更新の通知メールが、退職した担当者や使っていないアドレスに届いているのが、期限切れの最も多い原因です。登録者の連絡先を共有の窓口にし、自動更新と支払い方法の期限を年に1回確かめます。

9. 障害時の連絡：誰に、いつ、何を

誰が動くか決まっていなければ、通知は役に立ちません。ENISA（EU サイバーセキュリティ機関）の中小企業向けガイドも、役割を決めた対応計画を挙げています。

連絡の順番と時間の区切り

DevNJ では、障害の連絡を次の区切りで考えます。時間は目安で、契約の内容で変わります。

「判断」の段階を人に残すのが要点です。バックアップから戻すと、その間に入った問い合わせや注文が消えることがあるため、自動で決めてはいけません。

サーバー・ドメイン・DNS・メール・決済・制作会社の6つは、契約者名、緊急時の窓口、二段階認証の端末を持つ人を一覧にし、毎年見直します。

個人データが関わる場合の届出

障害の原因が不正アクセスで、問い合わせフォームの内容や会員情報が漏れた可能性があるときは、法律上の届出が必要になる場合があります。期限は日本と欧州で違います。

GDPR の第32条は、個人データを適時に使える状態へ戻せる能力と定期的な検証を求めており、バックアップと復元テストはその説明の材料になります。日本と欧州の両方に顧客がいる会社は、短いほうの72時間に合わせて手順を作ります。

10. 費用と工数の幅

保守の自動化には、どの段階まで進めるかで費用に大きな幅があります。次の表は DevNJ の目安で、WordPress のサイト1つを想定しています。

差分の確認と復元の判断は、どの段階でも残ります。

時間単価80ユーロで外注した場合の初期費用は、次のようになります。円は1ユーロ175円で換算した概算です。

1年目の合計は初期費用に月額12か月分を足したもので、人の作業時間は含めていません。

損益は止まったときの損失と比べます。問い合わせが月20件、1件500ユーロのサイトが3日止まれば約1,000ユーロの損失で、段階2は1回の停止を防げば回収できます。問い合わせの多くが電話なら、段階1で足りることもあります。

11. よくある失敗

どの失敗も、仕組みを入れた後の確認を省いたときに起きます。

いちばん多いのは、最初の2行です。「バックアップは取っている」は、「戻せる」と同じ意味ではありません。

12. 日本と欧州で比べる

日本と欧州の両方にサイトを持つと、前提がいくつか変わります。優劣ではなく条件の違いです。

欧州向けのサイトでは、バックアップの保管先がEU域外でないかを問われることがあります。地域を選べるなら EU 域内にしておくと説明が簡単です。

13. ケースで考える（架空の3社）

架空の3社で、同じ考え方がどう違う答えになるかを見ます。

A社：日本の製造業の欧州向け英語サイト

フォームの問い合わせが月10件ほどのカタログサイトです（RPO 1日）。段階2で、DB は毎日、ファイルは毎週、別事業者の EU 域内へ送り、毎朝1回のテスト送信が届かなければ日蘭の担当者に通知します。

B社：オランダの日本食材のネットショップ

注文が1日30〜50件のため、RPO 1時間・RTO 2時間に置き、事業者の1時間ごとのバックアップに毎日の外部転送を足します。決済と在庫のプラグインは火曜の朝に検証を経て適用し、週末の更新を避けて窓口が開いている時間に対応します。

C社：日蘭2言語の士業事務所

相談の申込みに個人データが含まれます。段階1で、フォームの内容をサイトに保存しない設定にしました。サイトの個人データを減らすと、保持期間も漏えい時の影響も小さくなります。期限の監視は段階2と同じです。

14. 導入の手順：4週間で進める

保守の自動化は、4週間ほどで形にできます。週ごとに成果物を決めて進めます。

1. 1週目：今の状態を書き出す。版・バックアップ・期限・契約を1枚にまとめる
2. 1週目：RPO と RTO を責任者と決める（第5章）
3. 2週目：バックアップを 3-2-1 にする。外部の保管先、世代、容量の通知
4. 2週目：プラグインを仕分ける。自動・検証後・置き換え（第3章）
5. 3週目：4点の監視を入れる。バックアップの報告がないときの通知も
6. 3週目：連絡の表（第9章）と連絡先の一覧を埋める
7. 4週目：初めての丸ごとの復元を検証環境で試し、時間を測る
8. 4週目以降：確認を予定に入れる。月次は通知と記録、四半期は復元

最初の復元テストで、たいてい何か1つはつまずきます。それを本番の障害の前に見つけることが、4週目の目的です。

15. やってはいけないこと

保守の自動化で、避けたほうがよい設定と判断を並べます。

自動化は、手間を減らすために、最初に少し手間をかけるものです。

16. チェックリスト

導入の後、月に1回と四半期に1回、次の項目を確かめます。

• WordPress のコアは最新の系列で、マイナー更新が自動になっている
• PHP は 8.3 以上で、セキュリティ修正の終了日を把握している
• RPO と RTO を数字で決め、責任者が了承している
• バックアップが3つ以上あり、1つは別事業者・別の場所にある
• 四半期に1回、別環境への丸ごとの復元を試し、時間を記録している
• 応答・文字列・証明書・ドメインの4点を外から監視している
• 証明書の自動更新があり、残り日数の通知が2段階になっている
• 障害時の連絡の順番と、復元を決める人が決まっている
• 個人データの漏えい時の届出期限（72時間・3〜5日）を手順に書いた

17. まとめ

• 保守の自動化は、作業を任せる仕組みと、失敗に気づく仕組みを組で作ること
• 自動更新の範囲は、壊れたときの影響と戻しやすさで決める。決済・フォーム・ページビルダーは検証してから
• PHP 8.2 のセキュリティ修正は2026年12月31日で終わる。上げるなら 8.4 か 8.5
• バックアップは RPO と RTO を先に決め、3-2-1 で置き、四半期に1回は実際に戻す
• 監視は応答・文字列・証明書・ドメインの4点を外から、2回連続の失敗で知らせる
• 証明書の最長有効期間は2029年3月に47日になる。手作業の更新は続けられない
• 復元の判断と顧客への連絡は人が持ち、個人データが絡むときは72時間を基準に動く

参考にした情報源

WordPress・PHP

• Upgrading WordPress — WordPress Developer Resources：自動更新の種類と既定、設定の定数
• Plugin and themes auto-updates — WordPress.org Documentation：5.5 の画面、1日2回の実行、通知
• Merge Proposal: Rollback Auto-Update — Make WordPress Core：6.6 のロールバックの仕組み
• WordPress Backups — WordPress Developer Resources：取得の対象・頻度・世代・復元の順番
• Hardening WordPress — WordPress Developer Resources：古い版に修正が出ないこと
• Requirements — WordPress.org：推奨の動作環境
• PHP Compatibility and WordPress Versions — Make WordPress Core：系列ごとの PHP 対応
• Releases — WordPress.org：最新版の公開日
• Supported Versions — PHP：系列ごとのサポート期限

証明書・ドメイン

• Ballot SC-081v3 — CA/Browser Forum：最長有効期間の短縮の決議
• サーバー証明書の最長有効期間短縮に伴うサービス改定について — JPRS：短縮の日程
• Decreasing Certificate Lifetimes to 45 Days — Let's Encrypt：64日・45日への日程と更新の目安
• Ending Support for Expiration Notification Emails — Let's Encrypt：期限通知メールの終了
• Expired Registration Recovery Policy — ICANN：gTLD の通知と回復期間
• Undoing the cancellation of a domain name — SIDN：.nl の保留期間
• JPドメイン名のライフサイクル — JPRS：.jp の廃止と登録回復

バックアップ・セキュリティの指針

• Back Up Business Data — CISA：3-2-1 と復元の練習
• Een back-up strategie opstellen — NCSC：3-2-1、RPO と RTO の例
• Hoe test ik een back-up? — NCSC：復元テストの2種類
• Recovery point objective — NIST CSRC Glossary：RPO の定義
• Recovery time objective — NIST CSRC Glossary：RTO の定義
• 中小企業の情報セキュリティ対策ガイドライン — IPA：バックアップを含む6か条
• 安全なウェブサイトの運用管理に向けての20ヶ条 — IPA：サーバー更新と責任範囲
• Cybersecurity guide for SMEs — ENISA：中小企業向けの12ステップ

検索・届出

• HTTP status codes, network and DNS errors — Google 検索セントラル：5xx の扱い
• How Google interprets the robots.txt specification — Google 検索セントラル：robots.txt の 5xx の扱い
• Pausing your online business — Google 検索セントラル：計画停止の方法
• This is how you report a data breach — Autoriteit Persoonsgegevens：72時間以内の届出
• 漏えい等の対応とお役立ち資料 — 個人情報保護委員会：報告の期限
• Regulation (EU) 2016/679（GDPR） — EUR-Lex：第32条・第33条

いずれも2026年10月24日に確認したものです。版・期限・料金は変わるため、作業の前に公式サイトで最新の情報を確認してください。費用と工数、サイトの種類ごとの目安は DevNJ の実務上の目安で、サイトの規模と契約によって変わります。