【比較】GASの進捗表示、ダイアログ方式とトリガー連鎖方式はどちらを使うべき？VBAとの違いも整理

記事内には広告が含まれます

2026年8月14日

はじめに

前々回記事 gas-02ではHtmlServiceのモーダルダイアログ＋チャンク分割方式、前回記事gas-03ではセルに書き込むだけのシンプルな方式＋時間主導型トリガーの連鎖という、2つの異なるアプローチでGASの「6分の実行時間上限」を回避する検証を行いました。どちらも実機検証で完走を確認済みですが、実装のしやすさ・処理速度・制約はかなり性格が異なります。

今回はこの2方式を横並びで比較し、どちらをどんな場面で使うべきかを整理します。あわせて、そもそもVBAには存在しなかった発想（6分の壁を回避する、という発想そのもの）がなぜGASでは必要になるのか、要所でVBAとの違いにも触れながら解説します。

注意： 本記事は新しい実機検証を行うものではなく、gas-01〜gas-03で実際に確認した内容をもとにした比較・整理の記事です。数値や挙動の出典は各記事の該当セクションを参照しています。

GAS-01 シリーズ最初の記事

【検証】生成AIはVBAをGoogle Apps Scriptに変換できるか？Office Scriptsとの違いも解説

GAS-02 シリーズ2番目の記事

【検証】GASでHtmlServiceダイアログの進捗表示を実装する｜6分の実行時間上限も回避できた

GAS-03 シリーズ3番目の記事

【検証】GASでセルベースの進捗表示×時間主導型トリガーの連鎖で6分の壁を回避できるか

前回までのおさらい：VBAとの前提の違い

比較に入る前に、そもそもなぜGASにこの手の「壁を回避する工夫」が必要なのか、VBAとの前提の違いを整理しておきます。

項目	VBA	GAS
実行環境	ローカルPC（Excelプロセス内）	クラウド（Googleのサーバー）
1回の実行時間の上限	なし（理論上は無制限。フリーズ・強制終了のリスクはPC側の話）	あり（個人アカウント6分、Workspace30分）
進捗・完了通知	`MsgBox`・`UserForm`・ステータスバーが標準搭載	`Ui.alert()`／`toast()`はあるが呼び出しコンテキストに制約あり（gas-01参照）、プログレスバーは自作が必要
セル単位アクセスの重さ	ローカルなので比較的軽い	クラウド通信のため1回ごとのオーバーヘッドが大きい（gas-01で1000件がタイムアウト）

VBAでは「大量データを1つのマクロで最後まで回し切る」のがふつうで、遅くても待てば終わります。GASでは待っていても強制終了されるため、gas-02・gas-03はどちらもこの前提の違いに対応するために生まれた方式です。VBAに慣れた読者ほど、「なぜそこまでして時間を分割する必要があるのか」がピンと来にくいポイントなので、まずここを押さえておきます。

比較①：実装のしやすさ

項目	gas-02（ダイアログ＋チャンク分割）	gas-03（セルベース＋トリガー連鎖）
新規に覚える概念	`HtmlService`（HTMLファイルの追加、`google.script.run`）	`PropertiesService`、`ScriptApp`のトリガーAPI
追加するファイル	`.gs`に3関数＋新規HTMLファイル1つ	`.gs`に関数を追加するのみ（HTMLファイル不要）
制御シートへの追加項目	C1（チャンクサイズ手動指定・任意）	A1（進捗表示）・B1（キャンセル）・D1（再開行）
VBAでの近い操作感	`UserForm`をデザイナーで作る作業に近い（別ファイル・別画面の作り込み）	セルやステータスバーに直接書き込む、素朴な進捗表示に近い

VBAとの対比： VBAでプログレスバー付きのUserFormを作ったことがある人にとっては、gas-02の「HTMLファイルを別途作ってJavaScriptで制御する」という構成は感覚的に近いものがあります（デザイナー操作がコード記述に変わる点は異なりますが）。一方、gas-03はUserFormを作らずセルに直接文字列を書き込むだけなので、VBAでUserFormを使わずセルやステータスバーで簡易的に進捗を見せていた人には、こちらのほうが移行のギャップが小さく感じられるはずです。

実装コストだけで見ると、gas-03のほうが新規ファイルが不要な分、着手のハードルは低いといえます。ただし後述のとおり、gas-03には二重起動対策など気を配るべき点が別に存在します。

比較②：6分の壁への対処方法の違い

項目	gas-02	gas-03
分割の主体	クライアント側JavaScript（`google.script.run`で少量ずつ呼び出す）	サーバー側（GAS自身が経過時間を見て次のトリガーを予約）
分割の単位	チャンク（例：200件ごと）	安全マージン時間（例：5分ごと）
ブラウザ・タブを閉じた場合	❌ 処理が止まる（キャンセル・✕での強制クローズのどちらでも停止することを実機確認済み）	トリガーはGoogle側で予約されているため、ブラウザを閉じても進行する見込み（本記事執筆時点で厳密な検証はしていません）

VBAとの対比： VBAには「6分で打ち切られる」という概念自体が存在しないため、そもそもこの「分割して時間を稼ぐ」という設計判断そのものがVBA経験者には馴染みが薄い発想です。あえて近い状況を挙げるなら、VBAで大量データ処理中にExcelがフリーズするのを避けるためにDoEventsを挟んだり、処理を複数のマクロに分けて手動で順番に実行したりする工夫が近いかもしれません。ただしVBAのそれは「操作性・応答性」のための分割であり、GASの分割は「強制終了を回避するため」という、目的の切実さが異なります。

構造上の違いとして重要なのは、ブラウザとの結びつき方です。 gas-02はブラウザ上のダイアログが処理の指揮者（次のチャンクを呼ぶ）になっているのに対し、gas-03はGAS側（サーバー）が自分で次の実行を予約する自己完結型です。長時間画面を離れる可能性がある処理には、構造的にgas-03のほうが向いています。

比較③：処理速度の実測値

両記事の実測値を並べると、通信オーバーヘッドの効き方に違いが見えてきます。

gas-02（1000件・チャンクサイズ別）：

チャンクサイズ	更新回数	所要時間
200	5回	4:45
20	50回	8:09
10	100回	10:42

gas-03（安全マージン5分固定・データ量別）：

データ量	レグ数	所要時間
1000件	2レグ	9:37
2000件	5レグ	28:52

単純比較はできない（分割方式も分割単位も違う）ものの、傾向として、gas-02は「更新回数（＝通信回数）を増やすほど遅くなる」というトレードオフがはっきり出ているのに対し、gas-03は「レグ数が増えるほど、レグ間の待ち時間（1分30秒〜2分程度）が積み重なる」というオーバーヘッドがあることがgas-03の2000件テストで判明しています。どちらも「分割のしすぎ・回数の増えすぎ」が処理時間を押し上げる方向に働く点は共通しています。

VBAとの対比： VBAのローカル実行では、セル単位のループでも数千件程度なら数十秒〜数分で終わることが多く、「通信のオーバーヘッド」という概念自体がありません。GASで初めてこの手の速度実測をすると、同じ処理件数でもVBAよりずっと時間がかかることに驚くかもしれませんが、これはクラウド実行である以上避けられないコストです。gas-01で触れたとおり、getValues()/setValues()による一括読み書きへの書き換えは、GASでは実質必須の最適化と考えてください。

比較④：進捗表示の見え方・UX

項目	gas-02（ダイアログ）	gas-03（セルベース）
表示場所	モーダルダイアログ内のプログレスバー	制御シートのA1セル（文字バー＋％＋件数）
視覚的ななめらかさ	◎ HTML/CSSで自由に作り込める	△ 文字の繰り返し（■□）による疑似バーのみ（GASにはExcelのデータバー相当のAPIがない）
画面の占有	モーダルなので他のシート操作ができなくなる	しない。作業しながら他のセルも触れる
キャンセルの見た目	ダイアログ内の専用ボタン	シート上の図形ボタン（gas-01の方式を流用）

VBAとの対比： VBAのUserFormによるプログレスバーは、gas-02のダイアログ方式の体験にかなり近いです（モーダルで画面を占有し、視覚的になめらかに動く）。一方、VBAでもステータスバー（Application.StatusBar）に進捗をテキストで表示する簡易的な手法がありますが、これはgas-03のセルベース方式の感覚に近いといえます。「見た目のリッチさを取るか、他の作業を止めないことを取るか」という選び方は、VBAでUserFormかステータスバーかを選ぶときの判断基準とほぼ同じです。

比較⑤：制約・注意点

項目	gas-02	gas-03
固有の制約	ダイアログを閉じると処理が止まる（キャンセル・✕のどちらでも停止することを実機確認済み）	1日90分のトリガー合計実行時間クォータ、トリガー起動タイミングのばらつき（1秒未満〜2分程度）
実機で発覚したバグ	HIT件数リセット漏れ・完了時の表示崩れ（いずれも修正済み）	トリガー発火とボタン押下が重なると二重起動しHIT件数が壊れる（`LockService`＋確認ダイアログで修正済み）

VBAとの対比： gas-03の「1日90分クォータ」は、VBAには存在しない概念です。VBAはローカル実行のため、極端に言えばPCの電源が入っている限り何時間でも処理を続けられます（現実的には現実的な時間で終わらせるべきですが、上限そのものは存在しません）。GASの時間主導型トリガーには日次の合計実行時間という「見えない天井」があることを知らずにトリガー連鎖の設計をすると、想定外のタイムアウトに遭遇する可能性があるので注意が必要です。

「二重起動」問題も、VBAではあまり意識しない部類のバグです。VBAでも同じマクロを連打すれば同様の不整合は起こり得ますが、GASのトリガーはユーザーの操作と無関係に裏側で自動的に発火するため、「気づかないうちに2つ動いていた」という事故が起きやすい構造です。この種の非同期実行特有の罠は、VBAからGASに移行する際に意識しておくべきポイントの一つといえます。

結局どっちを使うべき？ユースケース別の使い分け

状況	おすすめ
進捗をリッチに見せたい・UserFormのような見た目にこだわりたい	gas-02（ダイアログ方式）
実装をシンプルに済ませたい・HTMLファイルを増やしたくない	gas-03（セルベース方式）
処理中も他のシート操作をさせたい	gas-03（セルベース方式）
処理中に画面を離れる・ブラウザを閉じる可能性がある	gas-03（セルベース方式）一択。gas-02はダイアログを閉じると処理が止まる
1回の処理が数分〜十数分程度で収まる規模	どちらでも可（実装のしやすさで選んでよい）
1回の処理が数十分〜に及ぶ可能性がある大規模データ	gas-03を検討しつつ、1日90分クォータの範囲に収まるか事前に見積もる
VBAのUserFormからの移行で、見た目の再現性を重視する	gas-02（ダイアログ方式）

どちらも「6分の壁」自体は回避できるので、最終的な決め手は実装コストとUXの好み、そして扱うデータ量が1日90分クォータに収まるかどうかになります。少量〜中量データの日常的なマクロ移行であれば、まずは実装が軽いgas-03から試してみて、見た目にもこだわりたくなったらgas-02のダイアログ方式に切り替える、という順番でも問題ありません。

よくある質問

Q. 両方の方式を1つのプロジェクトに共存させることはできる？

→ できます。gas-02の関数（showProgressDialog等）とgas-03の関数（startChainedTransfer等）は名前が重複しないため、同じスクリプトファイル内に共存可能です。ボタンをそれぞれ別に用意し、用途に応じて使い分ける運用も可能です。

Q. VBAのマクロをGASに移行するなら、どちらから覚えるべき？

→ 新規に覚える概念が少ないgas-03（セルベース＋トリガー連鎖）から着手するほうが取り組みやすいはずです。ただしPropertiesServiceやトリガーAPIといった非同期処理特有の概念に慣れる必要はあるため、「簡単」というより「ファイルが増えない分、迷う場所が少ない」という意味合いです。

Q. どちらの方式でも6分の壁を回避できるなら、そもそも工夫しない元のコード（gas-01）ではダメなの？

→ 数百件程度の小規模データであれば、gas-01のシンプルな実装でも問題なく完走します。6分の壁が問題になるのは、あくまで1000件を超えるような大量データを扱う場合です。データ量が少ないうちは無理に分割方式を導入する必要はありません。

まとめ

gas-02（ダイアログ＋チャンク分割）とgas-03（セルベース＋トリガー連鎖）は、どちらも実機検証で6分の壁を回避できることを確認済み
実装コストはgas-03のほうが軽い（HTMLファイル不要）が、VBAのUserFormに近い見た目を再現したいならgas-02が有利
処理速度は、gas-02が「通信回数」、gas-03が「レグ間の待ち時間」というそれぞれ異なるオーバーヘッドを抱える
gas-03には「1日90分のトリガー合計実行時間クォータ」「二重起動リスク」というVBAには無い、クラウド実行・非同期実行特有の制約がある
VBAには「6分で打ち切られる」という概念自体が存在しないため、この一連の工夫はGAS（クラウド実行環境）に移行して初めて必要になる発想であることを踏まえておくと理解しやすい

次回予告

今回サラッと触れたPropertiesServiceについて、CacheService・DocumentPropertiesとの使い分けを含めて別記事で掘り下げる予定です。VBAのSaveSetting/GetSettingに近い機能ですが、GASには3種類のスコープがあり、使い分けを整理する余地があります。