kintone と LINE をつなぐ：LINEの問い合わせをkintoneに起票し、進み具合をLINEに返す設計

kintone と LINE をつなぐ、と言ったときに作るものは3つです。LINE で受けた問い合わせをレコードにする「起票」、担当者が進めた状況を LINE に返す「進み具合の通知」、その2つを同じお客様に向けるための「LINE ユーザーIDの持ち方」。プラグイン・連携サービス・iPaaS・自作のどれを選んでも、この3つのどこまでを任せられるかが違うだけで、中身は同じです。

プラグインや連携サービスで済むかは、まず公式の一覧で見られます。サイボウズの「プラグイン・連携サービス」の一覧には、LINE 公式アカウントと kintone をつなぐ製品が載っています。たとえば KUZEN for kintoneのページは、kintone の顧客属性での配信と、LINE で取得した回答や行動履歴の kintone への連携を挙げ、価格は個別見積りとしています。どの製品でも、上の図の4本の矢印のうち、どれを受け持つかを先に確かめます。

「LINE WORKS と kintone」は別の話です。LINE WORKS は社内向けのチャットで、kintone とつなぐ製品は、LINE WORKS の連携ソリューションに Joboco・Smart at message for kintone・LITONE for チャットボットなどが載っています。このうち Smart at message for kintone は、提供会社がLINE公式アカウントにも対応したと案内しています（製品ページの連携先には LINE WORKS と LINE が並びます）。お客様の LINE 公式アカウントとつなぐのがこの記事の対象で、社内の通知や日報は「LINE Works × kintone連携ガイド」と「LINE WORKS と LINE の連携」を見てください。

3つの流れは、起票→担当者が進める→進み具合を返す、の順に動く

お客様が LINE にメッセージを送ってから、進み具合が LINE に戻るまでを、順に並べます。受け口の役目は、LINE から届いたものを失わずに保存して kintone に渡すことと、kintone の通知を LINE に渡すことです。受け口の作り方（署名の検証、イベントの保存、200を返す、重複の除去、失敗したときの再試行）は「LINE × Slack連携」にまとめたので、ここでは kintone との間だけを扱います。

LINE のユーザーIDは、問い合わせのレコードに持つ

LINE から届くイベントには、送ったお客様のユーザーIDが入っています。形は U に英数字32字が続く33文字で、表示名や LINE ID とは別の値です（ユーザーIDを取得する）。進み具合を返すときは、このIDを宛先にプッシュメッセージを送るので、起票のときに問い合わせのレコードへ持たせておきます。同じお客様が何度も問い合わせるので、このIDの項目は重複を許します。

ユーザーIDは、同じお客様でもプロバイダーごとに別の値になります。連携サービスが別のプロバイダーのチャネルを使うと、自社の LINE ログインや他のシステムのIDと合いません（「Salesforce と LINE をつなぐ」）。また、プロフィール情報の取得に同意していないユーザー（PC版の LINE だけを使っているユーザー）からの Webhook には、ユーザーIDが含まれません（プロフィール情報取得の同意）。この人たちへは、プッシュで進み具合を返せません。

プラグイン・連携サービス・iPaaS・自作：保守する人と、IDの置き場で選ぶ

最後の注記が、選ぶときの落とし穴になります。LINE の Webhook の送信先に設定できるのは1つだけです（ボットを作成する）。すでに配信ツールなどがその URL を使っているチャネルに、kintone 用の受け口をもう1つ足すことはできません。足すなら、いまの送信先から受け口へ転送してもらうか、同じ受け口に統合します。

ノーコードで、どこまで作れるか

kintone → 外部は、ノーコードで組めます。kintone のヘルプは、Webhook の送信先に Zapier・Microsoft Power Automate・IFTTT などを指定して、レコードの追加やステータスの更新を外部サービスに渡す設定を案内しています（Webhookを設定する）。kintone → 外部の向きは、プラグインに頼らなくても組めます。

外部 → kintone、つまり LINE から起票する側は、LINE の署名の検証と、重複の除去が要ります。ノーコードのツールでこの2つを作れるかは、ツールごとに違います。作れないときは、署名の検証と保存だけを受け口に任せ、その後ろをノーコードのフローに渡す形にします。

無料で試せる範囲と、本番の前提

本番では、kintone のコースで使える機能が変わります。料金ページは、外部サービス連携・プラグインなどの拡張機能をスタンダードコース以上の機能として並べ、1アプリごとの1日の API リクエスト数をスタンダードコースで1万、ワイドコースで10万としています（kintone 料金）。ライトコースの契約では、Webhook も API トークンも使えません（Webhookを設定する、APIトークンを生成する）。開発者ライセンスは、API の動作確認をする場所で、問い合わせを受ける本番の環境ではありません（kintone 開発者ライセンス）。LINE のコミュニケーションプランなどの内容は、LINE公式アカウントの料金プランにあります。

最小ユーザー数は、2024年10月以降の新しい契約から5ではなく10になりました。月額サービスで10ユーザー未満のまま契約している既存のお客様は、ユーザー数やコースを変えなければ2026年10月末まで契約した人数の料金で使え、2026年11月分（11月1日請求）から10ユーザーに自動で切り替わります。ユーザー数やコースを変えるときは、変更の時点で10ユーザー以上が必要です。ライトコースの10ユーザー未満の契約から、Webhook や API トークンを使えるスタンダードコースに上げるときも同じです（サイボウズ「クラウドサービスの価格改定に関するご案内」）。LINE 側は、2026年10月1日に追加メッセージの料金が改定されました（LINEヤフー for Business のお知らせ）。

kintone のアプリ：どのフィールドに何を入れ、誰が書くか

問い合わせを受けるアプリは、1つの問い合わせを1つのレコードにします。フィールドは、受け口が書くもの、担当者が書くもの、受け口が書き戻すものの3つに分けておくと、あとで「誰が書き換えたか」で迷いません。

API でレコードを登録するときは、存在しないフィールドコードを指定しても、そのフィールドが無視されるだけで、レコードは登録されます（1件のレコードを登録する）。フィールドコードを打ち間違えても、エラーにはなりません。登録のあとにレコードを取り直して、入るはずの値が入っているかを確かめる処理を、最初のテストに入れておくと安全です。

画像は、受けたその場で kintone に入れる

LINE で受けた画像・動画・音声・ファイルは、メッセージIDを使って取得できます。ただし、一定期間後に自動で削除され、保存期間は保証されません（コンテンツを取得する）。kintone に入れるときは、ファイルをアップロードするAPIで一時保管領域に置き、返ってきたファイルキーを、レコードの登録のときに添付ファイルフィールドの値にします。アップロードしたファイルは、レコードなどに添付しないと3日間で削除されます（ファイルをアップロードする、制限値一覧）。取得とアップロードと登録は、続けて行います。

1人が続けて送ったら、新しいレコードか、コメントか

メッセージのたびにレコードを作ると、1つの相談が何件にも割れます。当社なら、そのお客様の未完了のレコードがあるときは、既存のレコードにコメントで追記し、無いときだけ新しく起票します。未完了のレコードを探すには、アプリの閲覧権限が要ります。重複禁止はレコードの項目に付ける設定で、コメントには使えないので、コメントの二重投稿は、受け口の保存側で webhookEventId の処理済みを持って防ぎます（「LINE × Slack連携」）。コメントは、レコードコメントを投稿するAPIで入れられます。最大65,535文字で、アプリとレコードの閲覧権限が要ります（レコードにコメントを投稿する）。未完了かどうかは、ステータスで見分けます。

既存の顧客アプリと結ぶ

顧客を管理するアプリが別にあるときは、問い合わせアプリの顧客欄を、ルックアップで顧客アプリに結ぶ形があります。API でルックアップのコピー元の値を持ってきて登録するには、リクエストに両方のアプリの API トークンを指定します。1回のリクエストで指定できるトークンは9個までです（kintone REST APIの認証）。LINE のIDと顧客IDを、お客様のログインで結ぶ方法は、アカウント連携で作れます。連携トークンは10分間有効で1回しか使えません（ユーザーアカウントの連携）。Salesforce に置き換えた場合の流れは「LINEで受けた問い合わせを Salesforce のリードにする」にあります。

kintone の進み具合を LINE に返す：Webhook でステータスを受けて、プッシュで送る

進み具合を返す仕組みは、kintone の Webhook です。アプリの設定の「Webhook」で、送信先の URL と「通知を送信する条件」を設定し、「アプリを更新」で反映します。条件は、レコードの追加・編集・削除、コメントの書き込み、ステータスの更新から選びます。ブラウザーの操作だけでなく、REST API による操作でも通知されます（Webhookを設定する、Webhookを使ってみよう）。

ここで、条件は「ステータスの更新」だけにします。受け口が REST API でレコードを追加したり、通知済みの項目を書き戻したりしたときも、条件に「レコードの追加」「レコードの編集」が入っていると、受け口に通知が戻ってきて、ループになるためです。送信先の URL は、ヘルプの手順で、先頭の「https://」を除いて入れます。最大1,024文字、説明は64文字までで、1つのアプリに設定できる Webhook は10個までです。

届く通知は JSON で、ステータスを変えたときは type が UPDATE_STATUS、レコードの内容（record）、アプリのID（app.id）、レコードのタイトルとURL、通知ごとに付く固有のIDが入っています（kintoneの操作で送信されるWebhookの通知内容）。公式の一覧に、署名にあたる項目はありません。署名が無いので、届いた通知の中身をそのまま信じると、偽の通知でお客様に誤った進み具合を送りかねません。受け口は、通知の record は使わず、app.id と record のIDだけを受け取り、REST API でそのレコードを取り直して、現在のステータスを確かめてから送ります。送信先の URL に、推測されにくい文字列を含めておくのも有効です。取り直しは、あとの「拾い直し」と同じ手順にできます。

ステータスを、お客様に送る文面に変える

kintone のステータス名は、社内の言葉です。そのまま LINE に流さず、受け口で「ステータス名 → お客様向けの文面」の対応表を持ちます。表に無いステータスは、送りません。社内の差し戻しや保留が、お客様に届かないようにするためです。コメントの書き込み（ADD_RECORD_COMMENT）も、社内のやり取りが混ざるので、自動では転送しません。

返す手段で、通数が変わります。応答メッセージは通数に数えず、プッシュは数えます（Messaging APIの料金）。応答トークンは一度しか使えず、Webhook を受信してから1分以内に使う必要があります（Messaging API リファレンス）。進み具合は担当者が動いたときに送るので、ほぼプッシュです。たとえば1件の問い合わせで通知を3回送るなら、月200通の無料枠は66件ぶんで尽きます（試算。200 ÷ 3 ≒ 66）。コミュニケーションプランは、無料枠を超える追加メッセージを送れません（LINE公式アカウントの料金プラン）。通知の回数は、問い合わせの数から逆算して決めます。

お客様が LINE の画面を見るだけで進み具合が分かるようにするには、ユーザー単位のリッチメニューを使う手もあります。ユーザーごとに別のメニューを結べて、デフォルトより優先され、トーク画面に入り直さなくても即時に切り替わります（ユーザー単位のリッチメニューを使う）。

この「受け付けた」「準備できた」の通知がどう見えるかは、当社の公開デモ「モバイルオーダー」（架空の店舗・データ）で、注文から「できあがり」の通知までを操作して確かめられます。会員台帳と Messaging API のつなぎ方は「LINE×CRM連携」にあります。

kintone の Webhook は、取りこぼす前提で組む

kintone の Webhook は、ドメイン単位で1分間に60回までしか送られず、61回目以降の操作では通知が送られません（Webhookを設定する）。Excel や CSV の読み込み、複数のレコードの一括削除、複数のレコードを一括操作する REST API で操作した場合も、通知は送られません。通知に失敗する原因は、60回超えのほかに、通知のデータが1MBを超えた、kintone のタイムアウト、受け口側の停止やタイムアウトが挙がっています。実行ログで見られるのは、Webhook の設定ごとに直近10件までです（Webhookの実行ログを確認する）。

この性質のため、通知だけを頼りにすると、返したつもりの進み具合が届いていない状態が静かに起きます。受け口が LINE に返したあと、レコードの「通知済みのステータス」を、返したステータス名に更新しておきます。定期的に、現在のステータスと通知済みのステータスが食い違っているレコードを探し、食い違っていれば、同じ手順で送り直します。一括操作で通知が出なかったレコードも、同じ方法で拾えます。

うまく動かないとき：同じ問い合わせが2件、通知が来ない、エラーで落ちる

運用で出る問題は、大きく3つに分かれます。症状ごとに、まず見る場所があります。

同時実行は、ドメイン全体で100

kintone の REST API の同時実行は、1つのドメインにつき100までで、上限を超えると HTTP ステータスコード429が返ります（制限値一覧）。100という上限は、カスタマイズや連携の REST API にかかるものです。性能の目安としての「同時リクエスト数」には、ユーザーの画面操作も含まれるので、人が多く使う時間帯は、REST API の処理も遅くなります。上限を超えたときは、原因になったアプリだけでなく、ドメイン全体で REST API のリクエストがエラーになります（kintoneの性能Vol.2）。LINE の一斉配信のあとに返信が集中しても、社内の他の業務アプリが道連れで止まらないよう、受け口が kintone に出す数は小さな値に絞ります。

一度に登録できるレコードは100件までで、処理に失敗すると、そのリクエストの登録はすべてキャンセルされます（複数のレコードを登録する）。受付イベントIDを重複禁止にしていると、すでに登録済みの1件が混ざっただけで、100件の登録全体が取り消されます。1件ずつ登録するか、重複を先に除いてからまとめる形にします。

1日の上限は、超えてもエラーにはならない

1日に実行できる API リクエスト数は、契約するコースで決まります（スタンダードコースは1アプリ1日1万、ワイドコースは10万）。数えるのは、リクエストで単一のアプリIDを指定する API で、bulkRequest で複数の API を動かしたときは、動かした API の数だけ数えます。リセットは日本時間の毎日午前9時です（制限値一覧、料金）。上限を超えても、リクエストの実行はエラーになりません。翌日の午前9時ごろに、サイボウズドットコムストアの管理者宛てに警告メールが届きます（kintoneの性能Vol.2）。

1件の問い合わせで通知を3回送るなら、API は、起票1回と、通知ごとの取り直し1回・通知済みの更新1回で、合わせて7回です。1万回は約1,400件ぶんです（試算。1 + (1 + 1) × 3 = 7、10,000 ÷ 7 ≒ 1,428）。重複の検索や拾い直しの取得は、この数に入っていません。

kintone 側の権限：連携用のトークンを、用途ごとに分ける

受け口が kintone に入るときの鍵は、API トークンが基本です。アプリごとに生成し、1つのアプリにつき20個まで作れます。生成したトークンには、許可する操作を選びます。ここで設定したアクセス権は、アプリ・レコード・フィールドのアクセス権の設定に関わらず、優先されます（APIトークンを生成する）。つまり、トークンの権限が、そのままアプリ全体への権限になります。

そこで、用途ごとにトークンを分けます。この記事の設計が使う操作は3種類です。起票（レコードの追加）、読み取り（同じ値のレコードの検索、未完了のレコードの検索、コメントの投稿、通知を受けたあとのレコードの取り直し）、書き戻し（通知済みのステータスの更新）。登録には、アプリのレコード追加権限と、値を入れるフィールドの編集権限が要り（1件のレコードを登録する）、更新にはレコードの編集権限が（1件のレコードを更新する）、コメントの投稿にはアプリとレコードの閲覧権限が要ります（レコードにコメントを投稿する）。そのため、トークンは3つにします。

3つに分けても、「漏れても読めない」にはなりません。読める鍵を読み取り用の1つに絞れるだけです。読み取り用は、受け口の中でも読み取りの処理だけが持つようにして、置き場所の秘密情報の管理に入れます。重複の確認を「起票を断られたら処理済みとして扱う」だけにすれば、起票用だけでも動きますが、断られた理由が重複とは限らないので、検索で確かめる形を勧めます。トークンのアクセス権は、アプリ全体にかかります。APIトークンを使った操作は、kintone では Administrator による操作として扱われます（kintone REST APIの認証）。

ユーザーの権限で動かしたいときは、連携用のユーザーを作り、パスワード認証にします。2要素認証を有効にしたユーザーは、パスワード認証で REST API を実行できません。公式は、2要素認証を無効にした連携用ユーザーを用意するよう案内しています。ドメインに IP アドレス制限がある場合は、受け口の IP アドレスを許可するか、Basic 認証・クライアント証明書で実行します（同じページ）。

操作の記録は、cybozu.com共通管理者が監査ログで確認できます。Webhook の実行ログは、設定ごとに直近10件までなので、それより古い通知は監査ログで見ます（Webhookの実行ログを確認する）。受け口の側にも、受け取ったイベントのIDと処理の結果を残しておくと、お客様から「返事が来ない」と言われたときに、どこで止まったかを順にたどれます。

kintone と LINE のつなぎ方や、受け口の作り方、kintone の側のアプリの設計は、LINE運用・伴走支援のページから相談できます。kintone のアプリの開発は、業務ツール開発のページも見てください。