WordPress のセキュリティ対策を重ねても、根本的な問いに答えられていない場合があります。「なぜ攻撃されるのか」 ── それは WordPress が動的なシステムであり、常にインターネットから接続できる状態にあるからです。攻撃対象領域（Attack Surface）を小さくする、あるいはゼロにするという発想が、静的化という選択肢の本質です。
目次
「攻撃対象領域」とは何か
攻撃対象領域（Attack Surface）とは、外部から攻撃者がシステムに侵入・悪用できる接点の総体を指します。入口が多いほど、攻撃のリスクは高くなります。
WordPress が持つ攻撃対象の主な接点は次のとおりです。管理画面（wp-admin）への不正ログイン試行、PHP 処理における任意のコード実行の脆弱性、プラグインやテーマの既知・未知の脆弱性、データベースへの SQL インジェクション、XML-RPC エンドポイントへのブルートフォース攻撃などが挙げられます。
セキュリティプラグインや WAF は、これらの接点への攻撃を「防ぐ」ことを目的としています。しかし、これらはあくまで緩和策であり、接点そのものをなくすものではありません。攻撃の手法は自動化・高度化が進んでおり、緩和策には継続的なメンテナンスコストがかかり続けます。
近年は攻撃側でも自動化ツールの活用が進み、脆弱性が公開されてからスキャンや攻撃が開始されるまでの時間が著しく短くなっています。「明日対応しよう」という人間のタイムスケールでの運用が、現実的なリスクになりつつあります。防御側が個別の脆弱性にパッチを当て続けるいたちごっこには、構造的な限界があります。
動的 WordPress が常に抱えるリスク
WordPress は通常、閲覧者がページにアクセスするたびに PHP を実行し、データベースに問い合わせてコンテンツを生成します。この「動的処理」が行われている限り、次のリスクは構造的に消えません。
PHP が動いている限り、コード実行の脆弱性リスクは存在します。プラグインに未知の脆弱性が発見された場合、パッチが公開されるまでの間、サイトは攻撃に晒されます。管理画面は公開されている状態が続くため、自動化されたスキャンやブルートフォースの対象になり続けます。データベースへの接続が常に必要な構成では、SQL インジェクションの経路も残ります。
さらに、最近では AI を使った攻撃の懸念が増え、攻撃の自動化が進むほど、こうしたリスクへの露出時間が問題になります。脆弱性が公開されてから実際の攻撃が行われるまでの時間は以前より短くなっており、担当者がパッチの適用を検討・実施するよりも先に攻撃が始まるケースも起きています。動的な WordPress を運用し続けるということは、この種の「時間との戦い」に常に参加し続けることを意味します。
静的化とは何か ── WordPress の「動的部分」を切り離す
静的化とは、WordPress で作成したコンテンツを静的な HTML・CSS・JavaScript ファイルとして書き出し、その静的ファイルをユーザーに配信する仕組みです。
この構成では、閲覧者がページにアクセスした際に PHP は実行されません。データベースへの接続も行われません。サーバは静的ファイルをそのまま返すだけになります。
結果として何が変わるか。PHP が動作していないため、PHP レベルの脆弱性を悪用する経路が存在しません。データベースへの接続が配信時に不要なため、SQL インジェクションの経路も生まれません。プラグインの脆弱性は「生成環境のリスク」に限定され、配信環境には影響しません。
攻撃者から見たとき、静的ファイルを返すだけのサーバは「攻撃できる接点」がほとんどない状態になります。
Shifter の静的化が解決すること
Shifter は、WordPress で作成・管理したコンテンツを静的 HTML として書き出し、CDN 経由で配信するサービスです。普段は WordPress の管理画面自体が停止しているため、wp-admin に対する攻撃は無効化されています。 コンテンツの更新・管理を行う時だけ WordPress 管理画面を一時的な URL で起動するため、これまでの WordPress の操作感は変わらずに静的配信の恩恵を受けられます。
Shifter による静的化によって不要になる対策があります。WAF の常時稼働、wp-admin へのアクセス制限の継続管理、XML-RPC の無効化、PHP バージョンの継続監視などは、動的 WordPress を守るために必要な作業ですが、Shifter ではその多くが不要になります。セキュリティ対策の維持コストが構造的に下がります。
また、CDN からの配信はパフォーマンス面でも効果があります。静的ファイルをエッジから返す構成は、サーバ処理を挟む動的構成と比べてレスポンスが速く、アクセスが集中しても安定しやすい特性があります。
動的処理が残る機能への対処と、リスクの分離
静的化はセキュリティ上の接点を大幅に減らしますが、すべてのリスクがゼロになるわけではありません。
コンタクトフォームや会員機能など、動的処理が必要な機能が残る場合は、外部サービスとの組み合わせになります。フォーム処理を Formrun や HubSpot Forms などの外部サービスに委ねることで、WordPress 側に動的処理を持たせない構成を維持できます。
コンテンツを生成する WordPress 環境についても、Shifter では「Shifter にログインし、さらに WordPress を起動する」という2段階の操作が必要なため、管理画面が常時インターネットに公開されている状態にはなりません。動的 WordPress のように wp-admin が常に外部からアクセス可能な状態と比べると、生成環境へのリスクも構造的に限定されています。
静的化が向いているサイト・向かないサイト
更新頻度が低いコーポレートサイト、採用サイト、キャンペーンサイトは、静的化と相性が良い典型例です。閲覧者全員に同じコンテンツを返すサイトであれば、動的処理を維持する理由が薄く、静的化によってセキュリティと表示速度の両面でメリットを得られます。
一方、EC サイト、会員サービス、多くのメンバーが日常的に更新・運営に関わる大規模サイト、独自開発のプラグインを活用しているサイトは、動的処理が前提の機能に依存しているため、静的化の適用範囲に制約が生まれます。
「WordPress で作ったから動的のまま」という惰性で運用されているサイトは少なくありません。現在のサイトが本当に動的処理を必要としているかを一度問い直すことが、静的化を検討する最初のステップです。
まとめ
セキュリティ対策は「攻撃を防ぐ」から「攻撃点をなくす」という発想への転換が、静的化の本質です。AI を使った攻撃が当たり前になりつつある今、脆弱性が公開されてから悪用されるまでの時間はさらに短くなっていくと考えられます。人間のタイムスケールでパッチを当て続けるという防御の構造には、限界があります。WAF やセキュリティプラグインは引き続き有効な緩和策ですが、AI による攻撃が常態化する環境では、その維持コストと対応負荷は今後も増していく可能性があります。静的化は攻撃対象領域を構造的に減らすことで、そのいたちごっこから根本的に距離を置く選択肢です。すべてのサイトに適用できるわけではありませんが、適合するサイトにとっては今後ますます有力な選択肢になると考えています。
関連リンク
- WordPress サイトを高速・安全・メンテナンスフリーに Shifter
- コーポレートサイトに動的 WordPress は必要か
- WordPress の改ざんの手口と対策
- WordPress セキュリティプラグイン完全ガイド
当社へご興味をお持ちいただきありがとうございます。
「こんなことやってみたい！」と、ぜひ気軽にご相談ください。
担当者よりご連絡差し上げます。