予約が入ったら、LINEで自動で知らせるようにした話
シートにデータは貯まっていた。でも、新しい行に誰かが気づくのは、誰かが開いたときだけだった。あるクライアントの依頼で、シートの変化をGASに見張らせて、LINEに通知を飛ばす仕組みをつくった。確認しに行く、という作業がなくなった話だ。
シートに貯まるようになった。でも、見に行くのは人間だった
「シートへの入力は増えていった。でも、新しい行に誰かが気づくのは、誰かが確認しに行ったときだけだった。」
その会社では、予約をGoogleフォームで受けていた。フォームの回答はスプレッドシートに自動で貯まる。それ自体はうまく動いていた。
問題は、その先だった。
新しい予約への気づきが遅れる。担当者が外出中で、スマホでシートを開くのが1時間後になった。「今日、予約入ってる？」と朝に確認するのが習慣になった。その確認のために、毎朝シートを開くことが「仕事の一つ」になっていた。
前日リマインドのLINEが手動発生する。予約日の前日になると、担当者が顧客のLINEに手書きでメッセージを送る。「明日〇時にお待ちしています」という一文だ。予約数が増えると、この作業が積み上がる。送り忘れも出てくる。
確認する労働が残っていた、という言い方が正確だ。データの蓄積は解決していた。でも「変化に気づくこと」と「知らせること」は、まだ人間の手の中にあった。
データが増えることと、変化に気づけることは、別の話だった。
予約が入った瞬間、LINEに来るようにした
仕組みをつくった後、何が変わったか。結果から話す。
予約が入った瞬間、担当者のスマホにLINEの通知が届く。シートを開いていなくても、外出中でも、知ることができる。フォームに回答が入った、その瞬間に来る。
前日になったら顧客のLINEにリマインダーが自動で飛ぶ。毎朝手動で送っていた「明日〇時にお待ちしています」というメッセージが、時間になったら自動で顧客に届く。担当者は何もしていない。
「予約が入ったとき、スマホにLINEの通知が来た。シートを開いていなかった。それでも、知ることができた。」
確認しに行かなくていい。向こうから来る。
この反転が、使い始めた最初の週に起きた。「今日、予約入ってる？」と確認する習慣がなくなった。来たら知れる、という状態になると、確認という行動が必要なくなる。
「複雑そう」という印象があるかもしれない。仕組みの骨格だけ言えば、GASがシートの変化を見張っていて、条件に合ったときだけLINEに送る、という役割分担だけの話だ。技術の複雑さより、「誰が何を見張って、誰に何を送るか」を決めることの方に時間がかかる。
仕組みはこう動いている——GASのトリガーとMessaging APIのプッシュ送信
コードの話はしない。「誰が、何に反応して、何をするか」という役割の説明だけで完結させる。
動きは3ステップだ。
まず、シートが変化する。フォームから予約が入った（フォーム送信トリガー）、誰かが手動でシートを編集した（onEdit）、あるいは時間が来た（時間駆動トリガー）。このいずれかが起きると、GASが検知する。
次に、GASが条件を確認する。「フォームに回答が入ったか」「予約日が翌日かどうか」「特定の列に値が入ったか」——条件に合致したときだけ、次の動作に進む。合致しなければ、何もしない。これが無駄打ちを防ぐ役割だ。
最後に、Messaging APIのプッシュ送信（LINEの公式アカウントからユーザーへ能動的にメッセージを送る機能）でLINEに届く。担当者のLINEにも、顧客のLINEにも、送り先はGAS側で制御できる。
番人が変化を検知して、伝令がLINEに届ける——構造としてはそれだけだ。
トリガーを3種類挙げたのには理由がある。フォーム送信のタイミングで通知したいときと、「前日になったら」という時間条件でリマインドしたいときでは、使うトリガーが違う。用途に合わせて選ぶ、という設計になっている。設定の手間はある。骨格はシンプルだが、「細かい条件の設定でつまる」というのが正直なところだ。
同じ仕組みで、担当者にも・顧客にも・条件を変えて通知できる
一度つくった仕組みは、用途ごとに条件とトリガーを変えるだけで使い回せる。
今回のクライアントでは、2種類の通知を走らせた。
担当者向け通知：フォームに予約が入った瞬間、担当者のLINEへ。「〇月〇日〇時、予約が入りました」という内容で届く。確認しに行かなくていい状態が、ここで生まれた。
顧客向けリマインダー：予約日の前日、時間駆動トリガーが動いて、顧客のLINEへ自動でリマインダーを送る。担当者が手動で送っていた一文が、条件が満たされた瞬間に自動で届く。
別の案件では、フォームの回答が来たタイミングで顧客に「受け付けました」の自動返信を送るケースもあった。あるクライアントでは、シートの特定セルが「完了」に変わったとき、担当者に通知が来る設計にした。
通知の送り先（担当者 or 顧客）と、トリガーの種類（変化 or 時間 or フォーム）を組み合わせることで、かなりのパターンに対応できる。「LINE通知の仕組みをつくった」というより、「シートの変化を人間の代わりに見張らせる」という設計思想の話だ。
確認しに行くという作業が、条件を設定した時点で不要になる。確認する代わりに、来たら知れる状態になる。
構築が終わって最初の週、クライアントのスタッフから連絡があった。「予約が入ってもシートを見に行っていない」という一言だった。
確認しに行く習慣がなくなった、ということだ。それが起きるとは思っていなかった、とも言っていた。
確認しに行かなくていい。向こうから来る。
この反転は、ツールを入れた日に起きるわけではない。条件通りに通知が来た瞬間、「あ、見に行かなくてよかった」という感覚として来る。技術の話よりそっちの変化の方が、使う側の1日が変わるという意味で大きかった。
確認する仕事が、一つなくなった。それだけで、1日のリズムが静かに変わる。
「シートを確認しに行かなくていい。向こうから来る。」
LINEに来た問い合わせを、まずシートに貯めることから始めたい方へ。
