注文書の自動読込は取引先別に学習が必要？様式・方式別の枚数の考え方と試行の見方

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

B2B EC-COLUMN

注文書の自動読込は取引先ごとに学習させる必要があるのか

取引先ごとに様式の違う注文書がFAXやPDFで届き、基幹システムへの転記が追いつかない。
自動読込を試したくても、取引先別に学習させるのか、何枚読ませればよいのかが分からず、計画が立てられない。
学習が要るかどうかは、取引先の数ではなく読み取りの方式で決まります。
様式ごとに帳票を定義する方式、事前学習なしで項目を探す方式、見本で学習させる方式では、準備の単位がそれぞれ「様式の数」「補正に使う正解」「様式ごとの見本」に分かれます。
公式資料で確かめられた枚数は、ある学習型サービスの開始条件「5つ」だけで、実用精度の目安ではありません¹。
件数が多く、様式の変わらない取引先から、自社の注文書で試して判断するのが確かな進め方です。

帳票定義型・事前学習不要型・学習型の違い

「取引先別に学習させる」と聞くと、取引先の数だけ準備が要るように感じます。
ただ、自動読込の仕組みが見ているのは取引先の名前ではなく、注文書の様式、つまり品名や数量、納期が紙面のどこにどう書かれているかという作りです。
同じ取引先でも、部署や拠点で別の様式を使っていれば、準備は様式の数だけ必要になります。
反対に、たとえば複数の取引先が同じ市販の注文用紙を使っている場合は、取引先が違っても紙面は同じです。
そのため最初に数えるべきは取引先ではなく様式で、その様式をどう扱うかは、読み取りの方式によって大きく三つに分かれます。

一つ目は、様式ごとに「どの位置に何の項目があるか」を定義しておく帳票定義型です。
食品メーカーの日研フードは、注文の8割を占めるFAX注文書の基幹システムへの登録を、AI-OCR（画像から文字を読み取る光学文字認識に、AIによる認識を組み合わせたもの）で自動化した際、約400種類の帳票を設計する必要があったと報じられています³。
帳票は自社で設計する必要があるものの、慣れれば特別な知識がなくても扱いやすいという当事者の評価も紹介されています³。
この方式では「学習」というより「様式ごとの設定」が準備の中心になり、様式が増えれば、そのまま作業も増えます。

二つ目は、事前に様式を覚えさせず、項目名などを手掛かりに必要な値を探す方式です。
AI insideのDX Suiteは、定型・非定型を問わず事前学習不要で読み取れるサービスと説明されています²。
ここでいう「事前学習不要」は、使い始める前に様式ごとの準備をしなくてよいという意味で、どの注文書でも正しく読めることまで約束するものではありません。
読み違いが出たときにどう補正するかが、この方式での準備にあたります。

三つ目は、注文書の見本を読ませてモデル（読み取りの規則を持った仕組み）を作る学習型です。
開発者向けサービスであるMicrosoftのAzure Document Intelligenceでは、カスタムモデルにテンプレート型とニューラル型があり、テンプレート型は様式のバリエーションごとにモデルが必要、ニューラル型はすべてのバリエーションに一つのモデルを使うと説明されています¹。
同じ学習型でも、様式ごとにモデルを作るのか、まとめて一つで扱うのかで、取引先が増えたときの手間が変わるわけです。
なお、これは同サービスの仕様であり、受注システムやAI-OCR製品がすべて同じ作りになっているわけではありません。

自社の注文書がどのタイプに当たるかの見分け方

検討している製品がどの方式に当たるかは、製品名や「AI」という表現からは判断しにくいものです。
見分ける手掛かりは、新しい様式の注文書を初めて読ませるときに、何を用意するよう求められるかです。

• 読み取る位置や枠を様式ごとに指定する：帳票定義型の考え方
• 読み取りたい項目名を指定するだけで始められる：事前学習不要型の考え方
• 同じ様式の見本を登録してから使う：学習型の考え方

製品によって説明の言葉はまちまちなので、販売元には「新しい取引先の注文書が届いたら、誰が何をすれば読めるようになるか」を具体的に聞くと違いが見えます。
同時に、手元の注文書を取引先の一覧ではなく様式の一覧に並べ直しておくと、どの方式でどれだけの準備が要るかを自分で見積もれるようになります。
取引先は多いのに様式は少ない、あるいは取引先は少ないのに様式が多い、という偏りは、この並べ直しをして初めて見えてきます。

▼ 図の内容を文字で読む

• 帳票定義型
  • 準備の単位は様式の数
  • 新しい様式の帳票を設計する
• 事前学習不要型
  • 準備の単位は補正に使う確認済みの正解
  • まず読ませて読み違いを補正する
• 学習型
  • 準備の単位は様式ごとの見本
  • テンプレート型はバリエーションごとにモデルを作る
  • ニューラル型は一つのモデルで扱う

学習に必要な注文書の枚数は何で決まるか

学習型の開始条件と、画質・様式の揺れによる増減

方式が見えたところで、次に気になるのは「では何枚あれば読めるようになるのか」です。
公式資料で枚数が示されていたのは、学習型のうちMicrosoftのカスタム抽出モデルで、作業を開始するには同じフォームまたはドキュメントの種類の例が5つだけ必要とされています¹。
この数は学習を始められる最低限の条件で、5つ読ませれば実用的な精度になるという意味ではありません。
国内のAI-OCR製品や受注システムに同じ数が当てはまるとも言えないため、検討中の製品の必要枚数として読み替えないことが大切です。

同じ資料は、画質が低い場合は5つより多いデータセットを使うよう説明しています¹。
FAXで届いた注文書や、複写式の控えをスキャンしたものは、文字のにじみやかすれが出ていることがあります。
こうした注文書が中心なら、開始条件の数は下限と考え、普段届くままの画質の見本を多めに用意しておくほうが、試した結果を実際の運用に近づけられます。

もう一つ、枚数を左右するのが様式の揺れです。
テンプレート型はバリエーションごとにモデルが必要なので、同じ取引先でも欄の配置が違う注文書が混ざれば、それぞれに見本を用意することになります¹。
ニューラル型は、同じ情報を持ちながらページ構造が異なる文書に一つのモデルで対応するとされていますが¹、そのとき各バリエーションの見本をどれだけ含めればよいかは、この資料からは決まりません。

帳票定義型は「枚数」より「様式数」

帳票定義型では、問いの立て方そのものが変わります。
様式ごとに読み取る位置を定義するので、同じ様式の注文書を何枚集めても設定の手間は減らず、作業量は様式の種類の数で決まります。
日研フードが設計した約400種類という数も、注文書の枚数ではなく様式の数です³。
この方式で導入を見積もるときは、「何枚用意するか」ではなく「いくつの様式を、誰が、いつまでに定義するか」を数えることになります。

事前学習不要型の補正（Few-shot）の考え方

事前学習不要型では、最初の準備に見本の枚数を求めない代わりに、使いながら精度を補う考え方がとられています。
DX Suiteの項目抽出に追加されたFew-shot学習は、チェック済みの読取結果を参照して精度を高める機能で、学習データが少ない独自フォーマットの帳票を想定していると報じられています²。
ここで要るのは大量の見本ではなく、担当者が確認して直した「正解」です。
また、参照するデータはAI学習に利用されず各社の環境内で完結すると報じられており²、取引先から受け取った注文書の内容を外部の学習に使われたくない場合の確認点にもなります。

こうして並べると、「何枚必要か」の答えは方式ごとに単位が違います。
学習型は同じ様式の見本の数、帳票定義型は様式の数、事前学習不要型は補正に使う確認済みの正解です。
三者は製品も前提も異なるため、数字を足し合わせたり、横に並べて比べたりはできません。
自社の検討では、まず方式を確かめ、その方式の単位で準備量を数えるのが筋道です。

▼ 図の内容を文字で読む

• 開始条件の5つ
  • 学習を始められる最低限の数
  • 実用的な精度を保証する数ではない
• 画質が低い
  • FAXやスキャンの文字のにじみ・かすれ
  • 5つより多い見本を用意する
• 様式の揺れ
  • テンプレート型はバリエーションごとに見本とモデルが要る
  • ニューラル型は一つのモデルで扱うが、必要な見本の数は決まらない

どの取引先・様式から読ませると効果が出やすいか

件数×様式の固定度で並べる

準備の単位が分かると、取引先が多い場合にどこから始めるかも決めやすくなります。
ここで提案したいのは、取引先の数ではなく「注文件数」と「様式の固定度」の二つで並べる考え方です。
件数が多い様式ほど、一度準備すれば読み取りに回せる注文書が多くなります。
様式が変わらないほど、準備したものを長く使えます。
両方を満たす様式から始めれば、準備にかけた手間を早く取り戻しやすいという理屈です。

学習型の資料でも、テンプレート型はレイアウトが静的で一定の文書に向くとされています¹。
帳票定義型でも、様式が頻繁に変わる取引先は定義の手直しが続きます。
方式を問わず、固定された様式から着手すると準備が無駄になりにくいと考えられます。

並べ方は、次の手順で進められます。

1. 直近の一定期間に届いた注文書を、取引先ごとではなく様式ごとに分ける
2. 様式ごとに件数を数える
3. 過去に様式が変わったことがあるか、手書きの書き込みが多いかを書き添える
4. 件数が多く、変更の少ない様式を試行の候補にする

日研フードの例は、FAXで届く注文が大半を占めるという入口の偏りがあったことで、FAX注文書の登録をまとめて自動化する判断につながったと読めます³。
ただし、同社が約400種類の様式をどの順で設計したのかは、記事からは分かりません。
件数と固定度で並べる方法は、実測された効果ではなく、準備の手間を件数で回収するための考え方として使ってください。

手書き・低画質の様式の扱い

件数が多くても、手書きの注文書やにじみの多いFAXは、読み取り結果が安定しないことがあります。
こうした様式を最初の候補から外すか残すかは、事前には決めにくいところです。
前節で見たとおり、画質が低い場合は学習型でも見本を増やす必要があり¹、方式によっては補正の回数も増えます。
そこで、候補には含めたうえで試行の結果を見て判断し、修正が多すぎる様式は当面これまでどおり手入力に残す、という分け方が現実的です。
すべての様式を自動読込に乗せなくても、件数の多い固定様式を読めるようになれば、担当者が手で打つ注文書はその分だけ減ります。

▼ 図の内容を文字で読む

• 件数が多く変更の少ない様式
  • 準備した分を早く回収しやすい
  • 試行の最初の候補にする
• 手書きやにじみの多い様式
  • 読み取りが安定しないことがある
  • 候補に含め、試行の結果を見て判断する
• 試行で修正が多すぎる様式
  • 担当者の修正が多く手間が減らない
  • 当面は手入力に残す

様式が変わったとき・取引先が増えたときの対応

方式別の追加作業

導入が進むと、取引先が様式を改訂したり、新しい取引先が加わったりします。
そのときの追加作業も、方式によって違います。

帳票定義型では、新しい様式が届くたびに読み取り位置を定義します。
日研フードの事例では帳票を自社で設計しており³、新規の取引先や様式の改訂への対応も社内で進める形になります。
社内で素早く対応できる反面、受注担当者のうち誰が定義を作るのか、繁忙期に定義作業が後回しにならないかを決めておく必要があります。

学習型のテンプレート型は、バリエーションごとにモデルが必要なので¹、様式が改訂されれば新しいバリエーションとして見本を集め、モデルを用意することになります。
ニューラル型はすべてのバリエーションに一つのモデルを使いますが¹、新しい様式を加えたときにどの程度の見本を足し、モデルを作り直すのかは、製品や契約ごとに確かめる事柄です。

事前学習不要型は、項目名などを手掛かりに読むため、新しい様式でも事前の準備なしにまず読ませてみることができます²。
読み違いが出た様式は、確認済みの結果を参照させる補正で精度を上げていく考え方です²。

どの方式でも気を付けたいのは、様式の改訂に気付かないまま読み取りを続けてしまう場合です。
たとえば取引先が注文書の欄の並びを入れ替えたとき、位置で読む設定のままだと、数量の欄に別の値が入ったり、空欄のまま出力されたりするおそれがあります。
改訂を取引先から事前に知らせてもらう約束をしておくことと、読み取り後の確認で「いつもと違う」結果に気付ける手順を持つことの両方が、方式を問わず役に立ちます。

契約前に確認する項目

追加作業の費用、対応にかかる期間、再学習の手順は、製品や契約によって異なり、公開資料から一般的な答えを出せる部分ではありません。
そのため、契約前に次の点を販売元に確かめておくと、導入後に「誰がやるのか」で止まることを避けやすくなります。

• 新しい様式の追加や、改訂された様式の修正を、利用者側で行えるか、販売元への依頼が必要か
• 追加に必要な準備物（読み取り位置の定義、見本、項目名の指定、確認済みの正解など）
• 様式が変わったときに、読み取り結果の異常として知らせる仕組みがあるか
• 様式の追加やモデルの作り直しに費用がかかるか、かかる場合の範囲
• 依頼してから使えるようになるまでの期間

特に最初の二つは、受注担当者が自分で対応できるのか、販売元に依頼するのかを分けて聞くと、運用の体制が具体的に描けます。
依頼が必要な場合は、取引先が増える時期に合わせて対応が間に合うかどうかも、あわせて考えておきたいところです。

読取後の確認・修正と基幹システムへの取り込みの組み方

読取→確認→CSV・連携の流れ

読み取れるようになっても、注文がそのまま基幹システムに入るわけではありません。
読み取った値を確かめ、直し、基幹に取り込むまでを、ひと続きの流れとして組む必要があります。

日研フードでは、受信したPDFを専用フォルダに保存し、AI-OCRでテキスト化してCSVで出力し、基幹システムへ一括登録する流れを組んでいます³。
あわせて、基幹側もCSVを一括で取り込めるよう改修したと報じられています³。
読み取る仕組みだけを入れても、受け取る基幹側が一件ずつの手入力しか受け付けなければ、転記の手間は残ります。
取り込み口の準備も、導入の範囲に入れて考える必要があります。

PFUも、RPA（定型的なパソコン操作を自動で行うソフトウェア）やデータ連携の機能を備えたAI-OCRを選ぶと効率化しやすいとしています⁴。
CSVで渡すのか、連携機能で直接渡すのかは、基幹システムの側が何を受け付けられるかで決まります。

一方で、日研フードの記事には、読み取った後に誰がどう確認しているかは書かれていません。
確認の組み方は、自社で決める部分です。
注文書の誤りは出荷や請求にそのまま響くため、品番、数量、納期、届け先のように間違えると影響の大きい項目を決め、読み取り結果と元の画像を並べて確かめる手順を置くと、確認する場所を絞れます。
読み取れなかった様式や、値の並びがいつもと違う注文書は、手入力に回す分かれ道も用意しておきます。

FAXで受信した注文書については、受信した画像をいったん印刷してスキャンし直すと劣化するため、機器に保存された画像をそのまま使うよう勧められています⁴。
受信画像を加工せずに読み取りへ流す経路を作っておくことが、入口でできる精度の工夫になります。

元の注文書データの保存（原則7年）

読み取ってCSVにした後も、元の注文書は残しておく必要があります。
法人税法上、注文書は保存すべき書類に挙げられており、原則として確定申告書の提出期限の翌日から7年間の保存が求められます⁵。
青色申告で欠損金が生じた事業年度などでは、保存期間がこれより長くなる例外もあります⁵。

データで受け取った注文書には、別の注意点があります。
財務省の資料は、請求書などをデータでやり取りした場合は電子取引データとして保存する必要があり、プリントアウトして保存するだけでは認められないと説明しています⁶。
保存したデータは、日付・金額・取引先の三つで検索できることが求められます⁶。
基準期間の売上高が5,000万円以下の事業者は、ダウンロードの求めに応じられるなどの条件を満たせば、この検索要件が不要になります⁶。

紙で受け取った書類をスキャンして保存する制度は、任意とされています⁶。
FAXで受信した画像がどちらの扱いになるかは受信の方法などによって考え方が分かれうるため、ここでは断定せず、国税庁の案内や顧問の税理士に確かめることをお勧めします。
自社が例外の条件に当たるかどうかの判断も、同じように個別に確かめる事柄です。

運用としては、自動読込の流れの最初で元データを保存先に置き、日付・取引先・金額で探せるファイル名や台帳を付けておくと、読み取り結果に疑問が出たときの照合と、保存の要件への備えを同じ仕組みでまかなえます。
読み取ったCSVや基幹システムの登録データは、元の注文書の代わりにはなりません。

▼ 図の内容を文字で読む

1. FAX・PDFで注文書を受信
2. 元データを保存
   • 日付・取引先・金額で探せるようにする
   • FAX画像は印刷して再スキャンしない
3. 自動読込
4. 確認・修正
   • 品番・数量・納期・届け先を元の画像と照合
   • 読めない様式やいつもと違う注文書は手入力へ
5. CSV出力またはデータ連携
6. 基幹システムへ一括取り込み

導入前の試行では何を見て判断するか

自社の注文書で試す

ここまでの準備量や流れは、自社の注文書を実際に読ませてみるまで、確かなことが言えません。
PFUは、AI-OCRの精度は学習データに依存するため、自社の帳票で無料トライアルを試すことを勧めています⁴。
同社は自社の試験で従来型のOCRより読み取りの精度が高かったとしていますが、これは同社のFAX注文書向け製品と、同社の条件での結果です⁴。
他の製品や自社の注文書にそのまま当てはまる数字として受け取ることはできません。

試行に使う注文書は、前の節で候補にした件数の多い固定様式を中心にしつつ、手書きの書き込みが入ったものや、画質の悪いFAXも混ぜておきます。
きれいな見本だけで試すと、本番で届く注文書との差が結果に表れません。
無償試行の範囲や期間は製品ごとに異なるため、どの様式をどれだけ試せるかは、申し込みの段階で確かめておきます。

見る指標と記録の仕方

試行の結果は、全体の正解率ひとつで判断しないほうが、導入範囲を決めやすくなります。
次の4点を、様式ごとに記録する方法を提案します。

• 読取率（項目別）：品番・数量・納期など、項目ごとに正しく読めた割合
• 修正件数：担当者が直した件数と、直した項目
• 1件あたりの処理時間：読み取りから基幹への取り込みまで、確認と修正を含めた時間
• 例外様式の割合：読めずに手入力へ回した注文書の割合

項目別に見るのは、全体の読取率が高くても、数量や納期のように間違えると困る項目に誤りが集中していれば、確認の手間は減らないからです。
処理時間には、確認と修正の時間を必ず含めます。
読み取り自体が速くても、確認に時間がかかれば手入力との差は小さくなります。
例外様式の割合は、自動読込に乗せる範囲を決める手掛かりになります。

修正が多かった様式は、原因を画質・様式の揺れ・手書きに分けると、次に打つ手が見えてきます。
画質が原因なら見本の追加や受信画像の扱いの見直し、様式の揺れなら定義やモデルの分け方の見直し、手書きなら当面の手入力という具合です。
そのうえでもう一度読ませ、同じ指標で比べます。
この繰り返しで、修正が十分に少なくなった様式から本番に移し、残りは手入力のまま様子を見る、という段階的な判断ができます。

どの値を超えれば導入と決まる基準があるわけではありませんが、記録を様式ごとに残しておけば、どの取引先の注文書から自動読込に任せるかを、感覚ではなく結果で説明できるようになります。
社内で導入範囲を相談するときにも、その記録がそのまま判断の材料になります。

方式と準備の単位が分かっても、自社の注文書を様式ごとに並べ直し、件数や変更の頻度と突き合わせて試行の対象を絞る作業は、受注の実務を知る相手と一緒に進めたほうが早く形になります。

相談では、取引先ごとの注文件数と様式の揺れ、基幹への取り込み方法を並べ、どの様式から試行を始めるかを確かめられます。無料相談で要件を整理する

要点の整理

軸	基準
学習の要否	取引先の数ではなく、読み取りの方式で決まる
準備の単位	帳票定義型は様式の数、学習型は同じ様式の見本、事前学習不要型は補正に使う確認済みの正解
枚数の目安	公式資料で確認できたのはMicrosoftのカスタム抽出モデルの開始条件「5つ」のみで、実用精度の目安ではない
着手の順	注文件数が多く、様式が固定された注文書から
契約前の確認	様式の追加を誰が行えるか、準備物、変更の検知、費用、期間
読取後の流れ	確認する項目を決め、基幹の取り込み口を用意し、元データは別に保存する
試行の記録	項目別の読取率・修正件数・処理時間・例外様式の割合を様式ごとに残す

試行の結果をどう読み、どこまでを自動読込に任せ、どこを手入力や受注の仕組み側で扱うかは、受注業務の流れ全体を見ないと判断しにくいところです。 相談では、試行で記録した様式ごとの結果をもとに、導入範囲と読取後の確認・取り込みの組み方を確かめられます。

よくある質問

紙やFAXの注文書も、PDFで届く注文書と同じ保存義務の対象になりますか。

注文書は法人税法上の保存書類に挙げられており、受け取り方にかかわらず、原則として確定申告書の提出期限の翌日から7年間の保存が求められます⁵。
違いが出るのは保存の形です。
データでやり取りした書類は電子取引データとして保存する必要があり、プリントアウトだけの保存は認められません⁶。
紙で受け取った書類のスキャン保存は任意とされています⁶。
FAX受信画像がどちらに当たるかは受信の方法などで考え方が分かれうるため、国税庁の案内や顧問の税理士に確かめてください。

自動読込で読み取った後も、元の注文書を残す必要がありますか。

残す必要があります。
読み取ったCSVや基幹システムの登録データは、元の注文書の代わりにはなりません。
保存の要件を満たすためだけでなく、読み取り結果に疑問が出たときに元の画像と照合できるよう、読み取りの前に元データを保存し、日付・取引先・金額で探せるようにしておくと運用が楽になります。

取引先ごとに様式が違っても、全取引先の分を最初から設定する必要がありますか。

その必要はありません。
注文件数が多く、様式の変わらない注文書から試し、読み取り結果の良い様式から順に本番へ移す進め方ができます。
修正が多い様式や件数の少ない様式は、当面これまでどおり手入力に残しても、自動読込に乗せた分の転記は減ります。

試行で精度が足りなかった様式は、どう扱えばよいですか。

まず、原因が画質・様式の揺れ・手書きのどれにあるかを分けます。
画質が原因なら見本の追加や受信画像の扱いの見直し、様式の揺れなら定義やモデルの分け方の見直し、事前学習不要型であれば確認済みの結果を参照させる補正²が候補になります。
手を入れても修正が多い様式は、無理に自動読込へ乗せず、手入力に残す判断も選択肢です。

FAXで受信した注文書は、印刷してスキャンし直してもよいですか。

読み取りの精度の面からは勧められません。
PFUは、FAX画像を印刷してスキャンし直すと劣化するため、機器に保存された受信画像をそのまま使うよう勧めています⁴。
受信画像を加工せずに読み取りへ流す経路を用意しておくと、画質による読み違いを増やさずに済みます。

1. 1　出典：Microsoft「カスタム ドキュメント モデル（Document Intelligence）」（2026年確認）
2. 2　出典：Impress Cloud Watch「DX Suite『項目抽出』Few-shot学習の追加」（2024年）
3. 3　出典：Impress IT Leaders「日研フードのAI-OCR導入事例」（2022年）
4. 4　出典：PFU「FAX注文書はOCRできる？精度を向上させる3つのポイント」（2026年確認）
5. 5　出典：国税庁「タックスアンサー No.5930 帳簿書類等の保存期間」（2026年確認）
6. 6　出典：財務省「広報誌『ファイナンス』令和6年8月号 電子帳簿等保存制度の特集」（2024年）