はじめに

スプレッドシートを始めとしたGoogleのクラウドアプリは、時間主導型トリガー（以降、タイムトリガー）を使用して、定型処理を定期的に自動実行させることができます。

タイムトリガーはＵＩ画面から簡単に設定可能ですが、ＵＩにて設定できる項目が限られているため、要望する内容によってはGASのScriptAppを使ってプログラム側からトリガーを生成する必要があります。

本稿では、ＵＩ画面からの設定では対応できない内容について、当方にご相談頂いた内容を元にした事例別の参考コードを不定期連載形式で紹介していきたいと思います。（ネタが溜まってきたら、随時公開予定です）

今回は初回ということで、比較的実装が容易なケースとして、毎日指定時間（○時○分）に実行したい場合のご紹介です。

前提条件

仕様上、実行遅延（タイムラグ）がおよそ数分以内のレベルで発生します。そのため、厳密な時間管理が必要な処理には不向きです。（公式にて一部メソッドにおいては±15分と明記されています）
同様に、仕様上、エラー通知の頻度をスクリプト側で設定できないため、 毎日通知を受け取る がデフォルトとなります。
拙記事ですが、こちらを参考にタイムゾーンの設定が実行環境と合っているか確認してください。
サンプルコードでは１日あたりの総実行時間、１ユーザーあたり２０トリガーまで等、GASの制限事項は考慮していません。

設置時の共通事項

トリガー生成ロジックは独立した関数として定義し、メイン処理内に組み込みます。組み込み位置は末尾を推奨しておきますが、好みや状況に合わせて適宜ご対応ください。
GASの制限事項を考慮し、適宜メイン処理の軽量化、高速化をしましょう。また、実行回数に関係なく、実行済みトリガーの削除処理の実装を推奨します。
初回のトリガー設定のみ手動で行います。

比較的実装が容易なケース（１）

毎日指定時間（○時○分）に実行したい

ＵＩ画面にて時間主導型 → 日付ベースのタイマーでできそう、という安易なイメージでハマる場合が多いようです。

ハマるポイントとしては、日付ベースのタイマーでは１時間単位の時間帯しか指定できず、かと言って、特定の日時 の場合は指定日時の １回しか実行されない ことです。

ご相談いただいた方の多くのは、指定時間を含む時間帯か、指定時間以降の時間帯で日付ベースのタイマーを使用していました。つまり、妥協して利用していたということですね。

ロジック

Javascriptにて翌日の指定日時を設定する
ScriptAppにて特定の日時としてトリガーを生成する

つまり、当日実行時に翌日の処理を実行予約するイメージです。結果、これが毎回繰り返されることで、毎日指定時間（仮に午後１２時３４分とします）に自動実行されます。

サンプルコード

毎日午後12:34にメイン処理を実行する

// 初期設定用オブジェクト
function init(){
  return {
    START_TIME: '12:34', // hh:mm形式で指定
    TRIGGER_HUNDLER: 'main' // 自動実行対象の関数名
  };
}

// メイン処理
function main() {
  /* メイン処理省略 */

  setTrigger();
}

// トリガー生成処理
function setTrigger() {
  const now = new Date();
  const INIT = init();
  const startTime = INIT.START_TIME.split(':');
  const targetDate = new Date(now.getFullYear(), now.getMonth(), now.getDate()+1, startTime[0]*1, startTime[1]*1);

  ScriptApp.newTrigger(INIT.TRIGGER_HUNDLER)
  .timeBased()
  .at(targetDate)
  .create();
}

初回設定

初回はＵＩ画面経由で 特定の日時 で main を実行するようにトリガーを設定するか、エディタ画面より直接 setTriggerを実行します。

最後に

今回は初回ということで、比較的実装が容易なケースとして、毎日指定時間（○時○分）に実行したい場合のご紹介をしましたが、もちろん最適解ということではございません。

上記のサンプルコードを例に、mainからsetTriggerを切り離した上で、ＵＩ画面にて時間主導型 → 日付ベースのタイマーにて、setTriggerを実行させても同様の結果を得られます。

両者の違いは メイン処理直後に翌日の実行予約をする か、メイン処理とは別に 定期的な時間帯で翌日の実行予約をする か、ということになります。

メイン処理中にエラーが発生した場合、トリガー設定をしないようにするため、本稿では前者のようなフローを採用しました。ただ、メイン処理とは切り離したい場合もありますので、状況に応じて実装すれば良いと思います。

誰かのお役に立てたなら幸いです。

[参考・引用]