WordPressのadmin-ajax.phpへ大量アクセスがある時の切り分け|Bot・プラグイン・攻撃の見分け方

WordPressのadmin-ajax.phpへの大量アクセスをログと盾で安全に調査するイメージ

「WordPressのadmin-ajax.phpへ大量アクセスが集中し、サーバーが重い」と困っていませんか?
アクセスログに同じURLが何千件も並ぶと、攻撃なのかプラグインの不具合なのか判断しにくいものです。

管理画面やフォームが動いていても、CPU使用率が上がりPHPワーカーが埋まると、
ページ表示の遅延や500・503エラーにつながります。急いで止めたい場面ほど、入口を丸ごと塞ぎたくなります。

しかしadmin-ajax.phpは、WordPress本体と多くのテーマ・プラグインが使う共通の通信窓口です。
ファイル単位で遮断すると、投稿編集、自動保存、検索、フォーム、カートなど正常な機能まで壊すおそれがあります。

よこやま良平

ITエンジニアとして20年以上WordPressに携わり、復旧を多数手がけてきたよこやま良平です。わたしの現場経験をもとに、admin-ajax.phpの大量アクセスを安全に切り分ける順番を解説します。

この記事でわかること
  • admin-ajax.phpへの通信が必要な理由
  • 大量アクセスを最初の10分で確認する手順
  • Heartbeat・プラグイン・Bot・攻撃の見分け方
  • actionから呼び出し元を特定する方法
  • 正常な機能を壊さず負荷を止める対処

結論から言うと、admin-ajax.phpのURLだけを見ても原因は分かりません。
発生時刻、POSTのaction、ログイン状態、呼び出し元、負荷の変化をそろえると、対処すべき処理が見えてきます。

まず現状を保存し、正常処理と異常処理を分けてから、頻度調整・プラグイン修正・WAF・侵害調査を選びます。
全面遮断は最後まで避け、影響範囲の狭い対処から進めましょう。

目次

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか?」
自信を持って答えられますか?

WordPress緊急チェック50

こんなお悩みはありませんか?

  • ある朝、サイトを開いたら真っ白画面になっていた
  • 管理画面にログインできなくなって手が止まった
  • 身に覚えのない記事やページが勝手に増えていた
  • プラグインを更新したらサイト全体が崩れてしまった
  • 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

WordPressのadmin-ajax.php大量アクセスだけで攻撃と断定しない

WordPressのadmin-ajax.phpに大量アクセスがあっても、それだけでBotや攻撃と断定してはいけません。
同じURLの裏側で、WordPress本体、ログイン中の編集者、公開フォーム、各種プラグインが別々の処理を実行するからです。

admin-ajax.phpは複数機能が共有する受付口

AJAXは、ページ全体を再読み込みせず、ブラウザとサーバーの間で必要なデータだけを送受信する仕組みです。
WordPressでは、多くのAJAX通信がwp-admin/admin-ajax.phpへ集まります。

URLが同じでも、送信されたactionという値によって呼び出されるPHP処理は変わります。
宅配センターの住所だけを見ても荷物の届け先が分からないように、URL件数だけでは実行内容を特定できません。

actionとログイン状態で処理先が分かれる

WordPress公式仕様では、ログイン済みユーザーのactionはwp_ajax_で始まるフック、
未ログインユーザー向けはwp_ajax_nopriv_で始まるフックへ振り分けられます。

切り分けに必要な4要素
  • いつ、何回、どの間隔で届いたか
  • POST本文のactionは何か
  • ログイン済み画面か公開ページか
  • どのテーマ・プラグイン・本体機能が登録した処理か

HTTP 200や400も成功・攻撃の証明にはならない

HTTP 200が大量に並んでも、目的の処理が成功したとは限りません。
WordPress側がエラー内容を200で返す実装もあり、応答本文や後続のサイト変化まで確認する必要があります。

反対に400や応答本文の0は、action不足、登録されていない処理、入力不備などでも起こります。
ステータスコード1種類やIPの国だけで結論を出さず、複数の材料をそろえるのが安全です。

WordPressのadmin-ajax.php大量アクセスを最初の10分で記録する

WordPressのadmin-ajax.phpが高負荷を起こした時は、設定変更より先に、同じ時刻のログと負荷を保存してください。
先にキャッシュ削除やプラグイン停止をすると、原因を再現できず、正常化した理由も分からなくなります。

admin-ajax.phpの通信を複数のログ画面で比較し原因を切り分けるイメージ

障害時刻とサーバー負荷を1分単位でそろえる

最初に、表示が遅くなった時刻、500・502・503が出た時刻、サーバー会社の制限通知時刻をJSTで控えます。
次にCPU、メモリ、PHPワーカー、データベース接続数のグラフを同じ範囲で保存します。

アクセス件数が増えていても、CPUやPHP処理時間が平常なら緊急性は低いことがあります。
一方、少ない回数でも1回の処理が重ければ、数十件でワーカーを占有する場合があります。

変更前に保存するもの
  • 対象時間帯のアクセスログとエラーログ原本
  • CPU・メモリ・PHPワーカーのグラフ
  • 障害画面、サーバー通知、発生時刻
  • 有効なテーマ・プラグインと更新日時の一覧
  • 直前に行った更新・公開・広告配信・外部連携

時間帯・IP・User-Agent・Refererを集計する

件数は、1日合計ではなく1分・5分単位で集計します。
同じIPから一定間隔で来るのか、多数のIPから同時に来るのか、管理画面のRefererがあるのかを比較してください。

標準的なアクセスログから、時刻とadmin-ajax.phpの行を絞る例は次のとおりです。
実際の列位置やログ形式はサーバー会社で異なるため、原本のコピーに対して実行します。

grep 'POST /wp-admin/admin-ajax.php' access.log > admin-ajax-sample.log
cut -d' ' -f1 admin-ajax-sample.log | sort | uniq -c | sort -nr | head
awk '{print $4}' admin-ajax-sample.log | cut -d: -f1-3 | sort | uniq -c

個人情報やCookieを含む可能性があるため、ログ原本を公開サイトや共有チャットへ貼らないでください。

標準ログにactionがなければ別の場所で確認する

多くのアクセスログには、POST本文に入ったactionが記録されません。
その場合、URLだけを何時間眺めても、プラグイン名や処理内容は特定できません。

自分の操作で再現する通信は、ブラウザ開発者ツールのNetworkでadmin-ajax.phpを選び、送信内容を確認します。
本番ログへPOST本文を常時記録する方法は、認証情報や入力内容を残す危険があるため、安易に有効化しないでください。

WordPressのadmin-ajax.phpでHeartbeat・プラグイン・Botを見分ける

WordPressのadmin-ajax.php大量アクセスは、周期、action、画面操作との連動を比べると、正常機能・不具合・Botを分けやすくなります。
IP数だけで分類せず、1回の処理時間と繰り返し方も確認してください。

正常通信と異常な大量通信がWordPressサーバーへ届く違いを示すイメージ

Heartbeatは15〜120秒周期なら正常候補

Heartbeat APIは、WordPressに標準搭載された定期通信です。
公式資料では、画面を開いている間に15〜120秒間隔で動き、自動保存や投稿ロック、状態更新などに利用されます。

actionがheartbeatで、ログイン中の編集画面を開いた時間と一致し、タブを閉じると減るなら正常候補です。
ただし、多人数が複数タブを長時間開くと回数が積み重なり、低性能サーバーでは負荷要因になります。

正規プラグインは特定操作と既知actionが対応する

検索絞り込み、在庫確認、フォーム送信、チャット、アクセス集計などは、公開画面からadmin-ajax.phpを呼ぶことがあります。
対象ページを開く、ボタンを押す、入力するという操作と通信が対応すれば、呼び出し元を追いやすくなります。

問題は、表示するだけで重い集計を毎回実行する、失敗時に短い間隔で再送する、終了条件がなく連打する実装です。
正規プラグインでも、設定や競合、外部API停止によって異常な回数になるため、「正規だから安全」とは限りません。

正常処理に近い特徴
  • 管理画面や特定ページを開いた時間と一致する
  • action名が導入済みプラグインの機能と対応する
  • 一定周期または利用者の操作ごとに1回発生する
  • タブを閉じる、機能を止めると通信も止まる
  • 応答時間とサーバー負荷が許容範囲に収まる

Bot・攻撃は画面操作と無関係な偏りを示す

Botや攻撃が疑わしいのは、誰も操作していない深夜も同じactionが高頻度で続く、
存在しないactionを大量に投げる、多数IPが短時間に同じ要求を送る、といった不自然な偏りがある時です。

未ログイン向けのnopriv処理は公開ページから必要な場合がありますが、誰でも到達できるため悪用も受けやすくなります。
処理時間が長い、外部APIやDB検索を毎回行う、回数制限がない実装では、少ない通信でも負荷が高まります。

攻撃・悪用を疑う組み合わせ
  • 実利用のない時間帯にも同じactionが連打される
  • Refererが空または無関係でUser-Agentも不自然
  • 複数IPから同じ順序・同じ間隔で要求される
  • 同時刻にPHPワーカー枯渇や503が発生する
  • 不審ファイル・管理者・Cron・DB変更も見つかる

Botが見つかっても、即座にマルウェア感染を意味するわけではありません。
負荷だけなら防御と処理改善、内部変更があるなら侵害調査というように、被害の有無で次の工程を分けます。

WordPressのadmin-ajax.phpのactionからプラグインを特定する

WordPressのadmin-ajax.phpを安全に直すには、action名を手掛かりに登録元のプラグインやテーマを特定します。
ファイル名ではなく、フック登録と実際の再現操作を結び付けることが重要です。

プラグインのactionからadmin-ajax.phpの呼び出し元を特定するイメージ

ブラウザのNetworkで自分の操作を再現する

管理画面や公開ページで問題が再現できるなら、開発者ツールを開き、NetworkをFetch/XHRで絞ります。
admin-ajax.phpのRequest PayloadまたはForm Dataにあるaction、Initiator、応答時間を記録してください。

同じ操作を1回だけ行い、何本の通信が発生するかを確認します。
何も操作していないのに数秒ごとに増えるなら、自動ポーリング、再送ループ、別タブ、ブラウザ拡張も候補です。

公開ページの機能は、ログアウトした別ブラウザでも再現します。
ログイン時だけならwp_ajax側、ログアウト時にも同じならwp_ajax_nopriv側を優先して確認でき、調査範囲を狭められます。

wp_ajaxフックをプラグインファイルで検索する

action名が分かったら、検証用コピーまたは安全なサーバー検索機能で、wp_ajax_とwp_ajax_nopriv_の登録を探します。
actionがshop_filterなら、wp_ajax_shop_filterのような文字列が登録されている可能性があります。

検索結果がプラグイン1件に絞れても、すぐ削除はしません。
その機能がフォーム、決済、会員処理、バックアップなど業務に必要か、停止時の影響を先に確認してください。

検索に出ない場合は、action名を変数で組み立てる実装、mu-plugins、テーマ、外部連携も確認します。
キャッシュされた古いJavaScriptが削除済みプラグインのactionを送り続けるケースもあるため、ブラウザ側のファイルURLも控えます。

ステージング環境で1機能ずつ停止して比較する

本番で一括停止すると、原因以外の機能まで止まり、利用者への影響が大きくなります。
バックアップからステージング環境を作り、候補プラグインの設定、該当機能、プラグイン本体の順に1つずつ停止します。

各段階で、通信回数、応答時間、CPU、画面機能を同じ操作で比較します。
通信が減っても必要機能が壊れた場合は、停止を本番へ反映せず、更新・設定変更・開発元確認へ切り替えます。

わたしの実務では、action名と再現操作を先に固定すると、闇雲なプラグイン停止より短時間で原因へ到達できます。

WordPressのadmin-ajax.php大量アクセスを原因別に止める

WordPressのadmin-ajax.php大量アクセスは、原因に合う範囲だけを調整するのが正解です。
Heartbeat、正規プラグイン、公開AJAXの悪用では、有効な対策が異なります。

Heartbeatは無効化より間隔と利用状況を見直す

Heartbeatが主因なら、不要な管理画面タブを閉じ、同時編集者数を確認します。
そのうえで、サイト用途に支障がない範囲で間隔を延ばすか、特定画面だけ頻度を調整します。

完全に無効化すると、自動保存、投稿ロック、セッション関連などへ影響する場合があります。
変更前後に投稿編集と自動保存を試し、ログ件数だけでなく機能が保たれているか確認してください。

編集者がいない時間にもheartbeatが続くなら、放置タブ、監視ブラウザ、管理画面を開く外部ツールを探します。
サーバー側だけを変える前に、どの端末・セッションが定期通信を発生させているかを確認しましょう。

重いプラグイン処理は回数と処理時間を分けて直す

回数が多い場合は、ポーリング間隔、画面イベントの重複登録、失敗時の再送条件を見直します。
1回が重い場合は、DB検索、外部API、画像処理、集計範囲、同時実行を確認します。

POST型のadmin-ajax.phpは通常のページキャッシュだけでは軽くならないことがあります。
「キャッシュを入れれば解決」と決めつけず、処理本体の計測、プラグイン更新、設定変更、代替機能を比較しましょう。

公開AJAXは認可と回数制御を狭く追加する

未ログイン利用者が使うactionでは、nonce確認、入力値の検証、権限が必要な処理の認可、処理量の上限を実装側で確認します。
nonceだけをログイン認証の代わりにせず、更新・削除・情報取得の権限を個別に判定する必要があります。

WAFやレート制限は、admin-ajax.php全体ではなく、対象action、発信元の挙動、短時間の回数を基準に段階導入します。
決済やフォーム送信を誤遮断しないよう、監視モード、少数IP、短い期間から確認してください。

対策後は、正規利用者の成功率、応答時間、403・429の増加を観察します。
攻撃件数が減っても問い合わせや購入まで減った場合は、条件が広すぎる可能性があるためすぐ見直します。

やってはいけない一括対処
  • admin-ajax.phpを.htaccessで全面拒否する
  • 原因確認前に全プラグインを削除する
  • 海外IPを一括拒否して完了と考える
  • 本番でPOST本文を無期限に丸ごと記録する
  • 負荷が下がっただけで侵害なしと判断する

WordPressのadmin-ajax.phpから侵害調査へ切り替える条件

WordPressのadmin-ajax.php大量アクセスと同時に内部変更が見つかったら、単なる負荷対策ではなく侵害調査へ切り替えます。
通信を止めても、作成済みの管理者やバックドア、予約処理が残れば再発するからです。

ファイル・管理者・Cron・DBの変化を時刻で照合する

疑わしいactionが集中した時刻の前後で、PHPファイルの更新、不明な管理者、WP-Cronイベント、optionsや投稿の不審変更を確認します。
アクセスログの200だけでは成功を証明できませんが、内部変更が同時に起きれば疑いは強くなります。

見覚えのないaction名が、未知のプラグインや不審ファイルに登録されている場合も注意が必要です。
正規ファイルとの差分、設置時刻、呼び出し元、外部通信を保全し、ファイル1個だけを先に消さないでください。

証拠を保存してから公開制限と認証失効を行う

侵害が疑われる場合は、ログ、ファイル、DB、ユーザー一覧、Cron一覧を時刻情報ごと保存します。
その後、業務影響を確認しながらメンテナンス、WAF、接続元制限などで被害拡大を抑えます。

管理者パスワード、ホスティング、SFTP、DB、外部連携の認証情報は、安全な端末から変更し、既存セッションも失効します。
同一サーバー内の別WordPressや古いCMSも確認し、侵入口と再生成元まで除去してから公開を戻してください。

ログや不審ファイルを消す前に保全すると、攻撃経路と再発原因を追える可能性が高まります。

WordPressのadmin-ajax.php大量アクセスでよくある質問

WordPressのadmin-ajax.phpについて、切り分け中によく迷う点をまとめます。
一律の回数基準より、平常値、処理時間、必要機能、内部変更の組み合わせで判断してください。

admin-ajax.phpは何回から攻撃ですか?

共通の固定回数はありません。利用者数、編集タブ、プラグイン、サーバー性能で正常値が変わります。平常時との増加率、1回の応答時間、CPUやPHPワーカー、actionの偏りを一緒に確認してください。

admin-ajax.phpをrobots.txtで拒否すればBotは止まりますか?

robots.txtは協力的なクローラーへの案内であり、攻撃者のアクセス制御にはなりません。admin-ajax.phpの必要な通信を止める仕組みでもないため、WAFやアプリ側の検証を原因に合わせて使います。

Heartbeatを完全に止めても大丈夫ですか?

自動保存、投稿ロック、セッションやプラグイン機能へ影響する可能性があります。不要タブを閉じ、間隔や対象画面を調整し、編集と自動保存のテストを行ってから判断してください。

actionがアクセスログに出ない時はどうしますか?

自分の操作で再現できる通信はブラウザのNetworkで確認し、action名からプラグインのwp_ajaxフックを検索します。本番でPOST本文を記録する場合は、機密情報を避け、短時間・限定範囲で行ってください。

WordPressのadmin-ajax.php大量アクセスはactionから安全に切り分ける

WordPressのadmin-ajax.phpへ大量アクセスがある時は、URLを全面遮断せず、action、ログイン状態、周期、呼び出し元、負荷をそろえて確認します。
同じURLでも、Heartbeat、正規プラグイン、実装不具合、Bot、攻撃では対処が違います。

安全な確認順
  • 障害時刻・ログ原本・サーバー負荷を保存する
  • 1分・5分単位でIP・周期・応答時間を比較する
  • POSTのactionとログイン状態を確認する
  • ブラウザ操作とwp_ajaxフックから呼び出し元を特定する
  • 頻度調整・機能修正・WAFを狭い範囲から適用する
  • 内部変更があれば証拠保全後に侵害調査へ切り替える

正常な通信を残しながら負荷だけを下げるには、原因の名前を付けられるところまで切り分けることが重要です。
変更後は件数だけでなく、フォーム、編集、自動保存、決済など必要機能も確認してください。

不審ファイルや管理者、Cron、DB変更が重なる場合は、負荷対策だけで終わらせないでください。
証拠を残して侵入口と再生成元まで調べることが、再発を防ぐ近道です。

admin-ajax.phpの高負荷や攻撃を自分で解決できない時は

WordPress修復マルウェア駆除トラブル専門「クイックレスキュー」

admin-ajax.phpのactionが分からない、サーバー負荷でサイトが止まる、不正アクセスや改ざんも疑われる場合は、
クイックレスキューへご相談ください。

こんなお悩みはありませんか?
  • admin-ajax.phpの大量アクセス元を特定できない
  • CPUやPHPワーカーが埋まり503が繰り返す
  • プラグインを止めると必要な機能まで壊れる
  • Bot負荷と不正アクセスの違いを判断できない
  • 不審ファイルや管理者も見つかり侵害が心配
  • ログを保全しながら復旧と再発防止を進めたい

ログ確認、負荷原因の特定、感染調査、復旧、再発防止までまとめて対応します。
正常な機能を壊す前に、現在の状況をご相談ください。

3つの安心保証
  • 万一復旧できない場合やマルウェア駆除できない場合は全額返金保証で安心
  • 90日間再感染保証・動作保証で安心
  • 初期費用・調査費用0円で安心

この記事を書いた専門家

こんにちは!20年以上ITエンジニアとして活動してきた
よこやま良平です。

Wordpress復旧やサイト修復、オンライン講座では
776件以上のレビューを頂いており

「すぐに復旧してくれる!」
「当日行ってくれて助かった!」など

評価は4.9/5.0と非常に高く好評です。

またWordPress、SEO、Officeなど30冊以上の書籍を出版しており、
売上ランキング1位を連続で獲得致しました。

その他これまでに3000以上のサービス・システム・サイトを作成。

多くの方の「できない」や「悩み」を解決してきました。
その観点からわかりやすく解説しています。

目次