WordPressの権限設定｜編集者が安全に更新できる公開フローの作り方

WordPressを複数人で運用するとき、「更新担当者にどこまでの権限を渡すべきか」で迷う企業は少なくありません。権限を絞りすぎれば更新が滞り、管理者権限を広く渡せば、意図しない公開やサイト設定の変更が起こりやすくなります。

結論からいうと、WordPressの権限設定は役割名から選ぶのではなく、誰が何を変更し、誰が公開を判断し、問題が起きたときに誰が戻すかを先に決めることが重要です。日常の文章更新と、ナビゲーション・テンプレート・プラグインなどサイト全体に影響する変更を同じ扱いにしないだけでも、運用の安定性は大きく変わります。

WordPressの権限設定で最初に押さえるべきこと

WordPressには、管理者、編集者、投稿者、寄稿者、購読者などの標準権限があります。たとえば、寄稿者は自分の投稿を作成・編集できますが公開はできません。一方、編集者は他のユーザーが作成した投稿や固定ページも含め、コンテンツを管理・公開できます。

標準権限の概要は、WordPress.org日本語版の「ユーザーの種類と権限」で確認できます。ここで注意したいのは、編集者が「安全な更新担当者」とは限らないことです。固定ページを多数使うコーポレートサイトでは、編集者が全ページの文言を変更・公開できるためです。

また、ブロックテーマを使うサイトでは、サイトエディターへのアクセスに関わる権限を追加すると、テンプレート、ナビゲーション、スタイルなど、ページ本文以外の領域にも触れられる場合があります。権限を追加・変更する際は、役割名ではなく、その権限で実行できる操作を確認してください。WordPress公式も、必要な作業に必要な権限だけを与える考え方を案内しています。Roles and Capabilities（WordPress.org）

権限より先に、更新作業を3種類に分ける

担当者ごとの権限を決める前に、現在発生している更新依頼を棚卸しします。ポイントは、「ページを更新する」という大きな一括りをやめることです。

たとえばマーケティング担当者が導入事例の文章を更新することと、問い合わせフォームの項目やヘッダーメニューを変えることは、同じ「更新」ではありません。前者は日常業務として速く回すべきです。後者は事前確認と公開後のチェックを必要とする変更です。

サイトリニューアルの段階なら、画面や機能の要件と同時に、公開後に誰がどこを更新するかも決めておくとスムーズです。要件定義に盛り込む項目は、サイトリニューアルの要件定義｜成果・SEO・計測の抜け漏れを防ぐも参考になります。

役割ごとに「作成・確認・公開・復旧」を割り当てる

運用人数が少ない場合でも、少なくとも「作成する人」と「公開を判断する人」は分けると、誤りに気づく機会を作れます。ただし、すべての小さな修正に複数承認を求める必要はありません。変更の影響度に応じて、確認の重さを変えることが実務的です。

日常のコンテンツ更新は、下書きと公開を分ける

記事やお知らせを複数人で扱うなら、執筆担当には寄稿者、公開判断を担う担当者には編集者を割り当てる方法があります。寄稿者は標準機能では公開できないため、公開前の確認を必須にしやすい設計です。

ただし、投稿者は自分の投稿を公開できます。広報担当者が自分で公開してよい体制なら便利ですが、「必ず確認してから公開したい」という目的には合いません。役割名の印象ではなく、公開の可否で選びます。

固定ページを触れる人は、担当ページと判断基準を明確にする

編集者は固定ページも編集できるため、サービスページ、料金ページ、採用ページなどを横断して更新する担当者に向いています。一方で、全ページを編集できる必要がない場合は、標準の編集者権限をそのまま配る前に検討が必要です。

対象ページを限定したい、カスタム投稿タイプだけを更新させたい、といった要件では、開発者が権限を個別に設計する方法があります。プラグインで権限を細かく変えることもできますが、テーマやプラグイン、カスタム投稿タイプの実装によって挙動が変わります。本番で権限を変える前に、テスト環境と実アカウントで「見えるメニュー」「編集できる投稿」「公開できる範囲」を確認してください。

管理者権限は、日常更新用のアカウントにしない

管理者は、テーマ、プラグイン、ユーザー、サイト設定などに関わる強い権限を持ちます。日常の編集にも同じアカウントを使うと、誤操作の範囲が大きくなります。

管理者権限は、保守や障害対応を担う少人数に限定し、共有アカウントではなく個人ごとのアカウントを使うのが基本です。担当者が異動・退職したときは、アカウントを無効化または削除し、外部制作会社の一時アカウントも残さないようにします。

更新を止めずに品質を守る公開フロー

WordPressの権限だけでは、内容の正確性や表現の妥当性までは担保できません。そこで、更新の種類ごとに短い公開フローを決めます。チャットで確認するだけでは、誰が最終判断をしたのか分からなくなりやすいため、公開前の確認項目と担当を残せる形にします。

1. 依頼を受ける：更新対象URL、変更理由、公開希望日、確認者を記載します。
2. 下書きを作る：執筆者または更新担当が、WordPress上または別の原稿で変更案を作成します。
3. 内容を確認する：事業部門は事実・表現・価格・法務確認の要否を見ます。Web担当はリンク、画像、検索結果への表示、導線を見ます。
4. プレビューで表示を確認する：PCだけでなくスマートフォンでも、見出し、表、CTA、フォームへの導線を確認します。
5. 公開する：公開者が日時、対象URL、確認者を記録します。重要ページは公開直後に実ページを開きます。
6. 公開後を確認する：フォーム、資料ダウンロード、外部リンク、計測イベントなど、変更箇所に応じた最低限の動作確認をします。

この流れをすべての更新に当てはめる必要はありません。たとえば誤字修正は、更新者の自己確認だけで公開してもよいでしょう。一方、価格、訴求、フォーム、計測タグ、主要ナビゲーションの変更は、公開判断と公開後確認を省かないほうが安全です。

アクセシビリティに関わる更新では、画像の代替テキスト、リンク文言、見出しの順序、キーボード操作への影響も確認対象になります。日々の更新に組み込む観点は、Webアクセシビリティのチェック項目｜問い合わせ機会を逃さないサイト改善で詳しく解説しています。

リビジョンは便利ですが、復旧計画の代わりにはなりません

WordPressには、投稿や固定ページの保存履歴を確認し、過去の状態へ戻せるリビジョン機能があります。文章やタイトルを誤って書き換えた場合に役立つため、更新担当者は場所と使い方を把握しておくとよいでしょう。WordPress公式のリビジョン解説では、変更内容の比較と復元方法が案内されています。

ただし、リビジョンはサイト全体を元に戻すための仕組みではありません。テーマ、プラグイン、サーバー設定、ユーザー権限などの変更まで同じように戻せるとは限りません。構造変更やシステム変更を行う場合は、テスト環境での確認、バックアップの取得方法、障害時の連絡先、復旧の担当者を別途決めておく必要があります。

WordPressの権限設定で起きやすい失敗

「編集できる人」全員に管理者を渡す

最も多い失敗は、更新依頼を早く処理するために管理者を増やすことです。短期的には楽でも、設定変更やプラグイン更新が誰でもできる状態になり、原因調査も難しくなります。管理者が必要な作業を洗い出し、必要な人だけに限定します。

共有アカウントで運用する

共有アカウントでは、誰が何を変更したのか追えません。担当者の交代時にもパスワード変更が漏れやすくなります。アカウントは個人単位で発行し、役割はユーザーごとに割り当てます。

公開前の確認が口頭・チャットだけで終わる

確認依頼が流れてしまうと、公開責任者が曖昧になります。大げさなワークフローシステムを導入しなくても、更新台帳に「対象URL、変更内容、確認者、公開日時」を残すだけで、確認漏れと調査時間を減らせます。

カスタム権限を作っただけで安心する

独自権限は便利ですが、サイトの実装と合っていなければ、必要な画面を編集できなかったり、逆に想定外の操作ができたりします。カスタム投稿タイプ、フォーム、SEOプラグイン、ブロックテーマなどを使っている場合は、更新担当者の操作をテストし、アップデート後にも定期確認を行います。

まず整えたい運用チェックリスト

• 更新作業を、コンテンツ変更・構造変更・システム変更に分けている
• 各変更について、作成者・確認者・公開者・障害時の連絡先が決まっている
• 日常更新に管理者アカウントを使っていない
• アカウントは個人ごとに発行し、共有していない
• 寄稿者・投稿者・編集者の公開範囲を理解して割り当てている
• テーマ、ナビゲーション、フォーム、プラグインの変更は本番前に確認している
• 異動・退職・契約終了時にアカウントを見直す運用がある
• 重要な変更について、公開日時と変更内容を記録している

まとめ

WordPressの権限設定は、セキュリティ対策だけではありません。更新担当者が迷わず作業でき、確認が必要な変更を見落とさず、問題が起きたときに原因をたどれる状態を作るための運用設計です。

まずは管理者を増やす前に、直近の更新依頼を10件ほど並べてみてください。誰が作成し、誰が確認し、どの変更なら公開担当が自分で出せるのかを整理すると、自社に必要な権限と公開フローが見えてきます。