LINE × Slack連携ガイド2026｜問い合わせ転送・通知統合・使い分けの実践方法
LINEとSlackを連携して顧客問い合わせの社内転送・通知統合・双方向連携を実現する方法を解説。Make/Zapierを使ったノーコード設定とカスタム開発の費用も紹介します。
目次 クリックで開く
LINE × Slack連携ガイド2026
顧客問い合わせ転送・通知統合・双方向連携の実装方法
顧客接点はLINE、社内連絡はSlackというチームが増えています。両者を連携することで、顧客からのLINE問い合わせを社内SlackへリアルタイムにエスカレートしながらLINEで返信する仕組みが構築できます。
LINE × Slack連携でできること
- LINEカスタマー問い合わせ→Slack通知：顧客からLINEに届いた問い合わせをSlackの#support-lineチャンネルへリアルタイム転送
- Slack通知→LINE配信：Slackの障害アラートや売上通知をLINE Worksの担当者へ転送（Slack未使用メンバーへの周知）
- LINE問い合わせのSlack担当者割り当て：問い合わせ内容をSlackに転送し、担当者がSlack上で返信内容を確認・編集してLINEへ送信
- クロスチャネル通知統合：メール・LINE・Webフォームからの問い合わせをすべてSlackの1チャンネルに集約
LINE → Slack転送の実装パターン
最もシンプルな構成（Make利用）：
- LINE Messaging API Webhookで顧客メッセージを受信
- Makeが受信イベントを処理
- Slackの「Create a message」モジュールで#support-lineチャンネルへ転送
- メッセージにLINEユーザーID・送信時刻・内容を含める
- 担当者がSlackでスレッド返信 → LINEへの返信はMessaging APIで別途実装
双方向連携（Slack返信→LINE送信）のアーキテクチャ
より高度な実装として、Slackで担当者がスレッドに返信した内容をLINEへ自動送信する双方向連携があります。Slack Event APIの「message.channels」イベントを受信し、スレッド内の返信のみをフィルタリングしてLINE Reply APIで顧客へ送信します。専用のWebサーバー実装が必要なため、カスタム開発費用は30〜80万円程度です。
双方向連携 システムコンポーネント 設計早見表
前のセクションで「双方向連携にはWebサーバー実装が必要」と説明しましたが、具体的にどのコンポーネントを何で実装するかが分からないと、開発会社への要件定義や見積もり依頼ができません。下表は、LINE→Slack転送から Slack返信→LINE送信までの双方向連携を構成する主要コンポーネントと、それぞれの代表的な実装方法・注意点をまとめたものです。内製・外注を問わず、初期設計の整理資料としてご活用ください。
| コンポーネント | 役割 | 代表的な実装方法 | 主な注意点 |
|---|---|---|---|
| Webhook受信サーバー | LINE Messaging APIからのイベント（メッセージ・フォロー・ブロック等）を受け取る | AWS Lambda / Google Cloud Functions（サーバーレス）、またはNode.js・Python on VPS | LINEから送られる署名（X-Line-Signature）を検証すること。改ざん検知のため必須。SSL証明書（HTTPS）が必要 |
| LINE UID ↔ 顧客ID マッピングDB | どのLINEユーザーからの問い合わせかを社内顧客DBと紐づけて管理 | RDS（MySQL/PostgreSQL）またはFirestore。LINE UIDをキーに顧客名・担当者・対応状況を保持 | 友だち追加時にLINE UIDを取得してDBに登録するフローが前提。LINEはユーザーの名前を教えてくれないため、名寄せ設計が必須 |
| LINE→Slack転送モジュール | 受信したLINEメッセージを指定のSlackチャンネルへ転送 | Slack Web API（chat.postMessage）。Make/Zapier経由でも可（ただしリアルタイム性はAPI直接呼び出しが優位） | 転送メッセージにLINE UIDとメッセージIDを含めることで、返信時の逆引きを可能にする。画像・スタンプはURLを転送（LINE Content APIで24時間のみ取得可能） |
| SlackスレッドID ↔ LINEメッセージID マッピング | Slackで担当者がどのスレッドに返信したかを、どのLINE会話へ送信すべきかに変換 | 転送時にSlackの thread_ts（スレッドID）とLINEの replyToken または userId をDBに保存。返信時に逆引き | LINE Reply Tokenは送信から1分以内に使用しないと失効。1分超の返信はPush Message APIを使用（通数課金） |
| Slack Event Listener | Slackの特定チャンネルのスレッド返信を検知する | Slack Event API（message.channels イベント）。SlackアプリのBot TokenとEvent Subscriptions設定が必要 | すべてのメッセージイベントを受信するため、Botの返信やシステム通知まで拾ってしまう。フィルタリングロジック（送信者・チャンネル・スレッド判定）が必須 |
| エラーハンドリング・リトライ | API障害・タイムアウト時のメッセージ消失を防ぐ | キューイング（SQS / Cloud Tasks）でメッセージを一時保存し、冪等なリトライを実装 | LINE Reply Tokenは再利用不可のため、失敗時はPush Messageにフォールバック。顧客への二重送信を防ぐ冪等キー管理が必要 |
表の中で実装者が最も見落としやすいのが「LINE Reply Tokenの1分失効」です。Slackに転送されたメッセージに担当者が気づくまでに1分以上かかった場合、Reply Tokenは無効になっています。このケースでは自動的にPush Message APIへ切り替えるフォールバックが必要ですが、Push Messageは通数課金（フリープランは月1,000通まで無料、超過後は約3円/通）のため、コスト設計にも影響します。双方向連携を設計する段階で「Reply vs Push のフォールバック判断」と「月次Push Message見込み通数」を事前に見積もっておくことをお勧めします。
LINE・Slack・LINE Worksの使い分け整理
| チャネル | 主な用途 | 相手 |
|---|---|---|
| LINE公式アカウント | 顧客対応・マーケティング配信 | 一般顧客・見込み客 |
| LINE Works | 取引先・社外パートナーとの業務連絡 | 取引先・現場スタッフ |
| Slack | 社内IT/開発チームの連絡・システム通知 | 社内エンジニア・マネージャー |
| LINE→Slack転送 | 顧客問い合わせを社内チームへエスカレート | 外部→内部の橋渡し |
コスト比較
| 連携方式 | 初期費用 | 月額 |
|---|---|---|
| Makeノーコード連携 | 10〜20万円（設定代行） | 1〜3万円 |
| Zapier連携 | 10〜20万円 | 2〜5万円 |
| カスタム双方向連携 | 30〜80万円 | 3〜8万円（保守） |
LINE活用・販促とマーケティングDXのご相談
LINE公式アカウントを軸にした顧客接点づくりや配信・販促の自動化、マーケティング全体のデジタル化を支援します。業種ごとの勝ちパターンを踏まえ、貴社に合った活用方法をご提案します。
よくある質問
LINE公式アカウント支援
LINE公式アカウントの配信設計からCRM連携、LINEミニアプリ開発まで。顧客接点のデータを統合し、LTVと売上を上げるLINE活用を実現します。