エージェントの予約戦略：タイムゾーン、時間差送信、40ページへの9時一斉投稿を避ける方法
AIエージェントが多数のアカウントに投稿を予約する方法。ISO 8601のオフセット、タイムゾーンと夏時間、時間差の計算、グループの日別分割、安全な取り消し。
エージェントの予約戦略は、3つのルールに集約されます。時刻は必ず、クライアントのタイムゾーンから計算した明示的なオフセット付きの ISO 8601 で送ること。すべてを一度に送るのではなく、アカウントごとの時間差送信はプラットフォームに任せること。そして大量のアカウントは1回の巨大な配信にせず、複数の投稿と時刻に分けることです。まず下書きを作り、予約は別のステップにして、取り消しを手軽にできるようにしておきます。
以下では、Shager が求める具体的なフィールドとともに、これらのルールを実践に落とし込んでいきます。
なぜエージェントは時刻を間違えるのか
言語モデルは時計が苦手です。教えない限り今が何時かを知らず、平気でオフセットなしの 2026-11-02T09:00:00 を書き、タイムゾーンの変換を頭の中で済ませてしまいます。どれも、9:00 のはずの投稿が 7:00 に出てしまう原因になります。
Shager は曖昧さを受け付けないことで、その原因の1つを断っています。schedule_at はオフセット付きの ISO 8601 でなければならず、たとえば 2026-10-20T09:00:00+03:00 のように書きます。Z もオフセットもないタイムスタンプは検証で弾かれます。この形式は RFC 3339 で定義されたプロファイルなので、エージェントの指示にもその名前をはっきり書いておくとよいでしょう。
もう1つの原因はオフセットそのものです。+03:00 は10月のイスラエルなら正しいのですが、12月には誤りです。オフセットは夏時間によって変わり、切り替わる日もイスラエル、EU、米国でそれぞれ異なります。エージェントにオフセットを決め打ちさせてはいけません。主要な言語ならどれにも付属している IANA タイムゾーンデータベースでクライアントのタイムゾーン名を解決し、その日付に合ったオフセットを計算させます。
from datetime import datetime
from zoneinfo import ZoneInfo
local = datetime(2026, 11, 2, 9, 0, tzinfo=ZoneInfo("Europe/Berlin"))
print(local.isoformat()) # 2026-11-02T09:00:00+01:00
Shager の各ワークスペースにも timezone があります。これはワークスペースの作成時に設定する IANA のタイムゾーン名です（デフォルトは Asia/Jerusalem）。エージェントにはこれを読み取って使わせてください。1つのエージェントで多数のクライアントを担当すると、すべてのクライアントが同じタイムゾーンとは限りません。各クライアントがどのタイムゾーンにいるかを記録している唯一の場所が、ワークスペースです。
下書きしてから予約する
create_post は、schedule_at を渡せばその場で予約できます。ただ、クライアントの案件で私がエージェントにそれをさせることはほとんどありません。より安全なのは、呼び出しを2回に分けるやり方です。
schedule_atを付けずにcreate_postを呼び、下書きとして保存します。- 人またはルールによる確認が済んだら、投稿 ID と時刻を指定して
schedule_postを呼びます。
{
"tool": "schedule_post",
"arguments": {
"workspace_id": "ws_example",
"post_id": "pst_example",
"schedule_at": "2026-10-20T09:00:00+03:00"
}
}
権限の面でも理由があります。Shager では、予約には API キーの publish スコープが必要で、下書きには write だけで足ります。publish は、人がエージェントのサンドボックスを引き継ぐときに明示的に付与するもので、このスコープを持たないキーを作ることもできます。この分担により、下書きを作るエージェントには大きな自由を与えつつ、最後のステップは人の手に残せます。詳しくは API キー、スコープ、監査をご覧ください。
schedule_post は、失敗時にも役立つ動きをします。どれかのアカウントが投稿を拒否しそうな場合や、クライアントの承認が必要なのに得られていない場合は、半分失敗するような配信を予約するのではなく、理由をはっきり示してエラーを返します。
時間差送信には実際どのくらいかかるのか
Shager はアカウントごとに順番に公開し、同じ SNS のアカウント間にはランダムな待ち時間を挟みます。その範囲を決めるのが stagger_seconds フィールドで、デフォルトは [30, 90] です。SNS どうしは並行して処理されるので、配信全体の所要時間は、アカウント数が最も多い SNS で決まります。
計算は簡単なので、エージェントに時刻を決める前に計算させられます。
| 最も多い SNS のアカウント数 | 時間差 | 平均間隔 | おおよその所要時間 |
|---|---|---|---|
| 10 | [30, 90] | 60秒 | 約9分 |
| 40 | [30, 90] | 60秒 | 約39分 |
| 40 | [60, 180] | 120秒 | 約78分 |
| 120 | [30, 90] | 60秒 | 約2時間 |
多くの人が驚くのは最後の行です。クライアントから「10:00 までに全部公開されていること」と言われていて、Facebook ページが120あるなら、9:00 の予約では間に合いません。開始を早めるか、配信を分けるかのどちらかです。
締め切りに合わせるために、時間差を [0, 5] に縮めるのはやめましょう。待ち時間があるのは、大量配信が1つの発信元からの集中的な送信に見えないようにするためです。1本のキャプションよりペース配分のほうが重要な理由は、大規模投稿でスパム判定を避ける方法の記事で解説しています。
時間帯ではなくグループで分ける
大口のクライアントには、アカウントのグループごとに1つの投稿を作り、それぞれに別の時刻を設定するほうが効果的です。たとえば支店ページが90ある小売チェーンなら、地域別にグループ化できます。エージェントは地域グループごとに1つずつ、計3つの投稿を作り、別々の日の朝に、あるいは1日の中に分散させて予約します。
{
"tool": "create_post",
"arguments": {
"workspace_id": "ws_example",
"group_ids": ["grp_north"],
"caption": "Winter hours start Sunday at every northern branch.",
"per_channel": [
{ "channel_id": "ch_fb_haifa", "caption": "Haifa branch: winter hours start Sunday. We open at 8:30." }
],
"campaign": "winter-hours",
"stagger_seconds": [60, 150]
}
}
グループは create_group で作成し、名前と channel_ids のリストを渡します。グループを投稿先に指定すると、そのグループ内の有効なチャンネルがすべて追加されます。
エージェントが守るべき SNS の制限
各 SNS 自体も、1つのアカウントが API 経由で公開できる量に上限を設けています。Meta は、24時間の移動ウィンドウ内に API から公開できる Instagram 投稿数にアカウント単位の上限があることを明記しており、現在の使用量を確認できる content_publishing_limit エンドポイントも提供しています。YouTube はプロジェクトごとに API の割り当てを設けており、デフォルトは1日あたり10,000ユニットで、アップロードは特にコストの高い操作です。
送信の側は Shager が担いますが、計画の側はエージェントの仕事です。1日に6本も投稿されるアカウントは、API の問題である前に戦略の問題です。私はエージェントにシンプルな社内ルールを与えています。人が別の指示をしない限り、フィード投稿は1アカウントにつき1日1本までです。
カレンダー、祝日、静かな日
Shager のカレンダーにはイスラエルの祝日が含まれています。イスラエルのクライアントにとってこれは重要で、大きな祝日の前夜に予約した投稿は、オフラインになっている人々に届くことになるからです。それ以外の地域のクライアントについては、休業日やイベントをまとめたクライアント独自のカレンダーを、エージェントの指示に含めてください。モデルは祝日がいつ頃かをおおまかには知っていますが、このクライアントの倉庫が四半期最後の金曜日に棚卸しで休みになることまでは知りません。
取り消しと移動
cancel_post は、公開が始まっていない投稿の予約を取り消します。削除はしません。投稿は承認済みの下書きに戻るので、エージェントは新しい時刻を指定して再び schedule_post を呼べます。取り消しの対象はまだ待機中の投稿だけで、公開が始まった後は cancel_post は使えません。
何かを動かす前に、エージェントは status を SCHEDULED にして list_posts を呼び、そのワークスペースのキューにすでに何が入っているかを確認すべきです。同じアカウントに2つの予約配信が同じ時間帯に重なる。これが、私が見る中で最も多い自滅的なミスです。
よくある質問
エージェントが UTC で送った場合、Shager はどのタイムゾーンを使いますか？
Z 付きのタイムスタンプは曖昧さがないので、Shager はその正確な時刻で予約します。ワークスペースのタイムゾーンが関係するのは、カレンダー上で人が予約をどう見るかと、エージェント自身の判断です。正しいオフセット付きの現地時刻で送れば、確認する人にとってもエージェントのログが読みやすくなります。
1つの投稿の中で、アカウントごとに別の時刻を予約できますか？
1つの投稿が持つ schedule_at は1つで、各アカウントにはその後、時間差を付けて順に送信されます。本当に別々の時刻にしたいなら、投稿を分けてください。通常はグループごとに1つです。投稿ごとに専用の label を付けられるので、レポートもすっきりします。
時間差の妥当なデフォルトは？
ほとんどの配信には、デフォルトの [30, 90] で十分です。動画の場合や、1つの SNS で50アカウント程度を超える配信では、私は [60, 150] くらいまで広げて、開始を早めています。犠牲になるのは時間であって、リーチではありません。
次のステップ
これらのルールは、タスクごとに繰り返すのではなく、エージェントの常設の指示に入れておきましょう。コンテンツエージェント向けのプロンプトの記事に、そのまま貼り付けられる予約用のブロックがあります。
