GitHub通知設定を整理して、メール疲れから抜ける

結論: Watch設定・Subscription整理・メールフィルタの3段階で、GitHub通知は劇的に静かにできる。

GitHubの通知は、放置すると1日数十件を軽く超えます。 PRのコメント、CI失敗アラート、Dependabotの依頼——どれも無視できそうで、でも全部読む時間もない。 気づけばメール受信箱がGitHub一色になり、本当に大切なメッセージを見落とす、という悪循環に陥りがちです。

この記事では「全通知をオフにする」という乱暴な解決ではなく、必要な通知だけを届けるための設定を順番に説明します。

• そもそもGitHubの通知はどこから来るのか
• Watch設定を見直す(最大の効果)
• Subscriptionを一括解除する
  • 解除の手順
• Settings → Notificationsで「届ける種別」を絞る
• メールフィルタで仕分けを自動化する
  • Gmailでの基本フィルタ例
• GitHub Mobile で「本当に緊急のもの」だけ拾う
• 設定後の確認チェックリスト
• FAQ

§そもそもGitHubの通知はどこから来るのか

GitHubの通知経路は大きく3つあります。

最初に理解しておきたいのは、「通知が多い」原因はほぼ Watch設定 か Subscription(個別スレッド購読) のどちらかに絞られるという点です。 根本の設定をいじらずにメールフィルタだけで対処しても、受信件数は減らないので、順番どおりに進めるのが近道です。

§Watch設定を見直す(最大の効果)

最初は「Watchすれば全部追える」と思っていましたが、実際には参照用のリポジトリにWatchをつけていただけで、毎朝30件以上のメールが届いていました。設定を整理してからは、本当に自分が関わるものだけが届くようになりました。

github.com/watching にアクセスすると、現在Watchしているリポジトリの一覧が表示されます。

Watchのレベルは4段階あります。

• Participating and @mentions — 自分が関与したスレッドと@メンションのみ
• All Activity — すべての Issue・PRコメントを受け取る
• Ignore — 何も受け取らない
• Custom — 指定したイベント種別のみ

大半のリポジトリは「Participating and @mentions」で十分です。 「All Activity」にするのは、自分がオーナーのリポジトリや、リリース監視が必要なライブラリに限定すると通知量が大幅に減ります。

余談ですが、GitHubの公式ドキュメントでは「参加(Participating)」の定義を「コミット・コメント・レビュー・担当者への登録のいずれか」としています(GitHub Docs)。思ったより広い定義で、レビュアーに登録されただけでも通知が飛んできます。

§Subscriptionを一括解除する

Watchとは別に、個別のIssueやPRに「購読」している状態があります。 コメントを書いた、@メンションされた、アサインされた——これらのアクションが自動でSubscriptionを生成します。

古いIssueの議論に1回だけ参加して、その後ずっと通知を受け続けているケースが典型的です。

§解除の手順

1. github.com/notifications/subscriptions を開く
2. リポジトリ名でフィルタリングして古いものを特定する
3. 不要なものを選択して「Unsubscribe」

数が多い場合は、リポジトリ名を絞り込んで一括選択するのが早いです。 古いプロジェクトのリポジトリを一巡すると、17件前後のゾンビSubscriptionが見つかることが多い印象です。

§Settings → Notificationsで「届ける種別」を絞る

Watch設定とSubscriptionを整理したら、次は全体のポリシー設定を確認します。

Settings → Notifications(直接リンク)で設定できる主な項目は以下です。

「GitHub Actions」の通知はデフォルトで「すべて」になっています。 CIが頻繁に走るプロジェクトでは、ここを「失敗のみ」に変えるだけで通知が半減することもあります。

§メールフィルタで仕分けを自動化する

上記の設定をしても、メールが届く種別はある程度残ります。 そこで最後の仕上げとして、メールフィルタで受信箱を守ります。

GitHubが送るメールには、自動でヘッダが付いています。

X-GitHub-Reason: mention
X-GitHub-Reason: review_requested
X-GitHub-Reason: author
X-GitHub-Reason: subscribed

GmailやOutlookはヘッダ検索に対応していないことも多いですが、Subjectとfromアドレスを組み合わせたフィルタで実用レベルの仕分けは可能です。

§Gmailでの基本フィルタ例

from:(notifications@github.com)
subject:([reponame/projectname])

これでラベルを自動付与し、受信箱をスキップさせる設定にすると、「確認したいときにラベルを開く」スタイルに移行できます。

ここは賛否ありますが、「全件をInboxで受け取ってから読む」より「必要なときに能動的に確認する」ほうが精神的に楽、という人が多いようです。

§GitHub Mobile で「本当に緊急のもの」だけ拾う

メールとWebの設定を整えたうえで、プッシュ通知は**@メンション限定**に絞るのがバランスの良い運用です。

GitHub Mobileアプリ(iOS/Android、2026年4月時点でバージョン1.x系が最新)では、アプリ内の「Notifications → Configure」からプッシュ通知のイベント種別を細かく選べます。

• @mentions のみON
• Review requestsのみON
• それ以外はOFF

これにより、本当に自分の返答が必要なものだけがスマートフォンに届くようになります。 スマートフォンの通知量が多いと睡眠前にも気になりやすくなるので、寝る前のスマートフォン時間を減らすという視点でも整理する価値があります。

§設定後の確認チェックリスト

一通り設定したあと、翌朝に確認するポイントをまとめます。

1. メール受信箱に来たGitHubメールの件数が減っているか
2. github.com/notifications のInboxに必要な通知が残っているか
3. 重要なPRや@メンションを見落としていないか
4. Dependabotのアラートが溜まりすぎていないか(週1確認の習慣をつける)

設定直後は少し過剰に静かになる感覚があります。1週間ほど運用して、見落としたものがあれば該当リポジトリのWatchレベルを上げ、逆にまだ多ければSubscription一覧を再確認する——という微調整を繰り返すと自分にフィットした状態に落ち着きます。

§FAQ

Q. TeamやOrganizationの通知はどこで設定する? A. OrganizationごとにWatchのデフォルト設定があります。github.com/organizations/{org名}/notifications(または Organization Settings → Member privileges)で、新しくフォークしたリポジトリのWatchレベルを「Participating only」にしておくと、入社直後に大量通知を受け取る事態を防げます。

Q. Dependabotのアラートだけ別メールにまとめたい。 A. GitHubのメールSubjectには [Dependabot] という文字列が含まれるため、Gmailでは from:notifications@github.com subject:[Dependabot] のフィルタでラベル分けが可能です。週1回まとめて確認するラベルを作っておくと管理しやすくなります。

Q. 通知を絞りすぎてレビュー依頼を見落とした場合は? A. github.com/notifications のInboxには、メール通知をOFFにしていてもWeb通知は残ります。「Review requested」フィルタをかけたブックマークを作っておき、朝イチで確認する習慣を持つと安全網になります。

Q. GitHub ActionsのCI失敗通知だけ受け取りたい。 A. Settings → Notifications → GitHub Actions で「Send notifications for failed workflows only」を選択します。成功通知はこれでカットされ、CIが頻繁に走るプロジェクトでも通知量が大幅に減ります。