Slack Incoming Webhooks は「アプリ側から Slack のチャンネルへメッセージを投げ込む」だけの、意図的に機能を絞った仕組みだ。チャンネルごとに発行される Webhook URL に対して JSON を POST すれば投稿できる。OAuth もトークン管理も不要で、CI/CD の結果通知や監視アラートを Slack に流すには最短経路になる。
Block Kit で見せ方を整える
プレーンテキストだけでなく Block Kit に対応しているため、見出し・区切り線・ボタン風の装飾を入れて、ビルド成功/失敗やエラー内容を読みやすく整形できる。運用通知は流し読みされるので、色や構造で重要度を一目で伝えられるのは効く。
Webhook の限界を踏まえる
Incoming Webhooks は一方向の通知専用だ。URL は投稿先チャンネルに固定され、メッセージへの返信を受け取る、ユーザーの操作に反応する、複数チャンネルへ動的に投げ分けるといったことはできない。双方向のやり取りやインタラクティブな Bot を作りたいなら、Events API とプラットフォーム機能を備えた Slack App を構築するのが正しい道だ。
URL の秘匿が運用の肝
Webhook URL は知っている者なら誰でもそのチャンネルへ投稿できる「鍵」そのものだ。ソースコードにベタ書きしてリポジトリへ push してしまうと、第三者にスパム投稿される。環境変数やシークレット管理に逃がし、万一漏れたら Slack 側で URL を再発行する運用を前提にしておきたい。
通知の量を設計する
監視アラートをそのまま全部流すと、チャンネルが通知で埋まり肝心の異常が埋もれる。送る側で重大度のしきい値を設け、軽微なものはまとめる、復旧通知はスレッドにぶら下げる、といった整理をしてから投げると通知が機能し続ける。「通知を出すだけ」と割り切れる範囲では Incoming Webhooks がもっとも手間がかからず、要件が対話に踏み込んだ時点で乗り換える、という線引きで考えるとよい。
通知疲れをどう防ぐか
導入直後は「全部通知する」設定にしがちだが、通知が多すぎるチャンネルは誰も読まなくなる。読まれない通知は、無いのと同じどころか、重要な通知を埋もれさせる分だけ有害になる。重大度で送り先チャンネルを分ける、軽微なものは日次のサマリにまとめる、といった設計を最初から入れておきたい。「何を通知しないか」を決めるほうが、実際には難しく重要になる。
例外のスタックトレースやリクエスト内容をそのまま流すと、トークンや個人情報が Slack に残ります。Slack のログは検索可能な形で長期間保持され、参加者全員が閲覧できます。通知に含める情報は、識別子とエラーの種別に留め、詳細は権限のある画面で見る構成にしてください。
移行先としての Slack アプリ
Incoming Webhook は手軽だが、投稿先チャンネルが固定される、後から投稿を編集できない、といった制約がある。通知の内容に応じて宛先を変えたい、あるいは投稿後に状態を更新したい（対応中→解決済み）といった要件が出てきたら、Slack アプリとして実装し直す時期にきている。最初から作り込む必要はないが、拡張の道筋として把握しておくと判断が早い。