Xserver上でWordPress REST APIを使って記事投稿を自動化しようとした際、/wp/v2/posts へのPOSTリクエストに対して次のエラーが返ってきた。
WordPress API error 400 on /wp/v2/posts: 無効なパラメータ: status
メッセージだけ見ると「statusの値がおかしい」ように読める。しかし実際には、AuthorizationヘッダーがWordPress側に届いていないことが原因だった。
この記事では、同じエラーに詰まったときの切り分け手順と、.htaccess で解決した方法をまとめる。
この記事の要点
- エラーメッセージは「statusが無効」でも、原因が認証ヘッダー未伝達の場合がある
- XserverではAuthorizationヘッダーがPHPに渡らないことがある
.htaccessにHTTP_AUTHORIZATIONを引き継ぐ設定を追加すると解決するケースがある- 切り分けは「status値の確認」と「認証ヘッダーの確認」をセットで行う
発生したエラー
発生したエラーの全文は以下のとおり。
WordPress API error 400 on /wp/v2/posts: 無効なパラメータ: status
発生箇所は /wp/v2/posts（投稿作成エンドポイント）。HTTP 400 は「リクエストの内容に問題がある」という応答で、WordPress REST APIはどのパラメータが問題かをメッセージに含めてくれる。ここでは status が指摘されている。
まず確認すること：status値は正しいか
エラーメッセージの通り、まず status の値自体を疑うのが正しい順番だ。
WordPress REST APIの投稿作成で使える status の値は以下のとおり。
draft：下書きpublish：公開future：予約投稿（dateパラメータとセット）pending：レビュー待ちprivate：非公開
次のような誤りが混入しやすい。
- 全角文字や日本語で値を渡している（
"下書き"など） - 余分なスペースが入っている（
"draft "など） - フィールド名を
post_statusにしている（REST APIではstatus） - 定義されていない独自ステータスを指定している
これらを確認してもエラーが解消しない場合、原因は別にある可能性が高い。
Xserver環境で起きた実際の原因
今回のケースでは、status値に問題はなかった。
原因は AuthorizationヘッダーがWordPress（PHP）まで届いていなかったことだったとみられる。XserverのサーバーやApacheの設定によって、HTTPリクエストに含まれるAuthorizationヘッダーがそのままPHPに渡らない場合がある。
WordPress REST APIはApplication Passwordによる認証を処理する際にこのAuthorizationヘッダーを参照する。ヘッダーが届いていない状態では認証が通らず、リクエストは未認証扱いになる。
なぜstatusエラーに見えるのか。 未認証のリクエストは、公開ステータス（publish など）の投稿を作れないなど、権限に基づくバリデーションが走る。その結果として status に関するエラーが返ってくる場合があるとみられる。つまり、「statusの値が悪い」というメッセージが出ていても、根本的な原因はAuthorizationヘッダーの問題という可能性がある。
ここがポイント：「無効なパラメータ: status」は常にstatus値の問題とは限らない。XserverなどでApplication Passwordを使う場合は、AuthorizationヘッダーがWordPressに届いているかをあわせて確認する。
解決方法：.htaccessに設定を追加する
.htaccess に以下の設定を追加することで解決した。
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:Authorization} .
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
</IfModule>
この設定は、ApacheがPHPにリクエストを渡す際に、HTTPのAuthorizationヘッダーを HTTP_AUTHORIZATION 環境変数としてセットするものだ。WordPressはこの環境変数を通じてAuthorizationヘッダーの内容を受け取る。
追加する場所
.htaccess ファイル内の # BEGIN WordPress より前に追加する。
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:Authorization} .
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
</IfModule>
# BEGIN WordPress
# ... WordPressの既存設定 ...
# END WordPress
WordPress側が管理するブロック（# BEGIN WordPress ～ # END WordPress）の内部に書くと、WordPress更新時などに上書きされる可能性があるため、その前に置くのが基本だ。
編集前にバックアップを取ること。 .htaccess を誤って壊すとサイト全体がアクセス不能になる場合があるため、変更前に必ずバックアップを作成しておく。
確認手順
エラーが発生したときの切り分け手順を整理する。
1. status値を確認する
リクエストのペイロードを確認し、status フィールドの値が有効な値（draft / publish / future / pending / private）になっているかチェックする。
2. Application Password認証が通るか確認する
以下のエンドポイントにGETリクエストを送り、認証が正しく通るか確認する。
GET /wp-json/wp/v2/users/me
Authorization: Basic <base64エンコードしたユーザー名:Application Password>
レスポンスに自分のユーザー情報が返ってくれば認証は通っている。401 Unauthorized や 403 Forbidden が返る場合、認証ヘッダーが届いていない可能性が高い。
3. .htaccessの設定を確認・追加する
/wp-json/wp/v2/users/me で認証が通らない場合、.htaccess の設定を確認する。HTTP_AUTHORIZATION 引き継ぎ設定が追加されていなければ追加し、再度テストする。
4. statusをdraftに固定してテストする
設定追加後、まず status: draft で投稿作成リクエストを送って動作確認する。下書きであれば投稿権限のチェックが最小限になるため、認証が通ればほぼ成功する。
5. 本番のstatus設定に戻す
draft で成功したら、自動投稿スクリプトのstatus設定を本来の値（publish など）に戻して確認する。
まとめ：Xserverでは.htaccess設定も優先確認する
「無効なパラメータ: status」というエラーが出たとき、確認すべき点は2つある。
- status値そのもの — 有効な値を送っているか
- AuthorizationヘッダーがWordPressに届いているか —
/wp-json/wp/v2/users/meで認証確認
Xserver環境では後者が原因になるケースがある。.htaccess に HTTP_AUTHORIZATION の引き継ぎ設定を追加することで解決するため、同じエラーに詰まったらstatus値と認証ヘッダーの両方をセットで確認するのが早い。
他のサーバー環境でも類似の問題は起きる可能性があるが、環境依存の挙動のため、Xserver以外での動作は個別に確認が必要だ。
コメント