LINEのWebhookが届かないときの対処法｜接続確認と再送設定で受信障害を切り分ける
LINE公式アカウントを予約システムやCRM、チャットボットとつないだのに、友だちから届いたメッセージが自社のシステムに記録されない。昨日まで返っていた自動応答が急に止まった。管理画面にはエラーらしき表示がなく、制作会社に聞くと「サーバーは動いています」と返ってくる。Messaging APIで連携していると、こうした受信トラブルはどこから手を付ければよいか分からないまま時間だけが過ぎがちです。
Webhookの不具合は、「そもそも届かない」「届くが処理できない」「再送で重複する」の3つの状態に分けて考えると、原因の場所と相談先が見えてきます。確認する順番は、Webhookの利用設定、接続先の応答、受け取った後の処理、再送設定の4段階です。この順に見ていけば、SNS運用側の設定の問題なのか、連携システム側の問題なのかを切り分けられます。
この記事では、配信内容やCRM活用、予約導線の設計ではなく、LINEから自社システムにイベントが届かない障害の切り分けに絞って解説します。仕様はLINE Developersの公式ドキュメントで2026年11月時点に確認できる範囲で書き、エンジニアではない運用担当者でも画面で確かめられる項目と、開発側に伝えるべき情報を分けて整理しました。
この記事の要点
- Webhookの不具合は「そもそも届かない」「届くが処理できない」「再送で重複する」の3状態に分けると、原因と相談先が決まる
- 最初に［Webhookの利用］のオン、Webhook URLの中身、［検証］の結果の3点を確認する
- 接続先は2秒以内を目安にステータスコード200を返し、重い処理は非同期に回すのが公式の推奨
- 再送は初期設定で無効で、有効にしても確実な配信は保証されないため、webhookEventIdで重複を検出する前提で使う
- LINEヤフーは個別のエラー調査を行わないため、エラーの統計情報を記録して開発・運用の担当へ渡す
LINEのWebhookが届かない原因は3つの状態に分けて考える
LINEのWebhookが届かないという症状は、「そもそも届かない」「届くが処理できない」「再送で重複する」の3つの状態のどれかに当てはめると、確認する画面と相談先が決まります。症状だけを見るとどれも「連携が動かない」に見えるため、最初に状態を見極めることが切り分けの近道です。
Webhookとは、友だち追加やメッセージの送信といったイベントが起きたときに、LINEプラットフォームがあらかじめ登録されたURLへHTTPSのPOSTリクエストで通知を送る仕組みです。LINE DevelopersのMessaging APIリファレンスでは、通知を受け取る側をボットサーバー、送信先のURLをWebhook URLと呼んでいます。予約システムやCRM、配信ツールがLINEのメッセージを受け取れるのも、この通知があるからです。
そのため、Webhookの受信が止まると、LINEのトーク画面ではメッセージを送れているように見えても、連携先のシステムには何も届いていない状態になります。トーク画面だけを見て「LINEは正常」と判断せず、連携先のシステム側に受信の記録が残っているかを最初に確かめることが大切です。
3つの状態で変わる確認先
3つの状態は、確認すべき画面も相談先も異なります。「そもそも届かない」は、LINE側の設定か接続先までの通信に問題があり、ボットサーバーには受信の記録自体が残りません。「届くが処理できない」は、受信の記録はあるものの、応答に時間がかかりすぎたり処理の途中で失敗したりして、返信や登録まで進まない状態です。
「再送で重複する」は、Webhookの再送を有効にしている場合に起こりうる状態で、同じ問い合わせが二重に登録されたり、メッセージの前後関係が入れ替わったりします。下の表は、状態ごとの症状と最初に見る場所を整理したものです。自社の症状に近い行から確認を始めてください。
| 状態 | よくある症状 | まず見る場所 | 主な相談先 |
|---|---|---|---|
| そもそも届かない | 接続先に受信の記録がない／連携ツールに何も反映されない | ［Webhookの利用］、Webhook URL、［検証］、［Webhookエラー］タブ | LINE側の設定は管理者、接続先は開発・制作会社 |
| 届くが処理できない | 受信の記録はあるが返信や登録が行われない | 応答までの時間、署名検証、処理のログ | 開発・制作会社、連携ツールの提供会社 |
| 再送で重複する | 同じ内容が二重に登録される／順番が入れ替わる | webhookEventId・timestampの扱い | 開発・制作会社 |
担当の範囲を先に決めておく
切り分けの前に、誰がどの画面を見られるかを確認しておきましょう。Webhookの設定はLINE DevelopersコンソールとLINE Official Account Managerにあり、権限を持つ人しか操作できません。一方、ボットサーバーのログや処理の中身は、開発会社や連携ツールの提供会社でなければ確認できないことがほとんどです。
運用担当、チャネルの管理者、接続先の保守担当が別々だと、障害のたびに「どちらの問題か」の確認だけで時間を使ってしまいます。LINE側の設定は運用側、接続先の応答と処理は開発側というように範囲を決めておくと、状態を見極めた時点ですぐに相談先へ連絡できます。
なお、この記事は受信障害の技術的な切り分けに絞っています。友だちを公式アカウントの外に出さずに予約や会員登録へ案内する導線の設計は、以下の記事で解説しています。
最初に確認するのはWebhookの利用設定とWebhook URL
最初に確認すべきは、［Webhookの利用］がオンになっているかと、［Webhook URL］が正しい接続先を指しているかの2点です。どちらもLINE Developersコンソールでチャネルを開き、［Messaging API設定］タブの［Webhook設定］で確認できます。ここに問題があれば、接続先のサーバーがどれだけ正常でもWebhookは送られません。
［Webhookの利用］は2つの管理画面から切り替わる
見落としやすいのが、［Webhookの利用］のオンとオフが2つの管理画面から切り替えられる点です。LINE Developersの法人ユーザー向け開発ガイドラインには、LINE Developersコンソールの設定と、LINE Official Account Managerの［設定］＞［応答設定］＞［Webhook］の設定が同期していると書かれています。
つまり、エンジニアが何も触っていなくても、公式アカウントの運用担当が応答設定を見直した際にWebhookをオフにすれば、その時点で連携先への通知は止まります。受信が止まった日時と、応答設定や応答メッセージを変更した日時が重なっていないかを、運用チームの中で最初に確認してください。
同じガイドラインでは、Webhookをオフにしたうえで応答メッセージとあいさつメッセージも使わない組み合わせは、友だちにメッセージが届かなくなるため認められていません。応答メッセージを止めたいときに、Webhookまで一緒にオフにしていないかも確かめましょう。
Webhook URLは1つのチャネルに1つだけ
Webhook URLは、LINE Developersのボットを作成するのページにあるとおり、1つのチャネルに1つのエンドポイントしか設定できません。新しく配信ツールやチャットボットを導入した際に、ツールの案内に従ってURLを貼り替えると、それまで使っていた予約システムやCRMへの通知は止まります。
確認するときは、設定欄に入っているURLを丸ごとコピーし、どのシステムのものかを開発担当や連携ツールの提供会社に照合してもらいます。あわせて、URLが「https://」で始まっているかも見てください。Webhook URLにはHTTPSと信頼された認証局が発行したSSL/TLS証明書が必要で、自己署名証明書は使えないと公式ドキュメントに明記されています。
設定を変える前に控えておくこと
- 変更前の画面：［Webhook設定］の画面を保存し、元のURLとオン・オフの状態を残す
- 変更した人と日時：誰がいつ触ったかを社内のチャットなどに書き残す
- 連携中のツール：Webhook URLを使うツールがほかにないかを洗い出す
- 権限の範囲：チャネルの設定を変更できる人が誰かを確認する
Webhookの設定は、チャネルを操作できる権限を持つ人であれば変更できてしまいます。退職や外部への委託で権限の持ち主が入れ替わると変更の経緯を追えなくなるため、権限の管理ルールを日頃から決めておくことが受信障害の予防にもつながります。その考え方は以下の記事で解説しています。
接続先の応答は［検証］とエラーの統計情報で確かめる
接続先が応答しているかはWebhook URLの［検証］ボタンでその場で確かめられ、実際のイベントが失敗した理由は［エラーの統計情報］をオンにすると［Webhookエラー］タブで確認できます。前者は「今つながるか」、後者は「実際の送信で何が起きたか」を見る道具なので、両方を組み合わせて使います。
［検証］の成功は接続の確認にとどまる
［検証］ボタンを押すと、LINEプラットフォームはWebhookイベントを含まないPOSTリクエストを接続先に送ります。LINE DevelopersのWebhook URLを検証するのページでは、この疎通確認のリクエストにもステータスコード200を返すよう求めています。「成功」と表示されれば、少なくともLINEから接続先まで通信が届き、正しい応答が返っている状態です。
ただし、検証の成功は、実際のメッセージを正しく処理できることまでは意味しません。検証のリクエストにはイベントが入っていないため、メッセージの中身を読み取る処理は通っていない可能性があります。また、検証で送られたリクエストは成功・失敗にかかわらずエラーの統計情報に含まれないため、検証が成功しても実際のイベントでは失敗していることがある点に注意してください。
検証結果の原因の値を読む
検証は、開発担当がAPIから実行することもできます。Messaging APIリファレンスによると、その場合は結果の原因が次の5種類で返り、応答を受け取れなかったときのステータスコードは0か負の数になります。結果を共有してもらう際は、この値も一緒に聞きましょう。
| 原因の値 | 意味 | 次に確認すること |
|---|---|---|
| OK | 送信に成功した | 実際のイベントでの失敗をエラーの統計情報で確認 |
| COULD_NOT_CONNECT | 接続先に接続できなかった | URLの表記、ドメイン、SSL/TLS証明書 |
| REQUEST_TIMEOUT | リクエストがタイムアウトした | 接続先が応答するまでの時間 |
| ERROR_STATUS_CODE | エラーのステータスコードが返された | 接続先のログと返したステータスコード |
| UNCLASSIFIED | 分類できない不明なエラー | 発生時刻を控えて開発担当へ共有 |
原因の値は開発担当への説明にそのまま使えます。COULD_NOT_CONNECTなら接続先にたどり着いていないため、URLや証明書を疑います。ERROR_STATUS_CODEなら接続先までは届いているので、なぜ200以外を返したのかをログで調べる段階です。
エラーの統計情報は初期設定でオフになっている
実際のイベントが失敗した理由を知るには、［Messaging API設定］タブで［エラーの統計情報］をオンにします。LINE DevelopersのWebhookのエラーの原因と統計情報を確認するによると、この機能は初期設定では無効で、エラーはオンにしていた期間しか集計されず、オフだった期間のエラーはさかのぼって表示されません。障害が起きてからオンにしても過去の分は見られないため、連携を始めた時点でオンにしておくのが基本です。
［Webhookエラー］タブには、エラーの日付、最初と最後に検知した時刻、原因、詳細、同じ種類のエラーが60秒間に発生した件数が表示されます。時刻はUTC+9が基準で、TSVファイルとしてダウンロードもできます。原因の欄は次の4種類で、2026年11月時点の公式ドキュメントでは、request_timeoutは2秒以内に応答が返らなかった場合などと説明されています。
| 原因 | 公式の説明（要約） | 見るべきポイント |
|---|---|---|
| could_not_connect | 接続先に正常に接続できなかった | 詳細の欄（Unknown host、TLS handshake failureなど）でURLや証明書を確認 |
| request_timeout | 2秒以内に応答が返らなかった、または送信が途中で失敗した | 接続先では受信できている可能性もある |
| error_status_code | 200番台以外のステータスコードが返された | 詳細の欄のステータスコードと接続先のログ |
| unclassified | 上記のいずれにも分類できない | 発生時刻を控えて開発担当へ共有 |
エラー通知のメールが届くとは限らない
- エラー通知：接続先が応答しない、または200番台以外を返したときのメール通知は、所定の申請をした法人ユーザー向けのオプション機能
- 通知の宛先：チャネル基本設定のメールアドレスと、Admin権限を持つユーザー
- 個別の調査：LINEヤフーはエラーに関する個別の調査や確認を行っていないと公式ドキュメントに明記されている
- 日頃の備え：メールを待たずに［Webhookエラー］タブを定期的に確認する担当を決めておく
通知の条件はLINE Developersのエラー通知のページで確認できます。メールが来ないことは障害がない証拠にならないため、［Webhookエラー］タブを見る習慣のほうが確実です。見る担当を社内に置けない場合は、LINE公式アカウントの運用体制について相談することもできます。
届くが処理できないときは2秒以内の応答と処理の作りを見直す
Webhookは届いているのに返信や登録が行われない場合は、接続先が応答を返すまでの時間と、受け取った後の処理の作りを見直します。LINEの公式資料は、2秒以内を目安に200を返し、時間のかかる処理は非同期で進める構成を推奨しています。
2秒以内を目安に200を返す
法人ユーザー向け開発ガイドラインには、ボットサーバーがWebhookイベントを受信してから2秒以内を目安にHTTPステータスコード200を返すよう書かれています。エラーの統計情報でも、2秒以内に応答が返らないとrequest_timeoutとして記録されます。この秒数は2026年11月時点の公式資料の記載で、ネット上には別の秒数を書いた解説もあるため、判断には公式の記載を使ってください。
応答が遅れやすいのは、受け取ったその場でCRMへの登録や外部システムへの問い合わせ、AIによる回答の生成を済ませてから200を返す作りです。問い合わせが集中する時間帯だけ失敗するといった症状は、処理時間が目安を超えている可能性を示します。なお、request_timeoutでも接続先では受信できている場合があるため、記録だけで「届いていない」と決めつけないことも大切です。
受け取りと処理を分ける非同期処理
LINE Developersのメッセージ（Webhook）を受信するのページでは、Webhookイベントを非同期で処理することが推奨されています。先に届いたリクエストの処理が終わるまで後続のリクエストが待たされるのを防ぐためで、受け取ったリクエストの署名を確かめたらすぐに200を返し、登録や返信は別の仕組みで順に処理するという考え方です。
非同期にするときは、イベントの前後関係を保てるように作ることも開発ガイドラインで求められています。1つのWebhookに複数のイベントや別々のユーザーのイベントがまとめて含まれることもあり、「1回の通知に1人分」という前提の作りでは取りこぼしが起こります。開発会社には、非同期処理と複数イベントへの対応ができているかを確認しておきましょう。
署名検証の失敗も処理できない原因になる
接続先は、受け取ったリクエストが本当にLINEプラットフォームから送られたものかを、リクエストヘッダーの署名で確かめる必要があります。LINE DevelopersのWebhookの署名を検証するによると、送信元であるLINEプラットフォームのIPアドレスは開示されておらず、安全性は署名の検証で担保する設計になっています。
署名の検証にはチャネルシークレットを使うため、この値が変わると、それまで動いていた接続先で署名の検証が急に失敗するようになります。同じページでは、検証に失敗する原因として次のような例が挙げられています。
署名検証が失敗する主な原因（公式ドキュメントの例から抜粋）
- チャネルシークレットの再発行：同じチャネルのAdmin権限を持つ別の人が再発行し、古い値が無効になっている
- 別チャネルの値：対象とは別のチャネルのチャネルシークレットを使っている
- 途中での変更：プロキシやロードバランサーなど、接続先の手前でリクエストが変更されている
- 検証前の変換：署名を検証する前にリクエストの本文を解析したり整形したりしている
チャネルシークレットの再発行は、管理画面を触った人に悪気がなくても起こります。公式ドキュメントも、再発行の前に既存サービスへの影響を十分に調べるよう注意を促しています。権限を持つ人が複数いる場合は、再発行の前に開発担当へ必ず相談するルールを決めておきましょう。
再送設定は取りこぼしを減らす機能で復旧を保証しない
Webhookの再送は、接続先が200番台を返さなかったイベントを一定期間内に送り直す機能で、一時的な障害による取りこぼしを減らせますが、有効にすれば必ず復旧するものではありません。重複や順序の入れ替わりへの備えとセットで使う必要があります。
再送が行われる条件と限界
再送は初期設定では無効で、［Messaging API設定］タブで［Webhookの利用］をオンにしたうえで［Webhookの再送］をオンにします。有効にするときには注意事項が表示されるため、内容を読んでから操作します。再送されるのは、再送が有効になっていて、かつ接続先が200番台のステータスコードを返さなかった場合です。
メッセージ（Webhook）を受信するのページには、再送の回数と間隔は開示されておらず予告なく変わる可能性があること、再送は確実に行われることを保証するものではないことが書かれています。再送が急増してLINEプラットフォームに影響すると判断された場合に再送設定が強制的に無効になる可能性や、接続先が長期間受信に失敗するとWebhookの送信自体が停止される可能性も明記されています。再送は接続先を直すまでのつなぎではなく、短い障害の取りこぼしを減らす補助と位置づけるのが妥当です。
有効にする前に重複と順序の扱いを決める
再送を有効にするなら、同じイベントが複数回届く前提の作りが必要です。公式ドキュメントは、ネットワーク経路の問題などで同じイベントが重複して届く可能性があるとして、webhookEventIdで重複を検出するよう案内しています。再送で受信の順番が発生の順番と食い違う可能性もあるため、前後関係はtimestampで確認するよう求めています。
再送されたイベントは、deliveryContext.isRedeliveryの値を除いて元のイベントと同じ内容です。下の表のとおり、webhookEventIdは再送でも変わらないため、処理済みのIDを記録しておけば二重登録を防げます。重複を検出する仕組みがないまま再送をオンにすると、問い合わせや予約が二重に登録されるおそれがあるため、オンにする前に開発担当へ対応状況を確認してください。
| 項目 | 再送されたイベントでの扱い | 運用上の意味 |
|---|---|---|
| webhookEventId | 元のイベントと同じ（ULID形式の一意のID） | 処理済みのIDを記録すれば重複を検出できる |
| deliveryContext.isRedelivery | 再送ならtrue、初回はfalse | 再送分かどうかを見分けられる |
| timestamp | 再送時刻ではなくイベントの発生時刻 | 受信の順番が前後しても並べ直せる |
| 応答トークン | 元のイベントと同じ。特定の場合を除き使用できる | 再送分では返信に使えない場合がある前提で設計する |
検証用チャネルで正常応答とエラー応答を見比べる
原因の見当がついたら、本番とは別の検証用チャネルで、正常に応答する場合とエラーを返す場合の画面の出方を見比べておくと、本番で起きている状態を判断しやすくなります。法人ユーザー向け開発ガイドラインも、Webhookの設定を有効にする際は検証用のアカウントなどを使い、テスト環境で動作を確かめてから本番に適用するよう求めています。
正常応答とエラー応答を比べるチェック手順
比較の準備は開発担当に依頼します。2026年11月時点では、Messaging APIのチャネルはLINE Developersコンソールから直接作成できず、LINE公式アカウント側でMessaging APIを有効にして作る仕組みです。検証用のLINE公式アカウントでチャネルを用意し、Webhook URLには本番とは別のテスト用の接続先を設定します。そのうえで、接続先の返し方を「すぐに200を返す」「500などのエラーを返す」「2秒を超えてから返す」「存在しないホスト名にする」のように切り替え、［検証］の結果と［Webhookエラー］タブの表示、接続先のログを並べて記録していきます。
下の表は、公式ドキュメントの記載から想定される出方を整理したものです。実際の表示は接続先の構成や設定によって変わるため、自社の環境で確かめた結果を優先してください。本番で起きた表示がこの表のどの行に近いかで状態を読み解けるようになることが、比較の目的です。
| 接続先の返し方 | 公式ドキュメントから想定される出方 | 本番で同じ表示が出たときの見方 |
|---|---|---|
| すぐに200を返す | ［検証］は成功し、エラーとしては記録されない | 受信は正常。処理の結果を接続先のログで確認 |
| 500などのエラーを返す | error_status_codeとして記録され、詳細にステータスコードが入る | 接続先の処理が失敗している |
| 2秒を超えてから返す | request_timeoutとして記録される | 処理時間の見直しと非同期化を検討 |
| 存在しないホスト名 | could_not_connectとして記録され、詳細にUnknown hostなどが入る | URLやドメインの設定を確認 |
| 再送を有効にしてエラーを返す | isRedeliveryがtrueのイベントが届く場合がある | 重複の検出が働くかを確認 |
エラー応答は本番のチャネルで試さない
エラーを返す設定を本番のチャネルで試すと、実際の友だちから届いたメッセージが処理されずに失われたり、再送によって連携先に重複したデータが残ったりします。エラー応答の確認は必ず検証用のチャネルで行うことが、切り分けの作業で新たな障害を生まないための前提です。
また、検証用と本番用で接続先やチャネルシークレットを使い回すと、どちらのチャネルから届いたイベントかを判別しにくくなります。接続先を分け、どの設定がどのチャネルのものかを開発担当と共有しておくと、比較の結果を本番の判断に生かしやすくなります。
検証環境の用意や障害時の一次切り分けまで外部に任せる場合は、どこまでを依頼範囲に含めるかで費用が変わります。SNS運用代行の料金体系と費用の内訳は、以下の記事で整理しています。
社内で対応しきれないときは状況を記録して相談先を決める
LINEヤフーはエラーに関する個別の調査や確認を行っていないため、原因の特定は自社か、接続先を開発・保守する会社が担うことになります。相談する前に状況を記録しておくと、相手が同じ情報から切り分けを始められ、解決までの時間を短くできます。
相談先を決める判断軸
相談先は、3つの状態のどれに当たるかで決めます。［Webhookの利用］やWebhook URLの設定に問題があればLINE公式アカウントとチャネルの管理者、接続できない・エラーを返している・処理が遅いといった接続先の問題であればシステムを開発した会社、配信ツールやチャットボットを経由している場合はそのツールの提供会社が窓口になります。
一方で、社内にチャネルの管理者権限を持つ人がいない、Webhook URLを誰がいつ変えたか追えない、運用と連携の両方を見直したいといった状況では、個別の窓口への相談だけでは解決しにくくなります。運用と連携の設定をまとめて把握できる外部パートナーに任せることも選択肢です。運用体制ごと見直したい場合は、SNS運用の現状を無料で相談することもできます。
相談するときに伝える情報
- 発生日時：受信が止まった、または重複した日時（［Webhookエラー］タブはUTC+9で表示）
- 状態：そもそも届かない、届くが処理できない、再送で重複するのどれに近いか
- 画面の記録：［検証］の結果と、［Webhookエラー］タブの原因・詳細
- 直前の変更：応答設定、Webhook URL、チャネルシークレット、追加したツールの有無
- 関連する設定：［Webhookの再送］と［エラーの統計情報］のオン・オフ
これらの情報がそろっていれば、相談を受けた側はLINE側の設定と接続先のどちらから調べるべきかをすぐに判断できます。症状を「LINEが動かない」とだけ伝えると確認のやり取りが何往復も続きやすくなるため、記録する項目を社内で共有しておくと安心です。
LINEを含めたSNS運用を外部に任せる場合は、連携システムとの役割分担まで相談できる会社かどうかを見極めることが大切です。運用会社の選び方と比較のポイントは、以下の記事を参考にしてください。
まとめ：Webhookの受信障害は状態を見極めてから設定と応答を確かめる
LINEのWebhookが届かないときは、まず症状を3つの状態に当てはめ、LINE側の設定、接続先の応答、受け取った後の処理、再送設定の順に確認します。仕様は公式ドキュメントで確かめ、確認した結果を記録して相談先に渡すことが、復旧を早める近道です。
- 状態を先に見極める。「そもそも届かない」「届くが処理できない」「再送で重複する」のどれかを決めてから、見る画面と相談先を選ぶ
- 設定と応答を公式の基準で確かめる。［Webhookの利用］とWebhook URL、［検証］の結果、エラーの統計情報を確認し、接続先は2秒以内を目安に200を返す
- 再送は重複対策とセットで使う。再送は確実な配信を保証しないため、webhookEventIdとtimestampで重複と順序を扱える作りにしてから有効にする
まずは無料でSNSアカウント診断を
LINE公式アカウントの受信障害は運用側の設定と連携システムの両方にまたがるため、社内だけでは原因を突き止めにくいことがあります。ハーマンドットの無料診断では、LINE公式アカウントを含むSNSアカウントの運用状況をうかがい、応答設定や運用体制で見直すべき点を整理します。連携システムの不具合が疑われる場合も、運用側で確認すべき項目と開発側へ伝える情報を一緒に整理できます。
「Webhookが止まったときに誰が何を見るか決まっていない」「運用担当と開発会社の役割分担を見直したい」といったご相談も歓迎です。初回相談は完全無料・所要時間30分・オンライン対応可能です。まずはお気軽にお申し込みください。