複数人でSNSを運用するとき、出す前に誰かが見る仕組みが要ります。Bufferには、下書きと承認のフローが用意されています。
ただし、最初に確認すべき条件があります。下書きはすべてのプランで使えますが、下書きの承認はTeamプランだけの機能です。
そして、運用に乗せるうえで見落としやすい設定があります。承認依頼のメールは、既定では届きません。
この記事では、Buffer公式ヘルプセンターの記載をもとに、下書きと承認フローの回し方を整理します。
※ 本記事の内容は2026年9月時点でBuffer公式ヘルプセンターに記載されている内容を確認して書いています。
結論：下書きは全プラン、承認はTeamプランだけ
公式が、記事の冒頭に警告として置いています。
「下書きはすべてのプランで利用できますが、下書きの承認は私たちのTeamプランでのみ利用できます」
2つはまとめて語られることが多いのですが、使える条件が違います。
「下書き」と「承認」は別の機能
ここを分けて考えてください。下書きを保存しておくこと自体は、無料プランでもできます。
できないのは、承認を依頼して、別の人が承認するまで公開されない、という流れです。
つまり、ひとりで使っていて「書きかけを置いておきたい」だけなら、プランは関係ありません。チェック体制を作りたい場合にだけ、Teamプランが必要になります。
下書きは作りかけを保存しておく場所、承認は公開してよいかを人が判断する工程です。片方だけ使うこともできます。
承認が要らない運用もある
チームであっても、承認フローが必須とは限りません。
信頼している担当者が1人で回しているなら、承認は手間になるだけです。Teamプランに上げる前に、本当に「出す前に止める」必要があるかを考えてください。
必要になるのは、たとえばクライアントの投稿を扱う場合や、複数人が同じアカウントに投稿する場合です。誤りが出たときの影響が大きいほど、止める価値が上がります。プランごとの違いはBufferの料金プラン徹底解説で整理しています。
下書きは誰でも作れる。作れる場所は3つ
作成については、制限がありません。公式の記載です。
「ソーシャルチャンネルにアクセスできるすべてのユーザーは、権限に関係なく、下書きの投稿を作成できます」
プランの条件がないので、まずここから使い始められます。
作れる場所
公式が挙げているのは3か所です。
下書きを作れる3か所
権限に関係なく、チャンネルにアクセスできれば作れる
どこから作っても、同じ下書きの一覧に入ります。思いついた場所で保存しておけるということです。
保存した下書きは、あとから投稿に変えられます。
カレンダーから作るときの注意
3つ目のカレンダーから作る場合は、別の注意点があります。カレンダーでフィルタしているチャンネルが、作成画面で事前に選択されているという仕様です。
下書きの段階でも、出す先が入ったまま進むことになります。承認に回す前に、チャンネルの選択を確認してください。
この挙動の詳細はBufferのカレンダーの使い方で扱っています。承認フローを通しても、出す先が違っていれば止まりません。承認者は文面を見るからです。
権限で、できることが変わる
ここが、フローの骨格です。公式の記載です。
「あなたの権限レベルによって、下書きの投稿を管理するときに使えるオプションが決まります」
チームで使う場合、誰が何をできるかが役割で決まります。
自分の権限で何ができるかを知らないと、できないことを設定の問題だと考えてしまいます。
2つの権限レベル
公式が並べているのは2つです。
「アカウントオーナーと Full Access のユーザーは、すべての下書きを編集、削除、そしてキューへ移動できます」
「Needs Approval のユーザーは、自分自身の下書きについてのみ、編集、削除、そして承認の依頼ができます」
権限による違い
「自分の下書きだけ」という制限が、フローを成立させている
他人の下書きは触れない
Needs Approval のユーザーは、他の人が作った下書きを編集も削除もできません。
これは制限であると同時に、保護でもあります。複数人が同じ下書きを触って、どれが最新か分からなくなる事態を防いでいます。
裏を返すと、担当者が休んだときに、その人の下書きを別の担当者が引き継げません。できるのはオーナーとFull Accessだけです。
勝手に直されない代わりに、代わりに直してあげることもできません。修正が必要なときは、本人に戻すことになります。
権限の設計を先に決める
この仕様を踏まえると、権限の配り方が決まります。
複数人が相互に補い合う運用なら、Needs Approval だけで組むと詰まります。少なくとも1人はFull Accessを持っておく必要があります。
逆に、確認を確実に通したいなら、作る人を全員 Needs Approval にして、承認者だけをFull Accessにする。この形が素直です。
あとから変えると、作りかけの下書きの扱いが変わります。運用を始める前に決めておくほうが混乱しません。
承認を依頼する側の操作
Needs Approval のユーザーが行う操作です。公式の記載です。
「Needs Approval アクセスのユーザーとして、下書きに満足したら、承認を依頼する必要があります。そのためには、Request Approval をクリックするだけです。あなたの下書きは『Approvals』タブへ移動します」
依頼のボタンが出る2か所
公式は、ボタンの出る場所を2つ挙げています。
ひとつはコンポーザーの中です。「コンポーザーで Save and Request Approval というオプションが見えます」
もうひとつは、後から依頼する場合です。「Save Draft を選んだ場合でも、あとから Drafts タブへ行って、承認に出したい下書きを見つければ、いつでも Request Approval を選べます」
つまり、書き終えた勢いで出すことも、寝かせてから出すこともできます。
依頼を取り下げられる
間違えて出した場合の手当てもあります。公式の記載です。
「すでに承認を依頼したけれど、その下書きの作業を続けたい場合は、Revert Approval Request をクリックすることで、下書きの一覧に戻せます」
承認者が見る前なら、自分で引き戻せるということです。「出してしまったから、もう直せない」ということはありません。
ただし、承認者がすでに見ている可能性はあります。引き戻すなら早いほうがいいでしょう。
依頼は「移動」であって「送信」ではない
理解しておきたいのは、承認依頼がタブ間の移動だという点です。
Drafts タブにあったものが、Approvals タブへ動く。メールが飛ぶかどうかは、次に扱う通知設定に依存します。
つまり、依頼しただけでは、承認者が気づかない可能性があります。ここが運用の穴になりやすい部分です。
依頼を出しても、相手に通知が飛ぶわけではありません。画面の中で場所が変わるだけです。
ここを知らないと、待ち続けることになります。
オーナーとFull Accessには「承認依頼」が出ない
公式が警告として置いている項目です。
「あなたがアカウントオーナー、または Full Access のユーザーである場合、自分の下書きについて承認を依頼するオプションはありません。ただし、役立つ回避策があります」
仕様としては筋が通っている
Full Access のユーザーは、自分でキューへ移せます。承認を求める必要がありません。だからボタンが出ない。
論理としては自然です。しかし、実務では困る場面があります。
たとえば、自分はFull Accessだけれど、重要な投稿は誰かに見てほしい。あるいは、クライアントに確認してもらってから出したい。権限が強いことが、確認を受けられないことにつながっています。
通知を既定で送らないのは、人数が多いほど通知が増えるためだと読めます。ただ、知らないと「依頼したのに見てもらえない」という状態になります。
公式は「回避策がある」としている
公式は、この制限に対して「役立つ回避策があります」と書き、別の案内へリンクしています。
つまり、Buffer側もこれが不便だと認識しているということです。同じことで困っている人が一定数いる、と読めます。
ヘルプの中で「回避策」という言葉が出てくるのは、機能としては想定されていないが、運用で何とかできるという意味です。正規の手順ではないので、仕様変更で使えなくなる可能性もあります。恒久的な運用として組むなら、その前提で考えてください。
運用で回避するなら
公式の回避策とは別に、運用側でできることもあります。
確認を受けたい人があえて Needs Approval の権限で作業する、という形です。権限を落とせば、承認依頼のボタンが出ます。
ただしこの場合、他人の下書きを触れなくなります。権限は、できることとできないことがセットで動きます。どちらを優先するかは、運用の形で決めてください。
依頼を出したら、別の手段で声をかける。これを手順に入れておけば、仕様に関係なく回ります。
承認する側の操作
ここからは、オーナーとFull Accessのユーザーが行う操作です。
公式の記載です。「Needs Approval アクセスのユーザーが承認を依頼した下書きの投稿は、Awaiting Approval タブに表示されます。そこで、アカウントオーナーと Full Access のユーザーの両方が、確認して承認できます」
承認の前に直せる
承認する側も、内容を編集できます。公式の記載です。
「Approvals エリアで下書きの投稿に変更を加えたい場合は、Edit をクリックし、好きなように変更してから Save Draft をクリックします。投稿の準備ができたら、その投稿の Approve ボタンをクリックするだけです」
つまり、差し戻さずに、その場で直して承認できます。
誤字レベルの修正なら、戻すより直すほうが早くなります。作成者とのやり取りが1往復減ります。
差し戻すとメールが飛ぶ
戻す場合の挙動です。公式の記載です。
「ユーザーが作業を続けられるように、投稿を下書きの一覧に戻したい場合は、Reject をクリックします。その投稿を作成したユーザーは、『Collaboration』通知が有効になっていれば、メールの通知を受け取ります」
ここでも条件が付いています。「Collaboration通知が有効になっていれば」です。
差し戻したのに相手が気づかない、ということが起こり得ます。通知設定は、依頼する側と承認する側の両方で確認してください。
削除もできる
公式の記載です。「投稿を完全に削除したい場合は、Delete をクリックしてから Confirm をクリックします」
承認者は、他人の下書きを削除できます。差し戻すか、直して通すか、消すか。3つの選択肢があるということです。
消すという選択は、作成者から見ると「何も通知されずに消えた」という形になり得ます。差し戻しにはメール通知があると明記されていますが、削除については通知の記載がありません。チームで運用するなら、消すときは別途伝えるほうが親切です。
Add to Queue と Schedule Post の違い
承認やキューへの追加のとき、ボタンの表示が2種類あります。公式が説明しています。
並んでいる2つのボタンですが、意味が違います。押す前に区別しておいてください。
どちらを押すかで、公開の時刻の決まり方が変わります。
表示が変わる理由
公式の記載です。
「Add to Queue をクリックするということは、日付と時刻が選択されていないという意味なので、次に利用可能なキューの枠に追加されます」
「Schedule Post をクリックするということは、あらかじめ日付と時刻が設定されているという意味なので、あらかじめ予約されていた日付と時刻に予約されます」
ボタンの表示で、下書きの状態が分かる
押す前に、どちらが表示されているかを見る
ボタンが状態を教えてくれている
この仕様が便利なのは、ボタンの文言を見れば、その下書きに日時が入っているか分かることです。
承認する側は、作成者がいつ出すつもりだったかを把握していないことがあります。Schedule Post と出ていれば、作成者が日時を指定したということです。
キャンペーンの開始日に合わせた投稿なら、日時が指定されているはずです。もし Add to Queue と出ていたら、指定し忘れの可能性があります。
どちらが表示されているかで、いまの投稿がどの状態にあるかが分かります。
次の空き枠がいつか
Add to Queue を押した場合、投稿は「次に利用可能なキューの枠」に入ります。
これがいつになるかは、そのチャンネルの投稿スケジュールによります。設定によっては、承認した数分後に出ることもあれば、数日後になることもあります。
キューの仕組みはBufferのキューと投稿スケジュールの仕組みで整理しています。承認の前に、次の枠がいつかを把握しておくと安全です。
投稿スケジュールを決めていないと、この「次の空き枠」がありません。
オーナーは承認依頼を待たずに動かせる
もうひとつ、公式が書いている挙動があります。
「アカウントオーナー、または Full Access のユーザーとして、下書きを作成したユーザーがまだ承認を依頼していない場合でも、下書きの一覧からキューへ移動できます」
つまり、作成者が「まだ途中です」と思っているものを、承認者が出せてしまいます。
チームで使うなら、「Draftsに置いてあるものは未完成」というルールを共有しておく必要があります。
権限の高い人ほど、工程を飛ばせるということです。
メール通知は自分でオンにする
ここが、この記事でもっとも実務に効く項目です。公式が注記として置いています。
「注意：新しい下書きが確認できる状態になったときにメールを受け取りたい場合は、ダッシュボードの左下にあるプロフィールのアバターをクリックし、Settings を選び、次に Notifications を選んで、Collaboration をオンに切り替えてください」
既定ではない
公式が「オンに切り替えてください」と書いているということは、既定ではオフだということです。
つまり、承認フローを組んだだけでは、承認者にメールは届きません。誰かが依頼しても、承認者がBufferを開くまで気づかないという状態になります。
これは運用が止まる典型的な原因です。依頼した側は「出した」と思い、承認する側は「来ていない」と思う。
承認フローを使いたい場合は、自分で有効にする必要があります。Teamプランに上げただけでは動きません。
設定の場所
- ダッシュボードの左下のプロフィールのアバターをクリックする
- Settings を選ぶ
- Notifications を選ぶ
- Collaboration をオンにする
この設定はチャンネルごとではなく、アカウント単位です。一度オンにすれば、どのチャンネルの下書きについても届きます。逆に言えば、承認者が複数いる場合は、全員がそれぞれ自分で設定する必要があります。
Notificationsの中にあるため、普段の作業では通らない画面です。承認フローを導入した日に、関係者全員でこの設定を済ませるのがいちばん確実です。誰か1人が設定を忘れていると、その人のところで承認が止まったまま気づかれません。
オンにすると届く範囲
公式は、対象も明記しています。「有効にすると、ダッシュボード、モバイルアプリ、そしてBuffer API経由で作成された下書きについて、承認依頼のメールを受け取ります」
作られた場所を問わず届く、ということです。スマホから作られた下書きも、APIから入ってきた下書きも、同じようにメールで知らされます。
なお、この設定は承認する側だけでなく、依頼する側にも必要です。差し戻しの通知が届くのも、Collaborationがオンになっている場合だからです。
チームに人を追加したら、最初にこの設定を確認してもらう。これを手順に入れておいてください。
API経由でも、承認は必ず通る
自動化を考えている場合に重要な記載があります。
「Needs Approval のロールを持つチームメンバーが作成した投稿は、Bufferのダッシュボード、モバイルアプリ、あるいはBuffer API、MCPサーバー、Buffer APIを使うサードパーティのアプリのいずれで作成されても、常に承認待ちの下書きとして保存されます。その投稿は、承認者が先へ進めるまでDraftsに留まります」
抜け道がない
つまり、APIを使えば承認を飛ばせる、ということはありません。
権限がロールに紐づいているため、入口を変えても結果は同じです。Needs Approval のユーザーの投稿は、どこから作っても承認待ちになります。
これは、承認フローを設計する側にとっては安心できる仕様です。自動投稿ツールを噛ませても、チェックが外れません。
有効にすると、対象のメンバーは必ず承認を通ることになります。急ぎのときだけ飛ばす、という運用はできません。
自動化と承認は両立しにくい
一方で、自動化したい人には制約になります。
外部ツールから自動で投稿を流し込みたい場合、Needs Approval のアカウントを使うと、必ず人の手が要ります。完全な自動化にはなりません。
自動化を優先するなら、Full Access のアカウントを使うことになります。ただしその場合、チェックは掛かりません。どちらを取るかの判断になります。
自動で投稿を流し込む仕組みを組んでいる場合、承認の工程がそこで止まります。どちらを取るかの判断になります。
通知はどの経路でも同じ
公式は、通知についても補足しています。
「承認者には、Buffer内で作成された下書きと同じようにメールで通知されます。ダッシュボード、モバイルアプリ、APIのいずれから作成されたかを問いません。（中略）チームの承認者がCollaborationのメールを有効にしていれば、下書きがどの方法で作成されたかにかかわらず、同じ『承認待ちの下書きがあります』というメールを受け取ります」
経路によって通知が変わることはありません。ただし、ここでもCollaborationが有効であることが条件です。
承認待ちを1か所で見る
チャンネルが多いと、承認待ちを探すのが手間になります。公式のFAQに、解決策があります。
「承認待ちのすべての投稿の一覧を見ることはできますか。組織のすべての下書きを1か所で承認できますか」という問いに対して、「はい。All Channelsビューを使えば、承認待ちのすべての投稿の一覧にアクセスでき、承認のプロセスがとても簡単で効率的になります」と回答しています。
個別に開いて回らない
チャンネルごとに Approvals タブを開いて確認する、という方法もあります。しかし、チャンネルが10あれば10回開くことになります。
All Channelsビューなら、Approvalsタブを1回開くだけです。承認漏れは、見に行く場所が多いほど起きます。
All Channelsビューの使い方はBufferのチャンネルグループと全チャンネル表示で整理しています。
一覧から順に処理できるので、件数が多くても手が止まりません。
カレンダーでも確認できる
もうひとつの見方があります。カレンダーの投稿タイプのフィルタに、Pending Approval という選択肢があります。
これを選ぶと、承認待ちの投稿が日付の上に並びます。公開予定日が近いものから処理する、という優先順位の付け方ができます。
All Channelsビューは件数の把握に、カレンダーは緊急度の判断に向いています。詳しくはBufferのカレンダーの使い方で扱っています。
日付の並びで見られるので、公開日が近いものから片付けられます。
承認を溜めない仕組みにする
承認フローの最大の失敗は、承認者が詰まって全体が止まることです。
そうならないために必要なのは、3つだけです。Collaboration通知をオンにする。All Channelsビューで一覧を見る習慣をつける。承認者を1人にしない。
とくに3つ目です。公式によればアカウントオーナーとFull Accessのユーザーの両方が承認できます。承認者が複数いれば、1人が不在でも止まりません。
承認が滞ると、公開そのものが止まります。見る時間を決めておくのがいちばん簡単な対策です。
まとめ
下書きと承認フローについての要点です。
- 🔴 下書きは全プランで使えるが、下書きの承認はTeamプランのみ
- 下書きは権限に関係なく誰でも作れる。作れるのはキュー・Draftsタブ・カレンダーの3か所
- オーナーとFull Accessは、すべての下書きを編集・削除・キューへ移動できる
- Needs Approvalは、自分の下書きだけ編集・削除・承認依頼できる
- 承認依頼は Request Approval。コンポーザーの「Save and Request Approval」からも出せる
- Revert Approval Request で、依頼を取り下げて下書きに戻せる
- 🔴 オーナーとFull Accessには、承認依頼のオプションが出ない（公式は回避策があるとしている）
- 承認側はその場で編集してから承認できる。差し戻しは Reject
- Add to Queue は日時未設定、Schedule Post は日時設定済み。ボタンの文言で状態が分かる
- 🔴 承認依頼のメールは既定で届かない。Settings → Notifications → Collaboration をオンにする
- API経由でも、Needs Approvalの投稿は必ず承認待ちになる
- 承認待ちはAll Channelsビューで1か所にまとめて見られる
承認フローで止まるのは、たいてい通知の設定です。機能を有効にしただけでは、誰にも知らされません。運用を始める前に、関わる全員のCollaboration通知を確認してください。
よくある質問（FAQ）
下書きは無料プランでも使えますか
使えます。ただし承認はできません。公式には「下書きはすべてのプランで利用できますが、下書きの承認は私たちのTeamプランでのみ利用できます」と記載があります。
下書きはどこから作れますか
3か所あります。公式には「チャンネルのキューから」「チャンネルのDraftsタブから」「カレンダーから」と記載があります。また「ソーシャルチャンネルにアクセスできるすべてのユーザーは、権限に関係なく、下書きの投稿を作成できます」とされています。
他の人の下書きを編集できますか
権限によります。公式には「アカウントオーナーと Full Access のユーザーは、すべての下書きを編集、削除、そしてキューへ移動できます」「Needs Approval のユーザーは、自分自身の下書きについてのみ、編集、削除、そして承認の依頼ができます」と記載があります。
承認を依頼したあとに取り消せますか
取り消せます。公式には「すでに承認を依頼したけれど、その下書きの作業を続けたい場合は、Revert Approval Request をクリックすることで、下書きの一覧に戻せます」と記載があります。
自分で自分の投稿を承認に出せません
仕様です。公式には「あなたがアカウントオーナー、または Full Access のユーザーである場合、自分の下書きについて承認を依頼するオプションはありません」と記載があります。ただし公式は「役立つ回避策があります」として別の案内へリンクしています。
承認依頼のメールが届きません
設定が必要です。公式には「ダッシュボードの左下にあるプロフィールのアバターをクリックし、Settings を選び、次に Notifications を選んで、Collaboration をオンに切り替えてください」と記載があります。既定では届きません。
差し戻すと相手に通知されますか
条件付きで通知されます。公式には「その投稿を作成したユーザーは、『Collaboration』通知が有効になっていれば、メールの通知を受け取ります」と記載があります。相手側の設定にも依存します。
Add to Queue と Schedule Post は何が違いますか
下書きに日時が入っているかどうかです。公式には「Add to Queue をクリックするということは、日付と時刻が選択されていないという意味なので、次に利用可能なキューの枠に追加されます」「Schedule Post をクリックするということは、あらかじめ日付と時刻が設定されているという意味」と記載があります。
API経由なら承認を飛ばせますか
飛ばせません。公式には「Needs Approval のロールを持つチームメンバーが作成した投稿は、Bufferのダッシュボード、モバイルアプリ、あるいはBuffer API、MCPサーバー、Buffer APIを使うサードパーティのアプリのいずれで作成されても、常に承認待ちの下書きとして保存されます」と記載があります。
承認待ちをまとめて確認できますか
できます。公式のFAQには「All Channelsビューを使えば、承認待ちのすべての投稿の一覧にアクセスでき、承認のプロセスがとても簡単で効率的になります」と記載があります。カレンダーの投稿タイプのフィルタでも「Pending Approval」を選べます。