💬
Slack Socket Modeはどう動くのか？
WebhookなしでアウトバウンドWebSocketによるイベント受信
Slackは元々Webhook（Event Subscriptions）でイベントを配信していましたが、公開URLが必要という欠点がありました。Socket ModeではBotサーバーがSlackにアウトバウンドWebSocket接続を先に確立し、Slackがその接続を通じてイベントをpushする方式です。公開URL、SSL証明書、ファイアウォール設定がすべて不要です。内部的にapps.connections.open APIでWebSocket URLを取得して接続します。
構造ダイアグラム
接続確立フェーズ
🤖
マイBotサーバー
ファイアウォール内 / ローカル
① apps.connections.open
→
←
wss://... URL受信
→ アウトバウンド
② WS接続
💬
Slack
イベント + Web API
イベント処理フェーズ
🤖
マイBotサーバー
④ イベント処理
←
③ event push (WS)
⑤ acknowledge（3秒以内）
→
⑥ Web APIレスポンス
→
👤
ユーザーイベント
メッセージ、スラッシュコマンドなど
ポイント: Botが<strong>アウトバウンドWebSocket</strong>を開くため公開URL / ngrok不要
Socket Mode vs Webhook 比較
Socket Mode
Webhook (Event API)
公開URL不要
公開URL必須
アウトバウンドWebSocket
インバウンドHTTP POST
ローカル開発すぐ可能
ngrok等トンネル必要
接続維持が必要
Stateless
動作フロー
1
Botがapps.connections.open APIを呼び出し → 一時的なWebSocket URLを受信
2
BotがそのURLでWebSocket接続を確立（アウトバウンド）
3
Slackでイベント発生（メッセージ、スラッシュコマンド、インタラクションなど）
4
SlackがWebSocketでイベントペイロードをBotにpush
5
Botがイベントを処理し、acknowledge応答を送信（3秒以内）
6
必要に応じてSlack Web APIでメッセージを送信/更新
メリット
- ✓ 公開URL不要
- ✓ ファイアウォール/NAT背後で動作
- ✓ ngrokなしでローカル開発可能
- ✓ SSL証明書不要
デメリット
- ✗ 接続維持が必要（30秒ping）
- ✗ 切断時のイベント喪失の可能性
- ✗ 大規模アプリには不適合（接続数制限）
- ✗ Webhookと比較してデバッグツールが不足
ユースケース
社内Slack Bot開発
ファイアウォール背後のBot運用
ローカル開発環境でのBotテスト
セキュリティ重視のBot（公開URL公開不可）