Slack Web APIでHTTP 429が返ったら、失敗したmethod、workspace、app、Retry-Afterを一組で記録します。一つのworkerを止めても、同じappとworkspaceの別workerが同じmethodを呼び続ければ負荷は下がりません。待機状態を共有し、同じ制限単位の要求をまとめて制御します。
この記事はアプリからSlackへ送るWeb API要求の制御です。Slackから届くEvents APIのACKや再送処理、missing_scopeやnot_in_channelとは分けます。以下は架空のキュー設計例で、Slack APIへの要求やrate limitの実測はしていません。
目次
HTTP応答とmethodを先に確認する
HTTPステータスとheaderを保存できる箇所で429を確認します。SDKが自動再試行する場合、アプリが受け取る例外だけでなく、どこで待機が発生するかも把握します。ログへtokenやメッセージ本文を出さず、内部のworkspace識別子、method、要求時刻、Retry-After、試行回数を記録します。
表は横にスクロールできます
| 観測 | 調べる対象 | 同じ修復にしないこと |
|---|---|---|
| HTTP 429とRetry-After | 対象methodの呼出量と待機 | scope追加 |
| missing_scope | method要件・token・install | 待てば解決すると扱う |
| Events受信の再送 | 受信応答・重複排除 | outboundの429と混同 |
| timeoutや5xx | 結果の確定状況と再試行方針 | 書込を無条件再送 |
Slackのrate limits資料（新しいタブで開く）は、Web APIの制限をapp・workspace・method単位で説明し、429のRetry-Afterは再試行までの秒数としています。別tokenへ交換して同じ要求を送ることを、待機の代わりにしません。
待機をworker間で共有する
架空例として、app A・workspace X・conversations.historyで429を受けた場合、その組合せのcooldownを共有保存します。workerごとに独立して待つより、該当キューのdispatch前に共通の再開時刻を確認する方が、同じ制限に対する同時再送を抑えやすくなります。
表は横にスクロールできます
| 要求の組合せ | 架空の制御 | 確認する条件 |
|---|---|---|
| A / X / conversations.history | Retry-Afterまで停止 | 別workerも同じ待機を参照 |
| A / X / users.info | 別methodとして判断 | そのmethod自身の制限 |
| A / Y / conversations.history | 別workspaceとして判断 | Y側の待機・権限 |
| 別appや別token | 実際のapp対応を確認 | 制限回避のための切替にしない |
公式資料は、あるmethodで制限されても他methodや別workspaceの同methodを一律に止める必要はないと説明しています。ただし、別の要求が必ず成功する保証ではありません。投稿などmethod固有の制約もあるため、共通制御に加えて該当methodの仕様を確認します。
再開時に溜まった要求を一斉に放出すると、再び429へ戻りやすくなります。並列数とdispatch速度を調整し、再試行回数・総待機時間・キュー滞留の上限を決めます。上限を超えたら失敗を隠さず、再開待ちや要確認として残します。
SDKとアプリの二重再試行を避ける
SDKがRetry-Afterを処理している上に、呼出元とジョブ基盤も同じ要求を再実行すると、実際の試行数や待機時間が分からなくなります。利用SDKの版と再試行設定を確認し、どの層が何を再試行するかを決めます。
表は横にスクロールできます
| 層 | 決める責務 | 記録する値 |
|---|---|---|
| SDK | HTTPのrate-limit応答処理 | 自動再試行の有無・上限 |
| dispatch制御 | 対象単位の待機共有 | 再開時刻・並列数 |
| ジョブ | 業務処理の再開・終了判断 | 処理ID・再試行状態 |
読取でも取得ページの保存とcursorを対応させ、失敗したページから再開できるようにします。書込では429と、結果が不明なtimeoutを区別します。たとえば投稿後に応答だけ失われた場合、再送で二重投稿する可能性があるため、業務処理IDと実行結果を照合する経路が必要です。
historyやrepliesはアプリの適用条件を見る
Slackの2025年5月29日付の公式変更案内（その後の追記を含む）は、Marketplace外で商用配布されるappの新規作成・新規installationと、既存installation・社内向けappを区別しています。確認した案内では、既存installationと社内向けappは、この変更の対象外です。古い上限表や別appの実績から、自分の適用条件を確定しません。Slack：非Marketplace appのrate limit変更（新しいタブで開く）
この公式変更案内とconversations.historyの現行資料（新しいタブで開く）を合わせて、自分のappとinstallationに適用される条件を確認します。ページングを使わない取得にはより厳しい制限が適用され得るため、全件取得のつもりで同じ先頭ページを繰り返していないかも調べます。tokenのscopeと読めるchannelの条件は、rate limitとは別に満たす必要があります。
復旧を確認する
再開後は一回の成功だけでなく、待機を共有できていること、同じページをループしていないこと、キューが許容時間内に減ることを確認します。投稿などの副作用がある処理では、失敗前後の二重実行も照合します。
「429が消えた」だけで終了せず、対象workspaceとmethod、観測したRetry-After、調整した並列・再試行設定、未処理件数を記録します。必要な処理量が現行制約へ収まらない場合は、不要な全履歴取得や重複ポーリングを減らす設計へ戻ります。