この記事は、住宅会社の業務改善・Web・DX担当者に向けた実務ガイドです。
「GASで通知や転記を自動化したいが、二重処理や権限、止まったときの対応が不安」という状況から、判断の順番と確かめることを示します。
読み終えたときに、小さな自動化を入力・処理・保存・通知に分け、再実行できる形で設計できる状態をつくるための手順が手元に残ります。
例えば記事制作の進行管理なら、確認待ちの原稿を一覧にし、担当者へ通知する工程から始められます。通知した後の監修と公開は人が判断する形です。すべてを自動化するのではなく、抜けや重複が生じる小さな作業に対象を絞ります。
顧客への送信や公開サイトの更新など、外部へ影響する処理は、社内の通知とは分けて設計します。テスト中に実際の宛先へ送らないよう、試験用の入力と出力先を用意します。
以下は原稿の確認依頼を通知する設計例です。GASを導入すれば必ずこのまま使えるという意味ではなく、実際のアカウント、保存先、管理権限に合わせた実装が必要です。
| 工程 | 決めること | 失敗への備え |
|---|
| 入力 | 記事ID・担当・確認状態 | 不足や形式違いを止める |
| 対象の抽出 | 未通知の確認待ちのみ | 公開済みや停止中を除外する |
| 処理 | 送る前に対象を再確認 | 同時実行の競合を防ぐ |
| 通知 | 社内の承認済み宛先 | 結果不明の再送を区別する |
| 記録 | 実行ID・結果・確認時刻 | 手動の確認と再実行につなぐ |
Google Apps Scriptには、実行時間やサービスの利用回数などの制限があり、アカウントの種類による差や変更の可能性があります。公式の上限を確認し、処理件数を分割する、途中の状態を残すなどの設計を行います。現在の上限値を記事に固定して万能な条件として示すのではなく、実装時に原典を確認してください。［1］
処理が途中で止まった場合、もう一度実行すると同じ通知が送られることがあります。記事IDと処理の種類などで識別し、処理済み、未処理、結果不明を分けます。完了記録を書く前に通知だけ成功した場合も想定し、何度でも安全に再送できると安易に保証しません。
コードだけでなく、何がきっかけで動くか、どの権限で実行されるか、入力先と出力先、停止手順を残します。機密情報や認証情報を公開記事のサンプルへ埋め込まないでください。引き継ぎ時は、ファイルを共有するだけでトリガーや権限も移ったと決めつけず、実際の動作を確認します。
自動化の効果は、手作業の時間だけでなく、失敗の監視や修正に使う時間も含めて評価します。小さな作業で運用を確かめ、仕組みを説明できる状態にしてから対象を増やします。
外部サービスとの連携など実装方法によります。利用料金、認証、送信する情報、実行制限を別途確認し、GASだけで無条件に利用できると考えないようにします。
会社の管理方針と引き継ぎを確認します。退職や権限変更で止まる可能性を踏まえ、運用主体と管理方法を先に決めます。
処理の種類によります。送信や登録が一部成功している可能性があるため、重複と結果不明を区別して再実行する設計が必要です。
出典参照日：2026-09-27。外部資料で確認した内容と、本稿の判断表・手順・設計例を区別しています。設計例や仮定の数字は実際の顧客実績を示すものではありません。
［1］Google Apps Script：Quotas for Google Services→利用上限、アカウントによる違い、変更可能性。処理フローはNAYUTAの設計例。
