kintoneとLINE連携の設計方法｜LINE公式・LINE WORKS・通知入力を分ける

kintoneとLINEを連携したいという相談では、実際には複数の要望が混ざっています。

顧客からLINE公式アカウントで問い合わせを受けたい。

予約や申込の進捗を顧客へLINEで知らせたい。

現場スタッフがLINE WORKSのトークから日報や写真を登録したい。

kintoneで対応期限が近づいたら、LINE WORKSへ通知したい。

チャットボットで入力を案内し、kintoneへ登録したい。

ただし、このまま「kintoneとLINEをつなぐ」と考えると、設計が粗くなります。

• 顧客向けのLINE公式アカウントと、社内向けのLINE WORKSが混ざる
• 顧客の個人情報を社内チャットへそのまま流す
• kintoneの更新を誰に通知すべきか決めないまま全員に送る
• LINE上では返答済みなのに、kintoneのステータスが未対応のまま残る
• チャットボットが受けた入力の本人確認や権限があいまいになる
• 配信停止、同意、誤送信時の取り消し方を決めていない
• 連携に失敗しても、どのレコードが未送信か追えない
• LINEやLINE WORKS側の会話だけが残り、kintoneに対応履歴が残らない

LINEは、顧客にも社員にも身近な入口です。

一方で、身近だからこそ、業務データの置き場所にしてはいけない場面があります。

問い合わせ本文、顧客属性、担当者、対応期限、対応履歴、送信ログ、同意状態は、kintone側に残します。

LINE公式アカウントやLINE WORKSは、入力しやすく、気づきやすくするための接点です。

kintoneとLINE連携で最初に決めるべきなのは、LINEへ何を送るかではなく、LINE公式アカウント、LINE WORKS、kintoneの役割分担です。

この記事では、kintoneとLINE連携を、ツール選びではなく業務設計として整理します。

kintoneフォーム連携の設計方法はこちら
kintone通知の設計方法はこちら
kintone Webhookの設計方法はこちら
kintone問い合わせ管理の設計方法はこちら

LINE公式とLINE WORKSを混同しない

kintoneとLINE連携では、まずLINE公式アカウントとLINE WORKSを分けます。

名前は近いですが、業務上の役割は違います。

区分	主な相手	向いている用途	kintone側で持つべきもの
LINE公式アカウント	顧客、会員、応募者、取引先担当者	問い合わせ受付、個別返信、予約案内、進捗連絡、セグメント配信	顧客台帳、問い合わせ台帳、同意状態、配信ログ
LINE WORKS	社員、現場スタッフ、管理者	日報登録、写真報告、社内通知、承認依頼、対応依頼	社員マスタ、現場報告、作業依頼、対応状態
kintone	管理者、担当者、連携処理	業務データの正本、状態管理、履歴、検索、一覧、集計	アプリ、権限、ステータス、通知条件、監査ログ

LINE公式アカウントは、顧客との接点です。

LINE DevelopersのMessaging API概要では、ユーザーがLINE公式アカウントへ送ったメッセージをWebhookイベントとしてボットサーバーへ渡し、サーバーがLINEプラットフォームを通じて応答する流れが説明されています。

つまり、LINE公式アカウントをkintoneとつなぐ場合は、外部の顧客から来たイベントを、どのkintoneアプリに、どの顧客として、どの権限で登録するかを決める必要があります。

LINE WORKSは、社内の入力・通知の接点です。

LINE WORKS公式ブログでは、kintone連携の用途を、LINE WORKSのトーク画面からkintoneへ登録する「入力」と、kintoneの登録・更新をLINE WORKSへ知らせる「通知」として整理しています。

LINE WORKS公式ブログ：kintone連携

サイボウズの連携サービス掲載ページでも、LINE WORKSからkintoneアプリのレコード登録や更新を行い、kintoneの登録・更新をきっかけにLINE WORKSへ通知できることが紹介されています。

サイボウズ：LINE WORKS連携サービス

この違いを曖昧にすると、顧客向けメッセージと社内通知が同じ設計図に乗ってしまいます。

顧客への返信は外部送信です。

社内への通知は内部連絡です。

現場からの報告は社員入力です。

それぞれ、必要な同意、権限、ログ、表現、失敗時の扱いが違います。

顧客接点として使うケース

LINE公式アカウントをkintoneと連携する場合、最初に「顧客から何を受け取り、顧客へ何を返すか」を決めます。

代表的な用途は次の通りです。

用途	LINE公式アカウントの役割	kintoneの役割
問い合わせ受付	顧客がメッセージを送る	問い合わせレコードを作る
予約・申込	顧客が必要項目を送る	申込情報、希望日時、受付状態を管理する
進捗連絡	顧客へ状態を知らせる	対応ステータス、送信可否、送信ログを持つ
セグメント配信	対象者へ案内を送る	顧客属性、同意、配信対象を管理する
個別返信	担当者やボットが返す	対応履歴、担当者、未対応一覧を持つ

ここで重要なのは、LINE公式アカウントのトークルームを業務台帳にしないことです。

顧客とのやり取りはLINE上に見えますが、問い合わせ番号、担当者、期限、ステータス、対応履歴はkintoneに残します。

顧客が「前回の件です」と送ってきたときに、kintone側で顧客と過去問い合わせを引けなければ、対応品質が安定しません。

逆に、kintoneに問い合わせレコードがあり、LINEは受付と返信の接点であれば、担当変更や引き継ぎがしやすくなります。

kintone顧客管理の設計方法はこちら

顧客接点として設計する場合は、次の項目を事前に決めます。

設計項目	決めること
顧客の識別	LINEのユーザーIDとkintone顧客レコードをどう紐づけるか
初回受付	未登録顧客からのメッセージを仮受付にするか、登録フォームへ誘導するか
返信担当	ボット、自動返信、有人対応の切り替え条件
送信可否	同意、配信停止、対象外条件をどこで持つか
個人情報	LINEへ返してよい情報、返してはいけない情報
送信履歴	誰に、いつ、何を、どのレコードから送ったか
失敗時	未送信一覧、再送、管理者通知の扱い

LINE公式アカウントは便利ですが、顧客へ直接届きます。

社内通知の感覚で「全員に送る」「条件に当たったら送る」と作ると、誤配信の被害が大きくなります。

配信対象をkintoneで抽出する場合は、抽出条件だけでなく、最終確認、承認、送信ログまで含めて設計します。

LINE公式アカウント連携では、kintoneの条件に合う人へ送るだけでなく、送ってよい相手か、送ってよい内容か、送った事実を追えるかを設計します。

現場入力として使うケース

LINE WORKSをkintoneと連携する場合、社内メンバーが使う入力口として考えます。

たとえば、次のような業務です。

• 現場の日報
• 写真付きの作業報告
• 点検結果の登録
• 訪問完了の報告
• クレーム一次報告
• 在庫や資材の不足報告
• 承認依頼のコメント入力

LINE WORKSのトークから入力できると、PCを開かずに報告しやすくなります。

ただし、ここでもkintone側のアプリ設計が先です。

LINE WORKSから入ってきた内容を、どのアプリのどのフィールドへ入れるか。

社員をどのマスタで識別するか。

写真や添付ファイルをどこに残すか。

入力途中のものを下書き扱いにするか。

上長確認が必要な場合、ステータスをどう進めるか。

これらを決めずにチャット入力だけ作ると、現場は入力できても管理者が使いにくいデータになります。

LINE WORKSを入口にする場合は、入力フォームを小さく分けるのが現実的です。

入力単位	向いている内容	注意点
1メッセージ入力	完了報告、異常なし報告、簡単なコメント	後から検索しやすい選択値を持たせる
シナリオ入力	日報、点検、申請、問い合わせ一次受付	必須項目、戻る操作、途中離脱を設計する
写真付き入力	施工写真、破損報告、現地確認	写真の保存先、ファイル名、紐づけを決める
選択式入力	状態変更、承認、差し戻し	選択肢とkintoneステータスを対応させる
URL誘導	長い入力、添付が多い申請	kintoneフォームや外部フォームと組み合わせる

現場入力では、文章を自由入力にしすぎると後工程が困ります。

「対応済み」「要確認」「部材不足」「再訪問必要」のような分類は、ボタンや選択肢で入るようにします。

自由記述は補足に留めます。

そのほうが、kintoneの一覧、絞り込み、グラフ、通知条件に使いやすくなります。

kintone API連携の設計方法はこちら

通知先として使うケース

kintoneの更新をLINEやLINE WORKSへ通知するときは、通知先を分けます。

通知先	通知する内容	通知しないほうがよい内容
LINE公式アカウント	顧客本人に関係する受付完了、予約確定、進捗連絡	社内メモ、他顧客情報、担当者向け指示
LINE WORKS個人トーク	担当者への作業依頼、承認依頼、期限警告	全員が見るべき共有事項
LINE WORKSグループ	チーム全体で見る受付、障害、緊急対応	個人情報を含む詳細本文
kintone通知	担当者の標準通知、状態変更、コメント	外部送信を伴う案内

通知は増やすほど見落とされます。

特にLINE WORKSでは、全員が見るグループに細かい更新を流すと、重要な通知が埋もれます。

通知条件は、kintoneの一覧設計と合わせます。

たとえば、次のように分けます。

• 新規問い合わせは担当チームへ通知する
• 担当者が決まったら本人へ通知する
• 期限超過は管理者へ通知する
• 顧客への連絡が必要なものは送信待ち一覧に出す
• 失敗した外部送信は連携管理者へ通知する

大事なのは、通知を受けた人が次に何をするかです。

LINE WORKSに通知を出しても、対応完了をkintoneに戻さなければ、業務状態は更新されません。

通知本文には、対象レコード、対応期限、必要な操作、kintoneへのリンクを含めます。

顧客向けのLINE公式アカウント通知では、kintoneの内部URLや社内用語を出さないようにします。

LINE WORKSは社内の気づき、LINE公式アカウントは顧客への連絡、kintoneは対応状態と履歴の正本として分けます。

チャットボット・プラグイン・APIの使い分け

kintoneとLINEをつなぐ方法は、ひとつではありません。

用途に応じて、チャットボット、連携プラグイン、Webhook、API連携を使い分けます。

方法	向いているケース	注意点
連携プラグイン	LINE WORKS通知、簡単な入力、決まったパターンの連携	対応範囲、ログ、権限、添付ファイルの扱いを確認する
チャットボット	対話形式の入力、現場報告、よくある質問、一次受付	本人確認、入力途中、差し戻し、例外対応を決める
Messaging API	LINE公式アカウントの個別応答、Webhook受付、顧客向け通知	チャネル、アクセストークン、Webhook署名、送信ログを管理する
kintone Webhook	kintoneのレコード操作を外部処理へ伝える	受信側で重複、失敗、再実行、監視を設計する
個別API連携	顧客ID連携、複雑な権限、複数アプリ更新、監査が必要	開発、保守、障害対応、権限設計が必要

LINE DevelopersのMessaging API概要では、Webhook、応答メッセージ、任意タイミングの送信、画像やファイルなどのコンテンツ取得、プロフィール取得などが説明されています。

これらを使うと、LINE公式アカウントを顧客接点として作り込めます。

ただし、できることが多いほど、業務設計も必要です。

顧客が送った画像を取得するなら、画像をどこへ保存し、誰が見られるかを決めます。

プロフィール情報を扱うなら、kintoneの顧客レコードとの対応関係を決めます。

任意タイミングでメッセージを送るなら、送信対象と同意状態を確認します。

LINE WORKS側は、社内の入力と通知に寄せると設計しやすくなります。

たとえば、現場報告はLINE WORKSのボットで受け、kintoneの現場報告アプリへ登録します。

登録後、管理者にはLINE WORKSで通知し、詳細確認や差し戻しはkintoneで行います。

このように入口と正本を分けると、チャット上の会話に業務が埋もれません。

kintone外部連携の設計方法はこちら

個人情報・権限・誤配信の注意点

kintoneとLINE連携で最も危険なのは、外部送信の扱いを社内通知と同じ感覚で作ることです。

LINE公式アカウントへの送信は、顧客へ届きます。

LINE WORKSへの通知は、社内メンバーへ届きます。

この違いを境界として設計します。

リスク	起きる原因	設計で決めること
顧客への誤配信	抽出条件、顧客紐づけ、テンプレート選択の誤り	送信対象一覧、承認、テスト送信、送信ログ
個人情報の露出	社内グループへ詳細本文を流す	通知本文を要約し、詳細はkintone権限内で見せる
退職者・異動者への通知	LINE WORKSユーザーと社員マスタがずれる	社員マスタ、在籍状態、通知先同期
権限を超えた入力	ボットが誰の入力か識別できない	ユーザーIDと社員・顧客の紐づけ
送信失敗の放置	失敗ログや再送手順がない	未送信一覧、再送、管理者通知
二重送信	リトライや手動再送の制御がない	送信ID、冪等性キー、再送可否
同意違反	配信停止や同意状態を見ていない	同意アプリ、配信停止フラグ、対象外条件

通知本文には、情報を入れすぎないほうが安全です。

たとえば、LINE WORKSのグループ通知には次の程度に留めます。

• レコード番号
• 種別
• 重要度
• 対応期限
• 担当者
• kintoneへのリンク

顧客名、住所、電話番号、詳細な相談内容、添付ファイルの中身は、通知に直接書かず、kintoneの権限内で確認させます。

顧客向けLINEでは、テンプレートを使う場合でも、差し込み項目の扱いを慎重に決めます。

「{顧客名}様」「{予約日時}」「{受付番号}」のような差し込みは便利ですが、顧客紐づけが間違うとそのまま誤配信になります。

送信前の確認画面、承認ステータス、テスト送信、送信ログを設けます。

kintone側の正本アプリ設計

LINE連携の品質は、kintone側のアプリ設計で決まります。

LINE側で何ができるかより、kintoneにどのデータを正本として持つかが先です。

代表的なアプリ構成は次の通りです。

アプリ	主な役割	主なフィールド
顧客マスタ	LINE公式アカウントのユーザーと顧客を紐づける	顧客名、LINEユーザーID、同意状態、配信停止
問い合わせ管理	顧客からのメッセージや有人対応を管理する	受付番号、本文、担当者、ステータス、期限
現場報告	LINE WORKSからの報告を受ける	報告者、現場、種別、写真、確認状態
通知管理	誰に何を通知するかを制御する	通知種別、対象条件、通知先、本文テンプレート
送信ログ	外部送信と社内通知の結果を残す	送信先、送信内容、結果、エラー、再送状態
同意管理	顧客への送信可否を管理する	同意日、同意種別、停止日、取得経路
連携エラー管理	失敗した連携を追う	対象レコード、失敗理由、再実行担当、対応状態

LINE公式アカウント、LINE WORKS、チャットボット、APIは、このアプリ群に対する入口と出口です。

業務データは、kintoneで検索でき、一覧で追え、権限で守れ、履歴が残る状態にします。

通知や返信は、kintoneの状態を起点にします。

たとえば、顧客への返信を作る場合、問い合わせ管理アプリのステータスを「返信承認済み」にしたら送信対象にする。

送信後は送信ログを作り、問い合わせ管理の最終返信日時を更新する。

失敗したら連携エラー管理に残し、管理者へLINE WORKSで知らせる。

このように、連携処理をkintoneの状態遷移に合わせると、後から追えます。

kintoneステータス管理の設計方法はこちら

よくある失敗

kintoneとLINE連携では、次の失敗が起きがちです。

LINE公式アカウントとLINE WORKSを同じ図にしてしまう

顧客と社員は、同じLINE系ツールでも別の相手です。

顧客向けの配信と社内向け通知を同じ条件で作ると、権限と文面が崩れます。

設計図では、顧客接点、社内入力、kintone正本を分けます。

通知先だけ先に決める

「この更新をLINE WORKSに出したい」から始めると、通知が増えます。

先に、誰が、何を見て、何を完了させるのかを決めます。

通知はその導線です。

LINE上の返信で完了扱いにする

顧客へLINEで返信しても、kintoneの問い合わせステータスが変わらなければ、未対応一覧に残ります。

逆に、LINE上では会話が終わっているのにkintoneに履歴がなければ、引き継げません。

完了条件はkintone側に置きます。

顧客の同意を別管理にする

配信同意、配信停止、対象外条件をスプレッドシートや担当者メモで管理すると、送信時に事故が起きやすくなります。

顧客マスタか同意管理アプリで、送信可否を機械的に判定できる形にします。

送信ログを残さない

LINE公式アカウントへの送信、LINE WORKSへの通知、ボット入力の登録は、成功・失敗を残します。

送信ログがないと、顧客から「届いていない」と言われたときに確認できません。

再送も判断できません。

添付ファイルをチャットだけに置く

現場写真や顧客からの画像をLINEやLINE WORKSの会話だけに残すと、後から案件単位で探しにくくなります。

kintoneのレコードに紐づけるか、保存先URLを持たせます。

個人アカウントの設定に依存する

プラグインやAPI連携では、誰の権限で接続しているかが重要です。

退職、異動、権限変更で止まらないように、連携用ユーザー、管理者、更新手順を決めます。

実装前チェックリスト

kintoneとLINE連携を始める前に、次の項目を確認します。

確認項目	判断すること
連携相手	LINE公式アカウントか、LINE WORKSか、両方か
利用目的	顧客受付、顧客配信、社内入力、社内通知のどれか
正本アプリ	顧客、問い合わせ、現場報告、送信ログをどのアプリで持つか
本人識別	LINEユーザーID、LINE WORKSユーザー、社員・顧客マスタの紐づけ
権限	誰がどのレコードを見られるか、通知本文に何を出すか
同意管理	顧客への送信可否、停止、対象外条件
通知条件	どの状態、どの期限、どの担当者へ出すか
失敗時	未送信一覧、再送、管理者通知、手動対応
ログ	送信内容、送信先、結果、エラー、再実行履歴
運用責任	プラグイン設定、APIキー、アクセストークン、接続情報の管理者

このチェックリストを埋めると、必要な連携方法が見えてきます。

顧客向けの個別応答が中心なら、LINE公式アカウントとMessaging APIを検討します。

社内の現場報告が中心なら、LINE WORKSのチャットボットや連携サービスを検討します。

通知だけなら、プラグインやWebhookで足りることもあります。

ただし、顧客情報、送信ログ、同意、再実行が必要な場合は、個別API連携や管理アプリの追加を前提にしたほうが安全です。

Bitlightに相談できること

Bitlightでは、kintoneとLINE連携を、単なる接続設定ではなく、業務データの正本設計から整理します。

相談できる内容は次の通りです。

• LINE公式アカウントとLINE WORKSの使い分け整理
• 顧客向けLINE配信の同意管理、送信ログ、誤配信防止設計
• LINE WORKSからの現場入力、日報、写真報告のアプリ設計
• kintoneの顧客管理、問い合わせ管理、現場報告、通知管理アプリの設計
• チャットボット、プラグイン、Webhook、API連携の選定
• 個人情報をLINE WORKS通知へ出しすぎない通知本文設計
• 連携エラー、再送、管理者通知、運用引き継ぎの設計

「LINEで通知したい」という要望は入口としては自然です。

ただし、業務で使い続けるには、誰が入力し、誰が確認し、どのアプリが正本になり、どこまで外部へ送るかを先に決める必要があります。

kintoneとLINE連携は、LINEを業務台帳にするのではなく、kintoneの正本データへ顧客・現場・担当者をつなぐ入口として設計します。

LINE公式アカウントとLINE WORKSを分けて設計できれば、顧客対応と社内運用を混ぜずに済みます。

kintoneには、対応状態、履歴、同意、ログを残します。

LINEには、入力しやすさと気づきやすさを任せます。

この分担ができると、LINE連携は単発の通知設定ではなく、現場と顧客をkintoneへつなぐ実務の仕組みになります。