Application Passwordが別のWordPressユーザーに属している
認証情報がクライアントの想定とは異なるWordPressユーザーに属しています。
秘密情報を表示せず、対象プロフィールのApplication Password欄を確認します。
考えられる原因
- 認証情報がクライアントの想定とは異なるWordPressユーザーに属しています。
- 似た名前の認証情報が複数あり、所有者と実際の使用先が不明確です。
- アシスタントが専用の制限付きIDではなく、人間の管理者アカウントを使用しています。
- 表示名はラベルであり、作成元のページやワークフローを一意に示すとは限りません。
- クライアントがApplication Passwordに対応しないWordPressユーザー名を送信しています。
診断手順
- 秘密情報を表示せず、対象プロフィールのApplication Password欄を確認します。
- 現在の管理者が所有者だと決めつけず、候補となる全ユーザーを確認します。
- クライアントが送るユーザー名がApplication Passwordの所有者と一致するか確認します。
- 最小の認証済みID確認で、リクエストが表すWordPressユーザーを特定します。
- 名前、作成日、最終使用日時、最終IPを観測したワークフローと照合します。
- 各アシスタント、プラグイン、コネクターを一つのユーザーと一つの認証情報に対応付けます。
最小限の修正を適用する
- 人間の管理者を再利用せず、専用のWordPress IDを作成します。
- 専用IDと一つの連携目的に対して名前付きApplication Passwordを一つ作成します。
- 正確なWordPressユーザー名と現在のApplication Passwordを別々に設定します。
- 未使用または不要と確認できた認証情報を取り消します。
- 誰が認証情報を作成、ローテーション、再利用、取り消すかと各トリガーを記録します。
結果を検証する
- 認証済みリクエストが意図した専用WordPressユーザーに対応します。
- 承認された限定的な読み取りが再現可能な応答で成功します。
- 意図的に禁止した書き込みは引き続き拒否されます。
- 取り消し後、同じ認証情報では認証できません。
避けるべき対応
- 接続テストを通す目的だけで管理者権限を付与しないでください。
- Application Password、Authorizationヘッダー、トークン、Cookieをプロンプト、チケット、ログ、画像に含めないでください。
- 所有者、目的、最終使用を記録する前に未知の認証情報をすべて削除しないでください。
- 認証成功と、すべてのWordPress操作の許可を混同しないでください。
- 別の承認済みワークフロー、staging、ロールバックなしに制限付きIDからFull Powerへ移行しないでください。
関連ガイド
- AIアシスタントが使用するWordPressユーザーを特定する方法
- WordPressサイトのAI認証情報を監査する方法
- WordPressのApplication Passwordで401 Unauthorizedが返る
- WAPのApplication Passwordが持つ権限
- AIアシスタントがWordPress管理者アカウントを使うべきではない理由
情報源と検証
このページは、以下の一次情報源に基づいて確認されています。 情報源の最終確認日: .
- Application Passwords · WordPress Developer Resources
- Application Passwords REST API Reference · WordPress Developer Resources
- wp_authenticate_application_password() · WordPress Developer Resources
- Roles and Capabilities · WordPress Developer Resources