最終更新日: 2026-05-12
フォーム回答をSlackに流すと、チームの反応は速くなります。
新しい問い合わせが来た瞬間に気づける。資料請求やイベント申込を、メールボックスの奥で見落としにくくなる。Googleフォームを使っているなら、Apps ScriptでSlackのIncoming WebhookへPOSTする実装もできます。
ただし、Slack通知は対応管理ではありません。
通知が流れただけでは、誰が返すのか、今どの状態なのか、営業メールを除外したのか、あとで一覧に戻れるのかが決まりません。通知は入口です。対応漏れを減らすには、通知、記録、担当者、ステータスをセットで設計します。
この記事では、フォーム回答をSlack通知する方法を、Googleフォーム+Apps Scriptの実装イメージから、Google Sheetsへの記録、FORMLOVAのWorkflow Placeでの考え方まで整理します。
フォーム自動化全体の順番を先に見たい場合は、FORMLOVAでフォーム自動化を始める方法を読むと、この記事の位置づけが分かりやすくなります。
先に結論
フォーム回答のSlack通知は、次の4点を決めてから作るのが安全です。
| 決めること | 内容 | 決めないと起きること |
|---|---|---|
| 通知条件 | 全件通知か、条件付き通知か | 営業メールやテスト送信まで流れる |
| 通知先 | どのチャンネル、どの担当領域か | 関係ない人が通知に慣れて見なくなる |
| 記録場所 | Google Sheets、FORMLOVA回答一覧、CRMなど | Slackから流れたあとに追えなくなる |
| 状態管理 | 未対応、対応中、完了、除外など | 誰かが見たことと対応済みが混ざる |
Slack通知だけを作るなら、比較的簡単です。
でも、運用で効くのは「フォーム回答が来たらSlackへ送る」ではなく、次のような設計です。
新しい回答が届く
営業メールやテスト送信を除外する
必要なカテゴリだけSlackへ通知する
Google Sheetsにも同じ回答を残す
通知文に担当者・ステータス・回答URLを入れる
対応が始まったら未対応から対応中へ変える
この形にすると、Slackは気づく場所、Sheetsや回答一覧は戻る場所、ステータスは次の行動を決める場所になります。
よくある複合例: Slackに流したのに漏れる
以下は特定の顧客事例ではなく、フォーム運用でよく起きる状態をまとめた複合例です。
問い合わせフォームの回答を、すべて #inquiry チャンネルへ流すようにしたとします。送信されると、氏名、メールアドレス、問い合わせ内容がSlackに出ます。最初の数日は便利です。チーム全員が「届いた」と分かります。
しばらくすると、営業メール、テスト送信、既存顧客からの軽い連絡、料金相談が同じチャンネルに混ざります。
ある日、料金相談の問い合わせに誰かがリアクションを付けました。別の人は「誰かが見た」と思います。さらに別の人は、Slackの流れが速くて見落とします。週次でGoogle Sheetsを見返したとき、その問い合わせはまだ未返信でした。
この失敗は、Slack通知の失敗ではありません。
通知を「対応が始まった証拠」として扱ってしまったことが問題です。Slackに流れたこと、誰かが読んだこと、担当者が決まったこと、返信が完了したことは別の状態です。
Slack通知の最小構成
Googleフォームの回答をSlackに通知する場合、よくある構成は次の通りです。
- Googleフォームの回答をGoogle Sheetsへ保存する
- Apps Scriptでフォーム送信トリガーを設定する
- SlackのIncoming Webhook URLへJSONをPOSTする
- Slackチャンネルに通知が出る
SlackのIncoming Webhooksは、指定されたURLにJSONペイロードを送ることで、選択したチャンネルへメッセージを投稿する仕組みです。Webhook URLは秘密情報なので、公開リポジトリや記事のコードに実URLを貼らないでください。Slack公式ドキュメントでも、Webhook URLは秘密として扱うよう案内されています。
Google Apps Scriptでは、インストール型トリガーを使うと、フォーム送信のようなGoogle Workspace上のイベントをきっかけに関数を実行できます。外部URLへHTTPリクエストを送る場合は、UrlFetchApp.fetch(url, params) を使います。
実装イメージは次のようになります。
const SLACK_WEBHOOK_URL = PropertiesService.getScriptProperties().getProperty('SLACK_WEBHOOK_URL');
function onFormSubmit(e) {
const values = e.namedValues;
const name = values['お名前']?.[0] ?? '未入力';
const email = values['メールアドレス']?.[0] ?? '未入力';
const category = values['お問い合わせ種別']?.[0] ?? '未分類';
const message = values['お問い合わせ内容']?.[0] ?? '';
const payload = {
text: `新しいフォーム回答: ${category}`,
blocks: [
{
type: 'section',
text: {
type: 'mrkdwn',
text: `*新しいフォーム回答*\n*種別:* ${category}\n*氏名:* ${name}\n*メール:* ${email}\n*内容:* ${message}`,
},
},
],
};
UrlFetchApp.fetch(SLACK_WEBHOOK_URL, {
method: 'post',
contentType: 'application/json',
payload: JSON.stringify(payload),
});
}
これはあくまで最小例です。
実運用では、Webhook URLをスクリプトプロパティに保存する、テスト送信を本番チャンネルに流さない、エラー時にログを残す、通知文に回答シートの行番号や管理画面URLを入れる、といった調整が必要です。
Apps Scriptで実装する場合は、Google Apps Scriptのインストール型トリガー、UrlFetchApp、Slack Incoming Webhooksの一次情報を確認してください。
通知文に入れるべき項目
Slack通知の本文は、長ければよいわけではありません。
重要なのは、通知を見た人が次の判断をできることです。最低限、次の項目を入れます。
| 項目 | 理由 |
|---|---|
| 回答種別 | 問い合わせ、資料請求、採用、イベント申込を分ける |
| 氏名・会社名 | 誰から来たかをすぐ判断する |
| メールアドレス | 返信先を確認する |
| 要約 | 長文を全部読まなくても温度感をつかむ |
| 回答URLまたは行番号 | Slackから記録場所へ戻れるようにする |
| 初期ステータス | 未対応なのか、除外なのかを分ける |
| 担当候補 | 誰が見るべきかを通知時点で示す |
逆に、すべての自由記述をSlackに流す必要はありません。
個人情報や機密に近い内容を含むフォームでは、Slackに出す情報を絞ります。Slackには要約と管理画面URLだけを出し、詳細は権限のある場所で確認する設計にします。
全件通知は最初だけでよい
最初は全件通知でも構いません。
フォームの送信量が少ないうちは、全件を見たほうが状況を理解しやすいです。どんな問い合わせが届くのか、営業メールがどれくらい混ざるのか、カテゴリが足りているのかを見られます。
ただし、送信量が増えたら条件を切ります。
カテゴリが「料金相談」または「導入相談」
かつ営業メールではない
かつテスト送信ではない
かつステータスが未対応
このように条件を入れると、Slack通知は静かになります。
静かな通知は見られます。うるさい通知は見られなくなります。フォーム運用では、この差が大きいです。
FORMLOVAのワークフローでは、条件を eq、neq、比較、contains、not_contains、is_empty、is_not_empty のような単位で扱います。AIが勝手に全部を決めるのではなく、人間が決めた条件と意図に沿って、通知や記録を動かす考え方です。
Google Sheetsは通知の保険ではなく、記録の本体です
Slackは流れる場所です。
Google Sheetsは戻る場所です。
この2つを分けて考えると、フォーム運用はかなり整理しやすくなります。
| 役割 | Slack | Google Sheets / 回答一覧 |
|---|---|---|
| すぐ気づく | 強い | 弱い |
| あとで検索する | 弱い | 強い |
| 担当者を決める | 補助 | 強い |
| 集計する | 弱い | 強い |
| 対応履歴を残す | 弱い | 強い |
FORMLOVAでは、回答をCSVで一度書き出す方法と、Google Sheetsへ継続的に連携する方法を分けて考えています。CSVはある時点の回答を取り出す方法です。Google Sheets連携は、新しい回答を継続的に外部の表へ渡す方法です。
詳しくは回答をCSVで書き出す / Google Sheetsに自動連携する方法で整理しています。
Slack通知を作るときも同じです。通知を作ったら終わりではありません。あとから誰が、いつ、どの回答を、どう処理したかを見返せる場所を決めます。
ステータスがない通知は、対応漏れを防げない
問い合わせ対応でいちばん危ないのは、「見た」と「対応した」が混ざることです。
Slackで誰かがリアクションした。スレッドに「確認します」と書いた。担当者が口頭で返事をした。これらはすべて、対応完了とは限りません。
フォーム回答には、少なくとも次の状態を持たせます。
| ステータス | 意味 |
|---|---|
| 未対応 | まだ誰も対応を始めていない |
| 対応中 | 担当者が決まり、返信や確認を進めている |
| 完了 | 必要な返信や処理が終わった |
| 除外 | 営業メール、重複、テスト送信など |
Slack通知には、初期状態として 未対応 を入れます。
担当者が決まったら 対応中 に変えます。返信が終わったら 完了 にします。営業メールなら 除外 にします。
この状態をSlackのリアクションだけで管理しようとすると、あとで集計しにくくなります。フォーム側の回答一覧やSheetsに状態を持たせたうえで、Slackは入口として使うほうが安全です。
FORMLOVAの回答ステータス管理については、回答一覧を見て絞り込みとステータス管理をする方法を参照してください。
FORMLOVAで考えるなら、通知はWorkflow Placeの1部品です
FORMLOVAには、フォーム作成だけでなく、公開後の運用を扱うMCPツールがあります。2026年5月時点で、127個のMCPツールを25カテゴリに分けて扱っています。
その中には、回答、分析、メール、Webhook、フィルタリング、ステータス管理、スケジュール、Google Sheets、レシピなど、フォーム送信後に必要になる領域が含まれます。
Workflow Placeには、回答→Slack通知+Google Sheets記録 という横断レシピがあります。
これは「Slackに飛ばす」だけのレシピではありません。フォーム回答を起点にして、通知先と記録先を分ける考え方です。
たとえば、チャットでは次のように依頼できます。
問い合わせフォームの回答が来たら、
営業メールとテスト送信を除外して、
カテゴリが「料金相談」または「導入相談」のものだけSlackに通知してください。
同じ回答はGoogle Sheetsにも記録してください。
Slack通知には氏名、会社名、カテゴリ、要約、回答URL、初期ステータスを入れてください。
さらに運用に寄せるなら、次のように条件を足します。
Slackに通知した回答は、最初は未対応にしてください。
担当者が決まったら対応中に変更できるようにしてください。
営業メールと判断した回答は分析から除外してください。
毎週月曜に、未対応の問い合わせだけ一覧にしてください。
このプロンプトの価値は、個別のAPIを覚えなくてよいことではありません。
価値は、フォーム運用を「通知」「記録」「状態」「次の確認」に分けて、同じ意図で扱えることです。
Workflow Placeの使い方は、FORMLOVAのWorkflow Placeからレシピを見つけて、チャットで設定する方法で説明しています。MCPフォームサービス全体の考え方は、MCPフォームサービスまとめにまとめています。
実装前チェックリスト
Slack通知を作る前に、次を決めてください。
| チェック | 決めること |
|---|---|
| 目的 | 気づくためか、担当者へ渡すためか、エスカレーションか |
| 対象フォーム | 問い合わせ、資料請求、採用、イベント申込など |
| 通知条件 | 全件か、カテゴリや温度感で絞るか |
| 除外条件 | 営業メール、テスト送信、重複をどう扱うか |
| 通知先 | どのチャンネル、どの担当者、どの時間帯か |
| 記録先 | Google Sheets、FORMLOVA回答一覧、CRMなど |
| ステータス | 未対応、対応中、完了、除外の定義 |
| 失敗時 | Slack投稿失敗、Sheets連携失敗、権限切れをどう検知するか |
| 秘密情報 | Webhook URLやOAuth情報をどこに保存するか |
ここまで決めてから実装すると、Slack通知は長く使える運用になります。
逆に、ここを決めないまま通知だけ作ると、最初は便利でも、後から誰も見ない通知になりやすいです。
どの方法を選ぶべきか
最後に、選び方をまとめます。
| 状況 | 向いている方法 |
|---|---|
| Googleフォームをすでに使っていて、少量の回答をSlackに流したい | Googleフォーム + Apps Script + Slack Incoming Webhook |
| ノーコードで複数サービスをつなぎたい | Zapier、Makeなどの外部自動化 |
| 回答一覧、ステータス、Sheets連携、通知条件までまとめたい | FORMLOVA |
| MCPクライアントからSlackやSheetsも含めて運用したい | FORMLOVA + Workflow Placeの横断レシピ |
GASで自作する方法は、軽く始めるには向いています。
ただし、送信量が増える、営業メールを除外したい、担当者やステータスを管理したい、SlackとSheetsとフォーム回答一覧を同じ運用で扱いたい、という段階になると、通知だけを自作しても足りなくなります。
FORMLOVAでは、フォームを作る前後だけでなく、公開後の回答確認、CSV/Sheets連携、ステータス管理、自動返信、条件付き通知、Workflow Placeのレシピまでを同じ運用の中で扱います。
フォーム回答をSlackに流したいなら、最初の問いは「どう通知するか」で構いません。
でも、実務で最後に残る問いは「誰が、どの回答を、いつ、どの状態まで進めるか」です。
Slack通知は、その問いに答えるための入口として設計してください。
参考情報
- Slack: Sending messages using incoming webhooks
- Google Apps Script: Installable triggers
- Google Apps Script: UrlFetchApp
次に読む記事
- FORMLOVAでフォーム自動化を始める方法
- 回答をCSVで書き出す / Google Sheetsに自動連携する方法
- 回答一覧を見て絞り込みとステータス管理をする方法
- FORMLOVAのWorkflow Placeからレシピを見つけて、チャットで設定する方法
- MCPフォームサービスまとめ
執筆・確認情報
この記事は、FORMLOVAの既存記事、過去インタビュー、Workflow Placeのレシピ設計、SlackとGoogle Apps Scriptの公式ドキュメントを確認して作成しました。
本文中の「よくある複合例」は、実在する特定顧客の事例ではありません。フォーム回答をSlackに流す運用で起きやすい状態をまとめた説明用の例です。
