紙やメールや写真で届いた情報を、人が見て打ち直す——。FAXの注文書、手書きの日報、領収書の写真は、入口こそばらばらですが、台帳の1行に変えるところまでは同じ仕組みで作れます。
業務自動化でできること一覧の記事では、製造業・建設業・物流業の30の業務を洗い出し、4つの処理の型に分けました。
- 取り込み型:形の決まっていない入力を読み取り、台帳に入れる
- 照合型:2つの台帳、または台帳と今日の日付を突き合わせる
- 下書き型:過去のデータを探し、文書の下書きを作る
- 実行型:発注・振込などの確定処理を実行する

この記事が扱うのは、いちばん前にある取り込み型です。形の決まっていない入力を読み取って決まった項目に分ける型で、4つの型のうち、AIの力がいちばん必要な場所です。
代表例は、FAXやメールで届く注文の取り込みです。FAX-OCR(FAXの文字を読み取ってデータにする仕組み)で済むのか、AIに任せる範囲と人が確かめる範囲を、設計図とn8nで組んだ形で示します。
- 受注・日報・領収書の手入力を、同じ設計でなくす考え方
- 既製のFAX-OCRで足りる場合と、足りなくなる場合
- AIに任せる範囲と、受注台帳の項目・例外の扱い
- n8nで組んだときの形と、他の業務への広げ方
受注も日報も領収書も「取り込み」で解ける
手入力が残っている業務は、どれも同じ形をしています。届いたものを人が読み、別の場所に打ち直しているのです。
次の表は、この記事で扱う取り込み型の業務です。
| 業務 | 適性 | 恩恵 | 着手 | 人の接点 |
|---|---|---|---|---|
| 受注のマルチチャネル受付(FAX・メール・電話) | ◎ | 時間・ミス | 要準備 | 承認 |
| 日報・作業報告の収集と集計 | ◎ | 時間 | すぐ | 通知 |
| 現場写真の整理と台帳への紐付け | ○ | 時間 | すぐ | 無人 |
| 検査成績書と品質記録の作成 | ○ | 時間・売上 | 要準備 | 承認 |
| 経費精算と領収書の処理 | ○ | 時間 | すぐ | 承認 |
| 受領請求書の処理(インボイス・電子帳簿保存法) | ○ | ミス | すぐ | 承認 |
| 運行日報と点呼記録の収集 | ○ | ミス | すぐ | 無人 |
表の記号は次のとおりです。
- 適性:◎は恩恵が大きい、○は恩恵がある、△は限定的
- 恩恵:時間(時間短縮)、ミス(ミス防止)、売上(機会損失の防止)
- 着手:「すぐ」は手元のデータで始められる、「要準備」はマスタの整備や入力の習慣づけが要る
- 人の接点:無人/通知/承認/画面の4段階
入口の形はさまざまで、FAXは画像、メールは文章、日報は紙か短い文、領収書は写真で届きます。
それでも、出口はどれも同じです。「いつ・誰が・何を・いくつ」が欄に分かれた1行になり、この1行ができれば、集計も照合も通知も後ろの仕組みに任せられます。
台帳はデータの置き場で、人が操作する画面ではありません。最初はGoogleスプレッドシートで足り、件数が増えたらデータベースに移します。
FAXの注文書から始めるなら、先に取引先と品番のマスタがそろっているかを確かめてください。読み取った値を確定させるのは、AIではなくマスタです。
受注の入力で時間がかかる本当の原因
受注の入力で時間を使うのは、打ち込む作業そのものではありません。時間を取っているのは、打ち直しと見回りです。
社員30人ほどの会社で、受注の担当者が1人で受け持つ場面を考えます。担当者の1日は、よく次のような流れになります。
- FAX機の前に行き、届いた注文書を取る
- 注文書を見ながら、品番と数量を受注の画面に打ち直す
- 受注用のメールボックスを開き、本文の注文内容を写す
- 電話で受けた注文を、手元のメモから起こす
- 昼と夕方に、もう一度FAX機とメールを見に行く
この流れで無理が出る箇所は、2つあります。
1つ目は、様式が取引先ごとに違う点です。担当者は様式ごとに目の動かし方を覚えており、新しい取引先が増えるたびに覚え直しています。
しかも、この知識は担当者の頭の中にしか残りません。担当者が休むと、同じ速さで入力できる人がいなくなります。
2つ目は、入口が分かれている点です。FAX機、メールボックス、電話メモを順に見に行くため、見落としがあっても取引先から催促が来るまで分かりません。
どちらも、人が読んで打ち直していることから起きています。読み取りと転記を仕組みに渡せば、担当者の仕事は「中身を確かめること」だけになります。
既製のFAX-OCRで足りるかを確かめる
自分で組む前に、既製のサービスで足りるかを確かめてください。既製の手段で足りるなら、この記事の仕組みは要りませんし、サービスの設定を見直す方が早く確実です。
FAXの受注の手入力を減らす手段には、次のようなものがあります。きれいに分かれるものではなく、1つのサービスが複数を兼ねることもあります。
| 手段 | できること | 残る手間 |
|---|---|---|
| 受注・経費のサービスの読み取り機能 | 注文書や領収書を読み取り、そのサービスに入れる | そのサービスの形式でしか受け付けない |
| 注文書向けのAI-OCR(FAX-OCR) | FAXやPDFの注文書から、品番・数量・納期などを読み取ってデータにする | 自社のマスタとの照合と、基幹への取り込み |
| インターネットFAX | 届いたFAXを、PDFなどの添付ファイルにしてメールで届ける | 紙はなくなるが、打ち直しは残る |
| Web受注・受発注システム | 取引先に画面から注文を入れてもらう | 取引先に注文の出し方を変えてもらう必要がある |
| 入力の代行 | 人が代わりにデータを入力する | 費用は契約による。入力後の確認は自社に残る |
FAX-OCRは、読み取り方で大きく2つに分かれます。様式ごとに「どの位置に何があるか」を決めておくテンプレート型と、AIが文面から項目を読み分ける型です。
テンプレート型は様式が決まった帳票に向きますが、様式が変わるたびに設定し直します。取引先ごとに注文書の様式が違う受注では、AIが読み分ける型の方が向いています。
経費精算のサービスの読み取り機能と料金は、経費精算アプリの比較で扱っています。
既製の手段では足りなくなるのは、次のような場合です。
- 注文書の様式が多く、読み取りの精度が上がらない
- 読み取った結果を、自社のマスタと照らして直したい
- 基幹システムに取り込みの口がなく、CSVを作る手間が残る
- 受注と日報と経費で、別々のサービスを使うことになる
既製のサービスはそのサービスの形式しか受け付けないため、入口が複数にまたがると、つなぎ目が残ります。この記事で組むのは、そのつなぎ目です。
AIに任せる範囲と人に残す判断
取り込み型は、4つの型のなかで唯一、AIを本体に使います。ただし、AIに任せるのは読み取りまでで、確定と承認は台帳・ルール・人が受け持ちます。
読み取りだけをAIに任せる
注文書の様式は取引先ごとに異なり、品番の欄が右にある様式もあれば、明細が手書きの様式もあります。手書きの日報も、書く人ごとに書き方が変わります。
こうした入力から品番・数量・納期を取り出す作業は、ルールだけでは書き切れません。様式の数だけ条件を書き、取引先が増えるたびに書き足すことになるため、ここはAIに任せます。
一方で、次の3つは台帳とルールで決めます。
- 取引先の特定:読み取った社名を、取引先マスタと照らして決める
- 品番の確定:読み取った品番を、品番マスタと照らして決める
- 金額の計算:単価マスタから単価を引き、数量を掛けて出す
AIが社名を少し違う表記で読んでも、マスタとの照合で気付けます。金額をAIに計算させると、誤りの理由をあとから追えなくなるため避けます。
読み取った結果が正しいかどうかは、後段の照合で確かめます。突き合わせの組み方は、照合型の記事にまとめています。

基幹への登録は承認のあとにする
自動化に入る前に、仕組みに任せる範囲と、人に残す範囲の線を引きます。仕組みに任せるのは答えが1つに決まる作業、人に残すのは誤りが外に出ていく手前の確認です。
| 作業 | 受け持ち | 中身 |
|---|---|---|
| 受け取る | 仕組み | FAXとメールを一か所に集める |
| 読み取る | 仕組み(AI) | 画像やPDFを文字にし、取引先・品番・数量・納期を取り出す |
| マスタを引く | 仕組み | 取引先と品番と単価を確定する |
| 知らせる | 仕組み | 台帳に承認待ちの1行を書き、担当者に知らせる |
| 確かめる | 人 | 品番と数量が注文書のとおりか、納期が受けられる日付か |
| 承認する | 人 | 新しい取引先として登録してよいかを決め、承認する |
基幹システムへの登録は、承認のあとにします。読み取った直後に基幹へ入れると、誤りが出荷や請求まで流れてしまうためです。
あとで取り消すより、入れる前に止める方が手間は少なく済みます。判断を含まない仕組みは、止まったときにも直しやすくなります。
確実性の低い項目だけを見てもらう
取り込み型の自動化で、人と仕組みの接点は「承認」です。すべての項目を見直すと手入力と手間が変わらないため、担当者が確認するのは確実性の低い項目だけにします。
確実性は、次の2つの見方で決めます。
- AIの見立て:読み取りに自信のない項目の名前をAIに返させる
- マスタとの照合:取引先マスタや品番マスタに無い値を、確実性が低いとみなす
通知には、確実性の低い項目に印を付けて載せます。担当者は印の付いた箇所だけを注文書の画像と見比べ、印がなければ内容を一読して承認します。
承認のための新しい画面は作りません。承認は、台帳の「状態」の欄を書き換えるだけで済むからです。
通知は担当者あてに1件ずつ送ります。受注は1件ごとに承認するので、まとめて送ると承認の単位が分からなくなります。
受注取り込みの設計図を描く
ここからは、自動化の設計図を描きます。データの流れ、台帳の項目、処理の決めごとの順に見ていきます。
データの流れ
流れは、次の4つの段階に分かれます。
- FAXとメールを受け取り、文字にする
- 文字を決まった項目に分け、マスタから取引先と品番を引く
- 承認待ちの行を受注台帳に書き、担当者に知らせる
- 承認された行だけを、あとから基幹システムに登録する

図の点線から下は人の仕事です。仕組みが受け持つのは、承認待ちの行を作って知らせるところまでで、中身を確かめて承認するのは担当者です。
ポイントは、受注台帳を間に置くことです。読み取った結果をいったん台帳に書くので、何を承認待ちにしたかが記録に残り、基幹への登録はこの台帳から改めて拾い直します。
受注台帳に持たせる項目
受注台帳には、次の項目を持たせます。例の値は架空のものです。
| 項目 | 内容 | 例 |
|---|---|---|
| 案件ID | 取引先と注文番号から作る鍵 | SAMPLE-20261015-01 |
| 受信日時 | FAXやメールが届いた日時 | 2026-10-15 09:12 |
| 入口 | FAX/メール/電話のどれか | FAX |
| 取引先 | 取引先マスタのコード | C0031 |
| 品番 | 品番マスタのコード | AB-1024 |
| 数量 | 注文された数 | 50 |
| 納期 | 希望納期 | 2026-10-22 |
| 要確認の項目 | 確実性が低いと判定した項目の名前 | 納期 |
| 原本の場所 | FAX画像やPDFの保存先 | (リンク) |
| 状態 | 承認待ち/承認済/差し戻し/登録済 | 承認待ち |
| 処理済 | 基幹に登録した日時 | (空欄) |
鍵になるのは「案件ID」です。取引先と注文番号から作ると、同じ注文が二度届いても同じIDになります。
すでに同じIDの行があれば、新しい行は書かずに担当者へ知らせるだけにします。明細が複数行ある注文は明細ごとに1行にし、同じ注文の明細は案件IDの枝番でまとめます。
原本の場所を持つのは、担当者が確認するときにすぐ開けるようにするためです。通知にも、この欄のリンクを載せます。
トリガーと例外の決めごと
処理の決めごとを、1枚の表にまとめます。
| 項目 | 内容 |
|---|---|
| トリガー | 受注用のメールボックスへの着信(FAXはインターネットFAXでメールに届く) |
| 入力 | 注文書の画像またはPDF、メール本文、取引先マスタ、品番マスタ、単価マスタ、受注台帳 |
| 処理 | 文字にする → 項目に分ける → マスタで取引先と品番と単価を引く → 案件IDを作り、重複を確かめる |
| 出力 | 受注台帳への追記、担当者への承認依頼、通知済の印の書き込み |
| 例外 | 読めないFAX、登録のない取引先、品番の不一致、同じ注文の再送 |
例外は、先に扱いを決めておきます。決めずに動かすと、読み取れない注文が消えたように見えてしまうためです。
- 読めないFAX:項目を空のまま承認待ちにし、「読み取り不可」と印を付けて知らせる
- 登録のない取引先:取引先の欄を空にし、「マスタ未登録」と印を付ける
- 品番の不一致:読み取った品番をそのまま残し、「品番未確認」と印を付ける
- 同じ注文の再送:同じ案件IDの行があれば、台帳には書かずに担当者へ知らせる
登録のない取引先からの注文は、最初の数回は担当者が全項目を確かめます。
同じ注文の再送を除き、どの例外でも行は台帳に書きます。台帳に残さないと、届いた注文が消えたように見えるからです。
受注取り込みをn8nで組むとどうなるか
設計図を n8n で組むと、2つのワークフローになります。注文が届いたら動く「判断まで」と、5分おきに台帳を見に行く「承認後の実行」です。
この記事では、設定の細かい手順は載せていません。手順は配布するワークフローのJSONにまとめており、FAXやメールの受注をAIで取り込む実装の例は開発記録の記事にもあります。

四角の1つひとつが、小さな仕事を表しています。図の中の英語は画面に出るとおりの名前で、読み解く必要はありません。
この記事で押さえてほしいのは、次の4つの決めごとです。
注文のメールを見に行って動き出す
起点は、受注用のメールボックスです。決めた間隔(数分おきなど)でメールボックスを見に行き、新しく届いた注文を拾って動き出します。
照合型の記事で扱った勤怠の突き合わせは、毎朝決まった時刻に1回動く形でした。受注は届く時刻が読めないため、1日1回では担当者の確認がその分だけ遅れます。

差出人やラベルで、受注メールだけを拾う条件を付けます。個人のメールボックスではなく、受注専用のアドレスに届くようにすれば、担当者が休んだ日も仕組みは同じように動きます。
読み取った文字を項目の定義で並べ直す
添付ファイルを文字にしてから、決まった項目に分けます。分ける項目は取引先名、注文番号、品番、数量、単位、納期の6つで、あわせて読み取りに自信のない項目の名前も返させます。
インターネットFAXで届くPDFは、文字の情報を持たない画像だけのPDFのことがあります。その場合はPDFから文字を取り出す処理では文字にならないため、画像を読めるAI(AI-OCRや画像を読める生成AI)に渡します。

AIに渡す指示は、自由な文章では書きません。項目の定義を並べた表として書き、項目ごとに名前・型・定義・迷ったときの扱いを決めます。
| 項目名 | 型 | 定義 | 迷ったとき |
|---|---|---|---|
| 取引先名 | 文字 | 注文書の発行元の社名。宛先の社名は含めない | 空で返す |
| 注文番号 | 文字 | 取引先が振った番号 | 空で返す |
| 品番 | 文字 | 記号と数字をそのまま写す | 読めた範囲を返す |
| 数量 | 数 | 注文された数。単位は含めない | 空で返す |
| 単位 | 文字 | 個、箱、本などの単位 | 空で返す |
| 納期 | 日付 | 年月日。年の記載がなければ空 | 空で返す |
| 要確認の項目 | 文字の並び | 読み取りに自信のない項目の名前 | — |
この形で書く理由は、次の3つです。
- 迷ったら空で返させる:値が入っている欄は、確実に読めた値だけになる
- 出力の形を固定する:後段の処理が、受け取り方を変えずに済む
- 直す場所を絞る:読み取りが外れたら、その項目の定義だけを書き直せる
いちばん大事なのは、迷ったときに空で返させることです。AIは空欄を推測で埋めて返すことがあり、たとえば年の記載がない納期に今年の年を補うことがあります。
補われた値は、正しく読めた値と見た目で区別がつきません。空で返させておけば「要確認」の印が付き、担当者の目に入ります。
項目の定義では、間違えやすい箇所を先に断っておきます。たとえば取引先名に「宛先の社名は含めない」と書かないと、宛先にある自社の名前を取引先として読み取ってしまいます。
逆に、様式ごとの位置の説明は書きません。「品番は右上の枠にある」と書くとその様式にだけ合う指示になり、新しい取引先の注文書で崩れるためです。
動かし始めてからは、外れた項目の定義を足していきます。社名に「株式会社」を含めるか、宛名の「御中」を取り除くかといった細かい決めごとが、精度を上げます。
当社が使っている指示の全文は載せていません。取引先の様式と、自社のマスタの作りに合わせて書くものだからです。
確実性の低い項目に印を付けて送る
項目がそろったら、マスタと照らし合わせます。取引先マスタと品番マスタに無い値は、確実性が低いものとして印を付けます。
印の付いた行は、承認待ちとして台帳に書きます。状態は「承認待ち」、処理済の欄は空のままです。
担当者への通知には、次の4つを載せます。
- 取引先・品番・数量・納期(注文の中身)
- 印の付いた項目
- 元の注文書を開くリンク
- 台帳の該当行を開くリンク

通知はこの形で届きます。担当者は印の付いた箇所だけを注文書と見比べ、台帳の状態を「承認済」に変えれば承認は終わりです。
承認された行だけを後から拾う
基幹システムへの登録は、承認のあとに動く別のワークフローが受け持ちます。このワークフローは承認を待って止まっているのではなく、5分おきに台帳を見に行き、「承認済」で処理済の欄が空の行だけを拾います。
拾った行には、登録の直前に処理済の印を書きます。印を先に書くのは、途中で止まったときに同じ行を二度登録しないためです。

止まって待たない形には、次の利点があります。
- 承認待ちの行が、台帳から一目で分かる
- 同じ注文を二度登録しない理由を、台帳で説明できる
- 承認の合図を受けるために、外から入れる口を開けずに済む
担当者が休んだ日も、代わりの人が台帳を見れば、どの注文が止まっているか分かります。印の書き方と二度実行しない仕掛けは、実行型の記事で詳しく扱います。
動かしてからの手間
取り込み型を組むときは、読み取りの精度を上げる工程が要ります。実際の注文書を20枚ほど流し、外れた項目を見ながら定義を直します。
動かし始めてからの手間は、新しい取引先が増えたときの確認です。最初の数回は担当者が全項目を確かめ、様式に慣れたら印の付いた項目だけの確認に戻します。
取り込み型を他の業務へ広げる
受注で組んだ仕組みは、残りの業務にもほぼそのまま使えます。変わるのは、入口と取り出す項目と出口です。
次の表は、受注との違いをまとめたものです。
| 業務 | トリガー | 入力 | 取り出す項目 | 出力 | 例外 |
|---|---|---|---|---|---|
| 受注のマルチチャネル受付 | メールの着信 | 注文書の画像、メール本文 | 取引先、品番、数量、納期 | 承認待ちの行、承認依頼 | 読めないFAX、未登録の取引先、再送 |
| 日報・作業報告の収集と集計 | フォームの送信 | 入力フォームの回答 | 現場、作業者、作業時間 | 日報の行、集計の通知 | 未提出 |
| 現場写真の整理と台帳への紐付け | 共有フォルダへの保存 | 写真と撮影日時 | 撮影日時、位置 | 現場ごとの紐付け | 現場が決まらない写真 |
| 検査成績書と品質記録の作成 | 検査値の登録 | 測定器の出力、検査記録 | 測定値、規格 | 成績書の下書き、承認依頼 | 規格外の値 |
| 経費精算と領収書の処理 | 領収書の写真の送信 | 領収書の写真 | 日付、金額、支払先 | 精算の行、承認依頼 | 読めない領収書 |
| 受領請求書の処理 | 請求書のメール着信 | 請求書のPDF | 請求元、金額、登録番号 | 支払予定の行、承認依頼 | 登録番号の欠け |
| 運行日報と点呼記録の収集 | フォームの送信 | 運行と点呼の記録 | 車両、運転者、点呼の時刻 | 運行記録の行 | 記入漏れ |
受注と違う点が大きいのは、次の3つの業務です。
- 日報:入力の様式を決めれば、読み取りが要らない
- 検査成績書:取り込み型と下書き型をつないだ形になる
- 領収書と請求書:保存の仕方に法律上の要件がある
日報は、スマートフォンの入力フォームにすれば、最初から項目に分かれて届きます。現場名や作業の種類は選択肢から選ばせ、読み取りが要るのは紙の日報が残る場合だけです。
検査成績書は、測定器の出力や検査記録を取り込み、その値を成績書の形に起こします。顧客への提出物なので下書きのあとに承認を挟み、下書きの側は見積りを自動で下書きする設計の考え方が使えます。
領収書と請求書は電子帳簿保存法で保存の要件が決まっているため、何をどの形で残すかを先に決めてから、取り込みの仕組みを組みます。要件は国税庁の電子帳簿保存法のページや顧問の税理士に確かめてください。
運用でつまずかないための事前対策
取り込みの自動化は、組むこと自体はそれほど難しくなく、つまずくのは動かしたあとです。よく出る4つの問題と、その対策を挙げます。
手書きとかすれたFAXは読み違える
手書きの数字や解像度の低いFAXは、読み違えが出ます。「1」と「7」、「0」と「6」のような似た数字は、特に間違えやすくなります。
数量と納期は、確実性が高くても担当者が一度は確認する運用にします。ここを省くと、誤った数量が出荷まで流れてしまいます。
FAX-OCRのカタログにある精度の数字が、自社の注文書でも出るとは限りません。本格的に使う前に、自社に届いた注文書で試してください。
同じ注文が重ねて届く
取引先が「届いていないかもしれない」と、同じ注文書を送り直してくることがあります。メールが別になるため、メールの識別子だけでは見分けられません。
案件IDを取引先と注文番号から作り、同じIDの行があれば台帳に書かずに知らせるだけにします。
確実性を信じすぎない
AIが返す確実性はAI自身の見立てにすぎず、高いと返した項目が誤っていることもあります。
確実性だけで承認を省く運用にはしません。マスタとの照合と、担当者の承認を必ず通します。
マスタが古いと照合が効かない
取引先マスタと品番マスタが古いと、正しく読み取った値まで「未登録」になってしまいます。通知が印だらけになり、担当者は結局すべての項目を見ることになります。
組む前に、使っていない取引先と品番を整理してください。取引先マスタの社名を注文書に印字される社名にそろえておくと、照合が外れにくくなります。
読み取りの指示を直す前に、照合の相手になるマスタが正しいかを確かめてください。通知の印が急に増えたときは、マスタの側も疑ってください。
まとめ
- 既製のFAX-OCRで足りるかを先に確かめ、足りない分だけを組む
- AIに任せるのは読み取りまで。取引先・品番・金額はマスタとルールで決める
- 基幹への登録は承認のあと。承認を待たず、台帳を見に行く形にする
手入力をやめる設計とは、形の違う入力を台帳の1行に変えることです。担当者が確認するのは確実性の低い項目だけにし、数量と納期は一度は人が見ます。
この記事で組んだワークフローは、JSONで配布しています。記事で説明した中心の流れだけを組んだもので、再送の確認・単価の計算・明細の分割は、運用に乗せるときに足す前提です。


ほかの業務の自動化の向き不向きは、業務自動化でできること一覧にまとめています。承認のあとに発注や請求を送る側の設計は、次の記事で扱います。



