Slack API は、Slack ワークスペースをプログラムから操作するための API 群だ。メッセージの送受信・編集・削除、チャンネルの作成と管理、ファイルのアップロードまでをカバーする。

まず Incoming Webhook、必要なら Bot

「アラートを Slack に飛ばしたいだけ」なら、Incoming Webhook が最短だ。発行された URL に JSON を POST するだけでメッセージが届き、認証の組み込みもいらない。CI の失敗通知やサーバー監視のアラートはこれで十分まかなえる。

一方、ユーザーの発言に反応する、スラッシュコマンドを受ける、スレッドで対話するといった双方向のやり取りには Bot（Bot Token を持つアプリ）が要る。「通知だけか、対話までか」で実装の重さがはっきり分かれるので、最初に見極めておきたい。

設計上の注意

  • メッセージ送信にはレート制限があり、ループで大量投稿すると弾かれる。バッチ通知はまとめて 1 メッセージにする工夫が要る
  • Bot は招待されたチャンネルにしか書き込めない。「投稿が届かない」の典型原因はチャンネル未招待
  • Block Kit を使えばボタンやセレクトを含むリッチな UI を組めるが、インタラクションを受けるエンドポイントが別途必要になる

双方向 Bot の運用負荷

双方向の Bot に踏み込むと、運用の重さが一段上がる。Slack はユーザー操作のたびに 3 秒以内の応答を求めるため、重い処理は「いったん受領を返してから非同期で実行」する構成が必須になる。さらにイベントを受けるエンドポイントは常時公開しておく必要があり、署名検証でリクエストの正当性を確認しないと、第三者にコマンドを偽装される。通知用途とは別物のサーバー側設計が要ると割り切ったほうがよい。

向かない場面

当然ながら Slack を導入していないチームには通知が届かない。社内の連絡基盤が Teams や Discord のところでは別の手段を選ぶことになる。API 利用そのものは無料で、ワークスペースのプランに依存する。

3秒ルールが実装の形を決める

スラッシュコマンドやインタラクティブな操作に対して、Slack は短時間での応答を要求する。重い処理をその場で実行して結果を返そうとすると、処理が終わる前にタイムアウトして利用者にはエラーが見える。定石は、まず受領した旨を即座に返し、実際の処理は非同期に回して、完了後に response_url やチャンネル投稿で結果を届ける形にすることだ。この非同期前提の作りを最初から想定していないと、機能追加のたびに設計を作り直すことになる。

🟡
リクエストの署名検証を省略しないでください

Slack からのリクエストを受けるエンドポイントは公開されているため、署名を検証しないと第三者が任意の操作を偽装できます。署名の検証に加えて、タイムスタンプが古いリクエストを弾く（リプレイ対策）ところまでがセットです。

スコープ設計が後の運用を左右する

Slack アプリは要求する権限（スコープ）をワークスペース管理者が承認する。開発中に広めのスコープを取っておくと楽だが、企業導入では過剰な権限が承認の障壁になる。とくに全チャンネルの履歴閲覧のような強い権限は、セキュリティ部門の確認対象になりやすい。必要最小限から始め、機能追加時に追加承認を得る運用のほうが、結果的に導入は進む。