LINE公式アカウントから届いた問い合わせを業務システムへ自動登録していても、画面上はすぐに停止に気づけないことがあります。連携を始める前に、「LINEから受け取れたか」と「登録先へ反映できたか」を分けて確かめる方法を決めておきましょう。
Webhookの到達と、業務システムへの登録を分ける
【事実】LINE Developersには、Webhook送信時の接続失敗、応答の遅延、200番台以外の応答などを確認できるエラー統計があります。ただし初期設定では無効で、有効化した期間のエラーだけが集計されます。（出典：LINE Developers「Webhookのエラーの原因と統計情報を確認する」）
【推奨】まずLINEから連携サーバーまでの受信を確認します。次に、そのサーバーからSalesforce、kintone、HubSpot、Googleスプレッドシートなど、実際の登録先へ記録が反映されたかを確認します。LINE側のエラー表示だけでは、後段の登録成功まで判断できません。
異常を見つける場所と、連絡する人を決める
【事実】LINE Developersコンソールでは、［Messaging API設定］の［エラーの統計情報］を有効にすると、［Webhookエラー］タブで送信時のエラーを確認できます。Webhook URLの［検証］は疎通確認であり、そのリクエストはエラー統計に含まれません。（出典：LINE Developers「Webhookのエラーの原因と統計情報を確認する」、LINE Developers「Webhook URLを検証する」）
【推奨】連携サーバー側では、受信時刻と処理結果、登録先の応答、再試行待ちの有無を追えるようにします。記録には調査に必要な情報だけを残し、顧客の会話本文や接続キーを安易に含めないでください。誰がどの画面を確認するか、異常時に誰へ連絡するかを運用表に記します。
再送があることと、復旧できたことは別
【事実】LINEのWebhook再送は初期設定では無効です。有効にした場合も、すべてのWebhookが確実に再送される保証はありません。LINE Developersは、重複送信や到着順の変化にも注意を促しています。（出典：LINE Developers「メッセージ（Webhook）を受信する」）
【推奨】障害が解消したら、エラー表示が消えたことだけで終わらせず、対象期間の受付と登録先の記録を照合します。登録されていないものがあれば、二重登録を避ける確認をしてから、担当者が補完方法を決めます。再送や再実行の設計は、使うシステムに合わせて確認してください。
最初に決める運用表
「確認する箇所」「見る人」「異常時の連絡先」「復旧後に照合する記録」を一枚にまとめます。例えば、Webhookエラーは開発・保守担当、登録先の未反映は業務担当と保守担当が一緒に確認する、と役割を分けます。監視画面を増やすことより、気づいた人が次に何をするかが分かることを優先します。
まとめ
連携の運用では、Webhookの受信、登録先への反映、復旧後の照合を分けて確認します。まずは各段階で「どこを見るか」「誰が見るか」「異常時に誰へ連絡するか」を一枚に書き出してください。
現在の連携で確認箇所や担当が分からない場合は、和-Nodeへの相談で運用の流れを整理できます。相談時に実際の顧客情報や接続キーを送る必要はありません。