Slack APIとは？業務連携の方式・権限・運用の確認事項

Slack APIは、外部システムからSlackの情報を取得・操作したり、Slack内の出来事を受け取ったりするための仕組みです。Web APIはHTTPメソッドによる情報取得や操作、Events APIはSlackで起きたイベントの受信に使います。Web APIの概要・Events APIの概要

まず「Slackへ通知する」「Slackを操作する」「Slackからイベントを受け取る」を分けると、方式と権限を選びやすくなります。本記事では社内システム連携を想定し、実装前に決めることを整理します。仕様の確認日は2026年11月3日です。

チャンネルやワークスペースの意味から確認したい場合は、Slackの基本と企業導入の確認事項を参照してください。

Slack APIの方式は、データを送る方向で選ぶ

Incoming Webhooks：固定先への通知

Incoming Webhooksでは、発行されたURLへメッセージを含むJSONを送信します。投稿時にデフォルトのチャンネルを上書きすることはできません。例えば、日次処理の完了を一つのチャンネルへ知らせる用途なら、最初の検討候補になります。これは用途に基づく本記事の提案です。Incoming Webhooksの仕様

Webhook URLには秘密情報が含まれます。コードや共有資料へ直接書かず、実行環境の秘密情報として管理してください。

Web API：トークンで情報取得や操作を行う

Web APIには操作別のメソッドがあります。メッセージを送る chat.postMessage では、必要な権限を持つトークンと投稿先の channel を指定します。Botトークンでの基本的な投稿には chat:write スコープが必要です。chat.postMessageの仕様

投稿だけが目的なら、履歴取得まで必要かを別に判断しましょう。本記事では、実装する操作を先に列挙し、その操作に必要な権限だけを申請する進め方を勧めます。

Events API：Slack内の出来事を受け取る

Events APIでは、必要なイベントを購読し、Slackから通知を受け取ります。配信されるイベントは、アプリに付与されたOAuthスコープと関係します。イベントを選択するだけで、あらゆるデータが読めるわけではありません。イベントと権限の関係

例えば「イベントを受信して、外部システムで処理し、Slackへ結果を投稿する」なら、受信にEvents API、投稿にWeb APIを組み合わせる設計が考えられます。

イベント受信はHTTPとSocket Modeから選ぶ

Events APIの配信先には、公開HTTPエンドポイントとSocket Modeという選択肢があります。Socket ModeはWebSocketでイベントを受け取る方式です。Events APIの受信方式・Socket Modeの仕様

本記事では、次の観点で選ぶことを提案します。

HTTPでSlackから届く要求は、Signing Secretを使って署名を検証します。公式手順では、JSONなどへ変換する前の生のリクエスト本文とタイムスタンプから署名を計算し、受け取った署名と比較します。タイムスタンプが古くないかも確認します。Slackからの要求の検証

Socket Modeでも、イベントの受信確認は必要です。受信した envelope_id を使って応答し、接続更新に伴う再接続も扱います。HTTPの署名検証と同じ手順をそのまま当てはめず、受信方式ごとの公式手順に沿ってください。Socket Modeの受信確認

最初の実装では、操作・権限・投稿先を一組にする

以下は、Botが試験用チャンネルへ処理完了を通知する場合の設計手順です。画面操作の一覧ではなく、実装前後に確認する順序を示します。

1. 投稿する情報と投稿先チャンネルを決める。
2. Slackアプリに必要なスコープを設定し、社内の承認手順に従って対象ワークスペースへインストールする。
3. Botトークンを秘密情報として保管し、Botの投稿先への参加状態を確認する。
4. chat.postMessage へ投稿先と本文を渡し、応答と実際の投稿を確認する。
5. 権限不足や無効な投稿先を含む失敗ケースも試す。

Web APIのトークンは Authorization ヘッダーで渡す方法が推奨されています。レスポンスのJSONでは ok が成功・失敗を示し、失敗時には error を確認します。Web APIの認証と応答

また、chat:write があれば新しいアプリから全パブリックチャンネルへ投稿できるわけではありません。全パブリックチャンネルへの投稿には追加の chat:write.public スコープが案内されています。対象が限られている連携では、まず投稿先と参加状態を確認し、必要性を説明できる場合に権限を追加する方針が適しています。チャンネルへの投稿権限

BotトークンはAPI呼び出し、Signing SecretはHTTPで届く要求の検証に使うものです。運用資料には用途別に保管場所と更新担当を記載し、値そのものは載せない形を勧めます。

再送・重複・レート制限を試験する

HTTPのイベント受信は、受付と業務処理を分ける

HTTPでのイベント受信では、3秒以内にHTTP 2xxで応答する必要があります。失敗時にはSlackが再送するため、同じイベントを複数回受け取る可能性を考慮します。公式資料も、受信後の処理にキューを使う方法を案内しています。イベントへの応答と再送

実装案としては、署名検証後にイベントをキューへ確実に格納して受付応答を返し、業務処理を別のワーカーで実行します。イベントの event_id を処理記録と照合し、同じイベントによる二重登録を防ぐ設計も検討してください。重複防止の保存期間や、処理失敗後に再実行できる条件は、自社側で定める事項です。

呼び出し制限に達したら、指定時間を待つ

SlackのHTTP APIでは、レート制限を超えるとHTTP 429と Retry-After ヘッダーが返されます。指定された秒数を待って再試行する処理を設計します。制限はすべての操作で一律ではないため、使うメソッドの現行仕様を確認してください。レート制限の公式説明

下表は本記事が提案する試験項目です。Slack側の仕様と、自社システムで保証する動作を分けて確認します。

入力・応答・処理後の状態を組み合わせる検証方法は、APIテストの進め方でも整理しています。

委託する場合は、運用の担当まで決める

Slack連携の発注仕様には、API名だけでなく、失敗を誰が発見し、誰が復旧するかも記載することを勧めます。次は分担を話し合うための例です。実際の契約や提供範囲を示すものではありません。

まず一つの業務について「送信元・受信先・操作・権限・失敗時の担当」を一行で書き出してみてください。その一行をもとに方式を選び、試験用チャンネルで正常系と失敗系を確かめると、実装と委託の範囲を具体化できます。