向いている業務
- 業種
- Zendeskで問い合わせを受け付ける事業者
- 部門
- カスタマーサポート
- 実行頻度
- 新規チケット受信のたび。1日10〜50件を想定
- 作業量の試算（未実測）
- （未実測）月2,400分−承認900分−例外対応300分−運用保守180分＝月1,020分を想定
ZendeskRAG文章生成手動承認
Zendeskに新規チケットが届いたら承認済み回答をZendeskから返信する
Zendesk受信イベントの本文を使い、送信台帳で未返信を照合し、社内文書を根拠に作成した回答を人が承認してから返信する構成の設計例です。
設計例（未検証）:
この手順は Pigeon Workflow のノードで組める構成として設計したもので、実機での検証記録はまだありません。導入時は下の「検証時に確認する項目」を自社条件で確認してください。
Fit
このレシピが向く条件と対象外
Workflow
ワークフロー図
新規チケットを受信
Zendesk 受信（自動起動）
送信台帳を取得
スプレッドシート取得
返信対象状態を単一ルールで確認
条件で分岐
台帳上の未返信を単一ルールで確認
条件で分岐
問い合わせを分類
カテゴリ分類
回答根拠を検索
ドキュメント検索
引用元付き回答を作成
文章生成
回答内容を確認
手動承認
承認済み回答を返信
Zendesk 返信
返信結果を台帳へ記録
スプレッドシート書き込み
例外・確認の分岐
条件で分岐 から分岐
- 受信イベント本文の状態を単一ルールで判定
- 次の条件分岐でチケットIDを送信台帳と照合
- 送信済みなら公開返信を停止
状態と未返信のAND条件は、複数ルールを1ノードに置かず条件分岐2個を直列にして表す
ドキュメント検索 から分岐
- 2026-09-27時点の取り込み障害を確認
- 導入前に対象文書の取り込み状態を確認
- 利用できない場合は回答作成を停止
根拠を取得できる状態になるまで公開返信へ進めない
手動承認 から分岐
- 承認期限切れを検知
- 返信を停止
- 担当者の修正先へ戻す
代理承認者と公開返信の取消手順を導入前に決める
Zendesk 返信 から分岐
- API失敗を記録
- 上限回数まで再試行
- Zendeskと送信台帳を手動確認
返信結果が不明な場合は再返信前にZendesk側を照合
再実行や重複防止の扱いは、上の『例外・確認の分岐』に記載しています。
Verification checklist
検証時に確認する項目
- データ：個人情報、AIの処理先、保存期間、通知先に表示する項目を確認する。
- 認証：OAuthやAPIキーを最小権限にし、Webhook署名と秘密情報の更新・失効手順を確認する。
- 復旧：順序逆転、同時実行、レート制限、上限付き再試行、結果不明時の手動復旧を確認する。
- 承認：承認期限、代理承認者、却下・期限切れ後の修正先を確認する。人の承認を使わない手順では確認担当と停止条件を決める。
- 運用：運用担当者、停止・再開の判断者、障害時の連絡先を決める。
- 記録：実行結果と例外対応の記録先（台帳）と保存期間を決める。
- 検索：ドキュメント検索の取り込みは2026-09-27時点で障害を確認。導入前に対象文書の取り込み状態と検索結果を確認する。
Integrations & permissions
必要な連携と権限
Zendesk
Zendesk 受信（自動起動）のイベント本文を問い合わせ入力に使い、承認後は公開返信または社内メモを追加します。チケット一覧取得からコメント本文を得る前提にはしません。
ドキュメント検索・文章生成
2026-09-27時点でドキュメント取り込み障害を確認しています。導入前に取り込み状態を確認し、利用できる場合だけ引用元付きの回答案を作ります。
Google スプレッドシート
チケットID、受信イベントID、返信結果を記録し、未返信の照合に使います。
手動承認
回答案、引用元、公開範囲を担当者が確認します。
必要な権限・アカウント
- Zendeskのイベント受信・返信権限
- 対象ブランドの受信イベント本文の利用と返信に限定して設定します。
- 社内文書の閲覧権限
- 回答担当者が閲覧できる文書だけを検索対象にします。
- Google スプレッドシートの読み取り・編集権限
- 未返信の照合と返信結果の台帳記録に使います。
- 承認担当者のPWアカウント
- 回答案の修正、承認、却下に使います。
Exception handling
例外時の挙動
条件で分岐 から分岐
- 1. 受信イベント本文の状態を単一ルールで判定
- 2. 次の条件分岐でチケットIDを送信台帳と照合
- 3. 送信済みなら公開返信を停止
状態と未返信のAND条件は、複数ルールを1ノードに置かず条件分岐2個を直列にして表す
ドキュメント検索 から分岐
- 1. 2026-09-27時点の取り込み障害を確認
- 2. 導入前に対象文書の取り込み状態を確認
- 3. 利用できない場合は回答作成を停止
根拠を取得できる状態になるまで公開返信へ進めない
手動承認 から分岐
- 1. 承認期限切れを検知
- 2. 返信を停止
- 3. 担当者の修正先へ戻す
代理承認者と公開返信の取消手順を導入前に決める
Zendesk 返信 から分岐
- 1. API失敗を記録
- 2. 上限回数まで再試行
- 3. Zendeskと送信台帳を手動確認
返信結果が不明な場合は再返信前にZendesk側を照合
FAQ
よくあるご質問
この手順は検証済みですか？
設計例です。実機での検証記録はまだありません。検証時に確認する項目は本ページの一覧のとおりです
同じチケットイベントを再度受信したらどうしますか？
チケットIDと受信イベントIDを送信台帳で照合します。返信対象状態と未返信は、単一ルールの条件分岐を直列に2個置いて判定する想定です。
ドキュメント検索は導入時に使えますか？
ドキュメント検索の取り込みは2026-09-27時点で障害を確認しています。導入前に取り込み状態を確認し、利用できなければ回答作成を停止する想定です。
Related
親の活用シーンと関連レシピ
親の活用シーン
問い合わせメールを分類し、回答案の承認とCRM記録へつなぐ
問い合わせの分類と回答案の下書きを支援し、対外送信は担当者の確認・承認後に行います。
関連レシピ設計例（未検証）
Zendeskの不具合候補チケットを承認後にLinearへ登録する
Zendeskのチケットを不具合候補に分類し、単一ルールで対象を分け、人が承認した未反映分だけLinearへ登録する構成の設計例です。
関連レシピ設計例（未検証）
Gmailの問い合わせを承認後に要約してSlackへ共有する
EMAILトリガーの差出人・件名条件で受信した問い合わせ1通を要約し、担当者が原文と照合して承認した未送信分だけをSlackへ共有する構成の設計例です。本文長による数値判定は行いません。
関連レシピ設計例（未検証）
LINEの問い合わせを分類し、承認後にSlackへ共有する
LINEの問い合わせをカテゴリ分類し、単一ルールで共有対象を分け、人が承認した未送信分だけをSlackへ共有する構成の設計例です。