DiscordのセキュリティBot設定ガイド：権限、AutoMod、プロキシの確認方法

要点

まずDiscord AutoModを設定し、標準機能で補えない部分に限ってセキュリティBotを追加します。権限、ロールの順序、ログを確認し、一般メンバーのアカウントでテストしてください。独自ワーカーに固定の送信元IPや許可された地域別チェックが必要な場合は、Discordクライアントとは分けて外部リクエストを設定します。掲載コードは参考構成です。エラー処理はシミュレーションテストのみで確認しており、Rola IPへの実接続はテストしていません。

DiscordのセキュリティBotでできること

DiscordのセキュリティBotは、モデレーターが問題に気づいてから対応する作業の一部を自動化します。製品によって、スパム削除、新規メンバーの制限、モデレーション記録、ロールやチャンネルへの破壊的な変更への対応など、機能は異なります。不要なメッセージを削除できるBotが、自動的にサーバー破壊対策（アンチヌーク）まで備えているとは限りません。

まず、どのトラブルを防ぎたいのかを決めましょう。公開ゲームサーバーなら、新規参加者の確認やメンション制限が役立つ場合があります。ビジネスコミュニティなら、明確なログと一貫したエスカレーション手順が重要です。強い権限を持つロールが多いサーバーでは、新しいアプリを追加する前に権限設計を見直してください。

すべてのBotに共通する「Security Botダッシュボード」はありません。製品ごとに管理画面が異なります。サーバーの緊急確認を求めるDMではなく、開発元の公式サイトやドキュメントから管理画面へアクセスしてください。

DiscordのセキュリティBotは安全？

表示名だけでは安全性を判断できません。対象のアプリケーション、開発元、要求されるアクセス権を確認してください。見慣れたアイコン、大規模なコミュニティ、Bot一覧サイトへの掲載だけで確認を済ませないでください。

導入前に、招待リンクが開発元の公開するインストール手順と一致するか確認します。プライバシー情報を読み、メッセージ内容、モデレーションログ、認証データがどう扱われるか調べてください。実際に使う機能に必要な権限だけを付与し、まず非公開のテストサーバーで動作を確認します。

DiscordのセキュリティBotから認証を求められたら、サーバーの認証チャンネルを自分で開き、リンク先を確認してください。通常のOAuth認証でDiscord上のアクセス許可を求めることはありますが、外部ページにアカウントトークンを貼り付けたり、リカバリーコードを入力したり、PC上でコマンドを実行したりする必要はありません。手順が途中で変わった場合は中止し、以前から使っている信頼できる連絡経路でモデレーターに確認しましょう。

VPNやプロキシを使っていることだけを理由に、メンバーを悪意ある利用者と判断してはいけません。共有ネットワークやプライバシーツールは誤検知につながることがあります。外部認証サイトを使う場合は、収集するデータを説明し、異議申し立ての方法を用意してください。Discordが公開しているGuild Member Addイベントには、ギルドメンバーオブジェクトとギルドIDが含まれます。関連するギルドメンバースキーマとユーザースキーマには、メンバーのIPアドレス欄は記載されていません（2026年10月29日確認）。これは公開されているBot向けデータの範囲に限った説明であり、外部認証サイトが収集する情報について述べたものではありません。

Discord向けセキュリティBotの選び方

最適なBotは、管理負担を不必要に増やさず、サーバー固有の弱点を補えるものです。購入や複数Botの導入を決める前に、必要な動作を絞り、実際にテストしてください。

最初の選択肢はDiscord AutoModです。 サードパーティ製Botを追加せずに、キーワードやスパムを標準機能で制御できます。専門Botを後から導入する場合も、基本設定として活用できます。現在の機能はDiscord AutoModのドキュメントで確認してください。

サーバーへの破壊的な変更が懸念される場合は、Wickを候補として評価できます。 公式ドキュメントには、アンチヌーク監視、隔離、復元機能が記載されています。これらは設定とサーバー内の権限に左右されるため、頼る前に使い捨てのテスト環境で検証してください。導入直後からすべての保護機能が有効だと決めつけず、Wickの機能ドキュメントを確認しましょう。

一般的なモデレーションBotは、日常業務に向く場合があります。 候補製品の最新ドキュメントにあるルール、例外、ログ機能をチームの要件と照らし合わせてください。複数Botで重複した処罰を設定すると、1つの出来事に対して相反する処理が連続するおそれがあります。導入前に、予定しているプランで必要な機能が使えるか確認してください。

無料のDiscordセキュリティBotを探す場合は、まずDiscord標準機能を設定し、追加Botの無料機能を個別に確認します。プレミアム機能を前提にする場合は、現行プランの制限を調べてください。GitHub上のBotは別の観点で評価が必要です。スター数よりも、保守状況、依存関係、シークレットの扱い、実際のコード経路を確認しましょう。Redditの投稿は繰り返し報告される不満の把握には役立ちますが、セキュリティ監査の代わりにはなりません。

Discordの基本的な安全設定を行う

以下は、すべてのBotで共通するダッシュボード手順ではなく、一般的な初期設定です。手順4では、期待結果を確認できるAutoModのテストを行います。続く節では同じ考え方で特定のBotを設定します。掲載画像はDiscord公式チュートリアルの例であり、この記事用に設定したサーバーの画面ではありません。

手順1：Botを招待する前に基本設定を整える

非公開のテストサーバーを用意し、モデレーターだけが閲覧できるログ用チャンネルを作成します。一般メンバー、モデレーター、管理者のロールを決めてください。Botが停止した場合にどの設定を変更するか、復旧手順も文書に残しておきます。

Safety Setupでサーバーの認証レベルを設定します。コミュニティサーバーでは、DM and Spam Protection内に表示される場合があります。利用可能な条件や画面上の場所は、Discordの認証レベルガイドを確認してください。

手順2：目的のアプリケーションをインストールする

ホスティング型Botを使う場合は、公式ドキュメントから案内されている招待リンクを開き、テストサーバーを選択してください。他者が運用するBotを導入するだけなら、新しい開発者アプリケーションを作る必要はありません。

独自Botを作る場合は、Discord Developer Portalでアプリケーションを作成し、BotユーザーとGuild Installの設定を行います。トークンはシークレット管理サービスまたは環境変数で保護してください。実装で必要なインストールスコープと権限だけを追加します。Discordの初めてのBot作成チュートリアルでは、アプリケーション作成とインストールを説明しています。サンプルアプリは出発点であり、完成したセキュリティBotではありません。

使用言語に対応した、保守されているDiscordライブラリを選びます。処理するイベントに応じてGateway intentsを有効にしてください。メッセージ本文を調べる場合、特権インテントのMessage Content intentが必要になることがあります。古いチュートリアルに書かれているからという理由で、無関係な特権インテントまで有効にしないでください。

手順3：権限とロールの順序を確認する

実際に使う機能ごとに必要な権限を整理し、ロールの順序とチャンネルごとの上書き設定を確認します。Administratorは広範なアクセス権です。標準で付与するのではなく、製品ドキュメントの要件と照合してください。

Botのロールは、管理対象のロールより上に配置してください。権限を有効にしても、ロール階層の制限でモデレーション操作が失敗することがあります。詳しくはDiscord権限リファレンスを確認してください。

アンチヌーク製品の中には、機能を実行するために広い権限が必要なものもあります。そうした権限を付与するなら、そのアプリを重要なインフラとして扱い、設定を変更できる人を制限し、所有者アカウントで多要素認証を有効にし、設定変更を定期的に確認してください。

手順4：AutoModのキーワードルールを設定してテストする

テストサーバーで次の手順を実行します。

1. Server Settings → AutoModを開きます。クライアントによってはSafety Setup内のAutoModから設定します。
2. Custom Keyword Ruleを作り、Baseline testと名前を付けます。無害なキーワードmoderation-test-onlyを追加します。
3. Block MessageとSend Alertを有効にし、モデレーター専用の通知チャンネルを選択します。
4. ルールを保存します。テスト用チャンネルとテストメンバーのロールが、どちらも除外対象になっていないことを確認します。
5. AdministratorやManage Serverを持たない一般メンバーのアカウントから、指定した文字列を投稿します。特権アカウントは除外される場合があるため、管理者でのテストでは確認になりません。
6. 2つの結果を別々に確認します。メンバー側で投稿がブロックされ、非公開の通知チャンネルにイベントが届くことを確かめます。
7. 結果を記録し、テスト用ルールを削除します。

これはDiscord AutoModのドキュメントをもとにした、読者が実施する受け入れテストです。この記事のサーバーで実行した記録ではありません。実際にテスト済みと紹介する場合は、自分の環境での結果を添えてください。

手順3で選ぶアクションは、次のスパムフィルター画面のように表示されます。公式画面ではBlock messageが選択され、Send alertは未選択です。キーワードテストでは両方を有効にしてください。この画像はスパムフィルターの画面であり、Custom Keywordルールの編集画面ではありません。

任意設定：メンションスパムを制限する

メンションスパムルールは、2つ目のAutoModルールとして役立つ場合があります。通常のコミュニティ活動を妨げないしきい値に設定してください。スクリーンショットの数値は画面例であり、推奨値ではありません。誤検知の状況を見ながら調整しましょう。

続いてアクションを選びます。まずBlock messageを設定し、ログチャンネルを追加してください。Timeout memberは、ルールがどの程度作動するか確認してから有効にします。次の公式画面ではBlock messageだけが選択されています。

テストサーバーにDiscordセキュリティBotを設定する方法

ここでは、本文で評価対象としているWickを例にします。以下はWickのドキュメントに基づくチェックリストであり、実際のインストール記録ではありません。この記事ではWickアカウントや有料プランを利用しておらず、ボタン名、無料プランの制限、実機画面について断定していません。他のBotではダッシュボードや必要権限が異なります。

1. 公式の入口を確認する： 検索広告やDMではなく、この記事で案内する公式ドキュメントから始めます。アプリケーション名と、参照したドキュメントの日付を記録してください。
2. テストサーバーだけを認証する： 認証画面の権限一覧を読み、使う予定の機能と照合します。手軽だからという理由で、必要以上のアクセスを許可しないでください。
3. ダッシュボードとセットアップウィザードを開く：Wickのセットアップガイドでは、ダッシュボードでサーバーを選び、ウィザードを開始する手順が説明されています。実際の画面に表示された案内に従ってください。
4. 認証ロールとログチャンネルを選ぶ： 手順1で用意した専用ロールとモデレーター専用チャンネルを使います。ダッシュボードだけでなく、Discord上にもロールとチャンネルが存在することを確認します。
5. ロールの順序を調整する： Botが管理するロールより上にBotのロールを置き、Botに管理させないロールより下に配置します。
6. 一般メンバーでテストする： 認証フローを通じて参加するなど、破壊的でない操作を1つ試し、確認に必要な情報がログに残ることを確かめます。大量参加や破壊的なテストは行わず、稼働中のコミュニティでアンチヌーク機能を試さないでください。
7. 元に戻す手順を準備する： 問題が起きた場合に、Botのルールを一時停止し、テスト用ロールを削除し、サーバーからアプリを解除する方法を把握しておきます。

手順がドキュメントと異なる場合は中断し、公式サイトを開いているか確認してください。

どのBotでも使える簡易受け入れテスト

管理者権限のないテストアカウントを使います。新規参加者に意図したオンボーディングチャンネルが表示されること、許可されたメンバーが参加できること、無害なテスト投稿に期待どおりの対応が行われること、非公開ログに確認可能な情報が記録されることを確かめます。

失敗時の動作も確認してください。使い捨てのテストロールをBotより上に移動し、操作失敗がどう報告されるか観察します。独自ワーカーを一時停止し、リンクの安全を断定するのではなく、チェック不能として報告されることも確認しましょう。各テスト後は設定を元に戻してください。

DiscordセキュリティBotでRola IPのプロキシが役立つ場面

ホスティング型のモデレーションBotは、通常、提供元のインフラ上で動作します。プロキシを購入しても、その提供元のネットワーク経路を変更できるとは限りません。Rola IPが関係するのは、独自Bot、外部認証サービス、または許可された外部リソースを確認するワーカーを自分で管理している場合です。

通信経路を2つに分けて考えます。DiscordクライアントはDiscord GatewayとRESTエンドポイントに接続し、外部ワーカーは設定したプロキシを通して、許可されたサードパーティのHTTPSエンドポイントに接続します。レート制限への対応はDiscordクライアント側に置き、プロキシ設定はワーカーのHTTPセッションに適用してください。プロキシに障害が起きた場合、ワーカーは直接接続へ切り替えず、チェック不能として報告する必要があります。

たとえば、独自のモデレーション処理で、許可されたドメイン情報を送信元IPの登録が必要なレピュテーションサービスへ送る場合があります。ワーカーは設定済みのプロキシ経由でリクエストし、サービスの結果とリクエストIDを記録します。チェックに失敗した場合は「利用不可」としてモデレーターの確認に回してください。メンバーが入力した任意のURLを、ワーカーのリクエスト先にしてはいけません。

Discord event -> application queue -> external worker -> configured Rola proxy -> approved reputation API

Worker result -> moderator review / log -> Discord client -> Discord API

これは推奨アーキテクチャの例です。Rola IPは特定のレピュテーションサービスとの接続をテストしていません。後述のスクリプトで検証するのは出口経路であり、レピュテーションサービスとの連携ではありません。

外部リクエストを安定させる固定IPを選ぶ

サードパーティサービスがワーカーの送信元アドレスを許可リストに登録する場合は、その要件に照らしてRola IPの固定住宅プロキシを検討できます。購入前に、利用するプランのIP割り当て、更新条件、通信量、対応プロトコルをアカウント画面で確認してください。「固定」という名称だけから契約条件を推測してはいけません。

送信元アドレスの一貫性が必要なリクエストでは固定出口を使い、接続先が受け入れるかテストします。タイムアウト、認証エラー、接続失敗は、モデレーション結果とは分けて監視してください。IPアドレスが変わらないことは、サービス稼働率や接続先からの信頼を保証しません。

許可された地域別チェックにはローテーション住宅プロキシを検討する

地域によって表示が変わるリソースを許可された範囲で確認する場合は、ロケーションとセッションの選択肢があるローテーション型サービスとして案内されているRola IPの住宅プロキシを検討できます。ワーカーに設定する前に、選択したプランで利用できる地域とセッション設定を確認してください。

関連リクエストで一定期間同じ出口が必要な場合はスティッキーセッションが役立ちます。異なるネットワーク地点からの確認が本当に必要な場合はローテーションを検討します。生成したエンドポイントがどの動作をするか、セッションがどの程度継続するか、出口が利用できなくなったとき何が起きるかを確認してください。この記事では、アカウントごとのIPプール規模、国数、同時接続数、無制限通信量、稼働率保証を想定していません。

プロキシで守れる範囲を正しく理解する

正しく設定した外向きリクエストでは、接続先にプロキシの出口IPが通知されます。これにより外部ワーカーの送信元をホスティング元のアドレスと分けられる場合がありますが、ホストへのすべての経路が隠れるわけではありません。また、外部公開された受信エンドポイントをDDoS攻撃から守るものでもありません。

プロキシを使っても、疑わしいURLが無害になるわけではありません。メンバーが入力したリンクを直接開くのではなく、許可されたレピュテーションサービスに指標を送って確認する方法を優先してください。直接調査が必要な場合は、ネットワークを制限し、クラウド認証情報を持たせず、リダイレクト、応答サイズ、実行時間を制限した隔離ワーカーを使います。DNS解決やリダイレクト後も含め、プライベート、ループバック、リンクローカル、メタデータ用の宛先をネットワーク境界で遮断してください。

許可された外部リクエスト向けPython設定例

検証状況：Rola IPプロキシへの実接続は未テストです。 スクリプトのエラー処理は、2026年10月29日にLinux、Python 3.12.3、Requests 2.33.1の環境でシミュレーションテストを行いました。対象は、設定の未指定・不正、ローカルプロキシの接続拒否・応答停止、HTTP 403と429のモック応答、不正な応答本文、成功を模した応答です。以下で指定するrequests==2.34.2は推奨バージョンであり、テストに使用したバージョンではありません。Rolaのエンドポイント、認証情報、アカウント固有設定は提供されていないため、直結とプロキシ経由の実接続結果はありません。この例は参考構成であり、検証済みの本番環境やマルウェアスキャナーではありません。

実行環境とエンドポイントを準備する

以下のコードをproxy_check.pyとして保存します。元稿ではテストファイルtest_proxy_check.pyと、その記録test_output.txtも草稿と一緒に提供するとされています。PowerShellで仮想環境を作り、依存ライブラリをインストールします。

py -3.12 -m venv .venv
.\.venv\Scripts\python.exe -m pip install requests==2.34.2
.\.venv\Scripts\python.exe --version
.\.venv\Scripts\python.exe -m pip show requests

これらは読者向けのセットアップコマンドです。前述のシミュレーションテストはLinuxで実行しており、これと同じコマンドを使ったWindowsテストではありません。本番利用前に依存ライブラリの更新を確認してください。RolaのPython Requests向けプロキシ設定ガイドではエンドポイントの設定を説明しています。アカウントで選んだ製品設定から、ゲートウェイのホスト名または割り当てIP、ポート、対応プロトコル、プロキシ認証情報を取得してください。ユーザー名とパスワードを使うURLの形式はhttp://USER_ENCODED:PASSWORD_ENCODED@HOST:PORTです。各文字列は実際に使える接続情報ではなく、置き換え用のラベルです。ユーザー名とパスワードは個別にURLエンコードしてください。アカウントで発行されたユーザー名を使い、製品別のセッションや地域指定の接尾辞がある場合もそのまま含めます。パラメーター名を推測して作らないでください。

IP許可リストによる認証では、プロバイダーが指定する形式を使い、ワーカーの実際の送信元IPを許可リストに登録します。両方の認証方法が必要な場合は、どちらも設定してください。HTTPプロキシでCONNECTトンネルを使っても、接続先はHTTPSです。この例では、選択したプランが対応するHTTPプロキシエンドポイントを使います。特定のポートや地域対応を前提としていません。

環境変数を設定して接続を個別に確認する

PowerShell 7ではマスク入力を利用し、プロキシURLをコマンド履歴にそのまま残さないようにします。プロンプトにアカウント発行済みのURLを入力してください。環境変数はプロセス内のシークレットであり、暗号化された認証情報保管庫ではありません。

$env:ROLA_PROXY_URL = Read-Host 'Proxy URL' -MaskInput
.\.venv\Scripts\python.exe .\proxy_check.py --direct
.\.venv\Scripts\python.exe .\proxy_check.py
Remove-Item Env:ROLA_PROXY_URL

最初の実行ではアプリケーションのプロキシを使わず、固定エンドポイントにアクセスします。そのエンドポイントにホストの通常の出口IPが通知されます。この基準リクエストが許可されている場合だけ実行してください。2回目はプロキシ環境変数が必須で、失敗時に直接接続へ切り替わりません。本番環境ではシークレット管理サービスを使ってください。

"""Fixed-endpoint egress diagnostic for an approved external worker.

Live Rola connectivity has not been tested with this script.
Errors are reported by category and status code only; raw exception text
(which can contain proxy credentials) is never printed.
"""
import argparse
import ipaddress
import os
from urllib.parse import urlsplit

import requests

ENDPOINT = "https://api.ipify.org?format=json"
TIMEOUT = (5, 15)  # (connect, read) seconds


class EgressError(Exception):
    """A sanitized failure category that is safe to print."""


def observe_exit(proxy_url=None):
    with requests.Session() as session:
        session.trust_env = False
        if proxy_url:
            session.proxies = {"http": proxy_url, "https": proxy_url}
        try:
            response = session.get(ENDPOINT, timeout=TIMEOUT, allow_redirects=False)
        except requests.exceptions.ProxyError:
            # CONNECT failures, including proxy auth (407), usually surface here.
            raise EgressError("ProxyError: proxy refused or could not tunnel; "
                              "check endpoint, credentials, allowlist; no direct retry") from None
        except requests.exceptions.Timeout:
            raise EgressError("Timeout: check DNS, port and proxy reachability; "
                              "retest manually; no direct retry") from None
        except requests.exceptions.SSLError:
            raise EgressError("SSLError: certificate verification failed; "
                              "do not disable verification") from None
        except requests.exceptions.ConnectionError:
            raise EgressError("ConnectionError: could not connect; "
                              "check DNS and network path; no direct retry") from None
        except requests.exceptions.RequestException:
            raise EgressError("RequestException: request failed; no direct retry") from None

        status = response.status_code
        if status == 429:
            wait = response.headers.get("Retry-After", "")
            wait = wait if wait.isdigit() else "not provided"
            raise EgressError(f"HTTP 429 from the check endpoint (Retry-After: {wait}); "
                              "stop, wait, then rerun manually")
        if status != 200:
            raise EgressError(f"HTTP {status} from the check endpoint; no direct retry")
        try:
            return str(ipaddress.ip_address(response.json()["ip"]))
        except (ValueError, KeyError, TypeError):
            raise EgressError("InvalidResponse: HTTP 200 without a valid ip field; "
                              "not a success") from None


def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("--direct", action="store_true")
    args = parser.parse_args()
    proxy = None if args.direct else os.environ.get("ROLA_PROXY_URL", "")
    if not args.direct:
        if not proxy:
            parser.exit(2, "ROLA_PROXY_URL is required; no request sent\n")
        try:
            parsed = urlsplit(proxy)
            valid = (parsed.scheme in {"http", "https", "socks5h"}
                     and parsed.hostname and parsed.port)
        except ValueError:
            valid = False
        if not valid:
            parser.exit(2, "Invalid proxy URL; no request sent\n")
    try:
        print("Observed exit:", observe_exit(proxy))
    except EgressError as exc:
        parser.exit(1, f"Egress check failed - {exc}\n")


if __name__ == "__main__":
    main()

これは1回ずつ実行する手動診断なので、失敗時に停止し、自動で再試行しません。本番ワーカーでは独自の回数上限付きリトライとキュー処理を追加してください。その場合も直接接続へのフォールバックは行わないでください。

出力を解釈する前に成功条件を決める

成功とみなすには、固定エンドポイントからHTTP 200を受け取り、IPアドレスとして有効な値を解析できる必要があります。直結時とプロキシ使用時の値は非公開で比較してください。プロキシ側で異なる出口IPが観測され、想定される出口またはプロバイダー側の記録とも一致すれば、このリクエストが別の経路を使ったことを裏付ける材料になります。2つの値が同じなら、経路は確認できていません。先へ進まず原因を調べてください。1回の成功だけでは、継続的な稼働、位置精度、Botとの互換性は確認できません。実際の出力を共有する場合はIPアドレスを伏せてください。

以下はシミュレーションテストの結果です。実際のRola接続は含みません。

シミュレーションで使った認証情報の文字列は、どの出力にも表示されませんでした。TLS証明書の検証は有効なままにしてください。対応するSOCKSエンドポイントを使う場合は、requests[socks]==2.34.2をインストールし、プロバイダーが対応するスキームを選びます。socks5h://では、ホスト名の解決をプロキシ側で行います。RequestsのプロキシドキュメントにURL形式とSOCKSの挙動が説明されています。SOCKS接続はテストしていません。

観測したIPの確認には、RolaのIP検索ツールを利用できます。ただし、IPの分類結果は接続先からの信頼を証明するものではありません。ブラウザーの「IP確認」結果が示すのはブラウザーの経路であり、ワーカーの経路とは限りません。この同期処理の例を非同期Discord Botと使う場合は、ワーカーまたはスレッド内で実行してください。チェックできないときは、安全と断定せず、利用不可として報告して担当者へ通知します。

推測に頼らないトラブルシューティング

サーバーとネットワークを無理なく運用する

権限変更、期限切れの認証情報、モデレーションの誤検知を定期的に見直してください。招待を一時停止する人、認証レベルを強化する人、危険な連携を無効化する人、メンバーに連絡する人を決め、簡潔なインシデント手順を用意します。依存サービスが使えないときの対応を決めておくことも、安定運用の一部です。

独自ワーカー用にプロキシを契約する場合は、課金単位、最低購入量、通信量の有効期間、失敗リクエストの課金有無、ワーカーを停止する予算上限も確認してください。これらは記事から推測せず、利用するプラン画面で確認します。

まとめ

DiscordセキュリティBotを安定して運用するには、権限を明確にし、適切な認証ルールを設け、実際にテストしたモデレーション操作を使うことが基本です。Discord標準の安全機能で土台を作り、コミュニティ固有のリスクを補えるBotを選んでください。サーバーの成長に合わせてログと誤検知も見直します。独自構成では、外部リクエストのネットワーク設定と、依存サービスが停止した場合の対応も必要です。

固定の出口IPや、許可された地域別チェックが必要なワークフローでは、Rola IPの固定型・ローテーション型プロキシが外部リクエストの経路として選択肢になります。セッションと地域の要件に合わせて種類を選び、許可されたエンドポイントで検証してください。利用規模を広げても、Discord API自体のレート制限処理は別途維持します。