小規模チームで記事やページを増やすなら、最初に決めるのは公開判断の置き場所です。誰が決めるのか、何を確認してから公開するのか、問題が起きたときに誰が止めるのかを、先に合意しておきます。

記事やページの数が少ないうちは、担当者の気づきで何となく回ります。けれども、AIエージェント、外部ライター、社内の複数担当者が関わるようになると、文体より先に責任の所在が必要になります。

小規模チームのガバナンスは決定権から作る

最初に決めるのは、細かな言い回しではなく決定権です。企画を通す人、事実を確認する人、公開してよいと判断する人、公開後に直す人を分けておきます。

ひとりが全部を担当する場合でも、役割として分ける意味があります。同じ人が作業していても、「今は企画を決めている」「今は事実を確認している」「今は公開可否を判断している」と分けるだけで、見落としが減ります。

決定権が曖昧なままだと、公開前の不安が残っても止めにくくなります。逆に、誰が止められるかが決まっていれば、AIエージェントや外部担当者を使う場合でも、公開責任を人の側に残せます。

企画、執筆、確認、公開、修正の権限を分ける

コンテンツ運用で分けたいのは、肩書きではなく権限です。専門部署がなくても、記事が公開されるまでに必要な判断を分解します。

企画では、誰のどの問いに答えるのかを決めます。執筆では、その問いに自然に答える本文を作ります。事実確認では、断定した内容が一次情報や社内の実務記録と合っているかを見ます。公開判断では、サイトに残す価値があり、既存記事と重複しすぎていないかを確認します。公開後の修正では、古くなった情報や問い合わせで分かった不足を直します。

記録も役割ごとに分けます。企画では、読者の問い、公開する理由、既存記事との違いを残します。事実確認では、どの一次情報を見たか、何を社内判断として書いたかを残します。公開判断では、公開可、差し戻し、保留、統合の理由を残します。修正履歴では、いつ、何を、なぜ変え、公開後に何を確認したかを残します。

この分け方は、担当者を責めるためではありません。作業が止まったときに、どの判断が未完了なのかを見えるようにするためです。ひとりで運用している場合でも、今の自分が執筆者なのか、確認者なのか、公開判断者なのかを切り替えやすくなります。

承認状態は公開前後の迷いを減らすために使う

記事やページの状態は、担当者の頭の中だけで管理しないほうが安全です。小さなチームでも、承認状態を決めておくと、いま何を待っているのかが分かります。

たとえば、企画中から執筆中、事実確認中、承認待ちへ進む状態を分けます。公開可、保留、公開停止、修正中も別の状態として扱います。状態名は多すぎる必要はありません。大切なのは、公開してよい状態と、まだ人の確認が必要な状態を混ぜないことです。

AIエージェントや外部担当者が関わる場合は、状態の意味を共有しておきます。「下書き完了」は公開可ではありません。「事実確認中」は公開してよいという意味でもありません。状態名が曖昧だと、誰かが確認済みだと思い込んで公開してしまいます。

文体ルールより先に公開停止と例外条件を決める

運用規程で役に立つのは、「どう書くか」よりも「いつ公開しないか」です。文体の好みは後から整えられますが、根拠のない断定や古い情報を公開すると、信頼を戻すのに時間がかかります。

たとえば、根拠のない成果表現がある場合は公開しません。価格、制度、仕様が未確認の場合も止めます。医療、法律、金融のように高い正確性が必要な内容を扱う場合は、専門確認なしで公開しない条件を置きます。既存記事とほぼ同じ問いに答えている場合は、統合や保留を検討します。

公開後に更新できる担当がいない記事も注意が必要です。公開時点で正しくても、制度や仕様が変わる領域では、更新できないこと自体がリスクになります。

例外対応も同じ場所で決めます。緊急のお知らせや障害告知のように、通常の承認順を待てない場合は、期限、確認者、後追い記録を決めてから出します。例外は「急いだから記録しない」ではなく、「急いだので期限付きで後から確認する」と扱います。

AIエージェントが関わる記事は人の確認記録を残す

AIエージェントを使う場合、生成された文章そのものより、人がどこで責任を持ったかを記録します。誰が読んだのか、どの一次情報で確認したのか、どこを事業判断として採用したのかを残します。

Google検索セントラルは、生成AIによるコンテンツの使用そのものではなく、ユーザーに役立つ目的、信頼できる作成プロセス、独自の価値を重視しています。有用で信頼性の高いコンテンツを考えるうえでも、AIを使ったかどうかだけを記録するのでは足りません。人が確認した範囲と、確認できなかった範囲を分ける必要があります。

AIエージェントは、問いの分解、下書き、重複候補の発見、チェックリスト化に向いています。ただし、公開する理由、断定できる範囲、読者に渡す判断基準は人が決めます。

最小規程は責任、状態、記録、例外、緊急停止だけで始められる

小規模チームでは、規程を細かくしすぎると守れなくなります。最初のひな型は、責任、承認状態、根拠記録、例外期限、緊急停止が分かれば十分です。

そのまま使うより、担当名、確認範囲、期限だけを自社の運用に合わせて書き換えます。長い規程にする前に、次の短い形で回してみると、どこが曖昧か見つけやすくなります。

コンテンツ運用規程（最小版）

1. 責任
企画責任者は、読者の問いと公開する理由を決める。
確認責任者は、事実、根拠、社内判断の区別を確認する。
公開責任者は、承認状態を公開可へ変更し、公開後確認を完了する。

2. 承認状態
記事の状態は、次のいずれかにする。
- 企画中
- 執筆中
- 事実確認中
- 承認待ち
- 公開可
- 保留
- 公開停止
- 修正中
公開可ではない記事は公開しない。

3. 根拠記録
価格、仕様、制度、検索に関わる断定は、根拠を残す。
根拠には、確認したURL、確認日、確認者を含める。
社内判断は、事実ではなく判断として理由を残す。

4. 例外
緊急公開は、公開責任者が期限付きで許可する。
例外公開した記事は、原則として翌営業日までに事実確認と修正要否を記録する。

5. 緊急停止
次の問題を見つけた担当者は、公開責任者の承認を待たずに公開停止を提案できる。
- 誤情報
- 問い合わせ停止
- 法務リスク
- 意図しないnoindex
- 重大な表示崩れ
停止後は、理由、影響URL、復旧条件、再公開判断者を残す。

このひな型があると、記事を増やすときだけでなく、止めるときにも判断しやすくなります。保留、公開停止、例外公開の理由が残るため、次の担当者が同じ迷いを繰り返しにくくなります。規程は「公開するための通行証」ではなく、「公開しない判断も残せる場所」として機能します。

ルールは更新を遅くするためではなく安心して直すためにある

コンテンツガバナンスの目的は、自由に書けなくすることではありません。責任を分けることで、安心して更新できる状態を作ることです。

AIエージェントが関わる運用では、速く作れるぶん、誤った断定や似た記事も速く増えます。だからこそ、人が公開責任を持ち、公開後の改善まで含めて回せる規程にしておく必要があります。

最初に置くルールは小さくて構いません。決定権、承認状態、止める条件、確認記録、例外期限を決めるだけでも、運用はかなり安定します。小さな規程があることで、記事を増やすときも、直すときも、緊急で止めるときも、同じ基準で判断できます。