LINEとkintoneを連携する｜予約・顧客情報

LINEで受けた予約や申込を、誰かが手で別の台帳に写している——この状態が残っているかぎり、友だちが増えるほど社内の作業が増えます。 LINEは受け口であって、保管場所ではありません。 受けた内容の正本は業務側（kintone・予約システム・顧客管理）に置き、LINEには「その人が誰か」を示す印だけを残すのが、壊れにくい形です。 この章は、つなぐ向きを項目ごとに決め、つなぎ方を4段階から選び、どこまで自動にするかを件数と手間で判断し、失敗に気づける状態にするための章です。

この章で分かること

• つなぐ前に決める2つ（正本はどちらか／向きは項目ごとにどうか）と、LINEの中に残してよい情報の範囲
• つなぎ方の4段階（手作業 → CSV → ノーコード連携 → API）と、どこまで自動にするかを件数×手間×間違いやすさで決める方法
• LINE側から渡す値と、その性質（識別子はアカウント単位でしか通用しない／解除は業務側に伝わらない）、担当者への通知の決め方、失敗したときに気づく仕組み（点検リストの必須項目）

まず「正本はどちらか」を決める

つなぐ話は、機能から始めると必ず失敗します。最初に決めるのは1つだけです。同じ情報を、2か所で編集していないか。

LINE側（Lステップ・エルメの友だち情報）にも氏名と電話番号があり、kintoneにも氏名と電話番号がある。どちらでも直せる。この状態になった瞬間、どちらが正しいか誰にも分からなくなります。 電話番号が違う2つのレコードを前にして、担当者は毎回「どっちだろう」と止まります。

だから、項目ごとに正本（マスター）を1つに決めます。決め方の原則は2つです。

• 業務の判断に使う情報は、業務側が正本（予約日時・金額・ステータス・氏名・連絡先）
• 配信の出し分けに使う情報は、LINE側が正本（状態タグ・入口タグ・興味タグ）

この分け方にすると、LINE側で持つのは3章で決めた3区分のタグと、必要最小限の友だち情報だけになります。氏名や電話番号をLINE側に持つなら、「何に使うか」を1行書いてください。 書けないなら、持たないのが正解です。配信の宛名に使うだけなら、LINEの表示名で足ります。

つなぐ向きは、項目ごとに決める

「kintoneと連携する」という言い方は、実務では役に立ちません。項目ごとに向きが違うからです。1枚の表にします。

情報	向き	起きること
申込・予約の内容（希望日時・要望）	LINE → 業務	フォームの送信で業務側にレコードができる
氏名・連絡先	LINE → 業務（初回のみ）	以降は業務側が正本。LINE側では更新しない
友だちの識別子	LINE → 業務	業務側のレコードに「どの友だちか」を持たせる
予約の確定・変更・キャンセル	業務 → LINE	担当者が業務側で確定したら、本人に通知が飛ぶ
ステータス（来店済み・契約済み）	業務 → LINE	状態タグが付け替わり、配信の内容が変わる
空き状況・在庫	業務 → LINE（表示のみ）	LIFFで見せる（9章）。LINE側には保存しない

この表を作ると、ほとんどの項目が片方向だと分かります。双方向にしたくなるのは氏名・連絡先ですが、ここを双方向にすると前節の「どっちが正しいか分からない」が起きます。初回だけ流して、以降は業務側だけで直す。 これで足ります。

点検リストの1番と2番が必須項目なのは、後から直すとデータを突き合わせ直す作業になるからです。項目が10個なら、表を書くのに15分もかかりません。

LINEの中に残す情報を最小にする

もう1つ、最初に決めることがあります。LINE側に個人情報をどこまで置くかです。

LINE側に置く	業務側に置く
友だちの識別子（ユーザーID）	氏名・電話番号・メールアドレス・住所
状態タグ・入口タグ・興味タグ	申込内容・予約日時・金額・履歴
配信に使う最小限の情報（呼び名など）	本人確認に使う情報

識別子と、氏名・連絡先を分けて持つのが基本の形です（点検リスト4番）。2つが揃って初めて個人が特定される持ち方にしておくと、万一どちらかが漏れたときの被害が小さくなります。ツールの管理画面は多くの人が見られる状態になりがちなので、「見る必要のない人が、見られる場所に置かない」という一点だけでも判断は変わります。

つなぎ方には段階がある。上から順に検討する

手作業 → CSV → ノーコード連携 → API の4段階です。上から順に検討して、足りないときだけ下に降りてください。 いきなりAPIから考えると、要らない開発をします。

1段階目（手作業）は「負け」ではありません。 月に3件の申込を自動で入れるために開発すると、費用の回収に何年もかかります。8章の点検リスト9番が「手作業の場合は、月の件数と所要時間を数えてある」になっているのは、手作業を禁じているのではなく、数えないまま続けることを禁じているからです。

段ごとの向き不向き、APIトークンとWebhookの使い分け（この2つは向きが逆です）、閉域網で使えるかどうかの判断、止まったときに要る再送の仕組みは、kintoneの教科書13章 JavaScriptカスタマイズとAPI連携にまとめてあります。実装の話を2冊に書きません。 つなぎ先がkintone以外でも、決めることは同じです。

LINE側から見て、1つだけ足しておく注意があります。ノーコードの連携サービスを入れると、払う先と壊れる場所がもう1つ増えます。 LINE側のツール・連携サービス・業務側の3つが別会社になり、どれが落ちても症状は同じ「申込が入っていない」です。 提供元の料金と仕様は提供元のページで確認し、「落ちたときに誰が気づくか」を入れる前に決めてください（後述）。

どこまで自動にするかは、3つの掛け算で決める

判断を感覚に任せると、たいてい2通りに割れます。「全部自動にしましょう」と「うちは件数が少ないので手でやります」。どちらも根拠がありません。次の3つを掛けて考えてください。

見るもの	何を数えるか
件数	月に何件か
手間	1件あたり何分かかるか（探す・開く・写す・確認する、の合計）
間違いの起きやすさ	写し間違いが起きるとどうなるか。気づけるか

前の2つは掛け算で「月に何分を使っているか」になります。まずこれを1か月だけ実測してください。 記憶で答えると、ほぼ確実に少なく見積もられます。

3つ目が、実は一番大きく効きます。写し間違いが「予約日時」で起きると、当日お客様が来て席が無いという事故になります。一方、「アンケートの自由記述」を写し間違えても、誰も困りません。同じ転記でも、重さが違います。

当社が判断の出発点にしている決めごとは次のとおりです。出典のある統計ではなく、当社の決めごとです。自社で3か月記録を取ったら、自社の数字に置き換えてください。

状況	当社の判断	理由
月の転記時間が合計30分未満	手作業のまま	自動化しても回収できない。その時間は配信の設計に使うほうが効く
月の転記時間が合計2時間以上	自動化を検討する	年24時間。設定や開発の費用が見合い始める
間違えると人が動く情報（日時・金額・住所）	件数に関係なく自動化を検討する	事故の1件は、転記10時間より高く付く
内容が毎回違い、人の判断が要る	自動にしない	自動化しても結局確認が入る。二度手間になる

そして、どこから人の確認が入るかを必ず1行で書いてください（点検リスト5番）。「フォームの送信でkintoneに下書きレコードができる。担当者が内容を確認して『受付済み』にした時点で確定」——この形が、実務では最も安全です。全自動にするのは、確認しなくても成立すると確かめてからです。

kintoneに入れる場合の形

当社は業務システム側も同じ担当が作るので、つなぎ先がkintoneのケースを例に、決めることを書きます。他の顧客管理システムでも、決める項目は同じです。

1レコードが何かを先に決める

「1レコード＝1申込」なのか、「1レコード＝1人」なのか。 ここを決めずに作ると、同じ人が2回予約したときに破綻します。

形	1レコード	向いている業務
申込台帳	1件の予約・申込	予約、イベント、注文。同じ人が何度も来る
顧客台帳	1人の顧客	会員管理、継続契約。申込は別アプリにして紐づける

多くの場合、「顧客アプリ」と「申込アプリ」の2つに分け、申込から顧客を参照する形になります。この設計の詳細は、当社のkintoneの教科書 5章（アプリ設計の基本）と6章（複数アプリのつなぎ方）にあります。LINE側の設計より先に、こちらを決めてください。 受け皿の形が決まっていないところに、自動で流し込むことはできません。

LINE側から渡す値と、その性質

受け皿に足すフィールドは3つです。3つとも、後から足すとそれ以前のレコードは空のままになります。 タグと同じで、遡れません。

フィールド	用途	入れ忘れたときに失うもの
友だちの識別子	どの友だちからの申込かを結びつける。重複判定の鍵にもなる	業務側からLINEへ返せない（確定通知が送れない）
申込の経路	LINE経由かどうかを分けて数える（11章）	出口の件数を、LINE以外の経路と分けて数えられない
受付のステータス	下書き／確認済み／確定。人の確認が入る位置を表す	未確認の申込と確定した申込が、同じ一覧に混ざる

そのうえで、LINE側から渡ってくる値には、業務側で扱う前に知っておくべき性質があります。 ここを知らずに受け皿を設計すると、あとから作り直しになります。

渡ってくる値	性質	設計への影響
友だちの識別子	その公式アカウントの中でしか通用しない。 アカウントを作り直すと、全員ぶん変わる	アカウントの統廃合は、連携の作り直しになる。安易にアカウントを分けない（2章）
表示名	本人が自由に変えられる。本名とは限らず、絵文字も入る	本人確認には使えない。氏名は申込フォームで別に取る
プロフィール画像・ステータスメッセージ	変わる。保存しても古くなる	業務側に保存しない
ブロック・友だち解除	業務側には何も伝わらない。 解除されても申込レコードは残る	「通知が届かない人」が静かに増える
申込フォームの入力値	入力した本人の申告。表記が揺れる	形式を検査する。突き合わせの鍵には使わない

4行目が、LINE連携で最も見落とされます。 業務側で「確定」にして通知を送ったつもりでも、相手が友だち解除していれば届きません。届かなかったことは、業務側の画面には出ません。 予約の確定・変更・キャンセルのような間違えると人が動く連絡は、LINEだけに頼らず、電話番号かメールをもう1つ持っておくのが実務的な形です。

重複を止める

二重登録は、送信ボタンの二度押しと、同じ人が別の入口から申し込むの2つで起きます。LINE側で決めることは1つだけです。重複判定の鍵を、友だちの識別子にする。 氏名や電話番号を鍵にすると、表記の揺れで同じ人が別人になります。

受け皿側の作り（顧客アプリでは識別子を重複禁止の鍵にし、申込アプリでは禁止せず既存レコードを参照する形にする／電話番号・メールアドレスの形式を検査する）は、kintoneの教科書7章 入力を守るにあります。点検リスト7番はここです。起きてから直すと、必ず「どちらが本物か」の調査になります。

担当者への通知を決める

つないだ後に、最も多い苦情が「気づかなかった」です。通知は3つを決めるだけで足ります。

決めること	例
誰に	担当者個人ではなく、2人以上に届く形（担当が休んだ日に止まらないように）
どこに	業務側の通知、メール、チャットツール。普段から見ている場所を1つ
何を	「誰が・何を・いつ」の3つ。詳細は開けば分かるので、通知には入れない

通知先を増やしすぎないでください。 3か所に飛ばすと、全員が「他の誰かが見ている」と思います。1か所にして、届く人を2人以上にする。 そして通知が多すぎると見なくなります。 1日に何十件も来るなら、通知は「人の対応が要るもの」だけに絞り、残りは朝に一覧で確認する形にしてください。

失敗したときに気づける状態にする（この章の必須項目）

つないだ仕組みは、必ずいつか止まります。 仕様が変わった、トークンの有効期限が切れた、つなぎ先が一時的に落ちた、送られてきた値が想定と違った。どれも普通に起きます。

問題は、止まったことが静かに起きることです。フォームの送信は成功していて、画面には完了と出ていて、しかし業務側にレコードが入っていない。気づくのは、お客様から「予約したのに連絡が来ない」と電話が来たときです。

だから、点検リストの6番は必須項目です。決めることは2つ。

1. 失敗したらエラーが担当者に通知される（上の通知と同じ場所でよい）
2. 通知が実際に届くことを、テストで確認した

2つ目が大事です。エラー通知は、エラーが起きないと試せません。 だから、わざと失敗させて確かめます。つなぎ先の設定を一時的に誤った値にする、必須項目を空で送ってみる、といった形です。「設定したはず」は、確認したことになりません。

もう1つ、月に1回の突き合わせを入れてください。LINE側のフォーム送信数と、業務側に入ったレコード数が一致しているか。 1分で終わります。ここがずれていたら、静かに落ちていた期間があります。

失敗の記録と再送の仕組みは、受け取る側で作るものです。 つなぎ先がkintoneの場合、Webhookは送りっぱなしで、受け側が落ちていた通知はそのまま消えます（kintoneの教科書13章）。見積もりにここが入っているかを、発注前に確認してください。

出せるか、消せるかを、つなぐ前に確認する

点検リストの9番と10番です。どちらも、つないだ後で気づくと手遅れになります。

出せるか——LINE側のツールと業務側の両方から、友だち情報・タグ・申込内容を書き出せる手段と形式を確認します。そして友だちの識別子が、両方の書き出しに含まれるか。ここが抜けると、書き出せても突き合わせられません（詳しくは12章）。

消せるか——決めるのは3つだけです。何を・どこに・いつまで。 そして削除の手順と担当。本人から削除を求められたときにどこを消せば全部消えるか（LINE側・業務側・連携サービスに残るログ）を書きます。3つ目が最も忘れられます。提供元の仕様を確認してください。

なお、取り扱いの是非そのものは当社が判断できるものではありません。LINEヤフーの規約と、使うツール各社の規約を確認してください。 判断が分かれるところは、提供元に問い合わせてください。

つながないほうがよい場合

9章と同じく、先に潰します。 次のどれかに当たるなら、この章の作業はまだ早いです。

#	当てはまる状況	代わりにすること
1	出口がまだ1つに決まっていない	2章に戻る。何を流すのかが決まっていない状態でつながない
2	業務側に受け皿（アプリ・台帳）が無い／担当者の頭の中にしかない	先に業務側を作る。 流し込む先が無ければ、つなぎようがない
3	月の転記時間を数えていない	1か月だけ実測する。30分未満なら、手作業のままでよい
4	つなぎ先に外から出入りする口が無い	CSVで足りないか検討する。口が無いシステムには、つなげない
5	業務側の運用が、まだ毎週変わっている	固まるまで待つ。変わるたびに連携も直すことになる
6	止まったときに直せる人が、社内にも外注先にも決まっていない	決まるまで作らない。 静かに止まり、誰も気づかない
7	個人情報の保存場所・保存期間・削除の手順を決められない	決まるまで作らない（9章と同じ）

2番が、実務では最も多く当たります。LINEの改善のつもりで相談を受けて、結局いちばん効いたのが業務側の台帳を作り直すことだったというのは、珍しくありません。9章の点検リスト3番（つなぐ先）で止まった人の多くは、ここにいます。

費用の考え方

当社は、LINE側と業務システム側を同じ担当が見ます（/services/line／/services/liff）。初回相談と現状の診断は無料、導線設計・構築と運用・改善はお見積りです。LINE公式アカウントやLステップ・エルメの月額料金は御社のご契約で、当社の見積もりには含みません。連携サービスを使う場合の費用も、提供元との契約です。

見積もりを比べるときは、9章の3つ（失敗したときの動き／自社で直せる範囲／サーバー費用の負担）に、エラーの通知を足した4つが入っているかを見てください。4つ目が入っていない見積もりは安く見えます。そして、入っていなかったことに気づくのは、静かに止まった後です。

よくある誤解を3つ

「連携すれば、手作業がゼロになる」 ——なりません。減るのは写す作業だけで、確認する作業は残ります。むしろ、自動で入ってくるようになると「入ってきた内容を見る」という新しい作業が生まれます。だから点検リストの5番で、人の確認が入る位置を先に決めます。ゼロを目指すのではなく、判断が要らないところだけを自動にするのが正しい目標です。

「まずLINE側を作って、業務側は後からつなげばいい」 ——逆です。受け皿を先に作ってください。 LINE側のフォームは、業務側の項目が決まっていれば30分で直せます。業務側の台帳は、データが入り始めてからだと直せません。9章の「画面は減らしてよく、つなぐ先は減らさない」と同じ話で、後から直しにくいほうを先に決めるという原則です。

「件数が少ないから、連携は要らない」 ——件数だけで決めないでください。間違えると人が動く情報（日時・金額・住所）は、月に5件でも自動化を検討する価値があります。逆に、月に100件でも内容が毎回違って人の判断が要るなら、自動化しても二度手間になります。判断の軸は、件数ではなく「掛け算の3つ目」です。

この章の出口

この章を終えたとき、手元に残っているべきものは次の3つです。

1. 項目ごとの向きの表が1枚（LINE→業務／業務→LINE が、全項目に書いてある。正本の列も埋まっている）
2. 点検リスト10項目のうち、必須の1・2・6がすべて○（全体で8以上）
3. 月の転記時間の実測値（1か月だけ数えた数字。30分未満なら、手作業のままでよいという結論も含む）

ここまでで、受ける・返す・残すの3つがつながりました。 残っているのは、それが効いているかを見る仕組みです。 次の章で、数える対象を決めます。友だち数は、成果ではありません。

次の章へ：11章 LINEの効果測定｜登録数を成果と呼ばない