WordPressサイトのセキュリティは、プラグインを一つ追加して終わるものではありません。本体・テーマ・プラグインの更新に加え、管理者アカウント、サーバー、ドメイン、フォーム連携、バックアップ、緊急連絡先まで管理できているかが、被害の起こりやすさと復旧のしやすさを左右します。
この記事では、BtoBサイトで優先して確認したい対策と運用の決め方、改ざんや乗っ取りが疑われる場合の初動、保守を委託する際の確認事項を整理します。読後には、未対応項目・担当範囲・侵害時の初動準備を整理できるようになります。

WordPressのセキュリティは、管理画面だけでなく、サーバー、ドメイン、フォーム、外部連携を含めて継続的に管理します。
01SectionWordPressの対策を放置すると、BtoBサイトにどんな影響が出るか
WordPressを使っていること自体が、直ちに危険という意味ではありません。リスクが高まるのは、未更新の本体・テーマ・プラグイン、管理が不十分な認証情報、過剰な権限、用途不明の追加機能、サーバーや外部連携の管理漏れが重なる場合です。WordPress公式も、基本的な予防策と継続的なハードニング(安全性を高めるための設定・運用)を案内しています。WordPress公式のハードニングガイドも確認しましょう。
WordPressに関係する攻撃面と、周辺環境の管理対象
WordPress管理画面で扱う本体・テーマ・プラグイン・利用者アカウントは、まず棚卸しすべき対象です。サイトの安全性はWordPressだけで完結しません。サーバー上のPHP、DNS、メール、フォーム、CRM・MAなどの外部連携も、影響範囲を広げる要因になり得ます。
たとえば、DNSの変更権限やフォーム送信先の管理者が不明であれば、緊急時に必要な操作や確認を進められません。対策は「どの機能を入れるか」より先に、「どの資産を誰が管理しているか」を明らかにすることから始まります。
改ざん・不正ログインが業務に及ぼす影響
BtoBサイトでは、サイト表示の異常だけでなく、営業・マーケティングの導線が止まることが問題になります。代表的には、次のような影響が考えられます。
- 改ざんや不正ページにより、見込み顧客に不審な表示や外部誘導が起きる
- 問い合わせフォームや資料請求の送信先が変わり、商談機会を逃す
- CRM・MAなどの外部連携が停止し、営業・マーケティング活動に支障が出る
- 入力情報の第三者送信が疑われ、影響範囲の調査や対外対応が必要になる
- 復旧作業のために公開を制限し、信用や情報発信に影響が及ぶ
優先度は、問い合わせフォーム、資料ダウンロード、会員機能、重要な外部連携を持つか、管理者権限が適切か、復元テストを実施できるかによって変わります。Webサイト全体で確認したい基礎対策は、Webサイト全般の対策もあわせて確認してください。
02Section最初の30分で確認する場所:管理画面・サーバー・ドメイン・契約書
設定変更を始める前に、管理対象と管理権限、契約先、緊急連絡先を短時間で把握します。この時点で対策の実施まで終える必要はありません。「誰が、どこを確認できるか」を特定することが目的です。
WordPressのサイトヘルス機能では、更新状態、テーマ・プラグイン、サーバー構成などの確認に役立つ情報を見られます。WordPress公式のSite Healthの案内を参考に、管理画面で見える範囲を確認しましょう。ただし、サーバー設定やDNS、バックアップ保管先は別の管理画面や契約先で管理されている場合があります。
30分の現状確認先チェックリスト
- ✓
WordPress管理画面を確認する
更新、本体・テーマ・プラグインの有効状態、利用者と管理者権限、サイトヘルスを確認する。対象一覧、確認担当、次回確認日を決められれば第一段階は完了。
- ✓
サーバー・ドメイン・契約情報を確認する
サーバー、PHP、バックアップ、ドメイン、DNSの管理画面・契約名義・緊急連絡先を確認する。担当不明なら契約書、請求書、登録メール、社内の資産台帳をたどる。
- ✓
フォーム・外部連携を確認する
フォーム送信先、通知メール、CRM・MAなどの連携先、連携アカウント、停止時の業務影響を確認する。担当不明ならマーケティング、営業、情報システムの担当へ確認する。
- ✓
バックアップと復元担当を確認する
WordPressファイルとデータベースの復元データ、保管先、復元手順、復元担当を確認する。管理画面で把握できない場合はサーバー契約先または保守担当へ確認する。
- ✓
保守・緊急対応の窓口を確認する
保守契約の対象範囲、連絡方法、公開停止の判断者、代替担当者を確認する。不明な場合は制作時の引継ぎ資料、発注部門、経理の支払先記録を確認する。
ここで重要なのは、WordPressの管理者権限と、サーバー・ドメインの契約権限を同じものと考えないことです。管理画面へログインできても、サーバー設定の変更やDNSの確認、バックアップの取得・復元を行えるとは限りません。確認できない領域は、先に契約名義と管理権限を特定します。
03SectionWordPressで優先する必須セキュリティ対策

必須対策は導入や設定だけで終わらせず、確認者・連絡先・復旧手順まで決めて運用します。
優先すべき対策は、設定の有無だけでは完了といえません。対象資産、確認者、異常時の連絡先、必要に応じて復旧できる担当まで明確になって、はじめて運用できる状態になります。
| 対策 | 主な確認先 | 完了の目安 | 担当不明時の確認先 |
|---|---|---|---|
| 更新 | WordPress管理画面、サーバー管理画面、保守通知 | 本体・テーマ・プラグイン・PHPごとに確認者、保留ルール、更新後の確認方法がある | 制作引継ぎ資料、保守契約、サーバー契約先 |
| ログイン保護 | ユーザー一覧、認証基盤、サーバー設定、保守範囲 | 共有管理者がなく、多要素認証や試行制限などの実装場所と担当が明確 | サイト責任者、情報システム、保守担当 |
| 権限・不要アカウント | ユーザー一覧、委託先一覧、プラグイン・テーマ一覧 | 個人別アカウントと必要最小限の権限になり、用途不明のアカウントや不要資産がない | 人事、サイト責任者、制作・保守担当 |
| バックアップ・復元 | サーバー、バックアップ保管先、運用台帳 | ファイルとデータベースを含む復元データ、保管先、復元手順、復元担当が確認できる | サーバー契約先、保守担当、契約書 |
| 点検・監視 | 管理画面、通知メール、ログ、保守報告 | 更新・バックアップ失敗・管理者追加・重要導線の異常を確認する担当と連絡先がある | 保守契約、社内の資産・アカウント台帳 |
更新は本体だけで終わらせない
WordPress本体、テーマ、プラグインは、それぞれ更新対象です。本体更新の確認方法はWordPress公式の更新手順で確認できます。自動更新を使う場合も、対象ごとの有効・無効、失敗通知の送付先、更新後にフォームや主要ページを確認する担当を決めておく必要があります。
PHPの更新はサーバー側で行うことが多く、管理画面だけでは実施できない場合があります。更新前に互換性、検証環境、ロールバック(変更前の状態へ戻すこと)の可否を確認します。
ログイン保護と権限は、実装場所を確認する
WordPressでは、役割ごとにできる操作を分けられます。WordPress公式の権限・ロールの説明を参照し、管理者権限を必要最小限に絞りましょう。退職者、委託終了者、用途不明・共有のアカウントは優先して確認します。
多要素認証、ログイン試行制限、アクセス制限、WAF、ログ保管は、サーバー、認証基盤、追加機能、保守作業で提供される場合があります。設定方法を急ぐ前に、すでにどこで実装されているか、誰が変更権限を持つかを確認してください。
バックアップ・不要資産・点検を運用に組み込む
バックアップは「取得している」だけでは不十分です。復元対象にWordPressファイルとデータベースが含まれているか、復元できる担当者がいるか、重要な変更前や構成変更後に復元可能性を確認できるかが重要です。また、不要なテーマやプラグイン、利用目的が不明なアカウントは、依存関係や独自改修、復旧時の必要性を確認したうえで整理します。
04Sectionセキュリティプラグインは何を補い、何を代替できないか
セキュリティ用の追加機能は、ログイン保護や変更検知を補助できますが、運用を不要にするものではありません。プラグイン自体も更新・互換性・障害切り分けの対象です。WordPress公式のプラグイン管理ガイドを参照し、継続管理する前提で判断します。
セキュリティ用プラグインの代表例としては、Wordfence Security、SiteGuard WP Plugin、Solid Security(旧iThemes Security)などが、WordPress公式プラグインディレクトリで配布状況・更新状況・利用規模を確認できる、よく使われる例として知られています。いずれもログイン保護やスキャンなどの機能を持ちますが、対応範囲や無償版・有償版の差はプラグインごとに異なります。この列挙は代表例の紹介であり、特定のプラグインの推奨や機能比較を意図するものではありません。導入の判断は、以下の観点で自社の構成・運用体制と照合してください。
プラグインで補助できることと、運用で担保すること
ログイン保護・アクセス制限
不正なログイン試行やアクセスを抑える補助になることがある。ただし、認証基盤やサーバー側ですでに実装されている場合がある。
変更検知・監査ログ・通知
ファイルや設定の変更、操作記録、異常の通知を補助できる。通知を受けた後の確認者と連絡先は別途必要。
スキャン
不審な状態を見つける補助として使えるが、調査範囲の確定や復旧判断そのものを代替するものではない。
更新判断・権限設計
脆弱性の影響判断、管理者の最小権限化、不要アカウントの整理は、運用責任者が継続して行う必要がある。
バックアップ・復元テスト
保管先の分離、復元データの健全性確認、復元手順の検証は、サーバーや保守範囲を含めて設計する必要がある。
プラグインは必須対策を補う手段です。導入前後は、次の順番で確認しましょう。
プラグイン導入前後の確認手順
- Step01
重複する機能を確認する
解決したい課題を先に定め、サーバー、WAF、認証基盤、既存の追加機能に同等の機能がないか確認する。
- Step02
互換性と切り分け方法を確認する
WordPress、PHP、テーマ、既存プラグインとの互換性を確認し、不具合が起きた際に影響を切り分けられる担当と手順を決める。
- Step03
導入前にバックアップを確認する
導入・設定変更の前に、復元に使うデータと復元手順を確認する。必要なら検証環境で先に動作を確かめる。
- Step04
導入後に重要導線をテストする
管理画面へのログイン、主要ページ、フォーム、資料ダウンロード、外部連携、通知メールを確認し、結果を残す。
- Step05
通知担当と更新担当を決める
通知の受信者、確認者、異常時の連絡先、プラグイン自体の更新担当を台帳に記録する。
05Section更新とバックアップを継続運用するためのルール
更新は一定間隔で機械的に行うだけではなく、影響と検証体制に応じて判断します。緊急性の高い更新、定例で扱う更新、大きな構成変更を伴う更新を分けると、承認や検証の抜け漏れを減らせます。
| 区分 | 判断起点・判断者 | 検証・承認 | 記録と保留時の対応 |
|---|---|---|---|
| 緊急更新 | 脆弱性情報、保守・サーバーからの緊急通知、悪用の兆候を起点に、サイト責任者または保守担当が一次判断する | 管理画面、主要ページ、フォーム、重要連携、切戻し可否を確認する。公開停止など影響が大きい場合は責任者が承認する | 対象、影響、対応時刻、結果を残す。保留する場合は理由、代替策、再確認日を責任者へ共有する |
| 通常更新 | 定例の更新確認を起点に、運用担当が判断する | 更新前バックアップを確認し、主要導線と管理画面を確認する。定例の承認者を定める | 更新内容、検証結果、不具合を記録する。保留は次回定例任せにせず、再確認日と承認者を記録する |
| 計画更新 | PHP変更、テーマ改修、大型更新、構成変更を起点に、責任者と技術担当が判断する | 検証環境、切戻し、連携、性能、復元手順を確認し、変更責任者が承認する | 計画、承認、バックアップ、復元確認を記録する。リスクが解消しなければ本番反映を延期し、代替策を決める |
更新を保留する場合は、対象とバージョン、保留理由、影響を受ける機能、代替策、再確認日、承認者を残します。保留は「何もしない」判断ではなく、リスクを把握したうえで再判断する予定を持つ運用です。
バックアップ頻度は、復旧要件から決める
バックアップ頻度は固定値で決められません。許容できるデータ損失、更新量、フォームや会員情報の重要性、許容停止時間、保持世代数、復元体制を踏まえて決めます。
復元データには、データベースだけでなくWordPressファイルも含める必要があります。両者の復旧対象が異なる点は、WordPress公式のバックアップ解説で確認できます。復元データとは別に、サーバー・ドメイン・DNS・メール・外部連携の契約先、管理権限、緊急連絡先を記した管理台帳を管理してください。
復元テストは、重要更新前、大きな構成変更後、担当者や委託先の変更時、定期点検時などに予定化します。バックアップの設計と復元確認を深める場合は、バックアップ運用も参照してください。
06Section乗っ取り・改ざんが疑われるときの初動

改ざんが疑われる場合は、記録と証跡保全を踏まえ、責任者・技術担当・保守担当で被害抑止と復旧の順序を判断します。
意図しない投稿や管理者追加、不審な転送、不正ページ、検索結果の異常、フォーム送信先の変更などを見つけたら、復旧を急ぐ前に事実を記録し、責任者と技術担当を起動します。IPAのセキュリティインシデント対応の手引きでも、検知から初動、証拠保全、復旧、再発防止までを段階的に整理しています。
疑いの段階で独断操作をしない
ファイルの削除、原因確認のためのプラグイン追加、ログを確認する前の設定変更、無計画な上書き復元は避けてください。調査に必要な記録を失ったり、侵入経路を残したまま再公開したりするおそれがあります。被害抑止が必要な場合も、可能な範囲で記録を残し、サイト責任者と技術・保守担当で判断します。
公開停止、隔離、認証情報の変更、ログ取得、復元の具体的な順序は一律ではありません。被害の継続性、利用者への影響、ログ取得の可否、サーバー構成、保守契約の支援範囲に応じて決めます。
乗っ取り・改ざん疑い時の初動
- Step01
発見内容を記録して連絡する
URL、画面、発見日時、通知、直前の変更作業を記録し、サイト責任者と技術・情報システム担当へ連絡する。発見者は独断で削除や復元をしない。
- Step02
緊急性を確認する
不正配布、外部誘導、偽入力画面、認証情報や個人情報の送信疑い、継続する改ざん、管理者権限の不正利用がないかを確認する。
- Step03
証跡を保全する
取得可能な範囲で、アクセス・エラー・監査ログ、不審ファイル、利用者一覧、テーマ・プラグインの状態、DNS・フォーム・外部連携設定を保全し、取得者・時刻・保存先を記録する。
- Step04
被害抑止と認証情報保護を判断する
利用者への影響が継続・拡大するおそれがあれば、責任者、技術担当、保守担当が公開停止、限定公開、アクセス制限などを検討する。WordPress、サーバー、管理用接続、メール、DNS、外部連携の認証情報は、調査を妨げない順序を確認して保護する。
- Step05
原因是正後に復旧と個人情報対応を確認する
侵入経路、改変範囲、情報送信の有無、復元候補の健全性を確認し、原因を是正してから復旧を判断する。個人情報が関係する場合は、扱う情報と影響範囲を確認し、個人情報保護委員会の漏えい等対応案内と必要な専門窓口で報告・通知・公表の要否を確認する。
保守先やサーバー契約先が分からない場合は、保守契約書、請求書、制作時の引継ぎ資料、社内の資産・アカウント台帳、ドメイン・サーバー管理画面の登録メール、経理の支払先記録から確認します。自社での対応が難しい場合は、IPAのサイバーセキュリティ相談・届出窓口一覧も確認先になります。
07Section自社対応か外部委託か:保守の依頼・検収・運用で確認すること

委託範囲は契約前にそろえ、検収時に権限・手順を受け取り、運用中も更新・復元・緊急対応の記録を確認します。
自社対応か外部委託かは、サイト規模だけでなく、管理権限、更新・検証・復元を実施できる人員、緊急連絡先、代替担当者、重要導線の確認体制を持てるかで決めます。これらを継続的に担えない場合、またはサーバー・ドメインの契約先や管理権限が不明な場合は、外部支援を検討する価値があります。
契約前は依頼範囲をそろえる段階、制作・改修の検収時は権限・手順・成果物を受け取る段階、運用中は未適用更新や復元確認、対応履歴を見直す段階です。詳しい保守範囲の考え方は、WordPress保守も参考にしてください。
保守契約で時間条件を分けて確認する用語
受付時間
連絡を受け付ける窓口の対応時間帯。受付だけで調査や復旧が始まるとは限らない。
一次応答
受領連絡や初期ヒアリングを行う条件。優先度別・時間外の適用を確認する。
作業開始
調査、隔離、設定変更、復旧作業に着手する条件。承認やアクセス権の提供が前提になる場合がある。
暫定措置
公開停止、アクセス制限、限定的な機能回復など、影響拡大を抑える対応の範囲。
復旧完了
どの機能を確認し、誰が再公開を判定した状態を指すか。表示だけか、フォームや外部連携まで含むかを明確にする。
「24時間受付」と「復旧完了」を同じ条件として扱わない
受付時間、一次応答、作業開始、暫定措置、復旧完了は別の条件です。受付可能時間だけでは、どの範囲をいつまでに復旧するかは判断できません。優先度、時間外の扱い、発注者側の承認、追加費用の条件を分けて確認してください。
| 比較項目 | 契約前にそろえる条件 | 検収時に受け取る・確認するもの | 運用中に確認するもの |
|---|---|---|---|
| 対象資産 | 本体、テーマ、プラグイン、PHP、サーバー、DNS、メール、フォーム、外部連携の対象・対象外 | 資産一覧、管理画面、契約名義、管理権限 | 資産・権限変更、対象外となった機能 |
| 更新 | 通常・緊急・計画更新、検証、本番反映、保留判断の担当 | 構成一覧、更新手順、切戻し手順 | 未適用更新、保留理由、再確認日、承認記録 |
| バックアップ・復元 | 対象データ、保管先、復元、復元テスト、追加費用条件 | 復元手順、復元確認記録、復元対象外 | 取得失敗、復元テスト結果、是正状況 |
| 緊急対応 | 受付、一次応答、作業開始、暫定措置、復旧完了を別条件で定義 | 緊急連絡表、公開停止判断者、代行順位 | 受付・対応履歴、判断記録、未解決事項 |
| 権限・引継ぎ | 発注者と委託先の権限、認証情報の保管、契約終了時の返却条件 | 管理者一覧、引継ぎ手順、独自改修の所在 | 担当変更時の権限見直し、返却・削除確認 |
| 報告・追加費用 | 監視、調査、復旧、時間外対応、第三者支援の範囲と費用発生条件 | 報告形式、対象外作業、承認方法 | 定期報告、追加作業の承認、見積変更履歴 |
保守費用や復旧に要する時間は、公開情報だけでは同じ条件で比較しにくい領域です。対象資産、対応時間、監視、調査、復旧、検証、追加費用の発生条件をそろえ、複数の委託候補へ個別見積もりを依頼してください。IPAが案内する中小企業の情報セキュリティ対策ガイドラインも、資産管理や対応体制を継続的な管理事項として検討する際の参考になります。
WordPressセキュリティ対策のよくある質問
WordPress本体だけ更新すれば十分ですか?+
十分とはいえません。テーマ、プラグイン、PHPなどの周辺環境、利用者アカウントと権限、サーバー・DNS、バックアップと復元体制も確認対象です。本体更新後にフォームや外部連携が正常に動くかを確認する運用も必要です。
多要素認証やログイン試行制限は、WordPress標準機能だけで設定できますか?+
実装場所は利用環境によって異なります。認証基盤、サーバー、WAF、追加機能、保守作業のいずれかで提供される場合があるため、現在の構成と保守契約の責任分界を確認してください。
バックアップがあれば、改ざん時にすぐ復元してよいですか?+
証跡保全や原因確認をせずに上書き復元すると、調査に必要な記録を失ったり、侵入経路を残したまま再公開したりするおそれがあります。サイト責任者と技術担当、必要に応じて保守担当で、保全・原因是正・復元の順序を判断します。
保守契約の「24時間受付」は復旧完了を意味しますか?+
意味しません。受付、一次応答、作業開始、暫定措置、復旧完了は別条件です。復旧完了に含まれる機能、優先度別の条件、時間外対応、発注者側の承認、追加費用を見積書・契約書で確認してください。
WordPressの保守・セキュリティ対応を相談したい場合
更新、権限管理、バックアップ・復元、緊急時の連絡体制を継続して担うことが難しい場合は、対応範囲や管理権限の分担を整理したうえで、WordPressの制作・保守に対応できる事業者を比較できます。
PartnerBase Mag 編集部
デジタル発注の比較・発注準備を専門に扱う編集チーム。
デジタル発注の比較・発注準備を専門に、依頼範囲、費用、選定基準を実務で使える粒度に整理しています。
支援会社を比較する
得意領域、対応サービス、地域、実績を見ながら候補会社を絞り込めます。




