--- title: "Slack APIの料金：無料で使える範囲とプラン別のAPI・レート制限・429対処の実装【2026年11月】" url: "https://www.issoh.co.jp/tech/details/19479/" published: 2026-11-07 updated: 2026-11-08 categories: ["業務システム"] publisher: "株式会社一創" --- # Slack APIの料金：無料で使える範囲とプラン別のAPI・レート制限・429対処の実装【2026年11月】 Slack APIは、呼び出し回数に応じて請求される従量課金の仕組みを持たず、使える量はレート制限で決まります。お金がかかるのはワークスペースのプランの月額と、アプリを動かすサーバー、そして開発の工数です。この記事では、フリープランと有料プランでAPI連携に効く機能差、SCIM APIや監査ログAPIのようにプランで使える範囲が変わるAPI、Tier 1〜4のslack api 制限の具体値を、Slack公式ドキュメントの記述に沿って整理しました。後半では429とRetry-Afterを待つPythonの実装と、プランを上げるべき場面の線引きを示します。 ## まとめ：Slack APIの料金で最初に確かめるプランの壁とレート制限の上限 Slack APIそのものは無料で呼べます。レート制限のTierは全プラン共通なので、有料プランに切り替えても呼び出せる回数は増えません。 プランで変わるのは、インストールできるアプリの数と、使えるAPIの種類です。フリープランはアプリ10個まで、SCIM APIはBusiness+以上、監査ログAPIはEnterpriseだけが対象になります。 実装では、429が返ったらRetry-Afterの秒数だけ待つ処理を最初から組み込みます。社外へ配布するアプリは、2025年5月以降の新規インストールで履歴取得が毎分1回に絞られる点も見積もりに入れておきます。 ## Slack APIの呼び出しに料金がかからない仕組みと実費が生じる場所 ### 呼び出し回数ではなくレート制限で量を抑えるSlack APIの課金モデル Slackの開発者向けドキュメントには、APIの呼び出し回数や転送量に応じた単価が載っていません。量の制約はお金ではなく、[Rate limitsのページ](https://docs.slack.dev/apis/web-api/rate-limits/)に書かれたTierで課されます。同じページには、すべてのSlackプランで同じメソッドに同じTierが適用されると明記されています。 ここから導ける結論は単純です。フリープランのワークスペースでも、Business+のワークスペースでも、`conversations.history`を呼べる回数は同じです。レート制限に当たって困っている場合に、プランを上げても解決しません。直すべきは呼び出し方です。 Web API・Events API・Boltの役割分担は[Slack APIとは？Web API・Events API・Boltの違いと実装手順](https://www.issoh.co.jp/tech/details/18717/)で解説しています。この記事は費用と制約に絞ります。 ### プランの月額・サーバー・開発工数に分かれるAPI連携の実費の内訳 API連携で実際に支払うお金は、性質の違う3つに分かれます。金額が大きくなりやすい順に並べると次のとおりです。 | 費用 | 発生する条件 | 確認先 | | -------- | ----------------------- | ---------- | | 開発・保守の工数 | Botや連携処理を自作するとき | 要件と社内体制 | | プランの月額 | アプリ11個以上・SCIM・監査ログが要るとき | Slack料金ページ | | サーバー費 | HTTP受信やバッチを自前で動かすとき | クラウドの料金表 | プランの単価は、年払いか月払いかと、税込か税抜かで表示が変わります。最新の金額は[Slackの料金プランのページ](https://slack.com/intl/ja-jp/pricing)で確かめてください。チャットツールとしての料金比較は[Slack・Discord・LINEの違い](https://www.issoh.co.jp/tech/details/7427/)にまとめています。Socket Modeで動かすBotは公開URLが要らず、小さな常駐サーバー1台で動きます。 ## フリープランと有料プランでAPI連携に効く機能差と使えないAPI ### フリープランのアプリ10個上限と90日履歴とワークフロー停止の影響 [Slackヘルプの「フリープランの機能制限」](https://slack.com/intl/ja-jp/help/articles/27204752526611-Slack-%E3%81%AE%E3%83%95%E3%83%AA%E3%83%BC%E3%83%97%E3%83%A9%E3%83%B3%E3%81%AE%E6%A9%9F%E8%83%BD%E5%88%B6%E9%99%90)には、API連携に関わる制限が3つ書かれています。 - サードパーティ製アプリとカスタムアプリのインストールは、合わせて10個まで - メッセージとファイルの履歴は直近90日分に限られ、1年以上前のデータは削除される - ワークフロービルダーは使えず、ダウングレードすると既存のワークフローも止まる 実務で最初に当たるのは、10個の上限です。自作したBotも1個に数えるため、既製の連携アプリを入れているワークスペースでは、Botを1本足すために何かを外す判断が要ります。90日の制限は、過去ログを集計するBotの設計に響きます。ワークフローのWebhookトリガーをAPIの代わりに使う構成も、フリープランでは組めません。 ### SCIM APIはBusiness+以上・監査ログAPIはEnterprise限定の条件 Web APIのメソッドの大半はどのプランでも呼べますが、管理系のAPIにはプランの条件があります。[SCIM APIのドキュメント](https://docs.slack.dev/admins/scim-api/)によると、利用対象はBusiness+とEnterpriseのワークスペースだけです。人事システムやIdPから、入退社に合わせてSlackアカウントを自動で作成・停止する連携がこれにあたります。 [Audit Logs APIのドキュメント](https://docs.slack.dev/admins/audit-logs-api/)では、対象はEnterpriseプランだけです。ユーザートークンのスコープ`auditlogs:read`が要り、アプリはEnterprise組織のオーナーがインストールします。ログイン履歴やファイル共有の操作をSIEMへ流したい場合、Business+では足りません。SCIMの仕組み自体は[SCIMとは？ID自動プロビジョニングの仕組み](https://www.issoh.co.jp/tech/details/15876/)で扱っています。 ### Enterprise限定APIを契約前に試せる開発者サンドボックスの条件 監査ログAPIを使う連携を作りたいが、Enterpriseをまだ契約していない。この場合は[開発者サンドボックス](https://docs.slack.dev/tools/developer-sandboxes/)で検証します。Slack Developer Programの特典として、Enterpriseプランと同じ機能を持つ組織環境を追加費用なしで作成できる仕組みです。支払い方法の登録を求められますが、登録しても請求はされないと書かれています。 制約もはっきりしています。有効期間は通常6か月で、延長しなければアーカイブされ、3か月後に削除されます。作成は30日で10個まで、同時に有効なのは2個まで、1つのサンドボックスに入れるユーザーは8人までです。本番データを入れて長く使う場所ではなく、契約前の動作確認に限って使うのが妥当です。 ## Tier 1〜4とSpecialで決まるSlack APIのレート制限とメソッド別の上限 ### 毎分1回から100回以上まで4段階のTierと制限がかかる単位の比較表 各メソッドのTierは、APIリファレンスの「Facts」欄に書かれています。[Rate limitsのページ](https://docs.slack.dev/apis/web-api/rate-limits/)が示す目安は次のとおりです（2026年11月時点）。 | Tier | 1分あたりの目安 | 主な対象 | | ------- | -------- | ----------------------- | | Tier 1 | 1回以上 | めったに呼ばない管理系 | | Tier 2 | 20回以上 | 多くのメソッド | | Tier 3 | 50回以上 | conversations系・users系一覧 | | Tier 4 | 100回以上 | 大きなバーストを許すメソッド | | Special | メソッドごと | chat.postMessageなど | 一覧取得の対象にはconversations系やusers系があります。制限は「メソッドごと・ワークスペースごと・アプリごと」に数えられます。ある1つのワークスペースで`users.list`が429になっても、同じワークスペースの別メソッドや、別のワークスペースへの同じメソッドは止まりません。カーソルによるページングを使わない呼び出しには、より厳しい制限がかかる点にも注意が要ります。 ### chat.postMessage毎秒1件・Events API毎時3万件の個別上限 Tierの枠外で決まっている上限もあります。投稿は1チャンネルあたり毎秒1件が目安です。[chat.postMessageのリファレンス](https://docs.slack.dev/reference/methods/chat.postMessage/)では短いバーストは許容されますが、超え続けると制限がかかります。定時投稿でこの上限を扱う実装は[Slack Botで自動投稿する方法](https://www.issoh.co.jp/tech/details/19477/)に載せています。 受信側では、Events APIの配信が1ワークスペース・1アプリあたり60分で30,000件までです。超えると`app_rate_limited`イベントが届きます。ワークフローのトリガーにも上限があり、イベントトリガーは毎時10,000回、Webhookトリガーは毎分10回です。外部システムからWebhookトリガーを叩く構成は、毎分10回を超える頻度なら成り立ちません。 ### 2025年5月から非Marketplaceアプリの履歴取得が毎分1回になった変更 2025年5月29日、[Slackの変更履歴](https://docs.slack.dev/changelog/2025/05/29/rate-limit-changes-for-non-marketplace-apps/)で、`conversations.history`と`conversations.replies`の制限が引き下げられました。対象はSlack Marketplaceの審査を通さずに商用配布されるアプリで、Tier 3からTier 1へ、毎分1回・1回あたり最大15件になりました。 適用範囲は狭く読む必要があります。[日本語のFAQ](https://docs.slack.dev/ja-jp/2025-05-terms-rate-limit-update-and-faq/)には、Marketplaceアプリと社内用のカスタムアプリは影響を受けず、配布アプリの既存インストールにも適用しないと書かれています。社内用アプリは従来どおり毎分50回以上・1回あたり最大1,000件です。新しく作って複数の顧客企業へ配る連携アプリだけが、この制限を前提に設計し直すことになります。 ## 429とRetry-Afterを前提にしたSlack API呼び出しのPython実装手順 ### curlでSlack APIの応答ヘッダを表示しRetry-Afterを確かめる手順 レート制限を超えると、HTTP 429とともに`Retry-After`ヘッダで再試行までの秒数が返ります。応答ヘッダごと表示するために使うのが、curlの`-D -`オプションです。トークンは[Slack Bot Tokenの取得と確認](https://www.issoh.co.jp/tech/details/19472/)の手順で発行したxoxbを環境変数に入れておきます。 ``` curl -s -D - -o /dev/null \ -H "Authorization: Bearer $SLACK_BOT_TOKEN" \ "https://slack.com/api/conversations.history?channel=C0123456789&limit=200" \ | grep -i -E "^HTTP|retry-after" ``` 通常は`HTTP/2 200`の1行だけが出ます。短時間に繰り返して429になると、`retry-after: 30`のような行が加わります。この秒数より前に呼び直しても、また429が返るだけです。 ### RateLimitErrorRetryHandlerで429を待つ自動再送設定 Python Slack SDK（slack\_sdk）には、429を受けたときに`Retry-After`の秒数だけ待って再送する仕組みがあります。[Python Slack SDKのWeb clientのページ](https://docs.slack.dev/tools/python-slack-sdk/web/)によると、接続エラーの再試行は既定で有効ですが、429の再試行は自分で登録しないと動きません。 ``` import os from slack_sdk import WebClient from slack_sdk.errors import SlackApiError from slack_sdk.http_retry.builtin_handlers import RateLimitErrorRetryHandler client = WebClient(token=os.environ["SLACK_BOT_TOKEN"]) # 429が返ったらRetry-Afterの秒数だけ待って、最大3回まで再送する client.retry_handlers.append(RateLimitErrorRetryHandler(max_retry_count=3)) try: res = client.conversations_info(channel=os.environ["SLACK_CHANNEL_ID"]) print(res["channel"]["name"]) except SlackApiError as e: # 再送しても429が続いた場合や、missing_scopeなどのエラーはここで受ける if e.response.status_code == 429: print("待機が必要な秒数:", e.response.headers.get("Retry-After")) else: print("APIエラー:", e.response["error"]) raise ``` 再送の回数を決める基準は、利用者への応答か夜間のバッチかという処理の性質です。利用者の操作に応答する処理は3秒以内に返す必要があるため、再送の回数は0〜1回に抑える設計です。夜間のバッチなら3回程度にして、それでも失敗したら記録して終えます。429の設計全般は[APIレート制限（レートリミット）とは？](https://www.issoh.co.jp/tech/details/16179/)、Webhookでの扱いは[Slack Incoming Webhookの実装手順](https://www.issoh.co.jp/tech/details/17652/)で解説しています。 ### conversations.historyの200件単位ページングによる取得コード 履歴の取得は、1回に多く取るほど呼び出し回数が減ります。[conversations.historyのリファレンス](https://docs.slack.dev/reference/methods/conversations.history/)では`limit`の既定が100、上限が999で、1回200件以下でのページングが推奨されています。必要なスコープは`channels:history`など、チャンネルの種類に応じた`*:history`です。 ``` def fetch_history(client, channel_id, oldest="0"): """チャンネルの履歴をカーソルで最後まで取得する（429は上のハンドラが待つ）""" messages = [] cursor = None while True: res = client.conversations_history( channel=channel_id, limit=200, oldest=oldest, cursor=cursor, ) messages.extend(res["messages"]) cursor = res.get("response_metadata", {}).get("next_cursor") if not cursor: return messages ``` 社内用アプリなら、Tier 3の毎分50回以上で1万件のチャンネルも1分ほどで取り切れます。Marketplace外で配布するアプリの新規インストールでは、`limit`を200にしても1回15件しか返らず、呼び出しも毎分1回です。同じ1万件に11時間以上かかる計算になり、全件の同期を前提にした設計は成り立ちません。スレッドの展開や差分取得まで含めた取得処理の書き方は、[Slack APIでメッセージを取得する方法：conversations.historyとrepliesのページング・スコープ・差分取得](https://www.issoh.co.jp/tech/details/19485/)で解説しています。 ## Slack APIの費用を抑えて自作する場面とプラン変更や外注を選ぶ判断基準 ### 社内用カスタムアプリをフリープランのまま自作できる要件と判断条件 自社のワークスペースだけで使うBotを作るなら、まずフリープランのままで構いません。レート制限は有料プランと同じで、2025年の履歴取得の制限も社内用アプリには適用されないからです。条件は3つあります。 - 既製アプリと合わせて、インストールするアプリが10個に収まる - 90日より前のメッセージを処理の対象にしない - ワークフロービルダーとの組み合わせを前提にしない この3つを満たすなら、Botの作り方は[Slack Botの作り方：Bolt for Pythonでメンション返信からLambda運用まで](https://www.issoh.co.jp/tech/details/18861/)の手順で進められます。1つでも外れるなら、自作を始める前にプランの見直しを済ませます。 ### 有料プランへの切り替えや連携開発の外注を検討する要件の線引き プランの見直しが必要になるのは、人事システムと連動してアカウントを自動で作成・停止したいとき（SCIM APIでBusiness+以上）と、操作ログを監査に回したいとき（監査ログAPIでEnterprise）です。どちらもAPIの呼び出し料ではなく、ユーザー数分のプラン料金が費用の中心になります。 開発を自社で抱えないほうがよい場面もあります。複数の顧客企業へ配る連携アプリは、Marketplaceの審査を通すかどうかで1分あたりに取得できる履歴の件数が1,000倍以上変わり、設計の前提が変わるからです。基幹システムや会計システムとSlackを双方向につなぐ連携も、429の再送と冪等性の設計を誤ると二重登録が起きます。要件の整理から実装と運用までを任せたい場合は、[API開発・システム連携](https://www.issoh.co.jp/service/system/api/)で、連携先と通知の要件から構成と費用の見通しを相談できます。 ## よくある質問 Slack APIの料金と制限について、検討の段階でよく確認される点をまとめました。 ### Slack APIは無料プランのワークスペースでも使えますか？ 使えます。Web APIのメソッドはフリープランでも呼べ、レート制限のTierも有料プランと同じです。ただし、インストールできるアプリはサードパーティ製とカスタムを合わせて10個までで、メッセージ履歴は直近90日分に限られます。SCIM APIや監査ログAPIのように、プランの条件があるAPIはフリープランでは使えません。既製の連携アプリを多く入れているワークスペースでは、Botを足す前にインストール済みの数を確かめておくと手戻りがありません。 ### 有料プランにするとSlack APIのレート制限は緩和されますか？ 緩和されません。Slackの公式ドキュメントには、すべてのプランで同じメソッドに同じTierが適用されると書かれています。Business+やEnterpriseに切り替えても、`conversations.history`や`users.list`を呼べる回数は変わりません。レート制限に当たっている場合は、カーソルでのページング、取得結果のキャッシュ、Events APIで変更だけを受け取る構成への切り替えなど、呼び出し方を見直します。 ### Slack APIで429が返ったときは何秒待てばよいですか？ 応答の`Retry-After`ヘッダに書かれた秒数だけ待ちます。固定の秒数を決め打ちで待つより確実です。Python Slack SDKなら`RateLimitErrorRetryHandler`を登録すると、この待機と再送を自動で行えます。429は同じワークスペースの同じメソッドだけが対象なので、別のメソッドの呼び出しまで止める必要はありません。待機中に処理が溜まる場合は、キューに積んで順に送る作りにします。 ### Marketplaceに掲載しない社外向けアプリは何に注意すべきですか？ 2025年5月29日以降の新規インストールでは、`conversations.history`と`conversations.replies`が毎分1回・1回あたり最大15件に制限されます。過去ログを大量に読み込んで分析する機能は、この条件では実用的な速度で動きません。対象は社外へ商用配布するアプリで、社内用のカスタムアプリや既存のインストールには適用されないと公式FAQに書かれています。配布を予定しているなら、Marketplaceの審査を通すかどうかを設計の初期に決めておきます。 ### Slack APIを使った連携開発の費用は何で決まりますか？ APIの利用料はかからないため、費用は開発・保守の工数、プランの月額、サーバー費で決まります。中でも差が大きいのは工数で、連携先の数、双方向か片方向か、ボタンによる承認のような対話操作を含むか、障害時の再送をどこまで作り込むかで変わります。通知を一方向に流すだけならIncoming Webhookで足り、開発はほとんど要りません。要件を書き出してから見積もりを取ると、比較がしやすくなります。 ## 関連記事 - [Slack APIとは？Web API・Events API・Boltの違いと実装手順](https://www.issoh.co.jp/tech/details/18717/)：料金と制限を確かめたあとに読む、Slack APIの全体像と最小実装 - [API連携の実装方法：REST・認証・エラー処理の手順をcurlとPythonのコード例で解説](https://www.issoh.co.jp/tech/details/15351/)：Slack以外のAPIでも共通するエラー処理と再送の書き方 - [API連携とは？仕組み・データ連携との違い・導入判断までわかりやすく解説](https://www.issoh.co.jp/column/details/15354/)：自作するか既製の連携を使うかを決める前の考え方 --- 出典: [Slack APIの料金：無料で使える範囲とプラン別のAPI・レート制限・429対処の実装【2026年11月】]()（株式会社一創）