ロールベースアクセス制御(RBAC)とは、何ができるかを決めるのは個人ではなくロールだ、という考え方です。ソーシャルメディアチームに必要なのは20個ではなく6つのロール。クリエイター、エディター、承認者、パブリッシャー、アナリスト、管理者です。各メンバーを特定のクライアントアカウントに限定し、自分に関係のない仕事が見えないようにしましょう。そして、誰が何を承認したかの記録を残すのです。
代理店が失敗するパターンは、たいてい2つに分かれます。全員が同じログインを共有しているか、すべての投稿が創業者の承認待ちになっているか。どちらも半日あれば解決できます。
まとめ: クライアントごとに紐づく6つのロール。承認をゲートとし、すべての承認を記録に残す。個人ごとの例外設定こそが、このモデル全体を維持不能にする元凶です。
ほぼすべてのチームをカバーする6つのロール
| ロール | できること | できないこと |
|---|---|---|
| クリエイター | 投稿の下書き作成、アセットのアップロード | 公開、アカウント接続 |
| エディター | スコープ内の下書きを編集、承認申請 | 自分の作業を承認 |
| 承認者 | 下書きの承認、却下、コメント | 接続アカウントの編集 |
| パブリッシャー | 承認済み投稿のスケジュールと公開 | 承認、ユーザー追加 |
| アナリスト | アナリティクスの閲覧、レポートのエクスポート | コンテンツへの操作 |
| 管理者 | アカウント接続、ユーザーとロールの管理 | なし(だから2人までに) |
この仕組みを腐らせないためのルールが2つあります。自分の作業は自分で承認しないこと。そして管理者は必ず2人だけにすること。バックアップは常に確保しつつ、委員会状態は絶対に避けられます。
個人ごとの権限設定は避けましょう。「サラは木曜日だけ公開もOK」という例外を認めた瞬間、半年後には誰も監査できない状態になります。例外が必要なら一時的にロールを変更し、終わったら元に戻すのが正解です。
スコープ:代理店が最も間違えやすいポイント
ロールだけでは不十分です。クライアントAのクリエイターは、クライアントBのアカウントを見られない必要があります。これがスコープです。代理店が共有ログインを卒業した途端、最初に崩れるのがここです。
スコープは3つの軸で設定します。
- クライアントまたはブランド。 ここが絶対的な境界線。契約社員には必ず1つだけ割り当てます。
- チャンネル。 InstagramとTikTokを担当していても、LinkedInの企業ページには触れない、という設定が可能です。
- ステージ。 下書きへのアクセス権が、公開権限を意味することは絶対にありません。
これはフィルターではなく、本当の分離である必要があります。契約社員がアカウント切り替えで別のクライアントのインボックスに到達できるなら、それは分離ではなくデフォルトビューにすぎません。Mydropではワークスペースがこの境界線を引きます。各クライアントが独自のメンバー、カレンダー、接続アカウントを持つ独立したスペースになるのです。
クライアント側のステークホルダーは別の問題です。彼らのほとんどは、そもそもユーザーであるべきではありません。ログイン不要のクライアントポータルを使えば、シートもパスワードも、プロジェクト終了後も管理し続ける権限レベルもなしに、自分のコンテンツをレビュー・承認できます。
承認はゲートであり、役職のヒエラルキーではない
権限は「誰が行動できるか」を決めます。承認は「いつ行動するか」を決めます。この2つを分離しないと、金曜日の投稿を通すためだけに人を管理者に昇格させる事態が始まります。
役職ではなくリスクでルーティングしましょう。
| コンテンツ | レビュアー |
|---|---|
| テンプレート化された定期投稿 | エディター1名 |
| 新規キャンペーン、または新しい主張を含む投稿 | クライアントまたはブランド責任者 |
| 規制対象、法務関連、クライシス対応 | 指名された法務レビュアー(代替なし) |
最初の2行には代替承認者を設定し、休暇で公開が止まらないようにしましょう。3行目は本当にブロックされるべきものです。承認ワークフローは承認が揃うまで投稿を保留するため、「承認済み」と「公開済み」が別々のリストとして手作業で照合されるのではなく、1つの記録として残ります。
監査ログに記録すべきこと
「誰がこれを変えた?」という問いは、いつも最悪のタイミングでやってきます。そして現在の状態だけを保存するログでは、その問いに答えられません。
アクションごとに5つの項目を記録しましょう。
- 誰が行ったか。 共有アカウントではなく、必ず個人名で。
- その時点でのロール。 人はロールを変更します。読み出し時にロールを解決するログは、静かに履歴を書き換えてしまいます。
- 何が変わったか。 変更前のバージョンも読める状態で。
- いつか。 タイムゾーン付きで。
- どの承認の下で公開されたか。
実用的なルールが2つあります。承認記録は運用ログより長く保存しましょう。 誰かが実際に尋ねるのは、ほとんどの場合承認についてだからです。そしてクライアントと日付範囲で検索できるようにしましょう。 監査の依頼は、必ずその形で届くからです。
ベンダー比較は簡単です。各社に「3ヶ月前の特定の投稿の承認履歴を出してください」と頼んでみましょう。デモで出てくるかどうか、それだけです。
購入前に確認すべきこと
本物の権限モデルと設定ページを分ける機能は、次のとおりです。
- ロールをクライアントごとに定義できる(ユーザーごとのグローバルな1ロールではない)。
- アカウント切り替えでも分離が保たれる(実際の契約社員ログインでテスト)。
- 指名されたレビュアーによる承認ルーティングと、定義された代替承認者。
- 単一投稿の承認履歴をエクスポートできる。
- シートなしでレビュアーがアクセスできる(クライアントの承認にライセンスコストがかからない)。
- SSOとディレクトリプロビジョニング(ITがユーザーリストを管理している場合)。ほとんどのソーシャルツールではエンタープライズプラン限定なので、契約段階ではなく最初の打ち合わせで確認しましょう。
PlanableとSprout Socialはどちらも、定義されたロールによる複数段階の承認に対応しています。Mydropは、クライアントごとのワークスペース、ロール、ドラフト自体へのコメント、承認ゲート、ログイン不要のレビューリンクを1つのシステムに統合。代理店が通常2つの別々のツールで組み合わせている構成を、1つにまとめられます。周辺の運用体制については、ソーシャルメディア代理店向けソリューションでより広いスタックを解説しています。
今週中に設定しましょう
3つのステップです。この順番で。
- 現在公開権限を持つすべての人間をリストアップします。 元契約社員や共有ログインも含めてください。リストは誰もが予想するより長いはずです。
- 各人に1つのロールと1つのクライアントスコープを割り当てます。 最初のパスで例外は認めません。
- クライアントのステークホルダーをレビューリンクに移行し、ユーザーアカウントを削除します。
カレンダーに90日後のリマインダーを設定して、ステップ1を再度実行しましょう。古いアクセス権限は、何度でも繰り返し発生する失敗だからです。無料で始めて、次のキャンペーンが始まるまでにロールとクライアントワークスペースをマッピングしておきましょう。















































Google review
Trustpilot review