ステップ1：実行ログでエラーの原因を特定する
スクリプトエディタの左メニューから「実行数」（英語環境では「Executions」）を開くと、過去の実行履歴が一覧表示されます。
- ステータスが「失敗」の実行をクリックしてログの詳細を展開する
Exception: Exceeded maximum execution timeが表示されていれば、タイムアウトが原因です- 別のエラーメッセージが表示されていれば、タイムアウト以外の問題（権限エラー、参照先シートの名前変更など）の可能性があります
タイムアウト以外のエラーは、コードを変えなくても解決できるケースがあります。「参照先のシート名が変わった」「アクセス権限が失効した」などは設定の修正で対応可能です。まずエラーメッセージを確認することで、「本当にタイムアウトなのか」「別の問題なのか」を自分で切り分けられます。
ステップ2：書き込み済みの範囲を確認し「どこで止まったか」を把握する
タイムアウト時点でシートに書き込み済みのデータは残ります。処理中だった未書き込みの内容は失われます。
- スクリプトが更新するシート（「PL」「実績」「予算」タブなど）を開く
- データが何行目まで入っているかを確認する。途中の行でデータが途切れていれば、そこでタイムアウトしたことがわかります
- 「ファイル」→「変更履歴」→「変更履歴を表示」から、当日のタイムスタンプ付きの変更履歴を確認できます
「どこで止まったか」の把握は、後述のエンジニアへの依頼にも直接使える情報です。スクリーンショットを撮っておいてください。
ステップ3：所要時間の傾向を確認する
スクリプトエディタの「実行数」画面では、各実行の所要時間も一覧で確認できます。
- 所要時間が上限の80〜90%に近い実行が続いている場合（個人用なら4分50秒〜5分30秒、Workspaceなら24〜27分）、近いうちにタイムアウトが発生するリスクがあります
- 所要時間が回を追うごとに伸びている場合、処理対象のデータが増え続けており、現在の設計では近いうちに対応が追いつかなくなります
この傾向を確認しておくと、「今すぐ対処が必要か」「まだ余裕があるか」を自分で判断できます。
ステップ4：トリガーの実行頻度をGUIで調整する
1日あたりの合計実行時間が上限に近づいている場合、トリガーの実行頻度を下げるだけで改善できます。
実行頻度を下げる手順：
- スクリプトエディタ左メニューの時計アイコン（「トリガー」）を開く
- 変更したいトリガーの右端にある鉛筆アイコンをクリック
- 「頻度」の設定を変更する（例：「15分おき」→「1時間おき」）
- 保存する
計算例： 1回8分のスクリプトが15分おきに実行されていた場合、営業時間8時間で32回 × 8分 = 256分。個人用アカウントの上限（60分）を大幅に超えます。1時間おきに変更すると8回 × 8分 = 64分となり、ほぼ上限内に収まります。
時間帯をずらす： 重いデータ処理を深夜0時〜早朝6時に動かすよう変更することも有効です。営業時間外に集中させることで、業務時間中の1日の予算を温存できます。
重複トリガーを削除する： 同じ関数に複数のトリガーが重複設定されているケースが意外と多くあります。トリガー一覧で同じ関数名が2つ以上あれば、片方を削除するだけで消費時間を大幅に削減できます。
エンジニアへの依頼：「バッチ化をお願いします」で終わらせない
GUIでの調整で改善しない場合、コードレベルの変更が必要です。ここが多くの非エンジニアにとっての壁ですが、何を渡せば依頼が最速で進むかを知っておくだけで、エンジニアの初動コストを大幅に削減できます。
コードに何が起きているかを理解しておく
パターンA：1行ずつ読み書きしているループ（最も多いケース）
Google Apps Scriptはスプレッドシートへの読み書きのたびにサーバーへのリクエストを発生させます。「1行読む→処理→1行書く」というループが繰り返されると、このリクエストが数千〜数万回に及び、実行時間のほとんどが通信待ちになります。Googleの公式ベストプラクティスガイドも、一括読み込み・一括書き込み（バッチ化）への変更を最優先の最適化として推奨しています。
改善幅はデータ構造やスクリプトの内容によって異なります。実行ログで所要時間が上限の大半を占めている場合、バッチ化で劇的に短縮できる可能性がありますが、実際の改善効果はエンジニアによるコード確認後に判断してもらってください。
パターンB：データ量が多すぎて1回の実行に収まらない
バッチ化でも不十分な場合、処理を複数回のトリガー実行に分割し、途中経過を保存しながら継続する仕組みが必要です。これはコードの設計変更が必要な案件で、稟議・工数見積もりを経てエンジニアに依頼するフローになります。
エンジニア依頼テンプレート
以下の項目を埋めてSlackかメールで送ると、「詳細を教えてください」という往復が1〜2回なくなります。
【Apps Script タイムアウト対応依頼】
スクリプト名・対象ファイル：
例）update_pl_report、Google Drive内「2026Q1_ボードパック.xlsx」のコンテナバインドスクリプト
発生しているエラーメッセージ：
例）Exception: Exceeded maximum execution time（実行ログのスクリーンショット添付）
どこで止まっているか（データ確認結果）： 例）シート「実績」のA列は3,847行まで書き込み済み。変更履歴では13:42に最後の書き込み確認
所要時間の傾向： 例）先月時点では4分30秒→今週は5分40秒に伸びている（実行数画面のスクリーンショット添付）
現在のトリガー設定： 例）15分おきの時間ベーストリガー（営業時間中のみ）
処理しているデータの概要： 例）経費明細CSV（月次約4,500行）をVLOOKUPで科目コードと紐付けてPLタブに転記
アカウント種別： 例）Google Consumer（gmail.com）／Workspace Business Starter
依頼内容： 例）バッチ化による実行時間の短縮。改善後も上限に引っかかるようであれば分割実行の設計も相談したい
この情報があれば、エンジニアはコードを見る前に「おそらくパターンAで、バッチ化で対応できる」か「データ量的にパターンBの設計変更が必要」かを判断できます。見積もりの精度も上がります。
Google Workspaceへのアップグレードで解決するか
1実行あたりの上限が6分から30分に延長されるため、多くのケースで改善します。ただし2点注意があります。
- 1日あたりの合計時間は6時間が上限です。 1実行が長くなれば、同じ本数のトリガーを回したときに1日の予算を早く消費します
- アップグレードはGoogle Workspaceの契約単位です。 スクリプト単体の設定変更ではなく、組織全体のアカウント種別の変更が必要です
合理的な順序としては、①GUIでトリガー頻度の見直し→②エンジニアへのバッチ化依頼→③それでも不十分な場合にWorkspaceへの移行、という段階的な対応を推奨します。
Apps Scriptとの相性が根本的に悪いケース
以下のような要件では、GUIの調整やコードの最適化でも対応が難しくなります。
- 5分未満の間隔でリアルタイムに更新し続ける必要がある
- 外部APIから10万行以上のデータを毎回取得する
- 20タブ以上にわたる複雑な変換を1つのスクリプトで順次処理する
このような要件が出てきた場合、「スクリプトをどう直すか」ではなく「処理をどのインフラで動かすか」というアーキテクチャの問題になります。AI分類・抽出・要約などの処理をサーバーサイドで行うツール（ModelMonkeyもその一つです）は、Apps Scriptのタイムアウト制限の外側で動作するため、スクリプトの書き直しを検討する前に選択肢として評価する価値があります。
よくある質問
Q. タイムアウト時に表示されるエラーメッセージは何ですか？
Exception: Exceeded maximum execution time が表示されます。実行ログ（スクリプトエディタの「実行数」）にも同じメッセージが記録されます。別のエラーメッセージが表示されている場合は、タイムアウト以外の原因を先に確認してください。
Q. Googleサポートに申請すれば実行時間を延長できますか？
できません。6分（個人用）・30分（Workspace）は一律の上限で、申請による個別引き上げには対応していません。
Q. トリガーを使えば制限を回避できますか？
個々のトリガー実行にも同じ時間制限が適用されます。ただし、処理を複数回のトリガー実行に分割する設計にすることは可能です。これにより実質的に長い処理をこなせるようになります。
Q. スクリプトが途中で止まった場合、データはどうなりますか？
タイムアウト時点でシートに書き込み済みのデータは残ります。処理中だった未書き込みの内容は失われます。「ファイル」→「変更履歴」→「変更履歴を表示」から、どの時点まで書き込まれたかを確認してください。タイムアウトで途中から止まった数字を「完了済み」として使用するリスクを防ぐためにも、四半期末の締め作業前には必ず確認することを推奨します。
Q. 年度末（3月）や四半期末に特に注意すべきことはありますか？
決算締め作業など、短時間に複数の大型スクリプトが集中するタイミングでは、1日あたりの合計時間（個人用1時間・Workspace6時間）を事前に計算しておくことを推奨します。「各スクリプトの平均所要時間 × 1日あたりの実行回数」を合算して上限内に収まるかを確認し、余裕がない場合は重い処理を深夜帯に移すか、実行頻度を落とす調整をGUIで行ってください。
Q. 自分のスクリプトが「遅い」かどうかはどう判断すればいいですか？
「実行数」画面で所要時間を確認し、上限の80%（個人用なら約5分、Workspaceなら約24分）を超える実行が続いている場合は要注意です。また、同じデータ量でも実行のたびに所要時間が伸びている場合、データ増加に対してスクリプトが想定以上のコストをかけていることを示します。このパターンはバッチ化で改善できる可能性が高く、エンジニアへの依頼テンプレートを使って確認してもらう価値があります。