GAS の時間主導トリガーがデプロイ版に固定される罠 — 「成功したのに何も起きない」の切り分け

何が起きるか

Apps Script の時間主導トリガー（ScriptApp.newTrigger("fn").timeBased().everyMinutes(1).create()）は、そのトリガーを作成した実行が属していたバージョンのコードで動き続ける。

ウェブアプリのデプロイ（バージョン付き）経由でトリガー設置関数が実行された場合、以後 clasp push で HEAD を何度更新しても、トリガーは古いバージョンを実行し続ける。

この罠が厄介なのは症状の出方である。

• トリガーは正常に動いている（実行され、結果も返る）
• 返り値は OK。例外も出ない
• しかし新しいコードの副作用（列の追加、データ移行など）が一切起きない
• clasp pull でサーバー上のコードを確認すると、新しいコードは確かに上がっている

「コードは上がっている」「トリガーは動いている」「エラーも出ない」が同時に成立するため、原因がキャッシュ・権限・ロジックのバグのどれなのか見当がつかなくなる。

同種の罠にウェブアプリの /exec がバージョン付きデプロイを参照する件があるが、トリガー経路はウェブアプリを一度も呼ばないので、/exec を叩く検証では発見できない。別の罠として扱う必要がある。

決定的な切り分け方（推測を止める）

新しいバージョンにしか存在しない関数を、意図的に失敗する引数で呼ぶ。

// 新バージョンで追加した関数を、存在しないIDで呼ぶ
{"fn":"newFunctionName","args":[{"id":"__PROBE_NOT_EXIST__"}]}

返ってくるメッセージで、どちらのコードが動いているかが確定する。

返り値	判定
許可されていないコマンドです: newFunctionName（＝関数が存在しない）	旧コードが動いている
その関数の中のエラー（例: 指定されたレコードが見つかりません）	新コードが動いている

スタックトレースの行番号も新旧でずれるので、併せて確認するとより確実になる。

この切り分けの要点は3つ。

1. データを壊さない引数を使う。存在しないIDを渡せば、検証は必ず失敗側で終わり、副作用が残らない
2. 成功ではなく失敗の種類を見る。「OK が返るか」ではなく「どのエラーが返るか」が情報を持つ
3. 待ち時間を先に排除しておく。キャッシュや索引の遅延を疑う前に、まず 10〜15 分待って同じ結果になることを確認する。それでも変わらなければ遅延ではない

直し方

clasp push の後に、既存のデプロイIDを指定して新しいバージョンを反映する。

clasp push -f
clasp list-deployments
clasp deploy -i <既存のデプロイID> -d "<変更内容>"

-i を付けるのが要点である。付けないと新しいURLが発行されるため、利用者に配布済みのURLを貼り替えてもらう手間が発生する。既存IDを指定すればURLは変わらないままバージョンだけが上がる。

clasp list-deployments は通常2件返す。

- AKfycb...xxxx @HEAD
- AKfycb...yyyy @8 - v8

利用者が実際に踏んでいるのは @<数字> の方である。@HEAD の方を更新しても利用者の環境は変わらない。

注意 — -i での上書きが効かない環境もある

clasp deploy -i <既存ID> は Deployed ... @9 と表示されても、実際には旧コードが配信され続けたという報告がある。「Deployed と表示された」を成功判定にしてはいけない。

-i を実行したら、必ず上のプローブをもう一度実行して、新コードが動いていることを確認してから「反映しました」と報告する。プローブが旧コードのままなら、新規デプロイ（-i なし）を作る必要があるが、その場合はURLが変わるので配布物の差し替えが伴う。

チェックリスト

GAS を変更して「反映されない」と感じたら、上から順に潰す。

1. clasp pull して、サーバー上のコードが本当に新しいかを確認する（ここが古ければ push の失敗）
2. 10〜15 分待って再試行する（キャッシュ・索引遅延の排除）
3. 新関数プローブで、実行されているコードが新旧どちらかを確定させる
4. 旧コードなら clasp deploy -i <既存デプロイID> を実行する
5. プローブをもう一度実行して、新コードに切り替わったことを確認する
6. そこで初めて、本来やりたかった処理を実行する

この罠を最初から避ける設計

• トリガー設置関数は、必ずデプロイ後に実行し直す運用にする。変更のたびに deploy → トリガー再設置 をセットで行えば固定は解消される
• 副作用のある移行処理は、必ず「実行した証拠」を返す。Logger.log だけでなく、戻り値に「何行移行したか」を含める。戻り値が undefined だと、実行されたのか素通りしたのかが区別できない
• 移行関数は冪等にする。ヘッダーの内容などで現在の形を判定し、既に新形式なら何もしない。何度実行しても壊れない状態を作っておけば、切り分け中に安心して何度でも叩ける