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のページに書かれたTierで課されます。同じページには、すべてのSlackプランで同じメソッドに同じTierが適用されると明記されています。

ここから導ける結論は単純です。フリープランのワークスペースでも、Business+のワークスペースでも、conversations.historyを呼べる回数は同じです。レート制限に当たって困っている場合に、プランを上げても解決しません。直すべきは呼び出し方です。

Web API・Events API・Boltの役割分担はSlack APIとは？Web API・Events API・Boltの違いと実装手順で解説しています。この記事は費用と制約に絞ります。

プランの月額・サーバー・開発工数に分かれるAPI連携の実費の内訳

API連携で実際に支払うお金は、性質の違う3つに分かれます。金額が大きくなりやすい順に並べると次のとおりです。

プランの単価は、年払いか月払いかと、税込か税抜かで表示が変わります。最新の金額はSlackの料金プランのページで確かめてください。チャットツールとしての料金比較はSlack・Discord・LINEの違いにまとめています。Socket Modeで動かすBotは公開URLが要らず、小さな常駐サーバー1台で動きます。

フリープランと有料プランでAPI連携に効く機能差と使えないAPI

フリープランのアプリ10個上限と90日履歴とワークフロー停止の影響

Slackヘルプの「フリープランの機能制限」には、API連携に関わる制限が3つ書かれています。

• サードパーティ製アプリとカスタムアプリのインストールは、合わせて10個まで
• メッセージとファイルの履歴は直近90日分に限られ、1年以上前のデータは削除される
• ワークフロービルダーは使えず、ダウングレードすると既存のワークフローも止まる

実務で最初に当たるのは、10個の上限です。自作したBotも1個に数えるため、既製の連携アプリを入れているワークスペースでは、Botを1本足すために何かを外す判断が要ります。90日の制限は、過去ログを集計するBotの設計に響きます。ワークフローのWebhookトリガーをAPIの代わりに使う構成も、フリープランでは組めません。

SCIM APIはBusiness+以上・監査ログAPIはEnterprise限定の条件

Web APIのメソッドの大半はどのプランでも呼べますが、管理系のAPIにはプランの条件があります。SCIM APIのドキュメントによると、利用対象はBusiness+とEnterpriseのワークスペースだけです。人事システムやIdPから、入退社に合わせてSlackアカウントを自動で作成・停止する連携がこれにあたります。

Audit Logs APIのドキュメントでは、対象はEnterpriseプランだけです。ユーザートークンのスコープauditlogs:readが要り、アプリはEnterprise組織のオーナーがインストールします。ログイン履歴やファイル共有の操作をSIEMへ流したい場合、Business+では足りません。SCIMの仕組み自体はSCIMとは？ID自動プロビジョニングの仕組みで扱っています。

Enterprise限定APIを契約前に試せる開発者サンドボックスの条件

監査ログAPIを使う連携を作りたいが、Enterpriseをまだ契約していない。この場合は開発者サンドボックスで検証します。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のページが示す目安は次のとおりです（2026年11月時点）。

一覧取得の対象にはconversations系やusers系があります。制限は「メソッドごと・ワークスペースごと・アプリごと」に数えられます。ある1つのワークスペースでusers.listが429になっても、同じワークスペースの別メソッドや、別のワークスペースへの同じメソッドは止まりません。カーソルによるページングを使わない呼び出しには、より厳しい制限がかかる点にも注意が要ります。

chat.postMessage毎秒1件・Events API毎時3万件の個別上限

Tierの枠外で決まっている上限もあります。投稿は1チャンネルあたり毎秒1件が目安です。chat.postMessageのリファレンスでは短いバーストは許容されますが、超え続けると制限がかかります。定時投稿でこの上限を扱う実装はSlack Botで自動投稿する方法に載せています。

受信側では、Events APIの配信が1ワークスペース・1アプリあたり60分で30,000件までです。超えるとapp_rate_limitedイベントが届きます。ワークフローのトリガーにも上限があり、イベントトリガーは毎時10,000回、Webhookトリガーは毎分10回です。外部システムからWebhookトリガーを叩く構成は、毎分10回を超える頻度なら成り立ちません。

2025年5月から非Marketplaceアプリの履歴取得が毎分1回になった変更

2025年5月29日、Slackの変更履歴で、conversations.historyとconversations.repliesの制限が引き下げられました。対象はSlack Marketplaceの審査を通さずに商用配布されるアプリで、Tier 3からTier 1へ、毎分1回・1回あたり最大15件になりました。

適用範囲は狭く読む必要があります。日本語の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の取得と確認の手順で発行した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のページによると、接続エラーの再試行は既定で有効ですが、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レート制限（レートリミット）とは？、Webhookでの扱いはSlack Incoming Webhookの実装手順で解説しています。

conversations.historyの200件単位ページングによる取得コード

履歴の取得は、1回に多く取るほど呼び出し回数が減ります。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の費用を抑えて自作する場面とプラン変更や外注を選ぶ判断基準

社内用カスタムアプリをフリープランのまま自作できる要件と判断条件

自社のワークスペースだけで使うBotを作るなら、まずフリープランのままで構いません。レート制限は有料プランと同じで、2025年の履歴取得の制限も社内用アプリには適用されないからです。条件は3つあります。

• 既製アプリと合わせて、インストールするアプリが10個に収まる
• 90日より前のメッセージを処理の対象にしない
• ワークフロービルダーとの組み合わせを前提にしない

この3つを満たすなら、Botの作り方はSlack Botの作り方：Bolt for Pythonでメンション返信からLambda運用までの手順で進められます。1つでも外れるなら、自作を始める前にプランの見直しを済ませます。

有料プランへの切り替えや連携開発の外注を検討する要件の線引き

プランの見直しが必要になるのは、人事システムと連動してアカウントを自動で作成・停止したいとき（SCIM APIでBusiness+以上）と、操作ログを監査に回したいとき（監査ログAPIでEnterprise）です。どちらもAPIの呼び出し料ではなく、ユーザー数分のプラン料金が費用の中心になります。

開発を自社で抱えないほうがよい場面もあります。複数の顧客企業へ配る連携アプリは、Marketplaceの審査を通すかどうかで1分あたりに取得できる履歴の件数が1,000倍以上変わり、設計の前提が変わるからです。基幹システムや会計システムとSlackを双方向につなぐ連携も、429の再送と冪等性の設計を誤ると二重登録が起きます。要件の整理から実装と運用までを任せたい場合は、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の違いと実装手順：料金と制限を確かめたあとに読む、Slack APIの全体像と最小実装
• API連携の実装方法：REST・認証・エラー処理の手順をcurlとPythonのコード例で解説：Slack以外のAPIでも共通するエラー処理と再送の書き方
• API連携とは？仕組み・データ連携との違い・導入判断までわかりやすく解説：自作するか既製の連携を使うかを決める前の考え方