LINEのWebhook URL設定手順｜応答を受け取る連携

LINEのWebhook URLを登録したのに、メッセージを送ってもサーバー側にイベントが届かない。検証（Verify）ボタンを押すと赤いエラーが出る。そんな状態で手が止まっていませんか。

この記事では、LINE公式アカウントのWebhook URLを設定して、ユーザーの応答（メッセージ送信や友だち追加）を自社サーバーやツールで受け取れるようにするまでの手順を、順番に解説します。LINE Messaging APIを使ってチャットボットや自動応答、CRM連携を組みたい担当者や、外注先とのやり取りで用語だけでも押さえておきたい方に向けた内容です。読み終わる頃には、どこでつまずいているかを自分で切り分けられて、次に何を直せばいいかが分かる状態を目指します。

なお、Messaging APIそのものでできることや無料枠の考え方はLINE Messaging APIでできることと料金・トークン発行の進め方で解説しています。まだAPIの全体像がつかめていない方は、先にそちらを読むと理解が早くなります。

Contents / 目次

1. 結論。Webhook設定は5つの工程で完了する
2. 具体的なやり方。工程ごとの操作手順
3. 設定できると何が変わるか。応答連携でできること
4. よくある失敗と回避法。検証でつまずく原因を切り分ける
5. 使う側の落とし穴。URLは1本しかない、という現場の現実
6. AI応答を組み込むときの、任せる範囲の見極め方

結論。Webhook設定は5つの工程で完了する

LINEのWebhook URL設定は、大きく5つの工程に分けられます。この順番どおりに進めれば、応答を受け取る連携は動きます。

まず全体像を押さえましょう。ゴールは「ユーザーの操作を、あなたが用意した受け皿（サーバーやツール）で受け取れる状態」を作ることです。ここでいうWebhookとは、ユーザーがメッセージを送ったり友だち追加したりしたときに、LINEのプラットフォームからあなたのサーバーへ自動で通知が飛ぶ仕組みのことです。かんたんに言うと、LINE側の「動きがありました」というお知らせを、指定した住所（URL）に届けてもらう設定です。

その住所を登録し、正しく受け取れるかを確認するまでが今回の作業になります。全体の流れを先に一覧で見ておきましょう。

工程	やること	作業する場所
1	Messaging APIを有効化する	LINE公式アカウントマネージャー
2	チャネルを作り、アクセストークンとチャネルシークレットを取得する	LINE Developersコンソール
3	受け皿（エンドポイント）を用意し、そのURLを登録する	自社サーバー／ノーコードツール＋Developersコンソール
4	検証（Verify）で通信できるか確認する	LINE Developersコンソール
5	Webhookの利用と応答設定をオンにする	Developersコンソール／公式アカウントマネージャー

ここで一つ大事な前提があります。Webhookで応答を「受け取る」だけなら、必ずしも自分でプログラムを書く必要はありません。ZapierやMakeのようなノーコードツール、あるいはLINE公式アカウントの拡張ツールを使えば、受け皿のURLは自動で用意してくれます。

まず決めること。自分でサーバーを立ててコードで処理するのか、ノーコードツールに受け皿を任せるのか。ここを最初に決めると、工程3で用意するURLの中身が変わります。エンジニアがいない現場なら、まずはノーコードツールで受け皿を作るのが現実的です。

最近のLINE公式アカウントでは、運用の前段でビジネスマネージャーとの連携を求められる場面が増えています。Webhook設定の前でつまずかないためにも、この接続まわりの準備はLINEビジネスマネージャー必須化の接続手順で確認しておくと安心です。

具体的なやり方。工程ごとの操作手順

ここからは、5つの工程を一つずつ具体的に見ていきます。操作するのは主にLINE公式アカウントマネージャーとLINE Developersコンソールの2画面です。ボタン名やメニューの位置は更新で変わることがありますが、以下では実際のクリック順と、変わりにくい設定項目の名前を手がかりに、その場で再現できるように示します。

ステップ1。Messaging APIを有効化する

最初にやることは、LINE公式アカウントでMessaging APIを使える状態にすることです。LINE公式アカウントマネージャーにログインし、右上の［設定］→左メニューの［Messaging API］と進み、［Messaging APIを利用する］を選びます。案内に沿ってプロバイダー（開発者情報のまとまり）を選択または新規作成すると、有効化が完了します。メニュー名や位置は更新で変わることがあるため、最新の手順はLINE公式のMessaging APIドキュメントで確認してください。

この作業をすると、あなたのLINE公式アカウントが「外部システムと連携できるアカウント」に切り替わります。ここが済んでいないと、次のチャネル作成に進めません。

ステップ2。チャネルを作り、鍵となる情報を取得する

次に、LINE Developersコンソールでチャネルを作成します。チャネルとは、あなたのアカウントと外部システムをつなぐための「連携窓口」のことだと考えてください。

ここで取得しておく情報が2つあります。連携を安全に動かすための鍵になるので、必ず控えておきましょう。

• チャネルアクセストークン：あなたのサーバーからLINEに向けてメッセージを送り返すときに使う認証情報。「こちらは正規の送信者です」と証明する通行証のようなもの
• チャネルシークレット：届いた通知が本当にLINEから来たものかを確認する（署名検証する）ときに使う情報。後述する改ざんチェックの要になる

アクセストークンとチャネルシークレットは、パスワードと同じ機密情報です。コードや設定ファイルに直接書き込むのは避け、環境変数として管理してください。GitHubなどに誤ってアップロードすると、アカウントを乗っ取られる原因になります。

ステップ3。受け皿を用意してURLを登録する

ここが今回の山場です。ユーザーの操作を受け取る「受け皿（エンドポイント）」を用意し、そのURLを登録します。Developersコンソールで対象チャネルを開き、［Messaging API設定］タブの［Webhook設定］にある［Webhook URL］の［編集］からURLを入力して［更新］します。

受け皿の用意のしかたは、選んだ方式によって変わります。

• ノーコードツールを使う場合：ZapierやMakeなどの連携ツールでは、受信用のURL（Webhook）を発行できるものが多い。発行できる場合はそのURLをコピーしてWebhook URL欄に貼る。対応の有無や手順はツール・プランで変わるため、各ツールの公式ドキュメントで確認する
• 自社サーバーで処理する場合：PythonやNode.jsなどで、HTTP POSTを受け取るエンドポイントを作り、公開サーバーに配置する。そのURLを登録する
• 開発中にテストしたい場合：ローカル環境で作ったサーバーはそのままでは外部から見えないため、ngrokのようなトンネルツールで一時的なHTTPSのURLを発行して登録する

登録するURLには絶対条件が一つあります。必ずHTTPS（暗号化された通信）である必要があります。「http://」で始まるURLは登録できません。ここを見落として検証に失敗する人がとても多いです。

自分でコードを書く場合、受け皿が最低限やるべきことは決まっています。LINEから届いたPOSTリクエストに対して、すぐにHTTPステータス200を返すことです。そのため、時間のかかる処理は200を返したあとに非同期で行うのが安全です。

ステップ4。検証（Verify）で通信を確認する

URLを登録したら、同じ［Webhook設定］にある検証（Verify）ボタンを押して通信テストをします。成功すれば、LINEからあなたの受け皿まで、通知の道が正しくつながっている証拠です。

検証は、あなたのサーバーが通知を正しく受け取って応答を返せるかを確認するためのものです。ここで失敗する場合の原因と直し方は次のH2でまとめて解説します。まずは成功を確認できればこの工程は完了です。

ステップ5。Webhookの利用と応答設定をオンにする

最後に、2か所のスイッチをオンにします。ここを忘れると、検証は通ったのに実際の通知が届かない、という状態になります。

• Webhookの利用：Developersコンソールの［Messaging API設定］→［Webhook設定］で「Webhookの利用」をオンにする。これがオフだと、そもそも通知が送られない
• 応答設定：公式アカウントマネージャーの［設定］→［応答設定］で、応答モードを「Bot」にする（または「チャット」と併用する場合は詳細設定で応答方法を調整する）。自動応答メッセージと役割がぶつからないよう整える

応答モードの切り替えは、有人チャットと自動応答（Bot）のどちらを優先するかで設定が変わります。ここは混乱しやすいポイントなので、LINE公式の応答モード切り替え設定もあわせて確認してください。

署名検証まで自分で組む場合は、次のコードが出発点になります。Node.jsでよく使われるHMAC-SHA256による照合の例です。届いた通知が本当にLINEから来たものかを確かめる部分です。

// 前提：Node.js。expressで生のリクエストボディを受け取れる状態にしておく
// チャネルシークレットは環境変数から読む（コードに直書きしない）
const crypto = require('crypto');
const channelSecret = process.env.LINE_CHANNEL_SECRET;

// LINEから届いた署名(x-line-signature ヘッダー)と照合する関数
function verifySignature(rawBody, signature) {
  const hash = crypto
    .createHmac('SHA256', channelSecret)
    .update(rawBody)   // ［必ず「生のボディ」を渡す。JSON変換後の文字列だと不一致になる］
    .digest('base64');
  return hash === signature;
}

// 使い方の例
// const ok = verifySignature(req.rawBody, req.headers['x-line-signature']);
// if (!ok) return res.status(401).send('invalid signature');
// res.status(200).send('OK'); // ［先に200を返し、重い処理は後ろで非同期に行う］

公式のリファレンスにも受信データの形式が詳しく載っています。LINE Developers公式「メッセージ（Webhook）を受信する」で、届くデータの中身を確認しながら組むと確実です。項目ごとの仕様はMessaging APIリファレンスにまとまっています。

設定できると何が変わるか。応答連携でできること

Webhookで応答を受け取れるようになると、LINEが「配信するだけの道具」から「顧客と双方向でやり取りする窓口」に変わります。ここが一番の変化です。

具体的にできるようになることを整理します。どれも「ユーザーの操作を受け取れる」ことが土台になっています。

• 友だち追加時の自動処理：追加された瞬間に顧客情報をCRMへ自動登録し、あいさつや初回クーポンを出し分ける
• 問い合わせの自動応答：よくある質問はチャットボットが即答し、営業時間外でも取りこぼさない
• 行動データの蓄積：どのボタンを押したか、どの経路で友だちになったかを記録し、次の配信の精度を上げる
• 予約・注文の受付：LINE上で予約や注文を受け、外部の予約システムやPOSと連携する

運用のポイントは、「一斉配信」だけに頼らず「一人ひとりへの対応」を組み合わせることです。保険や通販のように問い合わせや手続きが多い業種ほど、双方向のやり取りが効いてきます。

ここ最近のLINE運用のトレンドは、全員に同じメッセージを送る一斉配信から、一人ひとりに合わせて情報を届ける個客対応（1to1）へのシフトです。Webhookはその土台になる仕組みで、ユーザーの反応を受け取れて初めて「相手に合わせた対応」が成り立ちます。

進め方のコツは、いきなり全部を自動化しようとしないことです。まず「友だち追加のお礼」や「よくある質問3つの自動回答」など、効果が見えやすい一点から始めて、反応を見ながら広げていきます。最初から完璧な自動応答を目指すより、小さく動かして育てるほうが、結果的に早く成果につながります。

よくある失敗と回避法。検証でつまずく原因を切り分ける

Webhook設定でつまずくポイントは、実はパターンが決まっています。ここでは現場で本当によく見かける失敗を、状況・何が起きるか・どう防ぐかのセットで解説します。検証（Verify）で赤いエラーが出たら、まずこの順で切り分けてください。

失敗1。検証（Verify）が通らない

URLを登録して検証ボタンを押したのに、エラーで通らないケースです。これが一番多い相談です。原因はほぼ3つに絞られます。

• URLの打ち間違い：末尾のスラッシュ有無や、パスの綴り違い。コピペで正確に貼り直す
• HTTPSになっていない：「http://」では登録・検証できない。ngrokなどでHTTPS化したURLを使う
• サーバーが200を返していない：受け皿がエラー（500など）を返している。まずは何が来ても200を返す最小構成でテストする

切り分けのコツは、いきなり複雑な処理を書かないことです。最初は「POSTを受けたら中身を見ずに200を返すだけ」の受け皿でVerifyを通し、そこから機能を足していくと、どこで壊れたかがすぐ分かります。

失敗2。検証は通るのにイベントが届かない

検証は成功したのに、実際にメッセージを送っても通知が来ない。この場合、原因はほぼスイッチの入れ忘れです。

Developersコンソールの「Webhookの利用」がオフのままだと、検証は通っても本番の通知は送られません。ここを最初に確認してください。あわせて、一部のイベントしか届かないときは、受信するイベントを絞り込むフィルタ設定が効いている可能性があります。原因を切り分ける間は、まず全イベントを受け取る設定にして、必要になってから絞り込むほうが確実です。

失敗3。署名検証でエラーになる

通知は届くのに、署名検証（本物かどうかのチェック）で弾かれてしまうケースです。放置すると、正規の通知まで処理できなくなります。

原因の多くは、使っているチャネルシークレットが古い、または照合に渡すデータが「生のボディ」ではなく加工後の文字列になっていることです。前掲のコードのとおり、JSONに変換する前の生データで照合するのが鉄則です。チャネルシークレットを再発行したのに古い値を使い続けている、という取り違えも見かけます。

失敗4。GAS利用時のタイムアウトとリダイレクト

手軽さからGoogle Apps Script（GAS）で受け皿を作る人は多いのですが、つまずくことがあります。環境によってはLINE側がうまく受け取れなかったり、スプレッドシートへの書き込みなど重い処理を挟むと、応答が遅れて失敗扱いになる場合があります。挙動はGAS側の仕様で変わることがあるため、GASで組むなら公開（デプロイ）方法や実行時間の制限をGoogle Apps Scriptの公式ドキュメントで確認しておくと安全です。

回避策は、間にプロキシ（中継役）を置く方式です。中継役が先に200を返してしまい、実際の処理はそのあと非同期でGASに投げる。こうすると「返事は速く、処理はゆっくり」を両立できます。GASにこだわらず、最初からノーコードツールを使う判断も十分アリです。

使う側の落とし穴。URLは1本しかない、という現場の現実

設定手順よりも、運用を始めてから効いてくる制約があります。1つのチャネルに設定できるWebhook URLは、原則1本だけという点です（Webhookの受信仕様はLINE公式の「メッセージ（Webhook）を受信する」で確認できます）。ここを知らずに複数ツールを同時導入しようとして、行き詰まる現場をよく見ます。

たとえば「予約はAツール、顧客管理はBツール、チャットボットはCツール」と使い分けたくても、通知の宛先は1つしか指定できません。素直に組むと、あとから入れたツールが前のツールの連携を上書きしてしまいます。

この制約の回避策は、Webhook転送という考え方です。まず通知を「振り分け役」の1本のURLで受け、そこから複数のツールへ配る構成にします。専用の転送サービスを使う方法もあれば、自社の中継サーバーで振り分ける方法もあります。いずれにせよ、最初の設計段階で「将来どのツールを足すか」を見込んでおかないと、あとで作り直しになります。

見落としがちなコストの話です。Webhook連携そのものは無料でも、受け皿となるサーバーの維持費、転送サービスの利用料、拡張ツールの月額が積み上がります。「LINEは無料」というイメージのまま始めると、運用費で驚くことがあります。最初に月々いくらかかるかを一覧にしておきましょう。

もう一つの本音として、内製と外注の線引きがあります。ノーコードツールで受け取るだけなら社内でも十分回せます。

ただし、署名検証・非同期処理・複数ツールへの振り分け・エラー時の再送設計まで含めて安定運用するとなると、途端に専門知識が必要になります。ここは「動かす」と「落ちない状態を保つ」の間に大きな壁があると考えてください。片手間で組んだ連携が、キャンペーンの山場でエラー多発、というのは避けたい失敗です。

複数人で運用するなら、権限や作業ルールの整理も欠かせません。誰が設定を触れるか、鍵情報を誰が管理するかを決めておかないと、事故のもとになります。運用ルールの作り方はLINE公式アカウント複数人運用の鉄壁ルールも参考にしてください。

AI応答を組み込むときの、任せる範囲の見極め方

Webhookで受け取ったメッセージを、そのまま生成AIに渡して自動で回答させる。この組み合わせは今とても増えています。ただ、全部をAIに任せるのは危険です。任せていい範囲とダメな範囲を、最初に線引きしておきましょう。

基本の考え方はシンプルです。AIに任せていいのは「間違えても取り返しがつく軽い応対」、人が担うのは「間違えると損害や信用問題になる判断」です。

• AIに任せてよい：営業時間や場所の案内、よくある質問への一次回答、要望のヒアリングと整理
• 人が確認すべき：金額・契約・在庫の確約、クレーム対応、個人情報を伴う手続き、最終的な意思決定

実装の道筋としては、Webhookで受けたメッセージをAIに渡す前に、内容を仕分けする一段を挟むのが安全です。定型で答えられる質問はAIに回し、複雑そうなワードや金額に関わる質問が来たら「担当者におつなぎします」と有人対応へ切り替える。この振り分けがあるだけで、AIの暴走リスクは大きく下がります。

AIに社内情報を渡して回答させる場合は、情報漏洩の観点も忘れないでください。顧客の個人情報や社外秘をそのままプロンプトに含めない設計が必要です。AIへの渡し方の注意点はLINE配信文をAIに書かせる時の情報漏洩を防ぐプロンプト設計で具体的に触れています。

チャットボットの下書きをAIに作らせて、送信前に人が確認する運用なら、安全性と効率のバランスが取りやすくなります。返信のスピードを保ちながらミスを防ぐ進め方はLINEチャットの返信をAI下書きで速くする運用術も参考になります。AIは生成は得意ですが、良し悪しの最終判断は人がやる。この役割分担が、失敗しないAI連携の肝です。

まずは今日、LINE Developersコンソールを開いて「Webhookの利用」がオンになっているかだけ確認してみてください。ここがオフのままで止まっている現場は本当に多いです。もし応答の設計まで踏み込みたくなったら、応答モードの整理から始めると迷いません。

ここまで読んで、署名検証や複数ツールの振り分けまで自社で安定運用するのは難しそうだと感じた方は、無理に一人で抱えなくて大丈夫です。コレットラボでは、LINEとAIを組み合わせた業務の自動化や、外部システムとの連携設計を現場目線で伴走しています。「今の運用のどこから自動化できるか整理したい」だけの段階でも構いません。AI業務システム化の詳細はこちらから、まずは気軽にお話を聞かせてください。