向いている業務
- 業種
- 契約書をBoxで管理する事業者
- 部門
- 法務・総務・購買
- 実行頻度
- ファイル追加のたび。週5〜15件を想定
- 作業量の試算（未実測）
- （未実測）月240分−承認0分−例外対応40分−運用保守60分＝月140分を想定
Box契約書Slack送信台帳
Boxに契約書が追加されたらSlackへレビュー依頼を通知する
Boxのファイル追加イベントを受け、実機で取得できるファイルID・名称などのメタデータだけを、未送信の契約書としてSlackへ知らせる構成の設計例です。
設計例（未検証）:
この手順は Pigeon Workflow のノードで組める構成として設計したもので、実機での検証記録はまだありません。導入時は下の「検証時に確認する項目」を自社条件で確認してください。
Fit
このレシピが向く条件と対象外
Workflow
ワークフロー図
ファイル追加を受信
Box 受信（自動起動）
契約書のメタデータを取得
Box 取得
通知項目を整形
AI データ加工
送信台帳を取得
スプレッドシート取得
ファイルIDを照合
データ結合
レビュー依頼を通知
Slack 送信
送信結果を台帳へ記録
スプレッドシート書き込み
例外・確認の分岐
データ結合 から分岐
- BoxファイルIDで照合
- 送信済みを検知
- 通知をスキップ
実機で取得できる識別子だけを台帳キーに使う
Box 取得 から分岐
- ファイルIDまたは名称の欠落を検知
- 通知を停止
- 担当者の確認対象に記録
契約書本文は取得・読解せず、実機で取得できるメタデータだけを扱う
Slack 送信 から分岐
- API失敗時は実行失敗として停止
- 結果不明時はSlackと送信台帳を照合
- 担当者が再実行
API失敗時は実行失敗として停止し、結果不明時は送信先と台帳を照合してから担当者が再実行する
データ結合 から分岐
- 同時実行では双方が未送信と判断する可能性を確認
- 起動間隔を空けて同時実行を避ける
- 1件ずつ処理
同時実行では双方が未送信と判断して重複送信があり得るため、同時実行を避ける運用にする
再実行や重複防止の扱いは、上の『例外・確認の分岐』に記載しています。
Verification checklist
検証時に確認する項目
- データ：個人情報、AIの処理先、保存期間、通知先に表示する項目を確認する。
- 認証：OAuthやAPIキーを最小権限にし、Webhook署名と秘密情報の更新・失効手順を確認する。
- 復旧：順序逆転、同時実行、レート制限、上限付き再試行、結果不明時の手動復旧を確認する。
- 承認：承認期限、代理承認者、却下・期限切れ後の修正先を確認する。人の承認を使わない手順では確認担当と停止条件を決める。
- 運用：運用担当者、停止・再開の判断者、障害時の連絡先を決める。
- 記録：実行結果と例外対応の記録先（台帳）と保存期間を決める。
Integrations & permissions
必要な連携と権限
Box
ファイル追加イベントを受け、実機で取得できるファイルID・名称などのメタデータだけを取得します。
Slack
契約書本文を含めず、実機で取得できるファイルID・名称などのメタデータだけを送ります。
Google スプレッドシート
ファイルIDと送信結果を送信台帳へ記録します。
必要な権限・アカウント
- Boxのイベント受信・読み取り権限
- 対象フォルダのメタデータ取得に限定します。
- Slackの投稿権限
- 契約情報を閲覧できるレビュー用チャンネルに限定します。
- Google スプレッドシートの編集権限
- 送信台帳の取得と記録に使います。
Exception handling
例外時の挙動
データ結合 から分岐
- 1. BoxファイルIDで照合
- 2. 送信済みを検知
- 3. 通知をスキップ
実機で取得できる識別子だけを台帳キーに使う
Box 取得 から分岐
- 1. ファイルIDまたは名称の欠落を検知
- 2. 通知を停止
- 3. 担当者の確認対象に記録
契約書本文は取得・読解せず、実機で取得できるメタデータだけを扱う
Slack 送信 から分岐
- 1. API失敗時は実行失敗として停止
- 2. 結果不明時はSlackと送信台帳を照合
- 3. 担当者が再実行
API失敗時は実行失敗として停止し、結果不明時は送信先と台帳を照合してから担当者が再実行する
データ結合 から分岐
- 1. 同時実行では双方が未送信と判断する可能性を確認
- 2. 起動間隔を空けて同時実行を避ける
- 3. 1件ずつ処理
同時実行では双方が未送信と判断して重複送信があり得るため、同時実行を避ける運用にする
FAQ
よくあるご質問
この手順は検証済みですか？
設計例です。実機での検証記録はまだありません。検証時に確認する項目は本ページの一覧のとおりです
契約書の本文も判定しますか？
この構成は本文を読解せず、実機で取得できるファイルID・名称などのメタデータだけを通知する想定です。
契約書が更新されたら再通知しますか？
初期構成はファイル追加イベントとファイルIDを対象にします。更新時の再通知は、実機で取得できるイベントと識別子を確認してから設計する想定です。
Related
親の活用シーンと関連レシピ
関連レシピ設計例（未検証）
PigeonCloudの在庫数が発注点を下回ったらSlackへ通知する
PigeonCloudの計算項目「発注対象」を使って在庫更新を判定し、未送信の対象だけをSlackへ知らせる構成の設計例です。
関連レシピ設計例（未検証）
Airtableの在庫が発注対象になったらSlackへ通知する
対象レコードIDを指定する手動実行でAirtableの1件を取得し、「通知対象」が真ならSlackへ知らせて通知済みにする構成の設計例です。Airtable側で「通知対象」と通知エピソードIDを計算し、対象レコードIDを1件ずつWebhookへ渡せることを実機確認できた場合だけ自動化します。
関連レシピ設計例（未検証）
Google Calendarの当日予定を一覧にしてSlackへ共有する
毎朝の定期実行で当日の予定を取得し、visibility等の確定項目で公開範囲を分け、非公開予定は時刻だけにした一覧を1通だけSlackへ共有する構成の設計例です。