WordPress保守は自分でできる？続けると難しくなるポイントと、任せる判断基準

WordPressの保守を自分たちで続けられるかどうかは、更新ボタンを押せるかどうかでは決まりません。判断の分かれ目は、保守作業を継続できるか、問題が起きたときに自分たちで判断・復旧できるかにあります。

この記事では、自分たちで保守を続ける場合に難しくなりやすいポイントと、外部に任せるかどうかを判断する基準の2つを扱います。ログイン保護や更新、バックアップといった対策そのものの中身、具体的な作業手順、料金については、この記事では扱いません。すでに更新を止めているサイトや、これから保守の体制を整えたいサイトのどちらにも当てはまる考え方を扱います。

WordPressサイトには継続的な保守が必要です。ただし、誰がどこまで担うかは選べます。この記事を読み終えたときに、今の体制でどこまで対応できるのかが分かる状態を目指します。まずは、自分が今どこまでを担っているのかを整理するところから始めましょう。

更新ボタンを押す、バックアップを取る、といった作業そのものは、自分でもできます。判断の分かれ目は、その作業を継続し、問題が起きたときに適切に判断できるかどうかです。

WordPress保守の基本は、大きく4つに整理できます。ログインページの保護、WordPress本体とプラグインの更新、復元できるバックアップの整備、セキュリティプラグインなどによる補完の4点です。

それぞれの中身、たとえばログインページを具体的にどう守るのか、セキュリティプラグインで何が検知できて何が検知できないのかは、基本対策と改ざん検知で確認できる範囲で扱っています。基本の対策がなぜ徹底されにくいのかについては、基本対策が続かないときに起きる乗っ取りの仕組みを参考にしてください。この記事では、その4点を自分たちで継続運用する場合に、どこで難しさが生じるかを見ていきます。

更新ボタンを押すこと自体は、決して難しい作業ではありません。実際に自分でクリックしている担当者もいます。ただし、それだけで保守が完結するわけではありません。

保守には、更新ボタンを押した後の確認や判断まで含まれます。まず、自分がどこまでの範囲を担っているのかを知っておくこと。具体的な範囲は次の章で整理します。次に、追いかけなければならない公式の期日を見続けること。押した後にサイトが崩れたとき、そのまま戻すべきか、原因の部分だけ戻して様子を見るべきか、それとも自分では触らず相談すべきかを判断すること。いざというときに元の状態へ戻せることを確かめておくこと。そして、担当者が替わっても同じように続けられる状態を保っておくこと。この5つまで含めて、継続的な保守運用と考える必要があります。

これらは、更新の頻度を上げたり、意識を高めたりすれば自然に解決する種類のものではありません。仕組みとして備えておく必要がある事柄です。自動更新を有効にしていたとしても、この5つがすべて消えるわけではなく、確認する作業は残ります。以下の章では、この5つのうち、自分たちで続けたときに特に難しくなりやすいポイントを、順番に見ていきます。

自分たちで担う保守範囲は、利用しているサーバーやサービス、契約内容によって変わります。まず自分が担っている範囲を知ることが、自分でできるかを考える出発点になります。

WordPressサイトの保守で「何をどこまで自分がやるべきか」を考えるとき、手がかりになるのがIPA（情報処理推進機構）が公開している「中小企業の情報セキュリティ対策ガイドライン」（出典: 中小企業の情報セキュリティ対策ガイドライン 第4.0版、2026年9月19日確認）です。同ガイドラインは、自社でサーバーを構えて運用している場合と、レンタルサーバーやクラウドサービスを借りている場合、ショッピングモールやASPのようなサービス上で運営している場合とで、事業者側が担う対策の範囲が異なるという整理を示しています。

ここで見落とされやすいのが、レンタルサーバーやクラウドサービスを借りている場合の線引きです。サーバーの設備そのものや基本ソフトの管理はサーバー会社が担いますが、その上で利用しているWordPress本体、プラグイン、各種設定、ログイン情報の管理は、原則として利用者側に残ります。「サーバー会社に任せているから大丈夫」という思い込みは、サーバー会社と自社の管理範囲を混同したときに起こりやすい誤解です。

もちろん、サーバー会社によっては、WordPressに関わる部分まで含めた運用支援サービスを別途提供している場合もあります。その場合は担う範囲が変わりますが、そうした契約をしていなければ、WordPress側の運用は自社側の担当として考える必要があります。まずは、自分が契約している内容が、サーバーの土台だけを指すのか、それとも中身の運用まで含むのかを確認するところから始めてください。

この線引きは、ショッピングモールやASPのようなサービス上でサイトを運営している場合には、また違った形になります。運営元があらかじめ用意した仕組みの中で更新やセキュリティ対策の一部を担ってくれることもありますが、その場合も「何を」「どこまで」担ってくれているのかは、サービスごとに異なります。自社の運用形態がどのパターンに当てはまるのかを最初に確認しておくと、以降の章で見る判断がしやすくなります。

サーバー会社の自動バックアップ機能や、契約しているサービスの自動更新機能など、サーバー会社やサービス提供者が担っている部分がある場合もあります。ここで大事なのは、それが何を担い、何を担っていないのかを把握しているかどうかです。

たとえば「バックアップは取れているはずだ」と思っていても、それがどの範囲を、どの頻度で、どこに保存しているものなのかを確認していなければ、いざというときに使えるかどうかは分かりません。「任せている」ことと「把握している」ことは、似ているようで別のことです。任せている部分があるからといって、自社側の管理責任がなくなるわけではありません。

一度、自分たちが担っている範囲と、サーバー会社や導入しているサービスが担っている範囲を、書き出してみることをおすすめします。書き出す作業そのものに正解の形式はありませんが、「何を」「誰が」「どこまで」の3つの観点で整理すると抜けにくくなります。この整理は、後段（自分で続けるか任せるかを決める基準）で判断の材料になります。

自分たちで保守を続ける場合に難しくなりやすいのは、更新・サポート情報を継続的に追うことと、更新後に不具合が起きた際の判断です。

WordPress本体について、公式にサポートされているのは常に最新版だけです。WordPress.orgは、セキュリティに関する考え方として、脆弱性が見つかった際の修正を提供する対象は最新版であることを明示しており（出典: WordPress.org「Security」、2026年9月19日確認）、古いバージョンへの修正の移植は、あくまで運営側の厚意によるものであって、保証された対応ではないという位置づけになっています。

しかも、その「最新版」は固定されたゴールではありません。WordPress本体は一定の間隔で新しいバージョンが公開され続けており、対応した後も、新しいバージョンが継続的に公開されます。つまり、自分で保守するということは、一度追いつけば終わる仕事ではなく、新しいバージョンが出るたびに対応を続ける必要があるということです。なぜ「最新版のみ」という方針なのかといえば、過去のすべての版に対して修正を配布し続けることは、提供側にとっても現実的ではないからです。

WordPress.org自身が公開している利用状況の統計（出典: WordPress.org「Statistics」、2026年9月19日確認）を見ると、最新版で運用されていないサイトが一定数存在することが分かります。これは自分たちだけが遅れているわけではないという意味では気休めになりますが、安心材料にはなりません。この統計はWordPress.orgへ通信するサイトの集計であり、全数ではない点にも注意が必要です。使用中のバージョンと最新版の差が大きくなるほど、後から追いつくときに一度に確認しなければならない変更点も増えていきます。小さな遅れのうちに追いつくほうが、負担は小さく済みます。

「保守にも期限があるのか」という疑問を持つ方もいるかもしれません。ここで言う期限は、契約上の保守の期限ではなく、ソフトウェアとして公式にサポートされる期間の話です。契約の期限については、保守を依頼している先、あるいはこれから依頼を検討する先に確認する事柄になります。

なお、WordPress本体の脆弱性がどのように公表され、修正版の適用をどれくらい急ぐべきかという判断は、脆弱性情報を受けた後に続ける確認の手順で扱っています。自動更新を有効にしていても、確認作業がなくなるわけではない、という点だけここでは触れておきます。

WordPress本体を常に最新の状態にしていても、それだけでは終わりません。WordPressはPHPという別のソフトウエアの上で動いており、PHPにも本体とは別に、独自の公式サポート期限があります。この期限は、WordPress本体の更新ボタンを押しても動きません。

WordPress.orgが示す推奨環境の情報でも、サポートが終了した古い環境のまま使い続けることは、脆弱性にさらされるおそれがあると注意喚起されています（出典: WordPress.org「Requirements」、2026年9月19日確認）。つまり、追いかけるべき対象は「WordPress本体」と「PHP」の少なくとも2つがあり、それぞれ別の場所で、別の時期に動いているということです。片方だけ追いかけていれば安心、というわけにはいきません。

サーバーの契約プランによっては、PHPのバージョンが自動的には上がらない設定になっていることもあります。本体を更新していれば十分だと思い込んでいると、PHP側の期限が過ぎていることに気づかないまま運用を続けてしまうおそれがあります。

自分のサイトで現在どのPHPバージョンを使用しており、いつまで公式サポートされるのか。その確認方法や判断の仕方は、PHPバージョンの確認方法で扱っています。確認した結果、PHPバージョンの更新が必要だと分かった場合の進め方は、PHPアップデートの方法を参考にしてください。ここで押さえておきたいのは、保守対象がWordPress本体だけではない、という点です。

WordPress本体やプラグインを更新した後、表示が崩れたり、機能が動かなくなったりすることがあります。このとき、対応方法はいくつかあります。

1つは、バックアップを使ってサイト全体を更新前の状態に戻す方法です。ただし全体を戻すと、直したかった別の更新まで一緒に巻き戻ってしまいます。もう1つは、原因になったプラグインなど一部分だけを一つ前の状態に戻し、開発元が修正版を出すのを待って改めて更新する方法です。こちらは、どの更新が原因かをある程度見当づける必要があります。そして3つ目は、自分では手を出さず、詳しい相手に相談する方法です。

どれを選ぶべきかを一律に決める基準はありません。原因を切り分けられるかどうか、部分的に戻すことでほかの機能に影響が出ないかどうかを見極める必要があり、この見極めこそが、自分で保守を続けるときに判断が難しくなりやすいポイントの1つです。複数の更新を一度にまとめて適用していると、原因の切り分けはさらに難しくなります。可能であれば少しずつ間隔をあけて適用し、そのつど表示や動作を確認するほうが、原因を追いやすくなります。

なお、これは更新後の互換性による不具合についての話であり、セキュリティ上の修正版を古い版に戻す判断とは別の話です。脆弱性の修正版を当てられない事情がある場合の考え方は、この記事では扱いません。

すでにサイトが表示されない、ログインもできないなど、今すぐ手を打つ必要がある状態になっている場合は、判断を悩んでいる時間そのものが負担になります。その場合は、自分で切り分けを試みる前に、詳しい相手へ早めに相談することをおすすめします。

普段は問題になりにくいものの、トラブル時や担当者交代時に不足が表面化しやすいものが2つあります。バックアップから復元できることと、手順や管理情報が特定の担当者だけに依存していないことです。

バックアップを取ることは、公的なガイドラインでも基本の対策の一つとして挙げられています。IPAの中小企業向けガイドラインが示す情報セキュリティ6か条にも、バックアップを取ることが含まれています。

ただし、取れていることと、必要なときにその時点の状態へ戻せることは、別の段階です。バックアップは「ファイルだけを取っているのか、データベースも含めているのか」「どのくらいの頻度で、いつの時点まで戻せるのか」「保存先はどこで、誰がどうやって戻す操作をするのか」という具体的な問いに答えられて、初めて実用的な備えになります。

これらの問いに即答できないまま「バックアップは取っているから大丈夫」と考えてしまうと、実際に必要になった場面で、想定していた形で戻せないという事態が起こり得ます。バックアップの仕組みを導入した時点では戻せる状態であっても、サイトの構成が変わった後は同じ手順で戻せるとは限りません。サーバー会社によっては、契約プランが変わるとバックアップの保存期間や対象範囲が変わることもあります。保存期間が短くなっていることに気づかないまま「バックアップはあるはず」と思い込んでいるケースもあるため、契約内容を定期的に見直すことも一つの備えになります。

取ることと戻せることを分けて考え、実際に復元できるか確認する機会を意識的に作っておくことが必要です。確かめる頻度に決まった正解はありませんが、少なくとも一度は、実際に戻す操作を試してみることをおすすめします。

戻す操作を試さないまま運用が続くことがあります。日常の業務に追われていると、問題が起きていない仕組みをわざわざ確認する優先度は上がりにくいものです。だからこそ、「取っている」という事実だけで安心してしまう前に、戻す確認だけは意識して予定に組み込んでおく価値があります。

自分たちで保守を続けていると、管理者アカウントのログイン情報、サーバーやドメインの契約名義、誰がどのプラグインを何のために入れたのか、更新の手順とうまくいかなかったときの戻し方といった情報が、担当者個人の頭の中や手元の資料だけに残りやすくなります。

これらの情報が特定の一人に偏っていると、担当者が異動したり退職したりした瞬間に、前の章まで見てきた「期日を追う」「更新後に判断する」「戻せることを確かめる」といった仕事が、急にできなくなります。複数の担当者や外部の業者が関わってきたサイトほど、誰がどのやり方を採用したのかが揃わなくなりやすい傾向もあります。

これは特定の相手のやり方が悪いという話ではありません。担当が一人、あるいは少人数に偏っている状態そのものが、引き継ぎの負担を大きくします。情報が個人に閉じている状態を放置していると、担当者本人が「辞める前に整理しよう」と思わない限り、誰も気づかないまま時間が過ぎていきます。口頭での引き継ぎだけに頼ると、伝えたつもりのことが伝わっていない、というずれも起こりやすくなります。ログイン情報そのものを記事や資料に書き残すことはおすすめしませんが、「どこに何の情報があるか」という所在だけは、担当者以外にも分かる形にしておくことができます。

「今の担当者が明日いなくなっても、この保守は続けられるか」を、一度自分たちに問いかけてみてください。答えに詰まる項目があるなら、それが担当者交代への備えが薄い部分です。管理情報の所在を書き出しておくことは、次に見る判断基準の材料にもなります。

この問いは、担当者が一人しかいない体制ほど答えにくくなります。複数人で分担していても、それぞれが違うやり方で管理していれば、結局は同じ弱さを抱えていることになります。担当者の頭数ではなく、やり方と情報がどれだけ共有されているかで、続けやすさは変わります。

自分で続けるか任せるかは、作業の難しさではなく、ここまで見た4つの課題に継続して対応できるかで決まります。全部を任せるか全部を自分でやるかの二択でもありません。

WordPress保守を自分で続けるべきか、それとも任せるべきかについては、一つの正解があるわけではありません。同じ問いに対して「できる」という答えも、「条件次第」という答えも、「やめたほうがよい」という答えも見かけます。答えが割れるのは、それぞれが前提にしている状況が違うからです。この記事の立場は、どの答えが正しいかを決めるのではなく、条件を具体的にすることです。

判断の軸になるのは、次の5つです。①どれだけ広い範囲を自分たちが担っているか（サイトの置き方で変わります）。②公式の期日を追い続ける人と時間が確保できているか。③更新後に何かが崩れたとき、戻すか待つか相談するかを判断できる人がいるか。④必要なときに戻せることを確かめているか。⑤担当者が替わっても続けられる状態になっているか。

この5つは互いに独立していません。たとえば、担う範囲が狭ければ期日を追う負担も軽くなりますし、担当者が複数いれば交代の影響も小さくなります。逆に、担う範囲が広いのに担当者が一人しかいない、という組み合わせは、負担が重なりやすい状態と言えます。

この5つすべてに「はい」と答えられるなら、自分たちで続けるという選択は十分に成り立ちます。対応が難しい項目がある場合は、その部分だけ外部に任せる方法もあります。サイトの規模や業種の大小で線を引く必要はありません。すべてを自分でやるか、すべてを任せるかという二択で考える必要もありません。

前の項目で対応が難しかった部分だけを外部に任せる方法もあります。たとえば、日々の更新作業は自分たちで行いながら、公式の期日を追い続ける部分と、更新後に崩れたときの判断だけを外部に持ってもらう、という分け方も考えられます。これはあくまで分け方の一例であり、特定のサービス内容を指すものではありません。

一部だけを任せると決めた場合に注意したいのは、どこまでを自分たちが持ち、どこから先を外部に任せるのか、その境目をきちんと書面にしておくことです。ここが曖昧なままだと、「相手がやってくれていると思っていた」「自分たちの担当だと思っていなかった」という抜けが、かえって増えてしまいます。

一部だけを任せれば必ずうまくいくというものでもありません。境目の取り決めが曖昧なままだと、一部を外に出したことでかえって責任の所在が見えにくくなる場合もあります。何を任せられるのか、費用がどのくらいかかるのかについては、保守サービスを提供している側に個別に確認することをおすすめします。

自分たちで続けると決めた場合、次にやっておきたいのは、ここまでの運用を継続するために、「誰が」「いつ」確認するかを決めておくことです。誰が公式の期日を見るのか、誰が更新後の判断をするのか、戻せることをいつ確かめるのかを、担当者の名前と時期を添えて決めておきます。

「どれくらいの頻度で見ればいいのか」という疑問には、決まった回数で答えることはできません。WordPress本体、プラグイン、PHPなど、追いかける対象がそれぞれ別の時期に動くため、その動きに合わせて確認の時期を決めることになります。回数を先に決めるのではなく、追う対象の動きに合わせて時期を決める、という順番で考えてください。

決めた内容は、口頭で共有するだけでなく、簡単にでもメモや書面に残しておくと、前の章で見た「担当者が替わっても続くか」という備えにもつながります。

点検の抜け漏れを防ぐ道具としては、IPAが公開している「安全なウェブサイトの運用管理に向けての20ヶ条」（出典: 安全なウェブサイトの運用管理に向けての20ヶ条、2026年9月19日確認）があります。2019年に更新された資料ですが、IPAの中小企業向けガイドラインも、運営が始まった段階ではこの20ヶ条を参照して未対応の項目に対策するよう案内しています。全項目をここで並べることはしませんが、自分たちで続けると決めたら、一度目を通しておく価値はあります。保守で続ける作業の全体像を改めて確認したい場合は、保守で続ける作業の全体像も参考になります。

WordPress保守を自分たちで続けられるかどうかは、担う範囲を把握し、更新・サポート情報を追うこと、更新後に判断すること、必要時に復元できること、担当者が替わっても継続できることに対応できるかで決まります。すべてに対応できるなら自社で続ける選択ができます。難しい項目がある場合は、その部分だけ外部に任せる方法もあります。

自分で続けている今の体制を見直したい、あるいは一部だけでも任せられる先を探したいという場合は、WordPress保守・セキュリティ対策の詳細を見るをご覧ください。

WordPress保守を担当するビークリエイトのチームの知見をもとに、本記事を構成しています。詳しくは会社概要をご覧ください。