WordPressのユーザー権限を実務で使い分ける：管理者・編集者・投稿者の違い

WordPressのユーザー権限は、「ログインできる人」を増やすためだけの設定ではありません。誰が記事を公開できるか、他人の記事を直せるか、プラグインやテーマに触れるかを分けるための安全装置です。

結論から言うと、普段の記事制作では管理者を増やさず、編集者・投稿者・寄稿者を役割に合わせて使い分けるのが基本です。管理者はサイト全体の設定やプラグイン変更までできるため、記事を書くだけの人に渡すには権限が強すぎます。

この記事では、WordPress.org公式ドキュメントで確認できる標準ロールを前提に、管理画面・WP-CLI・REST APIでどう扱うかまで整理します。確認時点は2026年7月7日です。

• 管理者は、単一サイトの管理機能全体に触れる役割
• 編集者は、他人の記事も含めて公開・編集できる役割
• 投稿者は、自分の記事を公開・管理できる役割
• 寄稿者は、下書き作成までで公開はできない役割
• 購読者は、プロフィール管理など最小限の利用者向け

ここがポイント: 「役職の上下」ではなく、「その人に任せる作業に必要な権限だけ渡す」と考えると、選び方を間違えにくくなります。

WordPressのユーザー権限は「ロール」と「権限」でできている

WordPressでは、ユーザーごとにロールを割り当て、そのロールに複数の権限が含まれます。

公式ドキュメントでは、WordPressの標準ロールとして次の6種類が整理されています。

• 特権管理者: マルチサイトのネットワーク管理まで扱う
• 管理者: 単一サイトの管理機能全体にアクセスする
• 編集者: 他のユーザーの記事を含め、投稿や固定ページを管理する
• 投稿者: 自分の記事を公開・管理する
• 寄稿者: 自分の記事を書けるが公開はできない
• 購読者: 自分のプロフィールを管理する

ここで大事なのは、ロール名よりも中身です。たとえば「投稿者」は記事を公開できますが、他人の記事は管理できません。「編集者」は他人の記事も扱えるため、チーム運用ではかなり強い権限です。

権限は細かい操作名で判定される

WordPress内部では、publish_posts、edit_others_posts、manage_options、install_pluginsのような細かい権限で操作可否を見ています。

たとえば次のように考えると分かりやすいです。

• publish_posts: 投稿を公開できる
• edit_posts: 投稿を編集できる
• edit_others_posts: 他人の投稿を編集できる
• manage_options: サイト設定を変更できる
• install_plugins: プラグインを追加できる

ユーザー一覧で見えるのは「管理者」「編集者」などのロールですが、実際にはその裏側で細かい権限の組み合わせが動いています。

管理者・編集者・投稿者の違いを実務目線で見る

記事制作でよく迷うのは、管理者・編集者・投稿者の3つです。違いは「サイト設定まで任せるか」「他人の記事まで任せるか」「自分の記事だけでよいか」で判断します。

ロール	できることの中心	向いている人	注意点
管理者	サイト設定、テーマ、プラグイン、ユーザー管理、投稿管理	サイト運用責任者、制作会社、保守担当	権限が強いため、人数を絞る
編集者	他人の記事を含む投稿・固定ページの編集、公開、コメント管理	メディア編集長、記事チェック担当、公開担当	他人の記事も変更できるため、運用ルールが必要
投稿者	自分の記事の作成、編集、公開、メディアアップロード	社内ライター、寄稿者より信頼できる執筆者	自分の記事は公開できるので、事前チェックが必要な現場には強すぎる場合がある

管理者は「サイトを壊せる人」でもある

管理者は便利ですが、記事作成だけを任せる相手には向きません。単一サイトの管理者は、プラグインの追加、テーマ変更、ユーザー追加、一般設定の変更など、サイト全体に影響する操作ができます。

たとえば次のような作業を任せる人なら管理者が必要です。

• プラグインの追加や削除を行う
• テーマや外観設定を変更する
• 他のユーザーを追加・削除する
• サイトURL、パーマリンク、コメント設定などを変更する
• バックアップやセキュリティ系プラグインを管理する

逆に、記事を書くだけ、画像を入れるだけ、公開前チェックをするだけなら、管理者である必要はありません。

編集者は「記事全体の責任者」に向く

編集者は、投稿や固定ページを広く管理できます。自分の記事だけでなく、他人の記事も編集・公開できるため、複数人で記事を作るサイトでは実務的に使いやすいロールです。

具体的には、次のような担当に向いています。

• ライターが作った下書きを確認して公開する
• 公開済み記事の誤字や古い情報を修正する
• カテゴリーや記事構成を整える
• コメント承認を行う

ただし、編集者は記事コンテンツへの影響が大きい権限です。公開フローを分けたい場合は、「ライターは寄稿者または投稿者」「公開担当だけ編集者」のように役割を分けると管理しやすくなります。

投稿者は「自分の記事だけ任せる」ための権限

投稿者は、自分の記事を作成・編集・公開できます。他人の記事は管理できません。

社内の担当者が自分の担当記事だけを書く場合、投稿者は分かりやすい選択です。画像も扱えるため、通常の記事作成には十分です。

一方で、投稿者は自分の記事を公開できます。レビューなしで公開されると困るサイトでは、投稿者ではなく寄稿者を使うほうが安全です。

寄稿者・購読者・特権管理者も押さえておく

管理者・編集者・投稿者だけを見ていると、公開前チェックが必要な現場で権限を渡しすぎることがあります。

寄稿者はレビュー前提の執筆者に向く

寄稿者は、自分の記事を書けますが公開はできません。公開ボタンを押せないため、編集者や管理者が内容を確認してから公開する流れに向いています。

たとえば、外部ライターに下書きだけ作ってもらう場合は寄稿者が候補になります。公開権限を渡さずに済むため、誤公開のリスクを下げられます。

購読者は会員・閲覧者向けの最小権限

購読者は、基本的に自分のプロフィール管理が中心です。会員制サイト、コメント投稿、限定コンテンツの閲覧など、サイト側の設計と組み合わせて使われます。

通常のブログ運用では、記事制作メンバーに購読者を割り当ててもできることが少なすぎます。

特権管理者はマルチサイト用

特権管理者は、WordPressマルチサイトでネットワーク全体を扱うロールです。単一サイトだけを運用している場合、日常的に意識する場面は多くありません。

ただし、マルチサイトでは通常の管理者と特権管理者でできることが変わります。プラグインやテーマ、ネットワーク全体の設定を触る場合は、どのサイトの管理者なのか、ネットワーク全体の管理者なのかを分けて確認してください。

実務では「誰に何を任せるか」から選ぶ

ロール名から選ぶより、作業内容から逆算したほうが安全です。

よくある場面別に見ると、次のようになります。

• 制作会社が初期構築を行う: 管理者
• 保守担当がプラグイン更新を行う: 管理者
• 編集長が記事を確認して公開する: 編集者
• 社内担当者が自分の記事を公開する: 投稿者
• 外部ライターが下書きだけ作る: 寄稿者
• 会員がプロフィールを持つだけ: 購読者

特に注意したいのは、外部の人へ管理者を渡すケースです。短期の作業で管理者が必要な場合でも、作業後に権限を戻す、不要なアカウントを停止する、共有アカウントを使わない、といった確認が必要になります。

よくあるNG例と改善例

NG例は、権限を「とりあえず管理者」に寄せることです。

外部ライターA: 管理者
社内確認担当B: 管理者
制作会社C: 管理者

この状態では、誰でもプラグインや設定に触れる可能性があります。記事修正だけのつもりが、設定変更やユーザー追加までできてしまいます。

改善するなら、役割ごとに分けます。

外部ライターA: 寄稿者
社内確認担当B: 編集者
制作会社C: 管理者

この分け方なら、外部ライターは下書き作成まで、社内確認担当は公開判断、制作会社はサイト設定という形で責任範囲が見えます。

管理画面・WP-CLI・REST APIでの扱い方

WordPressのユーザー権限は、管理画面だけでなく、WP-CLIやREST APIでも扱えます。制作や運用の自動化では、ここを知っておくと作業が安定します。

管理画面で確認する

管理画面では、通常「ユーザー」から各ユーザーの権限グループを確認・変更します。新規ユーザーのデフォルト権限は、公式ドキュメント上では「設定」>「一般」から設定できるとされています。

確認するときは、次の3点を見ます。

• 新しく作るユーザーにどのロールが付くか
• 既存ユーザーに管理者が多すぎないか
• 退職者、外部委託終了者、使っていないアカウントが残っていないか

ここは地味ですが、サイト保守では重要です。プラグイン更新やテーマ変更より前に、誰が何をできる状態なのかを見ておくと、事故の原因を絞りやすくなります。

WP-CLIでユーザーを作る例

サーバー上でWP-CLIを使える環境なら、コマンドでユーザー作成とロール指定ができます。公式のwp user createでは、--role=<role>でadministrator、editor、author、contributor、subscriberなどを指定できます。

wp user create writer01 writer01@example.com --role=author

実行例としては、ユーザーIDが返り、パスワードが生成されます。

Success: Created user 3.
Password: ************

実務では、画面に出た初期パスワードをチャットやメールで平文共有しないでください。可能なら、本人にパスワード再設定メールを送る、パスワード管理ツールを使う、初回ログイン後に変更してもらう、といった運用にします。

--porcelainを使うと、作成されたユーザーIDだけを出力できます。シェルスクリプトで後続処理につなぐときに便利です。

USER_ID=$(wp user create editor01 editor01@example.com --role=editor --porcelain)
echo "$USER_ID"

REST APIではrolesを確認・指定する

WordPress REST APIのユーザーエンドポイントでは、ユーザーに割り当てられたロールをrolesとして扱います。公式リファレンスでは、rolesはユーザーに割り当てられたロールの配列として説明されています。

ユーザー作成の入力例は、概念としては次の形です。

{
  "username": "writer01",
  "email": "writer01@example.com",
  "password": "temporary-password",
  "roles": ["author"]
}

期待する出力の一部は、たとえば次のような形になります。

{
  "id": 12,
  "username": "writer01",
  "roles": ["author"]
}

REST APIでユーザーを作成・更新する場合は、認証が必要です。パスワードやアプリケーションパスワードをコードに直書きせず、環境変数やシークレット管理に分けてください。Gitにコミットする設定ファイルへ認証情報を置くのは避けます。

つまずきやすいポイント

ユーザー権限のトラブルは、画面に表示されるメニューの有無だけで判断すると見落としが出ます。ロール、権限、プラグイン追加権限、マルチサイト差分を分けて確認します。

「投稿できない」はロール不足かもしれない

寄稿者は記事を書けますが公開できません。公開ボタンがない、公開できない、レビュー待ちになるという場合は、まずロールを確認してください。

• 公開まで自分で行う: 投稿者以上
• 他人の記事も確認して公開する: 編集者以上
• 下書きだけ作る: 寄稿者

ただし、プラグインやカスタム投稿タイプによっては、標準ロールとは別の権限チェックが入ることがあります。標準投稿では問題ないのに独自の投稿タイプだけ編集できない場合は、テーマやプラグイン側の権限設定も確認します。

「プラグインを追加できない」は管理者でも環境差がある

単一サイトの管理者は、通常プラグイン追加やテーマ変更に関わる強い権限を持ちます。一方、マルチサイトでは、ネットワーク設定や特権管理者の権限が関係します。

また、レンタルサーバーや保守会社の運用方針で、ファイル編集やプラグイン追加が制限されていることもあります。WordPressのロールだけを見て「管理者なのにできない」と判断せず、マルチサイトか、サーバー側で制限されていないかを確認してください。

権限変更は「一時的」にしたつもりでも残りやすい

作業のために投稿者を管理者へ上げ、そのまま戻し忘れるケースがあります。これは小さな見落としに見えますが、管理者が増えるほど、設定変更やアカウント乗っ取り時の被害範囲が広がります。

運用では、次のようなチェックを定期的に行うと現実的です。

• 管理者アカウントの人数を確認する
• 外部担当者の作業終了後に権限を戻す
• 共有アカウントを使っていないか確認する
• 使っていないユーザーを削除または無効化する
• ユーザー削除時に記事の引き継ぎ先を確認する

代替手段：標準ロールで足りないとき

標準ロールだけで足りない場合は、いきなり管理者を増やす前に、権限管理プラグインやカスタムロールを検討します。

たとえば、「メディアはアップロードできるが公開はできない」「特定のカスタム投稿タイプだけ編集できる」「EC担当者には注文管理だけ任せたい」といった場面です。

選択肢は大きく3つあります。

• 標準ロールだけで運用ルールを作る
• 権限管理プラグインでロールを調整する
• 開発者がadd_role()やadd_cap()で独自ロールを追加する

初心者向けの実務では、まず標準ロールで足りるかを確認するのが安全です。独自ロールは便利ですが、後から「この人はなぜこの操作ができるのか」を追いにくくなることがあります。

プラグインで権限を変える場合も、変更前に現在のロール構成をメモし、テスト用ユーザーで画面表示と操作可否を確認してから本番ユーザーへ適用します。

最初に決めるべき実務ルール

WordPressのユーザー権限は、細かな知識よりも運用ルールのほうが効きます。最初に決めるべきなのは、「誰に管理者を渡すか」ではなく「管理者を渡さずに済む作業は何か」です。

小規模サイトなら、次の形から始めると判断しやすくなります。

• サイト設定・プラグイン・テーマを触る人だけ管理者
• 記事全体を確認して公開する人は編集者
• 自分の記事を直接公開してよい人は投稿者
• 公開前レビューが必要な人は寄稿者
• 閲覧や会員プロフィール中心なら購読者

最後に見るべき分岐点は、記事制作フローです。レビューなしで公開してよい人が多いなら投稿者を使えます。公開前確認を必ず挟むなら、寄稿者と編集者に分けるほうが安全です。ここを曖昧にしたまま管理者を増やすと、後から権限整理が難しくなります。

参照リンク

• WordPress.org Documentation: Roles and Capabilities
• WordPress REST API Handbook: Users
• WP-CLI Command: wp user create