kintoneとLINEの連携。できることと組み方

公開 書いた人 大林 諒

kintoneとLINEをつなぐ相談は、たいてい「LINEで来た問い合わせが担当者のスマホに散らばっていて、顧客の記録とつながらない」という困りごとから始まります。kintoneにはLINEとつなぐ標準の機能が無く、間に何かを挟んで組むことになります。この記事では、Messaging APIの仕組み、3つの組み方の選び方、ユーザーIDと顧客のひもづけ、問い合わせの記録とkintoneからの送信、料金、個人情報の扱いまで通して書きます。kintoneで顧客管理アプリを作ったことがあり、アプリの設定画面を一通り触ったことがある人を前提にしています。

この記事の内容
  1. できることを3つに分ける
  2. LINE公式アカウントとMessaging APIの基本
  3. 先に決めること
  4. 設計表
  5. LINEのユーザーIDとkintoneの顧客をひもづける
  6. 友だち追加から問い合わせ記録までの流れ
  7. kintoneから個別に送る流れ
  8. 連携サービスやiPaaSを選ぶときに見ること
  9. 個人情報の扱いと同意
  10. できないことと、その代わり
  11. よく詰まるところ
  12. 次にやること

できることを3つに分ける

「LINE連携」と一言でいっても、やりたいことによって作るものがまるで違います。最初に、どれをやりたいのかを分けます。

LINEで受けた問い合わせをkintoneに記録する

お客様がLINE公式アカウントに送ったメッセージを、kintoneのレコードとして残す形です。誰から、いつ、何が来たかがkintoneに残り、顧客のレコードから過去のやり取りをたどれるようになります。友だち追加やブロックもイベントとして受け取れるので、「いつ友だちになったか」「ブロックされていないか」も顧客の記録に持てます。

kintoneからLINEで送る

kintoneのレコードを起点に、特定のお客様にLINEでメッセージを送る形です。予約の確認、書類の受け取り完了、支払いの案内のように、レコードの状態が変わったときに1人ずつ送る使い方が中心になります。全員に同じ内容を一斉に送る配信は、LINE公式アカウントの管理画面のほうが向いています。

LINE WORKSとの違い

LINE WORKSは「ビジネス版LINE」と案内されている別のサービスで、トーク、メール、掲示板を1つのアプリで使う業務用のチャットです。

LINE WORKSにも、外部のLINEユーザーとトークする機能があります。ただし、管理者が外部ユーザーとのトークを「許可」にし（初期値は「許可しない」で、登録から168時間は「許可」に変えられません）、LINEユーザーの側からLINE WORKSのメンバーを友だち追加してもらう形です。お客様から見ると、会社の公式アカウントではなく、担当者個人とつながることになります。

この記事で扱うのは、会社のLINE公式アカウントとkintoneをつなぐ話です。担当者を問わず会社として受け付け、記録を顧客ごとに残したいなら、LINE公式アカウントとMessaging APIで組みます。

LINE公式アカウントとMessaging APIの基本

kintoneとつなぐのは、LINE公式アカウントの管理画面ではなく、Messaging APIという仕組みです。用語が多いので、先に整理します。

用語何かどこで扱うか
LINE公式アカウント会社がお客様と友だちになるアカウントLINE Official Account Manager
Messaging APIチャネル公式アカウントを外部のプログラムとつなぐ窓口LINE Developersコンソール
プロバイダーチャネルをまとめる単位。会社やサービスごとに作るLINE Developersコンソール
チャネルシークレット届いたWebhookが本物か確かめる鍵チャネルの基本設定タブ
チャネルアクセストークンメッセージを送るときに使う鍵「Messaging API設定」タブ
Webhook友だち追加やメッセージをLINEが外へ知らせる仕組み「Messaging API設定」タブ
ユーザーID友だち1人ずつに付く U から始まる33文字の識別子Webhookで届く

Messaging APIを有効にする

  1. LINE公式アカウントを作成します。
  2. LINE Official Account Managerで、Messaging APIの利用を有効にします。
  3. プロバイダーを選びます。
  4. LINE Developersコンソールにログインし、選んだプロバイダーの中にチャネルができていることを確かめます。

Messaging APIを有効にすると、そのアカウント用のチャネルが作られます。LINE Developersコンソールから直接チャネルを作る方法は、2024年9月4日以降は使えません。

プロバイダーは一度選ぶと、あとから変えることも、連携を外すこともできません。ここは慎重に決めます。ユーザーIDはプロバイダーごとに発行されるので、同じ会社で複数の公式アカウントを持つ場合、同じプロバイダーにそろえておけば、同じお客様は同じユーザーIDで届きます。別のプロバイダーに分けると、同じ人でもIDが違い、突き合わせられません。

【画面：LINE Developersコンソールのプロバイダーの中に、Messaging APIチャネルが作られた状態】

応答メッセージとプッシュメッセージ

LINEからお客様へ送る方法は大きく2つあります。

  • 応答メッセージ：Webhookで届いた応答トークン（replyToken）を使って返信します。応答トークンは1回しか使えず、Webhookを受け取ってから1分以内に使う必要があります。
  • プッシュメッセージ：ユーザーIDを指定して、好きなタイミングで送ります。

応答メッセージは通数に数えられませんが、プッシュメッセージは数えられます。人がkintoneを見て1分以内に返すことはまずできないので、kintoneから送るメッセージは実質すべてプッシュメッセージになります。

届いた画像はいずれ消える

お客様が送った画像、動画、音声、ファイルは、Messaging APIで取得できます。ただし、送信から一定期間で自動的に削除され、保存期間は保証されていません。kintoneに残したいなら、受け取った時点で取得してkintoneの添付ファイルに入れる処理が要ります。あとからまとめて取りに行く設計にすると、取れないものが出ます。

先に決めること

ここを曖昧にしたまま作り始めると、ひもづけやアプリの分け方をあとで作り直すことになります。

構成をどれにするか

LINEとkintoneの間に何を挟むかで、3つに分かれます。

構成中身向いている会社気をつける点
連携サービスLINEとkintoneをつなぐ市販のサービスやプラグインを使う作る人がいない。早く始めたい月額費用。kintoneに残る項目の形を自分で決めにくい
iPaaSZapier、Make、n8nのような連携ツールで、Webhookを受けてkintoneに書く連携ツールをすでに使っている署名検証や画像の保存まで組めるかはツール次第
自前の中継自分でWebhookを受けるプログラムを置き、kintone REST APIで書く項目の形や名寄せを細かく決めたい作る人と保守する人が要る

どの構成でも、LINEから見れば「Webhookを受け取り、Messaging APIで送る何か」が1つ要るという点は同じです。Webhook URLはチャネルごとに設定するもので、欄は1つしかありません。連携サービスと自前の中継を両方つなごうとすると、どちらか一方にしか届かないので、つなぐ先は1つに決めます。

kintoneのWebhook、APIトークン、プラグイン、JavaScriptによるカスタマイズは、どれもライトコースでは使えません。LINEと連携するならスタンダードコース以上が前提です。

kintoneに何を持つか

メッセージの本文を1件ずつkintoneのレコードにするか、kintoneには顧客とのひもづけと最新の状態だけを持つかを決めます。

問い合わせが月に数百件までなら、本文をレコードにする形で十分に回り、担当者はkintoneの中だけで履歴を読めます。一方で、スタンダードコースのAPIリクエスト数は1アプリにつき1日1万回で、画面を開くたびに新着を取りに行くような作りにすると、この上限に近づきます。トーク画面のように頻繁に読み書きするものは中継の側に持ち、kintoneには「LINEユーザーID」「最終受信日時」「未対応」だけを置く形も、実際に回っています。

この記事では、本文をレコードにする形で組みます。

1つのLINEに何件の顧客がつくか

ここが一番作り直しになりやすい点です。子どもの習い事なら、LINEの友だちは保護者で、受講している子どもが2人いれば顧客のレコードは2件です。

最初から「1つのLINEユーザーに複数の顧客がつく」前提で、LINEの友だちを別アプリにします。顧客アプリにユーザーIDの欄を1つ置くだけの作りにすると、兄弟や複数の取引先が出てきた時点で破綻します。

誰が、どこで返事をするか

返事をkintoneから送るのか、LINE公式アカウントの管理画面のチャットで返すのかを決めます。両方でできるようにすると、管理画面のチャットで返した分はkintoneに残りません。kintoneに記録を寄せたいなら、返事はkintoneからに一本化します。

設計表

アプリは3つ作ります。顧客アプリはすでにある前提で、LINEの友だち、受信、送信を分けます。

LINE友だち

フィールド名種類設定
LINEユーザーID文字列（1行）必須。「値の重複を禁止する」をオン。中継が書き込む
表示名文字列（1行）友だち追加時の表示名。照合の手がかりで、キーには使わない
状態ドロップダウン友だち／ブロック中
友だち追加日時日時中継が書き込む
ブロック日時日時中継が書き込む
最終受信日時日時中継が書き込む。一覧の並び替えに使う
受付番号文字列（1行）ひもづけ用。後の節で使う
ひもづけ済み顧客テーブル中に顧客番号と顧客名を置く
受信履歴関連レコード一覧LINE受信をLINEユーザーIDで表示

ユーザーIDは33文字なので、「値の重複を禁止する」をオンにしたときの64文字の制限には収まります。

LINE受信

フィールド名種類設定
受信日時日時中継が書き込む
LINEユーザーID文字列（1行）中継が書き込む
種類ドロップダウンテキスト／画像／ファイル／友だち追加／ブロック／その他
本文文字列（複数行）テキストのときだけ
添付添付ファイル画像やファイルのとき
イベントID文字列（1行）webhookEventId を入れる。「値の重複を禁止する」をオン
対応状況ドロップダウン未対応／対応中／対応済み。初期値は未対応
担当者ユーザー選択割り振った人

イベントIDの重複を禁止しておくと、LINEから同じWebhookが2回届いたときに、2件目の登録が失敗して二重記録を防げます。

LINE送信

フィールド名種類設定
送信先ルックアップ関連付けるアプリはLINE友だち、コピー元はLINEユーザーID
表示名文字列（1行）ルックアップの「ほかのフィールドのコピー」で入る
本文文字列（複数行）必須
送信状態ドロップダウン下書き／送信待ち／送信済み／失敗。初期値は下書き
送信日時日時中継が書き込む
エラー内容文字列（複数行）失敗したとき中継が書き込む
送信者作成者自動で入る

LINEのユーザーIDとkintoneの顧客をひもづける

Webhookで届くのはユーザーIDと表示名くらいで、氏名や電話番号は届きません。表示名はお客様がいつでも変えられ、ニックネームのことも多いので、表示名で顧客を特定してはいけません。ひもづけの方法は4つあります。

方法仕組み確実さ手間
受付番号を送ってもらう顧客ごとの番号入りのURLを渡し、トークに番号を送ってもらう高い小さい
フォームに入力してもらうLINEログインを使った入力画面で、会員番号などを入れてもらう高い作る量が多い
アカウント連携自社サービスのログイン画面とLINEをつなぐ仕組みを使う高い自社のログイン画面が要る
担当者が手で照合する表示名や友だち追加の時期から候補を出し、人が確定する人次第件数に比例

受付番号を送ってもらう方法

小さく始めるならこれが一番です。LINEには、公式アカウントのトーク画面を開いて入力欄に文字を入れた状態にするURLがあります。

https://line.me/R/oaMessage/{LINE IDをパーセントエンコードしたもの}/?{入力済みにする文字}

LINE IDの @ は %40 にし、入力済みにする文字もUTF-8でパーセントエンコードします。顧客ごとに「受付番号：A1234」のような文字を入れたURLを作り、申込完了のメールや紙の案内に載せます。

  1. 顧客アプリに「受付番号」を作り、「値の重複を禁止する」をオンにします。
  2. 受付番号から、上の形のURLを計算フィールドか書き出したファイルで作ります。
  3. お客様にURLを渡します。まだ友だちでない人には、先に友だち追加のURL https://line.me/R/ti/p/{LINE ID} を案内します。こちらも @ は %40 にします。
  4. お客様がURLを開き、入力済みの文字をそのまま送ります。
  5. 中継は、届いたテキストが「受付番号：」で始まっていれば、番号で顧客アプリを検索します。
  6. 見つかれば、LINE友だちのテーブル「ひもづけ済み顧客」にその顧客を足し、お客様に「登録しました」と応答メッセージで返します。

応答メッセージで返せば通数に数えられません。番号が見つからなかったときも、応答メッセージで「番号を確かめてもう一度送ってください」と返します。

アカウント連携を使う場合

会員サイトのような自社のログイン画面があるなら、LINEのアカウント連携が使えます。中継が連携トークンを発行して連携用のURLをLINEで送り、お客様が自社サイトにログインすると、結果が accountLink イベントで届きます。連携トークンは10分で切れ、1回しか使えません。連携を外す方法も案内する必要があります。

LINE友だちアプリのレコード。ひもづけ済み顧客のテーブルに顧客が2件入った状態
LINE友だちアプリのレコード。ひもづけ済み顧客のテーブルに顧客が2件入った状態

友だち追加から問い合わせ記録までの流れ

自前の中継で組む場合の手順です。連携サービスやiPaaSで組む場合も、中で起きていることは同じなので、設定画面を読むときの地図になります。

kintoneの準備

  1. LINE友だち、LINE受信、LINE送信の3アプリを、設計表のとおりに作って公開します。
  2. LINE友だちの「アプリの設定」を開き、「設定」タブの「カスタマイズ／サービス連携」から「APIトークン」を開きます。
  3. 「生成する」をクリックします。
  4. 「アクセス権」で、レコードの閲覧、追加、編集にチェックを入れます。削除は付けません。
  5. 「メモ」に「LINE中継用」と書いて保存します。
  6. 画面右下の「保存」をクリックします。
  7. 「アプリを更新」をクリックします。
  8. LINE受信とLINE送信でも同じ手順でトークンを作ります。

APIトークンは1アプリにつき20個まで作れます。複数のアプリにまたがって操作するときは、X-Cybozu-API-Token ヘッダーに複数のトークンをカンマ区切りで並べます。

APIトークンの画面。アクセス権にレコード閲覧・追加・編集のチェックが入った状態
APIトークンの画面。アクセス権にレコード閲覧・追加・編集のチェックが入った状態

LINEの準備

  1. LINE Developersコンソールでチャネルを開き、チャネルの基本設定タブでチャネルシークレットを控えます。
  2. 「Messaging API設定」タブで、長期のチャネルアクセストークンを発行して控えます。
  3. 同じタブの「Webhook URL」の「編集」をクリックし、中継のURLを入れて「更新」をクリックします。
  4. 「検証」をクリックし、「成功」と出ることを確かめます。
  5. 「Webhookの利用」を有効にします。
  6. 「Webhookの再送」を有効にします。初期値は無効です。

Webhook URLはHTTPSで、信頼された認証局の証明書が必要です。自己署名の証明書は使えません。「Messaging API設定」タブの「あいさつメッセージ」と「応答メッセージ」は初期値で有効になっています。友だち追加のあいさつはLINEの機能に任せ、それ以外の応答は中継で返す、という併用ができます。慣れないうちはどちらから送られたメッセージか混同しやすいので、まず「応答メッセージ」を切っておくと切り分けが楽です。

【画面：「Messaging API設定」タブ。Webhook URL、検証、Webhookの利用、Webhookの再送が並んだ部分】

中継がやること

Webhookが届いたら、中継は次の順に処理します。

  1. リクエストヘッダー x-line-signature を取り出します。
  2. 受け取ったリクエストボディを加工せず、チャネルシークレットを鍵にしてHMAC-SHA256を計算し、Base64にします。
  3. 2の結果が1と一致しなければ、何もせずに終えます。
  4. LINEにステータスコード200をすぐ返します。
  5. 届いたイベントを1件ずつ処理します。
  6. フォローイベントなら、LINE友だちを検索し、無ければ追加、あれば状態を友だちに戻します。
  7. フォロー解除イベントなら、状態をブロック中にしてブロック日時を入れます。
  8. メッセージイベントなら、LINE受信にレコードを追加し、LINE友だちの最終受信日時を書き換えます。
  9. 画像やファイルなら、LINEからコンテンツを取得し、kintoneにアップロードしてから受信レコードに添付します。

署名は、ボディを一度でもJSONとして読み込んで書き直すと一致しなくなります。受け取った文字列のまま計算するのがこつです。LINEは送信元のIPアドレスを公開していないので、IPアドレスで絞る方法は使えず、署名の検証が唯一の守りになります。

kintoneへの書き込みは、REST APIで次のように送ります。REST APIではフィールド名ではなくフィールドコードで指定するので、ここではフィールドコードをフィールド名と同じにしてある前提で書きます。

POST https://(サブドメイン).cybozu.com/k/v1/record.json
X-Cybozu-API-Token: (LINE受信のトークン)

{"app": (LINE受信のアプリID),
 "record": {
   "LINEユーザーID": {"value": "U..."},
   "種類": {"value": "テキスト"},
   "本文": {"value": "明日の予約を変更したいです"},
   "イベントID": {"value": "(webhookEventId)"}
 }}

LINE友だちを探すときは、複数レコード取得のAPIで、クエリに LINEユーザーID = "U..." を指定します。画像は、kintoneのファイルアップロードAPI（/k/v1/file.json）に送って fileKey を受け取り、それを添付ファイルフィールドの値にしてレコードを登録します。アップロードしただけで添付しなかったファイルは3日で消えます。

REST APIの使い方そのものは「kintone REST APIの使い方。APIトークンの発行からレコードの取得・登録まで」に書いています。

担当者に知らせる

受信のレコードができたら、担当者が気づける形にします。LINE受信に「レコードの条件通知」を作り、条件を対応状況が未対応、通知先を問い合わせの担当グループにします。メールやkintoneの通知だけでは埋もれるなら、SlackやTeamsに流します。やり方は「kintoneとSlack／Teamsの通知連携」と「通知の設定。見落とされない通知の作り方」にまとめています。

LINE受信には「未対応」という一覧を作り、条件は対応状況が未対応、ソートは受信日時の昇順にします。古いものから片付ける並びです。

LINE受信の未対応一覧。受信日時の古い順に問い合わせが並んだ状態
LINE受信の未対応一覧。受信日時の古い順に問い合わせが並んだ状態
LINE友だちのレコード詳細。受信履歴の関連レコード一覧に問い合わせが並んだ状態
LINE友だちのレコード詳細。受信履歴の関連レコード一覧に問い合わせが並んだ状態

kintoneから個別に送る流れ

kintoneのWebhookは、決まった形のJSONを指定したURLに送るだけです。LINEの送信APIが求める形とは違うので、kintoneのWebhookからLINEへ直接は送れません。ここも中継を挟みます。

kintoneのWebhookを設定する

  1. LINE送信の「アプリの設定」を開き、「設定」タブの「カスタマイズ／サービス連携」から「Webhook」を開きます。
  2. 「追加する」をクリックします。
  3. 説明に「LINE送信」と入れます。
  4. Webhook URLに中継のURLを入れます。先頭の https:// は外します。
  5. 「通知を送信する条件」で、レコードの編集にチェックを入れます。
  6. 「このWebhookを有効にする」にチェックが入っていることを確かめ、「保存」をクリックします。
  7. 「アプリを更新」をクリックします。

送る手順

  1. 担当者がLINE送信にレコードを作り、送信先と本文を入れます。送信状態は下書きのままです。
  2. 本文を見直し、送信状態を送信待ちにして保存します。
  3. kintoneから中継にWebhookが届きます。
  4. 中継は、届いたレコードの送信状態が送信待ちのときだけ処理します。
  5. 中継は、送信先のユーザーIDを to にしてプッシュメッセージ（https://api.line.me/v2/bot/message/push）を送ります。
  6. 成功したら送信状態を送信済みにし、送信日時を入れます。
  7. 失敗したら送信状態を失敗にし、エラー内容を入れます。

送信状態で絞るのは、6で中継自身がレコードを書き換えると、それもレコードの編集としてWebhookが飛ぶからです。条件を付けないと、送信済みにした書き換えでもう一度送ろうとします。

顧客アプリの作り方は「kintoneで顧客管理アプリを作る全手順（項目設計から一覧・通知まで）」に書いています。

kintoneのWebhookの追加画面。通知を送信する条件でレコードの編集にチェックが入った状態
kintoneのWebhookの追加画面。通知を送信する条件でレコードの編集にチェックが入った状態
LINE送信のレコード。送信状態が送信済みになり、送信日時が入った状態
LINE送信のレコード。送信状態が送信済みになり、送信日時が入った状態

送信数と料金

LINE公式アカウントの料金プランは次のとおりです（税別、月額）。

プラン月額固定費無料メッセージ追加メッセージ
コミュニケーションプラン0円200通不可
ライトプラン5,000円5,000通不可
スタンダードプラン15,000円30,000通月20万通までは1通3円、超えた分は2.5円

通数は「送った回数×送った人数」で数えます。1回のリクエストに吹き出しを複数入れても、1人に送れば1通です。プッシュ、マルチキャスト、ナローキャスト、ブロードキャストと、管理画面からのメッセージ配信は数えられます。応答メッセージ、あいさつメッセージ、LINEチャットでの送受信は数えられません。

追加メッセージの単価は2026年10月1日改定後のものです。

1日に20件の問い合わせに2往復ずつkintoneから返すと、月におよそ1,200通で、ライトプランの枠に収まります。コミュニケーションプランの200通は、個別対応を始めるとすぐに使い切ります。

連携サービスやiPaaSを選ぶときに見ること

自前で中継を作らない場合でも、ここまでの流れに照らして確かめる点は決まっています。

  • Webhookの署名を検証しているか
  • 画像やファイルを受け取った時点で保存しているか
  • 1つのLINEユーザーに複数の顧客をひもづけられるか
  • kintoneから送るときにプッシュメッセージになるか、応答メッセージを使える場面があるか
  • 同じWebhookが2回届いたときに二重に記録しないか
  • kintoneのどのアプリに、どのフィールドとして書き込まれるかを自分で決められるか

中継をGoogle Apps ScriptのWebアプリで作る例を見かけますが、受け取ったリクエストの項目にリクエストヘッダーが含まれていないので、x-line-signature を読めず、署名を検証できません。受け口には、ヘッダーを読める環境を選びます。

個人情報の扱いと同意

LINEのユーザーIDは、kintoneの顧客とひもづいた時点で、その人を特定できる情報の一部になります。表示名やトークの本文も同じです。

LINEの側の決まり

ユーザーがプロフィール情報の取得に同意していない場合、WebhookにユーザーIDは含まれません。プロフィール情報の取得も、同意していない人、友だちでない人、ブロックした人については失敗します。LINEの開発ガイドラインでは、特定のユーザーIDについて属性を割り出す行為や、同じユーザーへの大量送信が禁止されています。送信が取り消されたメッセージは、それ以降見たり使ったりできないように扱うことが推奨されています。中継で送信取消のイベントを受けたら、kintoneの本文を消すか、見えないようにする処理を入れます。

自社の側でやること

  • ひもづけのURLを渡すときに、「LINEでのやり取りを顧客情報と合わせて記録し、問い合わせ対応と連絡に使う」と一文添えます。
  • プライバシーポリシーに、LINEで受けた情報を何に使うかを書きます。
  • LINE受信とLINE友だちのアクセス権を、問い合わせ対応をする人に絞ります。
  • 中継は、LINE友だちの状態がブロック中なら送らずに失敗として返します。
  • APIトークンとチャネルアクセストークンは、中継のプログラムの中だけに置きます。

kintoneのJavaScriptから kintone.proxy でLINEのAPIを直接呼ぶ作りは避けます。ブラウザに配信されるJavaScriptは誰でも中身を読めるので、コードに書いたチャネルアクセストークンが漏れます。どうしても画面から直接呼ぶなら、プラグインに認証情報を保存して kintone.plugin.app.proxy で送る形にすると、トークンがJavaScriptに現れません。

できないことと、その代わり

やりたいこと標準でできるか代わりの手
kintoneだけでLINEとつなぐできない連携サービス、iPaaS、自前の中継のどれかを挟む
kintoneのWebhookでLINEに直接送るできない中継を挟む
友だち全員のユーザーIDを一覧で取る認証済アカウントかプレミアムアカウントだけそれ以外はWebhookで届いた人から貯める
表示名で顧客を自動で特定する確実にはできない受付番号かアカウント連携でひもづける
ファイルの読み込みで更新したときに通知する「レコードの条件通知」は送られない中継からREST APIで1件ずつ書く
一括で書き込んだときにkintoneのWebhookを飛ばすCSVやExcelの読み込み、REST APIの一括操作では送られない送信は1件ずつ保存する運用にする

kintoneのWebhookは、1アプリに10個まで、1ドメインで1分に60回までです。それを超えた分は送られません。一斉に何百件も送信待ちにする使い方は、この上限に当たります。一斉送信は、LINE公式アカウントの管理画面のメッセージ配信で行います。

よく詰まるところ

症状原因直し方
「検証」で成功にならない中継が200を返していない、または証明書が自己署名200を返しているか確かめ、信頼された証明書のHTTPSにする
署名がいつも一致しないボディをJSONとして読み込んでから計算している受け取った文字列のまま計算する
急に署名が一致しなくなったチャネルシークレットが再発行された再発行すると古いシークレットはすぐ無効になる。新しい値に差し替える
同じ問い合わせが2件記録されるWebhookの再送で同じイベントが2回届いたwebhookEventId をイベントIDに入れ、重複を禁止する
WebhookにユーザーIDが入っていないお客様がプロフィール情報の取得に同意していないその人は自動でひもづけない。対応は管理画面のチャットで行う
画像があとで開けないLINE側で自動削除された受け取った時点で取得してkintoneに添付する
1回の送信で何通も送られる中継が送信済みにした更新でもWebhookが飛ぶ送信状態が送信待ちのときだけ送る
kintoneのWebhookが届かないライトコース、無効のまま、またはファイルの読み込みで更新したコースを確認し、「このWebhookを有効にする」を確かめ、1件ずつ保存する
失敗した理由がわからないログを見ていないWebhookの画面の「ログを確認」で直近10件の成否を見る
応答メッセージが失敗する応答トークンを使用済み、または受信から1分を過ぎた（1分を超えた動作は保証されない）人が返す返事はプッシュメッセージで送る
プッシュメッセージが送れなくなった月の無料メッセージを使い切った料金プランと通数を見直す
同じお客様なのに別人として届く別のプロバイダーのチャネルで受けている同じ会社の公式アカウントは同じプロバイダーにそろえる
兄弟の2件目がひもづけられない顧客アプリにユーザーIDを1つだけ置いたLINE友だちを別アプリにし、テーブルで複数の顧客を持つ

kintoneのWebhookの失敗は、1分に60回を超えた、データが1MBを超えた、タイムアウトした、送り先が止まっている、のどれかです。中継でも届いたリクエストと返したステータスコードを記録しておくと、どちらで止まったかがすぐ分かります。

kintoneのWebhookの実行ログ。成功と失敗のマークが並んだ状態
kintoneのWebhookの実行ログ。成功と失敗のマークが並んだ状態

次にやること

中継からkintoneに書き込む部分は、「kintone REST APIの使い方。APIトークンの発行からレコードの取得・登録まで」で手を動かしながら覚えると早いです。ひもづけ先になる顧客アプリがまだ無いなら、「kintoneで顧客管理アプリを作る全手順（項目設計から一覧・通知まで）」から作ります。受けた問い合わせを見落とさない仕組みは、「通知の設定。見落とされない通知の作り方」と「kintoneとSlack／Teamsの通知連携」を組み合わせて作ります。

あわせて読む

画面に出てくる言葉の意味はkintone用語集で引けます。