レート制限
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 の組み込みリトライハンドラーはいずれもこれを実装済みなので、独自の リトライループを書く前にまずそちらを使う。
ただし「権威がある」ことは「常に存在する」ことでも「無制限に従っても安全」ということでもない。 このヘッダーは 429 でも欠落したりパースできなかったりすることがあり、5xx では決して 返ってこない。Retry-After を読むことしか知らないリトライループは、どちらのケースでも 手がかりを持たず、フォールバックがなければ、こちらに減速を求めてきたエンドポイントに対して 連続で再試行してしまう。使えるヘッダー値が存在しないケースに備えて、ヘッダーベースの待機に 指数バックオフのフォールバック（基準 1 秒、失敗のたびに倍増）を組み合わせ、ヘッダーの値と フォールバックの計算値の両方を呼び出しパスごとの上限でクランプすること — 異常に大きい、 あるいは壊れた Retry-After の値が呼び出しパスを無期限に止められてはならないのは、無制限の 指数バックオフが止められてはならないのと同じことだ。
メッセージ投稿の制限: チャンネルあたり約 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 の承認を得ることだ。
本番運用からのフィールドノート
このレート制限モデルを本番で運用して得られた、実運用上の 2 つの現実。負荷がかかってから 思い知るのではなく、runbook に書き留めておく価値がある。
読み取りの予算は生の下限より高いところに落ち着く
非 Marketplace の体制下で稼働している、あるプロダクション向けの参照実装（production reference integration）では、読み取り側の実効的な Retry-After 上限を、より厳しく絞るのではなく、 おおよそ 60 秒まで引き上げている — 毎分 1 リクエストはハードな下限であって目標値ではなく、 プラットフォームが実際に強制する値より厳しい自主的な上限を設けても、失敗する呼び出しが 増えるだけで何も得られない。1 回の cron ティックが conversations.history/conversations.replies の呼び出しに使ってよい回数の予算を決め、パーマリンクをはじめとした 読み取りの重い再利用可能なデータはサーバー側でキャッシュし、毎回読み直さないようにすること。 tick ごとの予算の内訳、二段階のカバレッジパターン、そしてこの上限が形作る replace-on-read 設計の全体はチャンネル履歴の読み取りを参照。
内部アプリの適用除外は一度きりではなく、常に有効な分類
アプリが上記の非 Marketplace 制限の適用を免れ続けられるのは、それが「内部向け」— 商用配布に 出したことのない単一ワークスペースのアプリ — であり続ける間だけだ。Manage Distributionを有効にすると、アプリは即座にその適用除外から外れ、Tier 3 を前提に設計された読み取り側の 設計が、conversations.history/conversations.replies の削減後の毎分 1 リクエストという 上限に気づかぬうちに落とし込まれる。「Manage Distribution は OFF のままにする」は、一度きりの セットアップ判断ではなく、runbook に常設の運用上の不変条件として記載しておくべきものだ — 管理者権限を持つ誰かが、それが何を壊すか気づかないまま、あとから切り替えてしまうことも あり得るからだ。
ダッシュボード 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 オブジェクトを前提に設計する必要がある。