LINE Webhookの署名が一致しないとき｜本文を加工する前に確認する

LINEから届いたWebhookの署名が一致しない場合は、受信した本文をJSONに変換する前の状態で検証しているかを確認します。内容が同じに見えても、空白や改行、文字の扱いが変わると検証に使うデータは異なります。

署名検証を外せば動く、という修正で問い合わせを受け付けるのは避けてください。正しいリクエストだけを処理する条件を保ち、本文を加工する場所、対象チャネル、検証方式を順に調べます。

正しい処理順は、受信・検証・解析・業務処理

LINEの公式資料では、Webhookの署名を検証してからイベントを処理することが案内されています。署名がない、または検証できないリクエストでは、イベントの業務処理を始めません。

受信本文をまずオブジェクトへ変換し、そのオブジェクトからJSONを作り直して検証する実装は、元の本文と一致しない可能性があります。アプリのルートだけでなく、その前に動く共通処理やフレームワークの設定も確認してください。

LINE Webhookを処理する順序。受信した本文と署名を加工せず取得し、署名を検証する。一致した場合だけJSONを解析し、イベントの業務処理へ進む。不一致または署名なしなら業務処理を止める。

図：署名が一致した場合の処理順です。二段目で不一致・署名なしの場合は、三段目以降へ進みません。

署名検証へ渡す本文は、受信したままのデータにします。次のような処理が先に入っていないかを確認します。

公式資料でもこれらの失敗例が示されています。ログに表示したJSONが正しく見えることは、受信時の本文が保たれている証拠にはなりません。受信と検証の境界で何が渡っているかを確認します。

実際のお客さんの本文を、調査用ファイルや公開Issueへ貼り付けないでください。まず個人情報を含まない合成データで、空白・改行・日本語を含めた検証を再現する方法を使います。

署名検証に使う鍵は、対象Messaging APIチャネルのチャネルシークレットです。メッセージ送信で使うチャネルアクセストークンとは役割が異なります。

複数のチャネルや環境がある場合は、どのWebhook URLがどのチャネルへ設定され、サーバー側がどの設定を参照しているかを確認します。受信本文に書かれた値を根拠に、未検証のまま設定を変更する設計にはしません。

秘密値そのものをログへ出す必要はありません。環境名や設定の参照先、変更時刻など、値を公開しない方法で対応関係を確認します。昨日までは動いていた場合は、本文処理の変更に加えて、同じチャネルの設定変更があったかも調べます。

シークレットを再発行すると以前の値が無効になります。原因を調べる最初の操作として、むやみに再発行しないでください。必要な場合も、影響を受けるサービスと切り替え手順を先に確認します。

公式の方式は、受信本文とチャネルシークレットを使ったHMAC-SHA256で署名を計算し、Base64の値をヘッダーの署名と照合するものです。別のアルゴリズムや、本文の別表現で計算していないかを確認します。

自作の短い比較コードだけで済ませず、利用している言語の公式資料で案内されたSDKと実装に照らしてください。署名ヘッダーがない場合、不正な値、改変した本文を、検証失敗として扱えることも必要です。

署名が正しくても、イベントの重複処理を防げるとは限りません。再送を扱う設計はWebhook再送と重複防止を参照してください。

合成データで検証が通ったら、承認されたテスト環境・テスト先で、正しいWebhookが受信され、イベントの業務処理まで進むことを確かめます。同時に、本文を変更したリクエストと署名なしのリクエストが、その処理へ進まないことも確認します。

コンソールの接続確認が成功したことだけを、実際の問い合わせ対応の成功にしないでください。Webhookエラーの切り分けと合わせ、受信、検証、イベント処理、返信のどこまで確認できたかを残します。

正しい問い合わせを取りこぼさず、偽のリクエストを受け付けないために、まずは「JSONを読む前の本文で検証しているか」を確認してください。その順序を保ってから、チャネルの対応と検証方式を点検します。

仕様確認：2026年10月7日。参照：Webhookの署名を検証する。本文の確認手順は、秘密値や実際の問い合わせ本文を保存することを求めるものではありません。