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