小規模なBtoBチームでコンテンツガバナンスを作るなら、役職や確認工程を増やすところから始める必要はありません。まず、新規公開を最終的に判断する人を決めます。続いて、訂正や非公開を誰が決めるかを明らかにします。通常の規程から外れる例外と、規程そのものの変更にも決定者が必要です。

少人数なら、一人が作成と公開作業を兼ねても構いません。ただし、読者への約束や主張の根拠に影響する変更は、作成者だけの判断で公開しないようにします。根拠を確認する人が決まらない場合には、公開を見送ることも規程に含めます。

企画から公開後までの受け渡しは、AIエージェントとCMSの記事制作フローで説明しています。執筆前に企画を採用するかどうかはコンテンツを量産せずに企画を選ぶ方法をご覧ください。完成原稿の扱いはAI生成記事のレビュー手順で取り上げています。本記事では、組織の権限と継続して使う運用規程に範囲を絞ります。

小規模チームの規程は決定権から作る

誰が決めるかは、役職の一覧を先に作るのではなく、判断の種類ごとに定めます。新しいページを公開する判断と、公開済みの事実を訂正する判断では影響が異なるためです。公開を終了する場合は、営業や顧客対応にも影響するかもしれません。規程を変える判断まで制作担当者の裁量にすると、守るルールそのものが案件ごとに動いてしまいます。

各判断の最終決定者は、一人または一つの役割に定めます。役割名を使う場合も、その時点で誰を指すかが分かる状態にします。最終決定者は、CMSの公開ボタンを押す人とは限りません。確認担当から根拠と事業への影響を受け取り、公開を進めるか止めるかを決める人です。

ISO 9001の公開説明は、組織の運営方法を一つに固定していません。そのうえで、明確な責任や文書化した情報を品質マネジメントの要素として挙げています。プロセスアプローチの公開ガイダンスも、プロセスに責任と権限を割り当てる考え方を示しています。これらは役割数の根拠ではなく、判断の責任を曖昧にしないための参考になります。

兼務できる仕事と別の確認が必要な判断を分ける

兼務していることだけで規程が不十分になるわけではありません。文章の意味を変えない誤字修正なら、変更内容を残したうえで同じ人が確認と実行を担える場合があります。画像の差し替えやリンク修正も、読者が受け取る意味や権利関係が変わらないと確かめられるなら、同じ担当が確認と実行を兼ねられます。

一方、商品やサービスについて読者への約束を変える場合は、作成者とは別の人が確認します。数値や実績は出所を確認し、確かめられなければ公開を止めます。訂正や非公開を決めるときも、通常の規程から外れる例外を認めるときも、作成者だけでは決めません。

NIST SP 800-53のAC-5は、職務分離を考えるときの参考になります。ただし、対象は情報システムと組織のセキュリティおよびプライバシー統制です。一般的な記事制作に二者承認を義務づける資料ではありません。

確認担当が確かめる根拠と残す記録を決める

確認担当の仕事は、原稿を読んで感想を返すことではありません。どの主張や変更内容を確認するのかを明らかにし、参照できる根拠と照らし合わせます。社内に正本がある情報は、その情報に責任を持つ人へ確認します。最終決定者は、その結果を受けて公開するかどうかを決めます。

確認の記録には、使った資料または社内の情報責任者を残します。確認した日と人も必要です。確かめられなかった点は記録から消さず、未確認事項として分けて残します。商品改定などで結論が変わるなら、その変更を再確認の契機として記録します。

AIエージェントが作成や調査を補助する場合、本記事のひな型では、出力をどの人が確認するかを決めます。NIST AI RMF 1.0のCoreでは、人とAIの役割を区別し、AIリスクに関する責任を明確にする考え方が示されています。ただし、利用は任意であり、扱う場面によって適用方法が変わる枠組みです。AIを使ったすべての記事に人の承認を必須とする資料ではありません。

公開を止める条件には根拠不足や確認者不在を含める

止める条件を先に書いておけば、担当者は立場の強い人から急かされたときも規程を根拠にできます。主張の根拠が見つからないときや、必要な確認担当が不在のときは公開しません。既存のサービス情報と食い違っている場合も、どちらが正しいか決まるまで止めます。

権利の扱いを確かめられない素材は公開しません。個人情報や秘密情報が含まれる可能性を解消できない場合も同じです。これは、コンテンツ担当だけで法務判断を行うという意味ではありません。適切な判断者へ渡せない状態を、公開の停止条件にするということです。

停止は廃案ではないため、不足している根拠と再開条件を記録します。公開後に問題が見つかった場合に備え、一時的な非公開を決める人と実行する人も定めておきます。

権限対応表で判断ごとの担当を決める

次の表は、同じ人が複数の仕事を担うチームで権限の空白を見つけるためのものです。セルには実際に連絡できる人の名前か、担当者が一意に決まる役割名を入れます。記録先には文書やシステムの名称を書き、判断理由はそこへ残します。

判断最終決定者確認担当実行担当記録先
新規公開または大幅変更
事実の訂正
一時非公開または公開終了
例外の適用
規程の変更

空欄は「担当不要」という意味ではありません。まだ責任の所在を決められていない判断です。最終決定者の空欄が埋まるまで、その行に当たる変更は進めません。記録先が決まっていない場合も、後から判断の根拠を追えないため、変更は進めないようにします。

同じ名前が複数の列に入ることはあります。意味を変えない保守なら、確認と実行を兼ねられる場合があります。ただし、読者への約束を変える変更は別です。最終決定と確認と実行が作成者に集中しており、別の確認担当を置けないなら公開を止める条件へ含めます。

例外を認めるときは理由と通常の確認へ戻る条件を記録する

例外は、急ぐために規程を無効にする仕組みではありません。通常の確認を省いた結果、何が未確認のまま残るかを見えるようにする仕組みです。例外を決める人は、通常の公開を決める人と同じとは限らないため、別に定めます。

英国政府の公開基盤であるGOV.UKには、まれなケースとして、編集者が不在で緊急公開が必要なときにレビューを経ず公開できる運用例があります。その場合は、レビューなしで公開した理由を入力し、コンテンツを未確認の状態にします。公開後は編集者がレビューし、確認できた時点で未確認の状態を解除します。これは公的組織の実装例であり、民間企業へ緊急公開や二者承認を求める標準ではありません。

自社の規程にも、例外を認めた人と省略した確認を残します。判断に使った根拠も記録します。何がそろえば通常の確認へ戻せるかを決め、例外中でも公開を止められる人を置きます。戻す条件は一律の時間ではなく、必要な確認者が判断できることや、不足した根拠がそろうことから決めます。

運用規程ひな型に自社の担当者と判断条件を書き込む

このひな型は、権限対応表で決めた担当を継続して使えるルールにするためのものです。最初に対象範囲と決定権を埋めます。次に、公開を止める条件を自社の情報や体制に合わせます。細かな禁止事項は、実際の一件を判断して不足が見つかったときに加えます。

コンテンツ運用規程

規程名: [記入]
目的: [この規程で判断できるようにすること]
対象にするコンテンツ: [記事、サービスページなど]
対象外: [別の規程や専門判断へ渡す範囲]
規程の責任者: [氏名または一意に決まる役割名]

1. 決定権
新規公開は、[氏名または役割名]が最終決定する。
大幅な変更は、[氏名または役割名]が最終決定する。
事実の訂正は、[氏名または役割名]が最終決定する。
一時非公開または公開終了は、[氏名または役割名]が最終決定する。
規程の変更は、[氏名または役割名]が最終決定する。
最終決定を受けた実行担当は、権限対応表に従って公開状態を変更する。

2. 確認責任
確認が必要な主張や変更: [記入]
確認に使える根拠: [資料名または社内の情報責任者]
確認する人: [氏名または役割名]
作成者とは別の確認が必要になる条件: [記入]
確認する人は、主張または変更内容を根拠と照合する。
確認日、確認した人、未確認事項、結論が変わる再確認契機は、[記録先]に残す。

3. 公開を止める条件
次のいずれかに当たる場合は、[公開を止められる人]が公開を進めない。
- 主張または変更の根拠が不足している。
- 必要な決定者または確認する人が不在である。
- 既存ページまたは社内の正本と食い違っている。
- 権利、個人情報、秘密情報の扱いを確認できない。
- [そのほか自社で公開を進めない状態]
公開を再開できる条件: [不足した根拠や確認がそろった状態]

4. 例外
例外は、[氏名または役割名]だけが決定できる。
例外を認める条件: [記入]
省いた確認、残る未確認事項、判断理由、根拠は、[記録先]に残す。
通常の確認へ戻す条件: [記入]
例外中の公開は、[氏名または役割名]が止められる。

5. 記録
最終判断と変更理由は、[記録先]に残す。
根拠、確認日、確認した人は、[記録先]に残す。
例外と未確認事項は、[記録先]に残す。
記録を確認できる人: [氏名または役割名]

6. 見直し
規程を見直す人: [氏名または役割名]
見直しは、担当や事業の変更によって現行規程が合わなくなったときに行う。
自社に適用される法令または契約の条件が変わった場合も見直す。
誤りや苦情が発生した場合と、同じ例外が繰り返された場合も対象にする。
そのほか見直しが必要になる変更や出来事: [記入]
見直し後の版と変更理由は、[記録先]に残す。

記入後は、いま公開しようとしているコンテンツを一件だけ当てはめます。規程の文章を読んでも担当が決まらない箇所は、役職を増やすのではなく名前や判断条件を具体化します。答えられなかった箇所だけを直せば、短い規程のまま運用を始められます。

規程の対象外も先に書いておく

対象外は、確認を省いてよい範囲ではありません。コンテンツチームの権限では決められない事項を、適切な担当や別の規程へ渡すための境界です。契約上の承認や法的な判断が必要な内容は、その責任者が分からない状態で公開しません。技術障害への対応も、本規程へ手順を詰め込まず保守担当へ渡します。

規制のある業種では、法令や契約が追加の責任者や記録を求めることがあります。このひな型だけで個別要件を満たせるとは限りません。自社へ適用される要件を確認し、その結果を対象範囲か対象外の受け渡しへ反映します。

AdRegionの独自ルールと一般化できる考え方を分ける

AdRegionのKnowledge記事では、新規作成と大幅なリライトで担当を分けています。企画の扱いは企画担当が決め、完成原稿の公開判断は公開判定担当が引き受けます。本文を書いた担当は、その原稿の最終的な公開判定を行いません。

事実の確認と文体の確認も、別の担当に分けています。一次情報で支えられない原稿は、一般論で補わず保留へ戻します。公開判定では、85点以上であることに加えて必須条件を満たす必要があります。これはAdRegionが選んだ停止条件です。

判断の内容に応じて記録先も分けています。全体の進行状態は記事計画に残し、記事ごとの根拠と未確認事項は記事別計画に記録します。公開前の評価は品質記録に保存します。そのため、CMSで公開操作をしただけでは承認の記録になりません。

AdRegionでは六つの役割に分け、同時に執筆する記事を原則一つにしています。これらは、このプロジェクトに合わせた決め事です。保留を表す状態名や85点という基準も同じです。

タイトルと見出しの規則まで、他社がそのまま採用すべきものではありません。一般化できるのは、誰が決めるかと、何が不足したら止めるかを明文化する考え方までです。これらの規程が品質や制作時間を改善したか、検索成果や事故の減少につながったかは確認していません。自社へ取り入れるときは六つの役割をそのまま再現せず、権限対応表で必要になった役割だけを置きます。

規程は担当や事業の変更に合わせて見直す

見直しの時期は、月次や年次といった周期を根拠なく先に決める必要はありません。規程が実際の体制や事業に合わなくなったときに見直します。担当者が変わり、権限対応表の名前が現状と違えば見直す時期です。商品やサービスの提供条件が変わったときも、確認に使う正本と決定者を確かめます。

利用するCMSの権限やAIエージェントの役割が変わると、実行できる人と確認すべき範囲も変わります。自社に適用される法令や契約の変更も契機になります。公開した情報に誤りが見つかったり、苦情を受けたりした場合は、規程どおりに止められたかまで確認します。

同じ例外が繰り返されるなら、例外の理由だけでなく通常の規程を見直します。毎回同じ確認者が不在になるのであれば、代わりの確認方法か停止条件が必要です。定期的な見直し日を自社で置く場合は、その周期を選んだ理由と責任者も記録します。

ISO 9001の文書化した情報に関する公開ガイダンスは、必要な文書量が組織の規模や活動などで異なると説明しています。規程を長文にすること自体が目的ではありません。変更後も判断と根拠を追える量に整え、使われない項目は理由を確かめて見直します。

最初の一件を規程に沿って判断する

いま公開しようとしている一件を、権限対応表の「新規公開または大幅変更」の行へ置きます。最終決定者の名前を入れ、確認担当が使う根拠を規程へ書きます。実行後に判断結果を残す場所まで決まれば、その一件を誰が引き受けるかが見えるはずです。

最終決定者を決められないうちは、公開へ進みません。根拠を確認する人がいない場合も同じです。停止条件に当たるか判断できないなら、まずその条件を具体的にします。細かな禁止事項を増やす前に、目の前の一件を必要に応じて止められる短いルールから確定します。