Apps Script実行ログにService invoked too many times for one day: urlfetchと出た場合、同じ処理を何度も実行しても日次quotaはすぐには回復しません。まずエラー文が「one day」なのか「in a short time」なのかを確認し、UrlFetchの日次利用数、実行ユーザー、trigger・custom function・手動実行のどこから呼ばれているかを切り分けます。日次quota超過、短時間の呼出し過多、1回の実行時間上限、認証・アクセスエラーは別の問題です。
この記事はApps ScriptとGoogle公式資料に基づく診断・設計ガイドです。特定のscript project、外部API、Googleアカウントの実行履歴を調べたり再実行したりしていません。quota値は変更されるため、数字は2026-10-15に公式表で確認した参考値として記載し、エラー発生時は必ず現行ページで再確認してください。
目次
エラー文から失敗の種類を判定する
Apps Script公式quota資料は、service呼出しの上限とscript実行時間などを別の例外メッセージで示しています。文言を短縮せず、可能なら実行ログから全文を保存し、Execution historyで発生時刻・関数・実行種別・ユーザーを確かめます。
・Service invoked too many times for one day: UrlFetch：UrlFetchのdaily service quotaを超えた可能性。quota resetを待つだけでなく、呼出しの発生源と数を調べる。
・Service invoked too many times in a short time: UrlFetch：短時間に同serviceを呼び過ぎた可能性。Google資料は例として呼出し間にsleepを置く方法を挙げますが、sleepを加えるだけで日次quotaが増えるわけではない。
・Service using too much computer time for one day：1日の総実行時間quotaの問題。trigger実行では手動実行と異なる低い総runtime上限があると説明されています。
・Exceeded maximum execution time等：1回の実行時間上限を確認。Apps Script公式表ではscript runtimeはアカウント種別にかかわらず1実行あたり6分。
・Authorization is required、403、admin policy error：認可・組織ポリシーの分岐。UrlFetch日次quotaと混同しない。
・Script invoked too many times per second for this Google user account：custom functionの過剰再計算など、短時間にユーザーアカウントの実行数が集中する状況を調べる。
エラー文の違いは、次に見る場所を決めるための手掛かりです。日次quotaは当日中に上限へ達した回数、短時間制限は短い時間帯の集中、runtimeは処理にかかった時間です。長い実行で一日の時間quotaを使い切るケースとUrlFetch回数を使い切るケースは、同じ「一日」という語があっても別の制限です。原因が違えば、呼出し量を減らす、スケジュールをずらす、処理時間を短くする、認証を直すなど、必要な対策も変わります。
現行UrlFetch quotaの見方
2026-10-15に確認したGoogle Apps Script公式quota表では、URL Fetch callsはconsumer account（例：gmail.com）で20,000回/日、Google Workspace accountで100,000回/日と掲載されています。quotaはユーザー単位で、最初のrequestから24時間後にresetすると説明されています。アカウント区分、trial状態、関連Google serviceのquota等の条件が関係する場合があり、表の数値は将来変更・削減・撤廃され得るため、固定保証として扱わないでください。
この数値を使うときは、エラーを起こした実行主体のアカウントがconsumerかWorkspaceか、quotaを共有する実行経路が何かを管理者・プロジェクト所有者と確認します。別ユーザーで試すことをquota回避策として推奨するものではありません。trigger・custom function・web app等の実行ユーザーや認可方式が意図したものか、同一ユーザーに呼出しが集中していないかを調べます。
日次quotaのresetは毎日0時に一律リセットされるとは限りません。Google公式資料の記述は「first requestから24 hours後」です。従って、エラー時刻から翌日の深夜を機械的に次回可能時刻と決めないでください。最初のrequest時刻を記録できていなければ、quotaが戻る時刻は不明として扱い、処理を止めて公式表と実行履歴を確認します。
同じURL Fetch quota表には、response sizeやPOST size、header数、URL lengthなど一回ごとの制限も掲載されています。daily quota超過とは別なので、巨大responseや長いURLが原因で失敗しているのに、呼出し回数だけを減らすと解決しません。HTTP ステータス、response code、exception text、対象requestのサイズも記録します。
Apps Scriptの実行履歴から呼出し元を追う
Apps Script DashboardのMy Executionsで実行履歴を確認します。Google公式資料では、Apps Script dashboardからscript execution statusやhealthを確認でき、Runningで絞れば同時実行状況も見られると案内しています。対象期間を日次quota errorの発生前後にし、失敗した関数名、開始時刻、起動元、実行ユーザーを表にまとめます。
確認する呼出し元：
・時間主導triggerが短い間隔で重複している
・onEdit等のイベントが大量更新で何度も発火している
・custom functionが多数セルで同じAPIを個別に呼んでいる
・手動実行とtriggerが同じ処理を二重に実行している
・失敗した外部APIを再試行するloopに上限がない
・同じURLや同じデータを各行・各セルから繰り返し取得している
・別の利用者や別script projectも同じ実行ユーザーのquotaを使っている可能性
Apps Scriptの実行記録をすべてUrlFetch回数の会計表とみなさないでください。1実行の中でfetchが何回呼ばれたか、triggerが何回走ったか、1回の呼出しで何件のデータを取得したかを、コード・ログ・外部API側のアクセス記録と照合します。fetchAll()は複数requestをまとめて発行するmethodですが、各requestを1回のUrlFetch利用として数える前提で設計し、これだけで日次quotaを減らせるとは期待しないでください。
権限・domain policyが原因なら呼出しを減らすだけでは直りません。Google公式troubleshootingは、authorizationが必要な場合、script editorから関数を実行して再認可する場合があること、Google Workspace administratorが外部URLへのUrlFetchをallowlistで制限できることを説明しています。管理者のpolicyに反する形でendpointを迂回せず、対象ドメイン・OAuth scope・実行ユーザーを担当者と確認します。
呼出し数を減らすための設計
同じURL・同じ入力・同じ取得結果を何度も必要とするなら、重複取得を防ぐ設計を検討します。Google Apps ScriptのBest Practicesは、サービス呼出しを最小化し、Cache Serviceで実行間にresourceを一時保存する方法を示しています。cacheの値は指定期限まで必ず保存される保証がないため、cache missで再取得する処理、古い値の許容期間、更新条件を決めます。ユーザーごとに異なるデータを共通cacheへ混ぜないよう、cache scopeとkeyに注意します。
同じ処理内で多数のSpreadsheetセルを一つずつ読み書きしている場合、GoogleのBest Practicesは値をまとめて読み、memory上で処理し、一括で書くbatch operationを推奨しています。ただしこれはSpreadsheet serviceへの往復を減らす方法であり、外部APIを呼ぶUrlFetch回数を自動で減らすものではありません。外部APIに公式batch endpointがある場合に限り、仕様・payload上限・error handlingを確認して複数レコードを1 requestにまとめられるか検討します。
一件ずつ別URLを取得する処理であれば、単純にfetchAll()へ置き換えても、外部へ送るrequest数は同じです。並列化により短時間の呼出し集中や外部APIのrate limitを強める可能性があるので、同時実行、request間隔、再試行、応答失敗時の記録を制御します。Apps Scriptのquotaを維持できても、外部APIのrate limitや利用規約に反する場合があります。
custom functionを多数のセルから呼び出している場合は、1セルごとに同じUrlFetchを発行していないか調べます。入力範囲をまとめて処理するrange-aware function、シートのトリガーやmenuから一括更新する仕組み、手動で再計算する方式などが選択肢です。単にcustom functionをtriggerに移すだけだと、ユーザー単位の日次UrlFetch quotaを消費する可能性は残るため、呼出し数と実行ユーザーがどう変わるかを確認します。
再試行処理は、回数・待機時間・対象ステータス・全体deadlineを明示します。外部APIの429・5xxに対する再試行方針は相手APIの公式仕様を確認し、401/403や不正requestを無限再試行しないようにします。Apps Script側のUrlFetch quota errorが明確なら、同じ一回の再実行ではquotaが戻らない可能性が高いため、失敗recordを保存し、次に再開する時刻や処理範囲を決めます。
日次処理を分割し、安全に再開する
全件を一度に処理すると失敗時に同じレコードを再送しやすくなります。処理単位を決め、完了済みrecord IDを保存して次回は未完了だけから再開します。実行時間上限への本稿の設計案は、処理を小さなchunkへ分割し、Properties Service（新しいタブで開く）などへ現在位置を保存して、時間主導trigger（新しいタブで開く）で続きを実行する方式です。保存するstateの範囲とtriggerの実行主体・上限を確認し、具体的な構成は対象処理に合わせて検証します。これは6分などの1回実行時間limitへの対応で、日次UrlFetch quotaを増やす手段ではありません。
再開用stateには、開始batch、終了batch、最後に成功したrecord ID、失敗したrecord ID、次回予定時刻、request-id等の必要情報を保存します。個人情報やtokenを保存せず、処理の重複を避けられる一意キーを使います。失敗と成功の境界を保存する前にscriptが止まった場合に備え、更新処理が冪等か、同じrecordを再実行した時に重複作成・外部副作用が起きないかを確認します。
triggerを使う場合、日次quota・trigger runtime・実行回数の上限も同時に確認します。短い間隔で多数のtriggerを作るとUrlFetch回数を分散できるという意味ではなく、むしろ同じユーザーが消費を続ける可能性があります。triggerは対象処理の再開と実行時間分割のために使い、quota回避のために別ユーザーを使う設計にはしません。
長い処理をchunkへ分けると、各実行が6分上限を越えにくくなりますが、全体のUrlFetch呼出し数が同じなら日次quotaは同じく消費します。つまり「runtime errorを解決する分割」と「daily UrlFetch quotaを減らす重複削減」は別の改善です。処理を分割した後も、総呼出し数と外部API側のrateを測定し、必要なら有効なbatch endpointやcacheを追加します。
quota停止時の運用手順
-
実行ログからexception全文、発生時刻、関数、起動元、ユーザーを保存する。
-
“one day”・“short time”・“computer time”・authorization/admin policyのどれかに分類する。
-
Apps Script Dashboardで該当時間のMy Executionsと同時実行を確認する。
-
コードからUrlFetchApp.fetch / fetchAllの呼出箇所を列挙し、実行一回ごとの発行回数を数える。
-
trigger、custom function、manual run、別scriptからの重複起動を調べる。
-
公式quota表でアカウント区分、daily quota、reset条件、関連する一回単位制限を再確認する。
-
すぐ復旧できる認証・endpoint・短時間制限ならその原因だけ修正。daily quota超過なら重複再試行を停止して消費源を抑える。
-
URL/APIのbatch endpoint、Cache Service、不要な再取得削減を設計し、変更前後のrequest数を測る。
-
quota復帰後、まず少数recordで実行し、response・処理済みID・重複防止・次のscheduleを確認する。
-
成功後、処理件数と推定/実測UrlFetch数を記録し、残りを段階再開する。
Google公式quota表の数値が変わっている場合、エラーが起きた日に表示されている表を優先します。quota exceededの例外文は具体的な制限を示す場合があり、一次情報を確認することで、失敗の種類と上限を照合できます。quota値が不明、実行ユーザーが分からない、複数projectで共同消費している可能性がある場合は、断定せずApps Script ownerまたはWorkspace administratorへ必要なログを渡します。
呼出しを減らす判断表
・同じ結果を複数行から何度もfetch：cache可否、cache scope、更新期限、cache miss時の処理を設計。
・APIが公式batch endpointを提供：payload上限と部分失敗時の応答を確認し、複数recordをまとめる案を検証。
・同じSpreadsheetへセル単位で大量アクセス：Spreadsheetのread/writeを範囲単位にまとめる。UrlFetch削減とは分けて測る。
・fetchAll()で高速化したい：リクエスト数自体は減ると想定せず、短時間rateや相手APIの負荷を確認。
・trigger/custom functionが重複：起動源を減らす。ユーザーのquotaや実行主体がどうなるかを確認。
・6分超過だけが問題：checkpoint付きchunkへ分割し、再開時に副作用が重複しないか検証。
・daily UrlFetch quotaに到達：quota resetを待ちつつ、重複・無制限再試行を止め、次の実行に備えて総呼出し数を削る。
・権限・admin allowlistの問題：Workspace管理者へ認証scopeと対象hostを確認し、quota対策で迂回しない。
この判断表は一律の実装指示ではなく、実際のerrorとコードを見て選ぶ分岐です。外部APIの制限・batch仕様・response上限、Apps Script quota、Google Workspace policyを別々に確認します。
運用チェックリスト
□ エラー全文がdaily / short-time / runtime / authorization / policyのどれか記録した
□ 失敗した関数、起動元、実行ユーザー、時刻を特定した
□ 公式quota表のアカウント種別・値・reset基準・確認日を記録した
□ 一回の処理で発行するUrlFetch数をコードとログで確認した
□ trigger / custom function / 手動実行の重複を確認した
□ cacheやbatchの導入が実際に外部HTTP request数を減らすか説明できる
□ fetchAllを日次quota削減策として誤認していない
□ 失敗済みrecordを重複処理しないcheckpointを準備した
□ quota復帰後の試験範囲を小さく定めた
□ secret・token・利用者データをログへ出していない
この一連の確認で、利用者は「いつ再実行するか」「何を減らすか」「どの担当者へ依頼するか」を説明できます。日次上限に達したときは、再実行を続けるのではなく、呼出し元を止め、処理状態を保存し、quotaが戻った後の小規模再開を設計します。
公式資料
Google for Developers｜Apps Script Quotas for Google Services
https://developers.google.com/apps-script/guides/services/quotas（新しいタブで開く）
確認日：2026-10-15
Google for Developers｜Apps Script Troubleshooting
https://developers.google.com/apps-script/guides/support/troubleshooting（新しいタブで開く）
確認日：2026-10-15
Google for Developers｜Apps Script Best Practices
https://developers.google.com/apps-script/guides/support/best-practices（新しいタブで開く）
確認日：2026-10-15
Google for Developers｜UrlFetchApp reference
https://developers.google.com/apps-script/reference/url-fetch/url-fetch-app（新しいタブで開く）
確認日：2026-10-15