WordPressへ外注ライターや制作会社を招待するとき、とりあえず「管理者」を渡していませんか。編集者との違いが分からない、共有IDのほうが楽、契約終了後もアカウントが残っているという状態は、誤操作と不正利用の両方を見つけにくくします。
安全な権限管理の基本は、役職名ではなく実際の作業に合わせて最小権限を選び、人ごとに個別アカウントを発行し、不要になった日に回収することです。WordPressの標準権限だけで足りるケースは多く、全員を管理者にする必要はありません。
管理者アカウントを複数人で共有しないでください。誰が設定を変えたか追えず、担当者が離れたときに一人だけのアクセスを止められません。パスワード変更のたびに全員へ再共有する運用も、漏えい範囲を広げます。
先に結論｜権限は「できるだけ小さく、必要な期間だけ」
- 依頼する作業を「記事」「固定ページ」「コメント」「設定」「更新」「ユーザー管理」に分ける
- 標準権限で、その作業に必要な最小の役割を選ぶ
- 一人につき一つの個別アカウントを発行する
- 初回ログイン、強固な固有パスワード、可能なら2段階認証を確認する
- 管理者が必要な作業は期間と終了条件を決める
- 契約終了前に投稿、メディア、連携、未完了作業を引き継ぐ
- アカウント停止または削除後に、投稿の帰属と主要機能を確認する
- 四半期ごとに利用者と権限を棚卸しする
最小権限は「不便にすること」ではありません。担当者が誤ってテーマ、プラグイン、設定、他人の記事を変更する範囲を小さくし、管理者だけが行う作業を明確にする運用です。
標準のユーザー権限は何が違うのか
| 権限 | 主にできること | 向いている担当 | 注意点 |
|---|---|---|---|
| 管理者 | 単一サイトの設定、テーマ、プラグイン、ユーザー、全コンテンツを管理 | サイト所有者、保守責任者 | サイト全体へ影響するため人数を絞る |
| 編集者 | 自分と他ユーザーの投稿・固定ページを公開、編集、削除し、コメントを管理 | 編集長、コンテンツ責任者 | 他人の記事も変更できる |
| 投稿者 | 自分の投稿を作成、公開、編集し、ファイルをアップロード | 自分の記事を公開する執筆者 | 自分の公開済み記事を変更できる |
| 寄稿者 | 自分の投稿を作成・編集するが公開はできない | 下書きだけ納品する外部ライター | 標準ではファイルをアップロードできない |
| 購読者 | ログインして自分のプロフィールを管理 | 会員閲覧などサイト独自用途 | 通常ブログでは作業権限として使わない |
WordPress公式のRoles and Capabilitiesでは、役割を上下関係ではなく、担当責任を表す操作権限の集合として説明しています。単一サイトには管理者から購読者までの標準役割があり、マルチサイトにはネットワーク全体を管理する特権管理者があります。
プラグインや独自コードが権限を追加・変更することもあります。そのため、表だけで決めて終わらず、テスト用アカウントで実際に見えるメニュー、投稿保存、公開、メディア追加を確認します。権限不足で403が出る場合は、WordPressの403 Forbidden確認順でWAFやサーバー側の拒否と分けてください。
作業内容から権限を選ぶ
| 依頼する作業 | 最初の候補 | 管理者が必要になり得る条件 |
|---|---|---|
| 下書きだけ作成 | 寄稿者 | 原則不要 |
| 自分の記事を画像付きで公開 | 投稿者 | 原則不要 |
| 全執筆者の記事を編集・公開 | 編集者 | 原則不要 |
| 固定ページとコメントを含む編集管理 | 編集者 | テーマ設定やプラグイン変更がある場合 |
| テーマ・プラグインの設定と更新 | 管理者 | 作業期間中のみ付与を検討 |
| ユーザー追加・権限変更 | 管理者 | 管理者以外では標準権限上できない |
| APIで記事を投稿 | 用途に合う専用ユーザー | APIに管理者操作が必要な場合だけ |
「制作会社だから管理者」「社員だから編集者」と所属だけで決めず、WordPress内の作業へ落とします。たとえば記事の装飾と公開だけなら編集者で足りることが多く、サイト設定まで触る保守作業だけ一時的に管理者が必要です。
不明な場合は小さい権限から始め、必要な操作だけ不足することを確認してから広げます。最初から管理者を付け、あとで狭める運用では、作業開始から見直しまでの間に不要な権限が残ります。
ユーザー追加前に決める6項目
- 利用者の氏名または識別できる担当名
- 本人だけが受信できるメールアドレス
- WordPressで行う具体的な作業
- 付与する権限と、その理由
- 利用開始日と終了予定日
- 契約終了時に投稿・メディア・連携を引き継ぐ担当者
会社共通のメールアドレスしか使えない場合でも、誰が利用責任者かを記録します。退職者のメールが削除されるとパスワード再設定を受け取れないため、終了前に連絡先と引き継ぎ先を確認します。
公開表示名とログイン名は役割が違います。ログイン名に個人の公開不要情報を詰め込まず、記事上で表示する名前はプロフィールの表示名を確認します。既存ユーザー名の再利用や、複数人が同じメール受信箱を使うことも避けます。
個別アカウントを安全に追加する手順
- 更新前に戻せるバックアップがあることを確認する
- 管理画面の「ユーザー→新規ユーザーを追加」を開く
- 利用者ごとに固有のユーザー名とメールアドレスを入力する
- 自動生成された強固なパスワードを使い、本人へ通知する
- 作業内容に合う最小の権限を選ぶ
- 追加後、本人が初回ログインできることを確認する
- 必要な画面だけ見え、不要な操作ができないことをテストする
- 2段階認証を利用する場合は登録と復旧手段を確認する
- 発行日、権限、終了予定日を管理表へ記録する
公式のUsers Add New screenでは、ユーザー名、固有のメールアドレス、パスワード、役割を指定して新しいユーザーを追加します。サイトの設定やプラグインにより画面項目が異なる場合は、現行の管理画面を優先します。
パスワードはチャットや共有文書へ平文で残さず、本人が管理するパスワードマネージャーなど安全な経路を使います。WordPress公式のHardening WordPressも、推測されにくい強固なパスワードと追加の2段階認証を案内しています。
共有の管理者アカウントが危険な理由
- 設定変更を誰が行ったか特定しにくい
- 一人だけ契約終了しても、その人だけを停止できない
- パスワード変更時に全利用者へ再配布が必要になる
- 2段階認証の端末や復旧コードが共有されやすい
- 誤操作時に本人へ状況を確認できない
- 外部サービスへ同じ認証情報を使い回す原因になる
共通アカウントを見つけたら、いきなり削除する前に現在の利用者と作業を確認します。個別アカウントを発行し、各自のログインと作業権限を確認した後で、共通アカウントを停止します。所有者不明の管理者が残っている場合は、バックアップと記録を保存し、不正利用の兆候も確認してください。
管理者権限は日常作業と分ける
管理者は、単一サイトのテーマ、プラグイン、設定、ユーザー、全コンテンツへ広くアクセスできます。侵害された場合は記事改ざんだけでなく、不正プラグインや新しい管理者の追加へつながるため、必要人数を絞ります。
| 場面 | 安全な運用 |
|---|---|
| 日常の記事編集 | 編集者・投稿者など専用アカウントを使う |
| 更新や設定変更 | 管理者でログインし、作業後にログアウトする |
| 制作会社の一時作業 | 個別管理者を期限付きで発行し、完了後に縮小または削除 |
| 緊急復旧 | 作業記録、変更対象、終了条件を残す |
| 所有者の予備 | 復旧可能な管理者を確保し、認証情報を安全に保管 |
管理者が一人だけで、その人のメールや2段階認証を失うと復旧が難しくなります。一方で予備管理者を大量に作るのも入口を増やします。サイト所有者が管理する復旧手段を決め、通常作業の管理者数は最小にします。ログインできない場合はWordPress管理画面に入れないときの確認順を使います。
外注・制作会社のアカウントは期限まで決める
| 時点 | 確認すること |
|---|---|
| 発行前 | 作業内容、権限、責任者、開始日、終了日 |
| 開始時 | 本人の個別ログイン、必要操作、不要操作、2FA |
| 作業中 | 変更記録、追加プラグイン、外部連携、未完了作業 |
| 完了前 | 投稿・メディア・設定・ライセンス・認証情報の引き継ぎ |
| 完了日 | 権限縮小、セッション終了、アカウント削除または停止 |
| 完了後 | 公開ページ、フォーム、更新、投稿帰属、不要連携の確認 |
「また依頼するかもしれない」という理由だけで管理者を残さないでください。再依頼時は新しい期間と作業範囲を決めて再発行できます。終了日を管理表とカレンダーへ登録し、担当者の記憶だけに頼らないことが大切です。
外注先が追加したプラグイン、外部ストレージ、計測、メール、CDNなどWordPress外の権限も確認します。WordPressアカウントだけ削除しても、サーバー、SFTP、ドメイン、Cloudflare、Googleサービスのアクセスが残る場合があります。定期作業全体はWordPress保守チェックリストへまとめてください。
ユーザーを削除する前に投稿を引き継ぐ
- 対象ユーザーの投稿、固定ページ、下書き、予約投稿を一覧にする
- メディア、コメント対応、フォーム、プラグイン設定への関与を確認する
- 外部連携とApplication Passwordを失効する
- 引き継ぎ先のユーザーを決める
- 戻せるバックアップを確認する
- ユーザー削除時に、投稿を引き継ぎ先へ帰属させる
- 記事URL、著者表示、画像、予約状態を確認する
- 主要機能と管理者一覧を再確認する
WordPress公式のUsers screenでは、ユーザー削除時に、そのユーザーの投稿とリンクをすべて削除するか、別ユーザーへ帰属させるかを選びます。
残す記事がある状態で「すべての投稿を削除」を選ばないでください。アカウントだけ消すつもりでも、担当者が作成した記事まで失うおそれがあります。先に投稿一覧を確認し、通常は引き継ぎ先へ帰属させてから削除します。
削除後は、著者アーカイブや構造化データの表示、予約投稿、メディアの参照、内部リンクを確認します。重要な変更前にはWordPressバックアップの取り方で、ファイルとデータベースの両方を戻せる状態にします。
外部アプリには通常パスワードを渡さない
投稿アプリ、連携サービス、スクリプトがWordPress REST APIへ接続するために、本人の通常パスワードを保存する運用は避けます。連携専用ユーザーを作り、用途に合う権限へ絞ったうえで、利用可能ならApplication Passwordを個別発行します。
WordPress公式のApplication Passwordsは、アプリごとに発行し、個別に失効できるAPI用の認証情報です。通常のパスワードとは別で、wp-login.phpから管理画面へログインする用途には使えません。
- 連携名に用途と発行先が分かる名前を付ける
- 連携専用ユーザーの権限を最小にする
- HTTPSで接続する
- 発行した値を画面や公開文書へ載せない
- 契約終了・連携停止時に該当するものだけ失効する
- 最終利用と不要な認証情報を定期確認する
独自権限・会員プラグインはテスト環境で確認する
標準権限で足りない場合、権限編集プラグインや会員プラグインで独自役割を作る方法があります。ただし、投稿、固定ページ、メディア、フォーム、EC、個人情報など複数機能の権限が絡み、更新で挙動が変わる可能性があります。
- 必要な操作と禁止する操作を先に文章化する
- 既存の標準権限で代替できないか確認する
- テスト環境で対象ユーザーとしてログインする
- 画面表示だけでなく保存・公開・削除を確認する
- REST APIやフォームの権限も確認する
- プラグイン停止時に役割がどうなるか確認する
- 戻し方と担当者を記録する
本番で直接権限を編集せず、重要な変更は検証環境で試します。独自権限を付けたユーザーが突然メニューを失ったり、逆に不要な操作が見えたりしないか、更新後にも再テストしてください。
四半期ごとにユーザーを棚卸しする
- 本人と所属・契約先を確認できるか
- 現在もWordPressへ入る必要があるか
- 権限は現在の作業に対して大きすぎないか
- 管理者になっている理由を説明できるか
- 共有アカウントや所有者不明アカウントがないか
- 退職者・契約終了者・休眠担当者が残っていないか
- メールアドレスと復旧手段が現在も有効か
- 2段階認証やパスキーの登録状況を確認したか
- Application Passwordと外部連携が必要か
- 投稿・固定ページの引き継ぎ先が決まっているか
| 記録項目 | 例 |
|---|---|
| 利用者 | 氏名、会社、責任者 |
| 用途 | 記事下書き、公開承認、保守更新 |
| 権限 | 寄稿者、編集者、管理者 |
| 発行・終了日 | 開始日、見直し日、契約終了日 |
| 外部連携 | API、SFTP、サーバー、CDN、計測 |
| 対応 | 継続、縮小、停止、削除、要確認 |
一覧の人数だけで判断せず、利用目的と権限の理由まで記録します。「不明」は継続理由ではありません。担当者へ確認し、確認期限を過ぎても所有者と用途が分からなければ、バックアップと影響確認後に停止を検討します。
身に覚えのない管理者を見つけたとき
- アカウント名、メール、権限、発見時刻を保存する
- 制作会社、保守担当、プラグインの正規追加かを確認する
- 他の管理者、最近の投稿、プラグイン、テーマ、設定変更も確認する
- 安全な端末から正規管理者の認証情報を変更する
- サーバー、SFTP、データベース、ドメイン、CDNの権限も確認する
- 改ざんや不正ファイルがあれば、アカウント削除だけで終わらせない
- 証拠とバックアップを保全し、侵害対応へ切り替える
不明な管理者がいるだけで侵害と断定はできませんが、攻撃者が作ったアカウントなら削除後に別の侵入経路から再作成される可能性があります。記事改ざん、不審なプラグイン、外部転送、未知のファイルがある場合は、WordPressが乗っ取られたときの復旧手順で隔離・証拠保全・再侵入防止まで行います。
平常時からの基本対策はWordPressセキュリティ設定の基本にまとめています。権限管理だけでなく、更新、バックアップ、ログイン保護、不要プラグインの整理も合わせて確認してください。
よくある質問
記事を書くだけの外注ライターには何を付けますか？
下書きだけを納品し、公開は社内編集者が行うなら寄稿者が候補です。画像アップロードも本人が行うなら、標準の寄稿者では足りないため、投稿者にするか、画像だけ別経路で受け取るかを決めます。自分の記事を公開する必要がない人へ、管理者や編集者を付ける必要はありません。
編集者はプラグインを更新できますか？
WordPress標準の編集者は、プラグインのインストールや更新を行えません。記事・固定ページ・コメントの編集管理が中心です。プラグイン変更が必要な作業だけ管理者が対応するか、期限付きの個別管理者を発行します。
ユーザーを削除すると記事も消えますか？
削除画面で選ぶ内容によります。対象ユーザーの投稿をすべて削除する選択肢と、別ユーザーへ帰属させる選択肢があります。残す記事があるなら、投稿一覧と引き継ぎ先を確認し、帰属変更を選んでください。
管理者は何人までなら安全ですか？
一律の人数では決められません。サイト所有者、保守責任者、復旧責任者など、管理者でなければできない現在の作業がある人だけに絞ります。人数よりも、各管理者の必要理由、個別アカウント、認証保護、終了日、定期棚卸しが重要です。
まとめ｜権限表より発行から回収までの運用が重要
WordPressのユーザー権限は、管理者、編集者、投稿者、寄稿者、購読者の名前を覚えるだけでは安全になりません。依頼する操作を先に決め、必要な最小権限を個別アカウントへ付け、期間と引き継ぎ先を記録します。
まず現在のユーザー一覧を開き、所有者不明、共有、退職者、過剰な管理者がないか確認してください。削除前には投稿と外部連携を引き継ぎ、完了後は公開ページと主要機能を確認します。権限を小さくすることに加え、不要になったアクセスを予定どおり回収できて、ユーザー管理は完了です。