WordPressサイトは誰のもの？｜管理者と編集者の役割から考える権限設計
1. 結論｜権限設計はセキュリティだけではなく、運用設計でもある
WordPressの権限管理というと、「誤操作を防ぐため」「セキュリティ対策のため」という印象を持つ方が多いかもしれません。
もちろん、それも間違いではありません。
しかし実際に企業サイトや店舗サイト、複数人で運営するWebサイトを制作・保守していると、権限設計はそれだけではないことが分かります。
誰が、どこまで編集できるべきか。
これは、そのサイトをどのように運用していくのかという「運用設計」そのものです。
ライターは記事だけ更新できればよい
店舗スタッフは営業時間だけ変更できればよい
社内担当者は固定ページは編集できるが、サイト全体のデザインは変更してほしくない
制作会社だけがテーマやプラグインを更新する
例えば、このような役割分担は、多くのサイトでごく自然に行われています。
一方で、最初から全員をAdministratorにしてしまうケースも少なくありません。
確かに管理は楽です。しかし、それでは「誰でも何でも変更できる」状態になります。
サイト全体のデザインが変わる。
テンプレートが書き換わる。
テーマやプラグインが更新される。
場合によっては、他のユーザーを追加・削除することもできます。
近年のWordPressでは、ブロックテーマやSite Editorの普及によって、編集できる対象が大きく広がりました。
記事や固定ページだけではなく、サイト全体の構造やデザインに関わる要素まで管理画面から編集できます。
テンプレート
テンプレートパーツ
パターン
ナビゲーション
グローバルスタイル
そのため、「Administratorなら管理者」「Editorなら編集者」という単純な役割分担だけでは、適切なサイト運用を設計することが難しくなっています。
さらにWordPressでは、Role（権限グループ）とCapability（実際に実行できる操作）を分けて考える仕組みになっています。
権限の判定はCapabilityを基準に行われ、投稿やユーザーなど対象ごとの権限確認では、map_meta_cap()によって必要なCapabilityへ変換されて判定されます。
つまり、WordPressが本当に見ているのは "AdministratorかEditorか"というRoleではなく、その操作を実行するCapabilityを持っているかです。
この記事では、RoleやCapabilityの一覧を紹介することが目的ではありません。
WordPressサイトは誰のものなのか。
その視点から、権限設計をどのように考えれば、安全で運用しやすいサイトになるのかを整理していきます。
これからWordPressサイトを構築する方はもちろん、すでに運用しているサイトを見直したい方にも、設計の1つの考え方として役立ててもらえれば幸いです。
2. WordPressサイトは誰のもの？
WordPressサイトは、管理者だけが使うものではありません。
実際の運用では、一つのサイトにさまざまな立場の人が関わります。
例えば、制作会社がサイトを構築し、公開後は、企業の担当者が日々の更新を行うケースがあります。
また、記事の執筆はライター、内容の確認は編集者、商品の登録は店舗スタッフが担当するなど、それぞれの役割が分かれていることもぜんぜん珍しくありません。
つまり、WordPressサイトは一人で管理するものではなく、複数人で運用するものと考える場面が多くあります。
そのような環境で重要になるのが、「誰が、何を担当するのか」を明確にすることです。
例えば、ライターに求められるのは記事を書くことです。
サイト全体のデザインを変更したり、テーマを更新したりする必要はありません。
一方、企業の広報担当者であれば、固定ページの内容を更新する機会はあっても、テンプレートやグローバルスタイルを編集する必要はないでしょう。
制作会社や保守担当者は、テーマやプラグインの更新、サイト全体の設定変更を行いますが、日々の記事更新までは担当しないこともあります。
このように考えると、「全員が管理者（Administrator）である必要はない」ということがわかってきます。
権限を広く与えれば自由度は高まります。しかし、その自由度は誤操作のリスクにもつながります。
例えば、誤ってテンプレートを編集してしまい、サイト全体のレイアウトが崩れることがあります。
不要なプラグインを停止してしまい、機能が動かなくなることもあります。
さらに、ユーザー管理の権限があれば、他のユーザーの削除や権限変更まで行えてしまいます。
もちろん、担当者を信用していないから権限を制限するわけではありません。むしろ逆です。
その人が担当する仕事に集中できる環境を作ることが、適切な権限設計であると考えます。
記事を書く人には記事を書くための画面だけを。
店舗スタッフには商品や営業時間を更新するための画面だけを。
サイト全体の管理は、管理者や保守担当者が責任を持って行う。
役割を明確に詳細に分けることで、操作ミスを減らし、運用も分かりやすくなります。
近年のWordPressでは、Site Editorの登場によって、管理画面から編集できる範囲が大きく広がりました。
以前はテーマファイルを編集しなければ変更できなかった部分も、現在ではテンプレートやテンプレートパーツ、パターン、ナビゲーション、グローバルスタイルなどを管理画面から編集できるようになっています。
そのため、編集者だから記事だけを触るという従来のイメージだけでは、現在のWordPressを適切に運用することは難しくなっています。
まず考えるべきなのは、どのRoleを与えるかではありません。
このサイトでは、誰が、どこまで編集できるようにするのか。
その運用方針を決めたうえで、RoleやCapabilityを設計することが、現代のWordPressではますます重要になっていると考えています。
3. 「権限を与える」と「編集できる」は違う
WordPressでは、「Administrator」「Editor」「Author」といったRole（役割）が用意されています。
そのため、「Editorなら編集は全部できる」「Administratorなら何でもできる」と考えてしまいがちです。
しかし、実際のWordPressはもう少し細かい仕組みで動いています。
WordPressが実際に判定しているのは、RoleではなくCapability（実行できる権限）です。
Roleは、Capabilityをまとめた役割のセットに過ぎません。
Role（役割）
│
▼
Capability（実行できる権限）
│
▼
実際にできる操作
（投稿編集・固定ページ編集・テンプレート編集 など）
例えばEditorには、投稿や固定ページを編集するためのCapabilityが複数割り当てられています。
一方でAdministratorには、それらに加えてテーマやプラグイン、ユーザー管理などのCapabilityも含まれています。
つまり、WordPressが確認しているのは、
「この人はEditorか？」
ではなく、
「この操作を実行するCapabilityを持っているか？」
ということです。
これは、WordPressの権限設計を理解するうえで、最も重要な考え方と言ってもよいと思います。
例えば、「記事だけ更新してほしい」という運用を考えてみます。
この場合、本当に必要なのは記事を編集・公開するためのCapabilityです。
テンプレートを編集する権限は必要ありません。
テーマを変更する権限も必要ありません。
プラグインを更新する権限も必要ありません。
逆に、「会社概要ページは更新してほしいが、デザインは変更してほしくない」というケースもあります。
固定ページは編集できても、グローバルスタイルやテンプレートまで編集できる必要はありません。
このように考えると、「Editor」を付与するかどうかではなく、
「その担当者は何を担当するのか」
から設計を始めるべきだということが分かります。
さらに、WordPressでは一部の権限は投稿やユーザーなどの対象に応じて動的に判定されます。
例えば、投稿を編集できるという一つの操作でも、自分が作成した投稿なのか、他人が作成した投稿なのかによって、必要になるCapabilityは変わります。
こうした判定は、WordPress内部のmap_meta_cap()という仕組みによって行われています。
つまり、投稿を編集できるという一つの操作であっても、内部では複数のCapabilityへ変換され、そのユーザーが実行できるかどうかを判断しています。
そのため、Roleだけを見て運用を考えると、「思っていたより編集できた」「逆に編集できなかった」という状況が発生します。
WordPressの権限設計では、下記の三つを分けて考えることが大切です。
Roleは役割
Capabilityは実際に許可される操作
操作内容によってはWordPressが内部で必要なCapabilityを判定する
「Editorだからここまでできる」という考え方ではなく、
「この担当者には何を任せたいのか。そのためにはどのCapabilityが必要なのか。」
この順番で考えることが、実際のサイト運用では重要になります。
4. CapabilityとUIの違い
WordPressでは、「画面に表示されていること」と「実際に操作できること」は同じではありません。
これは権限設計で最も誤解されやすいポイントの一つです。
例えば、管理画面に「投稿」メニューが表示されていても、投稿を編集するためのCapabilityを持っていなければ、投稿を編集することはできません。
逆に、管理画面からメニューを非表示にしても、その機能を操作するためのCapabilityを持っていれば、適切な画面へアクセスして利用できます。
つまり、「見える」と「できる」は別の話です。
UIは「見せる・見せない」
管理画面のメニューや通知、ボタンなどは、ユーザーインターフェース（UI）の一部です。
例えば、
管理画面メニュー
更新通知
ダッシュボードウィジェット
管理バー（ツールバー）
「新規追加」ボタン
Site Editorへの導線
これらは、「利用者に何を見せるか」を決めるための仕組みです。
運用しやすくするために不要なメニューを非表示にしたり、更新通知を表示しないようにしたりすることがあります。
しかし、これらはあくまでも画面表示を調整しているだけで、ユーザーが持つ権限そのものを変更しているわけではありません。
Capabilityは「できる・できない」
一方で、Capabilityは「その操作を実行できるかどうか」を判断するための仕組みです。
例えば
投稿を編集する
固定ページを編集する
テーマを変更する
プラグインを更新する
ユーザーを追加する
といった操作は、Capabilityによって許可・拒否が決まります。
WordPressは画面を表示するときだけではなく、実際に処理を実行するタイミングでもCapabilityを確認しています。
そのため、必要なCapabilityを持っていなければ、URLを直接開いたとしても操作は許可されません。
反対に、Capabilityを持っていれば、UIでメニューを非表示にしていても、その機能を利用できる場合があります。
つまり、本当の意味での「できる・できない」を決めているのは、Capabilityです。
UIだけを変更しても権限は変わらない
例えば、企業サイトでは「外観」メニューを非表示にして運用することがあります。
これによって担当者が誤ってテーマ設定を開くことを防ぎ、管理画面も分かりやすくなります。
しかし、これはUIを整理しているだけです。
テーマを操作するためのCapabilityを持っているユーザーであれば、メニューが表示されていなくても、その機能を利用できます。
一方で、Capabilityを持っていないユーザーは、たとえ関連する画面へアクセスしようとしても、WordPressが権限を確認し、操作は許可されません。
つまり、メニューを隠すことと、権限を制限することは別の話です。
権限設計では、まずCapabilityを適切に設定し、そのうえで利用者に合わせてUIを整理するという順番で考えることが重要です。
Site Editor時代は、この違いがさらに重要になった
ブロックテーマでは、テンプレートやテンプレートパーツ、パターン、ナビゲーション、グローバルスタイルなど、多くの機能がSite Editorに集約されています。
そのため、「Site Editorを表示するか」というUIの話と、「Site Editorで何を編集できるか」という権限の話は分けて考える必要があります。
管理画面を見やすく整理することは大切ですが、それだけで権限設計ができたことにはなりません。
複数人で運用するサイトでは、担当者ごとに必要なCapabilityを設定し、その役割に合わせてUIを整えることが、安全で分かりやすい運用につながります。
権限設計は「Capability」、使いやすさは「UI」
私は、権限設計を考えるときは、次の順番で整理しています。
誰が何を担当するのかを決める
必要なCapabilityを設定する
利用者に合わせてUIを整理する
この順番を逆にすると、
「メニューは表示されていないのに操作できる」
「画面は見えているのに何もできない」
といった、利用者にとって分かりにくい管理画面になってしまいます。
WordPressでは、
Capabilityが「できる・できない」を決め、
UIは「見せる・見せない」を決める。
この違いを理解することが、権限設計の第一歩です。
5. Site Editor時代の権限設計
WordPressの権限設計が大きく変わった理由の一つが、Site Editor（サイトエディター）の登場です。
従来のクラシックテーマでは、管理画面から編集する対象は比較的限られていました。
記事
固定ページ
メニュー
ウィジェット
カスタマイザー
一方、ブロックテーマでは、サイト全体を構成する要素の多くをSite Editorから編集できます。
例えば、次のようなものです。
つまり、記事を書くためのエディターと、サイト全体を編集するSite Editorが同じ「編集」という言葉で表現されていても、その意味はまったく異なります。
コンテンツ編集とサイト編集は役割が違う
例えば、企業サイトを考えてみましょう。
広報担当者には、お知らせやブログ記事を更新してもらいたい。
しかし、会社のヘッダーやフッター、サイト全体の配色まで変更できるようにしたいでしょうか。
多くの場合、答えは「いいえ」です。
これまでのWordPressでは、「記事を編集する人」と「サイトを設計する人」は、ある程度分かれていました。
しかしSite Editorでは、サイト全体を構成する要素も管理画面から編集できるようになったため、この役割の違いを意識した権限設計がこれまで以上に重要になっています。
Site Editorの権限はRoleだけでは判断できない
「EditorならSite Editorを使えるのか。」
「Administratorだけが使えるのか。」
このようにRoleだけで考えたくなりますが、実際にはそれほど単純ではありません。
WordPressは、RoleではなくCapabilityによってアクセス可否を判断しています。
また、Site Editorの各機能も、内部では複数のCapabilityを利用して権限を確認しています。
そのため、
Site Editorへアクセスできるか
テンプレートを編集できるか
ナビゲーションを管理できるか
デザインを変更できるか
といった内容は、「Editor」だから、「Administrator」だからというだけでは判断できません。
運用内容に合わせて、どの操作を誰に任せるのかを考えることが重要です。
「編集できる」は一つではない
近年のWordPressでは、「編集」という言葉が指す対象が増えています。
例えば、
記事を編集する
固定ページを編集する
パターンを編集する
テンプレートを編集する
グローバルスタイルを変更する
これらはすべて「編集」ですが、サイトへの影響は大きく異なります。
記事を編集しても一つの記事だけが変わります。
しかしテンプレートやテンプレートパーツを変更すると、サイト全体の表示が変わることがあります。
グローバルスタイルを変更すれば、すべてのページの色や文字サイズに影響する可能性があります。
つまり、「編集」という言葉だけでは、どこまで変更できるのかを判断できない時代になっています。
Site Editor時代に考えるべきこと
Site Editorが普及した現在は、Roleを決めることよりも先に、担当者ごとの役割を整理することが重要です。
例えば、
ライターは記事だけ更新する。
広報担当者は固定ページも編集する。
制作会社はテンプレートやデザインを管理する。
サイト管理者はテーマやプラグイン、ユーザー管理を担当する。
このように役割を整理したうえで、必要なCapabilityとUIを設計していくことが、安全で運用しやすいサイトにつながります。
Site Editorは、サイトを柔軟に編集できる非常に便利な機能です。
その一方で、従来よりも編集できる範囲が広がったからこそ、「誰に何を任せるのか」をこれまで以上に意識した権限設計が求められています。
6. 権限を実現する方法
ここまで、「誰に何を任せるのか」を決めることが、権限設計の第一歩だと説明してきました。
では、その設計をWordPressではどのように実現するのでしょうか。
方法はいくつかありますが、それぞれ役割が異なります。
標準のRoleを利用する
もっとも基本となるのが、WordPressに用意されている標準のRoleです。
Administrator
Editor
Author
Contributor
Subscriber
小規模なサイトであれば、標準のRoleだけでも十分運用できる場合があります。
しかし、企業サイトや複数人で運用するサイトでは、「もう少し細かく制御したい」という場面が少なくありません。
例えば、
記事は公開できるが、固定ページは編集させたくない
商品だけ編集できるようにしたい
Site Editorには入れたくない
といった要件は、標準のRoleだけでは対応できないことがあります。
Capabilityを追加・変更する
WordPressでは、Roleそのものではなく、Roleが持つCapabilityを変更することができます。
Capabilityを追加する
Capabilityを削除する
独自Roleを作成する
といったことが可能です。
つまり、「Editorを作るかどうか」ではなく、「この担当者には何が必要か」を基準に設計できます。
企業サイトでは、この考え方が非常に重要になります。
コードで制御する
さらに細かな要件では、コードによる制御が必要になることがあります。
例えば、
add_role()
add_cap()
remove_cap()
current_user_can()
などを利用することで、独自の権限設計を実装できます。
また、WordPressでは map_meta_cap() によって、「投稿を編集する」「固定ページを削除する」といった操作に対して、内部で必要なCapabilityへ変換し、権限を判定しています。
そのため、独自機能を開発する場合も、current_user_can() によるCapabilityチェックを行うことが推奨されています。
UIは別に制御する
前章で説明したように、CapabilityとUIは別の仕組みです。
例えば、
管理画面メニューを非表示にする
更新通知を表示しない
ダッシュボードを整理する
管理バーをカスタマイズする
といった内容は、運用しやすさを考えたUIの調整です。
これらは利用者にとって分かりやすい管理画面を作るために有効ですが、権限そのものを変更するものではありません。
そのため、
Capabilityで「できる・できない」を決め、
UIで「見せる・見せない」を整理する。
という考え方が基本になります。
権限管理プラグインを利用する
コードを書かずに権限設計を行いたい場合は、権限管理プラグインを利用する方法もあります。
現在でも広く利用されている代表的なプラグインとして、次の2つがあります。
どちらも現在も継続的にメンテナンスされており、WordPress最新版への対応が続けられています。
theme.jsonは権限管理ではない
ブロックテーマでは、theme.jsonを利用してエディターの設定を細かく制御することができます。
例えば下記のことが可能です。
カラーパレットを制限する
フォントサイズを制限する
スペーシングを制御する
ブロック機能を制限する
しかし、theme.jsonはテーマの機能やエディターの挙動を定義する仕組みであり、ユーザーごとの権限を管理するものではありません。
「利用できる機能を制御すること」と「誰が操作できるかを制御すること」は別の役割です。
そのため、theme.jsonだけで権限設計を行うことはできません。
方法を選ぶ前に、設計を決める
権限設計では、「どの方法を使うか」を先に考えがちです。
しかし、本当に重要なのは、誰が、何を担当するのか。
これを決めることです。
その設計が決まれば、
標準Roleで対応できるのか
Capabilityを調整するのか
コードを書くのか
プラグインを利用するのか
という実装方法は自然に決まってきます。
WordPressにはさまざまな権限管理の方法がありますが、それらはすべて「運用設計を実現するための手段」です。
手段から考えるのではなく、運用から考えることが、失敗しない権限設計につながります。
7. ケーススタディ｜サイトに合わせた権限設計を考える
ここまで、RoleやCapabilityの仕組みについて説明してきました。
しかし実際の現場では、Editorを使うべきか？、Administratorを何人にしたら良いのか？という単純な話では終わりません。
サイトの目的や運用体制によって、最適な権限設計は変わります。
ここでは、よくある運用例をもとに、権限設計の考え方を紹介したいと思います。
個人ブログ
個人で運営するブログであれば、Administratorだけで運用しても問題になるケースは多くありません。
記事を書き、デザインを変更し、テーマやプラグインを更新するのも同じ人だからです。
ただし、日常的な記事の更新までAdministratorで行う必要があるかは別の話です。
誤操作のリスクを減らしたい場合は、普段はEditorやAuthorで作業し、設定変更や更新が必要なときだけAdministratorを利用するという運用も考えられます。
企業サイト
企業サイトでは、サイト全体の構成と日々の更新作業を分けて考えることが重要です。
広報担当者はニュースや会社概要を更新できれば十分であり、テンプレートやグローバルスタイルまで変更する必要はないケースがほとんどです。
また、ライターには記事作成だけを担当してもらい、公開は広報担当者が確認して行う、といった運用もよく採用されています。
制作会社が保守するサイト
制作会社が継続保守を行う場合は、「クライアントがどこまで編集できるか」を最初に決めておくことが重要です。
記事や固定ページは自由に更新できる
テンプレートやデザインは制作会社が管理する
テーマやプラグインの更新も制作会社が担当する
というように役割を分けることで、トラブルを防ぎやすくなります。
また、更新通知を誰に表示するかも、保守契約に合わせて設計すると運用が分かりやすくなります。
店舗サイト
店舗サイトでは、営業時間やキャンペーン情報、お知らせを更新する機会が多くあります。
一方で、サイトデザインやレイアウトを変更する必要はほとんどありません。
そのため、スタッフには必要な更新だけを任せ、それ以外の設定変更は管理者が担当する運用が適しています。
管理画面も設定に合わせ、シンプルに整理すると、日常業務の負担を減らすことができます。
社内広報・複数部署で運用するサイト
複数部署が記事を投稿する場合は、作成と公開を分ける運用が効果的です。
各部署は記事を作成し、広報部が内容を確認して公開することで、効率よく品質を維持しやすくなります。
WordPressの標準Roleでも、このようなワークフローを構築できます。
ECサイト
ECサイトでは、WordPress本体だけではなく、ECプラグインが独自のRoleやCapabilityを追加することが一般的にあります。
そのため、WordPress標準Roleだけで考えるのではなく、利用しているECプラグインの権限設計も合わせて確認する必要があります。
特に受注管理や顧客情報を扱う権限は、記事編集とは性質が異なるため、安全で慎重な設計が求められます。
「誰が何をするか」が決まれば、権限設計は見えてくる
ここまで見てきたように、Roleには決まった正解はありません。
企業サイトでも、会社によって必要な権限は異なります。
広報担当がすべて更新する会社
制作会社が保守する会社
部署ごとに担当者がいる会社
大切なのは、Roleから考えるのではなく、担当者の役割から考えることです。
「誰が、何を担当し、どこまで編集するのか。」
その運用が決まれば、必要なRoleやCapability、UIの設計も自然に決まっていきます。
権限設計とは、WordPressの設定ではなく、サイト運用そのものを設計することなのです。
8. 更新通知は誰に見せるべきか
WordPressの権限設計を考えるとき、意外と悩むのが「更新通知を誰に表示するか」という問題です。
プラグインやテーマ、WordPress本体に更新があるとき、管理画面には更新通知が表示されます。
しかし、その通知を見る人が、本当に更新を行う担当者とは限りません。
制作会社が保守を担当している企業サイトでは、クライアントがテーマやプラグインを更新することは想定していないケースが多くあります。
その場合、更新通知だけが表示されると、
「更新した方がいいのでは？」
「このままで大丈夫なのだろうか？」
と、不安を与えてしまうことがあります。
一方で、更新通知を完全に非表示にすることに対して、
「サイトに更新があることを運営担当者も把握しておくべきだ。」
「保守会社に任せていても、更新状況は見えた方が安心だ。」
このような意見もあります。
つまり、更新通知を表示するかどうかに、絶対的な正解はありません。
表示した方がよいケース
例えば、社内でサイトを管理している場合は、更新通知があることでメンテナンスのタイミングを把握できます。
また、小規模サイトや個人ブログでは、更新通知がそのまま作業のきっかけになることも多いでしょう。
更新を担当する人が通知を見ることには、大きな意味があります。
さらに、更新通知は単に「新しいバージョンがあります」と知らせるだけではありません。
WordPress本体やテーマ、プラグインは、機能追加だけでなく、不具合の修正やセキュリティ対策を含む更新が行われることがあります。
そのため、更新を担当する人が最新の情報を把握しておくことは、安全なサイト運用にもつながります。
また、複数人でサイトを運営している場合でも、「現在更新がある」という状況を共有できることで、保守担当者への連絡やメンテナンスの計画を立てやすくなるというメリットもあります。
つまり、更新通知は「すぐに更新するため」の情報だけではなく、「現在のサイトの状態を把握するため」の情報としても役立ちます。
更新作業を担当する人、あるいは更新の判断に関わる人にとっては、更新通知を表示することに十分な意味があると言えるでしょう。
非表示を検討してもよいケース
一方で、制作会社や保守会社が更新を担当するサイトでは、更新通知を一般の担当者へ表示する必要がない場合があります。
更新できない担当者に通知だけを見せても、判断や対応ができません。
その結果、「何か問題が起きているのではないか」という不安だけを与えてしまうことがあります。
また、利用しているテーマやプラグインによっては、更新の判断にライセンスや保守契約が関係する場合もあります。
例えば、有料テーマや有料プラグインでは、ライセンス契約やサブスクリプションの更新状況によって、アップデートの可否やサポート範囲が変わることがあります。
さらに、制作会社が独自にカスタマイズしたテーマでは、WordPress本体を更新する前に互換性の確認や動作検証が必要になるケースもあります。
このような環境では、「更新があります」という通知だけでは、実際に更新すべきかどうかを判断できません。
そのため、更新作業を担当しない利用者には通知を表示せず、更新を管理する担当者だけが状況を把握するという運用も、一つの考え方です
更新通知は「権限」の問題ではない
ここで注意したいのは、更新通知の表示は、Capabilityそのものとは別の話だということです。
更新通知を非表示にしても、テーマやプラグインを更新する権限が変更されるわけではありません。
逆に、通知が表示されていても、必要なCapabilityを持っていなければ更新は実行できません。
つまり、こういうことです。
更新できるかどうかはCapability。
更新情報を見せるかどうかはUI。
前章で説明した「4.CapabilityとUIの違い」という考え方は、更新通知にもそのまま当てはまります。
運用に合わせて考えることが大切
更新通知は、「表示する」「非表示にする」のどちらが正しいというものではありません。
重要なのは、そのサイトを誰が管理し、誰が更新を担当するのかという運用です。
更新を担当する人には、必要な情報として通知を表示する。
更新を担当しない人には、不要な混乱を避けるために表示を見直す。
このように、サイトの運用体制に合わせて設計することが、利用者にとって分かりやすい管理画面につながります。
更新通知は単なる表示の問題ではありません。
誰に、どの情報を届けるべきかを考えることも、権限設計の一部なのです。
9. 権限設計は 信頼 の設計
ここまで、RoleやCapability、Site Editor、UIとの違いなど、WordPressの権限設計についてお話してきました。
伝えたいのは、権限設計は単なる技術の話ではないということです。
私は、権限設計とは「信頼」と「責任」を設計することだと考えています。
信頼しているからAdministratorにする、ではない
WordPressでは、Administratorは最も強い権限を持つRoleです。
テーマやプラグインの管理、ユーザー管理、サイト設定の変更、Site Editorの利用など、サイト全体に関わる操作を行えます。
そのため、「この人は信頼しているからAdministratorにしよう」という考え方をすることがあります。
もちろん、その考え方も間違いではありません。
しかし、本来のAdministratorは、「信頼の証」として与えるRoleではありません。
サイト全体の管理に責任を持つ人のためのRoleです。
誰でもAdministratorにするのではなく、本当にその役割を担う人にだけ付与する。
その考え方が、長く安定したサイト運用につながります。
Administratorを増やしすぎると責任が曖昧になる
Administratorが増えるほど、サイト全体を変更できる人も増えます。
例えば、
テーマが変更された
プラグインが停止された
Site Editorでテンプレートが編集された
サイト全体のデザインが変更された
ユーザー権限が変更された
このような変更が行われたとき、Administratorが何人もいると、
「誰が変更したのか。」
「なぜ変更したのか。」
を把握しにくくなることがあります。
これはセキュリティだけの問題ではありません。
保守や運用の面でも、責任の所在が曖昧になり、トラブル対応や原因調査が難しくなることがあります。
また、複数人が自由に設定を変更できる環境では、「よかれと思って行った変更」が思わぬ不具合につながることもあります。
だからこそ、Administratorは必要最小限にするという考え方が、多くの現場で採用されています。
必要な権限だけを渡すことも信頼
権限を制限すると、「信用されていない」と感じる人がいるかもしれません。
しかし、本来の権限設計は、人を制限するためのものではありません。
例えば、
ライターには記事を書くための権限を。
広報担当者には固定ページやお知らせを更新するための権限を。
店舗スタッフには営業時間や商品情報を更新するための権限を。
制作会社にはサイト全体を管理するための権限を。
このように、それぞれの役割に必要な権限だけを与えることで、担当者は自分の仕事に集中しやすくなります。
同時に、誤操作のリスクも減らすことができます。
必要な権限だけを渡すことは、「できることを減らす」のではなく、「安心して任せられる環境を作る」ことでもあるのです。
信頼とは、責任を明確にすること
私は、権限設計とは、人を信用するかどうかの話ではないと思っています。
本当に大切なのは、「誰が、何に責任を持つのか」を明確にすること。
その役割に必要な権限を与え、それ以外は担当する人に任せること。
それぞれが自分の役割に集中できる環境を作ること。
これが結果として安全で運用しやすいサイトにつながります。
Administratorを増やすことは、信頼を増やすことではありません。
責任を持つ人を増やすことです。
だからこそ、権限設計では、必要な人に、必要な権限だけを与える。
この考え方を大切にしたいと私は考えています。
権限設計とは、人を信頼したり制限することではありません。
安心して任せられる環境を作ること。
それが、複数人で運用するWordPressサイトにおける、本当の「信頼」の設計ではないかと思います。
10. まとめ｜権限設計は、WordPressサイトの未来を設計すること
この記事では、RoleやCapabilityの仕組みだけではなく、Site Editor時代の権限設計について整理してきました。
最初にも書きましたが、私は権限設計を単なるセキュリティ対策とは考えていません。
もちろん、誤操作を防ぐことや、不正な変更を防ぐことも大切です。
しかし、それだけではありません。
「誰が、どこまで担当するのか。」
これを決めることは、そのサイトをどのように運用していくのかを決める大事なことでもあります。
WordPressは、一人でも使えるCMSです。
その一方で、企業サイトや店舗サイト、メディアサイトのように、多くの人が役割を分担しながら運営するプラットフォームでもあります。
だからこそ、全員をAdministratorにすることが正解とは限りません。
Editorだから安心という話でもありません。
Roleだけを見て、本当の権限設計はできません。
大切なのは、
誰がサイトを管理するのか。
誰が記事を書くのか。
誰が固定ページを更新するのか。
誰がSite Editorを扱うのか。
誰がテーマやプラグインを更新するのか。
こうした役割を整理し、それぞれに必要なCapabilityを設計することです。
さらに、利用者に合わせて管理画面のUIを整理すれば、迷わず操作できる、分かりやすい運用環境を作ることができます。
近年のWordPressでは、ブロックテーマやSite Editorの普及によって、「編集できる範囲」が以前とは比べものにならないほど広がりました。
記事だけではありません。
テンプレート。テンプレートパーツ。
パターン。ナビゲーション。
グローバルスタイル。
サイト全体を構成する要素まで、管理画面から編集できる時代です。
便利になった一方で、「誰に何を任せるか」を考えなければ、思わぬ変更や運用トラブルにつながることもあります。
だから、Roleより先に運用を、Capabilityより先に担当者を考えます。
そして最後に、その運用を実現するための仕組みとして、RoleやCapability、UIを設計します。
技術は、運用を実現するための手段です。
設計が先にあり、実装はそのあとです。
これはWordPressのテーマ制作でも、システム開発でも、考え方は変わりません。
今回の記事で紹介した内容は、あくまでも、現在のWordPressを基準とした考え方です。
WordPressは進化を続けています。
Site Editorも、権限周りも、今後さらに改善されていくことでしょう。
だからこそ大切なのは、個別の機能を覚えることではなく、「なぜその権限が必要なのか」を考えることです。
その考え方が身についていれば、新しい機能が追加されても、自分のサイトに合わせた権限設計ができるようになります。
私自身、テーマを制作する中で、「どうすれば利用者が安心して使えるだろう」と考える機会が何度もありました。
テーマを作ることと、サイトを運用することは別の話ではありません。
利用者が迷わず操作できること。
必要な人が、必要な作業だけを行えること。
安心して更新を続けられること。
そうした積み重ねが、使いやすいWordPressサイトにつながるのだと思っています。
もし、この記事を読んで「とりあえずAdministratorを付与していたな」と思い当たるところがあれば、一度立ち止まって考えてみてください。
このサイトでは、誰が何を担当するのか。
その答えが見えてくると、RoleやCapabilityの選び方も自然と見えてくるはずです。
権限設計とは、人を縛るためのものではありません。
人が安心して役割を果たせる環境を作ることです。
そして、それはサイトを長く安全に運営していくための土台でもあります。
WordPressはCMSです。
しかし、それだけではありません。
複数の人が、それぞれの役割を持ちながら、一つのサイトを育てていくためのプラットフォームでもあります。
その力を最大限に活かすためにも、Role、Capability、Site Editor、UIそれぞれを個別の機能としてではなく、サイト運用を支える設計として考えていく、それが、これからのWordPressにおける権限設計の基本になると、私は考えています。
いいなと思ったら応援しよう！
よろしければ応援お願いします！
いただいたチップはDeveloperとしての活動費に使わせていただきます！ 