生産管理システム クラウド2026｜止まるのはサーバーではなく認証

「クラウドかオンプレミスか」を会議で決めようとして、結論が出ないまま次回に持ち越された——タイの日系工場で何度も見た光景です。決まらない理由は情報不足ではありません。生産管理システム クラウド化の可否を、システム全体でひとつ選ぼうとしているからです。決定の単位は機能であり、判断軸は費用ではなく、その機能が何分止まってよいかです。そして移行後に最初に止まるのは、サーバーでもアプリでもなく認証です。

生産管理システムのクラウド化は、2026年に前提が変わった

これまでタイの拠点でクラウドを検討すると、話は必ず同じ場所で止まりました。「データはどこに置かれるのか」です。シンガポールか、東京か、どちらにしても国外です。本社の情報システム部門が国外移転の是非を法務に投げ、法務が判断材料を求め、そこで案件が数か月止まる。これがこの数年の標準的な光景でした。

2026年に、この前提が変わりました。タイ国内にデータを置くことが、初めて標準的な選択肢になったからです。

バンコクにリージョンが揃った意味

事実関係を整理します。AWS（Amazon Web Services、Amazon.com社）は、Asia Pacific (Thailand) リージョン（ap-southeast-7、3アベイラビリティゾーン構成）を2025年1月8日に一般提供開始しました。Google Cloud（Google社）は、バンコクリージョン（3アベイラビリティゾーン構成）を2026年1月21日に開設し、10億USD規模の投資を表明しています。Microsoft Azure（Microsoft社）のタイリージョン（Thailand South）は現時点では開設予定の表明段階にあり、2025年10月にTrue IDC（True Corporation社）をアベイラビリティゾーンのひとつとして使うことを公表しています。

この3社の状況の差は、そのまま検討の進め方の差になります。すでに一般提供が始まっている基盤と、開設予定が表明されている基盤とでは、稟議に書ける内容が違います。本社が「タイ国内にデータを置くこと」を条件にしている場合、現時点で条件を満たせるのは前者だけです。後者を前提に計画を組むなら、開設時期が確定していない前提で移行計画を書くことになり、そこは計画のリスクとして明示しておく必要があります。

もうひとつ、実務的に大きいのはアベイラビリティゾーンが3つあることです。ゾーンが1つしかない拠点型のデータセンターでは、電源や空調の障害がそのままサービス停止になります。3ゾーン構成なら、データベースを複数ゾーンにまたがって配置し、片側の障害で自動的に切り替える構成が組めます。これは自社の工場内にサーバーを2台置いて冗長化するのとは、まったく水準の違う話です。工場内の冗長化は、建屋の停電と洪水には勝てません。

ただし、ここで結論を急がないでください。「タイ国内にリージョンができたから全部クラウドにできる」ではありません。変わったのはデータ所在という制約が外れたことだけで、それ以外の制約は何も変わっていません。

それでも「全部クラウド」が答えにならない理由

制約がひとつ外れたときに起きがちなのは、残りの制約も一緒に消えたと思い込むことです。実際には、リージョンが国内に来ても解決しない問題が3つ残ります。

ひとつめは、工場から先の回線です。データセンターがバンコクにあっても、工場からそこまでは通信事業者の回線を通ります。工事、停電、機器故障、そして雨季の物理障害。この区間は、リージョンがどこにあろうと自社の責任範囲です。クラウド側のサービス稼働率が仮に99.9%と示されていても、そこに至る回線が落ちれば工場から見た可用性はゼロです。

ふたつめは、費用の構造が読みにくくなることです。JUAS『企業IT動向調査2026』では、IT予算が増加する理由として「既存システムの更新・改修・拡張」が66.3%で最多、次いで「円安・人件費高騰・ベンダー値上げの影響」が46.6%、「クラウドサービスの増加」が45.0%、「AI関連の投資・利用コスト増」が43.7%（前年36.3%から7.4ポイント増）と報告されています。クラウドの増加が予算増の理由として上位に並ぶという事実は、そのまま「クラウドにしたら安くなる」という前提が現場で崩れていることを示しています。

みっつめは、いったんクラウドに寄せた後の揺り戻しが現実に起きていることです。クラウドからの回帰（リパトリエーション）に関する集計では、Flexera社の2025 State of the Cloudで既に21%のワークロードやデータが回帰済みとされ、84%が「クラウド支出の管理」を最大の課題に挙げています。IDC社の調査では2024年に59%の組織が予算を超過しました。ただし同じくIDC社の2024年10月時点の調査では、全ワークロードを引き上げる組織は約8%にとどまり、大半は選択的な回帰です。

この「大半は選択的」という部分が、この記事の主張そのものです。戻している企業も、全部を戻しているわけではありません。合わない機能だけを戻している。だとすれば、最初から機能単位で置き場所を決めればよい。「クラウドかオンプレか」をシステム全体でひとつ選ぶ問いの立て方自体が、間違っています。

生産管理システムは単一の機能ではありません。ラベル発行、在庫引当、実績入力、マスタ管理、購買、原価集計。これらは要求される応答速度も、止まったときの損害も、扱うデータの性質もばらばらです。ばらばらのものに、ひとつの答えを出そうとするから決まらないのです。

生産管理システム クラウドとオンプレミスの違いは、費用ではなく停止許容時間で見る

では機能単位で決めるとして、何を基準に振り分けるのか。費用ではありません。停止許容時間、つまりRTO（Recovery Time Objective／目標復旧時間）です。

理由は後段の試算で示しますが、先に結論だけ書きます。この規模の工場では、費用を判断軸にするとほぼ常にクラウドが勝ちます。しかもその差が逆転するのは10年以上先です。通常の投資判断期間である5〜7年に収まらない差なので、費用は判断軸として機能しません。機能しない軸で議論しているから、会議が終わらないのです。

機能ごとの停止許容時間

停止許容時間は、情報システム部門が机上で決めるものではありません。止まったときに実際に困る現場が決めるものです。以下は、タイの日系工場で実際に整理した際の典型的な水準です。自社の値は必ず現場と一緒に埋め直してください。

この表を見ると、同じ「生産管理システム」の中に、5〜15分しか止められない機能と、3営業日止まっても業務が回る機能が同居していることがわかります。差は数百倍です。

なぜラベル発行がこれほど短いのか。完成品にラベルが貼れないと、その品物は物理的に次の工程へ流せないからです。仮置き場に積むしかなく、仮置き場が埋まれば生産そのものを止めます。しかも後から貼り直す作業には、どれがどのロットだったかを特定する工数が乗ります。15分の停止が、翌日の数時間の手戻りに化けることがあります。

逆に原価集計は、その日に集計できなくても翌日にまとめて処理できます。月次締めの直前を除けば、3営業日の停止は業務を止めません。この機能に対して、ラベル発行と同じ可用性の投資をするのは過剰です。

RTOと同時に、RPO（Recovery Point Objective／目標復旧時点、どこまでのデータ喪失を許容するか）も機能ごとに決めます。実績入力はRPOが短い——直前の30分の入力が消えると、誰も再現できません。一方でマスタ更新は、直前の更新が消えても登録者が覚えているので入れ直せます。この2つの指標の考え方と、実際の設計への落とし方は業務システムのバックアップ体制をRTO/RPOから整理した記事で扱っていますので、社内で表を埋める前に目を通してください。

システム全体で1つのRTOを置くと、過剰投資と欠品が同時に起きる

現場でよく見るのは、要件定義書に「システム全体のRTO:4時間」と1行だけ書かれているケースです。この1行が、2つの失敗を同時に引き起こします。

ひとつは過剰投資です。4時間というRTOは、原価集計や購買にとっては厳しすぎます。3営業日でよい機能に、4時間で戻る仕組みを用意すると、その分の冗長化費用と運用工数が丸ごと無駄になります。しかもこの無駄は、金額が見えません。「システム全体の可用性のため」という項目に埋もれるからです。

もうひとつは欠品です。4時間というRTOは、ラベル発行にとっては緩すぎます。5〜15分しか止められない機能を4時間で設計してしまうと、実際に障害が起きたときに現場は3時間45分間、何もできません。そして障害が起きて初めて「これは4時間も待てない」と分かる。このとき、設計をやり直すコストは初期構築時の何倍にもなります。

システム全体に1つのRTOを置くというのは、最も厳しい機能の要求を無視し、最も緩い機能に過剰な投資をするという、両方向に外す決定です。書くべきは1行ではなく、機能の数だけの行です。

なお、この作業は情報システム部門だけでは終わりません。「ラベル発行が15分止まったら何が起きるか」に答えられるのは製造部門であり、「その状態で何分持ちこたえられるか」に答えられるのは工場長です。要件定義の初回に、この2者を同席させてください。同席させずに進めた案件が後でどうなるかは、生産管理システムの導入が失敗する典型パターンで整理しています。

クラウド移行で最初に止まるのはサーバーではなく認証

ここからが本題です。機能ごとにRTOを決めた表を作ったとして、その表には決定的な抜けがあります。認証が入っていません。

認証は「機能」として認識されていません。業務機能の一覧に載らず、業務フロー図にも描かれず、したがってRTOも割り当てられない。しかし実際には、先ほどの表の6機能すべての前段にあります。ログインできなければ、ラベルも出ませんし、実績も入りません。

つまり認証のRTOは、表の最短値に合わせる必要があります。ラベル発行が5〜15分なら、認証のRTOも5〜15分です。これが設計から抜けるので、クラウド移行後の最初のトラブルは、ほぼ例外なく認証で起きます。

認証の3構成と回線断時の挙動

生産管理システムをクラウドに移したとき、認証の構成は実務上3つに分かれます。それぞれ、工場と外部をつなぐ回線が切れたときの挙動が違います。

構成1：クラウドIdP単独。 Microsoft Entra ID（Microsoft社）やGoogle Workspace（Google社）などのクラウド上のIDプロバイダで認証し、オンプレミス側にはドメインコントローラを置かない構成です。運用は最も軽い。しかし回線が切れると、工場内の端末は誰もログインできません。すでにログイン中のセッションは、アクセストークンの有効期限が切れるまでは動きますが、切れた瞬間に止まります。有効期限が1時間なら、回線断から最大1時間で全端末が順番に落ちていきます。厄介なのは、全員が同時に落ちないことです。落ちる時刻がばらばらなので、現場は「回線が切れた」ではなく「システムが不安定」と認識します。原因の切り分けが遅れます。

構成2：オンプレミスAD＋クラウドへのフェデレーション。 工場内にActive Directory（Microsoft社）を置き、クラウド側へ認証を連携する構成です。パスワードハッシュ同期を使う場合と、フェデレーション（認証要求をオンプレミス側へ転送する方式）を使う場合で挙動が真逆になります。パスワードハッシュ同期なら、オンプレミスのADが落ちてもクラウド側だけで認証が完結します。フェデレーションなら、オンプレミス側の認証基盤が落ちた瞬間にクラウドサービスへのログインも止まります。この違いは構成図の見た目ではほとんど区別がつきません。ベンダーの提案書に「ADと連携」とだけ書いてある場合、どちらなのかを必ず確認してください。

構成3：オンプレミスAD単独。 クラウド側のアプリも、オンプレミスのADにドメイン参加した端末からのみ使う構成です。回線が切れても工場内のログインは通りますが、クラウド上のアプリには当然つながりません。認証は生きているがアプリが死んでいる状態で、現場から見ると構成1と区別がつきません。

この3構成に加えて、多要素認証（MFA）の依存先も確認が要ります。認証アプリやSMSで第二要素を確認する運用では、工場の回線が生きていても携帯回線が不調なら認証は通りません。認証の可用性は、社内ネットワークだけでは決まりません。

ラベル発行と実績入力がログインで止まる

具体的に何が起きるかを書きます。

朝7時30分、現場が始業します。ハンディターミナルの電源を入れ、作業者がIDカードをかざす。ここで認証が通らない。原因は、前夜のうちに回線側の機器が故障していたことです。サーバーは動いています。アプリも動いています。データも無事です。しかし誰もログインできない。

このとき現場が最初に取る行動は、多くの場合「紙に書く」です。これ自体は正しい対処です。問題は、紙に書いた実績を後から入力する工数と、その間に発行できなかったラベルです。ラベルが出ないと、完成品は仮置きになります。午前中で仮置き場が埋まり、午後には生産を止めるかどうかの判断が要ります。

そして復旧後にもうひと山あります。紙に書いた3時間分の実績を後追いで入力するとき、時刻はすべて入力時点のものになりがちです。工程進捗の時刻データが3時間ずれ、その日のリードタイム分析は使えなくなります。1日分のデータが欠けるのではなく、1日分の誤ったデータが入るほうが厄介です。

ここで確認したいのは、この障害の原因が生産管理システムではないことです。パッケージの選定を間違えたわけでも、サーバーのスペックが足りなかったわけでもありません。認証にRTOが割り当てられていなかった、それだけです。パッケージの機能比較にどれだけ時間をかけても、この失敗は防げません。パッケージそのものの比較軸については生産管理システムの比較記事にまとめていますが、選定と並行して認証の設計を進めてください。

認証を落とさないための4つの設計

対策は4つです。特別な技術は要りません。決めるべきことを決めるだけです。

1. 認証にRTOを明記し、最短機能に合わせる。 要件定義書に「認証のRTO:15分」と1行書く。これだけで、ベンダーの提案内容が変わります。15分で復旧する認証を設計しろと言われたベンダーは、単一のIdPに寄せた構成を出せなくなります。逆に、この1行がないと、認証は誰の責任範囲でもないまま構築が終わります。

2. 認証経路を二重化する。 クラウド側とオンプレミス側の、どちらか片方が落ちてももう一方で認証が通る状態を作ります。前述のパスワードハッシュ同期はその一例です。重要なのは「二重化してある」ではなく「片側を落として実際に通ることを確認してある」です。年に1回、計画停止を取ってフェイルオーバー試験を実施してください。試験していない冗長構成は、冗長ではありません。

3. トークンとキャッシュの有効期間を機能別に設計する。 現場端末と事務端末で、同じ設定にする必要はありません。現場のハンディターミナルは、決まった場所で決まった作業者しか使わない端末です。ここはトークンの有効期間を長めに取り、回線断でも一定時間は動き続けるようにする。一方、社外からもアクセスできる事務端末は短くする。セキュリティと可用性の折り合いは、システム単位ではなく端末と機能の単位で付けます。

4. 現場端末にオフライン認証のフォールバックを用意する。 回線が切れている間だけ、端末ローカルのキャッシュ資格情報やICカードで認証を通し、ラベル発行と実績入力だけを継続できるようにします。あわせて、緊急時にのみ使う管理者アカウント（ブレークグラスアカウント）と、MFAが使えないときの代替手段を用意し、その存在と保管場所を工場長と情報システム担当の2名以上が把握している状態にしてください。1名しか知らないアカウントは、その1名が休みの日に機能しません。

効くのは帯域ではなく往復回数｜ハンディ端末とクラウドの相性

認証の次に多い相談が「クラウドにすると現場が遅くなるのでは」というものです。ここも、見ている場所がずれていることが多い。

1スキャン5往復問題

まず遅延の目安を整理します。以下の数値は一般的に観測される目安であり、確定値ではありません。必ず自社の工場の回線から実測してください。同じバンコク近郊でも、契約している回線種別と経路によって大きく変わります。

この数値を見て「70msなら人間には分からない」と考えるのが、最初の間違いです。問題は1回の遅延ではなく、1つの操作で何回通信するかです。

ハンディターミナルで現品票のバーコードを1回スキャンしたとき、システムの内部では複数の通信が発生します。典型的には、認証トークンの検証、品番マスタの照会、在庫の引当、実績の登録、ラベル印字の要求。実装によっては、これで5往復します。

東京リージョンに置いた場合、RTTの目安を80msとすると、往復だけで5×80ms = 0.4秒が上乗せされます。サーバーの処理時間はこれとは別に乗ります。バンコク国内リージョンなら、目安を10msとして5×10ms = 0.05秒です。同じ実装でも、置き場所だけで0.35秒の差が出ます。

0.4秒を「たいしたことがない」と感じるかどうかは、回数で決まります。仮に1日1,000スキャンする現場なら、往復分だけで0.4秒×1,000回 = 400秒、約6.7分です。しかもこれは待ち時間なので、作業者はその間ハンディターミナルを持って立っています。

ここで重要なのは、帯域を増やしてもこの数字は改善しないことです。往復遅延は光の速度と経路長で決まるため、100Mbpsを1Gbpsにしても変わりません。改善する方法は2つだけ、距離を縮める（国内リージョンを使う）か、往復回数を減らすかです。

したがって、ベンダーへの確認事項は「回線は何Mbps必要ですか」ではありません。「現場の主要操作1回あたり、サーバーとの往復は何回発生しますか」です。この質問に即答できるベンダーは多くありません。答えられない場合は、PoC（実証）で実測させてください。ハンディ端末側にログを出せば計測できます。

なお、往復回数はパッケージの設計思想で決まるため、後から減らすのは容易ではありません。「スキャン時にマスタをまとめて先読みしておく」「実績登録を非同期にする」といった改修は可能ですが、いずれも追加開発です。選定段階で確認すべき項目です。

オフラインバッファをどこに置くか

往復回数を減らしても、回線が切れれば往復はゼロ回になります。切れている間に何ができるかを設計しておく必要があります。

置き場所の選択肢は3つです。

端末に置く。 ハンディターミナルのアプリ内にローカルデータベースを持ち、回線断中はそこに書き込み、復旧後に同期します。追加のハードウェアが不要で最も安い。弱点は、端末を紛失・故障させるとその端末の未同期データが消えることと、複数端末の間で在庫の整合が取れないことです。在庫引当のように排他制御が要る処理には向きません。

工場内のエッジサーバーに置く。 工場内に小型のサーバーを1台置き、マスタの複製とラベル印字、実績の一時受けを担当させます。端末は常にこのエッジサーバーと通信し、エッジサーバーがクラウドと同期する。回線断中も工場内では複数端末の整合が取れるため、在庫引当まで継続できます。後述するハイブリッド構成の中核がこれです。弱点は、この1台が単一障害点になることと、同期ロジックの追加開発が要ることです。

プリンタに置く。 ラベル発行だけに限れば、ラベルプリンタ側にテンプレートと直近の発行データを保持させ、回線断中は端末から直接プリンタへ印字指示を出す構成が取れます。最も安価に、最も短いRTOの機能だけを守る方法です。ただし発行済みラベルの情報を後からシステムへ取り込む手順を決めておかないと、二重発行の追跡ができなくなります。

どれを選ぶかは、やはりRTOの表に戻ります。ラベル発行が5〜15分なら、復旧に15分以上かかりうる構成では足りません。実績入力が2〜4時間なら、端末側のバッファで十分かもしれない。機能ごとに答えが違うので、ここでも「システムとしてどうするか」ではなく「機能ごとにどうするか」で決めます。

生産管理システム クラウドの費用とオンプレミスの5年比較【独自試算】

費用は判断軸として機能しない、と先に書きました。それを示すために、実際に計算します。以下はタイの日系工場の案件で使っている前提を単純化したモデルで、実在の1社の数字ではありません。自社の見積で置き換えて使ってください。

なお、この試算では削減効果額・ROI・投資回収年数は一切算定していません。費用の比較だけを行います。効果額は工場ごとの前提差が大きすぎて、モデルで示すと誤解を招くためです。

モデル工場の前提

• 所在地：バンコク近郊、単一拠点、日本本社あり
• 従業員：180名
• 生産管理システムの利用者：40名（事務25名＋現場15名）
• 現場端末：ハンディターミナル15台＋タブレット10台
• 通貨：THB（タイバーツ）
• 比較期間：5年

現場端末の費用（750,000 THB）は3シナリオすべてに同額で計上しています。クラウドにしてもオンプレミスにしても、現場が使う端末は必要だからです。ここを片方だけに計上している見積書を見かけますが、比較にはなりません。

3シナリオの5年総額

シナリオA：フルクラウド（SaaS）

5年ランニング：4,320,000 ＋ 720,000 ＋ 1,500,000 ＝ 6,540,000 THB

5年総額：9,210,000 THB

シナリオB：フルオンプレミス

5年ランニング：3,000,000 ＋ 1,500,000 ＝ 4,500,000 THB

5年総額：11,280,000 THB

シナリオC：ハイブリッド（現場系オンプレミス／管理系クラウド）

5年ランニング：2,700,000 ＋ 720,000 ＋ 1,400,000 ＋ 2,000,000 ＝ 6,820,000 THB

5年総額：11,650,000 THB

3シナリオを並べます。

差分は次のとおりです。

• B − A ＝ 2,070,000 THB（オンプレミスはクラウドより5年で207万THB高い）
• C − A ＝ 2,440,000 THB
• C − B ＝ 370,000 THB

読み取るべき点を3つ挙げます。

第一に、5年で見るとクラウドが最も安い。差は207万THBで、初期費用の差（6,780,000 − 2,670,000 ＝ 4,110,000）ほどではありませんが、無視できる額でもありません。

第二に、シナリオCのハイブリッドが最も高い。ここが多くの会議でひっくり返る場所です。ハイブリッドは「クラウドとオンプレミスの中間だから費用も中間」と思われがちですが、実際には両方の初期費用と両方の運用費用が乗ります。エッジサーバーもSaaSライセンスも回線冗長化も、すべて要ります。連携設計の分だけ導入支援も追加開発も増えます。結果としてフルクラウドより244万THB高く、フルオンプレミスより37万THB高い。

第三に、この3つの差は、5年間の総額としては同じオーダーの中に収まっているということです。9,210,000と11,650,000の差は、判断を一発でひっくり返すほどの桁差ではありません。だからこそ、費用以外の軸が必要になります。

逆転点は10.1年、更改を入れると13.4年

初期費用が高く年間費用が安いオンプレミスは、期間を長く取れば必ずクラウドを下回ります。では何年目でしょうか。

累計費用の式は次のとおりです（nは年数）。

• A累計 ＝ 2,670,000 ＋ 1,308,000n
• B累計 ＝ 6,780,000 ＋ 900,000n

年間費用の差は 1,308,000 − 900,000 ＝ 408,000。初期費用の差は 4,110,000。等号が成立するのは 408,000n ＝ 4,110,000 のときで、n ＝ 10.1年です。

検算します。n＝5 のとき A＝9,210,000／B＝11,280,000。n＝10 のとき A＝15,750,000／B＝15,780,000。10年目でまだBが上回っており、その直後に逆転することが確認できます。

ここに、現実に必ず発生する費用を1つ足します。ハードウェアとOSの更改です。サーバーは5年で保守が切れ、OSにもサポート期限があります。6年目にサーバー900,000＋OS/DBライセンス450,000の計1,350,000 THBを1回入れると、

• B累計 ＝ 8,130,000 ＋ 900,000n
• 408,000n ＝ 5,460,000 → n ＝ 13.4年

13.4年です。この数字が意味することは明確です。通常、工場のシステム投資は5年、長くても7年で評価します。13.4年目に逆転する費用差は、投資判断の期間に入っていません。つまり費用でクラウドとオンプレミスを比較しても、この規模では答えが出ない。出ないのに議論しているから、会議が終わらないのです。

念のため補足すると、これは「クラウドが安いからクラウドにしろ」という主張ではありません。逆です。5年でも10年でも差が決定的にならないなら、費用は判断材料から外すべきだ、という主張です。外したうえで、停止許容時間で決める。

5年で見るなら逆転するのは年数ではなく人数（約59名）

もうひとつ、費用に関して見落とされている軸があります。利用者数です。

シナリオAのライセンスは1人あたり月1,800 THBの従量課金です。利用者が増えれば、比例して増えます。オンプレミスの買い切りライセンスは、ある程度までは人数が増えても総額が変わりません。したがって、5年という固定期間で見た場合の逆転は、年数ではなく人数で起きます。

利用者をu名としたときの、シナリオAの5年総額は次のとおりです。

A5年総額 ＝ 4,890,000 ＋ 108,000u

内訳は、初期2,670,000 ＋ 5年×（年間ライセンス21,600u ＋ 回線144,000 ＋ 追加開発300,000）＝ 2,670,000 ＋ 108,000u ＋ 2,220,000 です。

これがシナリオBの11,280,000と並ぶのは、108,000u ＝ 6,390,000 のとき、すなわち u ≒ 59名です。

検算します。u＝40 のとき 9,210,000（シナリオAと一致）。u＝70 のとき 12,450,000 で、シナリオBの11,280,000を上回ります。

実務上の意味は大きい。このモデル工場の利用者は40名ですが、生産管理システムの利用者は運用開始後に増えます。品質部門を追加する、購買を追加する、日本本社から参照する人を追加する、協力会社に一部を開放する。40名で契約したシステムが、3年後に70名になるのはよくある話です。

したがって、費用を判断軸にするなら見るべきは「何年で逆転するか」ではなく「何名で逆転するか、そして自社は5年後に何名になっているか」です。59名という数字を出したうえで、5年後の想定人数を経営層に確認してください。59名を明確に超える見通しがあるなら、ライセンス体系の交渉（人数帯での定額プラン、参照専用ユーザーの安価な区分）を選定時の交渉材料にします。この交渉は契約後にはできません。

タイ拠点のデータ所在とPDPA｜国外移転が問題になる場面とならない場面

データ所在の話に戻ります。バンコクにリージョンが揃ったことで選択肢は増えましたが、そもそも生産管理システムのデータのうち、どれが規制の対象なのかを整理しておく必要があります。

タイのPDPA（個人データ保護法）については、国外移転に関する規則（ホワイトリスト告示およびBCR・適切な保護措置に関する告示）が2024年3月24日に施行されています。移転の根拠は、①十分性認定を受けた国への移転、②BCR（拘束的企業準則）、③適切な保護措置（標準契約条項など）の3つです。

そして実務上重要なのは、2025年時点でPDPC（個人データ保護委員会）が十分性認定国のリストを公表していないことです。したがって、当面すべての国外移転は非認定先への移転として扱い、②か③の保護措置が必要になります。「日本は個人情報保護法があるから大丈夫」という整理は、少なくとも①の根拠では成り立ちません。

ここで冷静に見ると、生産管理システムが扱うデータの大半は個人データではありません。品番、BOM、工程、設備、在庫数量、ロット番号、原価。これらはPDPAの対象外です。国外リージョンに置いても、PDPAの国外移転の論点にはなりません。

問題になるのは次のような項目です。

• 実績入力に紐づく作業者のID・氏名（誰がいつ何を作ったかの記録）
• 入退場記録や勤怠と連携している場合の出退勤データ
• 指紋認証や顔認証を使っている場合の生体データ（一般にセンシティブな個人データとして扱われ、より慎重な取り扱いが求められます）
• 取引先の担当者名・連絡先（購買モジュールに入ります）

このうち生体データは特に注意が必要です。認証をどうするかという先ほどの議論と、データ所在の議論がここで交差します。「現場のログインを指紋にしたい」という要望は運用上は合理的ですが、その瞬間に、より慎重な取り扱いが必要なデータを抱えることになります。テンプレートをどこに保存するか、国外へ出るのか、同意はどう取得するかを、設計段階で法務に確認してください。

もうひとつ、見落とされがちな論点があります。データがタイ国内のリージョンに置かれていても、国外のサポート拠点から運用担当者がアクセスする場合、それが移転に当たりうるという点です。SaaSベンダーのサポートがシンガポールやインドにある構成は珍しくありません。契約書のデータ処理条項と、実際のアクセス経路の両方を確認する必要があります。「データはタイ国内です」という営業の説明は、保存場所の話であって、アクセス元の話ではありません。

法解釈の最終判断は必ず法務部門または現地の弁護士に確認してください。この記事で示せるのは、確認すべき項目の一覧までです。

オンプレミスを選ぶなら決めておく4つの期限

ここまでクラウド寄りに読める内容が続きましたが、オンプレミスを選ぶ合理性は当然あります。回線断でも動く、応答が速い、データが物理的に手元にある。停止許容時間が短い機能を多く抱える工場では、正しい選択です。

ただし、オンプレミスを選ぶなら4つの期限を先に決めてください。決めずに導入すると、5年後に「動いているけれど誰も触れないサーバー」ができます。

1. OSのサポート期限。 Windows Server 2016（Microsoft社）の延長サポートは2027年1月12日に終了します。いま2016で動いているサーバーが工場にあるなら、残りの猶予は逆算できます。新規に構築する場合も、選定したOSの延長サポート終了日を稟議書に書き込んでください。この1行があると、次の更改予算を組む時期が自動的に決まります。

2. データベースのサポート期限。 SQL Server 2019（Microsoft社）はメインストリームサポートが2025年2月28日に終了し、延長サポートは2030年1月8日に終了します。メインストリームが終わっているということは、機能追加も仕様変更を伴う修正も原則提供されないということです。稼働はしますが、新しい要件には応えられません。

3. ハードウェア保守の期限。 サーバーの保守契約は通常5年です。5年を過ぎると保守部品の供給が止まり、故障時の復旧手段が「同型機を中古で探す」になります。この状態で「RTO 15分」を維持するのは不可能です。保守契約の終了日と、機能ごとのRTOを同じ表に並べて確認してください。

4. 人の期限。 最も見落とされる期限です。そのサーバーを設定した人は、5年後もこの拠点にいるでしょうか。日系工場の情報システム担当は、駐在員であれば任期があり、ローカルスタッフであれば転職があります。属人的に構築されたオンプレミス環境は、担当者の退任と同時にブラックボックスになります。構成情報とパスワードの管理場所を、個人ではなく組織に紐づけてください。 具体的には、構成図・IPアドレス台帳・管理者アカウント一覧・ベンダー連絡先を1つのドキュメントにまとめ、日本本社と現地の2箇所に保管し、年1回更新する。この運用があるかないかで、5年後の選択肢が変わります。

なお、この4つの期限のうち1と2と3は、クラウドを選ぶと事業者側の責任範囲に移ります。クラウドの費用に含まれているのは計算資源だけではなく、この期限管理の外部化でもあります。試算で見た年額の差408,000 THBを高いと見るか妥当と見るかは、自社にこの管理を続ける体制があるかどうかで変わります。

ハイブリッド構成の3パターン

シナリオCで見たとおり、ハイブリッドは安くありません。フルクラウドより244万THB高く、フルオンプレミスより37万THB高い。それでもハイブリッドを選ぶ理由は、費用ではなく停止許容時間です。この点を最初に共有しておかないと、稟議の途中で「ハイブリッドにしたのに高いじゃないか」という議論が必ず起きます。

買っているのは金額ではなく停止許容時間である。 これを提案書の1行目に書いてください。

そのうえで、ハイブリッドには実務上3つのパターンがあります。

パターン1：現場系オンプレミス／管理系クラウド。 シナリオCがこれです。ラベル発行、実績入力、在庫引当といった停止許容時間の短い機能を工場内のエッジサーバーに置き、購買、原価、分析、マスタ管理をクラウドに置く。境界が業務的にはっきりしているため、責任分界も明確です。弱点は、現場系のライセンスとクラウド側のライセンスを二重に持つことと、連携部分が追加開発になることです。試算で追加開発が400,000 THB（フルクラウドの300,000 THBより高い）になっているのはこのためです。

パターン2：本体はクラウド、工場内に読み取り専用キャッシュと印字機能だけを置く。 システムの本体はすべてクラウドに置き、工場内には品番マスタと在庫の複製、そしてラベル印字機能だけを置く構成です。書き込みは常にクラウドへ行くため、データの整合は取りやすい。回線断中は「見る」と「刷る」だけができ、「登録する」はできません。パターン1より安く構築できますが、実績入力を継続できないため、実績入力のRTOが短い工場では足りません。

パターン3：本番はクラウド、オンプレミスは縮退運転専用。 平常時はすべてクラウドで動かし、工場内のサーバーは災害時・長期回線断時にのみ起動する縮退用として置く構成です。DR（災害復旧）の考え方をそのまま持ち込んだものです。最大の落とし穴は、縮退側を平常時に使わないため、いざというときに動かないことです。使っていない待機系は必ず腐ります。四半期に1回は縮退側だけで半日運用する訓練を、運用設計に組み込んでください。訓練を組み込めないなら、このパターンは選ばないほうがよい。

3パターンとも、決め方は同じです。機能ごとのRTOの表を横に置き、「この機能はどちら側に置けば表の値を満たせるか」を1行ずつ判定する。それだけです。技術的な好みで決める場面はありません。

発注前に決める7項目（チェックリスト）

見積を取る前に、社内で決めておく項目を挙げます。この7項目が埋まっていれば、ベンダー各社の提案を同じ土俵で比較できます。埋まっていなければ、各社が違う前提で見積を出し、比較が成立しません。

7番について補足します。SaaSを選ぶ場合、契約終了時にデータをどの形式で受け取れるかを契約書で確認してください。「CSVで出力可能」だけでは足りません。マスタの階層構造、BOMの親子関係、添付ファイル、変更履歴が出力対象に含まれるかを個別に確認します。ここが曖昧なまま5年運用すると、次の更改で「移行費用が高すぎて動けない」状態になります。値上げ条項も同様で、年間の上限改定率が契約に書かれていない場合、5年総額の試算そのものが成立しません。

6番も実務上は重要です。同じ様式で出させないと、初期費用だけが安く、年額が高い提案が有利に見えます。試算で示したとおり、この規模では年額の差が5年で数百万THBの差になります。提出様式は発注側が指定してください。

よくある質問（FAQ）

生産管理システムのクラウドとオンプレミス、どちらが安いですか？

比較期間によります。本記事のモデル工場（従業員180名、利用者40名）では、5年総額でフルクラウドが9,210,000 THB、フルオンプレミスが11,280,000 THBで、クラウドが2,070,000 THB安くなります。累計費用が逆転するのは10.1年目、6年目にハードウェアとOSの更改1,350,000 THBを1回入れると13.4年目です。通常の投資判断期間である5〜7年には収まらないため、この規模では費用を判断軸にしても答えが出ません。停止許容時間で決めてください。

クラウド型 生産管理システムの費用相場は？

タイ拠点の規模と要件で大きく変わるため、単価だけを見ても判断できません。参考として、日本国内のクラウド型生産管理システムの価格帯は、月額3〜5万円程度からで、ユーザー課金制なら1人あたり月額1万円前後、初期費用は数十万円規模とされています。オンプレミス型は初期100万〜300万円程度、月額3万円程度が目安です。ただしこれは日本国内の相場であり、タイでの導入では要件定義・マスタ移行・タイ語対応・現場教育の工数が別途乗ります。本記事の試算でフルクラウドの導入支援を1,800,000 THBとしているのは、この部分です。ライセンス単価ではなく、初期＋年額×5の総額で比較してください。

タイの工場でクラウド型の生産管理システムは回線的に使えますか？

帯域よりも、1操作あたりの往復回数とRTTの積で決まります。RTTの目安は、バンコク国内リージョンで5〜15ms、バンコク〜シンガポールで25〜40ms、バンコク〜東京で70〜90msです。これらはあくまで一般的に観測される目安であり、確定値ではありません。必ず自社の回線から実測してください。1スキャンで5往復する実装なら、東京リージョンでは往復だけで5×80ms ＝ 0.4秒が上乗せされます。バンコク国内リージョンなら5×10ms ＝ 0.05秒です。帯域を増やしてもこの差は縮まりません。往復回数を減らすか、距離を縮めるかの2つしか手段はありません。

オンプレミスのままでよいのはどんな場合ですか？

停止許容時間が5〜15分の機能が業務の中心にあり、かつ回線の冗長化が現実的でない立地にある場合です。加えて、OS・データベース・ハードウェア保守の期限を管理し続ける体制が拠点内にあることが条件になります。この体制がないままオンプレミスを維持すると、Windows Server 2016（Microsoft社）の延長サポートが2027年1月12日に終了するといった期限が来るたびに、緊急対応での更改を強いられます。逆に、原価集計や購買のように3営業日止まっても業務が回る機能まで含めてオンプレミスに置く合理性はありません。「オンプレミスのままでよいか」ではなく「どの機能をオンプレミスに残すか」で考えてください。

基幹システムのクラウド移行にはどれくらい期間がかかりますか？

生産管理システムの範囲であれば、要件定義から本稼働までおおむね1年前後を見込む案件が多くなります。ただし工場の規模と既存データの状態で大きく振れるため、一般化できる数字ではありません。自社の条件で見積もりを取ってください。期間を延ばす要因は、機能の数ではなくマスタの状態です。品番マスタに重複があり、BOMが現物と合っておらず、単位や取引先コードが部門ごとに違う。この整理に想定の2倍かかる案件が最も多い。移行の可否を左右するのは新システムの機能ではなく、既存データの品質です。並行稼働の期間をどう取るかも先に決めてください。旧システムを止める日を決めずに始めると、並行稼働が終わりません。

まとめ

2026年、バンコクにクラウドリージョンが揃い、「タイ国内にデータを置く」が初めて標準的な選択肢になりました。しかし変わったのはデータ所在の制約だけで、判断の枠組みは変わっていません。

やめるべきは、「クラウドかオンプレミスか」をシステム全体でひとつ選ぼうとすることです。生産管理システムの中には、5〜15分しか止められないラベル発行と、3営業日止まってよい原価集計が同居しています。この2つに同じ答えを出そうとするから、会議が終わりません。決定の単位は機能です。

判断軸は費用ではありません。モデル工場の試算では、5年総額はフルクラウド9,210,000 THB、フルオンプレミス11,280,000 THB、ハイブリッド11,650,000 THBで、累計費用の逆転は10.1年目、更改を1回入れると13.4年目でした。5〜7年の投資判断期間に収まらない差は、判断軸として機能しません。ただし5年という固定期間で見るなら、逆転を決めるのは年数ではなく人数です。利用者が約59名を超えるとフルオンプレミスの総額を上回ります。5年後の利用者数を先に確認してください。

そして最も抜けやすいのが認証です。認証は業務機能の一覧に載らないのにすべての機能の前段にあり、RTOを誰も割り当てていません。だから移行後の最初の障害は認証で起きます。認証のRTOは、機能表の最短値に合わせてください。

ハイブリッドを選ぶなら、それが安いからではないことを最初に共有してください。試算ではフルクラウドより244万THB高く、フルオンプレミスより37万THB高い。買っているのは金額ではなく停止許容時間です。この前提を共有せずに進めると、稼働後に必ず揉めます。

次にやることは、見積を3社から取ることではありません。機能ごとの停止許容時間を、製造部門と工場長に埋めてもらうことです。その表さえあれば、どの機能をどちら側に置くかは機械的に決まります。表がなければ、どのパッケージを選んでも判断はできません。

機能をどちら側に置くかの切り分けは、現場の運用と回線の実態を見ないと判断できません。同じ「ラベル発行15分」でも、仮置き場の広さと出荷便の時刻で、実際に持ちこたえられる時間は変わります。TOMAS TECHはバンコクを拠点に、日系製造業の工場ITとFA領域で、生産管理システムの選定・移行・現場側の運用設計に関わってきました。パッケージがまだ決まっていない、クラウドにすべきかも決まっていない——その切り分けの段階からご相談いただけます。現状の機能一覧と回線構成をお持ちでしたら、停止許容時間の表を埋めるところからご一緒します。お問い合わせはこちらからご連絡ください。