ひとことで言うと
Webhook URLとは、あるサービスから別のサービスへHTTPリクエストを通じて自動的にデータを送るための専用URLです。たとえばSlackのIncoming Webhookは`https://hooks.slack.com/services/TXXXXX/BXXXXX/xxxx`のような形式で、このURLにPOSTリクエストを送るとSlackの特定チャンネルにメッセージが投稿されます。
AIでインタラクティブなHTMLを生成する際、「フォーム送信時にSlackに通知する機能を追加して」と指示すると、Webhook URLをfetch()やXHRで呼び出すJavaScriptが埋め込まれることがあります。このURLが本番の通知先であれば、プレビューでの操作が即座に本番のSlackチャンネルに通知を送ります。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
HTML共有で関係する場面
社内承認フロー用のHTMLフォームにWebhookが仕込まれていた場合、テスト目的でフォームを送信したレビュアーが誤って本番の承認通知を発火させてしまうことがあります。業務システムの誤作動につながるため、プレビュー共有用のHTMLからはWebhook送信処理を外しておく必要があります。
GitHubやZapierのWebhookが埋め込まれているHTMLを外部パートナーと共有した場合、そのURLを悪意ある第三者が取り出してスパム送信ツールとして悪用するリスクもあります。Webhook URLはAPIキーと同等の機密情報として扱うべきです。
よくある誤解
「WebhookのURLは長くて複雑だから知られても大丈夫」は誤りです。Webhook URLを知っている人であれば誰でもそのURLに対してリクエストを送ることができます。SlackのWebhookなら誰でもメッセージを投稿でき、Discord Webhookなら誰でもサーバーに書き込めます。
「静的なHTMLからは外部APIを呼び出せない」も誤解です。JavaScriptのfetch()APIはローカルのHTMLファイルからでも外部URLへリクエストを送れます（CORSの制限はあるものの、多くのWebhookサービスはCORSを緩く設定しています）。HTMLを開くだけでWebhookが呼ばれるケースさえあります。
安全に使うための注意点
共有前にHTMLソース内を「webhook」「hooks.slack.com」「discord.com/api/webhooks」「api.line.me」などのキーワードで検索してください。見つかった場合は送信先URLをコメントアウトするか、処理ブロック全体を削除した状態でプレビュー共有します。Webhook機能が必要な場合は本番公開時のみ追加する運用にしてください。
誤ってWebhook URLを含むHTMLを共有してしまった場合は、そのWebhookをサービス側のダッシュボードで即座に削除または再生成して古いURLを無効化してください。SlackならApp設定画面→Incoming Webhooks、DiscordならサーバーのWebhook設定から削除できます。
よくある質問
Webhook URLが漏洩した場合、どのような被害が起きますか？
送信先によって異なりますが、Slackであればチャンネルへのスパムメッセージ投稿、Discordならサーバーへの荒らし投稿、GitHub ActionsのWebhookなら意図しないワークフロー実行などが起こりえます。発覚次第すぐにURLを無効化し、新しいURLに差し替えてください。
Webhook送信コードをコメントアウトする以外に、プレビュー共有向けの安全な対処法はありますか？
環境変数でWebhook URLを管理し、デプロイ時にのみ注入するアーキテクチャが理想的です。静的HTMLの場合は、Webhook URLを別ファイル（config.js）に切り出し、そのファイルをプレビュー共有時に読み込まないようにする方法も有効です。
テスト用のWebhook URLを別途用意する方法はありますか？
webhook.siteというサービスを使うと、受け取ったリクエストをブラウザ上で確認できる使い捨てのWebhook URLを無料で発行できます。テスト・プレビュー環境用のaction先をwebhook.siteのURLにしておけば、本番サービスに影響を与えずに動作確認ができます。