更新通知を「触ると壊れそう」で放置していませんか。あるいは「自動更新オンだから安心」と思っていませんか。WordPressの事故は、更新を当てるかどうかではなく「壊さずに戻せる状態で当てたか」で決まります。
この記事では、株式会社六（Roku inc.）がWordPress保守で実践する「ステージング検証→メンテナンスモード→ロールバック前提」の安全な更新手順を、非エンジニアの担当者向けに解説します。あわせて、自動更新を安易に勧めない理由と、自社で回すか更新代行に出すかの判断軸も示します。
WordPressの更新を放置するとどうなるか
放置で本当に怖いのは、コア本体ではなくプラグインです。WordPressの更新は4種類あり、放置リスクも異なります。
| 更新の種類 | 主な役割 | 放置すると起きること |
|---|---|---|
| コア（本体） | 本体の機能・セキュリティ | 既知の穴が残る |
| プラグイン | 機能拡張（フォーム・SEO・EC等） | 脆弱性悪用・互換性切れ |
| テーマ | デザイン・表示制御 | 表示崩れ・脆弱性の温床 |
| PHP | サイトを動かす言語 | 旧PHPでプラグインが動かない |
穴はプラグインに集中している
「本体を上げないと危ない」と思われがちですが、実際の脆弱性はプラグインに集中しています。
- 2024年報告の脆弱性はプラグイン由来96%、テーマ由来4%、コア本体はわずか7件（全体の0.09%未満）（出典：patchstack.com）
- 2024年の新規脆弱性は7,966件（前年比+34%、1日平均約22件）、うち43%は「認証不要」＝ログインせず外部から直接攻撃できる（出典：patchstack.com）
- 2024年にマルウェア感染したサイトは50万件以上（出典：patchstack.com）
放置されたサイトは、攻撃者にとってログイン情報すら不要な、開いたままのドアになり得ます。改ざんやセキュリティの全体像はWordPressのセキュリティ対策で扱います。
ただし正直にお伝えすると、「更新さえすれば安全」とは言い切れません。 報告された脆弱性の33%は公開時点でパッチが未提供でした（出典：patchstack.com）。セキュリティプラグインのファイル自体がマルウェアに改ざんされ潜伏した事例もあります（出典：kaspersky.com）。だからこそ更新だけに頼らず、「バックアップ・監視・戻せる設計」をセットで持つ必要があります。
「とりあえず自動更新」が危険な理由
自動更新は、状況次第で正解にも事故の原因にもなります。まず、自分のサイトの自動更新がどう動いているかを正確に把握している担当者は意外と少ないのが現実です。
自分のサイトの自動更新範囲を把握していますか
WordPressの自動更新は作成時期で挙動が変わります。
- 5.6以降に作成：コアのマイナー・メジャー更新の両方が対象になり得る
- 5.6以前に作成：コアのマイナー更新のみが対象
- デフォルトはコアのマイナー更新＋翻訳ファイルのみ。プラグイン・テーマの自動更新は標準では無効（5.5以降、個別にオン可）
（出典：ja.wordpress.org / kinsta.com）
鍵は「マイナー」と「メジャー」の違いです。マイナー更新は後方互換を保った修正中心で自動でも比較的安全ですが、メジャー更新やプラグインの自動更新は互換性・依存が崩れ、サイトが真っ白になる「白画面（PHPエラー）」を起こすことがあります。なお白画面の発生率を示す統計はないため、「無検証の自動適用が事故を招き得る」というメカニズムとして理解してください。
オンにしてよい範囲／避ける範囲の切り分け
角度をはっきりさせます。当社は「自動更新は絶対ダメ」とは考えていません。 脆弱性の96%がプラグイン・テーマ由来で感染サイトは50万件超（出典：patchstack.com）。手が回らず放置するくらいなら、自動更新で当て続けるほうがはるかに安全です。問題は自動更新そのものではなく、「依存が多い・止められないサイトで、検証なしに当てること」です。
| 状況 | 推奨スタンス |
|---|---|
| 小規模・依存が少ない・多少止まっても許容 | コアのマイナー自動更新＋セキュリティ監視で十分なことが多い |
| EC・予約・問い合わせなど止められない／依存が多い | メジャー更新・主要プラグインは手動＋ステージング検証 |
壊さないWordPress更新手順（5ステップ）
事故るサイトと無事故のサイトを分けるのは、テクニックではなく「戻せる状態を作ってから当てる」手順設計です。当社が実際に踏む5ステップを紹介します。
- バックアップとステージング環境の用意：完全バックアップ（DB＋ファイル）を取得し、本番と同構成の検証用コピーサイト（ステージング）を用意する。本番でいきなり当てるのは、リハーサルなしの本番公演と同じです。
- ステージングで検証更新：先に更新を当て、(1)主要ページの表示崩れ、(2)フォーム・予約・決済などお金と顧客に直結する機能、(3)管理画面のログイン・編集を確認。ここで問題が出れば本番は無傷です。
- メンテナンスモードで本番をクローズ：検証通過後、本番にメンテナンスモードを表示し、中途半端な状態を訪問者に見せず、更新中の不整合を防ぐ（詳細は次章）。
- 本番更新と動作確認：本番に当て、ステップ2と同じ3観点（表示・主要機能・管理画面）を確認。済んだらメンテナンスモードを解除する。
- ロールバック前提（戻せる状態を必ず確保）：万一不具合が出ても、ステップ1のバックアップから即座に戻せる状態を保つ。「戻せること」を確保してから当てる——この前提の有無で事故時の被害が天と地ほど変わります。
メンテナンスモードの正しい使い方
メンテナンスモードは「作業中の画面を出す」だけではなく、やり方を間違えるとSEO（検索順位）に悪影響が出ます。
出し方と、SEOで気をつける「503」
表示方法は主に3つ——専用プラグイン／.htaccess／functions.phpです。どの方法でも重要なのは、検索エンジンに返す「HTTPステータスコード」です。Google公式は、計画的なダウンタイムでは404や200ではなく「503（Service Unavailable）」を推奨しています（出典：developers.google.com）。503は「今は一時的に止まっているが、また戻る」という正しいシグナルになります。
さらにRetry-Afterヘッダーで再クロールの目安時期を伝えられます（出典：yoast.com）。あわせて、robots.txtだけはアクセス可能に保つこと。robots.txtまで503にすると、クローラーが状況を正しく判断できません（出典：developers.google.com / yoast.com）。
短時間なら順位への影響はほぼありません。各SEO媒体の運用目安では、10〜15分程度なら影響はほぼなく、503は長くても1〜2日まで、1週間以上続くとインデックス削除（順位下落）のリスクがあるとされます（出典：yoast.com）。これらはGoogleが明示した閾値ではなく媒体側の目安なので、レンジとして捉えてください。長時間メンテが避けられない場合は、事前告知と管理者だけがアクセスできるIP制限を併用すると安全です。
自社で更新するか、更新代行に出すか
正直にお伝えすると、すべてのサイトが代行に出すべきわけではありません。 どちらが正しいかはサイトの状況で決まります。費用感や範囲はWordPress保守の全体像でまとめていますが、まずは判断軸を整理します。
| 自社で回せる条件 | 更新代行が向く条件 |
|---|---|
| 依存プラグインが少ない | 依存が多く互換性リスクが高い |
| 更新頻度が低い | 頻繁に更新が必要 |
| 多少止まっても許容できる | EC・予約など止められない |
| 検証・バックアップを回せる人がいる | 回せる人材がいない／属人化している |
依存が少なく停止許容度の高い小規模サイトなら、コアの自動更新＋無料のセキュリティプラグイン（中小サイトは無料版で足りることが多い）で内製運用が成り立ちます（出典：wordpress.org / owlcamp.jp）。外注すれば月1〜5万円前後の固定費が発生します。不要な固定費をかけないのも立派な経営判断です。逆に、止められないサイトや属人化が進んだ運用は、事故時の損失が固定費を上回ります。判断に迷う場合は自社運用と外注の比較もご覧ください。
当社の更新保守：AIによる常時監視・分析 × 人間の審美眼
当社は福岡・北九州を拠点に、創業から12年、WordPressの構築・移行・保守に取り組んできました（出典：6-inc.com）。特徴は、「AIによる常時監視・分析 × 人間の審美眼」で、事故が起きる前に更新を当てること。機械的な監視で脆弱性や更新の必要性を検知しつつ、「当てる/待つ」の判断と表示崩れの確認は人の目で行います。前述のとおり脆弱性の33%は更新だけでは防げないため、監視とロールバック前提をセットで設計しています。
なお当社は「何でも全部代行します」とは言いません。発送業務やカスタマー対応のフル人手代行は範囲外と正直にお伝えしています。できること・できないことを明確にするのも、長く付き合う保守には必要だと考えています。更新を放置している、または触るのが怖いなら、まずはWordPress保守の無料診断で現状を把握することをおすすめします。
よくある質問
更新はどのくらいの頻度でやるべき？
セキュリティに関わるコアのマイナー更新やプラグインの脆弱性修正は、できるだけ早く。新規脆弱性は1日平均約22件報告されています（出典：patchstack.com）。一方メジャー更新は急がず、ステージングで検証してから当てます。「セキュリティ修正は早く、大型更新は慎重に」が基本です。
更新したら表示が崩れた。すぐ戻せる？
更新前に完全バックアップを取り、ロールバックできる状態にしてあれば戻せます。バックアップなしで本番直更新だと、戻すのが困難になります。「戻せる状態を作ってから当てる」が最も伝えたい点です。
メンテナンスモード中はSEOに影響する？
短時間（10〜15分程度）なら影響はほぼありません。HTTP 503を返し、Retry-Afterで再訪時期を伝え、robots.txtはアクセス可能に保てば、Googleは「一時的な停止」と正しく判断します（出典：developers.google.com / yoast.com）。1週間以上の長期化は順位下落リスクがあるため避けてください。
自動更新は全部オフにすべき？
いいえ、一律オフは誤りです。脆弱性の96%はプラグイン・テーマ由来で、放置のほうが危険です（出典：patchstack.com）。小規模・低依存はコアのマイナー自動更新＋監視で十分なことが多く、ECや依存の多いサイトはメジャー更新を手動＋検証にする切り分けが現実的です。
更新代行の費用相場は？
対応範囲で幅がありますが、月額1〜5万円前後が中心。最低限なら月額1万円前後、セキュリティ・サポート充実型で月額3〜5万円が目安です（出典：owlcamp.jp）。単発のバージョンアップ（検証環境込み）は総額5〜10万円程度の例もあります（出典：site-hikkoshi.com）。価格は改定され得るため、レンジの目安としてご確認ください。
WordPress更新は、結局「壊さず戻せる状態で当てられるか」に尽きます。更新を放置している、あるいは触るのが怖いなら、そのまま開いたドアを閉めるところから始めましょう。
