表に新しい行が増えたらSlackへ通知したい｜標準機能・Make・Zapierの考え方

PR｜料金の案内先には紹介リンクを含む場合があります。

表の新着を探し、Slackへ送り、通知済みを書いている方へ。通知する項目と相手を決められるなら、その定型部分の自動化を検討できます。ただし、新着がメールで分かれば足りる場合は、Googleフォームの標準通知を先に試す選択があります。内容の判断と返信は担当者が続けます。

表へ回答を保存するのはGoogle側の標準機能です。その後の新着確認、Slackへの通知、表への記録をどこまで任せるかが、このページで扱う範囲です。問い合わせの内容を判断して返信する仕事は担当者が続けます。図は説明用の設計例なので、接続許可やテスト環境を整える前に実際の問い合わせを流さないでください。ここから、自分の条件で方法を選びます。

比較表

代表的な選び方で、すべての方法を網羅した比較ではありません。今の手作業で困っていないなら、それを続けても構いません。料金の安さだけで、新しい保守作業を増やす判断はしないようにします。

今、担当者がしていること

問い合わせはGoogleフォームで受け付けます。回答表への保存はGoogle側の標準機能です。その後、担当者が表を開いて新しい行を探し、必要な項目をSlackへ転記し、表に通知済みを記録します。最後に内容を判断し、返信します。保存まで人が毎回入力し直している、という例ではありません。

Makeでつなぐ場合の流れ

新しい行を一定の間隔で確かめ、決めた項目をSlackへ通知し、元の行に通知済みを記録する流れを考えます。Make公式には新規行の確認、Slackメッセージ送信、行更新の処理が掲載されています。機能があることと、この組み合わせを実際につないで動かしたことは別です。今回は接続していません。

担当者はSlackの通知を読み、内容を判断し、返信・対応します。表への記録が終わるまで返信できない、という依存関係にはしません。通知が届いたことは対応完了でもありません。定期確認の構成なので、即時通知を保証するものではありません。

条件を当てはめた例

説明用の表に受付ID「SAMPLE-001」、種別「資料請求」、空欄の通知済み列を用意します。Slackには受付IDと種別、それから「内容は回答表で確認」と送る設計です。氏名や問い合わせ全文は通知に含めません。成功後に元の行へ「済」と書きます。この「済」は通知の記録で、問い合わせへの返信が終わった意味ではありません。

受付IDと管理列は例のために用意したものです。GoogleフォームがそのIDを付けるとは限りません。実際の構成でIDを付ける作業が必要なら、準備や追加処理として計上します。架空の顧客事例や時間削減の実績として扱わないでください。

条件と注意

GoogleとSlackを接続する許可と、通知先の閲覧者を先に確かめます。行の更新にはどの行を変えるかの指定が必要です。列名、監視する範囲、初回に処理する行の範囲を、テスト用の表で確かめます。新規行監視には空の行があると後続の行を処理しない制約が公式に記載されています。

Slackへの送信が終わり、表への記録だけが失敗する場合も考えます。通知済み欄が空でも再送せず、担当者がSlackと表を照合します。通知を止める方法、手作業へ戻す方法、再実行する範囲まで決めておきましょう。保守担当を置けない、必要な権限を許可できない場合は、今回の構成をそのまま試さない選択です。

次の一手

選択式の確認欄で、メール通知で足りるか、今の作業を見直すかを整理できます。Makeが候補になった方は、無料枠と料金条件へ進んでください。接続の許可、待てる時間、月の件数、失敗時の担当者が不明なら、その条件を先に確かめます。

PR｜料金の解説ページには紹介リンクを含む場合があります。 MakeとZapierを比較する

出典・確認日

• Googleフォームの回答とメール通知（2026-09-25確認）
• MakeのSheetsとSlack連携（2026-09-25確認）
• MakeのGoogle Sheets処理（2026-09-25確認）
• Makeの未完了実行（2026-09-25確認）
• Zapierの料金・利用条件（2026-09-25確認）

公式機能を基にした説明用の設計例です。実接続、消費量、削減時間、導入成果は未検証です。読者像と需要も未検証です。

運営者情報・広告方針・お問い合わせ

Makeが必要かどうかから整理する / Makeの無料枠と料金条件