受発注メールの転記を自動化｜手段4つの比較と失敗しない順番

受注メールを開いて、型番と数量と納期を目で拾い、受注台帳のスプレッドシートに打ち直す。1件2〜3分の作業ですが、1日30件あれば1時間以上が消えます。しかも「速く打つ」ほどミスが増えるという、努力が裏目に出る種類の仕事です。

結論：受注メールの転記は4工程。まず「抽出」と「追記」だけを切り出す

受発注メールの転記は、ひとかたまりの作業に見えて、実際は「メールの受信・仕分け」→「注文項目の抽出」→「台帳への追記」→「内容の確認」の4工程に分かれています。ここを分けずに「受注業務をまるごと自動化したい」と始めると、ほぼ確実に止まります。止まる場所はいつも同じで、例外的な注文と、確認をどう残すかの2つです。

現実的な進め方は、4工程のうち「抽出」と「追記」だけを自動化し、「確認」は人の手に残すことです。抽出と追記は毎回まったく同じ手順なので機械が得意で、確認は判断が要るので人が得意。この線で切ると、初日から効果が出て、事故も起きません。

そもそも受発注のやりとりは、いまだにメールが主戦場です。東京商工会議所が2024年10〜11月に実施した「中小企業のデジタルシフト・DX実態調査」（回答1,218社）では、受発注の方法として「メール・ホームページ等オンラインでの受発注」が48.8％と最多で、EDI（電子データ交換）の導入は13.6％、電話・FAXも24.6％残っています（受発注の設問はn=1,002）。つまり多くの中小企業にとって、受発注の自動化とは「EDIを入れる話」ではなく、目の前のメールをどう捌くかという話です。

転記が事故になるのは、担当者のせいではなく工程の作りのせい

転記ミスは「注意力の問題」として扱われがちですが、実務で起きているミスには型があります。型があるということは、注意ではなく仕組みで潰せるということです。

型番は「似た文字列」でしか間違わない

型番の打ち間違いは、まったく無関係な文字列にはなりません。ハイフンの有無、全角と半角、O（オー）と0（ゼロ）、末尾のリビジョン記号（-A / -B）といった、目視では区別しづらい差で起きます。人が読み上げて確認しても見逃す種類の差なので、台帳側にマスタを持って「存在しない型番は弾く」形にしないと、確認工程をいくら足しても抜けます。

数量は桁ではなく「単位」でズレる

数量のミスで多いのは0を1つ多く打つことではなく、ケース単位とバラ単位の取り違えです。「10ケース」と書かれたメールを、台帳の数量欄（バラ換算）に10と入れてしまう。メールの文面としては正しく写しているので、転記した本人は間違いに気づけません。抽出を自動化するときは、数値と一緒に単位も必ず1つの項目として持つのが鉄則です。

納期は「解釈」が入るのでズレる

「月末まで」「来週中」「至急」といった表現は、そのままでは台帳に入りません。誰かが日付に翻訳しています。この翻訳が担当者ごとに違うと、同じメールから違う納期が生まれます。翻訳ルール（月末＝当月最終営業日、至急＝翌営業日 など）を先に文書化すると、自動化するかどうかに関係なく事故が減ります。

見落としは「担当者の受信箱」で起きる

いちばん重い事故は打ち間違いではなく、注文メールそのものの見落としです。原因はたいてい、注文が個人の受信箱に届いていることにあります。担当者が休んだ日、返信スレッドの下のほうに紛れた注文、件名が「Re: Re: ご相談」になっている注文。共有アドレスへの集約とラベル運用を先に整えないと、抽出を自動化しても入口で漏れます。

例外処理はベテランの頭の中にしかない

「A社のこの型番だけは在庫を先に押さえる」「B社は数量が偶数でないと確認の電話を入れる」——こうした暗黙のルールは、たいてい台帳にもマニュアルにも書かれていません。自動化の設計で最初にやるべきは、コードを書くことではなくこの例外を洗い出して一覧にすることです。ここを飛ばした自動化は、必ず「結局ベテランが全部見直している」状態に戻ります。同じ情報を2か所に打ち込む構造そのものを見直す観点は、Excelの二重入力をなくす考え方にまとめています。

受発注メールの転記を自動化する4つの手段を比較する

手段は大きく4つです。どれが正解かは「注文が定型か自由文か」でほぼ決まります。逆に言えば、自社の注文メールを10通並べて見比べることが、手段選びの最短ルートです。

定型フォーマット＋GASで転記する

注文メールの書式を取引先と決められるなら、これがいちばん安く早い解です。件名やヘッダーで注文メールを判別し、決まった位置の項目を切り出して台帳へ追記するだけなので、処理そのものは単純です。弱点は、書式が守られなかった1通で静かに壊れること。「解釈できなかったメールは台帳に入れず、別シートに退避して人へ回す」という逃げ道を最初から作っておくと、壊れ方が安全になります。

注文フォーム化して直接スプレッドシートへ

そもそも転記が発生しない形にする、いちばん筋のいい手です。抽出という工程を消してしまうので、事故の芽が根元から減ります。ただし成立条件がはっきりしていて、取引先に「これで注文してください」とお願いできる立場かどうかで決まります。また、フォームで受けた注文が増えたあと、集計や在庫連携までフォームだけで背負わせようとすると別の限界に当たるので、受けたあとの台帳設計はセットで考えておいてください。

AI（LLM）で自由文の注文メールから項目を抽出する

取引先ごとに書式がバラバラで、しかも書式を統一できない——という、いちばん多いパターンに効くのがこれです。「本文から品番・数量・単位・希望納期を取り出してJSONで返す」といった指示で、定型化を諦めたメールからも項目が取れます。ただし精度は100％になりません。詳しくは後述しますが、誤抽出を前提に確認工程を設計に組み込むことが導入可否そのものを決めます。メールの一次対応をAIで仕組み化する考え方は、問い合わせメールの自動返信を仕組み化する手順と共通です。

受発注SaaSを導入する

件数・品目・取引先が多く、在庫や請求まで一気通貫でつなぎたいなら、既製のSaaSが結局いちばん安くつきます。判断の分かれ目は、取引先にもその画面を使ってもらえるか。取引先が従来どおりメールで送ってくる限り、SaaSを入れても「SaaSに手入力する仕事」が残るだけになります。ここを確認せずに契約すると、月額だけが増えます。

受注台帳そのものの作り方から見直したい場合は、AIを使った受注管理表の作り方で、項目設計と受注漏れの防ぎ方を整理しています。

私たちは、こうしたスプレッドシート起点の業務をそのままアプリの形にする支援も行っています。記事の途中で恐縮ですが、「台帳は今のまま、入力と確認だけ楽にしたい」という相談が実際に多い領域なので、よろしければ合わせてご覧いただけたら嬉しいです。

GASで作る場合に必ず当たる制約（公式クォータ）

GAS（Google Apps Script）は無料で始められますが、Googleが公開しているクォータ（上限）は明確に決まっています。設計を始める前に見ておくと、作り直しが減ります。以下はGoogle公式の「Quotas for Google Services」に記載されている主な値です（無料のGoogleアカウントとGoogle Workspaceで差があります）。

Googleはこれらの値を予告なく変更する場合があると明記しているため、設計時点で必ず公式ページを確認してください。

「6分の壁」は件数ではなく設計を変える

1回の実行が6分で強制終了される制約は、受注メールの転記では意外と早く効いてきます。未処理メールが溜まった月曜の朝に100通をまとめて処理しようとすると、添付ファイルの読み取りや外部APIの呼び出しを挟んだ時点で6分を超えます。対策は処理の分割で、「1回の実行では最大N通まで処理し、続きは次のトリガーで拾う」という作りにします。実装量は素直なループの数倍になるので、ここは最初から見込んでおく箇所です。この制約が外注費用を押し上げる仕組みはGAS開発の外注費用と内製・外注の分かれ目で詳しく整理しています。

トリガーは「作った人のアカウント」で動く

GASの定期実行（インストール可能トリガー）について、Google公式ドキュメントは「インストール可能トリガーは常に、それを作成した人のアカウントで実行される」と明記しています。さらに、あるアカウントから別のアカウントが設置したトリガーは一覧に表示されず、実行に失敗したときの通知メールも作成者本人にしか届きません。

これは受注業務では致命的になり得ます。作った担当者が退職してアカウントが停止されれば、毎朝の転記は誰にも知らせず止まります。作成アカウントを個人ではなく共有の運用アカウントにする、失敗時に社内チャットへ通知を飛ばす——この2点は機能ではないので見積もりから抜けがちですが、受注が止まる前提で必ず入れてください。

スプレッドシート側の上限も先に見ておく

台帳をスプレッドシートで持つ場合、Googleドライブのヘルプに「Googleスプレッドシートで作成またはGoogleスプレッドシートに変換されたファイルは、最大1,000万セルまたは18,278列（ZZZ列）まで」と記載されています。受注1件＝1行、列が30程度なら行数としてはかなり持ちますが、明細を行で持つ設計や関数を多用した台帳では体感速度のほうが先に限界を迎えます。実務では、上限に達する前に年度ごとにシートを分けるのが定番です。複数人が同時に触る台帳が壊れる理由は、複数人で使うスプレッドシートが壊れる原因と対策にまとめました。

AIで自由文から項目抽出するときの注意

誤抽出は必ず起きる前提で「人の確認欄」を設計に入れる

AIによる項目抽出は、精度が高くても100％にはなりません。だから設計の目標を「間違えないこと」ではなく、「間違いが必ず人の目に留まる形で落ちること」に置き換えます。実務で機能する型は3つです。

• 確認ステータス列を必ず持つ：AIが書いた行は「未確認」で入り、人がチェックして初めて「確認済」になる。未確認の行は出荷・発注の対象にしない。
• 抽出の根拠を隣に残す：抽出した値だけでなく、元メールの該当箇所と元メールへのリンクを同じ行に持たせる。これがないと、確認作業がメールを探すところから始まってしまい、誰もやらなくなります。
• 自信のない項目を自己申告させる：「判断できなかった項目はconfidence: lowと返す」と指示し、lowが付いた行だけ色を変える。全件を等しく見直すのではなく、見るべき行を絞るのが確認を続けられる条件です。

この「確認欄を残す」設計は、自動化のレベルを下げているように見えて、実は最も早く現場に入る形です。人が最終責任を持てる限り、多少の誤抽出は業務を止めません。逆に確認欄のない全自動は、1件の誤出荷で運用ごと止まります。

取引先の情報を外部AIへ入れるときの社内ルール

注文メールには取引先名・担当者名・単価・数量といった、社外に出してはいけない情報が含まれます。外部のAIサービスへ本文を渡す前に、最低限これだけは決めてください。

• 入力データを学習に使われない契約形態か（法人向けプランやAPI利用など、事業者の規約で明示されている経路を選ぶ）。
• 渡す範囲を絞る：メール全文ではなく、注文明細の部分だけを渡す。署名・過去のやりとり・添付は原則渡さない。
• 取引先との契約に反しないか：秘密保持契約で第三者提供が制限されている場合があります。特に単価情報は要確認です。
• ログの保存場所と保存期間を決める：誰がいつ何を渡したかを追えるようにしておく。

この4点を1枚のメモにして社内で共有しておくと、後から「勝手にAIに入れていいのか」という話で止まることがなくなります。

段階的な進め方：1社・1商品から広げる

いちばん失敗が少ない順番は決まっています。全取引先を一気に対象にしないことです。

1. 1社・1商品の型で試す：注文の書式が最も安定している取引先を1社選び、その1商品だけを対象に抽出と追記を回す。ここで扱えないなら、他社では絶対に回りません。
2. 2週間、人の転記と並走させる：自動化した結果と、人が転記した結果を並べて突き合わせる。ここで初めて「AIが何を間違えるか」「どの表現が解釈できないか」が実データで見えます。
3. 例外を洗い出して一覧にする：並走で出た不一致を、ルール化できるもの（単位の換算、納期表現の翻訳）と、できないもの（取引先ごとの特別対応）に仕分ける。できないものは自動化せず、人へ回す条件として残す。
4. 確認工程を残したまま、取引先を1社ずつ増やす：確認欄を外すのは最後の最後です。件数が増えても確認が回るかどうかを見ながら広げる。
5. 止まったときに気づける仕組みを付ける：処理件数が0件の日にチャットへ通知する、といった単純な監視で十分です。「静かに止まる」ことだけは避けてください。

費用感：どこにお金がかかるのかで見立てる

金額の幅よりも、費用が跳ねる要因を知っておくほうが見積もりを読めます。受注メール転記の自動化で費用が上がるのは、次の3つが絡んだときです。

• 例外の数：取引先ごとの特別対応が多いほど、条件分岐と検証の工数が増えます。ここは機能数ではなく「ルールの数」で効いてきます。
• 処理件数と実行時間：前述の6分の壁を超える規模になると、分割処理と再開の設計が入り、実装量が数倍になります。
• 止まらないための作り込み：失敗検知、通知、ログ、権限設計。機能ではないので見積もりから抜けやすく、安い見積もりと高い見積もりの差はたいていここに入っています。

注文フォーム化のようにそもそも工程を消す方向で解けるなら、費用は最も安く済みます。まず「フォームにできないか」を検討してから、できない理由（取引先が使ってくれない、注文が複雑すぎる）を明確にして次の手段へ進むと、無駄な開発費を払わずに済みます。

自社の注文メールを見て、どの手段が向いているか判断がつかない場合は、10通ほどの実物を見せていただければ「フォームで消せる部分」と「抽出が必要な部分」の切り分けをお伝えできます。具体的な相談先をお探しでしたら、お気軽にご連絡ください。