向いている業務
- 業種
- 社内申請をPigeonCloudで管理する事業者
- 部門
- 総務・経理・現場管理
- 実行頻度
- 申請作成時に起動。検証では7回（正常2回・不備5回）を1件＝1実行で起動
- 作業量の試算
- （未実測）月600分−承認0分−例外対応80分−運用保守60分＝月460分を想定
PigeonCloud申請入力チェックSlack
PigeonCloudに申請が作成されたら入力を検査してSlackへ確認依頼を送る
申請の必須項目を検査し、正常時は確認依頼、不備時は不備内容を、未送信の検査版に限って通知する検証記録です。この検証はSlack 送信をメール送信に、Google スプレッドシート台帳を PigeonCloud の台帳テーブルに置き換えた構成で行った部分検証です。
Fit
このレシピが向く条件と対象外
Workflow
ワークフロー図
申請作成を受信
PigeonCloud Webhook
申請内容を再取得
PigeonCloud 取得
必須項目と形式を検査
入力チェック
検査結果で通知内容を分ける
条件で分岐
送信台帳を取得
スプレッドシート取得
申請IDと検査版を照合
データ結合
確認依頼を通知
Slack 送信
送信結果を台帳へ記録
スプレッドシート書き込み
例外・確認の分岐
入力チェック から分岐
- 正常なら申請IDと確認URLを用意
- 不備なら不足項目を用意
- 確認担当へ渡す
Slack通知は確認依頼であり、承認結果は受け取らない
データ結合 から分岐
- 申請IDと検査版で照合
- 送信済みなら通知を停止
- 内容変更時は新しい検査版にする
同じ検査版を重ねて送らない想定
Slack 送信 から分岐
- API失敗時は実行失敗として停止
- 結果不明時はSlackと送信台帳を照合
- 担当者が再実行
API失敗時は実行失敗として停止し、結果不明時は送信先と台帳を照合してから担当者が再実行する
データ結合 から分岐
- 同時実行では双方が未送信と判断する可能性を確認
- 起動間隔を空けて同時実行を避ける
- 1件ずつ処理
同時実行では双方が未送信と判断して重複送信があり得るため、同時実行を避ける運用にする
再実行や重複防止の扱いは、上の『例外・確認の分岐』に記載しています。
Evidence
検証した範囲と限界
- 検証日
- 2026-10-01
- 検証担当
- ロフタル社内検証（本番デモ組織 org 23・合成データ専用テナント）
- 正常系ログ要約
- この検証はSlack 送信をメール送信に、Google スプレッドシート台帳を PigeonCloud の台帳テーブルに置き換えた構成で行った部分検証です。正常2回・不備5回を実行し、作成操作から完了確認まで12〜14秒でした。正常時は確認依頼メール、不備時は不備内容メールを各1通送り、申請に検査結果を書き戻して台帳へ1行を追加しました。7通とも受信側で迷惑メールと判定されました。
- 例外系ログ要約
- 同一ペイロードの再送1回は台帳照合で終了し、メール0通・台帳追加0件でした。存在しない申請IDの1回は再取得0件となり、入力チェックと台帳照合の後の分岐で終了して、メール0通・書き込み0件でした。金額未入力の申請 1 回では入力チェックが不備を検出したものの、不備メールの送信を受信側メールサーバーが拒否したため、後段の検査結果の書き戻しと台帳保存は実行されず、実行は一部失敗で終わり、申請は未検査のまま残りました。
確認済みの制限事項
- ・この検証はSlack 送信をメール送信に、Google スプレッドシート台帳を PigeonCloud の台帳テーブルに置き換えた構成で行った部分検証です。原設計のSlack 送信とGoogle スプレッドシート台帳は未検証です。
- ・同時に複数申請が作られた並行実行と、その場合の重複は未検証です。
- ・メール送信成功後に台帳保存が失敗する障害窓と、その後の再実行は未検証です。
- ・メール送信失敗後の再実行手順は未検証です。
- ・更新イベントでの再検査と版管理は未検証です。
- ・Webhookの送信元認証とリプレイ耐性は未検証です。
- ・10分以上あとの遅延・重複配送は未検証です。
- ・実データと長期運転は未検証です。
- ・PigeonCloud画面から手入力で作成する経路は未検証です。今回は公開APIで作成しました。
- ・検証で送ったメール7通は、受信側で迷惑メールと判定されました。
Integrations & permissions
必要な連携と権限
PigeonCloud
申請作成イベントを受け、検査対象の最新内容を再取得します。
Slack
正常時は申請IDと確認URL、不備時は不足項目と修正先を送ります。
Google スプレッドシート
申請ID、検査版、送信結果を送信台帳へ記録します。
必要な権限・アカウント
- PigeonCloudのWebhook・読み取り権限
- 申請作成イベントの受信と対象レコード取得に使います。
- Slackの投稿権限
- 申請情報を共有できる確認用チャンネルに限定します。
- Google スプレッドシートの編集権限
- 送信台帳の取得と記録に使います。
Exception handling
例外時の挙動
入力チェック から分岐
- 1. 正常なら申請IDと確認URLを用意
- 2. 不備なら不足項目を用意
- 3. 確認担当へ渡す
Slack通知は確認依頼であり、承認結果は受け取らない
データ結合 から分岐
- 1. 申請IDと検査版で照合
- 2. 送信済みなら通知を停止
- 3. 内容変更時は新しい検査版にする
同じ検査版を重ねて送らない想定
Slack 送信 から分岐
- 1. API失敗時は実行失敗として停止
- 2. 結果不明時はSlackと送信台帳を照合
- 3. 担当者が再実行
API失敗時は実行失敗として停止し、結果不明時は送信先と台帳を照合してから担当者が再実行する
データ結合 から分岐
- 1. 同時実行では双方が未送信と判断する可能性を確認
- 2. 起動間隔を空けて同時実行を避ける
- 3. 1件ずつ処理
同時実行では双方が未送信と判断して重複送信があり得るため、同時実行を避ける運用にする
FAQ
よくあるご質問
この手順は検証済みですか？
上の構成で 2026-10-01 に社内検証しました。Slack 送信とスプレッドシート台帳の部分は設計のままで未検証です。
Slack上で申請を承認できますか？
この構成は確認依頼の通知だけです。承認結果は受け取らず、確認URLから元の申請を確認する想定です。
申請を修正したら再通知しますか？
申請IDと検査版を台帳で照合し、内容が変わった新しい検査版だけを通知する想定です。
Related
親の活用シーンと関連レシピ
関連するページは準備中です。