【完全版】エンジニアのための生成AI・AIエージェント活用ガイド
Ubuntu・Linux完全ガイド｜初期設定からサーバー構築まで
Windowsモダン開発環境構築ロードマップ｜WSL・コンテナ・Cursor
【完全版】Git初心者向けガイド｜基本コマンドから実務トラブル解決まで
個人でできるセキュリティ対策まとめ｜情報漏洩から身を守る完全ガイド
【毎朝7時更新】最新IT・テクノロジーニュース速報＆トレンドまとめ

WordPressのXML-RPC脆弱性対策｜国内IPすり抜けを防ぐ完全遮断手順

WordPressを運用していると、レンタルサーバーのセキュリティ設定を有効にしているから安心と考えてしまいがちです。特にwpX Speedやエックスサーバー系列の環境では、管理パネルに「XML-RPC API アクセス制限」という項目が用意されており、初期状態で有効（ON）になっているケースが多く見られます。

しかし、このサーバー標準機能には見落としがちな盲点が存在します。標準設定で制限されるのは国外IPアドレスからのアクセスのみであり、日本国内のIPアドレスや国内プロキシを経由したアクセスはそのまま通過してしまいます。

現代のWordPressでは、記事の投稿や外部システムとの連携においてREST APIが主流となっており、旧来のXML-RPC（xmlrpc.php）を必要とする場面はほとんどありません。不要なプロトコルを開放したまま放置することは、パスワード総当たり攻撃（ブルートフォース攻撃）やDDoS攻撃の踏み台にされる重大なセキュリティリスクを招きます。

この記事では、wpX SpeedをはじめとするWordPress環境において、国内IPからの攻撃も含めてXML-RPCを完全に遮断する手順を解説します。ファイル直接編集で細かく制御できる .htaccess による設定方法と、管理画面のスイッチ操作だけで安全に設定できるセキュリティプラグイン（SiteGuard WP Plugin等）を使った方法の2種類を比較しながら紹介します。あわせて、管理者のログインIDが外部から丸見えになってしまうREST APIのユーザー名露出対策についても取り上げます。

  1. この記事で行うこと
  2. 前提条件・検証環境
  3. 注意点
  4. 1. WordPressのXML-RPC（xmlrpc.php）とは？残されたセキュリティリスク
    1. 1-1. ブルートフォース攻撃とPingbackによるDDoS踏み台
      1. system.multicallを悪用した高速パスワード総当たり
      2. Pingback（ピンバック）機能を悪用したDDoS攻撃の踏み台
    2. 1-2. 現代のWordPressでXML-RPCは原則不要な理由
  5. 2. wpX Speed標準設定の落とし穴｜国内IP制限の盲点
    1. 2-1. 国外IP遮断だけでは防げない理由
    2. 2-2. 自サイトの露出状況を確認する方法（ブラウザ・curl）
      1. 方法1：Webブラウザで直接URLを開いて確認する（最も手軽）
      2. ブラウザ画面での判定基準
      3. XML-RPC server accepts POST requests only. と表示される場合
      4. 403 Forbidden または アクセス拒否画面 が表示される場合
      5. 方法2：ターミナルからcurlコマンドで確認する
      6. 応答ステータスの判定基準
      7. HTTP 403 Forbidden または HTTP 404 Not Found が返る場合
      8. HTTP 200 OK とともに XML（methodResponse）が返る場合
  6. 3. XML-RPC対策手順の比較｜.htaccess手動編集 vs プラグイン導入
  7. 4. 【推奨】.htaccessによるXML-RPC完全遮断手順
    1. 4-1. 完全遮断の記述コード
    2. 4-2. 【超重要】# BEGIN WordPress より前にまとめて配置する理由
      1. 正しい配置例
  8. 5. 【ノーコード】プラグインでXML-RPCを安全に無効化する手順
    1. 5-1. SiteGuard WP Plugin による設定手順
      1. 手順1：プラグインのインストールと有効化
      2. 手順2：XML-RPC防御メニューの選択
      3. 手順3：防御タイプの変更と保存
    2. 5-2. 単機能プラグイン（Disable XML-RPC-API）による最小構成
  9. 6. あわせて防ぎたいREST API経由のユーザー名露出対策
    1. 6-1. /wp-json/wp/v2/users からログインIDが抜かれるリスク
    2. 6-2. .htaccessによるユーザー列挙の遮断記述
      1. ルールの解説
  10. 7. 設定後の動作検証と外部連携への影響確認
    1. 7-1. 設定反映の動作検証手順（ブラウザ・curl）
      1. 方法1：Webブラウザのアドレスバーから確認する（最も手軽）
      2. XML-RPC の遮断確認
      3. REST API ユーザー一覧の遮断確認
      4. サイト全体の通常表示確認
      5. 方法2：ターミナルからcurlコマンドで厳密に点検する
    2. 7-2. 外部連携やAI自動投稿ツールへの影響有無
      1. WordPress管理画面への影響
      2. REST APIを利用した外部システム・AIツールへの影響
      3. スマホアプリからの更新
  11. 8. まとめ｜不要なAPIは完全遮断して安全なWordPress運用を
  12. 次に読むおすすめ記事
  13. 参考情報

この記事で行うこと

  • WordPressのXML-RPC（xmlrpc.php）が抱えるセキュリティリスクと、現代のWordPressで原則不要である理由を整理します。
  • wpX Speed等のサーバー標準設定における国内IPすり抜けの仕組みと、ブラウザや curl コマンドで自サイトの露出状況を診断する手順を把握します。
  • Webサーバー負荷を抑えられる .htaccess による完全遮断手順と、記述位置（# BEGIN WordPress より前）の重要な注意点を理解します。
  • ファイル編集が不安な方向けに、プラグイン（SiteGuard WP Plugin / Disable XML-RPC-API）を使った安全な無効化手順を確認します。
  • REST APIのユーザー名一覧（/wp-json/wp/v2/users）を遮断し、ログインIDの推測を防ぐ設定を追加します。
  • 設定変更後にブラウザでアクセスして403 Forbidden画面が出るか検証し、管理画面や通常のREST API連携に悪影響がないことを確かめます。

前提条件・検証環境

  • WordPress 6.0以上（最新バージョン環境を推奨）
  • サーバー環境：wpX Speed（Apache構成の一般的なレンタルサーバー全般に適用可能）
  • .htaccess の編集権限（FTPクライアント、SSH、またはサーバー管理パネルのファイルマネージャー）
  • 管理者権限を持つWordPressアカウント
  • 動作確認用のWebブラウザ、またはターミナル環境（Windows PowerShell / macOS・Linux ターミナル）

注意点

  • Jetpackプラグイン（Jetpack by WordPress.com）の連携機能や、スマートフォン向けWordPress公式アプリで旧来のXML-RPC通信を必要としている場合、本設定を適用するとリモート接続ができなくなります。
  • .htaccess はWebサーバーの動作を制御する最重要設定ファイルです。構文ミスや記述順序の誤りがあるとサイト全体が500 Internal Server Errorで停止する恐れがあるため、編集前には必ずファイルのバックアップをローカルに保存してください。
  • サーバー環境によっては、独自のセキュリティモジュールや上位のリバースプロキシによって .htaccess の一部ディレクティブの挙動が異なる場合があります。設定変更後は必ずブラウザや curl コマンドで実際の表示・応答ステータスを確認してください。

1. WordPressのXML-RPC（xmlrpc.php）とは？残されたセキュリティリスク

XML-RPCは、外部のアプリケーションやリモート環境からWordPressを遠隔操作するために設計された古い通信仕様です。WordPress 3.5以降では初期状態で有効化されており、WordPressが設置されたディレクトリのルートにある xmlrpc.php というファイルがリクエストを受け付けます。

1-1. ブルートフォース攻撃とPingbackによるDDoS踏み台

XML-RPCが現在でも世界中の攻撃者から集中的に狙われ続けている背景には、プロトコルの仕様上の特徴が悪用されやすいためです。

system.multicallを悪用した高速パスワード総当たり

通常のログイン画面（wp-login.php）に対する攻撃の場合、1回のリクエストで試行できるユーザー名とパスワードの組み合わせは1組だけです。そのため、サーバーやプラグインのログイン試行回数制限によって比較的検知・ブロックしやすい特徴があります。

一方、XML-RPCには複数のAPIメソッドを一度にまとめて実行できる system.multicall という機能が備わっています。攻撃者は1つのHTTP POSTリクエストの中に数百から数千通りのパスワード候補を詰め込み、一括で認証試行を実行できます。これにより、サーバー側のレート制限やログ検知をすり抜けながら、極めて高速に管理画面の乗っ取りを試みられます。

Pingback（ピンバック）機能を悪用したDDoS攻撃の踏み台

WordPressのPingbackは、他のブログから記事へのリンクが貼られた際に自動で通知を送信・受信する仕組みです。この通信処理もXML-RPCを介して行われます。

攻撃者が細工したリクエストを大量のWordPressサイトへ送信すると、それらのサイトが一斉に標的サーバーへ確認アクセス（Pingback）を試みる現象が発生します。結果として、自分の管理するWordPressサイトが知らぬ間に第三者への分散型サービス妨害攻撃（DDoS攻撃）の加担者（踏み台）に仕立て上げられ、自サイトのサーバーリソースも枯渇して高負荷障害を引き起こします。

1-2. 現代のWordPressでXML-RPCは原則不要な理由

かつてXML-RPCは、スマートフォンアプリからの記事投稿や、Windows Live Writerなどの外部ブログエディタからの投稿に不可欠でした。

しかし、WordPress 4.7でWordPress REST APIがコア機能として本格統合され、WordPress 5.0以降でブロックエディタ（Gutenberg）の標準通信基盤となって以来、公式スマートフォンアプリや主要な外部連携ツールはJSON形式で高速かつ安全に通信できるREST APIへと移行しました。

現在、XML-RPCを必須としている代表例はJetpackの一部の旧機能などに限られています。一般的な個人ブログ、コーポレートサイト、オウンドメディアにおいて、XML-RPCを開放しておく積極的な理由は存在せず、攻撃の入り口として放置するリスクだけが残されています。

2. wpX Speed標準設定の落とし穴｜国内IP制限の盲点

レンタルサーバー各社は、XML-RPCに対する攻撃被害を軽減するため、管理画面にセキュリティ設定を用意しています。代表的な例として、wpX Speedの管理パネルに用意されている設定項目を見てみましょう。

2-1. 国外IP遮断だけでは防げない理由

wpX Speedの管理パネル（「WordPress設定」＞「セキュリティ設定」）にある「WordPressセキュリティ関連設定」の中には、「XML-RPC API アクセス制限」という設定が存在します。この項目は初期状態で「ON」になっており、海外からの不正アクセスを大幅に削減できるためそのままの運用が推奨されています。

しかし、公式マニュアルに明記されている通り、この機能の動作仕様は「XML-RPC WordPress API（/xmlrpc.php）に対する国外からの接続を制限する」というものです。

攻撃者は海外から直接攻撃を仕掛けるだけでなく、日本国内に存在する脆弱なIoT機器、国内のクラウド・VPS上の踏み台サーバー、または国内プロキシを経由して攻撃パケットを中継させます。アクセス元のIPアドレスが日本国内と判定される場合、サーバー側の国外アクセス制限は一切反応せず、リクエストは素通りして xmlrpc.php に到達してしまいます。

2-2. 自サイトの露出状況を確認する方法（ブラウザ・curl）

自サイトのXML-RPCが国内からのリクエストを受け付ける状態になっているかどうかは、Webブラウザで直接URLを開くか、ターミナルから curl コマンドを実行して簡単に診断できます。

方法1：Webブラウザで直接URLを開いて確認する（最も手軽）

Google ChromeやMicrosoft Edgeなどのブラウザを開き、アドレスバーにご自身のWordPressサイトのURL末尾に /xmlrpc.php を付けたアドレスを直接入力してアクセスします。

https://example.com/xmlrpc.php

ブラウザ画面での判定基準

XML-RPC server accepts POST requests only. と表示される場合

XML-RPCエンドポイントが外部に露出しています。ブラウザからの通常アクセス（GETリクエスト）に対して xmlrpc.php のプログラム自体が直接応答（HTTP 405 Method Not Allowed）しており、攻撃者がPOSTリクエストでXMLデータを送信すれば、そのまま認証試行やPingback処理を受け付けてしまう無防備な状態です。早急な遮断対策が必要です。

403 Forbidden または アクセス拒否画面 が表示される場合

Webサーバーやセキュリティプラグインによってアクセスが正常に遮断されています。xmlrpc.php のプログラムが実行される前に接続が拒否されており、安全な状態です。

方法2：ターミナルからcurlコマンドで確認する

実際の攻撃と同じPOSTリクエストを送ってHTTPステータスコードを正確に点検したい場合は、PowerShellやターミナルから以下のコマンドを実行します。URL部分はご自身のサイトドメインに置き換えてください。

curl.exe -i -X POST -d "<methodCall><methodName>demo.sayHello</methodName></methodCall>" "https://snowsystem.net/xmlrpc.php"

応答ステータスの判定基準

HTTP 403 Forbidden または HTTP 404 Not Found が返る場合

Webサーバーまたはプラグインによってアクセスが正常に遮断されています。第三者からのPOSTリクエストは拒否されており安全です。

HTTP 200 OK とともに XML（methodResponse）が返る場合

XML-RPCが完全に有効で、外部からのコマンド実行を受け付けています。国内回線からのブルートフォース攻撃に対して無防備なため、直ちに対策を実施してください。

3. XML-RPC対策手順の比較｜.htaccess手動編集 vs プラグイン導入

WordPressで国内IPも含めてXML-RPCを無効化・遮断するには、大きく分けて .htaccess を直接編集する方法と、セキュリティプラグイン（SiteGuard WP Plugin または単機能プラグイン）を導入する方法があります。それぞれの特徴を比較して、ご自身の運用スタイルに合う手法を選択してください。

比較項目.htaccess の直接編集（推奨）SiteGuard WP Plugin単機能プラグイン（Disable XML-RPC-API等）
遮断の仕組みWebサーバー（Apache）で即時403拒否管理画面操作で .htaccess へ遮断ルールを自動追記PHP（WordPressフック等）で無効化
サーバー負荷ゼロ（PHPを起動せず遮断）ゼロ（.htaccess への自動記述によりWebサーバーで遮断）わずかに発生（PHP起動後に処理停止）
設定の手軽さファイルの直接編集が必要（中級者向け）管理画面のスイッチ操作のみ（初心者向け）インストールして有効化するだけ（初心者向け）
記述ミスのリスク手動編集時の構文誤りで500エラーの恐れ自動書き込みのため手動編集ミスを回避可能ファイル書き換えを伴わない場合はリスク極小
推奨対象余計なプラグインを増やさず高速・堅牢に管理したい方管理画面の日本語UIで安全に総合防御したい方他のセキュリティプラグインと併用して機能だけ止めたい方

4. 【推奨】.htaccessによるXML-RPC完全遮断手順

余計なプラグインを増やさず、Webサーバー（Apache）の入り口で確実に通信を遮断したい場合は、.htaccess に直接アクセス拒否ルールを記述するのが最もスマートです。PHPの処理エンジンが呼び出される手前でWebサーバーが403 Forbiddenを返すため、大量の攻撃リクエストが届いてもサーバーのCPUやメモリを消費しません。

4-1. 完全遮断の記述コード

FTPクライアントやサーバーパネルのファイルマネージャーを使用して、WordPressのルートディレクトリにある .htaccess を開きます。

既存のコードを書き換える前に、必ずファイル全体のコピーをローカル環境へバックアップしてください。バックアップ完了後、以下のコードを追加します。

# XML-RPC の完全遮断（国内・国外問わず全アクセス拒否）
<Files xmlrpc.php>
Order deny,allow
Deny from all
</Files>

なお、Apache 2.4以降の新しいアクセス制御構文を使用する場合は、以下の記述でも同様に動作します。一般的な国内レンタルサーバー（wpX Speedやエックスサーバー等）では互換モジュールが有効なため、上記または以下のいずれでも遮断が可能です。

# Apache 2.4 構文による遮断
<Files xmlrpc.php>
Require all denied
</Files>

4-2. 【超重要】# BEGIN WordPress より前にまとめて配置する理由

.htaccess にセキュリティ設定を追加する際、最も注意すべきポイントが「記述する位置」です。

WordPressをインストールすると、.htaccess にはパーマリンク設定を処理するための標準ルール（# BEGIN WordPress 〜 # END WordPress）が自動生成されています。

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

この標準ルール内にある RewriteCond %{REQUEST_FILENAME} !-f は「実在するファイルへのアクセスは書き換えない」という条件であり、末尾の RewriteRule . /index.php [L] は「実在しない仮想URLへのアクセスをすべて index.php へ引き渡し、そこでルール評価を終了（[L] = Last）する」という動作を行います。

実在ファイルである xmlrpc.php に対する <Files xmlrpc.php> 単体であれば下部に書いても動作するケースはありますが、後述するREST API（/wp-json/wp/v2/users のような実在ファイルではない仮想URL）の遮断ルールを # END WordPress より後ろに書いてしまうと、先に RewriteRule . /index.php [L] にキャッチされてWordPress側へ処理が流れてしまい、遮断ルールが完全に無視されるトラブルが発生します。

また、キャッシュ系プラグインやWAF設定が追加するルールとの干渉を防ぐためにも、独自のセキュリティ遮断ルールは必ず .htaccess の最上部（# BEGIN WordPress よりも前の行）にまとめて配置するのが鉄則です。

正しい配置例

# 1. XML-RPC の完全遮断（ファイル先頭に配置）
<Files xmlrpc.php>
Order deny,allow
Deny from all
</Files>

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
...

5. 【ノーコード】プラグインでXML-RPCを安全に無効化する手順

FTPの利用経験がない方や、.htaccess の手動編集による構文ミス（500エラー）のリスクを避けたい場合は、WordPressのセキュリティプラグインを利用するのが安全です。

5-1. SiteGuard WP Plugin による設定手順

SiteGuard WP Pluginは、国内のセキュリティ専門企業であるEGセキュアソリューションズが開発・提供している定番のセキュリティプラグインです。日本語UIに完全対応しており、管理画面から設定を保存すると、プラグインが .htaccess へ #==== SITEGUARD_DISABLE_XMLRPC_SETTINGS_START というマーカー付きの遮断ルールを安全に自動挿入してくれます。

手順1：プラグインのインストールと有効化

WordPress管理画面の「プラグイン」＞「新規追加」を開き、検索窓に「SiteGuard WP Plugin」と入力してインストールおよび有効化を行います。

手順2：XML-RPC防御メニューの選択

管理画面の左側メニューに追加された「SiteGuard」をクリックし、サブメニューまたは機能一覧から「XML-RPC防御」を選択します。

手順3：防御タイプの変更と保存

XML-RPC防御の設定画面を開くと、初期状態ではスイッチが「ON」で、タイプは「ピンバック無効化」が選択されています。 ブルートフォース攻撃も含めて完全に遮断するため、タイプを「XMLRPC無効化（またはXMLRPC防御）」に切り替え、画面下部の「変更を保存」ボタンをクリックしてください。

これで .htaccess へのアクセス拒否設定が自動反映され、xmlrpc.php への通信がWebサーバーレベルで遮断されます。

5-2. 単機能プラグイン（Disable XML-RPC-API）による最小構成

ログイン画面のURL変更など他の機能を含む統合型プラグインではなく、XML-RPCの停止機能だけをシンプルに追加したい場合は、単機能プラグインの導入が適しています。

「Disable XML-RPC-API」などの専用プラグインは、管理画面からインストールして有効化するだけで、バックグラウンドでXML-RPC機能を無効化します。他のセキュリティプラグインと機能が重複・干渉するのを避けたい場合に有効な選択肢です。

6. あわせて防ぎたいREST API経由のユーザー名露出対策

XML-RPCの遮断とセットで必ず実施しておきたいのが、WordPress REST APIによる管理者ユーザー名の外部露出対策です。

6-1. /wp-json/wp/v2/users からログインIDが抜かれるリスク

wpX Speedの「WordPressセキュリティ関連設定」には「REST API アクセス制限」という項目もありますが、こちらもXML-RPCと同様に「国外からの接続を制限する」仕様となっています。そのため、日本国内のIPアドレスからはREST APIへ自由にアクセスが可能です。

初期状態のWordPressでは、ブラウザやコマンドから以下のURLにアクセスすると、記事を投稿した管理者のログインID（ユーザー名 / slug）が誰でも閲覧可能なJSON形式で返却されてしまいます。

https://example.com/wp-json/wp/v2/users

攻撃者にとって、ログイン認証を突破するためのハードルは「ユーザー名」と「パスワード」の両方を特定することです。このURLから正確なユーザー名が特定されてしまうと、攻撃者はパスワードの総当たり作業だけに専念できるようになり、不正ログインのリスクが高まります。

6-2. .htaccessによるユーザー列挙の遮断記述

WordPressのブロックエディタや外部連携で使う正規のREST API通信（/wp-json/wp/v2/posts や /wp-json/wp/v2/media）を維持したまま、ユーザー名一覧のエンドポイント（/wp-json/wp/v2/users）だけをピンポイントで遮断するには、.htaccess に以下の書き換えルールを追加します。

第4章で解説した通り、/wp-json/wp/v2/users は実在するファイルではなく仮想URLであるため、このルールは必ず # BEGIN WordPress よりも前（先頭）に配置してください。後ろに書くとWordPress標準の [L] フラグによって無視されてしまいます。

# 1. XML-RPC の完全遮断
<Files xmlrpc.php>
Order deny,allow
Deny from all
</Files>

# 2. REST API ユーザー名一覧（/wp-json/wp/v2/users）の外部露出遮断
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/wp-json/wp/v2/users [NC]
RewriteRule .* - [F,L]
</IfModule>

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
...

ルールの解説

  • RewriteCond %{REQUEST_URI} ^/wp-json/wp/v2/users [NC]: リクエストされたURLパスが /wp-json/wp/v2/users で始まる通信（個別ID指定の /wp-json/wp/v2/users/1 等も含む）を検知します（[NC] は大文字・小文字を区別しない指定）。
  • RewriteRule .* - [F,L]: 条件に合致したアクセスに対して即座に HTTP 403 Forbidden（アクセス拒否） を返し（[F]）、後続のルール評価を停止します（[L]）。

7. 設定後の動作検証と外部連携への影響確認

設定が完了したら、意図した通りに遮断が行われているか、また他の正常な機能に支障が出ていないかを実機で検証します。

7-1. 設定反映の動作検証手順（ブラウザ・curl）

確認作業は、日常使っているWebブラウザのアドレスバーから確認する方法と、ターミナルの curl コマンドで確認する方法の2通りがあります。

方法1：Webブラウザのアドレスバーから確認する（最も手軽）

特別なツールを使わなくても、ブラウザのアドレスバーに直接URLを入力することで、遮断が成功しているかを数秒で確認できます。

XML-RPC の遮断確認

ブラウザのアドレスバーに以下のURLを入力して開きます（ドメイン部分はご自身のサイトURLに置き換えてください）。

https://example.com/xmlrpc.php

画面に「403 Forbidden」や「指定されたページへのアクセス権がありません」といったアクセス拒否エラーが表示されれば、完全遮断に成功しています。もし「XML-RPC server accepts POST requests only.」のテキストが表示される場合は、まだ遮断が効いていません。.htaccess の保存状態やプラグインの設定を再確認してください。

REST API ユーザー一覧の遮断確認

続いて、ブラウザで以下のURLを開きます。

https://example.com/wp-json/wp/v2/users

こちらも同様に「403 Forbidden」のエラー画面が表示されれば成功です。もし管理者や投稿者のユーザー名（slug）が含まれるJSONデータが表示されてしまう場合は、.htaccess 内で追記したルールが # BEGIN WordPress よりも前（先頭）に配置されているか見直してください。

サイト全体の通常表示確認

自サイトのトップページや公開済みの個別記事ページを開き、500エラーや画面崩れが発生せず、通常通り閲覧できることを確認します。

方法2：ターミナルからcurlコマンドで厳密に点検する

HTTPステータスコードをヘッダー情報から厳密に確認したい場合は、ターミナルから curl コマンドを実行して各エンドポイントの応答を点検します。

# 1. XML-RPC の遮断確認（403 Forbidden が返れば成功）
curl.exe -I -X POST "https://snowsystem.net/xmlrpc.php"

# 2. REST API ユーザー一覧の遮断確認（403 Forbidden が返れば成功）
curl.exe -I "https://snowsystem.net/wp-json/wp/v2/users"

# 3. REST API 投稿一覧の正常性確認（200 OK が返れば成功）
curl.exe -I "https://snowsystem.net/wp-json/wp/v2/posts"

すべてのコマンドを実行し、xmlrpc.php と users のみが403でブロックされ、通常の記事取得エンドポイント（posts）やサイトのトップページが200 OKで問題なく応答していることを確認してください。

7-2. 外部連携やAI自動投稿ツールへの影響有無

今回の設定によって、他のシステムや日常の更新作業にどのような影響が出るか不安に感じる方も多いはずです。影響範囲のポイントは以下の通りです。

WordPress管理画面への影響

Webブラウザから利用する通常の管理画面（/wp-admin/）やブロックエディタ（Gutenberg）の動作には一切悪影響はありません。記事の作成、編集、下書き保存、公開操作はすべて通常通り行えます。

REST APIを利用した外部システム・AIツールへの影響

Pythonスクリプトや外部WebサービスからREST API経由で記事を投稿・更新している場合、使用されるエンドポイントは /wp-json/wp/v2/posts や /wp-json/wp/v2/media、/wp-json/wp/v2/pages です。今回遮断したのは旧来の xmlrpc.php とユーザー一覧API（users）のみであるため、自動投稿プログラムやAIアシスタントによる記事更新処理は一切影響を受けず、安全に稼働し続けます。

スマホアプリからの更新

WordPress公式スマートフォンアプリを利用しており、アプリ側の通信が旧来のXML-RPCに依存している場合は接続エラーとなることがあります。その場合はモバイルブラウザから管理画面へアクセスして更新するか、用途に応じて設定を調整してください。

8. まとめ｜不要なAPIは完全遮断して安全なWordPress運用を

レンタルサーバーが提供するセキュリティ機能は非常に心強いものですが、「国外IP制限」のように日本国内の踏み台経由のアクセスを想定していない設定も一部に存在します。

現代のWordPress運用において、不要となったXML-RPC（xmlrpc.php）を開放し続けるメリットはありません。ファイルを直接管理できる場合は .htaccess の先頭にアクセス拒否コードを記述し、ノーコードで安全に設定したい場合は SiteGuard WP Plugin などの信頼できるセキュリティプラグインを活用して、確実に遮断しておきましょう。

あわせて、管理者のログインIDを露出させる /wp-json/wp/v2/users へのアクセス遮断も同時に講じておくことで、パスワード総当たり攻撃のリスクを最小限に抑え、堅牢で安全なWordPressサイトを維持できます。

次に読むおすすめ記事

WordPressをはじめとするWebサーバーやクラウド環境全体の不正アクセス点検、セキュリティ対策のチェックリストについては、以下の解説記事もあわせて参考にしてください。

参考情報