下書き運用から完全自動送信へのステップアップ
前章では、誤送信リスクを回避するために「下書き作成（createDraft）」を用いた運用を解説しました。しかし、送信対象が数百件に及ぶ場合や、即時性が求められる通知システムにおいては、人間が「送信ボタン」を押し続ける運用は現実的ではありません。本章では、GmailApp.sendEmailメソッドを用いて、ボタン一つで複数の宛先にメールを一斉送信する機能を実装します。
ここで重要なのは、単にループ処理でメールを送るコードを書くことではなく、プロフェッショナルな開発者として「事故を起こさない安全装置」をシステムに組み込むことです。一斉送信システムは、一度実行されると取り返しがつかないため、二重送信の防止、送信確認のユーザーインターフェース、そしてエラー発生時の適切なハンドリングといった非機能要件の実装が、機能要件以上に重要となります。本章では、これらを網羅した堅牢なメール配信エンジンの構築手法を学びます。
sendEmailメソッドによる即時送信の実装
メールを即時送信するための基本メソッドは GmailApp.sendEmail(recipient, subject, body, options) です。引数の構造は前章の createDraft と全く同じですが、実行した瞬間にメールサーバーへリクエストが飛び、相手にメールが届く点が異なります。
一斉送信を行う場合、スプレッドシートから取得した二次元配列データを for ループや forEach メソッドで回し、各行のメールアドレスや差し込みデータを引数にセットして sendEmail を実行します。この際、本文の生成にはテンプレートリテラルや replace メソッドを活用し、宛名などを動的に差し替えるロジックは前章と同様です。
開発者は、このループ処理の中に、後述するステータスチェックやスリープ処理（待機時間）を組み込み、APIの制限やサーバー負荷を考慮した設計を行う必要があります。
フェイルセーフの実装：UIによる実行確認ダイアログ
スクリプトが誤って実行された場合や、ボタンをダブルクリックしてしまった場合に備え、処理開始前に必ずユーザーの意思を確認するダイアログを表示します。GASでは Browser.msgBox や SpreadsheetApp.getUi().alert を使用して、確認画面を実装できます。
例えば、const ui = SpreadsheetApp.getUi(); const response = ui.alert('確認', 'メールを一斉送信しますか？', ui.ButtonSet.YES_NO); と記述することで、「はい」「いいえ」のボタンがついたダイアログを表示できます。ここで response == ui.Button.YES の場合のみ処理を続行し、それ以外の場合は return で処理を中断するガード節を設けます。この数行のコードを追加するだけで、誤操作による誤送信事故のリスクを大幅に低減させることができます。これはUI/UXの観点からも必須の実装です。
冪等性（Idempotency）の担保：ステータス管理による二重送信防止
一斉送信システムにおいて最も恐れるべきは、システムエラーなどで処理が中断し、再実行した際に「既に送った人にもう一度送ってしまう」ことです。これを防ぐために、処理に「冪等性（何度実行しても結果が変わらない性質）」を持たせる設計を行います。具体的には、スプレッドシートに「送信ステータス」列を用意し、メール送信が成功した直後にそのセルに「送信済み」というフラグや送信日時を書き込みます。
スクリプトのループ処理の冒頭で、必ずこのステータス列を確認します。「送信済み」のマークがある行は continue でスキップし、未送信の行だけを処理対象とします。このロジックにより、万が一途中で処理が落ちても、再度ボタンを押すだけで「残りの未送信者」のみにメールが送られるリカバリー可能なシステムとなります。送信処理とステータス書き込みは、可能な限り近いタイミング（トランザクション）で行うことが鉄則です。
APIレート制限の考慮とUtilities.sleepの活用
GmailAppの送信機能には、短時間の大量リクエストに対するレート制限が存在する場合があります。ループ処理で間髪入れずに sendEmail を数百回呼び出すと、API側が過負荷と判断し、エラーを返す可能性があります。これを防ぐために、1通送信するごとに意図的に処理を一時停止させる Utilities.sleep(ミリ秒) を導入します。
例えば、Utilities.sleep(1000) をループ内に記述すれば、メール送信ごとに1秒間のインターバルを設けることができます。処理全体の時間は伸びますが、APIエラーによる中断リスクを下げ、確実性を高めるためには有効な手段です。開発者は、「速さ」よりも「確実性」を優先する設計判断が求められます。特に無料アカウント（1日100通制限）やWorkspaceアカウント（1日1500〜2000通制限） のクォータを意識し、大量送信が必要な場合は、数回に分けて実行する運用設計も考慮に入れるべきです。
try…catchによる個別エラーハンドリング
一斉送信の途中で、特定のアドレスが形式不備（無効なメールアドレスなど）でエラーになった場合、通常はその時点でスクリプト全体が停止してしまいます。これでは、その後に続く正しいアドレスへの送信も行われません。これを防ぐために、ループ内のメール送信処理部分を try...catch 構文で囲みます。
try ブロック内で sendEmail を実行し、もしエラーが発生した場合（catch）は、スクリプトを停止させるのではなく、スプレッドシートのステータス列に「エラー：アドレス不明」などのログを書き込み、continue で次の行の処理へ進むように実装します。これにより、一部のデータ不備があってもシステム全体を止めずに、可能な限り処理を完結させる堅牢なバッチ処理が実現します。
BCCを利用した一斉送信との使い分け
ループ処理で1通ずつ個別に送信する方法（To指定）は、宛名の差し込みなどパーソナライズが可能ですが、通数分のAPI実行枠を消費します。一方、内容が全員同じで宛名の差し込みが不要な場合は、options 引数の bcc プロパティを活用して、1通のメールで多数に一斉送信する方法も検討すべきです。
GASでBCC送信を行う場合、宛先リストをカンマ区切りの文字列に結合して bcc に設定します。これによりAPI呼び出しは1回で済み、処理も一瞬で終わります。ただし、BCC送信では個別の「送信成功/失敗」の判定が難しく、一人が受信拒否設定をしているとエラーメールが返ってくるなどの挙動管理が複雑になる側面もあります。要件（個別最適化の必要性）とリソース（API制限）のバランスを見て、ループ送信かBCC送信かを選択するアーキテクチャ設計能力が求められます。
送信ログの記録と管理者への完了通知
数百件のメール送信ボタンを押した後、画面の前で処理が終わるのをじっと待つのは非効率です。処理が完了したタイミングで、実行者（管理者）に対して「送信完了レポート」をメールやSlackで通知する機能を実装しましょう。
このレポートには、「送信成功件数」「送信失敗件数」「エラーが発生したリスト」などの集計情報を含めます。これにより、管理者は処理結果をひと目で把握でき、エラーがあった場合のみ対応するといった効率的な運用が可能になります。
また、スプレッドシートとは別に、送信ログ専用のシートやログファイルを作成し、いつ、誰に、どんな件名で送ったかの履歴を残すことは、後日のトラブルシューティングや監査証跡（Audit Trail）としても非常に重要です。
カスタムメニューと図形描画ボタンによるUI実装
開発者ではない一般ユーザーがこのシステムを利用する場合、スクリプトエディタを開かせるのは避けるべきです。スプレッドシートのメニューバーに独自のメニューを追加する SpreadsheetApp.getUi().createMenu や、シート上に「送信ボタン」として図形を配置し、スクリプトを割り当てる方法で、直感的な操作環境を提供します。
ボタンをクリックすると確認ダイアログが表示され、OKを押すとプログレスバー（簡易的なトースト通知 spreadsheet.toast など）が表示されながら処理が進む、といったUX（ユーザー体験）を設計することで、ツールとしての完成度が高まります。使いやすいツールはミスを減らし、現場への定着率を向上させます。
テスト運用と段階的なデプロイ
一斉送信機能のリリース直後は、予期せぬバグによる誤送信が最も怖いタイミングです。最初は自分のメールアドレスやチーム内の少数のアドレスだけをリストに入れた「テスト用シート」で十分に動作検証を行います。
また、本番データで実行する際も、いきなり全件に送るのではなく、最初の5件だけ送信して停止するような if (i >= 5) break; といった制限コードを一時的に入れてテスト送信を行い、内容と挙動に問題がないことを確認してから全件送信を行う「カナリアリリース」的な運用フローを推奨します。慎重すぎるほどの検証と確認手順を設計・マニュアル化することが、信頼される開発者の証です。