Discordボットを公開したことがある人なら、必ず一度は経験しているでしょう。普通の火曜日だったのに、突然すべての場所でincreased api errorsが表示され、コマンドの半分が失敗します。2026年半ば、Google Trendsはこのフレーズを急上昇の検索語として記録しました。エンドユーザーが直接検索するほど、頻繁に起きているということです。ここでは、この事態を乗り切る方法と、Noxyrサーバー APIがそこから得た教訓を説明します。
Discord APIの失敗パターン3つ
- 全体的な障害／部分的な障害：discordstatus.comで確認できます。症状としては、どのリクエストも失敗する可能性があり、ゲートウェイが切断されたり、全体的にレイテンシが急上昇したりします。
- 429 Too Many Requests：バケットの上限を超えています。Discordは
Retry-Afterヘッダーを返し、どれだけ待つべきかを正確に伝えます。 - ゲートウェイの無効なセッション：WebSocketセッションが古くなっています。再開トークンで再接続してください。それが失敗した場合は、新しくIdentifyを行います。
晴れた日ではなく、失敗に備えて作る
- Retry-Afterを尊重する。独自のタイマーで再試行しないでください。Discordが指定した時間だけ待ってから、1回だけ再試行します。429を連続して受けても押し通そうとするボットは、BANされます。
- ジッター付きの指数バックオフ。5xxエラーの際は、1秒、2秒、4秒、8秒と待ち、さらに小さなランダムなずれを加えます。再起動が一斉に行われても、殺到しないようにするためです。
- 重要でない呼び出しはサーキットブレーカーで止める。ボットが毎週のダイジェストを投稿していて、Discord APIが劣化している場合は、その回をスキップしてください。無理に押し込むのは避けます。ダイジェストは待てますが、障害は待ってくれません。
- リアルタイムでないものはキャッシュする。サーバー名、チャンネル一覧、ロールIDなどはローカルにキャッシュしてください。障害中も、キャッシュされたデータがあれば応答を続けられます。
- 状況を表示する。Discordの障害でボットのコマンドが失敗しているなら、ユーザーに伝えてください。「Discordで現在問題が発生しています」という1行があれば、無言のタイムアウトより親切です。
Noxyrサーバー APIがこれらの教訓をどう適用しているか
Noxyrサーバー APIはDiscord APIそのものではなく、自身のデータベースを読み取ります。それでも同じ原則が当てはまり、その設計を形作っています。
- 予測可能なエラー：すべての失敗は、安定した
errorコードを持つJSONで返されます。HTMLも、形式がばらばらな応答もありません。 - レート制限ヘッダー：標準化された
RateLimit-*ヘッダーを返すため、クライアントは429に達する前にバックオフできます。 - 緩やかな機能縮退：
/api/v1/serverエンドポイントは、基盤となるDiscordの取得が失敗した場合、キャッシュされたサーバーデータにフォールバックします。 - 連鎖的な障害の防止：各エンドポイントは独立して失敗します。Discordがダウンしていても、チケット分析のエンドポイントは壊れません。Discordではなく、Mongoからデータを読み取るためです。
- 即時に効く無効化スイッチ：キーやスコープを無効にすると、次のリクエストから即座に反映されます。再起動は不要です。
Discordが不安定になったときの手順
- 1.まずdiscordstatus.comを確認します。自分だけの問題でしょうか？
- 2.自分のエラーログを確認します。429、5xx、ゲートウェイの切断などです。
- 3.Discord側の問題であれば、重要でない書き込みを一時停止し、Retry-Afterを守って、回復を待ちます。
- 4.自分側の問題であれば、直近のデプロイ、キャッシュの無効化、新機能を確認します。
- 5.状況を共有します。サポートチャンネルに短く正直な告知を出すだけで、100件の重複した報告を防げます。
APIレイヤーの詳細は、Noxyrサーバー API、Discord APIとNoxyr APIの比較、APIの設計原則をご覧ください。