目次
最終更新日：2026年7月29日
2026年6月、アクシアは自社サイトをWordPressから静的サイト（Astro）へ移行しました。よく「WordPressをやめればセキュリティが安心」と言われますが、本当にそうなのか。移行前の旧サーバーのアクセスログと、移行後のログを実際に突き合わせて数えてみました。結論から言うと、攻撃は止まっていません。止まったのは攻撃ではなく、別のものでした。そして、その過程で自社の守りにあいていた穴も見つかりました。
まず結論
- 攻撃は止まっていない。移行から1ヶ月半が経っても、1日およそ300件・1,000個以上のIPアドレスから叩かれ続けています。
- 止まったのは「WordPressに処理させること」。移行前は、攻撃を受けるたびにWordPressが動いて応答を作っていました（1日約1,173件）。移行後はゼロです。
- ログイン画面は守れていた。ログイン試行1,011件は全て認証の段階で遮断され、WordPressまで届いたものはゼロ。
- それでも穴はあった。守っていたのはログイン画面だけで、
xmlrpc.phpという別の入り口は開いたままでした。攻撃の大半はそこに来ていました。
つまり、「WordPressだから危ない」のでも「静的サイトだから安全」のでもありません。変わったのは、攻撃が届いた先に「動くプログラム」があるかどうかです。この記事では、その実データと、そこから経営判断として何が言えるかを書きます。技術的な中身は後半に分けたので、読み飛ばしていただいても結論は変わりません。
何を測ったのか
比較したのは次の2つです。
- 移行前：旧WordPress環境のWebサーバーのアクセスログ。2026年6月2日〜7日の6日間。
- 移行後：現在の配信基盤（CDN）のアクセスログ。2026年6月28日〜7月28日の31日間。
移行前のログは、実はもう存在しないと思っていました。旧環境はサーバーが自動で入れ替わる構成で、サーバー本体もロードバランサーも、移行のときに全て削除済みだったからです。ところが、運用の中でこまめに取っていたサーバーイメージのバックアップの中に、ログが丸ごと残っていました。移行の数日前まで記録されていた、旧環境の最後の姿です。
期間が6日と31日で違うので、以下はすべて1日あたりに換算して比べています。自社からのアクセスと死活監視は除外しました。
移行前──ログイン画面は守れていた。守れていない場所があった
先に、当時の守りの状態を書いておきます。WordPress本体はその時点の最新版に保ち、管理画面には二要素認証、セキュリティプラグインも導入済み。ログイン画面と管理画面には、WordPressに届く手前でID・パスワードを要求する認証をかけていました。設定ファイルも外部から読めないようにしてありました。
その部分については、狙いどおりに機能していました。
- ログイン画面（
wp-login.php）への攻撃 1,011件は、全て手前の認証で遮断された。WordPressまで到達したものはゼロ。 - 管理画面のプログラムへの攻撃 798件も、同じく全て遮断。
- 設定ファイル（
wp-config.php）を読み出そうとするアクセスも、全てサーバー側で拒否。 - アクセスログを見る限り、侵入や情報の持ち出しに至った形跡は見当たりません。
ここまでなら「ちゃんと守れていた」という話です。問題は次でした。
守っていたのは、ログイン画面だけだった
WordPressには、ログイン画面のほかにも外部から呼び出せる入り口があります。代表的なのが xmlrpc.php という、外部アプリからの投稿などに使われる古い仕組みです。うちはこの機能を使っていませんでした。使っていないのに、開いたままにしていました。
そして、攻撃の大半はまさにそこに来ていました。
xmlrpc.php への攻撃は6日間で5,244件。しかもその内訳が特徴的で、24個のIPアドレスが、それぞれきっちり150回ずつ叩いていました。1つのIPあたりの回数に上限を決めて、大量のIPで分担する。発信元を分散させて検知を避ける、典型的な形です。
正直に書きますが、これはうちの不備です。使っていない機能なのだから、認証をかける以前に入り口ごと閉じておくべきでした。知らなかったわけではなく、優先順位の中で後回しになったまま何年も過ぎた、というのが実態に近い。
もう一つの wp-json（REST API）は、こちらは仕様として公開されている入り口です。塞げばよかったという単純な話ではなく、使う機能との兼ね合いで「どこまで公開するか」を判断する必要があります。判断すべきことが増える、というのがWordPressを運用するということでもあります。
攻撃されるたびに、WordPressは1回ずつ動いていた
ここがこの記事のいちばんの発見です。
攻撃を受けたとき、サーバーの中で起きることは1つではありません。大きく3段階あります。
3段目が問題です。1日およそ1,173回、攻撃のたびにWordPressが呼び出され、応答を組み立てて返していました。
しかもこれは、WordPressを狙った攻撃だけの話ではありません。/.env（設定ファイル）や /.git/config（ソースコード）のように、WordPressとまったく関係ないファイルを探しに来たアクセスに対しても、WordPressが動いて「見つかりません」のページを作って返していました。これはWordPressの標準的な構成では自然に起きることで、存在しないURLへのアクセスはWordPressが受け取って処理する仕組みになっているからです。存在しないものを探されるたびに、律儀に1ページ描いて返していたわけです。
セキュリティプラグインが攻撃を弾いていた分も同じです。「防いだ」というのは、毎回プログラムが動いて、判定して、拒否しているということです。防御が働いているとき、サーバーは休んでいません。
移行後──攻撃は止まらない。届く先が無くなっただけ
では静的サイトに移行して、攻撃は止まったのか。止まっていません。
- 移行から1ヶ月半後の31日間で、WordPressを狙ったアクセスが9,502件（1日約307件）。送信元は1,041個のIPアドレス。
xmlrpc.phpを狙った攻撃も、移行前と同じ特徴のまま続いています（207個のIPが、それぞれきっちり150回ずつ）。同じやり方の攻撃が、同じように届き続けているということです。- そして、これらの攻撃・探索に対して正常な応答が返ったものは0件。全て「そんなものは無い」で終わっています。
攻撃側から見れば、やっていることは何も変わっていません。変わったのは、その先に叩かれて動くものが無くなったことだけです。
これが「WordPressをやめる」ということの実体だと考えています。攻撃を減らしたのではなく、攻撃が当たる面を減らした。防御を強くしたのではなく、守るべきものを減らした。
ここから何が言えるか
1. WordPressが危ないのではない。維持し続けられるかが問題
今回いちばん言いたいのはこれです。うちは、決していい加減な運用をしていたわけではありません。本体は最新版に保ち、管理画面には二要素認証、ログイン画面には手前の認証、セキュリティプラグインも入れていました。実際、ログイン突破は1件もされていません。
それでも、使っていない入り口が開いたままでした。閉じるべきだと知っていれば、設定を1行変えるだけで済む話です。
WordPressのセキュリティ対策とは、一度設定して終わりではなく、本体とプラグインの更新を追い続け、使わない入り口を閉じ続け、新しく見つかった穴を塞ぎ続ける作業です。仕組みが悪いのではありません。それを何年も維持し続けられる体制があるかどうかが問われます。
自動車や建物と同じで、乗る・住むこと自体は誰にでもできますが、点検を怠っていい理由にはなりません。そして点検を「気がついたときにやる」運用にしていると、たいてい気がつかないまま時間が経ちます。
2. 「攻撃されていない」と「攻撃が通っていない」は違う
ログを見るまで、正直こんなに毎日叩かれているとは思っていませんでした。何も起きていないように見えるサイトでも、実際には毎日数百件から数千件のアクセスが「開いている扉はないか」と試しています。
今回のうちのように被害が無くても、それは攻撃が来ていないという意味ではありません。防御が機能しているという意味です。そして防御は、放っておくと機能しなくなります。
3. 静的化は万能ではない。攻撃面がゼロになるわけでもない
誤解のないように、はっきり書いておきます。
静的サイトにすれば安全、ではありません。この記事で消えたと言っているのは「WordPressという動くプログラム」に対する攻撃面であって、それ以外は残ります。たとえばうちのサイトにも問い合わせフォームがあり、その裏側にはプログラムが動いています。そこは今も守るべき対象です。配信基盤やドメインの設定不備、外部サービスとの連携部分も同様です。攻撃面は小さくなりましたが、ゼロにはなっていません。
また、すべてのサイトを静的にすべきだとも考えていません。会員機能や予約、日々の複雑な更新が必要なサイトでは、動的な仕組みが必要です。うちのようなコーポレートサイトは、たまたま静的化と相性が良かった側です。
WordPressのまま運用を続けるという選択も当然あります。その場合に大事なのは、更新と点検が確実に回る体制があるかです。WordPressのまま安全に運用することと、静的サイトへ移行することは、どちらが正しいかではなく、そのサイトの用途と体制で決まります。
［技術者向け］計測方法と、この数字で言えないこと
ここからは技術担当者向けです。読み飛ばしていただいて構いません。数え方と、この計測の限界を書きます。
「どこまで到達したか」をどう判定したか
ステータスコードだけでは、応答を返したのがWebサーバーなのかWordPressなのか区別できません。たとえば404には「Webサーバーが返した404」と「WordPressがテーマの404ページを生成して返した404」の両方があり、どちらも同じ404です。401や403も同様に、手前で止まったのか奥まで行ったのか判別できません。
そこで応答サイズで出所を判定しました。
- Webサーバーが生成した応答（認証要求・アクセス拒否）＝いずれも数百バイトの組み込みページ
- WordPressが生成した応答（404ページを含む）＝十数KB以上のテーマ付きHTML
この計測では、その中間にあたるサイズの応答が1件もありませんでした。2つの集団がはっきり分離しているので、境界値をどこに置いても集計結果は変わりません。第2段階（実行環境まで渡ったが空振り）は、PHPの実行環境が「該当スクリプトが存在しない」と返したもので、エラーログの記録と一致します。
ただし、この方法には例外があります。REST API（wp-json）は、エラーであってもテーマ付きのHTMLではなく数百バイトの小さなJSONを返します。つまりサイズだけで見るとWebサーバーの拒否と区別がつきません。実際、最初の集計ではこれを取り違えていました。REST APIは手前の認証の対象外だったので、このパスへのアクセスはサイズではなくパスで判定し直しています（該当41件・全体の0.6%）。判定方法を1つのルールで押し切ろうとすると、こういう取りこぼしが出ます。
なお、クライアントIPはロードバランサー経由のため X-Forwarded-For の先頭を採用しています。ロードバランサー自身のIPで数えると、送信元がすべて同一に見えてしまいます。
この数字で言えないこと
- 移行前の数字は「下限」です。当時はWAF（Webアプリケーションファイアウォール）を手前に挟んでいたため、WAFが弾いた分はサーバーのログに残っていません。実際に飛んできた攻撃はこれより多かったはずです。WAFは現在は使っておらず、当時の記録も残っていないため、弾いた件数は事後には測れませんでした。
- 移行前後で「攻撃の総量」は比較できません。前はWAF通過後、後はWAFなしの素通しで、測定点も期間も違います。比較して意味があるのは「WordPressが処理した回数（1日約1,173件 → 0件）」の方です。この記事で「攻撃が減った／増えた」と書いていないのはそのためです。
- N=1、しかも6日間です。これは1サイトの、6日間と31日間の実測にすぎません。曜日や季節の変動も吸収できていませんし、「世の中のWordPressサイトの何割が」といった一般化はできません。
- 「150回ずつ」は試行回数そのものではありません。
xmlrpc.phpは1リクエストで複数の認証試行をまとめて送れる仕様があるため、リクエスト数＝パスワード試行回数とは限りません。実際の試行回数はこれより多い可能性があります。 - 第3段階に計上した中には、実際の訪問者がフォームを読み込んだ際のAPIアクセスが約2%含まれています。結論は変わりませんが、すべてが攻撃というわけではありません。
- 「侵入の形跡なし」はアクセスログの範囲での話です。ログに現れない経路まで検証したわけではありません。
ついでに見つかった細かい話
興味深かったのは、移行前（WAF通過後）の攻撃件数の方が、移行後（WAFなし）より多かったことです。フィルタを通った後の数字の方が多い。理由は断定できませんが、xmlrpc.php が正常に応答を返す＝「生きているWordPressがここにある」と攻撃側に確認できることで、集中的に狙われた可能性は考えられます。移行後は全て「無い」と返るので、割に合わないと判断されているのかもしれません。N=1で期間も違うため、あくまで仮説です。
もう1つ。存在しないはずのパスに対して1件だけ正常応答が返っていて肝を冷やしたのですが、応答サイズがトップページと完全に一致していました。WordPressがトップページを返していただけで、情報が出たわけではありません（存在しないURLに正常応答を返してしまうのは行儀が悪いので、これ自体は直すべき挙動です）。
まとめ
- WordPressから静的サイトへ移行しても、攻撃は止まっていない。1日約300件・1,000個以上のIPから叩かれ続けている。
- 消えたのは攻撃ではなく、攻撃のたびにWordPressが動いて応答を作っていたこと（1日約1,173件 → 0件）。
- 移行前、ログイン画面への攻撃1,011件は全て手前の認証で遮断され、突破はゼロ。それでも、使っていない
xmlrpc.phpは開いたままだった。 - 問題は仕組みではなく、それを何年も維持し続けられる体制があるか。「被害ゼロ」は「攻撃が来ていない」ではなく「今のところ防御が機能している」という意味でしかない。
- ただし静的化しても攻撃面はゼロにならない。フォームなど動く部分は残り、そこは引き続き守る必要がある。