AI-OCRと基幹システム連携｜CSV・APIの選び方

「読み取れる」と「基幹に入る」は別問題

OCR結果は帳票に書かれた値です。基幹システムが必要とするのは、登録規則に合う受注データです。帳票の『A店』を得意先コードへ変え、『上白1K』を商品コードと荷姿へ変え、納品日を所定の日付形式にし、必須の担当者コードや倉庫コードを補います。この変換をどこで行うかが連携設計です。

連携の完了点も決めます。ファイルを出力した時点、基幹へ送信した時点、基幹が受付した時点、受注番号が発番された時点では状態が違います。出力済みを登録済みと表示すると、取込エラーの注文が処理済みに見えます。OCR側の注文IDと基幹側の受注番号、受付結果を結び付けます。

注文書OCRを連携まで含めて選ぶ7つの基準を見る

連携方式3種の使い分け

方式は新しさではなく、基幹側が安全に受け取れる方法と運用体制で選びます。販売管理パッケージに標準のCSV取込があるなら、それを使う方が改修範囲を限定できます。自社開発でAPIを追加できても、夜間や締め時間の障害対応者がいなければ自動化の範囲を調整します。

CSV手動取込は人が介在するため遅いと決めつけません。確認済み注文を一括で取り込み、基幹のエラー一覧をその場で確認できれば、個別入力より操作を減らせます。自動化の初期段階では、列変換やマスタ不一致の型を集める観測点にもなります。手動の終了条件を決め、安定したファイルだけ自動取込へ移します。

APIでは、一件ごとに受付結果を返せる一方、通信成功と受注登録成功を分ける必要があります。HTTP応答が成功でも業務エラーを含む場合があり、タイムアウトでも基幹側では登録済みの可能性があります。同じ連携IDを再送したときに二重登録せず同じ結果を返す設計と、登録済みを照会する方法を用意します。

方式を切り替える基準も開始前に置きます。CSV手動取込で、ファイル加工がなく、取込エラーの原因が分類でき、担当者の取込操作だけが継続的な負担になった段階で自動取込を検討します。APIへ進むのは、即時に受付結果を返す必要がある、複数拠点から同じ状態を参照する、ファイル単位では再送管理が難しい、といった要件が確認できたときです。技術方式を先に決めず、残っている操作を一つずつ置き換えます。

CSVで詰まる実務ポイント

列順と必須列

基幹の取込定義が列番号で決まる場合、空の列も省略できません。OCRにない担当者コード、倉庫コード、伝票区分を固定値や得意先マスタから補うことがあります。ヘッダーの有無、明細一行ごとか注文一件ごとか、複数明細で受注番号をどうまとめるかも仕様書にします。

文字コードと区切り文字

UTF-8、UTF-8のBOM付き、Shift_JISなど、基幹が受け付ける文字コードを確認します。カンマ区切りでも、商品名や備考にカンマ、改行、引用符が含まれる場合は囲み文字とエスケープ規則が必要です。Excelで開いて保存すると文字コードや先頭ゼロが変わることがあるため、手直し手順もテストします。

商品コードの桁と値の型

商品コードや得意先コードを数値として扱うと、先頭ゼロが落ちます。固定桁の文字列として出力し、桁不足をゼロ埋めするのか、マスタ不一致として止めるのかを決めます。数量の小数、負数、ケースとバラ、日付の年月日、空欄とゼロの違いも同じです。見た目が同じでも基幹の型と一致しなければ登録できません。

マスタ照合をOCR側でやるか基幹側でやるか

正式な商品コード、販売可否、荷姿、価格、在庫などの正本は基幹側に置きます。OCR側には、取引先が使う商品名、略称、旧名、帳票上の位置と正式コードの対応を持たせると、確認画面で候補を提示できます。両側に同じ商品マスタを手入力すると更新時点がずれるため、正本と同期方法を決めます。

OCR側で照合する利点は、元帳票を見ながら候補を確定し、正式コードを連携できることです。基幹側で照合する利点は、販売停止や最新の荷姿など正本の規則を一か所で適用できることです。実務では、OCR側で取引先別名から候補を絞り、基幹側または基幹マスタAPIで有効性を確認する二段階が使えます。

同期では、全件置換か差分か、更新頻度、削除・終売の扱い、同期失敗時の前回データ利用を決めます。同期時刻より新しい商品が注文された場合は、自動で類似商品へ確定せず、マスタ外として確認へ回します。修正した別名は正式マスタへ混ぜず、取引先別対応として承認後に保存します。

マスタの版も記録します。注文を処理した時点の版、OCR側へ同期した時刻、基幹側で商品を変更した時刻が分かれば、同じ商品で候補が変わった原因を追えます。同期エラーが起きたときに前回版で処理を続けるなら、新規・変更商品を自動確定しない条件を置きます。復旧後は差分を再評価し、既に人が確定した注文を自動で上書きしません。

既存環境別の現実解

自社開発の基幹システム

既存APIや取込バッチ、注文テーブルの制約を確認し、まずCSV手動で項目対応を固めます。即時性が必要なら、同じ項目定義をAPIへ移します。開発担当がいることと運用保守できることは別です。認証情報の更新、障害通知、再送、仕様変更の担当と連絡時間を決めます。

販売管理パッケージ

標準の受注CSV取込、外部連携オプション、監視フォルダの有無をベンダー資料で確認します。パッケージ更新で取込仕様が変わる場合があるため、独自にデータベースへ直接書き込まず、公開された取込経路を使います。エラー一覧と取消し方法も含め、テスト環境またはバックアップ可能な範囲で検証します。

Excelでの受注管理

Excel運用では、所定の列へ確認済みデータを出力する方法から始められます。ただし、複数担当者の同時編集、コード列の型、数式、行追加、処理済み状態を決めます。元帳票と行の対応を注文IDで残し、別ファイルへのコピーを繰り返さないよう、受注一覧と出荷用出力の役割を分けます。

環境に関係なく、最初は件数の多い帳票と一つの登録先に限定します。正常系が通った後、手書き、複数ページ、訂正、取消し、マスタ外、通信停止を追加します。出力ファイルを作れたことではなく、基幹の受付結果と元帳票を追えることを合格条件にします。

連携を止めないエラー運用

エラーは、OCR、変換、マスタ、ファイル配置・通信、基幹業務チェックに分けます。一つの『連携失敗』通知だけでは担当が決まりません。注文ID、発生段階、理由、発生時刻、最終成功時刻、再処理可否、担当を確認キューに表示します。正常な注文まで同じファイルで止めるか、行単位で分けるかも基幹仕様に合わせます。

• OCR値と確定値、出力値、基幹受付値を注文IDで追えるようにする
• CSVは未処理、処理中、処理済み、エラーの保存場所を分け、同じファイルを二重取得しない
• APIは連携IDを冪等キーにし、タイムアウト後に受付状態を照会してから再送する
• マスタ不一致や必須項目不足は自動再送せず、担当者が確定してから送る
• 障害中のFAX注文をどこに保持し、復旧後にどの順で再開するかを決める
• 日次でOCR件数、送信件数、基幹受付件数、保留件数の差を照合する

自動再送は通信の一時障害に限定します。商品コード不明や納品日不正を同じ値のまま繰り返しても直りません。業務エラーは担当者へ、通信エラーは回数と間隔を制限した再送へ分けます。締め時刻が近い場合の手動登録への切替も決め、後で自動連携が復旧したときに二重登録しない印を残します。

連携方式の解決策はAPI化そのものではなく、確認済みデータを基幹の受付結果まで追跡し、失敗した注文だけを安全に復旧できることです。サンプル注文書の抽出項目を見ながら、得意先、商品、数量、納品日をどの列やAPI項目へ渡すかを整理してください。

本番前には、通常注文のほか、空欄、最大桁、先頭ゼロ、記号を含む備考、複数明細、取消し、同じ連携IDの再送を通します。CSVなら生成ファイルと基幹の取込ログ、APIなら要求、応答、受付状態を保管し、元帳票からたどります。テスト後に作った項目対応表とエラー一覧を運用手順へ引き継ぎ、仕様変更時の回帰テストにも同じデータを使います。

切替日には旧手順をすぐ消さず、利用条件を限定した復旧手順として残します。ただし、担当者が任意に旧入力へ戻ると二重登録が起きるため、切替判断者、開始時刻、対象注文、復旧後の照合を記録します。翌営業日に連携件数と基幹受付件数を確認し、手動登録分を自動再送の対象から除外します。

自社の注文書の型で読み取り結果を見る（サンプル4種）

FAX受注からCSVへつなぐ全体の進め方を見る

AI-OCRと基幹連携に関するよくある質問

CSV連携とAPI連携はどちらを選ぶべきですか？

月間件数だけでなく、締めまでの時間、基幹側の取込機能、社内の保守担当、エラー時の復旧方法で決めます。CSV手動取込で業務が回るなら小さく始められます。到着から登録までを無人化する必要があり、双方にAPIがある場合はAPI連携を検討します。

商品マスタはOCR側と基幹側のどちらに置きますか？

正式な商品コード、販売可否、荷姿などの正本は基幹側に置きます。OCR側には取引先別の商品名や略称と正式コードの対応を持たせ、基幹マスタの更新を反映します。同じ項目を両側で個別更新しないよう、正本と同期方法を決めます。

連携エラーが起きた注文を再送すると二重登録になりませんか？

注文ごとの連携ID、送信時刻、基幹側の受付結果を保存し、同じIDの再送を基幹側で重複判定できるようにします。再送前に登録済みかを照会できない場合は、自動再送せず確認キューへ移し、担当者が元帳票と受付結果を確認します。

AI受注さんの提供内容を確認する

CSVかAPIかを件数・時刻・受け口で決める

方式を決める前に、月間件数だけでなく一回にまとめられる件数を数えます。月1,000件でも、午前と午後の二回にまとめて取り込み、締め時間に間に合うならCSVで運用できます。月100件でも、在庫引当や納期回答を受信直後に返すならAPIの意味があります。件数だけでは決まりません。

判断材料は実測します。CSV候補なら、繁忙日の一回分を取り込み、ファイル作成から基幹受付までの分数とエラー行数を測ります。API候補では正常登録だけで終えません。タイムアウト後の照会や同じ連携IDの再送、マスタ不一致の戻り方を試します。どちらも元帳票、OCR確定値、基幹受注番号が一本でたどれれば合格です。

項目対応表は境界値まで書く

連携で詰まるのは列名より値の形です。文字コードはUTF-8かShift_JISか、BOMを付けるか。明細は一注文をヘッダー一行と明細複数行に分けるのか、各行へ注文番号を繰り返すのか。商品コードは固定桁の文字列か、先頭ゼロを許すか。日付はYYYYMMDDか区切り付きか。空欄とゼロを同じにするか。これらをサンプル値付きで項目対応表へ書きます。

再送規則も項目仕様の一部です。CSVならファイル名を変えれば再取込できるのか、正常行まで重複しないかを確かめます。APIでは通信が切れた後、同じ連携IDで受付状態を照会し、未登録のときだけ送ります。商品コードの桁不足や不正な日付は、同じ値の自動再送では直りません。確認キューへ戻します。

基幹改修が必要になる境目と避け方

基幹にCSV取込がない場合は改修の候補です。必要な明細構造を受けられない、外部の注文IDを保存できない、受付結果を返せない場合も基幹側の改修が必要になります。公開APIがあっても、商品コードを一件ずつしか照会できず、受注登録の口がなければ連携には使えません。データベースへ直接書き込む方法は、業務チェックを飛ばし、更新時に壊れやすいため避けます。

改修を抑える第一手は、基幹の標準CSVへOCR側の出力を合わせることです。必須の倉庫コードや伝票区分は、得意先マスタから補います。明細を一括登録できないなら、既存の取込ツールやRPAを受け口にできるかを先に調べます。ただし画面操作へ寄せる場合も、受付結果と注文IDを残せないなら無人化しません。保留一覧を持ち、担当者が失敗した一件だけ戻せる形にします。