2026.07.22

Discord Webhookの使い方｜作成からcurl送信・レート制限まで

sanane

記事内に商品プロモーションを含む場合があります

Contents

はじめに
Discord Webhookとは｜botとの違い
Webhookを作成する｜サーバー設定から発行
curlでメッセージを送信する｜基本形
投稿者名・アイコンを送信時だけ変える
レート制限（429）はいつ起きる？実測してみた
投稿先チャンネルの変更・Webhookの削除
まとめ

はじめに

Discord の Webhook（ウェブフック）は、プログラムから Discord のチャンネルにメッセージを自動投稿するための入口です。サーバーに専用の URL を1つ発行しておけば、あとはその URL に向けて POST するだけで、bot を常駐させなくても通知を送れます。

本記事では、2026年7月の実機検証をもとに、Webhook の作成 → curl での送信 → 投稿者名・アイコンの上書き → レート制限（429）の挙動 → 編集・削除までを、実際の画面とレスポンスで一通り追いかけます。特に、つまずきやすい「保存ボタンの落とし穴」と「どういうときに 429 が返るのか」は実測値付きで解説します。

こんな人にオススメ

Discord に自動で通知を飛ばしたいが、bot を作るのは大げさに感じる
Webhook URL を作ったあと、実際にどう送信するのか知りたい
「429 Too Many Requests」が出る条件と対処法を実測で確かめたい

URL の取得手順だけをサッと知りたい方は、先に以下の記事を読んでから戻ってくると理解が早いです。

あわせて読みたい

Discode Webhook URLの取得方法

Discord Webhookとは｜botとの違い

Webhook は「投稿専用の受け口」です。発行された URL に対してメッセージ本文を送ると、そのチャンネルに投稿されます。bot のようにログインやトークン管理、常時起動のプログラムは不要で、「何かが起きたら Discord に一言流す」という一方向の通知にはこれで十分です。

逆に、ユーザーの発言に反応したりコマンドを受け付けたりする双方向のやり取りには bot が必要です。使い分けの目安は「送るだけなら Webhook、反応させたいなら bot」と覚えておけば迷いません。

Webhookを作成する｜サーバー設定から発行

Webhook はサーバーごとに作成します。ここではテスト用に新しいサーバーを1つ用意し、その中で作成しました。既存の実サーバーで試すときも手順は同じです。

サーバー設定を開く

サーバー名のドロップダウン（または右クリックメニュー）から「サーバー設定」を開きます。

連携サービスを選ぶ

左メニューの「アプリ」カテゴリ内にある「連携サービス」を開き、「ウェブフックを作成」をクリックします。

名前・アイコン・チャンネルを設定

作成直後の画面で「お名前」「アイコン」「チャンネル（投稿先）」の3項目を編集できます。デフォルト名は毎回ランダムな海賊風の名前（今回は「Captain Hook」）が入ります。

URLをコピー

「ウェブフックURLをコピー」ボタンでクリップボードにコピーします。押すと一時的に「コピーされました！」の表示に変わります。

保存ボタンの落とし穴に注意。名前やチャンネルを書き換えただけでは反映されません。変更すると画面下部に「注意：保存していない変更があります！」というバーが出るので、必ず「変更を保存する」を押してください。Tab移動やフォーカス外しでは自動保存されず、これに気づかず送信すると「設定を変えたのに旧名のまま届く」というズレが起きます（実機で発生しました）。

Webhook URL はそれを知っている人なら誰でもチャンネルに投稿できてしまう鍵です。SNS やソースコード、スクリーンショットに貼り付けないでください。漏れたと思ったら、後述の手順で削除して作り直せば古い URL は即座に無効になります。

curlでメッセージを送信する｜基本形

URL さえあれば、あとは POST でメッセージを送るだけです。URL の構造は次の通りで、末尾の {id} と {token} が発行ごとに固有の値になります。

https://discord.com/api/webhooks/{webhook_id}/{token}

もっとも短い送信コマンドはこれです。content に本文を入れて POST します。

curl -X POST -H "Content-Type: application/json" \
  -d '{"content":"テスト送信です"}' \
  https://discord.com/api/webhooks/{id}/{token}

送信に成功すると、レスポンスボディは空で、HTTPステータスは 204（No Content）が返ります。「何も返ってこない＝成功」なので驚かないでください。Discord 側を見ると、Webhook に設定した名前とアイコンで投稿されています。名前の横には bot と同じ青い「アプリ」バッジが付きます。

ブラウザの JavaScript（fetch）から Webhook URL を直接叩くと、「リクエストのオリジンが無効です」（code 50067）で 400 エラーになります。discord.com 由来のオリジンを持つリクエストは拒否される仕様のため、送信は curl やサーバーサイドのコードから行う必要があります。

投稿者名・アイコンを送信時だけ変える

送信する JSON に username と avatar_url を含めると、Webhook 本体の保存済み設定を書き換えることなく、その送信だけ投稿者名とアイコンを上書きできます。1つの Webhook を「エラー通知」「デプロイ完了」など用途別に見た目を変えて使い回せる、便利な仕組みです。

curl -X POST -H "Content-Type: application/json" \
  -d '{"username":"サナネ通知Bot（上書き）","avatar_url":"https://example.com/icon.png","content":"名前とアイコンを上書きして送信"}' \
  https://discord.com/api/webhooks/{id}/{token}

username/avatar_urlを上書きして送信したメッセージがDiscordに表示された画面

実際に、Discord 上の表示が指定した「サナネ通知Bot（上書き）」＋指定アイコンに変わりました。この上書きはその1回の投稿限りで、設定画面の「お名前」は元のままです。

レート制限（429）はいつ起きる？実測してみた

Webhook を自動化に組み込むうえで気になるのがレート制限です。「連続で送りすぎると 429 が返る」とよく言われますが、実際にどのくらいで引っかかるのかを実測しました。

結論から言うと、1件ずつ順番に送る限り（15回、間隔あり）はまったく制限にかからず全て 204でした。一方、10リクエストをバックグラウンドで並列に同時送信すると、5件が 429・5件が 204という結果になりました。

429 のときのレスポンスボディは次の通りで、retry_after に「何秒待てば再送していいか」が入っています。実測では 0.39 秒前後でした。

{"message": "You are being rate limited.", "retry_after": 0.394, "global": false}

retry_after の秒数だけ待ってから再送すると、即座に 204 に戻りました。制限は自動的に解除されます。

実用上の結論：レート制限は「送信の速さ」よりも「同時多重リクエスト（並列）」で発生しやすいということです。1件ずつ通知する用途ならまず問題になりません。複数プロセスから同時に叩く自動化では、429 が返ったら retry_after 秒だけ待って再送する処理を入れておけば安全です。