この業務で解決したいこと
同じフォーム回答を二度通知しないような仕事は、一回ごとの作業時間が短くても、担当者が変わったり忙しくなったりすると後回しになりがちです。課題は「作業を速くすること」だけではありません。いつ、誰が、どの条件で処理したかを追えるようにし、例外が出たときに人が戻れる状態を作ることが重要です。GASはGoogle Workspaceの中で、フォーム、スプレッドシート、Gmail、Drive、Calendarなどをつなげます。
最初から完全自動にせず、まずは記録や通知のように、実行結果を人が確認できる場所から始めます。業務の判断を見えないコードへ閉じ込めず、シートの列名、承認者、通知先、停止方法をチームで読める形に残してください。
自動化の全体像
この4段階のうち、最初に決めるべきは「どこで人が確認するか」です。送信、権限変更、金額確定、外部公開など取り返しのつきにくい処理は、GASが決めるのではなく、確認用の一覧や下書きを作る段階で止めます。
実装前にそろえるもの
- 入力元のシート、フォーム、フォルダ、メールの所有者
- 実行を許可するGoogleアカウントと、管理者の連絡先
- 正常処理と例外処理を分けるためのステータス列
- テスト用データ、テスト通知先、本番へ戻す手順
- 実行履歴を残す列と、失敗時に知らせる通知先
特に共有シートでは、列順や選択肢を無断で変えるとスクリプトが想定どおり動かないことがあります。列を追加する場合は、見出しを基準に取得する設計にし、変更を記録します。個人のアカウントだけで所有すると、異動や退職で止まるため、業務用の所有者と引き継ぎ手順を決めます。
手順：小さなテストから始める
1. 入力と出力を一つずつ決める
最初の試作では、入力を一つ、出力を一つに絞ります。たとえばフォーム回答をスプレッドシートに残し、担当者へメールを送るだけです。条件分岐や複数の通知先は、基本の流れが確認できてから足します。
2. 判断を表で見えるようにする
担当分けや優先度は、コードに直接書くより、管理用シートの対応表で管理すると変更を説明しやすくなります。誰がその表を更新できるか、空欄の場合は誰へ送るかも先に決めます。曖昧な入力は無理に振り分けず、共通窓口へ渡して人が判断するほうが安全です。
3. 送信済みと失敗を区別する
通知を送ったら、処理日時、処理ID、担当者、結果を記録します。この記録がないと、再実行したときに同じ連絡を二度送る危険があります。失敗時はエラー本文をそのまま転送するのではなく、対象行、発生日時、次に確認する場所を通知してください。
最小コードは「処理の入口」を理解するために使う
GASでは、関数を手動で実行するところから始め、問題がなければ時間主導トリガーやフォーム送信トリガーへ進みます。コードをコピーするだけではなく、どのスプレッドシートを読むか、どの列を更新するか、誰に送るかを自分の業務に合わせて確認します。
function runWorkflow() {
// 1. 入力を読む 2. 条件を確認する 3. 記録・通知する
// 重要な処理は、まず下書きや確認用シートへ出力する
}この段階では秘密情報をコードへ書き込まないでください。外部サービスのキーや個人情報を扱う場合は、権限、保管場所、閲覧者を別途設計します。Google公式の認可画面では、スクリプトが要求する権限を読んでから許可します。
よくある失敗と回避方法
| 起きること | 原因 | 先に入れる対策 |
|---|---|---|
| 通知が二重に届く | 再実行時の判定がない | 処理IDと送信済み列を残す |
| 担当者へ届かない | 入力が想定外 | 未分類は共通窓口へ送る |
| 突然止まる | 権限・所有者・列名の変更 | 所有者と変更手順を記録する |
| 失敗に気づけない | 実行履歴がない | 結果と例外を別の列に記録する |
GASは便利ですが、実行回数や処理時間などの制約もあります。大量のデータを一度に処理するより、対象を絞り、途中で止まっても続きから確認できる単位に分けます。
GASと他の方法の使い分け
Googleフォームの通知や簡単な承認は、まずGoogle標準機能で足りるかを確かめます。Google Workspace内で完結し、独自の条件や定期処理が必要ならGASが候補です。Google以外のSaaSを複数つなぐなら、Make、Zapier、n8nのような連携ツールのほうが管理しやすい場合があります。比較の基準は、機能の多さではなく、管理できる人、障害時の対応、監査したい範囲です。
まとめ
GASのエラー・二重実行を防ぐ方法｜運用で困らない設計では、処理そのものよりも、入力・判断・通知・人の確認を分けることが運用の土台になります。まずはテスト用データで一つの流れを動かし、記録、停止、例外通知を確認してから本番へ広げてください。
実装前に決める「再実行してよい単位」
エラー対策で重要なのは、例外を握りつぶすことではなく、同じ処理をもう一度実行しても結果が壊れない単位を決めることです。たとえば問い合わせ通知なら「フォーム送信ID」、請求書作成なら「注文番号」、期限通知なら「対象行ID＋送信日」を処理キーにします。処理開始時にキーを記録し、完了したキーは次回以降に送らない設計にします。
| 処理 | 重複の判断キー | 再実行時の期待結果 | 人が確認する点 |
|---|---|---|---|
| フォーム受付通知 | フォーム送信ID | 同じ担当者へ二通送らない | 送信先の誤り |
| シート行の期限通知 | 行ID＋対象日 | 当日分だけ一回送る | 日付・担当者の変更 |
| Driveのファイル名変更 | ファイルID＋命名規則版 | 同じ名前のまま終了する | 既存共有リンク |
| 外部API登録 | 自社側の受付番号 | 作成済みとして扱う | 相手側の登録状況 |
安全な再実行の手順
- 実行ログに「開始」「成功」「失敗」を分けて残します。失敗だけを対象にできるため、全件再実行を避けられます。
- 書き込みの前に、処理キーが完了済みかを確認します。Properties Serviceや管理用シートは小規模な運用でも十分です。
- 失敗時はエラー文だけでなく、キー・対象行・実行時刻・次に試す操作を残します。個人情報やトークンをログに含めません。
- 復旧は「一件だけ」「テスト宛先」「権限の弱い環境」で確認してから範囲を広げます。
失敗を通知する基準
| 状況 | 自動処理 | 通知先 | 次の判断 |
|---|---|---|---|
| 一時的な通信失敗 | 一回だけ時間を空けて再試行 | 実行ログ | 成功なら終了 |
| 権限・認可エラー | 再試行しない | 管理者 | 権限とスコープを確認 |
| 入力値不正 | 対象を保留にする | 入力担当者 | 値を修正して個別再実行 |
| 同じエラーが連続 | 自動化を停止する | 運用責任者 | 変更履歴・影響範囲を確認 |
この設計なら、障害時に「もう一度動かしてよいか」を勘ではなく処理キーとログで判断できます。GASの時間制限や実行失敗を完全になくすことはできませんが、二重送信・二重登録・無差別な再実行を避けることが、現場で使い続けられる自動化の条件です。