温湿度監視システム｜タイ工場の選定・PoC 2026

タイの工場や倉庫で温湿度監視システムを検討するとき、センサーの価格やクラウド画面だけを比較しても、適切な選定にはなりません。必要なのは、温度マッピングで監視点を決め、異常時の判断と行動を定義し、通信断やセンサー故障があっても証拠を残し、FAT/SATで受入条件を確認できる一連の仕組みです。本稿では、調達担当、品質保証、設備、IT/OT、生産部門が同じ前提でRFPを作り、30日PoCから本番運用へ進むための実務手順を解説します。医薬品固有の法的助言ではなく、WHO、欧州委員会GDPガイドライン、NISTの公開資料を国際的な参考情報として用います。実際の要求は、対象製品・工程のリスク、顧客契約、社内基準、適用される法令・規格に合わせて確定してください。

温湿度監視システムは「センサーを置く案件」ではない

温湿度の記録を自動化する目的は、グラフをきれいに表示することではありません。製品品質、工程安定、設備保全、作業環境、顧客監査など、それぞれの判断に使える信頼性のあるデータを継続して残すことです。そのため、システムの範囲は測定素子から通知、時刻、ユーザー権限、監査証跡、バックアップ、復旧手順まで広がります。

特にタイでは、屋外の気候が一般に高温多湿で、季節や地域による変化もあります。タイ気象局の月次情報は周辺環境を理解する材料になりますが、屋外の気候値を工場内の設定値に転用してはいけません。2026年7月は南西モンスーンの影響を受け、全国降水量が平年を8％上回り、平均気温が平年を0.2℃上回ったと報告されています。これは「湿度対策を強くすべき」という一般論の背景にはなっても、特定の倉庫に何台のセンサーを置くか、警報を何％RHにするかを決める根拠ではありません。室内要求は保管物、空調能力、扉開放、壁・屋根、ラック配置、作業時間帯などから決めます。

まず分けるべき六つの活動

プロジェクトで混同されやすい活動を、最初から次のように分けます。

WHOの固定保管区域向け技術資料も、システム選定、設置、初期コミッショニングを扱っています。つまり、データロガーを購入しただけでは完成せず、「どの場所を、なぜ、何の判断のために監視するか」を証明できて初めて運用可能になります。

温度マッピングから定常監視点を決める

WHOは温度マッピングを三次元の保管空間で温度を記録する活動として説明し、保管監視に不可欠なものと位置づけています。ここで重要なのは、恒久センサーの位置を先に決めないことです。配線しやすい柱、電源に近い壁、通信が届きやすい場所だけを選ぶと、実際のリスク地点を外す可能性があります。

マッピング計画に含める情報

マッピング前に、少なくとも次を図面と計画書でそろえます。

• 対象エリアの寸法、高さ、ラックと保管物の配置、床・壁・屋根、熱源
• 空調機、吹出口、吸込口、除湿機、冷凍機、ファンと制御点
• 搬入口、シャッター、非常口、前室、頻繁に開閉する扉
• 操業時間、清掃、入出庫、休日停止、満載・低負荷など代表的な運転状態
• 日射を受ける外壁や屋根、隣接室、機械発熱、結露が疑われる場所
• 測定機器の識別、校正状態、設置高さと位置、開始・終了時刻
• 欠測、機器移動、扉開放など試験中の出来事を記録する方法
• 期待する分析方法と、恒久監視点を選ぶ判断基準

代表条件や季節変動をどう含めるかは、対象のリスクに応じて計画します。欧州委員会GDPガイドラインは代表条件でのマッピングと季節変動を考慮し、その結果に基づいて監視機器を配置する考え方を示しています。ただし、これはタイ国内の全工場へ自動的に適用される法令ではありません。国際的な参照として使い、実際の適用義務は顧客契約と現地要件で確認します。

マッピング結果を「点」ではなく判断経路へ変える

マッピングの成果はカラーマップだけではありません。次の順序で、定常監視へ接続します。

1. 空間内・時間帯別の変動と、扉開放や空調サイクルなど出来事の関係を確認する。
2. 製品・工程リスクに照らし、監視が必要な代表点とワーストケース候補を抽出する。
3. センサー設置可能性、保守アクセス、破損・水濡れ・フォークリフト接触のリスクを確認する。
4. 恒久センサー位置とその根拠を承認し、図面・資産台帳へ登録する。
5. 警報値、遅延、ヒステリシス、通知先を、工程リスクと運用手順に基づき別途承認する。
6. 将来のレイアウト、空調、製品、運転条件変更が再マッピングを要するか判断できる変更管理を作る。

センサー数や高さ、測定間隔に万能値はありません。空間の複雑さ、変化速度、製品リスク、機器性能、契約上の証拠要件によって変わるため、RFPではベンダーに固定台数を尋ねるだけでなく、「提案した台数と位置をどの調査・仮定・計算で正当化するか」を回答させます。

センサーデータ収集アーキテクチャの選び方

温湿度監視システムは、単体データロガー、無線ゲートウェイ、PLC/SCADA接続、クラウドサービスなど複数の形で構成できます。方式名で選ぶのではなく、障害時にも要求された証拠を残せるかで比較します。

オフラインバッファリングを仕様化する

「ネットワークが切れても大丈夫」という説明だけでは不十分です。センサー、ゲートウェイ、サーバー、クラウドのどこに、どの状態でデータを保持するかをデータフローで示します。保持可能時間は普遍値ではなく、想定停止時間、記録間隔、点数、保守体制から算定します。接続復旧後には、元の測定時刻を保ったまま再送されるか、重複が除かれるか、順序が整列されるか、欠測区間が明示されるかをPoCとSATで試験します。

さらに、バッファが満杯になった場合の挙動を確認します。古いデータを上書きするのか、新規記録を停止するのか、管理者へ通知するのか。どの挙動が正しいかはリスク次第ですが、未定義のままでは「通信断中も保存」の意味がありません。

時刻同期とタイムゾーン

温湿度値が正しくても、時刻がずれていれば扉開放、空調停止、製品移動との因果を追えません。RFPには、時刻源、同期失敗検知、機器再起動後の挙動、タイムゾーン、夏時間の扱い、UTC保存と現地表示の方針を含めます。タイで表示する場合も、海外本社や他拠点との比較を考え、データ交換時にタイムゾーン情報が失われない形式を指定します。手動時刻変更が可能なら、誰がいつ変更したかを監査証跡へ残す必要があります。

センサー故障とデータ品質フラグ

断線、電池低下、測定範囲外、値の固着、急なドリフト、通信品質低下は、環境異常とは別の「計測系異常」です。ダッシュボード上で両者を区別しなければ、現場は誤った対応をします。センサー故障時には、代替測定、交換、欠測評価、影響範囲の判断、データ注記までを手順化します。交換品は同じ識別番号を使い回さず、資産履歴として旧機器と新機器の関係を追跡できるようにします。

異常通知システムは「送信」ではなく「対応完了」まで設計する

警報の価値は、メールやLINEに通知が届くことではなく、適切な担当者が状況を確認し、製品・工程への影響を評価し、必要な処置を行い、その証拠が残ることです。警報値、遅延時間、ヒステリシス、エスカレーション時間に万能な推奨値はありません。製品・工程リスク、変化速度、現場の応答能力、顧客要求に基づいて承認します。

警報ライフサイクル

警報試験では、しきい値を一時変更して画面を赤くするだけでは足りません。安全な模擬入力や試験機能を使い、検知、配信、確認、エスカレーション、クローズまで通します。SMS、メール、アプリなど複数経路を使う場合は、それぞれの不達と代替経路も確認します。試験中の通知が実警報と混同されない表示と手順も必要です。

誤警報を減らすために遅延やヒステリシスを長くすればよいとは限りません。短時間の逸脱が品質に影響する工程では見逃しにつながり、反対に扉開放の瞬間変動を毎回重大警報にすれば警報疲れを招きます。マッピング、工程知識、過去データを用いて、検知性能と対応可能性のバランスを検証します。

データロガー工場導入のRFPチェックリスト

RFPは機器仕様表ではなく、調達後に受入試験へ転用できる要求の集合にします。「対応」「可能」だけで回答させず、標準機能、設定対応、追加開発、対象外、前提条件を分けて記載させると比較しやすくなります。

業務・品質要求

• 対象エリア、製品、工程、監視目的と、データを使う意思決定
• マッピング実施範囲と、恒久監視点を承認する責任者
• 必要な測定項目、測定レンジ、精度・不確かさに関する要求の根拠
• 記録間隔、保存期間、レビュー頻度、レポート形式の根拠
• 警報ルール、対応手順、夜間・休日のエスカレーション
• 校正・検証の方法、証明書、参照標準、期限切れ時の扱い
• 監査証跡、電子承認、コメント訂正、データエクスポート
• 多言語表示、タイムゾーン、単位、拠点横断レポート

ここで精度、記録間隔、保存期間、校正周期をベンダーの標準値へ丸投げしないことが重要です。万能な値は存在しません。要求元部門がリスクと契約を根拠に決め、ベンダーは実現方法と制約を回答します。

技術・インフラ要求

• センサー、ゲートウェイ、サーバー、クラウド間の通信方式と責任境界
• 無線サイトサーベイ、干渉、壁・ラック・保管物による減衰の評価
• 電源、UPS、電池寿命の前提、電池低下通知、交換手順
• オフライン保存容量の算定、再送、重複排除、欠測表示
• 時刻同期、時刻源障害、手動変更の監査証跡
• API、CSV/PDF出力、MES/WMS/SCADA/BIとの連携方式
• バックアップ対象、世代、暗号化、復元手順、復元試験
• 開発・検証・本番環境、設定移送、ロールバック
• 保守アクセス、リモートサポート、部品供給、SLAの適用時間帯

工場Wi-Fiを使う場合は、アクセスポイント数だけで判断せず、現場の端末密度、干渉、ローミング、VLAN、停電時継続まで含めて設計します。関連する実務はタイ工場の無線LAN設計ガイドも参照してください。また、ゲートウェイ、配線、クラウド利用料、保守まで含む費用の考え方はタイ工場IoT導入コストの整理で詳しく解説しています。

ベンダー成果物要求

RFPには納品物を明記します。例として、要件対応表、システム構成図、ネットワーク図、データフロー、センサー配置図、資産台帳、設定一覧、ユーザー・権限表、バックアップ手順、障害対応手順、校正証明、FAT/SAT記録、教育資料、ソースまたは設定バックアップ、ライセンス一覧、既知制約、保守窓口を含めます。ファイル形式と編集可能な原本の引渡しも指定します。

OTとしてのサイバーセキュリティ

NIST SP 800-82 Rev.3は、物理環境を監視するシステムもOTの範囲に含め、セキュリティ設計では性能、信頼性、安全性を尊重する必要があると示しています。温湿度監視は制御出力を持たない場合でも、品質判断や出荷可否に影響するため、単なる便利なIoT機器として扱うべきではありません。

最低限確認したい設計項目

1. ネットワーク分離：センサー／ゲートウェイを業務PCや来客Wi-Fiと同一平面に置かず、必要通信だけを許可する。
2. 識別と権限：共有管理者IDを避け、閲覧、設定変更、警報確認、承認を役割で分ける。
3. 認証情報管理：初期パスワード変更、秘密情報の保管、退職・異動時の無効化を手順化する。
4. 更新管理：ファームウェアとソフトウェアの更新可否、影響評価、検証、ロールバック、サポート終了を管理する。
5. ログ：ログイン、設定変更、時刻変更、校正情報変更、データ削除・出力を記録し、監視する。
6. バックアップと復旧：設定とデータを分けて保護し、復元できることを実際に試験する。
7. リモート保守：常時開放を避け、承認、時間制限、本人確認、操作ログを設ける。
8. インシデント対応：侵害が疑われるとき、監視を止めずに隔離・代替記録・影響評価する手順を持つ。

クラウドサービスでは、サービス終了や契約変更も可用性リスクです。契約終了時にどの形式で全データと監査証跡を回収できるか、回収後に読み取れるか、ベンダー依存の暗号化や専用ビューアが必要かを確認します。

30日PoCで確かめること

PoCはデモ画面の好みを決める場ではなく、最大の不確実性を小さくする期間です。以下は30日で進める一例であり、期間配分や合否値は対象現場に合わせます。

PoCのテストケース例

• センサーを計画位置へ設置でき、資産IDと図面位置が一致する
• 通信断中も元の測定時刻を保持して記録し、復旧後に欠落・重複なく同期する
• センサー切断、電池低下、値の固着候補が環境警報と区別される
• 時刻源を失った場合に検知され、復旧後も履歴の順序を追える
• 権限のない利用者が警報値、ユーザー、記録を変更できない
• 設定変更前後の値、実行者、時刻、理由が監査証跡に残る
• 警報の送信失敗が検知され、代替経路またはエスカレーションが働く
• ダッシュボード、CSV、PDFで同じ期間・センサーの値が整合する
• バックアップから代表データと設定を復元し、利用可能性を確認する
• 現場担当者が教育後に、確認・コメント・クローズを手順どおり実行できる

合否値は事前に決めます。ただし、本稿から特定の温度・湿度しきい値、精度、記録間隔、保存期間をコピーしてはいけません。製品仕様、工程リスク、マッピング、契約、適用基準から自社値を承認してください。

FAT/SATで受入証拠をそろえる

FATはベンダー環境で設計と主要機能を検証し、SATは実際の工場・倉庫で設置、通信、連携、運用を検証します。FATで成功しても、現地の壁、ラック、無線干渉、ファイアウォール、電源、ユーザー運用によりSATで問題が出ることがあります。両者を同じ試験の繰り返しにせず、環境差を意識して分担します。

試験項目には、前提条件、入力、操作、期待結果、実結果、証拠ファイル、実施者、確認者、日付、逸脱番号を持たせます。画面のスクリーンショットだけでなく、エクスポートデータ、システムログ、通知の受信記録、現場写真を組み合わせると、後から再現しやすくなります。

逸脱が出た場合は、口頭で「運用回避できる」と済ませず、影響、暫定措置、恒久対策、再試験、期限、責任者を記録します。条件付き受入を認めるなら、未完了事項が出荷判定や品質記録へ与える影響を承認者が理解できる形にします。

校正、保守、変更管理を運用へ組み込む

校正周期にも万能な値はありません。センサーの安定性、使用環境、製造者情報、過去の校正結果、要求精度、故障時の影響を踏まえ、リスクベースで決めます。期限が近い機器、期限切れ、校正不合格をシステムがどう示すかも重要です。

校正不合格が見つかった場合、直前の合格時点からの全データを自動的に無効と決めつけるのも、影響なしと決めつけるのも危険です。ずれの方向と大きさ、環境履歴、他センサーとの比較、製品・工程余裕、影響期間を評価し、品質部門が判断できる証拠をそろえます。

変更管理の対象には、センサー移設、警報値変更、記録間隔変更、ユーザー権限、ファームウェア、ネットワーク、空調、ラック、製品、操業時間を含めます。変更ごとに、再校正、部分再試験、再マッピング、教育更新の要否を評価します。

運用KPI

監視システム自身の健全性も測ります。例として、欠測時間、未確認警報、誤警報、センサー故障、時刻同期失敗、バックアップ失敗、期限超過の校正、未解決逸脱、平均復旧時間を追跡します。ただし目標値は自社のリスクとサービス水準から決めます。KPIの数字を達成するために警報を緩めたり、欠測を非表示にしたりしない統制が必要です。

RACIで責任の空白をなくす

温湿度監視は品質、設備、IT/OT、生産、倉庫、調達、ベンダーにまたがります。全員が関係者であるほど、最終判断者が不明確になりがちです。

Aは最終説明責任、Rは実行責任、Cは協議、Iは情報共有を表します。これは例なので、組織の権限へ置き換えてください。特に、警報を確認する担当と、製品影響を判断する担当を混同しないことが重要です。

温湿度記録自動化のTCOと効果を比較する

見積比較ではセンサー単価だけでなく、マッピング、設置、ネットワーク、サーバーまたはクラウド、連携、適格性確認、教育、校正、保守、電池・予備品、サイバー対策、データ移行、契約終了時の取り出しまで含めます。

パラメータ化した式は次のように置けます。

TCO = 初期機器・設計・設置・検証費 + 評価期間中のライセンス・通信・保守・校正・運用工数 + 更新・移行・廃棄費

便益 = 手作業記録削減 + 早期検知で回避できる損失の期待値 + 監査準備削減 + データに基づく設備改善

以下は計算方法を示すだけの架空の例で、タイ市場価格や効果保証ではありません。初期費用を1,800,000 THB、年間運用費を240,000 THB、3年評価とするとTCOは2,520,000 THBです。年間の回避損失を750,000 THB、手作業削減を180,000 THBと仮定すると、3年間便益は2,790,000 THBです。差額は270,000 THB、便益÷TCOは約1.11です。

実案件では、回避損失の発生確率、廃棄額、停止時間、担当工数を自社実績から置きます。便益を確実な効果と確率付き効果に分け、楽観・標準・慎重のシナリオで比較すると、誇張を避けられます。数値化しにくい顧客監査対応や原因究明時間も、別項目として意思決定へ含めます。

導入で失敗しやすいパターン

1. センサー位置を配線都合で決める

対策はマッピング結果とリスクで位置を決め、配線・無線設計を後から合わせることです。設置制約で変更する場合は、代替位置が同じリスクを代表できるか再評価します。

2. クラウド画面だけをPoCする

本番で問題になるのは通信断、電池切れ、時刻ずれ、権限、復旧です。PoCで異常系を安全に作り、証拠を確認します。

3. 警報を出せば運用できると思う

通知先の退職、夜間不達、確認だけで放置、影響評価の責任不明が起きます。警報ライフサイクルとRACIを同時に設計します。

4. 保存期間や校正周期をベンダー標準で決める

ベンダー標準は実装可能な選択肢であり、自社要求の根拠ではありません。製品リスク、契約、監査、故障履歴から承認します。

5. FATで合格したから現地試験を省略する

現地ネットワーク、ラック、壁、電源、ユーザー、通知先はFAT環境と異なります。SATで実構成と実運用を検証します。

6. データの正本と退出方法が不明

ゲートウェイ、クラウド、CSVのどれが正本か、訂正や再送をどう扱うか、契約終了時に何を返すかをRFPと契約で明記します。

まとめ：監視点の根拠と異常時の証拠から選ぶ

温湿度監視システムの選定では、センサー台数や画面機能より先に、何を守り、どの判断へ使うかを定義します。マッピングで恒久監視点を決め、コミッショニング、校正、警報試験、定常運用を分け、通信断・時刻ずれ・センサー故障・復旧を30日PoCとFAT/SATで確認します。警報値、記録間隔、保存期間、校正周期に万能値はなく、製品・工程リスク、契約、マッピング結果、適用要件に基づく承認が必要です。RACIと監査証跡を含めて設計すれば、温湿度記録の自動化を「見える化」で終わらせず、品質判断に使える仕組みにできます。

タイの工場・倉庫で、マッピング計画、RFP作成、PoC範囲、既存ネットワークとの接続を検討中の段階でもご相談いただけます。現場条件と運用責任を整理するところから進めたい場合は、TOMAS TECHお問い合わせフォームをご利用ください。

よくある質問

温湿度監視システムとは何ですか？

温度・相対湿度をセンサーで測り、時刻情報とともに収集・保存し、表示、警報、レポート、監査証跡へつなげる仕組みです。用途によってはデータロガーだけで構成できますが、多拠点監視、即時通知、権限管理、連携が必要ならゲートウェイやサーバー、クラウドを含みます。

温湿度センサーは何台必要ですか？

一律の台数はありません。空間の大きさだけでなく、高さ、ラック、空調、扉、熱源、代表運転、製品リスクを考慮したマッピング結果から恒久監視点を決めます。ベンダー提案では、台数と位置の根拠を確認してください。

記録間隔や保存期間はどのくらいですか？

万能な推奨値はありません。変化速度、逸脱が品質へ与える影響、検知したい事象、機器容量、契約・監査要件から決めます。保存期間も、法令・顧客要求・品質記録方針を確認し、検索・エクスポート・復元まで試験します。

温度マッピングと定常監視は同じですか？

異なります。マッピングは空間内の分布と変動を把握し、監視点を選ぶための調査です。定常監視は選定された点を継続測定し、異常へ対応する運用です。マッピング用ロガーの位置と数を、そのまま恒久配置へ固定するとは限りません。

異常通知はメールだけで十分ですか？

用途によりますが、重要なのはチャネル数ではなく不達検知、確認、対応、エスカレーション、クローズの証拠です。夜間・休日、担当変更、通信障害を含めて警報試験を行います。

クラウドが止まったらデータは失われますか？

設計次第です。センサーまたはゲートウェイにオフラインバッファを持たせ、復旧後に元の測定時刻で再送できる構成があります。保持容量、満杯時動作、重複排除、欠測表示、復旧試験をRFPとSATに含めてください。

校正は毎年必要ですか？

本稿では一律周期を推奨しません。要求精度、環境、機器の安定性、製造者情報、過去結果、故障影響に基づいて周期を決めます。校正不合格時に過去データへどのように影響評価するかも手順化します。

FATとSATの違いは何ですか？

FATは主にベンダー環境で設計と機能を確認し、SATは実際の設置場所でネットワーク、電源、センサー位置、通知先、連携、運用を確認します。要求IDと試験・証拠をひも付け、逸脱を追跡できるようにします。

参考情報

• WHO: Cold chain equipment and dry store temperature mapping tool (22 Jan 2026)
• WHO: Technical Supplement 6 — Temperature and humidity monitoring systems for fixed storage areas
• WHO: Temperature mapping of storage areas
• WHO: How to temperature map cold chain equipment and storage areas, 2nd ed.
• European Commission: Guidelines on Good Distribution Practice of medicinal products for human use
• NIST SP 800-82 Rev. 3: Guide to Operational Technology Security
• Thai Meteorological Department: Relative humidity
• Thai Meteorological Department: Monthly climate summary