XML-RPC は何をする機能なのか
XML-RPC は、WordPress が「外部アプリからのリモート操作」を受け付けるための古いインターフェースです。xmlrpc.php というファイルに対して、XML 形式のリクエストを送ることで、
ブログエディタアプリから投稿する
スマホアプリから記事を投稿・編集する
一部の古いサービスと連携する
といったことができるようになっていました。
プログラミングでたとえると、
「JSON ではなく XML でしゃべる古い API エンドポイント」が、サイトの表に出ているイメージです。
今は REST API が主流になっていて、XML-RPC を本当に必要とするケースはかなり限られています。
なぜ「不要なら無効化」がキーワードになるのか
XML-RPC は攻撃の“的”になりやすい
XML-RPC は、ログイン情報を使って記事投稿や設定変更ができるインターフェースです。
つまり、ここに対して大量のログイン試行（総当たり攻撃）を仕掛けられると、
通常のログイン画面とは別ルートからパスワードを破られる可能性が出てきます。
さらに、XML-RPC には「1 リクエストで複数のメソッドをまとめて呼べる」仕組みがあり、
これを悪用すると、少ないリクエスト数で大量のログイン試行を行うことができます。
天才プログラマー視点で言えば、
「認証付きの古い API が、インターネットに向けて開きっぱなし」
という状態は、それだけで攻撃面（attack surface）を広げていることになります。
もしあなたが XML-RPC を使っていないなら、
「使わない入口は閉じる」というのが、最もシンプルで強い防御です。
今の運用で本当に必要なケースは少ない
昔は、
Windows Live Writer のようなデスクトップブログエディタ
古いスマホアプリ
一部の外部サービス
が XML-RPC を前提にしていました。
しかし今は、
WordPress 公式アプリは REST API を使う方向に進み
ブラウザからのブロックエディタが十分に使いやすくなり
外部連携も Webhook や REST API が主流
という状況です。
「どうしてもこの古いツールを使いたい」という明確な理由がない限り、
XML-RPC を有効にしておく必要性はほとんどありません。
具体的にどんなリスクがあるのかをもう少し深掘り
ブルートフォース攻撃の踏み台になりやすい
XML-RPC には system.multicall というメソッドがあり、
1 回のリクエストで複数のログイン試行をまとめて送ることができます。
攻撃者はこれを利用して、
通常のログイン画面よりも効率よくパスワード総当たりを行います。
ログイン画面に対しては reCAPTCHA やロックアウトプラグインを入れていても、
XML-RPC 側がノーガードだと、そちらから攻められる、という構図です。
プログラミング的に言えば、
「/login には防御を入れたのに、/api/legacy-login が丸裸」
みたいな状態です。
使っていないなら、そのエンドポイントごと閉じてしまうのが筋が良いです。
DDoS の一部として悪用される可能性
XML-RPC を使って、他サイトへのリクエストを大量に飛ばすような攻撃手法も知られています。
あなたのサイトが「踏み台」として使われると、
直接被害を受けるだけでなく、
サーバー会社からの注意や制限の対象になることもあります。
もちろん、すべてのサイトが即危険というわけではありませんが、
「自分は XML-RPC を使っていないのに、攻撃の入口だけは開けている」
という状態は、避けておくに越したことはありません。
自分のサイトが XML-RPC を使っているかどうかの考え方
こんな運用をしていなければ、ほぼ不要
次のようなことをしていなければ、XML-RPC を使っている可能性はかなり低いです。
外部の古いブログエディタアプリから投稿している
「XML-RPC が必要」と明記された古いプラグインやサービスと連携している
自分で XML-RPC を叩くスクリプトを書いている
逆に言えば、
ブラウザから普通にログインして記事を書いているだけ
スマホアプリも特に使っていない
という運用なら、「不要」と判断してほぼ問題ありません。
「もしかして使っているかも」と不安なときのスタンス
もし「何かが使っているかもしれない」と不安なら、
一度 XML-RPC を無効化してみて、
何かの機能が急に動かなくなるかどうかを観察する、という手もあります。
プログラミングでも、
「この関数、本当に使われてる？」と思ったら、
一旦コメントアウトしてテストを回してみる、というやり方をしますよね。
同じノリで、
「使っていないなら閉じる」「問題が出たら、そのとき必要性を再検討する」
という段階的なアプローチで十分です。
無効化の考え方（コードのイメージ）
※ここでは「どういう発想で無効化するか」を、コードのイメージで説明します（実際の編集はテーマやプラグイン側で行うことが多いです）。
xmlrpc_enabled フィルターで無効化するイメージ
WordPress には xmlrpc_enabled というフィルターがあり、
ここで false を返すことで XML-RPC を無効化できます。
イメージとしては、こんな感じです。
add_filter( 'xmlrpc_enabled', '__return_false' );
これは、
「XML-RPC を有効にするか？」という問いに対して、
常に false を返すフックを差し込んでいるイメージです。
実際には、
セキュリティ系プラグインがこの設定を内部でやってくれていることも多いので、
初心者は「プラグインの設定で XML-RPC をオフにする」という形で触れることが多いと思っておけば OK です。
サーバーレベルで xmlrpc.php へのアクセスを遮断するパターン
もう一段強くやるなら、.htaccess やサーバー設定で xmlrpc.php へのアクセス自体をブロックする、という方法もあります。
イメージとしては、
<Files xmlrpc.php>
Require all denied
</Files>
のような設定です。
これは、
「アプリ側で無効化する前に、そもそも入口で弾く」
という発想で、
フレームワークの前段に WAF を置くのと似た考え方です。
具体例でイメージする「無効化した方がいいサイト」
例1：普通の企業サイト・サービスサイト
運用イメージ：
管理画面から記事を更新
問い合わせフォームは別プラグイン
外部アプリからの投稿はしていない
この場合、XML-RPC を有効にしておく理由はほぼありません。
むしろ、
ログイン攻撃の入口
DDoS の踏み台
として悪用されるリスクだけが残ります。
「セキュリティ系プラグインを入れて、XML-RPC を無効化する」
「サーバー側で xmlrpc.php をブロックする」
といった対策を、基本セットとして考えてよいレベルです。
例2：個人ブログ＋スマホアプリも特に使っていない
運用イメージ：
PC ブラウザからだけ投稿
スマホでは閲覧だけ
外部連携も特にしていない
この場合も、XML-RPC は不要です。
REST API や通常の管理画面だけで十分に完結しています。
「よく分からないけどデフォルトだからそのまま」ではなく、
「自分の運用には不要だから明示的に閉じる」
という判断ができると、一気に“設計している感”が出てきます。
まとめ：古い API の「出口管理」をちゃんとやる
「XML-RPC を不要なら無効化」というのは、
単なるチェックボックスの話ではなく、
自分のサイトが
どんな入口を持っていて
どのプロトコルで
どんな権限の操作を受け付けているのか
を意識する、ということでもあります。
プログラミングの世界では、
使わないエンドポイントは公開しない
レガシーなインターフェースは段階的に閉じていく
というのが健全な設計です。
WordPress でも同じで、
「XML-RPC を本当に使っているのか？」と一度立ち止まり、
使っていないなら閉じる。
それだけで、
攻撃面が一つ減り、
ログイン攻撃のリスクも下がり、
“よく分からない古い機能が開きっぱなし”という不安からも解放されます。
