注文メールAI 抽出手動承認PigeonCloud

注文メールから必要項目を抽出し、承認後にPigeonCloudへ保存する

注文メールを受信し、AIで7項目を抽出。担当者が内容を確認・承認したものだけを、注文番号をキーにPigeonCloudへ追加または更新する、実機での社内検証結果をまとめたレシピです。

Fit

このレシピが向く条件と対象外

向いている業務

業種
メールで注文を受け付けている事業者(当社テスト環境で検証)
部門
メールで注文を受け付けている受注窓口(当社テスト環境で検証)
実行頻度
件名に『注文』を含むメールを 1 分ごとに確認し、届くたびに起動
作業量の試算
今回の計測では受信→起動 3〜61 秒、AI 抽出 1.4〜6.0 秒、保存 1.6〜2.4 秒(10 実行・社内検証)
Workflow

ワークフロー図

  1. 注文メールを受信

    EMAIL トリガー

  2. 注文の7項目を抽出

    AI 抽出

  3. 抽出結果を確認

    手動承認

  4. 承認済みの注文を保存

    PigeonCloud 保存

例外・確認の分岐

  • 手動承認 から分岐

    1. 抽出結果を却下
    2. PigeonCloud 保存をスキップ
    3. 処理を終了

    却下した注文は保存しない

  • PigeonCloud 保存 から分岐

    1. 注文番号を照合
    2. 同じ注文番号のレコードを確認
    3. 既存レコードを更新

    今回の同一メール再投入ではレコード数は増えず、既存の1件を更新

再実行や重複防止の扱いは、上の『例外・確認の分岐』に記載しています。

Evidence

検証した範囲と限界

検証日
2026-09-25
検証担当
当社テスト環境(社内検証)
正常系ログ要約
合成メール10実行で計測。A〜C の 21 項目のうち本文に明示された 20 項目は 20/20 で正しく抽出。残る 1 項目(希望納期の年)は本文に無い値を AI が補ったもので、正しさは未検証です。承認した注文は注文番号をキーに保存されました。受信→起動は3〜61秒、AI 抽出は1.4〜6.0秒、保存は1.6〜2.4秒でした。
例外系ログ要約
実行9123は却下により保存ノードをスキップ。同一メールの再投入ではワークフローが再起動し、承認後は作成0・更新1でした。承認前の同一注文2通は各1試行で1件になりましたが、同時承認の再現性は未確認です。
EMAIL トリガー、AI 抽出、手動承認、PigeonCloud 保存を接続したワークフロー
新規作成時の全体構成。手動承認の「承認」側を PigeonCloud 保存へ接続し、「却下」側は接続していません。
保存後に開き直したワークフロー全体図
保存後の全体図では「承認→保存」の線が描画されませんが、定義データには承認側の線が残り、実行も承認側だけに進みました。
注文メールの件名と本文を使うAI 抽出プロンプトの設定画面
EMAIL トリガーの件名と本文を差し込み、注文の7項目を抽出するプロンプトです。
抽出結果を確認する手動承認ノードの設定画面
抽出した7項目、元メール件名、Message-ID を担当者へ提示する手動承認の設定です。期限は24時間、配信先は未設定です。
注文番号をキーに追加または更新するPigeonCloud 保存ノードの設定画面
注文番号を重複判定のキーにし、「あれば更新、なければ追加する」を選んだ保存設定です。
注文の抽出結果を表示した承認待ち画面
編集画面下部の実行状態パネルに表示された承認待ちの状態です。
実行 9114 が 4/4 で完了した実行履歴
実行 9114 が承認後に PigeonCloud 保存まで完了した実行履歴です。
検証後に6件の注文が保存されたPigeonCloudのレコード一覧
検証後の PigeonCloud レコード一覧。注文番号6種類が1件ずつ保存されています。

確認済みの制限事項

  • ・Message-ID が本当にないメールの挙動は未検証です。
  • ・注文番号を抽出できないメールを承認した場合の upsert は未検証です。
  • ・同時承認での重複防止は1回のみの試行で、再現性は未確認です。
  • ・承認リンクの配信、24時間の承認期限切れ、添付ファイルからの抽出は未検証です。
  • ・件名に「注文」を含まない注文メールの取りこぼしは未検証です。
Integrations & permissions

必要な連携と権限

専用ノード

EMAIL トリガー

IMAP の受信箱を1分ごとに確認し、件名に「注文」を含むメールを受け取ります。

専用ノード

AI 抽出

件名と本文から注文番号、会社名、担当者、商品名、数量、希望納期、備考を抽出します。

専用ノード

手動承認

抽出した7項目、元メールの件名、Message-ID を表示し、担当者が承認または却下します。

専用ノード

PigeonCloud 保存

注文番号をキーに、あれば更新、なければ追加する設定で保存します。

必要な権限・アカウント

構築時:Pigeon Workflow の組織管理者
ワークフローの作成と各ノードの設定に必要です。
構築時:PigeonCloud の管理者
保存先テーブルの作成権限がある管理者が必要です。
運用時:メール受信箱(IMAP)の読み取り
注文メールを受け取るメールアカウントを EMAIL トリガーに設定します。
運用時:PigeonCloud の API キー
保存先テーブルへの追加・更新に使用します。
運用時:承認担当者の PW アカウント
抽出結果を確認し、承認または却下するために使用します。
Exception handling

例外時の挙動

手動承認 から分岐

  1. 1. 抽出結果を却下
  2. 2. PigeonCloud 保存をスキップ
  3. 3. 処理を終了

却下した注文は保存しない

PigeonCloud 保存 から分岐

  1. 1. 注文番号を照合
  2. 2. 同じ注文番号のレコードを確認
  3. 3. 既存レコードを更新

今回の同一メール再投入ではレコード数は増えず、既存の1件を更新

FAQ

よくあるご質問

同じメールを2回受けたらどうなりますか?

今回の同一 Message-ID・同一注文番号の再投入では、ワークフローは再度起動しました。承認後の保存は作成0・更新1となり、レコード数は増えませんでした。

承認を却下したらどうなりますか?

今回の検証では PigeonCloud 保存ノードがスキップされ、レコードは作られませんでした。

Message-ID がないメールはどうなりますか?

送信時に付けなかったメールにも受信サーバーが Message-ID を付けたため、本当にない状態での挙動は未検証です。

どのくらい時間がかかりますか?

10実行の社内検証では、受信から起動まで3〜61秒、AI 抽出は1.4〜6.0秒、承認から保存完了までは約5秒でした。保存ノード単体は1.6〜2.4秒です。

運用上の注意はありますか?

今回の検証では、保存後に開き直した編集画面で「承認→保存」の線が描画されませんでしたが、定義データには承認側の線が残り、実行も承認側だけに進みました。また、既読化を OFF にしても、今回の受信箱ではテストメールと既存の未読メールが既読になりました。編集画面の実行状態パネルに表示される承認待ちは最新の1件だけでした。

Related

親の活用シーンと関連レシピ

関連するページは準備中です。
Consultation

この手順を自社の条件で確認しませんか

利用中のツールと例外条件を伺い、必要な連携、権限、人が確認する場所を整理します。