GASのトリガーが動かない原因6系統と、実行数画面から切り分ける手順

時間主導型トリガーを毎朝6時に設定したのに、集計シートが昨日のまま止まっている。onEdit を書いたのに、セルを編集しても何も起きない。先週まで動いていた自動送信が、今週になって静かに飛んでいる——GAS（Google Apps Script）のトリガーが動かないという相談は、原因がひとつではないぶん、思いつくところから触ると半日が溶けます。

この記事では、原因を6つの系統に束ねたうえで、Apps Script エディタの「実行数」画面から順番に切り分ける手順をまとめます。公式ドキュメントに書かれている仕様と、公式には書かれていないこと（＝断定してはいけないこと）は、はっきり分けて書きます。

結論：GASのトリガーが動かない原因は「起動していない」「失敗している」「ズレているだけ」の6系統

症状は同じ「動かない」でも、中身は次の6つのどれかにほぼ収まります。

1. シンプルトリガーでは実行できない処理を書いている（認可が必要な処理はインストーラブルトリガーが要る）
2. トリガーを作ったアカウントと、いま編集しているアカウントが違う
3. 承認（認可）が切れている／承認し直していない
4. エラーで失敗し続けている（＋その通知メールから誰かがトリガーを止めた可能性）
5. 時間主導型は実行タイミングに幅がある（分単位で正確ではない＝そもそも壊れていない）
6. クォータ（上限）に当たっている

このうち1・2・5・6は「そもそも起動していない」、3・4は「起動したが失敗している」です。先にどちらなのかを確定させれば、見るべき場所が半分に減ります。それを1分でやるのが次の3点です。

まず1分で確認する3点

コードを直す前に、ここだけ見てください。順番を守れば、直す必要のない場所を触らずに済みます。

1. Apps Script エディタの「実行数」を開く。 公式ドキュメントには「Google Apps Script はすべての実行を記録する。実行を見るには『実行数』をクリックする」とあります（トラブルシューティング｜Apps Script 公式ドキュメント）。トリガーの実行もここに残ります。
2. 該当の時刻に「行があるか／無いか」だけを見る。 行が1件も無ければ系統1・2・5・6。行があって状態が「失敗」なら系統3・4です。
3. いま自分がログインしているアカウントを確認する。 ブラウザで複数のGoogleアカウントを使い分けている場合、そもそも別の人のトリガーを見に行っている、ということが起こります。

ここで「行がある＋成功している」なら、止まっているのはトリガーではなく、その先（メール送信・シート書き込み・外部API）です。トリガー設定をいくらいじっても直りません。

原因別の対処6手順

手順1：シンプルトリガーの制限に当たっていないか確認する

onOpen onEdit onSelectionChange doGet などの「シンプルトリガー」は、関数名を書くだけで動く代わりに、公式で明確に制限が置かれています。シンプルトリガー｜Apps Script 公式ドキュメントには次のように書かれています。

• スクリプトは Google スプレッドシート、スライド、ドキュメント、フォームのいずれかのファイルにバインドされているか、それらを拡張するアドオンである必要がある
• ファイルが読み取り専用（閲覧またはコメント）モードで開かれているときは実行されない
• 認可（authorization）が必要なサービスにはアクセスできない。たとえば Gmail サービスは認可が必要なので、シンプルトリガーからメールは送れない
• バインドされたファイルは変更できるが、他のファイルにはアクセスできない（認可が必要になるため）
• スクリプトの実行やAPIリクエストではトリガーは動かない。たとえば Range.setValue() でセルを編集しても、そのスプレッドシートの onEdit トリガーは実行されない
• 現在のユーザーを特定できるとは限らない（複雑なセキュリティ上の制限に依存する）
• 30秒を超えて実行できない
• Apps Script のトリガーのクォータ制限の対象になる

つまり「onEdit の中でメールを送る」「onEdit の中で別のスプレッドシートに転記する」は、書いた時点で動きません。コードが悪いのではなく、実行できる場所が違います。

直し方は、その処理をインストーラブルトリガーとして登録し直すことです。公式には「インストーラブルトリガーは、認可を必要とするサービスを使える」「常に、そのトリガーを作成した人のアカウントで実行される」とあります（インストーラブルトリガー｜Apps Script 公式ドキュメント）。エディタ左の「トリガー」から、イベントの種類を「編集時」にして関数を指定します。

このとき関数名は onEdit のままにしないのがコツです。同名のままインストーラブル登録すると、シンプルトリガーとインストーラブルトリガーの両方が反応して、1回の編集で処理が二重に走ります。handleEdit のように別名にしてから登録してください。

ここで直らないなら、原因はシンプルトリガーの制限ではありません。インストーラブルに直しても「実行数」に1行も出ないなら、起動条件そのもの（手順2・手順5）を疑ってください。

手順2：トリガーを作ったアカウントを特定する

「トリガーが勝手に消えた」という相談のうち、かなりの割合がこれです。公式ドキュメントの「Installable triggers always run under the account of the person who created them.（インストーラブルトリガーは常に、それを作成した人のアカウントで実行される）」という一文が効いています。

この仕様から、共有スプレッドシートでは次のことが起きます。

• Aさんが作ったトリガーは、Bさんが編集してもAさんの権限で動く。Aさんが見られないファイルには触れない
• Bさんがトリガー画面を開いても、Aさんのトリガーは一覧に表示されない。「トリガーが消えた」ように見える
• Aさんが退職してアカウントが停止されれば、そのトリガーは止まる。誰のトリガー画面にも出てこない

スプレッドシートをコピーして使い回している場合も同様で、コピー先のファイルにトリガーは引き継がれません（この挙動について公式ヘルプに明記された記述は見つかりませんでしたが、コピー後は自分でトリガーを作り直す必要があります）。テンプレートを配る運用をしているなら、ここは必ず手順書に書いてください。

ここで直らないなら、原因はアカウントではありません。作成者本人でログインしてトリガーが一覧に存在し、かつ実行数にも行が出ているなら、次は失敗の中身（手順3・手順4）を見ます。

手順3：承認（認可）を取り直す

実行数に行はあるが状態が「失敗」で、メッセージが「このアクションを実行するには承認が必要です（Authorization is required to perform that action）」なら、認可の問題です。

よくあるのは途中でコードに新しいサービスを足したケースです。最初はスプレッドシートの読み書きだけだったスクリプトに MailApp や UrlFetchApp を追加すると、必要なスコープが増えます。増えたスコープは自動では承認されないので、エディタから関数を1回手動実行して承認ダイアログを出し、承認し直す必要があります。手動実行で承認を通せば、以降のトリガー実行も通るようになります。

Google Workspace を使っている場合、管理者がアプリのアクセスを制限していて、ユーザー側では承認しきれないこともあります。承認画面でブロックされる旨が出たら、そこは管理コンソール側の設定です。

ここで直らないなら、原因は承認ではありません。手動実行が最後まで通るのにトリガー実行だけ失敗するなら、認可ではなく実行文脈（手順2）か、コードが「トリガー経由だと e（イベントオブジェクト）が想定と違う」といった実装側の問題です。

手順4：失敗が続いていないか、通知メールを探す

トリガーの実行が失敗したとき、Apps Script は画面上にエラーを出せません。実行しているのはユーザーの目の前ではないからです。公式ドキュメントには、代わりに noreply-apps-scripts-notifications@google.com から「Summary of failures for Apps Script」という件名のメールが送られる、と書かれています。本文には失敗したスクリプトと、そのトリガーを無効化または再設定するためのリンクが入っています。

ここで注意したいのが、よく言われる「失敗が続くとGoogleが自動でトリガーを無効化する」という話です。公式ドキュメントにその記述は見当たりません。書かれているのは「通知メールが届く」「そのメールから無効化できる」までです。つまり、トリガーが消えていたとすれば、失敗通知を受け取った誰かがリンクを押して止めた可能性のほうが高い、ということになります。心当たりがなければ、まずは作成者のメールボックスを「Summary of failures」で検索してください。

なお、この通知メールはトリガーを作った本人にしか届きません。作った人が通知メールを見ていない、あるいは退職している場合、止まったことは誰にも伝わりません。ここは後半でもう一度触れます。

ここで直らないなら、原因は無効化ではありません。実行数に「失敗」が並んでいるなら、それはコード側のエラーが本体です。エラーメッセージの行番号から順に潰してください。

手順5：時間主導型は「分単位で正確ではない」ことを知る

「毎朝9時に設定したのに、9時に動いていない」という相談は、そもそも壊れていないことがあります。公式ドキュメントは時間主導型（クロック）トリガーについて、スクリプトは1分ごとという細かさから、1か月に1回という粗さまで実行できると説明したうえで、時刻については「わずかにランダム化されることがある」と明記しています。日次トリガーで「午前9時〜10時」のように時間帯を選ぶと、Apps Script がその1時間の中から実行時刻を選びます。

つまり、時間主導型に「毎日9時00分ちょうど」を期待してはいけません。

• 9時台のどこかで動けばよい処理（日次集計・日報送信）には向いている
• 「9時00分に始まる会議の直前」「締め時刻ぴったり」といった、分単位の正確さが要る処理には向いていない
• 前の実行が長引いていると、次の実行とのあいだが想定より詰まったり開いたりする

分単位の正確さが業務要件なら、GASのトリガー単体ではなく、外部から時刻どおりに叩く仕組み（HTTP でウェブアプリを呼ぶなど）に寄せる判断が要ります。

ここで直らないなら、原因はタイミングではありません。実行数に毎日きちんと行が出ていて成功しているなら、トリガーは正常です。止まっているのはその先の処理です。たとえばGASでスプレッドシートからメールを自動送信する仕組みなら、宛先の取得条件やメール送信の上限側を疑います。

手順6：クォータ（上限）に当たっていないか数える

「午前中は動くのに、午後になると止まる」「月末だけ動かない」なら、まずクォータを疑ってください。Apps Script のクォータ｜Apps Script 公式ドキュメントに載っている主な数字は次のとおりです（消費者アカウント／Google Workspace の順）。

• スクリプトの実行時間：6分／回（両方とも同じ）
• トリガーの合計実行時間：90分／日／6時間／日
• 同時実行数：30／ユーザー
• トリガー数：20／ユーザー／スクリプト
• メールの受信者数：100／日／1,500／日
• URL Fetch の呼び出し：20,000／日／100,000／日

効いてくるのは「トリガーの合計実行時間」です。無料のGmailアカウントで、5分おきのトリガーが1回2分かかる処理を回していると、1日あたり約9.6時間ぶんの実行が必要になり、90分の枠は昼前に尽きます。午前中だけ動いて午後から沈黙する典型がこれです。Google Workspace でも6時間なので、重い処理を高頻度で回せば同じことが起きます。

「6分／回」も見落としがちです。処理が6分を超えると強制的に打ち切られ、書き込み途中のシートが中途半端な状態で残ります。行数が増えるほど遅くなる書き方（1行ずつ getValue() / setValue() する等）をしていると、ある日を境に突然この壁に当たります。シート自体が重くなっている場合は、スプレッドシートが重い・開かない原因と軽くする対処のほうを先に手当てしたほうが早いこともあります。

ここで直らないなら、原因はクォータではありません。実行数に「最大実行時間を超えました」も「サービスの呼び出し回数が多すぎます」も出ていないなら、上限には当たっていません。

毎週のように止まるなら、シートの使い方が限界に来ている

ここまでの6手順で、目の前のトリガーはたいてい復旧します。ただ、同じ相談が毎週のように起きているなら、直すべきはトリガーではなく運用のほうです。

GASのトリガーには、業務システムとしては決定的に欠けているものがあります。止まったことを、誰にも知らせないという点です。

• 失敗通知メールは作った本人にしか届かない。その人が見ていなければ、誰も気づかない
• 成功したときは何も起きない。だから「今日も動いた」ことを確認する手段が、実行数画面を自分で開くこと以外にない
• そして実行数画面を毎朝開いている人は、まずいない
• 結果、止まったことに気づくのは「あれ、今月の集計が来ていない」と誰かが言い出したときになる。数日〜数週間ぶんのデータが欠けた後です

作った本人が現役で、作った本人が毎日そのシートを見ているあいだは、この構造は問題になりません。問題になるのは、担当が替わったとき、シートが部署を越えて使われ始めたとき、処理が3本4本に増えたときです。属人化した自動化が静かに壊れるのは、だいたいこのタイミングです。

最低限の対処としては、成功したときにもログを残すことです。処理の最後に実行時刻を1行シートへ書き、その最終実行時刻が一定時間更新されていなければ別のトリガーから通知する——いわゆる死活監視を自分で足す。ただしこれは「監視のためのGASをもう1本作り、そちらが止まっていないかを誰が見るのか」という、終わらない入れ子に入っていきます。ここまで来ると、スプレッドシートとGASで組むこと自体が適正規模を超えています。スプレッドシート管理の限界とアプリ化の判断基準も合わせて読んでみてください。

正直に言うと、トリガーの不調そのものは今日の6手順で直ることがほとんどで、外注して直してもらうような話ではありません。相談していただきたいのは、その先です。「誰が作ったか分からないGASが何本も動いていて、止まっても分からない」状態をどう畳むか、どこまでをスプレッドシートに残してどこからを別の仕組みに移すか。GAS開発を外注する場合の費用感も含めて、現状を見てから一緒に決めたほうが早い領域です。Mihata では、いまの運用を壊さない範囲での設計から相談を受け付けています。

切り分けの順番だけ覚えておく

最後に、この記事の実務上の要点をもう一度だけ。

1. 実行数を先に開く。「行が無い」のか「失敗している」のかで、見るべき場所が半分になる
2. 行が無いなら、シンプルトリガーの制限・作成アカウント・時間のブレ・クォータの4つ
3. 失敗しているなら、承認の取り直しと、エラーメッセージそのもの
4. 時間主導型は分単位で正確ではない。ズレているだけなら直す必要はない
5. 止まったことに気づける仕組みが無いなら、それは設計の問題であってトリガーの問題ではない

複数人でシートを共有していて不具合が頻発しているなら、複数人で使うスプレッドシートが壊れる原因と対策のほうに根っこがあることもあります。トリガーだけを見ずに、シートの使われ方ごと確認してみてください。