Vercel Schedules がパブリックベータに。Cron Jobs との違いと移行時の判断基準
2026年11月5日、Vercel は定期実行機能「Vercel Schedules」をパブリックベータとして全プランで公開しました。Cron Jobs の後継にあたる機能で、タイムゾーン指定、公開 URL を持たない関数ターゲット、一度きりの実行、実行履歴、再デプロイなしの停止・即時実行に対応します。既存の Cron Jobs はそのまま動き続けますが、新規に定期処理を実装するなら Schedules を前提に設計するのが妥当です。この記事では、Cron Jobs との具体的な差分、静的／動的スケジュールの使い分け、移行時に見落としやすい挙動の変化を整理します。
Cron Jobs から何が変わったのか
最大の違いは、スケジュールが「デプロイに固定された設定」から「実行時に操作できるリソース」になった点です。公式ドキュメントが挙げる主な差分は次のとおりです。
- ターゲット: Cron Jobs は公開パスへの HTTP GET のみ。Schedules はパスへの GET/POST に加え、非公開の Vercel Function や Vercel Queues のトピックを指定できます
- タイムゾーン: Cron Jobs は UTC 固定。Schedules はスケジュールごとに任意の IANA タイムゾーンを指定できます
- 環境: Cron Jobs は本番のみ。Schedules は本番・Preview ブランチ・カスタム環境で動きます
- 運用操作: Cron Jobs はプロジェクト単位の一括停止のみ。Schedules は個別に有効化・無効化・即時実行でき、再デプロイが不要です
- 可観測性: Cron Jobs は関数ログのみ。Schedules はスケジュール単位の実行履歴がダッシュボードと CLI から参照できます（保持は90日）
実務的に効くのは、Preview 環境で定期処理を検証できる点と、障害時に該当スケジュールだけを止められる点です。これまでは「cron の挙動は本番に出すまで確認できない」「一本止めるために設定を書き換えて再デプロイする」という運用が常態化していました。そこが構造的に解消されます。
静的スケジュールと動的スケジュールの使い分け
Schedules には定義方法が2種類あります。静的スケジュールは vercel.json などのプロジェクト設定に書き、デプロイ時に適用されます。動的スケジュールは @vercel/schedules SDK か vercel schedules CLI で実行時に作成し、即座に反映されます。
ドキュメントの指針は明快です。アプリ自身に属するジョブ（毎晩のクリーンアップなど）は静的、ユーザーごとに作られるジョブ（顧客別のリマインダーなど）は動的です。ここで重要な制約が2つあります。動的スケジュールのターゲットは Queue トピックのみで、関数やパスを直接指定できません。一方、一度きりの実行（one-time）とペイロードの付与は動的スケジュールでしか使えません。
つまり「指定日時に1回だけ実行したい」要件がある時点で、動的スケジュール＋Queues の構成が前提になります。Queues の消費者（コンシューマー）側の実装とリトライ設計が必要になるため、見積もり時はここを工数として織り込んでおくべきです。
関数ターゲットを選ぶと認証の設計が不要になる
Cron Jobs ではエンドポイントが公開 URL になるため、CRON_SECRET を自前で検証して外部からの実行を防ぐ必要がありました。Schedules の関数ターゲットは公開 URL を持たず、Vercel のスケジュール基盤だけが呼び出せます。設定は vercel.json の functions に experimentalTriggers として schedule/v1beta を追加し、ハンドラを @vercel/schedules の handleSchedule でラップする形です。
静的な共有シークレットに依存した認可は、漏洩時の影響範囲が読みにくく、ローテーションも忘れられがちです。新規実装なら関数ターゲットを既定とし、パスターゲットは「コードを変えずに Cron Jobs を移行する」用途に限定するのが合理的な判断です。
移行手順と、見落としやすい3つの挙動変化
公式の移行ガイドでは、vercel.json の crons 配列を schedules オブジェクトに置き換え、本番にデプロイし、ダッシュボードまたは vercel schedules invoke で動作確認する、という流れが示されています。ルート側のコードは変更不要です。user-agent: vercel-cron/1.0 や x-vercel-cron-schedule ヘッダー、CRON_SECRET の Authorization ヘッダーも維持されます。
一方で、次の3点は必ず確認してください。
- HTTP メソッドが変わる: パスターゲットの既定は POST です。Cron Jobs は GET だったため、ハンドラを変えないなら
"requestMethod": "GET"を明示する必要があります - 二重実行のリスク:
cronsとschedulesの両方を残すと、同じ処理が1回の発火ごとに2回走ります。置き換えは同一の変更でまとめて行います - 実行時刻が厳密ではなくなる: Schedules は「ジッターウィンドウ」内で開始します。Pro/Enterprise は既定1分（1〜15分で設定可）、Hobby は常に15分です。分単位の正確さに依存した処理がある場合は影響を検討してください
タイムゾーンについても注意が必要です。Cron Jobs は UTC 固定、Schedules も既定は UTC です。移行時に timezone を足すと実行時刻がずれるため、同じ時刻で動かしたいなら指定しないのが安全です。
料金とプラン別の上限
Pro と Enterprise では、100万回の実行あたり5ドル、100万回の作成あたり10ドルから課金されます。Hobby は月あたり作成500回・実行5,000回が含まれ、超過すると次の請求期間までスケジュールの作成・有効化・手動実行がブロックされ、定期実行もスキップされます。
チームあたりのスケジュール数の上限は Hobby が1,000、Pro が10,000、Enterprise が100,000 です。ペイロードは全プラン16KB、実行履歴の保持は90日。Hobby ではジッターが15分固定のため、cron の最短間隔も15分になります。加えて、Pro から Hobby へのダウングレードやプロジェクト移管時には、15分より短い間隔のスケジュールや jitter が15未満のスケジュールが削除され、アップグレードしても自動では復活しません。
なお、スケジュール自体の課金とは別に、実行先のリソース消費が発生します。関数・パスターゲットは Vercel Functions の呼び出しとして、Queue ターゲットは Queues のメッセージ publish とコンシューマー実行として計上されます。ユーザーごとに動的スケジュールを発行する設計では、テナント数に比例してこの両方が増える点を見積もっておく必要があります。
いま移行すべきか、待つべきか
Schedules はベータであり、公式ドキュメントは挙動・API・上限が一般提供前に変更される可能性を明記しています。判断は用途で分けるのが現実的です。
新規にユーザー起点の予約実行（リマインダー、公開予約、トライアル期限）を作るなら、Schedules を使う価値は大きく、代替手段を自前で組むより早いはずです。既存の Cron Jobs が UTC・本番のみで問題なく回っているなら、急いで移行する必要はありません。ただし Cron Jobs はレガシー扱いで、将来 Schedules へ移行される旨が明示されています。移行自体は設定変更で済むため、Preview 環境での検証や個別停止が必要になった時点が切り替えの好機です。
どちらの場合も、ハンドラは複数回実行されても壊れない設計にしておくことが前提になります。ジッターや手動実行、リトライがある以上、冪等性（同じ処理を何度実行しても結果が変わらない性質）の確保は必須と考えてください。
次の一歩
まずは本番に影響しない定期処理をひとつ選び、Preview 環境で関数ターゲットの静的スケジュールとして動かしてみるのが、最も安全な検証手順です。そのうえで、実行時刻の厳密さ・一度きりの実行の要否・ユーザー単位のスケジュール数という3点から、既存の Cron Jobs を移すべきかを判断してください。
Next.js や Vercel 上のアプリケーションで、定期実行や非同期処理の設計・移行に迷われている場合は、お問い合わせからご相談ください。chot Inc. では Web サイト制作・フロントエンド開発・AI アプリケーション開発を通じて、こうした実装・運用のご支援をしています。
出典
この記事に関連するchot Inc.の支援
chot Inc.は日本初のVercel公式パートナーとして、Next.jsを中心としたWebサイト・Webアプリケーションの開発を支援しています。Vercelの導入・契約・運用の見直しはVercel公式パートナー開発支援で、Next.jsによる新規開発や既存システムからの技術移行はモダンWeb開発で紹介しています。
