タイ トレーサビリティを輸出競争力につなげるには、「QRコードを付ける」「履歴を長く保存する」といった機能単位の導入では足りません。必要なのは、原材料の受入から製造、検査、梱包、出荷先までを同じ識別子とイベントで結び、顧客・監査・規制当局から求められた範囲だけを、根拠付きで素早く提示できる仕組みです。EUのDigital Product Passport(DPP)レジストリは2026年7月20日に稼働しましたが、これは全製品へのDPP義務が一斉に始まったという意味ではありません。本稿では、EU向け輸出を行うタイ工場が制度を過大解釈せず、RFPと90日PoCで「追えること」を証明する方法を整理します。
先に確認:DPPは全製品へ直ちに義務化されたのか
結論は「いいえ」です。欧州委員会のDPP案内によると、DPPは製品、部品、材料に関する情報を保持するデジタルな容器です。2026年7月にレジストリの枠組みが整備され、7月20日にレジストリが稼働したことは重要な技術基盤の前進です。しかし、Regulation (EU) 2024/1781、いわゆるESPRの第9条は、DPPを適用される委任法令に従って用意する構造を採っています。具体的な対象、データ項目、データキャリア、モデル・バッチ・個品のどの粒度で持つか、誰がどの情報へアクセスできるかは製品グループ別のdelegated actで定められます。
欧州委員会の2026年9月時点のタイムラインは、ESPRの委任法令採択後、事業者に少なくとも18か月の移行期間を設けると説明しています。したがって、レジストリが使える状態になったことと、自社のすべての輸出製品に法的義務が発生したことは別です。営業資料で「EU輸出品はすべて2026年からDPP必須」と書けば誤りになります。RFPではまず、自社の製品がどの規則・どの委任法令・どの適用日に該当するのかを製品分類ごとに確認する作業を、システム要件の前段に置くべきです。
2027年2月18日開始の電池パスポートは別の具体的な適用例
電池は具体化が先行する製品群です。欧州委員会が2026年8月21日に公表した更新ガイダンスは、電池パスポートに関する71のデータポイントを整理しています。ただし、この71項目はすべてのDPPに共通する固定フィールド数ではなく、EV電池、LMT電池、容量2kWh超の産業用電池について、各項目が必須・任意・特定条件で適用・当面不要のいずれかを示すための整理です。Regulation (EU) 2023/1542第77条により、対象となる電池をEU市場へ上市または使用開始する場合の電池パスポートは2027年2月18日から必要になります。
ここでも責任境界が重要です。欧州委員会は、完成電池を市場に出すeconomic operatorがパスポートを作成・維持する責任を負い、個々の部品やモジュールの供給者が直接その責任主体になるわけではないと説明しています。しかし、タイの材料・セル・モジュール・部品工場には、責任主体が必要なデータを契約仕様として要求してくる可能性があります。法的なパスポート作成主体でないから準備不要なのではなく、自社が供給すべき証拠範囲を顧客契約と製品別法令で切り分ける必要があります。
レジストリは詳細データをすべて中央保管する箱ではない
欧州委員会によると、DPP RegistryはEU市場に置かれる製品のパスポートを索引するサービスです。固有識別子、登録情報、高レベルのメタデータを保持しますが、DPPの詳細情報をすべて中央に格納する設計ではありません。詳細は原則として責任を負うeconomic operatorが分散型の仕組みで維持し、法令に基づくアクセス権に応じて提示します。
この構造をRFPへ翻訳すると、「DPPクラウドへ全データをアップロードできるか」という質問だけでは不十分です。どのデータを自社のERP、MES、QMS、LIMS、PLM、WMS、文書管理に置き、どの識別子で結び、誰が公開範囲を決め、どのサービスがレジストリ登録を担い、元データの変更をどう統制するかまで決める必要があります。

タイ工場のトレーサビリティで最初に定義すべき成果
トレーサビリティは「履歴を持っている状態」ではなく、指定した目的に対して、対象物の履歴または所在を特定できる能力です。製品安全、品質問題の封じ込め、顧客監査、偽造防止、保証、サステナビリティ、輸出規制では、必要な粒度も保持期間も閲覧者も異なります。目的を一つに束ねると、過剰収集と証拠不足が同時に起こります。
タイのTISIが公表するมตช. 22005-2567は、飼料・食品チェーンにおけるトレーサビリティシステムの設計と実施について、一般原則と基本要求事項を示す国家適合性評価規格です。2024年11月8日に官報掲載され、ISO 22005:2007の対象範囲に沿っています。これは全産業への一律の法的要件ではありませんが、「まず目的を決め、その目的を満たすシステムを設計・実施・内部評価・レビューする」という考え方は、食品以外の工場にも有用です。
GS1 Global Traceability Standardも、特定製品や単一ソフトウェアに閉じない形で、取引当事者をまたぐトレーサビリティを設計する枠組みを提供します。RFPの開始時には次の五つの成果を合意すると、機能一覧が現場の判断へつながります。
- 製造履歴追跡:完成品・半製品・原材料の関係、使用設備、工程条件、作業・検査結果を指定粒度で逆引きできる。
- 出荷先追跡:問題のあるロットまたはシリアルから、出荷、顧客、納入先、数量、残所在を前方追跡できる。
- 封じ込め判断:疑わしい範囲を「同日生産全部」ではなく、実際の変換・混合・分割・再加工関係から説明できる。
- 提出証拠:誰が、いつ、どの元データを承認し、どの版を顧客や監査へ出したか再現できる。
- 将来連携:製品別DPP要件、顧客ポータル、EPCISなどへ、元データの意味を崩さずに接続できる。
既存の費用構造を先に把握したい場合はタイのトレーサビリティシステム費用を、企業間のイベント共有はサプライチェーン・トレーサビリティとEPCISを参照してください。今回の記事は、EU DPPを見据えたRFPとPoCの受入証拠に焦点を絞ります。
QRコードより先に「識別子・関係・イベント」を設計する
QR、バーコード、RFID、刻印はデータキャリアであり、トレーサビリティそのものではありません。コードを読んだ先で、何を一意に識別し、どの関係とイベントを返せるかが本体です。
識別子:同じ番号が別の意味にならないこと
最低限、品目、製造ロット、個品シリアル、原材料ロット、荷姿・物流単位、場所、取引先、設備を区別します。顧客品番と自社品番、仕入先ロットと社内受入ロット、再梱包前後の物流単位を同じ欄に上書きすると、追跡の連鎖が切れます。番号体系は「人が見て分かる桁」より、発行主体、重複防止、廃番後の再利用禁止、取得時刻、ラベル再発行の統制を優先します。
DPPを視野に入れる場合は、製品別の法令がモデル、バッチ、個品のどの粒度を要求するかを後から割り当てられるようにします。最初から全製品を個品追跡にすると現場負担が過大になり、逆にロットだけで固定すると電池のような個品情報を求める制度や顧客要件へ対応できません。粒度はリスク、契約、工程特性、混合・分割の実態に応じて選択できる設計が必要です。
関係:変換、集合、分割、再加工を失わないこと
製造履歴は時系列ログを並べるだけでは再現できません。原料ロットAとBが半製品Cに混合され、Cが完成品DとEへ分割されたなら、A・B→C→D・Eという系譜を保持します。リワーク品が別ロットへ戻る、外注加工から複数荷姿で戻る、良品だけを選別して新ロットへ振り替える、といった例外も関係として残します。
この系譜があれば、上流へたどるtrace backwardと下流へたどるtrace forwardを同じ根から実行できます。自動車部品の要求へ展開する場合は、IATF 16949とタイのトレーサビリティも参考になります。
イベント:「いつ・どこで・何に・何が起きたか」を共通化する
GS1 EPCIS 2.0.1は、異なるアプリケーションが企業内外で可視化イベントを作成・共有するための標準です。JSON/JSON-LDの検証資産やRESTの問い合わせ定義も提供されています。RFPでEPCIS準拠を求めるかどうかは取引先と利用ケース次第ですが、イベントを次の観点で整理する方法は有効です。
- What:対象となる製品、ロット、シリアル、物流単位
- When:実行時刻と記録時刻、タイムゾーン
- Where:工程、設備、倉庫、出荷・受入場所
- Why:受入、投入、加工、検査、保留、解除、梱包、出荷などの業務段階と状態
- How:必要に応じたセンサー値、測定値、認証情報など
重要なのは用語をそのままシステム画面へ貼ることではありません。タイ語の現場用語、日本語の本社用語、顧客の英語コードを業務語彙へ対応付け、同じ出来事を別イベントとして二重計上しないことです。
タイ トレーサビリティのRFPに入れる12の質問
RFPは「機能あり/なし」のチェック表ではなく、ベンダーに責任境界と受入証拠を答えさせる文書です。少なくとも次の12項目を要求します。
- 対象と目的:どの製品・拠点・工程・顧客・制度を対象にし、どの意思決定時間を短縮するのか。
- 識別粒度:品目、ロット、シリアル、物流単位をどこで発番し、再利用と重複をどう防ぐか。
- 系譜:混合、分割、代替材、リワーク、外注、選別、再梱包をどう記録するか。
- イベント取得:ERP/MES入力、スキャナ、PLC、検査機、IoTゲートウェイのどれを正本とするか。
- 時刻と順序:ICT、UTC、日跨ぎシフト、遅延送信、時計ずれ、オフライン再送をどう扱うか。
- マスタ管理:品目、BOM、工程、設備、仕入先、顧客、場所、単位、版、有効日の所有者は誰か。
- データ品質:未入力、重複、矛盾、未知コードをどこで止め、誰が例外解除するか。
- 前方・後方検索:起点、応答時間、表示する数量・場所・出荷先、証拠の出力形式は何か。
- 外部共有:GS1/EPCIS、顧客API、CSV、ポータル、DPPサービスとの接続方式と版管理は何か。
- アクセス制御:公開、顧客限定、監査・当局限定、社内限定をフィールド単位でどう分けるか。
- 保持と変更証跡:保持期間、訂正理由、承認者、電子署名、バックアップ、復旧試験をどう扱うか。
- 運用責任:一次対応、データオーナー、インターフェース障害、ラベル再発行、SLA、変更管理を誰が担うか。
回答形式は、Standard、Configuration、Interface、Customization、Process Change、Unsupportedに分けます。「対応可能」だけでは比較できません。各回答に前提、担当、追加費用、保守、アップグレード時の再試験、PoCでの証明方法を添えさせます。

EU DPPを見据えたデータ責任マトリクス
DPPプロジェクトで起きやすい失敗は、必要項目を一つの部署へ丸投げすることです。製品識別は設計、材料情報は調達と仕入先、製造イベントは工場、品質結果はQMS、出荷先はERP/WMS、公開判断は法務・品質・営業など、情報源が分散します。RFPではデータ項目ごとに次を定義します。
- Legal source:どの規則、delegated act、顧客契約、社内基準から必要になるか
- Applicability:必須、任意、条件付き、非該当を誰が決めたか
- Source system:元データの正本と取得インターフェース
- Granularity:モデル、バッチ、個品、出荷単位のどれか
- Owner:意味、正確性、承認、訂正に責任を持つ部署
- Visibility:一般公開、取引先、監査・当局、社内などの閲覧範囲
- Update trigger:設計変更、製造完了、検査、修理、再利用など更新の契機
- Evidence:値の由来、承認、変更履歴を何で証明するか
- Retention:製品寿命や契約、法令に応じた保持期間
このマトリクスがあれば、新しい委任法令が出たときも「DPP機能を追加購入する」前に、既存データで充足できる項目、仕入先から新たに集める項目、工程取得を追加する項目を区別できます。
90日PoC:製品デモではなく追跡証拠を作る
以下の90日は計画例であり、法定期限、業界標準、成功保証ではありません。対象製品、拠点数、設備、取引先、データ品質によって調整してください。目的は短期間で本番を完成させることではなく、投資判断に必要な不確実性を順番に潰すことです。
Day 1–15:対象製品、法令、顧客要求、責任を固定する
輸出製品を一つ、代表ラインを一つ、出荷先を一つ選びます。製品分類と適用法令は専門家と確認し、現在必要な証拠と将来候補を分けます。対象電池ならRegulation (EU) 2023/1542と最新ガイダンスを使い、それ以外はESPRの該当delegated actの有無を確認します。「DPP対応」という抽象語を禁止し、ユースケースを、たとえば「顧客クレームのシリアルから使用原料ロット、検査結果、同じ原因で影響を受ける製品範囲、出荷先を再現する」と書きます。
成果物は、適用性メモ、Current Process、識別子一覧、データ責任マトリクス、例外一覧、PoC受入表です。法的判断とシステム判断を同じ担当に任せません。
Day 16–30:現物とデータの流れを一致させる
受入、保管、払出、加工、混合・分割、検査、梱包、出荷を現場で観察します。帳票上の標準工程だけでなく、ラベル破損、代替材、リワーク、バルク投入、端数、夜勤、ネットワーク断、手入力訂正を追います。各地点で「現物の識別子」「読取手段」「入力者」「元システム」「次工程へ渡す関係」を記録します。
この段階で大きな穴が見つかっても、すべてを自動化しません。影響の大きい系譜欠落と出荷先欠落を優先し、手順で補う範囲と機器を追加する範囲を分けます。
Day 31–60:代表シナリオを一本つなぐ
ERP、MES、QMS、WMS、IoTなどから必要なイベントを取り込み、選んだ製品の上流・下流を結びます。EPCISを外部共有に使う場合も、まず社内イベントの意味と品質を整えます。正常系だけでなく、分割、混合、リワーク、外注、保留解除のうち実際に頻発する二つ以上をPoCへ入れます。
画面を見せることより、同じ入力から同じ追跡結果と証拠パッケージを再生成できることを優先します。ユーザーがタイ語で入力しても、顧客へ英語で意味の整った出力を作れるか確認します。
Day 61–75:障害と権限制御を壊して試す
スキャナ停止、ネットワーク断、重複送信、時刻ずれ、未知品番、ラベル再発行、インターフェースのタイムアウト、誤った出荷先紐付けを意図的に発生させます。システムが黙って欠損を受け入れないか、再送で二重イベントにならないか、訂正が元の記録を消さないかを確認します。
さらに、一般公開ユーザー、顧客、社内品質、管理者の役割を切り替え、見えてはいけない原価、仕入先条件、個人情報、営業情報が露出しないことを試験します。DPPは公開ページを作るだけの企画ではなく、アクセス権の設計が中核です。
Day 76–90:模擬監査とRFPのGo/No-Goを行う
現場担当者だけでなく、品質、営業、IT、管理職が同じケースを使って模擬クレームまたは回収判断を行います。開始時刻、質問、検索過程、除外根拠、出力、承認、完了時刻を記録し、未解決項目をRFPへ戻します。ベンダーの説明ではなく、PoCログ、照合表、権限テスト、障害復旧結果を契約ゲートの証拠にします。

PoC受入基準の例
次の数値は説明用の目標例であり、外部統計や保証値ではありません。自社のリスク、量、シフト、顧客SLAから設定してください。
| 受入観点 | 例示する試験 | 例示する判定方法 |
|---|---|---|
| 系譜完全性 | 選定した代表シリアル・ロットを上流へ追う | 必須工程・原料・検査の関係に未説明欠落がない |
| 出荷先追跡 | 疑義ロットから下流を検索 | 出荷先、数量、出荷日、残所在が出荷記録と照合する |
| 混合・分割 | 一対多、多対一、リワークを再現 | 影響範囲が事前作成した期待結果と一致する |
| 応答時間 | ピーク相当データで検索 | 自社が定めた時間内に結果と証拠を出せる |
| オフライン | 回線を遮断して復旧 | 欠落・二重登録なく、遅延が識別できる |
| データ品質 | 未知コード、必須欠落、時刻矛盾を投入 | 自動拒否または承認付き例外として残る |
| 権限 | 役割別に同じDPP参照を実行 | 非許可フィールドがAPI・画面・出力の全経路で隠れる |
| 訂正証跡 | 誤データを承認付きで訂正 | 旧値、理由、申請者、承認者、時刻を再現できる |
| 災害復旧 | バックアップから模擬復元 | 決めた復旧点・復旧時間と照合し、追跡連鎖を再確認する |
「検索結果が表示された」で合格にせず、期待結果と元帳を先に凍結します。ベンダーが作ったデモデータだけではなく、匿名化した実データ、実際の例外、タイ工場のネットワーク条件、現場ユーザーを使うことが重要です。
製造履歴追跡を止めない統合アーキテクチャ
最適な構成は工場ごとに異なりますが、責任を分ける基本線は共通です。
- ERP:受注、購買、品目、BOM、製造指図、在庫、出荷、顧客などの業務記録
- MES/QMS/LIMS:工程実績、設備、作業者資格、検査、判定、逸脱、リワーク
- WMS/バーコード/RFID:保管場所、荷姿、移動、ピッキング、梱包、出荷読取
- IoT/PLC/ゲートウェイ:装置状態、実測値、タイムスタンプ、エッジでの一時保持
- Traceability repository/EPCIS:識別子間の系譜とイベントの横断検索・共有
- DPP service:製品別スキーマ、公開・制限情報、データキャリア、レジストリ連携
すべてを一つのデータベースへ複製する必要はありません。追跡に必要な最小イベントと元データ参照を決め、訂正は元システムの統制を保ちながら伝播させます。集約側で自由に値を書き換えると、証拠の正本が不明になります。
オフラインと時刻はタイ工場で必ず試す
工場ネットワークが一時的に切れる場合、端末やゲートウェイでキューイングし、event timeとrecord timeを分け、再送IDで重複を防ぎます。ICTとUTC、本社時刻を混在させず、保存形式と表示形式を定義します。日跨ぎシフトでは、カレンダー日と生産日の両方を持つ必要がある場合があります。
手入力の代替手順も設計対象です。緊急時に紙へ記録するなら、誰が後入力し、どの範囲を保留し、原記録をどう添付し、二重入力をどう防ぐかを受入試験へ入れます。
出荷先追跡と模擬回収で「範囲を説明できる」状態を作る
出荷先追跡の目的は、単に顧客名を表示することではありません。問題起点から、影響した個品・ロット、荷姿、出荷伝票、納入先、数量、出荷日、返品・在庫・仕掛の所在を一貫して数えられることです。総生産数、廃棄、検査サンプル、在庫、出荷、返品の数量収支が合わなければ、結果を狭く見せても信頼できません。
模擬回収では、疑義のある原料ロットを一つ選び、使用先を前方追跡します。次に、顧客クレームの完成品シリアルから材料と工程を後方追跡し、両者が同じ系譜で説明できるかを確認します。影響外と判断した製品にも、除外できる根拠が必要です。
DPPはこの基礎を置き換えません。公開情報の見せ方を整えても、工場内部の系譜が欠落していれば、正確で最新のデータを維持できません。反対に、堅牢なイベントと責任体系があれば、新しい製品別スキーマへ必要な項目をマッピングしやすくなります。
仕入先と顧客を巻き込む段階導入
海外工場のトレーサビリティは、一社の工場内だけで完成しません。しかし最初から全仕入先へ同じAPIを要求すると止まります。次の順序が現実的です。
- 重要製品と重要材料をリスクで絞る。
- 現在受け取れるCOA、ロット、原産・材料情報、出荷データを棚卸しする。
- 必須識別子、単位、時刻、訂正、版の最小契約仕様を作る。
- CSV/ポータル/API/EPCISなど複数の接続段階を許し、意味は共通辞書で固定する。
- データ品質のスコアと例外処理を共有し、いきなり罰則だけを置かない。
- 顧客への公開範囲と、仕入先の機密情報を分離する。
企業間共有で「同じフィールド名」を揃えるだけでは不十分です。単位、コード体系、イベントの意味、タイムゾーン、更新・取消方法を契約します。EPCISを採用する場合も、Business StepとDispositionの語彙、識別子発行、検索権限を双方で合意します。
BOI支援はシステム設計と切り分けて確認する
Thailand BOIのSmart and Sustainable Industry向け産業高度化措置は、製造・サービスの効率向上や事業高度化を支援する枠組みです。現行の英語案内では、効率向上投資の最低額を土地代・運転資金を除いて100万バーツとし、機械の輸入関税免除や、条件に応じた法人所得税優遇を説明しています。国内自動化産業と連携する機械等の比率に関する条件も示されています。
ただし、トレーサビリティ導入なら自動的に対象になるわけではありません。対象活動、既存・新規事業、投資項目、申請時期、国内開発・認証、完了期限などをBOIの最新公告と担当窓口、適切な税務・法務アドバイザーへ確認してください。RFPでは「補助・優遇が無くても成立する基本ケース」と「承認された場合のケース」を分け、制度採択をROIの前提にしないことが安全です。
運用KPI:導入後に毎月確認する指標
システム稼働を成功条件にせず、次を継続監視します。目標値はPoCでベースラインを測ってから自社で設定します。
- 追跡対象イベントの完全率と期限内記録率
- 未知コード、重複、時刻逆転、未解決例外の件数
- 代表シリアル・ロットの前方/後方追跡完了時間
- 数量照合の差異と原因区分
- ラベル再発行、手入力、オフライン再送の頻度
- 仕入先データの期限遵守率と修正リードタイム
- 権限違反、過剰公開、監査ログ欠落の検出件数
- 模擬回収での影響範囲確定・承認・通知準備時間
- DPPまたは顧客提出データの更新遅延と差戻し件数
KPIは現場を罰する道具にせず、どの工程・インターフェース・マスタで証拠が切れているかを見つける信号にします。未入力率だけを追うと、意味のない仮値入力が増えるため、正確性、適時性、整合性を組み合わせます。
よくある質問
EU DPPは2026年からすべての製品に義務ですか?
いいえ。DPP Registryは2026年7月20日に稼働しましたが、ESPRの具体的なDPP要求は製品グループ別delegated actで段階的に適用されます。欧州委員会は委任法令採択後に少なくとも18か月の移行期間があると案内しています。自社製品の分類と最新法令を確認してください。
電池パスポートはいつ、どの電池が対象ですか?
Regulation (EU) 2023/1542第77条では、2027年2月18日から、EU市場に置かれるEV電池、LMT電池、容量2kWh超の産業用電池が対象です。欧州委員会の2026年8月21日ガイダンスは71のデータポイントとカテゴリ別適用性を整理していますが、最新文書と自社の役割を個別に確認する必要があります。
タイのトレーサビリティ導入は何から始めますか?
製品やツールの選定より先に、対象製品、追跡目的、起点と終点、必要粒度、意思決定者、出すべき証拠を定義します。代表製品一本で現物とデータの流れを照合し、混合・分割・リワーク・ネットワーク断を含むPoCを行うと、RFPの不確実性を減らせます。
QRコードだけで製造履歴追跡はできますか?
QRコードは識別子やURLを運ぶ手段です。製造履歴には、原料と完成品の系譜、工程・検査イベント、訂正証跡、出荷先、数量照合、権限制御が必要です。コードを貼る前に識別子、関係、イベント、データ責任を設計してください。
EPCIS 2.0.1は必須ですか?
すべての工場に一律必須ではありません。複数企業・複数システムで可視化イベントを共有する際の有力な標準ですが、顧客契約や製品別要件に応じて判断します。採用する場合も、内部データの品質と語彙の合意が先です。
90日PoCで本番導入まで終わりますか?
本稿の90日は投資判断のための例です。本番全体を完成させる期間ではありません。代表製品・ライン・出荷先を限定し、系譜、例外、権限、障害、証拠出力を検証して、拡張可否と契約条件を判断します。
まとめ
EU DPP時代のタイ トレーサビリティで重要なのは、制度名を先取りして大きなシステムを買うことではありません。2026年7月20日のDPP Registry稼働は共通基盤の重要な前進ですが、ESPRの義務は製品別delegated actで段階適用されます。電池はRegulation (EU) 2023/1542に基づき、特定カテゴリで2027年2月18日から具体的に始まります。この境界を正しく理解したうえで、識別子、系譜、イベント、出荷先、データ責任、アクセス権、訂正証跡を整えることが、現在の品質課題と将来のDPP対応の両方に効きます。RFPには責任と受入証拠を求め、90日PoCでは実データ、例外、障害、権限を壊して試してください。
TOMAS TECHは、タイ工場の現物・データフロー調査、トレーサビリティRFP、ERP/MES/WMS/IoT連携、前方・後方追跡、EPCISを含む企業間共有、90日PoCの受入設計を支援できます。製品別DPPの適用確認を進めながら、まだ製品やベンダーを決めていない段階でもお問い合わせいただけます。
リサーチソース
- European Commission, Digital Product Passport
- European Commission, The DPP Registry
- EUR-Lex, Regulation (EU) 2024/1781 (ESPR)
- European Commission, Guidance to support preparations for the Digital Batteries Passport, 21 Aug 2026
- EUR-Lex, Regulation (EU) 2023/1542 on batteries and waste batteries
- GS1, Global Traceability Standard 2.0
- GS1, EPCIS Standard 2.0.1
- TISI, มตช. 22005-2567
- Thailand BOI, Smart and Sustainable Industry