WordPressで構築されたWebサイトにおいて、サーバーログやアクセス解析を確認した際、「xmlrpc.php」というファイルに対して大量のアクセスが集中しているケースが多発しています。結論から申し上げますと、現代のWordPress運用において外部アプリ連携や特定のプラグイン（Jetpackの一部機能等）を利用していない限り、XML-RPC（xmlrpc.php）機能は無効化（アクセス遮断）することが強く推奨されます。XML-RPCを放置すると、パスワードの総当たり攻撃（ブルートフォース攻撃）やDDoS攻撃の踏み台にされ、サイトの改ざんやサーバーダウンの原因となるためです。
本記事では、WordPressのセキュリティ対策と保守運用に精通したプロの視点から、XML-RPCの仕組みとリスク、自社サイトで無効化すべきかの判断基準、そして.htaccessやプラグインを用いた安全な無効化手順を分かりやすく解説します。
XML-RPC（xmlrpc.php）とは？WordPressでの役割と現代における必要性
XML-RPCとは、HTTPを転送プロトコルとし、XMLを記述言語として使用してリモートプロシージャコール（遠隔手続き呼び出し）を行うための通信プロトコルです。WordPressにおいては、ルートディレクトリ直下に「xmlrpc.php」というファイルとして配置されています。
元々XML-RPCは、Webブラウザ以外の外部アプリケーションやサードパーティ製ツールから、WordPressの投稿作成・編集・コメント送信・メディアアップロードなどの操作を行うために実装された仕様です。
XML-RPCが活用されていた主な用途
- スマホ用公式WordPressアプリからの投稿・管理：スマートフォンやタブレットの専用アプリからサイトを更新する際の通信処理。
- トラックバック（Trackback）およびピンバック（Pingback）：他のブログやWebサイトから自サイトの文章が引用・リンクされた際に、自動的に相互通知を送受信する仕組み。
- 外部ブログエディタや外部サービスとの連携：MarsEditなどのデスクトップ用ブログ投稿ツールや、外部の自動投稿サービスとの連動。
現代のWordPressにおいてXML-RPCが不要とされる理由
かつては必須とされたXML-RPCですが、WordPressバージョン4.7以降、より高機能で安全な構造を持つ「REST API（WP REST API）」が標準導入されました。現在の公式スマートフォンアプリや主要な外部連携サービスの多くはREST API経由の通信に移行しています。
そのため、過去に構築された古い外部システムとの通信を維持している特殊な環境を除き、一般的な企業ホームページやWebメディアにおいてXML-RPC（xmlrpc.php）を有効にしておく技術的メリットはほとんど存在しません。むしろ、セキュリティ上の脆弱性（攻撃の入り口）として残ってしまうリスクの方が遥かに大きいのが現状です。
XML-RPCを放置する3つの重大なセキュリティリスク
なぜ「xmlrpc.php」はこれほどまでにサイバー攻撃者から狙われるのでしょうか。その理由は、XML-RPCの仕様上に攻撃者にとって都合の良い利便性が含まれているからです。代表的な3つのリスクを解説します。
1. ブルートフォース攻撃（system.multicallを用いた大量パスワード試行）
通常、WordPressのログイン画面（wp-login.php）から不正ログインを試みる場合、1回のHTTPリクエストに対して1回のユーザー名・パスワードの検証が行われます。そのため、ログイン試行回数を制限するプラグインやIP制限を導入することで比較的容易に防御可能です。
しかし、XML-RPCに用意されている「system.multicall」というメソッドを使用すると、1回のHTTPリクエストの中に数千個単位のユーザー名とパスワードの組み合わせをまとめて送信可能になります。これにより、攻撃者は通常のログイン画面を経由する何百倍もの効率で高速にパスワード総当たり攻撃（ブルートフォース攻撃）を実行できてしまいます。ログイン試行制限の回避策としても悪用されるため、管理者の意図しない不正ログインを許してしまう最大の要因となります。
管理画面全体のセキュリティ設定については、WordPress管理画面のセキュリティ対策完全ガイド｜ログインURL変更・2段階認証・IP制限の実装手順でも詳しく解説しています。
2. DDoS攻撃・反射攻撃（pingback.ping）の踏み台化
XML-RPCには「pingback.ping」というメソッドが存在します。これは「自分のサイトのリンクが他サイトに貼られた際、相手サーバーに通知を送る」ための機能です。
攻撃者はこの機能を悪用し、自ら用意した攻撃対象のWebサイト（ターゲットサーバー）のURLを送信元として偽装し、世界中に存在する多数のWordPressサイトのxmlrpc.phpに対して一斉にPingbackリクエストを送信します。リクエストを受けたWordPressサイトは、自動的にターゲットサーバーに対してアクセス確認を行ってしまいます。
その結果、自社のWebサイトが意図せず他者へのDDoS攻撃（分散型サービス拒否攻撃）の加害者（踏み台）として悪用されてしまうリスクが生じます。
3. サーバー負荷の増大と表示速度の遅延
直接的な改ざん被害に遭わなかった場合でも、xmlrpc.phpに対する連続的な攻撃リクエスト（Botからの機械的なアクセス）が発生すると、WebサーバーのCPUやメモリリソースが過剰に消費されます。これによりデータベース接続エラーが発生したり、一般のユーザーがサイトを閲覧する際の表示速度が著しく低下したりする障害が発生します。
原因不明のサーバー高負荷や表示遅延に悩まされている場合、ログを確認するとxmlrpc.phpへの大量アクセスが原因であったというケースは珍しくありません。Webサイト全体のセキュリティ向上とトラブル防止については、WordPressサイトのマルウェア感染・改ざんの原因と復旧手順｜被害特定から再発防止策までプロが解説をご参照ください。
XML-RPCが無効化可能かどうかの判断基準
XML-RPCを無効化する前に、自社サイトでXML-RPCに依存している機能が存在しないか確認する必要があります。以下のチェックリストを参考に判断してください。
| 利用環境・機能 | XML-RPCの必要性 | 判断と対応方針 |
|---|---|---|
| WordPress公式スマホアプリからの投稿（最新版） | 不要 | REST APIを使用するため、XML-RPCを無効化しても問題ありません。 |
| サードパーティ製プラグイン（Jetpack等の一部機能） | 一部必要になる場合あり | Jetpackの機能（統計や共有など）で問題が発生する場合は個別許可、または代替プラグインを検討します。 |
| 他サイトからのトラックバック・ピンバック受信 | 不要（推奨非表示） | スパムの要因となるため現代では不要。無効化を推奨します。 |
| 外部エディタ（MarsEdit等）からのリモート投稿 | 必要 | 使用している場合は無効化不可。ただし特定IP制限などの保護が必要です。 |
| 一般的な企業HP・集客ブログ・ECサイト | 不要 | 即座にXML-RPCを完全無効化することを強く推奨します。 |
自社で外部エディタを用いた特殊な運用を行っていない限り、基本的には無効化して不都合が生じることはありません。
XML-RPCを安全に無効化する3つの実装手順
XML-RPCを無効化する方法にはいくつかの手段があります。サーバーレベルで通信を遮断する最も確実な方法から、プラグインを使った簡単な方法まで、自社の管理体制に合わせた手法を選択してください。
手順1: .htaccessファイルを編集してアクセス遮断（最も推奨）
ApacheやLiteSpeedサーバー環境を使用している場合、Webサーバーのルートディレクトにある「.htaccess」ファイルに拒否設定を追加するのが最も効果的です。WordPressのPHP処理が実行される前段階（サーバー層）でアクセスを破棄できるため、サーバー負荷を最小限に抑えることができます。
以下コードを .htaccess ファイルの冒頭付近（# BEGIN WordPress より上部）に追記します。
【.htaccess記述例】
<Files xmlrpc.php>
Order Allow,Deny
Deny from all
</Files>
※Apache 2.4以降の新しい記述形式を採用しているサーバーでは、以下の記法も一般的です。
<Files xmlrpc.php>
Require all denied
</Files>
※注意点：.htaccessの編集ミスはサイト全体の「500 Internal Server Error」を引き起こす可能性があるため、必ず編集前に元のファイルをバックアップしてから作業を行ってください。
手順2: セキュリティプラグインを利用して無効化
ファイル編集の権限がない場合や、コード変更に不安がある場合は、信頼できるセキュリティプラグインを使用する方法が簡単です。プラグインの安全な選定基準についてはWordPressプラグインの選び方とセキュリティリスク回避｜安全な導入基準と保守運用ポイントで詳しく紹介しています。
- SiteGuard WP Plugin：日本の レンタルサーバー環境等でも広く使われているセキュリティプラグイン。「XML-RPC防御」機能が搭載されており、スイッチをONにするだけで「xmlrpc.php」へのアクセスを無効化（またはピンバックのみ無効化）できます。
- Disable XML-RPC：XML-RPC機能全般を停止することに特化した軽量プラグイン。有効化するだけで自動的に機能が停止します。
- iThemes Security / Wordfence Security：総合セキュリティプラグイン内にある「XML-RPCの制限」項目から無効化設定が可能です。
手順3: テーマの functions.php にフィルターフックを記述（ピンバックのみ停止）
Pingback機能によるDDoS攻撃の踏み台化のみを防ぎたい場合は、使用中のテーマ（または子テーマ）の「functions.php」にフィルターフックを追加する方法もあります。
add_filter('xmlrpc_enabled', '__return_false');
ただし、この記述は「XML-RPCによる認証リクエスト等をPHP側で拒否する」設定であり、xmlrpc.php へのHTTPアクセス自体はサーバーに届いてしまうため、Botによる大量アクセス時のサーバー負荷軽減という点では .htaccess による遮断の方が優れています。
XML-RPC無効化後の動作検証とトラブルシューティング
設定完了後は、正常に遮断されているか必ず動作確認を行ってください。
1. ブラウザまたはターミナルからのアクセス確認
ブラウザで自社サイトの「 https://example.com/xmlrpc.php 」に直接アクセスします。
- 無効化成功時：「403 Forbidden（閲覧権限がありません）」エラー画面が表示される。
- 無効化未完了時：「XML-RPC server accepts POST requests only.」といったテキストが表示される。
403エラーが返されていれば、外部からの不正なアクセスは正常に遮断されています。
2. プラグインや連携サービスの動作チェック
無効化設定後、自社サイトの主要機能（問い合わせフォームの送信、SNS自動シェア機能、外部サービス連携など）が正常に動いているかを最終確認します。万が一、利用中の外部ツールでエラーが発生した場合は、対象ツールのIPアドレスのみアクセスを許可する例外規定を .htaccess に記述するか、REST APIベースの代替手段へ切り替える対応を行います。
日常的なWebサイトの保守・点検体制の確立については、ホームページの保守運用とは？重要性・作業内容・費用要因と失敗しない依頼先選びのポイント完全ガイドをご参照ください。
よくある質問
Q1. XML-RPCを無効化すると検索順位（SEO）に悪影響はありますか？
いいえ、SEOに対する悪影響は一切ありません。Googleなどの検索エンジンがサイトのコンテンツを巡回・インデックス登録する処理は、xmlrpc.phpを経由せず通常のHTMLアクセスおよびXMLサイトマップを元に行われます。むしろ、攻撃によるサーバー遅延やダウンを防ぐことで、検索エンジンのクローラーに対して安定した稼働環境を提供できるため、SEO面でもプラスに働きます。
Q2. REST APIとXML-RPCの違いは何ですか？REST APIも停止すべきですか？
XML-RPCは過去のレガシーな通信プロトコルであり、REST APIは現代のWeb標準（JSON形式）に基づいた安全で拡張性の高い通信インタフェースです。REST APIはWordPressの管理画面内部（ブロックエディターの挙動など）や多くの最新プラグインで必須機能として使用されているため、全面停止するとサイトの管理操作に支障が出ます。停止すべきなのは古くリスクの高いXML-RPCであり、REST APIは適切な認証設定を行って維持するのが正しい運用です。</p
Q3. .htaccessでの遮断とプラグインでの遮断、どちらを選ぶべきですか？
サーバー負荷削減の観点からは「.htaccessによる遮断」が最も推奨されます。PHPプログラムを起動させる前にサーバーレベルで拒否するため、Botによる大量アクセスを受けてもサーバーリソースをほとんど消費しません。サーバーの設定ファイルを直接編集できない環境や、安全に一括管理を行いたい場合はセキュリティプラグインを利用すると良いでしょう。</p
Q4. Jetpackプラグインを使っている場合、XML-RPCを停止すると動かなくなりますか？
Jetpackプラグインの一部の旧来機能（WordPress.comサーバーとの自動連携など）は、XML-RPC通信に依存しています。XML-RPCを完全に遮断するとJetpackで連携エラーが発生することがあります。Jetpackの継続利用が必要な場合は、Jetpackサーバーからの特定IPアクセスのみを許可する設定を行うか、SiteGuardなどのプラグインで「ピンバックのみ制限」する柔軟な設定を選択してください。
まとめ：XML-RPCの無効化でWordPressのセキュリティを強固に
WordPressの「xmlrpc.php」は、現代のWebサイト運用においては利用機会が非常に少ないにもかかわらず、サイバー攻撃者にとっては格好の標的となる脆弱性ポイントです。
- 無効化すべき理由：パスワード総当たり攻撃（ブルートフォース）やDDoS攻撃の踏み台化、サーバー高負荷を未然に防ぐため。
- 推奨される対応策：.htaccessによるサーバーレベルでのアクセス遮断（403 Forbidden設定）。
- 運用の注意点：設定後は必ず動作確認を行い、サイトの表示や機能に支障がないかを検証する。
自社のWebサイトを安全に保ち、安定したWeb集客と企業信頼性を維持するために、ぜひ速やかなXML-RPCのセキュリティ確認と適切な無効化対策を実施してください。
CONTACT
Web制作・SEO・AIOについてお気軽にご相談ください
ホームページ制作・リニューアル、WordPress、SEO・AIO対策、 ECサイト、Web集客、保守・セキュリティなど、 Webに関するご相談を承っています。 「何から相談すればよいかわからない」という段階でもお気軽にお問い合わせください。