LINE Bot署名検証エラーの原因と直し方をExpressで解説

LINE Botの開発を進めて、ローカル環境でメッセージの「オウム返し」が無事に動いた瞬間は本当に嬉しいものですよね。しかし、本番デプロイやセキュリティ対策を意識して署名検証コードを組み込んだ途端、SignatureValidationFailed や 401 Unauthorized が出て、Webhookが通らなくなっていませんか。

「チャネルシークレット（Channel Secret）のコピーペーストを間違えたのかな？」と何度も管理画面を往復したり、環境変数を設定し直したりして、貴重な時間を溶かしてしまうケースは少なくありません。Webhook設定の全体像から確認したい場合は、先にURL・検証・チャネル情報の関係を整理しておくと理解しやすくなります。

結論からお伝えすると、認証エラーの原因はチャネルシークレットの入力ミスとは限りません。Expressアプリケーションで何気なく記述している express.json() の「記述位置」が、署名検証を壊している可能性があります。

この記事では、Expressにおけるミドルウェアの評価順序の罠を構造的に解き明かし、既存のソースコードを最小限の修正で直す方法を解説します。情報時点は2026年5月21日です。SDKのバージョンによってクライアントの書き方が変わる場合があるため、実装前には公式ドキュメントと利用中の @line/bot-sdk のバージョンも確認してください。

この記事の著者：滝沢 誠（たきざわ まこと）
シニア・フルスタックエンジニア / Web開発スクール元講師。過去5年間で30件以上の大規模・中規模LINE Bot開発案件を主導。開発者コミュニティでのトラブルシューティング投稿や、技術書籍の執筆経験に基づき、誰もが一度はつまずきやすい「Expressのミドルウェア順序問題」を、ジュニアエンジニアの目線に降りて分かりやすく言語化・図解するメンター。

---

なぜ動かない？ LINE Botで SignatureValidationFailed が出る最大の原因

LINE Botの開発において、基本機能が完成した後に直面しやすい壁が、SignatureValidationFailed というエラーです。コードは指示通りに書いているはずなのに、なぜ検証で弾かれてしまうのでしょうか。署名検証が失敗する理由をExpressの構造から紐解いていきます。

LINE公式SDKとExpressの「ミドルウェア評価順序」の罠

ExpressというWebサーバーフレームワークは、app.use() や各ルーティングハンドラに指定されたミドルウェアを、ソースコードの上から記述された順番通りに実行します。

多くのExpressアプリケーションでは、リクエストで送られてきたJSONデータをプログラムで扱いやすくするために、サーバーの起動ファイル（app.js や index.js など）の上方に app.use(express.json()) または app.use(bodyParser.json()) を記述します。

しかし、ここに署名検証の落とし穴があります。JSONパース用ミドルウェアがLINE公式SDKの検証ミドルウェア（line.middleware(config)）よりも前で実行されると、ネットワークのストリームから流れてきた「生のリクエストボディ」を、JavaScriptのオブジェクトへ先に変換してしまいます。

LINEの署名検証ロジックは、改ざんやなりすましを防ぐために、パースされる前の生のリクエストボディ（Raw Body）を使って署名を検証します。そのため、先に express.json() によってオブジェクト化されたデータが渡されると、チャネルシークレットが正しくても、自サーバー側で計算した署名とLINEヘッダーの署名が一致しなくなる可能性があります。

Node.jsやTypeScriptで実装している場合は、TypeScript実装の基本もあわせて確認しておくと、@line/bot-sdk、Webhook、環境変数の関係を整理しやすくなります。

署名検証をサボるとどうなる？なりすましリスクの真実

「エラーが消えなくて開発が進まないから、いったん署名検証ミドルウェアをコメントアウトして外してしまおう」と考えるのは、本番運用では避けるべき選択です。

LINE公式ドキュメントでは、本番用として不特定多数のユーザー向けにBotを公開する場合、HTTPリクエストがLINEプラットフォームから送られたことを確認するために、リクエストヘッダーの x-line-signature に含まれる署名を検証する必要があると説明されています。

署名検証を省略してBotを公開すると、Webhook URL（エンドポイント）がLINE以外からのPOSTリクエストも受け取ってしまう状態になります。悪意ある第三者がLINEプラットフォームになりすまして偽のWebhookデータを送信した場合、Botが想定外の処理を実行するリスクがあります。

もちろん、署名検証だけですべての攻撃を防げるわけではありません。レート制限、ログ監視、環境変数管理、エラーハンドリングも必要です。ただし、LINE BotのWebhook受信において、署名検証は最初に外してはいけない基本対策です。

✍️ 専門家の経験からの一言アドバイス
【結論】: どれだけエラーの解消に焦っていても、署名検証を無効化した状態でステージング環境や本番環境へデプロイすることは避けてください。
なぜなら、インターネット上に公開されたエンドポイントは、LINE以外からもアクセス可能になるためです。Expressのミドルウェア順序を正しく直せば、安全性を保ったまま解決できます。

---

【コピペOK】Expressで署名検証を確実に成功させる正しいコード配置

ここからは、SignatureValidationFailed や 401 Unauthorized を解消し、LINEプラットフォームからの通信を安全に受信するための実装方法に移ります。

ベストプラクティスは、すべてのルートに対して一律で express.json() を適用するのではなく、LINEのWebhook受信ルートに対して、LINE公式の署名検証ミドルウェアを先に差し込む設計です。

解決コード：Webhookルートへの「ピンポイント適用」テンプレート

以下は、Node.js（Express）環境における修正後のテンプレートです。@line/bot-sdk はバージョンによってクライアントの書き方が変わるため、ここでは2026年5月時点の公式SDKドキュメントに近い LineBotClient を使った例にしています。チャネルシークレットやアクセストークンの発行・設定に不安がある場合は、先に初期設定の流れを確認してください。

const express = require('express');
const line = require('@line/bot-sdk');

const app = express();

// LINE Messaging APIの設定（環境変数から安全に読み込みます）
const middlewareConfig = {
  channelSecret: process.env.LINE_CHANNEL_SECRET
};

const lineClient = line.LineBotClient.fromChannelAccessToken({
  channelAccessToken: process.env.LINE_CHANNEL_ACCESS_TOKEN
});

// =================================================================
// 1. 【最重要】LINE Webhook用のルートを先に「単独」で記述する
// =================================================================
// express.json() よりも上に書くことで、生のリクエストボディをSDKに渡します
app.post('/webhook', line.middleware(middlewareConfig), (req, res) => {
  // line.middlewareを通過した時点で、署名検証は成功しています。
  // 検証に失敗したリクエストは、SDK側でエラーとして扱われます。

  Promise
    .all(req.body.events.map(handleEvent))
    .then((result) => res.json(result))
    .catch((err) => {
      console.error('Event handling error:', err);
      res.status(500).end();
    });
});

// =================================================================
// 2. LINE以外の通常のAPIやルート用のパースミドルウェアは「後ろ」に記述する
// =================================================================
// /webhook 宛ての通信が先に処理されるため、他のルートでは通常通りJSONを扱えます
app.use(express.json());
app.use(express.urlencoded({ extended: true }));

// その他の一般的なAPIルートの例
app.post('/api/user', (req, res) => {
  // ここでは通常の express.json() が効いているため、req.body.name などを扱えます
  res.json({ status: 'success', data: req.body });
});

// LINEのイベントを処理するハンドラ関数
async function handleEvent(event) {
  if (event.type !== 'message' || event.message.type !== 'text') {
    return null;
  }

  // シンプルなオウム返し処理
  return lineClient.replyMessage({
    replyToken: event.replyToken,
    messages: [
      {
        type: 'text',
        text: event.message.text
      }
    ]
  });
}

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`);
});

上記のポイントは、/webhook ルートを express.json() より前に置くことです。LINE Botの署名検証では、SDKがリクエストボディを検証できる状態で受け取る必要があります。

Express以外にもHonoやCloudflare Workersで構築する方法があります。サーバーレス構成を検討している場合は、Hono構成の記事も確認しておくと、Raw Bodyの扱い方を比較しやすくなります。

• チェック1：全体の app.use(express.json()) より上に /webhook ルートがあるか
  ソースコードファイルを上から見返したとき、リクエストボディを変換する記述（bodyParser 等も含む）よりも上の行に、LINEの app.post('/webhook', ...) が配置されていることを確認してください。
• チェック2：ルート個別の引数としてミドルウェアを設定しているか
  app.use(line.middleware(config)) のようにアプリケーション全体へ適用すると、LINE以外の通常ルートに送られてきた一般のJSONリクエストまでLINEの署名検証対象になる可能性があります。必ず特定のWebhookルートに対して個別に差し込んでください。

---

もっと深く知りたい！ 署名検証（X-Line-Signature）の裏側の仕組み

コピペでエラーが直っただけで満足せず、裏側でどのような暗号化ロジックが走っているのかを知ることで、エンジニアとしての応用力が向上します。ここでは、署名検証の仕組みを整理します。

LINEのサーバーからWebhookサーバーへリクエストが送信される際、HTTPヘッダーの X-Line-Signature に署名テキストが添付されます。この署名は、以下のプロセスで生成・検証されています。

1. LINE側での署名生成:
   LINE側のサーバーは、送信するリクエストのRaw Bodyを対象に、チャネルシークレットを秘密鍵として使い、HMAC-SHA256 でハッシュ値を計算します。さらに結果を Base64 形式のテキストにエンコードしてヘッダーに格納します。
2. サーバー側での検証:
   リクエストを受け取ったExpressサーバー、または公式SDKは、手元にあるチャネルシークレットを使って同じ計算を再現します。そして、自分が計算した署名と、ヘッダーの X-Line-Signature を照合します。

署名検証では、「入力データが少しでも変わると出力されるハッシュ値が大きく変わる」という性質が関係します。入力データが1文字、空白1つ、改行コード1つ異なるだけでも、計算結果は一致しません。

express.json() は、生のテキストデータだったJSONをJavaScriptオブジェクトへ変換します。オブジェクト化されたデータを再度文字列に戻しても、元のRaw Bodyと完全に同じ文字列になるとは限りません。これが、JSONパース後に署名検証が壊れやすい理由です。

---

Dify・サーバーレス・自作検証で署名検証が失敗する原因

実務では、単純なExpress構成だけでなく、ノーコードツール、サーバーレス環境、自作検証ロジックを使う場面もあります。ここでは、派生的なつまずきやすいポイントを整理します。

DifyなどのノーコードツールでRaw Bodyが変わるケース

ノーコードやローコードのプラットフォーム（DifyやMakeなど）をLINEとの間に仲介させる場合、外部ツールがリクエストを受信した時点で、HTTPボディのデータを再パース・整形して次のサーバーへ転送するケースがあります。

この場合、LINE側が送信したRaw Bodyの状態が途中で失われるため、後段のサーバーで署名検証を行っても一致しない可能性があります。対策としては、ツール側の設定で「Raw Payloadをそのまま転送する」オプションを確認するか、署名検証をツールの手前のAPIゲートウェイ等で先に実行する構成を検討してください。

Node.jsの標準モジュールで署名検証を自作するケース

公式SDKの line.middleware を使わずに、Node.js標準の crypto モジュールを用いて署名検証を自作する場合の基本ロジックは以下のようになります。他言語へ移植する際も、Raw Bodyを加工しないことが重要です。

const crypto = require('crypto');

function validateLineSignature(rawBody, channelSecret, signatureHeader) {
  // チャネルシークレットを秘密鍵として、生データ（Raw Body）からHMAC-SHA256ハッシュを計算
  const calculatedSignature = crypto
    .createHmac('sha256', channelSecret)
    .update(rawBody) // 必ず文字列、またはBuffer状態の生データを渡す
    .digest('base64');

  // 計算した署名と、ヘッダーから届いた署名が一致するか照合
  return calculatedSignature === signatureHeader;
}

ngrokを使ったローカル環境で確認するケース

通常は動作します。ngrokは、LINEサーバーから送信されたHTTPリクエストをローカルPCのExpressサーバーへ転送するため、Express側のミドルウェア順序が正しければ、ローカル環境でも署名検証を確認できます。

ただし、エラーが出る場合は以下を順番に確認してください。

• /webhook ルートが express.json() より上にあるか
• LINE Developersに登録したWebhook URLとExpress側のパスが一致しているか
• ngrokの転送先ポートがExpressの起動ポートと一致しているか
• LINE_CHANNEL_SECRET の環境変数名と値が正しいか

---

セキュリティ万全のLINE Botを、自信を持って本番へデプロイしよう

原因不明に思えた SignatureValidationFailed や 401 Unauthorized の正体は、Expressにおける「ミドルウェアの評価順序」と、署名検証に必要なRaw Bodyの扱いにある可能性があります。

最後にもう一度、実務で外してはならない鉄則を振り返りましょう。

• LINEのWebhookルートは、JSONパース処理より前に定義する。
• 共通のJSONパース処理（express.json()）は、Webhookルートの後ろに記述する。
• 署名検証を無効化した状態で本番公開しない。
• SDKのバージョンに応じて、クライアントの書き方を公式情報で確認する。

LINE公式アカウントの標準機能とMessaging APIの違いがまだ曖昧な場合は、自動返信の違いも確認しておくと、Webhookを使うべきケースと管理画面だけで足りるケースを切り分けやすくなります。

ミドルウェアのライフサイクルというWebサーバーフレームワークの基本を理解すれば、場当たり的なコピペではなく、安全なLINE Botを構築できます。セキュリティ要件を満たしたうえで、本番環境へのデプロイを進めてください。

トラブル解決！LINE Bot署名検証に関するよくある質問 (FAQ)

LINE Bot開発でつまずきやすい署名検証エラーについて、原因の切り分けと安全な対処法をQ&A形式でまとめました。