WP-CLI では、権限グループ（ロール）に含まれる権限（capability）を wp cap で、権限グループそのものを wp role で、個々のユーザーに直接付けた権限を wp user add-cap などで操作できます。管理画面にはロールを編集する画面が無いため、プラグインを入れずに「編集者にメニュー編集だけ許可したい」「独自の権限グループを作りたい」といった調整をするなら WP-CLI が近道です。この記事では、確認・追加・削除の手順に加えて、変更がデータベースに残り続けることと、その戻し方を説明します。
最初に知っておきたい仕組み
WordPress の権限は「権限グループ」と「権限」の2段構えです。
- 権限（capability）…
edit_posts（投稿の編集）やmanage_options（設定の変更）のような、個々の操作の許可 - 権限グループ（role）… 権限をまとめたもの。標準では管理者（administrator）・編集者（editor）・投稿者（author）・寄稿者（contributor）・購読者（subscriber）の5つ
権限グループの定義は、データベースの wp_options テーブルにある wp_user_roles というオプションに保存されています（wp_ の部分はテーブル接頭辞に合わせて変わります。wp db prefix で確認できます）。ユーザーに直接付けた権限は、ユーザーメタの wp_capabilities に入ります。
ここで重要なのは、WP-CLI で行った変更はコードではなくデータベースに書き込まれるという点です。コマンドを実行した時点で変更は保存され、プラグインを無効化しても、WP-CLI を使わなくなっても元には戻りません。戻すには、逆の操作をするかバックアップから復元する必要があります。そのため、作業前には次のバックアップを取っておきます。
# データベース全体
wp db export before-roles.sql
# 権限グループの定義だけを JSON で保存
wp option get wp_user_roles --format=json > roles-backup.json変更はまずステージング環境で試し、意図どおりにメニューや操作が制限されるかを確かめてから本番に適用してください。
権限グループと権限を確認する
# 権限グループの一覧
wp role list
# 編集者が持つ権限の一覧
wp cap list editor
# 特定の権限グループが存在するか
wp role exists shop_managerwp role list には、標準の5つに加えて、WooCommerce などのプラグインが追加した権限グループも表示されます。wp cap list の結果は --format=json や --format=csv でも出力できるため、変更前後の差分を取るときに便利です。
wp cap list editor --format=csv > editor-before.csv権限グループに権限を追加・削除する（wp cap）
例として、編集者に「外観」メニューの操作（edit_theme_options）を許可します。メニューやウィジェットの編集に必要な権限です。
wp cap add editor edit_theme_options複数の権限をまとめて追加することもできます。
wp cap add editor edit_theme_options list_users取り消すときは wp cap remove を使います。
wp cap remove editor edit_theme_options権限名の綴りを間違えても、WordPress は新しい名前の権限として登録してしまい、エラーにはなりません。追加したのに効かないときは、wp cap list で綴りを見直してください。また、edit_theme_options のようなコアの権限名は WordPress の開発者向けドキュメントの「Roles and Capabilities」で確認できます。
管理者から重要な権限を外さない
wp cap remove administrator manage_options のように管理者から設定系の権限を外すと、管理画面の多くのメニューに入れなくなります。誤って外した場合でも WP-CLI はデータベースを直接操作できるため、wp cap add administrator manage_options で戻せます。管理画面からは戻せないケースがあることを覚えておいてください。
独自の権限グループを作る（wp role create）
既存の権限グループをコピーして、新しい権限グループを作れます。
# 編集者をコピーして「サイト担当者」を作成
wp role create site_manager 'サイト担当者' --clone=editor
# 追加で外観の操作を許可
wp cap add site_manager edit_theme_options1つ目の引数はプログラム上で使う識別子（英数字とアンダースコア）、2つ目は管理画面に表示される名前です。作成した権限グループは、ユーザーに割り当てて使います。
wp user set-role 12 site_managerset-role はそのユーザーの既存の権限グループを置き換えます。今の権限グループを残したまま追加したい場合は wp user add-role を使います。
権限グループを削除する（wp role delete）
# 削除する前に、その権限グループのユーザーがいないか確認
wp user list --role=site_manager
wp role delete site_manager所属ユーザーが残ったまま削除すると、そのユーザーは権限グループを失い、ログインしても何も操作できない状態になります。先に wp user set-role で別の権限グループへ移してから削除してください。
標準の権限グループを初期状態に戻す（wp role reset）
編集者などの標準の権限グループをいじりすぎて元の状態が分からなくなった場合は、wp role reset で WordPress の初期状態に戻せます。
wp role reset editor対象にできるのは標準の5つの権限グループだけです。また、初期状態に戻すと、プラグインが後から追加した権限も消えます。たとえば EC やフォーム系のプラグインが管理者に独自の権限を追加している場合、wp role reset administrator を実行するとその権限が外れ、プラグインの管理画面に入れなくなることがあります。プラグインを無効化して再度有効化すると権限が付け直されるものもありますが、動きはプラグインによって異なります。リセットよりも、先ほど保存した JSON から戻すほうが安全な場合も多いです。
wp option update wp_user_roles --format=json < roles-backup.jsonユーザー単位で権限を付ける（wp user add-cap）
権限グループではなく、特定のユーザーだけに権限を付けることもできます。
# ユーザーID 12 に権限を追加
wp user add-cap 12 edit_theme_options
# そのユーザーが持つ権限を一覧
wp user list-caps 12
# 取り消し
wp user remove-cap 12 edit_theme_optionsユーザー単位の権限は、権限グループを変えても残り続けます。数か月後に「なぜこの人だけ操作できるのか」が分からなくなりやすいため、基本は権限グループで管理し、ユーザー単位の付与は一時的な対応にとどめるのがおすすめです。
変更が効いているか確かめる
権限が意図どおりに働いているかは、wp eval と user_can() で確認できます。
wp eval 'var_dump( user_can( 12, "edit_theme_options" ) );'bool(true) なら付与されています。最終的には、そのユーザーで実際にログインして、メニューの表示と操作を確かめてください。マルチサイトでは権限グループの設定がサイトごとに保存されているため、--url=https://example.com/sub/ で対象サイトを指定して実行します。
利用できるサブコマンドやオプションは WP-CLI のバージョンで異なる場合があるため、wp help cap・wp help role・wp help user で手元の環境を確認してください（2026年10月現在）。
まとめ
- 権限グループ内の権限は
wp cap list/add/remove、権限グループ自体はwp role list/create/delete/resetで操作する - 特定ユーザーへの権限は
wp user add-cap/remove-cap/list-caps - 変更はデータベースの
wp_user_rolesオプションやユーザーメタに保存され、コマンドを止めても残り続ける - 作業前に
wp db exportとwp option get wp_user_roles --format=jsonでバックアップし、ステージングで試してから本番に適用する wp role resetは標準の5つだけが対象で、プラグインが追加した権限も消える点に注意する