承認フローの多くは、同じ形で失敗します。仕組み自体に反対する人はいません。ところがレビュー担当者が2日不在になり、3件の投稿が予定の枠を逃し、「自分で公開してもいいですか」と聞く人が出てきます。
そこでこの記事では、承認を有効にする方法よりも、運用のしかたを扱います。誰が何をレビューするか、レビューにどれくらいかけるべきか、そして予定時刻を過ぎてから承認が届く木曜の朝に何が起きるかです。機能そのものを知りたいだけなら、承認ワークフローのページをご覧ください。ここでは、使うと決めた前提で進めます。
先に線引きをしておきます。承認の対象は、席を持つチームメンバーです。レビュー担当者がアカウントを持たないクライアントなら、レビューリンクを使います。詳しくはSNS投稿でクライアントのフィードバックをもらう方法をご覧ください。
具体例：3人、クライアント1社
Proプラン（3席）の小さな代理店を例にします。
- Maya はオーナーで、請求を担当しています。
- Dev は承認者です。クライアントのブランドルールと法務上の注意点を把握しています。
- Sam はContributorです。クライアントの投稿の大半を書き、スケジュールします。
火曜の午後、Samはクライアントの春のセールを知らせる投稿を書き、木曜9:00にスケジュールします。Contributorなので、ボタンにはScheduleではなく Submit for Approval と表示されます。投稿は木曜の時刻のまま保存されますが、Awaiting approval のバッジが付き、誰かが承認するまで公開されません。
Devに通知が届きます。水曜の朝、Devは投稿を開き、セールの終了が土曜ではなく日曜だと気づきます。却下して理由を書きます。「セールは土曜ではなく日曜の23:59までです」。投稿は Rejected バッジ付きで下書きに戻り、Samが開くと、コンポーザーの上部にDevのメモが表示されます。
Samは日付を直し、もう一度スケジュールします。これは再提出として扱われ、投稿は再び承認待ちになり、Devにもう一度通知が届きます。木曜9:20、予定から20分後にDevが確認します。ここが厄介なケースです。予定時刻から15分以上過ぎているため、Devは Approve and publish now か Approve and pick a new time を選ぶよう求められます。セールのメールは9:00に配信済みだと知っているDevは、今すぐ公開を選びます。
9:10に開いていれば、15分の猶予内なので、承認した時点で何も聞かれずにそのまま公開されていました。
この流れで真似する価値があるのは3点です。却下に理由が付いていたこと、レビュー担当が「見かけた人」ではなく名前のある1人だったこと、そして遅れた承認のルールが事前に共有されていたことです。
誰が何をレビューするか決める
問うべきは「誰が一番上の立場か」ではなく、「これが間違って出たとき、一番困るのは誰か」です。
| リスクが… | レビュー担当は… | 理由 |
|---|---|---|
| ブランドの声やトーン | コンテンツチームの承認者 | 数秒で判断でき、自分の投稿は直接公開できる |
| 法務、価格、規制対象の表現 | 管理者またはオーナー | 表現に責任を持てる人 |
| クライアント向けの正確さ | アカウント責任者（承認者として） | クライアントの実情に最も近い |
| 新しいライター | いちばん経験のあるメンバー（承認者として） | レビューが研修にもなる |
承認者は直接公開できるので、その役割の人は誰も待ちません。関門を通るのはContributorだけで、Viewerは投稿そのものを作れません。ロールの一覧はチームメンバーを招待してロールを設定する方法にあります。
承認できる人は最低2人決めてください。レビュー担当が1人だと、病欠がそのままコンテンツ停止になります。
フローを作る前に所要時間を決める
数字を1つ決めて、声に出して共有します。計画済みのコンテンツなら「1営業日以内」で十分です。
そこから逆算します。レビューに1日かかりうるなら、枠の1日前を切る提出は避けます。簡単な取り決めは「前日の終業までに提出」です。それより遅いものは頼みごとであり、全員がそれを知っておくべきです。
それでもレビューが遅れたとき、15分のルールは安全網であって計画ではありません。それを過ぎると、遅れて公開するか日時を取り直すかを誰かが判断しなければならず、クライアントを待たせた9:20にレビュー担当へ負わせたい判断ではありません。
ループを閉じる却下メモを書く
却下メモは、書き手が必要なタイミングで受け取る唯一のフィードバックです。最大2,000文字、入力は任意なので、空のままにしがちです。空にしないでください。
- 悪い例：「違います。」
- よりよい例：「このアカウントには売り込みが強すぎます。お客様のストーリーから始めて、割引は最後の行に回してください。」
- 理想： よりよい例に加えて、承認できる状態になる条件も書き、次の提出を最後にする。
却下は判決でもありません。投稿は下書きに戻り、書き手が直してスケジュールし直し、再びレビューに回ります。拒否ではなく、1ラウンドと考えてください。
よくあるミス
何でも関門に通す。 即時の返信やリシェアまで承認待ちにすると、レビュー担当は読まずに承認し始めます。関門は、計画済み・クライアント向け・規制対象のコンテンツに絞りましょう。突発的な投稿は承認者が直接公開できます。
承認者が1人で、代わりがいない。 先に触れたとおり、フローが静かに放棄される最も多い理由です。
承認後の編集に気づかない。 Contributorが承認済みの投稿を変更して再度スケジュールすると、もう一度承認が必要です。仕様です。周知しておかないと、ツールの不具合だと思われます。
自動化を忘れる。 公開権限のない人が作成・編集した繰り返しスケジュールとRSSフィードは、オフにしようとしても承認必須に設定されます。公開できる人なら、あとでオフに戻せます。フィードの投稿が待たされている理由がわからないときは、まずここを確認してください。
クライアントに承認を任せる。 席のないクライアントは承認者になれません。承認のためだけに席を渡すと、3席または10席のうち1席を使い切ります。
通知が全員に同じように届くと思い込む。 承認の通知は、各自の通知設定（アプリ内、メール、モバイル）に従います。メールをミュートしている承認者は、依頼に気づかないかもしれません。一度確認してもらいましょう。
エージェントと連携ツール
スクリプトやAIアシスタントがAPI経由で投稿を作成する場合、アカウントの持ち主が直接公開できる立場でも、requestApproval をtrueにして作成できます。するとContributorの投稿と同じように承認待ちになり、人が判断します。自動化に1週間分の下書きを任せつつ、チェックなしで公開させない、いちばん簡単な方法です。
設定チェックリスト
- 席数を数えます。Freeは1、Proは3、Businessは10で、保留中の招待も上限に含まれます。
- メンバーを招待し、仕事に足りる最も低いロールを割り当てます。書く人はContributor、レビューする人は承認者です。
- 承認できる人を最低2人決めます。
- 所要時間と提出の締め切りを合意します。
- 関門を通さないコンテンツを決め、承認者には直接公開してよいと伝えます。
- テストを1周します。投稿を提出し、理由付きで却下し、再提出して承認します。
- すべての承認者に通知が実際に届くか確認します。
ProとBusinessの料金は料金ページにあります。承認フローは、投稿先のプラットフォームに関係なく同じように動作します。
次の一歩
まず1社のクライアント、または1つのチャンネルセットで2週間運用し、投稿がどこで滞るかを見てください。関門を広げる前に、所要時間を詰めるか、2人目の承認者を加えましょう。準備ができたら、無料で始めて、Proに移行するときにチームメンバーを招待してください。