GitHub ActionsからWordPress REST APIへ記事を自動投稿するとき、本文生成や公開処理より先に固めたいのが認証情報の扱いです。自動化が動くだけなら、ユーザー名とパスワードをワークフローへ直接書くことでも実現できてしまいます。しかし、その構成はリポジトリ履歴、ログ、コピーされた設定ファイルなどから認証情報が漏れる原因になります。
WordPressには外部アプリケーション向けのApplication Passwordsがあり、WordPress REST APIをHTTPS経由で利用する認証手段として公式に案内されています。GitHub ActionsにはSecretsがあり、ワークフローで使う機密値をリポジトリの通常ファイルから分離できます。重要なのは、どちらか一方を使うだけではなく、発行・保存・実行・失効までを1つの運用として設計することです。
この記事では、AIBlogBaseで実際に採用しているGitHub Actions→WordPress REST APIの構成を一般化し、安全性と運用性を両立する認証設計を整理します。投稿自動化の全体像を先に知りたい場合は、GitHub ActionsでWordPress投稿を自動化する方法、公開後まで閉じる方法はWordPress自動投稿の公開後QA設計もあわせて確認してください。
結論：認証情報は「WordPress側」と「GitHub側」の2層で分ける
実運用では、次の役割分担にすると構成が分かりやすくなります。
- WordPress側：自動化専用のユーザーとApplication Passwordを用意する
- GitHub側：WordPress URL、ユーザー名、Application PasswordをSecretsとして保存する
- Workflow側：Secretsを環境変数として受け取り、値そのものをコードへ書かない
- 公開処理側：REST APIの認証成功と記事公開成功を分けて判定する
- 運用側：不要になったApplication Passwordだけを個別に失効できる状態にする
この設計の利点は、WordPressの通常ログイン用パスワードを自動化へ渡さずに済むことです。WordPress公式ドキュメントではApplication PasswordsはAPI認証用で、通常のブラウザログイン用ではないこと、個別に失効できることが説明されています。また、外部アクセスではHTTPSを利用する前提です。
Application Passwordsを使う理由
WordPress REST APIでは、外部のスクリプトやサービスから認証するときにApplication Passwordsを利用できます。Application PasswordはWordPress 5.6以降のコア機能として提供されており、ユーザーごとに作成できます。
大事なのは、Application Passwordが「管理者パスワードのコピー」ではないことです。自動投稿用に1つ作成し、その連携だけを後から失効できます。複数の自動化を運用するなら、1つのApplication Passwordを使い回すのではなく、用途ごとに分けた方が切り分けしやすくなります。
たとえば「GitHub Actions投稿用」「ローカル保守用」を分けておけば、GitHub Actions側だけに問題が起きたときに、該当するApplication Passwordだけを取り消せます。WordPress公式にはApplication Passwordごとの利用情報を確認し、個別に削除するAPIも用意されています。
自動化専用ユーザーを分ける
Application Passwordは、それを発行したWordPressユーザーの権限で動作します。そのため、自動投稿のためだけにサイト全体の管理権限が必要とは限りません。投稿、メディア、必要なカスタム投稿タイプなど、実際に操作する対象に合わせてユーザー権限を決めるべきです。
ここでの目的は「最小権限という言葉を使うこと」ではなく、事故時の影響範囲を具体的に狭めることです。自動投稿しか行わないワークフローに、プラグイン設定、ユーザー管理、サイト設定の変更権限まで持たせる必要は通常ありません。一方、既存サイトではプラグインや独自権限の構成が異なるため、実際のREST APIエンドポイントで必要な操作ができることを検証してから権限を確定します。
権限を絞りすぎて403になった場合も、すぐに管理者権限へ広げるのではなく、「どのエンドポイントのどの操作で拒否されたか」を確認します。投稿の更新は成功するが固定ページは403、メディアだけ失敗する、といった違いがあれば、必要な権限境界を特定できます。
GitHub Actions Secretsへ保存する値
GitHub Actionsでは、機密情報をSecretsとして保存できます。ワークフローはSecretsを明示的に参照した場合に利用できます。WordPress自動投稿なら、少なくとも次の3種類を分けて持つ構成が扱いやすいです。
- WordPressのベースURL
- 自動化用WordPressユーザー名
- そのユーザーに発行したApplication Password
これらをHTML記事、Pythonスクリプト、YAMLへ直接書かないことが重要です。コードには「どの環境変数を読むか」だけを書き、値はGitHub側のSecretsから注入します。AIBlogBaseの公開ワークフローでも、WordPress URL・ユーザー名・Application PasswordはSecretsから環境変数へ渡し、リポジトリのコンテンツファイルには認証情報を保持しない構成にしています。
Secretsを使えば何を書いても安全という意味ではありません。認証情報を自分でechoしたり、例外処理でAuthorizationヘッダー全体を出力したりすれば、不要な露出につながります。ログへ出すのはHTTPステータス、対象URL、投稿ID、QA結果など、障害調査に必要な非機密情報へ限定します。
Workflowでは最初に認証前提を検査する
自動投稿ワークフローは、記事処理へ入る前に必要な環境変数が存在するかを確認すると切り分けが速くなります。ここで値そのものを表示する必要はありません。「空ではないこと」だけを検査します。
この前処理を入れると、Secrets未設定とWordPress側の認証失敗を分離できます。Secretsが空ならGitHub側の設定問題、値は存在するが401なら認証情報や認証方式、403なら権限境界、REST APIは成功するが公開ページが異常ならWordPress表示側の問題、というように故障箇所を段階化できます。
自動化を長く運用すると、この切り分けが効きます。単に「投稿失敗」とだけ記録するより、どの層で止まったかが分かる方が復旧時間を短くできます。
401・403・200を同じ失敗として扱わない
認証まわりで特に重要なのがHTTPレスポンスの意味を分けることです。
- 401：資格情報が受け付けられていない可能性を優先して確認する
- 403：認証自体は通っていても、その操作権限がない可能性を確認する
- 200系：REST API上の処理成功。ただし本番ページ成功とは別に確認する
実際にはプラグイン、WAF、サーバー設定などでもレスポンスは変わるため、ステータスコードだけで原因を断定しません。それでも、すべてを同じ「APIエラー」にまとめないだけで調査の方向性は大きく改善します。
特に200系を最終成功にしない点は重要です。REST APIで投稿が更新されても、公開ページに古いキャッシュが残る、canonicalが想定外、noindexが付く、内部リンクや画像が壊れることがあります。認証設計は公開後QAとセットで完成します。
Application Passwordの失効手順を先に決める
認証情報は「漏れないようにする」だけでなく、「問題が起きたときに止められる」ことが重要です。Application Passwordsは個別に失効できるため、通常ログインのパスワードまで一緒に変更せず、該当連携だけを止められます。
運用開始前に、最低限次の情報を整理しておくと復旧しやすくなります。
- どのGitHub ActionsがどのWordPressユーザーを使うか
- そのApplication Passwordが何の連携用か
- 失効した場合にどのworkflowが止まるか
- 新しいApplication Passwordへ差し替えるSecretsはどれか
- 差し替え後にどのproduction QAで正常性を確認するか
Application Passwordの値自体を管理表へ書く必要はありません。必要なのは「用途」と「失効・復旧の経路」です。
安全なWordPress自動投稿のチェックリスト
- 通常ログイン用パスワードを自動化へ直接渡していない
- 外部REST APIアクセスはHTTPSを利用している
- Application Passwordを自動化単位で分けている
- 自動化ユーザーの権限を必要な操作範囲に合わせている
- 認証情報をGitHubの通常ファイルへ保存していない
- GitHub Actions Secretsから環境変数へ注入している
- ログへSecretsやAuthorization情報を意図的に出していない
- 401・403・REST成功・production QA失敗を別状態として記録する
- 不要になったApplication Passwordを個別に失効できる
- 認証情報更新後に公開URLまでQAする
まとめ
WordPress自動投稿の認証設計では、Application PasswordsとGitHub Actions Secretsを組み合わせるだけでなく、権限分離、ログ、失効、production QAまで一続きに考えることが重要です。
おすすめの基本形は、自動化専用WordPressユーザー → 用途別Application Password → GitHub Actions Secrets → REST API実行 → production QAです。この流れなら、認証情報をコードや記事へ埋め込まず、問題が起きた連携だけを止め、復旧後に本番状態まで確認できます。
AIBlogBaseでは、自動化そのものを増やすことより、失敗を検出して安全に戻せる運用を重視しています。WordPress側の見た目や記事導線も整えたい場合は、無料で使えるAIBlogBase Liteも確認してください。
