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 がもっとも手間がかからず、要件が対話に踏み込んだ時点で乗り換える、という線引きで考えるとよい。