受発注メールから受注データを取り出す手順——コピペを続けなくていい



受発注メールからの受注データ抽出は、4つの手順に分解できる。①CSVもAPIも無いメールだけに対象を絞る、②取り出す項目を品番・数量・納期の3つから始める、③AIに推測させず欠損はnullで返させる、④商品マスタか過去の受注実績で照合してから台帳に入れる。モールの注文通知メールは抽出対象にしない。

• モールの注文通知メールは解析対象から外す。CSV・APIが公式の取得経路であり、本文解析は精度でもコストでも劣る
• 抽出を壊すのはAIの性能ではなく、引用付き返信・後追いの訂正メール・ケース入数の換算・署名欄の住所というメール側の事情である
• AIの出力をそのまま台帳に入れない。原本メールのメッセージIDを台帳の列に持ち、間違いを1件ずつ元のメールへ戻せる状態を先に作る

抽出する前に、抽出しなくていいメールを外す

受注メールの自動化を考え始めると、たいてい最初に手が伸びるのは楽天やAmazonの注文通知メールだ。毎日いちばん多く届き、いちばん目に付くからである。受信トレイの中で件数を占めているのはこの手のメールで、「これが全部スプレッドシートに落ちたら楽になる」と考えるのは自然な発想だと思う。

ただ、ここは手を付けない方がいい。楽天ならRMSの受注管理からCSVを落とせるし、AmazonならセラーセントラルのレポートやSP-API経由で同じデータが取れる。Shopifyも管理画面の注文一覧からCSVエクスポートができる。同じ情報が、すでに列と行の形で公式に配られている。それを、いったん日本語の文章に整形されたメール本文から読み直そうとするのは、構造化されたデータをわざわざ非構造化してから再構造化する作業になる。

差は精度に出る。CSVには「商品管理番号」「モール別商品番号」「注文番号」といった列名が最初から付いていて、どの値が何なのかを人も機械も取り違えようがない。一方でメール本文は、モール側のテンプレート変更ひとつで行の並びが変わる。キャンペーン告知が1行挿入されただけで、行位置に依存した解析は壊れる。運用が始まったあとに、誰も気づかないまま数字がずれ始めるのがいちばん厄介な壊れ方だ。

だから本記事が対象にするのは、CSVもAPIも用意されていないメールだけである。具体的には、卸・BtoBの得意先から人の手で書かれて届く発注メール、代理店や小売店からの追加発注、自社サイトの問い合わせフォーム経由で来る個別注文といったものだ。これらには「注文データを配る公式の口」が存在しない。本文の日本語がそのまま一次データになっている。ここだけがAIに読ませる価値のある領域になる。

もうひとつ、先に線を引いておきたい。本記事は品番・数量・納期を主役にする。届け先の氏名・住所・電話番号といった個人情報を外部のAIに渡してよいかという話は、扱う論点がまったく別なので踏み込まない。マスキングの考え方は受注処理をAIで効率化するときの個人情報の扱いにまとめてある。また、受注から在庫引当・出荷指示までを含めた全体像で「どこまで機械に任せるか」を決めたい場合は、EC受発注・在庫管理の自動化を先に読んだ方が早い。本記事はその中の一区間だけを扱う。

なお、受信トレイに届いたメールをラベルやフィルタで振り分ける工程も、ここでは扱わない。仕分けと抽出は別の作業である。仕分けの手順はノーコードで受発注メールを自動仕分けしてみたにある。本記事は、仕分けが終わって「これは発注メールだ」と分かった1通を開いたところから始まる。

AIに渡す前に、正規表現で済むメールを見分ける

次にやることは、絞り込んだメールをさらに二分することだ。AIを使わなくても取り出せるメールが、この中にかなり混ざっている。ここを分けずに全部をAIに投げると、費用も待ち時間も、そして「なぜこの値になったのか分からない」という不透明さも、無駄に背負うことになる。

判断の基準は1文で書ける。その値が何であるかを、文章の意味を読まずに、目印だけで特定できるか。目印というのは、キーワード（「品番：」「数量：」）、記号（コロン、タブ、パイプ）、位置（何行目の何文字目）のことだ。これで特定できるなら正規表現や文字列処理で足りる。特定できず、日本語として読まないと分からないならAIが要る。

観点	正規表現・文字列処理で足りる	AIが要る
送信元	特定アドレス・特定ドメインで固定	担当者ごとにアドレスがバラバラ
件名	「ご注文」「発注書」など固定文字列	件名が毎回自由文
本文の形	「品番：」「数量：」のラベルが毎回同じ／表形式が固定	依頼が地の文に溶けている
発行元	システムが自動送信（受注システム・EDI・フォーム通知）	人が手で書いている

実務上の近道は、送信元アドレスが機械なら正規表現、人間ならAIと覚えることだ。自動送信メールは文面テンプレートが固定なので目印が壊れない。逆に、人が毎回打っているメールは、同じ会社の同じ担当者であっても文面が揺れる。この一線で切るだけで、AIに渡す対象は目に見えて減る。

ただし、この基準が破綻するケースが3つある。ここを知らないと、あとで「ルールを作ったのに動かない」という状態にはまる。

1つ目はルールベースの泥沼だ。取引先が50社あればテンプレートも50通りあり、さらに同じ会社でも担当者の癖で例外が増えていく。1社ずつなら形式的に解けるのだが、書式パターンが増えるほど保守が重くなり、どこかでルールを書き続けるコストがAIの利用料を上回る。目安としては書式パターンが10を超えたあたりから逆転しやすい。ただしこれは構造から導いた目安であって、実測値ではない。自社の取引先数と、月にルールを何回直しているかを数えて判断してほしい。

2つ目は形式と意味のハイブリッドである。本文は「品番：ABC-100／数量：50」と整っているのに、件名が「【ご相談】ABC-100の在庫確認」だった、という状況を想像すればいい。正規表現は品番も数量も正しく抜き出す。だが、そもそもこのメールは発注ではない。形式的に値を抜き出す仕事と、これが発注かどうかを判定する仕事は別物だ。前者は正規表現でよくても、後者にはAIが要る。

3つ目は社外のデータが要るケースだ。「いつものやつを10ケースお願いします」というメールには品番が存在しない。これは正規表現でもAIでも解けない。過去の受注実績や得意先別の定番品リストを引き当てないと決まらないからで、モデルの性能ではなく設計の問題である。この型は後半で扱う。

取り出す項目を先に決める — 品番・数量・納期の3つから

着手時にやりがちなのは、いま使っている受注台帳を開いて、その列をそのまま抽出項目の一覧にすることだ。得意先コード、担当者名、品番、品名、数量、単価、金額、納期、納品先、送料区分、備考。列が30あれば30項目を取りに行きたくなる。ここで先に決めるべきなのは台帳の列ではなく、AIに返させるデータの形のほうである。

返させる形はJSONと呼ばれる書き方で指定するのが一般的だが、身構える必要はない。要はスプレッドシートの1行が、どの列とどの列でできているかを文字で書いたものだと考えればいい。「品番という列があって、そこには文字が入る」「数量という列があって、そこには整数が入る」を機械が読める形で並べただけである。

最初に取りに行くのは3項目でいい。

• 品番（文字列。得意先が書いてきた表記のまま。自社の商品管理番号への変換は後工程でやる）
• 数量（整数。単位の換算はしない。書いてあった単位も別項目で持つ）
• 納期（日付。YYYY-MM-DD形式。相対表記は変換せず、後述のとおりnullにする）

3つから始める理由は3つある。1つ目は、この3つが欠けたら受注として成立しないからだ。逆に言えば、単価も備考も、後から人が埋められる。まず「注文の骨」だけを機械に取らせる。

2つ目は、項目を増やすほど検算の手間が線形に増えるからである。10項目を取らせれば、10項目分の「これは合っているか」を確認する仕組みを作らなければならない。最初から10列を自動で埋めようとして、結局どの列も信用できず全部を目視することになる、というのが最も無駄な着地だ。

3つ目は仕様側の事情だ。Geminiの構造化出力のドキュメントには「非常に大きい、あるいは深くネストしたスキーマは拒否されることがある」と明記されている（2026-08-10時点の記述）。OpenAIのStructured Outputs側も、strictモードでは全フィールドを必須として指定しなければならないという制約がある。つまり項目を増やすほど「必ず何かを埋めろ」という圧力がモデルにかかる。埋められない欄を用意することが、そのまま作り話を誘発する。

この制約への正しい対処が、任意項目を「文字列またはnull」という合併型で定義することだ。OpenAIのドキュメントも、任意項目はnullとの合併型で表現する方法を案内している（2026-08-10時点）。実務の言葉に直せば、「書いてなければ空欄で返してよい、という許可を明示的に与える」ということである。この許可がないと、モデルは欄を埋めるために本文にない値を持ってくる。

3項目で1〜2週間動かして、人が毎回手で足している列が見えてきたら、そこで初めて項目を追加する。追加候補になりやすいのは、得意先名（送信元ドメインから引ける場合が多いのでAIに取らせなくてよいことがある）、単位（ケース・本・個）、納品先の識別子、そして「原文のどこから取ったか」を示す抜粋である。最後の1つは検算に直結するので、実質的には最初から入れておいてよい。

メール本文の何が抽出を壊すのか

ここが本記事の中心になる。抽出がうまくいかないとき、原因はモデルの賢さではなくメールの側の事情にあることがほとんどだ。しかもその事情は、大きく3系統に整理できる。自社に届いている発注メールがどれに当たるかを分類してから対策を選ぶと、無駄な試行錯誤が減る。

A. 1通の中に情報が多すぎて壊れる

いちばん頻繁に踏むのが引用付き返信だ。得意先が前回の発注メールに返信する形で新しい発注を書いてくると、行頭に「>」の付いた前回分の本文が同じメールの中に丸ごと残る。人間は引用部分を過去の話として読み飛ばすが、機械にはその常識がない。品番と数量のセットが本文中に2つ見つかったとき、どちらが今回の注文なのかを決める根拠が、本文の中に存在しない。結果として前回分を今回分として二重に計上する。対策は前処理側にある。行頭が「>」の行、および「—–Original Message—–」や「差出人:」以降を切り落としてからAIに渡す。これは正規表現の仕事で、AIに頼む部分ではない。

もうひとつ厄介なのが問い合わせと発注の混在である。「ABC-100を10個お願いします。DEF-200は在庫ありますか？あれば5個追加で」という書き方は珍しくない。品番と数量だけを機械的に拾うと、まだ確定していないDEF-200の5個まで受注として登録される。確定・条件付き・単なる質問が、同じ日本語の形で1通に同居している。これは抽出ではなく意図判定の問題で、指示文の側で「確定した発注だけを取り出す」と明示しないと必ず混ざる。

B. 1通では完結しないので壊れる

「先ほどの数量、3を5に変更してください」という訂正メールが後追いで届くのは、卸の受注では日常だと思う。この1通には品番が書かれていないことが多い。「さっき」が何を指すかはスレッド全体を見ないと決まらないし、そもそも訂正は新しい行を作る操作ではなく、既存の行を書き換える操作である。1通単位で処理する設計のままだと、訂正メールが独立した新規注文として台帳に1行増える。キャンセルや納期変更も同じ構造で、更新・削除であるべきものが受注として積み上がっていく。

そして最も危険なのが「いつものやつを10ケース」である。品番がメールの中に存在しない。人間の担当者は過去の取引を思い出して補完できるが、AIはその過去を知らない。にもかかわらず、品番の欄を埋めろと指示されていれば、それらしい品番を作って返す。形式は完璧で、値だけが嘘になる。これが実務でいちばん見つけにくい誤り方だ。同種の型として「先ほど電話でお話しした件、正式に発注します」がある。発注の核心がメールの外にあるので、抽出は原理的に成功しようがない。この2つは精度を上げて解く問題ではなく、取り出せないことを検知して人に回すのが正解である。

C. 表記の揺れで壊れる

数量まわりで実害が大きいのが入数（ケース）換算だ。「3ケース」と書かれていて、台帳が「本」単位なら、入れるべき値は3ではなく36になる。ところが「1ケース12本入り」という換算式は、本文にしか書かれていないか、どこにも書かれず取引先との暗黙知になっていることが普通にある。単位を取り違えると誤差が12倍になる。だからこそ、AIには換算をさせず、書かれた数字と書かれた単位をそのまま別々に返させて、換算は自社の入数マスタで行う設計にする。

次に署名欄の住所を配送先と誤認する事故がある。署名は本文末尾に必ずあり、郵便番号から始まる整った形をしている。一方で本当の配送先は「今回はいつもの倉庫じゃなくて大阪の支店に送ってください」のように口語で書かれる。機械は、形の整った方を住所として選ぶ。署名がいちばん「きれいな住所」だからだ。本記事は配送先を扱わないが、この構造は覚えておいた方がいい。

残りの壊れ方を一覧にしておく。自社のメールを1週間分ながめて、どれが当てはまるかに印を付けてみてほしい。

壊れ方	なぜ機械が間違えるか
1通に複数商品・複数納品先	「どの数量がどの品番に係るか」は行の並びというレイアウトで表現されている。プレーンテキスト化した時点で対応関係が消える
表がHTML本文やExcel添付にある	HTML整形を落とすと表組みは1本の長い文字列になる。添付側に本体があれば、本文解析ではそもそも情報が存在しない
全角・桁区切り・単位の混在	「1,200」を数値化すると1と200に割れる。「１２００」は半角数字の正規表現に一致しない。桁が変わる誤りは金額と在庫に直撃する
相対日付（来週火曜・月末・なるはや）	絶対日付に直すにはメール受信日と営業日カレンダーが要る。AIは受信日を知らないので実行日などを勝手に基準にする
付帯条件（分納指示・製造番号指定）	3項目のスキーマに入る場所が無い。スキーマに無い情報はエラーも出さずに静かに捨てられる

抽出の指示文の作り方 — 推測させない、欠損はnullで返させる

前章の壊れ方を踏まえると、指示文に書くべきことはほぼ自動的に決まる。以下は出発点として使える骨格である。自社の得意先の書き方に合わせて規則を足していく前提の、出発点だと思ってほしい。

あなたは受注担当のアシスタントです。
以下のメール本文から、確定した発注の明細だけを取り出してください。

# 規則
1. 本文に書かれていないことは推測しない。分からない項目は null にする。
2. 行頭が > の行、および「-----Original Message-----」「差出人:」より
   後ろは、過去のやり取りとして無視する。
3. 確定した発注だけを対象にする。「在庫はありますか」「あれば追加で」
   のような未確定の依頼は取り出さない。
4. 明細1件につき1件返す。1通に複数商品があれば複数件返す。
5. 数量は本文の数字をそのまま整数で返す。ケースから本への換算はしない。
   書かれていた単位は unit にそのまま入れる。
6. 納期は YYYY-MM-DD 形式のみ。「来週火曜」「月末」「なるはや」などの
   相対表記は変換せず null にし、原文を due_date_raw に入れる。
7. 各明細について、その値を取り出した箇所をメール本文からそのまま
   1行以内で source_text に引用する。引用できない項目は null にする。
8. 本文に「変更」「訂正」「キャンセル」「取消」の語がある場合は
   needs_human を true にする。

# 返す項目（明細1件ぶん）
item_code    品番（文字列 または null）
quantity     数量（整数 または null）
unit         単位（文字列 または null）
due_date     納期 YYYY-MM-DD（文字列 または null）
due_date_raw 納期の原文（文字列 または null）
source_text  抽出根拠となる原文の引用（文字列）
needs_human  人の確認が必要か（true / false）

# メール本文
（ここに本文を貼る）

この指示文で意図的にやっていないことが1つある。AIに「確信度」を返させていない。「自信のない項目には低いスコアを付けてください」という設計は一見よさそうに見えるが、勧めない。大規模言語モデルの自己申告の確信度は較正が悪く、間違っているときほど自信を持って答える傾向が指摘されている（この点は複数の研究レビューを経由した二次情報で、個別論文までは確認できていない。自社で採用する前に検証してほしい）。スコアを閾値で切る運用は、根拠のない数字で仕分けをしているのと変わらなくなる。

代わりに置いたのが規則7の source_text である。AIに自信を聞くのではなく、原文のどこから取ったのかを言わせる。これなら機械が検証できる。返ってきた引用文が、元のメール本文に文字列として実際に含まれているかを照合すればいいだけだからだ。含まれていなければ、その値は本文になかったものを持ってきたということになる。自己申告と違い、こちらは第三者が確かめられる。

もう一段しっかりやるなら、APIの構造化出力機能を使って、返す形そのものを型で縛る方法がある。OpenAIのStructured Outputsは strict を有効にするとスキーマ準拠を強制し、拒否した場合は通常の回答とは別物として検出できる形で返る。Geminiの構造化出力も、JSON Schemaの一部に対応した形でスキーマを渡せる。Gemini側のドキュメントには、説明文フィールドがモデルの挙動を導くという記述があり、「本文に書かれていない場合はnull」といった注意をそこに書いておくのが実務的に効く（いずれも2026-08-10時点の記述）。ただし、パラメータの正確な名前は利用しているSDKの版で異なる。本記事では特定の綴りを書かない。お使いのSDKの公式ドキュメントを開いて、そこにある名前を使ってほしい。

そして、ここが最も誤解されやすい点になる。JSONの形が正しいことと、書いてある数量が正しいことは、まったく別の話である。Geminiのドキュメントは「構文としては正しいJSONが返るが、値は必ずアプリケーション側で検証すること」と明記している（2026-08-10時点）。OpenAI側も、仕様として保証されているのはスキーマへの準拠であり、値の正しさを保証する記述は置かれていない。形が整った出力が返ってきた瞬間に「うまくいった」と感じてしまうが、この安心感が次の章を飛ばさせる。

出力を信じないための検算 — 8割で人に渡す線引き

検算に使ってよいのは、機械が自力で判定できるものだけだ。人が目で見て「なんとなく合っていそう」は検算ではない。台帳に書き込む前に、次の4つを通す。

1. source_text が本文に含まれるか。含まれなければ、その明細は本文に無いものを返している
2. 品番が手元のリストに存在するか。1文字でも違えば別物として弾く。あいまい一致で寄せない
3. 数量が整数か、過去の受注実績の最大値を超えていないか。桁が1つ増える誤りはここで止まる
4. 納期が YYYY-MM-DD として解釈できるか。できなければ相対表記のまま来ている

もう1つ、効く割に軽い手が同じメールを2回抽出して突き合わせる方法である。2回の結果が一致しない明細は、そもそも本文が曖昧だという合図になる。件数が多ければコストが倍になるので、金額の大きい取引先だけに絞るなど、適用範囲を決めて使うといい。

商品マスタが整っていない現場でどうするか

ここまでの検算は「照合できるリストがある」ことを前提にしている。ところが、品番マスタが基幹システムとExcelと担当者の頭の中に散っている、という現場は少なくない。マスタ整備が終わるのを待っていたら、いつまでも着手できない。

回避策はある。過去1年の受注実績から、品番の列だけを抜き出して重複を消す。基幹システムの受注明細でもいいし、請求書や納品書のCSVでもいい。列を1本コピーして重複削除をかけるだけなので、作業としては数十分で終わる。これで「品番リスト」が1枚できる。

照合の条件も緩めていい。「正式なマスタに登録されているか」ではなく「過去に一度でも売ったことがあるか」で十分に機能する。この設計だと、初めて出てきた品番は必ず人に回ることになるが、それはむしろ望ましい。新規品番の初回受注は、どのみち人が見た方がいい取引だからだ。

人に回す条件を先に決めておく

自動化率を上げようとして条件を緩めるのは順序が逆である。先に「これは人が見る」という線を引き、その外側だけを自動で流す。

• 品番・数量・納期のいずれかが null
• 品番が品番リストに無い
• 数量が整数でない、または過去実績の最大値を超えている
• 同一スレッド内に2通目以降がある（訂正の可能性がある）
• 本文に「変更」「訂正」「キャンセル」「取消」の語がある
• 納期が相対表記のままで、絶対日付に変換できなかった

全件を自動で処理しようとしないのには、根拠がある。前章のB群、つまり訂正メール・キャンセル・「いつものやつ」・電話前提の発注は、そもそもメール本文の中に必要な情報が存在しない。情報が無いものは、モデルを新しいものに替えても精度は上がらない。ここは原理的に人の領域である。加えて、APIの仕様書が保証しているのは形式の準拠だけだった。この2つを合わせると、現実的な設計は「機械が全項目を根拠付きで埋められた注文だけ自動、それ以外は下書きにして人が見る」に落ち着く。

よく「まず8割の自動化を目指す」という言い方をするが、この8割という数字自体は目標であって実測ではない。本記事でも実測していない。自社の実態を知りたければ、直近1週間ぶんの受注メールを手で分類してみるのが早い。3項目が本文だけで埋まるメールが何通あったか、埋まらなかったメールは上のどの条件に引っかかったか。この2つを数えれば、自動化できる割合はその日のうちに出る。他社の数字より、この数字のほうが判断に使える。

台帳に入れるまでの配線 — 二重取り込みを止めるキーの作り方

最後は配線である。ここで設計を間違えると、抽出の精度がいくら高くても運用が崩れる。崩れ方はほぼ1種類で、同じメールを2回取り込んで台帳に同じ注文が2行並ぶ、という事故だ。スクリプトを手で再実行したとき、エラーで途中まで書き込まれたあと再実行したとき、実行時間が伸びて次の起動と重なったとき。どれも普通に起きる。

対策は単純で、台帳のA列に、そのメールのメッセージIDを入れる。Gmailのメッセージには1通ごとに割り振られるIDが割り振られていて、Apps Scriptなら getId() で取れる。件名や受信日時をキーにすると、同じ得意先から同じ件名で複数通届いたときに破綻するが、IDなら衝突しない。

ただしIDだけでは足りない。1通に複数明細があると、2行目以降が「既に取り込み済み」と判定されて消える。キーは メッセージID + 行番号 にする。例えば 18f2a...c1#2 のような形だ。

絞り込みはGmailの検索演算子をそのまま使える。from:（送信元）、subject:（件名）、label:（ラベル）、after: / before:、newer_than:7d（直近7日）、has:attachment、先頭に - を付けての除外。前工程で発注メールにラベルが付いているなら、label: と newer_than: の2つで足りることが多い。

以下はGoogle Apps Scriptの骨格である。この記事では実行検証をしていない。公式リファレンスの記述に沿って書いた出発点なので、まずは自分の環境で1通だけ通してから広げてほしい。

function importOrderMails() {
  const sheet = SpreadsheetApp.getActive().getSheetByName('受注台帳');
  const lastRow = sheet.getLastRow();
  const known = lastRow < 2 ? new Set()
    : new Set(sheet.getRange(2, 1, lastRow - 1, 1).getValues().flat());

  // 一度に大量のスレッドを取ると失敗しうるので件数を区切る
  const threads = GmailApp.search('label:発注メール newer_than:7d', 0, 20);

  threads.forEach(function (thread) {
    thread.getMessages().forEach(function (msg) {
      const id = msg.getId();
      const body = msg.getPlainBody();      // HTML整形は落ちる
      const rows = extractOrders(body);     // 前処理＋AI抽出は別関数

      rows.forEach(function (row, i) {
        const key = id + '#' + (i + 1);
        if (known.has(key)) return;         // 二重取り込みを止める
        sheet.appendRow([
          key, id, msg.getDate(), msg.getFrom(), msg.getSubject(),
          row.item_code, row.quantity, row.unit,
          row.due_date, row.due_date_raw, row.source_text,
          row.needs_human, '新規', body
        ]);
        known.add(key);
      });
    });
  });
}

ここで押さえておきたい点が3つある。

1つ目は getPlainBody() の性質だ。公式リファレンスには「HTML整形なしで本文の内容を取得する」とある。つまり表組みで届いた発注メールは、行の区切りが失われた1本の文字列になる。前章で書いた「レイアウトで表現されていた対応関係が消える」は、まさにここで起きる。表形式の発注が多い取引先については、HTML側を扱うか、そもそも添付ファイルを見に行くかを別に考える必要がある。

2つ目は取得件数の制限である。リファレンスには、スレッドをまとめて取得するとサイズが大きすぎて失敗しうるという趣旨の注意がある。search() は開始位置と最大件数を指定できるので、必ず区切って取る。過去分をまとめて流し込みたいときほど、ここで詰まる。

3つ目は訂正メールの入れ方だ。既存の行を上書きしたくなるが、やらない方がいい。追記し、「種別」列に 新規／訂正／取消 を入れる。台帳は履歴として持ち、集計は別シートで最新状態を作る。こうしておくと「いつ、どのメールで、数量が3から5に変わったのか」を1件ずつ元へ戻せる。上書きしてしまうと、間違いを見つけても原因のメールにたどり着けない。AIが間違えたときにそのメールへ戻れるかどうかが、この設計の合否である。

同じ理由で、getPlainBody() で取った本文全体も1列に丸ごと保存しておきたい。抽出結果だけを持っていると、値が変だと気づいたときに照合できない。なおスプレッドシートの1セルに入る文字数には上限があるので、極端に長いメールを扱うなら自社環境で確認しておくといい。

あわせて、メール原本の扱いも決めておきたい。台帳に転記したから元のメールを削除してよい、とはならない。メールで授受した注文書は電子取引データとして扱われ、電子のまま保存することが求められる場面がある。要件の詳細は本記事の守備範囲を超えるので断定しないが、運用ルールを固める前に国税庁の案内と顧問税理士に確認しておくことを勧める。

導入効果を、社内で通る数字にする

ここまでの手順を試すには、少なくとも自分の時間が要る。人を巻き込むなら、上長の承認も要る。そのときに「業務が効率化されます」と言っても、まず通らない。効率化という言葉には単位がないからだ。通る形にするには、単位のある数字を3つ用意する。

1. 1通あたりの処理時間。メールを開いてから台帳に入れ終わるまでを、実際にストップウォッチで測る。自分1人の1通ではなく、担当者3人×5通くらいを測って中央値を取る。画面を何回切り替えたかも一緒に記録しておくと、あとで効く
2. 月間の対象件数。Gmailの検索窓に label:発注メール after:2026/07/01 before:2026/08/01 のように入れて、ヒットした件数を数える。推測しない。検索して出た数を書く
3. 自動化できる割合。前章で出した「1週間分を手で分類した結果」をそのまま使う

この3つを掛ければ、月あたりの削減時間が出る。ただし、そこから残る作業を引くことを忘れない方がいい。自動化しても、検算で弾かれた明細の目視確認と、例外メールの手入力は残る。差し引く前の数字を持っていくと、稼働後に「言っていた効果が出ていない」と言われる。最初から差し引いた数字を出しておく方が、結果的に通りやすい。

もう1つ、時間だけを主語にしない方がいい。受注担当の工数が減って何が起きるのかまで書く。転記に使っていた時間が、欠品の事前連絡や納期回答の速さに回るという筋なら、削減時間ではなく取引先対応の質の話になる。承認する側が気にしているのは、たいてい後者だ。

ここで出した工数の数字は、そのままでは社内で通らない。数え方は正しくても、誰の何を解決するのかが添えられていないと、単なる作業報告として流される。数字を提案の形に組み替える手順はEC実務のデータを社内提案に変える手順にまとめてあるので、稟議や上申の直前に一度読んでみてほしい。

最後に、この一連の作業で本当に手元に残るものについて書いておく。抽出のスクリプトそのものではない。「うちの発注メールは、どこで、なぜ壊れるのか」を分類できるようになったことが残る。これは自社のメールを1週間分ながめた人にしか書けない知識で、AIの側からは取り出せない。現場の事情を知っている人がAIの使いどころを決める、という順序でしか、この種の仕組みは動かない。まずは1通、自分の受信トレイから選んで試してみるところからでいい。

よくある質問

添付のExcelやPDFで届く発注書はどうすればいいですか

本記事の手順はメール本文を対象にしているので、そのままでは扱えない。添付側に明細の本体があるなら、本文解析では情報がそもそも存在しないためだ。ただし考え方は同じで、①添付を取り出す、②文字列に変換する、③本記事の指示文に渡す、という順になる。ExcelはCSVに変換できる分だけ有利で、PDFは元がテキストか画像かで難易度が大きく変わる。まずは本文型と添付型でメールを分けて数え、多い方から着手するのが現実的だと思う。

ChatGPTの画面に毎回貼り付けるやり方ではダメですか

ダメではない。むしろ最初の1〜2週間はそれでいい。指示文が自社のメールに合っているかを確かめる段階では、手で貼った方が速く回る。切り替えを考えるのは、①同じ指示文で結果が安定した、②月の件数が数十通を超えた、③貼り付け作業そのものが転記と同じくらい面倒になった、のどれかが起きたときだ。自動化の前に、指示文を固める工程があると考えるといい。

訂正メールが来たとき、台帳の元の行はどうしますか

上書きしないことを勧める。新しい行を追記して、種別列に「訂正」と入れ、どのメールによる訂正かが分かるようにメッセージIDを残す。最新状態は別シートで作る。上書きしてしまうと、数字が変わった理由を後から追えなくなる。訂正メール自体は品番が書かれていないことが多いので、自動で当てにいかず人が紐づける設計にしておく方が安全だと思う。

結局、どのくらいの精度が出るのですか

本記事では実測していないので、数字は出さない。加えて、精度という1つの数字で語れる問題でもない。「いつものやつ」や電話前提の発注のように、本文に情報が存在しないメールは、モデルを替えても抽出できないからだ。知りたいのが自社の数字であれば、直近1週間分を手で分類するのが最短になる。3項目が本文だけで埋まったメールの割合が、そのまま自動化の上限に近い値になる。

あわせて読みたい：自分の業務のどの工程がAIに置き換わりつつあるかを数える手順は、事務職はAIに奪われるのか——EC実務の「工程」で数え直すにまとめています。

あわせて読みたい: EC実務者がプログラミングスクールを見るとき、「評判」より先に見るべき3つの接続点

あわせて読みたい：同じ「機械に転記を渡し、判断は人が確定する」考え方を在庫更新に適用した例は、在庫数の更新を、半分だけ自動化するで解説しています。

あわせて読みたい: 一元管理ツールの選び方｜楽天RMSだけで複数モールを回す限界とチェックリスト

あわせて読みたい：欠品と過剰在庫のアラートを、自分で組む