# 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` だと、実行されたのか素通りしたのかが区別できない - **移行関数は冪等にする**。ヘッダーの内容などで現在の形を判定し、既に新形式なら何もしない。何度実行しても壊れない状態を作っておけば、切り分け中に安心して何度でも叩ける ---