初動対応更新日
#漏れたWebhook URLに偽の通知を送られることはありますか？
「URLが知られただけで、何か困ることがあるの？」と感じる人もいるでしょう。通知先によっては、偽の通知を送られることがあります。
SlackのIncoming Webhookでは、URLそのものに秘密の値が入っています。そのURLへ投稿すると、決められたチャンネルにメッセージが表示される仕組みです（SlackのIncoming Webhook仕様）。宛先のアドレスを知っていれば、事前の認証なしに指定したチャンネルへメッセージを直接送信できます。そのため、悪意のある第三者にURLが知られた場合、管理者の意図しない偽の通知やフィッシングリンクがチャットに投稿される恐れが生じますね。
Studioの事案ページ（Studioの不正アクセスに関するお知らせ）では、Webhook通知URLが流出した可能性のある情報に挙げられています。第三者が情報を取得した事実は確認されていないものの、取得された前提で切り替えを進める方針が示されています。
あわせて、2026年9月30日以降に通知先へ心当たりのない通知が来ていないかを見てください。見覚えのない通知があっても、本文のリンクは開かないこと。Slackの通知はふだんから流し読みしがちなので、特にリンク付きのメッセージは送り主と内容をよく見てから扱うほうが安全ですね。
#Webhookを差し替える正しい順番は？
漏えいの疑いがあるとき、慌てて受信側の古いURLを先に削除してしまってはいないでしょうか。実は、作業の手順を前後させてしまうと、サイト公開や更新の重要な通知が途中で途絶えてしまいます。Studioがすすめている切り替えの順番は次のとおりです（Studioのインシデント対応のお願い）。
- SlackやDiscordなどの通知先サービスで、新しいWebhook URLを発行する
- Studioのプロジェクト設定を開き、通知先URLを新しいものに書き換えて保存する
- 保存後に「テスト送信」を実行し、新しい通知先にメッセージが届くか確認する
- テストの成功を確認してから、通知先サービス側で古いURLを無効化または削除する
順番を守ると、通知が途切れる時間を作らずに済みます。Slackの場合、無効にしたWebhookへ送ってもエラーが返るだけでメッセージは出ません。テスト送信の前に古いURLを止めてしまうと、どこで失敗しているのかも分かりにくくなります。
3番目のテスト送信は省かないでください。新しいURLの貼り付けで1文字欠けていたり、別のチャンネルのURLを登録していたりしても、保存だけでは気づけません。テストの通知が意図したチャンネルに出てから、古いURLを止めます。
#SlackやDiscordのWebhook URLを作り直すには？
たとえば、業務連絡のメインツールとしてSlackやDiscordを使っている現場では、受信サービスごとに再発行の画面が異なります。SlackでURLを作り直すときは、ワークスペースのアプリ管理画面から「Incoming Webhooks」の設定を開きます。通知を届けたいチャンネルを改めて指定して新しいWebhook URLを発行し、Studio側へ登録を済ませたあと、不要になった古い設定を選んで削除してください。漏れた秘密情報をSlack側で見つけて取り消す仕組みもありますが、それを待つのではなく自分で作り直しましょう。
一方のDiscordでは、サーバー設定またはチャンネル設定の「連携サービス」画面から操作を進めます。Discord公式の案内にもあるように、ウェブフック一覧から「新しいウェブフック」を作成してURLをコピーし、Studio側に反映させたあとで古いウェブフックを削除する流れです。もし画面上で作成や削除のボタンが見当たらない場合は、自身のアカウントに「ウェブフックの管理」権限が付与されているか確認してみるとよいですね。
ちなみに、DiscordのURLをStudioへ直接登録してそのまま通知が届くのかは、公式の資料でははっきりしません。Slackと同じ感覚で登録したら、テスト送信の結果で動くかを見てから古いWebhookを消すほうがよいでしょう。
#Webhookの受信側で偽の通知を防ぐ方法はありますか？
受信側だけで偽の通知を完全に遮断するのは難しく、URL自体の秘匿と適切な差し替えが基本的な防御策となります。チャットツールに標準で備わっている簡易的な通知受け口は、URLそのものを認証キーとして扱う設計が多いためです。実際、DiscordのWebhookは届いた通信が信頼できる送信元から送られたものかを個別に認証しません。そのため、URLが外部に知られてしまうと、第三者からの投稿を入り口で弾く手立てが受信側にほとんどないのが実情です。
一般的なWeb開発の世界では、送信元を検証する手段としてデジタル署名が用いられます。GitHubの検証手順のように、送信側と受信側で推測されにくい秘密の文字列を共有し、リクエストヘッダーに含まれる署名を受信側で計算・照合する仕組みであれば、偽装された通信を正確に見分けられます。しかし、こうした署名検証を行うには送信側と受信側の双方が署名機能に対応していなければなりません。
ただ、Studioの場合はこの方法をそのまま使えるとは言い切れません。署名を付けるという記載は見当たりません。自社サーバーで通知を受けている人も、署名で送り主を確かめられる前提では組めないでしょう。
URLが長く複雑でも、一度漏れてしまえば悪用を止める力はありません。受信側でできるのは、URLを公開リポジトリやチャットに貼らないこと、漏れた可能性があれば作り直して古いURLを止めること、この2つです。
こんな聞き方も
- studio webhook url 漏えい 対応
- studio webhook 悪用 偽 通知
- studio webhook 差し替え 順番
- slack webhook url 再発行
- studio webhook 通知 url 変更 場所
- webhook url 再発行 slack discord
- studio webhook slack 通知 url 悪用
- webhook 受信側 署名 検証
- 移行 業者 スプレッドシート連携 webhook 再設定
あわせて知りたい（関連する疑問）
QStudioのどこでWebhook通知URLを変更しますか？
設定画面の項目が多く、どこからURLを変更すればよいのか迷ってしまう方も少なくありません。Studioの通知機能は、フォーム回答を知らせる通知メールと、サイトの公開状態などを知らせるWebhookとで設定場所が分かれています。フォームの送信先メールアドレスは「フォーム」ダッシュボードで扱いますが、今回の対象となるWebhookはプロジェクト全体の設定画面で管理する決まりです。手順は次のとおりです（StudioのWebhook通知の設定ヘルプ）。
- 対象プロジェクトのダッシュボードで［ホーム］を開く
- ［プロジェクト設定］を開き、画面を一番下までスクロールする
- ［Webhook］の編集アイコンを押し、新しいURLを入力する
- ［保存］を押してから［テスト送信］で届くかを見る
なお、Studioのプロジェクト設定で登録できるWebhook URLは、1つのプロジェクトにつき1件のみとなっています。複数のプロジェクトで同じSlackチャンネルに通知を送っていた場合は、プロジェクトごとに書き換えとテスト送信を繰り返します。
もうひとつ知っておくと迷わないのが、Webhookで届く通知の種類です。Studioのプロジェクト設定から送られるのは、サイトの公開・更新・非公開と、サイトへのコメント追加の知らせ。これ以外の内容がStudioの名前で届いていたら、送り主をよく確かめたほうがよさそうですね。
QWebhookを使っていない場合も対応は必要ですか？
普段Webhook連携を使っていないサイトであれば、何も手を付けずにそのままでよいのでしょうか。過去に一度でもURLを登録していたなら、対応が必要です。今は通知を見ていなくても、Studioに古いURLが残っていれば、通知先のサービス側でそのURLはまだ生きています。Studioの通知先URLを空欄にして保存し、SlackやDiscordなど通知先のサービスで古いURLも無効にしてください。
Studio側の欄を空にするだけでは足りません。空欄で保存するとStudioから送るのは止まりますが、通知先に残ったURLは、知っている人がいれば使える状態のままです。一度もWebhookを設定したことがなければ、そもそも差し替えるURLはありません。迷ったら、プロジェクト設定の最下部にある［Webhook］欄を開き、何か入っているかを見れば分かります。
次に、Webhook以外の初期対応にも目を向ける必要があります。メールアドレスとパスワードの組み合わせでStudioにログインしている利用者は、アカウントのパスワード変更を済ませておきましょう。ただし、GoogleログインやFacebookログインなどのソーシャルログインだけを使い、Studio独自のパスワードを設定していない人は、このパスワード変更作業は不要とされています。もうひとつ、過去にライブプレビューURLを発行した経験がある場合は、いったんURLを削除し、共有を継続したいときだけ新しいプレビューURLを発行し直す手順が案内されました。
QGoogleスプレッドシート連携やWebhookの再設定も業者に頼めますか？
作業そのものは、制作会社などに頼むこともできます。ただ、どこまで任せられるかは、Studio・Slack・Googleのそれぞれで誰が権限を持っているかで変わりますね。
たとえばGoogleスプレッドシート連携を見直す場合、一度連携を解除してから再連携を行うと、Googleドライブ内に新しいスプレッドシートが生成されて自動更新が再開されます。連携するときにはGoogleアカウントのアクセス許可が必要になります。スプレッドシート連携の設定ガイドに記載があるとおり、連携をやり直す以前に届いていた過去の回答データは新しいシートへ自動で引き継がれません。反映されるのは連携後の回答だけなので、古いシートはすぐに消さずに残しておきます。
また、Webhookの再設定を依頼する際にも注意が必要です。SlackのIncoming Webhook URLには秘密情報が含まれるため、チャットやメールで外部業者へ受け渡す経路の安全管理が欠かせません。受け渡しの方法は事前に相談して決めておきます。さらに、社内のSlackワークスペースでアプリ承認機能が有効になっている環境では、新しいアプリの追加や再設定がワークスペース所有者やアプリ管理権限を持つメンバーだけに制限されている場合があります。業者のアカウントで操作できないこともあるので、Slackの作業は社内の管理者が受け持つほうが早いかもしれません。
独自にGoogle Apps Scriptでウェブアプリを作って連携している場合は、もう一段注意が必要です。実行するユーザーをスクリプトの所有者にするか、アクセスしているユーザーにするかで、動くときの権限が変わります。業者の人が所有者のまま作り直すと、契約が終わったあとに困ることもあるので、所有者を誰にするかも依頼の時点で決めておきます。
QStudioから移行したらWebhookはどうなりますか？
WordPressなど別の仕組みへ移ったら、Webhookも自然に止まるのでは、と考える人は多いようです。しかし、サイトの移行作業を終えただけでは、通知先サービス側に残ったWebhookの設定まで自動で消去されるわけではありません。移行に伴って不要になった場合は、プロジェクト設定のURL欄を空欄にして保存し、ステータスがOFFになったことを確かめてStudio側の送信を止めます。あわせて、SlackやDiscordなどの受信側でも、発行済みのWebhook設定を個別に削除または無効化しておかなければ、漏えい時の不正利用リスクが残ってしまいますね。Slackでは削除や無効化のやり方がアプリや連携の種類によって違うので、管理画面で該当する連携を探して止めます。
フォームの通知を使っていた人は、プロジェクト設定のWebhookとは別の経路も確かめます。Studioのフォーム回答をSlackに知らせる方法として、スプレッドシートとGoogle Apps Scriptを通してSlackのWebhook URLへ送る例が公式にあります（Studioのフォーム回答をSlackへ通知する例）。この形で組んでいた場合、Slackで取得したURLはApps Scriptの中に書かれています。Studioのプロジェクト設定を空にしても、こちらのURLは残ったままです。
サイト全体を他環境へ移行する際には、プロジェクト自体のWebhookだけでなく、こうした中継用スクリプトや外部連携ツールに埋め込まれたWebhook URLも洗い出し、旧環境の連携を一つひとつ手作業で停止させていく必要があります。
この内容をChatGPTで相談
