WordPressのメジャーアップデート対応を月額にする｜検証環境・プラグイン互換・ロールバックの手順と、料金の計算例【2026年版】

この記事は、WordPressのメジャーアップデート対応を、その都度の無償対応ではなく、検証の手順と料金の決まった月額の保守にする方法を扱います。

結論から書きます。WordPress アップデートの保守は「自動に任せる更新」と「人が検証してから入れる更新」を契約で分け、メジャーアップデートは検証環境での確認・プラグイン互換の確認・戻し方の用意の3工程を、年の回数で月額に割り付けるのが答えです。

2026年は、5月20日に WordPress 7.0、8月19日に 7.1 が公開されました（WordPress.org、2026年11月5日確認）。

WordPress のメジャーアップデートは、どれくらいの頻度で来るか

WordPress.org のリリースの一覧で確かめた内容です（WordPress.org、2026年11月5日確認）。

7.0：2026年5月20日公開　→ 7.0.8（2026年10月28日）
7.1：2026年8月19日公開　→ 7.1.4（2026年10月28日）

同じページには、最新の 7.1 系の最新版だけが安全に使える、という趣旨の注記があります。
WordPress 6.9 のまま止まっているサイトは、すでにメジャーアップデートを2つ見送っている状態です。

メジャーアップデートは、年に一度の行事ではありません。年に複数回来る前提で、保守を組み立てます。

WordPress アップデートの保守とは、更新を「自動に任せるもの」と「人が確かめるもの」に分け、後者を予定された作業にすることである

黒字化の外科医です。WordPress のメジャーアップデート対応を、月額の保守にする手順と料金を解剖します。

分けて扱うべき理由は、三つあります。

第一に、標準の自動更新の範囲が、サイトによって違うから。
WordPress の公式の管理者向けハンドブックでは、本体のマイナー更新（保守とセキュリティの更新）は多くのサイトで標準で自動、メジャー更新は WordPress 5.6 以降の新規のインストールで標準で自動、それ以前からのサイトは以前の設定のまま、と説明されています。プラグインとテーマは、特別な場合を除いて標準では自動で更新されません（developer.wordpress.org、2026年11月5日確認）。

第二に、メジャー更新では、プラグインやテーマとの相性が問題になるから。
本体が変わると、プラグインやテーマが追いつくまでに時間差が出ることがあります。確かめずに入れると、管理画面や表示が崩れます。

第三に、戻すのが難しいから。
同じハンドブックでは、更新の前にサイトをバックアップし、使えることを確かめるよう求めています。サイト全体とデータベースのバックアップがなければ、元に戻すのは難しく、戻すこと自体も一般には勧められない、という趣旨の説明があります。

今すぐ試せる：保守先の自動更新の設定を棚卸しするプロンプト

私はWeb制作会社の担当者です。保守先のWordPressサイトの、更新の扱いを一覧にしてください。

【前提】
・サイトの一覧（サイト名、WordPressのバージョン、インストールした時期、プラグインの数）：〔記載〕
・各サイトの自動更新の設定（本体のマイナー・メジャー、プラグイン、テーマ）：〔管理画面とwp-configで確認した内容を記載〕
・フォーム、会員、ECの有無：〔記載〕

1. 本体のメジャー更新が自動になっているサイトを抜き出す。
2. フォーム・会員・ECがあるのにメジャー更新が自動のサイトに、印をつける。
3. 各サイトについて「自動に任せる更新」と「検証してから入れる更新」の案を示す。

私が記載していない設定は推測せず「要確認」とすること。

WordPress 保守の月額工場：メジャーアップデートの3工程と料金

1. 自動と手動の分け方（契約に書く）

自動に任せる
　・本体のマイナー更新（保守・セキュリティ）
　・翻訳ファイル
検証してから入れる
　・本体のメジャー更新
　・プラグインとテーマの更新（主要なもの、または全部）
例外
　・提供元が緊急の修正を出した場合は、検証の前に入れることがある（事前に合意）

本体の自動更新は、wp-config.php の WP_AUTO_UPDATE_CORE で、マイナーだけにする（'minor'）などの設定ができると、公式ハンドブックに書かれています。設定を変えたら、その内容を保守の台帳に記録します。

2. メジャーアップデートの3工程

① 検証環境での確認
　 本番のコピーにメジャー更新を入れる
　 主要な画面、投稿の保存、メディア、フォーム、会員・ECの操作を確かめる
② プラグイン互換の確認
　 提供元の対応状況を確かめ、更新の順番を決める
　 対応が遅れているプラグインは、本番の更新を待つか、代わりを探す
③ ロールバックの用意と本番の更新
　 ファイルとデータベースのバックアップを取り、使えることを確かめる
　 本番に入れ、①と同じ項目を確かめる
　 不具合が出たら、バックアップから戻す

③の「バックアップが使えることを確かめる」を飛ばさないことが、ロールバックの成否を分けます。復旧のテストの考え方は、こちらで扱っています。

▶ バックアップは「取っている」だけでは保守にならない──復旧テストを年に何回、何時間でやるかを決め、保守の商品と報告に組み込む方法と計算例

3. 月額の計算（例）

メジャー更新1回の作業：6時間（例：①3時間 ＋ ②1時間 ＋ ③2時間）
年のメジャー更新の回数：3回（例）
メジャー更新の年の作業：6時間 × 3回 ＝ 18時間

プラグイン・テーマの月次の更新と確認：1時間 × 12か月 ＝ 12時間（例）

年の作業の合計：18時間 ＋ 12時間 ＝ 30時間
時間単価：7,600円（例）
年の原価：30時間 × 7,600円 ＝ 228,000円
月あたりの原価：228,000円 ÷ 12か月 ＝ 19,000円

数字はすべて例です。この原価に、自社で決めた粗利を乗せて月額にします。
メジャー更新の回数が想定より多い年は、契約の更新の時に回数の前提を見直します。

保守を年間の予定として組む考え方は、こちらの記事にあります。

▶ WordPressの保守を年間スケジュールで組む──「依頼が来たら対応」をやめ、月次・四半期・年次・更新日の4層で工数を読み、保守料の根拠にする

4. 月額に含めないもの（前提条件に書く）

・プラグインの不具合を、提供元の代わりに直す作業
・対応が止まったプラグインの入れ替えと、それに伴う作り直し
・PHPのバージョンアップ（別の工事として見積もる）
・顧客が自分で入れたプラグインによる不具合の調査

PHPの期限への対応は、PHP 8.2 サポート終了に制作会社がやることで扱っています。

構造的なリスク

逆説を指摘しておきます。

検証してから入れる、と決めるほど、更新は遅れます。
その遅れの間に、プラグインの脆弱性の修正が出ることがあります。

だから、「検証してから」には期限を付けます。たとえば、通常は月次の作業日に、緊急の修正は数日以内に、と契約に書きます。検証は、更新を止める理由ではなく、更新を安全に早く入れるための工程です。

脆弱性が出たときの体制は、こちらで扱いました。

▶ WordPress 脆弱性のたびに社長が夜中に更新している制作会社へ──更新の方針、検証、緊急時の判断基準、お客様との取り決めで「体制」にする

よくあるQ&A

Q. WordPress のアップデートは、保守契約に必要？

メジャー更新を検証してから入れるなら、その作業の時間がかかります。保守契約に回数と範囲を書き、月額の根拠にします。

Q. WordPress 6.9 のままでも大丈夫？

WordPress.org のリリースの一覧では、最新の 7.1 系の最新版だけが安全に使える、という趣旨の注記があります（2026年11月5日確認）。6.9 のサイトは、検証環境で 7.1 を確かめる計画を立てます。

Q. メジャーアップデートを自動にしてもいい？

フォームや会員、ECのないシンプルなサイトなら、選択肢になります。その場合も、更新の後に表示を確かめる仕組みと、バックアップは必要です。

Q. ロールバックは、プラグインで十分？

公式のハンドブックは、サイト全体とデータベースのバックアップを前提にしています。道具に頼る前に、バックアップから戻せることを確かめておきます。

最後に

WordPress のメジャーアップデートは、年に複数回来る、予定できる作業です。

自動と手動を契約で分け、検証・互換確認・戻し方の3工程を回数で月額に割り付けた会社だけが、アップデートのたびの無償対応を、続く保守の売上に変えられるのです。

顧客への案内文と対応台帳は、期限対応の顧客案内キットにまとめています。

これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。

#Web制作会社 #WordPress #WordPressアップデート #WordPress保守 #WordPress7 #保守契約 #制作会社経営 #中小企業 #サイト保守 #ストック収入