LINEで予約を受けて、リマインドを自動で送り、顧客のやりとりを一元管理する。そういう仕組みを、オープンソースを土台に4社ぶん構築・運用してきました。
この記事は、その過程で実際に詰まった箇所の記録です。結論を先に言うと、最大の教訓は「管理画面の表示を信用してはいけない」でした。設定したはずなのに動かない、という状況の大半がここに起因します。
手順書ではありません。やってみて初めて分かる落とし穴を書きます。導入を検討されている方が、何を覚悟すべきかの判断材料になればと思います。
何を作っているのか
LINE公式アカウントを、予約システムと顧客管理システムに変えるものです。利用者から見える機能はこうです。
- リッチメニューから予約画面を開いて、日時を選んで送信する
- 予約の前日にリマインドが自動で届く
- 過去の予約履歴を自分で確認できる
- アンケートに回答する
店舗側は管理画面から、予約状況の確認、個別チャット、スタッフごとのGoogleカレンダー連携などを行います。
構成はこうです。
| 要素 | 役割 |
|---|---|
| Cloudflare Workers | 本体。LINEからのWebhookを受け、予約処理を行う |
| D1 | データベース。予約・顧客・メッセージ履歴を保持 |
| R2 | 画像などのファイル保管 |
| LINE Messaging API | メッセージの送受信、リッチメニュー |
| LIFF | LINE内で開くWebアプリ。予約画面はこれ |
| Google Calendar API | スタッフのカレンダーと双方向連携(任意) |
サーバーを持たない構成なので、店舗ごとの月額固定費はほぼかかりません。ここが既存の予約システムと大きく違う点です。
土台にしているオープンソースについて
この仕組みは「LINE Harness」というオープンソースを採用しています。開発したのは野田修一さん(GitHub: Shudesu)で、当社が作ったものではありません。
当社の立場は、このOSSをサロン・整骨院・スクールなどの業種に合わせて最適化し、構築・運用するサービス提供者です。ソフトウェアそのものの著作権は原作者にあります。
この記事も「読者のみなさんもご自身で構築できます」という趣旨のものではありません。当社がどう構築・運用しているかの記録としてお読みください。
詰まりどころ その1:管理画面の表示を信用してはいけない
これが最大の落とし穴です。
LINE Developersの管理画面で「Webhookの利用」をONにしても、実際には有効になっていないことがあります。画面上のトグルは確かにONを示しているのに、メッセージを送っても何も起きません。
確認する方法は1つです。APIで実際の状態を問い合わせる。
curl -s https://api.line.me/v2/bot/channel/webhook/endpoint \
-H "Authorization: Bearer $TOKEN"
# 期待する応答
# {"endpoint":"https://<worker>/webhook","active":true}
"active":true になっていなければ、画面がどう見えていようと有効ではありません。対処はトグルをOFFにしてからもう一度ONにすること。これで実状態が追いつきます。
この確認を知らないと、「設定は合っているはずなのに動かない」という状態で延々と別の場所を疑うことになります。設定作業のあとは、必ずAPIで実状態を読み戻す。これは他の作業にも通じる原則です。
詰まりどころ その2:署名検証はデータベース側の値を見ている
LINEからのWebhookは、チャネルシークレットで署名検証されます。ここで「LINE側の設定を直したのに動かない」という事象が起きます。
原因は、検証に使われるのがデータベースに保存されたシークレットだからです。LINE Developersでチャネルシークレットを再発行しても、それだけでは反映されません。データベース側の値も更新する必要があります。
LINE側の画面を何度見直しても正しいので、原因にたどり着くまで時間がかかります。シークレットを変更したら、保存されている側も必ず一緒に更新する。
詰まりどころ その3:動いているのはソースコードではない
これは実際に誤診しました。
あるクライアントの環境で挙動がおかしく、ソースコードを読んで原因を探しました。しかし実際に動いているのは、ソースではなくビルド済みのバンドルでした。読んでいたコードと、稼働しているコードが別物だったのです。
OSSのソースやクライアントごとのクローンを見て挙動を判断すると、存在しない原因を延々と探すことになります。デプロイされている実体がどれなのかを、最初に確認する必要があります。
当たり前のようでいて、複数の環境を並行して扱っていると必ず一度はやります。
詰まりどころ その4:設定ファイルが環境変数を上書きする
Cloudflareの操作には wrangler というコマンドを使います。対象アカウントは環境変数で指定するのですが、設定ファイル(toml)にアカウントIDが書かれていると、そちらが優先されます。
つまり環境変数で「A社のアカウント」を指定したつもりが、実際にはB社に向かっているということが起こり得ます。複数クライアントを扱う立場では、これは事故に直結します。
対策は2つです。
- 設定ファイルが置かれていないディレクトリからコマンドを実行する
- どの設定ファイルを使うかを明示的に指定する
人は間違える前提で、間違えようがない手順に変える。複数環境を扱うときの原則だと思っています。
詰まりどころ その5:シークレットの「名前」と「値」を取り違える
Cloudflareのダッシュボードでシークレットを登録する画面には、「名前」欄と「値」欄があります。ここを逆に入れる事故が起きます。
逆に入れると、秘密の値が「名前」として画面に表示され続けます。一覧画面にも出るので、その時点で秘匿性が失われます。気づいたら値を再発行するしかありません。
当社ではシークレットの値そのものは扱わず、お客様に設定していただく運用にしています。そのぶん、依頼の文面で「名前欄にはシークレット名、値欄には秘密の値」と明示することが欠かせません。
詰まりどころ その6:R2が有効化されていないと止まる
画像の保管にCloudflare R2を使いますが、アカウントでR2が有効になっていないと、構築の途中でエラーで停止します。
エラーコードは 10042。原因が分かれば対処は簡単ですが、アカウントの所有者にダッシュボードで有効化してもらう必要があるため、そこで作業が中断します。
クライアント名義のアカウントで構築する場合、この待ち時間が発生します。着手前に確認しておくべき項目です。
詰まりどころ その7:移行は新規構築より難しい
既存環境を別のアカウントへ引っ越す場面があります。これが一番危険です。
| 落とし穴 | 何が起きるか |
|---|---|
| 旧環境を消し切らない | 新旧の両方が定期実行を続け、お客様にリマインドが二重に届きます。実害が出る事故です |
| 画像の回収が後回し | 旧環境を削除したあとでは、保管されていた画像を取り出せません。回収は削除の前に |
| データベースの取り込み | 外部キー制約でエラーになります。制約を一時的に外し、テーブル定義を先に並べ替える必要があります |
順序を間違えると取り返しがつかないものが含まれます。移行は手順書どおりに、順番を守って進める。創意工夫を入れる場面ではありません。
正直に書いておくこと:難易度は低くありません
ここまで読んで、お気づきかと思います。
この構築で扱うのは、Cloudflare Workers・D1・R2・LINE Messaging API・LIFF・OAuthです。いずれも設定を1つ間違えると動かず、しかも「なぜ動かないか」が画面に出ません。
さらに、LINEチャネルはMessaging APIとLINEログインの2種類が必要で、それぞれ別に作成します。LIFFのエンドポイントURLも、予約・履歴・アンケートで別々に設定します。
プログラミングの知識がない方が、記事を見ながら自力で構築するのは現実的ではありません。できると書いてある記事があれば、それは実際にやっていない方が書いたものだと思います。
一方で、一度型ができれば横展開は速いのも事実です。当社は同じ手順書に沿って、複数のクライアントに展開してきました。落とし穴が分かっているぶん、初回より確実に速く進みます。
これまでの構築実績
現在、以下のクライアント様で構築・運用しています。
- IDPA(一般社団法人・講座予約)
- 癒の原カラダ研究所(整体・パーソナル)
- 癒の原整骨院(整骨院)
- W KITCHEN LAB.(料理教室・イベント)
業種が違えば、必要な機能も運用の形も変わります。予約枠の持ち方、リマインドの文面、スタッフごとのカレンダー連携の要否。同じ土台でも、設計はクライアントごとに作り込んでいます。
構築代行・運用のご相談
LINE公式アカウントを予約システムにしたい、既存の予約システムの月額を見直したい、というご相談を承っています。
- 新規構築 … LINEチャネルの準備から、予約画面・リマインド・管理画面の設定まで一式
- 既存環境の移行 … 別アカウントへの引っ越し、旧システムからの乗り換え
- 運用サポート … 設定変更、トラブル対応、機能追加のご相談
この記事に書いたとおり、構築には複数のサービスを横断する作業が必要です。ご自身で進めて詰まってしまった、という状態からのご相談も対応しています。
料金は業種と必要な機能によって変わりますので、まずは現状をお聞かせください。相談・お見積りは無料です。しつこい営業はいたしません。
要点
- 管理画面の表示を信用しない。設定したあとは必ずAPIで実状態を読み戻す。「設定は合っているのに動かない」の大半はこれ
- 動いている実体を最初に確認する。ソースコードと稼働コードが別物のことがある。存在しない原因を探さないために
- 移行は順序が命。旧環境を消し切らないとリマインドが二重に届く。画像の回収は削除の前に。順番を守る
本記事は2026年8月時点の実作業にもとづく記録です。各サービスの仕様や管理画面は変更される場合があります。