【実践】n8n CloudでLINEの現場報告をkintoneに自動登録してみた

現場からの報告をLINEに送るだけで、kintoneにレコードが登録され、受付番号がLINEに返ってくる。今回はこの仕組みを、n8nのクラウド版（n8n Cloud）だけで作ります。LINEからのリクエストが本物かどうかを確かめる「署名検証」まで実装し、偽のリクエストが弾かれることも確認します。

対象は、kintoneは使っているが「現場の人がkintoneを開いてくれない」という悩みを持つ情シス・現場リーダーの方です。n8n Cloudなら、自分のPCにn8nを入れたり、インターネットに公開する仕組みを用意したりする必要がありません。ブラウザだけで最後まで進められます。

■完成形：LINEに3行送ると、kintoneに1件登録される

LINE公式アカウントに、次のようなメッセージを送ります。1行目が拠点、2行目以降が報告内容です。

中央営業所
エアコンから異音あり
至急確認お願いします

するとkintoneの「現場報告」アプリにレコードが1件増え、LINEには次の返信が届きます。

報告を受け付けました。
受付番号 #1
拠点：中央営業所

受付番号はkintoneのレコードIDをそのまま使っています。現場の人はLINEしか触りませんが、管理側はいつものkintoneの一覧で対応状況を追えます。プロセス管理を設定すれば、対応状況の管理にも利用できます。

■全体構成：LINEのWebhookをn8n Cloudが直接受け取る

LINEの仕組みでは、ユーザーがメッセージを送ると、LINEのサーバーがあらかじめ登録したURL（Webhook URL）にHTTPSでPOSTリクエストを送ってきます。n8nのWebhookノードを、この受け口として使います。kintoneへの登録もLINEへの返信も、n8nのHTTP Requestノードで呼べます。

LINEのWebhook URLは、一般的なブラウザが信頼する認証局の証明書を使ったHTTPSでなければなりません。n8n CloudのWebhookノードには、最初からこの条件を満たす公開URL（https://（ワークスペース名）.app.n8n.cloud/webhook/…）が付いています。そのため、自宅PCでn8nを動かす場合に必要なトンネルやリバースプロキシの準備は要りません。URLも固定なので、一度LINEに登録すれば変える必要がありません。

LINE（ユーザーのスマホ）
  ↓ メッセージ送信
LINEプラットフォーム
  ↓ Webhook（HTTPS POST）
n8n Cloud（https://xxxx.app.n8n.cloud/webhook/line）
  ├─ 署名検証
  ├─ kintone REST APIでレコード登録
  └─ LINE Messaging APIで返信

■費用：n8n Cloudは有料だが、検証は無料トライアルで足りる

n8n Cloudは有料のサービスです。2026年10月時点の料金表では、いちばん安いStarterプランが年払いで月€20、ワークフローの実行回数は月2,500回までです。

試すだけなら、無料トライアルで十分です。トライアルの内容は次のとおりです。

トライアルで作ったワークフローを残しておきたい場合は、期限が切れる前にJSONでエクスポートしておきましょう。

LINE側は無料のコミュニケーションプラン（月200通まで無料）で十分です。というのも、今回使う応答メッセージ（Reply API）は、料金プランのメッセージ通数にカウントされないからです。カウントされるのはプッシュ・マルチキャスト・ブロードキャスト・ナローキャストの4種類だけです。報告を受けたら返信する、という使い方なら無料枠を消費しません。

なお、以前よく使われていたLINE Notifyは2025年3月末で終了しています。LINEとシステムをつなぐ手段は、現在はMessaging APIが基本です。

■準備するもの

■手順1：kintoneに「現場報告」アプリを作る

フィールドは次の5つです。フィールドコードはn8n側のJSONと一致させる必要があるので、表のとおりに設定してください。

報告者はkintoneのユーザーではないので、「ユーザー選択」フィールドではなく文字列でLINEのユーザーIDを持たせます。誰が送ったかを名前で見たい場合は、後から「LINE User ID → 氏名」のマスタアプリを作ってルックアップでつなぐと運用しやすくなります。

アプリを公開したら、［アプリの設定］→［APIトークン］でトークンを発行します。付与する権限は「レコード追加」だけにしておきましょう（値を登録するフィールドの編集権限も必要です）。万一トークンが漏れても、閲覧や削除はできません。ただし、不正なレコードを追加される危険は残ります。トークンを発行・変更した後は、［アプリを更新］を押さないと有効になりません。

アプリIDも控えておきます。アプリを開いたときのURL https://（サブドメイン）.cybozu.com/k/123/ の数字部分です。

■手順2：LINE公式アカウントでMessaging APIを有効にする

1. LINE Official Account Managerで公式アカウントを作成します。
2. ［設定］→［Messaging API］で「Messaging APIを利用する」を押し、プロバイダーを選びます。一度プロバイダーと連携すると、後から変更・解除はできません。
3. LINE Developersコンソールで該当チャネルを開き、次の2つを控えます。
   • ［チャネル基本設定］タブのチャネルシークレット（署名検証に使う）
   • ［Messaging API設定］タブで発行するチャネルアクセストークン（長期）（返信に使う）
4. Official Account Managerの［応答設定］で、「応答メッセージ」と「あいさつメッセージ」をオフにします。

4のうち、特に「応答メッセージ」がオンのままだと、n8nの返信とは別に「メッセージありがとうございます」のような自動応答が届き、返信が二重になります。

同じ［応答設定］画面には「Webhook」のスイッチもありますが、Webhook URLを登録するまではオンにできません。手順4でURLを登録した後にオンにします。

■手順3：n8n Cloudでワークフローを作る

n8nの公式サイトから無料トライアルに登録すると、自分専用のワークスペース（https://（ワークスペース名）.app.n8n.cloud）が用意されます。ワークスペースを開いて新しいワークフローを作り、次の6つのノードを並べます。各ノードが何をしているかを順に説明します。

[LINE Webhook] → [署名を計算] → [署名は一致？] ─true→ [報告内容を取り出す] → [kintoneに登録] → [LINEに返信]
                                                └false→ （何もしない）

認証情報（Credentials）を3つ登録する

シークレットやトークンはノードに直接書かず、n8nの認証情報に保存します。ワークフローをエクスポートしても認証情報の秘密値は直接埋め込まれません。ただし、JSONにはURLやID、固定値などが残るため、公開する前に中身を確認してください。

認証情報は、各ノードの設定画面から作るのが手軽です。認証情報の欄にある［Connect to Crypto］や［Connect to Header Auth］を押すと作成画面が開きます。2つ目以降のHeader Authは、欄のプルダウンから［Create new credential］を選びます。画面左上の名前（初期値は「Crypto account」など）をクリックすると、表の名前に変えられます。

LINE側のValueは、Bearer とトークンの間に半角スペースが1つ入ります。Bearerbj8y… のように詰めて貼り付けてしまうと、返信が401エラーになります。また、Hmac Secretに入れるのは［チャネル基本設定］タブのチャネルシークレットです。［Messaging API設定］タブのアクセストークンと取り違えないよう注意してください。

ノード1：LINE Webhook（受け口）

このワークフローでいちばん重要な設定がRaw Bodyです。署名検証は「LINEから届いたそのままのバイト列」で計算しなければならず、n8nがJSONとして解釈した後のデータでは一致しません。LINEの公式ドキュメントにも、検証前にボディをデシリアライズしたり文字列を置換したりすると失敗する、と明記されています。Raw BodyをONにすると、解釈済みの body に加えて、生のボディがバイナリ data として後続ノードに渡ります。Raw Bodyは、Optionsの［Add option］から追加します。

Respondを「Immediately」にしているのは、LINEに素早く200を返すためです。Webhookの再送を有効にしている場合、Botサーバーが2xxを返さないとLINEはWebhookを再送の対象にします（再送は既定では無効です）。返信は後続のノードがReply APIで別途送るので、ここで即答しても問題ありません。

ノード2：署名を計算（Crypto）

LINEの署名は、チャネルシークレットを鍵にしてボディのHMAC-SHA256を計算し、Base64にしたものです。Cryptoノードの既定のEncodingはHEXなので、BASE64に変えるのを忘れないでください。HEXのままだと、本物のリクエストもすべて不一致で止まります。

ノード3：署名は一致？（IF）

条件はひとつだけです。計算した値と、LINEがヘッダーに付けてきた値が一致すれば本物とみなします。

{{ $json.expectedSignature }}   is equal to   {{ $json.headers['x-line-signature'] }}

falseの出口には何もつなぎません。偽のリクエストはここで処理が終わります。

なぜここまでするのか。Webhook URLは秘密の情報ではなく、知られてしまえば誰でもPOSTできます。署名検証がなければ、第三者がでたらめな報告をkintoneに大量登録できてしまいます。IPアドレスで制限できればよいのですが、LINEはWebhookの送信元IPを公開しておらず、予告なく変わる可能性があるとしています。つまり、LINEが公式に提供・推奨している送信元の確認方法が署名検証です。

n8n Cloudでは、偽のリクエストもワークフローの実行1回として数えられます。署名検証で処理を止めても実行回数は減らない点は、プランの上限を考えるときに覚えておいてください。

ノード4：報告内容を取り出す（Code）

LINEのWebhookは、1回のリクエストに複数のイベントをまとめて送ってくることがあります。また、LINE Developersの「検証」ボタンを押したときは、events が空の配列で届きます。どちらでもエラーにならないよう、Codeノードでテキストメッセージだけを取り出します。

// LINEのWebhookは1回のリクエストに複数イベントが入ることがある
// 「検証」ボタンからのリクエストは events が空配列
const events = $input.first().json.body?.events ?? [];
const out = [];

for (const ev of events) {
  // 今回はテキストメッセージだけを扱う
  if (ev.type !== 'message' || ev.message?.type !== 'text') continue;

  const lines = ev.message.text.split(/\r?\n/).map(s => s.trim()).filter(Boolean);
  // 1行目＝拠点、2行目以降＝報告内容。1行だけなら拠点は「未入力」
  const site = lines.length > 1 ? lines[0] : '未入力';
  const report = lines.length > 1 ? lines.slice(1).join('\n') : lines[0];

  out.push({
    json: {
      replyToken: ev.replyToken,
      userId: ev.source?.userId ?? '',
      site,
      report,
    },
  });
}

return out;

空の配列を返すと、後続のノードは実行されません。検証ボタンのリクエストも、スタンプや画像も、ここで静かに終わります。

ノード5：kintoneに登録（HTTP Request）

ボディは次のとおりです。app の123は手順1で控えたアプリIDに置き換えてください。

{{ JSON.stringify({
  app: 123,
  record: {
    site: { value: $json.site },
    report: { value: $json.report },
    line_user_id: { value: $json.userId }
  }
}) }}

kintoneのレコード登録API（POST /k/v1/record.json）は、成功すると登録したレコードの id を返します。これを次のノードで受付番号として使います。

kintone側でIPアドレス制限をかけている場合は、n8n Cloudからのアクセスが弾かれます。その場合は、kintoneの管理者に許可の設定を相談してください。

ノード6：LINEに返信（HTTP Request）

{{ JSON.stringify({
  replyToken: $('報告内容を取り出す').item.json.replyToken,
  messages: [{
    type: 'text',
    text: '報告を受け付けました。\n受付番号 #' + $json.id + '\n拠点：' + $('報告内容を取り出す').item.json.site
  }]
}) }}

Header Authの認証情報が1つしかない状態でこのノードを開くと、kintone用の「kintone API Token」が自動で選ばれていることがあります。必ず「LINE Channel Access Token」に切り替えてください。

直前のノードの出力はkintoneのレスポンスに置き換わっているため、返信トークンと拠点は $('報告内容を取り出す') でノード4の出力から参照しています。返信トークンは1回しか使えず、受信後すぐに使う前提のものなので、返信は処理の最後にまとめて1回だけ送ります。

■手順4：ワークフローを公開し、LINEにWebhook URLを登録する

n8nのWebhookノードには、テスト用URL（/webhook-test/line）と本番用URL（/webhook/line）の2種類があります。

LINEに登録するのは本番用URLです。n8n CloudのWebhookノードを開き、［Production URL］に切り替えると本番用URLが表示されるので、それをそのままコピーします。

https://（ワークスペース名）.app.n8n.cloud/webhook/line

次に、エディタ右上の［Publish］を押してワークフローを公開します。現在のn8nでは、公開のたびにバージョン名を入れるダイアログが出ます。既定の名前のままでよいので、［Publish］を押して確定します。「Workflow published」と表示され、右上が「Published」になれば公開完了です。

公開したら、LINE Developersの［Messaging API設定］→［Webhook設定］で、［Webhook URL］の［編集］を押してURLを入力し、［更新］を押します。

登録したら［検証］ボタンを押し、「成功」と表示されればつながっています。続けて「Webhookの利用」をオンにしてください。これでOfficial Account Managerの［応答設定］にある「Webhook」もオンになります。

ただし、この「成功」はn8nが200を返したという意味にすぎず、署名が一致したかどうかは分かりません。n8nの［Executions］を開き、検証のリクエストが「署名は一致？」のtrue側を通って「報告内容を取り出す」で終わっているかまで確認しておくと確実です。

■手順5：動作確認は「本物が通る」「偽物が止まる」の両方を見る

本物のメッセージを送る

LINE Developersの［Messaging API設定］にあるQRコードで公式アカウントを友だち追加し、冒頭の3行メッセージを送ります。kintoneにレコードが入り、受付番号が返ってくれば成功です。n8nのExecutionsを開くと、6つのノードがすべて緑になっているはずです。筆者の環境（2026年10月8日、n8n Cloud）では、メッセージを送ってから返信が届くまでの処理時間は約4.5秒でした。

偽のリクエストを送る

次に、署名のでたらめなリクエストを自分で送ってみます。

curl -X POST https://（ワークスペース名）.app.n8n.cloud/webhook/line \
  -H "Content-Type: application/json" \
  -H "x-line-signature: forged-signature" \
  -d '{"destination":"x","events":[{"type":"message","replyToken":"dummy","source":{"type":"user","userId":"Uattacker"},"message":{"type":"text","id":"1","text":"偽拠点\n偽の報告"}}]}'

レスポンスは200（Workflow was started）ですが、Executionsを見ると「署名は一致？」のfalse側で止まり、kintoneにはレコードが増えません。200は受信を正常に受け付けたという応答にすぎず、署名が正しかったという意味ではありません。後続の処理は行われていません。

■まとめ：受け口はn8n Cloud、守りは署名検証

n8n Cloudを使うと、Webhookの受け口とその公開URLが最初から用意されているので、LINEとkintoneをつなぐ作業はワークフローづくりに集中できます。残る仕事は署名検証で、ここだけは「ノーコードだから」と省略せず、Raw BodyとBASE64の2点を押さえて実装しておくべきです。LINEの検証ボタンが「成功」でも安心せず、実行履歴で署名が一致しているかまで確かめておきましょう。

まずは無料トライアルの14日間で、自分のスマホから報告を送ってkintoneに入るところまで動かしてみてください。社内で本格運用する段階になったら、実行回数に合ったプランを選び、LINEユーザーと社員をひも付けるマスタアプリの追加を検討するとよいでしょう。費用をかけずに自分のPCで動かしたい場合は、ローカルのn8nとCloudflare Tunnelを組み合わせる方法もあります。

次回は、写真付きの報告に対応します。LINEに送られた画像を取得してkintoneの添付ファイルに保存する方法と、テキストと写真が別々のメッセージイベントとして届くLINEの仕様をどう扱うかを解説する予定です。

■参考リンク

• 署名を検証する｜LINE Developers
• Always verify the signature on your Messaging API webhooks｜LINE Developers
• ボットを作成する（Webhook URLの要件）｜LINE Developers
• メッセージ（Webhook）を受信する｜LINE Developers
• Messaging APIの料金｜LINE Developers
• レコードを登録する｜cybozu developer network
• Pricing｜n8n
• Start your free trial｜n8n Docs
• Webhook node｜n8n Docs
• Crypto node｜n8n Docs

※本記事の内容は2026年10月時点の情報です。各サービスの仕様・画面・料金は変更される可能性があるため、最新情報は公式ドキュメントをご確認ください。