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