FAX-OCRと基幹システムの連携方法｜API・CSV連携の違いと導入手順

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

B2B EC-COLUMN

FAX注文の手入力負担とOCR単体導入の限界

FAXで届いた注文書を手元に置き、販売管理システムの受注入力画面に得意先コードと品番、数量を打ち込む。
この作業を減らしたくてOCRを調べ始めると、今度は読み取ったデータが基幹システムにどう入るのかが分からなくなります。
ここで決めることになるのが、認識結果の渡し方です。
多くの製品が標準機能として備えるCSVなどのファイル連携は、出力の形を基幹システムの取込仕様に合わせやすく、API連携は開発の手数がかかる代わりに人の操作を挟まず流せる範囲を広げやすい方式です。
どちらを選んでも認識率は100%ではないため、誤読を確認・修正する仕組みを流れに組み込み、自社の基幹システム側に受け入れ口があるかを確かめたうえで、事前検証から段階的に本番へ進めるのが現実的な進め方になります。

手入力のどこに時間がかかっているのか

朝いちばんにFAXの受信トレイを確認すると、昨夜から届いた注文書が何枚も重なっている。
得意先ごとに書式が違い、ある会社は品名だけ、別の会社は先方の品番で書いてくる。
紙を一枚ずつ見ながら、販売管理システムの受注入力画面に得意先コード、品番、数量、納期を打ち込んでいく。
この繰り返しに時間を取られているなら、負担の中身を一度分けて見ておくと、OCRで何がどこまで変わるのかも見当がつけやすくなります。

受注の現場でFAXがどれだけ使われているかについては、食品業の小売・卸売の受注担当者を対象にした調査があります。
この調査では、受注方法としてFAXを利用している担当者の割合が67%(n=106)でした³。
同じ調査で、FAX・メール・電話で受注している担当者(n=90)の60%が、注文書の手入力に手間がかかると回答しています³。
いずれも2023年3月時点の食品業を対象とした調査なので業種が違えば比率は変わりますが、FAXで受けて手で入れるという流れが珍しいものではないことは読み取れます。

業種を広げた数字としては、日経クロステックが経済産業省委託・帝国データバンクの調査報告書(2019年2月公開)を引いて、日本の中小企業の7〜8割が受発注をFAXでやり取りしていると紹介しています⁴。
公開から年数が経っているため現在の比率をそのまま示すものではありませんが、FAX受注が一部の例外ではないという背景として押さえておけば十分です。

ここで注意したいのは、負担が大きいからといってFAXでの受注をやめる方向に話が進むとは限らない点です。
先ほどの調査では、FAX・電話で受注している担当者(n=80)の58.8%が、FAX・電話での受注を廃止すると取引に支障が出ると想定していました³。
受け取り方そのものを変えられないのであれば、変えられるのは受け取った後の処理です。

その処理の中身を分けてみると、打鍵そのものより照合と確認に時間がかかっていることが多くあります。
先方の品名から自社の品番を探す、ケース単位で書かれた数量をバラに換算する、「月末納品」という書き方を納品日に直す。
こうした判断が挟まるぶん、1枚あたりの時間は入力欄の数だけでは決まりません。
OCRで変わるのはこのうちどの部分なのかが、導入効果を見積もるときの出発点になります。

OCRを入れても転記が残るのはどこか

OCRは、紙に書かれた文字を読み取ってデータに変える技術です。
FAXで届いた注文書をスキャナや複合機で取り込み、得意先名や品番、数量といった項目を文字データとして取り出します。
先ほどの工程でいえば、紙を目で読む部分を機械が担うことになります。

ただし、読み取った結果がパソコンの画面やファイルに出てきた段階では、まだ受注データにはなっていません。
販売管理システムや在庫管理システムに受注として登録されて初めて、出荷指示や在庫引当につながります。
読み取り結果をその登録まで運ぶ工程が、OCR本体とは別に必要になります。

ここを人が担うとどうなるか。
画面に表示された読み取り結果を見ながら受注入力画面に打ち直すなら、紙を見て打っていたのが画面を見て打つのに変わるだけです。
品番の照合も数量の確認も残り、むしろ画面を二つ行き来するぶん視線の移動は増えます。
OCRを入れたのに思ったほど楽にならないという話は、この部分が設計から抜けているときに起きます。

そのため、製品を比べる前に決めておきたいのは、読み取った結果をどの経路で基幹システムに渡すかです。
この経路によって、導入時にかかる手数も、導入後に残る作業も変わります。

基幹システムへの連携方式(API連携・ファイル連携)の違いと確認ポイント

API連携の仕組みと工数

APIは、ソフトウェアの機能を外部のプログラムから呼び出すための窓口のことです。
FAX-OCRでいえば、認識処理を呼び出して結果を受け取り、受け取ったデータを自社で用意したプログラムが基幹システムへ渡す、という形になります。
間に人の操作を挟まずに済むため、受注登録まで一続きで流せる範囲を広げやすいのが特徴です。

気になるのは開発の重さですが、これは一様ではありません。
PFUのDynaEye 11 SDKは「認識ライブラリ」「コンポーネントキット」「部品」という3種の開発用部品を提供しており、認識ライブラリはOCR機能のみを利用する形、部品はコマンドラインインタフェースから開発不要で利用できる形と説明されています⁷。
同じ製品の中でも、呼び出し方によって必要な作り込みの量が違うわけです。

この違いは運用の作り方に直結します。
認識ライブラリのようにOCR機能だけを利用する部品を選ぶと、スキャナを制御する部分や、読み取り結果を人が確認して直す画面は呼び出す側で用意することになります。
一方、コマンドラインから呼び出せる部品であれば、夜間に動いている既存のバッチ処理の中に認識処理を組み込むといった使い方ができます。
API連携は開発が必要だと一括りにせず、どの部品をどう呼ぶのかまで下りて見積もる必要があります。

データの形についても確認が要ります。
DynaEye 11 SDKのファイル出力はXML形式での出力とCSV形式への変換に対応しています⁷。
APIで受け取る場合でも、最終的に基幹システムが読める形に整える工程は残るということです。

ここで挙げた部品の区分はDynaEye 11 SDKの仕様であり、他社製品のSDKが同じ分け方をしているとは限りません。
検討している製品について、開発なしで呼び出せる方法があるのか、それとも一から組む前提なのかを、開発者向けの製品資料で確かめておくと見積もりの幅が狭まります。

ファイル(CSV)連携の仕組みと扱いやすさ

もう一つの経路が、認識結果をCSVやテキストのファイルに出力し、基幹システム側の取込機能で読み込ませる方法です。
読み込む機能は基幹システムが元から持っているものを使うため、OCR側に求められるのは相手が読める形で出せるかどうかになります。

DynaEye 11では、出力形式(CSV、テキストなど)や出力方法(新規ファイルとして出力するか、既存ファイルに追加するか)を後続システムの仕様に合わせて選択でき、OCR項目のレイアウト、つまり出力カラムの順番も指定できるとされています⁶。

この指定ができるかどうかで、導入の手間はかなり変わります。
基幹システムの取込レイアウトは、1列目が得意先コード、2列目が伝票日付というように決まっているのが普通で、順番が違えば取り込めないか、別の項目として登録されてしまいます。
OCR側で並び順を合わせられるなら、間に変換プログラムを作らずに済みます。
1日分をまとめて1つのファイルに追記していくのか、処理のたびに新しいファイルを出すのかという違いも、基幹システム側の取込の回し方に合わせられます。

残る作業は、ファイルを出して取り込む操作です。
取込を基幹システムの画面から人が実行する運用なら、1日に数回その操作が入ります。
決まった場所に置かれたファイルを自動で取り込む仕組みが基幹システム側にあれば、そこに出力先を合わせることで操作自体を減らせます。
どちらになるかは基幹システム側の作り次第なので、取込の実行方法まで含めて確認しておくと、導入後の手数が見えてきます。

なお、ここで挙げた出力形式や並び順の指定はDynaEye 11の機能として公開されているもので、すべてのFAX-OCR製品が同じ柔軟さを備えているとは限りません。
出力できるのがCSV1種類だけで列の順番が固定という製品もあり得るため、自社の取込仕様に合わせられるかは製品ごとに確かめる必要があります。

RPAによる代行という選択肢について

基幹システムに取込機能もAPIもない、あるいは長く使っている専用システムで改修の見積もりが取りづらい。
そうした場合に候補として挙がるのが、RPA(画面の操作手順を記録し、ソフトが自動で実行する仕組み)に入力を代行させる方法です。

この方法は、基幹システム側に新しい受け入れ口を作るのではなく、人が行っていた画面操作をなぞる点が他の2つと異なります。
そのため確認すべき点も画面側に寄り、入力画面の構成が変わったときにどうするか、エラーが出たときにどこで止めて誰が引き取るかを決めておくことになります。
どの範囲まで任せられるかはRPA製品と基幹システムの画面の作りによって変わるため、連携方式として横並びに比べるより、実際の画面で試して判断する性質のものだと考えておくほうが安全です。

また、OCRと基幹システムの間を汎用のデータ連携ツールでつなぐ経路もあります。
たとえばASTERIA Warpは、企業内外のシステムをノーコードでつなぐデータ連携ミドルウェアとして、Excelなどの業務アプリやクラウドサービスを含む100種類以上の接続先に対応し、導入社数は2023年8月に1万社を突破したと公表されています²。
これはFAX-OCR製品との連携実績を示すものではありませんが、出力されたファイルを加工して基幹システムへ渡す部分を、専用の開発ではなく汎用ツールで担う選択肢があることは知っておいて損がありません。

どの経路を通るにしても、最後は基幹システムが受け取れるかどうかで決まります。

自社の基幹システム側の受け入れ口を確認するポイント

ここまではOCR側が何を用意しているかの話でした。
見落としやすいのは、受け取る側にも入口が必要だということです。
OCR製品にAPIがあっても、基幹システムが外部から受注を登録できるようになっていなければ、認識結果の行き先がありません。
製品選定がほぼ固まった段階でここが詰まると、読み取りはできても結局人が打ち直すことになります。

確認しておきたいのは、おおむね次の内容です。
CSVなどのファイルを取り込む機能があるか、そのレイアウト仕様書を出してもらえるか。
外部から受注を登録できるAPIが公開されているか、公開されている場合は受注ヘッダだけか明細も含むかという範囲。
取込でエラーが出たときに何が表示され、取り込まれた後の修正をどの画面で行うか。
そして、得意先コードや品番の桁数・体系が、注文書に書かれている内容からそのまま作れるものかどうかです。

これらはOCR側の仕様から考えて必要になる確認の観点であり、自社の基幹システムで実際にどこまで対応できるかは、提供元や保守を担当している会社に個別に聞くしかありません。
問い合わせるときは連携できますかと尋ねるより、CSVの取込機能はあるか、取込レイアウトの仕様書はあるか、APIは公開されているかと分けて聞いたほうが、返ってくる答えがそのまま判断材料になります。

OCRの誤読を基幹データに流し込まないための確認フロー

認識率の差は何を意味するか

連携方式が決まっても、流し込む中身が正しいかどうかは別の話です。
OCRの認識率は製品や方式によって差があり、100%になるものではありません。

PFUが公開している比較では、PFU基準帳票を用いた検証で、従来型OCRの認識率80%に対してAI-OCR(DynaEye 11)は98%という結果が示されています¹。
ここでいうAI-OCRは学習させた認識エンジンを使うもので、従来型は文字の形をあらかじめ定義したパターンと照合する方式を指します。

この数値を読むときは条件を外さないことが大切です。
PFU基準帳票という決まった帳票を使った検証値であり、帳票の種類や記入のされ方によって数値は変わります。
手書きの多い注文書や項目数の多い帳票で同じ結果になるとは限らず、他社のFAX-OCR製品に当てはめられる数字でもありません。

そのうえで、98%という数字をほぼ間違えないと読むか、残りをどうするかと読むかで設計は変わります。
受注データで困るのは、誤りの数より誤る場所です。
備考欄の文字が1字違っても後工程は動きますが、数量の桁が1つ違えば出荷数と在庫が狂い、取引先からの連絡で初めて気づくことになります。
得意先コードや品番の誤りも、別の相手や別の商品として登録されるため、後から探し出すのに時間がかかります。

つまり必要なのは、認識率の高い製品を選ぶことと、誤りが基幹システムに入る前に止まる場所を作っておくことの両方です。

確認を挟む位置と、自動化との両立

確認を入れると自動化の意味がなくなるのではと感じるかもしれませんが、この二つは二択ではありません。
DynaEye 11では、スキャナ読取り、帳票認識、修正画面、データ出力、アプリケーションの起動までをボタン一つで実行できるように連携機能を設定できるとされています⁶。
読み取りから出力までの流れの中に、人が確認して直す画面が組み込まれている形です。

この形にすると、担当者の役割が変わります。
紙を見て全項目を打ち込む人から、読み取り結果のうち確認が必要な箇所を見て直す人になります。
どこを見るかは運用で決めることになり、全項目を原本と突き合わせるのか、数量・単価・得意先コードのように誤りが後工程へ波及する項目に絞るのかで、1枚あたりの時間は大きく変わります。

修正をどの段階で行うかも決めておきます。
修正画面で直してから出力すれば、基幹システムには確認済みの値だけが入ります。
先に取り込んでから基幹システムの受注画面で直す運用にすると、取り込んだ時点で在庫引当が動く仕組みの場合に後始末が増えることがあります。
自社の基幹システムが取込直後に何を動かすのかを踏まえて、どちらに寄せるかを選ぶことになります。

なお、API連携でOCR機能のみを利用する部品を選んだ場合は、この確認画面も自分たちで用意する側になります⁷。
開発工数を見積もるときは、認識処理を呼ぶ部分だけでなく、確認と修正をどこでどう行うかまで含めて考えておくと、後から追加する事態を避けやすくなります。

こうした仕組みを入れても、誤りがまったく出なくなるわけではありません。
減るのは、紙を見て打鍵する作業と、同じ内容を二度入力する手間です。
残るのは、読み取り結果と原本を見比べる確認と、判断が必要な項目の処理です。
導入後の体制を考えるときは、この残る確認を誰がいつ行うかまで決めておくと、運用が始まってから慌てずに済みます。

連携導入までの検証・段階導入の進め方

無償事前検証で精度を確かめる

ここまでの判断材料は、どれも自社の注文書で確かめないと最終的な答えが出ません。
得意先ごとに書式が違う、担当者の手書きで数量が追記されている、FAXを通ったことで線がかすれている。
こうした条件は、手元の帳票を実際に読ませてみないと分からないためです。

製品によっては、導入前に自社帳票を試せる仕組みが用意されています。
DynaEye 11 Entry AI-OCRを対象とした無償事前検証サービスでは、PFUの技術者のコメントが付いたOCR評価結果(PDF)と、サンプル帳票のOCR結果(CSV)を受け取れます⁵。
OCRしたい項目として指定できるのは、帳票1種類あたり最大20項目までです⁵。

この上限から逆算すると、何を検証に出すかを先に決めることになります。
受注登録に欠かせない項目、たとえば得意先、伝票日付、納品希望日、品番、数量、単価といったところから埋めていき、読み取れなくても運用で補える項目は後回しにする。
この取捨選択を行う過程そのものが、連携で渡す項目の洗い出しになります。

検証の条件は製品ごとに異なります。
ここで挙げた項目数や提供物はDynaEye 11 Entry AI-OCRのサービス内容であり、他製品で同じ条件の検証が受けられるとは限りません。
複数の製品を比べるなら、何枚・何項目まで試せるのか、結果として何を受け取れるのかを揃えて聞いておくと比較できます。

CSVサンプルで連携先の取込を確認する

事前検証で受け取るものには、評価資料だけでなくOCR結果のCSVも含まれています⁵。
精度を確かめるために読むのはもちろんですが、このファイルは別の使い方もできます。
自社の基幹システムの取込機能に実際に通してみる、という使い方です。

通してみると、精度とは別の問題が見えてきます。
列の順番や項目名、文字の全角と半角、日付の書き方、コードの桁数。
読み取り自体は正しくても、基幹システムが期待する形と違えば取り込めません。
この食い違いを導入前に把握できていれば、OCR側の出力設定で合わせるのか、間に変換を挟むのかを、契約前の見積もりに織り込めます。

もう一点、取り込めたことと正しい受注になったことは別だと押さえておきます。
先方の品番と自社の品番が違う取引先があるなら、その変換をどこで行うかを決めなければなりません。
OCR側の設定で置き換えるのか、間のツールで対応表を持つのか、基幹システムの取込時に変換するのか。
どこでもできるように見えて保守のしやすさは置き場所で変わるので、誰が対応表を更新するのかまで含めて決めておくと後が楽になります。

段階導入で本番反映前にリスクを抑える

精度とデータ形式の見通しが立ったら、いきなり全ての得意先・全ての帳票を切り替えるのではなく、範囲を区切って始めるほうが扱いやすくなります。
一度に切り替えると、誤読による問題と連携仕様による問題が同時に出て、どちらが原因かの切り分けに時間がかかるためです。

限定運用の段階では、特定の1〜2社の注文書だけを連携に通し、しばらくは従来どおりの手入力も並行して行って結果を突き合わせます。
一時的には手間が増えますが、どの項目でどれくらい修正が入るのか、確認に何分かかるのかが実際の数字で分かります。
並行している間は、問題が起きても従来の方法で受注を処理できるため、取引先に影響を出さずに済みます。

対象を広げる判断は、この並行期間に見えたもので行います。
修正がほとんど入らない項目は確認を軽くする、特定の得意先の帳票だけ誤読が多いなら書式の相談をするか確認を厚くする、といった調整ができます。
帳票の種類を増やすときは新しい書式ごとに同じ手順を踏むことになるので、最初の1種類で手順を固めておくと二つ目以降は短く済みます。

この進め方で減るのは、紙を見て基幹システムに打ち込む転記と、読み取り結果を見てもう一度打ち直す二重入力です。
残るのは、読み取り結果の確認と、判断が必要な項目の処理、そして新しい書式が増えたときの設定作業です。
どこまで減らせるかは自社の帳票と基幹システムの受け入れ口の組み合わせで決まるため、検証の段階で手応えを確かめてから投資の規模を決めるのが、無理のない順番になります。

連携方式そのものの違いは、次の観点に当てはめると自社の条件でどちらを選ぶかが見えてきます。

自社の注文書のばらつきと、いま使っている基幹システムの受け入れ口の組み合わせは、製品資料を読み比べても判断がつきにくいところです。

実際の注文書と受注登録の手順を見せていただければ、どの項目を連携で渡し、どこに確認を残す形なら無理なく回るかを一緒に整理できます。無料相談で要件を整理する

連携方式(API連携・ファイル連携)の比較

OCR側が用意する機能という観点から、データの渡し方、出力形式の調整、開発の手数、受け取る側の条件、運用時の手数という項目ごとにまとめています。

• データの渡し方：API連携は認識結果をプログラムから直接受け渡し、ファイル連携はCSVやテキストに出力して基幹システムの取込機能で読み込ませる

• 出力形式の調整：ファイル連携は出力形式や出力方法、OCR項目の並び順を後続システムの仕様に合わせて選べる標準機能として用意されている製品がある

• 開発の手数：API連携は呼び出す側のプログラムが必要で、OCR機能のみを使う部品を選ぶと確認・修正の画面も自分たちで用意することになる

• 基幹システム側の条件：ファイル連携はファイル取込機能、API連携は外部から受注を登録できるAPIの公開が、それぞれ受け取る側に必要になる

• 運用時の手数：ファイル連携はファイルを出して取り込む操作が残り、API連携はその操作を含めて人の手を挟まずに流せる範囲を広げやすい

基幹システム側に取込機能しかないならファイル連携、受注登録まで人の操作を挟まず回したいならAPI連携というように、受け取る側の受け入れ口から選び分けます。

要点の整理

連携方式の選び方	基幹システム側に取込機能があるならファイル連携、受注登録まで人の操作を挟まず回すならAPI連携を軸に検討する
基幹システム側の確認	ファイル取込機能の有無と取込レイアウト仕様書、受注登録に使えるAPIの公開範囲を提供元に分けて確認する
認識率の読み方	PFU基準帳票での検証値は従来型80%・AI-OCR98%。帳票の種類で変わるため自社帳票で確かめる
誤読への備え	確認・修正の画面を読み取りから出力までの流れに組み込み、数量や得意先コードなど後工程へ波及する項目を重点的に見る
導入の順番	事前検証で精度と出力形式を確かめ、一部の得意先で並行運用してから対象を広げる

読み取り精度の見通しが立っても、取込仕様の合わせ方や段階導入の区切り方は社内だけでは決めにくい部分が残ります。 現在の受注処理の流れをうかがったうえで、どの得意先から試すか、本番に広げる前に何を確認しておくかを具体化できます。

よくある質問

手書きのFAX注文書でも同じ認識率が期待できるか

PFU基準帳票を用いた検証では従来型OCRの80%に対してAI-OCRが98%という結果が示されていますが¹、これは決まった帳票での検証値です。
手書きの文字は書き方の個人差が大きく、FAXを通ることで線がかすれることもあるため、同じ数値が自社の手書き注文書に当てはまるとは限りません。
手書きの記入が多い帳票ほど、事前検証で実物を読ませて確かめる意味が大きくなります。

基幹システムがクラウド型でもファイル連携やAPI連携は使えるか

クラウド型かどうかよりも、その基幹システムがファイルの取込機能やAPIを備えているかで決まります。
クラウドサービスの場合、ファイルを置く場所が社内のフォルダではなくサービス側の画面からのアップロードになることがあり、その場合は出力したCSVを誰がいつ上げるかという運用が加わります。
APIが公開されていれば登録までの操作を減らしやすくなりますが、公開されている範囲は製品ごとに違うため、受注登録に使えるAPIがあるかを提供元に確認してください。

RPAでOCR結果を入力する方法はAPI連携やCSV連携とどう違うか

API連携やCSV連携が基幹システムのデータの入口を使うのに対し、RPAは人が行っていた画面操作を代行します。
取込機能もAPIもない基幹システムで候補になりますが、入力画面の構成が変わると動かなくなる、エラーが出たときの扱いを決めておく必要があるなど、確認すべき点が画面側に寄ります。
どの範囲まで任せられるかは製品と画面の作りによって変わるため、横並びの比較表で決めるより実際の画面で試して判断する性質のものです。
なお、どの方式を選んでもOCRの読み取り結果を確認する工程は別途必要になります。

無償の事前検証サービスはどのように申し込み、何が得られるか

DynaEye 11 Entry AI-OCRを対象とした無償事前検証サービスでは、製品サイトの申込フォームから自社の帳票とOCRしたい項目を指定して申し込みます。
受け取れるのは、PFUの技術者のコメントが付いたOCR評価結果(PDF)と、サンプル帳票のOCR結果(CSV)です⁵。
指定できる項目は帳票1種類あたり最大20項目までで⁵、読み取り精度の確認だけでなく、受け取ったCSVを基幹システムの取込に通して形式の食い違いを調べる材料としても使えます。

1. 1　出典：株式会社ピーエフユー（リコーグループ）「FAX注文書はOCRできる？精度を向上させる3つのポイント」（2025年）
2. 2　出典：アステリア株式会社「データ連携ツール「ASTERIA Warp」導入社数1万社を突破」（2023年）
3. 3　出典：株式会社ハンモック「食品業の受注業務に関する実態調査」（2023年）
4. 4　出典：日経BP（日経クロステック）「中小企業の8割が「ファクスで受発注」の現実、DX時代に日本の競争力が失われる」（2019年）
5. 5　出典：株式会社ピーエフユー（リコーグループ）「DynaEye 11 無償事前検証サービス」（2025年）
6. 6　出典：株式会社ピーエフユー（リコーグループ）「DynaEye 11 機能紹介（システム連携）」（2026年）
7. 7　出典：株式会社ピーエフユー（リコーグループ）「DynaEye 11 SDK 製品概要（API機能）」（2026年）