これで何ができるか
毎朝・毎時ひとりでに動かしている処理が、予定の時刻より遅れて実行された日でも、取りこぼしと二重処理を防げる指示文の作り方です。プログラミングは要りません。
毎日決まった時刻にAIを動かす仕組みを作ると、次に気になるのが「本当に決まった時刻に動いているか」です。このサイト自身のニューストラッカー（毎時実行の設計）の実行記録を、外向き通信を使わず手元のgit履歴だけで実測しました。
「70分以内」で動いたのは275回中135回、49%だけでした。中央値は76分、いちばん空いた回は25.0時間（8月9日07:49の実行から次が8月10日08:49）です。GitHub Actionsのスケジュール実行は、そもそも指定した時刻ちょうどに動く仕組みではありません。
ここで問題になるのが、自動処理が「今日はどこまでを対象にするか」をどう決めるかです。「7時までに届いた分」のように時刻で範囲を決めると、実行そのものが遅れたときに範囲がずれます。今回、架空の受付ログで実際に試したところ、時刻を基準にした指示は同じ文面のまま3回走らせても答えが割れました。「前回処理した続きから」に変えると、3回とも同じ答えになります。
前提
| かかる時間 | 20分 |
| 費用 | 無料 |
| 必要なもの | 毎時・毎日など定期実行している処理（GitHub Actionsで作る例）／AI |
| プログラミング | 不要 |
- すでに定期実行を動かしていること。この記事は「動かし方」ではなく「遅れた回に何を対象にするか」の話です
- 対象の処理が、一覧やログから「今回処理する分」を選ぶ形になっていること（受信箱・受付ログ・注文一覧など）
AIへの頼み方
1. 「時刻を基準」ではなく「前回処理した続きから」を指定する
架空のセミナー申込みの受付ログ24件を用意しました。前回の実行（2026年8月25日07:03）で R-014 まで処理済み、その後に届いた新着が R-015〜R-024 の10件、という設定です。今回の実行は本来7時の予定が、実際には3時間12分遅れて10時12分に行われました。
まず、ありがちな頼み方です。下の指示文は、避けたほうがいい書き方の例です。真似しないでください。
この指示文を、新規の会話で3回走らせました。返ってきた件数は21件・18件・4件と、毎回違います。すでに処理済みのはずの14件（R-001〜R-014）が何件また対象に含まれたか（重複、正しくは0件）を数えると、14件・14件・0件でした。
同じく新規の会話で3回走らせたところ、3回とも R-015〜R-024 の10件ちょうどでした。重複0・取りこぼし0が3回とも揃っています。
なぜこの言い方が効くか。「7時までに届いた分」は、実行のたびに「今の7時とはいつのことか」をAIが読み取り直す必要があります。「前回処理した最後のID」は、読み取りではなく照合（このIDより後かどうか）で決まるので、実行が何時であっても揺れません。このサイトのニューストラッカー自身も、時刻ではなく「前回まで読んだ記事のID一覧」（seen.json）で新着を判定しています。
📌 取りこぼしのほうも数えると、時刻基準は3件・6件・6件（正しくは0件）でした。1回目は「7時以降に届いた新着3件」を除外しただけでしたが、2回目・3回目は本来含めるべきR-016〜R-018のような7時より前の新着まで一緒に取りこぼしています。同じ指示文・同じログでも、AIがどこまでを「本日7時まで」に含めるかは安定しませんでした。
2. 遅延の事実を伝えても、時刻基準の指示は直らない
「実行が3時間遅れたこと」をAIに伝えれば、賢く対象を広げてくれるのでは、とも考えました。試しています。
結果は3回とも21件・重複14件・取りこぼし3件で変わりませんでした。返り自身が理由を書いています。「実行が本来の朝7時ではなく10時12分に行われたことは、抽出結果には影響していません。今回の基準は『本日の朝7時までに届いた分』という届いた時刻そのものであり、処理が実行された時刻ではないためです」——指示文が「7時まで」と言っている以上、それに忠実に従った結果です。
こちらは3回とも重複0・取りこぼし0で、遅延を伝えなかったときと同じ結果でした。効くかどうかを決めているのは「遅れを伝えたかどうか」ではなく、「何を基準に選ばせているか」です。遅延の事実を教える手間は、前回位置を基準にしている限り要りません。
📌 唯一の違いは安定性でした。時刻基準の版は遅延を伝えなかったとき21件・18件・4件と割れましたが、遅延を伝えた版は3回とも21件で揃っています。時刻の基準がはっきりするぶん、答えの割れ方だけは収まったようです。ただし収まった先が正解ではないので、安定しているからといって正しいとは限りません。
3. 初めて動かす日（前回の記録がまだない）は、絶対時刻で起点を決める
「前回処理済みのID」は、動かし始めた初日にはまだ存在しません。その場合は、時刻を使うこと自体は問題なく、「〜より前」ではなく「〜以降」で絶対時刻を1つ決める形にします。
2回とも R-021〜R-024 の4件（正解）で一致し、次回のためのIDも2回とも R-024（正解）でした。「7時までに届いた分」のような上限を時刻で切る言い方が割れたのに対し、「06:00以降」のような下限を1つ決める言い方は安定しています。振れが出たのは「今のこの瞬間までの上限をどこに引くか」を毎回読み取らせたときで、基準点そのものを1つの絶対値で固定したときではありませんでした。
4. 次回のために、今回処理した最後の場所を書き出させる
前回位置を基準にする形を自動で回すには、次回に渡すIDを毎回どこかに記録する必要があります。指示文の最後に一文足すだけです。
2回とも、対象の10件と、次回のためのID R-024 の両方が正しく返りました。この最後の一行を、次回の実行時に「前回処理済みの最後のID」としてそのまま渡せば、時刻に一切触れずに毎回の対象範囲が決まります。
うまくいかないときの言い直し方
前回処理済みの記録が見当たらない・壊れている
前回位置の記録ファイルが壊れていたり消えていたりすることがあります。このとき「分からないので念のため全部処理してください」に倒すと、既に処理済みの分まで全部重複します。3の指示文（絶対時刻で起点を決める）に切り替えて、「今日のこの時刻以降だけ」と安全側に狭く倒してください。取りこぼした分は、翌日以降の手動確認で拾えます。多く処理しすぎて事務局に二重の案内が届くほうが、影響が大きいことが多いはずです。
時刻での説明も残したい
前回位置だけだと、人間が結果を見たときに「今日は何時から何時までの分か」が分かりにくくなります。その場合は、選ぶ基準は前回位置にしたまま、結果に時刻を添えさせてください。
「対象は前回処理済みのIDより後の分」という選び方は変えず、出力の一覧に届いた日時も一緒に書かせれば、人が確認するときの読みやすさは損なわれません。選ぶ基準と、表示のための情報は別に扱えます。
前回位置の対象件数が、いつもよりはるかに多い・0件だった
これは「遅れて動いた」ではなく「材料そのものが壊れている」可能性のサインです。件数のいつもとの違いを自動で見張る形は、定期実行が本当に動いたかを、材料の件数で確かめるにまとめてあります。この記事の指示文と組み合わせると、「対象範囲は前回位置で正しく決め、件数の異常は別の仕組みで見張る」という役割分担になります。
応用・次の一手
毎日決まった時刻にAIを動かす仕組みには「数分〜十数分の遅れは正常です」と書きました。今回の実測（中央値76分・最長25.0時間）は、その言葉より遅れの幅がずっと大きいことを示しています。⚠️ この数字はこのサイト自身のGitHub Actionsの実測であり、ChatGPTのタスク機能やGeminiのスケジュール実行がどうなるかは測っていません。別の仕組みに一般化しないでください。
自動化がそもそも動いたかどうかを見張る仕組みは、自動化が静かに壊れたのを、AIに見つけさせるにあります。あちらは「動かなかった」を見つける話、この記事は「動いたが遅れた」ときに対象範囲を壊さない話です。似た自動化まわりの記事に止まった日のメモだけで再開するもありますが、あちらは処理が途中で止まった日の引き継ぎメモの話で、こちらは実行そのものは最後まで動いた前提での対象範囲の話です。
すでに動いている自動化があれば、まず対象範囲の決め方だけを確認してください。「今日」「7時まで」のような時刻の言葉が指示文に入っていたら、前回処理済みの位置を基準にする形に書き換える価値があります。書き換えたら、4の一文を添えて、次回のための位置が毎回正しく書き出されているかを1度確認してください。
📌 この記事の実測は、架空の受付ログ1本・4版×各3回＝12回（1・2節）に加えて、初回起動2回（3節）・次回位置の書き出し2回（4節）の計16回です。判定はすべて機械照合（集合演算での重複・取りこぼしの数え上げ）で、生の回答は docs/evidence/resume-from-last-not-clock-time.md に全文置いてあります。⚠️ 実測に使ったAIは、このセッション内の新規サブエージェント（Agentツール）です。素のAIがどう返すかの一般化はせず、機械で確認できた件数だけを根拠にしています。