GitHub ActionsのCronは「信頼するな」：バッチ処理を確実に完遂させるための極限戦略
GitHub Actionsの `on: schedule` を使っているか？「なんとなく設定して、動いたり動かなかったりしている」という状態なら、それはエンジニアとして危険信号だ。
cronは便利だが、GitHub Actionsにおけるそれは、「指定した時間に必ず実行される」という保証のない、あくまで「リクエストベースのスケジューリング」に過ぎない。本稿では、プロの現場で生き残るための「GitHub Actionsのスケジューリングとバッチ実行の真実」を叩き込む。
—
1. Cronの深淵：UTCの罠と「遅延」という現実
GitHub Actionsのcron構文はPOSIX標準に準拠しているが、最大の注意点は「すべてUTC（協定世界時）で評価される」ことだ。日本時間（JST）で運用したい場合、9時間の時差を脳内で変換するのではなく、必ずコメントにJSTの時間を併記せよ。
on:
schedule:
# 毎朝9:00 JSTに実行したい場合 (UTC 0:00)
- cron: ‘0 0 ‘
なぜ「遅延」が起きるのか？
GitHub Actionsのサーバーはマルチテナントだ。`on: schedule` で設定した時刻は、GitHub側のスケジューラーが「トリガーキュー」に投入する時刻に過ぎない。
- 高負荷時の遅延: GitHubプラットフォーム全体の負荷が高い時、実行キューが詰まり、数分から時には数時間の遅延が発生することがある。
- 解決策: 「時刻が正義」のバッチには絶対に使わないこと。もし厳密な時刻管理が必要なら、外部のクラウドスケジューラー（AWS EventBridgeなど）からGitHub Actionsの `workflow_dispatch` APIを叩くのが唯一の正解だ。
—
2. 依存関係更新を「完全自動化」する神構成
依存関係の更新（DependabotやRenovate）は手動でやると死ぬ。以下の設定は、堅牢なCI/CDを組む上でのベストプラクティスだ。
.github/workflows/dependency-refresh.yml
name: Dependency Refresh
on:
schedule:
- cron: ’30 2 1′ # 毎週月曜 11:30 JSTに定期更新チェック
workflow_dispatch: # 「今すぐ実行」できるようにしておくのが鉄則
jobs:
update:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with: { node-version: ’20’ }
# 依存関係更新後のテストが失敗したら即座に通知する
- name: Run Tests
run: npm test
プロのテクニック: `workflow_dispatch` を必ず含めること。自動更新が失敗した際、修正後に手動で再実行できないパイプラインは、ただの「負債」である。
—
3. 実務で差がつく「GitHub Actions」ハック集
① キーボードショートカットで爆速化
ブラウザでGitHubを開き、リポジトリのActionsタブへ移動した状態で、以下のキーを押せ。
- `g` + `a`: 瞬時にActionsページへ移動。
- `cmd + k` (Mac) / `ctrl + k`: GitHubのコマンドパレットを開き、ワークフロー名を入力して直接実行。
② 絶対入れるべき「神プラグイン（Action）」
- [action-slack](https://github.com/slackapi/slack-github-action): 失敗時はエンジニアのSlackへメンションを飛ばせ。メール通知など見ない。
- [cache](https://github.com/actions/cache): `node_modules` や依存キャッシュを使い倒せ。毎回のインストール時間は最大の無駄だ。
③ 設定の「共有化」ルール
大規模チームでは、ワークフローをコピペしてはいけない。
- Composite Actions: 再利用可能なロジックは `.github/actions/` 配下に集約せよ。
- Reusable Workflows: 複数のリポジトリで共通のデプロイフローがあるなら、単一のリポジトリで管理し、`uses: owner/repo/.github/workflows/main.yml@main` で呼び出せ。これで管理コストが激減する。
—
4. 最後に：テックリードからの提言
CI/CDにおいて最も愚かなのは、「CIが落ちていることに誰も気づかない状態」だ。
cronで動くバッチは、特にサイレントな失敗（成功したように見えるが処理が動いていない）を隠しやすい。
- ガードレールを敷け: 成功・失敗に関わらず、重要なバッチが終わったら必ずWebhookでステータスを通知するステップを組み込め。
- 冪等性（Idempotency）を担保せよ: 何度実行しても同じ結果になるように設計しろ。それができないなら、そのコードはプロダクションコードではない。
ツールは、使う側の思考レベル以上に賢くはならない。GitHub Actionsを単なる「動くスクリプト置き場」ではなく、「チームの自律的な品質保証エンジン」に昇華させること。それが、君がテックリードとして成すべき仕事だ。
健闘を祈る。