OCRで読み取ったデータは、基幹システムに届いて初めて業務改善につながる。ERP・TMS・受注DBとの3つの接続パターン（API直結・中継サーバー・ファイル連携）を軸に、データフォーマット変換からエラーハンドリングまでを元キーエンス画像処理エンジニアが解説。
物流現場にAI-OCRを導入し、ラベルや伝票の文字を高精度に読み取れるようになったとする。しかし、その読み取り結果が最終的にどこへ格納されるかが設計されていなければ、現場の業務フローは変わらない。
多くの物流現場で起きている典型的な「OCR導入後の停滞」は、以下の構造を持っている。
このボトルネックを解消するためには、OCRの読み取り結果を基幹システムへ自動的に流し込む連携基盤が不可欠になる。OCR精度の追求と同等以上に、「データの行き先」の設計が重要なのだ。
本記事では、WMS連携の基本設計をさらに発展させ、ERP・TMS・受注DBという3つの代表的な基幹システムとの接続パターンを網羅的に解説する。
物流OCRと基幹システムの接続方式は、大きく3つに分類できる。現場の既存システム構成・IT部門の体制・セキュリティポリシーに応じて最適な方式を選定する必要がある。
| 接続パターン | 概要 | 適するケース | 導入難易度 |
|---|---|---|---|
| API直結型 | OCRエンジンから基幹システムのREST/SOAP APIへ直接データ送信 | API公開済みのクラウドERP・SaaS型TMS | 低～中 |
| 中継サーバー型 | OCRと基幹システムの間に中継サーバーを設置し、データ変換・バッファリング・リトライを担当 | オンプレミスERP、APIが未整備のレガシーシステム | 中 |
| ファイル連携型 | OCR結果をCSV/XMLファイルとして出力し、基幹システム側の定期バッチで取り込み | 基幹システムの改修が一切できない環境、ファイル取込が唯一のI/Fの場合 | 低 |
実際の現場では、これらを単独で使うだけでなく、複数パターンを組み合わせるケースも多い。たとえば、メインのERP連携はAPI直結で処理しつつ、バックアップとしてCSVファイル出力を並行して残すといった設計がそれにあたる。
設計の原則：「既存システム側の改修を最小化する」ことが、連携プロジェクトの成否を分ける。OCR側・中継サーバー側でデータ変換を吸収し、基幹システムが受け入れ可能な形式に合わせるのが基本方針となる。
ERP連携は、OCR読み取り結果を入荷・在庫・仕入の各モジュールへ反映させるフローである。対象となるERPの種類によってAPI仕様やデータモデルが大きく異なるため、接続設計の前提知識を整理しておく。
SAPとの連携では、RFC（Remote Function Call）またはOData APIが主要な接続手段となる。OCRで読み取った伝票番号・品番・数量をSAPの入庫伝票（MIGO）に自動転記するフローが典型例である。
Oracle ERP Cloudの場合は、REST APIまたはSOAP Webサービスを利用する。E-Business Suite（オンプレミス）の場合は、Concurrent Program経由のファイル取込か、カスタムAPIの開発が必要となる場合がある。
中小企業で広く導入されているOBCの奉行シリーズは、奉行クラウドAPI（受入API）に対応している製品と、CSV取込のみに対応している製品が混在している。導入企業のバージョンと契約プランを確認した上で接続方式を決定する。
いずれのERPでも共通して重要なのがマスタ照合の設計である。OCRが読み取った品番・伝票番号がERP側のマスタに存在するかをリアルタイムで照合し、不一致時の処理フローを明確にしておく必要がある。この照合ロジックを中継サーバーに実装することで、ERP側の改修を回避できる。
TMS（Transport Management System）との連携は、OCR読み取り結果を配車計画・追跡情報・運賃計算に活用するフローである。2024年問題を背景にTMSの導入・刷新が進む物流業界において、OCR連携の需要は急速に高まっている。
入荷時に送り状をOCRで読み取り、荷送人・届先・品名・個数・配送指定日をTMSに自動登録するフローは、最も導入効果が大きいユースケースの一つである。
出荷時に追跡番号（トラッキングナンバー）をOCRで読み取り、TMSの出荷ステータスを自動更新すると同時に、顧客向けの追跡情報にも反映する。この双方向連携により、「出荷したのにTMS上ではステータスが変わっていない」という情報の断絶を防ぐ。
OCRで読み取ったケースの重量・サイズ情報をTMSの運賃計算エンジンに自動投入することで、手入力による運賃誤算定を排除できる。液体レンズを使った可変高さケースの読み取りと組み合わせることで、サイズ計測からTMS連携まで一貫して自動化する構成も実現可能である。
EC事業者やD2Cブランドの物流倉庫では、受注データベースとの連携がOCR導入の費用対効果を最大化する。EC受注 → 出荷指示 → OCR検品 → 出荷確定 → 配送ステータス更新という一連のフローを、人手の介在なしに完結させることが目標となる。
| ステップ | 処理内容 | データの流れ |
|---|---|---|
| 1. EC受注 | ECプラットフォームで注文確定 | 受注DB → WMS（出荷指示データ生成） |
| 2. ピッキング・梱包 | WMSの出荷指示に基づきピッキング | WMS → 現場端末（ピッキングリスト配信） |
| 3. OCR検品 | 梱包後の出荷ラベルをOCRで読み取り、受注内容と照合 | OCR読み取り値 → 中継サーバー → 受注DB照合 |
| 4. 出荷確定 | 照合OKなら出荷ステータスを自動更新 | 中継サーバー → 受注DB（ステータス更新）→ TMS |
| 5. 追跡通知 | 追跡番号を顧客に自動送信 | TMS → 通知サービス → 顧客 |
ステップ3のOCR検品では、出荷ラベルに印字された受注番号・届先名・品番・数量を読み取り、受注DBの出荷指示データとフィールド単位で突き合わせる。不一致が検出された場合は、そのケースをリジェクトラインに排出し、管理画面にアラートを表示する。
この照合処理では、PLCとAI検査の統合で培った制御信号の同期設計が応用できる。物理的なコンベア制御（リジェクト分岐）とOCR照合結果のデータ制御を、同一のタイミングで実行する必要があるためだ。
OCRエンジンの出力は一般的にJSON形式（フィールド名・読み取り値・信頼度スコアの構造体）であるが、各基幹システムが受け入れるデータ形式はそれぞれ異なる。このギャップを埋めるフォーマット変換の設計が、連携基盤の中核を担う。
| OCR出力フィールド | 変換処理 | ERP/TMS側フィールド |
|---|---|---|
| invoice_number（文字列） | 先頭ゼロ補完、ハイフン除去 | 伝票番号（固定長数値型） |
| product_code（文字列） | マスタ照合 → 正規化 | 品番（マスタ登録済みコード） |
| quantity（文字列） | 数値変換、単位分離 | 数量（整数型）＋単位コード |
| delivery_date（文字列） | 和暦→西暦変換、日付フォーマット統一 | 配送指定日（ISO 8601形式） |
| address（文字列） | 住所正規化、丁目・番地分割 | 届先住所（構造化フィールド） |
オンプレミスLLM連携の設計思想と同様、変換ロジックをエッジ側（中継サーバー）に配置することで、クラウド依存を排除し、ネットワーク障害時にもローカルでの変換処理を継続できる構成が実現できる。
基幹システム連携において最も運用負荷が高いのが、連携失敗時のリカバリーである。OCR→基幹システムのデータフローは24時間稼働する物流現場のクリティカルパスであり、連携が止まれば出荷が止まる。したがって、エラーハンドリングと監視の設計は「あったら良い」ではなく「必須」である。
| エラー種別 | 典型例 | 自動対応 | 手動フォールバック |
|---|---|---|---|
| OCR読み取りエラー | 信頼度スコアが閾値未満 | リトライ（再撮像 → 再読み取り） | 管理画面で目視確認・手入力 |
| マスタ不一致 | OCR読み取り品番がERPマスタに存在しない | 類似コード候補の自動提示 | オペレーターがマスタ確認・修正 |
| 通信エラー | ERP/TMSのAPIがタイムアウト | 指数バックオフ付きリトライ（最大5回） | CSV出力に切替（フォールバック連携） |
| データ整合性エラー | 数量が負値、日付が未来すぎる等 | バリデーションルールで検出・保留 | 管理画面でデータ修正後に再送信 |
| 基幹システム障害 | ERP定期メンテナンス、TMS障害 | ローカルキューにバッファリング、復旧後に一括送信 | 障害長期化時はCSVファイル出力に切替 |
連携基盤の稼働状況を常時監視するダッシュボードには、以下の指標を含めることを推奨する。
監視指標が閾値を超えた場合に、適切な担当者へ即時通知する仕組みが必要である。
これらのエラーハンドリング・監視の仕組みは、OCR導入のPoC段階から組み込んでおくことを強く推奨する。本番稼働後に「連携が止まったが原因がわからない」という事態に陥ることを防ぐためだ。
※ 記載の金額・料金は記事執筆時点の参考値です。最新情報は各メーカー・ベンダーの公式サイトをご確認ください。
基本方針は「既存システム側の改修を最小化する」です。API公開済みのERP・TMSにはREST APIで直接接続しますが、APIがない場合でも中継サーバーを介したCSV連携やDB直接更新で対応できます。多くのケースでは既存システムのコード変更は不要です。
OCR結果は基幹システムへ送信する前に、マスタ照合・信頼度スコア判定・フォーマットバリデーションの3段階で検証します。信頼度が閾値を下回った場合は自動送信を保留し、管理画面で人間が確認してから送信する設計を標準としています。
中継サーバー型のアーキテクチャでは、OCR側の出力フォーマットを統一し、各拠点のERPに合わせたアダプターを中継サーバー側に実装します。OCRエンジン自体は共通のまま、連携先だけを拠点ごとに切り替える設計が可能です。
PoC段階ではテスト用のステージング環境やサンドボックスAPIを利用し、本番データに影響を与えない形で連携テストを実施します。PoC設計書の段階で連携テスト計画まで含めてご提示します。
OCR導入後の「データの行き先」設計でお困りでしたら、貴社のシステム構成をお聞かせください。最適な接続パターンと概算スケジュールをご提示します。
無料相談はこちら →