昨日まで動いたGASが急に止まった｜権限・トリガー・外部APIで最初に見る7項目

昨日まで普通に動いていたGASが、朝になったら急に止まる。

コードは触っていない。シートも大きく変えていない。それなのにメールが飛ばない、PDFが保存されない、定期処理が実行されない。

こういう相談、実際かなり多いんですよね。

結論から言うと、GASが突然止まったときに最初からコードを全部読む必要はありません。僕はまず、権限・トリガー・外部API・実行ユーザー・参照先・上限・ログの7項目を順番に確認します。

この順番を飛ばしてコードを直し始めると、原因ではない場所を触って別の不具合を増やします。

はい。地獄の増築です。

 コードより先に見る7項目

 1．Googleアカウントの権限

最初に確認するのは、スクリプトを誰のアカウントで実行しているかです。

GASはコードだけで動いているように見えますが、実際には実行ユーザーの権限を使っています。スプレッドシート、Googleドライブ、Gmail、外部サービスへの接続権限が変われば、昨日までの処理でも止まります。

特に引継ぎ後は危険です。

作った人のアカウントでは動く。別の担当者が押すと動かない。この状態で「環境によって不安定です」と言われることがありますけど、環境ではなく権限差であることが多いです。

確認するのは次の内容です。

・対象ファイルへの編集権限  

・保存先フォルダへの書込み権限  

・Gmail送信権限  

・外部サービス連携の承認状態  

・スクリプトの所有者

「ファイルを開ける」と「GASから書き込める」は別物です。

 2．時間主導トリガー

次はトリガーです。

毎朝7時に動く処理、10分ごとに保存する処理、フォーム送信時に動く処理などは、コードではなくトリガー設定が起点になります。

コードが正しくても、トリガーが削除されていたら一度も実行されません。

以前、処理本体を何度見直しても問題がなく、最終的に確認したら時間主導トリガーが存在していなかったケースがありました。原因が分かれば一瞬ですけど、そこへ行くまでコードだけを追うとクッッッソ時間を使います。

確認するのは次の3点です。

・トリガーが残っているか  

・実行関数名が現在のコードと一致しているか  

・失敗通知が出ていないか

関数名を変更したのに、トリガーが古い関数を呼び続けていることもあります。

 3．外部APIのアクセストークン

Dropbox、Chatwork、Slack、Trelloなどと連携している場合は、外部APIを確認します。

僕が対応した案件では、既存のアクセストークンがあるため接続自体はできていました。しかし、対象フォルダへの書込み時にHTTP 409と`path/no_write_permission`が返っていました。

つまり、トークンがあるから大丈夫ではなかったんです。

接続確認が通ることと、目的の操作ができることは違います。

・トークンが失効していないか  

・必要なスコープが付いているか  

・対象フォルダへの権限があるか  

・アプリ専用領域とDropbox全体のどちらを使っているか

ここを分けて確認します。

 4．実行ユーザーの変更

退職、異動、Googleアカウント変更の後に止まるケースです。

時間主導トリガーは、設定したユーザーにひもづいています。元担当者のアカウント停止後も、スプレッドシートだけは共有されている。見た目は残っているので気づきにくいんですよね。

それで月初の処理だけ動かない。

めちゃくちゃ嫌な止まり方です。

運用中のGASでは、作成者ではなく「運用を継続するアカウント」でトリガーを作る方が安全です。

 5．シート名・列位置・保存先

GASは、シート名や列番号を固定していることがあります。

例えばコード側が「メール作成」というシート名を探しているのに、利用者が「メール作成_旧」に変更したら取得できません。列を1本追加しただけで、D列として読んでいた値がE列へずれることもあります。

コードを変更していなくても、入力側の構造変更で止まるわけです。

僕は確認時に、次を並べます。

・参照しているシート名  

・読み込むセル位置  

・見出し名  

・保存先フォルダID  

・対象ファイルID

見た目ではなく、コードが見ている識別子で確認します。

 6．Google側の実行上限

大量メール、PDF生成、ファイル操作、外部API呼出しが増えると、実行時間や利用上限に当たる場合があります。

昨日までは100件だった処理が、今日だけ1,000件になった。コードは同じでも処理量は同じではありません。

この場合は単純な再実行ではなく、分割処理や再開位置の保存が必要です。

「失敗したら最初から全部やり直す」設計は、データが増えた瞬間に苦しくなります。

 7．実行ログと失敗した地点

最後にログです。

最初から全コードを読むより、どこまで正常に進み、どこで止まったかを確認します。

・実行された時刻  

・実行した関数  

・エラーメッセージ  

・失敗した行  

・外部APIのHTTPステータス  

・処理対象の件数

ここまで分かれば、調査範囲はかなり狭くなります。

逆に「動きません」だけだと、原因候補が多すぎます。僕でも透視能力はありません（欲しいですけど）。

 応急処置だけで終わらせない

止まったGASを直すだけなら、エラー箇所を修正して再実行すれば終わることもあります。

ただし、業務で使うなら次に止まったときの準備まで入れた方が安全です。

・エラー内容を管理者へ通知する  

・処理件数をログへ残す  

・外部APIの応答を記録する  

・途中から再開できるようにする  

・権限やトリガーの確認手順を残す  

・運用アカウントを明確にする

僕も昔は、動いた瞬間に「よし、完了」と思っていました。

今考えると、目の前の火を消しただけなんですよね。次の火災報知器を付けていない。終わってる。

 まとめ

昨日まで動いていたGASが止まったときは、いきなり全面改修する必要はありません。

最初に確認するのは次の7項目です。

1．Googleアカウントの権限  

2．時間主導トリガー  

3．外部APIのアクセストークン  

4．実行ユーザー  

5．シート名・列位置・保存先  

6．Google側の実行上限  

7．実行ログと失敗地点

この順番で確認すると、コードの問題なのか、運用環境の問題なのかを切り分けやすくなります。

GASのエラー原因が分からない、前任者が作ったため触れない、急ぎで復旧したい場合は、現在のファイルとエラー内容を整理したうえでご相談ください。

全面的な作り直しではなく、原因調査、最小修正、再発防止まで分けて対応できます。