WordPressの「XML-RPC」は、外部のアプリやサービスからWordPressを操作・連携するための仕組みです。
WordPress本体にはxmlrpc.phpというエンドポイントがあり、外部から投稿・コメント・サイト情報などを扱うためのXML-RPC APIを提供しています。
一方で、XML-RPCは不正ログイン試行や大量リクエストの対象になることもあるため、「無効化した方がよい」と紹介されることがあります。 ただし、JetpackなどXML-RPCを利用するサービスもあるため、すべてのWordPressサイトで一律に無効化するのは適切ではありません。
30秒でわかる結論
- XML-RPCは、外部アプリ・サービスからWordPressへ通信するための仕組み
- WordPressでは
xmlrpc.phpがXML-RPCの入口になる - WordPress 3.5以降、XML-RPCは標準で有効
- Jetpackなど、現在もXML-RPCを必要とするサービスがある
- XML-RPCはブルートフォース攻撃や大量アクセスの対象になることがある
- 使っていないサイトなら、セキュリティ上の観点から制限を検討できる
- Jetpack等を使っている場合は、一律に
xmlrpc.phpを遮断しない xmlrpc_enabledフィルターはXML-RPC全体を完全停止するものではない- 初心者は「必要な連携があるか確認してから制限する」と判断すればよい
WordPressのXML-RPCとは？
XML-RPCは、XML形式のデータとHTTP通信を使って、離れたシステムから処理を呼び出す仕組みです。
WordPressでは、外部サービスがxmlrpc.phpへリクエストを送ることで、投稿、固定ページ、コメント、メディア、サイト情報などを扱えます。
XML-RPCのイメージ
WordPress管理画面をブラウザで直接操作する代わりに、外部アプリやサービスがxmlrpc.phpを通じてWordPressへ命令を送る仕組みです。
WordPress公式のXML-RPCサーバー実装には、WordPress APIのほか、MetaWeblog API、Movable Type API、pingbackなどとの互換機能が含まれています。
XML-RPCは何に使われる？
XML-RPCは、WordPressと外部サービスをつなぐために使われます。
- 外部アプリからWordPressを操作する
- 外部サービスから投稿・コメント等を管理する
- JetpackなどWordPress.com連携サービスと通信する
- 一部の古い投稿ツール・連携システムを利用する
- pingbackを処理する
現在も完全に不要な機能ではない
XML-RPCはREST APIより古い仕組みですが、現在もJetpackなど既存システムで利用されています。 「古い＝削除してよい」と単純に判断しないでください。
xmlrpc.phpとは？
xmlrpc.phpは、WordPressインストール先のルートにあるXML-RPC用の入口です。
通常、ブラウザで直接https://example.com/xmlrpc.phpを開くと、POSTリクエストだけを受け付ける旨のメッセージが表示されます。
これは、ブラウザで普通にページを見るためのファイルではなく、外部システムからPOST通信を受けるためのエンドポイントだからです。
Jetpack公式も、XML-RPC接続確認の方法として/xmlrpc.phpへアクセスし、XML-RPCサーバーがPOSTリクエストを受け付ける状態か確認する手順を案内しています。
XML-RPCが危険と言われる理由
XML-RPCそのものが「脆弱性」なのではありません。 ただし、外部からWordPressへリクエストを送れる入口なので、攻撃者に悪用されることがあります。
ブルートフォース攻撃の対象になる
WordPressのユーザー名とパスワードを大量に試す不正ログイン攻撃で、XML-RPCの認証機能が狙われることがあります。
通常のログイン画面だけを保護していても、XML-RPC経由の認証を許可していると、別経路から試行される可能性があります。
大量リクエストの対象になる
xmlrpc.phpへ大量のリクエストが送られると、PHP実行やデータベース処理が発生し、サーバー負荷が高くなる場合があります。
pingbackが悪用されることがある
XML-RPCにはpingback関連の機能があります。 過去には、第三者サイトへの大量リクエストにWordPressサイトが利用される問題もありました。
攻撃の具体的な実行方法は不要
サイト運営者が知るべきなのは、XML-RPCが外部通信の入口になり得ることと、不要なら制限できるという点です。 攻撃手順を試す必要はありません。
XML-RPCは無効化すべき？
結論は、利用状況によって判断するです。
| 利用状況 | 判断 |
|---|---|
| Jetpackを利用 | 一律無効化しない |
| 外部アプリ連携あり | 必要性を確認 |
| XML-RPCを使う機能なし | 制限を検討 |
| 攻撃ログが大量 | 制限・WAF・レート制限を検討 |
初心者向けの判断
Jetpackや外部アプリを使っていないなら、XML-RPCへのアクセスを制限する選択肢があります。 ただし、何に使われているか確認せず完全遮断するのは避けてください。
Jetpackを使う場合はXML-RPCを遮断しない
JetpackはWordPress.comとサイトを接続するためにXML-RPCを利用します。
Jetpack公式では、xmlrpc.phpが403・404になる場合、セキュリティプラグイン、WAF、ホスティング側ルールなどがXML-RPC通信を遮断していないか確認するよう案内しています。
Jetpack利用者の確認項目
xmlrpc.phpが403になっていないか- セキュリティプラグインでXML-RPCを遮断していないか
- WAFでWordPress.comからの通信を拒否していないか
- ホスティング側でXML-RPCがブロックされていないか
- Jetpackのサイトヘルス診断にエラーがないか
セキュリティ対策と機能停止を混同しない
Jetpackを使っているのにxmlrpc.phpを完全遮断すると、Jetpack接続や関連機能が正常に動かなくなる可能性があります。
xmlrpc_enabledで無効化すれば完全停止できる？
WordPressにはxmlrpc_enabledというフィルターがあります。
認証が必要なXML-RPCメソッドを無効にする例
add_filter( 'xmlrpc_enabled', '__return_false' );
ただし、WordPress公式は、このフィルターについてXML-RPC全体を完全に無効化するものではないと明記しています。
このフィルターが制御するのは、投稿などに使われる「認証が必要なXML-RPCメソッド」です。 pingbackや、プラグイン等が追加した認証不要メソッドまで必ず停止するわけではありません。
名前だけで判断しない
xmlrpc_enabledという名前から「XML-RPC全体がOFFになる」と思いやすいですが、WordPress公式ではそうではないと説明されています。
完全なアクセス制限が必要なら、WAF・サーバー設定・セキュリティプラグインなど別の方法も含めて考えます。
XML-RPCを制限する方法
XML-RPCを使っていないことを確認できた場合は、いくつかの方法で制限できます。
セキュリティプラグインで制限する
初心者には、XML-RPC制御機能を持つセキュリティプラグインを利用する方法が比較的分かりやすいです。
ただし、設定名や制限範囲はプラグインごとに異なるため、「XML-RPC無効化」が何を止める機能なのか公式説明を確認してください。
WAF・レンタルサーバー側で制限する
レンタルサーバーによっては、WordPressセキュリティ機能やWAFでXML-RPCへのアクセスを制御できる場合があります。
WordPressのPHP処理へ到達する前に遮断できるため、大量アクセス対策として有効な場合があります。
.htaccess等で制限する
Apache系サーバーでは、.htaccessやサーバー設定でxmlrpc.phpへのアクセスを拒否する方法もあります。
初心者は設定をコピーしない
WebサーバーがApacheかnginxか、Jetpackを使っているかなどで適切な設定が変わります。 他サイトの設定例をそのまま貼り付けるのではなく、利用中サーバーの公式手順を確認してください。
完全無効化より部分的な制限がよい場合もある
XML-RPCが必要な機能は残しつつ、不要なメソッドだけ制限する考え方もあります。
WordPressにはxmlrpc_methodsフィルターがあり、利用可能なXML-RPCメソッドを調整できます。
たとえばpingbackだけを制限し、Jetpack等に必要な通信を残す、といった設計も可能です。
これは開発者・サーバー管理者向けの設定です。 一般的な共用レンタルサーバー利用者は、無理にコードを追加せず、セキュリティプラグインやサーバー側機能で管理する方が安全な場合があります。
XML-RPCを止める前に確認すること
無効化前チェックリスト
- Jetpackを使っていないか
- WordPress.comとの連携がないか
- 外部アプリから投稿していないか
- 外部サービスがXML-RPCを使っていないか
- バックアップ・監視サービスが依存していないか
- 停止後にサイトヘルスや連携機能を確認できるか
特に会社サイトでは、「誰が何のために入れたサービスか分からない」状態でxmlrpc.phpを遮断すると、運用中の連携を壊す可能性があります。
XML-RPCを止めた後に確認すること
XML-RPCを制限したら、サイト表示だけではなく外部連携も確認します。
- Jetpackに接続エラーがないか
- バックアップが正常に実行されるか
- 監視サービスが正常か
- 外部投稿アプリが使えるか
- WordPress管理画面のサイトヘルスに問題がないか
- サーバーログに大量403が残っていないか
切り分け例
XML-RPC制限後にJetpackが「接続できません」と表示されるなら、セキュリティ設定がxmlrpc.phpを遮断している可能性があります。
XML-RPCとREST APIの違い
WordPressにはXML-RPC以外にREST APIもあります。 どちらも外部からWordPressのデータを扱うために使えますが、仕組みが異なります。
| 項目 | XML-RPC | REST API |
|---|---|---|
| 主な形式 | XML | JSON |
| WordPressでの歴史 | 古くから利用 | 比較的新しい |
| 主な用途 | 既存連携・Jetpack等 | 現代的なアプリ・連携 |
| 現在の扱い | 互換性のため残る | 新規開発で広く利用 |
「REST APIがあるからXML-RPCは完全に不要」とは言えません。 既存サービスがXML-RPCに依存していることがあるため、利用状況を確認して判断します。
XML-RPCを無効化してもセキュリティ対策は終わらない
XML-RPCを止めても、WordPressのログイン画面やREST API、プラグインなど別の入口は残ります。
最低限行うセキュリティ対策
- WordPress本体を更新する
- テーマ・プラグインを更新する
- 不要なプラグインを削除する
- 強いパスワードを使う
- 二要素認証を検討する
- ログイン試行回数制限を行う
- WAFを利用する
- バックアップを取る
XML-RPC停止だけで安全になるわけではない
XML-RPC制限は攻撃面を減らす対策の一つです。 WordPress全体の更新・認証・バックアップを含めて対策してください。
どんなサイトなら無効化を検討する？
個人ブログ
Jetpack等を使わないなら検討
XML-RPCを使う外部連携がなければ、制限する選択肢があります。
Jetpack利用サイト
一律無効化：非推奨
JetpackはXML-RPC通信を利用するため、必要な通信まで遮断しないようにします。
会社サイト
連携確認して判断
バックアップ・監視・外部サービスなどの依存関係を確認してから変更します。
攻撃が多いサイト
制限価値：高
XML-RPCが不要なら、WAFやサーバー側での制限を含めて対策を検討します。
教科書判定
XML-RPCは「使っているか確認してから制限」が正解
XML-RPCは古い仕組みですが、現在もJetpackなどで使われています。 そのため、すべてのWordPressサイトで一律に無効化すべきとは判断しません。
Jetpackや外部アプリを使っておらず、XML-RPCへの不審アクセスが多い場合は、セキュリティプラグイン・WAF・サーバー設定で制限を検討してください。
一方、Jetpackを利用しているサイトでは、xmlrpc.phpを完全遮断すると接続障害の原因になります。
必要な通信を残しながら防御する方が適切です。
初心者は「XML-RPC＝危険だから削除」ではなく、「必要な連携があるか → なければ制限を検討」という順番で判断してください。
よくある質問
Q．XML-RPCはWordPress 3.5以降も使われていますか？
はい。WordPress 3.5以降はXML-RPCが標準で有効になっており、現在もJetpackなど既存の連携サービスで利用されています。
Q．xmlrpc.phpを削除してもよいですか？
おすすめしません。xmlrpc.phpはWordPress本体のコアファイルです。コアファイル自体を削除するのではなく、必要に応じてアクセス制限や機能制限を行ってください。
Q．xmlrpc_enabledをfalseにすれば完全にXML-RPCが止まりますか？
完全停止ではありません。WordPress公式では、xmlrpc_enabledフィルターは認証が必要なXML-RPCメソッドを制御し、pingbackなどすべてのXML-RPC機能を止めるものではないと説明しています。
Q．Jetpackを使っている場合もXML-RPCを無効化できますか？
JetpackはXML-RPC接続を利用するため、xmlrpc.phpを完全遮断すると接続エラーの原因になります。Jetpackを利用する場合は必要な通信を許可してください。
Q．XML-RPCを無効化すればブルートフォース攻撃対策は十分ですか？
十分ではありません。通常のログイン画面への攻撃は残るため、強いパスワード、二要素認証、ログイン試行回数制限、WAF、更新なども合わせて行ってください。
まとめ
この記事の結論
- XML-RPCは外部サービスからWordPressを操作するための仕組み
- WordPressではxmlrpc.phpが通信の入口
- WordPress 3.5以降XML-RPCは標準で有効
- Jetpackなど現在もXML-RPCを必要とするサービスがある
- ブルートフォースや大量アクセスの対象になる場合がある
- 使っていないなら制限を検討できる
- Jetpack利用時は一律にxmlrpc.phpを遮断しない
- xmlrpc_enabledはXML-RPC全体の完全停止ではない
- 無効化後は外部連携やサイトヘルスも確認する
XML-RPCは「古いから不要」「危険だから必ず停止」と単純に判断する機能ではありません。 自分のサイトで使われているかを確認し、不要なら攻撃面を減らすために制限するのが現実的な運用です。
「WordPressのログインURLを変更する必要はある？」もあわせて確認してください。