エージェントが書いた投稿に人の承認を：関門はどこに置くべきか
AI エージェントが SNS 投稿を書いて予約するとき、人の承認をどこに入れるか。キーのスコープ、下書き優先、承認リンクを解説します。
エージェントが書いた投稿への人の承認は、1か所に置くべきです。完成した下書きと予約のあいだです。調べる、書く、下書きを作るところまではエージェントに自由にやらせ、何を公開するかは人、あるいはクライアントが決めます。これを支えるのは善意ではなく、キーのスコープです。承認の段階を経るまでは、エージェントが技術的に公開できない状態にしておくのです。
この記事では、なぜこの位置がうまく機能するのか、Shager でどう設定するのか、そして20件の下書きが一度に届いたときにレビュー担当者が実際に何を確認すべきかを説明します。
エージェントの一挙手一投足を承認すればよいのでは？
エージェントを導入すると、アップロードもキャプションも検索も、すべてに確認を求めようとするチームがあります。安全そうに見えますが、1週間もたずに破綻します。レビュー担当者は確認疲れを起こし、読まずに「はい」を押すようになります。これは関門がまったくないより悪い状態です。
MCP の仕様は、バランスの取れた立場をとっています。信頼と安全のために、ツールの呼び出しを拒否できる人が常にループの中にいるべきだとし、クライアントは機微な操作について確認を求めるべきだとしています。鍵となるのは「機微な」という言葉です。アカウントの一覧を読むのは機微ではありません。クライアントの名前で公の発言をするのは機微です。
関門は正確にはどこに置くのですか？
エージェントの仕事を一連の鎖として見て、どの輪が取り消せるかに印を付けてみましょう。
| ステップ | 取り消せるか | 人が必要か |
|---|---|---|
| ワークスペース、グループ、チャンネルを調べる | 何も変わらない | 不要 |
| URL からメディアをアップロードする | ワークスペース内で非公開 | 不要 |
| 投稿の下書きを作る | 非公開で、編集も削除もできる | 不要 |
| 投稿を予約する | 送信時刻までは取り消せる | 必要 |
| 公開する | 公開され、すぐに見られる | 必要（すでに判断済み） |
取り返しがつかないのは公開の瞬間で、それを止められる現実的な最後の地点が予約です。だから関門はそこに置きます。それより前のすべては中断なく進められ、それこそがエージェントの効率の源です。
スコープはどうやって関門を強制するのですか？
Shager の API キーには、read、write、publish のスコープがあります。read と write を持つキーは、関門より上のステップはすべて実行でき、下のステップは一切実行できません。エージェントが schedule_post を試みても、呼び出しは失敗します。
これにより、実用的な構成が3つ考えられます。
- エージェントが下書きし、人が予約する。 エージェントのキーは
readとwrite。人がダッシュボードで下書きを確認し、予約します。どのチームもここから始めるべきです。 - エージェントが下書きし、クライアントが承認し、エージェントが予約する。 エージェントのキーには
publishもありますが、スキルの指示で、承認が下りた投稿だけを予約させます。効率的ですが、指示が守られることが前提なので、監査ログを定期的に確認してください。 - キーを2つにする。 コンテンツ担当のエージェントは
publishのない下書き用キーを使い、予約の段階は、人か、指示を狭く絞ったエージェントが publish 用のキーで行います。大きめの代理店にとって、最もきれいな分離です。
自己登録したエージェントは、さらに制約の多い状態から始まります。/auth.md から自分で登録したエージェントが受け取るのはサンドボックスで、下書きは作れますが、人が引き継ぐまでは予約、公開、接続リンクの作成、承認依頼の送信ができません。引き継ぎの際に、キーに publish を与えるかどうかを人が決めます。全体の流れはエージェントの自己登録と引き継ぎで解説しています。
クライアントの承認はどう組み込むのですか？
代理店の仕事では、承認する人はクライアントであることがよくあります。Shager の request_approval は承認リンクを作り、クライアントはログインもアカウント作成もせずにそれを開けます。投稿を確認し、承認または却下します。
典型的な流れは次のとおりです。
create_post caption, group_ids, media_ids, per_channel[...], no schedule_at
request_approval post id, returns an approval link for the client
get_post later: read the approval status
schedule_post only if approved; schedule_at "2026-09-03T09:00:00+02:00"
そして、これに対応するエージェント向けの指示を、スキルに書いておきます。
Never call schedule_post on a post unless get_post shows it was approved.
If a post is rejected, do not schedule it. Report the rejection to the
account lead, wait for revision notes, then create a revised draft with
create_post and request approval again.
承認が何日も止まってしまうのを防ぐ方法も含めた全体のプロセスは、代理店のためのクライアント承認ワークフローで紹介しています。
レビュー担当者は実際に何を確認すべきですか？
エージェントの下書き20件をレビューするのは、人が書いた投稿1件をレビューするのとは別の仕事です。探すのは系統的なエラーです。エージェントは同じ間違いを一貫して繰り返すからです。次の順番で読んでください。
- 主張。 価格、日付、特典、健康やお金に関する記述。ブリーフと照らし合わせます。実害が生じるのはここです。
- リンク。 2〜3のバリエーションで、最初のコメントのリンクを開きます。正しいランディングページに飛ぶか確認します。
- アカウントごとの細部。 札幌版には札幌、福岡版には福岡と書かれているか、抜き取りで確認します。地域に合わせたキャプションで、エージェントが最もよく犯すのが地域情報の取り違えです。
- バリエーション。 バリエーションを並べて流し読みします。1語だけ入れ替えた同じ文に見えるなら、もっとはっきり違うものを求めましょう。
- フォーマット。 リールとショートには長さとアスペクト比の要件があります。Shager は送信前にメディアを各 SNS のルールで検証しますが、選んだフォーマットがクリエイティブに合っているかは、レビュー担当者も確認すべきです。
問題を見つけたら、投稿だけでなく、その原因となったルールを直します。エージェントが割引をでっち上げたなら、「ブリーフにない価格や割引は決して書かない」と指示に加えます。
関門を緩めてよいのはいつですか？
緩めるなら少しずつ、根拠があるときだけにします。数週間にわたって、主張やリンクの誤りがレビューで一度も見つからなかったなら、豆知識や営業時間のような定番コンテンツは軽めのレビューに移し、特典付きのキャンペーンは引き続きしっかりレビューする、といった判断もあり得ます。エージェントのダッシュボードの監査ログには、エージェントが行ったすべての呼び出しが残るので、関門を緩めても見えなくなるわけではありません。
よくある質問
クライアントは Shager のアカウントなしで投稿を承認できますか？
はい。承認リンクはログインなしで開けます。クライアントが投稿を見て承認または却下し、その結果をエージェントかアカウント担当者が確認します。
publish スコープなしでエージェントが公開しようとしたら、どうなりますか？
呼び出しは構造化されたエラーで拒否され、何も予約されません。関門をスコープに置く意味はそこにあります。指示が間違っていても、関門は守られるのです。
代理店自身のアカウントへの社内投稿なら、承認を省いてもよいですか？
関門を軽くするのはかまいませんが、何らかの人の確認は残してください。代理店のアカウントはあなたの公の評判そのものです。そこでのエージェントのミスは、クライアントのページでのミスと同じくらい目立ちます。
新しいクライアントには、まず1つ目の構成、つまりエージェントが下書きし人が予約する形から始めましょう。接続の詳細はエージェント向けページにあります。そこから先は、実際のレビューのデータを根拠に、締めたり緩めたりしていけばよいのです。
