WordPress自動投稿の401エラー7つの原因｜REST APIの切り分け方

※本記事にはプロモーション(アフィリエイト広告)を含みます。

結論から書きます。WordPressの自動投稿で返る401の多くは「パスワードが違う」のではなく、認証情報がWordPressに届く前にサーバーで落ちていることで起きます。

だから、パスワードを何度作り直しても直りません。

当ブログの運営者は、Claude Codeで3サイトの記事を毎日自動投稿しています。そのうちweb-prepa.comでは、まさにこの401で REST API が通らず、投稿の方式ごと切り替えました。

なお、外部から記事を投稿するには、APIの窓口を自分で管理できるWordPressとレンタルサーバーが前提になります。当ブログのhayamablog.orgはエックスサーバー上のWordPressで、REST APIで投稿できています。

結論｜WordPress自動投稿の401は、原因が3つの層に分かれる

自動投稿で返る401は、原因が大きく3つの層に分かれます。上から順に確かめれば、総当たりをしなくても原因にたどり着けます。

401を切り分ける順番

1. STEP 1発行を確かめるパスワードの種類
2. STEP 2経路を確かめるヘッダーが届くか
3. STEP 3サーバー設定国外制限・WAF
4. STEP 4方式を決める直らなければ切替

1つ目は「発行」の層

アプリケーションパスワードではなくログインパスワードを使っている、ユーザー名を取り違えている、といった入力側の問題です。この層は自分の側だけで直せます。

2つ目は「経路」の層（いちばん厄介）

送った認証情報が、Webサーバーの途中で捨てられている状態です。WordPressからは「誰も名乗っていないリクエスト」に見えるため、正しいパスワードでも401になります。

当ブログのweb-prepa.comで起きたのがこれでした。パスワードをいくら疑っても、この層の問題にはたどり着けません。

3つ目は「サーバー設定」の層

レンタルサーバーのセキュリティ機能が、APIへのアクセスそのものを拒否している状態です。国外からのアクセス制限やWAFがここに入ります。

WordPressのREST APIが401のとき、最初にやる3つの確認

いきなり記事の投稿を何度も試すのは遠回りです。記事の中身が絡むと、認証以外の失敗と区別が付かなくなります。

最初は記事を送らずに、「自分が誰として認識されているか」だけを確かめます。

確認1：自分の情報を取るAPIだけを叩く

投稿ではなく、ログイン中のユーザー情報を返すエンドポイントだけを叩きます。ここでIDとユーザー名が返れば、認証は成立しています。

curl -u "ユーザー名:アプリケーションパスワード" \
  "https://example.com/wp-json/wp/v2/users/me?_fields=id,slug"

自動投稿の仕組みに組み込むなら、記事を書く前にこの確認を入れておくのがおすすめです。認証が切れたまま記事だけ作ると、時間が丸ごと無駄になるからです。

確認2：返ってきたエラーコードを読む

WordPressまでリクエストが届いていれば、JSONの中に理由のコードが入っています。ここを読まずに設定をいじると、原因から遠ざかります。

• incorrect_password：ユーザー名かパスワードが一致していない
• rest_not_logged_in：認証情報がそもそも届いていない
• rest_cannot_create：401なら未認証、403なら権限不足
• JSONではなくHTMLが返る：WordPressに届く前に拒否されている

コード名はHTTPステータスとセットで読むのがコツです。JSONが返ってこない時点で、WordPressの認証の話ではなくなります。

確認3：ブラウザで「/wp-json/」が開くか見る

ログインしていないブラウザで、自分のサイトの「/wp-json/」を開いてみます。JSONが表示されれば、APIの入口自体は生きています。

404やエラーページが出るなら、プラグインかサーバー設定でAPIが閉じられています。

WordPressの自動投稿が401になる7つの原因と直し方

ここからは、401を引き起こす原因を1つずつ見ていきます。上から順に確かめれば、多くの環境でどこかに当たります。

原因1：ログインパスワードをそのまま使っている

REST APIの基本認証では、管理画面のログインパスワードは使えません。使うのは、WordPress 5.6から標準で入った「アプリケーションパスワード」です。

ユーザーのプロフィール画面の下のほうで、用途名を付けて発行します。発行時の文字列は画面を閉じると二度と表示されないので、その場で控えてください。

原因2：Authorizationヘッダーがサーバーで落ちている

PHPがCGIやFastCGIとして動く構成では、Authorizationヘッダーが PHP まで渡らないことがあります。送信側にヘッダーが出ているのに401なら、落としているのはサーバー側です。

Apacheで.htaccessが使えるなら、WordPressが自動で書くブロックより前に、次の指定を足します。

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
RewriteEngine On
RewriteCond %{HTTP:Authorization} .
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

「# BEGIN WordPress」から「# END WordPress」の間に書くと、パーマリンク設定を保存したときに上書きされるので注意してください。

nginxでは.htaccessが読まれないため、WordPress公式のFAQにあるとおり、fastcgiの設定に fastcgi_pass_header Authorization; を足すなど、サーバー側でヘッダーを渡す必要があります。共用サーバーでその設定に触れないなら、サポートに頼むか、別の方式に切り替えることになります。

原因3：サイトがHTTPSになっていない

アプリケーションパスワードは、原則としてHTTPSのサイトでしか使えません。常時SSL化していないと、発行欄そのものが出てこないことがあります。

原因4：サーバーの国外アクセス制限が効いている

レンタルサーバーには、国外IPからのREST APIへのアクセスを拒否する機能があります。国内のパソコンから操作していれば気づきませんが、海外のクラウドから投稿すると突然弾かれます。

原因5：WAFやセキュリティプラグインが弾いている

サーバーのWAFや、WordPressのセキュリティプラグインが、APIへのアクセスを攻撃とみなすことがあります。WAFを一時的に切って通るなら誤検知なので、恒久対応は「その検知だけを除外する」が安全です。

原因6：ユーザー名に表示名を入れている

認証に使うのは、記事の署名に出る表示名ではなく、ログイン時のユーザー名です（メールアドレスでも認証できます）。確認1で返ってくる値を見れば、WordPressが自分を誰と認識しているかが分かります。

原因7：パスワードの空白や引用符でコマンドが壊れている

アプリケーションパスワードは4文字ごとに空白が入った形で表示されます。空白はあってもなくても認証できますが、コマンドの中で引用符を付け忘れると途中で切れて401になります。

症状	疑う層	最初に見る場所
incorrect_password	発行	ユーザー名と種類
rest_not_logged_in	経路	ヘッダーの転送
HTMLが返る	サーバー設定	WAF・国外制限
/wp-json/が開かない	サーバー設定	API無効化の設定

表は、症状から疑う層を引くための早見表です。同じ401でも、返ってくる中身で見に行く場所がまったく違います。

【実体験】同じ仕組みで、REST APIが通ったサイトと通らなかったサイト

ここは、当ブログの運営者が実際に踏んだ話です。同じClaude Codeの仕組みで投稿しているのに、サイトによって結果が割れました。

通った側：hayamablog.org（REST API＋アプリケーションパスワード）

hayamablog.orgは、WordPressのREST APIとアプリケーションパスワードで投稿しています。サーバーはエックスサーバーで、この方式で投稿できています。

Claude CodeやAI運営の記事は2026年7月30日から投稿を始め、今も同じ方式で毎日動いています。

通らなかった側：web-prepa.com（nginxがヘッダーを落とした）

web-prepa.comでは、サーバー（nginx）が認証ヘッダーを落とすため、REST APIが通りませんでした。原因2の「経路」の層です。

パスワードを作り直しても、ユーザーを変えても変わらないのは当然でした。WordPressには、認証情報そのものが届いていなかったからです。

XML-RPCに切り替えて運用している

web-prepa.comは、REST APIをあきらめてXML-RPCで投稿しています。XML-RPCは認証情報をリクエストの本文で渡すため、ヘッダーが落ちる環境でも通ります。

ただしXML-RPCは、パスワードの総当たり攻撃の標的になりやすい機能です。使うなら、ログイン試行の制限やアクセス元の絞り込みなど、別の守りを足すのが前提だと考えています。

401が直っても、公開が成功しているとは限らない

認証が通ると、そこで終わったつもりになります。実際には、そのあとに認証とは別の失敗がいくつも起きました。

たとえば、内部リンクのブログカードをURLだけの段落で書いたため、カードにならず崩れていました。今は埋め込みブロック（wp:embed）で書いています。

SEO SIMPLE PACKの説明文の設定で存在しないタグを入れ、全記事の説明文が空になったこともあります（すぐ戻しました）。投稿が成功で返っても、公開ページを見るまでは終わりではないと考えています。

自分の状況別｜401の直し方の選び方

同じ401でも、使っているサーバーと投稿元によって、取るべき手が変わります。状況別に答えを出しておきます。

状況	おすすめの手
.htaccessを編集できる	転送設定を足す
nginxで設定に触れない	XML-RPCか移転
海外から投稿する	国外制限を確認
WAFのログに検知がある	その検知を除外

.htaccessを編集できる人は、転送設定を足す

Apache系のサーバーで.htaccessを編集できるなら、原因2の設定を足すのが最短です。足したら、確認1をもう一度実行して結果を比べてください。

nginxで設定に触れない人は、XML-RPCかサーバーを変える

設定ファイルに触れない環境で時間をかけ続けるのは損です。

REST APIが素直に通るサーバーとしては、当ブログのhayamablog.orgが動いているエックスサーバー公式があります。当ブログのweb-prepa.comのようにXML-RPCに切り替えるか、REST APIが素直に通るサーバーを選び直すかの二択になります。

海外のサーバーから投稿する人は、国外アクセス制限を見る

クラウドの実行環境など、海外のIPから投稿する場合は、まずサーバーの国外アクセス制限を疑ってください。解除するなら、代わりにIPの制限など別の守りを用意するのが前提です。

エックスサーバーとConoHa WINGで設定を見る場所

サーバー設定の層は、会社ごとに置き場所も名前も違います。ここでは利用者の多い2社について、見に行く場所をまとめます（2026年10月時点の公式マニュアルの内容です）。

エックスサーバー：WordPressセキュリティ設定の国外アクセス制限

サーバーパネルの「WordPressセキュリティ設定」に、「国外アクセス制限設定」があります。その中の「REST API アクセス制限」が有効だと、国外IPからのREST APIへのアクセスが拒否されます。

国内から操作している限りは、触る必要はありません。海外の回線やクラウドから自動投稿するときに、最初に見る場所です。

ConoHa WING：サイトセキュリティの海外アクセス制限とWAF

ConoHa WINGでは、「サイト管理」の「サイトセキュリティ」から、WordPressの海外アクセス制限とWAFを設定できます。REST APIやXML-RPCなど、窓口ごとに制限を切り替えられます。

画面の名前や手順は変わることがあるので、ConoHa WING公式のサポートページで最新の内容を確認してください。

自動投稿の認証情報をどこに置くか

401が直ったあとに残るのが、発行したアプリケーションパスワードの置き場所です。自動化する以上、どこかに保存する必要があります。

コマンドやスクリプトに直接書かない

当ブログの公開用スクリプトは、アプリケーションパスワードをmacOSのキーチェーンに保存し、実行のたびに取り出しています。コマンドの履歴やファイルに平文で残さないためです。

スクリプトに直接書くと、ファイルを共有したりバックアップしたりした瞬間に広がります。キーチェーンや秘密情報の保管庫を使うのが安全です。

使わなくなったパスワードは失効させる

アプリケーションパスワードは用途ごとに発行でき、不要なものだけを個別に失効できます。検証で何本も作ったら、動いた1本を残して消しておきましょう。

WordPressの自動投稿と401エラーのよくある質問

最後に、切り分けの途中でよく出てくる疑問に答えます。

401と403は何が違いますか？

401は「誰だか分からない」、403は「誰かは分かったが権限がない」という意味です。ただし403は、WAFがWordPressに届く前に拒否したときにも返るので、JSONの理由コードがあるかで見分けます。

プラグインを全部止めないと原因は分かりませんか？

いきなり全部止める必要はありません。まず確認1のAPIを叩き、返ってきたのがJSONかHTMLかを見るほうが速いです。

サイト全体にBasic認証をかけていても使えますか？

サイトにすでにBasic認証をかけていると、アプリケーションパスワードの認証とぶつかることがあります。テスト環境などでBasic認証を使っている場合は、まずそれを外した状態で確認1を試してください。

アプリケーションパスワードの欄が表示されません

多くの場合、サイトがHTTPSになっていないか、セキュリティプラグインで機能が無効にされています。まず常時SSL化を確かめ、それでも出なければプラグインの設定を見てください。

Claude Codeから投稿するときも同じ切り分けでいいですか？

同じです。当ブログもClaude Codeから投稿していますが、401の原因はAIの側ではなく、認証情報がWordPressに届くかどうかでした。

Claude CodeとWordPressのつなぎ方は、Claude CodeとWordPressを連携する方法でまとめています。

まとめ｜401はパスワードより先に「届いているか」を疑う

WordPressの自動投稿で401が返ったら、パスワードを作り直す前に、認証情報がWordPressまで届いているかを確かめてください。記事を送らずに確認1を叩き、理由コードを読み、発行・経路・サーバー設定の順に見ていけば、原因は絞れます。

当ブログでは、同じ仕組みでもhayamablog.orgは通り、web-prepa.comはnginxがヘッダーを落としてXML-RPCに切り替えました。違ったのはWordPressではなく、サーバーの構成です。

投稿が通ったあとの崩れや失敗は、WordPressの自動投稿でブロックが崩れる原因で書いています。

これから環境を用意するなら、REST APIが素直に通るサーバーを選ぶのが結局いちばんの近道です。当ブログが使っているエックスサーバー公式は、料金やキャンペーンが時期で変わるため、申し込む前に公式ページで確認してください。