はじめに
個人で「AIニュースを日本語に翻訳してX（旧Twitter）に自動投稿するbot」を運用しています。RSSで18個以上のAI系フィード（OpenAI / Anthropic / Google AI など）を集め、翻訳して、Vercel Cronで定期投稿する、という構成です。
このbotには長らく 「毎時実行（0 * * * *）」 という雑なcron設定が刺さっていました。1日24回、深夜3時だろうとお構いなしに投稿する。コードは動いていたし、エラーも出ない。でも数字は伸びない。
この記事は、その毎時実行をやめて JSTのピーク時間帯（7:00 / 12:00 / 18:00 / 20:00）だけに投稿を寄せる という変更（実際のPR: Issue #20）を題材に、
- cronのUTC/JST変換でハマるポイント
- 「投稿数を時間帯で動的に変える」実装の具体コード
- そして 投稿最適化を"回数の最大化"だと思っていた自分が、何を取り違えていたか
を、動くコードと正直な反省込みで書きます。
対象読者: Vercel/サーバーレスで定期実行（cron）を一度は触ったことがあり、「とりあえず動かした定期投稿」を一段良くしたい個人開発者・中級者。cronの記法（* * * * *）がうっすら読める人を想定しています。
何を解決したかったのか（背景）
最初の実装はこうでした。
// vercel.json（変更前）
{
"crons": [
{ "path": "/api/cron/auto-post", "schedule": "0 * * * *" }
]
}
0 * * * * は「毎時0分」。つまり1日24回起動します。一見たくさん露出できて良さそうに見えます。
毎時実行のままでよくない？露出は多いほうが得でしょ？
最初の自分もそう思っていました。しかし運用してみると問題が2つ見えてきます。
- 深夜帯の投稿が"無駄玉"になる。 日本のユーザーが寝ている UTC基準の真夜中（JSTの昼間とズレる）に投稿しても、誰のタイムラインにも残らず流れていく。
- 投稿頻度が高すぎるとスパム判定リスクがある。 フォロワーのTLを自分の投稿で埋め尽くすと、逆にフォロー解除を招きます。
つまり問題は「露出が足りない」ではなく 「沈黙すべき時間にも喋り続けている」 ことでした。ここが今回のキモです。
変更内容：毎時 → JSTピーク帯の4回
Vercel Cronのスケジュールは UTC基準 で書きます。ここが最初の罠です。日本時間（JST）は UTC+9 なので、JSTの投稿したい時刻から9時間引いた値をcronに書く必要があります。
| 時間帯 | JST | UTC（cronに書く値） | 理由 |
|---|---|---|---|
| 🌅 朝 | 07:00 | 22:00（前日） | 通勤・起床直後のスマホチェック |
| 🌞 昼 | 12:00 | 03:00 | 昼休みのリラックスタイム |
| 🌆 夕 | 18:00 | 09:00 | 退勤・帰宅前 |
| 🌙 夜 | 20:00 | 11:00 | SNS利用の最ピーク |
実際の差分（vercel.json）はこうなりました。
{
"path": "/api/cron/auto-post",
- "schedule": "0 * * * *"
+ "schedule": "0 22 * * *"
+ },
+ {
+ "path": "/api/cron/auto-post",
+ "schedule": "0 3 * * *"
+ },
+ {
+ "path": "/api/cron/auto-post",
+ "schedule": "0 9 * * *"
+ },
+ {
+ "path": "/api/cron/auto-post",
+ "schedule": "0 11 * * *"
}
1日24回 → 1日4回。回数を「6分の1」に減らす変更です。
投稿回数を6分の1に減らして、本当に成長するの？むしろ露出減るのでは？
ここが直感に反するところです。後述しますが、露出の総量より「誰が見ている時間に出すか」のほうが効く、というのが今回の賭けでした。
ハマりどころ：cronのUTC変換を"アプリ側でも"間違えない
cronをUTCで書くのは慣れれば良いのですが、アプリのコード内で時間帯判定をするときも同じ罠があります。Vercel Functionsのサーバー時刻はUTCで動くため、new Date().getHours() をそのまま使うとJSTのつもりがUTCで判定されて9時間ズレます。
そこで、JSTの「時」を明示的に計算するヘルパーを噛ませています。
/** JST（日本標準時）での現在の「時」を取得 */
function getJSTHour(): number {
const now = new Date();
const jstOffset = 9 * 60; // UTC+9 を「分」で表現
const jstTime = new Date(now.getTime() + jstOffset * 60 * 1000);
return jstTime.getUTCHours(); // ← getHours() ではなく getUTCHours()
}
ポイントは最後の getUTCHours() です。getTime() に9時間ぶんのミリ秒を足した「ズラした時刻」に対して、さらにローカルタイムゾーン補正のかかる getHours() を使うと二重補正になります。ズラした後は必ず getUTCHours() で読む、と覚えておくと事故りません。
一歩進める：時間帯で"投稿数"も動的に変える
cronで「いつ動くか」を絞ったら、次は「1回あたり何件投稿するか」も時間帯で変えたくなります。ピーク帯は厚く、準ピークは中くらい、万一オフピークに動いても薄く。
実装はシンプルな分岐です。
/**
* 時間帯に基づいて最大投稿数を動的に決定する。
* ピークタイムは多めに、オフピークは抑える。
*/
function getMaxPostsForCurrentTime(): number {
// 環境変数で明示指定があればそれを尊重（運用での上書き口を残す）
if (process.env.AUTO_POST_MAX_PER_RUN) {
return DEFAULT_MAX_POSTS_PER_RUN;
}
const jstHour = getJSTHour();
// ピーク（朝の通勤 / 昼休み / 夕〜夜）→ 多め：5件
if (
(jstHour >= 7 && jstHour < 9) ||
(jstHour >= 12 && jstHour < 13) ||
(jstHour >= 18 && jstHour < 21)
) {
return 5;
}
// 準ピーク（午前中 / 夜遅め）→ 中程度：3件
if (
(jstHour >= 9 && jstHour < 12) ||
(jstHour >= 21 && jstHour < 23)
) {
return 3;
}
// オフピーク → 少なめ：2件
return 2;
}
ざっくり言うと「人がいる時間は5件、いない時間は2件」という強弱です。環境変数 AUTO_POST_MAX_PER_RUN が立っていればその値を優先する、という逃げ道を最初の行に残しているのも地味に大事で、検証時に「今だけ全時間帯10件で流したい」みたいな上書きができます。
さらに、流す記事は適当に選ぶのではなくソース優先度でソートしてから上位N件だけ出します。
export const SOURCE_PRIORITY: Record<string, number> = {
"OpenAI Blog": 10,
"Anthropic News": 10,
"Google AI Blog": 9,
// …media は 6、arXiv 等のアカデミックは 3
};
「人がいる時間に、価値の高いソースから出す」——時間と中身の両方でピークに資源を寄せる、という設計です。
で、結局どうなった？（効果と、その正直な扱い）
PRの狙いは エンゲージメント率の20〜40%向上 でした。ただし——ここは正直に書きます——
この20〜40%は「狙い・仮説」であって、まだA/Bで厳密に取り切った確定値ではありません。
理由は2つあります。第一に、変更前後で「投稿時間」も「投稿数」も同時に動かしているので、効果の切り分け（時間帯のおかげなのか、件数を絞ったおかげなのか）ができていません。第二に、Xの個人アカウント規模ではインプレッションの分散が大きく、数日では有意差と言い切れません。
なので現時点で胸を張って言えるのは、「定量効果は検証中。ただしオフピークの無駄投稿がゼロになったのは確実」 という点までです。誇張せず、ここで止めておきます。
検証環境（2026年6月時点）:
- ランタイム: Node.js v20.12.2 / Vercel Functions
- ライブラリ:
twitter-api-v2@^1.29.0 - プラン: Vercel Pro（後述の理由で必須）
正直なデメリットと、踏んだ地雷
メリットだけ書くと嘘くさいので、リアルな話を3つ。
1. Vercel Pro（有料）がほぼ必須になった。
1回の起動で「最大5件 × 10秒間隔」だと処理に最大100秒ほどかかります。Functionのデフォルトタイムアウト10秒では全く足りず、maxDuration: 300 が要る。これは無料Hobbyプランの上限（10秒）を超えるため、Proプラン前提になります。「個人開発で月額が乗る」のは正直に言うべきデメリットです。
2. ドキュメントとコードがズレていた（自戒）。
リポジトリ内の古い設計メモには「1日3回（08:00/12:30/20:00）」と書いてあるのに、実際のcronは「4回（7/12/18/20）」。スケジュールという"プロダクトの意思"がコードとドキュメントで二重管理になっていて、片方が腐っていました。cronの値はコードであると同時に運用ドキュメントでもある、と痛感した部分です。
3. cronの起動時刻と"投稿数テーブル"が完全には噛み合っていない。
getMaxPostsForCurrentTime() は「18〜21時はピークで5件」と判定しますが、cronが夕方に起動するのは18:00ちょうどの1回だけ。テーブル側はもっと細かい時間帯を想定して作ってあるので、現状は実装の余力が先行している状態です。将来cronを増やしたときに効いてくる設計、と前向きに捉えていますが、「今この瞬間フルには使われていない」のは事実です。
まとめ：最適化とは「沈黙する時間を設計すること」だった
この変更を通して、自分のなかの定義が一つ書き換わりました。
投稿の最適化とは「回数を最大化すること」ではなく、「いつ黙るかを決めること」である。
毎時実行をやめるのは、機能を足す変更ではなく 機能を引く変更 です。コードはむしろ複雑になった（時間帯判定が増えた）のに、botの振る舞いは「静かになった」。この非対称さが、今回いちばん面白かった点でした。
学びを3行で:
-
cronはUTCで書く。 JSTは「やりたい時刻 − 9時間」。アプリ内判定では
getUTCHours()で二重補正を避ける。 - 時間も中身もピークに寄せる。 起動時刻を絞り、件数を動的にし、優先度の高いソースから出す。
- 減らす最適化を恐れない。 露出の総量より「誰が見ている時間に出すか」。沈黙の設計はコストではなく戦略。