GitHub Notificationsの「カスタムスレッド購読が廃止され、通知が一気に増えるのではないか」と心配している場合、まず最新状況を確認しておきましょう。
GitHubは2026年8月10日にカスタムスレッド購読の廃止を発表しましたが、同年8月14日に計画を一時停止しました。 Customizeは復元され、Subscribedへ変換された既存のカスタム購読についても、以前の設定へ戻るはずだと案内されています。
そのため、2026年9月2日時点では、通知増加を避けるためにすべてのスレッドを慌ててUnsubscribeする必要はありません。ただし、重要なIssueやPull Requestについては、購読状態が意図どおり戻っているか確認するのが安全です。(The GitHub Blog)
GitHubカスタムスレッド購読の廃止は一時停止されている
GitHubカスタムスレッド購読の廃止を巡る経緯は、次のとおりです。
| 日付 | 発表内容 | 利用者への影響 |
|---|---|---|
| 2026年8月10日 | カスタムスレッド購読の廃止を発表 | Customizeを削除し、既存設定をSubscribedへ変換する予定だった |
| 2026年8月14日 | 廃止計画を一時停止 | Customizeを復元し、変換済みの設定も以前の状態へ戻す方針 |
| 2026年9月2日時点 | 機能を継続提供 | IssueやPull RequestでCustomizeを利用できる |
当初の計画では、スレッド単位の通知設定からCustomizeを削除し、選択肢を次の2つに絞る予定でした。
SubscribedNot subscribed
さらに、既存のカスタム購読はすべてSubscribedへ変換され、そのスレッド内の全イベントについて通知を受け取る仕様になると説明されていました。
しかし、高頻度で更新されるリポジトリの通知管理に欠かせないという利用者の意見を受け、GitHubは発表から4日後に計画を一時停止しました。現在は機能の価値や今後の通知設計を改めて検討している段階です。(The GitHub Blog)
なお、「一時停止」は永久的な廃止撤回を意味するものではありません。将来、別の形で通知機能が変更される可能性はあるため、GitHub Changelogの更新は引き続き確認する必要があります。
カスタムスレッド購読とは
カスタムスレッド購読は、個別のIssueやPull Requestについて、どのタイミングで通知を受け取るかを細かく指定する機能です。
対象のIssueまたはPull Requestを開き、右側のNotifications付近にあるCustomizeから設定します。Customを選択すると、マージ、クローズ、再オープンなど、通知を受け取りたいイベントを絞り込めます。(GitHub Docs)
たとえば、Pull Requestのレビュー中にすべてのコメントを追う必要はなく、最終的にマージされたかどうかだけ知りたい場合に役立ちます。
| 設定 | 通知の受け取り方 | 適したケース |
|---|---|---|
Subscribed | スレッドの更新を広く受け取る | 担当中のIssueや自分がレビューしているPull Request |
Custom | 指定したイベントだけ受け取る | マージ、クローズ、再オープンだけ確認したい |
Unsubscribe | 通常の更新通知を停止する | 対応が完了し、継続的に追う必要がない |
リポジトリ単位のCustom設定とは別の機能
GitHubには、リポジトリのWatchメニューにもCustomがあります。
こちらは、リポジトリ全体について通知対象を次のような種類から選ぶ機能です。
- Issues
- Pull requests
- Releases
- Discussions
- Security alerts
今回、廃止対象として発表されたのは、個別のIssueやPull Requestに設定するスレッド単位のカスタム購読です。
リポジトリ単位のWatch設定とスレッド単位のCustomizeは、名前が似ていますが設定範囲が異なります。通知を見直す際は、どちらを変更しているのか確認してください。(GitHub Docs)
当初の廃止計画で通知が増えるとされた理由
当初の計画では、既存のカスタム購読がSubscribedへ自動変換される予定でした。
たとえば、次のような設定をしていたケースを考えます。
Pull Requestがマージまたはクローズされたときだけ通知を受け取る
これがSubscribedに変換されると、状態変更だけでなく、そのスレッドで発生する各種更新について通知を受け取る状態になります。
活発なPull Requestでは、コメント、レビュー、修正、状態変更などが短時間に繰り返されます。複数の高頻度リポジトリを扱っている開発者ほど、通知が急増する可能性がありました。
現在は廃止計画が一時停止されているため、この変換を前提に運用を変更する必要はありません。ただし、一時的な変換や設定復元の影響が疑われる場合は、重要なスレッドの設定を個別に確認しましょう。
GitHub通知が急に増えたときの対処法
通知が増えた場合、カスタムスレッド購読の廃止だけを原因と決めつけず、スレッド、リポジトリ、受信箱の順に確認すると効率的です。
個別スレッドの購読状態を確認する
通知が多いIssueまたはPull Requestを開き、右側のNotificationsを確認します。
必要なイベントだけ受け取りたい場合
Customizeを選択する- ダイアログで
Customを選択する - 通知が必要なイベントを指定する
Saveを選択する
マージ結果やクローズだけ確認したいスレッドでは、SubscribedのままにするよりもCustomが適しています。現在のGitHub公式ドキュメントでも、IssueやPull Requestの右側からCustomizeを選び、通知条件を指定する手順が案内されています。(GitHub Docs)
もう追う必要がない場合
対象スレッドでUnsubscribeを選択します。
ただし、購読解除後でも、次のような場合は再び通知されることがあります。
- 自分のユーザー名がメンションされた
- 所属チームがメンションされた
- Pull Requestのレビューを依頼された
- 自分が再びスレッドへ参加した
Unsubscribeは、そのスレッドから永久にすべての通知を遮断する機能ではありません。必要な依頼まで見逃しにくい仕組みになっています。(GitHub Docs)
Subscriptionsページで購読をまとめて確認する
どのスレッドを購読しているか分からない場合は、GitHub NotificationsのSubscriptionsページを利用します。
- GitHub右上の通知アイコンを開く
Manage notificationsを選択するSubscriptionsを開く- リポジトリや購読理由で絞り込む
- 不要なスレッドを選択して
Unsubscribeする
購読一覧では、リポジトリや通知理由による絞り込みに加え、購読した時期で並べ替えられます。古い購読を探す場合は、購読日時が古い順に確認すると、忘れていたIssueやPull Requestを見つけやすくなります。(GitHub Docs)
ただし、一括解除する前に、担当中のIssueやレビュー待ちのPull Requestが含まれていないか確認してください。
リポジトリ全体のWatch設定を見直す
特定のスレッドではなく、同じリポジトリから大量の通知が届く場合は、リポジトリ単位のWatch設定が原因かもしれません。
Manage notificationsからWatched repositoriesを開き、各リポジトリの設定を確認します。
| 状況 | 適した設定 |
|---|---|
| リポジトリ内の全活動を追いたい | All Activity |
| IssueやReleaseなど一部だけ必要 | Custom |
| 自分が参加・メンションされた場合だけ必要 | Participating and @mentions相当の状態 |
| 今後ほとんど関わらない | Unwatch |
リポジトリをUnwatchしても、自分が会話に参加した場合やメンションされた場合は通知対象になることがあります。すべてのリポジトリ更新を追う必要がない場合は、CustomまたはUnwatchへ変更すると通知量を減らせます。(GitHub Docs)
通知フィルターだけでは通知量そのものは減らない
GitHub Notificationsの受信箱には、通知を整理するためのカスタムフィルターがあります。
たとえば、次のような条件を利用できます。
reason:review-requested
自分または所属チームにレビュー依頼が届いた通知を表示します。
reason:mention
自分が直接メンションされた通知を表示します。
repo:owner/repository reason:participating
特定リポジトリのうち、自分が参加しているスレッドの通知を表示します。
そのほか、org:、author:、is:unreadなども利用できます。GitHubの受信箱には最大15件のカスタムフィルターを作成できます。(GitHub Docs)
ただし、受信箱のフィルターは届いた通知を見やすく分類する機能です。スレッドの購読やメール配信そのものを停止するわけではありません。
通知量を実際に減らすには、目的に応じて次の設定を使い分けます。
- 個別スレッドの通知を減らす:
CustomizeまたはUnsubscribe - リポジトリ全体の通知を減らす:
Watch設定を変更 - メール通知を減らす:GitHubの通知設定でメール配信先や対象を変更
- 受信箱を整理する:カスタムフィルター、
Done、Save
DoneとUnsubscribeを混同しない
GitHub Notificationsでは、DoneとUnsubscribeの違いが重要です。
| 操作 | 現在の通知 | 今後の通知 |
|---|---|---|
Done | 受信箱から片付ける | 購読は継続する |
Unsubscribe | 受信箱から削除する | 通常の更新通知も停止する |
Save | 後で確認できるよう保存する | 購読状態は変更しない |
Mark as read | 既読にする | 購読状態は変更しない |
通知を読んだだけで今後も追いたい場合はDone、今後の通常更新が不要な場合はUnsubscribeを選びます。
通知を減らしたいのにDoneだけを使っていると、そのスレッドが更新されるたびに新しい通知が届きます。(GitHub Docs)
フィルター依存の運用を見直す方法
カスタムスレッド購読の廃止計画は一時停止されましたが、GitHubが通知機能の全体的な見直しを続けている点には注意が必要です。
将来の仕様変更に備えるなら、「すべて購読してフィルターで隠す」運用から、通知の重要度に応じて購読範囲を分ける運用へ移行するのが現実的です。
対応が必要な通知
次の通知は、専用フィルターを作って優先的に確認します。
reason:review-requested
reason:mention
reason:team-mention
reason:assign
レビュー依頼や担当割り当ては、他の通知に埋もれると開発を止める原因になります。
結果だけ確認したいスレッド
マージ、クローズ、再オープンなど、特定の状態変更だけ知りたい場合は、スレッド単位のCustomizeを利用します。
参考として参加したスレッド
継続的な対応が不要になった段階でUnsubscribeします。後から確認したい通知はSaveを使い、購読と保管を分けると受信箱を整理しやすくなります。
チームでルールを決める
チーム開発では、次のような基準を決めておくと通知設定が属人化しにくくなります。
| 通知の種類 | 推奨する管理方法 |
|---|---|
| レビュー依頼 | reason:review-requestedで優先表示 |
| 自分へのメンション | reason:mentionで優先表示 |
| 担当Issue | reason:assignで管理 |
| 状態変更だけ必要なPR | スレッドのCustomize |
| 対応終了済みのスレッド | Unsubscribe |
| 後で読み返す情報 | Save |
GitHub公式ドキュメントでも、レビュー依頼、メンション、CI通知などを優先度別にフィルタリングし、不要な参加通知は解除する運用例が案内されています。(GitHub Docs)
既存のカスタム購読は確認しておくべきか
GitHubは、Subscribedへ変換されたカスタム購読について、以前の設定へ戻るはずだと説明しています。(The GitHub Blog)
ただし、業務上重要なスレッドについては、復元されたことを前提にせず、次の項目を確認しておくと安全です。
- 重要なPull Requestが
Subscribedのままになっていないか Customizeで指定していたイベントが維持されているか- 不要なスレッドを大量に購読していないか
- リポジトリ自体が
All Activityになっていないか - メールとGitHub受信箱の両方で通知を受け取っていないか
特に、通知が増えた時期が2026年8月10日から14日前後と重なる場合は、スレッド設定を優先して確認してください。
今後の廃止に備えて取るべき対応
2026年9月2日時点で、カスタムスレッド購読の廃止は実施されていません。Customizeも引き続き利用できます。
現時点で取るべき対応は、すべてのスレッドを一括で購読解除することではなく、次の3点です。
- 重要なIssueやPull Requestの
Customize設定を確認する SubscriptionsとWatched repositoriesで不要な購読を整理する- レビュー依頼やメンション用の受信箱フィルターを作成する
GitHubの通知が急に増えた場合も、まず個別スレッドの状態を確認し、必要なイベントだけならCustomize、不要ならUnsubscribeを選びます。
カスタム購読、リポジトリのWatch設定、受信箱フィルターを役割ごとに使い分けることで、今後GitHub Notificationsの仕様が変更されても、重要な通知を見逃しにくい運用を構築できます。

コメント