SlackやMicrosoft Teamsへの通知を使って業務を回すときに大切なのは、通知を増やすことではなく、対応が必要な情報だけを、対応すべき人に、対応できる形で届けることです。システムの更新、問い合わせの受付、売上の速報、エラーの発生など、通知にできる出来事はいくらでもあります。しかし何でも通知にすると、チャンネルが流れていくだけの場所になり、本当に重要な通知まで読まれなくなります。
通知の自動化は、ノーコードツールやWebhookを使えば手軽に作れるぶん、設計をしないまま数が増えやすい仕組みです。「通知が来ても誰も反応しない」「重要なエラーに半日気づかなかった」という状態は、多くの場合、ツールの問題ではなく設計の問題です。
この記事は、社内の業務連絡や自社サービスの運用でチャット通知を活用している、またはこれから活用したいと考えている事業担当者、運用責任者、情報システム担当者に向けて書いています。通知が無視される原因、通知の分類方法、読まれる通知の書き方、チャンネル設計、自動化の手順と見直しの方法までを順番に説明します。
通知が多すぎて無視される問題はなぜ起きるのか
チャット通知の自動化を進めた職場でよく起きるのが、通知が多すぎて誰も見なくなる問題です。運用監視の分野では「アラート疲れ」と呼ばれることもあります。原因はおおむね次の四つに分けられます。
- 対応不要の通知が混ざっている：「処理が正常に完了しました」「新しいデータが登録されました」といった、読んでも何もしなくてよい通知が大半を占めると、読み手は通知全体を読み飛ばすようになります。
- 誰が対応するのか分からない：大人数のチャンネルに通知が流れると、全員が「誰かが見ているだろう」と考え、結局誰も対応しません。
- 何をすればよいのか分からない：「エラーが発生しました」とだけ書かれた通知では、どのくらい深刻で、何を確認すればよいのかが分からず、後回しにされます。
- 同じ通知が繰り返し届く：一つの問題に対して、同じ通知が数分おきに何十件も届くと、チャンネル全体が埋まり、他の通知も見えなくなります。
これらはすべて、通知を作るときに「この通知を受け取った人は何をするのか」を決めていないことから生まれます。通知の設計は、この問いから始めます。
通知を三つに分類する
まず、今ある通知と、これから作りたい通知を一覧にし、受け取った人の行動に応じて分類します。
| 分類 | 意味 | 例 | 届け方 |
|---|---|---|---|
| 対応必須 | 決まった時間内に誰かが対応しないと問題が起きる | 決済の失敗、サービス停止、至急の問い合わせ | 担当者を名指しし、対応状況を追跡する |
| 確認推奨 | 当日中に目を通せばよい、判断の材料になる | 新規の申し込み、承認待ちの申請、在庫の減少 | 担当チームのチャンネルに投稿する |
| 記録のみ | 後から振り返るときに参照する | 処理の正常完了、日次の件数 | 通知せず、ログやダッシュボードで見られるようにする |
分類してみると、通知の多くが「記録のみ」に当たることがよくあります。記録のみの通知はチャットに流すのをやめ、ログやダッシュボードに移します。それだけで、チャンネルの通知量が大きく減り、残った通知が読まれるようになります。
「確認推奨」の通知も、一件ずつ流すのではなく、一日一回まとめて投稿する方法があります。たとえば「本日の新規申し込み：件数と一覧へのリンク」という形で朝に一回まとめれば、通知の数は大幅に減ります。
部署ごとの通知の分類例
分類の感覚をつかむために、部署ごとの典型的な通知を当てはめてみます。あくまで一般的な例で、自社の業務によって分類は変わります。
- 営業：大口の見込み客からの問い合わせは対応必須、資料ダウンロードの発生は確認推奨、メール開封の記録は記録のみ。
- 経理：入金の消し込みができない取引や支払いの失敗は対応必須、請求書の送付完了の一覧は確認推奨、仕訳の自動登録の完了は記録のみ。
- カスタマーサポート：サービスが使えないという報告や解約の申し出は対応必須、通常の問い合わせの受付は確認推奨、自動返信の送信完了は記録のみ。
- 開発・運用：サービス停止やデータ処理の失敗は対応必須、リソース使用量の増加傾向は確認推奨、デプロイやバックアップの正常完了は記録のみ。
同じ「問い合わせの受付」でも、内容によって対応必須にも確認推奨にもなります。通知の元になる出来事の中身で分類を変えられるよう、通知の条件を細かく設定できる仕組みを選ぶことが大切です。問い合わせの内容から緊急度を判定する方法は、問い合わせメールの振り分けを生成AIで自動化する方法と注意点で扱っています。
読まれる通知の書き方
通知の文面は、受け取った人が通知だけを見て「何が起きたか」「どれくらい急ぐか」「何をすればよいか」を判断できるように書きます。
通知に含める要素
- 何が起きたか：事象を一文で書く。「〇〇株式会社のクレジットカード決済が失敗しました」
- 緊急度：対応必須か確認推奨かが一目で分かる表示。先頭に記号や色を付ける
- 影響範囲：誰に、どれくらいの影響があるか。「対象：1件、契約の更新処理が止まっています」
- 次の行動：何をすればよいか。「顧客管理画面で支払い方法を確認し、本人に連絡してください」
- リンク：詳細を確認する画面や手順書へのリンク
- 担当者：誰が対応するか。メンションで名指しする
悪い例と改善例
悪い例は「エラーが発生しました（処理ID：xxxxx）」という通知です。受け取った人は、どのくらい深刻なのか、誰が見るべきか、何をすればよいかが分からず、後回しにします。
改善例は「【要対応】請求書の自動送付が3件失敗しました。対象顧客のメールアドレスが無効です。担当：@経理当番。対応：顧客管理画面で連絡先を確認し、修正後に再送ボタンを押してください（手順書リンク）」という通知です。読んだ人がすぐに動けます。
表記をそろえる
通知の先頭に付ける表記は、組織の中でそろえておきます。あるシステムは「【緊急】」、別のシステムは「[ALERT]」、また別のシステムは赤い丸の絵文字、とばらばらだと、読み手は通知ごとに重要度を読み解かなければなりません。「【要対応】」「【確認】」の二種類に統一する、といったように表記のルールを決め、すべての通知に適用します。また、一つの通知に情報を詰め込みすぎないことも大切です。チャットの画面で最初の数行に要点が収まるように書き、詳細はリンク先やスレッドに回します。長いエラーログをそのまま貼り付けると、肝心の要点が画面の外に押し出されてしまいます。
対応手順を毎回通知に書き込むのが難しい場合は、通知の種類ごとに手順書を用意し、そのリンクを付けます。手順書の作り方は、用語解説のRunbook（運用手順書）も参考になります。
チャンネル設計と担当者の決め方
チャンネルは「誰が対応するか」で分ける
通知用のチャンネルは、システムごとではなく、対応するチームごとに分けるのが基本です。「決済システムの通知」「顧客管理システムの通知」とシステム単位で分けると、一つのチームが複数のチャンネルを見張る必要が出てきます。「経理チームの要対応」「サポートチームの要対応」のように対応者で分ければ、各チームは自分のチャンネルだけを見ればよくなります。
対応必須の通知は担当者を名指しする
対応必須の通知は、チームのチャンネルに流すだけでなく、当番の担当者をメンションで名指しします。当番を曜日や週で決めておき、当番表と連動して自動でメンションを付ける仕組みにすると、「誰かが見ているだろう」という状態を防げます。
対応状況を見える化する
対応必須の通知は、「誰が対応を始めたか」「対応が終わったか」が分かるようにします。簡単な方法としては、対応を始めた人がスタンプを押し、完了したら別のスタンプを押す運用があります。件数が多い場合は、通知と同時に問い合わせ管理ツールやタスク管理ツールにチケットを作り、対応状況をそちらで追跡します。用語解説のチケット管理も参考にしてください。
夜間・休日の扱いを決める
夜間や休日に対応必須の通知が発生した場合に、誰に、どの手段で知らせるかを決めておきます。チャットの通知は、勤務時間外には見られないことが前提です。本当に夜間でも対応が必要なものは、電話やSMSで知らせる仕組みと組み合わせます。逆に、翌営業日の対応で問題ないものは、夜間は通知を溜めておき、朝にまとめて投稿する設計にします。
通知のルールを文書にしておく
ここまでに決めた分類、チャンネル、当番、時間外の扱いは、一枚の文書にまとめて共有します。新しい通知を追加したい人は、この文書に沿って「どの分類か」「どのチャンネルか」「誰が対応するか」を決めてから設定します。ルールが文書になっていないと、担当者ごとに思い思いの通知が追加され、時間が経つと元の混乱した状態に戻ってしまいます。文書には、通知を追加・変更・削除するときの承認者も書いておくと、通知の増えすぎを防げます。
通知を自動化する方法
チャット通知を自動で送る方法はいくつかあります。仕組みの規模や保守の体制に合わせて選びます。
| 方法 | 向いている状況 | 注意点 |
|---|---|---|
| 各SaaSの標準連携 | 使っているSaaSがSlackやTeamsとの連携機能を持っている | 通知の文面や条件を細かく調整できないことがある |
| ノーコード自動化ツール | 複数のサービスの出来事を組み合わせて通知したい | ツールの設定を誰が管理するかを決めておく |
| Webhookで自社システムから送る | 自社システムの出来事を通知したい | 送信失敗時の扱い、通知内容の管理が必要 |
| 通知用の仕組みを開発する | 当番表との連動、まとめ投稿、重複の抑制などが必要 | 開発と保守の費用がかかる |
SlackもTeamsも、外部からメッセージを受け取る仕組みとしてWebhookを用意しています。自社システムからは、出来事が起きたときにWebhookのURLへメッセージを送るだけで通知できます。ただし、WebhookのURLを知っていれば誰でもメッセージを送れるため、URLの管理には注意が必要です。両サービスの仕様や提供機能は変わることがあるため、実装時には最新の公式情報を確認してください。
ノーコードツールの選び方は、ZapierとMakeの選び方：ノーコード自動化ツールの比較の観点で詳しく解説しています。
重複と大量通知を抑える工夫
同じ問題で通知が大量に届くのを防ぐために、次のような工夫を入れます。
- 同じ種類の通知は、一定時間内に一回だけ送る
- 一定件数を超えたら、個別の通知をやめて「〇件発生中」というまとめ通知に切り替える
- 問題が解消したら「解消しました」という通知を一回だけ送る
- 新しい通知を送るのではなく、最初の通知のスレッドに追記する
通知設計と自動化の進め方
- 今ある通知を棚卸しする：チャットに流れている自動通知をすべて書き出し、送信元、頻度、受け取っているチャンネルを記録します。
- 受け取った人の行動を書く：通知ごとに「受け取った人は何をするのか」を書きます。書けない通知は、記録のみの候補です。
- 三つに分類する：対応必須・確認推奨・記録のみに分け、記録のみはチャット以外へ移します。
- チャンネルと担当を決める：対応するチームごとにチャンネルを整理し、対応必須の通知の当番を決めます。
- 文面を書き直す：何が起きたか、緊急度、影響、次の行動、リンク、担当者を含む形に直します。
- 重複抑制とまとめ投稿を設定する：大量通知を抑える仕組みと、確認推奨のまとめ投稿を設定します。
- 夜間・休日のルールを決める：時間外の通知の扱いと、緊急時の連絡手段を決めます。
- 月に一度見直す：通知の件数、対応必須の通知への反応時間、反応がなかった通知を確認し、不要な通知を減らします。
具体例：会員制Webサービスの運用チーム
架空の例として、小規模な会員制Webサービスを運営する会社を考えます。運用用のチャンネルには、新規会員登録、決済の成功と失敗、問い合わせの受付、サーバーの監視アラート、夜間の集計処理の完了など、あらゆる通知が一つのチャンネルに流れていました。一日に流れる通知の大半は新規登録と決済成功と処理完了で、決済失敗や監視アラートはその中に埋もれていました。
棚卸しの結果、新規登録と決済成功は「記録のみ」としてダッシュボードに移し、朝に前日の件数だけをまとめて投稿することにしました。集計処理の完了通知はやめ、失敗したときだけ通知するように変えました。決済失敗は経理当番を名指しする「要対応」チャンネルへ、監視アラートは開発当番を名指しする別のチャンネルへ分けました。結果として、運用チャンネルに流れる通知は大きく減り、要対応の通知には担当者がすぐ反応するようになりました。
よくある失敗と避け方
- 作れるから作る：連携が簡単なため、必要性を考えずに通知を追加してしまいます。新しい通知を追加するときは、「受け取った人は何をするのか」を書くことを条件にします。
- 正常時の通知を流し続ける：「動いていることを確認したい」という理由で正常完了の通知を流すと、通知の大半を占めてしまいます。正常時は記録に残し、失敗時だけ通知します。処理が動いたかどうかを確認したい場合は、「予定時刻までに完了の記録がなければ通知する」仕組みにします。
- 全員に届ける：全員が見るチャンネルに要対応の通知を流すと、責任が分散して誰も動きません。担当者を名指しします。
- 作った人しか止め方を知らない：通知の設定がどのツールのどこにあるか分からず、不要になった通知を止められない状態になります。通知の一覧と設定場所を台帳にしておきます。自動化の仕組みの管理については、自動化の仕組みを誰が保守するか：野良ロボット・野良ツール対策で詳しく扱っています。
通知設計のチェックリスト
- すべての自動通知について「受け取った人の行動」が書かれている
- 記録のみの通知をチャットから外している
- 確認推奨の通知はまとめて投稿する設計になっている
- 対応必須の通知には担当者のメンションが付く
- 通知の文面に緊急度、影響、次の行動、リンクが含まれている
- 同じ問題で大量の通知が届かないよう抑制している
- 夜間・休日の通知の扱いと緊急連絡の手段を決めている
- 通知の一覧と設定場所を台帳で管理している
- 月に一度、通知の件数と反応を見直している
よくある質問
Q. SlackとTeamsで通知設計の考え方は変わりますか？
基本の考え方は同じです。対応が必要な通知だけを、対応する人に、対応できる形で届けることが原則です。メンションやスレッド、チャンネルの仕組みに細かな違いはあるため、自社が使っているツールの機能に合わせて実装を調整してください。
Q. 通知を減らすと、重要なことを見逃しませんか？
減らすのは「受け取っても何もしない通知」です。それらをチャットから外すことで、残った重要な通知が目に留まりやすくなり、見逃しはむしろ減ります。外した情報はダッシュボードやログで確認できるようにしておけば、必要なときに参照できます。
Q. 生成AIを通知に組み合わせる使い方はありますか？
長いエラーログや問い合わせ本文を要約して通知に添える、複数の通知をまとめて「今日起きたこと」として整理する、といった使い方があります。ただし、要約が誤っている可能性もあるため、元の情報へのリンクを必ず付けておきます。
Q. 通知のための仕組みを開発するべきか迷っています。
使っているSaaSの標準連携やノーコードツールで十分な場合は、まずそれで始めて構いません。当番表との連動、重複の抑制、まとめ投稿、対応状況の追跡などを細かく制御したくなった段階で、通知の仕組みを作ることを検討します。
Otsumuに相談できること
通知の数がそれほど多くなく、使っているSaaSの標準連携やノーコードツールで通知を送っている段階であれば、この記事の手順どおりに棚卸しと分類を行い、文面とチャンネルを整理するだけで、自社で十分に改善できます。外部に頼む前に、まず「記録のみの通知をチャットから外す」ことから始めてみてください。
一方で、自社サービスの運用で多くのシステムから通知が届き、整理しきれない場合、当番表との連動や重複の抑制、対応状況の追跡まで仕組みとして作りたい場合は、通知の設計と開発をまとめて考える必要があります。通知の先にある運用業務そのものの自動化まで検討したいときも、外部の視点が役に立ちます。
Otsumuでは、運用業務と通知の棚卸しから、通知設計、連携の仕組みづくり、運用の定着までを一貫して支援しています。目的から逆算して必要な範囲に絞り、小さく作って効果を確かめながら広げる進め方を取ります。詳しくは自社サービス運用の自動化コンサルティングやAPI連携開発のページをご覧ください。
通知が多すぎて困っている、どこから整理すべきか分からない、という段階でもかまいません。30分の無料相談からお気軽にご連絡ください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01