タイ工場で実績収集システムを導入するとき、本当の難所はPLCから値を読めるかではありません。停止中に溜まったデータが再送されたとき二重計上しないか、作業者の後入力をどう扱うか、検査結果が未承認のままERPへ流れないか、訂正前後を追跡できるかです。本稿は、製造実績の「記録の正しさ」と「確定の責任」をRFP、PoC、FAT/SATへ落とす実務ガイドです。
実績収集システムは「見えた」だけでは完成しない
設備の稼働信号を画面へ出すデモは、比較的短期間で作れます。しかし、画面に数字が出ることと、その数字を生産実績として使えることは別です。PLCのカウンタが1増えたとしても、それが良品1個なのか、空運転なのか、再加工なのか、検査待ちなのかは信号だけでは決まりません。夜勤の回線断後に同じメッセージが再送された場合、受信件数をそのまま足せば生産数量は増えてしまいます。
生産計画、在庫、原価、納期回答へ使う数字には、少なくとも次の問いへ答えられる必要があります。
- 何が、どの工程・設備・指図・品目・ロットに対して起きたか。
- いつ現場で起き、いつシステムへ届き、いつ誰が確定したか。
- 元の記録は何で、変換規則の版はどれか。
- 同じ出来事を再送しても一度だけ計上できるか。
- 未確定、確定、ERP反映済み、取消済みを区別できるか。
- 訂正した人、理由、訂正前後の値を追えるか。
工程進捗の見える化は、この土台の上に成立します。逆に、土台がないまま画面だけを整えると、現場は結局Excelや紙と照合し、「システムの数字は参考」と扱います。実績収集システムの発注では、グラフの種類より先にイベント定義、状態遷移、重複排除、訂正権限を決めるべきです。
製造実績収集を5段階の状態で設計する
実績を一度に「登録済み」にせず、状態を分けると責任が明確になります。本稿では次の5段階を基準にします。
- Raw：PLC値、センサー値、バーコード読取、作業者入力など、取得した原記録。
- Event：原記録を業務上の出来事へ変換した状態。例は「工程10開始」「良品1個完了」「検査NG」。
- Provisional：指図、品目、ロット、作業者、単位などを紐づけた仮実績。整合性確認前。
- Confirmed：業務責任者または承認規則が確定し、訂正統制の対象になった実績。
- Posted：ERP、原価、在庫など下流へ反映し、反映IDを照合した状態。
重要なのは、Rawを消さないことです。後からロジックを直したとき、原記録が残っていれば再計算できます。Event以降だけを保存すると、なぜその数量になったかを検証できません。一方、Rawを永久保存すればよいという話でもありません。保持期間、容量、個人情報、アクセス権、時刻精度をRFPで決めます。
状態遷移には、許される方向と戻し方も必要です。Confirmedを直接上書きせず、取消イベントと訂正イベントを追加する方式にすれば、当初値と変更理由が残ります。Posted後の訂正は、MESだけを直して終わりではなく、ERP側の取消・再転記と照合します。「画面上は正しいが原価だけ旧値」という分断を防ぐためです。
Raw signalとbusiness eventを混同しない
PLCのビット、レジスタ、カウンタは装置の制御状態です。生産実績は業務上の出来事です。両者の間には変換規則が必要です。
たとえば完成信号が0から1になったときに良品1個とする設計でも、次を確認しなければなりません。
- 信号はパルスか、一定時間保持されるか。
- PLC再起動時の初期値を完成として誤認しないか。
- 金型の複数個取りでは1パルスが何個か。
- 試運転、段取り、空打ちを除外する条件は何か。
- 検査前は仮数量か、検査合格後に良品へ変えるか。
- カウンタが上限やリセットで戻ったとき差分計算をどうするか。
RFPにはタグ一覧だけでなく、イベント定義表を添付します。各行にsource、trigger、debounce、quantity rule、work order mapping、quality state、event ID rule、error handling、ownerを書きます。ベンダーが「PLCからOPC UAで収集可能」と回答しても、イベント定義表に答えられなければ業務実績は確定しません。
OPC UA PubSubは周期データとイベントデータを配送する有力な仕組みですが、通信経路と業務意味は別です。Publisherから届いたDataSetMessageを、どの指図の何の実績として扱うかはアプリケーション側の契約です。接続方式の採否と、実績確定の採否を一つの評価項目にまとめないことが重要です。
PLC・作業者入力・検査・バーコードを役割分担する
PLCは客観的な発生点を取る
PLCはサイクル開始・終了、設備状態、カウンタ、アラームなどを安定して取るのに向きます。ただし品目、指図、作業者、良否理由を常に知っているとは限りません。PLCへ業務マスタを詰め込み過ぎると、品目追加や工程変更のたびに制御改修が必要になります。
推奨は、PLCがsource eventを発生し、edge/MES側が有効期間のある指図割当と結合する構成です。結合に失敗したイベントは捨てず、「指図未割当」例外キューへ送ります。後から担当者が正しい指図を割り当てても、原イベントIDと原時刻は変えません。
作業者入力は意味と例外を補う
段取り完了、停止理由、再加工理由、廃棄理由のように機械だけでは判断できない情報は、人が入力します。入力画面は自由記述を増やすより、品目・工程に応じた選択肢、必須条件、権限を変える方が集計しやすくなります。
タイ工場では、日本語マスタをそのまま現場へ出さず、コードを正本にしてタイ語・英語・日本語の表示名を管理します。翻訳語が変わっても理由コードは同一です。選択時刻と送信時刻も分け、端末がオフラインならローカルキューに保持します。共有アカウントでは訂正責任を追えないため、個人IDまたは承認済みの班運用と職務分離を決めます。
検査結果は品質判定と生産数量を切り分ける
設備完了時に総生産を仮計上し、検査後に良品・不良・保留へ振り分ける方法があります。あるいは全数検査工程の合格を良品イベントにする方法もあります。どちらが正しいかは工程で異なります。
重要なのは、「完了数量」「検査済み数量」「良品」「不良」「保留」「再加工」を一つのカウンタに上書きしないことです。数量間の整合式を定義し、未検査が残る条件、抜取検査時の扱い、再検査の版、品質承認者を決めます。結果訂正は監査証跡を残し、ERP在庫や品質ロットへ反映済みなら下流訂正も一つのワークフローにします。
バーコードは対象を特定する
バーコードや2Dコードは、指図、品目、ロット、容器、シリアル、作業者を特定するのに有効です。ただし読み取れたコードが有効とは限りません。工程順序、使用期限、既使用、重複、品目一致、設備適合を検証します。
スキャン結果にも一意なscan event IDを付け、同じラベルを連続で読んだときに「操作ミスの重複」か「正しい2回処理」かを業務規則で判断します。単純な数秒debounceだけでは、ライン速度や再作業で誤判定します。
MESとERPの境界は確定責任で決める
ISA-95は、設備・制御と製造オペレーション管理、企業業務の層を整理するための共通言語になります。ただし「すべての工場は同じ製品構成にせよ」という指示ではありません。実際の境界は、どのシステムがどのデータの正本で、どこが確定権限を持つかで決めます。
一般的には次の分担が考えられます。
| 情報 | 主な正本候補 | 実績収集側の役割 |
|---|---|---|
| 品目、BOM、工程、指図 | ERPまたは承認済み生産管理 | 版と有効期間を受け、勝手に別マスタを作らない |
| 設備、タグ、edge設定 | OT管理またはMES | sourceと変換規則を版管理する |
| raw/event/provisional | edge/MES | 原記録、一意ID、状態、例外を保持する |
| confirmed execution | MESまたは生産管理 | 権限と承認規則により確定する |
| 在庫・会計転記 | ERP | posting IDと結果を返す |
SAPのProduction Order Confirmation APIを例にすると、確認には開始・終了日時、yield、scrap、rework、variance reason、final confirmation等が含まれます。これは一つの製品例であり全ERPの共通仕様ではありませんが、生産実績が「数量だけ」では不足することを示します。
RFPでは、ERP送信の起点をConfirmedにするか、班長承認後にするか、バッチ締めにするかを決めます。ERPが一時停止したとき、MES側のPostedを先に立ててはいけません。送信要求ID、ERP応答ID、結果コードを保存し、成功応答を照合して初めてPostedへ遷移させます。
MES比較の4つの評価軸と併せて読むと、製品機能表では見えにくいデータ責任を評価できます。個別開発を含める場合は、タイ製造業のシステム開発委託RFPガイドの成果物・契約・受入観点も参照してください。
event_time・received_at・confirmed_atを分ける
実績収集で時刻を一つしか持たないと、遅延、後入力、回線断、承認待ちを説明できません。最低でも次の三つを分けます。
- event_time：現場で出来事が発生した時刻。
- received_at：edge、broker、MES等が記録を受信した時刻。
- confirmed_at：業務上の実績として確定した時刻。
GS1 EPCISも、実世界イベントのeventTimeと、リポジトリへ記録したrecordTimeを区別します。EPCISを採用しない工場でも、この分離は有用です。タイムゾーンoffset、時刻源、clock statusも保存すれば、タイ・日本・ベトナム拠点を横断する際の誤解を減らせます。
PLC、edge、サーバーの時計がずれている場合、received_atよりevent_timeが未来になることがあります。単純に拒否する前に、許容clock skew、時刻同期方式、同期喪失フラグ、補正可否を決めます。補正した場合も原時刻を消さず、corrected_event_timeと補正理由を別に持ちます。
工程進捗の見える化では、どの時刻で集計するかを画面へ明示します。現場発生基準ならevent_time、監視遅延ならreceived_at、締め実績ならconfirmed_atを使います。三つを混ぜたグラフは一見リアルタイムでも、締め後に数値が大きく変わるため信頼を失います。
再送・重複排除・順序逆転を業務IDで処理する
MQTT 5.0ではQoS 1はat least onceで、重複が起こり得ます。DUPフラグもアプリケーションメッセージ自体の一意性を保証するものではありません。QoS 2は配送上のexactly onceを提供しますが、受信後のアプリ処理、DB再試行、ERP API再送まで自動的に一度だけにするわけではありません。
そのため、実績イベントには長期間再利用しないsource_event_idを付けます。例はsite-line-plcBootId-sequence、UUID、装置が持つ単調増加sequenceとboot IDの組合せです。受信側はIDをunique keyとして受理し、同一ID・同一payloadの再送は重複として記録して計上しません。同一ID・異なるpayloadは上書きせず、重大例外にします。
idempotencyは各境界で必要です。
- device→edge：source_event_idで重複受理を防ぐ。
- edge→MES：送信attempt IDとsource_event_idを保持する。
- MES内部：状態遷移にexpected versionを使い、二重確定を防ぐ。
- MES→ERP：posting request IDを固定し、timeout後も同じIDで照会・再送する。
- ERP応答：ERP document IDを保存して照合する。
順序逆転も想定します。「工程終了」が「工程開始」より先に届く、検査結果が生産完了より先に届くことがあります。一定時間のreorder windowで待つ、前提イベントがなければ保留する、時間切れで例外へ送るという規則を決めます。到着順にDBへinsertできたことを、工程順序が正しい証拠にしてはいけません。
オフライン復旧はbuffer容量より復旧手順が重要
タイの工場では、工場LAN、Wi-Fi、拠点間VPN、クラウド接続、停電、edge更新など複数の断点があります。「インターネットが切れても動く」だけでは要件として不足です。どこで何時間保持し、どの順で再送し、満杯時に何を捨てず、誰へ通知するかを書きます。
AWS IoT Greengrass Stream Managerは、断続接続でのストリーム、ファイルシステム永続化、保持、優先度等を構成できる実装例です。製品は他にもありますが、必要な設計要素は共通です。
- edge再起動後も未送信イベントを復元できる永続queue。
- sequence、checksum、source_event_idを含むappend-only journal。
- 重要イベントを優先し、診断データと生産実績を同じ優先度にしない。
- buffer残量、最古未送信時刻、再送率、dead-letter件数の監視。
- 回線復旧時の帯域制御と、現行データを詰まらせないbacklog drain。
- 満杯、破損、時計喪失、証明書期限切れ時のsafe state。
- ローカル保存データの暗号化、鍵、権限、保守端末の統制。
回線断中も作業者へ「送信済み」と表示すると誤解を招きます。端末上でlocal saved、sent、received、confirmedを区別し、処理中の二重入力を防ぎます。復旧後は「全部送れた」だけでなく、欠番、重複、ERP反映件数までreconciliation reportで確認します。
実績収集システムのRFPに入れるデータ契約
RFPでは画面一覧や設備台数に加え、イベント1件の契約をサンプルJSONや表で提示します。最低限、次の項目を要求します。
| 分類 | 要求項目 |
|---|---|
| Identity | source_event_id、site、line、equipment、event_type、schema_version |
| Business context | work_order、operation、item、lot/serial、shift、operator/role |
| Value | quantity、unit、quality_state、reason_code、raw reference |
| Time | event_time、timezone offset、received_at、confirmed_at、clock status |
| State | raw/event/provisional/confirmed/posted/cancelled、state version |
| Audit | created by、confirmed by、changed by、reason、before/after、rule version |
| Delivery | sequence、attempt、checksum、posting request ID、target response ID |
schema versionの互換性も確認します。新しいfieldを追加したとき旧edgeは動くか、必須fieldを変えたときどう停止するか、段階展開中に2版が混在しても受理できるかを決めます。タグ名を直接payload keyに使うとPLC変更が上位へ波及するため、source mappingとcanonical event schemaを分けます。
セキュリティ要件は一般的な「暗号化する」だけでなく、device identity、certificate rotation、least privilege、port/route、remote maintenance、log access、backup restore、脆弱性対応、退職者権限剥奪を具体化します。OTからITへの一方向通信が必要な工程、ERPから指図を戻す双方向区間もnetwork diagramで示します。
30・60・90日PoCで「正しさ」を検証する
30/60/90日は本稿の推奨フレームであり、業界標準期間ではありません。設備停止を伴う場合や規制工程では長くなります。大切なのは、成功条件をデモ後に決めないことです。
30日：定義を固定する
1工程を選び、event definition、source mapping、ID、時刻、状態遷移、例外、責任者を合意します。通常生産だけでなく、段取り、試運転、再加工、品質保留、PLC再起動、指図変更のsampleを集めます。PoC開始前のmanual truth setを用意し、何を正解とするかを承認します。
60日：障害証拠を作る
正常系の画面だけでなく、回線断、edge再起動、同一イベント再送、順序逆転、ERP timeout、時刻ずれ、master不一致を注入します。例として10,000件、回線断2時間、同一イベント3回再送、時刻ずれ±5分を使えますが、これは一般推奨値ではありません。実際のpeak、buffer、SLAへ置換します。
評価指標は、収集完全率、二重計上件数、未照合件数、確定リードタイム、例外処理時間、復旧時間、監査証跡欠落件数です。平均だけでなく、最大値と失敗caseを見ます。
90日：運用受入を決める
実運用者がタイ語UIで例外を処理し、班長が確定し、IT/OT担当がalertから原因へ到達し、ERP担当が取消・再転記できるかを確認します。運用手順、access matrix、backup/restore、証明書更新、support escalation、known limitationsまで成果物として受領し、scale、revise、stopを判断します。
FAT/SAT受入基準は正常・障害・復旧を一組にする
FATではベンダー環境でevent schema、重複排除、状態遷移、権限、監査、interface simulatorを確認します。SATでは実工場のPLC、network、shift、operator、ERP/MESで同じ証拠を再現します。
受入項目には次を含めます。
- 正常：開始、完了、良品、不良、停止、再開、指図切替。
- 境界：最小/最大数量、日跨ぎ、shift跨ぎ、lot切替、カウンタreset。
- 障害：LAN/VPN断、broker停止、DB停止、edge再起動、PLC再起動、ERP timeout。
- 再送：ack喪失、同一ID再送、同一内容の別ID、同一IDの異内容。
- 時刻：clock skew、timezone、夏時間を持つ他拠点、同期喪失。
- 権限：未承認者の確定、確定後上書き、共有ID、退職者ID。
- 復旧：backlog drain、欠番照合、dead-letter再処理、ERP再転記。
- 負荷：peak時の遅延、queue増加、disk満杯、監視alert。
各test caseにはprecondition、input、expected event/state、evidence、actual、tester、date、defect IDを持たせます。「合格」とだけ書いたスクリーンショットは再現性がありません。event IDをたどり、raw、MES、ERPの対応関係を一件ずつ証明できるログを受入証拠にします。
TCOはライセンスより例外と変更を含める
実績収集システムのTCOは、初期開発費と月額ライセンスだけでは比較できません。次の式で見積項目を揃えます。
月間TCO = 月額ライセンス + edge/通信 + cloud/DB + 保守 + 例外処理工数 + 改修償却 + 教育・監査
金額や削減率は工場条件で変わるため、出典のない相場を置かず、各社へ同じ前提で回答させます。設備追加1台、tag追加10点、event type追加1種、ERP field変更、品目マスタ追加は標準保守か有償か。夜勤の一次対応、現地訪問、タイ語support、予備edge、certificate更新、OS patch、backup restore試験も確認します。
例外処理工数は見落とされがちです。自動収集率が高くても、指図未割当やclock errorが毎日大量に出れば現場負担は増えます。KPIは自動化率だけでなく、未解決例外の件数と滞留時間、再発率、manual correction比率、原因別topを見ます。
よくある失敗と修正策
- PLCカウンタをそのまま良品にする：raw counterとquality-confirmed quantityを分ける。
- 到着時刻だけ保存する：event、received、confirmedの三時刻とtimezoneを持つ。
- MQTT QoSで二重計上も解決したと考える：source_event_idと境界ごとのidempotencyを設計する。
- 回線断試験をpingで終える：buffer、再送、順序、欠番、ERP照合まで試験する。
- 確定後を上書きする：cancel/correction eventで履歴を残す。
- MESとERPの両方が正本になる：data ownerとstate transition ownerを項目別に決める。
- PoCを1設備のデモで終える：失敗注入、夜勤、多言語、運用引継ぎを含める。
- TCOに例外処理を入れない：manual work、support、certificate、更新、復旧を積む。
FAQ：製造実績収集と生産実績管理
実績収集システムとは何ですか？
PLC、作業者端末、検査、バーコードなどの原記録を、指図・工程・品目・lotへ結び、生産実績として仮登録、確定、ERP反映、訂正まで管理する仕組みです。単なるデータロガーやダッシュボードとは、業務event、状態、権限、監査を持つ点が異なります。
製造実績の収集はPLCだけで自動化できますか？
サイクルや設備状態はPLCに向きますが、停止理由、再加工、品質保留、指図例外など人や上位システムの情報が必要です。客観的発生点はPLC、意味と例外は作業者・MES・検査から補い、確定規則で統合します。
生産実績管理でevent timeと確定時刻を分ける理由は？
回線断、後入力、承認待ちがあると、発生時刻と記録・確定時刻は一致しません。分けなければ工程progress、shift締め、監査、遅延原因を説明できません。
工程進捗を見える化するだけなら重複排除は不要ですか？
必要です。再送を二重に数えると進捗率が100%を超え、遅延判断や完了予測を誤ります。表示用途でもsource_event_idによる一意性が必要です。
MQTT QoS 2ならexactly onceになりますか？
通信配送上の保証は強くなりますが、受信後のDB commit、サービス再試行、ERP postingまで自動的に一度だけにはなりません。アプリケーションevent IDとidempotent processingを別に実装します。
PoCとFAT/SATはどう分けますか？
PoCはevent definitionと方式の成立性を小範囲で検証し、FATはベンダー環境で機能・障害・証拠を確認、SATは実工場のnetwork、PLC、shift、ERP、operatorで再現します。各段階で合格証拠を変えます。
既存MESがあっても実績収集を見直す価値はありますか？
あります。既存MESの画面を変えず、edge/event contract、ID、時刻、例外、ERP照合を強化できる場合があります。最初に現行ログで欠落・重複・後入力・訂正を分類し、必要部分だけ改修します。
まとめ：正しい実績とは、経路を説明できる記録
実績収集システムの価値は、すべてを自動で取ることではありません。raw signalからbusiness event、仮実績、確定、ERP反映までを一意なIDでつなぎ、回線断や再送が起きても、なぜこの数量になったかを説明できることです。PLC、作業者、検査、MES、ERPの責任を分け、三つの時刻、訂正履歴、復旧照合をRFPと受入試験へ入れてください。
TOMAS TECHは、タイ工場の1工程を対象に、event definition、PLC/作業者/検査の境界、RFP、30/60/90日PoC、FAT/SAT受入表を整理できます。製品選定前の要件棚卸し段階でも、お問い合わせページからご相談いただけます。
