「9時に投稿」は、指示の半分でしかありません。残りの半分は、誰の9時か、です。時刻がずれた投稿の多くは、キャプションの誤字が原因ではありません。時刻は正しいのにゾーンが違っていて、投稿が出たあとで気づくのです。
このガイドはボタンの説明ではなく、判断の話です。スケジュール画面を手早く知りたい場合は、機能ページのスケジュールをご覧ください。ここでは現実的な一例を最後まで追い、そのまわりの落とし穴を見ていきます。
実例：カラチからニューヨークへ
サナさんはカラチから、ニューヨークのパン屋さんのSNSを運用しています。お客さんは朝食の時間にInstagramを見るので、今後2週間、すべての投稿をニューヨーク時間の午前8:00に出したいと考えています。この期間には2026年11月1日（日）が含まれます。アメリカが時計を1時間戻す日です。パキスタンは時計をまったく変えません。
サナさん自身の時刻にすると、こうなります。
- 10月31日（土）まで、ニューヨークは夏時間なので、向こうの8:00はカラチの17:00です。
- 11月1日（日）から、ニューヨークは標準時なので、向こうの8:00はカラチの18:00です。
意図は同じでも、カラチでの時刻は2つあります。サナさんが自分で計算して全部に17:00と入力すると、切り替え後の投稿はすべてニューヨークの7:00に届きます。毎日1時間早く、しかもエラーは一切出ません。
だから計算はしません。作成画面で、まずTimezoneのドロップダウンをニューヨークにして、そのあと時刻に08:00と入力します。これでニューヨーク時間の8:00の投稿になり、11月1日の切り替えは自動で処理されます。保存する前に、2週間が切り替えをまたぐので、日付と時刻をもう一度読み返します。
カレンダーには、最初の投稿は17:00、後半の投稿は18:00と表示されたままです。カレンダーは、お使いの端末の時計で時刻を表示するためです。これは正常です。投稿を開くと、設定したゾーンを確認できます。
投稿にはどのゾーンを使うべきか
候補は3つあり、それぞれ答える問いが違います。
- 読者のゾーン。 読者の1日のある瞬間に届けたいとき（朝食、昼休み、帰宅の電車）に使います。たいていはこれが正解で、読者側の夏時間の切り替えをまたいでも投稿の時刻が安定します。
- 自分のゾーン。 時刻が読者ではなく自分に関係するとき（自分が行うライブ配信、相談時間のお知らせ、「休暇から戻りました」の投稿）に使います。
- UTC。 全員に同じ時刻で告知するローンチのように、世界で1つの瞬間に結びついたものに使います。ずれることはありませんが、誰の現地時間にも合わせてくれません。
投稿に2つの読者層がある場合は、投稿も2つ必要です。1つのゾーンで、ニューヨークとシンガポールの両方の朝食にはなれません。それぞれにコピーを1つずつスケジュールし、各自のゾーンに設定してください。日付と時刻のフィールドの下にあるSuggested timesの行は、選んだチャンネルのピーク時間を、設定したゾーンの時刻で表示します。先にゾーンを設定してから、提案を見てください。
投稿を何時間もずらしてしまう間違い
初期値のままにする。 新しい投稿は、ブラウザが報告するゾーン、つまり端末が今いると思っている場所で始まります。出張、VPN、借りたノートパソコンなどで、実際に働いている場所と違うゾーンになることがあります。キューに入れる前に、ドロップダウンを確認してください。
ドロップダウンが換算してくれると思う。 ゾーンを変えると、時計の表示は保たれたまま、新しいゾーンの時刻として読み直されます。ロンドンの9:00の投稿は、ロンドンの9時の太平洋時間版ではなく、ロサンゼルスの9:00になります。「向こうの9時」という普通の意図には合いますが、換算を期待していた人は驚きます。換算したい場合は、時刻を自分で計算して入力してください。
時刻は自分のゾーンで入力して、ゾーンは相手のものを選ぶ。 カラチの例の逆です。ニューヨークの8:00だからと17:00と入力し、そのあとゾーンをニューヨークにすると、ニューヨークの17:00でスケジュールされます。基準は1つに決めてください。選んだゾーンの時計で時刻を入力するか、自分のゾーンを選んで自分で換算するかです。混ぜると、8時の投稿が17時の投稿になります。
両側が同じ日に切り替わると思い込む。 アメリカとヨーロッパは別の週末に時計を変えるので、約1週間、ロンドンとニューヨークの時差がいつもより1時間小さくなります。頭の中で時間を引き算してスケジュールしていると、間違えるのはまさにその日です。読者のゾーンを設定すれば、計算そのものが要りません。
存在しない時刻にスケジュールする。 時計が進む夜には、02:30は存在しません。その時刻に設定した投稿は、時計自体が進むのと同じように03:30に出ます。1時間早くはなりません。切り替えの夜に正確な分が重要なら、その空白から十分離れた時刻を選んでください。
キューに入れる前の簡単なチェック
- Timezoneのドロップダウンは、ノートパソコンの場所ではなく、読者のいる場所になっていますか。
- 時刻は、そのゾーンの時計で入力しましたか。
- 期間が、相手の国の時計の切り替えをまたいでいませんか。またぐ場合は、前後の投稿を1件ずつ開いて時刻を確認してください。
- 世界中の読者向けに、妥協の時刻を1つ選ぶのではなく、地域ごとに1件ずつ投稿を用意していますか。
繰り返しスケジュールと1日の上限
繰り返しスケジュールには、Repeat Scheduleパネルに専用のTimeとTimezoneのフィールドがあります。シカゴの9:00に出す毎週の投稿は、UTCとの差が変わっても、1年中シカゴ時間の9:00のままです。スケジュールに専用のゾーンがない場合は、作成元の投稿のゾーンが使われます。繰り返しが何に向いているかは、ソーシャルメディアの繰り返し投稿をご覧ください。
スケジュール済み投稿の1日の上限も、投稿のゾーンに従います。「1日」とは、そのゾーンでの暦の1日です。UTCで数分しか離れていない2つの投稿が、シドニーの読者にとっては別の日になることがあります。上限は Free：3件、Pro：30件、Business：100件のスケジュール済み投稿です。上限を超えて1件追加しようとした時点で分かります。
時刻を選ぶ代わりにAdd to queueを使う場合、スロットの時間帯は投稿のゾーンで9:00から20:00です。先に読者のゾーンを設定すれば、スロットは読者が起きている時間に収まります。
APIでは
scheduledAtは正確な1つの瞬間を指すので、オフセット付き、またはUTCで送ります。たとえば2026-11-02T13:00:00Zです。timezoneはAmerica/New_YorkのようなIANAのゾーン名で、省略可能で、初期値はUTCです。無効な名前は拒否されます。瞬間はscheduledAtで決まります。ゾーンは投稿が属するものを記録し、1日の上限や投稿の詳細ビューで使われます。「ニューヨークの8時」にしたい場合は、瞬間を自分で計算し、両方を送ってください。リクエストの全体像は、スケジュールAPIガイドをご覧ください。
気にしなくてよい場合
自分も読者も同じ場所にいるなら、初期値のままにして、ここまでの話は忘れてください。読者がどこにいるか分からない場合は、ゾーンを設定しても役に立ちません。まず分析を確認してください。その方法は、ソーシャルメディアに投稿するのに最適な時間のガイドで説明しています。
無料プランで試せます。app.bulkpublish.comで無料で始める。