WordPressの権限を渡すときに確認すること

1. 肩書きではなく、任せる操作を書き出す

「制作会社だから管理者」「社員だから編集者」という決め方では、必要以上の権限を渡しがちです。まず、原稿の下書き、画像の登録、自分の記事の公開、他人の記事の修正、プラグイン更新を別の作業に分けます。公開する前に誰の確認が必要かも、同じ段階で決めておきます。

たとえば外部ライターへ月に数本依頼する場合、下書きまで任せて公開は運営者が行う方法があります。画像が必要なら、画像を別途受け取って運営者が登録するか、必要な権限を検討するかを選びます。「画像を一枚追加できない」という理由だけでサイト全体の管理権限へ広げないことがポイントです。

この記事は権限を渡す前の作業設計です。実際の権限変更は、ご自身が管理するサイトで、現在の担当者と合意してから行ってください。

2. 標準の権限を候補にし、実際の構成で確かめる

WordPressの標準では、寄稿者は自分の記事を下書きできますが公開はできず、投稿者は自分の記事を公開できます。編集者は他のユーザーの記事も管理でき、管理者はサイト管理の広い範囲を扱います。プラグインなどで変更できるため、役割の名前だけで操作範囲を保証しないでください。

参考: WordPress公式・Roles and Capabilities。確認日: 2026年9月10日。次の表は権限を自動決定する表ではなく、依頼内容を整理するための例です。

スマホでは表を横にスクロールできます。

3. アカウントと期限を台帳に残す

一つのログイン情報をチーム全員で共有すると、退任者だけを切り離しにくくなります。担当者ごとのアカウントを用意し、誰が使うものか分かる形で管理します。パスワードそのものは権限台帳へ書かず、安全な認証・共有手段を別に用意します。

• 担当者名と連絡先、運営側の承認者
• 作業対象のサイトと記事、許可する操作
• 割り当てた役割と、実際に確認した操作
• 利用開始日、終了予定日、見直し担当者
• 終了時に引き継ぐ原稿、画像、作業記録

記入例は「担当A／原稿3本の下書き／公開は運営者／納品確認後に権限を見直す」です。これは例で、自動的に期限が切れる設定ではありません。期限の日に誰が確認するかまで決めてください。WordPressのログインとサーバーのSSH・契約管理は別の権限なので、ひとまとめに渡さないようにします。

4. 「できる」と「できない」を両方テストする

検証環境でテスト用の下書きを使い、依頼した操作ができるか確認します。あわせて、公開権限が不要な担当者なら公開できないこと、管理操作が不要なら設定変更の画面へ進めないことも確かめます。本番の投稿を削除するような破壊的テストは行いません。

操作できなかったときは、画面名、対象、表示されたメッセージを記録します。すぐ管理者へ変更するのではなく、固定ページの編集なのか、画像登録なのかなど不足する作業を特定してください。細かな権限を調整する場合は、他の利用者にも影響する設定かを管理担当と確認します。

複製する環境にも公開・通知の対策が必要です。準備は検証環境の分離チェックで整理できます。

5. 納品後は原稿を確認してから権限を見直す

契約や担当が変わったら、残っている下書き、添付画像、公開済み記事の担当を確認します。ユーザーを削除する際には、投稿の扱いを選ぶ画面をよく確認し、必要な記事まで消さないでください。作業前のバックアップと、引き継ぐ利用者の有無も確認します。

外部ツールやアプリ用の認証を発行していた場合は、その接続も別に棚卸しします。ログイン用アカウントを整理したことだけで、すべての外部アクセスが終わったとは判断しません。最後に、運営者がログインできること、記事が残っていること、不要な権限が残っていないことを記録すれば、次の引き継ぎにも使えます。

役割ごとの権限の目安

WordPressには、標準で「管理者」「編集者」「投稿者」「寄稿者」「購読者」の権限があります。任せる作業に対して、必要より強い権限を渡さないことが基本です。

表は横にスクロールできます。

使っているプラグインによっては、権限の内容が変わることがあります。実際に渡す前に、テスト用のアカウントで操作を確かめます。

権限を渡すときの連絡文の例

文例：「記事の作成と公開をお願いするため、投稿者の権限でアカウントを作成しました。ログインURLは○○です。初回ログイン後にパスワードの変更をお願いします。作業期間は○月○日までを予定しており、終了後にアカウントを停止します。」

パスワードは、ログインURLやユーザー名とは別の方法で伝えると、どちらかが漏れたときの危険を減らせます。

作業が終わったあとの確認表

表は横にスクロールできます。