GitHubとSlackを連携する方法（通知の洪水を避けて）
GitHubをSlackに正しく接続する – 公式インテグレーションの設定、ラベルとブランチによる通知フィルタリング、チャンネルを有用に保つ方法。
By Ellis Keane · 2026-03-19
デプロイが失敗しました。チームが作業調整に使っているSlackチャンネルは静まりかえっています – GitHub Actionsのアラートは#github-notificationsに投稿されましたが、数週間前に全員がそのチャンネルをミュートしていたのです。
GitHubとSlackを連携する方法を調べているなら、おそらくそういった経験をしたからでしょう。接続のセットアップ自体は数分で完了します（私はミーティングの合間にセットアップしましたが、振り返ってみれば楽観的すぎました）。実際に役立つ状態にするにはもう少し時間がかかります。このチュートリアルではそこをカバーします。
公式GitHub-Slackインテグレーションができること（できないこと）
GitHubの公式Slackアプリは、PR、イシュー、デプロイ、コミットに関する通知をSlackチャンネルに投稿します。チャンネルを特定のリポジトリに紐付け、イベントタイプでフィルタリングし、Slackから直接一部のアクションを実行できます – イシューのクローズや新規作成といった操作です。
できないのはコンテキストを理解することです。READMEのタイプミス修正が本番環境のホットフィックスと同じ扱いを受けます。ボットが開いた依存関係のバンプが重大なセキュリティパッチと並列で表示されます。インテグレーションはパイプであってフィルターではありません – そしてパイプは流れるものをコントロールできてこそ価値があります。
"インテグレーションはパイプであってフィルターではありません – そしてパイプは流れるものをコントロールできてこそ価値があります。" attribution: Chris Calo
（ほとんどのチームは1週間ほどで気づきます。#engineeringが誰も見たくないコミットのティッカー表示になった頃です。）
GitHub Slackアプリのセットアップ
3ステップで完了します:
- SlackにGitHubアプリをインストールする。 SlackワークスペースのアプリディレクトリにアクセスしてGitHubを検索してください。ワークスペースの管理者権限、もしくはそれを持つ人の協力が必要です。
- 認証する。 任意のチャンネルで
/github signinと入力します。これでGitHubアカウントがSlackにリンクされ、よりリッチな通知が表示され、会話を離れずにイシューを操作できます。
- チャンネルをリポジトリに紐付ける。 通知を受けたいチャンネルで:
``` /github subscribe owner/repo-name ``` デフォルトではissues、pulls、commits、releases、deploymentsの5種類のイベントタイプを購読します – ほとんどのチャンネルには多すぎます。
- すぐに整理する。 チャンネルの目的に合わないものを解除します:
``` /github unsubscribe owner/repo-name commits ``` 多くのエンジニアリングチームにとって、pullsとdeploymentsは価値があります。issuesはチームがGitHubでトリアージするかLinearなどの別のトラッカーを使うかによります。commitsはほぼ常にノイズです – コード変更を確認したいなら、PRを見てください。
完全なコマンドリファレンスはインテグレーションリポジトリのドキュメントにあります。
まず購読し、チャンネルの目的に合わないイベントタイプはすぐに解除しましょう。デフォルトの「全部」購読がほとんどのチームがチャンネルをミュートしてしまう原因です。
実際に役立つGitHub Slack通知の連携方法
ほとんどのチュートリアルはここで終わり、多くのインテグレーションが静かに使われなくなります。subscribe/unsubscribeシステムはおおまかなもの – すべてのPRかゼロか、すべてのイシューかゼロかです。40人のコントリビューターがいるモノレポなら、「全PRを受け取る」は水道の蛇口全開と同じです。
ラベルベースのフィルタリングが回避策であり、あまり使われていません。ラベルで通知をフィルタリングできます:
``` /github subscribe owner/repo-name +label:"needs-review" ```
これでチャンネルはneeds-reviewタグが付いたPRやイシューのみを受け取ります。ラベルを一貫して使用しているチーム（これは簡単なことではなく、本当のコミットメントが必要です）にとって、インテグレーションがうるさいものから有用なものに変わります。注意が必要なPRがSlackに表示され、それ以外はGitHubに留まります。
ワークフローランのフィルタリングでブランチごとにCI通知を絞り込めます:
``` /github subscribe owner/repo-name workflows +branch:main ```
これによりmainブランチで実行されたワークフローのみ表示されます – フィーチャーブランチのCI実行ではなく。デプロイにGitHub Actionsを使用しているチームなら、開発ブランチの緑のチェックマークの流れなしに本番に関連するアラートを受け取れます。
チャンネルアーキテクチャが重要です。 すべてに対して単一の#githubチャンネルはミュートへの近道です。分割を検討してください:
| チャンネル | 購読内容 | |---------|--------------| | #deploys | deploymentsのみ | | #pr-reviews | pulls +label:"needs-review" | | #incidents | issues +label:"P0" |
3つの特化チャンネルは1つのうるさいチャンネルよりも優れています。それぞれに明確な目的があり、チームメンバーは自分の役割に関連するものに参加できます。（当たり前に聞こえるかもしれませんが、Slackボット、GitHub通知、デプロイアラート、一般的なチャットを1つの#devチャンネルで処理しているチームを見たことがあります。それは混乱のもとです。）
設定する価値のある3つのワークフロー
古いPRのスケジュールリマインダー。 GitHubのスケジュールリマインダーは、PRがレビュー待ちのときにSlackにアラートを届けます。SlackコマンドではなくGitHubのWeb UI（Settings → Scheduled Reminders）で設定します。誰も気づかずにバックログで静かに老朽化するPRを防ぎます。
デプロイプレビューリンク。 PRがデプロイメントプレビュー（Vercel、Netlifyなど）をトリガーすると、そのステータスがSlack通知に表示されます。デザイナーはGitHubを開かずにプレビューURLをクリックできます – レビューごとに1回のコンテキストスイッチが減ります。
スレッドベースの会話。 PR通知へのコメントはSlackスレッドに留まります。「良さそうです、47行目に1点だけ」というコメントが他のコンテキストと同じ場所にあります。コメントはGitHubに同期されません（Slackのみ）– これは制限でもあり、ある意味では機能でもあります。
ネイティブインテグレーションの限界
公式インテグレーションは多くのことをカバーしますが、対応できないパターンもあります:
クロスリポジトリの可視性。 プロジェクトが3つのリポジトリにまたがる場合、3つの別々の購読と3つの別々のフィルタ設定が必要です。「Project Xに関連するすべてをリポジトリ横断で見せて」という機能はありません。並行設定を管理し、一貫性が保たれることを期待するしかありません。
GitHubをイシュートラッカーに接続する。 チームがタスクの情報源としてLinearを使用している場合、GitHub-Slackインテグレーションはその関係を知りません。PRがLinearのイシューをクローズしても、Slackはそれを知りません – 通知には「PRがマージされました」とだけ表示され、それがどのタスクのためであったか、誰が待っていたかのコンテキストはありません。
スケールでのラベル管理。 ラベルベースのフィルタリングは機能しますが、一貫性が必要です – 誰かがラベルを適用する必要があり、PRがラベルなしでリリースされた瞬間にフィルターが機能しなくなります。チームが大きくなるにつれてメンテナンスのオーバーヘッドが増えます。ある時点で、フィルターを正確に保つために費やす時間が、フィルターで節約できる時間を超えてしまいます。
（これがチームがZapierやカスタムボットに頼り始めるポイントです。Webhookの認証が失効したり、レート制限がかかったり、担当者が退社してどう繋がっているか誰も覚えていないという事態になるまでは機能します。）
継続的に機能させるために
GitHub-Slackインテグレーションは、うまく設定されていれば透明で（存在を忘れるほど自然に機能する）、設定が悪ければ積極的に嫌われるツールの一つです。違いはセットアップにあります:
- チャンネルの目的に合ったイベントタイプのみを購読する
- ラベルとブランチのフィルターを使ってSlackに届く前にノイズを削減する
- 1つのキャッチオールではなく、特化チャンネルに通知を分散させる
- GitHubのWeb UIから古いPRのスケジュールリマインダーを設定する
- ネイティブインテグレーションには限界があると認識する – クロスリポジトリのコンテキストやイシュートラッカーとの連携が重要な場合は、そのレイヤー向けに設計されたツールを検討する
GitHubをSlackと連携させたい場合、ネイティブアプリが正しい出発点です。上記のフィルタリングとチャンネルアーキテクチャのヒントにより、最初の1週間以降も有用な状態を保てます。そして、通知パイプができることを超えた場合 – PRとそれが属するLinearチケット、アプローチが議論されたSlackスレッドとの関係が欠けているピースなら – それこそがSugarbugで解決しようとしていることです。
GitHub、Linear、Slack、Figmaをひとつのナレッジグラフにつなぎ、すべてのPRが属する会話とチケットにリンクします。
Q: GitHubとSlackを連携するにはどうすればいいですか？ A: SlackのアプリディレクトリからGitHubアプリをインストールし、/github signinで認証した後、/github subscribe owner/repo-nameでチャンネルをリポジトリに紐付けてください。イベントタイプはすぐに整理しましょう – デフォルトはすべてのイベントが含まれており、ほぼ常にノイズが多すぎます。
Q: SugarbugはGitHub-Slackインテグレーションの代わりになりますか？ A: Sugarbugは代替ではなく併用するものです。ネイティブインテグレーションが通知を処理し、SugarbugはGitHubのPRを対応するLinearのイシュー、Slackのディスカッション、Figmaのデザインとつなぐナレッジグラフをつくります – PRがマージされたという事実だけでなく、変更の全コンテキストが把握できます。
Q: SlackでGitHub通知をラベルでフィルタリングするにはどうすればいいですか？ A: 購読時にラベルフィルターを使用してください: /github subscribe owner/repo-name +label:"needs-review"。そのラベルが付いたアイテムのみがチャンネルに投稿されます。複数のラベルフィルターを組み合わせたり、イベントタイプの購読と混在させることができます。
Q: SugarbugはGitHubのアクティビティをSlackとLinear全体で自動的に追跡しますか？ A: はい。SugarbugはAPI経由でGitHub、Slack、Linearに接続し、それらのアクティビティを相互に関連付けます – GitHubのPRがSlackの会話を参照したり、Linearのチケットをクローズしたりすると、手動でタグ付けやラベル管理をしなくてもナレッジグラフにその関係が記録されます。