WordPress保守を自分でやる手順チェックリスト|外注に切り替える判断基準まで

「WordPressの管理画面を開くたびに、更新通知が溜まっていく——」

制作したサイトを納品したあと、あるいは自社サイトを引き継いだあと。保守は自分でやろうと決めたものの、何を・どのくらいの頻度でやればいいのか自信が持てない。そんな方は少なくありません。

結論から言えば、会社案内やブログのような小規模で機能が限定されたサイトなら、保守を自分で回すことは可能です。やるべき作業は決まっていて、手順を踏めば失敗のリスクは大きく下げられます。

ただし、EC・予約・会員・決済・外部API連携などを含むサイトや、「毎月・毎週続けられるか」「メジャーアップデートやPHP切り替えといった”事故りやすい場面”に対応できるか」は別の問題です。つまずくと、かえって復旧に大きなコストがかかることもあります。

この記事では、頻度別チェックリスト更新事故のリスクを下げる手順「どこまで自分でやり、どこから外注に切り替えるか」の判断基準を実務ベースで整理しました。制作会社・フリーランスの方はクライアントのサイトを、社内のWeb担当者の方は自社サイトを守るためのガイドとしてお使いください。

1. WordPress保守を自分でやるとは?作業を「頻度別」に整理する

まず押さえておきたいのは、WordPress保守は「更新ボタンを押すこと」だけではないという点です。

保守とは、本体・テーマ・プラグインの更新に加え、定期的なバックアップ、更新前の検証、表示やフォームの動作確認、ログやセキュリティの監視まで含めた継続的な運用業務全体を指します。ひとつの作業ではなく、頻度の違う作業の積み重ねだと考えるとイメージしやすくなります。

なぜ、そこまで手をかける必要があるのか

W3Techsの調査によると、WordPressは世界のWebサイトの約4割で使われる圧倒的シェアのCMSです。普及率が高いほど攻撃者にとって狙う価値のある対象になりやすい側面があります(ただし個々のサイトの実際のリスクは、更新状況や認証・アクセス制限などの設定で大きく変わります)。

さらに見落とされがちなのが脆弱性の発生源です。報告されるWordPressの脆弱性の多くは、本体よりもサードパーティ製のプラグインやテーマに起因し、各種調査では9割前後とされます(これは「報告された脆弱性の内訳」で、実際の侵害原因の9割という意味ではありません)。いずれにせよ「本体さえ更新すれば安全」ではなく、プラグイン・テーマまで含めた管理が必要です。

「うちは小さなサイトだから狙われない」という考えも、残念ながら誤解です。多くの攻撃は自動化されたスキャンで無差別に行われるため、規模や業種を問わず、踏み台にされたり、スパムページを勝手に設置されたりする被害が起こり得ます。

そして、保守を後回しにする本当の怖さは、問題が起きたときの復旧コストが、平時の予防的な対応よりはるかに大きくなりやすいことです。日頃の更新やバックアップを積み重ねておけば軽微な手間で済んだはずが、改ざんや長期放置による大規模な不具合になると、原因調査からやり直しになり費用も時間も膨らみます。バックアップがなければ、最悪の場合は元に戻せなくなることも。保守は損害を補償する「保険」ではなく、予防・検知・復旧のための日常的な備えだと考えておくのが正確です。

保守作業を「頻度別」に俯瞰する

やるべきことを頻度で整理すると全体像がつかみやすくなります。以下は一例です——ECサイトと会社案内サイトでは必要な頻度が変わるため、サイトの重要度に応じて調整してください。

頻度 主な作業 目的
随時(通知が来たら) 緊急性の高いセキュリティ更新の確認・適用 脆弱性を突かれる前に塞ぐ
週次 バックアップの確認、表示・フォーム動作チェック、スパム処理 「壊れていないか」を早期に把握する
月次 本体・テーマ・プラグインの更新(検証のうえ)、不要プラグイン整理、ログ確認 最新の状態を保ち、不具合の芽を摘む
半期〜年次 PHPバージョンの確認、認証(MFA・パスワード)の見直し、復元テスト、不要データ整理 中長期のリスク(環境変化)に備える

次章から、この頻度別に「具体的に何をするのか」をチェックリスト形式で見ていきます。

2. 【頻度別チェックリスト】自分でやる保守の具体作業

ここが本記事の中心です。運用状況と照らし合わせ、抜け漏れがないか確認してください。

随時(更新通知が来たとき)

  • WordPress本体・プラグイン・テーマの更新通知の内容を確認する
  • セキュリティ修正を含む更新は、内容と影響を確認して優先度を判断し対応する(悪用が確認されている・認証なしで攻撃可能なものほど急ぐ)
  • 利用中のプラグインに重大な脆弱性が報告されていないか確認する(配布元、WordPress.org、セキュリティベンダーやホスティング会社の通知など。管理画面の通知だけでは把握できない場合があります)

セキュリティ更新は時間との勝負になることがあります。ただし「何でも即適用」ではなく、内容と影響を確認して優先度をつけるのが実務的です。

週次でやること

  • バックアップが正常に取得できているか確認する(ファイルとDBの両方があるか、保存先が本番と分かれているか、必要な世代が残っているか)
  • お問い合わせフォームをテスト送信する(送信完了画面だけでなく、実際にメールを受信できるか・迷惑メール扱いされていないか・自動返信や管理画面への保存まで)
  • 主要ページの表示崩れがないか確認する(PC・スマホ両方で)
  • 管理画面に問題なくログインできるか確認する
  • スパムコメント・スパム登録を確認して処理する

フォームの不具合は、気づかぬうちに「問い合わせが1件も届かない」状態を招きます。確認頻度は、問い合わせが売上に直結するなら毎日や自動監視、閲覧が少なければ月次でも、と重要度に応じて決めましょう。

月次でやること

  • WordPress本体・テーマ・プラグインを(検証のうえ)更新する ※手順は次章
  • 使っていないプラグイン・テーマを停止し、不要なものは削除する
  • リンク切れがないかチェックする
  • 表示速度に大きな低下がないか確認する
  • サーバーのエラーログ・アクセスログに異常がないか確認する
  • 登録ユーザーの権限を棚卸しし、不要なアカウントを整理する

半期〜年次でやること

  • 利用中のPHPバージョンと、そのサポート期限を確認する
  • 認証まわりを見直す(管理画面に多要素認証を設定、使い回さない長いパスワードとパスワードマネージャーを使用、共有アカウントは避け、退職・漏えい時は速やかに変更)
  • バックアップから実際に復元できるか、テスト環境で試す
  • 不要なメディア・古いデータを整理する(※メディアはテーマ設定やカスタムフィールド等から参照されている場合あり。削除前にバックアップと参照確認を)

意外と見落とされがちなのが「バックアップからの復元テスト」です。取っていても、いざ復元できなければ意味がありません。年に一度でも実際に戻せることを確認しておくと安心です。

まずは無料でご相談ください。現状のサイトURLをお送りいただくだけで、初期の状況把握が可能です。1営業日以内にご返信します。

3. 更新作業を安全に行う手順(更新事故のリスクを下げる4ステップ)

「更新するのが怖くて、通知が溜まったまま触れない」——他社制作サイトの修正・改修をお受けする中でも、実際によく目にするお悩みです。その不安の多くは「本番でいきなり更新して壊れたら…」というもの。裏を返せば、手順を踏めば不安の大部分は解消できます。

ステップ1:バックアップを取得する

更新前に、WordPress本体(ファイル)とデータベースの両方をバックアップします。

ここで注意点を。バックアップに戻すと、取得後に追加された注文・問い合わせ・会員登録・投稿などは失われる可能性があります。ECや会員サイトのように動的にデータが増えるサイトでは、「戻せる」ことと「損失なく戻せる」ことは別だと意識しておきましょう。

ステップ2:検証環境(ステージング)で更新をテストする

本番に近い構成の複製環境で、先に更新を試します。レンタルサーバーのステージング機能や複製用のプラグインを使うと、比較的手軽に用意できます。ここで表示崩れやエラーが出れば、本番に影響を与えずに対処できます。

なお、完全に同一の環境の再現は難しく(PHP拡張・キャッシュ・外部APIの差で、ステージングで正常でも本番で失敗することがある)、検証は「事故の可能性を下げる」ものです。また複製環境には顧客の個人情報が入るため、Basic認証やIP制限、検索エンジン非公開、実メール・決済のテスト化、使用後の削除といった配慮が要ります。

ステップ3:問題がなければ本番環境に反映する

検証環境で問題がないことを確認できたら、本番環境を更新します。このとき、ステージングのデータベースをそのまま本番へ上書きしないよう注意してください。上書きすると、ステージング作成後に本番で増えた注文・投稿・会員情報などが消える恐れがあります。基本は「本番側でも同じ更新作業を行い、ステップ2で見つけた修正を反映する」形で進めます。

ステップ4:反映後にチェックする

更新後は、次の順で確認します。

  • 一度にまとめて更新しない:本体・テーマ・プラグインを一括更新すると、問題時の原因特定が難しくなります。できれば分けて更新し、そのつど確認して記録を残します
  • キャッシュをクリアする(サーバー・プラグイン・CDN)。残っていると「直っていないように見える」など判断がぶれます
  • 重要な導線から優先して確認する:ログイン、フォーム送信、決済、検索、会員機能など「壊れると困るところ」から先に見ます
  • ログを監視する:画面が正常でも、ログに警告が出続けていることがあります。監視期間はアクセスや業務の周期に応じて決めます(高トラフィックなら反映直後の数十分〜数時間、更新の少ないサイトなら数日など)

本番でいきなり更新しない

検証を省いて本番を直接更新すると、非互換や環境差による不具合にその場で対処せざるを得ません。特にメジャーアップデートでは検証環境での確認を省略しないことをおすすめします(ワンクリック復元が使える環境など、条件次第で本番で段階的に更新する運用もありますが、その場合もバックアップは必須です)。

なお、放置した結果として実際にどんなトラブルが起きるのかは、別記事「WordPress保守を放置していませんか?よくあるトラブル事例とご相談のタイミングを解説」でも具体的に紹介しています。あわせてご覧ください。

4. 自分でやると詰まりやすい・危険なポイント

手順どおりに進めても、いくつか「専門知識がないと対応が難しい場面」があります。ここを事前に知っておくだけでも、判断を誤りにくくなります。

メジャーアップデートの非互換

本体のメジャーアップデートでは、テーマやプラグインが追従できておらず、表示崩れや機能停止が起きることがあります。特に更新が止まっているプラグインや、独自制作のテーマを使っている場合は注意が必要です。

PHPバージョンの切り替え(「何もしてないのに壊れる」の主な原因のひとつ)

WordPressはPHPで動いています。このPHPには寿命があり、PHP公式のサポート情報によれば、各バージョンのサポートは原則リリースから約4年で終了します(前半2年がアクティブ、後半2年はセキュリティ修正のみ)。

問題は、サポートが切れた古いPHPは、利用中のホスティング事業者によっては提供終了や新バージョンへの移行が行われることがあるという点です。すべてのサーバーが自動で切り替えるわけではありませんが、事前告知や猶予期間の案内を見落としたまま放置していると、ある日「何も触っていないのにサイトが真っ白に」という事態が起こり得ます。原因は、古いテーマやプラグインが新しいPHPに対応していないこと。多くは「サーバーからの重要なお知らせに気づけなかった」ことが引き金です。

とりわけPHP 7系から8系のような世代をまたぐ移行は、削除された関数や動作変更が多く、影響が出やすい変更でした。WordPress公式の推奨環境では2026年時点でPHP 8.3以上が推奨とされ、広く使われてきたPHP 8.2もPHP公式では2026年12月31日にセキュリティサポート終了が予定されています。ただし、WordPress本体がPHP 8.3を推奨していても、利用中のテーマ・プラグイン・独自コードが対応しているとは限りません。「公式が推奨=サイト全体の互換性が保証される」ではない点に注意が必要です。

プラグイン競合・自作テーマの非推奨コード

複数のプラグインが干渉する「競合」や、非推奨コードがPHP更新で完全に動かなくなるケースもあります。厄介なのは、原因がひと目では分からない点です。切り分けの基本は全プラグインを止めて一つずつ有効化し表示を確認する方法ですが、これは本番ではなく必ず検証(ステージング)環境で行ってください。本番で止めると決済・フォーム・会員機能などが停止します。原因がテーマ・サーバー設定・キャッシュ・外部サービス側にある場合はこの方法だけでは特定できず、ログやエラー表示、直前の変更履歴と突き合わせる必要があります。非対応が見つかれば、データや設定の移行を含めて代替への入れ替えを検討します。

PHP以外の「何もしてないのに壊れる」外部要因

サイト側を触っていなくても不具合は起こります。SSL証明書の期限切れ外部サービス(地図・SNS・決済など)の仕様変更やAPI制限キャッシュ・CDNの設定などが原因で、表示崩れだけでなく、決済停止やデータ欠落といった事業影響が生じることもあります。原因が一つとは限らず、切り分けに知識が要る点が難しさです。

属人化のリスク

そしてもうひとつ、技術以前の落とし穴が属人化です。「作った担当者が退職して社内に詳しい人がいない」「サーバーやFTPの情報が分からない」——こうした状態は規模を問わず起きます。トラブル時に誰も手を出せない状況は避けたいところです。

こうした場面に不安があれば、苦手な部分だけスポットでご相談いただけます。他社制作のサイトでも状況を確認のうえ対応します。お気軽にお問い合わせください。

5. 「自分でやる」と「外注する」の判断基準

ここまで読んで「思ったよりやることが多い」と感じた方もいるかもしれません。まず、作業の一部は自動化やマネージド環境で軽減できます。自動バックアップやステージング機能を備えたホスティングを選ぶ、死活監視ツールを入れる、といった工夫で手作業は減らせます。そのうえで大切なのは、すべてを自分で抱え込む必要はないこと。自分でやる・自動化する・任せるを切り分けるのが現実的です。

自分でやる場合と外注する場合の比較

観点 自分でやる 外注する
費用 外注費はかからない(が、作業時間という見えないコストはかかる) 契約範囲に応じた月額・スポット費用が発生
時間 毎週・毎月の作業時間が発生 本業に時間を回せる(発注・情報共有の手間は残る)
リスク対応 事故・緊急時に自力対応が必要 実績ある外注先なら検証・復旧を頼れる(障害復旧が別料金のことも)
専門性 PHP切替や競合の切り分けは難しい 専門的な原因調査・修正に対応(外注先の力量による)
属人化 担当者不在で止まるリスク 外注先・担当者への依存という別の属人化も。資産は自社保有を

外注費用の相場は、各社の公開料金を見ると、定期契約でおおむね月額1万〜5万円程度、スポットで1回1万〜10万円程度が目安です。ただしこの幅は対応範囲(更新のみか、監視・障害復旧・改修まで含むか)やサイト規模で大きく変わり、同じ「保守」でも中身はまちまちです。金額だけでなく、何がどこまで含まれるかをそろえて比べましょう。そのうえで「自分の作業時間」や「事故時の復旧コスト」まで含めると、印象は変わってきます。

判断のための視点

どちらを選ぶか迷ったら、次の点で整理すると考えやすくなります。

  • サイトの重要度と「止まったときの許容範囲」:EC・会員・売上直結のサイトほど損失が大きい。「何時間以内に復旧が必要か」「何時間分のデータなら失っても耐えられるか」を具体的に考えると、必要な体制が見えます
  • 扱う情報の重さ:個人情報や決済情報を扱うほど、求められる管理レベルと責任が上がる
  • 社内のリソースと専門性:PHPやサーバーまわりを自信を持って触れる人がいるか
  • 営業時間外の対応と機会損失:夜間・休日に止まったとき誰が対応するか。保守の時間を本業に回せる価値
  • 属人化:いま担当者以外は誰も把握していない状態になっていないか

制作会社・フリーランスの方へ

クライアントのサイトを自分で保守していると、保守が増えるほど制作という本業を圧迫し、スケールしにくくなります。「制作は得意だが、保守や緊急対応は正直しんどい」——他社制作サイトのご相談をお受けする中でも、こうした声はよく届きます。保守そのものをやめる必要はありません。苦手な領域や手の回らない部分だけを外注のバックヤードに任せ、クライアントとの窓口は自社が持つ体制も選べます。

社内Web担当者の方へ

兼任で管理していると保守は後回しになりがちで、担当者の異動・退職で情報が宙に浮くリスクもあります。日常の更新は自社で回しつつ、専門性の高い部分や緊急時の相談先を確保しておくと、安心して運用を続けられます。

判断に迷う場合は、現状をお聞きしたうえで対応可能な範囲をご案内します。Chatworkでの気軽なご相談にも対応しています。

6. 外注に切り替えるときの進め方・準備するもの

外注を決めたら、進め方の準備と、依頼先を選ぶ観点を整理しておきましょう。

相談前に準備しておきたいもの

特に他社が制作したサイトの場合、次の情報が役立ちます。

  • WordPress管理画面のアクセス(既存の共有管理者を渡さず、外注先専用アカウントを作り最小限の権限を付与するのが安全)
  • サーバーへの接続情報(平文FTPではなくSFTP/SSH鍵認証を優先。SSHのrootは共有しない)
  • ドメイン・サーバーの契約情報
  • 直近の変更履歴(何を・いつ触ったか)
  • バックアップの有無と保存場所

認証情報を渡すときは、メールやチャットの本文にパスワードをそのまま書かないのがおすすめです。パスワードマネージャーの共有機能などを使い、作業後は共有解除・アカウント無効化を。

「どこにあるか分からない」状態でも、その洗い出しからご相談いただけます。現状のサイトURLは初期の相談や外形的な把握に役立ちますが、正確な原因調査には管理画面やサーバーの権限が必要です。「相談開始はURLでOK、正式な調査には権限が必要」と分けて考えてください。

「スポット」と「定期保守」、どちらで頼むか

外注には大きく2つの頼み方があります。不具合時や特定作業をその都度頼むスポット対応と、月額で継続的に更新・バックアップ・監視を任せる定期保守です。「普段は自分で回せるが相談先だけ確保したい」ならスポット、「更新作業から解放されて本業に集中したい」なら定期保守。まずスポットで試し、相性を見て定期契約に移る進め方も現実的です。

ただし注意点として、通常のスポット契約では、緊急時に必ず優先対応してもらえるとは限りません。障害時は環境の確認から始まるため、初動に時間がかかることもあります。売上に直結する重要サイトで相談先を確保したいなら、事前に現状を把握してもらう・緊急時の対応条件を決めておくと安心です。

依頼先を選ぶときの観点

  • 他社制作サイトへの対応可否:自社で作っていないサイトのコードも読み解けるか
  • 契約に含まれる範囲:更新・バックアップだけか、障害復旧・改修・緊急/時間外対応まで含むか
  • 初動と「一次回答」の中身:返信の速さと復旧の速さは別物。一次回答が受付連絡か、対応可否・原因の見立てかを確認
  • 検証・記録・契約面:修正前後のバックアップと影響確認、作業報告、秘密保持、再委託の有無、解約時のデータ返却など
  • コミュニケーションのしやすさ:専門用語を噛み砕いて説明してもらえるか

コーディングコネクションの場合

コーディングコネクションでは、自社制作に限らず、他社が制作したWordPressサイトの修正・改修にも対応しています。デザインデータ(PSD/AI/XD/Figma)や参考URL、現状のサイトURLをお送りいただくだけで、仕様書がなくてもご相談を始められます(正式なお見積り・作業には、あらためてコード・管理画面・サーバーの確認や要件のすり合わせが必要です)。

ベトナムのオフショア体制と日本人ブリッジSEによるチェックを組み合わせ、コストを抑えながら品質管理を行っているのが特徴です。現状のURLをお送りいただければ、1営業日以内に一次回答(受付のご連絡、対応可否の目安、次に必要な情報のご案内)をいたします。WordPress専用の保守プランもあり、対応範囲や費用は状況を確認のうえご案内します。なお、極端に古いPHP環境、正規ライセンスのないテーマ・プラグイン、マルウェア感染、ソースや権限が揃わないケースなどでは、対応可否の判断や追加調査が必要になる場合があります。

まとめ

WordPressの保守は、正しい手順とチェックリストがあれば、小規模で機能が限定されたサイトなら自分で回していくことも可能です。一方で、続けることの負担や、専門知識が必要な「事故りやすい場面」があるのも事実です。

この記事のまとめ

  • 保守は「更新」だけではない。頻度別(随時・週次・月次・半期〜年次)に作業を整理すると、抜け漏れを減らしやすい
  • 更新は4ステップで、事故のリスクを下げて行う。バックアップ → 検証環境でテスト → 本番反映 → 反映後チェック(キャッシュ・重要導線・ログ)
  • 詰まりやすいのは、メジャーアップデート・PHP切替・プラグイン競合・属人化。「何もしてないのに壊れる」は、PHPやサーバー環境の変化も主な原因候補になる
  • すべてを自分で抱えなくていい。サイトの重要度・復旧の許容範囲・リソース・機会損失・属人化リスクで判断し、自動化や、苦手な部分だけ任せる選択肢もある

大切なのは、無理なく続けられる体制をつくることです。

WordPressの更新・修正・保守でのお困りごとや、コーディングのご依頼など、どんなことでもお気軽にご相談ください。他社が制作したサイトでも、状況を確認のうえ対応いたします。まずは現状のURLやご希望をお送りいただければ、1営業日以内にご返信します。

※本文中の市場シェア・脆弱性傾向・PHPサポート期限などのデータは、W3Techs、WordPress公式情報、PHP公式情報、および複数の関連調査をもとに、一般的な傾向として整理したものです。個別サイトの状況によって最適な対応は異なります。