「うちの基幹は古くてAPIなんて無い」——そう言われた瞬間に連携を諦めていないでしょうか。実は多くの基幹システムには、CSV取込や共有フォルダという昔ながらの「口」が残っています。本記事では、基幹の改修ゼロからAI-OCRの結果を流し込む現実的な設計と順序を整理します。
結論から言えば、APIが無くても基幹システムとAI-OCRの連携は多くの場合で可能です。ここでいうAPIとは、外部プログラムがデータを読み書きするための決められた入り口のことで、これが公開されている基幹は連携が楽になります。しかし現場で使われている基幹の相当数は、数年〜十数年前に導入されたパッケージや自社開発資産であり、そもそもAPIという概念が前提になっていません。それでも連携を諦める必要はないと考えられます。
背景にあるのは、深刻な人手不足とコスト構造の変化です。伝票・納品書・ラベルといった紙由来の情報を人が目で読んで基幹に手入力する作業は、担当者の高齢化や採用難のなかで維持が難しくなりつつあります。AI-OCR（画像から文字を読み取る技術。近年はVLM＝画像と言語を同時に扱うモデルの活用も進んでいます）で読み取り自体は自動化できても、その結果を基幹に「入れる」ところで止まってしまう——これが多くの情報システム担当者が直面している壁だと考えます。
止まる理由の多くは、技術的な不可能ではなく「口の存在を知らない」ことにあると考えられます。APIという新しい入り口が無いことばかりに目が行き、多くの基幹に昔から備わっているCSV取込やファイル連携の口が見落とされがちです。まずは、リアルタイムで直接つなぐという発想を一度手放し、自社の基幹に何の受け口が残っているかを棚卸しすることが、現実的な第一歩になりうると考えます。
連携方式を選ぶ基準は、技術のモダンさではなく「壊れにくさ」と「基幹を改修しなくて済むか」の二点に置くのが現実的だと考えられます。最新の連携方式が常に最良とは限りません。むしろ、基幹側に手を入れずに済み、失敗しても人が気づいて直せる方式のほうが、中小規模の現場では長く使えることが多いと考えます。
連携には大きく「即時性」と「実装の重さ」というトレードオフがあります。リアルタイム連携は反応が速い一方、基幹側の改修やAPIの用意が必要になり、実装も運用も重くなりがちです。対してファイル連携やバッチは反応こそ遅いものの、基幹の既存機能をそのまま使え、改修ゼロで始められる場合が多いと考えられます。基幹側から見た連携の要点は物流OCRと基幹連携でも整理しています。
「リアルタイム連携でなければ意味がない」という思い込みは、一度検証する価値があると考えます。納品書の入力が数時間後にまとめて反映されても業務が回る現場は少なくありません。むしろ即時反映は、読み取り誤りがそのまま基幹に流れ込むリスクと表裏一体です。日次や数時間おきのバッチにして、その間に人が確認・修正する余地を残すほうが、結果的に安全で運用しやすい場合が多いと考えられます。まず自社の業務が本当に即時性を要求しているのかを、フローに即して見極めることをおすすめします。
APIが無くても、多くの基幹には昔ながらのデータ受け口が残っています。代表的なのは、CSVや固定長ファイルの取込機能、共有フォルダ経由のファイル受け渡し、中間テーブルへの書き込み、そして夜間バッチによる一括取込です。これらは地味ですが、基幹の改修なしに使えることが多く、AI-OCRとの連携において十分に現実的な解になりうると考えられます。
| 取込口 | 基幹の改修 | 向く場合 | 注意点 |
|---|---|---|---|
| CSV・固定長ファイルの取込機能 | 不要なことが多い | 基幹に標準の取込機能が残っている場合 | 項目順・区切り・文字コードを基幹側に合わせる |
| 共有フォルダ経由のファイル連携 | 不要なことが多い | 両システムを疎結合のまま始めたい場合 | ファイル名の一意化と処理済み移動で二重取込を防ぐ |
| 中間テーブル＋夜間バッチ | 場合による | 基幹の正規取込ロジックを通したい場合 | ベンダーの保守条件に触れる場合があり事前確認が前提 |
| RPAによる画面操作 | 不要 | 取込口が一切無い場合の最後の手段 | 画面の変化で止まりやすく、夜間無人運転に不向き |
CSVや固定長ファイルの取込は、最も枯れていて確実な口の一つだと考えられます。多くの基幹は、外部で作成したデータを定型フォーマットで読み込む機能を最初から備えています。AI-OCRの読み取り結果を、この基幹が期待する項目順・区切り・文字コードに整形して渡すだけで取り込める場合があります。固定長ファイルとは、各項目の桁数を固定した昔ながらの形式で、古い基幹ほどこれを前提にしていることが多いと考えます。
社内の共有フォルダ（ファイルサーバー上の決まった置き場）にファイルを出力し、基幹側が定期的にそれを見に行って取り込む方式も広く使えます。AI-OCR側は「決まった場所に決まった名前でファイルを置く」だけで済み、両システムが直接通信する必要がありません。疎結合（お互いの内部を知らずに済む結びつき）なので、片方が止まってももう片方に波及しにくいという利点があると考えられます。
基幹と同じデータベース上に「中間テーブル」（取込前の一時置き場となる表）を用意し、そこへ書き込んでから基幹の夜間バッチで本テーブルに反映する方式もあります。基幹の正規の取込ロジックをそのまま通せるため、整合性チェックを基幹側に任せられるのが利点です。ただしデータベースへの直接書き込みは、基幹ベンダーの保守条件に触れる場合があるため、事前に契約・サポート範囲を確認することが前提になると考えます。
ファイル連携で最初に決めるべきは、フォーマットよりも「異常時にどう振る舞うか」です。正常に流れているときは何を選んでも動きます。差が出るのは、文字化け・取込失敗・二重取込・エラー発見といった異常時の設計であり、ここを先に固めておくことが安定運用の分かれ目になりうると考えられます。
文字コードと改行コードの不一致は、ファイル連携で最も多いつまずきの一つだと考えます。古い基幹はShift_JIS（Windows系の従来文字コード）を前提にしていることが多く、UTF-8で出力すると文字化けや取込エラーになりがちです。丸数字や一部の外字が化けることもあります。基幹が期待する文字コード・改行コードをドキュメントで確認し、AI-OCR側の出力をそこに合わせて固定することが出発点になると考えられます。
二重取込の防止は、自動化する前に必ず設計しておくべき点だと考えます。バッチが二重に走る、同じファイルを二度置く、といった事故は現場で起こりえます。対策としては、ファイル名に日付や連番を含めて一意にする、取り込んだファイルを処理済みフォルダへ移動する、伝票番号などの業務キーで重複を弾く、といった方法が考えられます。複数を組み合わせておくと、片方が破れても検知できる余地が残ると考えます。
取込が途中で失敗したとき、どこからやり直せるかを最初に決めておくことが重要だと考えられます。理想は、同じファイルをもう一度流しても結果が変わらない（冪等な）設計です。難しい場合でも、失敗したファイルは取り込まれずに待避され、原因を直して再投入すれば復旧できる、という手順を用意しておくことで、被害を局所化できると考えます。既存資産を活かす連携の考え方は既存システムからの移行も参考になります。
結論として、画面をRPAで操作して入力する方式は「最後の手段」と位置づけるのが現実的だと考えられます。RPA（人の画面操作を自動で再現するソフトウェア）は、CSV取込もファイル連携も中間テーブルも一切使えない基幹に対して、それでも自動化したいときの有効な選択肢です。ただし、他の口が使えるならそちらを優先するのが無難だと考えます。
RPAが向くのは、どうしても外部からの取込口が存在せず、かつ入力画面が安定していて変更が少ない基幹の場合です。一方で向かないのは、基幹の画面レイアウトやバージョンが頻繁に変わる場合、入力件数が多く処理時間がかかる場合、そして夜間に無人で確実に流したい場合だと考えられます。人の操作を模倣する方式は、画面のわずかな変化で止まりやすいためです。
RPAが壊れやすい理由は、それが「正式な連携口」ではなく「画面という人間向けのUIを間借りしている」ことにあると考えます。ボタンの位置が数ピクセルずれる、確認ダイアログが1つ増える、項目の並びが変わる——こうした人間なら難なく対応できる変化で、RPAは静かに失敗します。まずCSVやファイル連携の口が無いかを十分に探し、それでも無い場合の次善策としてRPAを検討する、という順序が堅実だと考えられます。基幹をつくり替えずに賢くする発想はレガシー資産とAIでも扱っています。
連携を動かし続ける鍵は、技術ではなく「エラーを誰が見て、誰が直すか」を最初に決めておくことだと考えられます。自動化された連携は、正常時は誰の目にも触れません。だからこそ異常が起きたときに気づく仕組みと担当者を用意しておかないと、静かに止まったまま誰も気づかない、という最悪の状態になりうると考えます。
運用設計では、AI-OCRの「読み取り誤り」と連携の「取込エラー」を分けて考えることが重要だと考えます。読み取り誤りは、文字は流れたが値が間違っている問題で、確からしさ（信頼度）の低い項目を人が確認する運用で吸収するのが一般的です。取込エラーは、ファイルが基幹に入らない問題で、こちらはシステム担当者の対応領域です。両者は原因も担当も違うため、切り分けて監視することが現場を守ると考えられます。
読み取り結果を人が確認・修正する場を、基幹に入れる前に設けるのが安全だと考えられます。基幹に入ってから直すと、取消や再入力の手間が大きく、履歴も複雑になりがちです。読み取り結果を一覧で確認し、信頼度の低い箇所だけを修正してから連携ファイルを確定する——この一段を挟むことで、誤った値が基幹に流れ込むのを防ぎやすくなると考えます。読み取り結果を台帳へ入れる基本はWMSとOCRの連携で整理しています。なお、OCRと受け側システムのベンダーが別会社の場合は、この連携部分がどちらの見積にも入らない「谷間」になりがちです。契約段階での決め方は連携部分の責任分界で扱っています。
連携が動き始めてから顕在化しやすい落とし穴を、事前に押さえておくことをおすすめします。以下はいずれも、最初の設計で少し手当てしておけば防げることが多いと考えられる項目です。
最初の一歩は、大がかりな連携基盤の構築ではなく、現物の帳票と現行フローを客観的に把握することだと考えられます。どんな紙が、どの担当者を経て、基幹のどの画面に、どんな順で入力されているか。ここを実際の現物で確認せずに設計を先行させると、現場と噛み合わない仕組みになりがちだと考えます。
現実的な順序は、①基幹に残っている取込口の確認 → ②一種類の帳票に絞ったCSV/ファイル連携の試行 → ③日次バッチでの運用と効果測定 → ④対象帳票の拡大や連携頻度の見直し、という段階を踏むことだと考えられます。最初から全帳票・リアルタイムを狙わず、改修ゼロで小さく回し、効果を確認してから連携を深めるほうが、失敗の被害も学習コストも小さく抑えられると考えます。
Nsightは、元キーエンス画像処理事業部の現場知見に、VLM・Jetsonなどのエッジ処理・産業用カメラ・現場ライティングを組み合わせ、読み取りから基幹連携までを現場の実態に即して設計します。特定の基幹パッケージ名で断定はしませんが、多くの基幹に残る昔ながらの口を活かし、改修ゼロから始める設計を得意としています。在庫台帳と現場をつなぐコアであるWMS（倉庫管理）との連携も、同じ考え方で組み立てられると考えます。効果や精度は現物・現場での検証が前提であり、まずは小さく試すことをおすすめします。
多くの場合で可能だと考えられます。APIが無くても、CSVや固定長ファイルの取込機能、共有フォルダ経由のファイル連携、中間テーブル、夜間バッチといった昔ながらの受け口が残っていることが多いためです。まずは自社の基幹にどの口があるかを確認するのが出発点になります。ただし実際に使えるかは基幹の仕様や保守契約により異なるため、現物での確認が前提になると考えます。
必ずしもそうではないと考えられます。納品書などの入力が数時間後にまとめて反映されても回る業務は少なくありません。むしろ日次や数時間おきのバッチにすることで、その間に人が読み取り結果を確認・修正でき、誤った値が基幹に流れ込むのを防ぎやすくなります。自社の業務が本当に即時性を必要としているかを、フローに即して見極めることをおすすめします。
異常時の振る舞いを先に決めておくことだと考えます。具体的には、基幹が期待する文字コード・改行コードへの統一、二重取込を防ぐ仕組み（ファイル名の一意化や業務キーでの重複チェック）、取込失敗時にどこからやり直せるか、そしてエラーを誰が見て直すか、の四点です。正常時はどの方式でも動くため、差が出る異常時の設計が安定運用の分かれ目になりうると考えられます。
最後の手段と位置づけるのが現実的だと考えられます。CSV取込やファイル連携の口が一切無い基幹には有効ですが、RPAは人間向けの画面を間借りするため、画面レイアウトやバージョンの変化で止まりやすい弱さがあります。取込口が使えるならそちらを優先し、無い場合の次善策としてRPAを検討する順序が堅実だと考えます。
連携方式によっては必要だと考えます。特に中間テーブルへの直接書き込みは、基幹ベンダーの保守条件やサポート範囲に触れる場合があるため、事前の契約確認が前提になります。一方、基幹に元から備わるCSV取込機能や共有フォルダ経由のファイル連携は、正規の機能を使うため許可が不要なことが多いと考えられます。方式を決める前に、保守契約書とベンダーへの確認を済ませておくことをおすすめします。
「うちの基幹は古いから無理」と諦める前に、どんな取込口が残っているか、どの帳票から始められるかを一緒に確認できます。実際の帳票と現行フローを客観的に把握するところから、改修ゼロで小さく検証を始めましょう。
基幹とAI-OCRの連携について相談する