WordPressのXML-RPCは無効化してよい？Jetpack・アプリ利用時の判断基準

WordPressのXML-RPCは、Jetpackや外部アプリを使っていないサイトなら無効化を検討できます。ただし、攻撃対策だけを理由に確認せず止めると、スマートフォンからの投稿や外部サービスとの連携が突然できなくなることがあります。

結論は「すべてのサイトで即時停止」ではありません。使っている機能を洗い出し、不要なら遮断、必要なら接続元や機能を絞って守るのが安全な判断です。

よこやま良平

20年以上ITエンジニアとしてWordPressの制作・保守・復旧に携わっている、よこやま良平です。XML-RPCは、攻撃対策だけで止めると必要な連携まで壊れるため、利用状況を確認してから判断することが大切です。

XML-RPCは古い仕組みに見えますが、WordPress本体には現在も実装され、投稿・メディア・コメント・ユーザー・Pingbackなど複数の操作を扱えます。入口だけを見て「不要」と決めず、自分のサイトで実際に使われているかを確認しましょう。

この記事では、初心者でも事故を起こしにくい順番で、判断、確認、無効化、動作テスト、切り戻しまで整理します。設定ファイルを触る場合は、必ずファイルとデータベースのバックアップを先に用意してください。

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

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

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

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

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

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

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

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

WordPressのXML-RPCは使っていなければ無効化してよい

WordPressのXML-RPCは、リモート操作を一切使っていないサイトなら無効化して問題ないケースが多いです。一方、Jetpackなどが通信に使っているサイトでは、全停止より利用を継続しながら攻撃を減らす設定が適します。

XML-RPCは外部からWordPressを操作するためのAPI

XML-RPCは、外部のクライアントがHTTP経由でWordPressへ命令を送る仕組みです。通常はサイト直下の「xmlrpc.php」が窓口になり、記事の取得・作成・編集、画像アップロード、コメント操作などを処理します。

WordPress公式の開発者情報では、投稿、タクソノミー、メディア、コメント、オプション、ユーザーなどのメソッドが定義されています。管理画面をブラウザで開かなくても操作できるため、モバイル投稿や外部連携で利用されてきました。

REST APIとは別の通信経路として扱う

XML-RPCとREST APIは、どちらも外部からWordPressを扱うためのAPIですが、通信形式と入口が異なります。XML-RPCを無効化しても、原則として「/wp-json/」から始まるREST APIまで自動的に止まるわけではありません。

まずはXML-RPCとREST APIを別々の経路として把握し、実際の利用機能に合わせて判断するのが正解です。

WordPressのXML-RPCを止める前に確認する機能

WordPressのXML-RPCを止める前に、Jetpack、モバイルアプリ、外部投稿ツール、Pingbackの4系統を確認してください。利用者へ聞かずに遮断すると、普段は見えない自動処理だけが数日後に失敗することがあります。

JetpackはXML-RPCとREST APIの両方を確認する

Jetpack公式の接続トラブル手順では、Jetpackがサイトへ接続するためにxmlrpc.phpを必要とすると案内されています。さらに、JetpackはJSON API（REST API）も利用するため、どちらか一方だけ通れば十分とは限りません。

Jetpackの統計、バックアップ、セキュリティ、WordPress.com連携などを使っているなら、xmlrpc.phpの全遮断は避けるべきです。機能が画面上で有効でも、外部からサイトへ到達できなければ同期や復元点作成が止まる可能性があります。

判断前に「Jetpack→My Jetpack」の接続状態を確認し、Jetpack Debugでもテストします。エラーが出た時は、プラグインの再接続だけでなく、WAF、CDN、サーバー側のアクセス制限、REST API認証も一緒に見てください。

モバイルアプリと外部投稿ツールは実機で確かめる

WordPressのスマートフォンアプリ、デスクトップ投稿ツール、予約投稿サービス、サイト管理サービスには、XML-RPCを使うものとREST APIを使うものがあります。製品名が同じでも、接続方式がバージョンや連携方法で変わることがあります。

そのため「最近のアプリだからXML-RPCは不要」と推測してはいけません。実際に使用中の端末で、投稿一覧の取得、下書き作成、画像アップロード、既存記事の編集をテストし、どの操作が成功したか残します。

Pingback・Trackback・外部監視の必要性を確認する

XML-RPCには、他サイトからリンクされたことを通知するPingback関連メソッドもあります。コメント欄にPingbackを表示しているサイトは、全停止で通知を受け取れなくなる可能性があります。

一方、Pingbackを運用していないサイトでは、攻撃の反射やスパムに悪用される入口を残すメリットは小さくなります。投稿機能は必要だがPingbackは不要という場合、XML-RPC全体ではなくPingbackメソッドだけを外す選択肢があります。

どれにも該当せず、アクセスログにも正規利用が見つからないなら、XML-RPCを無効化する判断がしやすくなります。

WordPressのXML-RPCを無効化すべきケースと残すケース

WordPressのXML-RPCは、必要機能の有無と攻撃状況を組み合わせて判断します。「攻撃があるから必ず全停止」「Jetpackがあるから無制限に開放」という二択にしないことが重要です。

XML-RPCを全体的に無効化しやすいケース

Jetpackを使わず、外部アプリから投稿せず、Pingbackも不要な企業サイトや店舗サイトでは、XML-RPCを全体的に遮断しやすいです。更新作業が管理画面だけで完結するなら、外部操作の入口を減らせます。

XML-RPCを残す、または一部制限にするケース

Jetpackを利用中、外出先からアプリ投稿を行う、複数サイト管理サービスで更新する場合は、全停止を急がないでください。必要な通信まで遮断すると、利便性だけでなくバックアップや監視の信頼性にも影響します。

この場合は、Pingbackだけを無効化する、WAFで異常な回数を制限する、接続元を許可リストへ入れる、強い認証情報を使うなど、機能を保ちながら攻撃面を狭めます。許可リストはJetpackの接続元変更に追従できるかも確認が必要です。

攻撃対策はXML-RPCだけで完結させない

xmlrpc.phpを止めても、wp-login.php、REST API、脆弱なプラグイン、漏えいしたパスワードなど別の入口は残ります。XML-RPC遮断だけでサイト全体が安全になったと考えるのは危険です。

WordPressでブルートフォース攻撃を防ぐ方法｜ログイン試行制限と具体的な設定手順

WordPressセキュリティ対策の完全ガイド｜初心者でも今日からできる安全設定チェックリスト付き

XML-RPCは攻撃経路の一つです。必要性がなければ閉じ、必要なら守り方を追加するという位置づけで扱いましょう。

WordPressのXML-RPC利用状況を安全に確認する手順

WordPressのXML-RPC利用状況は、設定変更より先に「機能一覧、ログ、テスト結果」を残して確認します。先に止めてエラーが出るかを見る方法は、本番の自動処理を壊すためおすすめできません。

手順1：担当者とプラグイン一覧から用途を洗い出す

最初に管理者、編集者、制作会社、保守会社へ、WordPress管理画面以外から接続しているか確認します。スマートフォン投稿、外部エディター、複数サイト管理、バックアップ、監視、SNS自動投稿など、サービス名と操作内容を記録してください。

手順2：アクセスログでxmlrpc.phpの通信を確認する

サーバーのアクセスログで「/xmlrpc.php」を検索し、日時、接続元IP、HTTPメソッド、応答コード、転送量、User-Agentを控えます。正規サービスの接続と攻撃ボットは見た目が似ることがあるため、IPだけで即時遮断しないでください。

手順3：現在の正常状態を変更前にテストする

設定変更前に、普段使う外部機能を一度実行します。Jetpack接続確認、アプリの投稿一覧表示、下書き保存、画像アップロード、外部管理サービスの同期など、成功している状態を基準として保存します。

ブラウザでxmlrpc.phpを開いた結果だけでは不十分です。実際のPOST処理や認証を伴う機能まで確かめないと、変更前から壊れていたのか、変更によって壊れたのか判断できません。

手順4：バックアップと切り戻し方法を準備する

WordPress側のフィルターやプラグイン設定を変える前に、ファイルとデータベースをバックアップします。WAFやサーバー設定を触る場合は、現在のルールをスクリーンショットやエクスポートで残してください。

1. 利用者と外部委託先へ接続方法を確認する
2. プラグインと外部サービスの一覧を作る
3. アクセスログでxmlrpc.phpの通常時を記録する
4. 変更前にJetpack・アプリ・同期を実行する
5. バックアップと切り戻し手順を準備する

この準備ができれば、無効化後の不具合を短時間で発見し、原因をXML-RPC変更へ絞り込めます。

WordPressのXML-RPCを無効化・制限する方法

WordPressのXML-RPCを無効化する方法は、プラグイン、サーバー・WAF、WordPressフィルターの3系統です。どれを選んでも、変更した層と範囲を記録し、同じ目的の設定を重ねすぎないでください。

初心者は管理画面で戻せるプラグイン設定を使う

コード編集に慣れていない場合は、管理画面からXML-RPC遮断を有効・解除できるセキュリティプラグインが扱いやすいです。設定前にJetpackやアプリを使っていないことを確認し、変更直後にテストします。

クイックレスキュー365にはXMLRPC遮断機能があります。スキャン機能ではなく、不要な遠隔操作の入口を閉じるための機能なので、マルウェア検査が必要な場合はWordfenceなど別のスキャン手段を使ってください。

日本製セキュリティ対策で不正アクセスを遮断「クイックレスキュー365」無料ダウンロード

サーバーやWAFでxmlrpc.phpへの到達を止める

Apache、Nginx、CDN、WAFでxmlrpc.phpを遮断すると、WordPressが起動する前に通信を拒否できる場合があります。大量アクセスによるPHP負荷を減らしやすい一方、Jetpackや外部アプリも同じ入口を使うため、全遮断の影響は大きくなります。

WordPressの安全性を高める.htaccess設定12選｜コピー＆ペーストで使える実践例

xmlrpc_enabledフィルターの範囲を理解する

WordPressには「xmlrpc_enabled」フィルターがあります。ただし、公式コードリファレンスでは、このフィルターはXML-RPC全体の入口を消すものではなく、投稿など認証を必要とするメソッドの有効・無効を制御すると説明されています。

add_filter( 'xmlrpc_enabled', '__return_false' );

この1行だけでxmlrpc.phpへのすべてのPOSTやPingbackまで完全に止まる、と説明するのは正確ではありません。目的が「リモート投稿を止める」なのか「大量アクセスをWebサーバーで拒否する」なのかを分けてください。

Pingbackだけを無効化して必要な連携を残す

外部投稿やJetpackのためXML-RPCを残しつつ、Pingbackが不要なら、XML-RPCメソッド一覧からPingback関連だけを外す方法があります。サイトから外部へ送るPingback設定やコメント受付も合わせて見直してください。

add_filter( 'xmlrpc_methods', function ( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

WordPressおすすめセキュリティプラグイン5選【2026年版】導入手順と設定方法まとめ

初心者は、目的と戻し方を説明できる一つの方法だけを選びます。複数層で制限する必要がある場合は、設定一覧を作り、どの層で何を拒否するか整理しましょう。

WordPressのXML-RPC変更後に確認する項目

WordPressのXML-RPCを変更した後は、遮断結果と必要機能の両方を確認します。403や404が返ったことだけで成功とせず、Jetpack、アプリ、管理画面、公開画面、ログを一連でテストしてください。

変更直後に公開画面と管理画面を確認する

トップページ、主要な投稿、問い合わせ、ログイン、投稿編集、画像アップロードを確認します。XML-RPC設定だけを変えたつもりでも、.htaccessやWAFルールの書き方によって別URLまで巻き込むことがあります。

Jetpack・アプリ・外部サービスを再テストする

変更前に実行したのと同じ操作を同じ端末で行います。Jetpack Debug、投稿一覧取得、下書き作成、画像追加、同期完了時刻を比較し、一つでも失敗したら全遮断が適切だったか見直します。

アクセスログとサーバー負荷を変更前後で比べる

xmlrpc.phpへの応答コード、件数、転送量、CPU使用率、PHP同時実行数を変更前後で比べます。全遮断なら403や404になる構成が多いですが、ホスティング会社の仕様で別の応答になることもあります。

重要なのは、不審なPOSTがWordPress処理まで到達しなくなったか、正規機能が残っているかです。ログ件数が同じでも早い段階で拒否できていれば負荷が下がることがあります。

不具合が出たら一度元へ戻して原因を確定する

外部機能が失敗した時は、別の設定を追加して辻褄を合わせる前に、XML-RPC変更を一度戻します。戻すと復旧し、再適用で再発するなら、その制限が原因である可能性が高くなります。

全停止で問題が出た場合は、必要な連携を残した部分制限へ変更します。どのサービスがどの通信を必要とするか分からなければ、ログとエラー時刻を保存してホスティング会社や専門家へ相談してください。

変更後のテストと記録まで終えて、初めてXML-RPC対策は完了です。

WordPressのXML-RPCでよくある質問

WordPressのXML-RPCでは「無効化した方が安全か」「Jetpackが壊れないか」という質問が多くあります。判断に迷いやすい点を簡潔に整理します。

WordPressのXML-RPCは利用確認後に止めるのが正解

WordPressのXML-RPCは、使っていなければ無効化を検討してよい機能です。ただし、Jetpack、モバイルアプリ、外部投稿、複数サイト管理、Pingbackのどれかを使うなら、確認なしの全停止は避けてください。

現場では、設定そのものより「誰が何に使っているか分からない」ことが障害の原因になります。実施時刻、変更箇所、確認結果を記録し、将来の担当者が戻せる状態を残しましょう。

不審な大量アクセス、Jetpack接続障害、WAF設定が重なっている場合は、闇雲にコードを追加せず、アクセスログと利用機能を整理してから対処するのが安全です。

WordPressのセキュリティ設定を安全に見直したい時は

WordPress保守・不正アクセス対策・マルウェア駆除・WordPressクイックレスキュー365

ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。

これらでお悩みなら最短30分ですぐに解決します！

いまなら期間限定で