GASでGmailを自動送信する方法

※本記事はプロモーションを含みます

目次

Google スプレッドシートで管理している業務リストから特定のステータスになった行だけを抽出して連絡を入れたり、定期バッチ処理でエラーを検知した瞬間に管理者のアドレスへアラートを通知したりと、GAS（Google Apps Script）から自動で連絡を飛ばしたい場面は頻繁に出てきます。手動でGmailを開いて宛先を貼り付け、本文を整形して送信ボタンを押すという日々の反復作業は、件数が増えるほど転記ミスや宛先間違いを引き起こしやすくなります。なので、GAS メール 送信の仕組みを一度構築してしまえば、スプレッドシートの行追加や時間駆動型トリガーに連動させて無駄な確認工数をゼロに近づけることができます。

ただし、スクリプトによる自動送信は人間の目による最終確認を挟まずに外部へ直接メッセージが届く仕組みでもあるため、宛先の判定ミスやループ処理の暴走があると取り返しのつかない事故につながる危険性を孕んでいます。というのは、Googleアカウントの種別ごとに1日に送信できる通数の上限が厳密に定められているからです。なので、仕様を理解せずに大量のアドレスへ一括配信しようとすると、途中で処理が強制停止してしまい誰に送れて誰に送れていないのかが分からなくなるトラブルもよく起きます。ここでは、GmailAppを使った標準的なメール送信の基礎から実務で安全に運用するためのエラー制御や配信ログの記録まで、現場で本当に役立つ観点に絞って手順を確認しましょう。なお、無料枠や利用容量の表示は公式サイトでの表記が優先されます。

スプレッドシート更新やエラー監視の通知を自動化したい場面

実務でGAS メール 送信の仕組みを導入するケースとして最も多いのは、Google フォームからの回答受付通知、日次集計データの関係者への共有、そして外部API連携や深夜バッチ処理における例外エラーの即時アラートです。問い合わせフォームにお客様から回答があった際、スプレッドシートの最終行を取得して担当部署に即座に通知を飛ばせば、一次対応までの初動速度を大幅に引き上げることができます。ただし、従来のようにメールボックスやスプレッドシートを定期的にリロードして新着を確認する必要がなくなるので、見落としによる対応遅延を根本から防ぐことが可能になります。

夜間や早朝に自動実行している集計スクリプトがある場合、途中でスプレッドシートの読み込みエラーやタイムアウトが発生しても、担当者が翌朝出社して画面を見るまで障害に気付けないという事態が起こりがちです。なので、処理全体をtry-catch構文で囲み、例外が発生したcatchブロックの中で開発者宛てにスタックトレース付きのメールを自動送信するように設定しておきましょう。というのは、問題発生直後にスマートフォンなどで障害を把握し、始業前にリカバリーを行う運用体制を組めるからです。

さらに、請求書の発行リストや会員の更新期限リストなど、スプレッドシート上に期日と顧客情報が並んでいる帳票から期限の数日前にリマインドメールを自動送付する用途でも重宝されます。1件ずつ手作業で下書きを作って確認する作業は集中力を削ぎます。ただし、スプレッドシートの各セルから宛先、会社名、期限日を読み取ってテンプレート本文に流し込み、送信完了フラグを隣の列に書き込むフローを自動化できれば、月間数十時間の作業削減に直結します。このように、単にメールを送るだけでなく、特定のトリガーに反応して必要な相手に必要な情報だけを確実に届ける仕組みを構築しましょう。

GmailApp.sendEmailを使った基本送信処理

Google Apps ScriptからGmailを操作してメールを送信するには、標準で用意されている組み込みのGmailAppサービスを使用します。最もシンプルに1通のメールを送信する場合、宛先メールアドレス、件名、本文の3つの文字列を引数として渡すだけで完了します。ただし、特別な外部ライブラリを導入する必要もなく、スクリプト実行ユーザーのGmailアカウントを踏み台にして即座にメッセージが送信トレイから送り出されます。

function sendAlertEmail() { // 開発環境で動作テストを行います
  const recipient = "test@example.com";
  const subject = "テスト件名";
  const body = "テスト本文です。\nこちらは自動送信テストのメッセージです。";

  // 基本的なメール送信を実行
  GmailApp.sendEmail(recipient, subject, body);
}

この処理は、決まった管理者へ一定のメッセージを送る単体テストやエラーログの通知など、送信先と内容が固定されている場面で最も手軽に機能します。実行すると対象のアカウント宛てに即座にプレーンテキストのメールが届き、送信者のGmailの送信済みトレイにも全く同じメールが正常に記録されます。なので、スプレッドシートを開かずにスクリプトエディタ（開発画面）単体で動作確認ができるため、まずは自分のアドレスを宛先に設定して疎通を確認しましょう。

しかし、この最小コードをそのまま実務のスプレッドシート処理やループ処理に流し込もうとすると、いくつかズレが生じます。というのは、宛先の文字列が空文字または不正な形式だった場合にスクリプト全体がクラッシュしたり、本文内の改行コードが環境によって崩れたり、宛先がカンマ区切りで正しく指定されていないという問題が起きるからです。特にスプレッドシートのセルから宛先アドレスを動的に取得している場合、未入力の空行を読み込んだ瞬間にInvalid emailという例外エラーを吐いて実行が止まり、それ以降の行への送信がすべてスキップされてしまう事態に陥ります。

このズレを回避するためには、送信処理を呼び出す直前に宛先変数が空でないか確認しましょう。なので、文字列として最低限のメールアドレスの体裁を保っているかを正規表現などで検証する条件処理を挟む必要があります。本文に動的なパラメータ（顧客名や日付など）を埋め込む際はテンプレートリテラルを用いて安全に文字列を組み立てましょう。ただし、改行コードを適切にエスケープして意図したレイアウトで相手に届くよう配慮することが重要です。

1日の送信クォータ制限と大量配信における注意点

GAS メール 送信を実用化する上で絶対に避けて通れないのが、Googleがアカウントごとに設けている1日の送信上限（E-mail recipients per day）という制約です。スクリプトが無限ループに陥ってスパムメールをばら撒く事故を防ぐため、無料の一般Googleアカウント（@gmail.com）と有料のGoogle Workspaceアカウントとでは24時間あたりに送信可能な宛先数に大きな開きが存在します。

無料版のGoogleアカウントの場合、1日に送信できる宛先数は通常100通程度に厳しく制限されています。一方、Google Workspaceの有料ビジネスアカウントであっても通常は1日あたり1,500通が上限となっています。ただし、ここで重要なのはメールの通数ではなく宛先の数（Recipients）でカウントされるという点です。というのは、1通のメールに対してToに1人、Ccに2人、Bccに3人を指定して送信した場合、消費されるクォータは1ではなく合計6件分として差し引かれるからです。なので、複数人を同報送信する仕組みを作っていると、想定の何倍ものスピードで上限枠を使い切ってしまうことになります。なお、無料で登録しただけでは、全機能が使えるとは限りません。

もしこのクォータ上限に達した状態でGmailApp.sendEmail()を実行すると、Service invoked too many times for one dayという回復不能なエラーが発生し、その日は翌日のクォータリセット時間まで一切のメール送信が拒否されます。これが基幹業務のリマインド処理や問い合わせ自動返信のスクリプトで起きると顧客対応が完全にストップする重大な業務障害に発展します。なので、未然に防ぐためのチェック機能を組み込んでおきましょう。

このリスクを回避するために、実務スクリプトではMailApp.getRemainingDailyQuota()というメソッドを活用して送信を実行する前に必ず本日の残り送信可能数を確認しましょう。残りクォータが0、あるいは極端に少ない数値（例えば5以下など）になった段階で処理を中断し、スプレッドシート上にクォータ超過のため未送信という警告ステータスを残すように作っておきます。というのは、未送信の対象者を可視化でき、手動でのリカバリーや翌日への持ち越しがスムーズに行えるからです。数千件規模のメールマガジンや一斉連絡の用途にGASのGmail送信を流用するのは構造的に向いていないため、そうした用途では外部サービス（配信用API）の導入を検討しましょう。

誤送信と情報漏洩を物理的に防ぐテスト手順とバリデーション

メール送信自動化の開発において、最も恐れるべきトラブルは送信先の間違いとテストデータの誤送信による個人情報の流出事故です。スプレッドシートの行と列の指定が1つずれていたためにA社の請求情報をB社のメールアドレス宛てに送信してしまったり、本番用のスクリプトを改修中に誤って顧客の実アドレス宛てにテストですというダミー本文を一斉送信してしまったりする事故は現場で後を絶ちません。自動化スクリプトは人間と違って違和感を察知して止まってくれないので、設計段階で物理的な防壁を何重にも設けておきましょう。

第一の防壁は、開発および改修のフェーズにおいて送信先アドレスを強制的に開発者自身のテストアドレスへ上書きするデバッグフラグの導入です。スクリプトの先頭に定数としてテストモードの真偽値を定義しておきます。なので、テストフラグが有効な間はスプレッドシートからどのような宛先を読み込んでも、最終的にGmailApp.sendEmailに渡す宛先引数を開発者自身のアドレスに強制置換しましょう。ただし、本来送るはずだった送信先アドレスは件名や本文の冒頭に「[本来の宛先: user@example.com]」といった形で明記しておけば、誰宛てにどういう内容が送られる想定だったのかを安全に目視確認できます。

第二の防壁は、スプレッドシート上の宛先判定における厳密な条件分岐とバリデーションです。単にセルに文字が入っているかを確認するだけでなく、文字列が半角の有効なメールアドレス形式に合致しているかをチェックしましょう。なので、送信可否フラグ（例えば「送信対象」列に「OK」が入っているか）を厳格に照合します。空白行やフォーマット崩れの行に遭遇した場合はスクリプトを即時エラーで落とすのではなく、ログに警告を出力した上でその行のステータス列に「アドレス形式不正」と書き込み、次の行の処理へ安全にスキップする設計にしましょう。

また、Bccによる一斉送信を行う際にも落とし穴があります。GASのオプション指定でToを空にしてBccだけを渡そうとするとエラーになるので、Toに自身の管理アドレスを入れ、Bccに対象顧客を配列から結合して渡す工夫をしましょう。ただし、宛先リストの構築時にカンマ区切りの文字列結合を誤ると宛先同士が繋がって送信エラーになったり、最悪の場合ToやCcに混ざって顧客同士のアドレスが丸見えになったりする危険があります。というのは、複数人への個別送信であれば無理にBccでまとめず、1人ずつ個別のメールとして送信ループを回す方が宛先ごとの差し込み文面も制御しやすく事故のリスクを低減できるからです。

スプレッドシート連携を破綻させないステータス管理とリトライ設計

実務でGAS メール 送信を活用する場合、大半はスプレッドシートの行データをループで回しながら順番に送信していくバッチ処理になります。ここで最もありがちな失敗が、全行の送信が完了してから最後にまとめてスプレッドシートを更新しようとする設計です。GASには実行時間制限（通常のスクリプトで最大6分間）が存在するため、途中で実行時間オーバーになって強制終了したり通信エラーが発生したりすると、スプレッドシート上の記録が一切更新されません。なので、どこまで送信が完了したのかが分からなくなり、再実行した際に前半の対象者へ二重送信してしまうという最悪のトラブルを引き起こします。

この破綻を防ぐための鉄則は、1通送信が成功するごとにその行のステータス列へ即座に送信完了と送信日時を記録することです。毎回スプレッドシートへ書き込みを行うとAPIの処理コストが上がって実行時間が長くなる懸念はあります。ただし、安全性を最優先にする現場ではステータス列の即時更新が二重送信に対する最強の防壁になります。スクリプトが途中で止まったとしても次回実行時にはステータス列が空欄の行だけを拾って処理を再開できるので、何度実行しても同じ安全な結果になる性質を担保できます。