レート制限
Tier 1-4 のモデル、Retry-After の扱い、チャンネル単位の投稿制限、2025-2026 年の非 Marketplace アプリ向け変更 — 2026-08-06 検証
2026-08-06 時点の docs.slack.dev で検証済み。 レート制限は プラットフォームのなかでも変更が活発な部分のひとつなので（後述の非 Marketplace アプリの節を 参照）、正確な数値に本番で依存する前に一次情報を確認し直すこと。
Tier モデル
Web API のすべてのメソッドには 4 段階のレート制限 Tier のいずれかが割り当てられ、独自ルールを もつメソッド向けに special Tier が加わる。あるメソッドの Tier はすべての Slack プランで 共通で、どの Tier が適用されるかは各メソッドのリファレンスページの Facts セクションに書かれて いる（Rate limits）。
| Tier | レート | 性格 |
|---|---|---|
| 1 | 毎分 1 回以上 | アクセス頻度が低く、小さなバーストは許容される |
| 2 | 毎分 20 回以上 | 大半のメソッド。時折のバーストは許容 |
| 3 | 毎分 50 回以上 | 多めの割り当て。散発的なバーストも歓迎 |
| 4 | 毎分 100 回以上 | 寛容なバースト挙動 |
| Special | メソッドごとに異なる | メソッド固有のルール。chat.postMessage もこれにあたる（後述） |
制限のスコープは API メソッド単位 × ワークスペース/チーム単位 × アプリ単位だ。あるワーク スペースに対して 1 つのメソッドで制限に達しても、他のメソッドや、同じアプリがインストール されている他のワークスペースがスロットリングされることはない。
Retry-After の扱い
レート制限にかかった呼び出しは HTTP 429 Too Many Requests を返し、再試行までに待つべき秒数を Retry-After ヘッダーで示す。独自のバックオフスケジュールをゼロから組むのではなく、これを 権威ある値として扱うこと。示された時間（以上）だけ待ってから、まったく同じ呼び出しを再試行 する。公式 SDK の組み込みリトライハンドラーはいずれもこれを実装済みなので、独自のリトライ ループを書く前にまずそちらを使う。
メッセージ投稿の制限: チャンネルあたり約 1 通/秒
chat.postMessage は単純な Tier ではなく special のレート制限挙動をもつ。アプリが投稿 できるのはチャンネルあたり毎秒 1 通までで、これは chat.postMessage 経由か、incoming webhook 経由か、その他どの経路でチャンネルに入るかを問わない。このレートを超える短いバースト は許容されるものの、バースト中のすべてのメッセージが表示される保証は Slack にはなく、超過が 続けば前述の HTTP 429 + Retry-After が返ってくることもある — この処理は読み取り系メソッド だけでなく、投稿系の呼び出しにも実装しておくこと。大量投稿はバーストの許容度に頼らず、間隔を 空ける（あるいは内容をまとめて、少数の大きなメッセージにする）のが正しい。
2025〜2026 年の非 Marketplace アプリ向けレート制限変更
公式の Slack Marketplace の外で作られ配布される bot にとって、これが最も影響の大きい変更で あり、その対象は conversations.history と conversations.replies — bot がチャンネルや スレッドの内容を読むためによく使うメソッドであって、投稿用のものではない。
何が変わったか: 商用配布されているが Slack Marketplace の承認を受けていないアプリでは、 conversations.history と conversations.replies が通常の Tier 3 の割り当て（毎分 50 回以上、 1 リクエストあたり最大 999 オブジェクト）から、毎分 1 リクエスト、1 リクエストあたり最大 15 オブジェクトまで削られた。Marketplace の承認を受けたアプリと、社内向けのカスタムアプリ （商用配布ではなく、自組織のために作られた単一ワークスペースのアプリ）は従来の Tier 3 の制限を 維持する (conversations.history)。
適用のタイムライン:
2025-05-29 — この日付以降に作成されたアプリ、および既存の非 Marketplace アプリの新規 インストールに対して即時適用。Slack が挙げた理由は「審査を受けていないアプリケーションには 大量の機微な会話データを持ち出す余地がある」ことであり、この変更はこれら 2 つのメソッドを 通じた大量のデータ持ち出しを防ぐためのものだとしている。
2026-03-03 — すでにインストール済みの非 Marketplace アプリに対する猶予期間がこの日で 終了。2025 年 5 月の変更の影響を受けていなかった既存インストールも、この日以降は同じ 毎分 1 リクエスト / 15 オブジェクトの制限を受けるようになった。
このページの検証日（2026-08-06）時点で猶予期間はすでに過ぎている。つまり Marketplace 承認も 社内向けでもないアプリは、既存のインストールも含めて現在は縮小後の制限の対象であり、新規 作成のものだけではない。チャンネルやスレッドの履歴を読む bot が Marketplace の承認を受けて いないのなら、最初にインストールされた時期にかかわらず、毎分 1 リクエストの上限が今日すでに 適用されていると考えるべきだ。
出典: Rate limit changes for non-Marketplace apps （元の変更履歴と FAQ）、Clarifying rate limit changes for non-Marketplace apps （続報の補足）、および conversations.history のメソッドリファレンス（Tier の分岐がメソッドページに直接記載されている）。
大量の履歴読み取りがどうしても必要な場合
Slack は、大規模なエクスポートなしでメッセージやファイルの内容を検索する正規の代替手段としてReal-time Search API を挙げている — ただし 2026-08-06 時点でその対象は「選ばれたパートナー」に限られており、どのアプリでも そのまま採用できる代替ではない。conversations.history/conversations.replies で従来の Tier 3 の制限を保つ直接的な道は、Marketplace の承認を得ることだ。
ダッシュボード bot への当てはめ
ピン留めダッシュボードのパターン — 更新 1 回につき chat.update 1 回 — は、このページのどの制限にも余裕をもって収まる。 special Tier の chat.update 呼び出し 1 回（chat.postMessage と同じチャンネル単位の投稿 レートの系列に属する）を、毎秒 1 回よりはるかに緩い cron の間隔で実行するだけだからだ。上記の 非 Marketplace の変更が効いてくるのはむしろ読み取り側になる。非 Marketplace アプリで conversations.history/conversations.replies から元データを取得する同期ジョブは、メソッドの 基本ドキュメントが既定として今も示している Tier 3 の数値ではなく、毎分 1 リクエスト・ 1 リクエストあたり 15 オブジェクトを前提に設計する必要がある。