前回の続き——引き金が、もう1つ増える
前回のK-07では、相手側の出来事がこちらの受け口へ通知を送ってくるWebhookを学びました。あれは、相手が引き金を引く仕組みでした。今回扱う定期実行は、人でも相手でもなく、時刻そのものが引き金になります。これで処理の引き金が3種類そろい、どの要件をどの引き金で実現するかを、自分で選べるようになります。今回はその3つ目を、正式に手に入れる回です。
このスライドのポイント
- K-07: 相手の出来事がこちらの受け口へ通知を送るWebhookを学んだ
- Webhookは「相手が引き金を引く」仕組みだった
- 今回の定期実行は、人でも相手でもなく「時刻そのもの」が引き金
- これで引き金が3種類そろい、要件ごとに選べるようになる
定期実行の定義
まず言葉を定義します。定期実行とは、「毎朝9時」「5分ごと」のように、時刻や間隔を引き金として処理を開始する仕組みのことです。スケジュール実行とも呼びます。ここまで見てきた引き金は、I-06で扱った人の操作と、K-07で扱った相手からの通知の2つでした。定期実行は、そのどちらでもなく、決めた時刻が来たこと自体をきっかけにします。主な用途は、日次の集計、リマインドの送信、外部データの定期取得などです。
このスライドのポイント
- 定期実行＝時刻・間隔を引き金として処理を開始する仕組み（スケジュール実行とも呼ぶ）
- 例:「毎朝9時」「5分ごと」
- ここまでの引き金は、操作（I-06）と通知（K-07）の2つだった
- 主な用途: 日次集計・リマインド送信・外部データの定期取得
なぜ必要か——定番要件と特有の罠
この仕組みを知らないと、「毎週月曜に未提出者へ通知する」といった業務の定番要件を、実装の形に翻訳できません。人が毎回ボタンを押す前提でしか考えられず、自動で回る設計が思い浮かばないのです。さらに、定期処理には特有の罠があります。代表が、前回の処理が終わる前に次の時刻が来てしまう「多重起動」です。この危険を知らないと、AIが出してきた定期処理の設計の穴を、そのまま見逃してしまいます。
このスライドのポイント
- 知らないと「毎週月曜に未提出者へ通知」のような定番要件を実装に翻訳できない
- 人が毎回ボタンを押す前提でしか考えられなくなる
- 定期処理には特有の罠がある——代表が「多重起動」
- 多重起動＝前回の処理が終わる前に、次の時刻が来て重なること
構造——引き金3種の整理と注意3点
全体像を、引き金の3種類で整理します。人の操作は、押した瞬間に即時処理へ向かいます。相手からの通知は、あらかじめ用意した受け口が受け止めます。そして時刻は、定期実行として決まった時間に処理を起動します。定期実行を設計するときは、あわせて3つの注意点を押さえます。多重起動をどうするか、失敗したときに再実行するか、そして実行の記録を残すか、の3点です。この3点を決めていない定期処理は、静かに壊れる余地を残します。
このスライドのポイント
- 引き金3種の整理: 操作→即時処理／通知→受け口／時刻→定期実行
- 定期処理の注意3点をあわせて押さえる
- ①多重起動をどうするか ②失敗時に再実行するか ③実行の記録を残すか
処理の流れ——毎月1日の集計を例に
具体例で見てみます。経費アプリで、毎月1日の9時に先月分の集計を作る処理を考えます。単純に時刻で起動するだけなら簡単です。問題は、集計に時間がかかり、処理が次の実行と重なってしまう場合です。このとき、次の実行を飛ばすのか、それとも前の処理の完了を待つのかを、あらかじめ決めておく必要があります。ここまで決めて、初めて本当の要件定義と言えます。A-08で学んだ、例外を先に決めることの、時間版だと考えてください。
このスライドのポイント
- 場面: 経費アプリ「毎月1日9時に、先月分の集計を作る」
- 単純に時刻で起動するだけなら簡単
- 問題は、集計が長引いて次の実行と重なる場合
- 次を飛ばす（スキップ）か、前の完了を待つかを、あらかじめ決める
技術サンプル——タイムラインで多重起動を見る
スライドのサンプルは、定期処理のタイムラインを図にしたものです。上の帯は、各実行が定刻の間に終わっている正常な状態です。下の帯は、1回目の処理が長引き、2回目の定刻に達しても終わっていない、多重起動の危険を表しています。読み方のポイントは、定期処理は重なったらどうするかまで含めて設計する、ということです。特に、数分ごとのように間隔が短いほど重なりやすくなります。AIへ組み込ませたら、前回が終わっていないときと失敗したとき、それぞれどう動くかを必ず確認してください。
混同しやすい点——定期実行とWebhook
混同しやすいのが、定期実行とWebhookです。どちらも人の操作なしに処理が始まりますが、引き金が違います。定期実行は時刻が引き金で、リマインドの送信のように、決まった時間に自分から動くものに向いています。Webhookは相手の出来事が引き金で、決済完了の記録のように、いつ起きるかが相手次第のものに向いています。時刻で動かしたいのか、相手の出来事に反応したいのか。この引き金の性質を見て、どちらで実現するかを選びます。
バイブコーディングでの確認点——実行の記録を残させる
バイブコーディングでの確認点です。定期処理には、必ず実行の記録を残させてください。いつ動いて、成功したか失敗したかを記録する、という意味です。定期処理の怖さは、動かなかったこと自体に気づけない点にあります。画面のボタンなら、押して反応がなければすぐ気づきます。しかし裏で静かに止まった定期処理は、誰も気づかないまま放置されがちです。AIへは「この定期処理は、実行のたびに成功・失敗を記録に残しますか」と確認しましょう。この記録は、カテゴリSで学ぶ監視へつながっていきます。
このスライドのポイント
- 定期処理には「実行の記録」を必ず残させる
- 記録＝いつ動いて、成功したか失敗したか
- 怖さは「動かなかったこと自体に気づけない」点にある
- この記録は、カテゴリSで学ぶ監視につながる
まとめと一問一答
最後に一問一答です。処理の引き金は、3種類ありました。それは何でしょうか。（間）答えは、人の操作、相手からの通知であるWebhook、そして時刻を引き金にする定期実行の3つです。30秒でまとめます。定期実行は時刻を引き金にする仕組みで、設計では多重起動、失敗時の再実行、実行の記録という3点を必ず押さえます。次回のK-09では、重い処理をリクエストから切り離すジョブキューへ進みます。関連資料は「n8n自動化レシピ50」「GAS自動化レシピ50」「通知・リマインド設計30」です。
このスライドのポイント
- 一問一答: 処理の引き金3種類は？
- 答え: 人の操作・相手からの通知（Webhook）・時刻（定期実行）
- 30秒まとめ: 定期実行＝時刻が引き金／設計は多重起動・失敗時の再実行・実行記録の3点
- 次回: K-09 ジョブキュー（重い処理を切り離す）
- 関連資料: 「n8n自動化レシピ50」「GAS自動化レシピ50」「通知・リマインド設計30」
