二重入力をなくす方法｜タイ工場のMES・ERP・WMS連携

工場の二重入力をなくすには、紙をタブレットへ置き換えるだけでは足りません。同じ生産実績を現場日報、MES、ERPへ別々に入力し、入庫時にはWMSへ再入力しているなら、画面が増えても転記ミスは残ります。必要なのは「どの事実を、誰が、どこで一度だけ確定し、いつ他システムへ渡すか」を決めることです。本稿は、タイ工場の現場・情報システム・経理・倉庫が共通で使える要件定義、RFP、FAT/SATの実務ガイドです。

二重入力が起きる場所を、まず見える化する

よくある流れは、作業者が紙の日報に数量を書き、班長がExcelに集計し、事務担当がERPへ実績を登録し、倉庫担当がWMSへ完成品を入庫するというものです。どれも仕事に理由があります。現場は停止と不良を残したい、ERPは原価と在庫を締めたい、WMSは棚位置と出荷可能数を管理したいのです。問題は、同じ数量をそれぞれが別の「確定値」として持ち、差が出たときに正しい値と訂正責任者が分からないことです。

最初の調査では、入力画面の数ではなく、事実の流れを一つずつ追います。製造指図、投入材料、出来高、検査結果、完成品入庫、出荷というイベントごとに、最初に発生する場所、承認者、保存先、他システムへの転記先、締め時点を書き出します。同じ数字が複数の場所にあっても、それが参照用コピーか、独立した入力可能な台帳かでリスクは違います。紙を法的・顧客要求で保管する場合も、紙への記入を唯一の原本とするのか、電子記録の印刷控えにするのかを分けて判断します。

これは業務フロー全体の再設計や、請求書の自動化の解説ではありません。対象を「製造実績から入庫・出荷までの同じ事実の再入力」に絞ります。既存の工程や役割を調べたうえで、入力先と確定時点を一つに定め、必要なシステムへ安全に反映することが狙いです。

全体の役割・工程を見直す段階ならタイ工場の業務フロー改善を先に参照してください。本稿はフローが決まった後の、データの二重登録と差異を防ぐ実装条件に焦点を当てます。

「正本」を項目ではなくイベントごとに決める

「ERPが正本」と一言で決めても現場では使えません。ERPは受注と会計の正本でも、設備停止の時刻を作る場所ではありません。MESが製造実績の正本でも、実際の棚位置はWMSが管理します。正本とは、あるイベントの値を最終的に確定し、訂正の権限と履歴を持つシステムです。コピー先に表示される値が同じでも、誰でも編集できるなら正本の決定は意味を失います。

製造指図なら、ERPで発行された指図IDと版をMESへ配信し、現場は受け取った指図から作業を始めます。途中で数量や納期が変わったら、ERPで改訂し、MESで受領・実行可能性を確認します。既に完成した実績を改訂で上書きしないのが重要です。材料投入なら、投入場所で袋や容器のコードを読み、作業者が確定します。ERPには材料消費として伝えますが、ERP上で同じ投入履歴を再入力しません。

完成品は、成形機や組立機のカウンターが示した時点では必ずしも出荷可能ではありません。検査、手直し、梱包が終わった数量をMESで「完成」と確定し、棚入れした箱をWMSが「保管場所に存在する」と確定する二段階にします。ERPの利用可能在庫へいつ反映するかは、この二つの事実と保留状態に合わせて定めます。両方を一つの数へ無理に圧縮すると、品質保留品を売れる在庫として表示したり、棚に無いものを出荷指示したりします。

ISA-95は、製造運用と企業側の業務との情報交換を考える枠組みです。MESを含むレベル3とERPを含むレベル4の境界を整理する参考になります。ただしISA-95が各工場の「正本システム名」を自動的に決めてくれるわけではありません。業務上の責任者がイベント別に合意する必要があります。

正本表に必ず入れる列

正本表は「データ項目」「発生イベント」「入力者」「確定者」「訂正者」「正本システム」「参照先」「締め時点」「消込キー」「障害時の代替手順」で作ります。たとえば良品数は、作業者の暫定入力を班長または品質担当が確定し、確定後の訂正は差分イベントとして承認者が記録する、という具合です。画面ごとの権限設定だけでなく、訂正後にERPとWMSへ何が再送されるかまで決めます。

「一度だけ入力」は「一度しか見ない」という意味ではありません。品質、倉庫、経理は同じイベントをそれぞれの画面で確認できます。複製が必要でも、参照専用の値と管理上の派生値にします。たとえばMESの確定良品数とERPの原価計算用数量は同じイベントから導けますが、換算単位や締め時点が異なる場合は計算式と差異理由を明示します。

転記ミス防止に必要な共通IDと単位

同じ品目を「A-100」「A100」「製品A」と各システムが呼ぶと、人が照合する作業は消えません。連携前に品目、製造指図、ロット、箱、パレット、機械、倉庫、保管場所のIDを対応づけます。表示名は日本語・タイ語・英語で違っても構いません。内部IDは不変にし、旧コードや得意先コードは別名として管理します。短い桁数へ無理に変換して衝突する設計は避けます。

バーコードは入力を速くする道具であり、正本設計の代わりにはなりません。GS1の仕様にはロットを表すAI (10)などの識別子があります。GS1を採用するか独自コードを使うかは、取引先要件と現場運用に応じて決めます。どちらでもスキャンした文字列をそのまま全システムの主キーにせず、品目・ロット・数量・単位・梱包階層を解析し、マスタと照合してから確定します。読取不能、ラベル貼り間違い、複数ロット混載の扱いも決めます。

数量の単位違いは二重入力以上に厄介です。現場は個、倉庫は箱、ERPはkgを使う場合、換算係数の版と適用日を持たせます。箱の入り数が途中で変わる製品なら、単純な「箱×固定個数」では履歴が合いません。実数量と表示用換算数量を分け、元のイベントを消さずに差分で訂正します。異なる単位の値を合計する前に、基準単位と丸め規則を合意してください。

基幹システム連携の鍵はイベントID

APIやメッセージキューがあれば、二重入力が自動的に消えるわけではありません。通信が切れ、送信側が再送し、受信側が同じ実績をもう一度登録すると、在庫が二倍になります。各業務イベントへ一意のIDを付け、送信側は同じイベントの再送時に同じIDを使い、受信側は処理済みIDを記録して二重反映を避けます。訂正は旧イベントの上書きではなく、旧イベントを参照する取消・差分・再確定のイベントとして扱います。

取引先との注文・出荷情報まで広げる場合は、工場内のMES―ERP連携と外部とのEDIを分けて考えます。外部接続の項目と責任分界は製造業EDI連携の設計も参考になります。

Microsoftのメッセージング設計資料も、再配信が起こり得るため受信側を冪等にする必要を説明しています。これは特定クラウド製品の導入推奨ではなく、システム間連携全般に使える設計原則です。「一回だけ送る」ことへ依存せず、「複数回来ても結果は一回分」にすることが要点です。イベントIDは作成システム名と合わせて全社で一意にし、受信側の保存期間をイベント再送期間より短くしないようにします。

一つのイベントには少なくとも、イベントID、種類、発生元、発生時刻、確定時刻、対象ID、数量と単位、版、関連イベントID、作業者またはシステムID、ペイロード版を持たせます。タイ工場の現場にはタイ時間で表示しても、システム間ではタイムゾーンを含む時刻で交換します。夜勤の日付境界や、後から入力された実績の発生時刻と登録時刻を混同しないためです。

注文データ、指図、実績、在庫は更新頻度が異なります。秒単位で設備停止を見たい場合と、品質承認後にERPへ完成実績を反映する場合を同じ即時連携にしないでください。連携時点は「イベント発生時」「承認時」「箱確定時」「日次締め時」から業務に合わせて選び、遅延の許容時間と連携失敗時の連絡先を明記します。これがないと、画面に表示された古い数値を担当者が手で再入力してしまいます。

エラーを隠さない「例外キュー」を作る

連携を自動化すると、エラーは必ず起こります。品目マスタが未登録、単位が不一致、ロットが保留、ERPが停止、WMS側で箱番号が重複、という場面です。エラーをシステムログだけに残すと、現場は処理済みと思い込み、事務担当は翌朝にExcelで補填します。結果として二重入力が復活します。

例外キューには、失敗したイベントID、発生元、対象の指図・箱・ロット、失敗時刻、理由、担当部門、再試行回数、最後の応答、現在状態を出します。「未処理」「調査中」「再送待ち」「解決」「手動補正済み」を区別し、手動補正時は元イベントとの関係と承認者を残します。再送ボタンは同じイベントIDで実行し、別IDの新規実績を作らないようにします。

異常を通知する条件も設計します。単に「連携エラーが1件」では夜勤で通知疲れが起きます。出荷停止に直結する保留・在庫不整合は即時、日次集計の軽微な遅延は締め前、という業務上の期限で分けます。解決までの時間と滞留件数を見える化し、未処理のまま月次締めへ進まないルールを作ります。例外キューは運用費を左右するため、RFPで標準機能か追加開発かを必ず確認してください。

エラーで失ったイベントを誰が再入力してもよい設計は危険です。通信復旧後に自動再送されると、手入力分と重複します。代替運用では、紙またはCSVに記録したイベントを後で取り込む際にも同じイベントIDを付け、処理済みチェックへ通す必要があります。完全にオフラインの現場端末なら、端末側で仮IDを発行し、再接続時にサーバーIDへ紐付けます。

監査証跡は「誰が直したか」だけでは足りない

監査ログには、元の値、新しい値、訂正理由、訂正者、承認者、時刻、影響した後続システム、再送結果を残します。ERPの在庫が変わった後にMES実績を訂正した場合、ERPとWMSへ訂正イベントが届いたか確認できることが重要です。画面上の数字だけ直して下流が古いままなら、二重入力をなくしたとは言えません。削除権限は厳しくし、誤入力は原則として取消・訂正履歴で表します。

監査証跡と個人情報の取り扱いは、必要性とアクセス権を分けて設計します。誰がどのジョブを確定したかは品質上必要でも、全員に作業者の個人情報を表示する必要はありません。保存期間は顧客契約、業界要件、社内規程に合わせ、バックアップからの復旧時にもイベント順序と訂正関係が保たれるかを確認します。

システムが違えばアクセス権も違います。MESで班長が承認したイベントをERPで一般ユーザーが無断修正できるなら、正本ルールは崩れます。権限表には新規入力、承認、取消、再送、手動補正、例外キューの解決を別操作として記載します。共用端末では個人IDの共用を避け、短時間で交代できるログイン方法を用意します。

タイ工場で先に確認する運用条件

日本本社のERP、タイ工場のMES、現地倉庫のWMSが別々のベンダーで運用されると、障害時の責任が曖昧になりがちです。RFPにシステム境界図とデータ責任者を付け、連携障害の一次受付、原因切り分け、夜勤の連絡先、復旧目標を指定します。タイ語画面だけでなく、エラーメッセージ、例外キュー、教育資料、現場帳票も現地担当者が理解できる言語にします。日本語・タイ語の表示名は変えても、エラーコードとイベントIDは共通にします。

現場にはWi-Fiの死角や手袋で操作しにくい端末があります。入力件数を減らしても、一回の操作が複雑なら作業者は紙にメモします。製造指図をスキャンしたら必要な品目・工程・単位を先に表示し、数量だけ入力する、材料ロットはバーコードで選ぶ、異常時は理由を数回のタップで選ぶなど、現場での操作を実機で試します。端末故障時には、どの紙様式または予備端末を使い、誰がいつ電子記録に取り込むかを決めます。

タイのdepaが公表した2024年調査は、製造業のデジタル導入が進む一方で成熟度に差があることを示しています。ただし、個々の工場が同じ段階にあるとは限りません。自社の紙、Excel、MES、ERP、WMSの実態を測ることから始めます。BOIの制度に関係する投資であれば、最新の対象条件をBOIへ確認してください。連携システムを入れれば自動的に優遇されると判断しないでください。

二重入力をなくすRFP：ベンダーへ聞く10項目

機能一覧で「ERP連携あり」にチェックが入っても、実際にはCSVを手でダウンロードして別システムへアップロードする場合があります。RFPでは業務イベントと失敗ケースを具体的に渡し、標準機能、設定、追加開発、対象外を分けて回答させます。連携先のベンダーにも同じ仕様を確認します。

1. 正本：指図、材料投入、良品、検査、入庫、出荷の各イベントをどこで確定するか。
2. ID対応：品目、指図、ロット、箱、棚のIDと旧コードをどう変換・保持するか。
3. 単位：個・箱・kgの換算、丸め、入り数変更の履歴をどう扱うか。
4. 連携時点：発生、承認、箱確定、締めのどの時点で送るか。最大遅延は何分か。
5. 重複防止：同じイベントを3回送っても在庫と実績が1回分であることをどう示すか。
6. 順序：訂正が元イベントより先に届いた場合の保留、再処理、警告はどう動くか。
7. 例外キュー：誰が、何件、どの状態のエラーを確認・再送・承認できるか。
8. 監査：元値・新値・理由・承認者・下流反映の履歴をどこまで検索できるか。
9. 障害：ネットワーク断、ERP停止、端末故障時のローカル保存と復旧手順は何か。
10. 費用・責任：API、コネクター、監視、保守、夜勤支援、変更対応の範囲と費用は何か。

回答にはサンプルのイベントデータ、項目対応表、例外キューの画面、監査ログ、試験手順を添えてもらいます。見積は初期費用だけでなく、API利用料、機器、現場端末、データ保存、インターフェース変更、保守を含む複数年の総費用で比べます。既存システムの仕様が非公開の場合、現地調査と接続検証を先に小さな契約に分けると、未確認の前提を価格に埋め込みにくくなります。

FAT/SATの受入試験で再入力ゼロを確認する

受入基準は「連携成功」よりも業務の整合で書く

連携プログラムが「送信成功」と表示しても、受信先の在庫や原価へ正しく反映されたとは限りません。送信側は受付応答を受けた時点で成功とし、受信側は後続のマスタ検証で保留する場合があります。そこでRFPと試験表には、①送信した、②受信した、③業務検証に通った、④台帳へ反映された、⑤照合で一致した、という段階を分けて書きます。運用画面にも同じ段階を表示し、途中状態を「完了」と誤認しないようにします。

照合は数量の総計だけでは不十分です。ある箱が二重計上され、別の箱が欠落すると総計は偶然一致します。イベントID、指図ID、品目、ロット、箱、数量、単位、状態の組合せで突き合わせ、差異一覧を出します。差異が出たときに、どちらの台帳を正すかを人が判断できるよう、元イベントと訂正履歴へすぐ移動できる画面が必要です。日次照合を自動化しても、差異の承認は業務責任者に残します。

たとえば夜勤の終わりに20件の入庫イベントがWMSへ送られ、ERP停止のため3件だけ未反映になった場合、翌朝の事務担当が3件を手入力するのではなく、例外キューの3件を原因解決後に再送します。復旧後は「20件すべてが一度ずつ反映され、再送した3件も二重計上されていない」ことをイベント単位で確認します。これは単純なAPI疎通試験では見えない、二重入力削減の受入条件です。

外部ベンダー間の責任分界も試験表へ書きます。MESが正しいイベントを送り、ERPが不正な品目として拒否した場合、品目マスタの所有者が修正し、MES側の担当者が再送結果を確認します。通信の問題なのか、業務ルールの問題なのかで担当が異なります。責任者が決まっていないと、各社が「自分のシステムは正常」と答え、現場だけが再入力を続けます。

FATでは模擬のMES・ERP・WMS接続で機能を確かめ、SATでは実際の現場端末、ネットワーク、機械、倉庫ラベル、既存システムで再試験します。自動連携が成功する通常ケースだけでは、運用開始後の手入力を減らせません。テストごとに初期状態、操作、期待結果、証跡、責任者、再試験条件を契約時に決めます。合格値は工場の業務要求から定め、以下の例を普遍的な保証値として使わないでください。

受入判定に「画面が表示された」を使わず、①人が同じ事実を再入力した回数、②送信・受信・確定の件数、③システム間差異、④例外の解決時間を測ります。実測した現状値と目標値を比較し、結果を記録してください。目標はゼロ件の手入力だけではなく、再入力が必要な例外の理由が明確で、承認・監査できることです。現場では法令や顧客要求で手動確認を残す場合もあり、その確認を「二重入力」と混同しないようにします。

小さく始める順序と運用後の点検

効果を測るときの分母を先に決める

「二重入力を半減した」と報告する前に、何を一件と数えるかを決めます。一つの製造指図で良品数を三画面に手で入力したなら、原本の確定操作一回と転記操作二回を分けます。バーコードの確認スキャンや品質承認は、同じ数字を打ち直していなければ転記回数に含めません。逆にCSVを出力し、担当者が表を直してアップロードしているなら、画面で数字を直接打っていなくても手作業の再登録として数えます。この定義をパイロット前後で変えると、改善率の比較はできません。

測定表には、対象期間、対象ライン、対象イベント種、発生件数、手入力の原本件数、同一内容の再入力件数、手動補正件数、処理待ち件数、差異件数、作業時間を記録します。作業時間は担当者の推測ではなく、代表的な操作を実際に観察して測ります。夜勤や月末の締め作業を除いた日勤の平均だけでは、例外処理の負荷を過小評価します。入力削減と同時に、未処理イベントが増えていないことを必ず見ます。

効果を金額に換算するときは、削減された転記時間に標準人件費を掛けた参考値と、実際に削減できた残業・外注費を区別します。空いた時間を品質確認へ振り向けるなら、人件費がそのまま現金として減るわけではありません。一方、誤出荷や在庫差異の減少は価値が大きくても、発生頻度が少ないと短い試行期間では統計的に証明しづらいものです。確実に測れた事実と期待効果を分けて報告します。

経営報告には「入力画面数」だけでなく、同じ事実の再入力率、連携成功率、例外の平均滞留時間、イベント単位の照合一致率を並べます。連携成功率が高くても、失敗した少数のイベントが出荷や月次締めを止める場合があります。重要度別の未解決件数と最長滞留時間も示すと、次にどの例外を改善すべきか判断できます。

第一段階は、対象を一つの製品群と一つの工場ラインに絞り、紙・Excel・MES・ERP・WMS間の再入力箇所を数えます。画面を変更する前に、正本表とID対応表を承認し、現場と倉庫の責任者が例外ケースを出します。第二段階で最も頻度が高く、金額・在庫影響が大きい一つのイベントを連携します。たとえば完成品入庫です。そこで重複防止、例外キュー、訂正履歴を完成させてから材料消費や出荷へ広げます。

パイロットは簡単な日勤だけで終えないでください。少なくとも夜勤の班交代、ネットワーク断、品質保留、箱ラベルの再発行を試します。実運用では週次に、連携失敗件数、手入力補正件数、在庫差異、未解決の例外、イベント再送回数を見ます。数字が悪化したら人を責めるのではなく、入力画面、マスタ、承認手順、連携仕様のどこに原因があるかを確認します。

紙とExcelを撤去する日は、保存義務、監査、バックアップ、障害時の代替手順を確認してから決めます。電子化の途中で旧台帳と新システムを並行運用する期間はあり得ますが、その期間の正本を明示しないと差異が膨らみます。切替日時、未処理イベントの移行、旧データの参照方法、ロールバック条件を決めておきます。これは履歴データを大量移行する方法論ではなく、二重入力を再発させない切替管理です。

FAQ：工場の二重入力・ERP連携でよくある質問

二重入力をなくすには、まずERPを入れ替えるべきですか？

必ずしも必要ありません。既存ERPがAPIや安全なファイル連携を提供し、イベントIDと訂正を受け取れるなら、MES・WMS側の正本設計と連携改善で解決できる場合があります。まず再入力しているイベント、各システムの変更可能範囲、障害時の運用を調べてください。システム入替が必要かは、その結果で判断します。

転記ミス防止はバーコードだけで実現できますか？

バーコードは品目やロットの手打ちを減らしますが、誤ったラベル、単位違い、二重スキャン、未承認の在庫計上は防げません。マスタ照合、入力先の指定、イベントID、承認、例外キューを合わせて設計してください。スキャンの成功と業務イベントの確定を分けて扱うことが重要です。

ERP連携と生産管理はリアルタイムが必須ですか？

監視や安全に関わる表示は短い遅延が必要な場合がありますが、在庫は品質承認後、会計は締め時というように、業務ごとに確定時点が異なります。全イベントを即時に送ると未確定値が下流に広がることがあります。イベントごとに許容遅延と下流の利用条件を決めてください。

二重入力をなくした後も紙の記録が必要ですか？

顧客契約、業界規制、社内規程次第です。紙が必要でも、電子記録から帳票を出す方式にできる場合があります。紙に手書きした値を電子システムへ再入力する運用が残るなら、その紙の法的な位置付け、検証・訂正方法、電子記録の正本性を確認してください。

タイ工場で日本本社ERPにつなぐ場合の注意点は？

時刻・生産日の扱い、タイ語のエラー表示、夜勤の連絡体制、品目コードと単位、ネットワーク障害時の再送が重要です。現地で発生したイベントを本社側で再入力する設計にせず、現地の確定イベントを共通IDで渡し、本社は受信と例外解決を確認できるようにします。

まとめ

工場の二重入力をなくす鍵は、紙を消すことよりも、イベントごとに正本と確定時点を決めることです。共通ID、単位、再送しても一回分しか反映しない仕組み、例外キュー、訂正の監査証跡をセットで設計します。RFPでは通常時だけでなく、品目未登録、通信断、品質訂正、夜勤の例外を問い、FAT/SATで人の再入力回数とシステム間差異を確かめてください。

タイ工場の現場日報・MES・ERP・WMSで同じ値を何度も入力している場合、TOMAS TECHにご相談ください。現行の入力箇所とシステム境界を一緒に整理し、正本表、連携要件、受入試験に落とし込む段階から対応できます。

参考情報

• ISA：ISA-95 Enterprise-Control System Integration（MESとERPを含む業務境界の参考）
• GS1：GS1 Application Identifiers（ロット識別子AI (10)等の定義）
• Microsoft Learn：非同期メッセージの選択と冪等性（重複配信への設計上の注意）
• Microsoft Learn：Publisher-Subscriber pattern（相関ID、順序、重複処理の考え方）
• OPC Foundation：OPC UA Overview（設備と上位システム間の情報モデル）
• depa：Thailand Digital Density Survey（タイ産業のデジタル導入に関する公表資料）
• Thailand BOI：Smart and Sustainable Industry（制度条件は申請時に要確認）

*本稿は2026年10月時点の公開資料と一般的なシステム設計に基づきます。法令・顧客契約・保存期間・合格値は個別案件で確認してください。*