こんにちは！日々の面倒な定型作業や、深夜のバッチ実行に頭を悩ませていませんか？
「毎週月曜日の朝に、依存関係のアップデートPRを自動で作ってほしい」
「毎日深夜に、データベースのバックアップや死活監視のスクリプトを走らせたい」
そんなときに最高に頼りになるのが、GitHub Actionsの `schedule` イベント（cron構文による定期実行）です。これをマスターすれば、あなたの代わりにGitHubが24時間365日、正確にタスクをこなしてくれるようになります。毎日の手動作業が劇的に楽になりますよ。
今回は、GitHub Actionsのcron実行について、基本の「キ」から、現場のエンジニアなら絶対に知っておくべき「UTCの罠」や「遅延のメカニズム」まで、優しく徹底的に解説していきますね！
—
1. GitHub Actionsの定期実行（schedule）とは？
GitHub Actionsといえば、「コードをプッシュしたとき（`push`）」や「プルリクエストを作ったとき（`pull_request`）」に動くイメージが強いかもしれません。
しかし、`schedule` イベントを使えば、「特定のトリガー（人間の操作）がなくても、時間主導でワークフローを自動起動」させることができます。
主なユースケース
- 定期的な依存関係のチェック: Dependabot以外に、自前で特定ライブラリの脆弱性スキャンや更新チェックを走らせたい。
- バッチ処理の実行: 毎日深夜に不要なテストデータをクリーンアップしたり、集計レポートを生成してSlackに飛ばしたりする。
- APIの死活監視: 外部の自社サービスやAPIが生きているか、定期的（例: 5分おき）に叩いて確認する。
—
2. 最初のステップ：Hello Worldワークフローを作ろう
百聞は一見にしかず。まずは実際に動く最小限のコードを見てみましょう。
リポジトリの `.github/workflows/` ディレクトリの中に、以下のような YAML ファイル（例: `cron-test.yml`）を配置するだけです。
name: 毎日の挨拶ボット
1. ここでスケジュールを設定します
on:
schedule:
# 毎日、協定世界時（UTC）の 0時0分（＝日本時間の午前9時）に実行
- cron: ‘0 0 ‘
jobs:
say-hello:
runs-on: ubuntu-latest
steps:
- name: リポジトリをチェックアウト
uses: actions/checkout@v4
- name: 挨拶をログに出力する
run: |
echo “おはようございます！今日も自動実行が成功しました。”
date
たったこれだけの設定で、毎日決まった時間にGitHub上で仮想マシンが立ち上がり、スクリプトを実行してくれます。サーバーを立てる必要も、cronを設定した常時起動のマシンを用意する必要もありません。完全無料（パブリックリポジトリ、またはプライベートの無料枠内）で動きます。
—
3. 基礎知識：cron構文の読み方と書き方
`cron: ‘0 0 ‘` の部分が、いつ実行するかを決める「cron構文」です。
左から順に5つのスペース区切りのフィールドで構成されています。
┌───────────── 分 (0 – 59)
│ ┌───────────── 時 (0 – 23)
│ │ ┌───────────── 日 (1 – 31)
│ │ │ ┌───────────── 月 (1 – 12 または JAN-DEC)
│ │ │ │ ┌───────────── 曜日 (0 – 6 または SUN-SAT。0と7は日曜日)
│ │ │ │ │
いくつか実用的なサンプルを見てみましょう。
- 毎時0分に実行: `0 `
- 平日の毎日、朝の9時30分に実行: `30 9 1-5`
- 毎週月曜日の深夜0時に実行: `0 0 1`
- 15分おきに実行: `/15 `
※なお、GitHub Actionsのcron構文は、秒単位（6つ目のフィールド）や、年単位の指定には対応していません。最短でも「分単位」の制御となります。
—
4. 【超重要】現場でハマる「UTC時間」の罠
ここからが、先輩エンジニアとして一番伝えたかった重要なポイントです。
GitHub Actionsのスケジュールは、すべて「UTC（協定世界時）」で解釈されます。 日本時間（JST）ではありません！ ここを間違えると、「朝9時に動いてほしいのに、夕方や夜中に動いてしまった……」という悲劇が起きます。
- 日本時間（JST）とUTCの時差: 日本はUTCより +9時間 進んでいます。
したがって、「日本時間の朝9時（09:00）」に実行したい場合は、JSTから9時間を引いた 「UTCの深夜0時（00:00）」 を指定する必要があります。
| 希望する日本時間 (JST) | 設定すべきUTC時間 (cron) | YAMLの書き方例 |
| :— | :— | :— |
| 午前 0:00 (深夜) | 前日の 15:00 UTC | `0 15 ` |
| 午前 9:00 (朝) | 深夜 0:00 UTC | `0 0 ` |
| 午後 12:00 (昼) | 午前 3:00 UTC | `0 3 ` |
| 午後 6:00 (夕方) | 午前 9:00 UTC | `0 9 ` |
「夏時間（サマータイム）」の導入有無によってもズレが生じる場合がありますが、日本国内で完結するプロジェクトであれば、常に「JST – 9時間 = UTC」で計算すると覚えておけば間違いありません。
—
5. 知っておくべきGitHub Actionsの裏側：キューの仕組みと「遅延」の真実
「あれ？さっき設定したのに、定刻になってもワークフローが動き出さない……」
そんな経験をしたことはありませんか？ ここにはGitHub特有のインフラ事情が絡んでいます。
cronは「正確な秒」には実行されない
GitHub Actionsのスケジュールは、アラームクロックのように「その瞬間にピタッと起動する」わけではありません。内部のキューイングシステム（処理待ちの行列）を通るため、指定した時間から数十分遅れて実行されることが日常茶飯事です。
- 遅延の理由: 世界中の数百万人の開発者が同じようにcronを設定しています。特に、毎時0分や毎日0時（UTC）といったキリの良い時間帯にはリクエストが爆発的に集中します。その結果、GitHubのサーバー側でキューが渋滞を起こし、順番待ちが発生するのです。
- どれくらい遅れるの？: 軽いときは数秒〜数分ですが、混雑時には 15分〜30分以上 遅れることも珍しくありません。
【対策】厳密な時間厳守が必要なタスクへのアプローチ
もしあなたのタスクが「何秒の遅れも許されない（例：株取引や秒単位の正確な時刻同期）」という性質のものであるなら、GitHub Actionsのスケジュール機能を使うべきではありません。
代わりに、以下のようなアーキテクチャを検討してください。
1. AWS EventBridge + Lambda: サーバーレスで秒単位の正確なスケジュール実行を行う。
2. 外部のcronサービス（cron-job.orgなど）からGitHubのRepository Dispatch APIを叩く: 外部からWebhook的にGitHub Actionsをキックする。
逆に、「一日のうちに一度動けば、何時何分であまり厳密でなくてよいバッチ処理」であれば、GitHub Actionsの遅延は全く問題になりません。安心して使い倒しましょう。
—
6. もう一つの注意点：「デフォルトブランチ」でしか動かない
これも初心者がハマりやすい罠のトップクラスです。
`schedule` トリガーは、デフォルトブランチ（通常は `main` や `master`）に存在するワークフローファイルにしか適用されません。
- 特徴ブランチ（`feature/xxx`）にどれだけ完璧なcron設定のYAMLを書いても、マージされるまでスケジュール実行は無視されます。
- デフォルトブランチにマージされた後、初めてスケジュールが有効化されます。
「動作確認のためにブランチを切ってテストしたい！」というときは、`schedule` に加えて `workflow_dispatch`（手動実行トリガー）を併記しておくのが、現場のプロとしてのスマートな定跡です。
on:
schedule:
- cron: ‘0 0 ‘
# 手動でも動かせるようにしておくと、テストが圧倒的にラクになります！
workflow_dispatch:
これなら、GitHubのActionsタブから「Run workflow」ボタンを押して、いつでも即座に動作確認ができます。
—
まとめ：今日からあなたの開発を自動化しよう！
今回は、GitHub Actionsのcron実行について、基礎から実践的な注意点まで深く掘り下げて解説しました。
- cron構文で自由な時間に自動実行ができる
- 時間は必ず「UTC（協定時間）」で指定する（JST – 9時間）
- 混雑時には実行が遅延することがあるため、厳密な時間勝負には使わない
- 動作確認には `workflow_dispatch` を組み合わせるのが鉄則
これをマスターすれば、毎日の面倒な定型作業やルーティンワークをすべてGitHubに肩代わりさせることができます。あなたの開発ライフがより快適でクリエイティブなものになること間違いなしです。
さあ、今すぐ `.github/workflows/` にファイルを作って、最初の自動化を体験してみましょう！