「通知が多すぎて見ない」を直す：GASの重複排除で"本命だけ"届ける通知設計

「通知を入れたのに、誰も見ていない」。自動通知を導入した会社で、意外なほどよく起きる話です。最初は便利だった通知が、気づけば1日に何十件も飛び、現場は全部まとめて無視するようになる。いわゆる”オオカミ少年”状態です。これを直す鍵は、通知を増やすことではなく、**重複を消して、本当に見るべきものだけを残す「通知設計」**にあります。

仕組みとしては、Google Apps Script（グーグル アップス スクリプト・GAS・Google 製品を自動で動かす無料のプログラム実行環境） で通知を出す前に「これは前にも送ったか」を確かめ、スプレッドシート（Google 製のクラウド表計算） に送信済みを記録して重複を排除（dedup・ディーダップ・同じ通知の二重送信を消すこと）し、Slack（スラック・チーム向けチャット） や LINE にはしきい値を超えた本命だけを届ける。この組み合わせで、「通知疲れ」は現実的に解消できます。本記事では、どの工程でどの道具をどう使うかまで具体名で説明します。

1分の無料セルフ診断：5つの質問に答えるだけで、時間と人件費の変化の目安が出ます。

結論：通知は「増やす」より「減らして本命だけ残す」ほうが見てもらえる

通知が無視されるのは、内容が悪いからではなく、多すぎて優先順位がつけられないからです。同じ案件のリマインドが毎時間飛ぶ、すでに対応済みの件が何度も鳴る。こうした”ノイズ”が混じると、人は本命と区別する手間を惜しんで、全部を見なくなる。これは意志の弱さではなく、自然な反応です。

通知設計とは、この逆を仕組みでやることです。「同じ通知は一度だけ」「決めた基準を超えたものだけ鳴らす」という”型”を機械に持たせる。通知を送るかどうかの判断は、毎回ほぼ同じルールの繰り返し、つまり”型のある作業”なので、AI や自動化がいちばん力を発揮します。人が見るべきなのは、鳴った後の中身の判断だけ。鳴らすかどうかの仕分けは、機械に任せられます。

ここでの「浮く時間」は、いらない通知を一件ずつ確認して「これは対応済み」と打ち消す手間と、逆に本命を見落として後から取り返す手間の両方が減ることで生まれます。

向いている会社・向きにくい会社

向いているのは、すでに何らかの自動通知が動いていて、それが多すぎて見られていない会社です。在庫アラート、入金チェック、問い合わせ転送、システムのエラー通知。種類は問いません。「通知はあるのに、結局人が目視で確認している」状態なら、設計を入れ直すだけで大きく変わります。これから通知を作る会社も、最初から重複排除としきい値を組み込んでおけば、“オオカミ少年化”を未然に防げます。

逆に、通知の件数がもともと少なく、一件一件すべて対応が必要な会社では、削る余地は小さめです。それでも「対応済みのものは二度と鳴らさない」という重複排除だけでも、通知は目に見えて減ります。

1分の無料セルフ診断：5つの質問に答えるだけで、時間と人件費の変化の目安が出ます。

具体的に、どう仕組みにするか

1. いまの通知を棚卸しする：何が・どれくらいの頻度で・どこに飛んでいるかを書き出します。「同じ件で何度も鳴っているもの」「一度も読まれていないもの」を見つけるのが、設計の出発点です。
2. “同じ通知”の見分け方を決める：何をもって「同じ」とするか（例：同じ案件番号＋同じ日、同じ取引先＋同じ金額）を最初に定義します。ここが重複排除の心臓部です。曖昧なままだと、消しすぎたり消し漏れたりします。
3. 送信済みを表に記録する：通知を出すたびに、その”見分けるキー”と日時をスプレッドシートに1行ずつ残します。これが「前に送ったか」を確かめる台帳になります。
4. 送る前に照合して重複を消す：新しく通知しようとするたびに、台帳を見て「もう送ってある」なら飛ばす。これで二重送信が機械的に消えます（dedup）。
5. 本命の基準（しきい値）で絞る：「在庫が基準を割って、かつ前回通知から24時間以上経っている」のように、鳴らす条件を言葉で明確にします。この基準を超えたものだけが、Slack や LINE に届く状態が完成形です。

肝心なのは、2の「同じの定義」と5の「鳴らす基準」を最初に言葉で決めて残しておくこと。ここが曖昧なまま自動化すると、「消えすぎて本命まで届かない」「結局うるさいまま」のどちらかに転びます。

実際に、どの道具を使うのか

ここは具体名で踏み込みます。通知設計は大きく「①送信済みを覚える → ②重複を消す → ③届け先に飛ばす」の3工程に分かれ、工程ごとに向く道具が違います。

①送信済みを記録する（状態管理）

まず Google スプレッドシート が手軽です。「いつ・どのキーで・どこに送ったか」を1行ずつ残すだけなら、表計算で十分。中身が見えるので、運用中に「なぜこれは鳴らなかったのか」を人が目で追える利点もあります。通知の件数が増えて表計算が重くなってきたら、キーと値だけを高速に出し入れできる GAS の CacheService / PropertiesService（GAS に標準でついている、値を一時保存する仕組み） や、大量データに強い BigQuery（ビッグクエリ・Google のデータ集計基盤） に寄せる、という広げ方があります。まずはスプレッドシート、重くなったら寄せるのが現実的な順番です。

②重複を消し、本命を選ぶ（判定ロジック）

中心が Google Apps Script（GAS） です。決まった時間に動いて、「このキーは台帳にあるか」「前回通知から十分時間が経ったか」「基準値を超えたか」を毎回ぶれずに判定します。GAS は Google スプレッドシートやカレンダー、Gmail と同じ世界の中で動くので、追加費用なしで、決まった時刻に自動で回すのに向きます。判定が複雑で、文章での問い合わせ内容など”あいまいなもの”を仕分けたい場合は、Claude（クロード・Anthropic 社の対話AI） や ChatGPT に「この通知は緊急か・既存案件の続きか」を判定させて、しきい値の一部に組み込む、という使い方もできます。

③届け先に飛ばす（通知チャネル）

社内のチームに見せたいなら Slack、現場のスマホに直接届けたいなら LINE（LINE Messaging API・LINE 公式アカウントから通知を送る仕組み） が定番です。チャットに常時いる事務・管理の現場なら Slack、外回りや店舗でスマホを見る現場なら LINE、届けたい相手がふだん何を見ているかで選ぶのがコツです。両方に出し分けることもできます。

実際、ある現場でも、自動通知が氾濫して誰も見なくなっていたのを、この重複排除と「鳴らす基準」の設計で組み直したところ、通知の数自体は大きく減ったのに、本当に必要な件はかえって見られるようになりました。通知は、増やすほど見られるのではなく、絞るほど見られるのです。

つまずきやすい点

• “同じ通知”の定義を決めずに重複排除する：見分けるキーが曖昧だと、別件まで「同じ」とみなして消したり、逆に消し漏れたりします。手順2を飛ばさないのが肝です。
• しきい値を厳しくしすぎる／緩すぎる：基準が厳しいと本命まで黙り、緩いと結局うるさいまま。最初はやや緩めに始め、運用しながら「鳴ったが対応不要だった件」を見て締めていくのが現実的です。
• 送信済みの記録を残さないまま走らせる：台帳がないと「前に送ったか」を確かめようがなく、重複排除そのものが成り立ちません。①の記録を必ず先に作ります。

よくある質問

Q. 通知を絞りすぎて、大事な連絡を見落とさないか不安です。 A. だからこそ「鳴らす基準」を言葉で残し、運用しながら調整します。最初はやや緩めに設定し、「鳴ったけど対応不要だった件」を記録に残して、その分だけ基準を締めていく、という回し方なら、見落としのリスクを抑えながら、少しずつ静かにできます。基準はいつでも見直せます。

Q. 通知の中身に、取引先名や金額などの機密が含まれます。AIに渡して大丈夫ですか？ A. 何を渡すかを線引きすれば運用できます。重複の判定や基準のチェックは、機密の中身そのものを AI に渡さなくても、「キー（案件番号など）」と「数値」だけで成り立つ場合がほとんどです。文章の中身をAIに仕分けさせたい場合だけ、必要な範囲に絞って渡す設計にできます。

Q. すでに動いている通知に、後から重複排除を足せますか？ A. 足せます。いまの通知の出口に「送信済みを記録して、送る前に照合する」工程を挟むだけで、既存の仕組みを作り直さずに重複を消せます。まずは一番うるさい通知ひとつから試すのがおすすめです。

なお、この記事の数値は、特定の実在企業の事例ではなく、現場でよく見る状況を組み立てた代表的なケースです。御社に当てはめた目安は、診断で出すのがいちばん近くなります。

通知は、数を増やすほど安心に見えて、実は現場の注意力をすり減らし、本命を埋もれさせていることがよくあります。重複を消し、本当に見るべきものだけが届くようにすれば、社員は通知の選別に使っていた時間を、本来やるべき仕事に戻せます。御社のどの通知がいちばん”鳴りすぎ”か、まずは目安を出してみませんか。

1分の無料セルフ診断：5つの質問に答えるだけで、時間と人件費の変化の目安が出ます。