REST API は何をしているのか
WordPress の REST API は、
「/wp-json/〜」という URL で、サイトのデータにアクセスしたり操作したりできる仕組みです。
記事一覧を JSON で取得したり、
プラグインやテーマが内部的に設定を読み書きしたり、
ブロックエディタ（Gutenberg）が動くために必要な情報を取ってきたり、
かなり広い範囲で使われています。
プログラミングで言えば、
「WordPress というアプリが公開している公式 API 群」が REST API です。
だからこそ便利ですが、その分“どこまで誰に見せるか”を意識しておく必要があります。
なぜ「制限する」という発想が必要なのか
誰でも叩ける「公開 API」になっているから
デフォルトの WordPress では、
ログインしていない人でも、/wp-json/wp/v2/posts のようなエンドポイントにアクセスすると、
公開記事の情報を JSON で取得できます。
公開情報なので「見られて困る」わけではありませんが、
スクレイピングや自動収集にはとても都合が良い入口にもなります。
また、設定やプラグインによっては、
ユーザー情報（ユーザー名一覧など）が REST API 経由で取得できてしまうこともあります。
これは、ログイン攻撃の足がかりになる可能性があります。
「REST API を全部止める」のではなく、
「誰でも叩ける範囲を絞る」「ログインしていない人には見せない情報を決める」
という意味での“制限”が重要になります。
REST API 自体は「必要なことが多い」
ここが XML-RPC と大きく違うポイントです。
XML-RPC は「今はほとんど使わないなら切ってしまっていい」機能でしたが、
REST API は、ブロックエディタや多くのプラグインが依存している“現役の中枢”です。
完全に無効化すると、
ブロックエディタが動かない
一部プラグインがエラーになる
ヘッドレス連携が壊れる
といった問題が出やすくなります。
だからこそ、
「全部 OFF」ではなく「どういう条件でアクセスを許すか」を設計する、
という“制限”の考え方が大事になります。
どんな制限をイメージすればいいのか
典型的な方針：未ログインユーザーへの情報を絞る
一番よくある考え方は、
「ログインしていない人が REST API から取れる情報を減らす」
という方針です。
例えば、次のようなイメージです。
公開記事の一覧・詳細はそのまま（どうせフロントから見える）
ユーザー一覧など、攻撃の足がかりになる情報は非公開
管理系・設定系のエンドポイントは、認証済みユーザーだけ
こうしておけば、
サイトの公開情報を JSON で取られること自体は許容しつつ、
「ログイン攻撃に使われそうな情報」や「内部設定」は守れます。
プログラミングで言えば、
「GET /public/posts は誰でも OK だけど、GET /admin/users は認証必須」
という API 設計に近いです。
もう一歩踏み込む：特定の用途だけ許可する
もしあなたのサイトが、
「REST API を特定の用途でしか使っていない」
（例：フロントの JS から特定のエンドポイントだけ叩く）
という構成なら、
そのエンドポイントだけを許可し、
それ以外は未ログインユーザーからは見せない、
という制限も考えられます。
これは少し上級者向けですが、
「このサイトは REST API をどう使っているか」を把握できてくると、
より細かい制御ができるようになります。
制限するときに絶対に意識すべきポイント
「ブロックエディタが動くかどうか」を必ず確認する
REST API を強く制限しすぎると、
ブロックエディタ（Gutenberg）がエラーを出すことがあります。
ブロックエディタは、
記事の保存・プレビュー・メタ情報の取得などに REST API を使っています。
制限を入れたあとに、
投稿の新規追加・編集が普通にできるか
ブロックの挙動がおかしくなっていないか
プレビューが動くか
を必ず確認してください。
プログラミングで言えば、
「API の認可ルールを変えたら、フロントエンドのテストを必ず回す」
というのと同じです。
プラグインの動作にも影響する可能性
フォーム系、SEO 系、キャッシュ系、セキュリティ系など、
多くのプラグインが REST API を内部的に利用しています。
REST API を制限した結果、
特定のプラグインの設定画面がエラーになる
フロントのウィジェットが動かなくなる
SPA 的な動きが壊れる
といったことも起こり得ます。
だからこそ、
「制限を入れたら、サイト全体をざっと触ってみる」
というチェックが重要です。
これは、コードのリファクタリング後に回帰テストをするのと同じ感覚です。
初心者向けの現実的なアプローチ
まずは「REST API を完全に止めない」を前提にする
いきなり「REST API 無効化！」とやるのは、今の WordPress ではかなり危険です。
初心者向けの現実的な方針は、
REST API 自体は生かしておく
未ログインユーザーへの情報露出を減らす
必要ならセキュリティ系プラグインの機能を使う
という三本立てです。
セキュリティ系プラグインの中には、
「REST API でユーザー一覧を出さない」
「未ログインユーザーからの特定エンドポイントへのアクセスを制限する」
といったオプションを持っているものがあります。
コードを書かずに制限したいなら、
こうしたプラグインの設定を使うのが一番現実的です。
「何を守りたいのか」を先に決める
REST API 制限を考えるとき、
いきなり技術的な話に飛びつくのではなく、
ユーザー名を外から見えにくくしたいのか
内部設定やメタ情報を守りたいのか
スクレイピングを少しでもやりづらくしたいのか
といった「目的」を先に言葉にしておくと、
どこまで制限するかの判断がしやすくなります。
プログラミングでも、
「何を守るか」「何を許すか」を決めてから認可ロジックを書くはずです。
REST API も同じで、目的が決まれば、手段は後からいくらでも選べます。
具体例でイメージする「制限した方がいいサイト」
例1：企業サイト・サービスサイト
運用イメージ：
管理画面から更新
外部アプリ連携はほぼなし
REST API を直接叩くようなカスタム実装もない
この場合、
REST API 自体はそのまま
ユーザー情報などの露出はプラグインや設定で制限
ログイン攻撃対策（WAF・ログイン試行制限など）とセットで考える
という構成が現実的です。
「REST API を全部 OFF」ではなく、
「外から見せたくない情報だけを閉じる」
というバランスを意識すると、壊れにくくて安全な設定になります。
例2：ヘッドレス構成や SPA 的なフロントを持つサイト
運用イメージ：
フロントは別の JS フレームワーク
WordPress はバックエンド API として使っている
この場合、REST API は完全に“心臓部”です。
制限するとしても、
認証付きエンドポイントの保護（トークン・Cookie・CORS など）
IP 制限やレートリミット
不要なエンドポイントの無効化
といった、より API 設計寄りの話になってきます。
ここまで来ると、
「REST API を制限する」は、
もはや“WordPress の設定”というより“アプリケーション設計”の領域です。
まとめ：REST API は「切る」のではなく「設計して絞る」
「REST API を制限する」というテーマの本質は、
自分のサイトがどんな API を公開していて
誰がそれを叩けて
どこまでの情報や操作を許しているのか
を意識することです。
XML-RPC のように「不要なら丸ごと OFF」ではなく、
REST API は「生かしたまま、見せ方と入口を設計する」対象です。
プログラミング的に言えば、
公開 API のスコープと認可ルールをちゃんと決める、という話です。
初心者のうちは、
REST API 自体は無効化しない
未ログインユーザーへの情報露出を減らす
制限を入れたら、ブロックエディタやプラグインの動作を必ず確認する
この三つだけ意識しておけば十分です。
そこから先、
「自分のサイトは REST API をどう使っているのか」を少しずつ理解していけば、
より細かい制限や設計にも自然と手を伸ばせるようになります。
