オウンドメディアの編集権限・版管理を設計する方法｜誤公開・上書き・承認漏れを防ぐ

監修: 菊地 将（リブランディング株式会社）

複数人でオウンドメディアを運営すると、「誰でも公開できる」「公開済みの記事を直接書き換える」「修正理由が残っていない」といった状態が事故につながります。

重要なのは、担当者を増やすことではありません。作成・レビュー・公開・管理を別の権限として定義し、すべての変更を版として残し、問題が起きたときに戻せる状態を作ることです。

この記事では、CMSの編集権限、承認フロー、変更履歴、版管理、ロールバックを一つの運用ルールとして設計する方法を整理します。読み終えると、自社のCMSで誰に何を許可し、どの変更をどう記録し、誤公開時にどう戻すかを決められるようになります。

関連する全体像や前提は「コンテンツ制作・運用体制とは？編集フロー・役割分担・品質チェックの仕組みを体」で整理しています。

CMSの編集権限は「誰が担当するか」ではなく「何を実行できるか」で分ける

CMSの権限設計では、社員の役職名をそのまま権限名にするのではなく、「下書きを作れる」「他人の記事を変更できる」「公開できる」「ユーザー権限を変更できる」といった操作単位で考えることが重要です。

情報セキュリティ分野では、担当業務に必要な最小限の権限だけを与える「最小権限」の考え方が基本とされています。NISTも、利用者には割り当てられた業務を実行するために必要な最小限の権限だけを与える原則を示しています。

CMSでも同じ考え方が使えます。

たとえば、記事を書くライターにCMS全体の設定変更権限まで与える必要はありません。一方、最終責任者だからという理由だけで、日常的に管理者アカウントを使用する必要もありません。

まず、次の4つを別の権限として考えます。

ポイントは、「編集できる」と「公開できる」を同じ権限にしないことです。

WordPressも標準で複数のロールを持ち、Contributorは自分の記事を作成・編集できますが公開権限を持たず、Editorは他ユーザーの記事を含めて公開・管理できます。

WordPress以外のCMSでも名称は異なりますが、同じ発想で権限を整理できます。

まず「作成→レビュー→承認→公開」の4段階を標準フローにする

複数人運用では、記事が完成した瞬間に公開できる状態を作らないことが基本です。

CMSでは「完成したらそのまま公開」ではなく、作成・レビュー・承認・公開を状態として分けると、承認漏れを防ぎやすくなります。

最低限、次の4段階を分けます。

作成 → レビュー → 承認 → 公開

Drupalの公式ドキュメントでも、作成者がDraftとして保存し、Editorが確認してPublishedへ移行する運用例が示されています。公開中の版を維持したまま、別の作業版をレビューできる仕組みも用意されています。

実務では、各段階の「完了条件」まで決めてください。

ここで重要なのは、人の注意力ではなくCMS上の状態で制御することです。

「公開前にSlackで一声かける」「担当者同士で確認する」といったルールだけでは、担当者変更や繁忙期に抜けが生まれます。

可能であれば、承認されていない記事では公開操作ができない設定にします。

版管理では「何を保存するか」を先に決める

版管理とは、単に過去の本文を残すことではありません。

最低でも次の5項目を一つの変更履歴として扱います。

• いつ変更したか
• 誰が変更したか
• どこを変更したか
• なぜ変更したか
• どの版が現在公開されているか

公開版と作業中の版を分け、変更者・変更理由まで残すことで、誤った更新が起きても原因を追いやすくなります。

たとえば、次のように管理します。

WordPressのRevision機能では、保存された改訂履歴から追加・削除・変更箇所を比較し、以前の版を復元できます。WordPress 7.0では新しいRevision画面も導入されています。

DrupalでもRevisionには日時、作成者、変更理由などを残せ、過去版へ戻すことができます。過去版へ戻した場合も履歴自体を消さず、新しい版として復元されます。

この「履歴を消さずに戻す」考え方が重要です。

過去の正しい状態へ戻した結果だけでなく、一度誤った変更が入り、その後戻したという事実も履歴として残すことで、原因調査や再発防止がしやすくなります。

公開中の記事は直接上書きせず「次の版」を作る

複数人運用で避けたいのが、公開中の記事を担当者がその場で直接修正し、そのまま更新する運用です。

特にSEO記事、料金ページ、採用情報、法務確認が必要なページでは、数文字の変更でも意味が大きく変わる場合があります。

安全な運用は次の流れです。

1. 現在公開している版を確定する
2. 公開版を元に次版の下書きを作成する
3. 下書き側で修正する
4. 差分をレビューする
5. 承認された次版だけを公開する
6. 旧版は履歴として保持する

Drupalのコンテンツモデレーション機能では、現在公開しているコンテンツを表示したまま、その次の作業版を別に保持し、レビュー後に公開版へ切り替える運用が可能です。

CMSに同様の機能がない場合でも、運用ルールとして「公開中の記事を即時上書きしない」を決めるだけで事故を減らせます。

変更内容によって承認レベルを変える

すべての修正を同じ承認フローにすると、今度は運用が遅くなります。

すべての変更を同じ承認フローにせず、内容が事業や利用者へ与える影響度に応じて承認レベルを変えます。

そこで、変更の影響度を3段階に分けます。

「1文字変更しただけでも役員承認」というルールでは運用が止まります。

反対に、「小さな修正だから」と自由に公開できる状態にすると、重要情報まで同じルートで変更される危険があります。

変更内容と影響度を基準に承認ルートを分けてください。

ロールバックは「機能がある」だけでは足りない

ロールバックとは、問題が発生した際に以前の正常な状態へ戻すことです。

版管理機能を持つCMSでも、実際に事故が起きたときに誰が戻すのか決まっていなければ機能しません。

最低限、次のルールを決めます。

ロールバックを実行する条件

• 誤った情報を公開した
• 表示が大きく崩れた
• 意図しないURL・タイトル変更が発生した
• 法務・広報上の問題が判明した
• 公開後に重大な事実誤認が判明した

実行できる人

原則として公開責任者またはCMS管理者に限定します。

戻す対象

直前の版とは限りません。「最後に正常だったことを確認できる版」まで戻します。

戻した後

修正理由、発生日時、対象ページ、問題のあった版、復元した版を記録します。

緊急修正だけは通常フローとは別に設計する

通常の承認フローだけでは、緊急時に対応が遅れる可能性があります。

たとえば、次のようなケースです。

• 誤った価格を公開した
• 公開禁止情報を掲載した
• 個人情報が含まれていた
• 法律上問題のある表現が判明した
• リンク先が不正なページへ変わっていた

こうした場合は、通常のレビューを待たずに公開停止またはロールバックできる「緊急経路」を用意します。

ただし、緊急経路を誰でも使えるようにしてはいけません。

おすすめは、

公開責任者または管理者が一時対応 → 対応履歴を記録 → 後から正式レビュー

という流れです。

「緊急だから履歴を残さない」のではなく、緊急時ほど変更記録を残すことが重要です。

CMSの権限表は「人」ではなく「ロール」で管理する

権限を「田中さんは公開可能」「佐藤さんは編集可能」と個人単位で決めると、異動や退職のたびに設計が崩れます。

役割に対して権限を紐付けるRBAC（Role-Based Access Control）では、利用者個人ではなく役割に権限を割り当てます。NISTのRBAC研究でも、比較的安定する役割を中心にアクセス権を管理することで、大規模な権限管理を整理しやすくする考え方が示されています。

たとえば、

• CMS管理者
• 公開責任者
• 編集者
• 作成者
• 外部ライター

というロールを先に作り、担当者が変わったらロールへの所属だけを変更します。

CMS権限は個人ごとに設定するのではなく、役割ごとのロールを作り、その業務に必要な操作だけを許可すると管理しやすくなります。

特に外部ライターや制作会社へ管理者権限を渡す運用は避け、業務に必要な範囲へ限定します。

権限は付与時だけでなく定期的に棚卸しする

一度正しく設定した権限も、組織変更によって徐々に実態とずれていきます。

NISTの最小権限に関する管理策でも、役割や利用者へ割り当てた権限を定期的に確認し、不要になった権限を削除・再割り当てすることが示されています。

少なくとも次のタイミングで確認してください。

• 入社・退職
• 異動
• 外注契約の開始・終了
• CMSリニューアル
• 運用体制変更
• 新しい部署の参加

さらに、半年または四半期ごとに一覧を確認すると安全です。

確認する項目は、

• 現在CMSへログインできる人
• 各ユーザーのロール
• 管理者権限を持つ人数
• 使用していないアカウント
• 退職・異動済みユーザー
• 外部委託先アカウント

です。

複数担当者で事故を防ぐための10項目チェック

現在のCMS運用を次の10項目で確認してください。

• 作成者と公開者が分かれている
• 全員へ管理者権限を付与していない
• 公開前にレビュー状態を通る
• 公開中の記事を直接上書きしない
• 過去版を確認できる
• 変更者と変更日時が残る
• 重要な変更では変更理由を残す
• 問題発生時のロールバック担当者が決まっている
• 緊急公開停止の手順がある
• 退職者・異動者の権限を定期的に削除している

3項目以上が未整備なら、CMSそのものを変更する前に、まず現在の権限表と公開フローを整理する価値があります。

最初に作るべきものは「CMS権限・版管理表」

運用ルールを文章だけで作ると、実際のCMS設定とずれやすくなります。

まず1枚の表に、

ロール × 操作 × 承認 × 履歴 × 復元

を整理してください。

そのうえでCMS側の設定と照合します。

CMSに必要な機能が不足している場合も、「どの機能が不足しているか」が明確になります。

たとえば、

• 権限は分けられるが承認フローがない
• Revisionはあるが変更理由が残せない
• 過去版は見られるが公開版と作業版を分離できない
• ロールバックはできるが実行権限を細かく分けられない

というように、運用課題を具体化できます。

まとめ

オウンドメディアの権限・版管理で重要なのは、CMSの高機能さそのものではありません。

誰が作るか、誰が確認するか、誰が公開するか、何を履歴として残すか、問題発生時に誰がどの版へ戻すかを決めることが先です。

基本は、

作成 → レビュー → 承認 → 公開 → 履歴保存 → 必要時にロールバック

という流れです。

そのうえで、担当者には必要最小限の権限だけを与え、個人ではなくロール単位で管理します。

最初から複雑な仕組みにする必要はありません。まずは「作成者は公開できない」「公開済み記事は次版を作って更新する」「重要変更では履歴と理由を残す」という3点から始めるだけでも、誤公開・上書き・承認漏れのリスクを大きく減らせます。

参考文献・データ元

‹ 親記事: コンテンツ制作・運用体制とは？編集フロー・役割分担・品質チェックの仕組みを体系的に整理