温湿度記録の自動化｜タイ工場で監査できるデータとRFPを設計

リード：グラフだけでは「どのロットが影響を受けたか」に答えられない

ある日、品質保証部門から「恒温恒湿槽で温度逸脱が発生したが、どの製品ロットが影響を受けたのか？」という問い合わせが届きました。多くの工場では、温湿度の時系列グラフを提示することで「管理されている」と考えがちですが、グラフだけでは「どのロットが、どの時間帯に、どの程度の逸脱にさらされたか」を正確に説明できません。記録の自動化は単なる「見える化」やPoC（概念実証）ではなく、後から第三者がレビューし、根拠をもって説明できる「記録体系」の設計が必要です。

想定読者と「管理」「監視」との境界

本記事は、タイや日本の工場で調達・品質・エンジニアリング部門のリーダー、特に「温湿度記録の自動化」を検討し、将来的な監査やクレーム対応、製品品質の証明責任を担う方を対象としています。ここで扱うのは「温湿度の管理」や「監視」ではなく、「記録」の自動化です。単なるリアルタイム監視や警報発報ではなく、「後から説明できる」記録体系の設計・運用に焦点を当てます。

記録設計の出発点：「どんな品質質問に答える必要があるか」

温湿度記録の自動化設計は、「どんな品質上の質問に答える必要があるか」から始めるべきです。たとえば、

• 「このロットは、規定温度範囲外に何分間さらされたか？」
• 「逸脱発生時、誰がどのような対応をしたか？」
• 「このデータはどのセンサー、どの校正状態で取得されたか？」

こうした質問に対し、後から「記録」を根拠に説明できる設計が不可欠です。単なるグラフや数値の羅列ではなく、記録の「文脈」や「由来」まで追跡できることが求められます。

記録の最小スキーマ：どこまで記録すべきか

温湿度記録の自動化において、最低限必要な記録項目（スキーマ）は以下の通りです。これらを欠くと、後からの説明や監査に耐えられません。

• ソースセンサーID：どのセンサーから取得したか
• 設備/ゾーンID：どの部屋・装置・エリアか
• 測定値・単位：温度・湿度・単位
• ソースタイムスタンプ：センサー側で記録された時刻
• 受信タイムスタンプ：システムが受信した時刻
• ステータス/品質コード：通信異常・校正切れ・異常値等の状態
• 校正状態・バージョン：取得時点の校正証明書番号や有効期限
• 適用リミットバージョン：どの管理基準（例：SOPバージョン）で評価すべきか
• ロット/作業指示リンク：どの製品ロット・作業指示と紐づくか
• アラーム/アクションID：逸脱発生時のアラームIDや対応記録ID
• インジェスチョンID：データ取り込み処理の識別子（再送・重複排除のため）

このスキーマは、OPC UAのヒストリカルデータ仕様（OPC Foundation Historical Timestamps、StatusCode、Original Values）や、FDAのデータインテグリティガイダンス資料10にも通じる考え方です。

記録例：ある逸脱イベントのサンプルテーブル

下記は、恒温恒湿槽で温度逸脱が発生した際の記録例です。値やIDは説明のための架空例であり、普遍的な閾値や基準を示すものではありません。

このように、逸脱発生時のアラームIDや対応記録（アクションID）、校正情報、管理基準のバージョン、ロット/作業指示との紐付けまで記録することで、後から「どのロットが、どの逸脱に、どのように対応されたか」を説明できます。

センサー設置場所と校正チェーン：NISTトレーサビリティの現実

センサー設置の考慮点

センサーの設置場所は、製品や工程リスクに応じて慎重に決定する必要があります。たとえば、恒温恒湿槽内では「製品実体の近傍」「最も温度変動が大きい箇所」「制御センサーとは別の独立系」など、複数ポイントの設置が推奨される場合があります（Vaisala温度マッピング議論）。タイ工場でも、出入口、空調吹出口、外壁付近などで測定値の代表性を確認し、ゾーンごとの設置理由を残す必要があります。

校正チェーンとNISTトレーサビリティ

センサーの校正は、NIST（米国国立標準技術研究所）などの国家標準へのトレーサビリティが求められる場合がありますが、NISTトレーサビリティ自体は「証明書がNISTに直結している」ことではなく、「校正の連鎖（チェーン）が文書化されている」ことが本質です（NISTメトロロジートレーサビリティ）。タイ国内で利用する校正事業者の測定範囲・不確かさ・証明書の内容と、証明書番号・有効期限を記録する方法を設計段階で確認します。

タイ工場のゾーンと気候的運用差異

タイの工場では、現地の雨季・乾季、外気の流入、空調運転条件を設置場所ごとに確認します。ゾーンごとに「外気に面した壁」「高温多湿エリア」「冷房直下」など、リスクの異なるポイントが存在します。日本工場の設計をそのまま流用せず、現地の気候・建屋構造・運用実態を踏まえたゾーン設計が不可欠です。

システムアーキテクチャ：センサーから記録・レビューまで

温湿度記録の自動化システムは、単なるセンサーとグラフ表示だけでは不十分です。以下のような多層構造が必要です。

1. センサー／ロガー

設置場所・校正状態を管理し、測定値とタイムスタンプを記録。

1. ゲートウェイ

センサーからのデータを収集し、通信異常や重複排除、時刻同期を管理。

1. ヒストリアン（記録DB）

すべての記録をスキーマ付きで保存し、後からの検索・レビューに対応。

1. レビュー画面

記録の検索、アラーム発生時の対応記録、校正証明書の参照など、監査・品質部門が使いやすいUI。

1. QMS/MES連携

ロット・作業指示・逸脱対応記録と連携し、品質記録として一元管理。

OPC UAの限界とメタデータ保証

OPC UAのHistorical Access仕様は、タイムスタンプやステータスコード、元値と変更履歴を扱う方法（OPC UA Historical Timestamps、StatusCode、Original Values）を定義しています。しかし、全てのメタデータが自動的に保証されるわけではありません。たとえば、校正証明書番号やロットID、アクションIDなどは、システム設計時に明示的に記録・連携する仕組みを構築しなければ、OPC UAだけでは担保できません。

タイムゾーン・タイムスタンプ・クロックドリフト

ソース／サーバータイムスタンプの扱い

センサー自体が記録する「ソースタイムスタンプ」と、ゲートウェイやヒストリアンが受信時に付与する「受信タイムスタンプ」は、必ず両方記録する必要があります。ネットワーク遅延やバッファリング、センサーの時計ズレ（クロックドリフト）、一時的な通信断による遅延送信など、実際の測定時刻と記録時刻が一致しないケースが現実には多発します（OPC UA Historical Timestamps）。

タイムゾーンの明示

タイ工場では、タイ時間（UTC+7）での記録が基本ですが、サーバーやクラウドが日本時間（UTC+9）やUTCで動作している場合、タイムスタンプのタイムゾーン明示が不可欠です。タイムゾーンを明記しないと、後から「いつ逸脱が発生したのか」「どのロットが影響を受けたのか」を正確に説明できなくなります。

クロックドリフト・遅延配信の扱い

センサーやゲートウェイの時計がずれていた場合、記録の信頼性が損なわれます。定期的な時刻同期（NTP等）の実施、クロックドリフトの検出・記録、遅延配信時の「実測時刻」と「受信時刻」の両方記録など、設計段階での対策が必要です。

設計レビュー時の主な確認ポイント

• 記録スキーマは、後から品質質問に答えるのに十分か？
• 校正証明書や管理基準バージョンの記録・参照は容易か？
• ロット・作業指示との紐付けは自動化されているか？
• タイムスタンプ・タイムゾーン・クロックドリフトの管理は十分か？
• OPC UAや他プロトコルの限界を補う設計になっているか？
• タイ工場特有のゾーン・気候リスクを反映した設置・運用か？

（PART Bに続く）

欠測データとバックフィル戦略

温湿度記録の自動化において、データの欠測（missing data）は避けられないリスクです。工場現場ではネットワーク障害、センサー故障、電源トラブルなど多様な要因で記録が途切れることがあります。記録の完全性を担保するには、欠測時の対応方針を明確に設計し、工程や製品リスクに応じて運用を選択する必要があります。

ネットワーク障害中にロガーが実測値を保持し、復旧後に送れる構成なら、欠測を減らせます。ただし、OPC UA Historical Accessの仕様だけで後着データが自動的に「バックフィル」と識別されるわけではありません。過去のソース時刻で初回一括投入したデータには、変更記録が作られない場合もあります（OPC Foundation historical updates and original values）。そのため、実測時刻と受信時刻に加え、アプリケーション固有の遅延到着・再送フラグ、元イベントIDを要件化し、通信断から復旧までの受入試験で表示とエクスポートに残ることを確認します。

一方、現場の装置やシステムがローカルバッファを持たない場合、ネットワーク断絶期間のデータは物理的に取得不能となり、記録上は「ギャップ」として残ります。この場合、欠測区間の明示的な記録（たとえば「No Data」フラグや理由付きの空白）を残すことが、後の監査や品質判断に不可欠です。データを「なかったこと」にせず、欠測の事実と期間を正確に残すことで、工程リスク評価やロット判定の信頼性が維持されます。

無効値・欠測・補間・生データの違いとOPC UAによる根拠

温湿度記録の自動化では、単に値を集めるだけでなく、「どのような値か」を明確に区別することが重要です。OPC UAヒストリカルデータモデルでは、各データポイントに対して「StatusCode」を付与し、値の有効性や由来を記録できます（OPC Foundation historical StatusCode）。

• 無効値（Invalid）：センサー異常などが判明した値を品質判定へ使わないため、原因とともに無効扱いにします。OPC UAのBadなどのStatusCodeを利用する場合も、どの装置がどの条件で付けるかを確認します。
• 欠測（No Data）：物理的に実測値がない区間は、値があったかのように埋めません。読出し時のNoData応答と、アプリケーションが保存する欠測イベントは区別して設計します。
• 補間値（Interpolated）：前後の値から推定した値は実測値と区別します。OPC UAのReadAtTimeでは、補間時にInfoBitsでInterpolatedを示す仕様があります（OPC Foundation raw vs interpolated readings）。
• 生データ（Raw）：指定時刻に元の記録値がある場合、同じReadAtTime仕様ではInfoBitsでRawを示します。RawとGoodは別の意味なので、生データだから必ずGoodと決め付けません。

この区別は、後から記録をレビューする際や、逸脱時の原因究明、規格適合性の証明に不可欠です。たとえば、工程中の温湿度逸脱が発生した場合、その時点の値が「生データ」なのか「補間値」なのかで、品質部門の判断やロットの扱いが大きく変わります。

ネットワーク断絶時のシミュレーションとローカルバッファ

ネットワーク断絶時のデータ記録の堅牢性は、システム設計の重要な評価ポイントです。たとえば、Vaisala viewLincのような一部システムでは、センサーやローカルユニットがネットワーク障害時も一定期間データを内部保存し、回復後に自動でサーバへアップロードする機能が実装されています（Vaisala viewLinc official product）。この場合、データギャップは最小化され、記録の連続性が保たれます。

しかし、全てのシステムでこの機能が保証されているわけではありません。導入前には、実際にネットワーク断絶を模擬したテストを行い、どのような挙動になるかを必ず確認すべきです。もしローカルバッファがなく、断絶期間中のデータが完全に失われる場合は、記録上に明示的なギャップを残し、後から補間や推定を行わない方がリスク管理上は安全です。補間値に頼ると、実際の逸脱や異常を見逃すリスクが高まります。

元記録、訂正、作業者・理由、監査証跡

温湿度記録では、元記録の保全と訂正の追跡を要件として定めます。OPC UA Historical Accessは変更値・元値・変更情報を扱う仕組みを規定しますが、履歴管理と監査イベントの実装・保存は採用製品と設定で検証が必要です。特に過去時刻を持つデータの初回一括投入には変更記録が作られない場合があります（OPC Foundation historical updates and original values）。そのため、訂正前後の値、担当者、時刻、理由をアプリケーションの記録として残し、エクスポート後にも再構成できるか試します。

たとえば、現場担当者がセンサー交換や校正後にデータの訂正を行う場合、誰が、いつ、どの値を、どの理由で修正したかを必ず記録し、監査証跡（audit trail）として残すことが求められます。これにより、後からの品質監査やトレーサビリティ要求に対応できます。訂正理由の記録は、単なる操作ログではなく、工程リスクや製品品質への影響評価の根拠となります。

また、訂正や追記が発生した場合でも、元の記録を物理的に消去せず、訂正前後の値と理由を一元管理することが重要です。これにより、意図的な改ざんや操作ミスの早期発見、監査時の説明責任が果たせます。

アラーム閾値・バージョン管理、承認・是正対応・クローズ

温湿度逸脱のアラーム管理では、閾値（threshold）の設定と、そのバージョン管理が重要です。工程や製品ごとに異なる閾値を設定し、その変更履歴を記録することで、どの時点でどの基準が適用されていたかを明確にできます。

アラームが発生した場合、単なる「承認（acknowledgement）」と「是正対応（corrective action）」、および「クローズ（closure）」の区別が必要です。OPC UAのアラームモデルでは、アラーム発生時にオペレーターが「承認」操作を行い、その記録を残すことができます（OPC Foundation alarm acknowledge method）。しかし、承認はあくまで「認知」の記録であり、実際の是正対応（たとえば現場点検や設備調整）が完了したかどうかは別途管理が必要です。

是正対応の記録には、対応者、対応内容、対応日時、根本原因分析、再発防止策などを含めることが推奨されます。これらを一元管理し、最終的に品質部門や責任者が「クローズ」操作を行うことで、アラーム対応の完了を明確にできます。バージョン管理された閾値情報と組み合わせることで、どの基準で逸脱が発生し、どのような対応がなされたかを後から正確にレビューできます。

シフト間エスカレーション

24時間稼働の工場では、アラーム対応や記録レビューがシフトをまたぐことが一般的です。アラームが発生したが、夜間シフトでは対応できず、日勤シフトにエスカレーションされるケースも多いでしょう。自動化記録システムでは、アラームや是正対応の「未完了」状態を明示し、シフト交代時に次の担当者へ確実に引き継ぐ仕組みが求められます。

たとえば、アラーム発生から一定時間内に対応がなければ自動的に上位者へ通知する、あるいは未対応アラーム一覧をシフト交代時に自動表示するなど、エスカレーション機能の有無と運用設計が品質リスクの低減に直結します。システム設計時には、現場の運用実態や人員体制を踏まえ、エスカレーションルールを柔軟に設定できるかを確認することが重要です。

“`

+——————-+——————-+——————-+

| 記録種別 | 例 | OPC UA Status |

+——————-+——————-+——————-+

| 生データ | 23.5°C, 55%RH | Good |

| 無効値 | センサー故障 | Bad |

| 欠測 | ネット断絶 | No Data |

| 補間値 | 2点間の推定値 | Interpolated |

+——————-+——————-+——————-+

“`

生産中の湿度逸脱シナリオとロット境界の重複

具体的な運用例として、ある製品の生産中に湿度が一時的に上限を超過した場合を考えます。たとえば、ロットAの生産が終了し、直後にロットBの生産が開始されたタイミングで、湿度逸脱が発生したとします。この場合、逸脱期間が両ロットの境界をまたぐため、どちらのロットに影響が及んだかを厳密に特定する必要があります。

品質部門の保守的なポリシーでは、逸脱期間に該当する全ロットを「一時保留（hold）」とし、追加の品質評価や再検査を経て「リリース（release）」判断を下すことが推奨されます。ここで重要なのは、記録が「生データ」であるか、「補間値」や「欠測」区間を含むかによって、判断の信頼性が大きく変わる点です。たとえば、逸脱期間中にネットワーク断絶が重なり、一部データが「欠測」となっている場合、より厳格な保留措置が必要となるでしょう。

このようなシナリオでは、記録の完全性と由来の明確化が、品質判断の根拠となります。逸脱時の記録が「生データ」で連続している場合と、補間や欠測が混在している場合では、最終的なロットリリース判断や顧客への説明責任の重みが異なります。

セキュリティロール、サプライヤーリモートアクセス、バックアップ・リストア、エクスポート・リプレイテスト、保持期間

温湿度記録自動化システムでは、閲覧、アラーム確認、訂正、設定変更、バックアップの権限を職務別に定義します。OPC UAにはロールや監査に関する仕組みがありますが、サーバーがロール機構の全部または一部を実装するかは製品次第で、監査イベントのディスク保存も仕様だけでは保証されません（OPC Foundation OPC UA security model）。現場、品質、保全、IT/OTそれぞれの試験アカウントで許可・拒否される操作を確かめ、監査ログの保存先、保持期間、バックアップ、改変検知の実装を受入条件にします。

また、サプライヤーによるリモートアクセスが必要な場合でも、アクセス範囲や操作権限を限定し、アクセスログを必ず残すことが推奨されます。リモートメンテナンス時の操作記録も監査証跡の一部として管理すべきです。

バックアップ・リストア機能は、障害発生時の記録保全に不可欠です。定期的なバックアップ取得と、リストア後のデータ完全性検証（たとえばエクスポートデータのリプレイテスト）を運用手順に組み込むことで、万一のデータ消失リスクを最小化できます。エクスポート機能は、記録データをCSVやPDFなどの形式で出力し、外部監査や顧客提出に活用できますが、出力時にもデータの由来（生データ・補間値・欠測区間）を明示することが重要です。

記録の保持期間は、顧客要求や工程・製品リスクに応じて個別に定義されます。たとえば、医薬品や高信頼性部品では数年以上の長期保存が求められる場合もありますが、全ての業界で一律の法的義務があるわけではありません。保持期間の設定は、製品ライフサイクルや顧客契約、内部品質ポリシーを踏まえて決定し、システム側で自動削除やアーカイブ機能を活用することで、運用負荷とリスクのバランスを取ることが推奨されます。

次回PART Cでは、導入・運用時の現場課題、工程・製品リスクごとの設計ポイント、レビュー・監査時の実践的な運用例についてさらに掘り下げます。

RFP仕様テンプレート：12の実践的な質問

温湿度記録自動化システムの導入を検討する際、RFP（提案依頼書）には、単なるスペックやダッシュボードの見栄えではなく、実運用や監査・品質保証の観点から具体的な要件を盛り込むことが重要です。以下の12項目は、現場でのリスクや記録の完全性を担保するために、ベンダーに必ず確認すべき実践的な質問例です。

1. 記録データのタイムスタンプの取得方法と精度

　センサーローカル時刻、サーバー時刻、OPC UAのtimestamp（資料1）のどれを採用しているか。時刻のずれが生じた場合の補正・記録方法は。

1. データの変更履歴・監査証跡の管理方法

　記録値の修正・削除・再入力が発生した場合、誰が・いつ・なぜ・どのように変更したかを記録し、後からレビューできる仕組みはあるか（資料3）。

1. 異常値・アラーム発生時の対応フロー

　アラーム発生時の通知、アラームの確認（acknowledge）方法、誰がどのタイミングで対応したかの記録（6）。

1. センサー切断・通信断時のデータ保全

　センサーやネットワークが一時的に切断された場合、データの欠損や遅延が発生した際の記録・復旧方法。

1. 遅延データ・バッファデータの識別と記録

　センサー再接続時の遅延到着データをアプリケーション固有のフラグでリアルタイム値と区別できるか。値の品質StatusCodeも別項目として確認できるか（資料2）。

1. キャリブレーション履歴・不正校正の拒否

　校正作業の履歴管理と、校正値が規定範囲外の場合の自動拒否・アラート機能。

1. しきい値（アラーム閾値）の変更履歴・ロールバック

　しきい値の変更が誰によって、いつ、なぜ行われたかの記録と、誤設定時の元への復元手順。

1. CSV/PDFレポートの再生成と完全性担保

　過去の記録データから、監査やロットトレース時にレポートを再生成した際、元データと一致することの保証。

1. ロット・製品単位でのデータ検索・抽出機能

　製造ロットや特定製品に紐づく温湿度記録を迅速に抽出できるか。

1. システム障害・再起動時のデータ一貫性

　サーバーやネットワーク障害からの復旧後、データの欠損や二重記録が発生しない設計か。

1. ユーザー権限と操作ログの管理

　誰がどの操作を行ったかの詳細ログと、権限ごとの操作制限。

1. メトロロジートレーサビリティの担保

　センサーの校正証明書やトレーサビリティチェーンの管理方法（資料9）。

これらの質問は、単なる「温湿度監視」ではなく、「完全でレビュー可能な記録」を実現するための具体的な要件です。ベンダーの回答内容を比較し、現場のリスクや監査要件に合致しているかを必ず確認しましょう。

ベンダー提案比較：サンプルデータセットとデモによる評価

多くのベンダーは、ダッシュボードのデザインやグラフ表示の美しさを強調しますが、記録の完全性や運用時のトラブル対応力は、見た目だけでは判断できません。RFP回答後の比較検証では、以下のアプローチが有効です。

サンプルデータセットによる検証

• 実際の温湿度センサーから取得した生データ（欠損・異常値・遅延を含む）を提供し、各ベンダーのシステムでインポート・記録・レポート生成を実施。
• 意図的なセンサー切断や時刻ずれ、アラーム発生・復旧シナリオを含め、どのように記録・表示・監査証跡が残るかを比較。

デモ環境での実機操作

• アラーム発生から対応、記録修正、レポート再生成までの一連の操作を実際にベンダー担当者に実演させ、操作性・証跡・データの一貫性を確認。
• ユーザー権限の切り替えや、意図的な誤操作・不正操作時の挙動も必ずチェック。

このような検証を通じて、単なる「監視」ではなく「記録の完全性・監査性」を担保できるかどうかを見極めることができます。詳細は「温湿度監視システムの選定ポイント（タイ工場2026年版）」もご参照ください。

FAT/SAT詳細テストケース

システム導入時のFAT（Factory Acceptance Test）およびSAT（Site Acceptance Test）では、以下のような現場リスクを想定した詳細なテストケースを設計し、実機で検証することが不可欠です。

1. センサー切断・再接続

• センサーの物理的切断・再接続を行い、欠測区間と、復旧後の遅延到着データの専用フラグ・元時刻・受信時刻が記録されるか確認する。

2. タイムスタンプのずれ・補正

• センサー側の時刻を意図的にずらし、サーバー記録時のtimestampとの整合性、補正履歴の記録（資料1）。

3. 遅延データ・バッファデータの処理

• 通信断後に届く値を遅延データとして記録・検索できるかを試す。さらに、生値と補間値の区別も別に確認する（資料12）。

4. アラーム発生・アラーム確認（acknowledge）

• しきい値超過時のアラーム発生、ユーザーによるアラーム確認操作、その履歴記録（6）。

5. 記録値の変更・監査証跡

• 記録値の修正・削除操作を実施し、変更前後の値・担当者・理由・時刻が監査証跡として残るか。

6. 不正な校正値の拒否

• 校正作業時に規定外の値を入力し、システムが自動的に拒否・アラートを発するか。

7. ネットワーク障害・復旧後のデータ一貫性

• サーバー・ネットワークを強制的に停止・再起動し、データの欠損や二重記録が発生しないか。

8. CSV/PDFレポートの再生成・ロット検索

• 任意期間・ロット単位でレポートを再生成し、元データと一致するか、監査時に証明できるか。

9. しきい値変更・ロールバック

• しきい値を変更・誤設定した後、元に戻す操作とその履歴記録。

10. ユーザー権限・操作ログ

• 権限ごとに操作制限が正しく機能し、全操作のログが残るか。

（図3：FAT/SATで検証すべき温湿度記録自動化システムの主要テストケース一覧）

これらのテストケースを網羅的に実施し、すべての記録・監査証跡・レポート再現性が担保されていることを、現場・品質保証・IT部門が共同で確認することが重要です。詳細なデータ記録の仕組みについては「計測機器データ記録の実践ポイント（タイ工場2026年版）」も参考にしてください。

オーナーシップ/RACIと変更管理、校正・交換、しきい値更新・ロールバック

オーナーシップ/RACIの明確化

温湿度記録自動化システムの運用には、現場・品質保証・IT・設備保全など複数部門が関与します。RACI（Responsible, Accountable, Consulted, Informed）マトリクスを用い、以下のように役割分担を明確化しましょう。

• Responsible（実行責任）：日常点検・アラーム対応（現場担当）
• Accountable（最終責任）：記録の完全性・監査対応（品質保証部門）
• Consulted（助言）：システム設定・障害対応（IT部門・設備保全）
• Informed（報告）：経営層・監査担当

変更管理・キャリブレーション・交換

• 校正・交換時の記録：センサーの校正・交換履歴をシステム上で一元管理し、校正証明書やトレーサビリティ情報も紐付けて保存（資料9）。
• しきい値更新・ロールバック：アラーム閾値の変更は必ず履歴を残し、誤設定時には即座に元に戻せる運用手順を整備。

運用中の変更管理

• システム設定変更やソフトウェアアップデート時は、変更内容・担当者・理由・日時を必ず記録し、事前承認フローを設けることが推奨されます。

導入フェーズ、受入基準、サプライヤーに確認すべきポイント

導入フェーズ

1. 要件定義・RFP作成：現場リスク・監査要件を明文化
2. ベンダー選定・デモ検証：サンプルデータ・実機デモで比較
3. FAT/SAT：詳細テストケースによる検証
4. 現場展開・教育：操作訓練・運用手順の整備
5. 本稼働・運用監査：定期的な記録レビュー・監査対応

受入基準（Acceptance Criteria）

• すべてのFAT/SATテストケースをパス
• 記録・監査証跡・レポート再現性が担保されていること
• 校正・しきい値変更・障害復旧など、運用上の全シナリオでデータの一貫性が保たれること
• ユーザー権限・操作ログが適切に管理されていること

サプライヤーに確認すべきポイント

• システム障害時のサポート体制・復旧手順
• 校正証明書やトレーサビリティの管理方法
• ソフトウェアアップデート時の変更管理・事前通知
• 長期運用時のデータ保全・バックアップ体制

導入前に決めるべきデータ辞書と境界条件

データ連携を後工程へ広げる予定があるなら、計測点の名称だけではなく、変わらない識別子と表示名を分けて定義します。たとえば保管庫の表示名を現場改善で変更しても、過去の記録が別の計測点に見えないよう、設備ID・ゾーンID・センサーIDの対応履歴を保存します。センサーを交換した日以降は新しいセンサーIDに切り替え、同じゾーンの時系列として参照するときも交換境界を示します。どの値が物理測定値で、どれが画面表示用の計算値かも区別します。こうした辞書を調達時に渡さないと、ベンダーごとにIDの粒度や単位表記が異なり、後でロット検索を統合できません。

記録の生成点も明確にします。センサーが測定時刻を持つのか、データロガーが受信時に付与するのか、ゲートウェイが取り込むのかによって、同じ「時刻」欄の意味が変わります。後からロットの滞在時間と重ねるためには、時計同期方法、時刻の精度とずれを監視する方法、ずれが判明した期間の扱いを仕様に記載します。OPC UAにはソースとサーバーのタイムスタンプがありますが、機器の実装が両方を保存するとは限りません。採用構成のサンプル記録をFATで取り、どちらの時刻が測定イベントを示すか確認するべきです。

ロットとの結合も「同じ分にいた」という推定だけで決めません。入庫と出庫、装置への投入と取り出し、作業指示の一時停止と再開をイベントとして取得できるか確認します。境界の時刻が欠ける場合、影響範囲を狭める根拠がなくなります。品質担当が保守的な仮置き範囲を設定し、後から現場記録で確認する手順を決めておくと、システムが誤って安全と判定することを避けられます。測定結果とロットイベントは別システムに存在し得るため、照会画面だけでなく、どちらの元記録へ戻れるかが重要です。

受入証拠を残すための試験記録

FATの試験手順書には、操作と期待結果だけでなく、実施時の構成を残します。センサー型式とファームウエア、ゲートウェイとサーバーの版、時刻設定、接続方法、テストアカウントの権限、しきい値の版を記録します。同じ「ネットワークを切る」試験でも、センサーとゲートウェイ間を切ったのか、ゲートウェイとサーバー間を切ったのかで結果は異なります。試験のスクリーンショットだけでは元データとの一致を説明しにくいため、試験イベントID、エクスポートファイル、操作ログを一組にして保管します。

SATでは実際の建屋と運用を試します。センサーが予定位置に取り付けられているか、設備名と画面上の表示が対応しているか、通常のシフト引継ぎで警報が放置されないかを確認します。通信障害時には、現場がどう異常を知るか、復旧担当へどの情報を渡すか、後で欠測時間を誰がレビューするかを実演します。受入は「画面に値が出た」で終えず、指定したロットと期間について、元値、異常、対応、校正状態を別の担当者が再構成できることを完了条件にします。

運用開始後も、校正時に測定点を外す、センサーを入れ替える、閾値を変更するなどの作業が記録の文脈を変えます。変更票には理由、承認者、適用時刻、影響する設備・製品範囲、変更前後の設定、復旧手順を記載します。監査証跡がソフトウエアに存在しても、現場作業の紙記録と結び付かなければ説明の連鎖は途切れます。品質、保全、IT/OT、製造それぞれがどの記録を残すかを手順書に定め、定期的に実際のイベントを一件抽出して追跡できるか試すとよいでしょう。

FAQ（よくある質問と回答）

Q1. 温湿度監視システムと記録自動化システムの違いは？

A. 監視システムはリアルタイムの状態把握が主目的ですが、記録自動化システムは「誰が・いつ・どのように」記録・修正・対応したかを監査証跡付きで完全に残し、後からレビュー・証明できる点が本質的に異なります。

Q2. FDAのデータインテグリティ要件に準拠する必要がありますか？

A. 参照したFDAのデータインテグリティ・ガイダンスは米国の医薬品CGMPを対象とします。適用法令・契約・顧客要求は製品と取引先ごとに確認してください。ここで紹介する監査証跡の考え方を一般のタイ工場へ一律に法的義務として当てはめるものではありません。

Q3. センサーの校正や交換時、記録の一貫性はどう担保されますか？

A. 校正・交換履歴をシステムで一元管理し、校正証明書やトレーサビリティ情報（資料9）を紐付けることで、監査時にも記録の正当性を証明できます。

Q4. 記録データの改ざんや誤操作が発生した場合、どう検知できますか？

A. すべての記録変更・削除操作に対し、担当者・理由・時刻を監査証跡として残し、後からレビュー・追跡できる設計が必須です（資料3）。

Q5. システム障害やネットワーク断が発生した場合、記録はどうなりますか？

A. 採用する機種にローカル保存と再送機能があれば、復旧後に遅延データとして識別する設計が可能です。機能がなければ欠測を明示し、推測値で埋めない運用を決めます。FAT/SATで実機と実際のネットワーク構成を検証します。

まとめ・TOMAS TECHへのお問い合わせ

温湿度記録自動化システムの選定・導入は、単なる「監視」から「完全でレビュー可能な記録」への転換が求められる時代です。現場リスクや品質監査に耐えうる設計・運用を実現するには、RFP段階から実践的な要件を明確化し、ベンダーの提案をサンプルデータや実機デモで厳格に比較・検証することが不可欠です。

TOMAS TECHへのご相談では、対象工程、現行センサー、記録例、ロット情報の所在、想定する調達時期を共有ください。要件の整理と、現場で確認すべき接続・運用上の論点について相談できます。

詳細なご相談・現場ヒアリング・デモ依頼は、TOMAS TECHお問い合わせフォームよりお気軽にご連絡ください。

参考資料

1. https://reference.opcfoundation.org/specs/OPC-10000-11/4.5
2. https://reference.opcfoundation.org/specs/OPC-10000-11/6
3. https://reference.opcfoundation.org/specs/OPC-10000-11/4.4
4. https://reference.opcfoundation.org/specs/OPC-10000-9/5.7.3
5. https://www.vaisala.com/en/products/software/viewlinc
6. https://docs.vaisala.com/r/M212315EN-C/en-US/GUID-E738FA55-CB57-4BE6-8331-C811E10AB988/GUID-46424254-8FC3-4883-AEA9-2946CD88252F/GUID-8A1D9588-D668-45FD-8662-C7F01317869A
7. https://www.vaisala.com/sites/default/files/documents/viewLinc-Continuous-Monitoring-System-Brochure-B211555EN.pdf
8. https://www.vaisala.com/en/blog/2023-07/temperature-mapping-study-design-duration-intervals
9. https://www.nist.gov/metrology/metrological-traceability
10. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/data-integrity-and-compliance-drug-cgmp-questions-and-answers
11. https://reference.opcfoundation.org/specs/OPC-10000-2/4
12. https://reference.opcfoundation.org/specs/OPC-10000-11/6.5.5.2