GASで定期実行する方法 トリガーの設定手順と時間指定・動かないときの対処法を解説

毎朝スプレッドシートを開いて集計する、月初に決まった形式でレポートを送る、受信したメールから必要な情報を転記する。こうした作業は手順が決まっているのに、誰かが手を動かさないと進みません。GAS（Google Apps Script）の定期実行を使えば、この「決まった時間に決まった処理を走らせる」部分を任せられます。

ただし、実際に設定しようとすると「トリガーの種類が多くて選べない」「時刻を指定したのにその時間に動かない」「しばらく動いていたのに突然止まった」といった場面に出くわします。いずれもGASの仕様を知っていれば説明がつくもので、あらかじめ理解しておけば回避できます。

本記事では、トリガーの仕組みと種類の整理から、画面操作での設定手順、コードでトリガーを作る方法、必ず押さえておきたい実行時間や回数の制限、そして動かなくなったときの切り分け方までを順番にまとめます。最後に、社内で長く運用するための設計についても触れます。

確認したいポイント	結論	詳細
GASで定期実行するには何が必要？	時間主導型トリガーの登録	エディタ左側の時計アイコンからトリガーを追加し、実行する関数と時間帯を指定するだけで開始できます。
実行する時刻は細かく指定できる？	時刻ではなく時間帯で指定	午前9時〜10時のように1時間単位の枠で指定するため、その範囲内のどこかで実行されます。
1回の実行にかけられる時間は？	6分が上限	6分を超えると処理が打ち切られます。範囲まとめての読み書きや、処理を分割する設計で回避します。
急に動かなくなる主な原因は？	権限の失効と割り当て超過	承認の切れ、1日の合計実行時間の超過、関数名の変更によるトリガーの不整合が代表的な原因です。

この記事でわかること

• GASの定期実行を支える「時間主導型トリガー」の仕組みと設定できる間隔
• 画面操作でトリガーを追加するまでの具体的な手順と各項目の意味
• ScriptApp.newTriggerを使って、コードからトリガーを作成・削除する書き方
• 6分の実行時間や1日あたりの合計実行時間など、先に知っておくべき制限
• 定期実行が動かないときの原因の切り分け方と、止まったことに気づく仕組みの作り方

▼ 自社の定型業務をどこまで自動化できるか整理したい方へ GASや生成AIを使った業務自動化の進め方、支援内容、導入までの流れをまとめた資料をご用意しています。 検討の初期段階でも構いませんので、まずは全体像の把握にご活用ください。 ＞ 資料請求はこちら

GASの定期実行を支えるトリガーの仕組み

GASで定期実行を実現しているのは「トリガー」という機能です。トリガーは、指定したイベントが起きたときに決まった関数を自動で呼び出す仕掛けで、定期実行に使うのはその中の一種類にあたります。まずは全体像と、選ぶべきトリガーの見分け方を整理します。

トリガーとは何をするものか

トリガーは「〇〇が起きたら、この関数を動かす」という登録情報です。スプレッドシートが開かれたとき、フォームが送信されたとき、そして指定した時刻が来たときなど、きっかけの種類はいくつかあります。定期実行で使うのは、時刻をきっかけにするタイプです。

トリガーが発火すると、GASはイベントオブジェクトを関数に渡します。中身はトリガーの種類によって異なり、フォーム送信なら回答内容、時間主導型なら実行時刻などの情報が入ります。定期実行の処理では、このイベントオブジェクトを使わないケースがほとんどです。

重要なのは、トリガーはスクリプト本体とは別に登録される情報だという点です。コードをいくら書いても、トリガーを設定しなければ自動では動きません。逆に、関数名を変えるとトリガー側の指定が外れて動かなくなります。

シンプルトリガーとインストーラブルトリガーの違い

GASのトリガーは大きく2種類に分かれます。1つはonOpenやonEditのように、決められた名前の関数を用意するだけで動くシンプルトリガーです。設定作業は不要ですが、承認が必要なサービスを呼び出せないという制約があります。

もう1つがインストーラブルトリガーで、画面またはコードから明示的に登録します。こちらは承認を伴うサービス、たとえばメール送信や外部へのリクエストも実行できます。時間主導型トリガーはこのインストーラブルトリガーに含まれます。

つまり、定期実行をしたい時点で選択肢はインストーラブルトリガー一択になります。「関数を書いたのに勝手に動かない」と感じる場合は、この登録作業が抜けていることがほとんどです。

時間主導型トリガーで設定できる間隔

時間主導型トリガーでは、分ベース、時間ベース、日付ベース、週ベース、月ベース、そして特定の日時という区分から実行タイミングを選べます。分ベースは1分、5分、10分、15分、30分といった間隔、時間ベースは1時間から12時間までの間隔が用意されています。

日付ベースを選ぶと、毎日どの時間帯に動かすかを1時間単位で指定できます。週ベースなら曜日と時間帯、月ベースなら日付と時間帯の組み合わせです。日次のレポート送信なら日付ベース、常時監視に近い処理なら分ベースというように、業務の性質で選び分けます。

ここで注意したいのが、指定するのが「時刻」ではなく「時間帯」だという点です。午前9時から10時を選んだ場合、その1時間のどこかで実行されます。9時00分ちょうどを求められる業務には向かないと考えておいてください。

定期実行が向いている業務・向かない業務

向いているのは、発生タイミングが予測でき、手順が固定されていて、多少の実行時刻のずれが許容される業務です。日次の売上集計、週次の未処理案件の洗い出し、月初の請求データ作成などが典型例になります。

逆に向かないのは、秒単位の正確さが求められる処理、1回で数分を大きく超える重い処理、そして人の判断が途中に挟まる業務です。GASには1回の実行時間に制限があるため、大量データを一度に処理する設計は最初から避けたほうが安全です。

また、フォーム送信やメール受信のような「起きたらすぐ処理したい」要件は、定期実行よりもイベント起点のトリガーや別のツールのほうが適しています。何分までの遅れなら許容できるかを最初に決めておくと、設計がぶれません。

画面操作でトリガーを設定する手順

ここからは実際の設定に入ります。画面からの登録は数分で終わり、コードを一行も書かずに定期実行を開始できます。エディタを開くところから、設定項目の意味、そして初回の承認までを順に確認します。

スクリプトエディタを開く

スプレッドシートに紐づくスクリプトなら、対象のスプレッドシートを開き、「拡張機能」から「Apps Script」を選びます。この方法で作られたスクリプトはコンテナバインド型と呼ばれ、そのファイルに付随します。ファイルを削除するとスクリプトも消える点は覚えておいてください。

特定のファイルに紐づけたくない場合は、GoogleドライブやApps Scriptのトップページから新規プロジェクトを作成します。こちらはスタンドアロン型で、複数のファイルを横断して扱う処理や、そもそもファイルを扱わない処理に適しています。

エディタが開いたら、定期実行したい処理を関数として書きます。動作確認のため、まずはエディタ上の実行ボタンで手動実行し、期待どおりの結果になることを確かめておきます。ここが通らないうちにトリガーを設定しても、原因の切り分けが難しくなるだけです。

トリガー画面から新規作成する

エディタの左側メニューにある時計のアイコンが「トリガー」です。クリックするとトリガーの一覧画面が開き、右下の「トリガーを追加」から新規登録できます。すでに登録済みのトリガーがある場合も、この画面で確認と編集ができます。

追加ダイアログでは、実行する関数、実行するデプロイ、イベントのソース、そして時間ベースの詳細を指定します。最後に保存を押せば登録完了です。一覧に行が増えていることを確認してください。

なお、トリガーはアカウントごとに登録されます。同じスクリプトを複数人が開いていても、自分が作ったトリガーしか一覧には表示されません。「設定したはずなのに一覧に出ない」場合は、別のアカウントで作業していないかを確認します。

設定項目の意味を押さえる

「実行する関数を選択」では、定期実行したい関数名を選びます。引数が必要な関数は選べないため、トリガーから呼ぶ関数は引数なしで完結する形にしておきます。複数の処理をまとめたい場合は、それらを順に呼び出す入口の関数を1つ用意する方法が扱いやすくなります。

「実行するデプロイを選択」は通常Headのままで構いません。Headは最新のコードを指すため、コードを修正すれば次回実行から反映されます。特定バージョンで固定したい事情がなければ、変更する必要はありません。

「イベントのソースを選択」で時間主導型を選び、続けてトリガーのタイプと時刻を指定します。ここで選んだ時間帯は、スクリプトのプロジェクト設定にあるタイムゾーンを基準に判定されます。日本時間で動かしたい場合は、タイムゾーンがAsia/Tokyoになっているかを確認しておいてください。

「エラー通知設定」も同じダイアログで指定できます。毎日通知、1時間おき、即時などから選べるので、業務の重要度に応じて設定しておきます。ここを既定のままにして、止まっていたことに数週間気づかなかったという例は珍しくありません。

初回実行時の承認を済ませる

メール送信やファイル操作を含むスクリプトでは、初回に権限の承認が求められます。自分のアカウントでエディタから一度手動実行し、表示される画面に沿って承認を済ませておきます。この作業をしていないと、トリガーが発火しても処理が失敗します。

承認画面で「このアプリはGoogleで確認されていません」と表示されることがありますが、自分で作成したスクリプトであれば詳細を開いて続行できます。社内の共有ドメインでは管理者の設定によって挙動が変わるため、進めない場合は情報システム部門に確認してください。

また、承認はアカウントとスコープの組み合わせに紐づきます。後からコードに新しいサービス、たとえば外部へのリクエストを追加した場合は、追加のスコープに対して再度承認が必要になります。

▼ 自社に合う自動化の進め方を相談したい方へ どの業務から着手すべきか、GASで組むべきか別の方法が良いかは、業務の実態によって答えが変わります。 現状をうかがったうえで、無理のない進め方をご提案します。 ＞ 相談予約はこちら

コードからトリガーを作成・削除する

画面操作で足りるケースがほとんどですが、細かい時刻指定や、条件に応じたトリガーの付け外しをしたい場合はコードから制御します。ここでは基本の書き方と、実務で必要になる削除処理までを整理します。

ScriptApp.newTriggerの基本形

コードからトリガーを作るには、ScriptAppというサービスを使います。ScriptApp.newTriggerに実行したい関数名を渡し、条件を指定するメソッドをつないで、最後にcreateで確定するという流れです。createを書き忘れると登録されないので注意してください。

時間主導型ならtimeBasedを挟み、その後ろに間隔や時刻の指定を続けます。たとえば6時間ごとに動かしたい場合はeveryHoursに6を渡し、毎週月曜の9時台に動かしたい場合はonWeekDayで曜日を、atHourで時刻を指定します。

なお、この登録処理そのものも一度は実行する必要があります。エディタから手動で実行するか、初回設定用の関数として用意しておき、必要なときだけ呼び出す形にしておくと管理しやすくなります。

日次・週次・月次の書き方

日次ならtimeBasedの後にeveryDaysを使い、atHourで時間帯を指定します。分単位まで寄せたい場合はnearMinuteを併用しますが、これも厳密な時刻指定ではなく目安として扱われます。週次はonWeekDay、月次はonMonthDayで日付を渡します。

複数の時刻に動かしたい場合は、その数だけトリガーを作ります。たとえば午前9時台と午後5時台の2回であれば、同じ関数に対して2つのトリガーを登録する形です。トリガーの数には上限があるため、増やしすぎには注意が必要です。

コードで作るメリットは、条件に応じて動的に変えられることにあります。処理の最後で「次はこの時刻に動かす」というワンタイムのトリガーを登録し、処理を分割して6分の制限を回避する手法も、この仕組みを利用しています。

トリガーの重複を防ぐ削除処理

コードでトリガーを作るときに最も起きやすい失敗が、実行のたびに同じトリガーが増えていく状態です。登録処理を何度か動かした結果、同じ関数が1日に何度も走ってしまい、メールが重複送信されるといった事故につながります。

対策は単純で、新しく作る前に既存のトリガーを削除することです。ScriptApp.getProjectTriggersで登録済みの一覧を取得し、対象の関数名と一致するものをdeleteTriggerで消してから、あらためて作成します。

既存のトリガーの内容を変更したい場合も、直接書き換えることはできません。一度削除して作り直すのが唯一の方法です。この前提を踏まえて、登録処理は必ず「全削除してから作成」という形にまとめておくと安全になります。

定期実行で必ず押さえたい制限

GASは無料で使える一方、実行時間や回数に明確な上限があります。設計段階でここを知らないと、運用を始めてしばらく経ってから突然止まるという事態になりかねません。主要な制限を数字で確認しておきます。

1回の実行は6分まで

最も影響が大きいのが実行時間の上限です。Googleの公式ドキュメントによると、スクリプトの実行時間は一般ユーザー向けアカウント、Google Workspaceアカウントのいずれも1回あたり6分と定められています（出典：Google「Google サービスの割り当て」）。

6分を超えると処理は途中で打ち切られます。数千行のスプレッドシートを1行ずつ処理するような書き方では、この上限に簡単に到達します。対策は、まず処理自体を軽くすることです。

スプレッドシートの読み書きは、1セルずつではなくgetValuesとsetValuesで範囲をまとめて扱うだけで大幅に速くなります。それでも足りない場合は、処理した位置をプロパティサービスに記録しておき、次の実行で続きから再開する分割処理を設計します。

トリガーの合計実行時間は1日90分または6時間

見落とされやすいのが、1日あたりの合計です。トリガー経由で動くスクリプトの合計実行時間は、一般ユーザー向けアカウントで1日90分、Google Workspaceアカウントで1日6時間が上限とされています。

ここに達すると「Service using too much computer time for one day.」という例外が出て、その日の残りは動かなくなります。1回の処理が3分かかるスクリプトを5分間隔で回すような設計は、一般アカウントでは早い段階で上限に触れます。

間隔を短くすればするほど安心というわけではない、という点が設計上の勘所です。5分間隔が本当に必要なのか、1時間に1回で足りないかを見直すだけで、上限の心配はほぼなくなります。

トリガーの数は20個まで

トリガーの登録数にも上限があり、1ユーザー・1スクリプトあたり20個までとされています。日次のトリガーをいくつも登録していくと意外に早く到達する数字です。

上限に近づいてきたら、複数のトリガーを1つにまとめられないかを検討します。1時間ごとに動く入口の関数を1つ用意し、その中で「今が何時なら何をする」と分岐させれば、トリガーは1つで済みます。

同時実行数にも制限があり、1ユーザーあたり30、1スクリプトあたり1,000が上限です。通常の定期実行で触れることはまれですが、短い間隔のトリガーと手動実行が重なる場面では意識しておくとよいでしょう。

実行時刻は厳密ではない

前述のとおり、時間主導型トリガーは指定した時間帯のどこかで実行される仕組みです。午前9時から10時を指定した場合、日によって9時05分に動いたり9時50分に動いたりします。

そのため、「9時ちょうどに送信したメールが届いている」という前提の業務フローは組めません。どうしても時刻を揃えたい場合は、余裕を持った時間帯に処理を走らせ、結果の配信だけ別の手段で制御するといった設計が必要です。

また、Google側の負荷状況によっては実行が遅れることもあります。数分の遅れで問題が起きる業務には、最初から別の手段を検討したほうが、後の手戻りを防げます。

▼ 「この処理はGASで組めるのか」から相談できます 実行時間の制限に引っかかりそうな処理、他ツールと組み合わせたほうがよい業務など、設計段階の判断からご相談いただけます。 ＞ 相談予約はこちら

定期実行が動かないときの原因と対処

設定したはずの処理が動かない場合、確認する順番を決めておくと原因にたどり着くのが早くなります。トリガーの登録状態、権限、実行ログ、そして制限。この4つを上から順に見ていきます。

まず実行履歴を確認する

最初に開くのは、エディタ左側メニューの「実行数」です。ここにはトリガー経由の実行も含めた履歴が残り、成功したか失敗したか、どんなエラーが出たかを確認できます。そもそも履歴に何も出ていないなら、トリガー自体が発火していません。

履歴があってステータスが失敗になっている場合は、エラーメッセージが原因の手がかりになります。どの行で止まったかも表示されるので、該当箇所の処理を手動で実行して再現するのが確実です。

履歴が空の場合は、トリガー画面に戻って登録の有無を確認します。関数名を後から変更していたり、別アカウントで登録していたりすると、この状態になります。

権限の承認が外れているケース

一定期間が経過したり、コードに新しいサービスを追加したりすると、承認が無効になって実行が止まることがあります。エラー内容に認可や権限に関する記述が含まれていれば、まずこれを疑います。

対処は、エディタから手動で一度実行し、承認画面を通し直すことです。数十秒で終わる作業ですが、担当者が異動していて誰も気づかない、という状態になりやすいので、運用担当を明確にしておく必要があります。

組織のセキュリティ設定が変更された場合も、同様に動かなくなることがあります。社内で一斉に複数のスクリプトが止まったときは、個別の不具合ではなく管理設定の変更を疑ってください。

実行時間や割り当ての超過

「Exceeded maximum execution time」は1回6分の上限、「Service using too much computer time for one day.」は1日の合計時間の上限に達したことを示します。前者は処理の書き方、後者は実行頻度の見直しが対処になります。

前者であれば、スプレッドシートへのアクセス回数を減らす、処理対象を絞る、分割実行に切り替えるといった手を打ちます。後者であれば、トリガーの間隔を広げるか、不要になった古いトリガーを削除します。

メール送信数など、サービスごとの割り当てに達している可能性もあります。1日あたりの送信先件数には上限があるため、一斉配信を含む処理では特に注意が必要です。

止まったことに気づく仕組みを作る

定期実行で最も怖いのは、エラーが出ることではなく、止まっていることに誰も気づかないまま時間が過ぎることです。トリガーのエラー通知設定は必ず有効にし、通知先が現在も確認されているアドレスかを点検しておきます。

さらに確実なのは、処理の成否を自分でログに書き出す方法です。専用のシートに実行日時と件数、結果を1行ずつ追記しておけば、いつから止まっているかが一目で分かります。件数が0の日が続いていれば、エラーが出ていなくても異常に気づけます。

try…catchで例外を捕まえ、その内容をチャットツールへ通知する構成にしておくのも有効です。通知が来る前提で運用すると、日々の確認作業そのものを減らせます。

▼ つまずいたところだけでも相談できます 「作ったスクリプトが止まってしまった」「エラーの原因が分からない」といった個別の課題も含めて、実務目線でご相談を承っています。 ＞ 相談予約はこちら

実務での活用シーンと設計のコツ

手順が分かっても、「自社の何に使うか」が決まらなければ前に進みません。定期実行が効きやすいのは、頻度が高く、手順が固定されていて、多少の遅延が問題にならない業務です。代表的なシーンと、作るときの勘所をまとめます。

スプレッドシートの集計とレポート送信

最も導入しやすいのが、日次や週次の集計です。複数シートのデータを1枚にまとめ、決まった書式に整えて関係者へメールするという流れは、GASの得意分野といえます。日付ベースのトリガーを1つ登録するだけで運用に乗ります。

作るときのコツは、集計結果を必ずシートにも残すことです。メールだけに出力すると、過去の推移を追えなくなります。シートに履歴を積み上げておけば、後からグラフ化することもできます。

Gmailの自動整理と添付ファイルの保存

特定の条件に合うメールを検索し、添付ファイルをドライブの所定フォルダに保存したうえでラベルを付ける、という処理もよく使われます。検索条件を絞り込んでおくことが、処理時間を短く保つポイントです。

処理済みのメールにはラベルを付け、次回の検索条件から除外します。この一手間を入れておかないと、同じメールを毎回処理してしまい、実行時間が日に日に伸びていきます。

外部サービスからのデータ取得

APIを持つ外部サービスからデータを取得し、スプレッドシートに蓄積する使い方もあります。取得のたびに全件を取り直すのではなく、前回取得時点からの差分だけを取る設計にすると、実行時間と呼び出し回数の両方を抑えられます。

前回の取得日時はプロパティサービスに保存しておくのが簡単です。なお、外部への呼び出しにも1日あたりの回数制限があるため、短い間隔で回す場合は事前に見積もっておいてください。

何度動いても壊れない設計にする

定期実行を安定させる最大のコツは、同じ処理が2回走っても結果が変わらない作りにしておくことです。ネットワークの一時的な不調などで処理が中断し、再実行が必要になる場面は必ず訪れます。

具体的には、追記の前に同じキーの行が存在しないかを確認する、処理済みフラグを立てる、といった工夫です。この設計にしておけば、障害時に「とりあえずもう一度動かす」という対応が安全に取れるようになります。

あわせて、自動化する前に業務手順そのものを見直しておくことも大切です。そもそも様式が統一されていない作業を自動化しても、例外処理が増えるだけになります。業務全体の整理の仕方は業務効率化アイデア55選の記事でもまとめています。

社内で長く運用するための体制づくり

自動化で多い失敗は、作った本人しか中身を知らず、異動や退職とともに使われなくなることです。動くものを作ることと、組織で使い続けられることは別の問題として考える必要があります。運用面で押さえたい点を整理します。

アカウントへの依存を減らす

GASの定期実行は、トリガーを登録したアカウントの権限で動きます。そのアカウントが退職などで停止すると、スクリプトは残っていても処理は止まります。個人アカウントで作った重要な自動化ほど、このリスクは見過ごされがちです。

対策としては、共有ドライブにスクリプトを置く、業務用の共有アカウントで登録する、複数人が編集権限を持つようにするといった方法があります。どれを選ぶかは社内のセキュリティ方針次第なので、情報システム部門と相談して決めてください。

命名規則とドキュメントを残す

関数名やプロジェクト名に一貫したルールを決めておくだけで、引き継ぎの負担は大きく下がります。「部署名_業務名_処理内容」のような形式にしておくと、一覧から目的のスクリプトをすぐ見つけられます。

あわせて、どの業務のどの工程を代替しているのか、トリガーは何時に動くのか、エラー時は誰に連絡するのかを1枚のメモにまとめておきます。コード内のコメントも、処理の内容ではなく「なぜそうしているか」を残すと後任者が判断に迷いません。

他のツールとの使い分け

GASはGoogle Workspaceの中では強力ですが、万能ではありません。Microsoft 365が中心の環境ならPower Automate、ローカルPCの操作が絡むならRPA系のツールというように、環境に合わせた選択のほうが結果的に安定します。

判断基準は、扱うデータがどこにあるかです。スプレッドシートやGmailが中心ならGAS、ExcelやOutlookが中心なら別の選択肢、という切り分けから始めると迷いが減ります。無理に1つのツールへ寄せる必要はありません。

人材面の課題をどう埋めるか

ツールが使えるだけでは、自動化は社内に広がりません。総務省の令和7年版情報通信白書では、日本企業がデジタル化に関して認識している課題として「人材不足」が48.7%と最も高く、他国と比べても突出していることが示されています（出典：総務省「令和7年版 情報通信白書」各国企業のデジタル化の状況）。

この状況で外部への丸投げを続けると、社内にノウハウが残らず、小さな修正のたびに費用と時間がかかる構造になります。一方で完全な内製化を目指すと、立ち上げに時間がかかりすぎます。現実的なのは、最初の数本を伴走しながら一緒に作り、社内に作れる人を育てる進め方です。

担当者を1人に任せきりにせず、部署内に最低2人は中身が分かる人を置くこと。そして、稼働中のスクリプトを棚卸しする機会を定期的に設けること。この2点だけでも、自動化が形骸化するリスクはかなり下げられます。社内での育て方はAI研修の目的と選び方をまとめた記事も参考にしてください。

まとめ

GASの定期実行は、時間主導型のインストーラブルトリガーを登録することで実現します。エディタ左側の時計アイコンから数分で設定でき、細かい制御が必要な場合はScriptApp.newTriggerを使ってコードから作成・削除することもできます。

設計段階で押さえておきたい制限は3つです。1回の実行は6分まで、トリガー経由の合計実行時間は1日90分または6時間まで、トリガーの登録数は1ユーザー・1スクリプトあたり20個まで。いずれも公式ドキュメントに明記されている数字です。

また、指定できるのは時刻ではなく時間帯である点も、業務設計に直結します。分単位の正確さが必要な業務は、最初から別の手段を検討したほうが手戻りを防げます。

そして、動くものを作ることと同じくらい、止まったときに気づける仕組みと、担当者が変わっても引き継げる状態を整えることが重要です。エラー通知、実行ログ、命名規則、アカウント依存の解消。この4点を最初から設計に含めておけば、定期実行は一過性の取り組みで終わりません。

▼ 定型業務の自動化を、社内に定着する形で進めませんか 株式会社ネクストスケールでは、業務の棚卸しから自動化の設計、社内への定着支援までを一貫してご支援しています。 何から手をつけるべきか整理したい段階でも構いません。まずはお気軽にご相談ください。 ＞ 相談予約はこちら