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