Google Sheetsの更新からメールを送る場合、AIへ送信可否や宛先を決めさせず、Sheetの明示fieldと条件で対象を絞ります。基本は「Trigger→条件判定→本文作成→送信→送信結果を記録」です。誰に何をいつ送るかを固定し、AIは必要なら内容の要約や表現調整だけを担当させます。
目次
Triggerの違いを先に確認する
MakeのGoogle Sheets modulesにはWatch New RowsやWatch Changesがありますが、Watch ChangesはSheetsアプリで利用者が行ったcell変更を監視し、API/script経由の変更や新規rowの追加を検知しない条件が公式docsに記載されています。新しいrowを起点にするのか、既存cell変更を起点にするのか、定期検索にするのかを先に選びます。moduleの現在の制約やtrigger設定は利用前に公式documentationで再確認してください。
表は横にスクロールできます
| 起動条件 | 向く場面 | 事前に確認すること |
|---|---|---|
| 新しいrow | 申請受付、問い合わせ通知 | blank row、重複row、列header |
| cell変更 | status更新、承認完了 | 変更者、対象column、API更新の扱い |
| 定期チェック | 未送信rowの定期処理 | interval、過去分、実行上限 |
| 手動実行 | 担当者の承認後送信 | 実行者、対象選択、二重実行 |
Triggerが想定どおりに動かない場合、AIやメールmoduleの問題と決めつけず、Sheetの更新経路とtrigger仕様を切り分けます。Google Sheets integrationからGmailまたはEmail actionへ接続できる例もありますが、宛先や送信権限は接続accountとworkspace policyで異なります。
送信条件と宛先を固定する
To、subject、氏名、案件番号などは構造化columnから読み、空欄や形式不正を先に検出します。AIに宛先を抽出させたり、自由記述を読んで送信先を推測させたりしません。たとえばstatusがready、emailが有効、consent fieldが条件を満たす、sent_atが空の場合だけ送るなど、条件を表にします。
表は横にスクロールできます
| Field | 役割 | 確認 |
|---|---|---|
| record_id | 送信対象を一意に特定 | 空・重複を検査 |
| recipient | 宛先 | approved columnから取得 |
| status | 送信可否 | allowed valueのみ |
| message source | 本文に使う情報 | verified fieldを限定 |
| sent_at / message_id | 送信結果 | 成功後に書き戻す |
| error | 要確認の理由 | retry前に分類 |
宛先不明、複数宛先、個人情報の共有範囲が不明なrowは送信せず、担当者の確認queueへ送ります。Sheetの閲覧者が変わった場合も、メールに入れる情報が引き続き適切かreviewしてください。
二重送信とloopを防ぐ
メール送信後にsent statusを書き戻すと、その書き戻しが再びtriggerになることがあります。trigger条件から処理済みrowを除外するか、処理IDを記録して同じイベントの二重実行を抑止します。メール送信の成功とSheetへの書き戻しの間で障害が起きる場合、同じメールを再送するのか、送信済み履歴を確認してから記録を直すのかを設計します。
表は横にスクロールできます
| 状態 | 意味 | 次のAction |
|---|---|---|
| ready | 明示条件を満たし未送信 | 送信前validation |
| processing | 一つの実行が処理中 | 重複runnerを抑止 |
| sent | 送信成功を確認済み | trigger対象から除外 |
| error | 不正宛先、送信失敗等 | 原因別に再試行 |
送信APIが成功を返しただけで受信者が読んだと断定しません。受信拒否、迷惑メール、配送遅延など、どの状態まで自動化で把握できるかを区別します。
AIを本文に使う範囲
AIは自由記述から要点を短くする、指定toneへ整える、structured fieldを読みやすく並べる用途に使えます。日付、金額、契約条件、受付番号は元Sheetから差し込み、AIが書き換えないようにします。本文草案には元データの参照IDを残し、送信前に重要fieldを原文と比較します。
AIが本文生成に失敗した場合は送信を止めるか、承認済み定型文へfallbackするか決めます。モデル出力にない事実、期限、保証、謝罪の約束などを加えさせず、個別判断が必要な問い合わせは人へ回します。送信内容をAIに任せるほど、review、audit log、recipient consentの条件が重要になります。
実装手順
-
Sheetの必須column、unique ID、status value、送信条件を定義する。
-
test spreadsheetとtest recipientを用意し、実在顧客への送信を止める。
-
triggerを単独で試し、どの更新方法を検知するか記録する。
-
filterで宛先、status、sent_at、必須dataを検証する。
-
templateまたはAI draftを生成し、変動値を元Sheetと照合する。
-
test recipientへ一通だけ送り、message IDとsent timestampを記録する。
-
同じrowを再実行し、duplicate送信されないことを確認する。
-
失敗rowが誰に通知され、どう再処理されるか確認する。
公開前のQA
-
対象rowが一件だけ選ばれる条件を説明できる。
-
Sheet更新がtrigger仕様に合う経路で発生している。
-
送信先と本文に必要最小限の情報だけ含まれる。
-
AIが宛先、金額、日付、送信可否を変更しない。
-
errorや再実行でも二重送信しない。
-
send後のSheet updateが無限loopを起こさない。
-
test recipientから本番recipientへ切り替える承認者が明確。
自動メールが社外へ出る場合、送信者名、reply-to、unsubscribeやprivacy notice等は業務・規制要件に合わせて確認します。この記事は個別の法的要件を確定しません。
AIものさしの判断
メールの宛先と送信時点はruleで固定し、AIは本文補助に限定します。まず定型通知とstate controlをtestし、安定してから個別化を加えると、automation failureと生成文の品質問題を分けて追えます。
Triggerの落とし穴
MakeのGoogle Sheets資料では、Watch ChangesはSheets画面でユーザーが行った変更を監視する説明になっており、scriptやAPIによる変更を拾う用途とは一致しません。新しい行の追加が起点ならWatch New Rowsを候補にし、既存行のstatus変更や外部連携による更新なら、実際の更新経路でtriggerが発火するか別途試します。空行があると後続行を処理しない場合もあるため、入力表の途中に空行を置かない運用も必要です。
送信前後の状態遷移
表は横にスクロールできます
| 時点 | 条件 | 更新する値 | 再実行での扱い |
|---|---|---|---|
| 受付 | 必須列と宛先がある | ready | 条件不備はhold |
| 送信開始 | readyかつ未送信 | processing、attempt ID | 同じattemptを重複起動しない |
| 成功確認 | メールactionが成功 | sent_at、message参照 | 再送対象から除く |
| 失敗 | actionが失敗または結果不明 | error、理由 | 状態を確認してから再試行 |
メール送信とSheetの更新は別の操作です。メールが送れた直後にscenarioが停止すると、送信済みなのにsent_atが空のまま残る可能性があります。単純に再実行すると二重送信になり得ます。送信前のprocessing記録、試行ID、送信結果の照合などで不確実な状態を区別し、結果不明を自動再送せず人へ知らせる設計を検討します。完全な一回限り実行を前提にしないでください。
例:送信対象を明示する
表は横にスクロールできます
| 判定項目 | 例 | 通過条件 |
|---|---|---|
| record_status | approved | 指定した状態と完全一致 |
| recipient_email | 構造化column | 空でなく書式確認済み |
| consent / purpose | 通知区分 | その目的の連絡が許可されている |
| sent_at | 空 | 未送信かつ結果不明ではない |
| content_version | template version | 承認済みtemplateを使用 |
この例の列名は設計用です。実際の列、同意の要否、保存期間は自社の業務と適用ルールに合わせて決めてください。シートに自由記述欄がある場合、そこから相手のメールアドレスや送信同意を推定させないでください。
テストで見る境界
テストでは新規row、既存row編集、script/APIからの更新、空行を挟んだ行、宛先欠損、条件外、同じeventの再処理、送信成功後の書き戻しをそれぞれ分けます。テスト用宛先以外へメールが飛ばないことを、宛先を固定した状態で確認します。AI本文を使う場合は、日付・金額・申込条件が原データと一致するかを照合し、禁止表現や根拠のない確約がないことを人が確認してから本番送信へ進めます。
運用を止める条件
宛先が空、対象者の状態が未承認、同じ行が複数回拾われた、templateが未承認、AI出力が必須項目を欠いた場合は送信を止めます。送信エラーや結果不明を単にsent=falseへ戻すと、再試行で重複する恐れがあります。例外の状態を明示して担当者に渡し、確認後に再送する手順を用意してください。
引用・データ出典
公式情報を編集部が見た内容です。Hands-on未実施の記述は本文かここに分けています。
確認日:2026-10-09
Make:Google Sheets modules(新しいタブで開く)
Make:Google Sheets and Gmail Integration(新しいタブで開く)
