WordPress REST API無効化でもブロックエディタは動いた｜SiteGuard有効のまま実測

サーバー・WordPress実務
2026.08.16

著者: 佐藤優太（Web制作事業 MOVON 代表） ｜ 公開日: 2026-08-16 ｜ 最終更新日: 2026-08-16
この記事は筆者が実際に契約・操作して計測した結果に基づいています。計測条件・計測日・証跡は本文中に明記しています。
本サイトの編集方針: 運営者情報

結論（先に答え）

  • 「REST APIを無効化した」状態でも、ブロックエディタは普通に起動しました。新規投稿画面が開き、日本語を入力でき、下書きの保存まで通りました【実測: n=1, 2026-08-16, Classic Editorを無効化した直後の新規投稿画面での操作】
  • 理由は単純で、この環境の「REST API無効化」は匿名アクセスだけを止める実装だったからです。ログインしていない状態では8エンドポイントすべてが 401 を返し、レスポンスの code は rest_disabled でした【実測: n=1, 2026-08-16, Cookieを送らないcurlでの取得】
  • 同じ設定のまま、管理者としてログインしたセッションで叩くと10エンドポイントすべてが200でした。ブロックエディタが依存する wp/v2/block-types も200です【実測: n=1, 2026-08-16, 管理者セッションのCookieとX-WP-Nonceを付けたGET】
  • つまり「REST APIを無効化するとブロックエディタが使えなくなる」という説明は、少なくともこの構成では成り立ちません。同じ言葉でも、誰に対して閉じているのかで意味がまったく変わります【実測: n=1, 2026-08-16, 匿名側と認証済み側の同一エンドポイント比較】
  • ただし速さははっきり違いました。投稿画面が入力できる状態になるまで、ビジュアルエディタ同士で比べると Classic Editor が平均 1884ミリ秒（1653／2000／2000）、ブロックエディタが平均 3134ミリ秒（3542／2858／3001）で、約1.66倍の差でした【実測: n=3, 2026-08-16, 同一手順・同一判定でのブラウザ内計測】
  • Classic Editor のテキスト入力欄だけなら平均 1061ミリ秒（1124／1014／1046）で使える状態になりました【実測: n=3, 2026-08-16, 同上】
  • エディタを切り替えても、読者が見る公開ページのHTMLは1バイトも変わりませんでした。固定ページ3本を前後で取得して比較した差分は 0行、サイズも 203405／207183／207516バイトで完全一致です【実測: n=3, 2026-08-16, キャッシュバスター付きURLでの匿名HTTP取得とdiff比較】

「REST APIを無効化するとブロックエディタが使えない」と言われる理由

WordPressのセキュリティ設定を調べていると、この組み合わせの説明に何度もぶつかります。

REST APIを無効化するとブロックエディタが使えなくなるので、Classic Editorを入れましょう。

自分のサイトでも、実際にこの順番で作業しました。先に Classic Editor を入れて、そのあと SiteGuard WP Plugin の「ユーザー名漏えい防御」とそのオプションである「REST API 無効化」をONにしています。そのときは、この説明を信じて順番を決めていました。

ところが、その後に別の作業をしていて妙なことに気づきます。REST APIを「無効化」したはずのサイトに、自分は REST API 経由で記事を投入できていたのです。

無効化したはずのものが動いている。これはどちらかが間違っています。

  • 設定が効いていない（＝ユーザー名漏えい対策が機能していないという、笑えない話）
  • それとも「無効化」の意味を自分が読み違えている

前者だったらセキュリティの問題なので、確かめないわけにいきません。そして確かめた結果は後者でした。

しかも同時に、「Classic Editorを入れる理由」として広く語られている因果そのものが、この環境では成立していないことがわかりました。この記事はその記録です。

REST APIを無効化した環境をどう作って測ったか

  • 対象: 自分のサイト（WordPress 7.0.4・Cocoonテーマ）1環境のみ
  • 使ったプラグイン: Classic Editor 1.7.0（WordPress公式・無料）、SiteGuard WP Plugin 1.8.8（無料）
  • 測定中に変えたのは Classic Editor の有効／無効だけ。SiteGuard の「REST API 無効化」は最初から最後までONのまま
  • 測定回数: RESTのステータスコードとブロックエディタの起動可否は n=1（成否が構造的に決まるため）。所要時間は n=3。公開ページの差分は固定ページ3本を各1回で n=3
  • 測定環境: macOS 26.6.0／Google Chrome（管理者としてログイン済みのセッション）／匿名側は curl（Cookieなし）／家庭用光回線／同時実行タスクなし
  • 計測日時: 2026-08-16。認証済みセッションでのREST取得のみ15:39〜15:40、それ以外（匿名RESTの再取得・ブロックエディタの起動確認・所要時間・HTML差分）は17:49〜17:55（いずれもJST）

所要時間の測り方は途中で変えました。 最初は「画面を開いてから手元で計る」方式で試したのですが、操作の往復にかかる時間（約9秒）が数値を飲み込んでしまい、エディタの差がまったく見えませんでした【実測: n=1, 2026-08-16, 最初に試した方式での計測値】。そこで、同じページの中に投稿画面を読み込ませて、本文を入力できる要素が現れた時刻をブラウザ自身に測らせる方式に変えています。判定条件は次のとおりで、Classic Editor 側もブロックエディタ側もまったく同じ手順で測りました。

条件 「入力できる状態」の判定
Classic Editor（テキスト欄） 本文のテキスト入力欄が存在し、入力が禁止されていないこと
Classic Editor（ビジュアル） ビジュアルエディタの初期化が完了し、編集領域が編集可能になっていること
ブロックエディタ 本文の段落ブロックが編集可能な要素として存在すること

ブラウザのキャッシュは消していません。 どちらの条件も「同じ画面を何度か開いたあと」の状態で比べています。はじめて開いたときの数値ではない、という点は先に書いておきます。

実測結果1：SiteGuardのREST API無効化は、誰に対して閉じているのか

まず、ログインしていない状態（読者や、外から探しに来る自動化ツールと同じ立場）で叩いた結果です。

エンドポイント 匿名アクセスの結果 出典
/wp-json/ 401 【実測: n=1, 2026-08-16, Cookieを送らないcurl】
/wp-json/wp/v2/posts 401 【実測: n=1, 2026-08-16, 同上】
/wp-json/wp/v2/users 401 【実測: n=1, 2026-08-16, 同上】
/wp-json/wp/v2/types 401 【実測: n=1, 2026-08-16, 同上】
/wp-json/wp/v2/pages 401 【実測: n=1, 2026-08-16, 同上】
/wp-json/wp/v2/block-types 401 【実測: n=1, 2026-08-16, 同上】
/?rest_route=/wp/v2/posts 401 【実測: n=1, 2026-08-16, 同上】
/?rest_route=/wp/v2/users 401 【実測: n=1, 2026-08-16, 同上】

8つとも401で、返ってきたJSONの code は rest_disabled でした【実測: n=1, 2026-08-16, 匿名HTTPのレスポンス本文】。ここで大事なのは最後の2行です。/wp-json/ を塞いだだけでは、パーマリンクに依存しない /?rest_route= という別経路が残ります。その経路も401でした。

次に、設定は一切変えないまま、管理者としてログイン済みのセッションで同じ場所を叩きます。

エンドポイント 認証済みアクセスの結果 出典
/wp-json/ 200 【実測: n=1, 2026-08-16, 管理者Cookie＋X-WP-Nonce付きGET】
/wp-json/wp/v2/posts 200 【実測: n=1, 2026-08-16, 同上】
/wp-json/wp/v2/posts?context=edit 200 【実測: n=1, 2026-08-16, 同上】
/wp-json/wp/v2/pages 200 【実測: n=1, 2026-08-16, 同上】
/wp-json/wp/v2/users 200 【実測: n=1, 2026-08-16, 同上】
/wp-json/wp/v2/types 200 【実測: n=1, 2026-08-16, 同上】
/wp-json/wp/v2/types?context=edit 200 【実測: n=1, 2026-08-16, 同上】
/wp-json/wp/v2/settings 200 【実測: n=1, 2026-08-16, 同上】
/wp-json/wp/v2/block-types 200 【実測: n=1, 2026-08-16, 同上】
/wp-json/wp/v2/plugins 200 【実測: n=1, 2026-08-16, 同上】

同じURL、同じ設定、違うのはログインしているかどうかだけ。それで401と200に分かれます。

とくに wp/v2/block-types が200を返しているのが今回の要点です。これはブロックエディタが起動時に必要とするエンドポイントで、ここが閉じていればブロックエディタは立ち上がりません。閉じていませんでした。

「REST APIを無効化する」という言葉は、実装によって指すものが違います。 この環境では「匿名アクセスに対して閉じる」であって、「WordPress内部のREST通信ごと止める」ではありませんでした。

実測結果2：REST APIを無効化してもブロックエディタは動くのか

ステータスコードが200でも、それは「エディタが動く」証明にはなりません。ここは実際にやってみる必要があります。

Classic Editor を一時的に無効化して、新規投稿画面を開きました。

  • ブロックエディタは起動しました。エラー画面にも白画面にもなっていません【実測: n=1, 2026-08-16, Classic Editor無効化直後の新規投稿画面】
  • 起動直後に「エディターへようこそ」という案内モーダルが表示されました【実測: n=1, 2026-08-16, 同画面】
  • 目視だけだと見間違いの余地があるので、機械的にも確認しています。ページの body 要素にブロックエディタ固有のクラスが付き、本文の段落ブロックが編集可能な要素として存在することを確かめました【実測: n=1, 2026-08-16, 同画面のDOM検査】
  • タイトルと段落ブロックに日本語を入力できました。全角スペース（U+3000）・①・㈱・〜・— を含む文字列を入れて、いずれも表示されています【実測: n=1, 2026-08-16, 同画面への入力】
  • 「下書き保存」を押すと 「下書きを保存しました。」 と表示され、URLが編集画面に切り替わり、ステータス欄は「下書き」になりました【実測: n=1, 2026-08-16, 同画面の保存通知とサイドバー表示】

保存まで通ったということは、保存に使われる通信も止まっていないということです。結論1の内容と矛盾しません。

作業のあと、Classic Editor は再度有効化して元に戻しています。有効・停止の内訳が測定前と一致していること、公開ページ7本が200を返すこと、匿名の /wp-json/wp/v2/users が401のままであることを確認しました【実測: n=1, 2026-08-16, 原状回復後の匿名HTTPとプラグイン一覧の突き合わせ】。

実測結果3：ブロックエディタとClassic Editorで読み込みはどれくらい違うのか

ここが、この記事でいちばん役に立つ部分かもしれません。因果の話が崩れても、「Classic Editorのほうが軽い」という体感が本当かどうかは別の問題だからです。

条件 1回目 2回目 3回目 平均 出典
Classic Editor（テキスト入力欄） 1124 1014 1046 1061 【実測: n=3, 2026-08-16, ブラウザ内計測・単位はミリ秒】
Classic Editor（ビジュアルエディタ） 1653 2000 2000 1884 【実測: n=3, 2026-08-16, 同上】
ブロックエディタ 3542 2858 3001 3134 【実測: n=3, 2026-08-16, 同上】

比べるべきはビジュアルエディタ同士です。 1884ミリ秒に対して3134ミリ秒で、約1.66倍、差は 2073ミリ秒でした【実測: n=3, 2026-08-16, 上表の平均値の比と差】。

体感で言えば「2秒弱で書き始められる」か「3秒強待つ」かの違いです【実測: n=3, 2026-08-16, 上表の平均値1884ミリ秒と3134ミリ秒を秒に読み替えたもの】。1回なら誤差のようなものですが、1日に何本も下書きを開く使い方だと積み上がります。「ブロックエディタは重い」という声には、少なくともこの環境では根拠がありました。

ただし注意点があります。

  • キャッシュが温まった状態での比較です。はじめて開くときはどちらももっと遅くなるとみられます（測っていません）
  • ブロックエディタは読み込むJavaScriptが多いため、サーバーの速さより手元の端末とブラウザの性能に左右されやすいと考えられますが、これは今回の測定では確かめていない推測です
  • 2回目と3回目のビジュアルエディタがどちらも2000ミリ秒ちょうどなのは、20ミリ秒間隔で監視した都合で同じ区間に入ったためとみられます。偶然かどうかは追加検証していません

実測結果4：エディタを変えると読者が見るページのHTMLは変わるのか

エディタを変えると公開側の見た目や出力も変わるのでは、と心配になります。ここも測りました。

固定ページ3本について、Classic Editor 有効の状態でHTMLを取得 → Classic Editor を無効化 → 同じ3本を再取得して、差分を取ります。

ページ Classic有効時 Classic無効時 差分 出典
運営者情報 203405 203405 0行 【実測: n=3, 2026-08-16, 匿名HTTP取得とdiff比較・サイズの単位はバイト】
プライバシーポリシー 207183 207183 0行 【実測: n=3, 2026-08-16, 同上】
広告・PR表記ポリシー 207516 207516 0行 【実測: n=3, 2026-08-16, 同上】

差分0行、バイト数も完全一致でした。

ここで一つ、測定として気をつけた点があります。このサーバーはコンテンツキャッシュが効いているので、古いキャッシュを2回取ってきて「同じでした」と言ってしまう事故が起こり得ます。それを避けるため、取得URLの末尾に毎回変わる文字列を付けて一意なURLにしました。そのうえで、レスポンスヘッダの x-nginx-cache が3本とも MISS（＝キャッシュから返していない）であることを確認しています【実測: n=3, 2026-08-16, キャッシュバスター付きURLのレスポンスヘッダ】。この判別方法は別の記事で測ったものです。

ただし、この結果の読み方には注意が必要です。 今回わかったのは「エディタを切り替えるだけでは、既存ページの出力は変わらない」ことです。「どちらのエディタで書いても同じHTMLになる」という意味ではありません。ブロックエディタで書いた記事は wp-block- で始まるクラスやコメントを出力するので、中身を書いたエディタが違えばHTMLは当然変わります。ここを混同すると読み違えになります。

では、なぜ Classic Editor を使うのか

因果が崩れたので、正直に整理し直します。

当初の理由（誤り）: REST APIを無効化するとブロックエディタが使えなくなるから、Classic Editorが必要。
→ この環境では成り立ちませんでした。 ブロックエディタは起動し、保存もできました【実測: n=1, 2026-08-16, 前掲】。

実際に残った理由:

  1. 書き始められるまでが速い。ビジュアルエディタ同士で約1.66倍の差があります【実測: n=3, 2026-08-16, 前掲】
  2. 好みの問題。長文を書くときの操作感を旧エディタのほうが好む、というのは正当な理由です。ただしそれは「使えないから仕方なく」ではありません
  3. 公開ページへの影響はない。少なくとも既存ページの出力は変わりませんでした【実測: n=3, 2026-08-16, 前掲】

つまり 「セキュリティ設定のためにClassic Editorが必要」ではなく、「速さと好みでClassic Editorを選んでいる」 が正確な言い方でした。自分のサイトの説明も、この記事を書く過程で言い直しています。

なお、「REST APIの無効化」自体は無意味ではありません。 ログインしていない相手に対してユーザー一覧系のエンドポイントを閉じる効果は実測で確認できています【実測: n=1, 2026-08-16, 匿名アクセスでの8エンドポイントの結果】。やめる理由にはならず、説明の仕方を直すべきだったという話です。

この記事の限界（正直に書いておきます）

  • 測定は1環境のみです。 WordPress 7.0.4・Cocoon・Classic Editor 1.7.0・SiteGuard WP Plugin 1.8.8 という組み合わせでの結果で、他の環境で同じになる保証はありません
  • 「REST API無効化」の実装はプラグインによって違います。 今回検証したのは SiteGuard WP Plugin のオプション1つだけです。認証済みのリクエストまで止める実装であれば、ブロックエディタは動かない可能性があります。 この記事の結果を「REST APIを無効化してもブロックエディタは動く」と一般化しないでください
  • 確認したのはブロックエディタの「起動・日本語入力・下書き保存」の3点だけです。 画像のアップロード、再利用ブロック、パターンの挿入、プレビューなどは試していません（未測定）
  • 保存時にどのエンドポイントを叩いたかは通信を記録していません。「保存できたのでRESTは通っている」と推定はできますが、推定であって実測ではありません
  • 所要時間はブラウザキャッシュが温まった状態での比較です。初回訪問時の数値は測っていません。回線・時間帯・端末性能でも変わります
  • HTMLの差分比較は固定ページ3本のみです。投稿ページ・アーカイブ・トップページは比較していません。また比較したのは「導入前と導入後」ではなく「有効と無効の切り替え前後」です（導入前のHTMLを保存していなかったため）
  • プラグイン一覧の画面にはこのサイトの防御構成が写り込むため、スクリーンショットは記事に掲載していません（別の記事と同じ方針です）。掲載している証跡は、匿名アクセスの生ログ・キャッシュヘッダの取得結果・差分の出力です
  • Classic Editor のサポート終了時期については、公式のアナウンスに依存する話であり、実測できる対象ではないため本記事では扱っていません

WordPressのREST API無効化についてのQ&A

Q. REST APIを無効化すると、ブロックエディタは使えなくなりますか？

A. 少なくとも今回測った環境では、使えなくなりませんでした。ブロックエディタは起動し、日本語の入力も下書き保存もできています【実測: n=1, 2026-08-16, Classic Editorを無効化した新規投稿画面での操作】。ただし「REST APIの無効化」という言葉が指す実装はプラグインによって違い、認証済みのリクエストまで止める実装であれば結果は変わり得ます。

Q. なぜ無効化したはずのREST APIが動いているのですか？

A. この環境の「無効化」が、ログインしていない相手だけを止める実装だったためです。匿名アクセスでは8エンドポイントすべてが401（code は rest_disabled）でしたが、管理者としてログインしたセッションでは同じ10エンドポイントすべてが200を返しました【実測: n=1, 2026-08-16, 匿名側と認証済み側の同一エンドポイント比較】。

Q. 設定が効いていない、ということではないのですか？

A. 効いています。外から見た場合、ユーザー一覧を返すエンドポイントは閉じています【実測: n=1, 2026-08-16, Cookieを送らないcurlでの取得】。ユーザー名の露出をどこまで防げているかについては、別の記事で外部から複数の経路を測っています。

Q. Classic Editor とブロックエディタでは、どれくらい速さが違いますか？

A. 投稿画面が入力できる状態になるまでで、ビジュアルエディタ同士なら Classic Editor 平均1884ミリ秒、ブロックエディタ平均3134ミリ秒でした（各3回計測）【実測: n=3, 2026-08-16, 同一手順・同一判定でのブラウザ内計測】。ブラウザキャッシュが温まった状態での比較です。

Q. エディタを変えると、公開されているページの表示は変わりますか？

A. 今回測った固定ページ3本では、HTMLの差分は0行でバイト数も一致し、変わりませんでした【実測: n=3, 2026-08-16, キャッシュバスター付きURLでの取得とdiff比較】。ただしこれは「既存ページの出力が変わらない」という意味で、「どちらのエディタで書いても同じHTMLになる」という意味ではありません。

Q. Classic Editor を入れる意味はありますか？

A. セキュリティ設定のために必要、という理由はこの環境では成り立ちませんでした。残る理由は、書き始めまでが速いこと（約1.66倍の差）【実測: n=3, 2026-08-16, 前掲】と、操作感の好みです。

この記事の測定条件・証跡の詳細は運営者情報・編集方針に記載の方針に従っています。広告表示についての方針は広告・PR表記に関するポリシーをご覧ください。

タイトルとURLをコピーしました