プルリクをマージした後にGitHub Actionsワークフローが失敗しても、失敗したことに気づけないという課題がありました。
1回目の対策としてREADME.mdにワークフロー状態バッジ*1を置いていました。

しかし、バッジに気づかずリリースしかけたことがあったので、バッジでは不十分だとわかりました。
そこで、色々検討した結果、GitHub Actionsの失敗をSlackに通知するのが良いと考えました。
手段の比較
候補に挙がった手法は3通りでした。
- rtCamp/action-slack-notify を使う
- Slack: Send to Slack を使う
- 直接Slack APIを叩く
| 手法 | メリット | デメリット |
|---|---|---|
| 1. rtCamp/action-slack-notify | ・環境変数の設定のみで導入が可能。 ・通知デザインや色のテンプレートが用意されている。 ・複雑なスクリプト記述が不要。 |
・サードパーティ製であるため、提供元の信頼性への依存が生じる。 ・社内の外部サービス利用規則においてソースコード精査対象となっている ・通知内容のレイアウトを微調整する自由度が低い。 |
| 2. Slack: Send to Slack | ・Slack公式による提供であり、長期的な保守が期待できる。 ・「Block Kit」により、ボタン配置などの高度なUI構築が可能。 |
・Slackアプリの作成や、権限(Scopes)の管理を自ら行う必要がある。 ・通知内容をJSON形式で定義するため、設定がやや複雑になる。 |
| 3. 直接Slack APIを叩く | ・外部アクションや依存関係を一切排除でき、セキュリティリスクが最小限になる。 ・環境構築が不要で、標準的なシェルスクリプトで完結する。 |
・メッセージのペイロードJSONをすべて自前で構築する必要がある。 ・通知失敗時のリトライ処理など、エラーハンドリングを自作しなければならない。 |
生成AIはシェルスクリプトの作成が得意なので、サクッと作れてリスクも低い手法が良いと考え、3. 直接Slack APIを叩く で進めることにしました。
実装手順
- Slack Apps を作成。作成時にSlackのワークスペースと通知先チャンネルを選ぶ
- 1.で作成したアプリのメニューで Features → Incoming Webhooks → Webhook URL をコピペ
- GitHub を開いて Settings → Secrets and variables → Actions → Secrets に
SLACK_WEBHOOK_URLを作成 - GitHub Actions ワークフロー yml に curl コマンドを実装(サンプル)
これで、ワークフローが失敗すると Slack に失敗したURLが通知されるようになりました。

Slackへの通知の仕方は生成AIに聞いても答えてくれますが、いろいろな手法の中でどれを選ぶかは現時点ではまだ人間による判断だと思うので、判断の例として記事を書きました。何かの役に立つなら幸いです!