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