数百のアカウントに投稿するAIエージェントの安全ルール

数百のアカウントに投稿する AI エージェントを安全に運用するためのルールは、それほど多くありません。公開は各 SNS の公式 API 経由に限ること、必要最小限の権限のキーだけを持たせること、複数のアカウントに同じキャプションを送らないこと、アカウント間で送信の間隔を空けること、各 SNS の制限とポリシーを守ること、そして配信をすぐに止める手段を用意しておくことです。これらの多くはプラットフォームとキーのスコープで強制すべきもので、エージェントへの指示は唯一の防御ではなく、2層目の守りと位置づけます。

以下は私たちが推奨するルールブックで、ほとんどをそのままエージェントのスキルに貼り付けられるように書いています。各ルールには理由を添えました。理由を理解しているエージェントは、指示だけを渡されたエージェントよりも想定外のケースにうまく対処できるからです。

なぜエージェントには専用の安全ルールが必要なのか

人が投稿を予約する場合、ミスは1件ずつ起きます。エージェントの場合、ミスはまとめて起きます。指示に誤りがあれば、その誤りは配信対象のすべてのアカウントに及びます。規模は、良い仕事も悪い仕事も同じように増幅します。

各 SNS も、投稿量と繰り返しを監視していることを明言しています。Meta のスパムに関するポリシーは、手動か自動かを問わず極端に高い頻度での投稿や、繰り返しの多いコンテンツを対象にしています。YouTube のスパム、欺瞞行為、詐欺に関するポリシーも、繰り返しの多いコンテンツや対象を絞らないコンテンツを対象にしています。どちらも行動に関するポリシーであり、ボタンを押したのが人かソフトウェアかは問題にしていません。

横にスクロールすると図全体を表示できます

ルールブック

ルール1：公式 API だけを使う

エージェントは、各 SNS の公式 API を使うプラットフォームを通して公開します。ブラウザの自動操作、ログイン情報の共有、非公式のエンドポイントは使いません。Shager は公式 API だけを使って公開するので、このルールはエージェントの規律ではなく、プラットフォームの選択によって満たされます。

理由：非公式の方法は利用規約に違反してアカウントそのものを危険にさらし、しかも予測できない形で失敗します。

ルール2：最小権限のキー

どのエージェントも、最初は read と write で始めます。publish を付けるのは、そのエージェントに予約を任せてよいと人が判断したときだけです。キーはクライアントごと、またはエージェントごとに分け、1つを無効にしてもすべてが止まらないようにします。

理由：公開できないキーなら、誤った指示は誤った下書きになるだけで、実害はありません。設定方法は API キー、スコープ、監査の記事で解説しています。

ルール3：まず下書き、予約はその後

どの配信でも、まず下書きを作ります。予約は、レビューやクライアントの承認を経た後の別ステップです。

理由：エージェントの制作作業を遅らせることなく、自然なチェックポイントが生まれます。詳しい理由はエージェントの投稿を人が承認するをご覧ください。

ルール4：アカウントごとにキャプションを変える

1つの投稿を多数のアカウントに送るときは、per_channel を使ってアカウントごとに専用のキャプションを、必要に応じて専用の最初のコメントも用意します。主張やオファーは固定したまま、書き出し、地域の情報、言い回し、行動喚起を変えます。

理由：多数のアカウントに同じ瞬間に同じ文章が並べば、外から見ればまさに繰り返しのコンテンツです。ブランドから外れずに書き分ける方法は、アカウントごとのキャプションの書き分けのガイドで紹介しています。

ルール5：送信に時間差を付ける

すべてのアカウントに同じ秒で送らないこと。Shager の stagger_seconds は、アカウント間にランダムな遅延の範囲を設定するもので、デフォルトは [30, 90] 秒です。大きなグループや慎重に扱うべきクライアントでは、この幅を広げます。

理由：送信を時間的に分散させるのは、実際のチームが多数のページに投稿するときのやり方そのものであり、自動化らしく見える集中的な送信を減らせます。

ルール6：各 SNS の厳格な制限を把握する

公表されている制限もあります。たとえば Instagram は、アカウントごとに 24時間の移動期間内で API から公開できる投稿は100件までと明記しています。通常の運用で、エージェントがこうした制限に近づくことがあってはいけません。近づくなら、計画のほうが間違っています。メディアにも形式の制約があります。リール、ショート、ストーリーズ用の動画をアップロードするときは、upload_media_from_url に width、height、duration_ms を渡し、投稿を組み立てる前に検証できるようにしてください。

理由：送信時に拒否された投稿は枠を1つ無駄にしますし、失敗の繰り返しはクライアントのアカウントに残したくないノイズです。

ルール7：送信前のチェックはプラットフォームに任せる

Shager は送信前に、各投稿が投稿先 SNS のルールに沿っているかをチェックします。エージェントは検証エラーを情報として扱うべきです。エラーコードとメッセージを読み、投稿を修正して、一度だけやり直します。2回失敗したら、止めて報告します。

理由：やみくもにリトライするエージェントは、1つの問題を何十件もの失敗した呼び出しに変えてしまいます。

ルール8：API 自体のレート制限を守る

Shager API の上限は、キーごとに毎分120リクエストです。うまく設計された配信は、アカウントごとに1回ずつ呼び出すのではなく、グループ指定と per_channel を使って1回の create_post で済ませるので、上限に近づくことはまずありません。

理由：まとめて処理するほうが速く、エージェントのロジックに待機ループを入れなくても制限内に収まります。

ルール9：停止の手順を用意する

大きな配信の前に、止め方を把握しておきます。list_posts で予約内容を確認でき、配信の label を見ればどの投稿がその配信に属するかがわかります。cancel_post を使えば、送信時刻の前に1件ずつ取り下げられます。また、人がエージェントダッシュボードでキーを無効にすれば、そのエージェントからのそれ以降の呼び出しはすべて止まります。

理由：停止ボタンは、必要になる前に設計しておくものです。

ルール10：監査ログを残し、実際に読む

エージェントの呼び出しはすべて、エージェントダッシュボードの監査ログに記録されます。問題が起きた後だけでなく、毎週誰かが目を通すべきです。

理由：エージェントの振る舞いのずれは、表に出る前にまずログに現れます。

スキル用のルールブック

スキルやシステムプロンプトに入れるための要約版です。

SAFETY RULES (always apply)
1. Create drafts only unless the instructions explicitly say to schedule
   an approved post.
2. When targeting more than one account, always use per_channel with a
   distinct caption for each account. Never send identical captions.
3. Use stagger_seconds of at least [30, 90]; use [60, 180] for groups
   larger than 20 accounts.
4. For video, always pass width, height and duration_ms on upload.
5. Never state a price, discount, date or claim that is not in the brief.
6. On a validation error, fix and retry once. On a second error, stop and
   report the error code and message.
7. Label every post in a run with the same label so the run can be listed
   and cancelled as a group.
8. Never call schedule_post on a post that has not been approved.

ルール3のしきい値は私たちの提案であり、SNS のルールではありません。クライアントに合った値を選び、一貫して使ってください。

安全な大規模配信の流れ

1. whoami で、キーのスコープがタスクに合っているかを確認します。
2. list_groups と list_channels で対象のアカウントを正確に特定し、他の作業に入る前にその件数を報告します。
3. upload_media_from_url で、サイズと長さをすべて指定してアップロードします。
4. create_post で、group_ids、per_channel、first_comment、stagger_seconds、配信用の label を指定して下書きを作ります。
5. request_approval を呼ぶか、人のレビュー担当に引き継ぎます。
6. 承認後、承認された投稿ごとに schedule_post を呼びます。
7. 送信時刻を過ぎたら、いくつかを抜き出して get_post で配信を確認し、失敗があれば報告します。

ステップ2は、多くのチームが飛ばして後悔するステップです。「この配信は3つのグループ、212アカウントが対象です」とエージェントが宣言すれば、下書きが1件もできないうちに、人が「そのグループは違う」と言えるチャンスが生まれます。

横にスクロールすると図全体を表示できます

よくある質問

エージェント経由の投稿は、手作業より危険ですか？

リスクの種類が違うだけで、必ずしも高いわけではありません。エージェントはミスを大規模に繰り返し、人はミスを散発的に起こします。スコープ付きのキー、下書き優先の配信、キャプションの書き分けがあれば、多数のアカウントを扱う場合、エージェントによる配信は手作業より一貫性を保てることもあります。

stagger_seconds の最も安全なデフォルトは？

Shager のデフォルトは、アカウント間で30〜90秒です。理想的な間隔を公表している SNS はないので、大きなグループでは幅を広げ、経験則ではなく結果を見て判断してください。

予約した配信を、開始後に止められますか？

はい。まだ送信されていない投稿は cancel_post で取り下げられ、配信共通のラベルがあれば list_posts で簡単に見分けられます。キーを無効にすれば、それ以降の呼び出しはすべて止まります。

SNS が大量投稿をどう扱うかの背景は、大規模投稿でスパム判定を避ける方法をお読みください。そのうえで、次の配信の前に上のルールブックをエージェントのスキルにコピーしておきましょう。