向いている業務
- 業種
- Google Calendarを共有する事業者
- 部門
- 営業・カスタマーサポート・採用
- 実行頻度
- 平日毎朝1回。当日分を一覧1通に集約
- 作業量の試算(未実測)
- (未実測)月300分−承認0分−例外対応40分−運用保守60分=月200分を想定
毎朝の定期実行で当日の予定を取得し、visibility等の確定項目で公開範囲を分け、非公開予定は時刻だけにした一覧を1通だけSlackへ共有する構成の設計例です。
設計例(未検証):
この手順は Pigeon Workflow のノードで組める構成として設計したもので、実機での検証記録はまだありません。導入時は下の「検証時に確認する項目」を自社条件で確認してください。
当日予定を毎朝取得
定期実行(自動起動)
当日の予定一覧を取得
Google Calendar 取得
visibility等の確定項目で判定
条件で分岐
時刻と件名を一覧化
文章生成
予定一覧を共有
Slack 送信
送信結果を台帳へ記録
スプレッドシート書き込み
Slack 送信 から分岐
事前照合と出力後記録だけでは、並行実行時に重複する可能性があります。一意キーの処理中状態を原子的に確保できる台帳、出力先の一意制約・upsert、または同時実行数1を実機確認できた場合だけ自動運用し、それまでは重複の可能性を前提に担当者が出力先を照合します。
条件で分岐 から分岐
非公開判定はAIに任せません。Google Calendarから取得できるvisibility等の確定項目で分岐し、非公開または判定項目を取得できない予定は時刻だけを残し、件名・担当者・会議URLを送信しません。判定項目を確認できない場合は公開用カレンダーだけを対象にします。
Slack 送信 から分岐
API失敗時は実行失敗として停止します。自動再試行は前提にせず、結果不明時は出力先と台帳を照合してから担当者が手動で再実行します。
再実行や重複防止の扱いは、上の『例外・確認の分岐』に記載しています。
対象カレンダーから当日分とvisibility等の確定項目を取得します。取得件数とページングは導入前に確認します。
公開可能な予定は時刻と件名を、非公開予定は時刻だけを朝会用チャンネルへ一覧1通で送ります。
カレンダーID、対象日、送信結果を送信台帳へ記録します。
Slack 送信 から分岐
事前照合と出力後記録だけでは、並行実行時に重複する可能性があります。一意キーの処理中状態を原子的に確保できる台帳、出力先の一意制約・upsert、または同時実行数1を実機確認できた場合だけ自動運用し、それまでは重複の可能性を前提に担当者が出力先を照合します。
条件で分岐 から分岐
非公開判定はAIに任せません。Google Calendarから取得できるvisibility等の確定項目で分岐し、非公開または判定項目を取得できない予定は時刻だけを残し、件名・担当者・会議URLを送信しません。判定項目を確認できない場合は公開用カレンダーだけを対象にします。
Slack 送信 から分岐
API失敗時は実行失敗として停止します。自動再試行は前提にせず、結果不明時は出力先と台帳を照合してから担当者が手動で再実行します。
設計例です。実機での検証記録はまだありません。検証時に確認する項目は本ページの一覧のとおりです
投稿しません。当日分を開始時刻順の一覧にまとめ、朝の実行で1通だけ送る想定です。
非公開判定はvisibility等の確定項目で行い、非公開または判定項目を取得できない予定は時刻だけを残します。判定項目を取得できない場合は公開用カレンダーだけを対象にします。取得ノードでAsia/Tokyoの当日開始・終了を動的に指定できることを導入前に確認し、確認できない場合は対象日を指定する手動実行に変更します。
PigeonCloudの計算項目「発注対象」を使って在庫更新を判定し、未送信の対象だけをSlackへ知らせる構成の設計例です。
Boxのファイル追加イベントを受け、実機で取得できるファイルID・名称などのメタデータだけを、未送信の契約書としてSlackへ知らせる構成の設計例です。
対象レコードIDを指定する手動実行でAirtableの1件を取得し、「通知対象」が真ならSlackへ知らせて通知済みにする構成の設計例です。Airtable側で「通知対象」と通知エピソードIDを計算し、対象レコードIDを1件ずつWebhookへ渡せることを実機確認できた場合だけ自動化します。