PR このサイトはアフィリエイト広告を利用しています。料金の解説ページには紹介リンクがあります。
問い合わせ受付・社内への連絡を担当している方へ
問い合わせの新着確認とSlackへの転記、毎回手作業でしていませんか？
Googleフォームの回答を表で確認し、Slackへ知らせ、通知済みを記録する。同じ作業を繰り返しているなら、仕組みに任せられる部分があります。まずは作業の流れを見ながら、標準のメール通知で足りるか、自動化ツールが必要かを整理しましょう。
手作業と自動化の違いを見る図は仕組みを説明するための例です。実際の接続動作や、削減できる時間は未検証です。
作業の流れを比べる
新着の確認・通知・記録。どこを任せられる？
今、担当者がしている作業
表への保存は標準機能。その後の確認・通知・記録を、担当者が繰り返しています。
- 受付Googleフォーム問い合わせを受け付ける
- Googleの標準機能Googleスプレッドシート回答を表に保存
- 人が確認回答表表を開いて新着を探す
- 人が転記Slack必要な項目を送る
- 人が記録回答表通知済みを書き込む
- 人が対応問い合わせ内容を判断して返信
Makeに任せる部分と、担当者が続けること
確認・通知・記録をつなぎます。問い合わせの内容を判断して返信するのは、担当者です。
共通の受付：Googleの標準機能
- 受付Googleフォーム問い合わせを受け付ける
- 保存Googleスプレッドシート回答を表に保存
Makeが行うこと
- 1. 定期的に確認回答表新しい行を探す
- 2. 通知Slack必要な項目を送る
Slackへ送った後、Makeは記録へ
Makeが続けること
Slackの通知を受けて、担当者は対応へ
担当者が行うこと
- Slackの通知を読む
- 内容を判断する
- 返信・対応する
表の記録が終わるのを待つ必要はありません。
一定の間隔で確認する構成です。即時通知を保証するものではありません。
フォームから表への保存は、Google側の標準機能を使います。Makeを検討するのは、その後の新着確認・Slackへの通知・通知済みの記録です。Slackに通知したことと、問い合わせへの対応が終わったことは別です。
新しいツールが必要か考える
メール通知だけで足りるなら、新しいツールは不要です
必要なことから、方法を選ぶ
代表的な3つの選び方です。すべての方法を網羅した比較ではありません。
今の確認方法で困っていない
選択肢：今の手作業
手作業を続ける選択でも構いません。設定や保守を増やしてまで変える必要があるかを考えましょう。
今の方法を続ける登録や次のページへの移動は不要です。
返信に人の判断が必要でも、新着確認や決まった項目の通知を切り離せる場合があります。どこまで同じルールで行えるかを考えましょう。
複数のサービスをつなぎたいとき
Makeは、いつものサービス同士をつなぐツールです
Makeは、GoogleスプレッドシートやSlackなどのサービスをつなぎ、あらかじめ決めた処理を自動で進めるためのツールです。この例では、新しい問い合わせの確認、Slackへの通知、表への記録をつなぐ選択肢になります。
最初の接続設定と、動かなかったときの確認は必要です。Makeを入れるだけで、問い合わせ対応がすべて終わるわけではありません。
1件の問い合わせが、どこにどう記録されるか
説明用のサンプルです。同じ受付IDを使い、通知と表の記録を照らし合わせます。
1. 通知前の回答表
- 受付ID
SAMPLE-001- 種別
- 資料請求
- 通知済み
- 空欄
3. 処理後の回答表
- 受付ID
SAMPLE-001- 通知済み
- 済
通知の記録です。問い合わせの対応完了とは別です。
「受付ID」と「通知済み」は、この例のために用意する列です。ここでは架空のIDをあらかじめ記入しています。GoogleフォームがこのIDを自動で付けるわけではありません。自動採番する場合は、追加の設定・処理と、その利用量を別に確かめます。
図は公式機能を基にした設計例です。この組み合わせでの実接続は未検証です。使う処理は、新しい行の確認（Watch New Rows）、メッセージの送信（Send a Message）、行の更新（Update a Row）。機能の根拠を見る
設定より先に決めること
試す前に、接続の許可と確認担当を決めましょう
- GoogleとSlackを接続してよいか接続時に求められるアクセス権限を、管理者や情報の責任者と確かめます。Slackでは、管理者によるアプリの承認が必要な場合があります。
- どの情報を、誰が見られる場所へ通知するか通知する項目と、通知先の閲覧者を決めます。氏名や問い合わせ全文まで送る必要があるかも考えましょう。
- 止まった通知や、記録の食い違いを誰が調べるかSlackには届いていても、表への記録だけが失敗する場合があります。担当者が通知と表を照合し、再実行による二重通知を防ぐ方法を決めます。
設定時に詳しく確認すること
架空の問い合わせで、送る範囲を確かめる
テスト用の表と通知先を用意します。初回に過去の問い合わせまで送らないよう、どの行から処理を始めるかを指定する設定（Choose where to start）を確かめます。「All」を選ぶと既存の行も処理されます。
新しい行を確認する処理は、表に空の行があると、それより後の行を処理しません。テストでは列名・空の行・通知する問い合わせの行を確かめます。行の更新には行番号を指定するため、通知した元の行に記録できるかを照合します。
実行の記録と、途中で止まった処理を見る
Makeの管理画面の実行履歴（History）で、実行状態や各処理の出力を調べられます。途中で止まった処理を残す設定（Store incomplete executions）は、初期状態では無効です。必要に応じて有効にし、未完了の処理（Incomplete executions）を確認する方法を決めます。
再実行する前に、Slackと表を照合する
通知済みの欄が空でも、Slackには送信済みかもしれません。同じ問い合わせを二度通知しないよう、受付IDと実行履歴を照合します。再実行する範囲を確かめ、問題が続くときに定期実行を止めて手作業に戻せる担当者を置きます。
各設定の根拠は下の公式情報にまとめています。エラーが必ず自動で直ることを示すものではありません。
方法を選ぶための確認
あなたの作業には、どの方法が合いそうですか？
分かる範囲で答えると、次に確認することを整理できます。導入や有料契約を決めるものではありません。
回答はこのページ内だけで使い、送信・保存しません。ページを読み直すと未選択に戻ります。このページではアクセス解析を使いません。
Makeを候補にした方へ
Makeを検討するなら、次は無料枠と料金を確認しましょう
通知までどのくらい待てるか、月に何件あるか、どの処理を任せるかによって、必要な条件は変わります。次のページで、無料プランで試す場合の条件と、有料プランを確認するタイミングを整理できます。
Makeの無料枠と料金条件を見る確認欄に答えていなくても読めます。この先は料金と利用条件の説明で、設定手順の実演ではありません。読むだけで登録や購入が必要になることはありません。
参考にした公式情報と、この説明の範囲
公式情報の確認日：。次回確認：2026年9月24日。以下は通常の公式リンクです。紹介報酬が発生するリンクではありません。
- Google：フォームの回答の保存先／新しい回答のメール通知
- Make：Google SheetsとSlackの処理一覧／新しい行の確認と行の更新
- Make：新しい行の確認・初回の開始位置／定期実行の間隔
- 接続と許可：Googleの接続／Slackの接続／Slack公式のアプリ承認
- Make：実行履歴／途中で止まった処理の保存と確認／最新の料金・利用条件
業務の流れと架空のデータは説明用です。実アカウントでの接続動作、削減時間、導入成果は未検証です。この読者像が実際の需要に合っているかも、まだ調査していません。
運営：SaaS TCO Lab（omishu）。紹介リンクを通じた有料利用などにより、運営者が報酬を受け取る場合があります。運営者情報／広告方針／お問い合わせ／プライバシー