WordPressの自動投稿が401で通らない7つの原因|72日247本を自動公開して切り分けた手順

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

先に立場を明かします。このブログの記事は、AI(Claude Code)が書いてWordPressに自動で公開しています。

自動投稿を始めた2026年7月10日から9月19日までの72日間で、3つのカテゴリ合わせて247本が公開されました(2026年9月19日時点の集計)。

その同じ仕組みを、もう1つの自分のサイトに入れようとしたときに丸一日を溶かしたのがこの401エラーでした。

そして原因は、パスワードではありませんでした。

401の大半は「パスワードが違う」ではなく、認証情報がWordPressに届く前に落ちていることで起きます。だから何度パスワードを作り直しても直りません。

なお、外部から記事を投稿するには、APIの窓口を自分で開け閉めできるWordPressとレンタルサーバーが前提になります。この247本を公開しているのはエックスサーバー公式のサーバー上です。

結論|WordPressの自動投稿の401は、原因が3か所にしか分かれない

結論から書きます。自動投稿で返る401は、原因が大きく3つの層にしか分かれません。

この3つを上から順に潰すだけで、総当たりをしなくても原因にたどり着けます。

401の原因は「発行」「経路」「サーバー設定」の3層に分かれる

1つ目は発行の層です。そもそもアプリケーションパスワードではないものを使っている、ユーザー名が違う、といった入力側の問題がここに入ります。

2つ目は経路の層で、ここが一番厄介です。送った認証情報がサーバーの途中で捨てられ、WordPressには「誰も名乗っていないリクエスト」として届いています。

3つ目はサーバー設定の層です。レンタルサーバー側のセキュリティ機能が、APIへのアクセスそのものを国外IPやWAFで拒否している状態を指します。

同じ手順でも、サーバーが違うだけで通ったり通らなかったりする

筆者は自分の2つのサイトに、ほぼ同じ自動投稿の仕組みを入れました。

結果は割れました。このブログは72日間ずっとREST APIで通っている一方、もう1つのサイトは同じ手順で一度も認証が通らず、別の方式に切り替えて運用しています。

違いはWordPressの設定ではなく、サーバー側の構成でした。詳しくは後半で書きます。

この記事で確かめられること・確かめられないこと

確かめられるのは、筆者が実際に自分の環境で踏んだ症状と、その切り分け方です。

一方で、すべてのレンタルサーバーやすべてのセキュリティプラグインを試したわけではありません。サーバー固有の設定名や既定値は、必ず各社の公式マニュアルで確認してください。

WordPressのREST APIが401で認証できないとき最初にやる疎通確認

投稿のリクエストを何度も叩きながら原因を探すのは、遠回りになります。記事の中身が絡むと、認証以外の失敗と区別が付かなくなるからです。

最初にやるべきなのは、記事を一切送らずに「自分が誰として認識されているか」だけを確認することです。

手順1|自分の情報を取るAPIだけを叩いて切り分ける

まず、投稿ではなくユーザー情報を取るエンドポイントだけを叩きます。ここが通れば認証は成立しており、401の原因は認証以外にあります。

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

このブログの自動投稿では、記事を書き始める前に必ずこれを実行しています。

そして想定したIDとユーザー名が返らない限り、記事を書く処理に進ませないというルールにしています。認証が切れたまま記事だけ作っても、時間が丸ごと無駄になるからです。

手順2|返ってきたエラーコードを読む

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

• incorrect_password|ユーザー名かパスワードが一致していない(発行の層)
• rest_not_logged_in|そもそも認証情報が届いていない(経路の層の可能性が高い)
• rest_cannot_create|401で返るなら認証が届いていない、403で返るなら権限が足りない
• HTMLが返る・JSONですらない|WordPressに届く前に拒否されている(サーバー設定の層)

コード名だけで判断せず、HTTPステータスとセットで読むのがコツです。同じコードでも、401なら認証が届いておらず、403なら権限の問題になります。

そして最後のパターンが特に重要です。レスポンスがJSONでない時点で、それはWordPressの認証の話ではなくなります。

手順3|ブラウザでAPIの入口が開くか確認する

次に、ログインしていないブラウザで自分のサイトの「/wp-json/」を開いてみます。

ここでJSONが表示されればAPIの入口自体は生きています。404やエラーページが出るなら、プラグインかサーバー設定でAPIが閉じられています。

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

ここからは、実際に401を引き起こす原因を1つずつ見ていきます。上から順に確認すれば、ほとんどの環境でどこかに当たります。

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

WordPressのREST APIは、管理画面にログインするときのパスワードを受け付けません。ログインパスワードでは、どれだけ正しくても必ず401になります。

使うのはWordPress 5.6から標準で入った「アプリケーションパスワード」です。ユーザー編集画面の下のほうで、用途名を付けて発行します。

発行時に表示される文字列は、その画面を閉じると二度と表示されません。控え忘れたら作り直すことになります。

原因2|認証ヘッダーがサーバーの途中で落ちている

これが、筆者が一番長くはまった原因です。送った認証情報が、PHPに渡る前にWebサーバーで捨てられていました。

PHPがCGIやFastCGIとして動いている構成では、Authorizationヘッダーが素通ししてもらえないことがあります。WordPressから見れば「何も名乗っていないリクエスト」なので、正しいパスワードでも401です。

疑わしいときは、送信内容まで表示させて確認します。

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

送信側にAuthorizationの行が出ているのに401が返るなら、落としているのは自分ではなくサーバー側です。

Apacheが使える環境なら、.htaccessに転送の指定を足します。WordPressが自動生成するブロックより前、ファイルの先頭に置くのが要点です。

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

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

どちらか片方では効かない環境があるため、2つとも書いておくほうが安全です。

nginxとPHP-FPMの構成では.htaccessが読まれないため、この方法は効きません。サーバー側の設定でヘッダーを明示的に渡す必要があります。

fastcgi_param HTTP_AUTHORIZATION $http_authorization;
fastcgi_pass_header Authorization;

共用サーバーでこの設定に触れない場合は、サポートに依頼するか、別の方式に切り替えるかの二択になります。

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

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

ローカル開発環境だけは例外的に許可できますが、公開サイトでHTTPのまま使う選択肢はありません。まずSSL化が先です。

原因4|サーバー側のREST APIアクセス制限がONのまま

レンタルサーバーには、REST APIへの国外IPからのアクセスを既定で拒否する機能があります。日本国内から操作していれば気づきませんが、海外の回線やクラウド経由だと突然弾かれます。

たとえばエックスサーバーの「REST API アクセス制限」は既定で有効で、公式マニュアルでも原則そのままの運用が推奨されています(2026年9月時点)。

解除する場合は、代わりにIP制限などの別の防御を用意するのが前提になります。設定場所は後の章で具体的に書きます。

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

サーバーのWAFや、WordPress側のセキュリティプラグインがAPIへのアクセスを攻撃とみなして遮断しているケースです。

見分け方は単純で、WAFを一時的に切って同じリクエストが通るかを試します。通るならWAFの誤検知なので、恒久対応は「WAFを切る」ではなく「そのログだけを除外する」です。

プラグイン側が原因の場合は、REST APIを無効化する設定や、xmlrpc.phpを塞ぐ設定が入っていないかを確認します。

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

認証に使うのは、記事の署名に出る表示名ではなく、ログイン時のユーザー名です。日本語の表示名をそのまま入れて通らない、という取り違えは珍しくありません。

手順1のAPIが通ったときに返ってくる値を見れば、WordPressが自分を誰として認識しているかがはっきりします。

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

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

自動化の中で変数として渡すときは、必ず引用符で囲みます。コピー時に改行が混ざっているだけで401になることもあります。

症状	疑う層	最初に見る場所
incorrect_password が返る	発行	ユーザー名とアプリケーションパスワード
rest_not_logged_in が返る	経路	Authorizationヘッダーの転送設定
JSONではなくHTMLが返る	サーバー設定	WAF・国外アクセス制限
ブラウザで/wp-json/が開かない	サーバー設定	プラグインのREST API無効化
401ではなく403が返る	権限	ユーザー権限グループ

【実体験】同じ自動投稿の仕組みで、通ったサーバーと通らなかったサーバー

ここが、この記事でいちばん具体的に書ける部分です。筆者は2つの自分のサイトに同じ仕組みを入れて、結果が割れました。

同じ手順書、同じ発行方法、同じコマンドです。違ったのはサーバーだけでした。

通った側|72日間、認証で止まったことはない

このブログでは、アプリケーションパスワードを発行してすぐにREST APIで投稿が通りました。追加の設定は何もしていません。

その後、2026年7月10日から9月19日までの72日間で247本が公開されています。この間、認証が原因で公開が止まったことはありません。

通らなかった側|認証情報がPHPまで届いていなかった

もう1つのサイトでは、まったく同じ手順で401が返り続けました。パスワードを作り直しても、ユーザーを変えても同じでした。

原因は原因2でした。サーバーの構成上、Authorizationヘッダーが途中で落ちており、WordPressまで届いていなかったのです。

パスワードを疑っている限り、この症状には一生たどり着けません。だからこそ、手順2でエラーコードを読む価値があります。

XML-RPCに切り替えたときの代償

そのサイトは、REST APIをあきらめてXML-RPC経由の投稿に切り替えました。XML-RPCは認証の渡し方が違うため、同じ環境でも通ります。

ただしこれは妥協です。XML-RPCはブルートフォース攻撃の標的として有名で、一般には無効化が推奨されている機能だからです。

使うと決めたなら、ログイン試行の制限など別の守りを足す必要があります。何も足さずに開けておくのは、認証が通る代わりに穴を1つ開けたのと同じです。

認証が通っても、公開が成功しているとは限らない

401が消えると、そこで終わったつもりになります。実際には、ここからが自動投稿の本番でした。

投稿が200で返ってきても、公開が成功しているとは限りません。このブログでは、文字化け・ブロック崩れ・二重投稿の3つが実際に起きています。

いずれも認証とは別の問題です。それぞれの内容と対策はClaude Codeでブログを自動投稿する手順にまとめています。

エックスサーバーとConoHa WINGで設定を見る場所【2026年9月時点】

サーバー設定の層は、会社ごとに置き場所も名前も違います。ここでは利用者の多い2社について、実際に見に行く場所を書きます。

以下は2026年9月時点で公式マニュアルに記載されている内容です。仕様は変更されることがあるため、最終確認は公式で行ってください。

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

サーバーパネルの「WordPressセキュリティ設定」を開き、上部の「国外アクセス制限設定」タブに進みます。

ここに「ダッシュボードアクセス制限」と並んで「REST API アクセス制限」があります。既定は有効で、国外IPからのREST APIリクエストを拒否する挙動です。

国内から操作している限りは触る必要がありません。逆に、海外のサーバーや回線から自動投稿するなら、ここが最初の容疑者になります。

ConoHa WING|海外アクセス制限とWAFの除外設定

ConoHa WINGはコントロールパネルの「サイト管理」から「サイトセキュリティ」に進み、その中の「WordPressセキュリティ」タブを開きます。

ここにある「海外アクセス制限」で、ダッシュボード・XML-RPC-API・REST-APIなどの項目を個別に切り替えられます。既定はすべて制限する側に倒れているため、自動投稿で使う窓口だけを開ける形になります。

WAFで弾かれている場合は、同じサイトセキュリティ内の別タブにあるWAFのログから、該当の時刻の検知を選んで「除外」にします。全体を切るより安全な直し方です。

設定画面の項目名や手順はConoHa WING公式のサポートページで公開されています。

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

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

ここを雑にすると、投稿が通ることと引き換えに認証情報が漏れる経路を作ってしまいます。

コマンドやファイルに直接書かない

筆者はmacOSのキーチェーンに保存し、実行のたびに取り出す形にしています。コマンドの履歴にもログにも残らないようにするためです。

スクリプトの中に平文で書くと、そのファイルを共有したりバックアップに含めたりした瞬間に広がります。環境変数や秘密情報の保管庫を使うのが前提です。

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

アプリケーションパスワードは用途ごとに分けて発行でき、不要になったものだけを個別に失効できます。

検証で何本も作った場合は、動いた1本を残して残りを消します。どれが生きているか分からない状態を放置しないことが大事です。

XML-RPCを使うなら合わせてやること

REST APIが通らずXML-RPCに逃げる場合は、開けっ放しにしないことが条件になります。

ログイン試行回数の制限を入れる、アクセス元を絞る、使わなくなったら閉じる。この3つはセットで考えたほうが安全です。

自分で直せる401と、構成上どうにもならない401

ここまでの7つの原因は、設定画面で直せるものと、サーバーの構成そのものに踏み込まないと直らないものに分かれます。

判断の基準は「管理画面で開け閉めできる話か、設定ファイルの話か」の一点です。

設定画面だけで直せる401

国外アクセス制限やWAFが原因なら、サーバーの管理画面の操作だけで解決します。発行の取り違えやHTTPS未対応も同じで、自分の側で完結します。

ここに当たったなら、原因さえ特定できれば数分で終わります。総当たりをしないで済むかどうかは、手順2でコードを読んだかどうかで決まります。

構成上どうにもならない401

認証ヘッダーが落ちていて、かつ設定ファイルに手を入れられない環境は、時間をかけるだけ損になりやすいです。

毎日記事を公開する前提なら、外部から投稿する窓口を自分で開け閉めできるサーバーを選んだほうが確実です。筆者が247本を公開しているのはエックスサーバー公式のサーバーで、こちらは追加設定なしでREST APIが通りました。

サーバー側の条件をどう見たかはAI自動投稿で実際に止まった場面とサーバー選びに書いています。

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

実際に自動投稿を組むときに、つまずきやすい点をまとめます。どれも切り分けの途中でよく出てくる疑問です。

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

401は「誰だか分からない」、403は「誰かは分かったが、それをする権限がない」という意味です。

ただし403は、WAFなどがWordPressに届く前に拒否したときにも返ります。JSONで理由コードが返っているかどうかで、この2つを見分けます。

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

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

JSONで理由コードが返っているなら、プラグインではなくWordPressの内部まで届いています。

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

多くの場合、サイトがHTTPSになっていないか、セキュリティプラグインで機能自体が無効化されています。

まず常時SSL化を確認し、それでも出ないならプラグインの設定を見てください。

無料ブログやnoteでも自動投稿はできますか?

外部から記事を投稿する窓口が用意されていないため、同じやり方はできません。自動で公開したいならWordPressが前提になります。

サーバー選びの条件については、関連記事のほうで比較しています。

自動投稿にすると検索でペナルティを受けますか?

投稿の方法そのものが理由で罰せられるわけではありません。問題になるのは、価値を足さない量産のほうです。

この線引きについてはAIの自動投稿とGoogleの線引きで詳しく整理しています。

まとめ|WordPressの自動投稿の401は、切り分ける順番さえ決めれば終わる

401でパスワードを作り直し続けるのは、ほとんどの場合、間違った場所を掘っています。

やることは3つです。記事を送らずに認証だけを確認し、返ってきた理由コードを読み、発行・経路・サーバー設定の順に潰していく。

筆者の環境では、同じ手順でも通るサーバーと通らないサーバーがありました。原因はWordPressではなく、認証情報がPHPまで届いていたかどうかでした。

なお、認証が通っても記事が読まれるかは別の話です。実際に72日247本を公開した結果はAIブログのアクセスが増えない理由に正直に書いています。

これから環境を用意するなら、APIの窓口を自分で開け閉めできるサーバーを選ぶところから始めるのが結局いちばん速いです。

筆者が使っているエックスサーバー公式は2026年10月5日17時まで半額キャッシュバックを実施しています(期間中の新規申込かつ12ヶ月以上の契約が対象・申請制)。

金額や条件は変更されることがあるため、申し込む前に必ず公式ページで確認してください。