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

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

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

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

この記事では、CMSの編集権限、承認フロー、変更履歴、版管理、ロールバック（問題が起きたときに以前の正常な版へ戻すこと）を一つの運用ルールとして設計する方法を整理します。自社のCMSで誰に何を許可し、どの変更をどう記録し、誤公開が起きたときにどう戻すかを決める材料がそろいます。

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

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

最初に決めるのは、CMSの権限を何を基準に分けるかです。社員の役職名をそのまま権限名にするのではなく、「下書きを作れる」「他人の記事を変更できる」「公開できる」「ユーザー権限を変更できる」といった操作単位で考えるのが出発点です。

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

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

この考え方に沿って、まず次の4つを別の権限として分けます。

権限	主な操作	想定担当者
作成	新規記事の作成、自分の下書き修正	ライター、各部門担当者
編集・レビュー	他担当者の記事修正、差し戻し	編集者、マーケティング担当
公開	公開・更新・公開停止の最終実行	編集責任者、広報責任者
システム管理	ユーザー、CMS設定、プラグイン等の変更	Web管理者、情報システム担当

作成と編集・レビューは記事の中身に関わる権限、公開は読者に届ける最終実行の権限、システム管理はCMSそのものの設定に関わる権限です。ポイントは、「編集できる」と「公開できる」を同じ権限にしないことです。

WordPressも標準で複数のロール（役割ごとにまとめた権限のセット）を持っています。Contributorは自分の記事を作成・編集できますが公開権限を持たず、Editorは他ユーザーの記事を含めて公開・管理できます。WordPress以外のCMSでも名称は異なりますが、同じ発想で権限を整理できます。

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

次に、記事が公開されるまでの流れをどう区切るかを決めます。複数人運用では、記事が完成した瞬間に公開できる状態を作らないことが基本です。

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

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

実務では、各段階の「完了条件」まで決めてください。次の表は、状態ごとに実行できる人と完了条件を整理したものです。

状態	実行できる人	完了条件
下書き	作成者	本文・画像・基本設定がそろっている
レビュー待ち	編集者	内容・表記・リンク・事実確認が完了
承認済み	公開責任者	公開内容と公開日時を最終確認
公開	公開権限保持者	承認済みの版だけを反映
修正中	作成者・編集者	公開版を残したまま次版を作成
公開停止	公開責任者	非公開理由を記録

表では、4段階に加えて、公開後に必要になる「修正中」と「公開停止」を状態として置いています。

ここで重要なのは、人の注意力ではなくCMS上の状態で制御することです。「公開前にSlackで一声かける」「担当者同士で確認する」といったルールだけでは、担当者変更や繁忙期に抜けが生まれます。可能であれば、承認されていない記事では公開操作ができない設定にします。

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

続いて、変更のたびに何を記録するかを決めます。版管理とは、単に過去の本文を残すことではありません。最低でも次の5項目を一つの変更履歴として扱います。

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

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

版	日時	担当者	主な変更	理由	状態
v1.0	8/1	Aさん	初回公開	新規公開	公開済み
v1.1	8/8	Bさん	数字を更新	最新統計へ更新	公開済み
v1.2	8/20	Cさん	CTA変更	導線改善	公開済み
v1.3	8/25	Aさん	全体リライト	検索意図への適合	レビュー中

この例では、v1.0からv1.2までが公開済みで、v1.3はAさんによる全体リライトがレビュー中です。誰が・いつ・何を・なぜ変えたかに加えて、各版の状態が一覧で分かります。

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

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

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

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

公開済みの記事を更新するときの手順も、あらかじめ決めておきます。複数人運用で避けたいのが、公開中の記事を担当者がその場で直接修正し、そのまま更新する運用です。特にSEO記事、料金ページ、採用情報、法務確認が必要なページでは、数文字の変更でも意味が大きく変わる場合があります。

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

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

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

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

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

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

そこで、内容が事業や利用者へ与える影響度に応じて、変更を3段階に分けて承認レベルを変えます。

変更レベル	例	推奨承認
軽微	誤字、リンク切れ、表記統一	編集者1名
通常	本文追加、見出し変更、CTA変更	編集責任者
重要	価格、実績、法務表現、会社情報、大規模改稿	部門責任者＋必要な専門担当

軽微な修正は編集者1名の承認で進め、本文追加や見出し変更などの通常の変更は編集責任者が承認します。価格や法務表現など影響の大きい変更だけ、部門責任者と必要な専門担当まで承認を広げる、という分け方です。

「1文字変更しただけでも役員承認」というルールでは運用が止まります。反対に、「小さな修正だから」と自由に公開できる状態にすると、重要情報まで同じルートで変更される危険があります。変更内容と影響度を基準に、承認ルートを分けてください。

ロールバックは「誰が・どの条件で・どこまで戻すか」まで決める

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

1つ目は、ロールバックを実行する条件です。次のような場合を対象にします。

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

2つ目は、実行できる人です。原則として公開責任者またはCMS管理者に限定します。

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

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

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

通常の承認フローだけでは、緊急時に対応が遅れる可能性があります。たとえば、次のようなケースです。

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

こうした場合は、通常のレビューを待たずに公開停止またはロールバックできる「緊急経路」を用意します。ただし、緊急経路を誰でも使えるようにしてはいけません。おすすめは、公開責任者または管理者が一時対応 → 対応履歴を記録 → 後から正式レビューという流れです。

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

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

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

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

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

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

CMS権限は個人ごとに設定するのではなく、役割ごとのロールを作り、その業務に必要な操作だけを許可すると管理しやすくなります。先に見た4つの権限（作成、編集・レビュー、公開、システム管理）は、次の表では操作ごとの行に分けて、各ロールに割り当てています。

操作	管理者	公開責任者	編集者	作成者	外部ライター
下書き作成	○	○	○	○	○
他人の記事編集	○	○	○	×	×
レビュー	○	○	○	×	×
公開	○	○	×	×	×
ロールバック	○	○	×	×	×
ユーザー追加	○	×	×	×	×
CMS設定変更	○	×	×	×	×

この表では、公開とロールバックは管理者と公開責任者に限り、ユーザー追加とCMS設定変更は管理者だけが行えます。編集者は他人の記事の編集とレビューまでで、公開はできません。作成者と外部ライターが行えるのは、下書き作成だけです。特に外部ライターや制作会社へ管理者権限を渡す運用は避け、業務に必要な範囲へ限定します。

権限は付与時だけでなく定期的に見直す

この節では、設定した権限をいつ、何を見て見直すかを決めます。一度正しく設定した権限も、組織変更によって徐々に実態とずれていきます。NISTの最小権限に関する管理策でも、役割や利用者へ割り当てた権限を定期的に確認し、不要になった権限を削除・再割り当てすることが示されています。

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

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

これに加えて、半年または四半期ごとに一覧を確認すると安全です。確認する項目は、次のとおりです。

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

なお、本記事で扱うのはCMS内のロール設計と、役割変更時の権限見直しまでです。CMS外のサービスを含む退職・異動・外注終了時のアクセス剥奪と証跡管理は、個別のオフボーディング工程へ切り分けます。

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

ここまでの内容を、現在のCMS運用に当てはめて確認します。次の10項目で点検してください。

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

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

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

運用ルールを文章だけで作ると、実際のCMS設定とずれやすくなります。そこで、まず次の5つの軸を1枚の表に整理してください。

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

そのうえでCMS側の設定と照合すると、CMSに必要な機能が不足している場合も「どの機能が不足しているか」が明確になります。たとえば、次のように運用課題を具体化できます。

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

まとめ

オウンドメディアの権限・版管理で重要なのは、CMSの高機能さそのものではありません。先に決めるべきなのは、誰が作るか、誰が確認するか、誰が公開するか、何を履歴として残すか、問題発生時に誰がどの版へ戻すかです。

基本の流れは、作成 → レビュー → 承認 → 公開 → 履歴保存 → 必要時にロールバックです。そのうえで、担当者には必要最小限の権限だけを与え、個人ではなくロール単位で管理します。

最初から複雑な仕組みにする必要はありません。まずは次の3点から始めるだけでも、誤公開・上書き・承認漏れのリスクを大きく減らせます。

• 作成者は公開できない
• 公開済み記事は次版を作って更新する
• 重要変更では履歴と理由を残す

参考文献・データ元

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

関連記事

• › 記事品質チェックリストの作り方｜編集基準・校正・根拠確認・公開承認を標準化する
• › SEO記事のコンテンツブリーフ作成方法｜検索意図・見出し・根拠・内部リンクを制作前に定義する
• › オウンドメディアの著者・監修者設計｜誰が書き、誰が確認したかを記事単位で明示する方法
• › オウンドメディア編集部の作り方｜編集長・ライター・監修者・SEO担当の役割分担
• › 記事の更新期限を決める方法｜鮮度・重要度・順位下落で判断
• › 記事の出典・根拠を管理するエビデンス台帳の作り方｜更新期限・一次情報・引用箇所を追跡
• › 生成AIを記事制作に使う運用ルールの作り方｜利用範囲・人間レビュー・機密情報を管理
• › 記事の出典を定期確認｜リンク切れ・情報鮮度・一次情報をチェック
• › オウンドメディアのアクセス権限を定期確認｜退職・異動時の対応
• › 生成AIを使った記事制作の検証ログを作る方法｜プロンプト・根拠確認・修正履歴を残す
• › コンテンツ制作の遅れを確認｜企画・執筆・確認・公開を可視化
• › 外注記事の受入れ基準を作る方法｜納品形式・根拠・著作権・修正責任を標準化
• › オウンドメディアの画像・図版ライセンスを管理する方法｜出典・利用範囲・期限を台帳化
• › 外注ライター・制作会社の評価スコアカードを作る方法｜品質・納期・修正回数・専門性を継続評価
• › オウンドメディアの緊急訂正・公開停止フロー｜訂正・一時非公開・削除の判断基準と復旧手順
• › 法人向けサービスページの比較表の作り方｜料金・対象・対応範囲・実績・契約条件を同じ軸で整理
• › 導入事例ページの作り方｜成果数値・導入期間・取り組み内容
• › オウンドメディア担当者の引き継ぎチェックリスト｜記事・CMS・編集ルール・分析データ・進行中企画を整理
• › 導入事例ページの作り方｜業種・課題・成果で探せる構成と導線
• › 法人向けサービスページのFAQの作り方｜料金・対象・導入条件・契約・セキュリティの質問を整理
• › 法人向けサービスページの導入フローの作り方｜期間・準備物・担当・例外条件まで整理
• › 法人向けサービスのセキュリティ情報の載せ方｜認証・データ保管・権限・問い合わせ先の整理方法
• › 法人向けサービスサイトの情報更新を誰が持つ？営業・法務・制作で料金・実績・契約条件を管理する方法
• › オウンドメディアの表記ガイドラインの作り方｜表記ゆれ・数字・固有名詞・引用ルールを統一
• › オウンドメディアのインタビュー記事の作り方｜企画・質問設計・取材・原稿確認・公開まで
• › オウンドメディアの記事テンプレートの作り方｜原稿フォーマット・出典・CTA・FAQ・著者欄を標準化
• › Claudeの料金プラン比較｜無料・Pro・Team・法人向けの選び方
• › NotebookLMの使い方｜資料の読み込み・要約・質問の基本手順

関連テーマ

AIO SEO MEO 口コミ・風評対策 採用改善