サーバー代0円で定期実行を回す：GitHub Actions の cron でハマった3つのこと

Posted at 2026-10-29

やりたかったこと

個人開発で、株価データを定期的に集めて条件チェックし、結果をメールで受け取る仕組みを運用しています。

いわゆる「定期収集 → 条件判定 → 通知」という型の自動化です。題材は株価ですが、価格監視でも求人チェックでも、形は同じだと思います。

最初は手元の PC で cron を回そうとしたのですが、スリープで止まる問題が避けられませんでした。レンタルサーバーを借りるほどでもない。そこで行き着いたのが GitHub Actions のスケジュール実行です。コードを置いている場所でそのまま定期実行できて、私の規模なら無料枠に収まります。

この記事では、実際に回し始めてから「先に知りたかった」と思った落とし穴を3つ紹介します。なお、これは仕組みの解説記事で、投資の判断や銘柄の話は一切しません。

GitHub Actions の schedule は UTC（協定世界時）指定です。日本時間とは9時間の差があります。

私のケースだと「平日 19:23（JST）に実行したい」ので、UTC では 10:23 になり、曜日も含めてこうなります。

on:
  schedule:
    - cron: "23 10 * * 1-5" # JST 19:23 = UTC 10:23、月〜金

地味ですが、ここを間違えると実行時刻が丸ごとずれます。特に日付が変わる時間帯（JST の深夜0〜9時）では曜日までずれるので、「JST の時刻から9時間引く。曜日が前日に戻る場合は曜日も1つ戻す」と意識しておくと安全です。

ついでに、workflow_dispatch を併記して手動実行できるようにしておくと、テストのたびにスケジュールを待たずに済みます。これは地味に効きます。

GitHub Actions のスケジュール実行は、混雑時に数分〜十数分遅れることがあります。公式にも、ピーク時は遅延しうる旨が書かれています。

つまり「何時何分ちょうど」に意味がある用途には向きません。私の用途は「市場が閉まった後のチェック」なので、十数分の遅れは問題になりませんでした。定期実行を Actions に任せる前に、自分の用途が遅延に耐えられるかを確認しておくのが大事です。

プライベートリポジトリの無料枠は月2,000分（Free プランの場合）です。私の実行は1回あたり数分で、平日分＋週次レポートを合わせても月に100分も使いません。個人の自動化なら、まず無料枠で十分というのが実感です。

ただし、テスト実行を繰り返すと意外と消費します。あと、実行のたびに依存ライブラリのインストールが走るので、処理時間の大半はそちら、ということもあります。キャッシュを使うかどうかは、まず素朴に回してみてから判断でいいと思います。

API キーは Secrets に置く。コードへの直書きはしない、が大前提です
「前回通知した内容」をどこかに保存する。保存しないと、同じ通知が毎日届きます。私の場合は Git のデータ専用ブランチに状態ファイル（JSON）を置く方法を取りました。データベースを用意するより個人規模では楽でした
データソースの癖を知る。株価の取得に使っている yfinance は、たまに取得失敗や空データを返します。「0件取得」を正常と取り違えないチェックは必須でした。また財務データの J-Quants API（無料プラン）は約12週間の遅延があるので、「いつの時点の数字か」を常に意識して使っています
失敗に気づく仕組み。自動化で一番怖いのは、エラーで止まることより「止まっていることに気づかないこと」です。生存確認をどう設計するかは、作り始める前に考えておく価値があります

この記事では落とし穴の概観だけに絞りました。実際に手を動かす部分――

――は、note の有料記事に全手順を書いています。

「毎朝メールが届く仕組みを、自分で作った。――個人開発の自動スクリーナーをGitHub Actionsで無人運用するまでの全手順」
https://note.com/iguana_ai/n/nbef41adb6c5b

個人開発の自動化は、作ること自体より「止まらずに回り続けること」の方が難しいと感じています。GitHub Actions はその入口としてかなり手軽なので、自分の「毎日の面倒なチェック」を1つ預けてみるのはおすすめです。