WordPressの乗っ取り対策の情報は「プラグインを入れて、更新して、強いパスワードに」というものばかりです。どれも正しいのですが、この対応には更新という作業を永遠に続ける必要があるという前提が隠れています。乗っ取りが減らないのは、対策を知らないサイトが多いからではなく、更新を止めてしまったサイトが世界中に常時存在するからです。

この記事では、乗っ取りが増え続ける3つの構造的理由を整理した上で、①更新体制を仕組み化する従来型の対策と、②そもそもCMSに依存しない静的な構成という第三の選択肢を、判断軸つきで解説します。要点は次の3つです。

• 乗っ取りは「選ばれる」のではなく「機械的に見つかる」: 更新が止まったCMSを自動攻撃が巡回している
• 従来型の対策はすべて「継続コスト」を生む: 更新代行・WAF・監視は月額が付いて回る
• 更新頻度が低いサイトには、CMSをやめて静的な構成にする選択肢がある: 私自身の移行実録がその根拠です

なお、私はWeb制作を受注する側の制作者で、このサイト自体をWordPressから静的構成へ移行しています。移行はあくまで選択肢の一つで、更新の多いサイトにはCMSが合います。その判断軸も含めて整理します。

乗っ取りの兆候と、発見が遅れる理由

乗っ取りの典型的な兆候は3つです。サイトへのアクセスが見知らぬサイトへリダイレクトされる、自分で作っていないページや広告が表示される、検索結果の説明文（スニペット）が勝手に書き換わる。いずれも被害が進んでから発覚するケースが多く、発覚のきっかけが「Googleにペナルティを受けた」や「関係者からの指摘」であることが少なくありません。

発見が遅れる理由は、改ざんが管理画面や記事の見た目に出ない場所で行われるからです。テーマの関数ファイルやデータベースにコードを仕込まれると、普段の更新作業では気づけません。総務省の国民向けサイバーセキュリティサイトも、ホームページの書き換え被害を公開事例として挙げ、ソフトウェアの更新を怠ることが主な要因だと案内しています（総務省）。JPCERT/CCも改ざん事例の分析を継続的に公開しています（JPCERT/CC Eyes）。

乗っ取りが増え続ける3つの構造的理由

「対策すればいい」で終わらせないために、なぜ乗っ取りが減らないのかを構造的に押さえます。

理由1: WordPressのシェアが世界一であること。 攻撃者は収穫を最大化するため、最も使われているソフトウェアを狙います。WordPressは世界中のサイトの3割以上で使われており（W3Techsの調査、2026年時点）、それ自体が「攻撃対象として最も割の良い標的」であることを意味します。

理由2: 攻撃が自動化されていること。 脆弱性を持つサイトを探すボットが常時ネット上を巡回し、発見すれば既知の攻撃コードを試します。つまり被害に遭うのは「誰かが狙ったサイト」ではなく「更新が止まっているサイト」です。運営者が気づかないうちに、スキャンと攻撃は繰り返されています。

理由3: プラグインという常時リスク。 WordPressの機能拡張はプラグインに依存しますが、プラグイン1つ1つが個別のソフトウェアであり、個別に脆弱性を持ちます。導入数が増えるほど、更新待ちの「窓」が増える構造です。

この3つは個別の対処ではなく、WordPressを使い続ける限り構造として付き合う性質のものです。だからこそ、次節の対策は「続けられる形」である必要があります。

従来型の対策と、その「継続コスト」

CMSを使い続ける前提での対策は、確立された定番があります。効果も実証されています。ただし、それぞれに継続コスト（月額または作業時間）が付くことを理解して選ぶ必要があります。

費用を型で整理した詳細はセキュリティ対策の費用の記事で解説していますが、ここで重要なのは、これらはWordPressを使い続ける限り「やめられない支出・作業」だということです。更新をやめると脆弱性が残り、バックアップをやめると復旧不能になり、監視をやめると発見が遅れます。CMSの利便性と引き換えに、この固定費を受け入れるのが「CMSを使い続ける」選択です。

CMSに頼らないという第三の選択肢

ここからが本題です。乗っ取りリスクの根は「脆弱性を持つソフトウェアを、サイト公開と同じサーバー上で動かし続けること」にあります。ならば、更新頻度の低いサイトでは、CMSをやめて静的な構成（HTMLの集まり）にすることで、この根そのものを取り除けます。

静的な構成では、サーバー上でCMSというソフトウェアが動きません。プラグインが存在しないのでプラグインの脆弱性もなく、「更新を止めた」状態が攻撃者のスキャンに引っかからない構造になります。セキュリティ対策が不要になるわけではありません（SSL・パスワード・バックアップは引き続き必要）が、「CMS更新という常時作業」が消えるため、従来型対策の中で最も重い継続コストを外せます。

これは理論ではなく、私が実際に実行した移行です。このサイト（groove-web.tokyo）はWordPressから静的な構成へ移行しており、移行後はCMS更新という作業が消えました。具体的な手順・失敗・検証の記録はWordPressをやめて静的サイトへ移行した全手順で公開しています。

判断の分かれ目は更新頻度です。ニュースやブログを頻繁に更新するサイトにはCMSが合います。一方、会社案内・実績紹介のように更新が月1回未満のサイトなら、CMSの利便性より固定費が重くなりがちです。公開後の運用リスクの全体像は個人に依頼したホームページの保守も参照してください。

万一乗っ取られたときの対処の型

被害に遭った場合、動く順番は次の4ステップです。

1. 切り分け: 管理画面・サーバー・バックアップの状態を確認する。ここでバックアップの有無が復旧の速度を決める
2. 復旧: クリーンなバックアップから復元するか、改ざん箇所を除去する。複雑な改ざんは専門業者への相談が早い
3. 原因特定: 侵入経路（古いプラグイン・弱いパスワード・サーバー）を特定し、塞ぐ
4. 再発防止: 前述の対策を、今度は「仕組み」として入れる

この型を見ると分かるとおり、復旧の難易度と費用は事前の準備量でほぼ決まります。バックアップと更新体制があるサイトの復旧は短く、ないサイトの復旧は長く高いものになります。

よくある質問

Q. 静的なサイトなら乗っ取りは完全に防げますか？
100%ではありません。サーバーの脆弱性やパスワード漏えいなどの経路は残ります。ただし「CMSの更新を止めない」という常時作業が消えるため、乗っ取りの主要な入口が一つ減る、と理解するのが正確です。

Q. 改ざんされていないか、自分で確認する方法はありますか？
Google Search Consoleのセキュリティ警告、見知らぬページへのリダイレクト、サーバーのアクセスログの不審な書き込みなどを確認します。確実にやるなら、セキュリティプラグインのスキャン機能や専門の診断サービスを使います。

Q. 改ざんからの復旧は自分でできますか？
バックアップと原因の見当があれば可能です。ない場合は、復旧作業を専門とする業者の利用が現実的です。被害範囲の特定には専門性が必要になるため、費用は幅があります（セキュリティ費用の記事の「型③」で整理しています）。

Q. セキュリティプラグインを入れるのは悪手ですか？
悪くありません。CMSを継続するなら必須級です。本記事の主張は「プラグインや対策が無意味」ということではなく、それらが「CMSを使い続ける場合に必要になるもの」だということです。更新の少ないサイトには、CMSを外すという別の解もある、という話です。

まとめ: 更新を「続ける」か「消す」か、それが最初の分岐

• 乗っ取りは機械的な自動攻撃で発生し、更新が止まったCMSが主な標的になる
• 従来型の対策（更新・WAF・監視）は有効だが、すべて継続コストを伴う
• 更新頻度が低いサイトには、CMSをやめて静的な構成にする選択肢がある。固定費の構造が変わる
• 万一の復旧は、事前のバックアップと体制で難易度がほぼ決まる

「WordPressのままで安全にする」のか「静的にして安全域に移す」のか。サイトの更新頻度と運用体制が分かれば、どちらが向いているかは整理できます。ご相談はお問い合わせフォームからどうぞ。