LINEのWebhookが届かないとき｜エラー統計と受信記録で確認する順番

LINEからのWebhookが届かないときは、「LINEが送れなかった」「自社が受け取れなかった」「受け取ったあとに処理が止まった」を分けて調べます。管理画面に相談が出ないだけで、どの段階の障害かは決まりません。

最初に対象アカウント、発生した時間帯、最後に正常な受付を確認した時点を揃えます。テスト時刻と本番の障害時刻が混ざると、関係のない記録を同じ問題として追ってしまいます。

エラー統計が記録される条件を確かめる

公式のWebhookエラー統計ガイドでは、統計の表示は初期設定で無効です。対象チャネルのMessaging API設定でWebhookの利用とエラーの統計情報をオンにすると、Webhookエラーのタブから確認できます。

統計がオフだった期間は、あとからさかのぼって表示されません。時刻はUTC+9が基準です。また、Webhook URLの検証で送る疎通確認用リクエストは、エラー統計に含まれません。検証ボタンで失敗したのに統計が増えないことだけで、記録機能の故障とは判断しないでください。

受信障害の確認順。設定と疎通：対象URL・Webhookを確認。エラー統計：記録条件と原因を確認。受信側の記録：時刻・結果を突き合わせる。実際の受付：HTTP成功と処理完了を分ける。

図：受信障害の確認順。細かな条件と例外は、本文で確認してください。

公式資料の原因区分を起点に、次に確認する場所を整理すると、調査を進めやすくなります。以下の確認先は、自社の構成に合わせるための例です。

エラー件数を、そのまま失われた問い合わせ人数へ置き換えないでください。同じイベントの再送や複数イベントが関わる可能性があります。件数はまず障害の発生状況として扱い、受信したイベントと業務処理の記録で影響範囲を確認します。

受信側が200番台を返したあとで、保存、担当通知、予約の更新が失敗する場合があります。その失敗は、LINEから受信サーバーへ送る段階の統計だけでは追えません。

自社側では、受信を保存できたか、後続処理へ渡せたか、担当画面へ反映できたかを別々に確認します。イベントIDや内部の処理IDで追えるようにし、本文や秘密情報を調査ログへ無条件に残さないようにします。

署名の不一致を調べる場合も、検証を無効化して通すのではなく、未変更の本文を使っているか、対象チャネルの設定を取り違えていないかを確認します。公式の署名検証ガイドを根拠に、受信処理の前提を確かめてください。

URLの検証が通れば、入口への疎通を確認できます。それだけで、お客さんからのメッセージが担当の一覧へ届き、返信できることまで確認したとは言えません。

許可したテスト先で、テスト用メッセージを一通送り、受信記録、担当画面、担当の返信、端末での受信を順に確認します。通常の送信を伴わない範囲では、模擬イベントを使って保存・通知処理も確認できます。模擬結果を実際のLINE受信と混同しないでください。

復旧後に未処理の記録を再開する場合は、同じ業務を繰り返さないことを確認してから進めます。再送設定をオンにするだけで、過去の相談がすべて戻るとは限りません。確認できない相談は不明のまま残し、取得できた範囲で影響を説明します。

技術側で受信を直しても、お客さんへの回答が遅れたままなら相談は終わっていません。復旧した処理と、まだ担当の確認が必要な相談を分け、誰が続きを返すかを決めます。

報告では、発生した時間帯、確認できた原因、再開した処理、未確認の範囲を分けて記載します。「復旧済み」の一語だけで、過去の受信や回答まで完了扱いにしないでください。API全体の流れは、Messaging APIの基礎で確認できます。