専用のLINE日報Botを作る途中で、Webhook検証が302 Foundとなり、月次集計は参照エラーと月の型違いで止まりました。既存Botへ混ぜず、テンプレート・GAS・スプレッドシートを分離し、検証画面だけを追わず実送信へ切り替えました。
2か月分4件の送信でシート反映と月次切替を確認しています。継続稼働とテストデータの扱いは、次の判断として残しています。
既存Botへ混ぜず専用のLINE連携へ分けた
既存のBotとスプレッドシートを共用すると、異なる報告項目の解析、列、集計式、分析用データが一つに混ざります。便利さより、誤りが出た時の影響範囲を小さくする方を選びました。
LINE Bot、GAS、スプレッドシートを別にし、既存運用へ直接影響しない構成にしました。
テンプレート・列設計・GASを一組でそろえた
LINEで送る日報テンプレート、GASが読む項目、スプレッドシートの見出し、月次集計式は一組です。どれか一つだけ変えると、ずれた列へ値が入ります。
- 日報テンプレート：送信する項目と順番を固定
- 列設計：日付、区分、活動時間、結果数値、イベント、メモを整理
- GAS：Webhookを受け、本文から項目を取り出して1行追加
- Bot：｢日報｣の送信に対し入力テンプレートを返す
管理に必要な内部列は残しましたが、公開記事にはユーザー識別子や返信用情報を含めていません。
Webhook 302は実送信と分けて確認した
LINE Developersの検証では302 Foundが表示されました。公開URLの末尾やGASのアクセス権を確認しましたが、検証画面だけを追い続けると作業が止まります。
そこで実際のLINEからテスト日報を送り、日付、区分、各数値、イベント、メモがスプレッドシートへ入るかを確認しました。検証表示と実利用の結果を分けた判断です。
参照エラーと月の型違いを別々に直した
- 古い入力規則が配列式の展開先に残り、参照エラーになった
- 入力規則を削除し、式が使う範囲を必要行数へ限定した
- 対象月は見た目が同じでも内部では日付型で、日報側の文字列と一致しなかった
- 式の中で年月文字列へ変換してから比較した
新しい式を足す前に既存設定の残りを確認し、表示ではなく内部データ型をそろえました。
4件の実送信で月次切替を確かめた
確認できた範囲
- テストデータ：2か月分・4件
- 実送信：シートへの項目反映を確認
- 月次集計：対象月の切り替えを確認
- 継続稼働：要店長確認
対象月を切り替えると、それぞれの月のデータだけが集計されました。実際の売上値や組織名は出さず、4件で仕組みを確認した事実だけを残します。
日報原本は記録として保持し、分析には月次やイベント別に整理した集計を使う方針です。本番開始時には4件の確認データを残すか削除するかを決め、集計の初期状態を記録します。
本番前に判断が残ること
- Webhook検証の302と実送信成功を別々に記録する
- 継続稼働時の権限とWebhook設定を再確認する
- 4件のテストデータを残すか削除するか決める
- 入力形式が崩れた時の確認方法を運用へ残す