Slack（スラック）にGitHubのアプリを入れると、プルリクエストやIssueの動きがチャンネルに流れ、レビューを頼まれた人にはSlackでメンションが届きます。ただ、初期の状態のまま購読するとコミットのたびに通知が流れ、1週間ほどで誰も見ないチャンネルになります。ここでは社員20名ほどのWeb制作会社「サンプルデザイン」（プロプラン、エンジニア5名、GitHub.comを利用）の例で、GitHubアプリでできること、入れ方とGitHubの組織の承認、/github subscribe の書き方、案件のリポジトリの通知をプルリクエストとレビュー依頼だけに絞る設定、GitHub ActionsからIncoming Webhookで送る方法との使い分けまでを書きます。アプリの入れ方の全体は「Slackのアプリ連携：Googleカレンダー・Googleドライブ・GitHubをつなぐ」で1節だけ書いたので、ここではコマンドの書き方と、通知の量の決め方を詳しく扱います。内容は2026年11月時点のGitHubとSlackの公式の説明で確かめています。
この記事の内容
先に決めること
GitHubの通知は、何も決めずにつなぐと必ず多すぎます。次の5つは、エンジニアのリーダー（エンジニアC）とディレクターで先に決めておきます。
| 決めること | 迷ったときの考え方 | サンプルデザインの答え |
|---|---|---|
| GitHubの種類 | GitHub.comか、自社のサーバーのGitHub Enterprise Serverか | GitHub.com。Marketplaceの公開アプリを使う |
| 流す先のチャンネル | リポジトリか案件ごとに log- のチャンネルを分ける | 自社サイトは #log-github、A社の案件は #log-github-サイト改修 |
| 流す機能 | エンジニア以外も見るならプルリクエストとレビューだけ | プルリクエストとレビュー。Issueとコミットは流さない |
| 誰が入れるか | Slack側はアプリの承認、GitHub側は組織のオーナー | エンジニアCが入れ、Slackは代表、GitHubは組織のオーナー（代表）が承認 |
| 個人宛ての通知 | レビューを頼まれた人にはメンションで届ける | エンジニアとディレクターは全員 /github signin を済ませる |
迷いやすいのはチャンネルの分け方です。全部のリポジトリを1つのチャンネルに流すと、案件ごとの動きが混ざって追えません。サンプルデザインは「1つの案件に1つの pj- チャンネルと、必要なら1つの log-github- チャンネル」にしています。
GitHubアプリでできること
| できること | 中身 | 使い方 |
|---|---|---|
| 通知の購読 | リポジトリのプルリクエスト・Issue・コミット・リリース・デプロイなどをチャンネルに流す | /github subscribe |
| 通知のスレッド化 | Issueとプルリクエストの続きの通知は、最初のカードの下のスレッドにまとまる。カードには最新の状態が出る | 既定でオン。/github settings で切り替え |
| メンション | Issueの担当者、プルリクエストのレビュアー、本文やコメントで名指しされた人、デプロイのレビュアーにSlackで届く | 本人が /github signin を済ませる |
| Issueの作成 | Slackのメッセージから、その内容を説明に入れたIssueを作る | メッセージの3つのドットアイコン、または /github open |
| Issueの操作 | 届いたカードのボタンで、コメント・編集・クローズ・再オープン | カードのボタン |
| リンクの展開 | Issue・プルリクエスト・コメント・行番号つきのコードのリンクを貼ると中身が出る | リンクを貼るだけ |
| ワークフローの通知 | GitHub Actionsの実行の開始・承認の依頼・完了を流す。失敗したら再実行できる | /github subscribe ... workflows |
| デプロイの通知 | デプロイの状態の更新を流す | /github subscribe ... deployments |
| レビュー待ちのまとめ | レビュー待ちのプルリクエストを決まった時刻にまとめて流す | GitHubのチームの「Scheduled reminders」 |
Slackから操作できるのは、その人のGitHubの権限の範囲だけです。読む権限しかないリポジトリのIssueは、Slackからも閉じられません。
ワークスペースに入れて、GitHubとつなぐ
Slackのワークスペースに入れる
- Slack Marketplaceで「GitHub」のページを開きます。
- 「Slack に追加」をクリックし、アプリができることの一覧を確かめてアクセスを許可します。
サンプルデザインはアプリの承認制にしているので、エンジニアCが操作すると代表への承認リクエストになり、承認されると入ります。許可の画面には、プライベートな会話へのアクセス、github.comのリンクの表示、スラッシュコマンドの追加、アプリとしての投稿などが並びます。
GitHubの組織に入れる
Slack側に入れたあと、GitHub側でもアプリを組織に入れ、どのリポジトリを見せるかを選びます。組織にアプリを入れる権限が無いメンバーが、GitHubのアプリのインストールページ（GitHub Marketplaceではなく、アプリの公開ページ）から入れようとすると、組織のオーナーへのリクエストになり、オーナーにメールで知らせが届きます。オーナーはリクエストを見て入れるかどうかを決め、メンバーが選んだリポジトリを変えることもできます。
リポジトリの選び方は2通りです。「All repositories」を選んでおくと、あとで作ったプライベートのリポジトリもそのまま購読できます。一部のリポジトリだけを選んでいると、選んでいないリポジトリを購読しようとしたときに、追加のインストールを求められます。サンプルデザインは取引先の案件のリポジトリが多く、見せる範囲を絞りたいので、一部のリポジトリだけを選び、案件が始まるたびにエンジニアCが足しています。
各自がGitHubにサインインする
- Slackのどこかのメッセージ欄に
/github signinと入れて送ります。 - 表示される案内に従って、GitHubのアカウントで許可します。
/github signin を送ったあとに表示される、GitHubのアカウントをつなぐ案内のメッセージサインインしていない人には、レビューを頼まれてもSlackでメンションが届きません。また、複数のSlackのワークスペースで同じGitHubのアカウントを使っている人は、最後にサインインしたワークスペースでだけメンションが届きます。取引先のワークスペースにも入っているエンジニアは、自社のワークスペースでサインインし直します。
チャンネルにアプリを入れる
流したいチャンネルで、次を送ります。
/invite @githubプライベートチャンネルは、この招待をしないと通知が流れず、プライベートのリポジトリのリンクも展開されません。
/github subscribe の書き方
コマンドの一覧
| 書き方 | 何をするか |
|---|---|
/github subscribe owner/repo | リポジトリを購読する。既定でオンの機能が流れ始める |
/github subscribe owner/repo reviews comments | 機能を足す。複数をまとめて書ける |
/github unsubscribe owner/repo commits issues | 機能を外す |
/github unsubscribe owner/repo | リポジトリの購読をやめる |
/github subscribe list features | このチャンネルで購読しているリポジトリと機能を見る |
/github subscribe owner/repo commits:main | コミットの通知を特定のブランチにする |
/github subscribe owner/repo commits:* | すべてのブランチのコミットを流す |
/github subscribe owner/repo +label:"urgent" | ラベルが付いたものだけを流す |
/github subscribe owner/repo comments:"channel" | コメントをスレッドではなくチャンネルに流す |
/github settings | 通知のスレッド化を切り替える |
/github open | Issueを作る |
/github signin | 自分のGitHubのアカウントをつなぐ |
機能の一覧
| 機能 | 何が流れるか | 既定 |
|---|---|---|
issues | Issueの作成・クローズ | オン |
pulls | プルリクエストの作成・マージ、下書きからレビュー待ちへの変更 | オン |
commits | 既定のブランチへのコミット | オン |
releases | リリースの公開 | オン |
deployments | デプロイの状態の更新 | オン |
reviews | プルリクエストのレビュー | オフ |
comments | Issueとプルリクエストのコメント | オフ |
branches | ブランチの作成・削除 | オフ |
workflows | GitHub Actionsのワークフローの実行 | オフ |
discussions | Discussionの作成・回答 | オフ |
commits:all という書き方は前の書き方で、今は commits:* を使います。
ラベルで絞るときの決まり
ラベルの絞り込みは「このラベルが付いているものだけ通す」許可の一覧として働き、ラベルの無い通知は捨てられます。1つの購読に付けられる絞り込みは1つだけで、新しく書くと前の絞り込みと入れ替わります。効くのはプルリクエスト・Issue・コメント・レビューで、コミットとブランチには効きません。
日本語のラベル名は使わないほうが無難です。GitHubの説明には、絵文字以外の2バイトの文字は :foo: の形にしないと問題が起きることがある、と書かれています。また、カンマはコマンドの区切りに使われるので、ラベル名に入れません。サンプルデザインは急ぎのものに urgent という英語のラベルを付ける決まりにしています。
ワークフローを絞る
GitHub Actionsの通知は、名前・イベント・ブランチ・実行した人で絞れます。
/github subscribe sample-design/a-site-renewal workflows:{name:"deploy" branch:"main"}絞り込みを書かないと、既定のブランチを対象にした pull_request のワークフローが対象になります。個々のジョブの進み具合の通知は、2025年3月10日以降は届かなくなっています。
サンプルデザインの例：#log-github-サイト改修
A社のサイト改修の案件では、リポジトリ sample-design/a-site-renewal の通知を #log-github-サイト改修 に流しています。入るのは案件のエンジニア2名と担当のディレクターAで、流すのはプルリクエストとレビュー依頼だけです。
#log-github-サイト改修をプライベートチャンネルで作り、チャンネルの説明に「a-site-renewal のプルリクエストとレビュー。会話は #pj-a社-サイト改修 で」と書きます。- チャンネルで
/invite @githubを送ります。 - 次の3行を順に送ります。
/github subscribe sample-design/a-site-renewal
/github unsubscribe sample-design/a-site-renewal issues commits releases deployments
/github subscribe sample-design/a-site-renewal reviews/github subscribe list featuresを送り、pullsとreviewsだけが残っていることを確かめます。
#log-github-サイト改修 で /github subscribe list features を送り、pulls と reviews だけが並んでいる返事1行目で既定の機能が流れ始め、2行目で要らないものを止め、3行目でレビューを足します。レビューは既定ではプルリクエストのカードのスレッドに入るので、チャンネルの表面にはプルリクエスト1件につきカード1枚だけが並びます。レビュアーに指名された人には、/github signin を済ませていればSlackでメンションが届くので、チャンネルを常に見ていなくても気づけます。
自社のコーポレートサイトのリポジトリ sample-design/corporate-site は、同じ形で #log-github に流しています。ディレクターAは #log-github-サイト改修 だけ通知を「メンションのみ」にし、レビューを頼まれたときだけ気づく設定にしています。
通知を流しすぎないための決まり
| 決まり | 理由 |
|---|---|
人が話す pj- チャンネルには流さず、log-github- に分ける | 会話と通知が混ざると、どちらも読まれなくなる |
購読したらすぐ issues と commits を外す | コミットは1日に数十件になり、Issueは担当者に直接届けば足りる |
comments は流さない | コメントはプルリクエストの中で読む。担当者にはメンションで届く |
| 気づいてほしいものはメンションで届ける | チャンネルを全員が見続ける前提にしない。/github signin を全員に済ませる |
| チャンネルの通知は「メンションのみ」を基本にする | 通知のチャンネルは見に行く場所にする |
| 急ぎのものだけ流したい場合はラベルで絞る | urgent のような英語のラベルを1つ決める |
購読の中身を #team-engineer のcanvas（キャンバス）に控える | 担当が替わったとき、どのチャンネルに何を流しているか分かる |
| 案件が終わったら購読をやめてチャンネルをアーカイブする | 動かないリポジトリの通知チャンネルが残り続けない |
運用していると、通知が多いと感じた人はチャンネルをミュートして、そのまま二度と開かなくなります。量を減らすのは受け取る側の工夫ではなく、購読する側の設定で行います。チャンネルごとの通知の変え方は「Slackの通知設定：通知が来ないときの直し方と、うるさくない設定」に書いています。
Slackから Issue を作る・リンクを展開する
メッセージからIssueを作る
ディレクターが #pj-a社-サイト改修 でA社からの修正依頼を受けたとき、そのメッセージからIssueを作れます。
- メッセージにマウスポインターを重ね、3つのドットアイコンをクリックします。
- GitHubのIssueを作る項目を選びます（GitHub公式の表記は「Create an Issue GitHub」で、日本語の画面では表示が違うことがあります）。
- リポジトリ、タイトル、ラベル・担当者・マイルストーンを確かめて作ります。
メッセージの内容がIssueの説明に入り、末尾にSlackの会話へのリンクが付きます。リポジトリは直近に使ったものが最初から入っています。/github open からも作れます。
リンクの展開
Issue・プルリクエスト・コメント、行番号つきのコードのリンクを貼ると、中身がカードで出ます。次のときは展開されません。
| 展開されないとき | 直し方 |
|---|---|
| ワークスペースでgithub.comのリンクの展開が止められている | 管理者に確かめる |
| 同じチャンネルで30分以内に同じリンクが貼られている | そのまま。前のカードを見る |
| 1つのメッセージにリンクが3件以上ある | リンクを2件までにする |
| プライベートのリポジトリで、貼った人がGitHubにサインインしていない | /github signin を済ませる |
| プライベートのリポジトリで、アプリがチャンネルにいない | /invite @github を送る |
GitHub ActionsからIncoming Webhookで送る方法との使い分け
GitHubのアプリで足りないとき、GitHub ActionsのワークフローからIncoming Webhookで自分で組んだ通知を送る方法もあります。Slackが公開しているSlack GitHub Actionを使うと、ワークフローに数行足すだけで送れます。
| 比べるところ | GitHubアプリ | GitHub Actions＋Incoming Webhook |
|---|---|---|
| 向いている通知 | プルリクエスト・Issue・レビューの動き | 本番への反映の完了、定期の処理の結果など、自社で決めた通知 |
| 文面 | 決まった形のカード | 自由に組める（Block Kit） |
| スレッドへのまとまり | 自動 | まとまらない |
| メンション | GitHubのレビュアーなどに自動で届く | 文面に書いた分だけ |
| 必要な準備 | アプリを入れて購読するだけ | Slackアプリを作ってURLを出し、リポジトリのシークレットに置く |
| 保守 | ほぼ要らない | ワークフローとURLの管理が要る |
サンプルデザインは、プルリクエストとレビューはGitHubのアプリ、本番サーバーへの反映が終わったという通知だけをGitHub ActionsからIncoming Webhookで #pj-a社-サイト改修 に送っています。ディレクターが「本番に出た」を知りたいのはそのチャンネルだからです。
name: Notify deploy
on:
push:
branches:
- main
jobs:
notify:
runs-on: ubuntu-latest
steps:
- name: Send to Slack
uses: slackapi/slack-github-action@v4.0.0
with:
webhook: ${{ secrets.SLACK_WEBHOOK_URL }}
webhook-type: incoming-webhook
payload: |
text: "A社サイト改修：本番への反映が終わりました（${{ github.sha }}）"Webhook URLは、リポジトリのシークレットに SLACK_WEBHOOK_URL として登録し、ファイルには直接書きません。公開のリポジトリにURLを書いたまま上げると、Slackが漏れたURLを見つけて無効にすることがあります。URLの作り方と置き場所は「SlackのIncoming Webhook：外のシステムからチャンネルに通知を送る」に、ボタンを押してもらうような双方向の通知は「Slack APIとbotの作り方：Slackアプリを作ってメッセージを送る・受け取る」に書いています。
SLACK_WEBHOOK_URL を登録している状態GitHub Enterprise Serverとプライベートリポジトリ
GitHub Enterprise Serverの場合
自社のサーバーでGitHub Enterprise Serverを動かしている会社は、Marketplaceの公開アプリは使えません。GitHub Enterprise Server 3.8以降で、自社専用のアプリを作ってSlackとつなぎます。GitHubの説明の流れは次のとおりです。
- GitHub Enterprise Serverの管理画面（
8443番のポート）の「Chat Integration」で、Slackとの連携を有効にします。 - Slack側で設定用のトークン（Configuration token）を作って貼り付け、アプリを作ります。
- 設定を保存し、管理画面に出る入口からワークスペースにアプリを入れます。
できることはGitHub.comのアプリと同じと書かれています。データの保存場所を選ぶGitHub Enterprise Cloud（ghe.com）は、それ専用のアプリを使います。サーバーの管理者でないと設定できないので、外部の制作会社に頼んで運用しているなら、その会社に頼みます。
プライベートリポジトリの扱い
購読・通知・操作は、どれもその人のGitHubの権限にもとづきます。プライベートのリポジトリを購読するには、GitHub側でアプリにそのリポジトリへのアクセスを許可しておく必要があります。プライベートのリポジトリの通知は、Slackのチャンネルに入っている全員に見えます。取引先とつないだ ext- のチャンネルや、ゲストのいるチャンネルには流さないことを決まりにしておきます。
応用
レビュー待ちを毎朝まとめる
プルリクエストが出るたびの通知のほかに、GitHubのチームの「Scheduled reminders」で、レビュー待ちのプルリクエストを毎朝決まった時刻にまとめて流せます。サンプルデザインは平日の朝9時に #team-engineer に流しています。設定の手順は「Slackのアプリ連携：Googleカレンダー・Googleドライブ・GitHubをつなぐ」に書いています。
デプロイの承認をSlackで受ける
workflows を購読すると、GitHub Actionsで承認が要るデプロイの依頼がスレッドに届き、そこで承認できます。デプロイの状態を追いたいときは、GitHubの説明でも deployments より workflows が勧められています。最初に workflows を購読するとき、Slackの中でActionsのイベントを読む許可を求められます。
できないことと、その代わり
| できないこと | 代わりの手 |
|---|---|
| 1つの購読でラベルを2つ以上指定する | ラベルを1つにまとめる。足りなければチャンネルを分ける |
| ラベルでコミットやブランチの通知を絞る | commits:main のようにブランチで絞る |
| 1つのチャンネルで、リポジトリごとに違う人へ通知を出し分ける | リポジトリごとにチャンネルを分ける |
| GitHub Enterprise ServerでMarketplaceのアプリを使う | 自社専用のアプリを作る |
| 通知の文面を自社の形に変える | GitHub ActionsからIncoming Webhookで送る |
| Slackの通知を開発の記録として残す | 記録はGitHubのプルリクエストとIssueに残す。Slackは気づくための場所 |
| 取引先の担当者にプライベートのリポジトリの通知だけ見せる | 社内の log-github- チャンネルに流し、取引先には決まったことを ext- チャンネルに書く |
よく詰まるところ
| 症状 | 原因 | 直し方 |
|---|---|---|
| 「Slack に追加」を押してもすぐ入らない | Slackのアプリが承認制になっている | 承認リクエストを送り、管理者の承認を待つ |
| GitHub側でアプリを入れられない | 組織にアプリを入れる権限が無い | 組織のオーナーへのリクエストになるので、承認を待つ |
| プライベートチャンネルに通知が流れない | アプリがチャンネルにいない | /invite @github を送る |
| プライベートのリポジトリを購読できない | GitHubのアプリにそのリポジトリのアクセスが無い | 求められた追加のインストールを済ませるか、組織のオーナーにリポジトリを足してもらう |
| コミットのたびに通知が流れる | 既定の機能のまま購読した | /github unsubscribe owner/repo commits で外す |
| レビューを頼まれてもメンションが来ない | /github signin をしていない、別のワークスペースで最後にサインインした | このワークスペースで /github signin をやり直す |
| ラベルで絞ったのに何も流れない | ラベルの無い通知は捨てられる、日本語のラベル名、絞り込みが入れ替わった | 英語のラベル名にし、/github subscribe list features で中身を確かめる |
| レビューの通知がチャンネルに見えない | 既定でプルリクエストのスレッドに入る | スレッドを開く。チャンネルに出したいなら reviews:"channel" で購読する |
| GitHubのリンクが展開されない | 同じリンクを30分以内に貼った、リンクが3件以上、サインインしていない | リンクを減らし、/github signin を済ませる |
| GitHub Actionsからの通知が突然届かなくなった | Webhook URLが漏れて無効になった、シークレットの名前が違う | URLを作り直してシークレットに登録し直す |
次にやること
GitHubの通知が落ち着いたら、ほかの自動の通知も同じ考え方で整えます。
- Slackのアプリ連携：Googleカレンダー・Googleドライブ・GitHubをつなぐ
- SlackのIncoming Webhook：外のシステムからチャンネルに通知を送る
- Slack APIとbotの作り方：Slackアプリを作ってメッセージを送る・受け取る
- Slackの通知設定：通知が来ないときの直し方と、うるさくない設定