タイ システム開発会社の選び方2026｜費用相場と発注の実務

「タイでシステムを作りたいが、どこに頼めばいいのかわからない」——バンコクや東部臨海の工業団地で、日系メーカーの方から最も多く聞く相談のひとつです。タイ システム開発会社と一口に言っても、日系専業ベンダー、タイローカルベンダー、グローバルSIerのタイ法人、オフショア開発拠点では、得意な案件も価格も保守の作法もまったく異なります。本記事では2026年時点の市場データを踏まえ、4タイプの違い、選定の判断軸、費用と隠れコスト、PDPAやBOIといった制度面、そして失敗を避ける発注の進め方までを実務目線で整理します。

タイのシステム開発市場の現在地：数字で押さえる2026年

発注先を比較する前に、まず「いまタイのIT市場がどういう状態にあるか」を押さえておくと、見積書の読み方が変わります。ベンダーの提示単価や納期が高いのか安いのか、無理があるのかないのかは、市場の需給を知らないと判断できないからです。

市場は拡大局面にあり、開発リソースの奪い合いが起きている

Mordor Intelligence の推計では、タイのIT・セキュリティ市場は2026年に 100.3億USD となり、年平均成長率（CAGR）10.26%で2031年には 167.2億USD に達する見通しです。二桁成長が5年続くという前提の市場であり、これは裏を返せば「使えるエンジニアの取り合いが続く」という意味でもあります。

一方、より狭い定義であるITサービス市場については、Data Bridge Market Research が2025年時点で約 25億USD、2025〜2030年のCAGRを 3.31% と見ています。内訳では、ITアウトソーシングが最大規模の 10.3億USD、ソフトウェアサービスが 11.3億USD（CAGR 4.46%）、そしてデジタルサービスが最も高い成長率 約34% を示しています。

この2つの数字を並べると、市場の性格が見えてきます。市場全体（ハードウェア、セキュリティ製品、クラウド基盤を含む）は二桁で伸びる一方、従来型のITサービス、つまり「人が常駐して運用する」タイプのビジネスの伸びは緩やかです。伸びているのはデジタルサービス——クラウドネイティブ、データ活用、AI関連といった新しい領域に明確に偏っています。

発注側の実務に翻訳するとこうなります。従来型のスクラッチ開発＋常駐保守という座組みは、供給側から見ても成長領域ではなくなりつつある。したがって、ベンダーを選ぶときには「その会社がこの5年でどちらの方向に投資しているか」を見るべきです。過去の実績だけでなく、クラウド、API連携、データ基盤といった領域に人材を張っているかどうかが、5年後の保守品質を左右します。

公共部門のクラウド移行が民間の常識を引き上げる

制度面の動きも無視できません。タイのデジタル政府開発機構（DGA）は、新規の公共部門ワークロードの 70%を2027年までにクラウドへ 移行する方針を打ち出しています。さらに、412の政府機関が2026年12月までに最低1つの基幹システムをクラウドへ移行する 必要があるとされています。

政府調達がクラウド前提に振れると、そこに納品するベンダー側の標準的な設計スキルもクラウド前提に寄っていきます。逆に言えば、いまだにオンプレミス前提の提案しか出てこないベンダーは、この数年でスキルセットの更新が止まっている可能性を疑ってよい、ということです。

インフラ側の選択肢も広がりました。Google Cloud はバンコクリージョンを開設済みで、タイ国内にデータを置いたままクラウドの利便性を取る、という設計が現実的な選択肢になっています。後述するPDPAや重要情報インフラ規制との兼ね合いで、この「国内リージョンがある」という事実は設計上かなり効いてきます。

生成AIの普及速度は世界トップクラス

もうひとつ、意外に思われるかもしれない数字があります。BigGo ファイナンスの報道によれば、タイで生成AIを積極的に利用する人の割合は2026会計年度Q1に 12.4%、前年比 +36.4% の伸びを示し、AI導入スピードで 世界2位 に浮上しました。

「タイは技術の受け入れが遅い」という先入観を持っている日本本社の方は少なくありませんが、少なくとも生成AIに関しては逆です。現場のタイ人スタッフが業務でAIツールを使いこなしはじめている一方で、日系企業の社内ルールが追いついていない、というねじれが起きているケースもあります。ベンダー選定の場面でも、AI活用を織り込んだ開発生産性の話ができる相手かどうかは、見積の妥当性を測るひとつの目安になります。

タイのシステム開発会社は大きく4タイプに分かれる

ここからが本題です。タイでシステム開発を発注するときの選択肢は、実務上おおむね4つのタイプに整理できます。それぞれ「悪いタイプ」があるわけではなく、案件の性格との相性の問題です。

タイプ1：日系専業ベンダー（タイ現地法人）

日本人が経営または主要ポジションにいて、日本語で要件定義から保守まで対応するベンダーです。日系製造業向けの生産管理、会計連携、勤怠、原価計算といった領域に実績を持つ会社が多く、日本本社の情報システム部門とも日本語でやり取りできます。

強みは、日本語での要件定義とタイ人開発者への橋渡しが組織として組み込まれていること、そして日本の商習慣（検収、稟議、報告書の粒度）とタイの実務の両方を理解していることです。弱みは、大規模案件を一括で受けきる体力が限られる会社が多いこと、そして単価がローカルベンダーより高くなりやすいことです。

タイプ2：タイローカルベンダー

タイ資本、タイ人経営のシステム開発会社です。数としては最も多く、価格競争力があります。タイの税制、電子インボイス（e-Tax Invoice）、社会保険、労働法まわりの実装ノウハウを持っている会社もあり、タイ国内向けの業務システムでは強みを発揮します。

一方で、コミュニケーションは英語かタイ語が基本です。日本語対応を掲げていても、実際には営業だけが日本語で、開発チームには通じないというケースがあります。また、ローカル向けの会計・業務パッケージは多通貨・多言語に対応しておらず、操作画面がタイ語のみで日本人管理者が内部統制を効かせられない、という問題が実際に起きています。日本本社への報告や監査対応を考えるなら、この点は事前に必ず確認すべきポイントです。

タイプ3：グローバルSIerのタイ法人

外資系の大手SIerやコンサルティングファームのタイ拠点です。ERP刷新、グローバル標準テンプレートの展開、複数国同時ロールアウトといった大規模案件では、方法論と人員動員力が圧倒的です。ガバナンス文書や監査対応の成果物も整っています。

反面、単価は最も高く、小規模案件では最低受注金額の壁に当たります。また、担当コンサルタントの入れ替わりが早く、「タイ工場の現場をわかっている人」が最後まで残るとは限りません。工場の現場端末やOTネットワークに踏み込む案件では、別途現地パートナーが必要になることも多いです。

タイプ4：オフショア開発拠点（他国リソースの活用）

ベトナム、インド、フィリピン、ミャンマーなどの開発拠点を使い、タイの案件を遠隔で開発する形態です。あるいは、タイ拠点の会社が他国のオフショア拠点をバックエンドとして持っている場合もあります。

大量の実装工数が必要なWeb系・アプリ系の案件ではコスト効率が高く、体制の拡張も速いのが特徴です。ただし、タイ国内の現場に足を運ぶことが前提となる案件——工場のライン、設備、現場端末が絡む案件——では、物理的な距離がそのままリスクになります。障害発生時に「明日現地に行く」ができない体制で、24時間稼働の工場システムを支えられるかは慎重に検討すべきです。

4タイプ比較表

実務では「1社にすべてを任せる」よりも、基幹は日系専業ベンダー、Web周りはオフショア、全社ERPはグローバルSIerというように、レイヤーごとに使い分ける企業が増えています。ただし、その場合は必ず結合点の責任分界を契約書で明示しておく必要があります。

選定の判断軸：価格より先に確認すべき7つのポイント

見積金額は最後に見る、というくらいでちょうどよいと考えています。金額差の多くは、以下の判断軸のどこかを削ったか、含めたかの違いに過ぎないからです。

判断軸1：要件定義を何語で行うか

最大の分岐点です。要件定義を日本語で行い、実装をタイ語で行う場合、その間に必ず翻訳が発生します。この翻訳を誰がやるのか、翻訳の結果を誰がレビューするのかを明確にしないと、「日本語の要件がタイ語の実装に正しく落ちない」という典型的な失敗が起きます。

確認すべきは「日本語ができる人がいますか」ではなく、「要件定義書を書く人と、それを読んでコードを書く人の間に、何回の言語変換が入りますか」という問いです。0回（日本語で書いてタイ人開発者が日本語で読む）、1回（日本語→英語）、2回（日本語→英語→タイ語）で、仕様の劣化リスクはまったく違います。

判断軸2：現場（業務部門）をどう巻き込む設計になっているか

日系企業のシステム導入が失敗する最大の要因は、技術ではありません。業務部門がコミットせず、IT部門だけが走ってしまうこと、そしてベンダー任せで自社検収をしないことです。

提案書の段階で「業務部門のキーパーソンをどのフェーズで何時間拘束するか」が書かれているベンダーは、この失敗を経験して学んでいる可能性が高いです。逆に「弊社にお任せください、御社の負担は最小限です」という提案は、耳当たりはよくても危険信号だと考えています。

判断軸3：保守体制の実態

契約書上の「24時間365日対応」が、実態としてどう運用されるかを確認します。一次受けの窓口は誰か、二次対応のエンジニアは何人いるか、深夜の障害で実際に工場に行けるのか。工場の生産管理システムは止まると生産が止まるので、レスポンスタイムの定義（受付までか、復旧までか）まで詰めておくべきです。

判断軸4：拠点の物理的な距離

意外と軽視されがちですが、重要です。アユタヤ、ラヨーン、チョンブリ、プラチンブリの工業団地に工場がある場合、バンコク中心部のオフィスから片道2〜3時間かかります。「何かあれば行きます」の実行可能性は距離に比例します。

現地立会いが必要な作業（現場端末の設置、ネットワーク工事の立会い、設備との通信試験）が何日分見込まれているか、その交通費・宿泊費が見積に含まれているかを確認してください。

判断軸5：ドキュメントの言語と粒度

納品されるドキュメントが英語のみだった場合、日本本社の情報システム部門がレビューできない、という事態が起きます。逆にタイ語のみだと、日本人管理者が内部統制を効かせられません。

現実的な落としどころは、設計書は日本語または英語、操作マニュアルは日本語とタイ語の両方という組み合わせです。誰がどの言語版を作り、翻訳費用が見積に含まれているかを契約前に確定させてください。

判断軸6：日タイ両方の商習慣理解

日本本社の標準システムをそのまま持ち込み、タイの税制・帳票・現場運用に合わない、という失敗は繰り返し起きています。逆に、タイの実務にだけ合わせると本社連結や監査で困ります。

VAT（付加価値税）、源泉徴収税（Withholding Tax）、Tax Invoice の様式、輸出入とBOI恩典に関わる書類——このあたりを実装した経験のあるベンダーかどうかは、率直に聞いて具体例を挙げてもらうのが確実です。

判断軸7：撤退・引き継ぎのしやすさ

最も見落とされる軸です。そのベンダーとの関係が終わったとき、システムを別のベンダーに引き継げるか。ソースコードは誰のものか、開発環境は再現できるか、特殊なフレームワークやベンダー独自ライブラリに依存していないか。

「この会社としか続けられない構造」になっていないかを、契約前に確認しておくことをおすすめします。技術選定の一般性（広く使われている言語・フレームワーク・DBか）は、そのまま将来の交渉力になります。

費用の考え方：単価表だけでは総額は読めない

「タイの人月単価はいくらですか」という質問をよくいただきますが、実はこの問いは、総額を見積もるうえではあまり有効ではありません。理由を順に説明します。

周辺国の人月単価から相場観をつかむ

まず参考として、オフショア開発白書2025年版（2026年2月13日時点）による主要国の人月単価を挙げます。

なお同資料では、プログラマーの平均単価は34万円に下落したとされています。

重要な注意点として、この統計にタイの数値は含まれていません。タイは公開されている単価統計が乏しく、信頼できる数字として提示できるものがないのが実情です。現場感覚としては「ベトナムやフィリピンと同水準から、やや高めのレンジに収まることが多く、日本語対応のブリッジ機能が付くとさらに上振れする」という程度の定性的な理解にとどめるのが誠実だと考えています。具体的な単価は、必ず複数社から実際の見積を取って比較してください。

そして単価表を見るときのコツは、ブリッジSEとPMの単価に注目することです。上の表でも、プログラマーとPMの間には2倍近い開きがあります。日系案件では、この「翻訳と調整を担う層」の工数比率が高くなりがちで、そこが総額を押し上げます。プログラマー単価の安さだけで発注先を選ぶと、この構造を見落とします。

費用は「初期」「保守」「隠れコスト」の3層で分解する

見積書は初期費用しか書かれていないことが多いのですが、システムの総所有コスト（TCO）は5年で見ると保守費用のほうが大きくなることも珍しくありません。以下のように分解して比較することをおすすめします。

特に データ移行と自社工数 は、当初見積の想定を超えることが多い領域です。既存のExcel台帳や旧システムのマスタデータは、たいてい表記ゆれ、重複、廃止済みコードを抱えています。このクレンジングは発注側にしかできない作業であり、ここを甘く見ると全体スケジュールが後ろ倒しになります。

見積比較のときに揃えるべき前提

複数社から見積を取るときは、以下の前提を揃えないと比較になりません。

• 対象業務の範囲（どの業務プロセスまでを含むか）
• 想定ユーザー数と同時接続数
• データ移行の対象期間と件数
• テストの範囲（単体・結合・受入のどこまでをベンダーが担うか）
• 保守の対象時間帯とレスポンスタイム
• ドキュメントの種類と言語
• 稼働後の改修枠（月あたりの工数）

この7項目を書いた1枚のシートを作り、全社に同じ条件で提示するだけで、見積の比較精度は大きく上がります。

契約・法務でつまずくポイント

タイでのシステム開発契約は、日本と同じ感覚で進めると想定外の論点に当たります。特に近年はデータ保護規制が強化されており、設計段階で織り込んでおかないと後戻りが発生します。

PDPA（個人情報保護法）とデータの置き場所

タイのPDPAは2022年6月に全面施行されました。まず押さえるべき事実として、タイには一般的なデータローカライゼーション義務はありません。つまり「タイ人のデータは必ずタイ国内に置かなければならない」というルールが全業種に課されているわけではない、ということです。

ただし例外があります。2024年9月、NCSC（国家サイバーセキュリティ委員会事務局）が重要情報インフラ事業者（CIIO）向けのクラウド利用規則を採択しました。この規則では、「高」影響度の情報システムについて、主データセンターをタイ国内に置き、バックアップはタイ国内またはASEAN域内に置くことが義務づけられています。自社がCIIOに該当するかどうか（エネルギー、金融、公衆衛生、輸送、通信などが典型）は、早い段階で法務に確認しておくべきです。

国外へのデータ移転については、ホワイトリスト国への移転、または 標準契約条項（SCC） による移転が基本的な枠組みとなります。日本本社のサーバーにタイ従業員の人事データを集約する、といった構成は珍しくありませんが、この場合はグループ内のデータ移転契約を整備しておく必要があります。

なお、政府クラウドについては原則としてタイ国内保管とされ、例外にはDGAの承認が必要です。官公庁向けの案件に関わる場合は前提が変わります。

前述のとおりGoogle Cloudがバンコクリージョンを開設済みであるほか、国内リージョンの選択肢は広がっています。「クラウドを使うと国外にデータが出る」という前提は、もはや必ずしも正しくありません。

著作権・ソースコードの帰属

日本の実務では「納品物の著作権は発注者に移転する」と書くのが一般的ですが、タイのベンダーとの契約では、ソースコードの著作権はベンダーに留保され、発注者には使用許諾のみが与えられるという条件が提示されることがあります。

ここは必ず明示的に交渉すべき点です。最低限、以下を契約書で確定させてください。

• 納品物（ソースコード、設計書、ビルド手順）の著作権または利用権の範囲
• 第三者に改修を委託する権利があるか
• ベンダーが既存で保有するライブラリ・フレームワーク（背景資産）の扱いと、それに依存した場合の継続利用条件
• オープンソースライブラリのライセンス一覧の提出義務

「別のベンダーに乗り換えられるか」は、この条項で決まります。

検収条件と瑕疵対応

検収基準が「発注者が承認したとき」としか書かれていない契約は、双方にとって不幸です。何をもって合格とするかを、テスト項目と合格基準のレベルまで具体化しておくべきです。

• 受入テストの期間（何営業日か）と、期間経過後の「みなし検収」条項の有無
• 不具合の重大度分類（業務停止／代替手段あり／軽微）と、それぞれの対応期限
• 瑕疵担保（契約不適合責任）の期間——日本の慣行より短い提示がされることがあります
• 稼働後の性能要件（レスポンスタイム、同時接続数）を検収項目に含めるか

契約書の言語と準拠法

タイでは、契約書を英語で締結し、タイ語版を参考訳とするケースが多く見られます。日系企業同士でも、タイ法人間の契約であれば英語が実務的です。

重要なのは、言語間で齟齬があった場合にどの言語版が優先するかを明記することです。また準拠法と紛争解決手段（タイの裁判所か、シンガポール等での仲裁か）は、いざというときのコストを大きく左右します。金額の大きい案件では、契約段階でタイの法律事務所にレビューを依頼する価値は十分にあります。

なお、システムが工場のOT（制御）ネットワークに接続する場合は、セキュリティ要件と責任分界も契約に落とし込む必要があります。この領域の考え方はOTセキュリティ 工場の実務ガイド2026で詳しく整理しています。

BOI恩典とコスト設計：ソフトウェア開発も対象になる

コスト面で見落とされがちなのが、タイ投資委員会（BOI）の恩典です。製造業の恩典はよく知られていますが、ソフトウェア開発そのものも恩典の対象カテゴリになっています。

最大8年間の法人所得税免除

BOIには「ソフトウェア、デジタルサービスプラットフォーム、デジタルコンテンツの開発」というカテゴリがあり、最大 8年間の法人所得税免除 が認められます。AIを活用したシステム開発、クラウドサービス、データセンター運営も対象に含まれます。

恩典の年間上限額の算定にあたっては、タイ人IT人材の追加雇用にかかる費用、その訓練費用、そして ISO 29110 や CMMI レベル2以上といった国際標準認証の取得費用 が考慮されます。つまり、「タイ人エンジニアを雇って育て、開発プロセスを標準化した会社ほど恩典が大きくなる」という設計思想です。

発注者側の実務的な意味

自社でソフトウェア開発子会社を設立する場合を除けば、BOI恩典は直接的には発注先ベンダー側の話です。しかし、発注者にとっても2つの意味があります。

ひとつは、ベンダーの品質シグナルとして使えることです。ISO 29110 や CMMI レベル2以上の認証は、開発プロセスが文書化され、レビューと構成管理が回っていることの一定の証明になります。提案依頼の際に認証取得状況を質問項目に入れておくと、体制の成熟度を測る材料になります。

もうひとつは、グループ内でIT機能を現地法人化する構想がある場合、BOI恩典を含めて設計すると総コストが変わるということです。タイ国内に開発機能を持ち、ASEAN他拠点へも展開する——という構想であれば、BOI申請を前提に検討する価値があります。

いずれにせよBOIの適用条件は案件ごとに判断されるため、一般論で結論を出さず、事業計画を持って個別に相談するのが確実です。

よくある失敗パターン5つと回避策

ここからは、実際にタイで繰り返し起きている失敗のパターンを整理します。技術的に難しかったから失敗した、というケースはむしろ少数派です。

パターン1：IT部門だけが走り、業務部門がコミットしない

最も典型的です。本社からの指示でIT担当者がプロジェクトを立ち上げるものの、実際に業務を回している製造部門、購買、経理が「自分たちの仕事ではない」と考えている状態。要件定義のヒアリングには出てくるが、テストには参加せず、稼働後になって「これでは仕事にならない」と言い出します。

回避策は、プロジェクト開始時に業務部門側のオーナーを明示し、その人の評価項目にプロジェクトを入れることです。加えて、要件定義の成果物には業務部門長のサインをもらう運用にします。

パターン2：要件が固まらないまま着手し、仕様変更が積み上がる

「まず作ってみて、動くものを見ながら決めましょう」というアプローチ自体は悪くありませんが、変更管理のルールがないまま始めると、追加要望が無限に積み上がります。結果として予算超過とスケジュール遅延が同時に起きます。

回避策は、変更管理プロセス（誰が変更を承認するか、変更単価はいくらか、いつまでなら変更を受け付けるか）を契約時に決めておくこと。そして、フェーズを区切って「このフェーズで凍結する範囲」を明確にすることです。

パターン3：ローカルの業務ソフトが多通貨・多言語に対応していない

タイ国内向けに作られた会計・業務パッケージは、タイバーツ単一通貨、タイ語画面のみという前提のものが少なくありません。導入後に「日本本社への報告のために結局Excelで作り直している」「日本人管理職が画面を読めず承認プロセスが形骸化している」といった事態になります。

回避策は、選定段階で日本人管理者が使う画面と、本社報告に使う出力を具体的に指定し、デモで実際に見せてもらうことです。カタログの「多言語対応」という記載だけを信じないでください。

パターン4：日本本社の標準システムをそのまま持ち込む

グローバル標準化の方針自体は正しいのですが、タイの税制（VAT、源泉徴収税）、帳票様式、現場の運用（多能工、シフト、外国人労働者を含む勤怠管理）に合わないまま導入すると、現場が二重入力を強いられます。

回避策は、標準テンプレートを持ち込む場合でも、「絶対に譲れない部分」と「現地に合わせる部分」を事前に線引きすることです。会計コード体系や連結報告の粒度は標準化し、現場のオペレーション画面は現地化する、という切り分けが現実的です。

パターン5：ブリッジ人材が不在で仕様が正しく伝わらない

日本語の要件が、英語を経由してタイ語の実装に落ちる過程で、ニュアンスが失われます。特に日本語特有の「暗黙の前提」——たとえば「当然、月末締めですよね」といった業務常識——は、書かれていなければ実装されません。

回避策は、要件定義書に「暗黙知を書き出す」セクションを設けることと、ブリッジSEに業務理解を求めることです。単なる通訳ではなく、業務を理解して仕様を再構成できる人材がいるかどうかが分水嶺になります。

発注の進め方：RFI → RFP → PoC → 段階導入

比較検討フェーズにいる方に最もお伝えしたいのは、いきなり大きく発注しないということです。以下の4段階で進めると、リスクを段階的に減らせます。

ステップ1：RFI（情報提供依頼）で市場を知る

まだ要件が固まっていない段階では、RFI から始めます。「こういう課題があるのですが、どういう解決の選択肢がありますか」と複数社に投げかけ、アプローチの違いを見る段階です。

この段階で聞くべきなのは価格ではなく、似た課題をどう解いた経験があるかです。同業種・同規模の事例、そのときの体制、期間、うまくいかなかった点。誠実なベンダーは失敗談も話してくれます。

RFI は3〜5社程度、期間は2〜4週間が目安です。この段階で自社の課題の解像度が上がることが、実は最大の成果になります。

ステップ2：RFP（提案依頼）で条件を揃える

RFI で得た情報をもとに、RFP を作成します。前述した「見積比較のときに揃えるべき前提」の7項目を必ず含めてください。加えて、以下を明記すると提案の質が上がります。

• 現状の業務フローと課題（できれば As-Is の図）
• システム化して達成したい状態（To-Be の定性目標と、可能なら定量指標）
• 既存システムの一覧と連携要件
• 制約条件（予算レンジ、稼働希望時期、社内標準、データの置き場所に関する方針）
• 評価基準と配点（価格だけでなく、体制、実績、保守、引き継ぎ性）

評価基準を事前に公開することには2つの効果があります。ベンダー側が的を絞った提案をできること、そして社内の選定プロセスに説明責任を持たせられることです。

ステップ3：PoC（概念実証）で小さく試す

いきなり本開発に入らず、限定した範囲で実際に動かしてみる段階です。PoCの目的は「技術的に可能か」の確認だけではありません。むしろそのベンダーと一緒に仕事ができるかを確かめることのほうが重要です。

• 質問への回答速度と正確性
• 想定外の事象が起きたときの報告の仕方
• 現場のタイ人スタッフとのコミュニケーション
• ドキュメントの質

PoC は有償で発注することをおすすめします。無償のPoCは、ベンダー側もリソースを割けず、結局お互いに実態が見えないまま終わります。

ステップ4：段階導入とスモールスタートの設計

本開発に入ってからも、一括で全機能を作るのではなく、価値の出る単位で区切って導入していきます。スモールスタートの設計で重要なのは、「最初の3か月で誰が何を実感できるか」を定義することです。

工場系の案件でよく機能する入り口は、以下のようなものです。

• 現場実績の収集から始める：生産実績、稼働状況、不良数を紙やExcelからデジタルに置き換える。既存の業務を変えずに、データだけを取り始めるので現場の抵抗が少ない
• 見える化から始める：集めたデータをダッシュボードで見せる。「今まで月末にしかわからなかった数字が翌日にわかる」という体験が、次のフェーズへの協力を引き出す
• 紙の削減から始める：受発注票、検査記録、日報などの帳票をデジタル化する。AI-OCRを使えば既存の紙運用を大きく変えずに移行できます（AI-OCRでバックオフィス自動化）
• 1ラインだけで始める：全ラインに展開する前に、1ラインで運用を回して問題を洗い出す

この順序で進めると、投資判断も段階的に行えます。第1フェーズの成果が出てから第2フェーズの予算を承認する、という進め方は、日本本社への説明の面でも通りやすくなります。

生産管理システムそのものの選定基準については、タイ工場の生産管理システム選定ガイド2026で機能要件の観点から整理しています。

工場システム特有の論点：オフィス系システムとは前提が違う

最後に、工場のシステムを発注する場合の固有の論点を整理します。ここを理解していないベンダーに工場系案件を任せると、稼働してから苦労します。

生産管理システムは「止められない」前提で設計する

会計システムなら、深夜のメンテナンスで数時間止めても業務に影響はありません。しかし24時間稼働の工場では、生産管理システムが止まると生産が止まります。

このため、以下が設計要件になります。

• ネットワーク断・サーバー障害時のオフライン運用手順（紙で回して後から入力する運用を含む）
• メンテナンスウィンドウをどこに設定するか（生産計画と調整が必要）
• 冗長構成のレベルと、それにかかるコスト
• 復旧目標時間（RTO）と復旧目標時点（RPO）の合意

「バックアップは取っています」だけでは不十分で、実際にリストアして何時間で復旧するかを試した記録があるかを確認してください。

IoT設備監視は「つながるか」の事前確認が9割

設備からデータを取る案件では、その設備が本当にデータを出せるかどうかが最大の不確実性です。古い設備にはそもそも通信インターフェースがない、PLCのプロトコルが独自仕様、メーカーが情報を開示しない、といった障壁が普通に存在します。

したがって、IoT案件は必ず事前の現地調査（アセスメント）を有償で行うことをおすすめします。設備一覧、型式、制御機器のメーカーと世代、既存の配線状況を洗い出したうえでないと、まともな見積は作れません。この調査を省いて出てきた見積は、後で必ず追加費用が発生します。設備側の自動化・データ取得の考え方はファクトリーオートメーション タイにまとめています。

現場端末は環境条件から決める

事務所のPCと同じ感覚で端末を選ぶと失敗します。工場現場は高温多湿、粉塵、油、振動、作業手袋、大きな騒音——という環境です。

• 手袋をしたまま操作できるか（静電容量式タッチパネルは手袋で反応しないことがある）
• 防塵防滴等級（IP規格）は十分か
• 直射日光下や暗所での視認性
• 作業者がタイ語話者であることを前提としたUI設計
• 端末が故障したときの予備機と交換手順

そして意外に効くのが「入力項目を減らす」ことです。現場端末で入力する項目が10個あると運用は続きません。バーコード・QRコードで済ませ、手入力は最小限にする設計が現実的です。

OTネットワークとITネットワークの接点

生産設備が接続されるOTネットワークと、業務システムが動くITネットワークをどう接続するかは、セキュリティ上の最重要論点です。

原則は、両者をフラットにつながず、明確な境界（DMZ）を設けることです。生産管理システムが設備からデータを取る場合も、設備側から一方向にデータを送る構成にできないかをまず検討します。ランサムウェアがITネットワーク経由で生産設備に到達すると、生産停止という最悪の結果を招きます。

このとき、IT部門とOT（保全・生技）部門のどちらが責任を持つかが曖昧なまま進むケースが非常に多いです。プロジェクトの早い段階で責任分界点を決めておいてください。

なお、工場から出た製品が倉庫・物流へ流れる部分まで含めて設計すると全体最適が見えてきます。この領域の動向は物流DX 東南アジア最新動向2026を参考にしてください。

まとめ：比較のものさしを先に作る

タイでシステム開発を発注するとき、最終的に成否を分けるのは「どのベンダーを選んだか」よりも「どういうものさしで選んだか」だと考えています。

本記事の要点を改めて整理します。タイのIT・セキュリティ市場は2026年に100.3億USD規模へと拡大し、公共部門のクラウド移行や生成AIの急速な普及が進む一方で、従来型のITサービスの伸びは緩やかです。この環境で選択肢となる開発会社は、日系専業ベンダー、タイローカルベンダー、グローバルSIerのタイ法人、オフショア開発拠点の4タイプに整理でき、それぞれ向く案件が異なります。

選定にあたっては、要件定義の言語、業務部門の巻き込み方、保守体制の実態、拠点の物理的距離、ドキュメントの言語、日タイ両方の商習慣理解、そして撤退・引き継ぎのしやすさという7つの軸で見ること。費用は人月単価ではなく、初期・保守・隠れコストの3層で比較すること。契約ではPDPAとCIIOのクラウド規則、ソースコードの帰属、検収条件、契約書の言語と準拠法を確認すること。そして、RFIから始めてPoCを挟み、スモールスタートで段階的に広げていくこと。

工場系の案件であれば、止められない前提の設計、設備の事前アセスメント、現場端末の環境条件、OTネットワークとの境界という固有の論点が加わります。これらは机上の検討では見えず、現場を歩いて初めて判明することが多い領域です。

急がず、しかし止まらず。まずは自社の課題を言語化するところから始めるのが、遠回りのようで最も確実な道筋です。

私たちTOMAS TECHは、バンコクを拠点にタイ・ASEANの日系製造業向けのシステム開発と工場DXに携わっています。「何をシステム化すべきかまだ整理できていない」「複数社の見積を比較したいが、そもそも比較の観点がわからない」といった、要件が固まる前の段階でのご相談も少なくありません。他社との比較検討材料として現地の実務感覚が必要な場合も含め、お問い合わせからお気軽にお声がけください。日本語・タイ語・英語で対応しています。

よくある質問

タイのシステム開発会社の費用相場はどのくらいですか？

タイについては信頼できる公開統計が乏しく、具体的な人月単価を断定することは避けるべきだと考えています。周辺国の参考値として、オフショア開発白書2025年版ではベトナムのプログラマーが40.1万円、フィリピンが37.2万円、インドが37.5万円とされています（2026年2月13日時点）。タイの単価は感覚的にはこれらと同水準からやや高めのレンジに収まることが多く、日本語対応のブリッジ機能が付くとさらに上振れします。実際の総額は単価よりも工数の見積精度と隠れコストで決まるため、必ず複数社から同一条件で見積を取得して比較してください。

日系ITベンダーと現地のタイローカルベンダー、どちらを選ぶべきですか？

案件の性格によります。日本本社への報告や内部統制が必要な会計・原価系、そして日本語での要件定義が必須の案件では日系ベンダーが向いています。一方、タイ国内で完結し、ユーザーがタイ人中心で、法令対応の実装知見が必要な案件ではローカルベンダーに強みがあります。判断のポイントは「要件定義者と実装者の間に何回の言語変換が入るか」です。変換回数が多いほど仕様の劣化リスクが上がるため、そのリスクを許容できるかで決めるとよいでしょう。

オフショア開発とタイ現地開発の違いは何ですか？

最大の違いは物理的な距離です。オフショア開発は他国の開発拠点を使うためコスト効率が高く、Web系・アプリ系の大量実装に向いています。ただし、工場の現場端末や設備との接続、現地立会いが必要な作業がある案件では、「明日現地に行く」ができない体制がそのままリスクになります。オフィス系のシステムはオフショア、工場現場に関わるシステムは現地拠点、という使い分けが実務的です。

BOIの恩典は受託システム開発でも活用できますか？

BOIには「ソフトウェア、デジタルサービスプラットフォーム、デジタルコンテンツの開発」というカテゴリがあり、最大8年間の法人所得税免除が認められています。AIを活用したシステム開発、クラウドサービス、データセンター運営も対象です。恩典の年間上限額は、タイ人IT人材の追加雇用・訓練費用や、ISO 29110・CMMIレベル2以上といった国際標準認証の取得費用を考慮して決まります。ただし適用可否は事業計画ごとに判断されるため、一般論で結論を出さず、個別に相談することをおすすめします。

タイのPDPAでは、データを必ずタイ国内に置く必要がありますか？

タイに一般的なデータローカライゼーション義務はありません。ただし2024年9月にNCSCが採択した重要情報インフラ事業者（CIIO）向けのクラウド利用規則により、「高」影響度の情報システムについては主データセンターをタイ国内に、バックアップをタイ国内またはASEAN域内に置くことが義務づけられています。国外移転はホワイトリスト国、または標準契約条項（SCC）によることが基本です。政府クラウドは原則タイ国内保管で、例外にはDGAの承認が必要です。自社がCIIOに該当するかを早めに確認してください。

システム導入を小さく始めるには、何から手をつければよいですか？

既存の業務プロセスを変えずにデータだけを取り始める領域が入り口として機能しやすいです。具体的には、生産実績や設備稼働状況の収集、ダッシュボードによる見える化、紙帳票のデジタル化、1ラインだけでの試行運用などです。重要なのは「最初の3か月で誰が何を実感できるか」を定義すること。第1フェーズで成果を出してから次の予算を承認する進め方は、日本本社への説明という観点でも通りやすくなります。

発注先を1社に絞るべきですか、複数社を使い分けるべきですか？

規模と領域によります。近年は、基幹の生産管理は現地に強い日系ベンダー、Webフロントはオフショア、全社ERPはグローバルSIer、というようにレイヤーごとに使い分ける企業が増えています。ただし複数社体制では、システム間の結合部分で「どちらの責任か」が曖昧になりやすいのが難点です。使い分ける場合は、インターフェース仕様の管理責任者を発注者側に置き、責任分界点を契約書で明示してください。

参考情報

• Mordor Intelligence — Thailand IT and Security Market: https://www.mordorintelligence.com/industry-reports/thailand-it-and-security-market
• Data Bridge Market Research — Thailand IT Services Market: https://www.databridgemarketresearch.com/reports/thailand-it-services-market
• 一般社団法人ソフトウェア協会 — タイ投資委員会（BOI）より情報提供: https://www.saj.or.jp/NEWS/activity/government/210706_boi.html
• Cookie Information — What is the Thailand PDPA? 2026 guide: https://cookieinformation.com/blog/what-is-the-thailand-pdpa/
• Hogan Lovells — Thailand releases draft guidelines on government cloud adoption and data classification: https://www.hoganlovells.com/en/publications/thailand-releases-draft-guidelines-on-government-cloud-adoption-and-data-classification
• オフショア開発.com — 人気6カ国の単価比較（2026年版）: https://www.offshore-kaihatsu.com/faq/tanka.php
• BigGo ファイナンス — タイ、AI導入速度で世界2位に浮上: https://finance.biggo.jp/news/ENXbs54B-PfaobXfgh3Q
• Google Cloud — Bangkok region launch: https://cloud.google.com/blog/products/infrastructure/google-cloud-launches-new-region-in-bangkok-thailand
• 山田コンサルティンググループ — タイ進出後、日系企業が直面する課題: https://www.ycg-advisory.jp/learning/oversea_28/
• 東洋経済オンライン — ITプロジェクトが失敗する必然: https://toyokeizai.net/articles/-/894218