向いている業務
- 業種
- メールで注文を受け付けている事業者(当社テスト環境で検証)
- 部門
- メールで注文を受け付けている受注窓口(当社テスト環境で検証)
- 実行頻度
- 件名に『注文』を含むメールを 1 分ごとに確認し、届くたびに起動
- 作業量の試算
- 今回の計測では受信→起動 3〜61 秒、AI 抽出 1.4〜6.0 秒、保存 1.6〜2.4 秒(10 実行・社内検証)
注文メールを受信し、AIで7項目を抽出。担当者が内容を確認・承認したものだけを、注文番号をキーにPigeonCloudへ追加または更新する、実機での社内検証結果をまとめたレシピです。
注文メールを受信
EMAIL トリガー
注文の7項目を抽出
AI 抽出
抽出結果を確認
手動承認
承認済みの注文を保存
PigeonCloud 保存
手動承認 から分岐
却下した注文は保存しない
PigeonCloud 保存 から分岐
今回の同一メール再投入ではレコード数は増えず、既存の1件を更新
再実行や重複防止の扱いは、上の『例外・確認の分岐』に記載しています。








IMAP の受信箱を1分ごとに確認し、件名に「注文」を含むメールを受け取ります。
件名と本文から注文番号、会社名、担当者、商品名、数量、希望納期、備考を抽出します。
抽出した7項目、元メールの件名、Message-ID を表示し、担当者が承認または却下します。
注文番号をキーに、あれば更新、なければ追加する設定で保存します。
手動承認 から分岐
却下した注文は保存しない
PigeonCloud 保存 から分岐
今回の同一メール再投入ではレコード数は増えず、既存の1件を更新
今回の同一 Message-ID・同一注文番号の再投入では、ワークフローは再度起動しました。承認後の保存は作成0・更新1となり、レコード数は増えませんでした。
今回の検証では PigeonCloud 保存ノードがスキップされ、レコードは作られませんでした。
送信時に付けなかったメールにも受信サーバーが Message-ID を付けたため、本当にない状態での挙動は未検証です。
10実行の社内検証では、受信から起動まで3〜61秒、AI 抽出は1.4〜6.0秒、承認から保存完了までは約5秒でした。保存ノード単体は1.6〜2.4秒です。
今回の検証では、保存後に開き直した編集画面で「承認→保存」の線が描画されませんでしたが、定義データには承認側の線が残り、実行も承認側だけに進みました。また、既読化を OFF にしても、今回の受信箱ではテストメールと既存の未読メールが既読になりました。編集画面の実行状態パネルに表示される承認待ちは最新の1件だけでした。