これで何ができるか

サーバーを1台も借りずに、毎日決まった時刻に処理を走らせられます。

  • 毎朝7時にデータを取得して更新する
  • 毎晩、動画やニュースを要約させる
  • 毎週月曜にレポートをメールで送る

必要なのはGitHubアカウントだけです。VPSもレンタルサーバーもクレジットカードも要りません。

ただし、「毎朝7時に動かして」とだけ頼むと、たいてい思ったとおりに動きません。時刻がずれる、走らない、手動で試せない。この記事は、そうならないために最初に付けておく注文をまとめたものです。

十数本の定時実行を毎日動かしていて分かった、言っておくべきことだけを載せます。

前提
かかる時間 30分
費用 無料。公開リポジトリなら実行時間は無制限、非公開でも月2000分まで無料
必要なもの GitHubアカウント / ファイルを作れるAI
プログラミング 不要

AIへの頼み方

1. 最初の1回で、注文を全部付ける

いきなり結論です。この指示文をコピーして、○○の部分だけ書き換えてください。

○○を毎日自動で実行する仕組みを、GitHub Actions で作ってください。 時刻の注文: - 日本時間の朝7時半ごろに動かしたいです。UTCとの時差を間違えないでください - 毎時0分・毎日0時のようなキリのいい時刻は避けて、半端な分にしてください（混雑して遅延・スキップが起きるため） - 「その時刻ちょうどに動く」ことに依存しない作りにしてください 必ず入れてほしいもの: - 手動でも実行できるようにしてください - リポジトリにファイルを書き戻す場合は、必要な権限も教えてください 作る前に、この設定でいいか確認させてください。

「時差を間違えないでください」を明示するのが効きます。GitHub Actions の時刻指定は必ずUTCで、日本時間から9時間引きます。引くと前日になることが多く、ここは高い確率で間違えます。

cronの5つの数字の読み方。左から分（0-59）・時（0-23）・日（1-31）・月（1-12）・曜日（0-6、0が日曜）。時はUTCで指定する。27 22 * * * はUTC22時27分で、9時間足すと日本時間の翌朝7時27分になる。曜日を指定するときは、日本時間の月曜朝がUTCでは日曜の夜になるため 0 を指定する。
AIが書く設定はこの5つの数字です。読めなくてかまいませんが、「時がUTC」だけ知っておくと、おかしいときに気づけます。

2. キリのいい時刻を避けさせる

上の指示に入っていますが、単独で頼むならこうです。

実行時刻の「分」を、0分ではなく半端な値（13分・27分・43分など）にしてください。 理由は、毎時0分は世界中の利用者が殺到してキューに積まれ、30〜90分遅れたりスキップされたりするためです。
毎時0分にジョブが集中する様子の概念図。0分の棒が突出して高く、15分・30分・45分も高い。27分のような半端な分は空いている。キリのいい時刻はキューに積まれて30分から90分遅れ、最悪スキップされる。
混みやすい時刻の傾向を示すための概念図です（実測値ではありません）。分を半端な値にするだけで安定します。

3. 「絶対に動いてほしい」ものは多重化させる

遅れるだけならまだしも、動かないことがあります。重要な処理なら、こう頼んでください。

この処理は動かないと困るので、スキップされたときの保険を付けてください。 30分おきに4回仕掛けて、どれか1回でも動けばいいようにしたいです。ただし、2回目以降が実行されても何も壊れないように、「前回から変わっていなければ何もしない」判定を入れてください。
30分おきに4回仕掛けるタイムラインの図。1回目の7時27分が動いた日は、残り3回は「変更なし」で何もせず終わる。1回目がスキップされた日は2回目の7時57分が拾うので、結果は同じになる。
上が普通の日、下が1回目を飛ばされた日。どちらも最終的な結果は同じになります。

後半の「2回目以降が実行されても何も壊れないように」が本体です。これが無いと、4回動いて4回投稿する、のような事故になります。

定時実行を作るときは、時刻を守らせようとするより、何回走っても大丈夫にするほうが圧倒的に楽です。

4. 手動で試せるようにさせる

GitHubの画面から手動でも実行できるようにしてください。実行するボタンがどこに出るかも教えてください。
GitHubのActionsタブの図解。左にワークフロー名の一覧があり、対象を選ぶと右上に Run workflow ボタンが出る。workflow_dispatch を書いていないとこのボタン自体が表示されない。
GitHubの画面配置を説明するための図解です（実際の画面とは配色・文言が異なります）。この設定を頼まないと、右上のボタン自体が出ません。

これが無いと、動作確認も、失敗したときの復旧も、全部「次の自動実行を待つ」になります。スケジュールが初めて動くのを待たないでください。書き間違いがあった場合、翌朝まで気づけません。

5. 動かす前に確認させる

実行する前に、次を教えてください。 1. この設定だと、日本時間の何時に動きますか 2. 私がこれから手でやる作業を、順番に番号を振って書いてください 3. うまくいったとき、画面に何が出れば正解ですか

1番で時差の間違いが見つかります。「日本時間の何時に動きますか」と聞き返すだけで、UTCの計算ミスをその場で捕まえられます。

うまくいかないときの言い直し方

動くはずの時刻に動かなかった

昨日の朝、動くはずの時刻に動きませんでした。実行履歴を見て、次のどれか教えてください。 - 実行されたが失敗した - 実行されたが遅れた - そもそも実行されなかった そのうえで、原因と対処を教えてください。

3つに切り分けさせるのがコツです。「動かなかった」とだけ言うと、AIは原因を推測で語り始めます。実行履歴という事実を見せてから話させてください。

なお、数分〜十数分の遅れは正常です。GitHub のスケジュールは混雑状況次第で、正確な時刻の保証はありません。

エラーは出ていないのに、結果が保存されない

処理は成功しているのに、結果のファイルが更新されていません。 書き込みの権限が足りていないのだと思います。必要な権限と、GitHubの画面のどこをどう変えればいいかを教えてください。

定時実行が結果をリポジトリに書き戻す場合、設定ファイル側の指定とリポジトリの画面設定の両方が必要です。片方だけだと、処理は成功して最後の保存だけ失敗します。

しばらくしたら、自動実行が勝手に止まった

自動実行がいつの間にか止まっていました。60日間リポジトリに動きがないと自動で無効化される、という話を聞いたのですが、それでしょうか。確認して、再開の手順と、今後止まらないようにする方法を教えてください。

心当たりを添えて聞くと、確認が早いです。「なぜか止まった」だけだと、AIは可能性を延々と並べます。

これは、何も書き込まないタイプの自動化（メールを送るだけなど）で起きます。

同じ処理が2回走っている

同じ処理が1日2回実行されているようです。パソコンのタスクスケジューラでも同じものを動かしているかもしれません。 いま自動実行されている場所を全部洗い出して、どちらか一方に寄せる案を出してください。

「覚えのない更新」「上書き合戦」の正体はたいていこれです。両方走らせる必然性は普通ありません。

頼んでいない設定まで変えられた

いま頼んだのは時刻の変更だけです。他の設定は元に戻してください。何を変えたか一覧にしてください。

応用・次の一手

まず1つ作って、しばらく放置してみてください。動き続けることが分かると、任せられる仕事の見え方が変わります。

そのうえで、必ず死活監視を付けてください。

この自動実行が、エラーを出さずに静かに壊れたときに気づける仕組みを作ってください。「動いているが中身が古いまま」を検知したいです。

自動化で一番怖いのは、エラーで止まることではなく、エラーを出さずに古い結果を出し続けることです。詳しくは サービスが静かに壊れたのを見つけさせる に書きました。

具体的な題材が欲しければ、AIの最新情報を自動で集める がそのまま動く実例です。ここで書いた注文をすべて使っています。