定期処理だけなら常時稼働のVPSは必要か
定期処理に要るのは「決めた時刻に起動する仕組み」と「失敗や未実行に気づいて再実行できる仕組み」で、常時稼働のサーバーそのものではない。どこで動かすかは、下の要件票を埋めてから選ぶ。
契約前に埋める要件票
| 項目 | 書き出す内容 |
|---|---|
| 実行間隔と許容できるずれ | 何分・何時間ごとか。予定時刻からどれだけ遅れても困らないか |
| 1回の処理時間 | 最長で何分かかるか。途中で打ち切られた時に続きから再開できるか |
| 前回との重複 | 前回が終わる前に次の時刻が来たら、待つ・飛ばす・並行して動かすのどれにするか |
| 失敗と未実行の検知 | エラーで止まった回と、そもそも起動しなかった回を、誰がどう知るか |
| 再実行 | 同じ回を2度実行しても結果が壊れないか。手で再実行する手順はあるか |
| 秘密情報 | APIキーをどこに保管し、実行時にどう渡し、ログに出さないようにするか |
| 停止中の扱い | 実行環境が止まっていた間の予定分を、後で1回だけ実行するか、全部やり直すか、捨てるか |
| 規約・費用 | 使うサービスの利用規約で、その処理に使ってよいか。実行時間や回数の課金・上限はどうか |
スケジューラが起動したことと、処理が正しく終わったことは別に確認する。
選択肢1：手元のPCやOSのタスクスケジューラ
実行し忘れた回を後から手で実行すれば済み、PCを使う時間帯に収まる処理なら、手元で動かす形から試せる。PCの電源が切れている・スリープしている間は起動しない前提で、要件票の「停止中の扱い」を「手で実行する」と書けるかを確認する。書けないなら、次の選択肢に進む。
選択肢2：マネージドなスケジュール実行
PaaSやFunctionsには、決めた時刻に処理を起動する機能を持つものがある。OS保守を持たずに済むが、実行時間、同時実行、再実行の扱いはサービスごとに違う。
たとえばRenderのcron jobは、同じジョブの実行は同時に1つまでで、前回が終わっていなければ次回を遅らせ、長時間の実行は打ち切ると説明している（Render Docs: Cron Jobs、確認日: 2026年9月14日）。Cloudflare Workersの定期実行（Cron Triggers）にも、1回あたりの実行時間の上限がある（Cloudflare Docs: Workers Limits、確認日: 2026年9月14日）。要件票の「1回の処理時間」と「前回との重複」を、候補サービスの公式資料に1行ずつ当てはめる。
GitHub Actionsのscheduleを使う場合の注意
リポジトリのワークフローをscheduleで起動する方法は、汎用の定期実行基盤として選ぶ前に次を確認する。
- GitHub公式は、
scheduleは負荷の高い時間帯（毎時0分を含む）に遅れることがあり、負荷が十分高いとキュー内のジョブが実行されないことがあると説明している。パブリックリポジトリでは一定期間操作がないと定期実行が無効化される（GitHub Docs: Events that trigger workflows）。遅れを許容するだけでは足りず、実行されなかった回を検知して再実行する仕組みが別に要る。 - 1ジョブの実行時間の上限は、GitHubホストのランナーとセルフホストランナーで異なる（GitHub Docs: Actions limits）。
- GitHubの追加製品向け規約は、GitHubホストのランナーを、そのリポジトリのソフトウェアの開発・テスト・デプロイ・公開に関係しない用途に使うことを禁じている。サーバーへ不相応な負荷をかける使い方の例として、サーバーレスアプリの一部としての利用も挙げている（GitHub Terms for Additional Products and Features）。リポジトリのソフトウェアと関係のない業務処理を載せる前に、規約に照らして判断する。
- Secretsはワークフローのログで自動的に伏せ字にされるが、GitHub公式は値の変形や構造化データでは伏せ字が働かない場合があり、自動の伏せ字は保証されないとしている（GitHub Docs: Secure use reference）。秘密の値は、伏せ字に頼らず、意図的にログへ出さない。
確認日: 2026年9月14日。
選択肢3：常時稼働しているサーバー上のtimer
Webhookの受信など別の理由ですでに常時稼働のサーバーがあるなら、そのサーバーのcronやsystemd.timerに定期処理を載せる選択肢がある。定期処理のためだけにサーバーを持つと、OS更新や監視の担当も一緒に引き受けることになる。
systemd.timerのPersistent=trueは、停止中の予定分を補う設定として紹介されることが多いが、意味は限定的だ。OnCalendar=で時刻を指定したtimerにだけ効き、停止していた間に1回以上起動するはずだった場合、timerが有効になった時点でサービスを起動する。予定分を回数どおりに実行するものではなく、RandomizedDelaySec=を設定していればその遅延も加わる（systemd.timer man page（systemd公式リポジトリ）、確認日: 2026年9月14日）。停止していた期間のデータをどこまで処理するかは、処理側で前回の完了位置を記録して決める。
要件票から選ぶ
- 停止中の分を手で実行すれば済む → 手元のPCから試す
- OS保守を持ちたくない。実行時間と重複の扱いが候補サービスの仕様に収まり、規約上もその用途に使える → マネージドなスケジュール実行
- 別の理由で常時稼働のサーバーがあり、保守の担当が決まっている → サーバー上のtimer
どれを選んでも、失敗と未実行の検知、再実行しても壊れない処理、秘密情報をログに出さない扱いは利用者側で用意する。用途全体で方式を確かめるなら自己管理VPSを契約するか決める前の確認ツール、外部からの通知も受けるならWebhookを受信する前に確認することへ進む。