海外拠点 IoT 導入2026｜タイ工場のRFP・90日PoC・運用設計

海外拠点 IoT 導入を成功させるには、センサーやダッシュボードを選ぶ前に、「タイ工場で誰がデータを使い、日本側はどこまで遠隔で関与し、通信断やサイバー事故時に誰が操業判断をするか」を決める必要があります。本稿では、タイの製造拠点へIoTを導入する企業が、RFP、90日PoC、本番移行、日常運用、OTセキュリティ、バックアップまで一貫して発注できるように実務要件を整理します。90日という期間や後述の閾値は契約設計の例であり、法定値や普遍的な業界標準ではありません。

結論：タイ工場IoTは「見える化」ではなく、現地で継続運用できる意思決定システムとして発注する

海外工場のIoTは、設備データをクラウドへ送れば完成するものではありません。経営、日本本社、タイ工場の製造、保全、品質、IT、OT、外部ベンダーが、同じデータを異なる目的で使います。データの意味、時刻、単位、品質、責任者が曖昧なまま画面だけ作ると、異常時には電話と表計算へ戻り、現場に保守できないゲートウェイが残ります。

RFPでは少なくとも次の6点を必須ゲートにします。

1. 対象設備、業務判断、利用者、期待する証拠をユースケースごとに定義する。
2. PLC、センサー、ゲートウェイ、工場ネットワーク、クラウドの責任境界を定義する。
3. 日本からの閲覧と、現地設備への操作権限を明確に分離する。
4. 通信断、時刻ずれ、欠測、重複、再送を含むデータ品質を受入試験にする。
5. 資産台帳、脆弱性対応、アカウント、証明書、バックアップ、復旧演習を運用契約へ含める。
6. PoCの成功条件を「データが見えた」ではなく、業務判断と本番運用へ移せる証拠で定義する。

設備接続以前に費用項目を整理したい場合は、タイ工場IoTの費用設計を、無線区間を含む工場ネットワークを設計する場合はタイ工場の無線LAN設計も参照してください。

海外拠点 IoT 導入が国内工場より難しい理由

海外拠点では、設備年代、メーカー、通信方式、保全資料、使用言語、勤務時間、ベンダー契約、社内IT標準が混在します。日本側が「このタグを取ればよい」と考えても、タイ工場ではPLCプログラムの原本が見つからない、装置メーカーの保証条件で接続できない、盤内に電源とスペースがない、工程名が日本のマスターと一致しない、といった問題が起こります。

さらに、遠隔監視は組織設計の問題でもあります。日本側がアラームを見たとき、現地へ誰が連絡するのか。現地の夜勤は誰の判断を優先するのか。データが欠けているのか、本当に設備が止まったのか。日本から設定変更してよいのか。こうした問いに答えずに「日本からタイ工場を監視する」という表現だけをRFPへ書くと、供給者ごとに提案範囲が変わり、価格比較も受入判定もできません。

したがって、最初の成果物は機器表ではなく、ユースケース台帳にします。各行に、利用者、判断、必要データ、必要な鮮度、許容する欠測、通知先、現地での対処、保存期間、監査証拠を記載します。例えば「コンプレッサーの電力原単位を日次会議で確認する」と「危険な状態を秒単位で検知して設備を停止する」は、必要な信頼性と安全責任がまったく異なります。後者を一般的なクラウドIoTの通知だけへ依存させてはいけません。

RFPの前に決めるべき経営・工場・IT/OTの責任分担

IoTプロジェクトの失敗は、技術不足よりも「誰が正本を持つか」の未決で起こります。RFP準備会では、少なくとも工場責任者、製造、保全、品質、EHS、現地IT、日本側の事業責任者とIT/セキュリティを参加させます。供給者へ設計を丸投げする前に、発注者が次の責任を決めます。

責任分担はRACI表だけで終わらせず、異常シナリオで検証します。「夜勤中にVPNが切れ、ゲートウェイはバッファ中、日本側ダッシュボードは古い最終値を表示している」とき、画面は古い値であることを明示するか、現地は何を確認するか、誰が復旧させるかまで答えられる状態にします。

タイ工場IoTの対象をユースケースから絞る

PoCでは対象を広げるほど学びが増えるとは限りません。設備台数より、判断の閉ループが完結する小さな範囲を選びます。選定候補には、エネルギー監視、稼働・停止理由、予防保全、品質条件の記録、ユーティリティ異常、ロットと設備条件の関連付けなどがあります。

優先順位は、課題の大きさだけでなく、データ取得可能性、現場の対処可能性、設備停止リスク、横展開可能性で評価します。センサーを付けても現地に対応部品と作業者がないなら、通知を増やすだけです。逆に、既存PLCのデータが安定しており、停止理由を現場が毎日見直せる工程なら、限られた設備でも運用能力を検証できます。

RFPにはユースケースごとに次を記載します。

• 現状の判断方法と問題点。
• データを見て誰が何を変えるか。
• 対象設備、信号、サンプリング、イベント条件。
• 欠測や通信断でも維持すべき現地操業。
• 受入時に再現する正常・異常シナリオ。
• PoC後に廃棄、継続、拡張を判断する基準。

ISA-95で日本本社・ERP・MES・設備の境界をそろえる

ISA-95は企業機能と製造オペレーション／制御の統合を整理する標準群です。2025年版Part 1を含むシリーズは、活動と情報交換を技術に依存せず整理する土台になります。RFPで階層図を飾りとして載せるのではなく、どのシステムがどの情報の正本で、どちら向きに、どのイベントで更新するかを決めるために使います。

例えば、受注、購買、会計、公式な品目はERP、詳細な製造実行と設備割当はMES、瞬時の制御はPLC/DCS、横断分析はIoT基盤という分担が考えられます。ただし製品名で自動的に決めず、既存環境に合わせて一項目ずつ責任を決めます。IoT基盤が勝手に設備IDを作り、ERPやMESと別の名称を持つと、日本側の分析が現場の製造指図やロットへ結びつきません。

インターフェース表には、送信元、送信先、データオーナー、キー、単位、時刻、作成・変更・取消、再送、順序逆転、重複排除、エラー時の保留場所を記載します。「API対応」「OPC UA対応」だけでは受入可能な仕様になりません。

接続方式：OPC UA、MQTT、既存PLCをどう使い分けるか

OPC Foundationの2026年資料は、OPC UAをIEC 62541に基づく、メーカーやプラットフォームに依存しない情報交換の仕組みとして説明し、機器間の水平連携とデバイスからクラウドまでの垂直連携を扱っています。OPC UAはクライアント／サーバーとPubSubを支え、情報モデルで値の意味を表現できます。OPC UA over MQTTの選択肢もあります。

ただし、規格名だけで相互運用性は保証されません。RFPでは、利用するOPC UAプロファイル、情報モデル、ノード命名、証明書、暗号設定、エンドポイント、タイムスタンプ、ステータスコード、履歴、イベント、再接続、サーバー負荷を具体化します。ベンダー固有タグを標準語彙へ変換する場所も決めます。

MQTTは低帯域やPublish/Subscribeに適する場面がありますが、トピック名、ペイロードスキーマ、QoS、保持メッセージ、セッション、重複、順序、証明書更新、ブローカー停止時の挙動を設計する必要があります。QoSの数字だけで業務上の一回性が保証されるわけではないため、受信側でイベントIDと時刻を使った冪等処理を要求します。

既存PLCへ直接負荷をかけられない場合は、SCADA、ヒストリアン、専用ゲートウェイを経由します。古いプロトコルをクラウドへ直接公開してはいけません。プロトコル変換は、セキュリティ境界と保守責任を明確にした中間層で行います。

海外工場 遠隔監視のアーキテクチャ要件

遠隔監視は、監視データの送信と遠隔操作を分離して設計します。通常の分析用途では、工場側から境界の中間層へ、さらに承認したクラウドサービスへ送る方向を基本にし、インターネットからPLCへ任意に入れる経路を作りません。日本側ユーザーはID連携、多要素認証、役割、端末条件、セッション記録によりダッシュボードへアクセスします。

遠隔保守が必要な場合は、恒久VPNアカウントを共有する設計を避けます。申請・承認、利用時間、対象資産、ジャンプ環境、多要素認証、操作ログ、録画の必要性、緊急停止、契約終了時の失効を定めます。ベンダーが接続できる時間と範囲は最小化し、現地が接続状態を認識して遮断できるようにします。

NIST SP 1800-45は2026年6月24日に最終版となり、市販技術を使ったOTリモートアクセスの構成例を3つ示しています。認証・認可、安全な通信などをRFPの検証シナリオへ落とす際の参考になります。ただし、これは米国の上下水道分野で能力の異なる事業者を想定した実装例であり、製造業へ自動適用する規格ではありません。タイ工場では設備リスク、既存ネットワーク、現地手順に合わせて採否を評価します。

NIST SP 800-82 Rev.3は、OT固有の性能、信頼性、安全要求を考慮してセキュリティを設計する指針です。2026年8月時点でRev.4はpre-draft段階であり、本稿は公開済み最終版のRev.3を基準にしています。ITの標準管理策をそのまま適用して設備を停止させるのではなく、リスク、保守窓、設備メーカー条件、現場の安全手順に合わせて実装・試験します。

Secure by DemandをRFPの評価項目へ変換する

CISAなどがOT所有者・運用者向けに公表したSecure by Demandのガイドは、購入者が供給者へ安全な製品を要求するための優先事項を示しています。RFPでは「セキュアであること」という抽象文ではなく、製品選定と契約で確認可能な質問へ変換します。

• 製品は既定で安全な設定になり、不要なサービスと初期アカウントを無効化できるか。
• 多要素認証、役割分離、集中ID連携をどこまで標準で支えるか。
• 脆弱性開示方針、通知方法、修正版提供期間、サポート終了日は何か。
• ソフトウェア構成、第三者部品、署名済み更新、更新の検証方法を示せるか。
• ログを外部へ安全に転送し、時刻と資産IDを保てるか。
• 構成とデータを標準形式で輸出し、契約終了時に返却できるか。
• 工場がネットワークから切り離されても安全な状態を維持できるか。

回答はYes/Noではなく、標準機能、設定、追加開発、外部製品、将来計画に分類させ、デモやFATで証拠を提出させます。ロードマップ機能を現行機能として採点しないことも重要です。

データ設計：タグ一覧より「意味・品質・時刻」を発注する

IoTデータは値だけでは不十分です。各信号に、グローバル設備ID、現地表示名、データ型、単位、スケール、収集元、原時刻、受信時刻、品質コード、正常範囲、校正情報、責任者、変更履歴を持たせます。タイ語、日本語、英語の表示名は翻訳文ではなく同じ設備IDに結びます。

時刻は特に重要です。PLC時刻、ゲートウェイ時刻、クラウド受信時刻が混在すると、停止原因の前後関係を誤ります。タイムゾーン、UTC保存、現地表示、時刻同期元、夏時間の扱い、時刻が飛んだときのフラグを定義します。タイには夏時間がなくても、日本や他拠点と統合する基盤では、表示規則を明示しておく方が安全です。

データ品質は、good/badだけでなく、欠測、通信断、範囲外、センサー保全中、手入力、推定、遅延到着を区別します。ダッシュボードで最終値を表示し続ける場合は、経過時間と品質を目立たせます。古い値を現在値に見せることは、停止そのものより危険な誤判断につながります。

90日PoCを「本番の縮小版」として設計する

本稿の90日は、契約上の例示期間です。設備停止日、調達、ネットワーク工事、製造サイクルによって適切な期間は変わります。重要なのは、検証用の仮設環境で画面を見せるだけでなく、実際の利用者、設備、勤務、通信断、保守手順を含めることです。

Day 0まで：ベースラインと安全承認

開始前に、対象KPIの定義、現状値の取得方法、設備接続承認、変更管理、作業許可、ロールバック、ネットワーク図、資産台帳を確定します。効果率は先に作らず、同じ定義で比較できるベースラインを取ります。安全関連制御へ影響する可能性があれば、工場の正式なリスク評価と承認を通します。

Day 1–30：接続とデータ品質

タグを接続し、単位、時刻、品質、欠測、再送、バッファ、負荷を検証します。画面の見栄えより、データがどの経路で作られ、変換され、失われるかを証拠化します。ネットワーク切断、ゲートウェイ再起動、証明書エラーを意図的に再現し、復帰後の重複と順序を確認します。

Day 31–60：業務運用と例外処理

タイ工場の実利用者が日次会議、保全判断、アラーム対応を行います。日本側は定めた範囲でレビューし、現地判断を飛び越えません。通知疲れ、翻訳、勤務交代、休日連絡、責任者不在、誤検知を確認し、ルールと教育を修正します。

Day 61–90：セキュリティ、復旧、拡張判断

アカウント棚卸し、権限レビュー、ログ確認、脆弱性対応フロー、バックアップ復元、障害連絡、契約終了時のデータ返却を演習します。横展開のため、設備追加に必要な工数、テンプレート化できるデータモデル、現地保守部品、ライセンスと通信費も測ります。

PoCの受入基準とスコアカード

PoCの合否は、単一の効果率で決めません。少なくとも業務適合、データ品質、OT安全、セキュリティ、運用性、拡張性、総費用の観点を分けます。重みは工場のリスクに合わせます。

例示的な証拠は次のとおりです。

• 対象ユースケースの判断が定めた利用者と会議で実行された記録。
• 欠測・遅延・重複が検出され、ダッシュボードとログで説明できること。
• 通信断後に現地操業を継続し、復帰時に安全に再同期できること。
• 権限外ユーザーが設備・設定・データへアクセスできない試験結果。
• ゲートウェイ交換、証明書更新、アカウント失効を現地手順で実行できること。
• バックアップから構成と必要データを復元し、復旧時間を実測した証拠。
• 本番移行時の未解決事項、費用、責任者、期限が合意されていること。

「データ取得率99%以上」のような数値を使う場合は、分母、計画停止、品質不良、遅延到着、対象タグ、測定窓を契約で定義します。本稿は一律の基準値を推奨しません。安全や制御に関わる要件は、分析ダッシュボードより厳しい別基準が必要です。

OTバックアップと復旧をIoT導入範囲に含める

NIST SP 1339（2026年6月公開）は、OTバックアップを信頼性・サイバー事故からの復旧に重要なものとして扱い、変更管理への統合、定期的な作成、テスト、復旧演習でのレビューを要点にしています。IoT導入ではクラウドデータだけでなく、ゲートウェイ構成、証明書、接続設定、タグ変換、PLCやHMIの関連構成、ダッシュボード、アラームルール、ネットワーク機器設定、復旧手順を対象にします。

RFPでは次を確認します。

• 何を、どのイベントと周期でバックアップするか。
• バックアップの所有者、暗号化、別環境保管、アクセス権は誰か。
• 機器交換時に同型機がなくても復旧できるか。
• 復元試験を誰が、どの環境で、どの頻度で行うか。
• 復元した構成と現行設備の差分をどう承認するか。
• ランサムウェア、クラウド停止、証明書失効、ベンダー撤退をどう演習するか。

バックアップジョブが成功したというログだけでは、復旧可能性の証拠になりません。PoCまたはSATで、隔離した環境へ復元し、接続、権限、データ、アラーム、運用手順が機能することを確認します。

日本から タイ工場 監視を日常業務へ組み込む

遠隔監視センターを作っても、現地と日本で同じアラームを二重に追うだけでは価値が出ません。監視項目ごとに、情報通知、要確認、現地対応、経営エスカレーションを分けます。安全停止と緊急操作は、現地の正式な制御・安全手順を優先します。

アラームには、設備ID、発生時刻、品質、現在状態、推奨確認、現地担当、エスカレーション期限を付けます。日本語説明があっても、現地のタイ語作業手順と設備表示に対応していなければ使えません。対応完了後は、原因、処置、部品、停止時間を記録し、同じアラームの繰り返しを月次で見直します。

日本側の役割は、拠点比較、専門家支援、未解決課題の追跡、投資判断に向いています。現地の承認を飛ばしてPLC設定を変える仕組みにしないことが重要です。緊急時の例外アクセスが必要なら、二者承認、時間制限、対象制限、操作記録、事後レビューを契約と手順へ入れます。

本番運用：資産、アカウント、証明書、パッチ、変更を一つの台帳で追う

IoTゲートウェイは導入後に増え続けます。設備ID、型式、シリアル、設置場所、IP、ファームウェア、OS、ソフトウェア、所有者、保守会社、保証、サポート終了、証明書期限、バックアップ、通信先を資産台帳で管理します。仮設PoC機を本番へ残す場合も、正式資産へ昇格させます。

パッチは自動適用か放置かの二択ではありません。脆弱性通知を受け、影響を評価し、検証環境で試し、保守窓で適用し、失敗時に戻すフローを設計します。すぐ適用できないOT機器には、接続制限、監視強化、アカウント停止などの補完策と期限を持たせます。

証明書とサービスアカウントには人事異動がないため、忘れられやすい資産です。発行者、用途、秘密鍵保管、期限、更新責任、失効、交換試験を台帳化します。共有アカウントを避け、外部保守員は個人識別できるアクセスにします。契約終了時にベンダーのアカウント、API鍵、VPN、証明書を失効する手順も受入対象です。

タイのSmart and Sustainable Industry施策をどう扱うか

タイBOIの現行Smart and Sustainable Industryページでは、対象となる最低投資額を土地代・運転資金を除き100万THBとしています。既存案件の法人所得税免除は原則3年間で、投資額の50%を上限とする記載があります。一方、タイ国内のautomation industryと連携した機械が対象価値の30%以上を占める条件では、3年間・投資額の100%を上限とする記載があります。また、投資奨励証書の発行後3年以内に実施を完了する条件が示されています。

これらは制度ページの要約であり、IoT機器を買えば自動的に適格になるものではありません。投資判断ではシステムの業務適合性と優遇申請を分け、申請を見込む場合は発注前にBOIやNSTDAなど関係機関へ、対象活動、対象価値、計算範囲、申請時期、必要証拠を確認します。設備表、工程改善内容、投資額、請求書、稼働証拠を保存してください。本稿は税務・法律・投資奨励の助言ではありません。

ベンダーデモ、FAT、SATで再現するシナリオ

自由デモでは供給者の得意画面しか比較できません。全社へ同じ入力データ、ネットワーク条件、利用者、期待結果を渡します。

シナリオA：正常な収集と日次判断。 設備値、状態、エネルギー、製造指図を関連付け、タイ語現場画面と日本語管理画面で同じ設備・時刻・単位を確認します。

シナリオB：通信断と再送。 工場とクラウドの回線を止め、現地操業、ゲートウェイのバッファ、古い値の表示、復帰後の重複・順序・欠測を検証します。

シナリオC：センサー異常。 範囲外、固定値、校正期限切れを入力し、生産異常とデータ品質異常を区別できるか確認します。

シナリオD：遠隔保守。 外部ベンダーが承認済み時間だけ指定資産へ入り、操作が記録され、期限後に接続できないことを示します。

シナリオE：復元。 新しいゲートウェイまたは隔離環境へ構成、証明書、マッピングを復元し、承認済み接続だけが戻ることを確認します。

FATは構成済み環境で標準・例外シナリオを証拠化します。SATはタイ工場の実PLC、盤、電源、ネットワーク、時刻、言語、勤務、セキュリティ境界で実施します。PoC合格と本番受入を混同せず、未解決項目、暫定策、期限、支払条件を結びます。

RFPに入れる質問チェックリスト

業務・データ

• ユースケース、利用者、判断、KPI、データオーナーは明確か。
• 設備ID、タグ、単位、時刻、品質、履歴を一括輸出できるか。
• 現地語・日本語表示が同じマスターへ結びつくか。
• 欠測、遅延、重複、推定値を識別できるか。

OT接続・可用性

• PLCへの負荷と装置保証への影響を誰が評価するか。
• 回線断、電源断、クラウド停止中の現地操業はどうなるか。
• ゲートウェイ交換、オフラインバッファ、再同期を試験できるか。
• 安全制御とIoT分析の境界が文書化されているか。

セキュリティ・供給者

• ネットワーク区域、許可通信、遠隔アクセス、ログを図示できるか。
• MFA、最小権限、証明書更新、脆弱性通知を標準で支えるか。
• サポート終了、第三者部品、更新署名、インシデント連絡を契約化できるか。
• データと構成を返却し、供給者アクセスを完全に失効できるか。

導入・運用・費用

• 現地調査、盤改造、工事、停止、教育、予備品を見積に含むか。
• ライセンス、クラウド、通信、保守、更新、データ搬出費を同じ期間で比較できるか。
• タイ語の一次対応と日本側エスカレーションの時間帯は何か。
• 本番展開時にPoC資産とデータを再利用できるか。

よくある失敗と回避策

ダッシュボード完成をPoC成功とする

画面は正常時の一部しか示しません。通信断、センサー故障、権限失効、復元、夜勤対応を成功条件に含めます。

日本側が現地を介さず遠隔操作する

現地の安全責任と設備状態を見落とします。閲覧と操作を分離し、操作は正式な承認、時間制限、記録を条件にします。

すべてのタグを最初から集める

意味と利用者がないデータが増え、費用と攻撃対象領域が広がります。ユースケースに必要なタグから始め、追加手順を標準化します。

PoC専用の仮設構成をそのまま本番化する

共有アカウント、未管理端末、暫定回線が残ります。本番移行ゲートで資産登録、構成標準、バックアップ、保守契約を確認します。

効果率を先に約束する

停止、欠測、勤務、製品構成の定義が違えば比較できません。同じ定義でベースラインとPoC値を測り、観測期間と除外条件を明示します。

FAQ：海外拠点 IoT 導入でよくある質問

タイ 工場 IoTは何台から始めるべきですか？

普遍的な台数はありません。設備台数ではなく、データ取得から現場の対処、効果・リスク確認まで一つの閉じた業務を検証できる範囲を選びます。横展開用のテンプレートもPoC成果物にします。

海外工場 遠隔監視はクラウドだけで実現できますか？

クラウドは集約と分析に有効ですが、現地の安全・制御・通信断時操業を代替しません。工場側の境界、ゲートウェイ、バッファ、権限、復旧、現地手順を含む全体設計が必要です。

日本から タイ工場 監視でPLC操作も許可すべきですか？

標準では閲覧と操作を分離するのが安全です。遠隔操作が業務上必要なら、リスク評価、現地承認、対象・時間制限、MFA、ジャンプ環境、操作記録、緊急遮断、事後レビューを要求します。

OPC UA対応なら異なるメーカーでもすぐ接続できますか？

規格対応だけでは不十分です。プロファイル、情報モデル、証明書、セキュリティ設定、ノード、単位、時刻、品質、イベントを双方で合わせ、FAT/SATで検証します。

90日PoCは業界標準ですか？

いいえ。本稿の90日は契約設計の例です。工事、保守窓、製造サイクル、季節性、調達に応じて期間を決め、期間よりも正常・異常・復旧・運用の証拠が揃うことを重視します。

IoT導入でBOI優遇を受けられますか？

個別条件によります。対象事業、土地・運転資金を除く投資額、対象機械の価値、実施期限などの現行要件を発注前にBOIやNSTDAなど関係機関へ確認してください。システム導入の技術評価と申請適格性は別に判断します。

まとめ：RFP・PoC・運用を一つの証拠の流れにする

海外拠点 IoT 導入では、センサー、ネットワーク、クラウド、画面を別々に買うのではなく、タイ工場の判断と日本側支援を一つの運用として設計します。ISA-95でシステム境界と情報責任を整理し、OPC UAやMQTTは具体的な情報モデルと障害挙動まで発注します。NIST SP 800-82 Rev.3を現行最終版のOTセキュリティ基準として参照し、Secure by Demandの考え方を供給者評価へ、NIST SP 1339の考え方を変更管理・バックアップ・復旧演習へ落とします。

90日PoCは、本番の縮小版としてデータ品質、通信断、遠隔アクセス、現地業務、バックアップ復元まで検証します。数値目標は根拠と測定定義を合意し、誇張した効果率を置きません。PoC後に現地が運用でき、次の設備へ同じ型で展開できることが、問い合わせ前に確認すべき最終成果です。

タイ工場IoTの構想をRFP、接続調査、90日PoC、運用設計へ落とし込みたい場合は、まだ対象設備や方式が固まっていない段階でもTOMAS TECHへご相談ください。既存PLCやERPを活かしながら、現地運用を止めない段階導入を一緒に整理できます。

参考資料

• NIST, SP 1339 OT Backup Quick Start Guide
• NIST, SP 800-82 Rev.3 Guide to Operational Technology Security
• NIST, Operational Technology Security Publications
• NIST, SP 1800-45 Cybersecurity for the Water and Wastewater Sector: OT Remote Access
• CISA et al., Secure by Demand Priority Considerations for OT Owners and Operators
• OPC Foundation, OPC UA Interoperability for Industrie 4.0 and IoT 2026
• International Society of Automation, ISA-95 Standard
• Thailand Board of Investment, Smart and Sustainable Industry

一次資料は2026年8月27日に確認しました。規格・ガイドは個別設備の安全評価やタイの法務・税務判断を代替しません。制度、製品版、サポート状況、申請条件は発注・申請直前に公式情報で再確認してください。