Members vs. Kakapo Roles：実効性のある権限管理
権限管理プラグインは、ただ1つの問いで評価されます。誰も管理画面をクリックしていないときでも、その権限は有効か、です。「非表示」と呼ばれるものの多くは表示を変えるだけで、データは REST API へのアクセス1回で取得できる状態のままです。この比較では、その観点で Members と Kakapo Roles を整理します。
短い答え
Members は定評ある無料の権限管理プラグインです。ロールの作成と編集、権限の割り当て、ロールごとのコンテンツ保護ができます。軽量で広く普及しており、たいていの単純なケースには十分です。
Kakapo Roles は、もう一段深いところから取り組みます。ロールと権限だけでなく、ユーザーが管理画面でそもそも何を目にするか（管理メニュー、メディアライブラリ、ウィジェット、ショートコード）も管理し、表示ルールを REST API でも明示的に適用します。さらに、変更履歴、削除したロールのためのゴミ箱、インポート／エクスポートも備えています。
まとめると、ロールを作成してコンテンツを保護したいなら、Members で十分に対応でき、費用もかかりません。クライアントに整理された管理画面を渡したい、権限を追跡できる形で記録したい、ルールが見た目だけに作用するのを防ぎたいなら、Kakapo Roles のほうが適しています。
どちらにもできること
- 独自のロールの作成、名前の変更、削除
- ロールごとの権限設定。カスタム投稿タイプの権限も含む
- 個々のユーザーへの権限の追加付与や取り消し
- コンテンツを特定のロールに限定する
- ユーザーごとの複数ロール
ここまでは、どちらを選ぶかは好みの問題です。面白くなるのはここから先です。
両者の違い
| 問い | Members | Kakapo Roles |
|---|---|---|
| 価格 | 無料 | 有料プラグイン、1つのライセンスで9つ |
| REST API 経由でも投稿の権限を適用 | 要確認 | はい、明示的に適用 |
| ロールごとに管理メニューを非表示 | 拡張機能で | 標準搭載 |
| メディアライブラリを自分のファイルに限定 | 拡張機能で | 標準搭載 |
| ロールごとのウィジェットとナビゲーションメニュー | — | 標準搭載 |
| ロールごとにショートコードを許可 | — | 標準搭載 |
| ロールごとのログイン後のリダイレクト | — | 標準搭載 |
| 削除したロールのゴミ箱 | — | はい、復元可能 |
| 変更履歴 | — | はい、誰がいつどの権限を変更したか |
| 権限のインポートとエクスポート | — | はい、ファイルとして |
| 権限昇格の防止 | 要確認 | get_editable_roles に準拠、ネットワークでも |
| 複数のサイト | サイトごとに個別 | リモートステータスと、すべてに1つのライセンス |
重要な違い：非表示はロックではない
投稿を「特定のロールだけ」に表示したい場合、実現方法は2つあります。1つは、一覧やフロントエンドで非表示にする方法です。もう1つは、アクセスを拒否する方法で、誰もクリックしない場所も含め、あらゆる場所で拒否します。
この違いは細かな話ではありません。WordPress の REST API は初期状態でアクセス可能で、/wp-json/wp/v2/posts にアクセスすれば、ログインなしで投稿が JSON として返されます。表示を変えるだけのルールは、そこでは無力です。「会員限定」のはずだったコンテンツが、平文でレスポンスに含まれてしまいます。
そこで Kakapo Roles は、表示ルールを REST API でも適用します。この1行こそ、権限管理プラグインをそもそも検証できる理由です。ログアウトした状態で、保護したアドレスを一度 JSON として呼び出してみてください。そこに内容が表示されれば、そのルールは何も保護していません。
このテストは、今使っているものを含め、どのプラグインでも行えます。投稿を保護し、ログアウトして、/wp-json/wp/v2/posts?search=… にアクセスします。1分で済み、どんな機能一覧よりも多くのことを教えてくれます。2つ目の落とし穴：誰が権限を付与できるか？
管理画面にアクセスできる人なら誰でも自分にさらに権限を与えられるような権限管理プラグインは、自らの存在意義を失っています。WordPress にはそのためのチェック機構があります。get_editable_roles() が、誰がどのロールを編集できるかを決めています。これを無視するプラグインは、塞ぐべき道をまさに開いてしまいます。
マルチサイトのネットワークで運用する場合は、もう1つ問いが加わります。そこではロールの一部がネットワーク全体で共有されています。サブサイトからそれを上書きすると、すべてのサイトで変更されます。Kakapo Roles は、このチェック機構と、サイトとネットワークの境界の両方を守ります。
Members のほうが適している場合
- ロールと権限が必要で、それ以外は要らない
- 予算がゼロ
- 単一のサイトで、ユーザーも少ない
- 1つのことだけを行うプラグインがほしい
Kakapo Roles のほうが適している場合
- クライアントに管理画面を渡すので、メニュー、メディアライブラリ、ウィジェットを整理したい
- 保護したコンテンツを REST API 経由でも保護したい
- 誰がいつどの権限を得たかを証明できる必要がある
- 権限の構成を一度作り、他のサイトにも移したい
- いずれにしても他の Kakapo プラグインを使っていて、請求書を5枚ではなく1枚にしたい
乗り換え：やるべきこと
- どの独自ロールがあり、それぞれにどの権限が付いているかを書き留めます。マトリクスのスクリーンショットで十分です。
- バックアップを作成します。権限はデータベースに保存されており、1つの誤操作がすべてのユーザーに同時に影響します。
- Kakapo Roles をインストールし、ライセンスキーを入力します。
- ロールを作り直し、マトリクスをメモと1行ずつ照らし合わせます。
- ロールごとにテストユーザーでログインし、実際に何が見えるかを確認します。
- 保護したコンテンツについて REST テストを行います。
- それが済んでから旧プラグインを停止します。削除はせず、2週間そのままにします。
権限管理プラグインを2つ同時に使うのは、よくない状態です。どちらも同じロールに書き込み、最後に保存した方が勝ちます。移行期間は短くし、その間はどちらか一方でだけ変更してください。