注文書の自動読込は取引先別の学習が要る?様式が違う注文書の読み方と選び方

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

B2B EC-COLUMN

様式がばらばらの注文書は、取引先別の登録なしで読めるのか

取引先ごとに様式の違う注文書を見比べながら、品番や数量を受注画面へ打ち直していると、注文書自動読込に取引先別の学習がどこまで要るのかが気になります。
取引先ごとに読取位置を登録する方式もあれば、登録せずに項目を抽出する方式もあり、取引先別の登録が要るかどうかは方式で決まります。
ただし、どちらを選んでも、読み間違いの確認と、自社の品番・得意先コードへの照合は残ります。
様式がどこまで固定されているか、手書きや画質にばらつきがあるかを見て、数社で試す範囲を決めるのが現実的な始め方です。

取引先ごとに読取位置を登録する方式

一つ目は、取引先ごとに「この様式なら、どこに何が書いてあるか」をあらかじめ教えておく方式です。
注文書の自動読込には主にAI-OCRが使われます。
AI-OCRは、画像の文字を読み取ってデータにするOCRに、AIによる判別を組み合わせたものです。
発注書AI-OCR（invox）の紹介では、取引先ごとにサンプル画像をアップロードし、基本情報と明細の読取箇所をクリックして設定する流れが説明されています²。
この準備は、機械に大量の注文書を学ばせる作業とは違います。
受注担当者が見本の注文書を一枚用意し、画面上で項目の位置を指し示す作業に近いものです。

同じ取引先から毎回同じ様式で届くなら、一度教えた位置が次の注文書にもそのまま当てはまります。
その代わり、準備は取引先の数だけ必要です。
取引先が少なく様式が安定していれば負担は限られます。
取引先が多いほど、最初の登録作業はまとまった量になります。

登録せず項目を抽出する方式

二つ目は、読取位置を登録せず、書かれている内容から項目を取り出す方式です。
PFUは、2026年に販売開始を発表したPaperStream AIについて説明しています。
生成AIが帳票の記載内容を解析して項目を抽出するので、事前にOCR項目を定義する必要がなく、帳票ごとの設定作業も要らない、という内容です¹。
どの位置に書かれているかではなく、何が書かれているかから注文番号や品名を判別する考え方です。

提供元の説明に沿えば、取引先別の登録を前提にしないので、様式がばらばらでも最初の一枚から読ませられます。
ただし、これはクラウド型の製品であるPaperStream AIの仕様です。
利用にはPaperStream Capture Proなどのライセンスが必要とされています¹。
「登録なしで読める」ことはAI-OCR全般には当てはまらず、製品ごとに前提が違います。

どちらの方式でも残る作業

取引先別の学習が要るかという疑問は、二つの話に分けると整理しやすくなります。
一つは、読み始める前の登録です。
これは方式によって、要る場合と要らない場合があります。
もう一つは、使いながら精度を上げる学習です。
こちらは登録が要らない方式にも、担当者が直した結果を取り込む仕組みとして用意されています¹。
「登録不要」と「学習不要」は同じ意味ではありません。

そのうえで、方式に関係なく受注側に残る作業が二つあります。
一つは読取結果の確認と修正です。
PFUも抽出結果を確認・修正できると説明しており、読み取った値をそのまま受注へ流す前提にはしていません¹。
もう一つは、読み取った品名や取引先名を自社の品番・得意先コードに結び付ける照合です。
読取の後に商品と得意先を照合する工程を組み込んでいる製品もあります³。
注文書の文字を正しく読めても、それが自社のどの商品か、どの得意先かまでは決まらないからです。

方式の違いが大きく出るのは、導入するときと取引先が増えたときの準備です。
日々の確認と照合は、どちらを選んでも設計が要ります。

▼ 図の内容を文字で読む

1. 取引先ごとに読取位置を登録する方式
2. 取引先ごとにサンプル画像を登録し、基本情報と明細の読取箇所を設定する
3. 登録せず項目を抽出する方式
4. 記載内容を解析して項目を抽出し、事前のOCR項目定義を求めない
5. どちらでも残る作業

自社の注文書の状況で、読み方の選び方はどう変わるか

様式がほぼ固定の場合

二つの方式を、受注側が実際に行う作業ごとに並べると次の表になります。
精度の欄には、提供元が数値を示している条件をそのまま書いています。

表のうち、判断が分かれるのは二点です。
準備作業がいつ・どれだけ発生するかと、精度をどこまで比べられるかです。
取引先ごとに様式がほぼ固定なら、登録型の準備は取引先ごとに一度で済む可能性があります。
たとえば、注文の大半が限られた取引先から毎回同じ様式で届くとします。
その場合は、その取引先分の登録を終えれば、日々の作業は確認と照合が中心になります。
登録の手間を前もって見積もれるので、登録が必要なこと自体は大きな欠点になりにくいと考えられます。

一方で、登録型の読取位置は、決まった様式を前提にしています。
固定だと思っていた取引先でも、担当者が代わったり、相手先のシステムが入れ替わったりして、注文書の形が変わることはありえます。
そのとき設定をどこまでやり直すのかは、紹介ページに手順が示されていません。
試す前に提供元へ尋ねておきたい点です。

様式が多い・頻繁に変わる場合

反対に、取引先ごとに様式がばらばらで取引先の数も多いと、登録型の準備は取引先の数に比例して積み上がります。
スポットの取引先や、注文のたびに書き方が少しずつ変わる取引先が混ざっていることもあります。
その場合、登録した設定はあまり使われないまま、登録作業だけが増えていきます。
このような状況では、事前の項目定義を求めない方式を試す価値が高くなります。

ただし、ここで言えるのは、準備作業の負担が方式によって違うということまでです。
登録しない方式のほうが読み間違いが少ない、とまでは言えません。
精度の数値は製品ごとに測った条件が違い、同じ物差しで並べられないからです。
様式が多い会社ほど、準備の軽さだけで決めるのは避けたいところです。
確認・修正にかかる手間まで含めて試し、比べる必要があります。

手書き・画質にばらつきがある場合

精度の数値を読むときは、どんな条件で検証したかに注意が要ります。
PFUが示す認識精度99.99%は、PFU基準帳票（活字）を300dpi・フルカラーでスキャンした画像を使った自社検証の値です。
それ以外の条件での精度は示されていません¹。
dpiは画像の細かさを表す単位で、数字が大きいほど細かく読み取った画像になります。
FAXで届いた白黒の注文書や、手書きで数量を書き足した注文書は、この検証条件から外れます。

invoxの発注書AI-OCRは、手書き用を含む複数のOCRエンジンを備えていると紹介されています²。
複数の納期や届け先が入った明細を行に分ける機能や、単位を換算する機能もあるとされています²。
ただし精度の記載はなく、手書きの注文書がどこまで読めるかは示されていません。
機能があることと、自社の注文書でその機能が期待どおりに働くことは、別の問題です。

明細の複雑さも、同じ考え方で見ていきます。
たとえば、一行の明細に「半分は今週、残りは来週納品」と書かれた注文書があるとします。
受注システムには、納期ごとに分けた二行として入れる必要があります。
こうした書き方をする取引先がいるなら、行分割のような機能があるかどうかに加えて、その取引先の実物を読ませた結果が判断の材料になります。

手書きや低画質の注文書が多くても、自動読込をあきらめる必要はありません。
読める部分と確認が必要な部分を分け、確認の手間がどこに集中するかを把握しておけば、その取引先だけ従来どおり手入力で残す、といった切り分けもできます。

▼ 図の内容を文字で読む

1. 様式がほぼ固定の取引先が中心：登録型でも準備は取引先ごとに一度で済む可能性。様式変更時の扱いは提供元に確認
2. 様式が多い・頻繁に変わる：事前の項目定義を求めない方式を試す価値が高い。準備の軽さと確認の手間を合わせて見る
3. 手書き・FAX・低画質が混ざる：提供元の精度は条件付き。実物の注文書を読ませ、確認が集中する箇所を見る

読み間違い・様式変更・新規取引先が出たとき、誰がどう直すのか

確認が必要な項目の見つけ方

自動読込を入れても、読取結果を確認せずに受注へ流す運用は現実的ではありません。
ただ、すべての項目を一つずつ目で確かめていると、転記の手間が確認の手間に置き換わるだけになります。
減らしたいのは、注文書を見ながら受注画面に打ち込む作業と、打ち込んだ内容を読み直す作業の両方です。

そこで注目したいのが、確認が必要な箇所を絞り込む仕組みです。
kozokaAIの受注AIエージェントは、数量・納期・単価・過去注文との差異など、確認が必要な項目をAIが提示すると説明しています³。
たとえば、いつも同じ数量を注文してくる取引先から、桁が一つ多い数量が届いたとします。
読取は正しくても、取引先が書き間違えた可能性があります。
過去の注文と比べて目立つ差がある行だけを見て、取引先へ問い合わせるかを判断すればよく、全行を同じ重さで確かめる必要はなくなります。
なお、これは提供元のプレスリリースでの説明で、第三者が効果を検証したものではありません。

運用の分担としては、次のような形が考えやすいでしょう。
受注担当者は、提示された項目を確認・修正します。
業務の改善担当者は、どの取引先でどの項目の修正が多いかを定期的に見ます。
前者は日々の注文を正しく通すための作業で、後者は設定やマスタの不足を見つけるための作業です。
同じ確認作業でも、目的が違います。

修正結果の学習と反映

担当者が直した内容が次回に生かされるかどうかで、運用を続けたときの手間は変わってきます。
PFUは、運用中の修正結果を学習し、表記ゆれや例外的な記載への対応を改善すると説明しています。
その学習は自社の運用データに基づくとしています¹。
また、複数の部門で共用すると、修正内容が帳票の種類ごとに蓄積されるとしています¹。
kozokaAIも、担当者の修正内容や確認履歴を蓄積して精度を高めるとしています³。
invoxの紹介には、商品検索キーを事前に学習でき、使うほど判別精度が上がると書かれています²。

受注側で考えておきたいのは、修正をどこで行うかです。
読取結果の画面では直さず、受注システムに取り込んだ後で直していると、読取の仕組みからはその修正が見えません。
修正結果を学習する仕組みは、修正が読取の画面で行われることを前提にしていると考えられます。
確認と修正をする場所を一か所に決めておくことが大切です。

一方で、学習があるから最初の精度が低くても自然に良くなる、と期待しすぎるのも避けたいところです。
学習の効果は提供元の説明で、どれだけ修正すればどこまで改善するかは示されていません。
試行の期間中は、同じ取引先で同じ種類の間違いが繰り返し出ていないかを見ていきます。
そうすれば、自社の注文書で学習が効いているかを確かめられます。

新規取引先を追加するときの作業

新しい取引先から初めて注文書が届いたときの作業は、方式によって入口が違います。
登録型では、その取引先のサンプル画像をアップロードし、基本情報と明細の読取箇所を設定してから読ませます²。
登録しない方式では、事前の設定は求められません。
ただし、初めての様式には過去の修正の蓄積がないため、最初の数回は確認を丁寧に行う必要があります。

どちらの方式でも共通するのが、その取引先の品名や得意先の情報を自社のマスタに結び付ける作業です。
マスタとは、商品や取引先の正式なコードと名称をまとめた一覧のことです。
新しい取引先は、自社の品番ではなく、自分たちの呼び方で商品を書いてくることがあります。
最初の注文のときに結び付けておけば、その後の照合が楽になります。

既存の取引先が様式を変えたとき、どう再設定するかは、どちらの方式についても公表資料に手順が示されていません。
導入前に提供元へ確認する項目に入れておくと安心です。

▼ 図の内容を文字で読む

1. 注文書を読み取る
2. 確認が必要な項目を提示
3. 担当者が読取画面で確認・修正
4. 修正結果を蓄積・学習
5. 次回の読取に反映

▼ 図の内容を文字で読む

1. 初めての注文書を受け取る
2. 方式に応じて準備する（登録型はサンプル登録と読取箇所の設定）
3. 読取結果を丁寧に確認・修正する
4. 品名・得意先を自社のマスタに結び付ける

読み取ったデータを受注入力・基幹システムに渡すまでに必要な整理

取引先独自の品名・コードの照合

読取が終わった時点で手元にあるのは、注文書に書かれていた文字をデータにしたものです。
受注システムに入れるには、そこからもう一段、自社の言葉に置き換える必要があります。
たとえば取引先が、自社の品番ではなく、相手先の社内コードや略称で品名を書いてくる場合があります。
文字は正確に読めていても、そのままでは受注システムが商品を特定できません。

この照合を、自動読込の仕組みの中で行う製品もあります。
kozokaAIは、読み取った内容を商品マスタ・得意先マスタと照合して商品を特定すると説明しています³。
invoxの紹介では、基幹システムと連携してマスタを確認し、発注マスタから候補を提示できると挙げられています。
商品検索キーを事前に学習できることも挙げられています²。

照合の仕組みがあっても、結び付けるための情報が社内で整っていなければ、候補はうまく出てきません。
担当者が「この取引先のこの略称はこの品番」と頭の中で覚えて処理しているなら、まずその対応を一覧にしておくことが、どの製品を選ぶ場合でも準備になります。
Excelで対応表を管理しているなら、それが照合の元になる可能性があります。
読み込ませられるかどうかは、製品ごとに確かめることになります。

得意先についても同じことが言えます。
同じ会社でも支店ごとに別の得意先コードを持っていたり、注文ごとに届け先が違ったりする場合があります。
そうした場合、読み取った会社名だけでは、どのコードに当てればよいかが決まりません。

CSV・APIなど受け口の確認

照合を終えたデータを受注システムや基幹システムへ渡す方法も、製品によって違います。
kozokaAIは、基幹への登録をCSVやAPIでの連携を前提にしています³。
invoxは、読取データを基幹へ連携できると紹介されていますが、出力の形式は書かれていません²。
PFUのリリースも、項目ごとに整理された構造化データに変換すると説明していますが、出力ファイルの形式は明記していません¹。

CSVは、項目をカンマで区切った表形式のファイルです。
読取側から出力したファイルを受注システムに取り込む、という手順を挟む形になります。
APIは、システム同士が直接データをやり取りする仕組みです。
取り込みの手作業は減りますが、受注システムの側に受け口が用意されている必要があります。

自社の受注システムがCSVを取り込めるのか、取り込めるなら列の並びや文字コードに決まりがあるのかを、先に把握しておきます。
そうしておけば、試行で出てきたデータを実際に受注システムへ流せるかまで確かめられます。
読取がうまくいっても、取り込みの段階で列を手で並べ替えていれば、転記の手間が別の形で残ってしまいます。

▼ 図の内容を文字で読む

1. 注文書の読取
2. 読取結果の確認・修正
3. 商品マスタ・得意先マスタと照合
4. CSVやAPIで受注システム・基幹システムへ渡す

最初に何社分から試し、何で続けるかを決める

試す取引先の選び方

試行の範囲を決めるとき、読みやすい注文書だけで試すことは避けたいところです。
きれいに印刷された活字の注文書で良い結果が出ても、日々の手間を生んでいるのがFAXや手書きの注文書なら、本当に知りたいことは分かりません。

そこで、取引先を注文書の状況によって三つの群に分け、それぞれから数社ずつ選ぶ方法が考えられます。

• 様式がほぼ固定の取引先
• 様式が多い、またはよく変わる取引先
• 手書きやFAXで画質にばらつきがある取引先

一行に複数の納期や届け先が入るなど、明細が複雑な取引先がいる場合は、どの群からでも一社は含めておきます。
そうすると、行分割や照合でつまずく箇所が見えやすくなります。

何社選ぶかに、決まった目安はありません。
注文の件数が多い取引先と、担当者が手間がかかると感じている取引先を優先すると、試行の結果をそのまま判断に使いやすくなります。
同じ取引先の注文書は、一枚だけでなく何回分かを読ませます。
そうすると、修正の学習による変化も見えてきます。

評価の見方

続けるかどうかを判断する物差しとしては、修正が必要だった項目の割合と、一件あたりの処理時間の二つが分かりやすい指標です。
処理時間には、読取を待つ時間だけでなく、確認・修正、マスタとの照合、受注システムへの取り込みまでを含めます。
読取が速くても照合に時間がかかっていれば、その分は効果として数えられないからです。

記録は取引先の群ごとに分けて取ります。
全体を平均してしまうと、固定様式の取引先では手間が減ったのに手書きの取引先ではほとんど変わらない、といった差が見えなくなります。
群ごとに見ておけば、効果が出た群から本運用に移し、効果の薄い群は手入力のまま残す、といった段階的な判断ができます。

比べる相手は、いまの手作業です。
試行の前に、同じ取引先の注文書を従来どおり入力したときの時間と、入力後に見つかった間違いを記録しておきます。
そうすれば、試行の結果を同じ物差しで並べられます。
どの水準なら続けるかは、外から一律に決められるものではありません。
担当者の人数や注文の件数を踏まえて、社内で線を引くことになります。

保存期間の補足

試行を始めると、受け取った注文書の画像やPDFと、読み取って作ったデータの両方が手元に残ります。
注文書は、法人税法上保存が必要な取引関係書類の例に含まれています。
その事業年度の確定申告書の提出期限の翌日から、原則7年間保存します⁴。
青色申告で欠損金が生じた事業年度などは、10年です⁴。

自動読込の運用では、元の注文書と読み取ったデータを後から突き合わせられるようにしておくと、読み間違いの確認にも保存にも役立ちます。
受注データから元の画像やPDFにたどれる状態にしておけば、取引先から問い合わせがあったときも、注文書に何が書かれていたかをすぐに確かめられます。
紙で受けた注文書と、メールやデータで受けた注文書とでは、保存方法の扱いが変わることがあります。
どう保存するかは、経理の担当者や顧問税理士と決めておくと迷いません。

▼ 図の内容を文字で読む

1. 様式がほぼ固定の取引先
2. 準備が一度で済み、確認と照合が中心になるかを見る
3. 様式が多い・よく変わる取引先
4. 事前の設定を減らせるか、確認・修正の手間がどれだけ残るかを見る
5. 手書き・FAXで画質にばらつく取引先

自社の注文書が様式の固定度や画質でどう分かれ、どちらの方式から試すのがよいかは、取引先の一覧と実物の注文書を並べてみないと判断しにくいものです。

手元の注文書と現在の受注入力の流れをもとに、試行に向く取引先の分け方と、読み取ったデータを受注システムへ渡すときに確かめておく点を整理できます。無料相談で要件を整理する

要点の整理

軸	基準
取引先別の登録	方式によって要否が違う。登録が要らない製品でも確認・修正は残る
様式の固定度	固定様式が中心なら登録型も候補、様式が多いなら事前定義を求めない方式を試す
精度の数値	検証条件を確認し、自社の注文書で試して比べる
修正の場所	読取の画面で直し、学習に生かす
基幹への受け渡し	自社の受注システムがCSVかAPIかを先に把握する
試行の評価	群ごとに修正が必要だった項目の割合と一件あたりの処理時間を見る
保存	注文書は原則7年間、欠損金が生じた事業年度などは10年

試行の結果をどの水準で本運用に移すか、照合に使うマスタをどこまで整えるかは、担当者の人数や注文の件数によって答えが変わります。 試行で記録した修正項目の割合や処理時間をもとに、本運用に移す取引先と手入力に残す取引先の線引きを一緒に確認できます。

よくある質問

注文書がFAX・メール本文・Excelで混在していても自動読込はできますか。

混在していても読み込める製品はありますが、受け取り方ごとに確かめる必要があります。
kozokaAIは、FAX・メール・PDFの注文書を読み取ると説明しています³。
これは提供元の説明で、メール本文やExcelのファイルをそのまま読ませられるかは、製品ごとに確認が必要です。
試行では、実際に届いている形式をそれぞれ用意します。
どの形式がそのまま読めて、どの形式は一度PDFや画像にする手間が要るかを見ておくと、運用の流れを決めやすくなります。

新しい取引先が増えたとき、運用担当者は何をしますか。

取引先ごとに読取位置を登録する方式なら、その取引先のサンプル画像を登録し、基本情報と明細の読取箇所を設定します²。
登録しない方式なら事前の設定は求められませんが、最初の数回は読取結果を丁寧に確認します。
どちらの方式でも、その取引先の品名や得意先の情報を、自社の品番・得意先コードに結び付けておく作業が要ります。

手書きの注文書や画質の悪いFAXは、どこまで読めますか。

確認できた資料からは、どこまで読めるかを言い切ることはできません。
PFUの認識精度99.99%は、PFU基準帳票（活字）を300dpi・フルカラーでスキャンした画像での自社検証値で、手書きやFAXには当てはまりません¹。
invoxは手書き用を含む複数のOCRエンジンを備えると紹介されていますが、精度は示されていません²。
実際の手書きやFAXの注文書を試行で読ませ、確認が必要になった項目の割合を見て判断します。

取引先独自の品名や略称は、どう自社の品番にそろえますか。

読取の後に、自社の商品マスタと照合する工程でそろえます。
読取後に商品マスタ・得意先マスタと照合する製品や³、発注マスタから候補を提示し、商品検索キーを事前に学習できる製品があります²。
どの製品を使う場合でも、担当者が覚えている「略称と品番の対応」を一覧にしておくことが照合の準備になります。

自動読込した注文書データやPDFは、何年保存しますか。

注文書は法人税法上の保存対象の書類に含まれます。
その事業年度の確定申告書の提出期限の翌日から、原則7年間保存します⁴。
青色申告で欠損金が生じた事業年度などは10年です⁴。
保存方法は受け取り方によって扱いが変わることがあるため、経理の担当者や顧問税理士と決めておきます。

1. 1　出典：株式会社PFU「新AI-OCR「PaperStream AI」販売開始のプレスリリース」（2026年）
2. 2　出典：ASPIC「発注書AI-OCR（invox）の機能・特徴の紹介」（確認時点）
3. 3　出典：株式会社kozokaAI「kozokaAI 受注AIエージェントの紹介記事（ASCII.jp掲載）」（確認時点）
4. 4　出典：国税庁「タックスアンサー No.5930 帳簿書類等の保存期間」（確認時点）