目次
WordPressへログインできる人を把握していても、外部ツールがどのユーザーとして投稿や画像追加を行っているかまで説明できますか。担当者が退職した後も、以前発行した連携用の認証情報が残っていることがあります。認証を強くする対策と、許可する操作を減らす対策は、両方が必要です。
この記事は、2026年10月18日にWordPress公式資料を確認した権限管理の実務ガイドです。人が使うアカウントと、APIへ接続するツールの認証情報を分けて点検します。2段階認証プラグインのインストール手順ではなく、役割の選び方、外部連携の分離、終了した接続の失効までを扱います。
スポンサーリンク
認証の成功と操作の許可は別の確認
認証は誰として接続するかを確認し、認可はその相手に何を許すかを決めます。WordPressのREST API公式資料も、認証した利用者に操作に必要な権限があることを求めています。ログインやAPI接続に成功したという結果だけでは、付与した権限が適切かは分かりません。出典：WordPress公式：REST APIの認証。
たとえば外部ツールに記事の下書き作成だけを任せたいのに、サイト設定やプラグインの変更までできるアカウントを渡していたら、認証方式を変えても権限は広いままです。対策の出発点は、「何をしてよいか」を業務の言葉で具体化することです。
ユーザー一覧を人の名簿だけにしない
本サイトでは、利用者の一覧に、所有者、担当業務、必要な操作、確認日、終了条件を加えることを提案します。人に紐付くアカウントと、投稿連携や保守用のアカウントを区別し、表示名だけで誰の管理下にあるかを判断しないようにします。
制作会社が作った共有管理者を、そのまま複数人で使い続けていないかも確認してください。誰が操作したかを説明しにくくなり、契約が終わるたびに接続先全体を見直す負担が増えます。個別の所有者と用途を決めることは、事故の追跡だけでなく通常の引き継ぎにも役立ちます。
- 人の利用：氏名または担当、役割、連絡先、契約や業務の終了時期を確認する。
- 外部連携：ツール名、接続するユーザー、必要な機能、認証情報の保管先を記録する。
- 緊急用：保管責任者、利用する条件、利用後の見直し方法を決める。
- 不明なもの：すぐ削除する前に所有者と利用状況を調べ、未確認として期限を付ける。
スポンサーリンク
肩書きより必要な機能で役割を選ぶ
標準の役割では、編集者は他の利用者を含む投稿の管理、投稿者は自分の投稿の公開、寄稿者は自分の投稿の執筆が中心です。寄稿者には標準で公開権限がなく、画像アップロードも許可されていません。追加機能で権限が変わる場合があるため、実環境で確認します。出典：WordPress公式：Roles and Capabilities。
「記事担当だから投稿者」と機械的に決めず、公開を誰が承認するか、画像は誰が用意するか、他人の記事を直す必要があるかを分けます。下書きだけを作る人へ画像追加も認めたい場合、標準の役割だけでは要件と一致しないことがあります。
その場合も、エラーを解消するため管理者へ格上げするのではなく、必要な機能に対応する権限を調査します。カスタムの役割を使うなら、追加した権限と理由を記録し、テーマやプラグインを変えた後にも確認してください。細かく分けた結果、管理できない役割が増えすぎないことも大切です。
アプリケーションパスワードの役割を理解する
WordPressのアプリケーションパスワードは、特定のユーザーに紐付くAPI接続用の認証情報です。通常のログインパスワードを外部ツールへ渡さずに利用でき、個別に取り消せます。作成時に一度だけ表示され、ブラウザーでwp-adminへログインするためのものではありません。出典：WordPress公式：Application Passwords。
重要なのは、連携用の名前を付けただけで「投稿だけ」「読み取りだけ」といった操作制限が自動で付くと考えないことです。認証先のユーザーが持つ権限と、API側の権限判定を確認します。複数の用途を分けたいなら、接続するユーザーや、連携側が許可する操作の境界も設計対象になります。
本サイトの提案は、投稿を作る連携、状況を読む連携、保守で使う連携を、管理者の一つの認証情報にまとめない方法です。用途別に必要な操作を定義し、その操作に合ったアカウントと連携設定で接続します。外部サービス独自のOAuthやプラグインを使う場合は、その方式の許可範囲と失効方法を確認してください。
スポンサーリンク
発行する前に連携の終了まで決めておく
発行時は「自動化用」のような曖昧な名前を避け、用途と管理者が分かる名前にします。公式資料はアプリごとの作成、不要になった認証情報の失効、漏えいが疑われる場合などの交換を案内しています。プロフィールでは名前や最終利用などの利用情報を確認できます。出典：WordPress公式：アプリケーションパスワードの管理。
記録するのは秘密の文字列ではなく、認証情報の識別、所有者、保存先の管理責任、交換方法です。秘密は利用するサービスが認めた保管先へ登録し、記事本文、スクリーンショット、一般の作業チケットへ貼り付けません。発行した人が異動しても、残った担当者が失効を判断できる資料にします。
最終利用時刻が古いという理由だけで不要と決めるのも避けます。月次処理や障害時だけ使う接続かもしれません。所有者に用途を確認し、停止する場合は影響を見ながら終了します。反対に、最近使われているから正当な接続だとも限りません。記録は判断材料であり、所有者の確認の代わりではありません。
HTTPSと2段階認証を違う境界として扱う
公式資料は、アプリケーションパスワードを使う通信でHTTPSを求めています。Base64で表した認証情報は暗号化された秘密保管の仕組みではありません。外部へ接続するときは、正しいサイトを宛先にして証明書の検証を維持します。出典：WordPress公式：アプリケーションパスワードの利用条件。
人がブラウザーでログインする際の2段階認証は重要ですが、外部ツールが同じ確認画面を通るとは限りません。人向けのログイン保護を設定した後にも、API用の認証方式を別に点検します。利用する認証プラグインがAPIをどう扱うかは、その提供元の仕様で確かめてください。
既存の導入手順は、関連記事のWordPressのTwo Factorでログイン画面に2段階認証を導入するで扱っています。ここで追加するのは、その対策だけで外部連携や権限の問題も解決したと判断しないための確認です。
許可される操作と拒否される操作を検証する
説明用に、外部ツールで画像を追加できない場合を考えます。必要なのが画像アップロードだけなら、プラグイン管理やユーザー変更の権限まで付ける理由はありません。逆に、公開の承認を別の担当に残す要件なら、画像追加を認めることと公開を認めることを分離して設計し、実際のAPIで確かめます。
権限を狭めた後は、正規の作業が成功することに加え、不要な操作が拒否されることを確認します。以下は検証環境で行う試験の案です。試験用の投稿と画像を使い、実在する顧客の記事を削除するような試験は避けてください。
- 想定した利用者として認証されていることを確認する。
- 必要な下書きの作成、編集、画像追加などが要件どおり動くことを確認する。
- 公開を許可していない利用者では、公開が拒否されることを確認する。
- 他人の投稿や管理設定など、対象外の操作が実行できないことを確認する。
- 連携を失効した後は、以前の認証情報では接続できなくなることを確認する。
拒否されたときは、ユーザーの役割だけでなく、対象の投稿の所有者、APIの経路、プラグイン固有の権限判定も調べます。画面のメニューが見えないことだけでは操作を制限した証明にならないため、必要なAPIについても結果を確かめます。
退職や契約終了では接続先を追って止める
担当者の退職時には、人のログイン、外部連携の認証情報、保存先のアクセス権を別の項目で扱います。通常のパスワードを変えたので、すべてのAPI接続も止まったはずだとは推測しません。利用している方式ごとに明示的な失効と確認を行います。
すぐにユーザーを削除すると、投稿の所有や連携の依存関係を見失う場合があります。必要な公開記事の引き継ぎ、接続先の交換、失効後の検証を決めた上で処理します。削除や再割り当ての選択肢は管理画面で内容を確かめ、既存記事を意図せず消さないようにします。
漏えいが疑われる場合は、単なる定期交換とは異なります。速やかな失効に加えて、その接続で何を実行できたか、実際に何が行われたかを確認する必要があります。新しい認証情報を登録する前に、保存先や管理端末の安全性も確認し、同じ経路へ再び秘密を置かないようにします。
スポンサーリンク
権限の棚卸しを変更の手順に組み込む
本サイトでは、新しいツールの接続、委託契約の終了、担当の変更、権限に関わるプラグインの追加を、見直しのきっかけにすることを提案します。定期点検だけを待たず、業務が変わった時に権限も変えることで、不要な接続が残る期間を短くできます。
棚卸しの完了条件は、管理者が何人かを数えることだけではありません。誰または何が、どの用途で、何をでき、いつ止められるかを説明できることです。人とツールの両方に所有者を付け、必要な操作が成功し、不要な操作が拒否される状態を維持してください。
