WordPressのXML-RPCは無効化すべき？Jetpackへの影響と安全な対策

2026年10月26日

WordPress XML-RPCを止めるべきか、攻撃対策とJetpackへの影響を示すアイキャッチ

WordPressのアクセスログに大量の/xmlrpc.phpが見つかると、「すぐ無効化すべきか」と迷います。結論は、使っていなければ遮断を検討し、Jetpackなどが使っていれば接続を維持したまま制限と監視を行うことです。ログにアクセスがあるだけでは侵害を意味しません。一方、何の確認もなく放置する必要もありません。

この記事では、XML-RPCの役割、依存する連携の調べ方、サーバー・WAF・WordPressでの対策の違い、設定後の動作確認と戻し方まで説明します。操作は自分が管理するサイトだけで行ってください。画面や機能の名前は契約先、プラグイン、WordPressの構成によって異なります。2026年10月26日時点でWordPressとJetpackの公式資料を確認しました。

XML-RPCは何をする？危険性と誤解を整理

XML-RPCは、WordPressの外部から投稿や情報の取得などを行うための仕組みです。通常はサイト直下のxmlrpc.phpがリクエストを受けます。WordPressの公式API資料には投稿、メディア、コメントなどの操作が記載されています。ブラウザで記事を読む人が使う画面とは異なり、アプリや外部サービスとの通信経路です。

この入口があること自体を「脆弱性」と断定するのは正確ではありません。ただし認証を伴う機能へ大量の試行が向けられることがあります。WordPress公式の総当たり攻撃対策資料も、xmlrpc.phpを狙う試行、とくにsystem.multicallを挙げ、不要なら無効化し、必要なら制限とレート制御を勧めています。対策すべき対象は、通信の有無だけでなく、認証情報の使い回し、権限の過大付与、監視不足などを含む全体のリスクです。

「アクセスがある」と「ログインされた」は違う

アクセスログにPOST /xmlrpc.phpが見えても、それだけで認証が成功したとは分かりません。接続元、時刻、応答コード、送信量、WAFの判定、同じ時間帯の管理者操作を照合します。認証成否がサーバーのアクセスログだけでは分からない場合もあります。公開ログへパスワードやリクエスト本文を貼り付けないでください。

一方で、予期しない管理者アカウント、記事の改ざん、不明なプラグイン、外部への転送、急なメール送信量の増加が同時に見えるなら、通常の設定変更より侵害対応を優先します。現状のログとファイルを保存し、管理者、ホスティング事業者、セキュリティ担当で影響を確認してください。詳しい初動はWordPress侵害の疑いがあるときの初動対応も参照できます。

遮断すれば安全になる、とは限らない

XML-RPCを遮断すると、その経路を使った攻撃試行は届きにくくなります。しかし管理画面のログイン、REST API、古いプラグイン、PHP、ホスティング環境の問題が同時に解消されるわけではありません。「xmlrpc.phpを閉じたから更新や2段階認証は不要」と考えると、別の入口を残します。WordPress公式のセキュリティ資料は、本体・テーマ・プラグインを最新に保つことを基本として示しています。

反対に、XML-RPCを使う機能があるサイトで一律に遮断すると、投稿アプリやJetpackの接続が止まることがあります。つまり判断は「危険そうだから即遮断」ではなく、どの連携が何のために使っているかから始めます。

攻撃を受けやすいサイトと、対応の優先度

優先度を決めるときは、ログの件数だけでなく、サイトが持つ情報と停止時の影響を重ねます。問い合わせだけを受ける小規模サイトと、会員情報や注文を扱うサイトでは、同じ認証試行でも事故時の影響が違います。さらに、管理者のパスワードが他サービスと共用されている、外部連携の担当者が不明、WAFが停止している、バックアップを戻したことがない、という条件が重なるほど対策を急ぎます。

たとえば架空の会社Aは企業サイトを運営し、XML-RPCを使う連携はありません。CDNのログに連日試行があり、管理画面は2段階認証済みです。この場合、遮断の効果と業務影響を短い検証で確かめ、サーバーかCDNで止める計画を立てやすいでしょう。架空の会社BはJetpackで統計とバックアップを利用しています。ログに試行があっても、全面遮断でバックアップが止まるほうが事故になります。正規通信を維持しながら制限する計画が必要です。

架空の会社Cは会員サイトで、管理者が退職後も残り、外部投稿ツールの契約も不明です。この場合、XML-RPCの遮断だけを先に実施するより、不要アカウントの停止、認証情報の更新、連携台帳の作成、ログ保存を同じ変更計画に入れます。ここで挙げた会社は説明用の架空例で、実際の事故や改善実績ではありません。

「404なら安全」「200なら危険」と決めつけない

HTTP応答コードには経路ごとの意味があります。CDNでブロックされた応答、Webサーバーのエラーページ、WordPressが返す応答を、数字一つで同一視できません。公開URLをブラウザで開いた結果だけでも、POSTで利用する正規のXML-RPC機能の可否は判断できません。実際に利用するサービス側で成功を確かめ、その時間帯のWAFとサーバーログを照合します。テストのために第三者サイトへリクエストを送る必要はありません。

観測したこと	そこから言えること	次の確認
XML-RPCへのアクセスがある	外部から到達を試みている	正規の連携か、WAFと認証ログを照合
403などで遮断されている	その層では拒否されている	正規サービスの通信まで止めていないか
Jetpackの接続エラー	XML-RPC経路の問題が一因の可能性	公式診断、WAF、サーバー設定を確認
見知らぬ管理者や改ざん	侵害の疑いがある	保全・封じ込め・原因調査へ移行

無効化前にJetpack・投稿アプリ・外部連携を調べる

遮断前の点検は、機能の棚卸しと小さなテストの二段階で行います。管理者だけが気づく連携もあれば、編集者のスマートフォンから投稿するときだけ使う連携もあります。管理画面のプラグイン一覧だけで「利用なし」と判断せず、運用担当者と外部サービス側の設定を合わせて確認します。

最初の15分で作る依存関係表

サイトの管理者、編集者、制作会社、運用代行者に、外部から投稿・更新・分析・バックアップを行う仕組みがないか聞きます。Jetpack、WordPress.com連携、モバイル投稿アプリ、旧式の自動投稿ツール、独自のXML-RPC実装などが対象です。名称だけでなく、利用者、最後の成功時刻、止まった場合の影響、代替手段、動作確認担当を記録してください。

Jetpackの公式資料は、WordPress.comとサイトの接続にXML-RPCを使用すると説明しています。xmlrpc.phpを全面遮断すると接続が壊れる場合があります。したがって「Jetpackが入っている」だけで必ず遮断不可と断定するのではなく、現に利用中の機能、接続状態、提供元の案内を確認します。一部の機能だけ有効でも、接続の基盤として使われる可能性があります。

確認項目	記録する情報	担当	完了条件
外部連携	サービス名、用途、契約、管理者	サイト運用者	使う・使わないが説明できる
通信経路	XML-RPC、REST API、別方式のどれか	制作・保守担当	推測でなく提供元資料か実測で確認
直近の動作	最後の成功日時、試験操作の結果	機能担当者	遮断前の正常状態を保存
障害時の影響	投稿停止、統計停止、バックアップ停止など	事業責任者	許容停止時間と戻す判断者を決める

REST APIへの移行は「置き換え可能」かを確認する

WordPressにはREST APIとアプリケーションパスワードもあります。新しい連携を作る場合には候補ですが、今動いているJetpackや既存ツールが自動でREST APIへ切り替わるわけではありません。提供元が対応するか、必要な操作が揃うか、認証情報を個別に失効できるかを確認してから移行します。アプリケーションパスワードはブラウザの管理画面ログイン用ではなく、API向けの認証情報です。連携ごとに発行し、不要になったものだけ失効できます。

REST APIを一律に停止する方法は避けてください。WordPress公式FAQは、REST APIを無効化すると管理画面の機能が壊れると注意しています。XML-RPCとREST APIは別経路です。どちらを使っているかを切り分けずに両方止めれば、編集作業まで止まる恐れがあります。

依存の有無が分からない場合

「使っていないはず」でも担当者が不在、古い設定が残る、代理店だけが知っている、という場合があります。そのまま本番で遮断しないでください。まずアクセスログの一定期間を保全し、直近の正規通信の有無と発信元を確認します。ログの保持期間が短いホストでは、調査できる期間を明記します。ログがないことは利用がない証明ではありません。

次に検証環境で制限を試し、投稿・Jetpack接続・自動処理・バックアップ・決済など影響が出る機能をチェックします。検証環境がない場合は、アクセスが少ない時間帯に短い変更枠を設け、担当者と復旧手順を準備します。判断を急ぐほど、「誰が戻せるか」を先に決めることが重要です。

担当者へ確認する質問例

「外部サービスはありますか」だけだと、担当者がWordPressとの通信方式を知らず、重要な接続を見落とすことがあります。そこで作業単位で聞きます。「スマートフォンから記事を公開するか」「WordPress.comと連携した統計・バックアップ・セキュリティ機能を使うか」「別の管理画面で下書きや画像を送っているか」「夜間に自動で投稿や同期をしているか」「障害時の通知はどこに届くか」。回答は、機能名と利用者を結びつけて残します。

代理店が管理している場合には、XML-RPCに依存するか、移行するならどのAPIを使うか、変更時に誰が試験するかを尋ねます。契約書や運用手順に担当者がないなら、依存関係表へ「未確認」と書き、公開変更の承認条件にします。未確認の欄を空白のまま残すより、調査責任者と期限を決めたほうが安全です。

検証用の操作は本番の注文やメールを実際に送らない方法を選びます。テスト投稿を非公開にする、テスト用アカウントを使う、通知先を内部へ限定するなど、対象機能に合う方法を事前に決めます。ただし、検証用の設定と本番設定が違いすぎると結果を移せません。差分を一覧にし、最終確認を本番の変更枠で実施します。

連携があるサイトで「止められる日」を設計する

古い投稿アプリを使い続けるためにXML-RPCを永久に公開しておく、という二択にする必要はありません。連携の提供元がREST APIに対応していれば、試験環境で機能、認証、権限、ログ、障害時の戻し方を確認して切り替えます。移行の完了条件は、普段の投稿が一回成功したことだけではありません。画像アップロード、予約投稿、更新、失敗時の通知、アプリケーションパスワードの失効まで確認します。

移行中は旧経路と新経路を同時に使う期間を限定します。併用期間が長いほど、使われないはずの認証情報やルールが残ります。切り替え日、旧経路を止める日、失敗時の判断者を決め、停止後も一週間ほどログで旧経路への正規通信がないか点検します。こうすれば「今は必要だが、いつかは減らす」という具体的な計画になります。

不要なら遮断、必要なら制限・監視する

対策には層があります。サーバーやCDNでxmlrpc.phpへの到達を止める方法、WAFで危険な通信を制限する方法、WordPress側で認証を必要とするXML-RPCメソッドを止める方法は、効く範囲が同じではありません。どこに設定したかを記録し、機能テストとログで結果を確認します。

利用なし：サーバーやCDNで到達を遮断する

依存する連携がないと確認できたら、ホスティング事業者のセキュリティ設定、CDNのWAF、またはWebサーバー設定でXML-RPCへのアクセスを制限する方法があります。共有サーバーで設定権限がない場合は、事業者が提供する機能とサポート窓口を利用します。WordPressのプラグインでHTTPリクエストを受けてから拒否するより、サーバーやエッジで遮断したほうがPHPへ届く通信を減らせる場合があります。ただし実際の経路やルールによって効果は変わります。

ルールを置く場所は本番構成に合わせます。Apacheの.htaccess、Nginx、CDNでは記法と適用順が違います。Webサーバー設定を直接編集できない契約では、例をそのまま貼り付けないでください。誤ったルールはサイト全体を停止させる可能性があります。変更前の設定を保存し、復旧手段を確認してから実施します。

利用あり：必要な通信を残し、試行を絞る

Jetpackなどが必要なら、全面遮断ではなく、ホストやCDNのWAFでレート制限、不審な通信の検知、必要に応じた送信元の制限を検討します。WordPress公式も、利用する場合の制限とレート制御を推奨しています。ただし送信元IPを固定で許可する方法は、サービス側のIP変更や共有環境の構成変更に対応できる運用が前提です。提供元の最新の許可リストや手順を確認し、更新担当を決めます。

大量の失敗試行に対しては、管理者の強固で固有のパスワード、2段階認証、不要なアカウントの削除、権限の最小化、異常な認証への通知も必要です。WAFだけでは漏れた正しいパスワードの使用をすべて防げません。管理画面の具体的な点検はWordPress管理画面の乗っ取り対策で整理しています。

WordPressのフィルターは「完全遮断」ではない

WordPressにはxmlrpc_enabledフィルターがあります。公式リファレンスによると、これは認証が必要なXML-RPCメソッドの有効・無効を制御します。名前と違い、xmlrpc.phpへのHTTPアクセスを丸ごと止めるものではなく、認証を必要としないpingbackやカスタムメソッドも別扱いです。「コードを1行入れたから入口は完全に閉じた」と報告しないでください。

細かくメソッドを制御したい場合のxmlrpc_methodsフィルターも公式に記載されています。しかし導入するコードは、既存プラグイン、マルチサイト、外部連携との互換性を確認してからレビューします。記事中の断片を本番に貼って完了とするより、ホストの設定と運用を含めて設計するほうが安全です。

WAFルールを作るときに決めること

ルール名を「XML-RPC対策」だけにすると、後で何を守るルールか分からなくなります。対象ホスト名、対象パス、対象メソッド、適用モード、例外、所有者、作成日、見直し日を記録します。複数サイトを同じCDNアカウントで管理する場合、一つのルールが別サイトにも当たる可能性があります。変更前に対象範囲を画面で確認してください。

レート制限の閾値はサイトごとの正規通信に合わせて決めます。記事中の固定値を万人向けに断定しません。正規連携が短時間に複数リクエストを送ることもあるため、まずWAFのイベントを見て、誤検知、同一送信元の集中、時間帯を確認します。IPアドレスだけでは同じ組織の複数利用者を区別できない場合があります。逆に一つの攻撃元がIPを変える場合もあります。

緊急に通信量を下げる必要がある場合でも、遮断の対象、開始時刻、終了・再評価時刻を明確にします。暫定ルールを作ったまま忘れると、半年後に新しい連携が動かない理由になります。変更を戻す判断基準を「担当者が異常に気づいたら」だけにせず、正規接続の失敗、バックアップ失敗、編集者の投稿失敗など観測できる条件にします。

アプリケーションパスワードと権限を見直す

XML-RPCが必要な連携であっても、WordPress管理者の通常パスワードを複数サービスに共有する運用は避けます。WordPress公式のアプリケーションパスワードは、連携ごとに個別発行・個別失効できるよう設計されています。連携が対応するなら、主パスワードとは別に管理してください。発行したアプリケーションパスワードが利用できる操作は、そのユーザーの権限にも依存します。投稿しか必要ないサービスへ管理者権限を与えないことが重要です。

ただし、アプリケーションパスワードを使えば全ての問題が消えるわけではありません。連携先で認証情報が漏れれば、その権限で操作される可能性があります。サービスごとの名前、発行日、利用者、権限、最後の利用、失効手順を管理します。退職者や契約終了した委託先の認証情報は、連携を確認したうえで失効します。管理者の個人アカウントを共用するより、担当者が追える構成にしてください。

対策の層	目的	注意点	確かめること
CDN・WAF	外部からの到達や頻度を制限	正規連携の通信も巻き込む可能性	許可対象とWAFイベント
Webサーバー	特定パスへの通信を拒否	設定ミスでサイト全体に影響	HTTP応答と他ページの正常表示
WordPressフィルター	一部メソッドの動作を制御	HTTP入口の完全遮断ではない	対象メソッドと連携テスト
認証・運用	資格情報の悪用と見逃しを減らす	単独では通信量を止めない	権限・2段階認証・通知

設定後の確認と戻し方：安全に運用へ移す

セキュリティ設定は「保存できた」だけでは完了しません。意図した通信を止め、必要な機能は保ち、問題があれば戻せるところまでが一つの作業です。変更を行う人と、業務機能を確認する人を分け、結果を記録します。

変更前に残す基準値

変更前に、公開ページ、管理画面、投稿の保存、フォーム、必要な外部連携が正常か確認します。XML-RPC関連ログの件数と、WAFで許可・遮断した件数の見え方を記録します。数値は曜日や時間帯で変動するため、単純な前後比較だけで攻撃がゼロになったとは言えません。注文や会員データを扱うサイトでは、復旧可能なバックアップと変更後のデータ保全策も確認します。

変更枠を決めて小さく適用する

CDN、サーバー、WordPressプラグインの複数箇所を同時に変えないでください。問題が起きたときに原因を切り分けられません。まず一層だけ変更し、反映時刻、ルール名、担当者、戻す操作を記録します。WAFには監視モードと遮断モードがある製品もあります。提供機能があるなら、先に監視結果を見て正規通信への影響を確認します。

適用後は、一般公開ページの表示、管理者ログイン、記事の保存、連携サービスの接続、予約投稿やバックアップなどの定期処理を確認します。Jetpackを使う場合は、Jetpackの管理画面と公式診断も見ます。正規の接続が通らなくなったら、該当する新しいルールを戻し、ログを保存してから原因を調べます。広い許可ルールを追加して無理に通す前に、対象の通信だけを特定します。

変更後24時間・7日間で見ること

直後に動いた連携でも、夜間のバッチや週次バックアップが失敗することがあります。変更後24時間はWAFイベント、エラーログ、正規連携の成功、編集者からの問い合わせを確認します。7日後には、定期処理が一巡したか、異常な認証試行が続いていないか、ルールの例外が広すぎないかを再点検します。数値の改善だけでなく業務が動いているかを評価してください。

障害が起きたときの戻し方を具体化する

設定直後にJetpackの接続だけが失敗した場合は、変更した層を一つずつ戻して原因を探します。CDNとサーバーの両方を同時に緩めると、どちらが原因だったか分からなくなります。まず変更履歴から最も新しいルールを特定し、そのルールだけを無効にして、接続テストをやり直します。戻しても直らなければ、別の設定や通信障害を疑います。

投稿アプリだけが失敗した場合には、アプリのエラー時刻、WordPress側のログ、WAFイベントを並べます。失敗した投稿をむやみに再送すると重複記事が生まれます。下書き一覧で同じ題名や投稿時刻の重複を確認し、担当編集者と処理を決めます。バックアップの失敗なら、失敗分を手動で補う必要があるか、次回まで待てるかをデータの更新頻度から判断します。

もし悪意あるアクセスの増加と正規連携の障害が同時に起きたら、単なる設定不具合として片付けません。サーバー負荷、ログの保持期間、アカウント操作、ファイル変更を確認し、必要に応じてホスティング事業者へ連絡します。被害の疑いがある間は、証拠を消す可能性のある一括復元を急がず、初動手順に切り替えます。

公開後の運用ルールに落とす

一度の設定が長く有効とは限りません。新しいプラグインを入れた、新しい制作会社と契約した、CDNを移した、ホストのプランを変えた、という時点で依存関係とルールを見直します。月次点検では、XML-RPCの通信量だけでなく、例外ルールの追加、連携の失敗、管理者とアプリケーションパスワードの一覧を確認します。

運用台帳には、現在の判断、公式情報の確認日、変更した設定、影響を受ける連携、検証結果、戻す担当者を残します。後任が数か月後に見ても「なぜ全面遮断しなかったか」「どの連携のために例外を置いたか」が分かる状態が合格です。対策は強さだけでなく、運用し続けられるかでも評価してください。

よくある質問：XML-RPCだけを止めればWordPressは守れますか？

いいえ。XML-RPCに向けた試行の一部を減らせても、管理画面、REST API、プラグイン、テーマ、PHP環境など別の経路は残ります。本体と拡張機能の更新、権限整理、認証強化、バックアップ、ログ監視を組み合わせてください。特にPHPの脆弱性はWordPressの設定だけで修正できない場合があります。ホスティング事業者が適用した修正と、サイト側の更新を分けて確認します。

よくある質問：Jetpackが入っていたら対策できませんか？

対策できます。ただし、xmlrpc.phpを丸ごと止めると接続が壊れる可能性があるため、実際に使う機能を確認し、WAFやレート制限、認証・権限の点検などを組み合わせます。例外を設定する場合は、Jetpack公式の最新手順に従い、送信元や接続方法が変わったときに見直せるようにします。接続が正常でも、正規以外の試行がなくなるわけではありません。

よくある質問：ログが見られない共有サーバーではどうしますか？

管理画面で取得できるアクセスログやWAF履歴、ホストの障害通知を調べます。必要な情報がない場合は、サポートへ対象ドメイン、時間帯、確認したい経路、保持期間を伝え、取得できる範囲を聞きます。分からない状態を「攻撃なし」と報告せず、調査できない項目と暫定対策を記録します。将来の事故対応を考え、ログ保存と通知が可能なプランやサービスも比較してください。

時点	確認内容	問題があったら
変更前	設定、バックアップ、連携、ログを記録	準備不足なら実施を延期
変更直後	公開表示、管理画面、連携、WAF判定	新ルールを戻して原因を分離
24時間後	定期処理、障害通知、ログの変化	失敗した処理の再実行要否を判断
7日後	週次処理と例外ルールを再点検	ルールと運用手順を見直す

結論と次の行動

XML-RPCは一律に「危険だから止める」ものでも、「WordPressの標準機能だから放置する」ものでもありません。まず連携の有無を確かめます。使っていなければ、サーバーやCDNで遮断し、公開ページと管理機能を検品します。使っていれば、必要な通信を残しながらWAF、レート制限、認証強化、ログ監視を組み合わせます。どちらの場合も、変更を戻せる状態を作ってから作業してください。

サイトの管理者が複数、制作会社との契約が古い、Jetpackや外部投稿の利用状況が分からない場合は、いきなり設定を変えず、連携台帳と変更手順を先に作ることが近道です。担当者、設定場所、確認方法、戻す条件を一枚にまとめれば、次回の脆弱性対応にも流用できます。運用の整理や実装の学習を進めたい方は、WithAIの無料学習コンテンツも活用してください。