WordPressの保守案件は、更新作業を淡々と続けていれば終わるように見えます。ところが実際に負っている範囲は、契約書の一行だけでは決まりません。壊れたときに誰がどこまで動くのか、弱点の情報をどこまで追うのか、使う人からの連絡をどこで受け止めるのか。この記事では、公的な資料をもとに、保守を受ける側が事前に決めておきたい範囲を整理します。

1. WordPressの保守で一番重いのは壊れたときの負担

更新作業そのものより重い判断

WordPressの保守を引き受けるとき、最初に目に入るのはコア・テーマ・プラグインの更新作業です。しかし実際に案件の中で重みを持つのは、壊れたときにどこまで自分が動くのかという判断のほうです。更新を止めていた期間や、動作確認の範囲によって、負う作業量は大きく変わります。

この重さを言葉にする手がかりが、IPAが毎年公表している情報セキュリティ10大脅威です。組織向けの脅威の中で最も上位に置かれているのは、データを使えなくして金銭を要求する攻撃(ランサム攻撃)による被害です。2016年の初選出から数えて11年連続11回目の選出になります¹。

保守案件でこの脅威が重いのは、被害が起きた後の作業量が一気に増えるためです。ファイルを元に戻すだけでは終わらず、原因の切り分けと再発防止の説明までが求められる場面もあります。壊れる前の更新作業よりも、壊れた後の対応のほうが重いというのは、保守を受ける側が最初に押さえておきたい順序です。

弱点(脆弱性)を突く攻撃の位置づけ

システムの弱点、いわゆる脆弱性を悪用した攻撃は、同じ10大脅威の中で4位に置かれています。2016年から6年連続で9回目の選出です³。ランサム攻撃ほど順位は高くありませんが、脆弱性を突く攻撃はランサム攻撃の入口としても使われるため、切り離して考えることはできません。

保守を受ける立場からすると、更新が遅れたプラグインやテーマの弱点は、壊れたときの負担に直結する要素です。更新の手間よりも、更新を止めた期間に何が起きうるかという想定のほうが、案件の負担を左右します。

壊れたときの負担を整理すると、保守案件で候補になる作業は一つではありません。動作の確認、弱点の情報を追うこと、使う人からの連絡への対応、壊れたときの復旧を並べてみると、この4つの中でどれがもっとも重い候補になるかが見えてきます。

図の作成：Remogu編集部。保守案件で負う範囲の候補を整理したもので、統計データではありません

4つの候補を並べたとき、壊れたときの復旧がもっとも重くなりやすいのは、被害が起きた後にまとまった作業時間を要するためです。動作の確認や弱点の情報を追うことは日々の積み重ねで進められますが、復旧はその積み重ねが崩れた場面で一気に発生します。

次の章では、この壊れたときの負担が、なぜ保守を担う立場そのものへの攻撃につながるのかを、10大脅威のもう一つの順位から見ていきます。

2. 外から入って保守を担う立場が狙われる

委託先を狙った攻撃という順位

情報セキュリティ10大脅威では、サプライチェーンや委託先を狙った攻撃が2位に置かれています。2019年の初選出から8年連続8回目の選出です²。委託先という言葉には、外部から保守や開発に入る立場も含まれます。

つまり、保守を引き受ける側そのものが、攻撃の通り道として狙われる対象になっているということです。自社の中だけで完結する話ではなく、どの委託先を経由しているかまで、攻撃する側は見ています。

この2位という順位は、特定のCMSや特定の技術に限った話ではありません。委託の関係そのものが攻撃の対象になっている以上、WordPressの保守案件でも同じ前提で臨む必要があります。個々のプラグインの安全性だけでなく、保守という立場そのものが注目されているという見方です。

10大脅威の上位と保守案件との関わり

同じ10大脅威では、リモートワークなどの環境や仕組みを狙った攻撃が8位に置かれています。2021年から6年連続6回目の選出です⁴。離れた場所から管理画面に入って保守作業をする働き方そのものが、対象に含まれています。委託先を狙った攻撃と、リモート環境を狙った攻撃の両方が組織向けの上位に入り続けている点は、外から入って保守を担うという働き方そのものが注目され続けていることを示しています。ここまでに出てきた4つの順位を、保守を受ける側との関わりで並べ直すと、下の表のようになります。

順位	脅威の名前	保守を受ける側との関わり
1位	データを使えなくして金銭を要求する攻撃(ランサム攻撃)	壊れたときの復旧作業の重さに直結
2位	サプライチェーンや委託先を狙った攻撃	外から入って保守を担う立場そのものが対象
4位	システムの脆弱性(弱点)を突いた攻撃	更新を止めた期間の負担に直結
8位	リモートワーク等の環境や仕組みを狙った攻撃	離れた場所から作業する働き方そのものが対象

表を見ると、保守案件に直接関わる順位は2位と8位です。1位と4位は壊れたときの負担に、2位と8位は保守を担う立場そのものに効いてきます。この4つを図にすると、それぞれの関わり方の違いがより分かりやすくなります。

出典：IPA「情報セキュリティ10大脅威 2026」をもとに作成

次の章では、この立場を守る手がかりとして、まず何を使っているかの一覧を持つという備え方を見ていきます。

3. 何を使っているかの一覧を持つ

構成管理の資料が出発点になる

IPAの脆弱性対処に向けた製品開発者向けガイドは、構成管理の資料をもとに、出荷後も継続して脆弱性の情報を収集するという進め方を示しています⁸。保守案件に置き換えると、構成管理の資料にあたるのが、使っているテーマやプラグイン、バージョンの一覧です。

この一覧がないまま保守を引き受けると、新しい弱点の情報が出るたびに、対象になるかどうかを一から確認する作業が発生します。一覧を先に作っておけば、確認する範囲を絞り込めます。

一覧は一度作れば終わりというものではありません。案件の途中でテーマやプラグインを追加したときや、バージョンを上げたときに、一覧のほうも合わせて書き換えておく必要があります。更新のたびに一覧を見直す習慣をつけておくと、後から見返したときに実際の構成とのずれが生まれにくくなります。

一覧の有無で確認の速さが変わる

同じガイドでは、集めた脆弱性の情報について、実際に再現するかどうかを確認するという手順も示されています⁹。一覧があれば、この確認は「使っているものに当てはまるか」を照らし合わせるだけで済みます。一覧がなければ、まず何を使っているかを洗い出すところから始めることになり、確認にかかる時間そのものが増えます。担当が替わるときや、動作確認をするときも、一覧があるかどうかで確認にかかる時間が変わります。この違いを新しい弱点の情報が出た場面で比べると、下の表のようになります。

場面	一覧がある場合	一覧がない場合
新しい弱点の情報が出たとき	一覧と照らし合わせて対象かどうかすぐ分かる	何を使っているか洗い出してから対象かどうかを確認する
担当が替わるとき	一覧を引き継ぐだけで状況を把握できる	使っているものを一から聞き取る必要がある
動作確認をするとき	確認する範囲を一覧の項目に絞り込める	どこまで確認すればよいかが定まりにくい

表のように、一覧の有無が効いてくる場面は、弱点の情報が出たときだけではありません。一覧を先に用意しておくかどうかで、その後の確認にかかる時間が大きく変わります。次の章では、この一覧を手がかりに、弱点の情報をどこまで追いかけるかという範囲の話に移ります。

図の作成：Remogu編集部。一覧の有無による確認の流れを整理したもので、統計データではありません

4. 弱点の情報をどこまで追うか

再現の確認まで含めるかどうか

弱点の情報を集めるだけでなく、自分が担当する環境で再現するかどうかまで確認するのが、IPAのガイドが示す進め方です⁹。保守案件では、この確認をどこまで担うかが契約前にはっきりしていないことがあります。

情報を眺めるだけで終えるのか、実際に手元の環境で確認するところまで担うのかは、作業量が大きく変わる境目です。ここを決めずに引き受けると、後から範囲が広がっていく原因になります。

この境目は、契約前の段階で言葉にしておくほうが、後の食い違いを防ぎやすくなります。「弱点の情報を確認する」という一文だけでは、情報を見るところまでなのか、手元の環境で試すところまでなのかが読み手によって変わるためです。

利用者からの問い合わせも情報源になる

同じガイドは、利用者からの問い合わせも脆弱性の情報源として扱うとしています¹⁰。保守案件で考えると、使う人からの連絡が、弱点の情報を追う入口の一つになるということです。

情報を追う範囲を、公表された弱点の情報だけに絞るのか、使う人からの連絡まで含めて追うのかによって、保守側が確認する量は変わります。この境目も、引き受ける前に言葉にしておきたい点です。

次の章では、この使う人からの連絡そのものを、どこまで自分が受け止めるかという範囲を見ていきます。

5. 使う人からの連絡を受ける範囲

問い合わせが最初の情報になる場面

利用者からの問い合わせを情報源として扱うという進め方は¹⁰、保守案件では「使う人から連絡が来たとき、誰が最初に見るか」という具体的な範囲の話になります。窓口を保守側が持つのか、依頼元の担当者が持つのかで、対応の速さが変わります。

連絡を受ける範囲を決めていないと、小さな不具合の報告が、保守側に届くまでに時間がかかることがあります。届いたときには、すでに影響が広がっている場合もあります。

個人向けの脅威も連絡の中身に含まれる

10大脅威の個人向けの一覧には、インターネット上のサービスへの不正なログインが挙げられています⁷。個人向けの脅威は順位を付けず、五十音順で並べられています⁶。

使う人からの連絡の中には、自分のアカウントに見覚えのない動きがあったという内容が混ざることがあります。これはサイトの弱点そのものとは別の話ですが、保守側が最初に話を聞く相手になりやすい連絡です。下の表のように、連絡の内容によって最初に確認する相手や次にすることも変わります。

連絡の内容の例	最初に確認する相手	次にすること
サイトが表示されない・重い	保守を担当する側	直近の更新や変更点を確認する
使っているシステムの弱点情報を見た	保守を担当する側	一覧と照らし合わせて対象かを確認する
アカウントに見覚えのない動きがある	依頼元の担当者	パスワードの見直しなど個人側の対応を案内する

表のように、連絡の内容によって最初に確認する相手も変わります。すべてを保守側が抱え込む前提で話を進めると、引き受けた後で範囲が広がりやすくなります。

連絡を受ける範囲を事前に決めておくと、使う人からの連絡が来たときに、まず自分が見るべきものかどうかをすぐ判断できます。判断に迷う時間が減るぶん、実際に手を動かす作業に早く進めるようになります。

次の章では、ここまで見てきた10大脅威という順位そのものが、どうやって作られているかを見ていきます。

6. 順位の作りを踏まえた読み方

約250名による審議と投票で決まる順位

情報セキュリティ10大脅威の順位は、約250名の委員による審議と投票を経て決まっています⁵。特定の1社や1人の判断ではなく、複数の人による見立てを重ねて出された順位だということです。

この決まり方を知っておくと、順位の数字だけを絶対の基準として扱うのではなく、複数の見立てが重なって出た目安として読むことができます。

順位が毎年入れ替わるのも、この決まり方に理由があります。委員による審議と投票を毎年重ねている以上、前年と同じ脅威でも順位が上下することがあります。1年分の順位だけを見るより、何年連続で選ばれ続けているかという続き方も合わせて見ておくと、その脅威の重さがより読み取りやすくなります。

組織向けと個人向けで並べ方が違う

10大脅威では、組織向けの脅威は順位を付けて並べ、個人向けの脅威は順位を付けず五十音順で並べています⁶。保守案件は組織向けの一覧を中心に見ることになりますが、使う人からの連絡には個人向けの脅威も混ざってきます。

順位がある一覧と、順位のない一覧を同じ基準で比べることはできません。組織向けの順位は重さの目安になりますが、個人向けの一覧は「何が挙げられているか」を確認する一覧として読むのが自然です。

ここまでの話を並べると、壊れたときの負担(1位・4位)、保守を担う立場そのもの(2位・8位)、使う人からの連絡(個人向けの一覧)という3つの見方が、同じ10大脅威の中に並んでいます。次の章では、これらの見方を踏まえて、案件を受ける前にどの順番で取り決めておくとよいかを整理します。

7. 受ける前に取り決める順番

まず負う範囲を言葉にする

サプライチェーンや委託先を狙った攻撃が2位に置かれているように²、外から入って保守を担うという立場そのものが注目されています。だからこそ、案件を受ける前にまず言葉にしておきたいのが、壊れたときにどこまで自分が動くのかという範囲です。

範囲を決めずに引き受けると、後から「ここまでやってもらえると思っていた」という認識のずれが出やすくなります。最初の取り決めで、復旧作業の範囲と、報告の範囲を分けておくと、ずれを防ぎやすくなります。

範囲を言葉にする作業は、契約書に細かい条件をすべて書き込むこととは違います。壊れたときにまず誰が状況を確認し、どこまでの作業を保守側が担い、どこから先を依頼元に相談するのかという、動き出しの順番をそろえておくだけでも認識のずれは減ります。

次に一覧と情報の追い方を決める

構成管理の資料をもとに継続して脆弱性の情報を収集するという進め方に沿うなら⁸、使っているテーマやプラグインの一覧を最初に用意しておくことが、次の取り決めになります。

一覧ができたら、弱点の情報をどこまで追うのか、使う人からの連絡をどこで受け止めるのかを、順番に決めていきます。範囲を先に決めておくほど、引き受けた後の作業量の見通しが立てやすくなります。下の図は、ここまでの話を受ける前に取り決める順番として整理したものです。

図の作成：Remogu編集部。受ける前に取り決めておきたい順番を整理したもので、統計データではありません

保守案件を受ける前に、最初に確認しておきたいことは何ですか

壊れたときにどこまで自分が動くのかという範囲です。復旧作業の範囲と、報告の範囲を分けて、契約前の会話で言葉にしておくと、後からの認識のずれを防ぎやすくなります。

一覧を作る時間がない場合はどうすればよいですか

案件開始時に、使っているテーマとプラグイン、バージョンだけでも書き出しておくと、弱点の情報が出たときに確認する範囲を絞り込めます。少しずつ増やしていく形でも、無いよりは確認が速くなります。

使う人からの連絡は、どこまで自分が対応するものですか

連絡を受ける範囲は案件ごとに異なります。誰が最初に確認するか、弱点の情報に関わる連絡かどうかの見分け方を、依頼元と事前にすり合わせておくと、対応の順番で迷いにくくなります。

ここまで見てきた範囲の整理は、保守案件に限らず、どの案件を引き受けるときにも役立つ考え方です。Remoguでは、案件の90%以上がフルリモート可能です。まずは自分の経験に近い案件を見て、負う範囲がどう書かれているかを確かめてみるのも一つの進め方です。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 IPA「情報セキュリティ10大脅威 2026」1位の脅威（2026年1月・2026年8月確認）
＊2 IPA「情報セキュリティ10大脅威 2026」委託先という経路（2026年1月・2026年8月確認）
＊3 IPA「情報セキュリティ10大脅威 2026」直せる穴（2026年1月・2026年8月確認）
＊4 IPA「情報セキュリティ10大脅威 2026」働く場所の穴（2026年1月・2026年8月確認）
＊5 IPA「情報セキュリティ10大脅威 2026」決め方（2026年1月・2026年8月確認）
＊6 IPA「情報セキュリティ10大脅威 2026」並べ方の違い（2026年1月・2026年8月確認）
＊7 IPA「情報セキュリティ10大脅威 2026」個人側の脅威（2026年1月・2026年8月確認）
＊8 IPA「脆弱性対処に向けた製品開発者向けガイド」監視の継続（2026年3月・2026年8月確認）
＊9 IPA「脆弱性対処に向けた製品開発者向けガイド」確認の段（2026年3月・2026年8月確認）
＊10 IPA「脆弱性対処に向けた製品開発者向けガイド」情報源の広さ（2026年3月・2026年8月確認）