WordPressのセキュリティは、保守会社と契約しただけでは整いません。更新、バックアップ、監視、管理者アカウント、事故時の連絡について、誰が判断し、誰が作業し、誰が結果を確認するかが曖昧なら「相手が対応しているはず」という空白が残るため、中小企業では専門作業を外部へ任せつつ、事業上の判断と重要な情報の所有を発注側に残す形が現実的でしょう。
先に決めたいのは、対策製品の数ではなく責任分担です。発注側は停止できる時間、失ってよいデータの範囲、管理者として残す人、事故時の意思決定者を定め、保守会社は契約した技術作業を実行する。そのうえで、更新記録やバックアップの復元確認などを双方で確かめると、契約名だけでは見えない抜けを減らせます。
この記事では、WordPress本体・テーマ・プラグインの更新、バックアップと復元、アカウント、監視と初動、契約の確認項目を、発注側と保守会社の担当に分けて整理します。現在の保守契約書と管理画面を見ながら読み進めれば、追加で決めることと、保守会社へ確認することを一枚の表へまとめられる構成です。
中小企業のWordPress対策は、作業名より先に担当を決める
セキュリティは危険を完全になくす作業ではなく、利用できる対策を組み合わせてリスクを下げ続ける取り組みです。WordPressの公式資料も、ホスティング事業者が守る範囲とサイト所有者が担う範囲の境界を理解する必要があると説明しているため、「保守あり」という契約名だけで十分と考えず、サーバー、WordPress、外部サービス、自社運用の境目から確認します。 Hardening WordPress｜WordPress.org
担当を決めるときの基本は、一つの作業を「決める」「実行する」「確認する」の三役に分けることです。例えばプラグイン更新なら、発注側が更新できない日や重要機能を伝え、保守会社がバックアップ、更新、動作確認を実施し、双方が結果と未対応事項を確認するという形であり、実行を外注しても事業への影響を決める役割まで自動的に移るわけではありません。
| 作業単位 | 発注側が決めること | 保守会社が実行する例 | 双方で確認する証拠 |
|---|---|---|---|
| 更新 | 更新できない日、重要機能、緊急時の承認者 | 事前バックアップ、検証、更新、表示・送信確認 | 対象、実施日、結果、保留理由 |
| バックアップ | 失ってよいデータ範囲、許容停止時間 | 取得、別環境への保管、復元試験 | 対象、世代、保存先、復元結果 |
| アカウント | 利用者、必要権限、利用終了日 | 発行、権限変更、停止・削除 | 現行アカウント一覧と変更履歴 |
| 監視・初動 | 連絡先、連絡条件、停止判断者 | 監視、一次調査、契約範囲の隔離・復旧 | 通知時刻、影響、対応内容、次の判断 |
| 連絡・記録 | 社内責任者、代理者、保管場所 | 技術報告、作業記録、引継ぎ資料の更新 | 連絡網と記録が最新か |
外部へ業務を委託する場合、IPAの中小企業向けガイドラインは、契約書に委託先の責任と実施すべき対策を明記し、合意する必要があるとしています。ここで重要なのは、保守会社へすべてを押しつけることではなく、発注側の経営判断と保守会社の技術作業を接続すること。契約の各項目に判断者、実行者、確認者を置くと、障害時にも迷いにくくなります。 中小企業の情報セキュリティ対策ガイドライン第4.0版｜IPA
図の五つの作業を別々の契約名へ分ける必要はありませんが、どの作業にも三役があるかは点検してください。保守会社が実行者と確認者を兼ねる場合は、発注側へ何を、どの頻度で、どの形式で報告するかまで定めることが、実施の有無を追う条件です。
更新はWordPress本体・テーマ・プラグインを分けて扱う
WordPress本体、テーマ、プラグインはいずれも更新対象ですが、影響範囲は同じではありません。WordPress公式は、本体を最新状態に保つことに加え、プラグインの更新と未使用分の削除を案内している一方、独自テーマ、外部フォーム、決済、予約、解析タグなどが組み合わさる実サイトでは、構成を踏まえて更新の可否を判断する必要があります。 Hardening WordPress｜WordPress.org
発注側が伝えるべき情報は、技術的な手順より事業上の制約です。問い合わせや申込みが増える期間、更新を避けたい営業時間、止まると困るフォーム、社内で必ず確認したいページを示せば、保守会社は検証順序と作業時間を組み立てやすく、緊急性の高い更新を通常スケジュールより先に行う場合も、承認者を決めておくことで連絡待ちを短くできます。
保守会社側では、対象バージョンの確認、事前バックアップ、必要に応じた検証環境での確認、本番更新、主要画面と重要機能のテスト、作業記録までを一つの単位にします。「更新ボタンを押す」だけを契約範囲とすると、不具合が出た際の切り戻しや原因調査が別料金・別依頼になり得るため、更新後の確認と失敗時の扱いを先に聞いておくべきです。
見落とされやすいのが、有料プラグインや独自テーマのライセンス、ソースコード、開発元への連絡手段です。発注側・保守会社・制作会社のどこがライセンスを更新し、費用を負担し、更新ファイルを入手するのかが曖昧なままでは、脆弱性修正が出ても適用できないため、サイト引継ぎ時に製品名、契約者、更新日、費用負担、入手先を一つの一覧へ残しておきます。
自動更新があっても「確認担当」は残る
自動更新は適用の遅れを減らせても、正常終了とサイトへの影響を確認する役割までは置き換えません。通知先が退職者のまま、エラーが管理画面にだけ出る、フォーム送信だけが失敗するといった問題は、更新機能が動いているだけでは拾えないためです。
自動更新する対象、通知を受ける人、異常時に保守会社へ連絡する人、確認するページ・機能を一組にし、重要度の低い対象は自動、事業に直結する機能は検証後に手動とするなど、サイトごとの基準まで決めておきます。
バックアップは「取る」と「戻せる」を別の仕事にする
WordPressサイトを完全に戻すには、一般にデータベースとファイルの両方が必要です。公式資料もこの二つを一組として扱い、更新前のバックアップを案内していますが、記事・固定ページ・各種設定が入るデータベースと、テーマ・プラグイン・アップロード画像などのファイルでは保存対象が異なるため、「サーバーがバックアップしているらしい」だけでは範囲を判断できません。 Backups – Advanced Administration Handbook｜WordPress.org
発注側が決めるのは、何分・何時間前の状態まで戻せれば事業上許容できるか、復旧までどの程度待てるかです。更新が月に数回の会社案内サイトと、毎日申込みや記事が増えるサイトでは必要な取得頻度が異なるため、保守会社はその条件から取得間隔、保存世代、保存先、復元手順を設計し、費用と制約を示します。
バックアップの成功通知は、復元できることの証明ではありません。保存データが欠けている、暗号化キーや認証情報がない、復元手順が担当者の頭の中にしかない場合、事故時に使えないからです。取得とは別に復元試験を予定し、テスト環境へ戻した日時、対象、結果、残った課題までを完了条件にしてください。
IPAのガイドラインは、重要情報を定期的にバックアップして安全な場所へ保管するだけでなく、データを戻せるか定期的に確認するよう求めています。WordPressでの実務に置き換えると、発注側が停止時間とデータ損失の許容範囲を決め、保守会社が技術条件へ落とし込み、双方で復元結果を確かめる流れです。 中小企業の情報セキュリティ対策ガイドライン第4.0版｜IPA
契約書では取得頻度だけでなく、保存先が本番サーバーと分かれているか、何世代残すか、復元作業が月額内か別見積もりか、誰の依頼で復元を開始できるかまで確認します。サイトが動かない緊急時に、発注側の承認者へ連絡がつかず復元を始められない設計では、技術的な準備があっても停止時間を縮められません。
管理者アカウントは発注側が台帳を持つ
WordPressの役割と権限は、管理者、編集者、投稿者などによって実行できる操作を分ける仕組みです。公式ドキュメントが示すとおり、サイト所有者は利用者ごとに役割を割り当て、投稿、ページ作成、プラグイン管理、テーマ管理、利用者管理などへのアクセスを制御できるため、全員へ管理者権限を渡すのではなく担当業務に必要な範囲を選ぶことが基本です。 Roles and Capabilities｜WordPress.org
発注側は、現在のアカウント名、利用者、所属、役割、利用目的、発行日、利用終了予定を台帳で持ちます。保守会社はその指示に基づいて発行や権限変更を行い、作業後の一覧を返す。この分担なら、技術操作は任せつつ、誰が自社サイトへ入れるかを発注側が把握できます。
共用の管理者アカウントは、担当者が変わったときに誰の利用を止めるべきか分かりにくく、操作の追跡もしづらくなります。社内担当者、外部ライター、広告会社、保守会社には原則として個別のアカウントを発行し、異動・退職・契約終了を人事や取引終了の手続きとつなげ、削除前には投稿者の引継ぎや所有コンテンツの扱いも確認してください。
WordPressの管理画面だけでなく、ドメイン、DNS、レンタルサーバー、バックアップ保存先、有料プラグイン、メール送信サービスなどの契約者とログイン先も一覧化します。発注側が契約名義と復旧連絡先を把握して保守会社だけが知っている状態を避ければ、担当変更や会社変更の際にもサイトを継続して管理できますが、認証情報そのものは社内で定めた安全な保管方法へ分け、台帳へ平文で並べない運用が必要です。
監視と事故対応は、連絡条件と停止権限まで決める
監視は「何かを見ている」という表現では足りません。サイト表示、更新失敗、不審な変更やログイン兆候、証明書、サーバー資源など、対象によって見つけられる問題が変わるため、WordPress公式がログと監視を状況把握の手段として挙げていることも踏まえ、保守契約では監視対象、確認頻度、通知条件、保存する記録まで具体化します。 Hardening WordPress｜WordPress.org
さらに、アラートが出た後の行動を分けてください。通知を受けるだけなのか、保守会社が一次調査まで行うのか、夜間・休日も受付するのか、一定時間連絡がつかないときの代理者は誰か――この違いで、同じ「監視あり」でも初動の速さが変わります。対応時間の目標と、調査・復旧が月額内か別費用かも、平時に確認しておく項目です。
IPAのインシデント対応手引きは、異常の検知と責任者への報告、対応体制の立ち上げ、初動対応、調査、証拠保全、復旧、再発防止という流れを示しています。被害が広がる可能性がある場合はネットワーク遮断、情報や機器の隔離、サービス停止が必要になる一方、不用意な操作で記録を消さない配慮も要るため、WordPressでも慌てて初期化する前に、誰が隔離を指示し、誰が記録を保全するかを決めておく意味があります。 中小企業のためのセキュリティインシデント対応の手引き｜IPA
保守会社が担うのは、契約と権限の範囲内で行う技術確認、影響範囲の整理、必要な隔離や復旧作業です。発注側はその情報を受けて、サイトや受付機能を止めるか、事業部門へ連絡するか、顧客・取引先への説明準備を始めるかを判断し、保守会社が事業上の決定まで背負う状態と、発注側が根拠なく技術操作を指示する状態の双方を避けます。
連絡網には、発注側の責任者、代理者、保守会社の通常窓口と緊急窓口、サーバー会社など第三者の窓口を記載し、電話、メール、チャットのどれを第一連絡にするか、件名や伝える項目、受付外時間の扱いまでそろえておけば、異常時に探し物をする時間を減らせます。作成日だけでなく最終確認日を残し、担当変更や契約更新のタイミングで見直してください。
保守契約で空白になりやすい項目を確認する
保守契約を読み直すときは、「セキュリティ対策」「バックアップ」「障害対応」といった大きな言葉を実際の作業へ分解します。契約に書かれていない仕事を保守会社が善意で毎回行うとは限らず、発注側も未実施に気づけないため、次の表で月額保守の有無を問わず確認したい代表的な空白を整理しました。
| 確認項目 | 契約で確かめる質問 | 空白なら決める担当 |
|---|---|---|
| サーバー・PHP等の基盤 | 更新、設定変更、障害調査は誰の範囲か | ホスティング会社、保守会社、発注側の境界 |
| WordPress本体・テーマ・プラグイン | 対象、頻度、事前検証、失敗時の切り戻しを含むか | 実行者と承認者 |
| 有料製品・ライセンス | 契約名義、更新費用、期限管理、入手先は誰が持つか | 費用負担者と期限確認者 |
| 独自テーマ・追加開発 | ソース、仕様書、開発環境、元の開発者情報があるか | 保管者と改修判断者 |
| バックアップ・復元 | 対象、保存先、世代、復元試験、緊急復元の費用は何か | 設計者、実行者、承認者 |
| 監視・初動 | 監視対象、通知条件、受付時間、一次調査、隔離権限はどこまでか | 通知先と停止判断者 |
| ドメイン・DNS・証明書 | 契約者、期限、更新、設定変更、障害時窓口は誰か | 名義管理者と作業者 |
| アカウント管理 | 発行、権限変更、退職者停止、定期棚卸しを誰が行うか | 依頼者、作業者、確認者 |
| 作業報告・引継ぎ | 記録の形式、頻度、保管期間、契約終了時の受渡し内容は何か | 記録作成者と保管者 |
IPAのガイドラインが委託先の責任と対策を契約へ明記するよう求める背景には、外注しても発注側の確認が不要にはならないという考えがあり、契約範囲を細かくする目的は責任逃れではなく、異常時の次の行動を明確にすることです。作業対象、頻度、報告、例外、追加費用、緊急時の権限を同じ表で照合すれば、営業説明と実際の運用のずれも見つけやすくなります。 中小企業の情報セキュリティ対策ガイドライン第4.0版｜IPA
月次報告や作業記録は、実施済みの証明だけでなく、次回判断の材料です。更新対象と結果、バックアップの成否、復元試験、アカウント変更、検知した異常、保留課題を同じ場所へ残せば、担当者が代わっても経緯を追えます。報告書の見た目より、対象と結果が照合できることを優先してください。
保守会社を変更する可能性も考え、契約終了時に受け取れるものを確認します。サイト一式、データベース、設定情報、契約・ライセンス一覧、管理者アカウント、バックアップ、作業履歴、未解決事項がそろわなければ安全な引継ぎに時間がかかるため、引渡し方法と期限、削除するアカウント、旧会社が保持するデータの扱いまで終了手続きへ含めておくと安心です。
責任分担表を一枚にまとめ、定期的に更新する
最終的には、更新、バックアップ、アカウント、監視・初動、連絡・記録の五項目を一枚へまとめ、「誰が決めるか」「誰が実行するか」「何を見て完了とするか」「いつ見直すか」を埋め、空欄を次に契約または社内運用で決める項目として扱います。
| 確認項目 | 決める人 | 実行する人 | 完了の確認方法 | 見直すきっかけ |
|---|---|---|---|---|
| 更新 | 発注側のサイト責任者 | 保守会社または社内担当 | 更新履歴と主要機能の確認結果 | 構成変更、緊急更新、契約更新 |
| バックアップ | 発注側の事業責任者 | 保守会社または基盤事業者 | 取得記録と復元試験結果 | 更新頻度や重要機能の変更 |
| アカウント | 発注側の管理責任者 | 保守会社または社内管理者 | 現行アカウント台帳 | 異動、退職、外部契約終了 |
| 監視・初動 | 発注側責任者と保守会社 | 契約で定めた担当 | 通知・調査・判断の時系列記録 | 窓口変更、障害、監視対象の追加 |
| 連絡・記録 | 発注側責任者 | 双方の担当者 | 連絡網と月次・作業記録 | 担当変更、契約更新、事故後 |
作り始める材料は、現在の契約書、請求書、管理画面の利用者一覧、ドメイン・サーバーの契約情報です。これらを集めて五つの作業ごとに現状の担当を記入し、次に保守会社へ範囲と報告方法を確認して、空欄や双方の認識が違う行だけを契約変更または社内ルールへ反映します。
- 現在の保守契約と、ドメイン・サーバー・外部サービスの契約者を確認する。
- 五つの作業を行にして、判断者、実行者、確認者を記入する。
- バックアップの復元、アカウント停止、異常時連絡など、実施結果を証明する方法を決める。
- 契約外の作業には、社内担当、別事業者、追加依頼のいずれかを割り当てる。
- 担当変更、サイト構成変更、契約更新、事故発生を見直しのきっかけとして記録する。
WordPressのセキュリティ対策で最も避けたいのは、専門知識が足りないことそのものではなく、誰も担当していない作業が見えないまま残ることです。発注側は事業上の条件と所有情報を持ち、保守会社は合意した技術作業を確実に行い、双方が結果を確認する。この関係を一枚に可視化すれば、対策の追加や保守契約の見直しも、必要な場所から進められます。
まずは現行契約の「更新」「バックアップ」「監視」という言葉へ、対象、実行者、確認方法を書き足してみてください。三つが埋まらない行こそ、保守会社または社内で次に確認すべき空白です。
