生産管理システム クラウドを検討するタイ工場では、「月額だから安い」「工場内に置けば安全」という二者択一では判断できません。製造指図、実績、在庫、ロット、品質、設備、原価を誰がどこで処理し、回線断や契約終了時にも何を継続できるかまで設計して初めて比較になります。本稿では、クラウド、オンプレミス、ハイブリッドを、5年TCO、可用性、回線断、データ所在・越境移転、拡張・カスタマイズ、終了・移行、FAT/SAT/UATの証拠で選ぶ実務手順を解説します。メーカーの順位づけではなく、自社要件に対する適合を再現可能な証拠で判断するためのガイドです。
先に結論：配備方式ではなく「止められない処理」を起点に選ぶ
最初に決めるべきはクラウドかオンプレミスかではなく、回線や上位システムが止まったとき、現場が何分・何時間まで耐えられるかです。受注照会は遅れてもよい一方、ラベル発行、工程実績、材料照合、品質判定、設備インターロックは止めにくい場合があります。処理ごとの最大許容停止時間、許容データ損失、復旧順序を決めると、配備方式は次のように整理できます。
| 選択肢 | 向きやすい状況 | 主な設計課題 | 発注前に得る証拠 |
|---|---|---|---|
| クラウド | 複数拠点展開、需要変動、遠隔運用、標準機能中心 | WAN依存、共有責任、データ所在、出口 | SLA原文、責任分界、データフロー、全量エクスポート試験 |
| オンプレミス | 工場内の低遅延、閉域、特殊設備連携、現場独立性 | 二重化、パッチ、バックアップ、要員属人化 | 構成図、復旧演習、部品・保守期限、運用手順 |
| ハイブリッド | 現場継続と全社統合を両立したい | 同期競合、マスター所有、再送、監視範囲 | 回線断試験、再同期試験、重複防止、時刻整合 |
NISTはクラウドを、オンデマンドのセルフサービス、広範なネットワークアクセス、資源共有、迅速な伸縮、計測サービスという特性で整理しています。つまり「外部のサーバーに置く」だけではクラウドの運用効果は得られません。迅速な増減、標準化、計測、責任分担を実運用へ落とせるかが要点です。一方、工場内サーバーも、設置すれば可用性が確保されるわけではありません。電源、空調、ストレージ、バックアップ、予備機、監視、復旧要員まで工場側の責任になります。
生産管理システム クラウド比較の前に業務を四層へ分ける
ひとつの製品名で全処理を論じると、重要な違いが隠れます。タイ工場では少なくとも次の四層に分けてください。
- 企業・計画層：受注、MPS/MRP、購買、在庫評価、標準原価、経営レポート。
- 工場実行層：製造指図、投入、出来高、不良、ロット、仕掛、作業者・設備実績。
- エッジ制御層：PLC、検査機、計量器、ラベルプリンター、ゲート、ローカルバッファ。
- 証拠・統制層：承認履歴、電子署名、監査ログ、マスター版、バックアップ、復旧記録。
企業・計画層は複数拠点で共有しやすく、伸縮性と遠隔保守の便益が出やすい領域です。エッジ制御層はミリ秒から秒単位の応答や回線断時の自律運転が必要になることがあります。工場実行層はその中間です。したがって、全機能を同じ場所へ置く必要はありません。クラウドに計画と可視化、工場内にエッジバッファと必須照合を置き、復旧後に整合させるハイブリッドが合理的な場合もあります。
5年TCOで生産管理システムを比較する
初期費用と月額だけを比べない
生産管理システム 比較で最も起きやすい誤りは、クラウドのサブスクリプションとオンプレミスのライセンスだけを並べることです。評価期間を同じにし、税、為替、成長、保守更新、停止損失まで同じ条件で扱ってください。5年は提案する比較期間であり、資産方針や契約年数に応じて3年または7年へ変えて構いません。
クラウドTCOの考え方
導入・移行 + 60か月の利用料 + 通信・閉域 + API/連携 + 追加保存・転送 + 運用監視 + カスタマイズ保守 + 教育 + 監査対応 + 終了時のデータ搬出・移行 + 想定停止損失
オンプレミスTCOの考え方
サーバー・ストレージ・OS/DB + 二重化 + UPS・ラック・空調 + 設計・構築 + ライセンス保守 + バックアップ媒体/遠隔保管 + パッチ・監視・障害対応人件費 + 更新部品 + 更改移行 + 教育 + 想定停止損失
ハイブリッドTCOの考え方
上記双方に加え、エッジ装置、同期ソフト、メッセージキュー、証明書、二重監視、競合解消、現地サポートが必要です。ハイブリッドは「中間だから安い」のではなく、継続性のために二つの運用面を持つ設計です。
TCO入力値はRFPで同じ単位にする
| 入力項目 | ベンダーへ求める回答 | 注意点 |
|---|---|---|
| 利用者 | named/concurrent/device別単価 | 繁忙期、派遣、共有端末を含める |
| 取引量 | 指図、実績、API、帳票、添付の上限 | 超過単価とスロットリングを確認 |
| 保存 | DB、ログ、画像、バックアップ別 | 本番削除後のバックアップ保持も確認 |
| 通信 | 主回線、副回線、SIM、閉域、転送量 | 工業団地での実測と障害履歴を確認 |
| 環境 | 本番、検証、教育、災対 | 非本番停止時の料金削減も確認 |
| 更新 | 定期版、緊急パッチ、カスタム回帰 | 強制更新と延期可能期間を確認 |
| 終了 | 全量エクスポート、媒体、工数、消去証明 | 契約終了後の猶予と単価を確認 |
価格は同じ基準日と通貨で受け取り、VATの内外、源泉・送金、為替前提を明記します。クラウドの将来単価やオンプレミス部品価格を断定せず、基準ケース、利用量20%増、為替10%変動、停止時間増加などの感度分析を行います。これらの割合は市場予測ではなく、社内意思決定用の提案シナリオです。
可用性はSLAの数字ではなく業務復旧で測る
サービスの月間稼働率が高くても、工場側の回線、ID基盤、端末、プリンター、連携APIが止まれば製造は継続できません。逆にオンプレミスでも、単一UPS、単一DB、同一室内のバックアップ、担当者一人だけという構成なら停止リスクは集中します。
NIST SP 800-34 Rev.1は米国連邦情報システム向けのガイドであり、タイ工場へ直接適用される法令や製造規格ではありません。本稿では工場の復旧設計を整理する参照枠として用います。同ガイドは、業務影響分析（BIA）がシステム重要度、損失影響、RTOを決め、バックアップ頻度、冗長化、代替サイトの判断に結びつくと説明しています。工場では次を処理単位で定義してください。
- MTD：業務が許容できる最大停止時間。
- RTO：障害後、業務を復旧させる目標時間。
- RPO：復旧時に許容するデータ損失の時間幅。
- 復旧順位：認証、マスター、指図、実績、ラベル、在庫、帳票の順序。
- 縮退運転：紙、ローカルキャッシュ、CSV、手入力など一時手段。
RTO/RPOはベンダーのパンフレット値を転記せず、バックアップから別環境へ復元し、利用者がログインし、未処理データを照合し、業務責任者が再開承認するまでを時計で測ります。SLAに含まれない計画保守、地域障害、回線、顧客設定ミス、第三者連携も一覧にします。
回線断でも工場を止めないオフライン設計
オフライン可否を画面単位ではなく取引単位で確認する
「オフライン対応」という言葉だけでは不足です。次の取引ごとに、読み取り、登録、訂正、取消、承認、印刷が可能かを確認します。
| 取引 | 回線断中の最低要件 | 復旧後の検証 |
|---|---|---|
| 製造指図 | 承認済み最新版を閲覧 | 古い版で実行していないか |
| 材料投入 | ロット・品目・期限を照合 | 重複投入、禁止ロットを検知 |
| 実績 | 端末に時刻付きで蓄積 | 冪等キーで二重登録を防止 |
| 品質 | 判定ルールと規格値を保持 | 版違いの判定を隔離 |
| ラベル | 採番と再発行を統制 | 番号重複、再印刷理由を監査 |
| 在庫移動 | 仮取引として記録 | 負在庫・同時移動の競合を解消 |
再同期の仕様がハイブリッドの品質を決める
回線復旧後は「送れた」だけでなく、順序、重複、競合、時刻、マスター版を検証します。各取引へ一意なID、端末時刻、サーバー受信時刻、操作者、元指図、マスター版を付けます。少なくとも一度配送される仕組みなら、受信側は同じIDを再処理しない冪等性が必要です。二拠点で同じマスターを更新できるなら、どちらを正とするか、競合時に自動決着するか保留キューへ送るかを決めます。
提案する回線断テストは、5分、30分、2時間、交代跨ぎの四ケースです。これらは法定値でも規格値でもなく、実際の工場影響に合わせて変更する試験値です。断線、遅延、パケット損失、DNS不良、ID基盤だけ停止という異なる故障も入れます。
タイPDPA、データ所在、越境移転を分けて確認する
「タイ国内リージョン」と「越境しない」は同義ではない
タイの個人情報保護法（PDPA）第28条は、個人データを国外へ送付・移転するとき、原則として受領国・国際機関に十分な保護基準を求め、法律上の例外も定めています。第29条は同一企業グループの方針等に関する枠組みを置いています。具体的な適用はデータ、当事者、契約、例外により変わるため、法務・DPOの確認が必要です。
生産管理データにも、作業者ID、勤務情報、力量、承認者、写真、位置、端末ログなど個人データが混在し得ます。データベースがタイにあっても、次の経路で国外処理が起こる可能性があります。
- 海外のサポート担当者による管理アクセス。
- 国外の監視、ログ分析、メール、バックアップ、災害復旧。
- 親会社ERPや地域データレイクへの連携。
- 生成AI、OCR、翻訳など別サービスへのAPI送信。
- 契約先の再委託先、保守ツール、チケットシステム。
RFPでは、保存場所だけでなく、処理場所、バックアップ場所、サポートアクセス元、再委託先、暗号鍵管理者、削除・返却、法執行機関からの要求手順をデータフロー図で回答させます。PDPA対応を「認証取得済み」の一言で代替してはいけません。法的根拠、通知、処理委託契約、越境移転の根拠、保存期間、権利対応、漏えい対応を自社の役割と結びつけます。
認証は入口であり、適合性の結論ではない
ISO/IEC 27001は情報セキュリティマネジメントシステムの要求事項、ISO/IEC 27017:2026はクラウド顧客とクラウド提供者の双方に対するクラウド固有の管理策ガイダンスを提供します。認証や適用宣言は有力な証拠ですが、対象範囲、拠点、サービス、除外、監査時点を確認してください。契約するSaaS、運用会社、データセンターのどれが認証範囲かは別問題です。
共有責任をRACIと運用証拠へ変換する
クラウドでは提供者が基盤を守る一方、顧客にもデータ、利用者、設定、権限、端末などの責任が残ります。AWSの公式説明も、クラウド「の」セキュリティとクラウド「内」のセキュリティを分け、顧客責任は選ぶサービスやデータの機微性、法令に左右されるとしています。これは特定ベンダーを推奨するためではなく、一般的な確認観点として有用です。
| 管理領域 | SaaS提供者 | 導入ベンダー | 工場・本社 | 証拠例 |
|---|---|---|---|---|
| 基盤パッチ | 主担当 | 確認 | 通知確認 | リリース記録、脆弱性対応SLA |
| アプリ設定 | 仕様提供 | 設定・移送 | 承認 | 設定台帳、変更承認 |
| ID・権限 | 機能提供 | 連携支援 | 主担当 | 棚卸し記録、退職者無効化 |
| マスター | 入力制御 | 移行支援 | 主担当 | 版、承認、変更ログ |
| バックアップ | 契約範囲 | 復元支援 | 要件・確認 | 復元試験結果 |
| インシデント | 検知・通知 | 一次切分け | 判断・報告 | 連絡網、時系列、是正記録 |
RACIでは、各活動にAccountableを原則1名、Responsibleを少なくとも1名定め、必要なConsultedとInformedを割り当てます。特に「復元」「鍵管理」「ログ保全」「退職者停止」「再委託先変更」「緊急パッチ」「監査証拠提出」は空欄にしないでください。
生産管理システム カスタマイズを「変更可能性」で評価する
カスタマイズ量ではなくアップグレード影響を測る
クラウドは標準化に向きますが、拡張できないとは限りません。オンプレミスは自由に改造できても、将来の更新費用と障害責任が増えることがあります。比較では、要件を次の順で処理します。
- 業務を標準へ合わせられるか。
- パラメータ、ワークフロー、帳票設定で満たせるか。
- 公開API、イベント、拡張ポイントで外出しできるか。
- コア改修が本当に必要か。
各差分には、業務価値、法令・顧客要求、代替運用、利用者数、頻度、停止影響を記載します。コア改修には、ソース所有、テスト環境、デプロイ、ロールバック、脆弱性対応、次版追随、ベンダー交代時の権利を紐づけます。
生産管理システム カスタマイズの受入では、正常系だけでなく、同時更新、重複送信、ネットワーク遅延、途中失敗、権限不足、マスター切替中、月末負荷を試験します。多言語では、タイ語の結合文字、日英タイの検索、仏暦・西暦、タイムゾーン、桁区切り、単位、ラベル幅も対象です。
契約終了と移行を契約前に試す
データを「出せる」と「再利用できる」は違う
終了時のリスクはクラウドだけではありません。オンプレミスでも、独自DB、暗号鍵、古いOS、保守切れ、ソース不在で移行困難になります。RFPには次を含めます。
- マスター、未完指図、実績、在庫、ロット、品質、承認、監査ログ、添付を全量で取得できる。
- CSV/JSON等の形式、文字コード、時刻、単位、コード表、参照関係が文書化される。
- 添付とレコードを一意IDで結べる。
- 差分抽出と最終凍結抽出の方法がある。
- 契約終了後の読取期間、支援単価、消去時期、バックアップ消去、証明書が明確である。
- API制限、転送料、暗号化、搬送媒体、国外移転の扱いが明確である。
契約前の提案試験として、代表データをエクスポートし、別DBへロードし、件数、金額、数量、参照整合、ハッシュ、添付開封を確認します。全量試験が難しければ、契約後早期に実施する義務と不合格時の是正を契約へ入れます。「契約終了時に相談」では交渉力が弱くなります。
FAT・SAT・UATで生産管理システム 導入期間を管理する
生産管理システム 導入期間は、クラウドなら短くオンプレなら長いと一律には言えません。標準適合、移行データ、設備IF、承認、教育、拠点数、停止可能時間で変わります。日数を先に約束するより、完了条件と依存関係を置きます。
FAT：供給者環境で仕様と例外を確認
FATでは、要件トレーサビリティ表に基づき、設定、カスタム、IF、権限、帳票、監査ログを確認します。模擬データだけでなく匿名化した代表データを含め、障害注入とロールバックも行います。未解決事項には重大度、回避策、責任者、期限を付けます。
SAT：タイ工場の実環境で接続と継続性を確認
SATでは、実端末、スキャナー、プリンター、PLC/設備ゲートウェイ、主副回線、ID基盤、時刻同期、電源を使います。回線断、再同期、ラベル重複、設備からの再送、交代跨ぎ、ピーク負荷を確認します。クラウド側が正常でも工場側で使えなければSAT合格ではありません。
UAT：業務責任者がシナリオ完結を承認
UATは画面のクリック確認ではなく、受注・計画から材料投入、製造実績、品質、出荷、原価・在庫照合までの業務シナリオで行います。タイ語利用者を含む実際の役割が担当し、旧方式との数量・金額差、例外処理、締め処理、取消・訂正、監査証跡を確認します。
提案する段階ゲート
| ゲート | 入口条件 | 出口証拠 | Go/No-Go責任者 |
|---|---|---|---|
| 設計凍結 | 要件・データフロー合意 | 仕様、責任分界、テスト計画 | 業務責任者＋IT |
| FAT完了 | 設定・開発完了 | 実行ログ、欠陥一覧、回帰結果 | プロジェクト責任者 |
| SAT完了 | 現地接続完了 | 回線断・設備・印刷・復旧証拠 | 工場長＋IT |
| UAT完了 | 教育・移行リハ完了 | シナリオ署名、照合結果 | 業務オーナー |
| 本番移行 | 重大欠陥解消 | 切替・戻し計画、連絡網 | ステアリング委員会 |
重大度1は安全、法令、出荷、データ完全性に重大影響、重大度2は主要業務が代替困難、重大度3は回避可能、という分類を提案できます。ただし分類と合格条件は各社で承認すべき提案値です。未解決件数だけで合否を決めず、影響と回避策を見ます。
どの方式が向くかを点数ではなく制約で絞る
重み付き採点は便利ですが、法令や停止許容を平均点で相殺してはいけません。最初に必須条件で除外し、その後に採点します。
必須条件の例
- 回線断中も対象工程を所定時間継続できる。
- 必要なデータフローと越境移転根拠を法務が承認できる。
- RTO/RPOを復旧試験で証明できる。
- 全量データを再利用可能な形で搬出できる。
- 重要な設備IFとラベル統制をSATで合格できる。
- 監査ログを必要期間、改ざん防止と検索性を保って保持できる。
必須条件を通過した候補に、TCO、展開速度、標準適合、運用要員、拡張性、サポート言語、ロードマップを採点します。評価者は根拠URL、文書版、デモ結果、試験IDを残し、「印象」を点数へ変換しないようにします。
三つの代表シナリオ
シナリオA：多拠点の計画・可視化を迅速に統一
各工場で基本プロセスが近く、設備制御は別MES/エッジにあり、本社が共通KPIを求めるならクラウドが候補になります。共通テンプレート、拠点別設定、統合ID、API監視、データ所在、段階展開を重視します。
シナリオB：特殊設備と低遅延処理が中心
古い設備、独自プロトコル、閉域、厳しい応答、長い製品ライフサイクルが中心なら、工場内実行をオンプレミスまたはエッジに置く合理性があります。ただし遠隔バックアップ、パッチ、予備部品、サイバー対策、要員継承をTCOへ含めます。
シナリオC：回線断継続と全社データ統合を両立
ローカルで指図キャッシュ、投入照合、実績バッファ、ラベル統制を継続し、クラウドで計画、分析、拠点統合を行うハイブリッドです。成功条件は同期仕様です。接続中の正常系より、断線中の版管理と復旧後の競合解消へ試験工数を割きます。
RFPへそのまま使える質問
- 提案構成を企業層、工場実行層、エッジ層、証拠層に分け、責任者を示してください。
- 各取引のRTO/RPO、オフライン可否、保持件数、再同期方式を示してください。
- SLAの対象、除外、計測点、返金以外の是正、過去の稼働情報を示してください。
- 本番、バックアップ、ログ、監視、サポートの国・地域と再委託先を示してください。
- PDPA対象データの役割、処理目的、保持、削除、越境根拠をデータフローへ記載してください。
- 標準設定、ローコード拡張、外部拡張、コア改修を区別してください。
- バージョン更新の通知、延期、検証、回帰、ロールバックを説明してください。
- 全データと監査ログのエクスポート仕様、費用、所要期間、消去証明を提示してください。
- FAT/SAT/UATの環境、データ、役割、証拠、欠陥管理を提示してください。
- 導入後のL1/L2/L3、タイ語・英語・日本語対応、現地出動条件を示してください。
機能要件の作り方は生産管理システム 機能｜タイ工場RFP要件2026で、失敗パターンと回避策は生産管理システム 導入 失敗｜タイ工場で防ぐ実践設計で詳しく解説しています。本稿の配備方式比較と合わせると、要件、契約、受入の流れを一貫させられます。
FAQ：生産管理システム クラウドのよくある質問
生産管理システム クラウドはオンプレミスより安いですか？
一律には言えません。利用者、取引量、保存、通信、連携、カスタマイズ、運用要員、更新、停止損失、終了時移行を同じ期間で比較してください。クラウドは初期資産を抑えやすい一方、長期の利用料や追加量、データ搬出が効きます。オンプレミスは利用料以外に二重化、空調、バックアップ、要員、更改を含める必要があります。
生産管理システム オンプレミスなら回線断の影響はありませんか？
工場内処理は継続しやすくなりますが、本社ERP、ライセンス認証、外部ID、メール、遠隔バックアップなどが外部依存なら影響は残ります。また工場内LAN、電源、DB、ストレージの障害もあります。依存関係を図にして実際に遮断試験をしてください。
生産管理システム カスタマイズはどこまで許容すべきですか？
業務価値と差分理由を確認し、標準、設定、公開拡張、コア改修の順に検討します。改修件数より、更新ごとの回帰範囲、ロールバック、ソース権利、脆弱性修正、ベンダー交代時の保守性を評価してください。
生産管理システム 導入期間はクラウドなら短縮できますか？
インフラ調達は短縮しやすい一方、業務標準化、データ浄化、設備IF、PDPA確認、教育、UATは残ります。期間は製品形態だけでなく、拠点数と差分、意思決定速度、受入証拠の準備で決まります。
ハイブリッドは最も安全な選択ですか？
自動的に安全にはなりません。現場継続性を高められる一方、同期、監視、証明書、二重運用、競合解消が増えます。回線断と再同期をSATで証明でき、運用責任を維持できる場合に有効です。
まとめ：クラウド／オンプレミスの正解を契約前に証明する
生産管理システム クラウドの選定は、配備場所の好みではなく、止められない処理と証拠の設計です。業務を四層へ分け、同じ5年TCOで比較し、RTO/RPOとオフライン取引を定義し、PDPAのデータフローを確認し、共有責任と出口計画を契約へ入れます。最後にFAT、タイ工場でのSAT、業務責任者によるUATで合格を証明します。この順番なら、クラウド、オンプレミス、ハイブリッドのいずれを選んでも、判断理由と残存リスクを経営へ説明できます。
TOMAS TECHでは、候補製品を決める前の業務・データフロー整理、クラウド／オンプレミス比較、RFP、設備連携、回線断テスト、FAT/SAT/UATの設計からご相談いただけます。「現状でどこまで決めるべきか」という検討初期でも、お問い合わせください。
参考情報
- NIST, *The NIST Definition of Cloud Computing (SP 800-145)*: https://csrc.nist.gov/pubs/sp/800/145/final
- NIST, *Contingency Planning Guide for Federal Information Systems (SP 800-34 Rev.1)*: https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final
- Personal Data Protection Act B.E. 2562, Royal Thai Government Gazette: https://ratchakitcha.soc.go.th/documents/17082307.pdf
- Thailand PDPC, Government Platform for PDPA Compliance, Privacy Policy: https://gppc.pdpc.or.th/privacy-policy/
- ISO, *ISO/IEC 27001:2022 Information security management systems*: https://www.iso.org/standard/27001
- ISO, *ISO/IEC 27017:2026 Information security controls for cloud services*: https://www.iso.org/standard/27017
- AWS, *Managing security responsibilities for Amazon VPC*: https://docs.aws.amazon.com/vpc/latest/userguide/security.html
本稿はシステム選定・統制設計の一般情報であり、法的助言ではありません。PDPA、越境移転、業界固有規制の適用は、最新の法令・通知を確認し、法務・DPO・監査部門と判断してください。
