LINE × Slack連携｜問い合わせの転送と、Slackから返信するときの設計（再送・重複・返信の戻し方）

LINE と Slack をつなぐと言っても、道は2本あります。1本目は転送で、LINE 公式アカウントに届いたメッセージを Messaging API の Webhook で受け、Slack に投稿する道です。2本目は返信で、担当者が Slack のスレッドに書いた文を Slack の Events API で受け、Messaging API でお客様の LINE に送る道です。「slack line 連携」と調べて出てくる手順の多くは、1本目までで終わります。2本目は、使う API も、失敗したときの再送の決まりも別です。

LINE → Slack の転送は、受け口を立てて Slack に投稿する

LINE の Messaging API は、ユーザーが友だち追加したりメッセージを送ったりすると、LINE Developers コンソールの［Webhook URL］に HTTP POST を送ります。この URL が受け口で、設定できるのは1つだけです（ボットを作成する）。HTTPS で、広く信頼されている認証局の証明書が要ります。すでに別のシステム（会員データベースや別の連携ツール）の Webhook URL に使っているアカウントでは、そこで受けたものを Slack 用に分ける中継が要る、ということです。

Slack に投稿する方法は2つあります。1つは Incoming Webhook で、チャンネルを固定した投稿用の URL に JSON を送るだけです。もう1つは Web API の chat.postMessage で、bot トークンの chat:write 権限で投稿します。転送だけなら前者で足ります。ただし Incoming Webhook は、投稿したメッセージの ts（メッセージの ID）を返さず、投稿したメッセージを削除することもできません（Sending messages using incoming webhooks）。返信をそのメッセージのスレッドに結ぶには ts が要るので、返信まで作るなら chat.postMessage を選びます（chat.postMessage）。

新しい Slack アプリは、すべての公開チャンネルに投稿できるわけではありません。投稿先のチャンネルにアプリを入れるか、chat:write.public 権限を足します。chat.postMessage は、1つのチャンネルに1秒に1件が目安です（同）。お客様のメッセージが続けて届く時間帯は、受け口で順番に並べて投稿します。

どこで誰が何を設定するか

つなぎ方は3通り：連携ツール、自作、LINE の標準のチャットだけ

受け口を誰が持つかで、3通りに分かれます。どれが正しいかは、再送や重複を誰が防ぐか、止まったときに誰が直すか、で決まります。比べる前に、各社の公式の資料で料金を確かめてください。

連携ツールで組むときも、中身は同じ2本の道です。ツールの画面に「LINE のメッセージを受けたら Slack に通知」という部品があっても、署名を検証しているか、同じイベントを2回受けたときにどうなるか、スレッドの対応表をどこに持つかは、部品の説明だけでは分かりません。検証できる環境で、同じメッセージを2回送って確かめるのが確実です。

標準のチャットで足りる場合があります。担当者を設定し、「要対応」のものだけを絞り込み、別の管理者が入力しているかを見る、までは標準の画面でできます（チャット）。店舗側の画面から返信する流れは、当社のデモ（架空の店舗・データ）の「自動応答と、スタッフへの切り替え」で触れます。Slack に出す意味が出てくるのは、LINE の画面を見ない人と一緒に相談しながら返したいとき、です。

Slack の通知を、社内の担当者の LINE に届ける向きも、よく一緒に聞かれます。以前よく使われた LINE Notify は、2025年3月31日にサービスを終了していて、公式は代わりに Messaging API を案内しています（LINE Notify 提供終了のお知らせ）。Messaging API で社内の担当者に送る場合も、そのメッセージはプッシュメッセージで、通数に数えられます。その設計は「LINE社内通知・ワークフロー自動化ガイド」に書きました。

取りこぼさない受け口：署名を検証し、保存して、200を返し、あとから処理する

LINE の Webhook を受ける受け口の順番は、署名を検証し、イベントを保存し、200を返す、までです。重複の除去と Slack への投稿は、その後ろで行い、失敗したら保存したイベントから再試行します。この順番を崩すと、取りこぼしか二重の投稿のどちらかが起きます。

1 署名を検証する

LINE は、本文を入力、チャネルシークレットを鍵にして HMAC-SHA256 で署名を作り、x-line-signature ヘッダーに入れて送ります。受け口は、受け取った本文の文字列に手を加えずに（パースや整形の前に）同じ計算をして、署名を比べます。一致しなければ、中身は処理せずに終えます。LINE の送信元の IP アドレスは公開されていないので、IP の制限ではなく署名で守ります。受け口の手前のプロキシやロードバランサーが本文を変えると、署名が一致しなくなります（署名を検証する）。ヘッダー名の大文字・小文字は予告なく変わることがあるので、区別せずに読みます（Messaging API リファレンス）。

2 イベントを1件ずつ分けて保存する

1回の Webhook には複数のイベントが入ることがあり、1人のユーザーとは限りません。A さんのメッセージと B さんの友だち追加が同じ Webhook に入ることもあります（Webhook の受信）。そのため、保存も、あとの重複の判定も、Webhook の1回ごとではなく、イベントごとにします。届いたイベントは、そのままキューか表に保存します。Slack に転送するのは、まずメッセージイベントです。友だち追加（フォロー）、ブロック（フォロー解除）、ユーザーによる送信の取り消しも届くので、どれを Slack に出すかを決めておきます。

3 200を返す

LINE の公式ドキュメントは、後続のリクエストが待たされないように、Webhook のイベントを非同期で処理することを勧めています。受け口がやることは、署名を確かめ、イベントを保存し、200を返すところまでです。Slack への投稿は、その後ろで行います。

先に200を返すと、LINE の再送には頼れなくなります。再送は、200番台を返さなかったときだけ起きるからです。それでも、イベントを保存してから返しているので、あとの処理が失敗しても、保存した分から取り直せます。保存そのものに失敗したときは、200を返さず、再送に任せます（再送を有効にしている場合）。

4 後ろで重複を除く

同じイベントが重複して届く可能性は、LINE の公式ドキュメントが認めています。重複は、Webhook イベントの webhookEventId で見分けます。再送されたイベントは、deliveryContext.isRedelivery が違うだけで、イベント ID や応答トークンは元のイベントと同じです。再送で順番が前後することもあり、前後関係は timestamp で確かめます（受け取りに失敗したWebhookを再送する）。保存したイベントを webhookEventId で突き合わせ、処理済みのものは飛ばします。

5 Slack に投稿し、失敗したら保存分から再試行する

後ろの処理は、保存したイベントを順に取り出して、Slack に投稿し、投稿の ts を対応表に残します。Slack への投稿が失敗したら（エラー、レート制限）、保存したイベントからやり直します。やり直しで同じイベントを二度投稿しないよう、投稿済みかどうかを対応表で確かめてから投稿します。

LINE の Webhook の再送は、既定では無効です。有効にするには、LINE Developers コンソールの［Messaging API設定］タブで［Webhookの利用］と［Webhookの再送］をオンにします。再送されるのは、再送が有効で、ボットサーバーが200番台のステータスコードを返さなかったときです。再送の回数と間隔は公開されておらず、予告なく変わることがあります。再送は確実な再送を保証するものではなく、再送の件数が急に増えて LINE プラットフォームの動作に影響すると判断されると、強制的に無効になることもあります（Webhook の再送）。受け口が一時的に落ちたときの保険にはなりますが、これを唯一の頼りにしない、という設計になります。

もう1つ、公式ドキュメントが注意しているのは、取り直せないものがあることです。ユーザーが送ったテキストは、Webhook のテキストメッセージでしか受け取れず、受け取ったあとでテキストをもう一度取るための API はありません。画像・動画・音声・ファイルは、メッセージ ID を使って取得できますが、一定期間後に自動的に削除されます（ユーザーが送ったコンテンツを取得する）。受け取った時点で、自社の側に保存するか、Slack に出す必要があります。保存の期間と明示は、後半の個人情報の節で扱います。

LINE と Slack の再送が重なると、二重の投稿と二重の返信が出る

再送は LINE にだけあるのではありません。返信の側、つまり Slack から受け口へのイベントにも再送があります。Slack は、受け口が3秒以内に HTTP 2xx を返さないと、そのイベントの配信は失敗したとみなします。失敗すると、最大3回、間隔を空けて再送します。1回目はほぼ即時、2回目は1分後、3回目は5分後です。再送のたびに x-slack-retry-num（1〜3）と x-slack-retry-reason（http_timeout など）のヘッダーが付きます（The Events API）。

二重の返信が起きる典型の順番は、こうです。担当者がスレッドに返信する。Slack がイベントを受け口に送る。受け口が、その場で LINE の API を呼び、返事を待つ。LINE の API の待ちで3秒を超える。Slack は失敗とみなして再送する。受け口は2通目のイベントを受け、もう一度 LINE に送る。お客様の LINE に同じ返信が2回届きます。逆の向きでも同じで、受け口が200を返し損ねると、LINE が同じイベントを再送し（再送を有効にしている場合）、Slack に同じ問い合わせが2回出ます。

Slack の側には、再送を止める仕組みもあります。非200の応答に x-slack-no-retry: 1 のヘッダーを付けると、そのイベントは再配信されません。また、再送を含めて、配信の95%以上が失敗する状態が60分続くと、イベントの購読が一時的に無効になります（1時間に受け取るイベントが1,000件に満たないアプリは、自動では無効にならない、とされています）。購読が止まったときは、Slack からアプリの作成者にメールが届き、アプリの管理画面で再開します。受け口の不調が長く続くと、再送の前に、Slack からのイベントそのものが止まる、ということです。

もう1つ、Slack には「Delayed Events」という設定があります。オンにすると、3回の再送のあとも、1時間ごとの再送を24時間続けます。既定では、2時間以上遅れたイベントは配信しません。これをオンにする場合は、遅れて届いた返信を、そのまま LINE に送ってよいかを決めておく必要があります。お客様にとっては、半日前に書かれた返信が突然届くことになるからです。イベントの時刻（event_time）を見て、古いものは送らずに Slack に知らせる、という判断を入れておくと安全です。

返信を LINE に戻す：Slack のスレッドと LINE のユーザー ID を結ぶ

返信の道は、Slack の Events API で始まります。Slack のアプリで message.channels（非公開チャンネルなら message.groups）のイベントを購読すると、チャンネルへの投稿が、受け口に届きます。受け口は、そのイベントが「どのお客様へのスレッド返信か」を決めなければなりません。決める手がかりが、Slack のメッセージの ts と thread_ts です。thread_ts があればスレッドの一員で、thread_ts と ts が同じなら親メッセージ、違えば返信です（Retrieving messages）。

返信と見分けるときに外すものが、いくつかあります。メッセージイベントには、subtype を持つものがあり、bot_message（連携したアプリによる投稿）、channel_join（メンバーの参加）などがあります（message イベント）。自分の bot が Slack に投稿した転送メッセージも、メッセージイベントとして自分に届くことがあるので、人の返信だけを LINE に送る条件を入れておかないと、転送した文をそのまま LINE に送り返すことになりかねません。

対応表に持つ項目

スレッドとお客様の結び付けは、受け口の持つ対応表で行います。LINE の応答トークンを、スレッドの ts と一緒に保存する構成を紹介している記事もありますが、応答トークンは受信から1分以内にしか使えません。残しておいても、有効期間は延びません（次の節）。残すのは、期限のない、ユーザー ID のほうです。

お客様1人に、スレッドを1本にするか、問い合わせごとに新しいスレッドにするかは、運用で決めます。1人1本なら、過去のやり取りがスレッドに残り、「最後の担当者」を引き継ぎやすくなります。ただし、スレッドが長くなり、未対応の判定が難しくなります。問い合わせごとなら、完了を区切りやすい代わりに、「どこからが新しい問い合わせか」を決めるルールが要ります。

ユーザー ID が無いとき、複数のアカウントがあるとき

LINE のユーザー ID は、LINE プラットフォームが発行する値で、同じユーザーでもプロバイダーが違えば別の値になります。プロバイダーが同じなら、Messaging API のチャネルでも LINE ログインのチャネルでも同じ値です（ユーザーIDを取得する）。アカウントを事業部ごとに分けていて、プロバイダーが別々の場合、同じお客様が別のユーザー ID で届きます。対応表のキーは、destination とユーザー ID の組にして、アカウントを混ぜない設計にします。ID を自社の顧客番号に結ぶ話は「Salesforce と LINE の連携の記事」でも扱っています。

例外が1つあります。プロフィール情報の取得に同意していないユーザーのメッセージでは、Webhook にユーザー ID が含まれません（ユーザーIDを取得する・ユーザーのプロフィール情報取得の同意）。該当するのは、iOS 版・Android 版の LINE を使わず、PC 版の LINE だけを使っている人です。PC 版では2020年4月から新規にアカウントを作れないので、対象は過去に PC 版で作ったアカウントだけを使い続けている人に限られます。この人たちにも、あとからプッシュメッセージで返すには宛先のユーザー ID が要るので、転送のとき、ユーザー ID の有無を Slack の投稿に出しておくと、返信を書く前に分かります。

応答メッセージか、プッシュメッセージか：返信が1分を超えたとき

LINE に返信を送る方法は2つあります。応答メッセージ（Reply API）は、Webhook で受け取った応答トークンを使う方法で、通数に数えられません。プッシュメッセージは、ユーザー ID を指定して任意のタイミングで送る方法で、通数に数えられます（Messaging APIの料金）。

応答トークンには、使い方の決まりがあります。使えるのは一度だけで、Webhook を受信してから1分以内に使う必要があります。1分を超えた場合の動作は保証されません。再送された Webhook に含まれる応答トークンも、再送を受信してから1分以内なら使えますが、元のトークンをすでに使っている場合と、イベントの発生から20分が経過している場合は使えません。時間制限は予告なく変わることがあるので、制限に頼った実装は避け、できるだけ早く使うよう、公式に書かれています（Messaging API リファレンス「応答トークン」）。

担当者が Slack で内容を読み、確認し、返信を書くまでに、1分を超えることは普通にあります。応答トークンを対応表に残しても、1分は延びません。担当者が人の手で返す連携では、プッシュメッセージで返す前提で設計し、通数を見積もるほうが、あとで困りません。応答メッセージは、1分以内に返せることが分かっている自動の一次対応で使う、という分け方になります。

プッシュで返すときに確かめること

• 送れる相手：LINE 公式アカウントを友だち追加しているユーザーと、1対1のトークで7日以内にそのアカウントへメッセージを送ったユーザー。ブロックしているユーザー、アカウントを削除したユーザー、友だちでなく7日を過ぎたユーザーには、ステータスコード200が返っても実際には届かず、通数にも数えられません（プッシュメッセージを送る）。Slack に「送信した」と出ていても、届いたとは限りません。ブロックのイベント（フォロー解除）を受け取ったら対応表に記録し、そのお客様への返信は、送る前に Slack に知らせます。
• 通数の数え方：通数は、メッセージを送る対象になった人数で数えます。1回のリクエストに入れるメッセージの数（最大5つ）は、通数に影響しません。1人のお客様に返信を何回かに分けると、その回数が通数になるので、まとめて1回で送るほうが通数を抑えられます（メッセージを送信する）。
• 無料の通数：コミュニケーションプランは200通、ライトプランは5,000通、スタンダードプランは30,000通です。追加メッセージを送れるのはスタンダードプランだけで、2026年10月1日から、月20万通までは1通3円、20万通を超えた分は1通2.5円です（税別。料金プラン・お知らせ）。たとえばコミュニケーションプランでは、プッシュで返す返信が月200件になると、無料の通数を使い切ります（当社計算。配信など、ほかのメッセージの通数も同じ枠です）。新旧の単価表は「LINE公式アカウントの料金改定」にまとめています。
• 二重送信の防止：プッシュメッセージには、X-Line-Retry-Key ヘッダーに16進表記の UUID を付けられます。同じキーで再度送ると、すでに受理されていれば409が返り、重複して送られません。キーは自社で作る必要があり、LINE 側で管理される期間は24時間です。24時間を過ぎて同じキーを使うと、新しい送信として扱われ、重複して届きます（APIリクエストを再試行する）。Slack の event_id から同じ値の UUID を作れば、Slack の再送で2回目のイベントが来ても、同じキーで送ることになります。

誰が返したかを残し、未対応を見えるようにする

お客様の LINE に届くのは、LINE 公式アカウントからのメッセージです。返信のリクエストの項目（宛先、メッセージ、通知の有無）に、送信した人を表すものはありません（リクエストボディ）。誰が返したかを残せるのは、自社の側の記録だけです。対応表に、返信した Slack のユーザー ID、送った時刻、応答かプッシュか、応答コードを残しておきます。文面に担当者名を入れるかどうかは、お客様に見せてよいかの問題なので、運用で決めます。

標準のチャットは、別の管理者が入力しているときに、入力中の表示とそのユーザー名が出ます（チャット）。Slack のスレッドでは、2人が同時に返信を書くと、両方がそのまま LINE に届きます。担当者を先に決める運用が要ります。たとえば、問い合わせの投稿に最初に絵文字を付けた人を担当として対応表に記録し、ほかの人の返信は、LINE に送らずに Slack の側で知らせる、という作りです。絵文字を付けたことは、reaction_added のイベント（reactions:read 権限）で受け取れます（reaction_added）。

注意が1つあります。標準のチャットの「未読」「要対応」「対応済み」は、LINE Official Account Manager の中の状態です。API で送った返信が、その状態にどう反映されるかは、当社では確かめられませんでした。Slack で返したあとも、LINE 側の画面で「未対応」のまま残ることがあり得るので、運用の前に、検証用のアカウントで確かめてください。

Slack に残る LINE の会話の扱い

LINE のユーザーデータポリシーは、LINE 公式アカウントが受け取ったユーザーからのメッセージを「LINEユーザ情報」に含めています。表示名やアイコン画像も同じです。Slack に転送したメッセージは、この LINE ユーザ情報を自社の側で保存していることになります（LINEユーザーデータポリシー 1.2）。ポリシーの条項のうち、Slack への転送に関わるものは次のとおりです。

LINE の公式ドキュメントは、ユーザーが送信を取り消したときに、取り消した意図を尊重し、独自の管理画面に表示しているメッセージの表示を取り消し、データベースに保存しているメッセージを削除するよう勧めています（送信取消イベント受信時の処理）。Slack に転送した分も同じ扱いにします。送信取消のイベントを受けたら、対応表から転送した投稿の ts を引き、chat.delete（chat:write 権限）で消します（chat.delete）。Incoming Webhook で投稿したメッセージは削除できないので、ここでも chat.postMessage のほうが扱いやすくなります。

画像や動画は、LINE 側では一定期間で自動削除されますが、Slack に転送したコピーは別です。保持の期間を自社で決め、削除の手段を用意しておきます。Slack のワークスペース側の保持期間の設定やエクスポートの扱いは、Slack の管理者に確認してください。社内で使っているのが Slack ではなく LINE WORKS の場合は「LINE と LINE WORKS の連携ガイド」を、あわせて読んでください。

転送と返信の設計は、受け口を誰が持つか、担当者が LINE の画面を見ないのか、通数をどう抑えるか、の3つを決めると形が固まります。Aurant Technologies では、LINE 公式アカウントの運用と、転送・返信の設計の相談をLINE運用・伴走支援のページで受け付けています。自作するか、連携ツールに任せるか、標準のチャットで足りるかの見極めも、一緒に整理できます。