メールは4通、依頼は2件。メール・フォームを台帳に自動登録するときの重複と訂正

たとえば「用紙Aを10冊」「先ほどの分は12冊に訂正」「別の研修にも10冊」「訂正メールを再送します」。4通のメールが届いても、台帳に残す依頼は12冊と10冊の2件です。届いた順に新しい行を増やすだけでは、訂正と再送まで注文にしてしまいます。

この4通は、訂正と再送の扱いを考える例です（想定例）。配布するExcelは、原文と判断を照らし合わせる記入表で、自動では取り込みません。

どこまで自動化するかを、受け付け方で選ぶ

今の受け付け方	最初に試す方法	人が判断する場面
項目が決まったフォーム	回答を表へ保存する標準機能から試す	回答の訂正、同じ人からの別依頼
定型メール	送信元・件名・項目の位置を指定できる連携機能を試す	書式が変わったメール、必要項目の不足
自由な文章と添付	必要な項目を抽出し、担当者が原文と照合してから台帳へ反映する	訂正対象、数量・単位、別注文か再送か

自社で使うフォームやメール、台帳の組合せに対応しているかを調べ、まず一つの受付先で試します。新規依頼だけでなく、訂正と再送を一通ずつ流し、台帳に二重登録されないことまで確かめてください。以下は、メールで届いた用紙注文の例です。

届いた原文は次の4通です。最初と3通目は本文も添付も同じですが、3通目は別の研修分だと分かった設定です。4通目は、2通目の訂正を送信者が再送したものです。

表1　メール3通と再送1通（2026-09-15、日本時間）

受信ID・時刻	原文の内容	添付
M01／09:00	用紙A・10冊・研修用	仕様A.txt
M02／09:10	R001を10冊から12冊へ訂正。追加注文ではない	なし
M03／09:20	用紙A・10冊・研修用。本文はM01と同じ	仕様A.txt
M04／09:40	09:10の訂正を再送。R001を12冊にする	なし

台帳へ反映する項目と、原文の保存先

まず、受信内容を見比べる「取込管理表」と、確定した依頼を扱う「業務台帳」を分けます。受信IDは届いたメールや回答を識別する番号、受付IDは業務上の一つの依頼を追う番号です。訂正メールが届いても、元の受付IDを使います。

連携元のIDは、受信箱やフォームの識別情報と組み合わせて記録します。複数の受信先をまとめる場合も、番号だけで同一と決めないためです。IDが取れない行には取込管理用の仮番号を付け、業務上の同一性が分かるまで自動確定しません。

表2　取り込む項目と点検の条件

項目群	記録する内容・確定条件	判断できないとき
受付ID・受信ID	文字で記録。受付と受信元の対応を残す	仮の管理番号で保留し、担当者が照合
品目・数量・依頼者	品目と依頼者は文字で記録。この用紙注文では数量は1以上の整数、単位は冊	未処理として確認待ち。不明を0にしない
原文参照・取込時刻	参照先と版、取込処理を始めた日時を記録	原文を開けなければ確定しない
状態・担当・訂正情報	状態を選択し、訂正時は対象と旧値新値を記録	担当と次の作業を残す

重量や作業時間を扱う業務では、小数を認めるか、kg・時間などどの単位で記録するかを別に決めます。取消は数量0の新規注文にせず、元の依頼に対する変更として扱います。

受付の判断と、処理が動いた記録は分けます。受付側には原文、確定した数量、訂正理由、担当を残し、取込側には試した日時と反映結果を残します。「取込済み」は台帳への反映が確かめられた状態を指し、出荷や支払いの完了を意味しません。

添付と原文を開けるようにしておく

抽出した値だけでなく、判断の根拠を開けるようにします。原文参照には保存先と版を記録し、添付がある場合はファイル名だけでなく、その取込時点の内容へ戻れるようにします。担当者が実際に参照先を開けるかも試します。

個人情報を含む原文は、保存目的、閲覧者、保持の見直し日、削除担当を決めて管理します。通知には必要最小限のIDと状態を載せます。フォームの回答が後から変わる場合は、照合に必要な取込時点の控えを、同じ管理ルールで扱います。

同じ文面でも、別の注文かもしれない

同じメールをもう一度読み込む処理と、送信者が送り直したメールでは、見分け方が違います。同じメールなら、受信番号・原文・登録済みの結果を見比べ、追加せずに終えられます。送り直されたメールには別の受信番号が付くため、元の注文と依頼内容まで確かめます。

本文や送信時刻が似ているだけの行は「重複候補」です。M03のような別依頼まで削除してはいけません。本例では09:22に依頼者へ問い合わせて別の研修分と分かり、R002として扱います。分からなければ保留のまま、次の担当を残します。問い合わせメールの分類や返信の下書きをAIに任せる場合も、判断できないものを保留に回す考え方は同じです（問い合わせ対応にAIを使う進め方）。

訂正は、元の注文へ反映する

訂正では対象の受付IDを指定して、既存行を更新します。M02では、R001の依頼者と旧値10冊を照らし合わせ、責任者Bが承認して12冊へ更新した後、反映を見ます。元の原文と変更履歴は、定めた保存範囲で残します。

管理表には、訂正対象ID、変更した項目、旧値新値、理由、承認者、処理時刻を記録します。対象が一意に決まらない場合や、台帳の値が想定した旧値と違う場合は、別の変更が先に入っていないかを調べます。推測で上書きしないのが訂正待ちの役割です。

M04が届いた時点ではR001は12冊です。先の訂正の再送だと分かれば、12冊をさらに加算したり、新たな12冊の行を作ったりしません。先へ連携済みの注文などは、台帳の更新だけで完了とせず、連携先の担当者にも訂正の扱いを問い合わせます。

訂正メールが先に届いても、12冊を10冊へ戻さない

4通を処理する前に、受付担当が「どの注文に対する、どの変更か」を確かめます。M1は注文O1の初回10冊、M2は同じO1の第2版12冊、M3は別の注文O2の10冊、M4はM2と同じ変更の再送、と対応付けた例です。文面が同じという理由だけで、この対応を自動で決めません。

訂正と再送を試す教材（ZIP）の intake では、上の対応付けを入力として、三つの受信順序を比較できます。

処理する順序	最後に残したい注文
M1→M2→M3→M4	O1は12冊、O2は10冊。注文2件・受信4通
同じ4通をもう一度処理	注文も受信元の件数も増えない
M2→M1→M3→M4	O1の新しい第2版を、遅れて届いた第1版で戻さない

2026年10月26日に三条件を計算し、いずれも注文2件、受信4通、業務上の変更3件として一致しました。原文から注文や版を読み取る処理は行っておらず、人が対応を決めた後の小さな模型です。

実際の連携では、元メールの番号、注文番号、訂正の版、同じ変更の再送を対応付けます。版や対象を特定できなければ確認待ちにします。新規注文を誤って再送扱いにして消していないかも、M3のような別依頼で確かめます。再送の試験では、件数が増えないことと、必要な2件が残ることを一緒に見てください。

取り込みが止まったら、反映先の台帳を見る

失敗と表示されても、既に台帳へ反映されている場合があります。3通目は台帳へ書き込んだ後、結果を記録する途中で接続が切れた設定です。09:30の再処理では、原文と台帳を見比べます。10冊が既に反映されているため、結果の記録だけを補います。行がなければ新規登録、反映有無が分からなければ保留です。

件数は「受信4通」「取込試行6回」「最終台帳2件」を分けて見ます。本例では途中失敗1回の履歴が残りますが、09:43時点の未解消失敗は0件です。失敗履歴の件数を、そのまま現在の未処理件数にしないでください。また、取込ログにすら入っていない受信もあるため、受信側の対象一覧との突合が必要です。

停止時は、最終正常時刻、対象ID、失敗理由、どの段階で止まったか、次の担当を一覧にします。通知先と再開担当に加え、通知も止まった場合の定時の見回りを用意します。例として、事務担当が始業時と終業前に受信一覧・取込ログ・台帳を照合し、不在時は責任者へ引き継ぐ運用が考えられます。

取込担当者向け：4通を処理した6回の記録

表3　4通のメールを、6回の取込試行で追う

想定例。日時はすべて2026-09-15、日本時間。原文参照は管理表「原文見本」のセルを示します。表の1行は1回の取込試行です。

試行	受付ID	受信ID	原文参照	取込時刻	処理状態	訂正対象ID	旧値新値	失敗理由	確認・台帳処置
T01	R001	M01	原文見本!A6	09:01	未処理 → 取込済み	—	未登録 → 10冊	—	必須項目を照合し、R001の10冊を確認。
T02	R001	M01	原文見本!A6	09:05	重複候補 → 重複確認済み	—	10冊 → 10冊（変更なし）	—	同一ID・原文・結果を確認。追加なし。
T03	R001	M02	原文見本!A7	09:11	訂正待ち → 取込済み	R001	10冊 → 12冊	—	責任者Bの承認後、R001を12冊へ更新。
T04	R002	M03	原文見本!A8	09:21	重複候補 → 失敗	—	未登録 → 10冊（結果未確認）	台帳書込後の結果記録中に接続中断（想定）。反映有無は未確認。	別依頼と確認後に中断。完了にしない。
T05	R002	M03	原文見本!A8	09:30	失敗 → 取込済み	—	10冊 → 10冊（追加なし）	—	既存のR002を照合。結果記録だけ補完。
T06	R001	M04	原文見本!A9	09:41	重複候補 → 重複確認済み	R001	12冊 → 12冊（変更なし）	—	M02の再送と確認。訂正を再適用しない。

最終結果は09:43時点で、R001＝用紙A・12冊、R002＝用紙A・10冊の2件です。T04の失敗履歴は消さず、T05で解消したことを記録します。フォーム補足例は、この4通・6回・2件に含めません。

実装担当者向け：Gmail・フォームの識別情報と利用上限

Gmailを使う実装では、Apps ScriptのGmailMessageにメッセージID、添付、本文・原文を取得する機能があります。保存先と閲覧できる担当者は、自社の運用に合わせて決めます。Google「Class GmailMessage」

同じIDでも、内容が変わっていれば以前の結果をそのまま流用しません。Google Forms API v1にはフォームID・回答ID・最終送信時刻・回答内容があります。これらを照合に使い、差分がある行は訂正待ちへ回す、という設計です。Google「REST Resource: forms.responses」

補足例では、フォームZの回答A01を3冊で登録後、同じ版の再取込は追加なしとします。次の取込で4冊への変更を見つけた場合は、回答IDが同じでも訂正待ちです。承認前の台帳は3冊のままにします。過去版を保存する仕組みは別途設計し、古い版が後から届いても最新値を戻さない点検を入れます。

Apps Scriptにはアカウント等によって異なる利用上限があり、上限超過時は例外が発生して実行が停止します。上限は予告なく変更され得るため、採用する機能と実行アカウントの条件を導入時・更新時に調べます。Google「Quotas for Google Services」

資料を使って、既製機能で足りるか確かめる

取込管理表（Excel）の「取込空欄」へ自社の例を入れ、「チェック空欄」で担当・保持方針・停止時の連絡先を埋めます。印刷して使う場合は、チェック表（PDF）も使えます。既製の連携機能で、受信IDの保持、例外の保留、訂正対象の指定、失敗一覧の確認まで扱えるなら、追加開発を急ぐ必要はありません。契約プランと実際の設定で確認します。

複数経路を同じ受付へまとめる、独自の承認が必要、反映結果を複数台帳で照合するといった条件がある場合は、追加の仕組みを検討します。

再試行の間隔、二重実行への技術的な備えは、API連携の要件｜待ち時間・再送・二重実行で説明しています。管理表は、実装担当へ渡す業務上の条件として使ってください。

複数のツールをつなぐ条件は、ツール・API連携の開発も参考になります。

添付された紙の注文票を扱う場合は、誤読や欄外追記を原本で確かめる工程も残します（紙・FAX・手書きのデータ化｜確認と訂正の進め方）。

メール・フォームの受付と台帳連携を相談する

参考出典

• Google「Quotas for Google Services」Apps Scriptの利用上限と停止条件（2026年9月3日更新、9月15日確認）
• Google「Class GmailMessage」メールID・添付・本文・原文の取得機能（2026年4月13日更新、9月15日確認）
• Google「REST Resource: forms.responses」フォームID・回答ID・最終送信時刻・回答内容（2026年2月24日更新、9月15日確認）