【GAS】フォーム通知が突然止まった：インストール型トリガーの復旧手順（原因5パターン）

皆さんこんにちは、ぼっち企業界隈のえ１７うです。

採用フォームの通知が止まる瞬間って、だいたい「一番忙しい日に限って」起きません？

朝イチでコーヒーを入れて、応募確認しよ〜って開いたら……「あれ、昨日から通知メールが1通も来てない」。

で、フォーム自体は回答が増えてる。スプレッドシートにも行が増えてる。でも通知だけ来ない。

はい、だいたいトリガーです。インストール型トリガーが止まってます（あるいは無効化されてます）。

これ、私の知人（採用担当・非エンジニア寄り）も同じ状況でした。最初は素人同然で「GAS？なにそれ、ガス代？」くらいのノリだったのに、試行錯誤で“止まり方のパターン”を掴んだ途端、復旧が30分で終わるようになって、再発もほぼゼロになりました。

このnoteは、まさにその「止まり方のパターン」と「復旧の手順書（Runbook）」を、採用担当の目線で“コピペ→検証→復旧→再発防止”まで落としたものです。

冒頭の注意事項（仮定した前提）

• あなたはGoogleフォームの回答をGoogleスプレッドシートに保存して運用している（または近い構成）。

• 通知はGAS（Apps Script）で送っている（もしくは以前送っていた）。

• トリガーはインストール型（手動で追加するトリガー）で動いていた。

• 権限は「閲覧のみ」ではなく、少なくともスプレッドシートの編集とApps Scriptの編集ができる。

• ブラウザはChrome推奨だが、他でも基本は同じ（UI表記だけ少し違う可能性あり）。

守る制約（規約/法務/セキュリティ）

• 各サービス規約の遵守（不正アクセスや権限昇格につながる手順は書きません）。

• 個人情報・認証情報（応募者情報、メールアドレス、トークン等）を記事に含めません。サンプルは必ず架空データ/プレースホルダにします。

• 操作はあなたが正当に編集権限を持つファイル上でのみ実施してください。

• 本手順は「再現条件が揃えば高確率で復旧する」ことを狙っていますが、Google側の障害や組織ポリシー（Google Workspace管理者設定）で制限される場合があります。

• このnoteは医療/法律/労務助言ではありません。採用運用の最終判断は自己責任でお願いします。

このnoteの目的（Before → After）

• Before：フォーム回答が来ているのに、通知メールが来ない。トリガーが止まっている/無効化されている気がする。原因が分からず焦る。

• After：詰まり（エラー/停止状態）を復旧し、再発防止（監視・ログ・予防策）まで完了して“明日も止まらない”状態になる。

対象読者（刺さる人）

• 採用担当（応募をGoogleフォームで受けている）

• 応募の見逃しが致命的（返信遅れ＝機会損失）

• GASは詳しくないが、コピペと手順書があれば実行できる

対象外（このnoteでは救えない人）

• Googleアカウント/Googleスプレッドシートを使わない

• 管理者/編集権限が一切ない（閲覧のみ）

• 組織ポリシーでApps Script/トリガー/メール送信が全面禁止（管理者に依頼が必要）

付ける成果物（この記事内で提供）

• 復旧チェックリスト（緊急時に上から潰すだけ）

• トリガー再作成手順（UI操作＋コードの両方）

• 監視用ログコード（ログシート＋監視トリガー＋通知）

目次

• 無料：10分で自己診断（Yes/No）

• 無料：インストール型トリガーの基礎（ここが詰まりの核心）

• 無料：通知が止まる原因5パターン（症状→当たり）

• 無料：今すぐ確認すべき3点セット（画面の見方）

• 無料：買うと何が手に入る？（成果物のサンプル）

• 有料：復旧Runbook（切り分け→復旧→検証）

• 有料：トリガー再作成（UI手順＋自動再作成コード）

• 有料：原因5パターン別の“刺さる復旧策”

• 有料：再発防止（監視・ログ・冪等性・運用ルール）

• 有料：Q&A（採用運用で実際に詰まる所）

• 最後のCTA

無料パート：10分で自己診断（Yes/No 10項目）

まずは「これ、自分の症状だ」を確信するための自己診断です。Yesが多いほど、この記事の手順が刺さります。

• Q1. フォームの回答は増えている（フォーム上で確認できる） → Yes/No

• Q2. 回答がスプレッドシートには記録されている（行が増えている） → Yes/No

• Q3. 以前は通知メールが来ていたが、ある日突然来なくなった → Yes/No

• Q4. 送信先メール（採用共有アドレス等）側の迷惑メールにも見当たらない → Yes/No

• Q5. Apps Scriptの「トリガー」画面を開いたことがある（または存在は知っている） → Yes/No

• Q6. スクリプトを編集できる（閲覧だけではない） → Yes/No

• Q7. 最近、フォーム/シート/スクリプトをコピーした、または所有者が変わった/共有設定を触った → Yes/No

• Q8. 最近、Googleアカウントのパスワード変更・2段階認証・端末入替・管理者ポリシー変更があった → Yes/No

• Q9. 直近、応募数が一気に増えた/一斉送信が増えた（=クォータに触れそう） → Yes/No

• Q10. 「何を見れば原因が分かるか」が分からず、とにかく焦っている → Yes/No

Q1とQ2がYesで、Q3もYesなら、かなりの確率で「トリガーの停止/無効化」が原因です。

無料パート：インストール型トリガーの基礎（ここが詰まりの核心）

そもそもトリガーって何？（採用担当向けに超ざっくり）

トリガーは、「フォーム回答が来たら、このスクリプトを動かしてね」という自動実行の予約です。

• フォーム回答（イベント）が発生する

• Apps Script（GAS）が呼ばれる

• 通知メールが送られる

「シンプル型」と「インストール型」の違い（重要）

• シンプル型：特定の関数名などで自動的に動く（ただし制限が多い/権限周りが弱い）

• インストール型：トリガー画面で“手動で追加”する。権限が明確で、運用に向く。採用通知はこっちが多い。

そして今回止まっているのは、ほぼインストール型トリガーです。

「止まる」とは具体的に何が起きている？

• トリガーが削除されている（存在しない）

• トリガーが無効化されている（連続失敗などで停止）

• トリガーは存在するが、実行時にエラーで落ちている（結果として通知が来ない）

• トリガーは動いているが、メール送信がクォータ/制限で失敗している

仕組みを絵で見る（全体像）

Googleフォーム回答が送信される回答スプレッドシート行が追加されるApps Script通知処理（GAS）ログ/監視もここインストール型トリガー「来たら動け」通知メール採用担当へここが止まると全部止まる

図1：フォーム通知の全体フロー。回答がシートに来ているのに通知が来ないとき、トリガー周辺が疑わしい。

無料パート：通知が止まる原因5パターン（症状→当たり）

「原因は1つ」と思うとハマります。現場では、止まり方がだいたい5つに分類できます。

パターン1：権限（認可）が剥がれた／再承認が必要になった

• ありがちな状況：パスワード変更、2段階認証、端末入替、アカウント切替、組織ポリシー変更など

• 症状：トリガーは存在するが実行が失敗。実行履歴に「承認が必要」「Authorization required」系のエラーが出る

• 当たりの取り方：トリガーの「実行ログ」を見ると分かりやすい（無料パート後半で見方を説明）

パターン2：スクリプトの例外（エラー）が連続してトリガーが無効化された

• ありがちな状況：想定外の入力、空欄、特殊文字、シート名変更、列の順番変更、通知先の形式ミス

• 症状：トリガーが「無効」っぽい。実行が一定期間ない。過去ログに同じエラーが連発

• 当たりの取り方：エラー文を“分類”すると復旧が早い（有料部分で分類表を渡します）

パターン3：クォータ（送信数/実行時間）に当たって失敗している

• ありがちな状況：応募が急増、通知を複数宛先に送っている、添付/長文が多い、処理が重い

• 症状：ときどき届く/届かないが混在。ある日からピタッと止まることもある

• 当たりの取り方：失敗のエラーが「Service invoked too many times」「Exceeded maximum execution time」系

パターン4：フォーム/シート/スクリプトをコピー・移管して“ひも付け”がズレた

• ありがちな状況：テンプレ運用でコピー、部署移管、担当変更、ファイル整理で置き換え

• 症状：新しいシートでは通知が来ない。旧シートにだけ何かが残っている

• 当たりの取り方：トリガーは「コピーされない/ズレる」ことがある。どこにトリガーが付いているかが鍵

パターン5：Google側/組織側の変更（管理者制限・サービス状態）

• ありがちな状況：Workspace管理者がApps Scriptや外部送信を制限、監査強化、またはGoogle側の障害/一時不調

• 症状：今まで動いていたのに突然。自分の設定変更の心当たりがない

• 当たりの取り方：管理者設定/サービスステータスの影響を疑う（ただし本noteは“不正回避”はしません。正攻法だけ）

どのパターンか一瞬で把握する“診断フロー図”

回答はシートに来ている？（Q1/Q2がYes）No：そもそも連携が壊れてるフォーム→シート連携を確認Yes：次へ（トリガー周辺）通知だけ止まっているYes/Noトリガーは存在する？Apps Script → トリガーNo/YesNo：パターン4（コピー/移管）濃厚トリガー再作成が最短（有料で手順をRunbook化）Yes：実行ログを見る権限/エラー/クォータ→パターン1〜3,5

図2：原因の切り分けフロー。最短ルートは「シートに来てるか」→「トリガーあるか」→「実行ログで分類」。

無料パート：今すぐ確認すべき3点セット（画面の見方）

ここは無料で全部出します。ここを理解するだけで「何も分からない」状態から抜けます。

確認①：スプレッドシートに回答行が増えているか

• 増えている → フォーム→シート連携は生きている（通知側の問題）

• 増えていない → まずフォーム側の「回答の保存先」が違う可能性（このnoteの主戦場は“増えているのに通知が来ない”です）

確認②：Apps Scriptの「トリガー」画面に、該当トリガーがあるか

だいたいの人がここで詰まります。「トリガーの画面どこ？」問題。

スプレッドシート（回答が入るシート）拡張機能 → Apps Scriptスクリプト画面へApps Script左メニュー「トリガー」（時計アイコン）

図3：「トリガー」画面への行き方（迷子対策）。

この「トリガー」画面に、フォーム送信（またはスプレッドシートのフォーム送信）に紐づくトリガーが見当たらない場合、かなりの確率でトリガーが削除/コピーで消失しています（パターン4寄り）。

確認③：Apps Scriptの「実行」や「実行ログ（実行履歴）」で失敗していないか

• 成功が並んでいるのに通知が来ない → 通知先/メール仕様/迷惑メール/条件分岐が怪しい

• 失敗が並んでいる → エラー文を読む。だいたいパターン1〜3へ分類できる

• 実行履歴がそもそも増えていない → トリガーが動いていない（削除/無効化/対象イベント違い）

ここまでで「原因の当たり」を付ける準備ができました。

無料パート：買うと何が手に入る？（成果物のサンプル）

このnote（1万円）の価値は、“知識”より手順書です。忙しい採用担当が欲しいのは、だいたいこれ。

• 「何をどの順番で見ればいいか」が明確

• エラー文を見た瞬間に「次に押すボタン」が分かる

• 復旧後に「また止まる」を潰せる（監視がある）

成果物①：復旧チェックリスト

成果物②：監視ログの出力イメージ

「今、動いてるの？」「最後に動いたのいつ？」を、採用担当でも一目で分かるようにします（応募内容はログに残さない設計）。

• 日時

• ステータス（OK/ERROR/WARN）

• 種別（FORM_SUBMIT / WATCHDOG）

• メッセージ（マスク済み）

成果物③：トリガー再作成の“自動化コード”

有料部分では、トリガーをUIで作り直すだけでなく「スクリプト側から安全に作り直す」コードも渡します。たとえばこんな感じの関数（これは断片、核心は有料でフル提供）。

// ※断片サンプル（有料部分でフル版と運用手順を提供）
function recreateTriggers_() {
  // 既存トリガーを整理 → 必要トリガーを作成 → ログに残す
  // （誤爆防止の安全策・権限確認・監視もフル版に含めます）
}

ここまでで「自分の症状っぽい」「買えば手順で直せそう」が見えたはずです。

次からは、実際に止まっているトリガーを復旧して、明日も止まらない状態にするマニュアルを渡します。

ここから先は有料部分です。