WordPressを外部アプリ、スクリプト、投稿ツールから操作するとき、認証情報が必要になります。この用途でWordPress本体に用意されているのがApplication Passwordです。名前に「パスワード」とありますが、普段の管理画面ログイン用パスワードとは役割が異なります。
WORK EDITとしての結論
Application Passwordは、WordPressユーザーにひも付く、プログラム接続用の個別に失効できる認証情報です。主パスワードを外部ツールへ渡さずに済む点が利点ですが、発行しただけで操作権限が小さくなるわけではありません。専用ユーザーの権限を先に絞り、接続先ごとに別のApplication Passwordを発行し、HTTPS、秘密情報管理、定期確認、不要時の失効を一体で運用します。
Application Passwordでできること
WordPress公式資料では、Application Passwordはモバイルアプリ、外部連携、スクリプトなどのプログラムアクセスに使う、アプリ単位で失効可能な認証情報と説明されています。WordPress 5.6で導入されました。REST APIや、有効な場合のXML-RPCで利用できます。出典: Application Passwords
代表的な用途は、外部サービスからの投稿作成、画像アップロード、保守スクリプトからの情報取得です。実行できる操作は、接続先のAPIが提供する機能と、ひも付いたWordPressユーザーに許された権限の組み合わせで決まります。REST APIでも操作に応じたcapabilityが必要です。出典: Authentication
Application Passwordではできないこと
Application Passwordはwp-login.phpから管理画面へ入るためのパスワードではありません。また、管理画面ログインの主パスワードや二要素認証を置き換えるものでもありません。「Application Passwordを発行したからユーザー権限の設計は不要」という意味でもありません。
認証は「どのユーザーとして接続したか」を確かめる仕組みです。認可は「そのユーザーが何をしてよいか」を決める仕組みです。Application Passwordは主に認証を担うため、投稿作成だけの連携に広い管理者権限を持つユーザーを使わないことが重要です。
発行時に何が起きるか
管理画面のユーザープロフィールにあるApplication Passwords欄で、用途が分かる名前を付けて生成します。公式資料によると、生成値は作成時に一度だけ表示され、WordPress側ではハッシュ化して保存されます。後から同じ値を再表示するのではなく、失った場合は新しく発行し直します。
既存のApplication Passwordは名前で区別でき、最終使用時刻や最終使用IPなどの情報を確認し、個別に失効できます。REST APIにも作成、取得、更新、削除のエンドポイントが用意されています。出典: Application Passwords REST API Reference
REST APIではHTTPSで使う
Application Passwordは通常、WordPressユーザー名との組み合わせをHTTP Basic Authenticationで送ります。Basic認証の情報は暗号化されていない通信では傍受され得るため、WordPress公式資料はHTTPSの利用を求めています。2026年7月17日時点の公式管理ガイドでも、Application Passwordは既定でHTTPSのリクエスト時に利用可能と案内されています。環境やフィルター設定によって無効化されている場合があります。
接続テストでは、資格情報そのものを画面共有、ログ、コマンド履歴へ残さない方法を選びます。認証ヘッダーを含む完全なデバッグ出力も保存対象を確認してから使います。
安全な発行・運用の手順
以下は公式仕様を踏まえたWORK EDITの運用案です。
- 自動処理専用のWordPressユーザーを作る
- 実行するAPIに必要な権限だけを与える
- 連携先がHTTPSであることを確認する
- 「記事下書き連携」「レポート読取」など用途が分かる名前で個別発行する
- 表示された値を秘密情報管理へ一度だけ登録する
- ステージングで読み取りから試し、次に下書き1件を作成する
- 最終使用情報と利用中の連携を定期的に照合する
- 担当変更、連携終了、漏えい疑いがあれば該当するものを失効する
同じ値を複数サービスで使い回すと、漏えい元を特定しにくく、1サービスだけ止める利点も失われます。名前は後から人が見て接続先と目的を判断できる粒度にします。
認証できないときの確認順
まず、サイトがHTTPSとして正しく認識されているか、対象ユーザーと生成値の組み合わせが正しいか、機能がフィルターやセキュリティプラグインで無効化されていないかを確認します。次に、クライアントがAuthorizationヘッダーを送っているか、Webサーバーやプロキシがそのヘッダーを除去していないかを調べます。WordPress公式のREST API FAQも、構成によって認証ヘッダーがサーバーで失われる場合を挙げています。出典: REST API Frequently Asked Questions
401と403を同じ問題として扱わず、認証が成立していないのか、認証後に権限が不足しているのかを分けて確認します。
向く人
- 外部ツールやスクリプトからWordPress APIへ接続したい人
- 連携ごとに認証情報を分け、失効まで管理できる人
- 専用ユーザーと最小権限を設計できる運用者
向かない人
- 人がブラウザから管理画面へログインする用途を探している人
- HTTP接続しか用意できない人
- 認証情報をコードや共有文書へ直接書く前提の人
- 管理者ユーザーで全連携をまとめ、利用状況を確認しない人
最大の注意点
最大の注意点は、Application Passwordを「権限が弱い安全なパスワード」と誤解しないことです。個別失効できることと、接続後に許される操作範囲は別です。ひも付くユーザーの権限が広ければ、資格情報を得た接続元もその範囲のAPI操作を試みられます。専用ユーザーの権限設計が先です。
公式情報と分析の区別
公式情報として確認したのは、導入バージョン、API用途、管理画面ログインには使えないこと、作成時のみ表示されること、ハッシュ保存、個別失効、利用情報、HTTPS、REST APIの管理エンドポイントです。用途別の命名規則、発行から失効までの8段階、ステージングで読み取りから始める順序はWORK EDITの分析です。
未確認事項
- 対象サイトでApplication Passwordが有効か
- セキュリティプラグインや独自コードによる利用制限
- Webサーバー、CDN、プロキシでのAuthorizationヘッダーの扱い
- 接続予定ツールの秘密情報の保存方式、閲覧権限、削除方法
- 対象APIに必要なWordPress capability
運用全体の安全策はWordPress自動化で最初に用意すべき安全対策で確認してください。AIへ任せる範囲と公開承認者の決め方はAIを使ってWordPressサイトを作る前に決めることで整理しています。
