【備忘録】WordPress自動投稿プロジェクトの初回動作テストで発生した問題と解決手順まとめ

本記事は、WordPress への自動下書き投稿を行うプロジェクトの初回動作テストで発生した問題、原因、解決方法、今後の運用上の注意を整理した記録です。

確認できた動作、詰まりやすかったポイント、再テスト手順をまとめておくことで、同種の構成を再度セットアップするときの確認資料として利用できる内容にしています。

初回テストで確認できたこと

• request と draft から payload を生成できた
• WordPress REST API へ接続できた
• Application Password 認証で users/me を取得できた
• taxonomy を解決して下書き投稿できた
• publish と publish-draft の基本経路が動作した

つまり、MVP として必要な「原稿を用意し、payload 化し、WordPress に下書き投稿する」流れ自体は成立していました。

基本方針

初回テストでは、エラーの表面だけを追うのではなく、通信経路を段階的に切り分ける方針を取ることが重要でした。

特に、ローカル実行環境の問題なのか、TLS の問題なのか、WordPress 側の認証経路の問題なのかを分離して確認することで、不要な推測を減らせます。

また、公開記事として扱う前提のため、実際のログイン名、アプリケーションパスワード、実URL、内部ブログ識別子などの機密情報は伏せた状態で整理しています。

発生した課題と解決内容

1. PowerShell で複数コマンドを1行貼り付けして失敗した

仮想環境作成コマンドの後ろに別コマンドまで続けて貼り付けた結果、引数解釈が崩れてエラーになりました。

原因は、PowerShell 上でセットアップ手順を1行ずつではなく連結したまま実行していたことです。

対策としては、セットアップ手順を必ず1行ずつ実行するか、activate を使わずに仮想環境配下の実行ファイルを直接呼ぶ方式に統一するのが安全です。

python -m venv .venv
.venv\Scripts\python --version
.venv\Scripts\ツール名 --help

2. Activate.ps1 実行時に発行元確認が表示された

PowerShell では、実行ポリシーや署名確認の影響で Activate.ps1 実行時に確認ダイアログが出ることがあります。

この問題は、確認を許可して進める方法でも回避できますが、運用上は activate 自体を前提にしない構成のほうが扱いやすい場合があります。

本件では、仮想環境を activate せず、.venv 配下の python や投稿ツールを直接呼ぶ方式でも十分に運用可能であることを確認しました。

3. Windows の curl.exe で SSL 失効確認エラーが出た

切り分け中に Windows の curl.exe を利用したところ、証明書失効確認で停止するエラーが発生しました。

この段階では WordPress 認証以前の TLS 確認で失敗しており、認証設定そのものの問題ではありませんでした。

同種のエラーが出る場合は、切り分け目的で ssl-revoke-best-effort を付けて実行し、まずは通信経路を確認するのが有効です。

curl.exe --ssl-revoke-best-effort https://example.com/wp-json/

4. API チェックで rest_not_logged_in が返った

チェックコマンド実行時に、users/me へ対して 401 と rest_not_logged_in が返る状態になりました。

このエラーは「WordPress まで到達しているが、Application Password の認証が通っていない」ことを示していました。

当初は認証情報の誤り、マルチサイト構成、Two Factor なども候補に入りましたが、最終的には WordPress 側に Authorization ヘッダーが渡っていないことが主因でした。

切り分けでは、ツール経由ではなく curl.exe で直接 users/me を叩く方法が有効でした。これにより、ツール固有の不具合か、WordPress 側の認証経路問題かを分離できます。

curl.exe --ssl-revoke-best-effort --user "LOGIN_NAME:APPLICATION_PASSWORD" https://example.com/wp-json/wp/v2/users/me

なお、この切り分けで、マルチサイト自体や Two Factor 自体が直接の主因ではないことも確認できました。

5. サイトヘルスの Authorization ヘッダー警告が決定打になった

WordPress のサイトヘルスに「Authorization ヘッダーがありません」という警告が表示されていました。

この状態では、Application Password を使っても PHP や WordPress 側で認証ヘッダーを受け取れないため、rest_not_logged_in になりやすくなります。

API 認証で 401 が出た場合、認証情報の正誤だけを疑うのではなく、まずサイトヘルスの Authorization ヘッダー警告を確認する流れにしておくと調査が早くなります。

6. Xserver 環境では .htaccess 追記で解決した

Xserver 環境では Authorization ヘッダーがそのまま WordPress まで渡っておらず、.htaccess で受け渡しを明示する対応が必要でした。

対応として、# BEGIN WordPress より前に以下を追加しました。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:Authorization} .
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
</IfModule>

この対応後、curl による users/me の取得が成功し、投稿ツールの接続確認も通るようになりました。

配置場所は # BEGIN WordPress ブロックの中ではなく外側に置くほうが安全です。WordPress 側の設定保存などで既存ブロックが再生成される可能性があるためです。

7. publish 実行時にカテゴリ不足で停止した

投稿処理の段階では、payload に含まれるカテゴリが WordPress 側に存在せず、カテゴリ不足エラーで停止しました。

この問題は、WordPress 側でカテゴリを事前作成するか、設定ファイルで不足カテゴリの自動作成を許可することで解決できます。

ただし、運用方針としてはタグとカテゴリを同列に扱わないほうが無難です。タグは多少増えても影響が限定的ですが、カテゴリは AI 出力の揺れで乱立しやすいため、手動管理か厳格なルール化が望まれます。

8. smoke test 用 payload ファイルは通常運用に不要だった

初回テストでは、明示的に出力先を指定して検証用 payload ファイルを生成していました。

これは通常運用に必須のファイルではなく、検証目的で作成された一時成果物です。再利用予定がなければ削除して問題ありません。

Web UI で追加発生した問題

初期表示でモーダルや処理中表示が出っぱなしになる

画面を開いた直後から「処理中です」が表示され、投稿前チェック用のモーダルまで同時に見えてしまう状態が発生しました。

サーバーログに POST リクエストが出ていなかったため、バックエンド側ではなくフロントエンド表示制御の問題と判断できます。

原因は、hidden 属性を付けた要素に対して CSS 側の display 指定が勝っていたことでした。

対応として、CSS に hidden 属性を強制的に優先させる定義を追加し、初期表示時に不要なモーダルやビジー表示が出ないことを再確認しました。

[hidden] {
  display: none !important;
}

完了通知の音が鳴らない

完了モーダル自体は表示される一方で、通知音のみが鳴らない症状も確認されました。

原因としては、ブラウザの自動再生制限により、そのタブでまだユーザー操作をしていない場合に音声再生が拒否される挙動が考えられます。

確認時は、同じタブ内で一度クリックやキー入力を行ったあとに再度完了通知を発生させること、設定画面で通知音が ON になっていること、さらに試験再生で音が鳴ることを先に確認しておくと効率的です。

実運用向けの注意点

• base_url にはサイトのルート URL を使い、wp-json や wp-admin は付けない
• 認証には表示名ではなくログイン名を使う
• 認証障害時は投稿ツールより先に curl.exe で経路を切り分ける
• rest_not_logged_in のときはサイトヘルスの Authorization ヘッダー警告を最初に確認する
• マルチサイトや Two Factor が有効でも、Application Password 運用自体は可能
• カテゴリ自動作成を有効にするかどうかは、分類ルールと合わせて事前に決める
• サーバー側の設定を修正する場合、WordPress が書き換える領域の外に置く

最小の再テスト手順

再現確認や別環境への横展開では、以下の順序で最小テストを行うと状況を把握しやすくなります。

1. payload を生成する

wp-post build --request examples/request.example.yaml --draft examples/draft.example.md

2. WordPress 接続を確認する

wp-post check --blog TARGET_BLOG

3. payload から下書き投稿する

wp-post publish --payload payloads/example.json

4. request と draft から一括投稿する

wp-post publish-draft --request examples/request.example.yaml --draft examples/draft.example.md

この手順で得られるメリット

• ローカル実行環境、TLS、WordPress 認証のどこで失敗しているかを段階的に切り分けられる
• 初回セットアップ時の詰まりどころを標準化できる
• Xserver のような共有サーバー環境でも対応手順を再利用しやすい
• カテゴリ運用や UI 初期表示など、投稿成功後に起きる二次的な問題も先回りして確認できる

注意点

• 認証エラー時に、すぐマルチサイトや Two Factor を主因と断定しない
• Windows の curl.exe は TLS 周りで別系統のエラーを出すことがある
• .htaccess の追記位置を誤ると、将来の WordPress 更新や設定保存で消える可能性がある
• カテゴリを自動生成する場合は、分類ルールを決めないとカテゴリ乱立が起きやすい
• UI 側の hidden 制御や通知音は、API と無関係でも操作感に大きく影響する

まとめ

今回の初回動作テストでは、投稿機能そのものは早い段階で成立していましたが、最大の詰まりどころは WordPress 側で Authorization ヘッダーが渡っていないことでした。

Xserver 環境では .htaccess の追記が解決策となり、その後は WordPress REST API 認証、taxonomy 解決、下書き投稿まで一連の経路が通ることを確認できました。

今後の運用では、認証系エラー時の切り分け順序、カテゴリ運用方針、UI 初期表示の確認項目をあらかじめ標準化しておくことで、再発防止と再現確認の効率を高めやすくなります。