WordPress REST API の認証を通す — Application Passwords と、401が返るときの切り分け

公開 2026-10-25 ／ 更新 2026-10-25 ／ 文：ランツ

先に結論

WordPress の REST API に認証を通す方法は、昔はプラグインを選ぶところから始まりました。 いまは選ぶ必要がありません。用途が2つに分かれていて、それぞれ答えが1つです。

そして、401が返ったときの切り分けはこうです。

選択肢は実質2つしかない

Application Passwords はコアの機能

公式ドキュメントにはこう書かれています。 「5.6 以降、WordPress には Application Passwords が同梱されており、 ユーザー編集画面（wp-admin → ユーザー → ユーザーを編集）から生成できます」。

発行したものは HTTPS 経由の Basic認証（RFC 7617）でREST APIに渡します。 プラグインのインストールも、Client ID の取得も、有料ライセンスも要りません。

認証プラグインを入れる話は、ほぼ終わった

公式ドキュメントは認証プラグインとして OAuth 1.0a Server と JSON Web Tokens を挙げています。 そして Basic Authentication プラグインについては、はっきりこう書いています。

使えるかどうかは、1回のGETで分かる

authentication キーを見る

インストールも設定も要りません。REST APIのルートURLを叩いて、authentication キーを見るだけです。 公式の統合ガイドがこの方法を案内しています。「空なら Application Passwords は使えません」。

curl -s https://example.com/wp-json/ | jq .authentication

使える状態なら、こう返ってきます。

{
  "application-passwords": {
    "endpoints": {
      "authorization": "https://example.com/wp-admin/authorize-application.php"
    }
  }
}

{}（空のオブジェクト）が返ったら使えません。 HTTPSでないか、プラグインで無効化されているか、のどちらかです。

運用中の11サイトで叩いてみた

手元で運用しているWordPressサイト11件に対して、実際に /wp-json/ をGETしました。 どれも公開エンドポイントへの読み取りだけで、認証も書き込みもしていません。

9件はすべて、何も設定していないのに使える状態でした。 テーマもプラグイン構成もバラバラで、共通していたのはHTTPSで動いていることだけです。 「使えるようにする作業」はほぼ不要で、確認するだけで済みます。

使えなかった2件の理由

残り2件は、原因がまったく別でした。

1件目は、静的書き出しのサイトでよく踏みます。 見た目はWordPressのサイトなのに、公開されているのは書き出されたHTMLだけなので、 /wp-json/ は単なる存在しないパスになります。

このとき返ってくるのは404のHTMLです。それをJSONとして解釈しようとすると、こうなります。

SyntaxError: Unexpected token '<', "<!DOCTYPE "... is not valid JSON

手元で実際に出した出力です。「APIが壊れている」のではなく、そこにAPIが無いだけです。 このエラーの読み方は Unexpected token '<' ... is not valid JSON の原因と直し方 に書きました。

2件目は、トップページも叩いて切り分けました。 トップページも応答しないなら、APIの話ではありません。 /wp-json/ だけが失敗するのか、サイト全体が失敗するのかを先に分けてください。

Application Passwords を使う

発行する

wp-admin → ユーザー → 自分のプロフィールを開き、下のほうにある 「アプリケーションパスワード」で名前を付けて発行します。 表示されるのはその1回だけなので、その場で控えます。

表示のスペースは読みやすさのためのもので、入れても抜いても通ります。 ここで迷って「コピーミスかもしれない」と何度も発行し直す必要はありません。

HTTPSが前提なのは仕様です。公式はこう書いています。 「SSLがなければ、ネットワーク上の攻撃者にアプリケーションパスワードを見られる可能性があります」。 Basic認証は、中身をほぼそのまま送っているだけだからです。

curlで叩く

公式に載っている形です。ユーザー名とアプリケーションパスワードを --user に渡します。

# 公式ドキュメントの例
curl --user "USERNAME:PASSWORD" https://HOSTNAME/wp-json/wp/v2/users?context=edit

# 実際に使う形（スペースは抜いてよい）
curl --user "subburi:abcdEFGH1234ijklMNOP6789" \
  https://example.com/wp-json/wp/v2/posts?context=edit&per_page=1

投稿するときは、ヘッダとJSONを付けてPOSTします。

curl -X POST \
  --user "subburi:abcdEFGH1234ijklMNOP6789" \
  -H "Content-Type: application/json" \
  -d '{"title":"テスト","content":"本文","status":"draft"}' \
  https://example.com/wp-json/wp/v2/posts

"status":"draft" を付けておくのが安全です。 省略すると既定値で作られます。最初の1回は下書きで試して、応答の id と link を確認してください。

ブラウザの中から呼ぶときは nonce

管理画面のJSやテーマから同じサイトのAPIを呼ぶ場合は、話が変わります。 ログイン中のCookieがすでにあるので、認証そのものは済んでいます。 足りないのはCSRF対策のnonceです。

公式の説明で、一番効くのはこの一文です。

ログインしているのに401が返る、という症状の多くはこれです。 エラーは「権限がない」ように見えますが、WordPress側から見れば未ログインの人が叩いています。

渡し方は、PHP側でnonceを出して、JS側でヘッダに載せます。

<?php
// PHP側：スクリプトにnonceを渡す（公式の例）
wp_localize_script( 'wp-api', 'wpApiSettings', array(
    'root'  => esc_url_raw( rest_url() ),
    'nonce' => wp_create_nonce( 'wp_rest' )
) );

// JS側：X-WP-Nonce ヘッダに載せる
fetch( wpApiSettings.root + 'wp/v2/posts/1', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-WP-Nonce': wpApiSettings.nonce,
  },
  credentials: 'same-origin',
  body: JSON.stringify( { title: 'Hello Moon' } ),
} );

公式が「ヘッダが最も確実」と書いているのは DELETE のためです。 PHPは DELETE のリクエストボディをスーパーグローバルに展開しません。 クエリやボディに入れる方式だと、DELETE のときだけ落ちます。

nonceのアクション名は wp_rest 固定です。 自分のエンドポイントの中でnonceを検証し直す必要はありません。 WordPressが rest_cookie_check_errors() で自動的にやってくれます。

401が返るときの切り分け

まずエラーコードを読む

WordPressのREST APIは、失敗の理由をJSONの code で返します。 HTTPステータスだけ見ていると区別がつきません。本文を読んでください。

手元のサイトで、認証なしのまま各エンドポイントを叩いた結果です。

3行目が要注意です。公式ドキュメントに載っているURLなのに 404 が返りました。 認証の問題ではなく、そのサイトでユーザー一覧のエンドポイントが塞がれているということです。 セキュリティプラグインや functions.php での対策としてよく行われます。

rest_no_route が返ったら、認証を疑う前にエンドポイントの存在を疑ってください。 いくら正しいパスワードを渡しても404のままです。

Authorizationヘッダが落ちている

パスワードは合っているのに401が返り続ける場合、最有力はこれです。 公式のFAQに項目があります。

公式が載せている設定です。

# Apache（.htaccess または設定ファイル）
<IfModule mod_setenvif>
  SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
</IfModule>

# Nginx（fastcgi の設定セクション）
fastcgi_pass_header Authorization;

この症状の見分け方は、エラーコードです。 ヘッダが届いていなければ、WordPressから見れば誰も名乗っていないので rest_not_logged_in 系になります。 パスワードが違うなら incorrect_password が返るので、そこで区別できます。

それでも通らないとき

1行目を先に見てください。プロフィール画面に項目が出ていないなら、そこで話が終わります。 curlをいくら書き直しても通りません。

公開エンドポイントは誰でも叩ける

認証を整える前に、知っておくべきことがあります。 WordPressのREST APIは、リクエストのOriginヘッダを検証しません。

公式FAQの説明はこうです。

これは設計上の意図であって、不具合ではありません。 ただし、公開したくないものが公開エンドポイントから読めていないかは、確認する価値があります。

最後の行は、今回11サイトを叩いたときに実感しました。 /wp-json/ の namespaces を見るだけで、 SEOプラグイン、問い合わせフォーム、リダイレクト管理など、入れているものがかなり分かります。 塞ぐかどうかは別として、見えているという事実は知っておいたほうがいいです。

AIに任せるときの注意

判定は簡単です。「プラグインをインストールして Client ID を取得して」と言い出したら、情報が古いと思ってください。 2026年の答えは、プロフィール画面でパスワードを1つ発行するだけです。

よくある質問

OAuth 2 のプラグインは必要ですか

ほぼ不要です。公式が認証プラグインとして挙げているのは OAuth 1.0a と JWT で、OAuth 2 ではありません（表3）。 外部アプリから叩くだけなら Application Passwords で足ります。

アプリケーションパスワードの項目が見当たりません

HTTPSでないか、セキュリティプラグインが隠しています。 /wp-json/ の authentication が空かどうかで確認できます（詳しく）。

パスワードのスペースは入力するのですか

どちらでも通ります。公式が「スペースなしでも使える」と明記しています（表6）。 表示の区切りは読みやすさのためのものです。

ログインしているのに401が返ります

ブラウザ内から呼んでいるなら、nonceが渡っていません。 公式は「nonceが無ければ現在のユーザーを 0 に設定し、ログインしていても未認証リクエストとして扱う」と書いています（詳しく）。 X-WP-Nonce ヘッダを付けてください。

パスワードは合っているのに401が返ります

Authorizationヘッダがサーバーで落とされている可能性が高いです（詳しく）。 CGI/FastCGI環境でよく起きます。公式FAQの設定を入れてください。 応答の code が incorrect_password ならパスワードの問題、 未認証扱いの系ならヘッダの問題です。

404と rest_no_route が返ります

認証の前に、そのエンドポイントが存在しません。 URLかメソッドの間違いか、プラグイン等でそのルートが塞がれています（表8）。 実際、公式ドキュメントに載っているユーザー一覧のURLでも404になるサイトがあります。

/wp-json/ を叩いたらHTMLが返ります

そのドメインでWordPressが動いていません。静的に書き出したサイトでよくあります（表5）。 それをJSONとして読むと Unexpected token '<' になります。 詳しくは こちら。

DELETEだけ失敗します

nonceをクエリやボディで渡していませんか。 PHPは DELETE のリクエストボディをスーパーグローバルに展開しません。 X-WP-Nonce ヘッダで渡してください（表7）。

ブラウザのJSにアプリケーションパスワードを書いてもいいですか

いけません。ソースを見れば誰でも読めます。 サーバー側のコードからだけ使ってください。ブラウザから呼ぶならCookieとnonceです。

まとめ

• 外部から叩くなら Application Passwords、ブラウザの中からなら Cookie＋nonce。この2つでほぼ終わる。
• Application Passwords は WordPress 5.6からコア同梱。プラグインもClient IDも有料ライセンスも要らない。
• OAuth 2 は公式の認証手段の一覧に無い。公式が挙げているのは OAuth 1.0a と JWT。
• 使えるかどうかは /wp-json/ の authentication キーを見れば1回のGETで分かる。空なら使えない。
• 運用中の11サイトで実測したら、9件は何もせず使える状態だった。共通点はHTTPSで動いていることだけ。
• パスワードは24文字・記号なし。表示のスペースは抜いて使ってよい。
• ログイン中なのに401なら、nonceが渡っていない。WordPressは未認証リクエストとして扱う。
• パスワードが合っているのに401なら、Authorizationヘッダがサーバーで落とされている。CGI/FastCGIで起きる。
• rest_no_route は認証の問題ではない。そのエンドポイントが無いか、塞がれている。
• 公開エンドポイントはOriginを検証しないのでどこからでも叩ける。何が見えているかは確認しておく。