GitHub Actions・Kubernetes・systemd timerの使い分け

1. GitHub Actions schedule: 無料枠は広いが遅延あり

GitHub Actions の schedule トリガーは無料プラン・Pro プランで広い無料枠が提供され、リポジトリにYAMLを書くだけで動かせます。UTC固定で TZ 設定はできず、cron式は POSIX 5フィールド準拠。注意点は実行タイミングの保証が「ベストエフォート」であること。公式ドキュメントでも「最大数分の遅延が発生する場合がある」と明記されており、特に毎時00分など集中する時刻は遅延が大きくなる傾向があります。秒精度・分精度が必要な処理には向かず、定期的なリポート・週次のデータ同期・月次のクリーンアップなど、数分の遅延を許容できるバッチに最適。実行環境は公式ランナー（Ubuntu/Windows/macOS）で、必要なツールチェーンを毎回セットアップするため起動時間がやや長い点も考慮。

2. Cloudflare Workers cron triggers: 低レイテンシで軽量

Cloudflare Workers の cron triggers は Workers ランタイム上で動くJavaScript/TypeScript（および WebAssembly）が定期実行されます。実行時間はFreeプランで30秒、Paidで30秒〜30分の制約があり、軽量で短時間のタスク向け。利点は低レイテンシ起動（Cold start がほぼゼロ）、グローバルエッジ分散、HTTP リクエストや D1/KV/R2 などCloudflare自社サービスとの統合が容易な点。POSIX 5フィールド準拠で UTC 固定、TZ 設定不可。wrangler.jsonc の triggers.crons 配列に複数式を書けます。重い処理（数分〜数十分のバッチ、機械学習推論）には不向きで、外部APIへのpingや軽い集計、cache warming、定期通知などのユースケースに最適。Workers Free プランでも cron triggers は使えるため、個人開発のスケジューラとしてコスト面で優秀です。

3. Vercel Cron: Next.js統合の手軽さ

Vercel Cron は Vercel にデプロイした Next.js / Nuxt / SvelteKit 等のアプリ内に /api/cron/... のような API Route を作り、vercel.json の crons 配列にスケジュールを書く方式。同一デプロイ内なので環境変数・データベース接続・ライブラリが全てそのまま使えて開発体験が良い。POSIX 5フィールド準拠で UTC 固定。注意点は Hobby プランで cron 数とスケジュール頻度に制限があり、Pro プランでも実行時間は Serverless Function の上限（デフォルト10秒〜最大300秒）に縛られる点。重いバッチ処理は Vercel の外（GitHub Actions やキューワーカー）で動かす方が安全です。利点は Vercel ダッシュボードからログ・実行履歴が見られ、デプロイのバージョン管理と一体化していること。Next.js を Vercel にホスティングしているプロジェクトでは第一選択肢になります。

4. Kubernetes CronJob: フルコントロール・フル責任

Kubernetes CronJob は CronJob リソースの spec.schedule に cron 式を書き、指定タイミングで Job リソース（=Pod）を起動します。POSIX 5フィールド準拠（@daily 等の省略形も対応）、v1.27 以降は spec.timeZone で IANA タイムゾーン指定可能（Asia/Tokyo など）。利点は実行環境を完全に自前で定義できる点（任意のコンテナイメージ、任意のリソース割当、PV マウント、Service との連携など）。欠点は K8s クラスタの運用負荷を全て引き受ける必要があること。Pod のスケジュール失敗・OOMKill・ノードダウン時の挙動を understand しておかないと、cron 式は正しいのに Job が動かない、という事故が起きます。重い ETL バッチ、機械学習バッチ、データベース夜間メンテナンスなど、コンテナ単位で完結する大規模ジョブに最適。クラウドマネージド K8s（EKS/GKE/AKS）と組み合わせれば運用負荷を一部委譲できます。

5. systemd timer: サーバー1台運用の伝統的選択肢

systemd timer は伝統的な crontab に代わる Linux サーバー上の定期実行機構で、Ubuntu / Debian / RHEL / CentOS Stream / Rocky Linux など主要ディストリで標準サポート。.timer と .service の2ファイルを書き、OnCalendar= に時刻指定するスタイル。POSIX cron式ではなく独自構文（例: OnCalendar=Mon..Fri 09:00）だが、cron 式と概念的に同じスケジューリングが可能で、より読みやすい記法です。利点は systemd エコシステムとの統合（ログが journalctl で一元管理、依存関係を Requires= で表現、サーバー起動時の自動有効化）。欠点はサーバー1台に閉じた仕組みで、複数サーバーへの分散・冗長化はできないこと。VPS でアプリを動かす個人開発、社内 1〜数台の小規模運用、cron 式とlogが分離しがちな伝統的 crontab からの移行先として最適。

6. 選び方の判断軸: 重さ・保証・運用コスト

スケジューラ選択の判断軸は3つ。①ジョブの重さ: 軽量短時間（〜数十秒）→ Cloudflare Workers / Vercel Cron。中重量（数分〜10分）→ GitHub Actions / AWS Lambda Scheduled。重量（数十分〜数時間）→ Kubernetes CronJob / Cloud Run Jobs / VM上のsystemd timer。②実行保証: At Most Once（重複NG）→ Cloud Scheduler + 冪等な実装。At Least Once（漏れNG）→ K8s CronJob の concurrencyPolicy 設定 + リトライ。③運用コスト: フルマネージド（運用負荷ゼロ）→ Vercel Cron / GitHub Actions / Cloud Scheduler。一部マネージド → EKS/GKE上の K8s CronJob。フル自前 → 自社サーバー上の systemd timer。これら3軸で「軽量・At Most Once・運用コスト最小」なら Vercel Cron、「重量・At Least Once・運用コスト許容」なら GKE上の K8s CronJob、というように選定できます。本ツールで cron 式の意味と次回発火日時を確認してから、選んだスケジューラに登録するのが安全です。

関連ツール

• ・UNIX時間変換 ログのUNIX秒を実行時刻に変換
• ・時間計算ツール JST/UTC換算の手助けに
• ・JSON整形 wrangler.jsonc / vercel.json の整形に