FAX-OCRと基幹システムの連携｜取込形式の合わせ方と導入前に確かめる項目

◆監修・編集責任者　小園 将隆　2026年10月6日

B2B EC-COLUMN

FAX-OCRの結果は基幹にどう流れ、手作業はどこに残るのか

取引先から届くFAX注文書を、受注担当者が一枚ずつ販売管理の画面へ打ち直している。
OCRの話は出たものの、読み取った結果が基幹システムにどう入るのか分からず、判断が止まっている。
この場面で置き換えられるのは「見て打つ」作業で、FAX-OCRによる読み取りとCSV出力まで進められます。
一方、読み取り結果の確認・修正、取引先の表記を自社コードへ合わせる突合、取込時のエラー対応には人の手が残ります。
基幹側の取込形式・文字コード・必須項目は製品ごとに違います。
そのため「そのまま入る」かどうかは、自社の取込仕様書と実際のFAXで試すまで判断できません。

受信から取込までの5つの工程

FAXで届いた注文書は、まず画像として受け取ります。
複合機で受信して紙に印刷する運用なら、その紙をスキャンして画像に戻す手間が加わります。
そのため、受信した時点で画像ファイルとして保存できるかどうかが、最初の分かれ目になります。
OCRはその画像から、取引先名、品名、数量、納期といった文字を読み取り、項目ごとのデータに分けます。
読み取ったデータは人が確認・修正し、基幹システムが取り込める形のファイルに書き出します。
最後に、基幹の取込機能でそのファイルを読み込みます。

つまり、受信、読み取り、確認・修正、出力、取込という5つの工程を通ります。
手入力のときは、担当者が注文書を見ながら受注画面へ一項目ずつ打ち込み、この5つを一人の頭の中で同時にこなしていました。
OCRが肩代わりするのは、そのうち「見て打つ」部分です。

打ち込みながら自然にしていた判断は、工程のどこかに残ります。
たとえば「この品名は自社の商品コードでいうとどれか」「数字がかすれているが、いつもの数量だろう」といった判断です。
手作業がどれだけ減るかは、こうした判断をどの工程で、誰が、どの画面で行うかで決まります。

確認・修正で人が見る箇所

人の判断が残る場所は、大きく3つあります。
1つ目は、読み取り結果の確認・修正です。
ハンモックのDX OCRは、読み取り結果の自信度を色分けし、精度に自信のない文字列の枠を赤色で示すと説明しています³。
この場合、担当者は原本の画像と読み取り結果を見比べ、赤枠の箇所から確かめていきます。
ただし、色分けは確認の順番をつける手がかりで、赤枠のない箇所が正しいと保証するものではありません。
また、これは1製品の機能説明であり、OCR製品が一様に同じ画面を備えているわけではありません。

2つ目は、コード突合です。
FAXに書かれた品名や取引先名は、送ってきた取引先側の書き方です。
基幹に受注として登録するには、その品名や取引先を、自社の基幹に登録されている商品や得意先と結び付ける必要があります。
手入力のときに担当者が頭の中で済ませていた対応付けは、OCRを入れると独立した作業として表に出てきます。

3つ目は、取込エラーへの対応です。
出力したファイルを基幹に読み込んだとき、必須の項目が空いていたり、登録されていないコードが含まれていたりすると、その行が取り込まれないことがあります。
原因を確かめて直し、もう一度取り込む作業は、確認・修正を通過した後に発生します。
担当を決めておかないと、誰の仕事でもない作業として残りやすい部分です。

手入力の負担を示す調査

食品の小売・卸売業で受注業務に携わる106名を対象にした2023年3月のインターネット調査では、受注方法としてFAXを利用する割合が67%でした²。
同じ調査で、注文書の手入力に手間がかかるとの回答は60%でした²。

この調査は、OCRを提供するハンモックが自社サービスの背景として公表したもので、対象は食品の小売・卸売業に限られます。
業種を問わずFAXが同じ割合で使われているとは言えません。
それでも、この対象では、FAXで受注した注文書を手で入力する負担を感じている担当者が半数を超えていました。

ここで考えておきたいのは、自社の負担の中心が「打つこと」なのか「判断すること」なのかです。
打鍵の量が負担なら、読み取りと出力で減らせる部分が大きくなります。
品名とコードの照合に時間を取られているなら、OCRの読み取りだけでは負担が残ります。
その場合の焦点は、出力の段階でコードをどう合わせるかです。

▼ 図の内容を文字で読む

1. 受信：注文書を画像として受け取る
2. 読み取り：取引先名・品名・数量・納期を項目ごとのデータに分ける
3. 確認・修正：担当者が確認して直す
4. 出力：基幹が取り込める形のファイルに書き出す
5. 取込：基幹の取込機能でファイルを読み込む

▼ 図の内容を文字で読む

• 確認・修正
  • 原本の画像と読み取り結果を見比べる
  • 誤りを直す
• コード突合
  • 取引先側の品名・取引先名を確認する
  • 自社の商品・得意先に結び付ける
• 取込エラー対応
  • 必須項目の空欄や未登録コードで止まった行を直す
  • 原因を確かめてもう一度取り込む

OCRの出力形式と基幹の取込条件をどう合わせるか

OCR側で調整できること

基幹の取込機能でファイルを読み込むとき、どの列に何を置くか、どのコードで指定するかは基幹側の決まりに従います。
OCRの出力をその決まりに近づけられれば、出力から取込までの間に挟む手作業が減ります。

OCR側でできる調整として、確認できた例は次のとおりです。
ハンモックのDX OCRは、後続のシステムに合わせて、出力するCSVの項目を選んだり並べ替えたりできると説明しています³。
同じ製品は、特定の文字列から、基幹システム側が求める正規コードへ置換・追記できるとも説明しています³。
PFUのコラムは、DynaEye 11の機能として、後続の業務システムの仕様に合わせた形式に変換して出力する機能に触れています¹。

置換がどう効くかを、仮の例で考えます。
取引先から「しょうゆ1L×12」と書かれた注文書が届き、自社の販売管理ではその商品を独自の商品コードで登録しているとします。
置換の設定に「しょうゆ1L」と自社コードの組を登録しておけば、出力の段階でコードが付いた状態になります。
担当者が商品一覧を引いてコードを探す手間は、その分減ります。
反対に、取引先が書き方を変えたり、新しい商品を注文してきたりして対応表にない文字列が来ると、その行は人が対応付けることになります。

置換は、誰かが対応表を作り、増やし続けることで機能します。
どの範囲の文字列をどこまで置換できるか、取引先ごとに別の書き方を登録できるかは、製品の説明だけでは分かりません。
導入を検討する製品で、自社の実際の品名を使って設定を試すのが確実です。

基幹側で確認する項目（形式・文字コード・必須項目・マスタ）

OCRの出力をいくら調整できても、合わせる先の条件が分からなければ設定できません。
基幹の取込条件は製品ごとに違うため、手元の取込仕様書や操作マニュアル、提供元への問い合わせで確かめます。
見ておきたいのは次の項目です。

<ul><li>形式：CSVのように区切り文字で列を分ける形式か、決まった桁数で並べる形式か、見出し行を付けるか</li><li>文字コード：基幹が受け付ける文字コード（合わないと品名や取引先名が文字化けする）</li><li>必須項目：受注日、得意先、商品、数量など、空欄では取り込めない項目はどれか</li><li>マスタ未登録時の扱い：登録されていないコードが来たとき、取込全体が止まるのか、その行だけ保留されるのか</li><li>明細の持ち方：1行に1明細を並べるのか、注文の見出しと明細を分けて持つのか</li><li>日付・数値の書き方：西暦か和暦か、区切り記号、桁区切りの有無</li></ul>

なかでも判断が分かれやすいのは、マスタ未登録時の扱いと明細の持ち方です。
未登録のコードで取込全体が止まる基幹なら、新しい商品の注文が1行あるだけで、その日の取込が遅れます。
行ごとに保留して後から直せる基幹なら、取込は進めつつ、例外だけを人が処理できます。
明細の持ち方が合わない場合は、OCRの項目の並べ替えだけでは吸収できず、間に変換の工程を挟む必要が出てきます。

▼ 図の内容を文字で読む

• ファイルの形
  • 形式（区切り文字か決まった桁数か、見出し行の有無）
  • 文字コード
  • 日付・数値の書き方
• 取り込めない条件
  • 必須項目
  • マスタ未登録時の扱い
• データの持ち方
  • 明細の持ち方（1行1明細か、見出しと明細を分けるか）

CSV取込・API連携・中間変換はどの条件でどれを選ぶか

連携方法を同じ軸で比べる

OCRの出力を基幹へ渡す方法は、出力ファイルを基幹の取込機能で読み込む形が基本です。
そこから、間に変換を挟む形、ファイルの置き場所を介する形、システム同士を直接つなぐ形に分かれます。
違いは、基幹側にどんな受け口が必要か、人の確認をどこに置くか、設定や開発を誰がどこまで行うかに表れます。

OCRが基幹の取込仕様どおりのCSVを出せるなら、担当者は確認・修正を終えたデータを出力し、基幹の取込画面で読み込むだけで済みます。
OCRの出力がそのままでは合わない場合は、間に表計算ソフトや変換用のツールを挟みます。
そこで列の組み替えやコードの付け替えをしてから取り込むのが、中間変換です。
API連携は、システム同士がファイルを介さずにデータを直接受け渡す方法です。
ただし、基幹とOCRのどちらがどの範囲で対応しているか、追加の費用がかかるかは製品ごとに違い、提供元の仕様で確かめる必要があります。

表のうち判断が分かれるのは、確認工程の置き場です。
CSVを直接出す方法では、人の確認はOCRの確認画面に集まります。
中間変換を挟むと、変換後のファイルにも目を通す工程が増え、変換の手順や対応表を保守する人も必要になります。
手間を減らすつもりで工程を一つ足していないか、という視点で見ると選びやすくなります。

外部ストレージ連携という選択肢

CSVの受け渡し以外の形として、ハンモックのDX OCRは外部ストレージ連携を挙げています。
boxやkintone内のファイルを取り込み、OCRの出力データをそこへ格納できるという説明です³。

受信したFAXを共有のフォルダへ保存して部署で見ている運用や、受注の一部をkintoneで管理している運用では、ファイルの置き場所をそろえられる点が利点になります。
ただし、これは基幹システムへの直接連携の説明ではありません。
ストレージに置かれたデータを基幹へ取り込む段取りは、別に必要です。
そこを誰がどう行うかまで決めて初めて、手作業の減り方が見えてきます。

選ぶ前に聞くこと

どの方法を選ぶかは、基幹とOCRの両方の提供元に、次の問いを投げると整理しやすくなります。

<ul><li>基幹側：ファイルの取込機能はあるか、取込仕様書はあるか、APIはあるか、それらに追加の契約や費用が必要か</li><li>OCR側：出力項目の選択・並べ替え、コード置換、文字コードの指定ができるか、その設定を自社で行えるか</li><li>両方：取込エラーが出たとき、原因の切り分けをどちらに相談するか</li></ul>

基幹にファイルの取込機能があり、OCR側の出力調整でその仕様に合わせられる見込みがあるなら、CSVを直接出す方法から試すのが分かりやすい選択です。
出力ファイルを開けば何が入っているかを目で確かめられ、取込エラーの原因もたどりやすいからです。
API連携は、扱う件数が増えて受け渡しの手間そのものが負担になったときに、対応範囲と費用を確かめたうえで検討すれば足ります。

▼ 図の内容を文字で読む

• CSV直接出力
  • 基幹にファイルの取込機能がある
  • OCR側の出力調整で取込仕様に合わせられる見込み
  • 最初に試す方法
• 中間変換
  • 出力がそのままでは合わない場合に挟む
  • 変換後のファイルにも目を通す工程が増える
  • 対応表を保守する人が必要
• 外部ストレージ経由
  • ファイルの置き場所をそろえられる
  • 基幹へ取り込む段取りは別に必要
• API連携
  • ファイルを介さずデータを直接受け渡す
  • 対応範囲と費用は提供元の仕様で確かめる
  • 件数が増えて手間が負担になったときに検討

取引先ごとに書式が違うFAXや手書きは、どこまで通るのか

精度の数値の読み方

OCR製品の説明では、読み取り精度が数値で示されることがあります。
ただ、その数値は測った帳票と条件に結び付いており、自社のFAXにそのまま当てはまるものではありません。

PFUのコラムは、同社の基準帳票を用いた検証で、従来OCRの認識率が80%だったのに対し、AI-OCRでは98%だったと紹介しています¹。
これは提供元が用意した基準帳票での値で、検証の実施時期は記載されていません。
取引先ごとにレイアウトが違い、送信の過程でかすれや傾きが生じたFAX注文書で、同じ値が出るとは限りません。

もう一つ気を付けたいのは、認識率は読み取りの正しさを示す値で、基幹に取り込めた割合を示す値ではないことです。
読み取りが正しくても、品名が対応表になければコードは付きません。
必須項目が空なら、取込は止まります。
精度が高いほど確認・修正の手間は減る方向に働きますが、コード突合と取込エラーへの対応は、精度とは別に残ります。

手書きの実証が示すこと

手書きについては、NTTデータが自治体と行った検証があります。
2018年12月から2019年3月にかけて、6自治体の実帳票73種の手書きサンプルを対象に、雑字やくせ字を含めてDX Suiteで読み取り精度を測りました。
その結果、正読率は約93%で、参加団体からは業務や帳票によって実用に耐え得る可能性があるという意見が出たとされています⁴。

この数値も、条件とセットで読む必要があります。
対象は自治体の実帳票で、民間のFAX注文書ではありません。
PFUの値とは帳票も条件も違うため、両者を並べてどちらが高いかを比べたり、平均したりすることはできません。

それでも、2つの資料から言えることはあります。
精度の値は、どの帳票を、どんな条件で読ませたかによって変わる、ということです。
NTTデータの検証では、帳票定義（どこに何が書かれているかをOCRに教える設定）を、AI-OCRに習熟していない人が行ったことが測定条件に含まれていました⁴。
取引先ごとに書式が違うFAXを扱うなら、書式の種類ごとに準備が要るのか、どこまで自動で対応できるのかも、精度と並ぶ確認点になります。
自社の注文書で試さない限り自社での結果は分からない、というのが数値から引き出せる結論です。

確認・補正の運用

読み取りに誤りが混じる前提に立つと、確認・修正を誰がいつ行うかが、導入後の手間を左右します。
考え方としては、品名や取引先の事情を知っている受注担当者が、出力の前に確認画面で直すのが基本の形になります。
出力した後や基幹に取り込んだ後で誤りに気付くと、ファイルや基幹のデータを直す手間が重なるためです。

確認の範囲は、最初から絞らないほうが安全です。
試験の段階では全項目を原本と見比べ、赤枠などの目印がない箇所でどれだけ誤りがあったかを記録します。
目印のない箇所の誤りが少ないと分かってから、目印のある箇所と、数量や納期のように間違うと影響が大きい項目に確認を絞ります。
この順で進めると、確認を減らした判断に根拠が残ります。

手書きや不鮮明なFAXは、無理にOCRで通そうとせず、手入力に回す例外の道を残しておく考え方もあります。
注文書の大半が定型の印字なら、そちらで手入力が減ることのほうが、全体の負担には効いてきます。

▼ 図の内容を文字で読む

1. 全項目を原本と見比べる：試験の段階では確認の範囲を最初から絞らない
2. 目印のない箇所の誤りを記録する：赤枠などの目印がない箇所でどれだけ誤りがあったかを数える
3. 確認を絞る：目印のある箇所と、数量や納期のように影響が大きい項目に絞る

導入前に、基幹の仕様とFAXサンプルで何を確認するか

サンプルの集め方

試験の材料は、実際に届いたFAXです。
見本としてきれいな注文書だけを選ぶと、導入後に初めて読み取れない書式に出会うことになります。
次のような区分を意識して集めます。

<ul><li>取引先ごとの書式（よく届く取引先から順に）</li><li>印字か手書きか、印字に手書きの追記があるか</li><li>かすれ・傾き・黒つぶれのある不鮮明なもの</li><li>複数ページにまたがる注文書</li><li>二重線の訂正や欄外の書き込みがあるもの</li></ul>

注文書には取引先名や取引条件が含まれるため、試験のために提供元へ渡す場合は、取扱いの約束を先に確かめておきます。
集めた枚数とその内訳を記録しておくと、試験結果を、どの種類の注文書で起きたかに分けて読めるようになります。

試験の確認項目

試験では、読み取りから基幹への取込までを通して行い、工程ごとに次の点を記録します。

<ul><li>確認・修正：赤枠など目印の件数、目印のない箇所の誤り、1枚あたりの確認・修正にかかった時間</li><li>コード突合：置換で自社コードが付いた行と、付かずに人が対応付けた行の数</li><li>取込：基幹の取込エラーの件数と理由（必須項目の空欄、未登録コード、文字化けなど）</li><li>保管：原本の画像と取り込んだデータを後から突き合わせられるか、保管場所と期間を決められるか</li></ul>

時間は、同じ注文書を手入力した場合と比べられるように測ります。
OCRの導入で減るのは打鍵の時間で、増えるのは確認と例外処理の時間です。
両方を同じ単位で並べないと、楽になったかどうかの感覚だけが残ります。

進める・見送るの判断基準を決める

合格の目安は、資料から借りてくることができません。
自社の受注件数、担当者の人数、締め時刻に左右されるからです。
そのため、試験の前に自社で基準を決めておきます。
たとえば「1枚あたりの確認・修正と例外処理の合計時間が、手入力の時間を下回るか」「取込エラーが、原因を直して再取込すれば解消できる範囲に収まるか」「置換の対応表に追加していくことで、人が対応付ける行が減っていくか」といった問いです。

結果は、進めるか見送るかの二択とは限りません。
よく届く取引先の印字の注文書では基準を満たし、手書きでは満たさないなら、対象を絞って始め、手書きは手入力に残す進め方もあります。
基幹側に取込機能がない、または仕様が合わず変換の保守が重くなりそうだと分かった場合は、OCRだけを先に入れるより、基幹側の取込方法を確かめるところへ戻るのが筋です。

どちらの結論になっても、試験で集めた記録は、提供元への質問や社内の説明にそのまま使えます。
FAX-OCRの結果が基幹に「そのまま入るか」という問いには、自社の注文書と取込仕様の組み合わせで試した記録をもとに答えを出すことになります。

▼ 図の内容を文字で読む

1. サンプルを集める：取引先ごとの書式、手書き、不鮮明なもの、複数ページなど実際に届いたFAXを集める
2. 読み取りと確認・修正：目印の件数、目印のない箇所の誤り、1枚あたりの時間を記録する
3. 出力して基幹へ取込：置換で付かなかった行と、取込エラーの件数・理由を記録する
4. 事前に決めた基準と照らす：試験の前に自社で決めた基準で、進める・対象を絞る・見送るを判断する

基幹の取込仕様書とOCRの出力項目を並べれば、ずれのある箇所は見えてきます。ただ、そのずれをOCR側・変換・運用のどこで埋めるかは、両方の仕組みを見比べないと決めにくい部分です。

手元の取込仕様書と実際のFAX注文書をもとに、出力の合わせ方と、試験で記録すべき項目を一緒に整理できます。無料相談で要件を整理する

要点の整理

軸	基準
手作業の残る場所	確認・修正、コード突合、取込エラー対応の3か所に担当を置く
出力の合わせ方	OCR側の項目選択・並べ替え・コード置換で、基幹の取込仕様にどこまで寄せられるか
基幹側の条件	形式・文字コード・必須項目・マスタ未登録時の扱い・明細の持ち方・日付と数値の書き方を仕様書で確かめる
連携方法	まずCSVの直接出力を検討し、合わなければ中間変換、APIは対応範囲と費用を確かめてから
精度の数値	測定条件が違う値は比べず、自社のFAXで試して判断する
判断基準	確認・修正と例外処理の時間、取込エラー、置換漏れの推移を見る基準を試験前に自社で決める

試験の判断基準は資料から借りられず、受注件数や締め時刻など自社の事情から決める必要があります。 試験の進め方と基準の置き方を相談しながら、進める・対象を絞る・見送るの判断材料をそろえられます。

よくある質問

基幹システム側に取込用のCSV仕様がない場合、OCRの導入はあきらめるべきですか。

すぐにあきらめる必要はありません。
まず基幹の提供元に、ファイルの取込機能やAPIがないか、追加の契約で使えるようにならないかを確かめます。
受け口がどうしても無い場合、OCRで減らせるのは原本を見て項目を拾う手間までで、基幹への入力は人が行うことになります。
その範囲で手間がどれだけ減るかを試験で測り、導入に見合うかを判断します。

取引先の商品コードが自社コードと違うとき、どこで変換するのが現実的ですか。

置換の対応表をどこで持つかで考えると整理できます。
OCR側に文字列から自社コードへ置換する機能があれば、出力の時点でコードを付けられ、取込前にファイルを作り直す手間が減ります。
OCR側で対応できない場合は、中間変換の段階で対応表を当てる方法があります。
どちらの場合も、新しい品名が来たときに対応表へ追加する担当を決めておかないと、人が対応付ける行は減っていきません。

読み取り結果の確認作業は、誰が担当し、どの時点で行えばよいですか。

品名や取引先の事情が分かる受注担当者が、出力の前に確認画面で行うのが基本の考え方です。
届くたびに処理するか、まとめて処理するかは、出荷や締めの時刻から逆算して決めます。
修正した内容と頻度を記録しておくと、対応表の追加や確認範囲の見直しに使えます。

手書きの注文書や不鮮明なFAXは、導入前の試験でどう扱えばよいですか。

試験から外さず、別の区分として含めます。
手書きや不鮮明なものは読み取り結果が印字の注文書と分かれることがあるため、結果を分けて記録します。
基準を満たさなければ、手書きは手入力に回す運用で始める判断もできます。

試験導入で見るべき件数や期間は、どう決めればよいですか。

決まった件数の目安はありません。
件数よりも、よく届く取引先の書式、手書き、不鮮明なものといった区分が一通り含まれることを優先します。
期間は、月末など受注が集中する時期を一度含むように取ると、繁忙時の確認時間や取込エラーの出方も確かめられます。

1. 1　出典：株式会社ピーエフユー「FAX注文書はOCRできる？精度を向上させる3つのポイント」（2025年）
2. 2　出典：株式会社ハンモック「食品業の受注業務に関する実態調査」（2023年）
3. 3　出典：株式会社ハンモック「DX OCRの機能一覧」（2026年閲覧）
4. 4　出典：株式会社NTTデータ「町田市、郡山市、市川市、つくば市、横浜市、福岡市におけるAI-OCR実用性の検証結果について」（2019年）