向いている業務
- 業種
- 日報をPigeonCloudで管理する事業者
- 部門
- 営業・現場統括
- 実行頻度
- 日報追加のたび。1日20〜40件を想定
- 作業量の試算（未実測）
- （未実測）月1,600分−承認400分−例外対応160分−運用保守120分＝月920分を想定
PigeonCloud日報要約Slack
PigeonCloudに日報が追加されたら要点を承認後にSlackへ共有する
PigeonCloudに追加された日報から進捗、課題、支援依頼を要約し、人が確認した未送信の内容だけをSlackへ共有する構成の設計例です。
設計例（未検証）:
この手順は Pigeon Workflow のノードで組める構成として設計したもので、実機での検証記録はまだありません。導入時は下の「検証時に確認する項目」を自社条件で確認してください。
Fit
このレシピが向く条件と対象外
Workflow
ワークフロー図
日報追加を受信
PigeonCloud Webhook
日報本文を再取得
PigeonCloud 取得
進捗・課題・支援依頼を要約
要約
原文と要約を確認
手動承認
送信台帳を取得
スプレッドシート取得
日報IDと要約版を照合
データ結合
承認済み要約を共有
Slack 送信
送信結果を台帳へ記録
スプレッドシート書き込み
例外・確認の分岐
データ結合 から分岐
- 日報IDと要約版で照合
- 同一イベント再投入を検知
- Slack送信をスキップ
日報の編集後は新しい要約版として承認対象にする想定
手動承認 から分岐
- 却下または承認期限切れを検知
- 送信と台帳記録を停止
- 原文と要約を修正先へ戻す
代理承認者と却下後の編集担当を導入前に決める
Slack 送信 から分岐
- API失敗を記録
- 上限回数まで再試行
- 台帳と送信先を手動確認
送信結果が不明な場合は成功を台帳へ記録しない
再実行や重複防止の扱いは、上の『例外・確認の分岐』に記載しています。
Verification checklist
検証時に確認する項目
- データ：個人情報、AIの処理先、保存期間、通知先に表示する項目を確認する。
- 認証：OAuthやAPIキーを最小権限にし、Webhook署名と秘密情報の更新・失効手順を確認する。
- 復旧：順序逆転、同時実行、レート制限、上限付き再試行、結果不明時の手動復旧を確認する。
- 承認：承認期限、代理承認者、却下・期限切れ後の修正先を確認する。人の承認を使わない手順では確認担当と停止条件を決める。
- 運用：運用担当者、停止・再開の判断者、障害時の連絡先を決める。
- 記録：実行結果と例外対応の記録先（台帳）と保存期間を決める。
Integrations & permissions
必要な連携と権限
PigeonCloud
日報追加イベントを受け、原文と更新情報を再取得します。
要約・手動承認
要約案を作り、原文リンクと一緒に担当者へ提示します。
Slack・Google スプレッドシート
承認済み要約の投稿と、日報ID・要約版の送信台帳に使います。
必要な権限・アカウント
- PigeonCloudの日報読み取り権限
- 対象テーブルのイベント受信と本文取得に使います。
- Slackの投稿権限
- 日報内容を共有できる対象チャンネルに限定します。
- Google スプレッドシートの編集権限
- 送信台帳の取得と記録に使います。
Exception handling
例外時の挙動
データ結合 から分岐
- 1. 日報IDと要約版で照合
- 2. 同一イベント再投入を検知
- 3. Slack送信をスキップ
日報の編集後は新しい要約版として承認対象にする想定
手動承認 から分岐
- 1. 却下または承認期限切れを検知
- 2. 送信と台帳記録を停止
- 3. 原文と要約を修正先へ戻す
代理承認者と却下後の編集担当を導入前に決める
Slack 送信 から分岐
- 1. API失敗を記録
- 2. 上限回数まで再試行
- 3. 台帳と送信先を手動確認
送信結果が不明な場合は成功を台帳へ記録しない
FAQ
よくあるご質問
この手順は検証済みですか？
設計例です。実機での検証記録はまだありません。検証時に確認する項目は本ページの一覧のとおりです
同じ日報を編集して再送したらどうしますか？
日報IDと要約版を台帳と照合し、内容が変わった版だけを新しい承認対象にする想定です。
要約に原文にない内容が入った場合はどうしますか？
承認担当者が原文リンクと要約を照合し、却下して修正先へ戻す想定です。
Related
親の活用シーンと関連レシピ
関連レシピ検証記録あり
PigeonCloudに申請が作成されたら入力を検査してSlackへ確認依頼を送る
申請の必須項目を検査し、正常時は確認依頼、不備時は不備内容を、未送信の検査版に限って通知する検証記録です。この検証はSlack 送信をメール送信に、Google スプレッドシート台帳を PigeonCloud の台帳テーブルに置き換えた構成で行った部分検証です。
関連レシピ設計例（未検証）
PigeonCloudの在庫数が発注点を下回ったらSlackへ通知する
PigeonCloudの計算項目「発注対象」を使って在庫更新を判定し、未送信の対象だけをSlackへ知らせる構成の設計例です。
関連レシピ設計例（未検証）
PigeonCloudの返却超過になった備品をSlackへ通知する
平日の定期実行で、PigeonCloudの計算項目「通知対象」が真かつ「通知済み」が偽のレコードを1件だけ取得し、Slack送信後に「通知済み」を真へ更新する構成の設計例です。