Makeでフォーム回答をスプレッドシートとLINEにつなぐ手順と詰まる場所

この記事で作るもの:フォーム回答→スプレッドシート→LINE通知

この記事どおりに進めると、Googleフォームに回答が入るたびに、スプレッドシートへ1行追加され、同時にLINEへ通知が届く仕組みを、今日中にMakeで動かせます。

流れは次のとおりです。Googleフォームへの回答が送信される、Makeがそのシートの新しい行を検知する、Google Sheetsに行を追加する、LINE Messaging APIへHTTPリクエストを送ってpush通知を出す、という4段階です。

始める前に、次の3つのアカウントを用意してください。

1. Googleアカウント(フォームとスプレッドシートを作成できるもの)
2. Makeのアカウント(無料プランで開始可能)
3. LINE Developersのアカウント(LINEアプリと同じアカウントで作成できます)

この3つが揃っていれば、今日中に最初の通知を受け取れるところまで到達できます。

Makeでシナリオを組む手順

結論として、トリガーをGoogle SheetsのWatch Rowsにし、Router経由でAdd a RowとHTTPモジュールに分けると、どちらかが失敗してももう一方は止まらない構成になります。

手順は次のとおりです。

1. Makeにログインし、新しいシナリオを作成します。
2. 検索窓に「Google Sheets」と入力し、トリガーとして「Watch Rows」を選びます。Googleフォームの回答は、デフォルトで「フォームの回答 1」という名前のシートに自動で溜まるため、フォーム自体を直接トリガーにするより、この連携シートをWatch Rowsで見る方が設定が単純です。
3. 接続の作成で、Googleアカウントのログイン画面が出ます。ここで「このアプリは確認されていません」という警告画面が出ることがあります。これは個人アカウントや組織の制限設定が原因で、画面下の「詳細」をクリックし、「安全ではないページに移動」を選ばないと先に進めません。会社やGoogle Workspaceのアカウントを使っている場合は、管理者がアプリの利用を許可していないとこの画面すら出ず、接続自体が失敗します。その場合は個人のGoogleアカウントで一度試すと切り分けができます。
4. 対象のスプレッドシートとシート名を選択します。フォームを作り直した直後は、スプレッドシートがまだ連携されておらず、一覧に出てこないことがあります。その場合はフォームの「回答」タブから「スプレッドシートにリンク」を先に実行してください。
5. Watch Rowsの実行間隔(スケジュール)を確認します。無料プランではポーリング間隔が短くても15分程度に設定されることがあり、フォーム送信直後に通知が来なくても故障ではありません。この間隔はシナリオの時計アイコンから変更できます。
6. Routerモジュールを追加します。ここから2方向に分岐させ、一方をGoogle Sheetsの「Add a Row」、もう一方をHTTPモジュールにつなぎます。分岐を作らず直列につなぐと、スプレッドシートへの書き込みが失敗したときにLINE通知も止まってしまうため、Routerで独立させておきます。
7. Add a Rowモジュールで、書き込み先のスプレッドシートとシートを選び、列のマッピングを行います。ここで一番つまずくのが、フォームに質問を後から追加・並び替えした場合です。Make側のマッピングは追加した時点の列構成を覚えているため、フォームの質問順を変えると、回答内容が別の列にずれて書き込まれます。質問を変更したら、Add a Rowのマッピング画面を開き直し、列の対応を目視で確認してください。
8. 各列に、Watch Rowsが出力した項目(例:名前、メールアドレス、問い合わせ内容)をドラッグして割り当てます。空欄のまま保存すると、その列だけ空白行として書き込まれるため、必須項目はマッピング後に一度テスト実行して値が入るか確認します。

LINE側の準備とHTTPモジュールの中身

結論として、LINE Developersでチャネルを作り、チャネルアクセストークンと送り先のuserIdの2つを用意すれば、HTTPモジュールはテンプレートどおりのJSONで動きます。

1. LINE Developersにログインし、新規プロバイダーを作成します。
2. そのプロバイダーの下に「Messaging API」のチャネルを新規作成します。チャネル名やカテゴリの入力を求められますが、個人の検証用途であれば仮の名称で問題ありません。
3. 作成したチャネルの「Messaging API設定」タブを開き、「チャネルアクセストークン(長期)」を発行します。この値はHTTPモジュールのAuthorizationヘッダーに使うため、発行後にコピーして控えておきます。再表示できますが、流出すると第三者がpush送信できてしまうため扱いに注意します。
4. 同じチャネルのQRコードを使って、自分のLINEアカウントでそのチャネル(公式アカウント)を友だち追加します。push送信するには、相手が友だち登録済みである必要があります。
5. 送り先のuserIdを取得します。最も簡単な方法は、Messaging API設定の「Webhook URL」にMakeのWebhookモジュールを一時的に差し込み、自分のアカウントから何かメッセージを送って、受信したJSONの中のevents[0].source.userIdを確認する方法です。これを1回確認できれば、以後はこの文字列を固定値として使い回せます。
6. Makeのシナリオに戻り、HTTPモジュール(「Make a request」)を追加します。URLはhttps://api.line.me/v2/bot/message/push、メソッドはPOSTです。
7. ヘッダーに、AuthorizationとContent-Typeの2つを設定します。
8. 本文(Body type)はRaw、Content typeはJSON (application/json)を選び、下のサンプルのような構造を入力します。

HTTPモジュールのヘッダー設定は次のとおりです。

Authorization: Bearer チャネルアクセストークンの値
Content-Type: application/json

本文は次のようなJSONです。{{1.回答者名}}の部分は、Watch Rowsモジュールの出力項目をMakeの画面上でドラッグして差し込みます。

{
  "to": "送り先のuserIdの値",
  "messages": [
    {
      "type": "text",
      "text": "新しい回答が届きました。氏名: {{1.回答者名}} 内容: {{1.問い合わせ内容}}"
    }
  ]
}

ここでよく止まるのは、JSONの閉じ括弧の数が合わない場合と、textの中に改行やダブルクォートがそのまま入ってエラーになる場合です。Watch Rowsの回答に長文や記号が含まれるフォームでは、テスト送信して400エラーが返ってこないかを必ず一度確認してください。LINE連携の具体的な転記例はMakeを使ったLINE受信メッセージのスプレッドシート転記の自動化でも紹介されています。

無料枠と料金の考え方

結論として、Makeは「モジュールが1回実行されるごとに1オペレーション」という数え方をしており、LINEは「push送信した通数」で無料枠が決まるため、どちらも処理件数が増えるほど消費が積み上がる構造だと理解しておくと、料金が上がるタイミングを予測しやすくなります。

どちらも無料枠の数値自体はプランや時期によって変わるため、この記事では数字を固定で書きません。確認すべきなのは数値そのものより「どこを見れば残量が分かるか」です。Makeならシナリオ一覧の実行履歴から1回あたりの消費オペレーション数が見えますし、LINEなら公式アカウントマネージャーの管理画面で当月の送信数が確認できます。フォームの回答が月に数件程度なら無料枠を超えることはまずありませんが、回答が増えてくると、Router分岐を増やすたびにオペレーション消費も比例して増える点は覚えておく価値があります。

コードに移す目安

結論として、分岐・件数・再試行制御・費用のいずれかが一定のラインを超えたら、Makeを続けるよりGASかPythonに移した方が管理しやすくなります。

Googleサービス同士(フォーム・スプレッドシート・Gmailなど)で完結する処理ならGAS、外部APIとの連携や複雑なデータ加工が絡む処理ならPythonに寄せる、という切り分けが実務では扱いやすいです。Makeの基本的な画面構成やアプリ連携の全体像はMake(旧Integromat)の使い方と自動化ガイドにも整理されています。

自分の運用での位置づけ

私自身は、ノーコードを検証段階の道具として位置づけ、継続して回す処理はPythonとタスクスケジューラに移しています。

このサイトはCloudflare Pagesで公開しており、定時処理はWindowsのタスクスケジューラとPythonで動かし、データの保存先はSupabase、通知はLINEを使っています。公開や送信の最終判断は、どの工程でも人が行っています。

具体的には、案件収集・応募文の下書き・記事の下書き・計測といった定時タスクを、Webの収集、AIによる分類と下書き、LINEのwebhook、Cloudflare Worker、Supabaseを組み合わせて構成し、ローカルPCのタスクスケジューラで定期実行しています。公開や送信の操作自体は自動化せず、下書きができた段階で通知を受け取り、内容を確認してから自分で実行しています。

私自身はMakeを本番の処理には使っていません。フォームの回答のような単発のトリガー処理は、この記事の手順のとおりMakeで今日中に動かせますが、複数のデータソースを突き合わせて判断を挟む処理は、分岐の見通しが悪くなる前にPythonで組んでいます。新しい連携を試すときの動作確認にノーコードを使い、継続運用が決まったものはコード側に置く、という分担です。

関連記事

GASでの自動化を外注するかどうかの判断基準をまとめた記事では、どこまで自分で組んでどこから依頼すべきかを具体的に書いています。あわせて、GASが向く作業と向かない作業を切り分けた記事もあります。LINEとSupabaseをn8nで連携させた実装の記事では、Make以外のノーコードツールでの構成例も紹介しています。次に試すなら、まずは今日組んだシナリオのWatch Rowsの実行間隔を確認し、フォーム送信から通知までの実際の遅延を測ってみてください。