WordPressユーザーの「権限グループ」と「権限」徹底解説ガイド

管理者WordPressユーザーの権限グループと権限の機能を使い、サイト上で他のユーザーができること/できないことを管理できます。投稿の作成/編集、新たなページの作成、コメントの管理、プラグインのインストール、新たなユーザーの追加などのユーザーのアクションを管理可能です。

ユーザーの権限グループと権限を理解することは、どのようなWordPressサイトを管理する上でも重要です。例えば、クライアント向けのサイトを構築している場合、勝手にインストールされたテーマを変更したり、編集したりしてしまうのを避けたいものです。同様に、複数の著者のいるブログで勝手にプラグインをインストールまたは削除されてしまっては困るでしょう。

WordPressのユーザー権限を賢く管理することで、ワークフローを整理し、サイトの安全性を維持し、サイト全体を包括的に管理することができます。

この詳細ガイドでは、WordPressユーザーの権限グループ、利用できる様々な権限、既存のユーザー権限の編集方法、マルチサイトでのユーザーの管理方法、新たな権限を付与した新しい権限グループの作成方法などをご紹介します。

ご興味は湧いてきたでしょうか？早速詳しく見ていきましょう。

WordPressユーザーの「権限グループ」と「権限」とは？

ユーザーの「権限グループ」と「権限」はWordPressのユーザーアクセス管理において必要不可欠なものです。WordPressユーザーの「権限グループ」について理解するには、まず「権限」について知る必要があります。

WordPressではユーザーが実行できる一つ一つのアクションを権限と呼びます。WordPress内で利用できる権限とコード上の表記の例をいくつかご紹介します。

• 投稿を読む（read）
• 投稿を書く、編集する（edit_posts）
• 投稿を公開する（publish_posts）
• プラグインをインストールする（install_plugins）
• テーマを削除する（delete_themes）
• ユーザーを作成する（create_users）
• コメントを管理する（moderate_comments）

ほとんどの権限は、その名称から内容が分かります。WordPressコアには70以上の権限がハードコードされています。

権限グループとは、特定のユーザーに割り当てられる複数の権限の総称です。全てのWordPressユーザーに権限グループを割り当てる必要があります。各ユーザーは割り当てられた権限グループで許可されたアクションしか実行できません。

上記の図では、Role 1のユーザーは投稿を読むことができますが、投稿を編集することはできません。Role 2のユーザーは投稿を読むことも編集することもできますが、投稿の公開はできません。Role 3のユーザーは投稿を読むこと、編集すること、公開することはできますが、削除することはできませんが、Role 4のユーザーは投稿を削除することもできます。

WordPressではネイティブな権限を利用しデフォルトの権限グループを定義しています。例えば、管理者、編集者には「publish_pages」（ページの公開）の権限が付与され、購読者、寄稿者には付与されません。

全てのWordPressユーザーは最低限、ユーザー名、パスワード、メールアドレス、権限グループを持ちます。

WordPressでは、権限グループに基づいた全ての権限がデータベースに保存されます（連番付きで、wp_user_rolesオプション内、wp_optionsテーブルの中）。WP_Rolesというコアクラスはデータベース内でどのように権限グループと権限を保存するかを定義するのに使われます。

WP_Rolesクラス

WordPressではユーザーロールAPIを使って権限グループや権限を実装しており、その大半はWP_Rolesコアクラスに基づいています。そのソースはwp-includes/class-wp-roles.phpファイルで見ることができます。

データベースを見ると、権限グループは権限グループ名が定義された配列の中に記載されていることが分かります。Rolenameキーは nameキーの値として権限グループ名を保存し、全ての権限は capabilityキーの値として別の配列で保存されます。

array (
     'rolename' => array (
         'name' => 'rolename',
         'capabilities' => array()
     )
)

WP_Rolesクラスは多くのメソッドを定義します。これをコード内の好きなところで呼び出して、ユーザーロールAPIを利用することができます。

補足情報：WordPressにはもう一つのコアクラスWP_Role（「Role」が単数形）も存在します。ユーザーロールAPIを拡張するのに利用します。

wp_user_rolesキーの値をアンシリアライズすると次のようになります。

array (
  'administrator' => 
  array (
    'name' => 'Administrator',
    'capabilities' => 
    array (
      'switch_themes' => true,
      'edit_themes' => true,
      'activate_plugins' => true,
      // [...rest of the lines cut off for brevity...]
    ),
  ),
  'editor' => 
  array (
    'name' => 'Editor',
    'capabilities' => 
    array (
      'moderate_comments' => true,
      'manage_categories' => true,
      'manage_links' => true,
      // [...rest of the lines cut off for brevity...]
    ),
  ),
  'author' => 
  array (
    'name' => 'Author',
    'capabilities' => 
    array (
      'upload_files' => true,
      'edit_posts' => true,
      'edit_published_posts' => true,
      // [...rest of the lines cut off for brevity...]
    ),
  ),
  'contributor' => 
  array (
    'name' => 'Contributor',
    'capabilities' => 
    array (
      'edit_posts' => true,
      'read' => true,
      // [...rest of the lines cut off for brevity...]
    ),
  ),
  'subscriber' => 
  array (
    'name' => 'Subscriber',
    'capabilities' => 
    array (
      'read' => true,
      'level_0' => true,
    ),
  ),
)

すべての権限グループに権限グループ名が割り当てられ、一連の権限が付与された多次元配列です。同様に、WordPressではユーザー毎の権限はwp_usermetaテーブルのwp_capabilitiesメタキーに保存されます。

補足情報：設定によってwp_という接頭辞が異なる場合があります。サイトの wp-config.phpファイルのグローバルプレフィックス$table_prefixの値によって異なります。

権限グループと権限の一覧表

WordPress Codexにはあまり分かりやすいものではありませんが、シンプルな権限と権限グループの一覧が掲載されています。WordPressのシングルサイト、マルチサイトそれぞれのデフォルトの権限グループで利用できるアクションがまとまっています。権限を決まった数で区切ることで、レベルの高い権限とレベルの低い権限が分かりやすいようになっています。

より分かりやすいWordPressの権限グループと権限の一覧が見たいという場合は Exygyによる一目で分かる一覧をご覧ください。

グーテンベルクの再利用ブロックに関連する機能

WordPressのグーテンベルクブロックエディタに再利用ブロックと呼ばれる素晴らしい機能が導入されました。ブロック全体（または複数のブロック）をテンプレートとして保存し、サイトの他の部分で使用することができます。

それに伴い、再利用ブロックに関連する次の新機能も導入されました。

• 再利用ブロックの作成
• 再利用ブロックの編集
• 再利用ブロックの閲覧
• 再利用ブロックの削除

上記の機能の仕組みは投稿関連の機能と似ています。管理者と編集者は、再利用ブロック関連のすべての機能にアクセスできますが、作成者は自分で作成した再利用ブロックしか編集/削除できません。寄稿者は、再利用ブロックを閲覧することしかできません。

特別な権限：ファイルチェックなしのアップロード

ファイルチェックなしのアップロードはデフォルトでは管理者や特権管理者を含めどの権限グループにも付与されていない権限です。この権限が付与されたユーザーはWordPressでサポートしている形式だけでなく、どのような拡張子のファイルでもアップロードすることができます（SVGやPSDなど）。

補足情報：wp_get_mime_types()関数を利用すると、WordPressでサポートしているメディアタイプとファイル拡張子の一覧を確認できます。

この権限を有効にするには、wp-config.phpファイルの下の方に次のコードスニペットを追加する必要があります。「編集が必要な場所はここまでです」という行の直前にコードを追加します。

define( 'ALLOW_UNFILTERED_UPLOADS', true );

この行を挿入すると、WordPressのシングルサイトの全ての権限グループにファイルチェックなしのアップロードの権限を付与できるようになります。しかし、マルチサイトの場合、この権限を付与できるのは特権管理者のみです。

例えば、unfiltered_uploadの権限を編集者に付与したい場合、次のコードをWordPressのコードの好きな場所に追加します（テーマ/プラグインの有効化の際のみ適用するのが理想です）。

<?php

  $role = get_role( 'editor' );
  $role->add_cap( 'unfiltered_upload' );

?>

各権限グループへの権限の付与、調整の仕方については後ほどより詳しくご説明します。

既存の権限とメタ権限

WordPressの権限には大きく分けて２つの種類があります。

• 既存の権限：特定の権限グループに付与された権限。各権限グループに自動的に付与されます。
• メタ権限：デフォルトではどの権限グループにも付与されない権限。WordPressは投稿や固定ページ、ユーザー、分類など、コードやデータベース内の特定のオブジェクトをチェックし、ロジックが合致した場合には、メタ権限を、特定の、あるいは複数の既存の権限と「紐付け」解釈します。

例えば、投稿者は自分で作成した投稿についてedit_postsの権限が付与されるため編集することができます。しかしこの権限では他のユーザーの投稿を編集することができません。ここで便利なのがメタ権限です。

WordPressではmap_meta_cap()関数を利用すると、特定のオブジェクトに結びついている既存の権限の配列が返されます。そして、ユーザーが投稿を編集できるかどうか確認するためにユーザーオブジェクトと比較します。

メタ権限には、他にもread_post、delete_post、remove_user、read_postなどがあります。これらについては、権限のカスタマイズのセクションで詳しくご紹介します。

WordPressの6つのデフォルト権限グループ

WordPressには６つのデフォルトの権限グループが存在します。WordPressをインストールして最初に利用するユーザーにはデフォルトで管理者の権限が付与されます（マルチサイトの場合、特権管理者）。

WordPressは現在の本格的なCMSに発展する前はブログ向けプラットフォームとしてスタートしているため、権限グループの権限の大半はウェブ上にコンテンツを公開することに関するものです。他のデフォルトの権限グループは編集者、投稿者、寄稿者、購読者です。

WordPressのデフォルト権限グループを、様々な権限の範囲を示す円柱を積み重ねたものに例えてみましょう。最も大きな円柱が最も多くの権限が付与されたグループで、二つ目に大きなものが二番目に多くの権限を持ち、一番小さな円柱が最も権限が少ないグループです。

権限グループは優劣の関係ではありません。サイト内でのユーザーの責任を決定するためのものと考えましょう。

権限グループに優劣はなく、各ユーザーに何ができるのかを正確に定義するものです。

それでは早速WordPressのデフォルトの権限グループをそれぞれ詳しく見ていきましょう。

管理者

WordPressではシングルサイト向けのインストール後初めて利用するユーザーに管理者の権限が付与されます。他の権限グループと比べ最も権限の範囲が広く、WordPressで規定されている全ての機能へのアクセス権限を持ちます。管理者の権限を持つユーザーは次のようなアクションが実行できます。

• ユーザーの作成/削除
• プラグインとテーマのインストール/管理
• プラグイン、テーマ、ファイル、コードの編集

管理者は最も強い権限を持つ権限グループなので、信頼のおける人物にしか付与してはいけません。1サイトにつき管理者は一人だけ設定するのが理想です。

WordPressのマルチサイトネットワークにも管理者はありますが少し定義が異なります。マルチサイトネットワークでは、管理者はプラグインやテーマのインストールなど、シングルサイトの管理者には付与される一部の権限が適用されず、 これらは特権管理者にのみ与えられる権限となります。

編集者

編集者はWordPressサイトのコンテンツの管理を担います。投稿や固定ページの作成、変更、公開、削除ができ、他のユーザーが作成した投稿や固定ページも対象となります。編集者の権限には次のようなものがあります。

• 公開された投稿/固定ページの削除
• コメントの管理
• リンクとカテゴリーの管理
• 他のユーザーの投稿/固定ページの編集

編集者はプラグインやテーマのインストールなどサイト管理に関わるアクションはとれません。その主な責任は他の投稿者や寄稿者の仕事を監督するか、一人で何役もこなすコンテンツ担当になることです。

ヒント：一人でWordPressサイトを管理している場合、編集者の権限を持つ自分用のユーザーアカウントを別途作成する方法があります。そうすることで管理と投稿の作業を分けることができます。万が一編集者のアカウントがハッキングされたとしても、管理者のアカウントは守ることができます。

投稿者

名前の通り、投稿者の権限を持つユーザーは投稿を作成、編集、公開できます。メディアファイルのアップロードと自分の投稿の削除はできますが、固定ページの作成や他のユーザーの投稿の編集はできません。

投稿者は自分の投稿にタグを追加したり、既存のカテゴリーに投稿を割り当てたりすることができますが、新たなカテゴリーを作成することはできません。編集者と同じように設定、プラグイン、テーマなどの管理に関連する作業はできません。

補足情報：投稿者は公開した後であっても自分の投稿を削除することができます。投稿者の権限を付与する際は、そのユーザーの投稿や削除などを十分管理できていることを確認しましょう。

寄稿者

寄稿者は投稿者よりやや権限を軽くした権限グループです。寄稿者は自分の投稿を作成し、下書きを削除することができますが、公開することはできません。

投稿の下書きを保存し、編集者か管理者に確認と公開を依頼するために送信することができます。投稿が公開された後は、寄稿者がその投稿を削除することができません。一方、投稿者は公開後の自分の投稿を削除することができます。

寄稿者の権限は新人の執筆者やゲストの寄稿者にぴったりです。

購読者

購読者は権限のランクでは最下位にある権限グループです。購読者は自分のプロフィールが編集でき、サイト上の全ての投稿を読むことができます。たったそれだけです。

通常は誰でもWordPressサイトのコンテンツを閲覧することができます。しかし、定期購読制や会員制サイトではログインユーザーしかコンテンツを閲覧できません。その場合、購読者の権限グループのユーザーのみ投稿を読むことができます。

特権管理者

特権管理者はマルチサイト向けのWordPressのみで利用できる権限グループです。この権限グループはマルチサイトネットワーク内のシングルサイトの管理者権限グループよりも上位の権限グループで、高レベルな管理権限にアクセスできます。

特権管理者の利用できるマルチサイト限定の権限には次のようなものがあります。

• ネットワークのサイトの作成、管理、削除
• ネットワークのユーザー、テーマ、オプションを管理
• マルチサイトネットワーク上の全てのサイトをアップグレード
• マルチサイトネットワークを設定
• ネットワークの個別サイトに管理者を割り当てる

マルチサイトネットワークでは、テーマをインストールし、ネットワーク内で有効化できるのは特権管理者だけです。ネットワーク内の個別のサイトの管理者は特権管理者によってインストール済みのテーマの閲覧と有効化しかできません。

例えば、ネットワーク内に無料のAstraのテーマをインストールして、ネットワーク内でまだ有効化していないとします。その場合、ネットワーク内の個別のサイト管理者のテーマ画面にこのテーマは表示されません。

上記のスクリーンショットでは、ネットワーク内の個別のサイトの管理者はプラグインのメニューにアクセスできないことがわかります。テーマの場合とは違い、特権管理者はネットワークの設定を変更し、個別のサイト管理者が自分のサイトにプラグインをインストールし有効化できるようにすることができます。

また、特権管理者はネットワーク内全てのサイトにプラグインが適用されるよう、プラグインをサイトネットワークで有効化することもできます。個別の管理者はネットワークで有効化されたプラグインを無効化することはできません。この設定はネットワーク内で必要不可欠なプラグインを強制的に有効にしたい場合に便利です。

ネットワーク管理画面

ネットワーク管理画面は特権管理者がWordPressのマルチサイトネットワーク権限を管理するためのハブの役割を担います。ネットワークを作成した後、特権管理者の権限を持つユーザーのみアクセスができます。

1. ダッシュボード

ネットワーク管理画面はネットワーク内のサイトの詳細情報を管理する中央ハブです。ネットワークに関する全ての設定にアクセスできます。

2. サイト

マルチサイトネットワークを構成するサイトを管理するのには「サイト」画面を利用します。ここに表示されるサイトはマルチサイトネットワークをどのように設定したかによって、サブディレクトリもしくはサブドメインになります。

ネットワークには新規サイトを追加したり、既存のサイトを削除したりすることができます。

また、サイトやユーザー、テーマ、ネットワーク全体の設定に関する情報もここで確認できます。最初に作ったサイトがネットワーク内の基本のサイトとなります。ネットワークは最初に作成したサイトの設定を引き継ぎます。

新規サイトを作成のリンクをクリックすると上記の画面が表示され、マルチサイトネットワークに新しいサイトを追加することができます。新しいサイトの管理者が他にいない場合は、自分自身を管理者として割り当てることもできます。

3. ユーザー

ネットワーク管理画面の「ユーザー」画面ではマルチサイトネットワークのユーザーを管理したり新しいユーザーを追加したりすることができます。ネットワークへのユーザーの追加は特権管理者しかできませんが、特権管理者がネットワーク設定を変更することで、個別のサイトの管理者が自身のサイトにユーザーを追加できるようになります。

4. テーマ

「テーマ」画面ではサイト管理者がアクセスできるテーマを管理することができます。サイトで使用されているテーマを有効化したり無効化したりすることはできませんが、ネットワーク内のサイトが使用できるテーマを設定することができます。

ネットワーク内のサイトで使用されているテーマを無効化してしまった場合、無効化した後もそのサイト内では引き続き有効であり続けます。しかしそのサイトが別のテーマを使うと、無効化されたテーマはネットワークサイトのテーマ画面に表示されなくなります。

ネットワーク内でのテーマとプラグインの使用方法についてはKinstaのWordPressマルチサイト解説記事をご覧ください。ダッシュボード内でテーマファイルを編集するのにテーマエディタを使用することもできます。

5. プラグイン

「プラグイン」の画面では、ユーザーはネットワーク内のプラグインを追加したり削除したりすることができます。プラグインを追加すると、サイトのダッシュボードからそのプラグインを有効化できるようになります。ネットワーク内全てのサイトにプラグインが適用されるようにネットワークで有効化することもできます。

デフォルトでは、個別のサイトの管理者はダッシュボードのプラグインのメニューにはアクセスできません。特権管理者がネットワーク設定を変更することにより、アクセスできるようになります。

補足情報：全てのWordPress プラグインがマルチサイトネットワークに対応しているわけではありません。プラグインのドキュメンテーションを確認しマルチサイトで利用できるか確認しましょう。

6. 設定

ネットワーク設定画面ではネットワーク全体の設定をしたり変更したりすることができます。ネットワークのデフォルトの設定は最初に作成したサイトに基づいて決定します。ここで変更できる設定には次のようなものがあります。

• 運用設定
• 登録の設定
• 新規サイト設定
• アップロード設定
• 言語設定
• メニュー設定

また、ネットワーク作成時に使用したネットワーク設定情報にもアクセスできます。WordPress Codexのネットワーク管理/設定画面のページでは全ての設定オプションの詳細が確認できます。

7. 更新

更新画面ではネットワーク全体と個別のサイトの両方の更新状況を確認できます。更新画面にはWordPressのコア、テーマ、プラグインの全ての利用可能なアップデートが表示されます。WordPressの最新バージョンをインストールすると、ネットワークをアップグレードの画面からネットワーク上の全てのサイトに適用することができます。

補足情報：WordPressのシングルサイトでは、管理者は全ての管理者権限にアクセスできるため実質、特権管理者と同義です。

WordPressのデフォルトの権限を利用して、権限グループをカスタマイズしたりオリジナルの権限グループを作成したりすることもできます。

権限グループと権限を利用するメリット

権限グループと権限はWordPressのユーザー管理を支えるシステムです。そのメリットをいくつかご紹介します。

• 権限グループによりサイト上のユーザーをより効率的に管理できます。世界中の様々な場所で働くユーザーが数十人いたとしても、一人一人に適切な権限を与えることで簡単に監督することができます。
• ユーザーの権限を特定のもののみに制限することで、サイトの安全性を維持することができます。例えば、投稿者は他の人の投稿を削除することができず、編集者はテーマの変更やプラグインのインストールができません。また、購読者は自分のプロフィールにしかアクセスできません。
• WordPressプラグインがユーザーに特定の権限があるか確認し、それに基づき特定のアクションを実行します。current_user_can()というWordPress関数はこの確認の実行に役立ちます。例えば、セキュリティプラグインではオプション画面は管理者にしか表示されませんが、セキュリティの警告は全てのユーザーに表示されます。
• 権限グループを編集し、自分の権限の一部を他のユーザーに委任し、自分の時間を有効に使うことができます。例えば、あなたのサイトはたくさんのコメントがつくサイトだったとします。そんな時、信頼できる投稿者にコメントの管理を委任することができます。管理者としての最上位の権限は維持しつつ、必要に応じて権限の一部を他のユーザーと共有することができます。
• 特定の権限グループのユーザーしか閲覧できないプライベートな投稿やページを表示するために権限のチェックが利用できます。これが会員制サイトの基本となります。
• ユーザー権限に応じてサイトフロントエンドの要素（メニューのアイテム、ウィジェットなど）を表示させたり、制限したりすることができます。
• オリジナル権限付きのカスタム投稿タイプを作成し、権限グループ毎にその権限を付与するかどうかを指定できます。同様に、オリジナルの権限を定義し、プラグインやテーマの設定にアクセスできるユーザーを制限することもできます。

WordPressの権限グループを効果的に利用する方法

それぞれの権限グループとその権限について理解することは必要不可欠ですが、それらをサイト上で効果的に活用する方法も、知っておく必要があります。全く同じWordPressサイトというものは、この世に存在しませんが、権限グループとその権限を有効に活用するための、基本的なルールは存在します。

ユーザーのアクセス権は全て最低限にする

ユーザーへ付与する権限は必要最低限の範囲にとどめましょう。権限は多すぎるよりも少ない方が良いものです。WordPressの権限グループを限定的にすることはサイトやコンテンツを保護する上で重要です。

管理者と編集者の数は最低限にする

一般的なルールとして、サイトの管理者は一人に限定し、サイトの中核部分のみを変更するべきです。WordPressでは必要なタスクを実行するのに必要不可欠な権限のみを与えるという「最小権限の原則」に従うことを推奨しています。

例えば、サイトのコンテンツの管理には管理者権限よりも編集者の権限の方が適切です。編集者が２人以上いる場合、大きな権限を与えることになるので信頼がおける人物であることを十分確認しましょう。

投稿者は自分の投稿を公開/削除できるので、その権限は信頼できるコンテンツクリエイターに割り当てましょう。寄稿者は新人のコンテンツクリエイターやゲストの執筆者に適しています。

必要に応じて権限グループをカスタマイズする

WordPressのデフォルト権限グループは便利ですが、全ての場合に適しているとは限りません。例えば、投稿者にコメントの管理権限を与えたい場合などもあるでしょう。

幸い、WordPressでは個別のニーズに合わせて権限グループをカスタマイズしたり、新しいグループを作成したりすることができます。コードを用いて手動で設定することも、WordPressの権限グループのプラグインを用いることも可能です。今回の記事ではその両方の方法をご紹介します。

WordPressマルチサイトネットワークでユーザーを管理する

WordPressマルチサイトでは独自のユーザー管理設定が利用できます。中には分かりやすいものあれば、そうでないものもあります。

詳しく見ていきましょう。

マルチサイトネットワークの登録の設定

デフォルトでは、ネットワークへ新しいユーザーやサイトを追加できるのは特権管理者だけです。しかし、ユーザーが子サイトの購読者としてネットワークにアカウントを登録することを許可することはできます。

有効にするには「ネットワーク管理者」>「ネットワーク設定」>「登録の設定」>「新規登録の許可」を開き「ユーザーアカウントの新規登録を許可する」の項目にチェックを入れます。

ここでは、ログイン中のユーザーによる新規サイト登録を許可することもできます。サイトを作成する権限をあなたの設定したユーザーのみに制限したい場合、この項目にチェックを入れます。

最後の項目では、ネットワーク内でユーザーがアカウントを登録することとサイトを作成することの両方を許可します。ネットワーク内にサイトを作成したユーザーには子サイトの管理者権限が付与されます。

一つのユーザーアカウントでネットワーク全体にアクセス

ネットワーク内にユーザーアカウントを作成する時やユーザーがネットワーク内のサイトにアカウントを新規で登録する時、その新規ユーザーはログイン後、ネットワーク内の全てのサイトを閲覧できます。一つのアカウントを作成すれば同じユーザープロフィールで全てのグループにアクセスでき、サブレディットを閲覧できるFacebookやRedditなどのソーシャルネットワークを想像するとわかりやすいでしょう。

これはWordPressのマルチサイトを利用する主なメリットの一つです。一つのアカウントに登録するだけでユーザーはネットワーク内の全てのサイトにアクセスできます。

サイト管理者に追加の権限を付与する

「新規ユーザーの追加」にチェックを入れることで、サイト管理者は自分のサイトにユーザーを追加することを許可できます。

上述の通り、「ネットワーク設定」>「メニュー設定」で「管理メニューを有効化」>「プラグイン」からサイトの管理者に子サイト内のプラグインの管理権限を付与することができます。

子サイト単位でのユーザー登録

WordPressのマルチサイトのインストールでは、デフォルトではネットワーク全体のユーザー登録しかできません。子サイトの一つだけにユーザーを登録することができません。そこでNetwork Subsite User Registrationというプラグインを使います。

このプラグインを使用すると、子サイトの管理者は自分のサイトへのアクセスのみ許可された子サイト内限定のユーザーの登録ができるようになります。新しく追加されたユーザーはデフォルトで購読者の権限が付与されますが、プラグインの設定で変更することも可能です。

同一ユーザーを複数の子サイトに割り当て

同一のユーザーを複数のサイトに割り当て、個別の権限を付与することも可能です。ユーザーがサイトの管理画面にログインすると、「参加サイト」の画面で全てのサイトの管理画面にアクセスできます。

他のユーザーに特権管理者の権限を付与する

特権管理者は自分の権限を他のユーザーと共有することも可能です。ただしこの機能は信頼できる人物にのみ慎重に利用しましょう。

WordPressマルチサイトの全てのユーザー管理設定を理解することでより効率的にネットワークを管理することができます。WordPressマルチサイト向けの他の便利なプラグインをお探しの方はWordPressレポジトリを見てみるか、KinstaのおすすめのWordPressマルチサイトプラグインをご覧ください。

既存のWordPressの権限グループをカスタマイズする方法

既存の権限グループに権限を追加し、アクセス権を広げることもできます。例えば、編集者にプラグインを管理する権限を付与することができます。もしくは寄稿者に自分の投稿のコメントを管理する権限を付与することもできます。その方法を詳しくご紹介します。

補足情報：コードを扱いたくないという方は手動の方法を飛ばして、そのあとの権限グループと権限のプラグインに関するセクションへお進みください。または、WordPress開発者を雇用してもいいでしょう。

権限グループに権限を追加する方法

WordPressのadd_cap()関数を利用して権限グループや特定のユーザーに権限を追加することができます。Customize User Roleと名付けたカスタムプラグインを利用して、編集者にプラグインを管理する権限を付与する方法をご紹介します。

<?php

/*
Plugin Name:  Customize User Role
Version:  1.0
Description:  Demonstrating how to customize WordPress User Roles.
Author:  Salman Ravoof
Author URI:  https://www.salmanravoof.com/
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html
Text Domain:  customize-user-role
*/

この設定はデータベース（wp_optionsテーブルのwp_user_rolesフィールド）に保存されるため、WordPressではこの関数はプラグインかテーマを有効化した時に実行することを推奨しています。ページを読み込む度にこの関数を実行するのは（データベーステーブルが毎回上書きされることになるので）非効率的です。

ここではプラグインを使用しているので、register_activation_hook()関数を使ってプラグインを有効化した時に実行される関数を登録します。他にも様々な方法がありますが、干渉が起きないように、堅牢なクラスベースの方法で実装します。

// this code runs only during plugin activation and never again
function sal_customize_user_role() {
    require_once plugin_dir_path( __FILE__ ).'includes/class-sal-customize-user-role.php';   
    Sal_Customize_User_Role::activate();
}
register_activation_hook( __FILE__, 'sal_customize_user_role' );

上記のコードは、プラグイン有効時にのみ1度だけ実行されます。フックの対象となる関数sal_customize_user_roleは Sal_Customize_User_Roleというカスタムクラスを参照します。

このクラスはclass-sal-customize-user-role.phpという名前の別のファイルで定義し、プラグインのルートフォルダの中のincludesというサブフォルダーに保存しましたが、名前は何でも構いません。

<?php

class Sal_Customize_User_Role {
    public static function activate() {
        // get the Editor role's object from WP_Role class
        $editor = get_role( 'editor' );

        // a list of plugin-related capabilities to add to the Editor role
        $caps = array(
                  'install_plugins',
                  'activate_plugins',
                  'edit_plugins',
                  'delete_plugins' 
        ); 

        // add all the capabilities by looping through them
        foreach ( $caps as $cap ) {
            $editor->add_cap( $cap );
        }
    }
}

上記のコードの詳しい説明は次の通りです。

• まずクラスとその関数（メインプラグインファイルで参照した）を定義します。
• get_role( ‘editor’ )関数がWP_Roleコアクラスから編集者の権限グループオブジェクトを受け取り、$editor変数に割り当てます。
• プラグインの管理にはinstall_plugins、activate_plugins、edit_plugins、delete_pluginsの４つの権限が必要です。しかしadd_cap()関数では一つしかパラメーターを指定できません。そのため一つの配列に全ての権限を含める必要があります。$capsの配列にこれら全ての権限が含まれるよう定義します。追加したい権限が一つだけの場合は配列を仕様する必要はありません。
• add_cap( $cap )関数はPHP関数foreach ()を利用しループ処理をして$capsの配列で定義された全ての権限を追加します。

プラグインファイルを全て保存し、管理者画面からプラグインを有効化します。編集者の管理画面にログインすると変化が分かります。

プラグイン関連の権限を権限グループに追加すると、編集者の管理画面にプラグインメニューが表示されるようになります。

WordPressサイトデータベース内のwp_optionsテーブルに保存されているwp_user_rolesキーの値を見ると、各権限グループに割り当てられた権限を確認することができます。

編集者に割り当てられた権限は次のように表示されます。

'editor' => 
  array (
    'name' => 'Editor',
    'capabilities' => 
    array (
      'moderate_comments' => true,
      'manage_categories' => true,
      // [...lines cut off for brevity...]
      'install_plugins' => true,
      'activate_plugins' => true,
      'edit_plugins' => true,
    ),
  ),

最後の３行を見ると編集者にプラグインの管理権限が付与されていることがわかります。

権限を削除したい場合は、register_deactivation_hook()関数にフックし、 remove_cap()関数を利用し、先程プラグインの有効化の際に権限を追加したのと同じように、プラグイン無効化時に権限を削除することができます。

権限グループに権限を追加する方法は既に学んだので、今後は権限グループの権限を削除する方法を見てみましょう。

補足情報：アクションフックafter_switch_themeを利用して、テーマ（または子テーマ）有効化の際にコードを適用することも可能です。その場合、コードはテーマもしくは子テーマ（推奨）のfunctions.phpファイルに含めます。

権限グループから権限を削除する

時に権限グループから権限を削除したいこともあります。権限グループ、または特定のユーザーから権限を削除するにはremove_cap()関数を利用します。例えば、投稿者からdelete_published_postsの権限を削除したいとします。

実際にやってみましょう。

まずはCustomize Author Roleという名前の新しいカスタムプラグインを作成します。前回と同じように、このコードはregister_activation_hook()関数にフックして一度だけ実行します。

<?php

/*
Plugin Name:  Customize Author Role
Version:  1.0
Description:  Demonstrating how to customize WordPress Author Role.
Author:  Salman Ravoof
Author URI:  https://www.salmanravoof.com/
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html
Text Domain:  customize-author-role
*/

// this code runs only during plugin activation and never again
function sal_customize_author_role() {
    require_once plugin_dir_path( __FILE__ ).'includes/class-sal-customize-author-role.php';
    Sal_Customize_Author_Role::activate();
}
register_activation_hook( __FILE__, 'sal_customize_author_role' );

次に、class-sal-customize-author-role.phpファイル内で Sal_Customize_Author_Roleクラスを定義します。上記のメインプラグインファイルで両方のリソースを参照しました。

<?php
class Sal_Customize_Author_Role { 
    public static function activate() {
        // get the Editor role's object from WP_Role class
        $author = get_role( 'author' );
 
        // remove the capability to delete published posts from an Author role
        $author->remove_cap( 'delete_published_posts' );
    }
}

remove_cap( 'delete_published_posts' )関数によって投稿者の公開済みの投稿を削除する権限が削除されます。

全てのプラグインファイルを保存しプラグインを有効化します。投稿者の管理画面にログインすると変化が分かるでしょう。

投稿者の公開した投稿のゴミ箱のオプションが利用できなくなっています。ただし、下書きもしくはレビュー待ちステータスの未公開の記事は削除することができます。

この権限も削除したいという場合は、投稿者の権限からdelete_postsの権限も削除する必要があります。

特定のユーザーの権限を追加/削除する

権限グループ全体ではなく、特定のユーザーに権限を追加したい場合、WP_User::add_cap()クラス関数を利用します。

// get the user object by their ID
$user = new WP_User( $user_id ); 

// add the capability to the specific user
$user->add_cap( $cap );

get_user_by()関数を使用してユーザーのメールアドレス、ログインユーザー名、スラッグを利用してIDを呼び出すことができます。

同様にWP_User::remove_cap()クラス関数を利用すると特定のユーザーの権限を削除することができます。

// get the user object by their ID
$user = new WP_User( $user_id );

// add the capability to the specific user
$user->add_cap( $cap );

先程と同じように、コードの最適化のために、このコードはプラグイン、またはテーマを有効化した時のみ実行するようにしましょう。

補足情報：add_cap()もremove_cap()もWP_Roleクラスのオブジェクトメソッドです。コードで直接呼び出すことはできません。 get_role() 関数、もしくはグローバル変数$wp_rolesのいずれかを使用してアクセスする必要があります。

権限グループを複製する

既存の権限グループを全てコピーして新たな権限グループを作成することもできます。その方法は次の通りです。

add_role( 'clone', 'Clone', get_role( 'administrator' )->capabilities );

上記の例では、管理者と同じ権限を持つCloneという新たな権限グループを作成しています。テーマやプラグインを有効化する際にこのコードを実行することで、この複製された権限は一度だけ追加されます。

WordPressでオリジナルの権限グループを作る方法

既存のユーザーの権限を編集するのが、権限をカスタマイズする一番手っ取り早い方法です。しかし、多くの権限を編集したい場合は、新たな権限グループを一から作るのがよいでしょう。そうすることで、サイト上で必要な全てのユーザーの権限を正確に設定することができます。

新しい権限グループを作成するにはadd_role() 関数を使用します。この関数には３つのパラメーターが利用できます。

add_role(  $role, $display_name, $capabilities );

最初の2つのパラメーターは関数を実行するために必ず定義しなければなりません。それぞれ新しい権限グループの名前と表示名です。最後のパラメーターは任意の設定で、配列でなければなりません。これを使って、新たな権限グループの全ての権限を割り当てることができます。

ここではサイト上全てのコメントの管理、投稿の編集ができるCommunity Managerというオリジナルの権限グループを作成してみましょう。実際にやり方をご説明します。

<?php

/*
Plugin Name:  Add Community Manager Role
Version:  1.0
Description:  Add a Custom User Role called 'Community Manager'
Author:  Salman Ravoof
Author URI:  https://www.salmanravoof.com/
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html
Text Domain:  add-community-manager-role
*/

// this code will run only once on plugin activation and never again
function add_community_manager_role() {
    add_role(
         'community_manager',
         __('Community Manager', 'add-community-manager-role'), 
         array( 
              'read' => true,
              'moderate_comments' => true,
              'edit_posts' => true,
              'edit_other_posts' => true,
              'edit_published_posts' => true
         )
    );
}
register_activation_hook( __FILE__, 'add_community_manager_role' );

先程と同じように、add_role()関数はプラグイン有効化の時にのみ一度だけ実行されます。ファイルを保存しプラグインを管理者の画面から有効化します。新規ユーザー、既存ユーザーの両方にCommunity Managerの権限を付与できるようになっているはずです。

また、データベース内wp_optionsテーブルのwp_user_rolesフィールドの値を見ると、この新たな権限グループに付与された権限を確認することもできます。私のサイトのデータベースでは次のようになっています。

array (
  'administrator' => 
    // [...]
  'editor' => 
    // [...]
  'author' => 
    // [...]
  'contributor' => 
    // [...]
  'subscriber' => 
    // [...]
  'community_manager' => 
  array (
    'name' => 'Community Manager',
    'capabilities' => 
    array (
      'read' => true,
      'moderate_comments' => true,
      'edit_posts' => true,
      'edit_other_posts' => true,
      'edit_published_posts' => true,
    ),
  ),
)  

コードの最後尾に先程追加した新しい権限グループとその権限が記載されています。この権限グループに権限を追加/削除することでさらにカスタマイズすることもできます。

新規の権限グループを試してみる

新たな権限グループを実際のユーザーに割り当てる前に、思った通りに機能するかどうか試してみる必要があります。テストの際にチェックするべき項目は次の通りです。

1. 新たな権限グループを割り当てるためのテストユーザーアカウントを作成します。
2. テストユーザーのアカウントにログインし、全ての権限が思った通りに機能するかどうか確認します。例えば、公開済みの投稿を編集する権限を付与した場合、任意の投稿を開き、編集できるかどうか確認します。付与した権限が多いほど、テストにかかる時間は長くなるでしょう。
3. 次に、ブラウザから直接、上位の権限グループのリンクへ試しにアクセスしてみます。WordPressの設定画面に直接アクセスしようと試みたところ、予想通りアクセスできませんでした。「denied access（アクセス拒否）」のメッセージが表示されます。
4. テストが完了したらテストユーザーアカウントを削除します。

たったのこれだけです！問題なければサイトのユーザーに実際に新たな権限グループを割り当てましょう。

User SwitchingやView Admin Asプラグインを使用するとワンクリックで簡単にサイト上の様々なユーザーに切り替えることができます。複数のユーザーの権限を確認するのに大変便利です。これについては、後ほど詳しくご説明します。

WordPressマルチサイトでオリジナルの権限グループを作成する

WordPressマルチサイトでは、シングルサイトと権限グループの扱いが若干異なります。先程ご説明したadd_role()関数でオリジナルの権限グループを作成する方法は利用できますが、新しい権限グループはネットワークのメインサイト（最初に作成したサイト）にしか適用できず、ネットワーク上の他の子サイトには適用されません。

コールバック関数内のコードが確実にネットワーク上の全てのサイトに適用されるようにするには、ネットワーク上のサイト一つ一つについてループ処理をして、強制的に実行させる必要があります。今回は例として、プラグインを管理するための全ての権限を付与したPlugin Managerという新しい権限グループを作成しました。

<?php

/*
Plugin Name:  Add Plugin Manager Role
Version:  1.0
Description:  Add a custom user role named Plugin Manager in a WordPress Multisite Installation
Author:  Salman Ravoof
Author URI:  https://www.salmanravoof.com/
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html
Text Domain:  add-plugin-manager-role
*/

/* 
make the code run on every site in the network
when the plugin is Network Activated
*/
function add_plugin_manager_role( $network_wide ) {
 
     if ( is_multisite() && $network_wide ) { 
         // run the code for all sites in a Multisite network
         foreach ( get_sites(['fields'=>'ids']) as $blog_id ) {
             switch_to_blog( $blog_id );
                 add_role(
                      'plugin_manager',
                      __('Plugin Manager', 'add-plugin-manager-role'),
                      array( 
                           'install_plugins' => true,
                           'activate_plugins' => true,
                           'edit_plugins' => true,
                           'delete_plugins' => true
                      )
                 );
             }
             restore_current_blog();
     }
     else {
         add_role(
              'plugin_manager',
              __('Plugin Manager', 'add-plugin-manager-role'),
              array( 
                   'install_plugins' => true,
                   'activate_plugins' => true,
                   'edit_plugins' => true,
                   'delete_plugins' => true
              )
         );
     }
}
register_activation_hook( __FILE__, 'add_plugin_manager_role' );

上記のコードを詳しく見ていきましょう。

• まず、register_activation_hook()を利用してプラグイン有効化のアクションにフックし、コールバック関数を渡します。ここでのコールバック関数はadd_plugin_manager_role()です。
• 次にコールバック関数を定義し、 $network_wide引数を利用します。
• $network_wideというパラメーターはプラグインをネットワーク全体に有効化している場合trueを返すbool型の変数です。現在のサイトのみで有効化している場合はfalseを返します。またマルチサイトのみで利用でき、デフォルト値はfalseです。
• is_multisite() && $network_wideという条件文は、マルチサイトでプラグインが「ネットワーク全体で有効化されているかどうか」をチェックします。trueである場合If命令文にあるコードが実行されます。Falseの場合、else命令文に含まれるコードを実行します。
• get_sites(['fields'=>'ids'])関数はネットワーク内の全てのサイトIDの一覧を返します。foreach()PHP関数を利用して、ネットワーク内の各サイトに個別にコードを実行するためにループ処理します。
• switch_to_blog( $blog_id )関数はそれ以降数行のコードを$blog_idのIDを持つ子サイトに対して実行します。WordPressがもともとはブログのプラットフォームであったという経緯から、「blog」という単語が使用されていますが、「site」と入れ替えて考えると分かりやすいでしょう。
• 次にadd_role()関数を利用してオリジナル権限グループとその権限を定義します。ここで記述するコードは既にご説明した通りです。
• ループを終了する前に、restore_current_blog()関数で、（サイト切り替えの前の）元のサイトに戻るようにします。
• else命令文のコードは、シングルサイトとの互換性を保証するためのフォールバックです。

プラグインファイルを保存し、「サイトネットワーク管理」>「プラグイン」画面からカスタムプラグインを「ネットワークで有効化」します。その後、任意のサイトの「ユーザー」タブを開き、新しい「Plugin Manager」という権限グループが利用できるかどうか確認しましょう。

この新たな権限グループがネットワーク内の他のサイトでも利用可能かどうかを確認したところ問題ありませんでした。

サイトのデータベースを覗くと、新しい権限グループを確認することができます。ただし、シングルサイトとは異なり、WordPressのマルチサイトでは、各子サイトに個別のwp_optionsテーブルが作成されます。

子サイト専用のテーブルはwp_2_options、wp_3_options、wp_4_optionsとして表示されます。同じように、権限グループと権限はそれぞれのフィールドにwp_2_user_roles、wp_3_user_roles、wp_4_user_rolesとして表示されます。

これでネットワーク内全てのサイトで利用できる権限グループを定義できましたが、これから新規で作成するサイトはどうなるのでしょうか？ネットワーク内に新規で作成されたサイトにもこのオリジナルの権限グループが適用されるようにするには、プラグインに次のコードを付け足しましょう。

// run the code once again when a new site is created
function add_custom_user_role_new_site( $blog_id ) { 
    // check whether the plugin is active for the network
    if ( is_plugin_active_for_network( 'add-custom-user-role/add-custom-user-role.php' ) ) {
        switch_to_blog( $blog_id );
        add_role(
             'plugin_manager',
             __('Plugin Manager', 'add-plugin-manager-role'),
             array( 
                  'install_plugins' => true,
                  'activate_plugins' => true,
                  'edit_plugins' => true,
                  'delete_plugins' => true
             )
        );
        restore_current_blog();
    }
}
add_action( 'wpmu_new_blog', 'add_custom_user_role_new_site' );

• wpmu_new_blogアクションはマルチサイトネットワーク内に新規サイトが作成されると実行されます。コールバック関数でこのアクションにフックして、権限グループを追加します。
• is_plugin_active_for_network()関数はプラグインがネットワーク全体で有効化されているかどうかをチェックし、bool型変数を返します。プラグインファイルのパスを引数として利用できます。
• 残りのコードはこれまで見てきたロジックと同じです。$blog_idパラメーターを使用して新しいサイトに切り替え、add_role()関数を利用してオリジナルの権限グループを作成し、 restore_current_blog()関数を利用して元のサイトに戻ります。

WordPressから権限グループを削除する方法

remove_role( ) 関数を使用するとWordPressの権限グループを削除できます。引数として指定できるのは権限グループ名のみです。例えば、サイト上の任意の場所に次のコードを記述すると寄稿者の権限グループを削除することができます。

remove_role( 'contributor' );

プラグインかテーマの有効化と同時に実行しないとデータベースが毎回アップデートされてしまうadd_role()関数とは異なり、remove_role()関数は該当の権限グループが存在する場合のみ実行されます。引数として渡された権限グループは一度実行されると必ず削除されるので、この関数を実行する場所について悩む必要はありません。

ただし、将来的に不具合が発生するのを防ぐため、権限グループがデータベースから削除されたら、このコードは削除してしまいしょう。

WordPressでカスタム権限を作成する

大抵の場合は既存の権限グループを編集するか、WordPressのデフォルトの権限を利用して新しい権限グループを作成するかで事足りるでしょう。しかし時には、（プラグインやテーマを使用して）独自のカスタムコードで導入した機能のために新たな権限を定義したいこともあるかもしれません。

その場合はカスタム権限を利用して新たな権限グループを定義したり、既存の権限グループに追加したりすることができます。

例えば、WooCommerceでは膨大なeコマースの機能とともにカスタム権限が利用できます。カスタム権限には次のようなものがあります。

• WooCommerceの設定の管理を許可
• 商品を作成、編集する
• WooCommerceのレポートを閲覧する

これらの権限を利用し、2つの新たな権限グループ「Customer」と「Shop Manager」が追加されます。

Customerの権限は、自分のアカウント情報を編集でき、現在/過去の注文情報を閲覧できるという点を除いては、購読者とほとんど同じです。Shop Managerには編集者に付与された全ての権限に加え、WooCommerceに関する権限が全て付与されます。

カスタム権限/権限グループを導入しているプラグインには他にもThe Events Calendar、Visual Portfolio、WPML、WP ERPなどがあります。

これらのプラグインのドキュメンテーションを見ると、ほとんど全てのカスタム権限はそれぞれのプラグインで定義されるカスタム投稿タイプと結びついていることが分かります。WooCommerceの場合、商品と注文のカスタム投稿タイプで、他のプラグインではそれぞれ、イベント、ポートフォリオ、翻訳、顧客となります。

続いては、カスタム投稿タイプに紐づいたカスタム権限を作成する方法をご紹介します。

まず、プラグインを設定し、必要なカスタム投稿タイプを登録します。ここでは、Storiesという新たなカスタム投稿タイプを登録しました。

<?php

/*
Plugin Name:    Custom Post Type and Capabilities
Version:        1.0
Description:    Register a custom post type and define custom capabilities tied into it.
Author:         Salman Ravoof
Author URI:     https://www.salmanravoof.com/
License:        GPLv2 or later
License URI:    https://www.gnu.org/licenses/gpl-2.0.html
Text Domain:    custom-post-type-capabilities
*/

// register a custom post type, in this case it's called "story" //
function cpt_story_init() {
    $labels = array(
        'name'                  => _x( 'Stories', 'custom-post-type-capabilities' ),
        'singular_name'         => _x( 'Story', 'custom-post-type-capabilities' ),
        'menu_name'             => _x( 'Stories', 'Admin Menu text', 'custom-post-type-capabilities' ),
        'name_admin_bar'        => _x( 'Story', 'Add New on Toolbar', 'custom-post-type-capabilities' ),
        'add_new'               => __( 'Add New', 'custom-post-type-capabilities' ),
        'add_new_item'          => __( 'Add New Story', 'custom-post-type-capabilities' ),
        'new_item'              => __( 'New Story', 'custom-post-type-capabilities' ),
        'edit_item'             => __( 'Edit Story', 'custom-post-type-capabilities' ),
        'view_item'             => __( 'View Story', 'custom-post-type-capabilities' ),
        'all_items'             => __( 'All Stories', 'custom-post-type-capabilities' ),
        'search_items'          => __( 'Search Stories', 'custom-post-type-capabilities' ),
        'parent_item_colon'     => __( 'Parent Stories:', 'custom-post-type-capabilities' ),
        'not_found'             => __( 'No stories found.', 'custom-post-type-capabilities' ),
        'not_found_in_trash'    => __( 'No stories found in Trash.', 'custom-post-type-capabilities' ),
        'featured_image'        => _x( 'Story Cover Image', 'custom-post-type-capabilities' ),
        'set_featured_image'    => _x( 'Set cover image', 'custom-post-type-capabilities' ),
        'remove_featured_image' => _x( 'Remove cover image', 'custom-post-type-capabilities' ),
        'use_featured_image'    => _x( 'Use as cover image', 'custom-post-type-capabilities' ),
        'archives'              => _x( 'Story archives', 'custom-post-type-capabilities' ),
        'insert_into_item'      => _x( 'Insert into story', 'custom-post-type-capabilities' ),
        'uploaded_to_this_item' => _x( 'Uploaded to this story', 'custom-post-type-capabilities' ),
        'filter_items_list'     => _x( 'Filter stories list', 'custom-post-type-capabilities' ),
        'items_list_navigation' => _x( 'Stories list navigation', 'custom-post-type-capabilities' ),
        'items_list'            => _x( 'Stories list', 'custom-post-type-capabilities' ),
    );
 
    $args = array(
        'labels'             => $labels,
        'public'             => true,
        'menu_icon'          => 'dashicons-book',   
        'publicly_queryable' => true,
        'show_ui'            => true,
        'show_in_menu'       => true,
        'query_var'          => true,
        'rewrite'            => array( 'slug' => 'story' ),
        'capability_type'    => array ( 'story', 'stories' ),
        'map_meta_cap'       => true,
        'has_archive'        => true,
        'hierarchical'       => false,
        'menu_position'      => 6,
        'supports'           => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' ),
        'show_in_rest'       => true,
    );
 
    register_post_type( 'story', $args );
}
 
add_action( 'init', 'cpt_story_init' );

詳しい説明は次の通りです。

• register_post_type()関数を使用してカスタム投稿タイプを登録します。initアクションにフックしてこの関数を実行することができます。
• register_post_type()関数には二種類の引数が利用できます。1つ目はカスタム投稿タイプの名前で2つ目が投稿タイプを登録するために必要な全ての引数を含む配列です。
• $args変数にはregister_post_type()関数に渡す全ての引数が含まれます。そのうちの1つ(‘labels’) はそれ自体が$labelという変数で個別に定義されている配列です。
• 'capability_type' => 'post'という引数にご注目ください。これはカスタム投稿タイプを読む/編集する/削除する権限を構築するために使用されるWordPressのデフォルトの権限タイプです。
• カスタム権限を作成するには、capability_typeという引数の値を任意のカスタム権限名に置き換える必要があります。引数として、String型または配列のいずれかを記述できます。カスタム権限の複数形が通常の「s」をつける形ではない場合は、配列が便利です（book/booksではなくstory/storiesなど）。
• また、WordPressが自動で名付けるのと違う方法で新たな権限を名付ける場合capabilities引数を使用することもできます。
• カスタム権限はWordPressの既存の権限に紐付けなければなりません。そのように、WordPressが関連性を理解できるように、map_meta_cap引数をtrueに設定する必要があります。

次に、Storiesというカスタム投稿タイプにアクセスできる権限グループにカスタム権限を追加する必要があります。ここでは、管理者と編集者にこの権限を付与します。

// add the custom capabilities to the desired user roles 
$roles = array( 'editor','administrator' );

foreach( $roles as $the_role ) {      
    
    $role = get_role($the_role);
            
            $role->add_cap( 'read' );
            $role->add_cap( 'read_story');
            $role->add_cap( 'read_private_stories' );
            $role->add_cap( 'edit_story' );
            $role->add_cap( 'edit_stories' );
            $role->add_cap( 'edit_others_stories' );
            $role->add_cap( 'edit_published_stories' );
            $role->add_cap( 'publish_stories' );
            $role->add_cap( 'delete_others_stories' );
            $role->add_cap( 'delete_private_stories' );
            $role->add_cap( 'delete_published_stories' );
}

ファイルを保存しプラグインを有効化します。すると、管理者と編集者の管理画面上にStoriesのリンクと画面が表示されるはずです。

サイト上で利用できる権限を確認すると、追加した全てのstories関連の権限が表示されているはずです。ここではView Admin Asプラグインを使って権限をチェックします。

こちらのGistからこのプラグインの完全版をダウンロードできます。ここではカスタム権限を指定したProjectsというカスタム投稿タイプを登録しています。そしてそれをStudentsとTeachersという2つの権限グループに付与することで、教育関連のサイトが作れるようになっています。

権限グループに応じてプラグインの設定へアクセスできるカスタム権限を定義する方法も存在します。その方法については、今回の記事の主旨から外れてしまうのでここではご紹介しませんが、気になる方はStackExchangeのこちらのスレッドをご覧ください。

おすすめのWordPress権限グループ/権限関連プラグイン

コードを利用してユーザーグループ権限や権限を調整する方法を知っているに越したことはありませんが、全員がコードを使いこなせるわけではありません。適正にコードを記述しないと、大変なことになりかねません。しかし、プラグインを使用する場合でも、WordPressの権限グループと権限の仕組みを知っておくことは非常に重要です。

ここからは簡単に権限グループと権限を管理できる人気のWordPressプラグインをご紹介します。権限グループと権限を簡単にテストできる便利なプラグインも合わせていくつかご紹介します。

User Role Editor（開発者：Vladimir Garagulia）

User Role EditorはWordPressのレポジトリで最も人気な、権限グループ、権限管理プラグインです。ワンクリックで誰でも簡単に権限グループや権限を編集できるシンプルなインターフェースのプラグインです。

プラグインをインストール、有効化したら、管理画面の「ユーザー」>「User Role Editor」を開きメインインターフェースにアクセスします。

上記の管理画面の概要は以下の通りです。

1. ドロップダウンメニューからカスタマイズしたい権限グループを選択します。デフォルトの権限グループだけでなく、データベースに存在する全ての権限グループが表示されます。権限を定数ではなく概説で表示することも可能です。WordPressの最新バージョンでは非推奨となっている権限も表示するオプションも選べます。
2. User Role Editorでは全ての権限が左側にカテゴリー毎に表示されます。コアカテゴリーには全てのデフォルトの権限が含まれます。私の場合WooCommerceをサイトにインストールしているので、それに紐づいたカスタム投稿タイプの権限も表示されます。User Role Editor自体のカスタム権限も表示されます。
3. 右側には全ての権限が一覧で表示されます。ALLのグループを選択しているため全ての権限が表示されていますが、左側のグループをクリックすることでフィルターをかけることもできます。Granted Onlyのオプションにチェックを入れると、いずれの権限グループにも使用されていない権限を隠すことができます。
4. また権限グループの追加、権限グループ名変更、権限の追加、権限の削除もここからできます。一番下には権限グループのHide admin bar（管理バーを非表示にする）オプションも選択できます。

権限グループをカスタマイズしたいときは必要な権限にチェックを入れたり外したりして、更新ボタンを押すだけで変更を保存できます。このようにとても簡単です。

新しい権限グループを作成するには権限グループの追加をクリックします。一から権限グループを作成することもできますし、ドロップダウンメニューのコピー元を選んで複製することもできます。

権限グループ名変更からは表示する権限名を変更することができます。ただし、権限グループ名（ID）は変更できません。そのため、権限グループ名を変更したい場合は、元の権限グループを複製して、変更してから削除するとよいでしょう。

権限の追加ボタンからは新しい権限を追加できます。

権限の削除からはどのユーザーにも割り当てられていないカスタム権限グループを削除することができます。

補足情報：User Role EditorではWordPressのデフォルトの権限グループや権限を削除することはできません。また、いずれかのユーザーに割り当てられているカスタム権限グループや、管理者以外の権限グループに割り当てられている権限も削除することはできません。

権限の削除ボタンは、その権限が管理者以外のユーザーに割り当てられていない場合のみ表示されます。割り当てられている場合は表示されません。

同じユーザーに複数の権限グループを割り当てることも、一つも割り当てないこともできます。

ユーザーに複数の権限グループを割り当てるには管理画面のユーザーを開き、ユーザー名にマウスを当てると下に表示される権限のリンクをクリックします。

管理者画面の「設定」>「User Role Editor」を開くと、User Role Editorプラグインの他のオプションも選べます。

ここではプラグインの一般設定の変更、追加モジュールのインストール、新規ユーザーに割り当てられるデフォルトの権限グループの変更、さらには権限グループと権限をデフォルトに戻すこともできます。

多くの場合はUser Role Editorの無料版で十分ですが、有料版 ではWordPressマルチサイトでの権限グループや権限の管理機能など、より多くの機能が利用できます。

MemberPress提供のMembers

Membersは会員制サイトに特化したWordPress向け権限グループ/権限プラグインです。元々はシンプルな権限グループ/権限管理用のプラグインとして開発されましたが、その後、方向転換し、会員制サイトの機能に重点を置くようになりました。

プラグインをインストールし有効化したら、管理画面の「Members」>「Roles」 からサイト上の全ての権限グループを閲覧できます。

Membersでは管理者、そして、新規ユーザーにデフォルトで付与される権限グループ（「Default Role」と表示される）を除き、WordPressの標準の権限グループを含めて全ての権限グループを削除することができます。また、権限グループの編集と複製の他、特定の権限グループを割り当てられたユーザーの一覧を表示することもできます。

「Edit Role」画面ではチェックボックスのチェックを入れたり外したりすることで、特定の権限グループに対して権限を追加/削除することができます。また、ここから権限グループに対してカスタム権限を付与することもできます。

「Add New Role」をクリックすると同じような画面に移動し、表示名、ID、付与する権限を指定して新たな権限グループを作成することができます。

User Role Editorと同じように、Membersでもユーザーに複数の権限グループを割り当てることができます。また、特定の権限グループに属するユーザーのみにコンテンツの閲覧を限定する、コンテンツの閲覧制限も設定できます。

サイトとフィードをプライベートの設定にすることもできます。さらに、アクセス認証を要求することで、外部からのWordPressのREST APIへのアクセスを制限することもできます。

Membersは素晴らしいアドオンが揃っているという点が他の権限関連のプラグインと異なります。ユーザープライバシーや個人情報管理（GDPR）、タグやカテゴリーに関する権限の追加、権限グループのヒエラルキーの構築など、様々な機能を追加することができます。

またMembersは人気のWordPressプラグインとシームレスに連携することができます。例えば、Advance Custom Fields (ACF) プラグイン用のカスタム権限を作成、管理するのに利用できます。他にもEasy Digital Downloads、GiveWP、Meta Box、WooCommerceなどとも連携できます。

Members会員制サイト専用アドオン（支払い、定期購読、メールマーケティング、詳細コンテンツ保護ルール）が利用できるのは有料版のみです。

WPFront User Role Editor

WPFront User Role Editorは、WordPressサイトでの権限グループの作成、編集、削除をサポートしてくれるプラグインです。主な機能はこれまでご紹介してきたプラグインと似ていますが、特筆すべき独自の機能が2つあります。

WPFront User Role Editorをインストールし有効化したら、管理画面から「ユーザー」>「Assign / Migrate」へ移動し、特定の権限グループに属する全てのユーザーを別の権限グループに移行することができます。さらに、ユーザーに2つ目の権限グループを割り当てることもできます。

大勢のユーザーを特定の権限グループから移行する必要がある場合、この機能は非常に便利です。

もう一つのWPFront User Role Editorの便利な機能は、権限グループに基づいたLogin Redirect（ログイン時のリダイレクト）機能です。例えば、投稿者がログインした時に直接投稿画面にリダイレクトすることができます。また、/wp-adminページへのアクセスと、フロントエンドツールバーの閲覧をブロックするオプションも利用できます。

Advanced Access Manager

Advanced Access Manager（AAM）はサイトのほとんど全ての要素をコントロールできる強力なWordPressプラグインです。200以上の独特な機能が備わっていて、権限グループや権限の仕組みを熟知している上級者向けの設計になっています。

これまでご紹介したプラグインと比べるとAAMにはかなり多くの機能が備わっていますが、開発者向けのプラグインなので、初級者〜中級者にとってはそれほど使いやすくはありません。

AAMのメインの管理画面は４つのセクションに分けられます。上の図に振った番号に該当する概要の説明は以下の通りです。

1. 一番上のエリアには現在検討中の対象が表示されます。ここでは「Role: Administrator」（権限グループ：管理者）ですが、特定のユーザー、匿名の訪問者、全員に適用されるデフォルトの設定の場合もあります。
2. メインの画面のタイトルの下のエリアには、対象となるグループやユーザーのサイト上の様々なアクセス権を管理できる全ての設定が表示されます。
3. ３つ目のエリアはユーザー/権限グループを管理するエリアです。タブのアイコンで管理したいアクションを選択できます。権限グループでしょうか、特定のユーザーでしょうか、匿名の訪問者でしょうか、それとも全員へ適用されるデフォルトのアクセス権限でしょうか？
4. ４つ目のエリアはAAM設定の管理、有料アドオンのインストール、サポートへの問い合わせのエリアです。

AAMではその動作と目的に応じて設定を５つのグループに整理しています。

• 「Services」では、有効化/無効化できる全てのAAMのモジュールが一覧で表示されます。モジュールを選択して読み込むことで、サイトを最適化できます。
• 「Core Settings」のエリアではAAMとWordPressのコア機能を有効化/無効化することができます。
• 「Content Settings」はサイトのコンテンツ関連の設定です（投稿/固定ページ/カスタム投稿タイプなど）。
• 「Security Settings」のセクションではAAMへの安全なログインに関する機能の設定ができます。今のところ、利用可能な設定はBrute Force LockoutとOne Session Per Userの２種類です。
• 「ConfigPress」はAAMプラグインの設定をINIファイルベースのコードと入れ替える興味深い機能です。

AAMはシンプルな権限グループ/権限用のプラグインを超える開発者向けのプラグインです。各権限グループがサイト上でできること、できないことを細かく設定することができます。

サイトのアクセスとセキュリティのポリシー を設定するのにAAMを利用することもできます。どの権限グループがどのような状況下でサイトのリソースにアクセスできるかを定義できます。すぐに始めたいという方はアクセスポリシーをAAM Access Policy Hubからインストールすることができます。

AAMでは一時的なユーザーアカウント/権限グループを作成することができます。これはアカウントを外部のリソースと共有する安全な方法です。一時的なユーザーアカウントは設定した期限が到来すると期限切れになります。一時的な権限グループが付与されている場合、設定された期限が到来するとそのユーザーからは該当する権限が奪われます。

AAMの全ての機能をご紹介すると記事の主旨から外れてしまうので省略しますが、その豊富な機能の詳細をもっと知りたいという方はAdvanced Access Managerのドキュメンテーションをご覧ください。

ヒント：Advanced Access Managerの代替ツールにはUser Access Managerがあります。ただし、機能はAAMより少なく、アップデートも頻繁に行われていません。

User Switching

User Switchingもまた、ワンクリックでWordPressユーザーアカウントを切り替えられるプラグインです。たくさんの権限グループや権限を試す場合このプラグインを使えばかなりの時間を節約できます。User SwitchingはWordPressに元から備わっているクッキー認証システムを利用して切り替える前のアカウントを記憶し、すぐに戻すことができる仕組みです。

プラグインをインストール、有効化した後に、管理画面の「ユーザー」メニューを開きます。各ユーザーのところに「切り替え」というリンクが表示されます。クリックすると好きなユーザーに切り替えることができます。

管理画面もしくはユーザープロフィール画面に表示される「に戻す」というリンクをクリックすると元のアカウントに戻すことができます。

「切り替えを元に戻す」をクリックすると管理者アカウントを一時的に切り替え、訪問者にフロントエンドがどのように表示されるかを確認できます。

安全策として、ユーザーを編集する権限を持つユーザーしかユーザーアカウントの切り替えができません。デフォルトでこの権限を持つのは、WordPressの、シングルサイトの場合は管理者のみで、マルチサイトの場合は特権管理者のみです。

さらに切り替え作業を簡素化するためにはAdmin Bar User Switchingという拡張機能をインストールして、管理バーに「Switch to user」リンクが表示されるようにすることもできます。

View Admin As

View Admin Asは権限グループ/権限管理の機能も備えた上級者向けの切り替えプラグインです。User Switchingとは異なり、管理バーにユーザー切り替えメニューを表示するのに拡張機能のインストールは必要ありません。View Admin Asでは、デフォルトで管理バーに全てのメインメニュー項目が表示されます。

その権限グループのユーザーが存在しない場合でも、既存のユーザーや権限グループ間を（権限を引き受けて）切り替えることができます。「Site visitor」のリンクをクリックすると、サイトのフロントエンドが表示され、ブラウザのタブを離れず通常のユーザーとしてサイトの機能を試せます。

View Admin Asでは一時的に自分の権限を変更することができます。従来の権限を破壊することなく切り替え、元の権限は失われません。

特定のユーザーアカウントに切り替えた後、画面の設定を直接メニューから編集することができます。フロントエンドとバックエンドの言語/地域を別々に切り替えることも可能です。

様々なオプションを組み合わせ同時に適用することができるため、特定の1つの閲覧方法に限定されません。

View Admin Asでは必要に応じて2つのオプションモジュールを有効にすることができます。

1つ目のモジュールでは全ての権限グループにデフォルトの画面を設定できるRole Defaults機能が追加できます。これを権限グループや個別のユーザー、将来的な新規ユーザーに適用することが可能です。

2つ目のモジュールではRole Manager機能を追加できます。このモジュールで加えた権限グループや権限への変更は永続的なものとなります。他の権限グループ編集のプラグインと異なり、このモジュールではユーザーを自動で他の権限グループに移行することで、ユーザーに付与された権限グループを削除できます。

この拡張機能についてもっと知りたい方はView Admin Asのドキュメンテーションをご参照ください。

MyKinstaの権限グループ

MyKinstaのマルチユーザー機能では、同一ユーザーアカウントで複数のユーザー権限を作成、管理しKinstaアカウントの独自の機能やKinstaでホストしている特定のサイトへのアクセス権を付与することができます。

様々な権限グループを選ぶことができ、ニーズに応じてユーザーのアクセス権限をカスタマイズできます。

最初のユーザーにはデフォルトで「企業の所有者」権限が付与されます。これは、最も権限の大きな権限グループであり、「企業の管理者」の全ての権限が付与されます。

「企業の所有者」は一度に一人しかなれませんが、必要に応じて他の「企業の管理者」に権限グループを移譲することはできます。そうすることで同時に、新しい（元々は「企業の管理者」である）「企業の所有者」にKinstaアカウントの所有権を譲渡することになります。

Kinstaにアカウントの削除を依頼できるのは「企業の所有者」だけです。

他の権限グループも大きく2つの権限グループカテゴリーに分けることができます。

• 企業レベル
• サイトレベル

企業レベルの権限グループはKinstaアカウントの企業レベルの情報にアクセスできます。一方、サイトレベルの権限グループは、ユーザーに割り当てられた特定のサイトにのみアクセスできます。新しいユーザーを招待する時や、既存のユーザーを編集する時に最初に考慮すべきは「企業」レベルのアクセスを付与するか、「サイト」レベルのアクセスを付与するかです。

企業レベルの権限グループ

企業の管理者

企業の管理者はMyKinstaでもっとも高い権限レベルのグループです。Kinstaのアカウントと全てのサイトに対する完全な管理権限を持ちます。この権限グループは信頼できる人物にしか付与してはいけません。

企業の開発者

 

企業の開発者はサイトの削除を含め全てのサイトの管理権限が付与されています。MyKinstaの権限グループはヒエラルキーに基づいているので、企業の開発者はサイトレベルのユーザーの管理権限も持ちます。ただし、企業の開発者は、企業の設定や支払い情報にはアクセスできません。

企業の課金担当者

企業の課金担当者には、企業の支払い情報と設定画面のみへのアクセス権が付与されます。いずれのサイトへのアクセス権も持ちません。企業の課金担当者の権限グループのユーザーは請求書の確認、自動請求メールの有効化、 所在地や連絡先など企業情報の変更が可能です。

サイトレベルの権限グループ

サイトの管理者

サイトの管理者には、サイトに紐づいた全ての環境（本番、ステージング）を含め、特定のサイトの完全なアクセス権が付与されます。ただし、企業のアカウントからサイトを削除することはできません。同一のユーザーを複数のサイトにおけるサイトの管理者として割り当てることも可能です。

サイトの開発者

サイトの開発者は割り当てられたサイトのステージング環境にのみアクセスできます。ステージング環境ではなんでもできますが、ステージング環境を削除したり、変更点を本番環境に反映したりすることはできません。サイトの管理者と同じように、同一のユーザーに、複数のサイトにおける、サイトの開発者という権限を付与することも可能です。

またサイトの開発者はMyKinsta管理画面内の分析、ユーザー管理、活動記録機能にもアクセスできません。

MyKinstaの権限グループとWordPressの権限グループ

MyKinstaとWordPressの権限グループの間に重複はありません。それぞれ独立して利用することができます。

KinstaアカウントのオーナーにとってはMyKinstaのマルチ権限グループ機能は管理者、開発者、経理担当者のチームの管理にとても便利です。ウェブ開発エージェンシーにとっては、一つの充実した管理画面で全ての顧客のサイトを簡単に管理できる非常に便利なツールです。

まとめ

WordPressの権限グループと権限はユーザーアクセス管理を支える基本的なコンセプトです。サイト上のユーザーがどのような行動をとれるかをコントロールすることができます。また多くのプラグインやテーマにも使われていて、WordPressのコアに非常に便利な機能を加えています。

WordPressにはデフォルトで権限グループと権限が設定されていますが、さらに柔軟性が必要な場合はそれらをカスタマイズしたり、独自のものを作成したりすることも可能です。コードを自分で記述することも、外部のプラグインを活用することもできます。

権限グループと権限について理解し、その管理の仕方を知ることはWordPressをマスターする上で重要なステップです。今すぐ覚えて活用しましょう！