WordPress REST APIの「rest_not_logged_in」を解決｜XServer・Wordfence・.htaccessの確認記録

2026年8月20日

CodexにWordPressの編集者権限を渡し、REST API経由で記事の下書き・更新を行う準備中に、401エラーが発生しました。

{
  "code": "rest_not_logged_in",
  "message": "現在ログインしていません。",
  "data": {
    "status": 401
  }
}

同じXServer内の他サイトでは、アプリケーションパスワードを使ったWordPress連携を何度も行ってきました。しかし、このエラーが出たのは今回が初めてです。

最終的にはREST API認証に成功しましたが、原因を一つに断定できたわけではありません。本記事では、確認したポイントと解決までの流れを備忘録として残します。

発生した状況

• WordPressサイト
• 外部ツール：Codex
• WordPressユーザーを追加した
• 認証方法：WordPress標準のアプリケーションパスワード
• 確認したREST API：/wp-json/wp/v2/users/me
• エラー：401 rest_not_logged_in

アプリケーションパスワードは、通常のWordPressログインパスワードを外部ツールへ渡さずに、REST APIなどの外部連携を行うためのWordPress標準機能です。

最初に確認したこと

ユーザー名とアプリケーションパスワード

WordPress管理画面の「ユーザー」→「プロフィール」で、ログインユーザー名が間違っていないことを確認しました。

あわせて、codexユーザーに対してアプリケーションパスワードを発行し直しました。アプリケーションパスワードは発行直後しか本文を再表示できないため、発行画面でコピーして安全なローカル設定ファイルへ保存しています。

Wordfenceの設定

Wordfence Securityには、WordPressのアプリケーションパスワードを無効化する設定があります。

今回、Wordfenceがアプリケーションパスワードの発行を止めていたため、以下の設定をオフにしました。

• Wordfence → All Options
• Brute Force Protection
• 「WordPress アプリケーションパスワードの無効化」

この設定は外部連携を使わないサイトでは有効でも問題ありません。ただし、REST APIとアプリケーションパスワードを使う場合はオフにする必要があります。

XServerサポートへ問い合わせ

Wordfence設定を見直し、アプリケーションパスワードも再発行しましたが、REST APIは引き続き401エラーになりました。

そこでXServerサポートへ問い合わせたところ、Authorizationヘッダーがアプリケーション側まで渡っていない可能性があるとして、.htaccessの設定例を案内してもらいました。

外部ツールは、アプリケーションパスワードを含む認証情報をAuthorizationヘッダーに載せて送信します。サーバー設定によっては、この情報がPHP・WordPressまで引き継がれず、WordPress側が「ログインしていない」と判断する場合があります。

.htaccessに追加した設定

WordPressを設置している公開フォルダの.htaccessへ、次の1行を追加しました。

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

この記述により、受信したAuthorizationヘッダーを、WordPressが参照できるHTTP_AUTHORIZATIONとして引き渡します。

WordPress公式の.htaccess例にも同等のルールが含まれています。WordPress公式：Apache HTTPD / .htaccess

注意：Lを付けると404になった

サポートから案内された例には、末尾にLが付いていました。

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]

この状態では、WordPressの通常のURL振り分けまで停止したのか、REST APIが401ではなく404になりました。

最終的にはLを外し、次の記述にしたところ、通常のWordPressルーティングを維持したまま認証に成功しました。

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

.htaccessを編集する際は、必ず事前にバックアップを取ることをおすすめします。

最終的な結果

修正後、以下の2点を確認しました。

• /wp-json/がHTTP 200で応答すること
• /wp-json/wp/v2/users/meへアプリケーションパスワード付きでアクセスし、codexとして認証できること

これにより、CodexからWordPress REST APIを利用して、下書き作成・既存記事の更新・価格データの反映を行うための準備が整いました。

原因は何だったのか

今回の原因を一つに断定することはできません。

ただし、少なくとも次の2点が認証を妨げる要因になっていました。

• Wordfenceの「WordPress アプリケーションパスワードの無効化」設定
• AuthorizationヘッダーをWordPressへ渡す.htaccess設定の不足

特に、Wordfenceを見直しただけでは401エラーは解消しませんでした。.htaccessへヘッダー受け渡しルールを追加した後に認証が成功したため、REST API接続における直接的な解決要因は後者だったと考えています。

同じエラーが出た場合の確認リスト

1. WordPressのログインユーザー名を確認する
2. アプリケーションパスワードを新規発行し、発行直後の値を使う
3. Wordfenceなどのセキュリティプラグインで、アプリケーションパスワードやREST APIを無効化していないか確認する
4. HTTPSでアクセスしているか確認する
5. .htaccessに以下の記述があるか確認する

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

WordPress公式でも、CGI・FastCGI環境ではAuthorizationヘッダーがWordPressへ渡らない場合があると説明されています。WordPress公式：AuthorizationヘッダーからBasic認証情報を取得する仕組み

同じ401エラーで困っている場合は、アプリケーションパスワードの再発行だけでなく、Wordfenceと.htaccessもあわせて確認してみてください。