WordPress採用サイトの権限設計｜顧客に渡す操作の決め方

WordPressの採用サイトを顧客へ引き渡すとき、最初から「管理者か編集者か」を選ぶと、必要な操作と渡し過ぎた操作が混ざりやすくなります。先に、誰がどの情報を更新し、誰が公開を承認し、誰がサイト全体を保守するかを分け、その作業に必要な権限を割り当てます。

まだ顧客が更新する対象を決めていない場合は、先に採用サイトで何をCMS化するか｜更新範囲の決め方で、定型CMS、固定ページ、制作者対応の範囲を整理してください。受注から公開・引き渡しまでの全体順は、WordPress採用サイトの制作・引き渡しチェックリストで確認できます。本記事では、その次に行うWordPress内の権限設計へ絞ります。

結論：role名ではなく、操作と影響から決める

権限を決めるときは、利用者ごとに次の四つを確認します。

1. 対象：求人、社員、インタビュー、固定ページ、画像、Navigation、設定等のどれを扱うか
2. 操作：作成、編集、下書き、公開、終了、削除、設定変更、更新のどこまで行うか
3. 影響：一つの内容だけが変わるのか、サイト全体、他の利用者、外部サービスまで変わるのか
4. 確認：誰が公開結果を確認し、問題時に停止・復元するか

日常更新用のアカウントと、サイト全体を管理・復旧するためのアカウントは、同じである必要はありません。顧客がサイトの管理主体であることと、採用担当者が毎日管理者権限で作業することも別の問題です。日常操作、所有・引き継ぎ、技術保守を分けて記録します。

採用サイトの責任を四つに分ける

一人が複数の責任を持つ場合でも、引き渡し資料では役割ごとに分けます。

責任	主な作業	WordPress外も含む確認
採用コンテンツ更新	求人・社員・インタビュー・固定ページの入力、下書き、画像差し替え	正式情報の確認者、素材の利用許可
公開承認	公開、募集終了、非公開、応募導線の確認	募集条件、応募先、プライバシー情報
WordPress技術管理	ユーザー、設定、テーマ、プラグイン、WordPress本体、復旧	保守範囲、変更記録、更新前後の確認
基盤・外部サービス管理	サーバー、ドメイン、SSL、バックアップ、フォーム、メール	契約主体、請求、障害時連絡先、復元手順

WordPressの管理者権限だけでは、サーバー、ドメイン、メール等を管理できません。反対に、サーバーの契約者が採用情報を公開してよいとは限りません。「管理者」という一語で、技術操作、情報の正しさ、契約上の責任をまとめないことが重要です。

WordPress標準の管理者・編集者を出発点にする

WordPressでは、roleは利用者の肩書ではなく、実行できるcapabilityの集合です。WordPress公式のRoles and Capabilitiesでは、シングルサイトの管理者はサイト内の管理機能全般へアクセスでき、編集者は他の利用者が作成したものを含む投稿や固定ページを公開・管理できるroleと説明されています。

標準状態では、主な違いを次のように整理できます。

操作	管理者	編集者
投稿・固定ページの作成、他者分を含む編集・公開	できる	できる
メディアのアップロード	できる	できる
ユーザーの作成・権限変更	できる	できない
WordPressの一般設定・パーマリンク等の変更	できる	できない
テーマの切り替え・外観設定	できる	できない
プラグイン・テーマ・WordPress本体の更新	できる	できない

ただし、これは標準状態の出発点です。プラグインや独自実装は、Custom Post Typeごとのcapabilityを追加し、管理者や編集者へ付与できます。反対に、画面や操作を制限することもあります。標準role名だけを見て「求人を更新できる」「設定は変更できない」と確定せず、対象サイトの実アカウントで確認します。

より細かな権限が必要な場合は、既存roleへcapabilityを追加する方法や独自roleもあります。WordPress公式は、利用者へ作業に必要な権限だけを与える考え方を案内しています。実装ではrole名の一致だけでなく、対象操作に必要なcapabilityを検査します。マルチサイトでは管理者と特権管理者の範囲が異なるため、本記事のシングルサイト前提をそのまま当てはめないでください。

顧客へ渡す操作を一覧にする

次の表を初期案にし、案件の投稿タイプ、プラグイン、承認手順に合わせて変えます。「候補role」は、その操作だけを見た場合の出発点であり、実サイトでの保証ではありません。

操作	影響範囲	候補role・担当	公開前に確認すること
求人・社員・インタビューの入力、下書き	採用コンテンツ	編集者または採用用capabilityを持つrole	対象投稿タイプを開けるか、必須項目を確認できるか
求人の公開、募集終了、非公開	一覧、詳細、応募導線等	公開承認者。編集者へ許可するかは案件判断	公開前確認、終了時の表示、応募先が連動するか
固定ページの文章・画像更新	ページ全体	編集者候補	触ってよいページ、構造変更の可否、表示崩れの確認
画像・PDF等の追加	複数コンテンツ	編集者候補	ファイル形式、容量、権利、代替テキスト、既存利用箇所
Navigation、テンプレート、全体スタイルの変更	サイト全体	制作者・技術管理者	PC・スマートフォン、全主要ページ、復元方法
プラグイン・テーマ・WordPress本体の更新	サイト全体・保存データ	技術管理者	更新前バックアップ、対応環境、更新後確認、復元手順
ユーザー、一般設定、パーマリンクの変更	利用者・URL・サイト全体	技術管理者	変更理由、対象、既存URL、管理主体、変更記録
商品固有のセットアップ・ライセンス操作	商品機能・契約中サービス	商品仕様で定める管理者	契約主体、キー管理、更新・サポート主体
サーバー、ドメイン、SSL、バックアップ、フォーム・メール	WordPress外を含む	基盤・各サービスの管理者	契約、請求、送受信、障害連絡、復元の実経路

「編集画面に入れる」と「公開してよい」、「メニューが見えない」と「操作権限がない」は同じではありません。管理画面の非表示は操作を分かりやすくできますが、それだけでアクセス制御が成立した証拠にはしません。

権限を決める六つの手順

1. 作業を「対象・操作・完了条件」で書く

「採用サイトを更新する」ではなく、「募集要項の勤務地と賃金を変更し、社内確認後に公開し、ログアウト状態の募集詳細と応募先を確認する」のように書きます。完了条件まで決めると、必要な権限と確認者を分けられます。

2. 下書き担当と公開担当を決める

同じ担当者が入力から公開まで行うのか、下書き後に別の人が承認するのかを決めます。WordPress標準roleだけで必要な承認手順を表せない場合は、運用手順または追加実装が必要です。

3. 日常操作と構造変更を分ける

文章・画像・定型項目の更新と、項目定義、テンプレート、Navigation、外部連携、権限、プラグインの変更を分けます。構造変更は影響調査と復元ができる担当へ戻します。

4. roleとcapabilityの実状態を確認する

使用中のテーマ、プラグイン、Custom Post Typeが追加・変更するcapabilityを確認します。管理画面の表示だけで判断せず、保存、公開、REST API等の実操作でも対象オブジェクトの権限が検査される設計かを確認します。

5. 利用者ごとのアカウントと見直し条件を決める

誰が操作したかを区別できるように、利用者ごとのアカウント、role、管理者、利用開始日を記録します。担当変更、退職、保守契約変更、作業終了時に、削除、停止、role変更のどれを行うかも決めます。

6. 実アカウントで一連の作業を試す

可能であれば本番と同じ条件のステージングで、顧客が使うroleのアカウントにログインし、入力から公開・終了・公開画面確認まで行います。管理者で成功した操作を、顧客用roleでも成功すると推測しません。

引き渡し前に実アカウントで確認する

顧客用の実roleで、少なくとも次を確認します。

• 対象の求人、社員、インタビュー、固定ページだけへ到達できる
• 新規作成、既存内容の編集、下書き保存、プレビューができる
• 公開を担当する場合は、公開・更新・終了・非公開を決めた手順で実行できる
• 他の担当者が作った内容を扱う必要がある場合、その範囲だけ編集できる
• 画像を追加し、利用箇所、代替テキスト、公開表示を確認できる
• 触ってよい固定ページを更新し、主要構造を意図せず変更しにくい
• 設定、ユーザー、テーマ、プラグイン、ライセンス等、担当外の操作を実行できない
• PCとスマートフォン、ログアウト状態で更新結果と応募導線を確認できる
• 誤操作、公開失敗、担当不在時の連絡先と復元担当が分かる

「編集者だから安全」とは判定しません。編集者は標準状態でも他者の投稿や固定ページを広く編集・削除できます。必要以上に広い場合は、投稿タイプ別capability、追加role、対象ページの保護、承認手順等を比較します。高度な権限設計を追加する場合は、実装だけでなく更新、移行、テスト、復旧の保守負荷も見積ります。

引き渡し記録に残す項目

権限設定は管理画面だけに残さず、引き渡し資料へ次を記録します。

1. 利用者または担当部署とWordPressアカウント
2. roleと、商品・独自実装が追加した主なcapability
3. 許可する対象と操作
4. 制作者・技術管理者へ戻す操作
5. 下書き、公開、終了、削除の承認者
6. 管理者アカウントと復旧経路の管理主体
7. サーバー、ドメイン、バックアップ、フォーム、メールの管理主体
8. 担当変更・退職・契約変更時の停止、削除、role変更手順
9. 最終確認日、次回見直し日、確認した環境

顧客が管理主体であっても、日常用アカウントを管理者へ固定する必要はありません。一方、制作会社だけが管理者と復旧情報を持ち続ける場合は、保守終了や担当変更時に引き継げるかを別に確認します。

2GUの権限分けを一例として見る

ここまでの一般判断を2GUへ当てはめると、2GUは独自roleを増やさず、WordPress標準の管理者と編集者へ、募集要項、社員情報、社員インタビュー用のcapabilityを追加します。編集者は、これらの採用コンテンツについて、他の利用者が作成したものを含む作成、編集、下書き、公開、非公開、ゴミ箱操作を行えます。

一方、採用基本設定、採用キットのセットアップ、ライセンス操作は管理者へ分けています。テーマ・プラグイン・WordPress本体、サーバー、ドメイン、バックアップ、フォーム・メールの管理主体も、採用コンテンツ更新とは別に決めます。

2GUの編集保護は、生成した採用ページの主要構造について日常の誤操作を抑えるUI上の仕組みです。アクセス制御、公開前確認、バックアップ、完全な事故防止の代わりではありません。また、WordPressの管理者を顧客へ渡しても、2GUの購入者、ライセンスキー、公式更新、購入者向けサポートの主体は自動で移りません。

公開マニュアルでは、管理者が行う準備・セットアップ・ライセンス操作と、採用コンテンツの作成・公開・引き渡し手順を確認できます。製造業とITの架空企業デモでは、更新結果として公開されるページと導線を確認できます。

この分け方は一例です。部署別承認、固定ページごとの制限、外部ID管理、短期の外注アカウント等が必要な案件では、標準管理者・編集者だけで要件を満たすとは限りません。必要な操作と確認手順を先に決め、追加実装または別の運用を選びます。

一般判断の結果が2GUの権限分けに近い場合は、2GUの内容と料金・提供条件で案件への適合を確認してください。先に管理者・編集者の名前を選ぶのではなく、顧客へ渡す操作と、制作者へ残す責任を決めてから照合する順序が重要です。