タイ工場システム導入2026｜発注先・費用・RFPの決め方
タイ 工場 システム導入を検討するとき、最初に製品デモを並べると判断が早くなったように見えます。しかし、現場の課題、対象工程、既存システムとの境界、データの責任者、合格を証明する方法が曖昧なままでは、比較しているのは製品ではなく各社が独自に解釈した別々の案件です。タイ拠点と日本本社、現地語と日本語、ITとOT、業務部門と管理部門がまたがる案件ほど、機能数や人月単価より「誰がどこまで責任を持ち、何を証拠として引き渡すか」を先に決める必要があります。
本稿では、製造業がRFP、候補選定、予算申請、契約、受入、運用移管までを一つの意思決定パッケージとして整える方法を解説します。TOMAS TECHはタイ・ASEANの工場IT／OT／FA統合パートナーとして実装を支援しますが、法務・税務当局でも投資恩典の保証者でもありません。制度や契約の最終判断は、必ず所管機関と専門家へ確認してください。
1. タイ工場のシステム導入に「二国・二言語」の意思決定が必要な理由
タイの製造業は経済と雇用の大きな基盤です。世界銀行の「Thailand Economic Monitor, February 2026」は、製造業がGDPの25%、雇用の16%、620万人超の雇用を占めるとし、同版では2026年の成長率を1.6%と予測しました。これは2026年2月時点の予測であり実績値ではありませんが、生産性、デジタル化、投資規律を同時に考える必要性を示す背景になります。
タイ工場案件では、単に日本で決めた仕様を翻訳して渡すだけでは足りません。本社は投資対効果、内部統制、グループ標準、連結データを重視し、工場は停止時間、入力負荷、設備接続、現場での復旧性を重視します。さらに、日本語の「在庫」「仕掛」「完了」「不良」の定義が、英語やタイ語の画面項目に移る過程で変わることがあります。言葉が翻訳されても、判断条件が翻訳されているとは限りません。
したがって意思決定を二層に分けます。第一層は本社と現地経営が合意する「なぜ投資するか、何を変えるか、どこまで許容するか」。第二層は現場と実装者が合意する「どのデータを、いつ、誰が、どの操作で確定するか」です。この二層を同じRFPと受入証跡に接続できれば、承認後に要件が蒸し返されるリスクを減らせます。
案件の共通言語として、少なくとも次の四つを日英または日泰併記で定義します。
| 共通言語 | 決める内容 | 曖昧な場合の典型的な問題 |
|---|---|---|
| 業務イベント | 着工、完了、検査、払出、移動、出荷を何で確定するか | 部門ごとに実績時刻が異なる |
| マスタ責任 | 品目、BOM、工程、設備、取引先を誰が承認するか | ERPと現場台帳が分岐する |
| 例外処理 | 欠品、手直し、設備停止、通信断をどう記録するか | 正常系だけ動き、現場がExcelへ戻る |
| 証跡 | 誰が、いつ、何を変更・承認したか | 受入や監査で根拠を提示できない |
2. 業務課題、目標工程、システム境界、ベンダー範囲を分ける
RFPの冒頭に製品名を書く前に、四つの箱を分離します。混ぜると、ベンダーは提案しやすい部分だけを自社範囲と解釈し、発注者は全体が含まれると思い込むからです。
業務課題は「症状」ではなく損失の発生構造で書く
「進捗が見えない」「在庫が合わない」は症状です。RFPでは、どの判断が遅れるのか、どの記録が後追いになるのか、誰が照合作業をしているのか、問題発見から復旧まで何が途切れるのかを書きます。金額を置けない場合でも、発生頻度、対象工程、影響を受ける役割、現在の確認方法は記述できます。未計測の数値を埋めるより、基準値を取る手順を要件にした方が正確です。
目標工程は画面ではなく業務の状態遷移で書く
「生産実績入力画面が欲しい」ではなく、「作業指示が発行済みから着工済みへ変わる条件」「完了数と不良数が確定する責任者」「ロット分割時に元ロットとの関係を保持する方法」を書きます。画面は実現手段であり、状態遷移が要件です。
システム境界は入出力と記録の正本で書く
ERP、生産管理、WMS、設備、表計算、本社データ基盤のどこがマスタかを決めます。同じ情報を複数システムが更新できる設計は、短期的には便利でも、障害時にどちらが正しいか判定できません。境界図には、送信元、受信先、データ所有者、更新方向、頻度、失敗時の再送、照合方法を添えます。
ベンダー範囲は成果物と責任で書く
「導入支援一式」では比較できません。Fit & Gap、設定、追加開発、データ移行、設備接続、テスト支援、教育、稼働後支援、文書化、ソースコードや設定の引渡しを行単位にし、Responsible、Approver、Contributor、Informedに近い役割分担を明示します。契約の論点はシステム開発契約の実務ガイドも参照してください。
3. 五つの調達ルートをどう選ぶか
調達方式は優劣ではなく、変更したい業務と守りたい標準の組み合わせで選びます。
| ルート | 向く状況 | 主な確認点 | 避けたい誤解 |
|---|---|---|---|
| パッケージ | 標準業務へ寄せられ、早期に統一したい | タイ語、税務周辺連携、権限、アップグレード | 標準機能なら業務変更が不要と思うこと |
| 設定型パッケージ | 標準を軸に承認経路や帳票を調整したい | 設定と追加開発の境界、将来更新 | 「設定可能」が保守影響なしを意味すること |
| ローコード | 部門ワークフローを短い反復で改善したい | ガバナンス、ライセンス、性能、退職者依存 | 試作がそのまま工場本番品質になること |
| 個別開発 | 差別化工程や固有制御が中核にある | 要件所有、テスト資産、保守要員、出口 | 自由度が変更費用を消すと思うこと |
| 統合主導ハイブリッド | ERPや既存設備を残し、接続と可視化を強化したい | インターフェース責任、監視、データ整合 | 接続すれば業務定義も自動で統一されること |
選定では「必要機能を何個持つか」だけでなく、「標準から外れる要求を誰が管理するか」を比較します。例えばパッケージが多くの機能を持っていても、工場固有のロット追跡で追加開発が集中すれば、保守上の中心は標準機能ではなく拡張部分です。逆に既存ERPを残す統合型でも、データ所有と障害復旧が明確なら、全面刷新より管理しやすい場合があります。
第一回の候補説明会ではデモを依頼する前に、同じ業務シナリオと同じ例外を提示します。ベンダーが準備した成功シナリオではなく、通信断、未登録品目、分納、手直し、誤入力訂正などをどう処理し、どんなログを残すかを見ます。この比較で、製品能力だけでなく実装チームの解像度が分かります。
4. タイ、日系、グローバル、共同チームの使い分け
タイのローカルベンダー
現地での訪問、タイ語教育、工場の勤務時間に合わせた支援、ローカル機器やネットワークへの対応が重要なら有力です。ただし「現地だから現場を理解している」とは限りません。製造工程の経験、文書言語、本社報告、担当者交代時の継続性を確認します。
日系ベンダーまたはタイの日系ITベンダー
本社との合意形成、日本語の要件整理、稟議や品質観点の共有に強みを出しやすい一方、実作業を現地パートナーへ再委託する構造では責任境界が増えます。営業窓口ではなく、設計、開発、現地テスト、稼働後支援を実際に担う法人と担当を確認します。
グローバルベンダー
複数国テンプレート、製品ロードマップ、グローバル統制を重視する場合に合います。一方で、グローバル標準の変更手続きとタイ工場の緊急性が噛み合うか、地域サポートの時間帯、言語、エスカレーション先を確認する必要があります。
共同チーム
本社側の標準ベンダー、タイの現場統合ベンダー、設備メーカーを組み合わせる方式です。能力を補完できますが、統合責任者が不在だと障害が境界を巡回します。共同チームを選ぶなら、一つの課題台帳、一つの統合工程表、一つの受入責任表を使い、総合テストの指揮者を指名します。
結論として、国籍や会社規模ではなく、案件の責任面を覆える組み合わせで選びます。TOMAS TECHは、タイ・ASEANの工場でIT、OT、FAの間に落ちやすい接続、現場検証、運用移管を含めた統合役を担えます。
5. RFPの入力チェックリストと要求成果物
よいRFPは仕様を固定しすぎる文書でも、ベンダーへ設計を丸投げする文書でもありません。比較可能な前提と、提案で埋めてほしい空欄を区別した文書です。
発注者が渡す入力
- 投資目的、対象拠点、対象工程、対象外範囲
- 現行業務フローと例外、既知の問題、基準値の有無
- システム構成図、ネットワーク区分、設備一覧
- 品目、BOM、工程、在庫、ロット等のデータ辞書とサンプル
- 本社標準、承認者、現地責任者、利用言語
- 停止可能時間、繁忙期、教育対象、サポート時間帯
- セキュリティ、プライバシー、監査、保存、委託先に関する社内条件
- 契約、知的財産、ライセンス、データ返却、終了時移行の基本方針
不足資料は隠さず「現時点で未整備」と明示し、現状調査を提案範囲に含めます。データ品質が未確認なのに固定価格の移行を求めると、ベンダーは大きな予備費を積むか、前提条件を狭くして後から変更扱いにします。
ベンダーに求める成果物
| 段階 | 最低限の成果物 | 受入の観点 |
|---|---|---|
| 提案 | 前提・除外・体制・工程・見積根拠・リスク一覧 | 比較単位が揃っているか |
| 要件 | 業務フロー、要件一覧、Fit & Gap、データ辞書 | 発注者の承認記録があるか |
| 設計 | 構成、権限、インターフェース、例外、監視、復旧 | 正常系だけでなく失敗系があるか |
| 構築 | 設定表、ソース、変更履歴、単体・結合証跡 | 再現可能で引継ぎ可能か |
| 移行 | 移行計画、変換、照合、リハーサル、戻し手順 | 件数だけでなく内容が一致するか |
| 受入 | シナリオ、結果、課題、残件、承認 | 合格条件と例外承認が追えるか |
| 運用 | 手順、監視、連絡網、SLA前提、教育、出口資料 | 現地チームだけで初動できるか |
RFPには回答様式も付けます。「対応可能」だけではなく、標準、設定、追加開発、外部製品、対象外のどれかを選び、根拠資料、前提、担当、費用区分を記入させます。これにより、安く見える提案が単に範囲を外しているだけかどうかを判別できます。
6. ERP、生産管理、WMS、設備、Excel、本社をつなぐデータフロー台帳
インターフェース一覧はAPI名の表ではありません。業務上の「約束」を表す台帳です。
| 台帳項目 | 確認する質問 |
|---|---|
| 業務イベント | 何が起きたときにデータを送るか |
| 送信元・受信先 | どちらが正本で、どちらが参照か |
| キー | 品目、指図、ロット、設備を何で一意にするか |
| 方向・頻度 | 即時、定期、手動のどれか。再送は可能か |
| 変換 | 単位、時刻、コード、桁、言語をどう変えるか |
| エラー | 誰に通知し、どこで保留し、誰が再開するか |
| 照合 | 送受信の件数と内容をどう一致確認するか |
| 変更 | 仕様変更を誰が承認し、どこへ通知するか |
例えばERPが製造指図を送り、生産管理が実績を返し、WMSが払出と入庫を担い、設備が測定値を出す場合、日付境界、単位変換、ロット分割、取消の伝播を決める必要があります。Excelが残る場合も「暫定だから対象外」とせず、誰がテンプレートを管理し、どの列を取り込み、重複や旧版をどう拒否するかを設計します。
本社システムへの連携では、タイ時間と本社時間、現地締めと連結締め、現地品目とグローバル品目の対応を確認します。多拠点の標準化を同時に考える場合は、複数工場の生産管理統合ガイドも有用です。
データフロー台帳は設計時だけでなく、テスト、障害調査、運用引継ぎ、将来のベンダー交代にも使います。ベンダー固有の図面だけに情報を閉じ込めず、発注者が更新できる形式と責任者を決めることが重要です。
7. 受入基準を「確認した」から「証明できる」へ変える
受入基準は契約末尾のチェック欄ではなく、要件からテストまでをつなぐ設計です。各要件に識別子を付け、設計、設定またはコード、テストシナリオ、結果、証跡、残件を紐づけます。
機能テストだけでは工場運用を証明できません。少なくとも次の証跡を案件特性に合わせて組み合わせます。
- 正常系と例外系の業務シナリオ
- 権限別の表示・操作・承認結果
- ERP、WMS、設備、本社連携の送受信と再処理ログ
- 移行前後の主要データ照合
- 障害、通信断、バックアップ、復旧の訓練記録
- タイ語、英語、日本語の表示と教育資料の確認
- 性能条件を発注者が定義した場合の測定条件と結果
- 未解決事項、暫定回避、期限、責任者を含む残件台帳
「ユーザーが確認したので合格」では、後から何を確認したか分かりません。スクリーンショットだけでも、操作前提やデータが分かりません。テストケース、入力データ、期待結果、実結果、ログや画面証跡、実施者、承認者を一つの単位として保存します。
合否を二択にせず、条件付き受入の扱いも契約前に決めます。業務停止を伴わない軽微な残件と、データ欠損や出荷判断へ影響する重大な残件を同列に扱わず、例外承認者、期限、支払や保証との関係を明確にします。これは法的助言ではなく、プロジェクトの判断記録を欠落させないための実務設計です。
8. セキュリティ、プライバシー、サプライチェーン、事故・終了条項
工場システムでは、ITサーバーだけでなく、設備PC、ゲートウェイ、リモート保守、クラウド、外部ライブラリ、再委託先がつながります。RFPには製品の機能チェックだけでなく、供給者へ伝える要求と、運用中に証明する方法を含めます。
NIST SP 1305は、CSF 2.0のサプライチェーン成果を使ってサイバーサプライチェーンリスク管理を整え、供給者要求を定義・伝達する考え方を説明しています。NIST SP 800-18 Rev. 2は、システムセキュリティ、プライバシー、サイバーサプライチェーンリスクの三つの関連計画を示し、システム、データフロー、環境、役割、管理策の情報を集約すると説明しています。いずれも任意のガイダンスであり、タイ法への適合や個別案件の安全性を保証するものではありません。それでも、RFPと運用文書の抜けを点検する参照枠として有効です。
RFP・契約・運用設計では、次を案件に応じて確認します。
- アカウント発行、権限変更、退職・異動時の削除
- 多要素認証、特権操作、リモート接続の承認と記録
- 脆弱性情報、修正方針、サポート終了の通知
- ログの種類、保存、時刻同期、閲覧権限、調査への提供
- バックアップ対象、復元方法、復旧時のデータ照合
- インシデント連絡先、初報内容、封じ込め、証拠保全、再発防止
- 個人情報や機密製造データの所在、アクセス、移転、削除
- 再委託先、クラウド、部品・ライブラリの管理
- 契約終了時のデータ返却、形式、移行支援、資格情報の無効化
- ソース、設定、文書、管理者権限の引渡し条件
条文を多くするだけでは安全になりません。誰が要求を審査し、どの証跡をいつ受け取り、逸脱を誰が承認するかまで決めます。タイの法令適合、越境データ、税務、知的財産については、対象データと契約構造を示したうえで適切な専門家へ確認してください。
9. 根拠のない相場を使わず、費用構造を比較する
タイのシステム導入費用を、根拠のない「一般的な相場」や一つの人月単価で判断するのは危険です。同じ製品でも、拠点数、ユーザー、設備点数、連携、データ品質、言語、稼働時間、責任範囲で総費用は変わります。本稿では市場平均の金額や比率は示しません。
代わりに、見積を次の費用バケットへ分解します。
| 費用バケット | 含める候補 | 比較時の質問 |
|---|---|---|
| 発見・要件 | 現状調査、ワークショップ、Fit & Gap | 成果物と承認回数は何か |
| 製品・基盤 | ライセンス、クラウド、端末、ネットワーク | 数量増減と更新条件は何か |
| 設定・開発 | 設定、帳票、ワークフロー、追加開発 | 標準と個別の境界はどこか |
| 統合 | API、ファイル、設備、監視、再送 | 接続先側の改修を含むか |
| データ | 整備、変換、移行、照合、リハーサル | 発注者作業と品質前提は何か |
| 検証・教育 | テスト支援、教材、現場教育、多言語対応 | 再試験と再教育を含むか |
| 移行・稼働 | 切替、立会い、初期安定化、出張 | 工場時間外や休日条件は何か |
| 運用 | 保守、監視、問い合わせ、改善 | 対応時間、範囲、除外は何か |
| リスク・終了 | 予備費、データ返却、移行支援 | 変更と契約終了の単価根拠は何か |
初期費用だけでなく、変更一件あたりの見積手順、年次更新、利用量増加、機器交換、OSや製品のサポート終了、ベンダー交代時の費用を比較します。安価な提案が、データ整備、現地教育、総合テスト、稼働支援を発注者側へ移していないかを見ます。
承認資料では「最安案」と「推奨案」の差を機能表だけで説明せず、発注者が保持するリスク、社内工数、停止時の復旧責任、将来変更の自由度として示します。IT投資の承認プロセスと接続すると、RFP評価と稟議の論点を揃えやすくなります。
BOI・depa制度を予算へ織り込む際の注意
タイBOIの2026年上期発表では、Smart and Sustainable Industryの下で、機械更新、デジタル技術、自動化、ロボティクスに関する132件、約172億THBの申請があり、BOIは上期全体で1,300プロジェクト、約1.31兆THBを承認したとしています。これは個別読者の案件が恩典対象になる証拠ではありません。
BOI Investment Promotion Guide 2026には、組織内で連携するシステム、AI・データ分析、ソフトウェア・情報システム、クラウド・データセンター支出に関するデジタル技術の効率化措置が含まれますが、条件や算入ルールは一様ではありません。タイ国内の事業者が開発または改修したソフトウェアと、認定機関の証明が必要となる場合もあります。対象、上限、期限は申請者と案件ごとにBOIへ確認してください。
depaはThailand Digital Catalog、条件を満たす登録デジタル製品・サービスに関するTax 200%措置、申請者当たり50%、最大200,000 THBを支援すると説明したAI Transformationマッチングファンドを案内しています。ただし募集期間、SME要件、登録要件、対象製品・サービス、税務上の取扱いは変わり得ます。採択や税効果を前提に予算を確定せず、最新の公式条件を確認してください。
10. 選定からパイロットまでの12週間例示計画
以下はTOMAS TECHが議論のたたき台として示す12週間の例示モデルです。市場平均、標準工期、成果保証ではありません。対象工程、設備停止、データ品質、承認速度、調達手続きに応じて組み替えます。
| 期間 | 主な活動 | ゲートと成果物 |
|---|---|---|
| 第1〜2週 | 課題、対象工程、基準値、関係者、境界の確認 | プロジェクト憲章、現状・目標フロー |
| 第3週 | データ、設備、連携、セキュリティ、運用制約の整理 | RFP入力一式、データフロー初版 |
| 第4週 | RFP発行、説明会、質問管理 | 共通回答と更新済みRFP |
| 第5〜6週 | 提案回答、同一シナリオデモ、前提確認 | 比較可能な提案書と論点一覧 |
| 第7週 | スコアリング、参照確認、リスク対話 | 候補順位、条件付き事項 |
| 第8週 | スコープ、責任、価格、契約論点の合意 | 選定ゲート、交渉記録 |
| 第9〜10週 | パイロット設計、設定・接続、テスト準備 | パイロット環境、試験シナリオ |
| 第11週 | 業務・連携・障害・運用の検証 | 証跡、課題、是正計画 |
| 第12週 | 結果評価、本番計画、継続可否判断 | パイロット受入、本番ロードマップ |
短く見せるために承認を省略せず、各ゲートの決裁者と期限を最初に押さえます。特に、現場が試せるデータと設備時間、本社が確認する設計・セキュリティ資料、調達・法務が確認する契約資料は並行で準備します。
パイロットは「動く画面を見せる期間」ではありません。本番化の不確実性を減らす実験です。最も難しい連携、最も頻出する例外、運用担当の初動、証跡の取得、変更手続き、終了時のデータ取り出しを小さな範囲で確認します。簡単な正常系だけ成功しても、本番判断の材料は増えません。
11. ベンダースコアカードとレッドフラッグ
以下のスコアカードもTOMAS TECHの例示モデルであり、市場標準や成果保証ではありません。配点を固定するのではなく、経営、工場、IT、調達が重要度と判定根拠を合意してから使います。
| 評価軸 | 証拠として求めるもの | 見極めたい点 |
|---|---|---|
| 業務理解 | 目標フロー、例外、未決事項 | デモ機能を課題へ正しく結び付けたか |
| 技術適合 | 構成、Fit & Gap、性能前提 | 標準・設定・開発の境界が明確か |
| 統合能力 | データフロー、再送、監視、照合設計 | IT／OT／FAの境界を覆えるか |
| 実行体制 | 実名役割、稼働場所、言語、代替要員 | 営業説明と実装体制が一致するか |
| セキュリティ | 管理策、証跡、事故対応、再委託情報 | 要求へ具体的に回答しているか |
| 移行・受入 | 移行、試験、戻し、残件管理 | 合格を再現可能に証明できるか |
| 運用・出口 | 支援、文書、権限、データ返却 | 稼働後と契約終了後を扱えるか |
| 費用透明性 | 前提、数量、単価根拠、変更条件 | 安さが範囲外しに依存しないか |
レッドフラッグは、機能不足だけではありません。
- 質問に対して「できます」だけで、標準・開発・外部サービスの区別がない
- 見積前提や対象外が提案書の別ページに散らばっている
- 現地担当、設備担当、セキュリティ担当が選定中に見えない
- データ移行を件数一致だけで合格にする
- インターフェース障害の監視、再送、照合の責任者がいない
- タイ語教育を翻訳資料の納品だけで終える
- 検収条件が「本番稼働」だけで、証跡と残件の扱いがない
- 変更単価はあるが、変更か瑕疵かを決める手続きがない
- 契約終了時のデータ形式、設定、ソース、管理者権限の引渡しが曖昧
- 投資恩典や税効果を、個別確認なしに確実な値引きとして扱う
価格交渉の前にレッドフラッグを解消すると、候補間の責任差が見えるようになります。価格が高いか低いかではなく、その価格で誰の仕事とどのリスクまで含むかを比べてください。
12. よくある質問
タイ 生産管理システムとは、ERPや設備監視と何が違いますか？
生産管理システムは一般に、計画、指図、進捗、実績、仕掛、品質、ロット等の製造業務を扱います。ただし製品ごとに範囲は異なります。ERPが受注、購買、在庫、会計の正本を持つ場合もあれば、生産管理側が詳細在庫や工程実績を持つ場合もあります。設備監視は状態や信号の取得に強くても、業務上の承認や在庫更新まで担うとは限りません。名称で境界を決めず、業務イベント、正本データ、更新責任で定義してください。
タイ ITベンダー 日系とローカル企業は、どちらを選ぶべきですか？
国籍だけで決めるべきではありません。本社との日本語合意、タイ語での現場支援、製造工程経験、設備接続、セキュリティ、稼働後の時間帯、契約と出口まで、必要な責任面を比較します。一社で覆えない場合は共同チームも選択肢ですが、統合責任者と共通の課題・受入管理が必要です。
海外拠点 システム導入のRFPは本社が作るべきですか？
本社だけでも現地だけでも不十分です。本社は投資目的、グループ標準、データ・統制、承認条件を示し、現地工場は工程、例外、設備、勤務、言語、復旧条件を示します。ベンダーは解決方式、前提、リスク、成果物を提示します。誰か一者が代筆するのではなく、責任分担された共同成果物にすることが重要です。
タイ工場システム導入の費用はどう比較すればよいですか？
市場平均の一括金額ではなく、要件、製品、設定・開発、統合、データ、検証、教育、切替、運用、終了のバケットに分けてください。数量、前提、対象外、発注者作業、変更条件を同じ様式で回答させます。初期価格に含まれない現地作業や将来更新も含め、責任移転後の総負担で比較します。
BOIやdepaの支援を前提に予算承認してもよいですか？
採択、対象、税効果を確定値として扱うべきではありません。BOIの条件や算入ルール、depaの募集期間、SME要件、登録製品・サービス、税務上の扱いは案件と時点で変わり得ます。公式の最新条件を確認し、予算では「適用できる場合」と「適用できない場合」を分けて判断してください。必要に応じてBOI、depa、税務・法務の専門家へ相談してください。
13. まとめ
タイ工場のシステム導入は、製品デモから始めるのではなく、業務課題、目標工程、システム境界、データ所有、責任分担、受入証跡、運用と出口を一つの意思決定パッケージにすることから始まります。パッケージ、設定型、ローコード、個別開発、統合型のどれを選んでも、現地と本社が同じ定義で判断し、ベンダーが前提・除外・証拠を示せることが重要です。費用は相場ではなく責任範囲で比較し、BOIやdepaの制度は個別確認なしに確約へ置き換えないでください。
TOMAS TECHでは、RFPを作り始める前の課題整理や、候補ベンダーの責任境界、ERP・生産管理・WMS・設備をまたぐ接続方針のレビュー段階からご相談いただけます。タイ・ASEAN工場のIT／OT／FAを一体で検討したい場合は、お問い合わせフォームから現在の構想と未決事項をお知らせください。
14. 参照資料
- Thailand BOI, “Thailand Secures 43.6bn 1H 2026 Investment Surge as Big Tech”: https://osos.boi.go.th/EN/news/2430/Thailand-Secures-43-6bn-1H-2026-Investment-Surge-as-Big-Tec/
- Thailand BOI, “Investment Promotion Guide 2026”: https://www.boi.go.th/upload/content/BOI_A_Guide_EN.pdf?v=20260607125432
- depa Thailand, Smart SME 2026 update: https://en.depa.or.th/th/article-view/20260723_04
- NIST SP 1305: https://csrc.nist.gov/pubs/sp/1305/final
- NIST, “Security, Privacy, and C-SCRM Risk Management Plans: NIST Releases SP 800-18r2”: https://www.nist.gov/news-events/news/2026/06/security-privacy-and-c-scrm-risk-management-plans-nist-releases-sp-800-18r2
- World Bank, “Thailand Economic Monitor, February 2026”: https://www.worldbank.org/en/country/thailand/publication/thailand-economic-monitor-february-2026-advanced-green-manufacturing-for-growth
