基幹システムと現場Excelをつなぐ業務システム開発会社の選び方 ― 工程進捗表API連携の設計術
基幹システムは稼働しているのに、工程進捗表や検査成績書だけが今日もExcelで更新され、月末になると誰かが数字を基幹システムへ転記し直している——そんな光景に心当たりはないでしょうか。
基幹システム導入済みでも現場帳票が孤立する構造的な悩み
ものづくり白書など各種DX調査では、中小製造業の多くが基幹システム（生産管理・販売管理など企業の根幹業務を支えるシステム）をすでに導入しているにもかかわらず、現場の工程進捗表や検査成績書はExcelや紙のまま運用され続け、「データが分断されたまま」という課題が指摘されているとされています。
基幹システムは受発注・在庫管理を前提に設計されており、段取り替えの時間や検査の合否判定といった現場特有の項目を柔軟に入力できないケースが少なくありません。
現場担当者は使い慣れたExcelシートに手書きのような感覚で記録し、管理部門が後から基幹システムへ再入力する。この「二重入力」が常態化し、転記ミスや締め作業の遅延を生んでいます。
現場帳票をAIが読み取り基幹システムへ自動反映する業務アプリの設計
この分断を解消する方法のひとつが、現場で使っているExcel帳票や紙の検査成績書をAI-OCR（画像から文字を認識する技術）で読み取り、業務アプリを経由して基幹システムへAPI連携（システム同士がデータを自動でやり取りする仕組み）する設計です。全面的にシステムを作り替えるのではなく、「読み取り」と「連携」だけを担う小さな業務アプリを基幹システムの前段に置くイメージです。
この転記作業、本当に人がやる必要があるのか？
Before／After：工程進捗表の扱いはこう変わる
現場担当者が工程ごとの進捗をExcelシートに手入力→印刷して現場監督が確認→月次で経理担当者が基幹システムの「生産実績入力」画面に同じ数値を再入力。工程数が多いほど入力項目も増え、締め日直前に残業が発生する。
現場担当者は従来通りの工程進捗表（Excel）を更新し、業務アプリの「帳票アップロード」画面にドラッグ＆ドロップ。「読取結果確認」画面で工程名・数量・完了日時などの項目をAI-OCRが自動抽出し、担当者が内容を確認して「基幹システムへ反映」ボタンを押すだけで、基幹システムの生産実績データが自動更新される。読み取り結果は「工程進捗_反映済_20XX年XX月.csv」として出力され、監査用の証跡としても保存される。
転記工程がひとつ丸ごと不要になり、二重入力そのものがなくなる点がこの設計の本質です。数値上の削減効果を誇張するのではなく、「人が手で打ち直す工程が1本減る」という変化として理解しておくと、現場にも説明しやすくなります。
開発会社選定の判断基準：全面リプレース型か、API連携特化型か
こうした設計を依頼する際、開発会社は大きく二種類に分かれます。基幹システムごと作り替える「全面リプレース提案型」と、既存の基幹システムを活かしたまま連携部分だけを作る「API連携特化型」です。提案書の具体性と試作のスピードで見極めることができます。
「御社の基幹システムは◯◯社製のため、△△APIを利用して工程進捗表の項目をこう連携します」と、使用中のシステム名とAPI仕様まで具体的に言及している提案書は、現場調査を実際に行っている証拠です。
「帳票アップロード画面」や「読取結果確認画面」のモックアップを数週間で提示できる開発会社は、小さく作って検証するAPI連携特化型の進め方に慣れています。全面リプレース型は要件定義だけで数ヶ月を要することが多く、試作スピードの差は選定の重要な手がかりになります。
「工程進捗表だけ」「検査成績書だけ」という単位で費用と期間を分けて見積もれる開発会社は、小さく始めて段階的に広げる前提で設計しています。一括見積もりしか出てこない場合は、全面リプレース前提の提案である可能性が高いです。
開発会社の良し悪しは「大きな提案ができるか」ではなく「小さく作って現場で検証させてくれるか」で判断するのが、中小製造業にとって失敗しにくい選び方です。
1帳票1連携から始める試験導入の手順
基幹システム連携は一度にすべての帳票を対象にせず、最もミスや手戻りが多い帳票ひとつに絞って試験導入するのが定石です。
工程進捗表、検査成績書、出荷伝票など候補が複数ある場合は、二重入力の頻度が最も高い帳票を優先します。
「読取結果確認」画面で誤読箇所を手直しできる設計にし、1〜2ヶ月は確認作業を残したまま運用し、読み取り精度のログを蓄積します。
最初の帳票で基幹システムとのAPI連携仕様が確立すれば、同じ構成を検査成績書や出荷伝票にも転用しやすくなり、部署展開のたびに設計をゼロから作り直す必要がなくなります。
この進め方であれば、万一読み取り精度が思うように上がらなくても影響範囲は1帳票にとどまり、開発会社とのやり取りも「この項目の読み取りだけ調整してほしい」と具体的に依頼できます。
まとめ
- 基幹システムが稼働していても、現場の工程進捗表・検査成績書がExcelのまま孤立し二重入力が続くのは中小製造業に共通する構造的課題
- 解決の鍵は全面リプレースではなく、AI読み取り＋API連携による小さな業務アプリを基幹システムの前段に置く設計
- 開発会社選定は提案書の具体性と試作スピードで見極め、1帳票1連携から試験導入して精度を確認しながら段階的に展開するのが失敗しにくい進め方
本記事はAIを活用して作成しています。内容についての責任は当社が負います。AI活用ポリシー