BufferのAI Assistantで投稿文を作った後は、文章の採用、下書き保存、承認、キューへの予約を分けて確認します。カレンダーに日時付きの下書きがあっても、それだけで投稿が予約されたとは限りません。
この記事はBufferのWeb版で、AIの候補文を下書きとして残し、必要な承認を経て予約へ進める手順です。実アカウントでの生成、保存、承認、予約、公開は行っていません。後半のイベントと確認表は架空例です。
目次
AIへ渡すのは、URLだけでなく確認済みの内容
Buffer公式は、AI AssistantをPublishingの作成画面とCreateで使えると説明しています。候補を生成し、言い換えや短縮などで整え、Insertで投稿文へ入れる流れです。また、AIは渡されたURLを直接開いて読めないと明記しています。Buffer公式：Using AI Assistant（新しいタブで開く）
「このリンクを読んで告知して」とだけ頼まず、公開してよい本文と確定条件を渡します。AIがリンク先を確認したような文章を返しても、掲載内容の読取証拠にはなりません。
例えば架空の社内勉強会なら、次の材料を準備できます。
表は横にスクロールできます
| 材料 | 架空の確定内容 | AIに補わせないこと |
|---|---|---|
| 目的 | 操作手順を学ぶ勉強会の参加案内 | 必ず習得できるという保証 |
| 日時 | 11月12日14時、日本時間 | 別日や別のタイムゾーン |
| 対象 | 事前登録した社内メンバー | 社外にも自由参加できるという案内 |
| 申込 | 承認済みの案内リンクを使用 | 未確認の短縮URLや申込期限 |
| 話者 | 名前と肩書を確認済みの範囲で記載 | 架空の実績・推薦 |
依頼文の例です。角括弧は入力欄であり、そのまま公開する文字列ではありません。
［投稿先と読者］に向け、以下の確認済み情報だけから告知案を作ってください。日時・対象・申込先を保持し、成果の保証、経験談、未記載の特典を追加しないでください。リンク先を読んだ前提にせず、情報不足は質問として返してください。入力：［公開してよい本文と条件］。
AIの文を採用するときは、元資料へ戻って日時、対象、リンク、主張を確認します。語調を整える操作で、条件まで変わっていないかも読みます。
Insert後は、まず下書きへ保存する
候補文を作成画面へ入れたことと、下書きを保存したことは別です。対象のSNSアカウントを確認し、文と素材を読み直して、Save as Draftで残します。下書き一覧で該当する文を開き、保存した対象と内容を確認してください。
公式は、下書きは日時なしでも、事前に日時を指定しても保存できると説明しています。日時付きの下書きはカレンダーへ表示されますが、その時刻より前にキューへ移されなければ、自動では公開されません。Buffer公式：Saving and scheduling drafts（新しいタブで開く）
このため「カレンダーに入っています」という報告だけでは、下書きか予約投稿かが分かりません。日時を添えて、現在の状態も伝えます。反対に、日時を付けていない下書きがカレンダーに見えないことだけで、保存失敗とは判断しません。対象チャンネルのDraftsを確認します。
複数チャンネルへ下書きを保存した場合は、それぞれ独立した下書きになるという公式説明です。一つだけ直して全投稿先を直したつもりにせず、アカウントごとの対象を確認します。
Teamの承認は、プランと権限で操作が変わる
公式は、下書き自体は全プランで利用でき、下書きの承認はTeamプランの機能と説明しています。Needs Approvalの利用者は自分の下書きを編集し、Request Approvalから承認を依頼します。OwnerとFull Accessの利用者は承認を行え、自分の下書きに対するRequest Approvalは表示されません。Buffer公式：Managing and approving drafts（新しいタブで開く）
承認ボタンがないときに、すぐ接続不良と決めつけないでください。対象組織のプラン、自分の役割、操作している下書きの所有者を確認します。見える操作が違う理由と、実際に誰へ確認を渡すかを分けます。
OwnerやFull Accessは、依頼前の下書きもキューへ移せる説明です。したがって、承認機能があることだけで、全員の全投稿が必ず別の人を通ると考えません。チームで必要な確認者と投稿権限を決め、操作可能なことと、社内手順として行ってよいことを区別します。
承認する前に、日時と投稿先を確認する
確認担当者は文章だけでなく、対象アカウント、素材、リンク、公開してよい時刻を読みます。AIが作った版から修正が入っていれば、現在の下書きを承認対象にします。別のチャットで確認した旧文を見て、変更済みの本文まで承認したつもりにしないようにします。
公式の操作説明では、日時未設定ならAdd to Queueで次の空き枠へ、日時が設定されていればSchedule Postで指定日時へ進む違いがあります。承認画面で予約へ進める前に、どちらの動作になるか確認してください。
表は横にスクロールできます
| 操作前の状態 | 確認すること | 避けたい勘違い |
|---|---|---|
| 日時なしの下書き | 次の空き枠が意図した時刻か | 承認した日の好きな時間に出ると思う |
| 日時付きの下書き | 日時、対象アカウント、現在の本文 | カレンダーにあるので予約済みと思う |
| 複数チャンネルの下書き | 各下書きの本文と素材 | 一つの承認・修正で全対象が同じになると思う |
| 修正が必要な案 | 下書きへ戻す対象と理由 | 予約後に直せばよいと先へ進める |
予約へ進めた後は、キューの対象投稿で日時と内容を確認します。チームの進捗表にScheduledと書くのは、予約状態を確認してからにします。公開されたかの確認は、さらに後の別工程です。
四つのケースで、次の行動を決める
以下は架空の確認例です。Bufferで観測した試験結果ではありません。
表は横にスクロールできます
| ケース | 状況 | 次にすること |
|---|---|---|
| A | AI案で「社内」が消え、誰でも参加できる表現になった | 元資料へ戻り、対象を直してから保存・依頼 |
| B | 日時付きDraftはあるが、キューに対象がない | 下書きのままと記録し、承認と予約が必要か確認 |
| C | Full Accessの本人にRequest Approvalが出ない | 権限に応じた仕様を確認し、必要な別担当レビューを組む |
| D | LinkedIn案だけリンクを修正し、別チャンネル案が残った | 各下書きを開き、修正範囲を照合 |
AではAIへ短縮を頼んだ結果、重要な対象条件が落ちています。文の読みやすさだけで採用しません。Bでは日時の存在と公開の準備が混同されています。Cでは機能不具合と権限仕様を分け、Dでは保存単位の違いを確認します。
修正後も、同じ元資料と現在の下書きを照合します。予約状態が分からないときは、すぐ手動投稿へ切り替えず、キューと対象投稿を先に確認して重複投稿を避けます。
原稿づくりと予約の担当を決める
継続運用なら、原稿を作る人、内容を確認する人、予約へ進める人、公開後を確認する人を決めます。一人で兼ねる場合も、確認する対象は分けます。AIに文を作らせることは、その人の承認や投稿権限の代わりにはなりません。
元記事から投稿の論点を選ぶ段階はブログからLinkedIn投稿を作る方法、月全体の企画と制作状況を整理する段階はSNS投稿カレンダーの作り方を参照してください。Bufferでは、確認した原稿がどの下書きへ入り、誰の操作で予約へ進んだかを対応させます。
参考資料
- Buffer：Using Buffer's AI Assistant（新しいタブで開く）
- Buffer：Saving and scheduling draft posts（新しいタブで開く）
- Buffer：Managing and approving draft posts（新しいタブで開く）
資料確認日：2026年10月21日。AI Assistantの利用条件、承認権限、予約機能と対応SNSは、利用時点の公式案内と自分の組織・アカウントの設定で確認してください。