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