Linear・GitHub・Slackの通知が多すぎる – 1日200件を5件に減らすには
LinearとGitHub、Slackの通知に追われるエンジニアチームへ。アーキテクチャの欠陥と本当に必要な5つのシグナルを解説します。
By Ellis Keane · 2026-03-13
問題は通知が多すぎることではありません。問題は、同じイベントについて3つのツールから同時に、ちょうど適切な数だけ届いてしまうことです。
すべてのウェブフックは正しく起動しています。すべてのインテグレーションは約束通りに動作しています。GitHubはPRについて通知します。Linearはそのクローズされるissueについて通知します。Slackは誰かが（おそらくあなたが、3ヶ月前に、「可視性」への根拠のない楽観主義で）ボットをプロジェクトチャンネルに接続したために通知します。3つのツール、3つの通知、1つのイベント、すべてが設計通りに動作しています。エンジニアリングは完璧です。体験は最悪です。
LinearとGitHub、Slackの通知が多すぎるのは、何かが壊れているからではありません。何も壊れていないからです。各ツールは、他のツールの存在を全く意識せずに、忠実に通知の役割を果たしています。共有のイベントバスもありません。重複排除レイヤーもありません。「この人はすでにこれを知っている」というコンセプトも、スタックのどこにもありません。あなたが苦しんでいるのは設定ミスではありません。6つのツールを同じワークフローに接続し、それぞれが独立して叫ぶようにした論理的な帰結です。
「通知システムは失敗していない。あまりにもうまく機能しすぎて、あなたを埋もれさせているのだ。」 – Chris Calo
進歩とはこういうものです。
1回のマージの解剖 – 重複の検死
あるイベント、つまり1つのPRマージを例に取り、通知レイヤーで何が起こるかを追ってみましょう。珍しいからではなく、うんざりするほど普通のことだからです。
チームメイトがGitHubでPRをマージしました。以下がそのカスケードです：
- GitHubはあなたの通知インボックスにウェブフックを送信します。このPRでレビューを作成したあなたは購読者です。これが通知1つ目。
- LinearのGitHubインテグレーションがリンクされたissueを検出し、ステータスを「進行中」から「完了」に自動遷移させます。Linearはissueを見ている全員に通知を生成します。同じチームにいるあなたも含まれます。これが通知2つ目。
- Slackボット（前述の楽観主義の中で接続したもの）が#frontendにマージのサマリーを投稿します。誰かがそのメッセージに絵文字やコメントでリアクションすると、Slackはスレッド通知を生成します。これが通知3つ目、場合によっては4つ目。
- CIがマージコミットで実行されます。GitHubが別のウェブフックを送信します。CIが通過しても気にしないかもしれませんが、GitHubの購読モデルはバイナリです。見ているか見ていないかのどちらかです。これが通知5つ目。
5つの通知。1つのイベント。そして、マージが議論されたコールにあなたもいたので、これらが届く前にすでに知っていました。
これをチーム6人のすべてのPR、すべてのissue遷移、すべてのCI実行に掛け合わせると、本当に新しいシグナルをカウントする前に、1人あたり1日30〜40の重複イベントを処理していることになります。通知システムは失敗していない。あまりにもうまく機能しすぎて、あなたを埋もれさせているのです。
ミュートは出血へのパッチ当て
標準的なアドバイスはアグレッシブなミュートです。GitHubのメール通知をオフにする。Slackはダイレクトメンションのみに設定する。Linearでは自分に割り当てられたissue以外はすべてフォローを解除する。これは手首が骨折しているのに時計を外すようなものです。技術的に手首周りの複雑さは減りましたが、時間を確認する手段も失いました。
私もミュートアプローチを試しました（もちろんです。誰もがやることです。全員が最初に試みること、次に試みるのはZapierチェーンで、なぜかさらに悪化させます）。徹底的にやりました：GitHubメールを完全に止め、チームのワーキングチャンネル以外はすべてSlackチャンネルをミュートし、Linearでは自分のissue以外はすべてフォロー解除しました。約3日間は至福でした。
それから、ミュートしたチャンネルでディスカッションが行われていたために、2つのブロッキングPRレビューを見落としました。私のレビューが必要だったエンジニアたちは最終的にDMを送ってきました。それは余分なステップと受動的な「ねえ、メッセージ見た？」というエネルギーが付いた通知に過ぎません。1週間後、私が作成中のコンポーネントを完全に変更するデザイン決定がFigmaのコメントスレッドに落ち、PRが却下されるまで知りませんでした。楽しかったですね。
ミュートの根本的な問題は、静的なルールを動的なコンテキストに適用することです。先週火曜日の通知設定は、今朝届いた緊急バグのことを知りません。そして積極的にミュートするほど、認識のギャップが広がります。そのギャップはチームメイトが「見た？」というDMで埋めます。つまり積極的なミュートは通知を減らしません。ボット（判断しない）から人間（確実に判断する）にシフトするだけです。
実際に割り込みを正当化する5つのシグナル
数週間にわたって通知を記録した後（プレーンテキストファイルで。通知アーキテクチャについての記事を書くような人間らしい記録法です）、パターンが現れました。1日約200件の通知のうち、1時間以内に実際にアクションが必要だったものは5つのカテゴリに分類されました：
- 誰かがあなたによってブロックされている。 あなたが所有するコードのPRレビューリクエスト、あなただけが答えられる質問、あなたのインプットを待っている決定。これは遅延に複利コストがかかる唯一のカテゴリです。あなたが応答しない1時間ごとに、誰かが作業できない1時間です。
- あなたがデプロイしたものが壊れている。 あなたのブランチのCIの失敗、マージ後のエラースパイク、リバートリクエスト。「あなたのコードが炎上している」カテゴリ。
- 現在の作業に影響する決定が下された。 デザイン変更、APIコントラクトの更新、プロダクト側からの優先度変更。これらは稀ですが、見逃すと高くつきます（上記の却下されたPRを参照）。
- デッドラインが移動した。 スプリントスコープの変更、デモが前倒しになった、依存関係がずれた。カレンダーを変えるイベント。
- 誰かがヘルプを必要としていて、あなたが適切な人物である。 すべての@channelではなく。すべての@hereでもなく。あなたの専門知識が本当に関連する特定のもの、それでも誰か他の人が答えられない場合のみ。
それ以外すべて、ステータス遷移、自動化されたボットメッセージ、「いいね」の絵文字リアクション、見ていないブランチのCIパス、これらはいつか役立つかもしれない情報ですが、書いている関数を中断させる必要はありません。通知産業複合体は、これらすべてが同等の緊急性に値すると私たちを説得してきました。そうではありません。
1日200件の通知のうち、実際に作業を中断させるに値するのは約5つのカテゴリのみです。残りはいつか役立つかもしれない情報です。しかしツールはすべてを同等に緊急として扱うため、結果として何も緊急ではなくなります。
アーキテクチャに裏切られた者のためのトリアージフレームワーク
今日から使い始められるフレームワークを紹介します。ツールは不要で、規律と約20分のセットアップだけです。アーキテクチャの問題は解決しません（重複排除レイヤー以外に解決できるものはありません）が、長期的な解決策を評価する間、出血を止めるでしょう。
1日2回のスイープ： 通知を継続的にチェックする代わりに、2回のスイープにまとめます。午前中に一度、午後に一度です。各スイープ中に、GitHub通知、Linearインボックス、Slackの未読を確認し、それぞれを3つのバケットに分類します：
| バケット | ルール | アクション | |--------|------|--------| | 今すぐ対応 | 誰かがブロックされている、何かが壊れている、または決定が必要 | 即座に処理 | | バッチ | 重要だが時間的に余裕がある | 「後で返答」リストに追加し、1日の終わりに処理 | | アーカイブ | ボットのチャット、ステータス更新、解決済みスレッド、重複 | 既読にして先に進む |
SlackでチャンネルレベルのデフォルトをSet: 各チャンネルについて決定します：これは「今すぐ対応」チャンネル（チームのワーキングチャンネル、インシデントチャンネル）か「バッチ」チャンネル（一般的なアナウンス、クロスチームの更新）か？バッチチャンネルをミュートし、スイープ中にのみチェックします。はい、これは技術的にはミュートです。先ほど2段落費やして批判したものです。違いは、存在しないふりをするのではなく、スケジュールに従ってチェックしている点です。
GitHubの通知フィルターを使用する： github.com/notifications?query=reason:review-requestedをブックマークしてください。このURLはあなたに明示的に割り当てられたPRレビューのみを表示し、購読済み・CIのノイズを完全にカットします。メールの場合、GitHubには理由ヘッダー（review_requested、mention、subscribed、ci_activity）が含まれており、フィルタリングできます。「subscribed」と「ci_activity」を自動アーカイブすれば、実際に必要なものを失いません。GitHubがこの有用なメタデータを通知UIではなくメールヘッダーに埋め込んでいるという事実は、これらのシステムの消費側にどれだけ思考が注ぎ込まれているかをすべて物語っています。
このアプローチはコンテキスト的なシグナルをキャッチしません（私のPRを台無しにしたFigmaのコメントを覚えていますか？1日2回のスイープもそれをキャッチしなかったでしょう）。しかしノイズを60〜70パーセント削減するでしょう。それは、本当の解決策が必要かどうかを評価しながら、強迫的なalt-tabをやめるのに十分です。
重複排除レイヤーが実際に何をする必要があるか
ここでアーキテクチャ的に興味深くなります。そして私がこれを通知設定の問題から分類問題として考え始めた転換点です。
単純なアプローチはキーワードマッチングとメンション検出です。あなたの名前が現れたらサーフェスする。あなたに割り当てられたレビューリクエストならサーフェスする。これは明らかなケースをキャッチしますが、コンテキスト的なケースは完全に見逃します。誰もあなたに@メンションしなかったスレッドのデザイン決定（あなたが影響を受けるコンポーネントを作成していることを気づいていなかったため）。（これはしばらく私を悩ませるでしょう。）
実際に必要なのは関係のグラフです：どのタスクがあなたのものか、どのPRがどのissueに関連しているか、どのSlackスレッドがどの機能についてのものか、どの人々がどのトピックであなたのインプットを必要とする傾向があるか。新しいシグナルが届いたとき、Slackメッセージ、GitHubイベント、Linearの遷移、それをそのナレッジグラフに対して分類します。「これはChrisに言及していますか？」ではなく「これはChrisが積極的に取り組んでいる、待っている、または責任がある何かに影響しますか？」
分類は次のようなものに分解する必要があります：
| 分類 | 意味 | アクション | |---------------|---------------|--------| | 緊急 | 誰かをブロックしている、または何かが壊れている | 即座にサーフェス | | 重要 | 現在の作業に影響するが、時間的に重要ではない | 日次ダイジェストにバッチ | | 情報 | 知っておくと良い、アクション不要 | 探しに行けば利用可能 | | ノイズ | 重複、ボットのチャット、解決済みスレッド | 完全にフィルタリング |
難しいのは、分類の確信度がバイナリではないことです。決して訪れないチャンネルのSlackメッセージが、あなたに割り当てられたissueを参照していれば緊急かもしれません。数ヶ月触れていないリポジトリのGitHub通知が、誰かが修正したと思っていたバグを再オープンしたばかりであれば重要かもしれません。2つのレイヤーが協調して動作する必要があります：受信したウェブフックを複合キー（リポジトリ、issue ID、アクター、イベントタイプ）でハッシュし、TTL付きの重複排除ウィンドウ（最近のイベントフィンガープリントのスライディングウィンドウ）と照合するイベント正規化レイヤー、その背後にタスクの所有権、PRのリンク、スレッドの参加者、最近のアクティビティパターンをマッピングするライブな関係グラフ。チームの作業状態全体のリードモデルをほぼリアルタイムで更新し、受信するシグナルごとにクエリするものを構築しています。重複排除レイヤーは明らかな重複をキャッチします。ナレッジグラフはより難しい質問に答えます：「これは今、あなたにとって具体的に関連しているか？」
コアの分類ループは明確なケースを十分に処理し、それだけでノイズを大幅に削減しますが、本当に曖昧なシグナル（抑制するほど確信がないが、サーフェスするほど確信がないもの）はまだ未解決の問題です。それらを「maybe」ダイジェストにバッチする実験をしていますが、解決したとは言いません。
ホースが止まったとき何が変わるか
予期しなかったこと、単純に「通知が少ない」だけだと本当に思っていたのですが、それ以上のことがあります。ツールが叫ぶのをやめると、ツールとの関係が劇的に変わります。
すべての通知が重要かもしれないとき、未読数に対する低レベルの不安が生まれます。太字のチャンネル名が並ぶSlackのサイドバー。GitHubのベル。Linearのインボックス。緊急なものを期待してではなく、何かを見落とすコストが50件のノイズをチェックするコストより高く感じるため、強迫的にチェックします。関数シグネチャと本文の間にSlackにalt-tabしていました。意識的な決定ではなく、赤信号でミラーを確認するような反射でした。
予防的な自己中断は、通知そのものよりも悪いと言えます。なぜならピングが届く前に自分の集中を壊しているからです。常に部分的な注意の状態で生活していて、書くコードにそれを感じます。浅いレビュー、より安全なアーキテクチャの選択、実際に正しいアプローチではなく最小抵抗の道、なぜなら45分の中断なし思考時間が得られると信頼できないからです。
ホースが止まったとき、重要なシグナルが届き、ノイズが届かないと信頼したとき、その反射は薄れます。すぐにではなく、古い習慣は頑固だからです。しかし2週間もすれば、強迫的なalt-tabなしにエディターで長い時間を過ごしていることに気づきます。考えを完成させ始めます。より良いコードを書きます。突然賢くなったからではなく、頼んでもいない通知システムの代わりに1時間に30のコンテキストスイッチを自発的に行うのをやめたからです。
通知の波に溺れるのをやめましょう。SugarbugはLinear、GitHub、Slackのすべてのシグナルを関連性によって分類し、実際に必要なものだけを表示します。
Q: SugarbugはLinear、GitHub、Slackの通知過多を解消できますか？ A: はい。SugarbugはAPIを通じてLinear、GitHub、Slackに接続し、すべてのシグナルを緊急度と関連性で分類します。すべての通知を転送するのではなく、注意が必要なものだけを表示します。1日数百件の通知が本当に必要な少数に減ることが一般的です。
Q: SugarbugはGitHub PRの通知を作業内容に基づいて優先できますか？ A: Sugarbugはタスク、PR、会話のナレッジグラフを構築します。どのPRが現在の作業に関連しているかを把握し、レビューリクエスト、マージコンフリクト、CIの失敗を優先的に表示し、残りは静かにファイルします。
Q: SugarbugはSlackの組み込み通知設定とどう違いますか？ A: Slackの設定ではチャンネルをミュートしたりキーワードを設定したりできますが、ツールをまたいだコンテキストを理解できません。SugarbugはLinear、GitHub、Slackをまとめて読み取るため、あなたが作成したPRに関するSlackのスレッドがミュート済みチャンネルにあっても、緊急であることを認識します。
Q: エンジニアチームにとっての通知過多の実際のコストは何ですか？ A: UCアーバイン校のグロリア・マークの研究によると、中断後に深い集中を取り戻すには約23分かかるとされています。通知そのものだけでなく、それが生み出す強迫的なチェック行動が、複雑なエンジニアリング作業に必要な持続的な集中を断片化させます。
エンジニアリングチームへの通知が「情報を保持する」から「不安を保持する」という線を越えたなら、それはおそらく通知の設定ではなく、アーキテクチャを修正する必要があるサインです。