向いている業務
- 業種
- LINEで問い合わせを受け付ける店舗・サービス事業者
- 部門
- 受付・カスタマーサポート
- 実行頻度
- 問い合わせ受信のたび。1日10〜40件を想定
- 作業量の試算（未実測）
- （未実測）月1,500分−承認600分−例外対応180分−運用保守120分＝月600分を想定
LINEカテゴリ分類Slack手動承認
LINEの問い合わせを分類し、承認後にSlackへ共有する
LINEの問い合わせをカテゴリ分類し、単一ルールで共有対象を分け、人が承認した未送信分だけをSlackへ共有する構成の設計例です。
設計例（未検証）:
この手順は Pigeon Workflow のノードで組める構成として設計したもので、実機での検証記録はまだありません。導入時は下の「検証時に確認する項目」を自社条件で確認してください。
Fit
このレシピが向く条件と対象外
Workflow
ワークフロー図
LINE問い合わせを受信
LINE トリガー
問い合わせをカテゴリ分類
カテゴリ分類
分類 equals 共有対象で判定
条件で分岐
要旨と連絡希望を抽出
AI 抽出
原文と分類を確認
手動承認
送信台帳を取得
スプレッドシート取得
イベントIDと分類版を照合
データ結合
承認済み分類を共有
Slack 送信
送信結果を台帳へ記録
スプレッドシート書き込み
例外・確認の分岐
データ結合 から分岐
- LINEイベントIDと分類版で送信台帳を照合
- 並行実行時は双方が未送信と判断する可能性を確認
- 自動運用前は担当者がSlackを照合
事前照合と出力後記録だけでは、並行実行時に重複する可能性があります。一意キーの処理中状態を原子的に確保できる台帳、出力先の一意制約・upsert、または同時実行数1を実機確認できた場合だけ自動運用し、それまでは重複の可能性を前提に担当者が出力先を照合します。
手動承認 から分岐
- 承認期限を運用台帳で監視
- 期限までに判断されない実行を担当者が停止
- 原文の現状を確認して再申請
承認期限切れの自動分岐は使わず、停止と再申請を担当者が行う
Slack 送信 から分岐
- API失敗時は実行失敗として停止
- 自動再試行は前提にしない
- 結果不明時はSlackと送信台帳を照合して担当者が手動で再実行
API失敗時は実行失敗として停止します。自動再試行は前提にせず、結果不明時は出力先と台帳を照合してから担当者が手動で再実行します。
再実行や重複防止の扱いは、上の『例外・確認の分岐』に記載しています。
Verification checklist
検証時に確認する項目
- データ：個人情報、AIの処理先、保存期間、通知先に表示する項目を確認する。
- 認証：OAuthやAPIキーを最小権限にし、Webhook署名と秘密情報の更新・失効手順を確認する。
- 復旧：API失敗時は実行失敗として停止する。自動再試行は前提にせず、結果不明時は出力先と台帳を照合してから担当者が手動で再実行する。
- 承認：承認期限、代理承認者、却下・期限切れ後の修正先を確認する。人の承認を使わない手順では確認担当と停止条件を決める。
- 運用：運用担当者、停止・再開の判断者、障害時の連絡先を決める。
- 記録：実行結果と例外対応の記録先（台帳）と保存期間を決める。
Integrations & permissions
必要な連携と権限
LINE
Webhook署名を確認し、イベントID、問い合わせ本文など導入前に取得を確認できた項目を使います。顧客への返信は含めません。
AI分類・抽出・手動承認
分類後に単一のequalsルールで共有対象を分け、原文と分類結果を人が照合します。
Slack・Google スプレッドシート
承認済み分類を共有し、イベントID、分類版、送信結果を台帳へ記録します。
必要な権限・アカウント
- LINEのWebhook受信・読み取り権限
- 対象チャネルの問い合わせイベントに限定します。
- Slackの投稿権限
- 問い合わせ対応者だけが閲覧できるチャンネルに限定します。
- Google スプレッドシートの読み取り・編集権限
- 送信台帳の照合と記録に使います。
- 承認担当者のPWアカウント
- 原文と分類結果の照合に使います。
Exception handling
例外時の挙動
データ結合 から分岐
- 1. LINEイベントIDと分類版で送信台帳を照合
- 2. 並行実行時は双方が未送信と判断する可能性を確認
- 3. 自動運用前は担当者がSlackを照合
事前照合と出力後記録だけでは、並行実行時に重複する可能性があります。一意キーの処理中状態を原子的に確保できる台帳、出力先の一意制約・upsert、または同時実行数1を実機確認できた場合だけ自動運用し、それまでは重複の可能性を前提に担当者が出力先を照合します。
手動承認 から分岐
- 1. 承認期限を運用台帳で監視
- 2. 期限までに判断されない実行を担当者が停止
- 3. 原文の現状を確認して再申請
承認期限切れの自動分岐は使わず、停止と再申請を担当者が行う
Slack 送信 から分岐
- 1. API失敗時は実行失敗として停止
- 2. 自動再試行は前提にしない
- 3. 結果不明時はSlackと送信台帳を照合して担当者が手動で再実行
API失敗時は実行失敗として停止します。自動再試行は前提にせず、結果不明時は出力先と台帳を照合してから担当者が手動で再実行します。
FAQ
よくあるご質問
この手順は検証済みですか？
設計例です。実機での検証記録はまだありません。検証時に確認する項目は本ページの一覧のとおりです
分類結果だけで顧客へ返信しますか？
返信しません。この構成は共有対象をequalsで分け、担当者が承認した分類と要旨を社内Slackへ送るところまでです。
同じLINEイベントが再送されたらどうしますか？
イベントIDと分類版を送信台帳で照合します。ただし並行実行時は重複する可能性があるため、出力先の一意制約・upsert、または同時実行数1を実機確認できるまでは担当者がSlackを照合する想定です。
Related
親の活用シーンと関連レシピ
親の活用シーン
問い合わせメールを分類し、回答案の承認とCRM記録へつなぐ
問い合わせの分類と回答案の下書きを支援し、対外送信は担当者の確認・承認後に行います。
関連レシピ設計例（未検証）
PigeonCloudの問い合わせを緊急候補に分類し、承認後にSlackへ通知する
問い合わせの感情とカテゴリから緊急候補を作り、人が原文と理由を確認した未送信の分類版だけをSlackへ知らせる構成の設計例です。
関連レシピ設計例（未検証）
Gmailの問い合わせを承認後に要約してSlackへ共有する
EMAILトリガーの差出人・件名条件で受信した問い合わせ1通を要約し、担当者が原文と照合して承認した未送信分だけをSlackへ共有する構成の設計例です。本文長による数値判定は行いません。
関連レシピ設計例（未検証）
Zendeskに新規チケットが届いたら承認済み回答をZendeskから返信する
Zendesk受信イベントの本文を使い、送信台帳で未返信を照合し、社内文書を根拠に作成した回答を人が承認してから返信する構成の設計例です。