生産設備トレーサビリティは、製品の移動履歴だけでなく、そのロットを「どの設備・治工具・PLC/HMI・レシピ版数・保全／校正状態で作ったか」まで遡れる仕組みです。本稿では、異常時の影響範囲を速く絞るためのデータモデル、RFP、90日PoC、FAT/SAT、4M変更管理、OTバックアップを実務レベルで解説します。
この記事で得られること
- 製造ロットと設備履歴を結ぶ最小データモデル
- 設備台帳、治工具台帳、ソフトウェア／レシピ版数の持ち方
- RFPに書くべき機能・非機能・受入条件
- 90日PoCを「デモ」で終わらせず、本番可否を判断する方法
- FAT/SAT、保全、校正、4M変更、OTバックアップを一つの運用にする方法
本稿に出てくる保存年数、応答時間、取得率、目標値は、特記しない限り法令や規格の必須値ではなく、プロジェクトで合意するための推奨設計値または例示です。顧客固有要求、契約、認証、現地法令を確認したうえで決定してください。
生産設備トレーサビリティが必要になる瞬間
設備起因の異常が見つかったとき、多くの工場で最初に起こるのは「対象ロットが分からない」という問題です。紙の保全記録には設備名がある、MESには製造ロットがある、PLCバックアップは保全PCにある、校正証明書は共有フォルダーにある。しかし、同じ時刻軸と識別子で結ばれていません。そのため、設備Aのセンサー交換前後に作られたロット、治具J-104の寿命超過中に加工されたワーク、旧レシピで処理された品目を横断検索できません。
設備履歴と製造ロットを結ぶ目的は、データを大量に集めることではありません。次の問いに、証拠を伴って答えることです。
- 影響を受けた可能性がある製造単位はどれか。
- その判定に使った設備・設定・時刻・状態の証拠は何か。
- 同じ条件で生産された別ロットはあるか。
- 是正後、同じ異常が再発していないことをどう確認するか。
従来の製品トレーサビリティが「材料がどの製品に入ったか」を中心に見るのに対し、本稿の対象は「製品がどの生産能力と構成状態を通過したか」です。両方を統合すると、材料ロット、製造条件、品質結果を一つの調査線上に並べられます。
製品追跡と「設備履歴×製造ロット」の違い
| 観点 | 製品中心の追跡 | 設備履歴×製造ロット |
|---|---|---|
| 主な識別子 | 材料ロット、製品シリアル、出荷番号 | 設備ID、治工具ID、構成版数、作業実績ID |
| 主な問い | どの材料がどの製品に入ったか | どの設備状態でどのロットを作ったか |
| 重要イベント | 入荷、投入、完成、出荷 | 段取り、開始、完了、レシピ適用、保全、校正、変更 |
| 異常調査 | 材料起点の前方／後方追跡 | 設備・版数・時間窓起点の影響範囲抽出 |
| 主なデータ源 | ERP、WMS、MES | MES、PLC、HMI、SCADA、保全、校正、版管理 |
| 典型的な落とし穴 | ロット分割・統合の欠落 | 設備名揺れ、時計ずれ、上書き、版数未取得 |
この二つは競合しません。GS1のEPCIS 2.0は、組織間・システム間で可視化イベントを共有するための標準で、対象、時刻、場所、業務文脈などをイベントとして表現します。EPCISをそのまま全PLCタグの保存形式にする必要はありませんが、「何が、いつ、どこで、どの業務ステップにあったか」というイベント思考は、製造ロットと設備状態を結ぶ設計に有効です。
まず設備台帳を「検索可能な正本」にする
設備IDは表示名と分ける
設備名は人のため、設備IDはシステム連携のために使います。「プレス1号」「PR-01」「Press No.1」が同じ設備を指す状態では、履歴の結合が不安定です。表示名が変わっても変化しない設備IDを一つ決め、MES、保全、校正、PLC接続設定で共通利用します。
推奨する識別階層の例は次のとおりです。
- サイトID：国・工場を区別する不変コード
- エリア／ラインID：生産組織や物理区画を表すコード
- 設備ID：機能単位の不変コード
- モジュールID：主軸、ポンプ、検査ヘッドなど交換可能な構成要素
- 治工具ID：金型、治具、ゲージ、締付軸など個体管理対象
- データソースID：PLC、HMI、ロボット、計測器、ゲートウェイ
「設備を移設したらIDを変えるか」はRFP前に決めます。原則として個体を追うならIDを維持し、設置場所を有効期間付き属性として変更します。機能位置を追うなら、機能位置IDと設備個体IDを分けます。この分離がないと、移設後に過去履歴の意味が変わります。
設備台帳に必要な属性
| 属性群 | 代表項目 | 設計上の注意 |
|---|---|---|
| 識別 | 設備ID、表示名、機能位置ID、メーカー、型式、製造番号 | 設備IDは再利用しない |
| 配置 | サイト、建屋、ライン、工程、有効開始／終了 | 現在値だけでなく履歴を保持 |
| 制御構成 | PLC型式、CPU、HMI、ロボット、ネットワーク位置 | IPアドレスを主キーにしない |
| ソフトウェア | PLCプロジェクト版、HMI版、ロボットプログラム版 | ハッシュ値または承認版IDを持つ |
| レシピ | レシピID、版数、承認状態、適用品目 | 名称だけでなく版数を固定 |
| 保全 | 状態、最終保全、次回予定、作業指示ID | 「実施済み」だけでなく結果を保持 |
| 校正 | 校正対象、結果、有効期限、証明書ID | 期限切れ時の生産可否ルールを定義 |
| セキュリティ | 資産所有者、ゾーン、バックアップ対象、重要度 | 認証情報そのものは台帳に保存しない |
ISO 55001:2024は、組織が資産から価値を実現するための資産マネジメントシステム要求事項を示します。また、ISO 55013:2024は、資産マネジメントを支えるデータ資産の管理に関するガイダンスです。これらは特定のDB製品や保持期間を指定するものではありません。本プロジェクトでは、目的、責任、データ品質、変更、評価を設備台帳の運用設計へ落とし込むための原則として参照します。
製造ロットへ何を紐付けるか：最小データモデル
重要なのは「現在の設備状態」を見ることではなく、「そのロットを処理した時点の状態」を再現できることです。現在値を上書きするマスタだけでは不十分です。イベントまたは有効期間付き履歴として保存します。
推奨する中核エンティティ
| エンティティ | 主キー例 | 必須の関係 |
|---|---|---|
| ProductionLot | lot_id | 品目、数量、開始／終了、親子ロット |
| OperationExecution | execution_id | lot_id、工程、設備ID、開始／終了、結果 |
| EquipmentAsset | equipment_id | 機能位置、設備型式、構成状態 |
| ToolUsage | tool_usage_id | execution_id、治工具ID、取付時刻、取外時刻、使用回数 |
| ControlConfiguration | config_id | PLC/HMI/ロボットの承認版、ハッシュ、適用期間 |
| RecipeApplication | recipe_event_id | execution_id、レシピID、版数、設定者、適用時刻 |
| MaintenanceEvent | maintenance_id | equipment_id、作業種別、結果、交換部品、有効時刻 |
| CalibrationEvent | calibration_id | 資産ID、基準、結果、証明書、合否、有効期限 |
| QualityResult | result_id | execution_id、測定項目、値、単位、判定、計測器ID |
| ChangeRecord | change_id | 4M区分、対象ID、変更前後、承認、検証、発効時刻 |
OperationExecutionを中心に置くと、ロットが複数設備を通る場合も、設備が同時に複数ロットを処理する場合も表現できます。バッチ炉のように複数ロットを同時処理する場合は、炉バッチIDを別に設け、各製造ロットとの多対多関係を記録します。連続プロセスでは、単純な開始・終了だけでなく、材料投入量や時間窓を使った寄与関係が必要です。
「適用版数」は値ではなく証拠として保存する
PLCやHMIのファイル名だけでは、実際に稼働していた版を証明しにくい場合があります。最低限、次を組み合わせます。
- 承認された版ID
- ソースまたはバイナリのハッシュ値
- 設備へ適用した日時と実施者
- FAT/SATまたは変更後確認の記録ID
- ロールバック対象版
- 取得方法と取得元デバイスID
レシピも同様です。ロット実績に「Recipe-A」とだけ残すのではなく、Recipe-A / Revision 12 / checksum / applied_atを記録します。オペレーターが一時変更できる設定値は、承認レシピとの差分も残します。上書き可能なCSVは便利ですが、監査証跡にはなりません。
ISA-95で境界を整理する
ISA-95は企業システムと製造オペレーション／制御の統合を扱う標準群です。ISAの公開ページではANSI/ISA-95.00.01-2025を含むシリーズが案内されています。本稿では規格本文を複製せず、ERP、MES、現場制御の責任境界を整理する概念として使います。
実装では、ERPが品目・受注・計画の正本、MESが作業実績とロット関係の正本、保全システムが保全作業の正本、OTデータ基盤が時系列信号の正本、といった役割を定義します。「全データをMESに入れる」のではなく、照会時に正本へ到達できる参照IDを共有します。
OPC UAとAASは意味をそろえる候補
OPC UA for Asset Administration Shell（AAS）は、AASメタモデルをOPC UA情報モデルに表現するためのマッピングを定めています。複数メーカー設備から資産属性を収集するとき、タグ名の個別対応だけでなく、識別子、型、意味をそろえる手掛かりになります。ただし、既設PLCをすべてAAS対応へ改造することが導入条件ではありません。ゲートウェイや上位層で正規化する段階導入も現実的です。
イベント設計：ロットと設備状態を時刻だけで結ばない
時刻範囲だけでJOINすると、時計ずれ、再実行、停止、並列処理で誤結合が起きます。最優先は、MESが払い出したexecution_idを設備側へ渡し、設備イベントが同じIDを返すことです。できない設備では、ライン、工程、設備、品目、開始／完了イベント、時間窓を組み合わせ、結合の確信度を持たせます。
推奨イベントは次のとおりです。
| イベント | 必須項目例 | 目的 |
|---|---|---|
| SetupStarted/Completed | execution_id、設備ID、治工具ID、予定レシピ版 | 段取り状態を確定 |
| ProductionStarted | lot_id、execution_id、設備ID、時刻 | ロット処理の開始点 |
| ConfigurationApplied | config_id、レシピ版、差分、実施者 | 稼働構成を証明 |
| Unit/BatchCompleted | 数量、良否、終了時刻 | 実績と品質結果を結合 |
| AlarmRaised/Cleared | アラームコード、重要度、開始／終了 | 異常時間窓を抽出 |
| ToolMounted/Removed | 治工具ID、カウンター、状態 | 治工具使用履歴を確定 |
| MaintenanceReleased | 作業指示ID、確認者、復帰条件 | 保全後の生産可否を制御 |
| CalibrationStatusChanged | 対象ID、旧／新状態、有効時刻 | 校正状態の影響範囲を抽出 |
全イベントには、イベント発生時刻とサーバー受信時刻を分けて持つことを推奨します。時計同期状態も監視し、許容差を超えたデータには品質フラグを付けます。「許容差500ミリ秒」などの値は設備能力と追跡単位に応じて決める推奨例で、一般的な規格必須値ではありません。
影響範囲を絞る検索を先に定義する
システム要件は画面一覧からではなく、異常シナリオから作ります。少なくとも次の検索をPoCで実行します。
- 指定設備のアラーム発生中に処理されたロットを抽出する。
- 指定したPLC/HMI版数が適用されていた全製造実績を抽出する。
- 校正期限切れの計測器で判定された製品を抽出する。
- 指定治工具の寿命カウンター超過後に作られたロットを抽出する。
- 保全部品交換前後で品質傾向が変化したか比較する。
- 4M変更の発効後、最初のNロットの検証結果を表示する。
- 対象ロットから、その時点の設備構成・レシピ・保全状態・品質結果を一括表示する。
たとえば「温度センサーが8月15日14:20から17:10までドリフトしていた可能性がある」という事象では、時間が重なったロットを候補として抽出し、工程開始・終了、実測信号、別計測器、停止時間、再加工を使って対象を絞ります。結果には、確定対象、可能性対象、対象外と判断根拠を付けます。単にCSVを出すだけでは、意思決定が属人化します。
設備履歴管理と保全記録電子化を一体化する
保全記録をPDF化しただけでは、設備履歴管理に必要な検索性は得られません。作業指示ID、設備ID、故障モード、作業開始・終了、交換部品、測定値、確認者、生産復帰判定を構造化します。写真や報告書は添付証拠として残し、検索に必要な項目はデータとして持ちます。
設備保全の予兆監視事例で扱う状態監視と組み合わせる場合も、予測スコアだけで判断しません。予測モデル版、入力センサー、欠測率、アラート閾値、確認結果を設備イベントへ結びます。これにより「どのモデルの判断で、どの作業を行い、その後の品質がどう変化したか」を追えます。
品質保証記録システムとの接続では、品質結果側にexecution_id、設備ID、計測器IDを持たせます。ロット合否だけを連携すると、同一ロット内のどの設備・キャビティ・測定系に偏りがあったか分析できません。
設備変更の4M管理：変更点を「発効時刻」で結ぶ
設備変更 4M 管理では、変更申請書を保存するだけでなく、変更対象と製造実績を結びます。人、機械、材料、方法の分類に加え、少なくとも以下を記録します。
- 変更対象の設備ID、治工具ID、プログラムID、レシピID
- 変更前／変更後の値または版数
- リスク評価と承認者
- FAT、SAT、初品、能力確認などの検証記録
- 予定発効時刻と実発効時刻
- 影響する品目、工程、顧客
- ロールバック条件と戻し先版
- 発効後に監視する品質指標と期間
特に「実発効時刻」が重要です。承認日は8月1日でも、実際にPLCへ適用したのが8月3日22:15なら、ロット結合には後者を使います。夜勤中の一時的なパラメータ変更、復旧のための旧版適用もイベントとして残します。
RFPに書くべき要件
RFPでは「トレーサビリティができること」だけでは評価できません。対象範囲、識別子、検索シナリオ、性能、欠測時の挙動、受入証拠を明記します。
機能要件
- 設備・機能位置・治工具・制御資産を一意に管理できること
- 製造ロットと作業実績、設備、治工具、構成版数、レシピ版数を結合できること
- 保全・校正・アラーム・4M変更を有効時刻付きで保持できること
- ロット起点と設備起点の双方向追跡ができること
- ロット分割、統合、再加工、代替設備、手動運転を扱えること
- 証拠データを改ざん検知可能な形で保持し、変更履歴を表示できること
- CSV/API出力時も検索条件、抽出時刻、版数、タイムゾーンを残せること
非機能要件
- OT停止時にも生産継続方針とバッファリング方針があること
- 通信復旧後に重複を作らず再送できること
- 権限を職務別に分け、重要操作を監査できること
- 時刻同期の状態とデータ品質を監視できること
- バックアップ、復元試験、災害復旧の責任分界があること
- 保存期間、アーカイブ、削除保留、訴訟／監査保全に対応できること
- タイ語・英語・日本語などの表示と、識別子の言語非依存性を両立できること
RFPに入れる推奨設計値の例
| 指標 | 例示する受入目標 | 注意 |
|---|---|---|
| 必須イベント取得率 | 対象期間で99.5%以上 | 法令値ではなく例。計画停止と除外条件を定義 |
| ロット照会応答 | 95パーセンタイル5秒以内 | 対象データ量と検索条件を固定して測定 |
| 再送の重複 | 同一event_idの論理重複0件 | 物理再送と論理重複を区別 |
| 時計ずれ検知 | 設定閾値超過を5分以内に通知 | 閾値は工程の時間粒度で決める |
| 復元試験 | 四半期ごと等、合意した頻度 | 規格必須頻度と断定しない |
| 監査証跡 | 管理対象変更の100% | 管理対象操作の範囲を定義 |
ベンダーには「標準機能／設定／追加開発／外部製品」の区分で回答させます。ライセンス費だけでなく、設備追加、タグ変更、版更新、データ量増加、長期保管、復元支援の費用も5年TCOとして比較します。
90日PoC：本番判断まで行う実行計画
PoCの目的は見栄えの良い画面を作ることではなく、対象設備でデータが取れ、意味がそろい、異常調査に使え、運用できるかを判断することです。以下の期間は推奨例です。
1〜15日：シナリオと識別子を固定
- 対象ライン1本、代表設備2〜4台、代表品目2〜3種を選ぶ
- 過去に調査が難しかった異常を3件以上選ぶ
- 設備ID、治工具ID、作業実績ID、レシピ版数の規則を合意する
- データ所有者、OT接続承認、セキュリティ責任を決める
- 成功条件と中止条件を承認する
16〜35日：接続と最小モデルを実装
- PLC/HMI/MES/保全から必要項目だけを収集する
- event_id、発生時刻、受信時刻、品質フラグを実装する
- ネットワーク断と再送を試す
- ロット分割、段取り、手動運転など例外を記録する
36〜60日：検索シナリオを検証
- 設備アラームから影響ロットを抽出する
- 旧レシピ版、期限切れ校正、治工具寿命超過を模擬する
- 現場担当者が根拠を説明できるか確認する
- 紙／Excel時の調査時間と比較する
61〜75日：運用・セキュリティ・復旧を試験
- 権限、監査ログ、アカウント停止を確認する
- バックアップを取得し、隔離環境へ復元する
- 版変更、設備交換、タグ追加の手順を実施する
- 欠測、時計ずれ、重複、誤った設備IDを検知させる
76〜90日：本番判定と展開設計
- KPI結果、未解決リスク、追加開発を整理する
- ライン展開のテンプレートと教育計画を作る
- 本番SLA、保守分界、データ保持、費用を確定する
- Go、条件付きGo、再PoC、No-Goを判定する
PoC終了時には、機能一覧ではなく「異常シナリオ別の証拠」「データ欠損一覧」「運用作業時間」「復元結果」「5年TCO」を意思決定資料にします。
FAT/SATで確認する受入条件
FAT（工場出荷前試験）では、模擬データと標準構成でロジック、性能、例外処理を確認します。SAT（現地受入試験）では、実設備・実ネットワーク・実運用者で再現性を確認します。FAT合格をSAT免除の理由にしません。
| 試験 | FATの主な確認 | SATの主な確認 | 証拠 |
|---|---|---|---|
| 識別子 | 重複・不正形式を拒否 | 実設備ラベルとの一致 | 台帳、画面、API応答 |
| ロット結合 | 正常・分割・統合データ | 実MESと設備イベントの一致 | 検索結果、原データ |
| 版数 | 模擬版変更とロールバック | PLC/HMI/レシピ実版との一致 | ハッシュ、変更記録 |
| 通信断 | バッファ、再送、重複排除 | 実ネットワーク断で復旧 | event_id比較、欠測一覧 |
| 時刻 | ずれデータの警告 | NTP/PTP状態とタイムゾーン | 監視ログ、イベント時刻 |
| 権限 | 役割別許可／拒否 | 実アカウントと退職者停止 | 監査ログ |
| 性能 | 合意データ量で負荷試験 | 現地回線を含む照会 | 測定条件、P95/P99 |
| 復元 | バックアップから構築 | 現地手順で業務復旧 | 復元ログ、照合結果 |
SATでは、現場が実際に困った異常を再現します。システム担当者だけでなく、製造、品質、保全、OTセキュリティが同じ結果を確認し、誰がどの判定をするかまで合意します。
OTセキュリティとバックアップを後付けにしない
NIST SP 800-82 Rev. 3は、性能、信頼性、安全性といったOT固有の要件を考慮したセキュリティ指針です。生産設備トレーサビリティでは、可視化のためにOTから上位へ接続を増やすため、資産把握、ネットワーク分離、最小権限、監視、インシデント対応を設計段階から扱います。読み取り専用接続でも、ゲートウェイ、証明書、サービスアカウント、遠隔保守経路は管理対象です。
2026年6月17日付として案内されたNIST SP 1339「OT Backup Quick Start Guide」は、OTバックアップを信頼性／サイバー事象からの復旧に不可欠と位置づけ、変更管理への統合、定期取得、テスト、復旧演習でのレビューを重視しています。バックアップは「ファイルがある」だけでは不十分です。
バックアップ対象の例は次のとおりです。
- PLC、HMI、ロボット、モーション、ビジョンのプログラム
- レシピ、パラメータ、校正係数
- ネットワーク機器、ゲートウェイ、OPC UA設定
- MES連携マッピング、設備台帳、データモデル
- 証明書、鍵の復旧手順、ライセンス情報
- ヒストリアン／イベントDBの設定と重要データ
- 復元に必要なエンジニアリングツール、対応OS、手順書
変更承認の完了条件に「バックアップ取得」「ハッシュ確認」「復元対象版の指定」を含めます。また、オフラインまたは論理的に分離したコピー、アクセス制御、暗号化、保管場所、保持世代をリスクに応じて決めます。月次、四半期、3世代などの頻度・数は例であり、NISTが一律に義務づける値として扱いません。
IATF 16949改訂情報の扱い
自動車サプライチェーンでは顧客固有要求と品質マネジメント要求の確認が欠かせません。IATFの2026年7月30日Stakeholder Communiquéは、IATF 16949第2版への改訂状況を知らせるものです。本稿公開時点では、このコミュニケを根拠に「第2版がすでに発行済み」「移行期限が確定済み」とは断定しません。正式出版物、IATF Global Oversight、認証機関、顧客固有要求の最新版をプロジェクト判断直前に確認してください。
トレーサビリティ設計も「IATFだから○年保存」と単純化せず、契約、製品安全、保証期間、法令、顧客要求、調査実務から保持期間を決めます。規格番号をRFPに書くだけでは、データ粒度や復元性は決まりません。
タイ工場での実装ポイント
タイの工場では、日本本社仕様、現地運用、グローバル顧客要求、複数メーカー設備が重なることがあります。画面だけを多言語化しても運用は定着しません。
- 不変ID、イベントコード、単位は言語非依存にする
- 表示名、説明、作業手順はタイ語・英語等を併記する
- 日時はUTCで保存し、表示時にICTなどのタイムゾーンを明示する
- タイ暦／西暦の誤解を避け、APIはISO 8601形式に統一する
- 現場変更を本社承認待ちで止めない責任分界を作る
- 夜勤、派遣、設備メーカー保守のアカウント運用を定義する
- 海外クラウドへのデータ送信、契約、顧客機密を確認する
教育では、システムの操作より「IDを勝手に作らない」「一時変更も記録する」「通信断時の手書き記録を後でどう確定するか」を重視します。KPIは入力件数ではなく、異常調査の対象絞り込み時間、未結合イベント率、期限切れ校正の検知、復元試験結果など、業務成果へ結びます。
導入費用を左右する要素
費用はソフトウェアライセンスより、既設設備の接続性とデータ整備に左右されることがあります。見積比較では次を分けます。
| 費用区分 | 主な内容 | 増加要因 |
|---|---|---|
| 調査・設計 | 設備棚卸し、シナリオ、ID、モデル、セキュリティ | 台帳不備、部門間ルール未決 |
| OT接続 | PLC/HMI/ゲートウェイ、ネットワーク、時刻同期 | 旧型機、閉鎖プロトコル、多メーカー |
| アプリ | 台帳、イベント、検索、ワークフロー、API | 例外工程、個別帳票、顧客別要件 |
| データ | 保存、バックアップ、アーカイブ、分析 | 高頻度タグ、画像、長期保持 |
| 検証 | FAT/SAT、性能、セキュリティ、復元 | 実機停止制約、試験環境不足 |
| 運用 | 監視、版管理、追加設備、教育、サポート | 拠点数、24時間対応、変更頻度 |
初期見積では「全タグを保存」ではなく、異常シナリオに必要なイベント、集約値、原信号を分類します。高速波形は異常前後だけ保存し、通常時は統計値を持つなど、用途に応じた階層化が有効です。ただし、後から必要になる証拠を消さないよう、品質・保全・法務と合意します。
よくある失敗と回避策
失敗1：設備名をキーにして後から統合できない
表示名、IPアドレス、PLC局番は変わります。不変IDを発行し、既存コードとの対応表に有効期間を持たせます。
失敗2：収集率だけ高く、ロットへ結び付かない
タグ数やストレージ量をKPIにせず、execution_idの結合率と異常シナリオの再現率を測ります。
失敗3：現在のレシピしか保存していない
適用イベント、版数、ハッシュ、差分、実発効時刻を保存します。管理画面のスクリーンショットだけに依存しません。
失敗4：PoCが正常系デモで終わる
通信断、時計ずれ、再加工、手動運転、設備交換、ロールバックを試します。No-Go条件も先に合意します。
失敗5：バックアップはあるが復元できない
別環境への復元、必要ツール、ライセンス、依存版、所要時間まで確認し、結果を記録します。
失敗6：設備変更と品質確認が別ワークフロー
4M変更IDを設備構成、FAT/SAT、初品、発効後ロットに共通で付け、承認画面から証拠へ遷移できるようにします。
FAQ：生産設備トレーサビリティの導入判断
生産設備トレーサビリティとは何ですか？
製造ロットや製品シリアルを、その生産時点の設備ID、治工具ID、PLC/HMI／レシピ版数、保全・校正状態、品質結果と結び、異常時に影響範囲と根拠を追跡できる仕組みです。単なる設備データ収集や製品の入出庫履歴とは目的が異なります。
設備履歴管理はMESだけで実現できますか？
MESにすべて保存する必要はありません。MESを作業実績の正本、保全システムを作業記録の正本、OT基盤を信号の正本とし、共通IDとAPIで結ぶ構成も可能です。重要なのは責任分界と、照会時点の証拠を再現できることです。
保全記録電子化は紙のPDF化から始めてもよいですか？
移行の入口としては有効ですが、検索に必要な設備ID、作業種別、故障モード、交換部品、測定値、実施時刻、復帰判定は構造化してください。PDFだけではロットとの自動結合や傾向分析が難しくなります。
設備変更の4M管理で最も重要な時刻はどれですか？
申請日や承認日だけでなく、実際に変更が設備へ適用された「実発効時刻」が重要です。変更前後のロットを正しく区切るため、ロールバックを含む適用イベントを保存します。
製造ロットと設備を紐付けられない旧設備はどうしますか？
ゲートウェイ、バーコード読取、作業端末、ライン・品目・時間窓による補助結合を検討します。自動結合できない場合は確信度と手動確認者を記録し、確定データと推定データを区別します。設備更新まで待つ必要はありません。
RFPではどの数値を必須にすべきですか？
取得率、検索応答、再送重複、時計ずれ検知、復元時間などを、対象設備・データ量・試験条件とセットで定義します。本稿の99.5%や5秒は例示であり、規格の必須値ではありません。工程リスクと投資対効果に合わせて合意してください。
90日PoCで本番導入を判断できますか？
対象を代表ラインと代表異常に絞れば、接続性、意味の整合、検索、例外処理、運用、復元の主要リスクを評価できます。ただし全工場の完成を目指す期間ではありません。未解決リスク、追加開発、展開費用を明示して条件付きGoを含めて判断します。
FATとSATのどちらを重視すべきですか？
両方必要です。FATは制御された環境でロジックと例外処理を確認し、SATは実設備、実ネットワーク、実アカウント、実運用者で成立するかを確認します。特に時刻、設備ID、通信断、実版数、復元は現地で再確認します。
データは何年間保存すべきですか？
一律の年数では決められません。法令、顧客固有要求、契約、保証、製品安全、設備寿命、異常調査の必要性、保管費用を考慮します。原信号、イベント、監査証跡、証明書で保持階層を分ける方法もあります。
まとめ
生産設備トレーサビリティの核心は、設備データを集めることではなく、製造ロットを「その時点の設備構成と状態」へ証拠付きで結ぶことです。不変の設備ID、作業実績ID、版数とハッシュ、実発効時刻、保全・校正イベントを最小モデルとして整え、異常シナリオからRFPと受入条件を作ります。90日PoCでは正常系デモだけでなく、通信断、時計ずれ、変更、復元を試し、FAT/SATから日常の4M変更とOTバックアップまで同じ証拠線で管理することが、本番定着への近道です。
既設設備でどこまでデータを取得できるか、RFPの粒度をどうするか、代表ラインの90日PoCから始められるかという検討段階でもご相談いただけます。TOMAS TECHは、設備台帳・OT接続・MES連携・受入試験を、現場運用に合わせて整理します。お問い合わせはこちら。
参考一次情報
- ISO 55001:2024 — Asset management — Asset management system — Requirements
- ISO 55013:2024 — Asset management — Guidance on the management of data assets
- GS1 EPCIS
- ISA-95 Series of Standards
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security
- NIST SP 1339 — OT Backup Quick Start Guide
- OPC UA for Asset Administration Shell
- IATF Stakeholder Communiqué, 30 July 2026 — IATF 16949 2nd Edition Update Information
