WordPressマルチサイトのアプリケーションパスワード権限確認｜role表示だけで判断しない

WordPressマルチサイトをREST APIや外部ツールから更新する時、アプリケーションパスワードで認証できても、投稿、メディア、設定を同じように操作できるとは限りません。さらに、ユーザー情報に表示されるサイト内roleだけを見ると、ネットワーク側の権限や対象操作の実効権限を見誤ることがあります。

結論は、「認証できたか」「どのユーザーか」「対象サイトで何ができるか」「目的のRESTエンドポイントへ届くか」を分け、role表示だけで可否を決めないことです。最初はGETの`context=edit`で非破壊確認し、更新前に本文、revision、modified、hashを保存してから最小の変更へ進みます。

アプリケーションパスワードは権限を増やさない

WordPressのアプリケーションパスワードは、REST APIなどの外部ツールが、ユーザーの通常パスワードを共有せず認証するための資格情報です。資格情報は特定ユーザーへ結び付き、個別に取り消せます。ただし、新しい管理者権限を作る仕組みではありません。

REST APIで実行できる操作は、そのユーザーが対象サイトで持つ権限に従います。投稿を編集するには投稿編集の権限、公開するには公開権限、メディアをアップロードするにはアップロード権限、サイト設定を読む・変更するには設定管理の権限が必要です。

そのため「アプリケーションパスワードを作れた」「`/users/me`がHTTP 200だった」だけでは、記事公開まで可能とは判断できません。認証成功は入口であり、目的の操作ごとに確認します。

マルチサイトではネットワークと単体サイトを分ける

WordPressマルチサイトには、ネットワーク全体を管理するSuper Adminと、各サイト内のAdministrator、Editor、Author、Subscriberなどがあります。WordPress公式でも、Super Adminはネットワーク管理機能と全機能へアクセスでき、単体サイトのAdministratorとは扱いが異なると説明されています。

実務では、ユーザー情報に見えるrole、ネットワーク管理者であること、各サイトへの所属、カスタム権限、プラグインによる制限が重なります。ある画面で`subscriber`と見えても、それだけで目的のREST操作が不可能と断定せず、対象サイトのendpointを確認します。反対に`administrator`と見えても、WAFやREST制限、アプリケーションパスワード無効化によって操作できない場合があります。

確認対象	分かること	分からないこと
role表示	対象サイトに保存された役割	全endpointの実効結果
capabilities	応答に含まれる権限の手掛かり	WAFやREST制限の影響
HTTP 200	そのGET要求を処理できた	別endpointやPOSTの許可
401/403	認証または権限で停止した	原因の全容

最初は非破壊のGETで確認する

いきなり投稿本文や設定を更新せず、正しいサイトURLへGETを送り、段階ごとに結果を記録します。認証値をURL、ログ、スクリーンショットへ残さないでください。アプリケーションパスワードはHTTPS上のBasic Authenticationで使い、スクリプトの標準出力にも出さないようにします。

1. `/wp-json/wp/v2/users/me?context=edit`で認証ユーザーを確認する
2. `/wp-json/wp/v2/posts?context=edit&per_page=1`で投稿の編集contextを読めるか確認する
3. `/wp-json/wp/v2/media?context=edit&per_page=1`でメディアの編集contextを確認する
4. 設定操作が必要な場合だけ`/wp-json/wp/v2/settings?context=edit`を確認する
5. HTTP statusとWordPressのエラーcodeを操作別に記録する

GETの200は、その読み取り要求が通った証拠です。記事を公開できることまで保証しません。公開が必要なら`publish_posts`、メディアなら`upload_files`、設定なら`manage_options`など、目的に対応する権限と対象endpointの両方を確認します。結果が食い違う時は変更を止め、ネットワーク管理者、対象サイトの所属、REST制限を確認します。

401・403・404・200を分けて読む

結果	最初に見ること	やらないこと
401	ユーザー名、アプリケーションPW、HTTPS、対象サイトURL	古いログから別の認証値を推測する
403	必要capability、サイト所属、REST制限、WAF	権限を一律に管理者へ上げる
404	REST base、post type、プラグイン有効状態、URL	認証エラーと決めつける
200	返ったユーザー、対象サイト、context、データ内容	全操作が可能とみなす

`incorrect_password`などの401では、アプリケーションパスワードの空白処理、ユーザー名、発行したサイト、HTTPSを確認します。403では、認証自体は通っていても目的の操作が許可されていない可能性があります。404はendpointやpost typeが存在しない場合もあるため、権限だけを疑わないでください。

更新直前は本文と競合を保全する

権限確認が終わっても、すぐにPOSTしないでください。対象ID、raw本文、revision、modified時刻、内容のhashを保存します。実行直前にもう一度取得し、modifiedとhashが変わっていないことを確認します。ほかの担当者や自動化が同時に編集していれば、古い本文で上書きする危険があるため停止します。

• 対象サイトとREST base
• 投稿・固定ページ・商品などpost type
• 対象IDと公開URL
• raw本文、excerpt、featured media
• revision IDとmodified時刻
• 本文hash
• 変更するフィールドと変更しないフィールド

最初の変更は下書き、テスト記事、または影響範囲の小さいフィールドで行い、REST応答と公開画面を確認します。価格、決済、認証、ユーザー権限など別の領域を、記事更新のついでに変更しないことも重要です。

安全な確認フロー

1. 対象サイトと操作目的を一つに固定する
2. 正本からユーザー名とアプリケーションPWを読み、値は出力しない
3. `users/me?context=edit`で認証ユーザーを確認する
4. 目的のpost type、media、settingsへGETする
5. role、capability、HTTP status、エラーcodeをまとめて読む
6. 不一致があれば変更せず、ネットワークと単体サイトの所属を確認する
7. raw、revision、modified、hashを保存する
8. 直前競合を確認して最小変更を行う
9. REST応答、公開URL、PC・スマホ、関連機能を検証する

WordPress更新の切り分けが必要な場合はプラグイン更新に失敗した時の対処法、更新前の運用設計はプラグイン自動更新の判断基準も確認してください。ACSの製品はプラグイン一覧へまとめています。

よくある質問

まとめ

WordPressマルチサイトのアプリケーションパスワードでは、認証、ユーザー、サイト内role、ネットワーク権限、目的のREST endpointを分けて確認します。role表示だけでも、HTTP 200だけでも決めず、操作別の結果をそろえてください。更新前はraw、revision、modified、hashを保存し、直前競合を確認してから最小の変更へ進みます。

公式情報: Application Passwords / REST API Authentication / Roles and Capabilities / Users endpoint

実効権限を確認しても注文一覧が空の場合は、個別注文は取れるのに一覧が0件になる時の確認手順も確認してください。