回答: 自作の自動化が止まるとき、必ずエラーになるわけではありません。 処理としては「成功」で終わっているのに、結果が届いていないことがあります。代表的なのは3つです。①送信の上限に達して、それ以降が送られない ②送った先が受け取れていないのに、送った側は成功として終わる ③条件に合わなくなって、何もせずに正常終了する。 ①と②は作りによって、③は通常、エラーとして記録されないため、気づくきっかけが「反響の連絡が来ない」という事後の形になりがちです。ただし、自動化が1本だけで、毎日人が結果を見ているなら、監視の仕組みは簡素にできます。
この記事でわかること
- 「エラーにならずに止まる」3つのパターン
- 送信の上限（公式の数値）と、残量を確認する方法
- ログの保持期間と確認方法（公式ドキュメントの記述）
- 気づくための仕組みを1つだけ入れるなら何か
- 監視を簡素化できるケース
エラーにならずに止まる3つのパターン
答え: 「失敗」ではなく「何もしなかった」という形で終わるケースです。パターン1・2は作り次第で、パターン3は通常、エラーになりません。
パターン1: 送信の上限に達する
メールやチャットへの通知には、1日あたりの上限があります。Google Apps Script からメールを送る場合、公式ドキュメントに記載された上限は次のとおりです。
| アカウント | メールの受信者数/日 |
|---|---|
| 一般ユーザー向けアカウント（gmail.com など） | 100 / 日 |
| Google Workspace アカウント | 1,500 / 日 |
出典: Apps Script サービスの割り当て（Google 公式）
公式ドキュメントでは、上限を超えるとスクリプトが例外（エラー）を出して実行が止まると説明されています。ただし、作りによってはエラーとして残りません。 例外を捕捉して記録せずに処理を続ける作りや、残量が足りないときに送信を飛ばす作りでは、未送信があっても正常終了することがあります。
上限は反響の件数ではなく、メールの受信者数で数えます。また上限はユーザー単位なので、同じアカウントで動くほかの処理の送信も合算されます。反響が少なくても、次のような場面で消費が増えます。
- 過去分の再送や、一括での再処理を走らせた
- 転送先が増えて、1件の反響で複数通送るようになった
- ループの条件を間違えて、同じ相手に繰り返し送った
残量は確認できます。公式ドキュメントには、1日の残りのメール受信者数を確認する方法として `MailApp.getRemainingDailyQuota()` が記載されています。処理の前に残量を見て、少なければ通知を出すという作りにしておくと、黙って止まる状態を避けやすくなります。
パターン2: 送った先が受け取れていない
通知の送信先（チャットのWebhookや、他システムの受け口）が変わっていたり、権限が切れていたりする場合です。
Apps Script の `UrlFetchApp` は、失敗を示す応答が返ると既定では例外を出します（UrlFetchApp リファレンス（Google 公式））。ただし、失敗応答で例外を出さない設定（`muteHttpExceptions`）にして、応答コードや本文を確認していない作りでは、未送信を成功扱いすることがあります。また、受け口が「受け付けた」と返しても、その先で最終的に届いたかまでは確認できない場合があります。送信側のログだけでは気づきにくいパターンです。
確認するには、送信側のログではなく受け取る側に届いているかを見る必要があります。両方を突き合わせない限り、送信側のログだけでは判断できません。
パターン3: 条件に合わなくなって何もしない
媒体のメール形式が変わり、抽出の条件に合わなくなったケースです。
- 件名の文字列が変わって、対象として拾われなくなった
- 本文のレイアウトが変わって、抽出した項目が空になった
- 送信元アドレスが変わって、フィルターを通らなくなった
このとき、スクリプトは「対象0件」として正常に終了します。例外は発生しないため、実行の成否だけでは気づけません。入力件数・抽出件数・必須項目が空だった件数をログに残しておくと、条件変更の影響を調べられます。形式変更への備えは反響メールのGAS自作で形式変更に備える確認ポイントで扱っています。
ログの保持期間を確認しておく
答え: 保持期間を確認しないままログに頼ると、調べたいときに残っていないことがあります。
Apps Script のログ記録（Google 公式）では、エディタに表示される組み込みの実行ログについて「軽量でリアルタイムにストリーミングされるが、短時間しか保持されない」と説明されています。Cloud Logging については「作成後数日間保持されるログを提供する」と記載されており、本番環境や複数ユーザーでの運用にはこちらが推奨されています。
Cloud Logging の保持期間は、ログバケットごとに決まっています。Cloud Logging の割り当てと上限（Google Cloud 公式）では、プロジェクトの `_Default` バケットの既定の保持期間は30日で、1日〜3,650日の範囲で変更できると記載されています。過去にさかのぼって調査できるかは、利用しているログと保持設定を確認してください。 処理件数をスプレッドシートなどに書き出しておく方法もあります。
保持期間を確認していないと、「おかしい気がするから、先月のログを見てみよう」と思ったときには残っていないことがあります。この論点はGASのエラーに気づかず反響を取りこぼす理由と対策でも扱っています。
気づくための仕組みを1つだけ入れるなら
答え: 「成功したこと」を定期的に報せる仕組みです。
エラーを検知する仕組みには、どの失敗条件を対象にするかの設計が必要です。それとは別に始めやすいのが、動いているときに動いていると分かる形です。
- 1日1回、「今日は◯件処理しました」という通知を出す
- 件数が0件の日も通知する（0件という通知が来ることが重要）
日次の件数報告は、異常に気づく手がかりになります。上限に達した日は件数がいつもより少なくなり、形式が変わった日は0件が続きます。
ただし、これだけでは送信先に届いていない状態（パターン2）や、本当に反響が0件だった日との区別はつきません。区別するには、入力件数・送信成功件数・受け取る側の記録を突き合わせる必要があります。また、報告が届かなかったときに確認する担当者と時刻も決めておいてください。報告を上限の対象になるメールで送る場合、上限に達した日は報告自体が届かないことがあります。
そのうえで余裕があれば、次を足してください。
- 処理前に送信の残量を確認し、少なければ通知する
- 受け取る側に届いているかを、週1回でも目視で突き合わせる
- 0件が2日続いたら通知する（曜日によって0件が正常な業態では、日数を調整する）
「必ず止まる」わけではない
自作の自動化が常に危ないという話ではありません。次の条件が揃っていれば、上の3パターンに気づきやすく、影響も小さくなります。
- 扱う媒体が限られていて、形式変更の影響が小さい
- 送信量が上限に対して十分小さい
- 毎日人が結果を見ていて、届かなければすぐ分かる
- 作った人が在籍していて、改修できる
逆に、この条件が崩れていくと気づきにくくなります。条件が変わったときに見直せるかどうかが、自作を続けられるかの分かれ目です。自作と専用サービスの比較材料は反響対応をAI+GASで自作する前の4つのリスクにまとめています。
監視を簡素化できるケース
- 自動化が1本だけで、毎日人が結果を見ている — 届かなければその日に分かるので、監視の仕組みは簡素にできます
- 処理件数が1日数件 — 同じアカウントのほかの送信も含めて上限に十分な余裕があれば、上限到達の監視は簡素にできます。ただし、送信先に届いているか（パターン2）と抽出条件（パターン3）の確認は必要です
- 止まっても業務が止まらない用途（集計の自動化など） — 気づくのが数日遅れても影響が小さいので、優先度は下がります
よくある質問
エラー通知を設定していれば足りますか
それだけでは足りないことがあります。本記事の3パターンは、作りによってはエラーにならないため、エラー通知では検知できません。「正常終了したが結果が届いていない」状態を見つけるには、処理件数の報告と、受け取る側の記録との突き合わせが必要です。
送信の上限はどうやって増やせますか
アカウントの種類で決まっているため、スクリプト側では増やせません。Workspace アカウントを使う、通知の送信先を1件にまとめる、メール以外の手段（チャットのWebhookなど）に分散する、といった方向になります。上限の最新値は公式の割り当てページで確認してください。
0件の日も通知すると、通知が多くなりませんか
1日1通です。多くはありません。0件の通知が来ないことが異常のサインになるので、0件を省略しないでください。0件を省略すると、「通知が来ない」が「0件だった」なのか「止まっている」なのか区別できなくなります。
受け取る側に届いているかを毎回確認するのは無理です
毎回は不要です。週1回、処理件数と実際に届いた件数を突き合わせるだけでも、ずれていれば気づけます。完全な自動検知を目指すより、頻度を落として続けるほうが実用的です。
まとめ
自動化が止まるとき、エラーになるとは限りません。送信の上限・届いていないのに成功扱い・条件に合わず0件の3パターンは、作りによってはログに異常として出ません。
始めやすいのは、「今日は◯件処理しました」という日次の報告です。0件の日も含めて通知すれば、異常に気づく手がかりになります。届いているかまで確かめるには、受け取る側の記録との突き合わせを組み合わせ、報告が来なかったときに確認する担当者と時刻も決めておいてください。
次に読むなら、自作の仕組みを止めずに運用できているかを点検する自作したメール転送、止めずに運用できていますか｜20項目の棚卸しチェックリストが近い内容です。
—
この記事を書いた会社
7plus株式会社 不動産会社向けの営業DX支援を行うITソリューションプロバイダーです。反響対応を即時化する「Mail2Link」「Mail2Link×AI」、ノーコード業務アプリ「BizBlock」の開発・提供に加え、Salesforce認定パートナーとして不動産特化型Salesforceパッケージの導入・定着コンサルティングも行っています。
詳しくはこちら → https://7plus.jp/
