gas スプレッドシート 自動通知｜メールを送る前に決める判定条件

「期限が近い案件をメールで飛ばすようにしたんですが、誰も反応しないんです」

作った本人からこう相談されて、実際に受信箱を見せてもらったことがあります。毎朝、同じ件名のメールが30通ほど届いていました。開かれた形跡はほとんどなく、受信ルールで専用フォルダに振り分けられていて、そのフォルダを開く習慣は誰にもない。仕組みは動いていたのに、業務としては何も起きていない状態でした。

スクリプトは正しく書かれていました。トリガーも毎朝きちんと発火していました。うまくいかなかった理由は技術ではなく、何を異常とみなすかを決めずに、条件に引っかかる行を全部流していたことです。届く量が読めなくなった通知は、受け取る側にとって背景音になります。背景音になった通知は、内容がどれだけ正確でも人を動かしません。

この記事では、GASでスプレッドシートから自動通知を送るときの「送る技術」ではなく、送る条件の決め方を扱います。コードは1つだけ、10行以内のものを1箇所に置きます。それ以外は、業務としてどこに線を引くかという話です。

通知を作る前に決める4つ

通知の設計で先に決めるべきことは、多くありません。次の4つです。逆に言えば、この4つが決まっていない状態で作った通知は、ほぼ同じ形で失敗します。

この4つは、どれもスクリプトの外側にある決めごとです。だから、通知の相談を受けたときに私たちが最初に聞くのは「何を送りたいか」ではなく「どうなっていたら困る状態なのか」です。困る状態を言葉で言えない業務は、条件にも落とせません。

言えないときは、通知を作る前に一段戻ります。その業務で誰が何を見ていて、どうなったときに手を打っているのかを、まず言葉で並べるところからです。

「全件送る」から「差分だけ送る」へ

読まれる通知と読まれない通知の差は、内容の丁寧さではなく状態そのものを送っているか、状態が変わった瞬間を送っているかにあります。「期限が近い案件が今30件あります」は状態です。毎日送れば毎日30件前後になります。「今日、期限まで3日を切った案件が2件あります」は変化です。人が動く単位はこちらのほうです。

変化の送り方は、実務では3つの型にだいたい収まります。

• 入った：新しい行が入ったとき。フォームからの受付、申請、反響の登録など。到着そのものが変化なので、判定は「まだ通知していない行かどうか」だけで足ります
• 越えた：ある行が境目を越えたとき。期限まで残り3日になった、最終更新から5日動いていない、といった型です。境目を越えた日にだけ鳴らしたいので、越えたことを記録しておく必要があります
• 合わない：2つを突き合わせて、片方にしかないとき。請求はあるが入金の記録がない、受注はあるが納品の記録がない。ここは通知として一番効く型ですが、突き合わせるためのキーが両方に揃っていることが前提になります

3つに共通しているのは、どれも前回どうだったかを持っていないと差分が出せないということです。前回の状態を持っていなければ、「越えた日」は判定できず、毎日「越えている行」を送り続けることになります。最初の相談の通知が30通になっていたのは、まさにこれでした。

つまり、自動通知を作るには判定した結果を残す列がシートに必要になります。通知日を入れる列でも、通知済みのフラグでも構いません。ここが用意されていないシートに通知を後付けすると、必ず「毎日同じものが鳴る」形になります。

そしてこの列を足すことは、技術の話ではありません。「対応済みとは何をした状態か」「誰がその印を置くのか」を決めるという、業務プロセスの構造化そのものです。私たちがツールを入れる前にここへ時間をかけるのは、決めていない状態のまま自動化を乗せると、決まっていないことが速く流れるだけになるからです。

最も多い失敗は「鳴りすぎ」ではなく「鳴っていないのに気づかない」

鳴りすぎる通知は、うるさいので必ず誰かが文句を言います。文句が出れば直せます。本当に危ないのは逆で、止まっていることに誰も気づかない通知です。

人が目で見て気づいていた異常を通知に置き換えると、見る習慣のほうは短期間で消えます。シートを毎朝開いていた人は、通知が来るようになった時点で開かなくなります。その状態で通知が止まると、異常を見つける経路がゼロになります。しかも「何も来ていない」ことは、平穏に見えます。

通知が止まる原因は、いくつも思い当たります。スクリプトがエラーで止まる。実行の上限に当たって回らなくなる。宛先の担当者が変わって、消えたアドレスに送り続けている。件名や差出人の条件が変わって、迷惑メールに入る。共有シートの列が1つ増えて、判定していた列がずれる。どれも珍しいことではありません。

対策は、そんなに難しくありません。

• 該当0件の日も1通送る。「本日、期限が近い案件はありません」で構いません。毎日必ず1通届く形にしておくと、届かないこと自体が異常として検知できます
• 宛先を直書きしない。スクリプトの中にアドレスを埋め込むと、担当が変わったときに直せる人が限られます。シート上の1箇所に宛先の表を作り、そこを読ませます
• 通知の担当を決めておく。届かなくなったときに直す人、または直せる人に連絡する人です。ここが空欄のまま運用に入った通知は、止まったときに復旧しません
• いつ、どこへ送ったかをシートに残す。送信の記録があると、「届いていない」と言われたときに、送っていないのか届いていないのかを切り分けられます

3つ目は特に大きいです。自動化は作った人しか直せない形になりやすく、その人が離れた時点で誰も触れなくなります。この構造の見分け方は作った人しか直せないツールが残るリスクで、業務そのものを一人に寄せない進め方は属人化を解消する3ステップで整理しています。通知は属人化を減らす道具に見えて、作り方を誤ると属人化を1つ増やします。

メールで送るか、チャットで送るか、シートに出すか

条件が決まったら、次は送り先です。ここを「とりあえず全部メール」で始める会社が多く、そのまま埋もれていきます。3つの選択肢を、向き不向きで並べます。

現実的な線引きは、動く人が1人に決まるものだけメールにすることだと考えています。1人に決まらない通知をメールで送ると、宛先が増え、量が増え、誰も動かない状態に近づきます。複数人で見る前提のものはチャットへ、毎日見る画面がある業務はシート上の色や絞り込みで足りることも多いです。

なお、GASのメール送信には1日に送れる宛先数の上限があり、一般のGoogleアカウントとGoogle Workspaceのアカウントで枠が違います。社内の担当者に条件付きで数通送る使い方なら気にする場面は少ないのですが、対象が増えていく通知や一斉配信では先に上限へ当たります。上限の具体的な数値と、上限に当たらない回し方はGASの実行時間と上限の設計でまとめています。数値はGoogle側で予告なく変更される場合があると明記されているので、実装前に公式ページ（https://developers.google.com/apps-script/guides/services/quotas）を必ず確認してください。

判定して、送ったら印を置く（最小の形）

考え方が分かる最小の形を1つだけ置きます。期限の列を見て、3日を切っていて、まだ通知していない行だけを送り、送ったら通知日を書き込む処理です。

const sheet = SpreadsheetApp.getActiveSheet();
sheet.getDataRange().getValues().forEach(function (row, i) {
  if (i === 0 || row[3]) return;                   // 見出し行と、通知済みの行はとばす
  const rest = (new Date(row[1]) - new Date()) / 86400000;
  if (rest > 3) return;                            // 期限まで3日以内だけを対象にする
  MailApp.sendEmail(row[2], "期限が近い案件: " + row[0], "残り" + Math.ceil(rest) + "日です");
  sheet.getRange(i + 1, 4).setValue(new Date());   // 通知した印を置く（ここが本体）
});

大事なのは最後の1行です。印を置くことが本体で、メールを送ることはおまけだと考えてください。この列があるから翌日は鳴らず、この列を消せばもう一度鳴らせて、この列を数えれば何件通知したかが分かります。逆に、印を置かない通知はどれだけ丁寧に書いても翌日また同じ行を流します。

通知で足りる範囲と、足りなくなる境目

スプレッドシートと自動通知の組み合わせは、条件が揃っていればかなり長く使えます。足りる範囲は、おおよそ次のような状態です。動く人が決まっている。対応したかどうかを人がシートに書ける。1日に鳴る件数が読める範囲に収まっている。この3つが揃っていれば、通知を外に出す理由はまだありません。

足りなくなる境目は、私たちが見ている限り4つに集約されます。

1. 通知を受けた人が対応したかを追う必要が出た。通知は知らせる仕組みで、記録の仕組みではありません。「送った先で何が起きたか」を管理しはじめると、通知だけでは持ちません
2. 誰に送るかが条件で変わり、その条件が増え続ける。担当・エリア・金額・取引先で宛先が枝分かれし、分岐がスクリプトの中に溜まっていく状態です。分岐は書いた人以外に読めません
3. 送った・届いた・開いたを説明する必要が出た。取引先への通知や、社内の監査で経緯を求められる場面です。ここは通知の外に記録の場所が要ります
4. 件数が増えて、1日の上限に当たり始めた。分割して回す設計で伸ばせる余地はありますが、伸ばし続けるものではありません。判断材料はGASの実行時間と上限の設計にまとめています

境目に当たったときに、いきなり全体をシステムに載せ替える必要はありません。現実的なのは、対応の記録を持つ場所だけを外に出すことです。シートは入口と一覧のまま残し、「誰がいつ何をしたか」だけをきちんと持てる場所を1つ作る。この順番だと、いま回っている運用を止めずに移せます。どこから外に出すかの判断はExcel業務をシステム化する判断とSaaSとスプレッドシート+自動化の選び方で整理しています。

そもそもGASでどこまで任せられるのかを先に押さえたい場合はGASでできることの範囲を、通知の手前で「そもそも情報が集まっていない」状態であればGoogleフォームで現場の報告を1枚に集めるのほうが先になります。判定する材料が揃っていないシートに通知を付けても、鳴る条件が作れません。

まとめ

自動通知の出来は、送る仕組みではなく何を異常とみなすかを決めたかどうかで決まります。異常の条件、動く人、対応を書く場所、鳴らない日があってよいか。この4つを先に決めておけば、コードは短くて済みます。

送るのは状態ではなく変化です。入った・越えた・合わないの3つの型はどれも、前回どうだったかを持っていないと判定できません。だから通知を作るときは、判定の結果を残す列を必ず用意します。この列を決めることは、業務の側で「対応済みとは何か」を決めることと同じです。

そして、該当0件の日も1通送ります。通知の一番怖い壊れ方は、鳴りすぎることではなく、鳴らなくなったことに誰も気づかないことです。宛先はシート上で管理し、届かなかったときに直す担当を決めておく。ここまでやって、はじめて人の目の代わりになります。

対応したかどうかを追う必要が出てきたら、それは通知の外に記録の場所を作る合図です。まずは今動いている通知について、「何を異常とみなしているか」を一文で言えるかどうかを確かめるところからで十分だと思います。言えないなら、直す場所はスクリプトではありません。