タイ システム開発会社の選び方｜製造業向け実践ガイド

タイでシステム開発会社を探すとき、提案書の見栄え、時間単価、日本語営業の安心感だけで決めると、稼働直前になって「現場例外が処理できない」「設備やERPにつながらない」「誰が直すのか分からない」という問題が表面化します。製造業の選定で本当に比べるべきなのは、会社紹介ではなく、ひとつの実業務を要件から運用まで通せる証拠です。本稿では、書類審査と有償のthin slice（薄い範囲を端から端まで作る小規模実証）の二段階で、タイの開発パートナーを再現可能に評価する方法を説明します。

タイ システム開発会社を探す企業が先に整理すべきこと

市場の大きさと自社案件の成功確率は別である

タイ投資委員会（BOI）の2026年上半期発表では、投資申請は1,299件、総額1.47兆バーツ（THB 1.47 trillion）で、金額は前年同期比37％増でした。このうちデジタル分野の申請額は約1.12兆バーツ（around THB 1.12 trillion）です。これはタイでデジタル投資への関心が強いことを示す市場文脈ですが、承認額や実現済み投資ではなく、全額が業務システム開発需要でもありません。数字を「どの開発会社でも需要があり品質が高い」という根拠に変換してはいけません。

BOIの現行申請様式には、ソフトウェア、デジタルプラットフォーム、デジタルコンテンツの開発・改修に関する活動区分があります。しかし、BOIの対象であること、認証を保有すること、社員数が多いことは、個別案件の納期、要件理解、テスト品質を直接証明しません。会社属性は一次審査の材料にとどめ、案件に割り当てられるチームと成果物を評価します。

「製品を買う」と「個別開発を委託する」を混同しない

パッケージやSaaSの調達では、標準機能への業務適合、設定範囲、ライセンス条件、バージョンアップ方針、データ持ち出しが中心です。個別開発では、それらに加えて、要件の決め方、設計根拠、ソースコード、ビルド手順、テスト資産、知的財産、保守交代可能性まで確認します。

両方を組み合わせる案件では、たとえば、生産管理パッケージを導入し、タイ工場固有のラベル、承認、設備連携だけを個別開発する場合があります。このとき責任主体を「導入パートナー」「製品ライセンサー」「クラウド事業者」「再委託先」に分けなければ、障害時に責任の空白ができます。パッケージ候補の比較軸はタイの生産管理システム比較ガイドも参考になります。

発注前に成功条件を一文で定義する

「DXしたい」「紙をなくしたい」では会社を比較できません。まず、対象者、対象業務、起点、完了条件、時間や品質の基準を一文にします。例は「倉庫担当者が入荷ラベルを読み取り、ERPの発注残と照合し、不一致を保留キューへ送り、監督者が同一シフト内に処理できる」です。

この一文から、正常系、例外系、連携、権限、性能、復旧、運用引継ぎを展開できます。逆に一文にできない案件は、提案依頼書を配る段階ではありません。業務を小さく切る考え方はタイ製造業のスモールスタート導入で詳しく解説しています。

バンコクのシステム開発で起きやすい選定ミス

最安の時間単価で総費用を判断する

時間単価は入力値の一つですが、必要工数が確定していない段階では総費用を示しません。安い単価でも、要件の再説明、手戻り、受入テストの自社負担、稼働後の障害対応が増えれば総費用は上がります。本稿では市場平均価格を示しません。一次情報で裏付けられない相場を置くより、各社が同じ成果物範囲を見積もる状態を作る方が比較に有効だからです。

見積では、前提条件、対象外、顧客側作業、再見積条件、変更要求の単価と承認フローを並べます。「一式」の金額だけでなく、要件確定、設計、実装、移行、教育、稼働支援、保証、保守を分解してください。

日本語の営業対応を開発力とみなす

日本語窓口は重要です。ただし、営業担当が流暢でも、実際のプロジェクトマネージャー、業務分析者、開発者、テスターが同じ理解を持つとは限りません。提案時に実名の予定チームを示してもらい、誰が日本語・タイ語・英語の要件を決定記録へ変換するのか、担当交代時に誰が承認するのかを確認します。

会議の言語より重要なのは、決定事項、未決事項、変更理由、受入条件が一つの台帳に残ることです。議事録だけでなく、要件IDとテストIDが連動しているかを見ます。

デモの正常系だけを見る

整ったデモデータによる登録・検索を提示できる候補でも、工場で差が出るのは、バーコードが読めない、ERP応答が遅い、数量が超過する、二重送信が起きる、ネットワークが切れる、承認者が不在という例外です。デモでは必ず一つの障害を意図的に起こし、ユーザー表示、再試行、データ整合性、監査履歴、復旧手順まで確認します。

ロゴ、認証、人数を成果保証と誤認する

認証や導入実績は評価材料ですが、それ単独で今回の成功を保証しません。確認すべきは、似た案件から何を再利用できるか、何が違うか、失敗や変更をどう扱ったかです。顧客名を開示できない場合でも、匿名化した要件追跡表、テスト証跡、障害報告、運用手順のサンプルは提示できます。

要件ゲート：提案依頼前に比較可能な土台を作る

要件追跡マトリクスを一枚作る

要件追跡マトリクスは、業務要求を設計、テスト、証拠、責任者へつなぐ表です。最初から全機能を詳細化する必要はありません。選定用のthin sliceに関する10〜20件だけで十分です。

この表があれば、各社は同じゴールを見積もれます。「対応可能」という回答ではなく、「どのテストをどう実行し、何を証拠として渡すか」という回答を求められます。

必須、評価、将来を分ける

全要求を必須にすると、価格が上がり、標準機能を壊すカスタマイズが増えます。Must（稼働条件）、Scored（比較加点）、Future（次期候補）に分類します。Mustは満たさなければ失格、Scoredは100点表で比較、Futureは今回の見積に含めず拡張性だけ確認します。

また、非機能要件を「速い」「安全」と書かないことが重要です。想定同時利用者数、データ量、応答時間の測定点、稼働時間、復旧目標、ログ保存期間など、試験可能な仮定に変えます。確定できない値は「要確認」とし、誰がいつ実測するかを決めます。

現場制約を添付資料にする

タイ工場の案件では、ネットワーク構成、端末OS、スキャナやPLCの型式、ERPのAPIまたはファイル仕様、シフト、停電・回線断時の運用、タイ語マスタ、時刻帯、データ保管地域を添付します。機密情報は候補を絞った後にNDA下で段階開示して構いません。

タイのITベンダーに求める「証拠」のチェックリスト

会社案内の回答は自己申告になりがちです。評価できる証拠へ変換します。

タイ政府のDGAが公開する開発調達例では、ソースコード、試験結果文書、UAT準備、機能・性能・セキュリティ試験、本番準備、導入報告、教育などが成果物として扱われています。2025年に署名され、2026〜2028年度を対象とする別のTOR例では、本番移行前のテストスクリプトに手順、条件、証拠を求めています。民間企業への法的な必須様式ではありませんが、成果物を具体化する参考になります。

100点評価モデルでタイ システム開発会社を比較する

以下はTOMAS TECHによる例示モデルです。自社のリスクに合わせて各項目の中身は調整できますが、候補ごとに配点を変えてはいけません。失格条件を先に適用し、通過社だけを100点で比較します。

0〜5段階を証拠に結び付ける

各軸の獲得点は、評価（0〜5）÷5×配点で計算します。0は回答なし、1は方針のみ、2はテンプレート提示、3は匿名化した実績証拠、4は今回案件に合わせた実行案、5はthin sliceで実証済み、といった定義です。たとえば業務適合25点で評価4なら20点です。

同点の場合の優先順位も決めます。製造停止リスクが高いならテストと復旧、個人データが多いならセキュリティとPDPA、将来の内製化を重視するなら引継ぎをタイブレークにします。営業印象を最後に足して順位を逆転させない運用が重要です。

書類審査の失格条件

ソースまたは設定の引渡しを拒否する、再委託先を開示しない、個人データ処理契約に応じない、実行チームを示さない、受入条件を契約に入れない、といった項目は点数ではなくゲートにできます。ただし、SaaSでソース提供がないのは通常です。その場合はデータエクスポート、API、事業継続、終了時支援で代替します。個別開発と製品購入の条件を同じにしないでください。

比較できるRFPパッケージの作り方

RFPは長い説明書ではなく、候補各社の回答形式をそろえる比較装置です。少なくとも次を含めます。

1. 事業目的と成功指標
2. 対象・対象外の業務範囲
3. 現行フローとthin sliceシナリオ
4. 要件追跡マトリクス
5. システム・データ・設備連携図
6. 非機能要件と未確定の測定計画
7. 成果物、受入、移行、教育、保証の条件
8. セキュリティ、PDPA、再委託の質問票
9. 見積分解表と変更管理ルール
10. 100点評価表と失格条件

回答欄には「標準対応」「設定対応」「個別開発」「第三者製品」「非対応」を設けます。個別開発の場合は工数だけでなく、将来のアップグレード影響と保守主体も回答させます。質問回答は全候補に同じ内容を共有し、特定社だけが有利な追加情報を持たないようにします。

候補を探し始める前に、内製と外注の境界を整理したい場合はタイ製造業のシステム開発外注ガイドも参照してください。

有償thin sliceで提案を実行可能性に変える

小さくても端から端まで通す

無償デモではベンダーが得意な機能を見せます。有償thin sliceでは、自社の代表的な一業務を、実データに近いサンプルで、画面、API、権限、ログ、例外、復旧まで通します。完成品の一部を安く作らせることが目的ではなく、不確実性を買い取ることが目的です。

例示スケジュールとして、2週間で要件・データ対応付け、2週間で提案確認、その後2〜4週間で有償thin sliceを行い、受入証拠に基づいて本契約へ進む流れが考えられます。これは市場平均や納期保証ではありません。設備接続、データ入手、意思決定者の予定によって変わります。

thin sliceで残す成果物

成果物は動く画面だけではありません。更新済み要件追跡表、設計判断、ソース、ビルド・配備手順、テストスクリプト、実行証跡、既知の制約、概算バックログを受け取ります。本契約を結ばない場合にも成果物を利用できる範囲を事前に決めます。

実行中は、質問の質と速度も観察します。良いチームは曖昧さを隠さず、現場へ確認すべき仮定を明示し、選択肢の影響を説明します。要求を何でも「できます」と受ける姿勢より、標準化すべき部分と差別化すべき部分を分ける能力が重要です。

受入テストを契約前に設計する

受入は「ユーザーが触って問題なかった」では再現できません。契約前に、テストデータ、前提状態、操作、期待結果、証拠、担当、合否、再試験条件を決めます。

性能値は現場測定前に推測しません。「5秒」とするなら、端末操作開始、API受信、ERP応答、画面表示のどこを測るかを定義します。回線やERP側が原因の場合の切り分けログも成果物に含めます。

契約・知的財産・ソース引継ぎの確認事項

開発契約は機能一覧だけでなく、将来の変更可能性を確保する設計図です。次の項目を契約本文または添付資料で確認します。

• 顧客または共同管理のソースコードリポジトリへの継続アクセス
• クリーン環境で再現できるビルド、テスト、配備手順
• OSS、商用ライブラリ、外部APIを含む依存関係一覧とライセンス
• 環境別設定の一覧と変更履歴
• 秘密情報を平文で渡さない安全な引継ぎ方法
• 全データと監査ログの機械可読なエクスポート
• バックアップ、復元、災害時切替の手順と試験責任
• 瑕疵保証の期間、対象、除外、再現情報
• 障害重大度、応答・復旧目標、営業時間、連絡経路
• 再委託先の役割、所在、アクセス範囲、変更時の通知
• 既存資産、個別成果物、汎用部品、第三者ライセンスの境界
• 契約終了時のデータ返却、知識移転、並行支援、削除確認

秘密情報は「納品物」としてメール添付させず、顧客管理のパスワード保管庫などで権限移管します。リポジトリにアクセスできても、ビルドできなければ実質的な引継ぎではありません。契約前またはthin slice完了時に、顧客側環境での再ビルドを実演してもらいます。

SaaSではソース引渡しを求める代わりに、データポータビリティ、設定エクスポート、API制限、サービス終了通知、代替移行支援、必要に応じたエスクロー可能性を検討します。

セキュリティとタイPDPAを調達要件にする

セキュリティを認証欄だけで終わらせない

NISTのSecure Software Development Framework（SSDF）v1.1は、組織の準備、ソフトウェアの保護、十分に安全なソフトウェアの生成、脆弱性への対応という成果志向の実務を整理しています。ベンダーバッジではなく、「コードレビューをどこで記録するか」「依存関係の脆弱性を誰がいつ判断するか」「本番の秘密情報へ誰がアクセスするか」という質問に変換できます。

CISAのSecure by Demand Guideも、購入前にセキュリティ質問を行い、調達中に契約要件へ組み込み、調達後に供給者の成果を評価する流れを示します。OWASP ASVS 5.0は2025年5月に公開され、Webアプリケーションやサービス向けの検証可能な要求項目を作る材料になります。ASVSの利用を「認証取得」と表現したり、適用しただけで安全だと判断したりしてはいけません。

PDPA上の役割とデータフローを明記する

タイ・デジタル経済社会省（MDES）が掲載するPDPAの非公式英訳のSection 40では、データ処理者について、管理者の指示に従うこと、適切な安全措置、侵害の通知、必要な処理記録、処理者の活動を管理する契約などが示されています。これは法律助言ではありませんが、開発・保守契約を作る実務チェックポイントになります。

候補会社には、どの個人データが、どの国・環境に、何の目的で保存され、誰がアクセスし、いつ削除されるかを図示してもらいます。開発用コピー、ログ、バックアップ、サポート画面にも個人データが残り得ます。再委託先とクラウド事業者を含め、管理者・処理者の役割、侵害連絡経路、返却・削除の証拠を契約へ落とします。最終的な法的判断は専門家へ確認してください。

工場連携と本番配備を評価する

ERP・設備連携は失敗を前提に設計する

工場連携では、APIが常に成功する想定を置きません。タイムアウト、再試行、二重送信、順序逆転、マスタ不一致、ネットワーク分断を設計レビューの入力にします。各連携について、送信元、受信先、データ所有者、頻度、認証、タイムアウト、再試行回数、冪等キー、保留キュー、監視、手動復旧を記載します。

PLCや設備へ直接書き込む範囲は、業務システムの責任と制御安全の責任を分けます。開発会社、設備メーカー、工場IT、クラウド事業者のRACIを作り、「インターフェースまでは誰」「設備動作の検証は誰」を明確にします。

本番移行とロールバックをリハーサルする

移行計画には、データ抽出、変換、照合、差分同期、停止時間、Go/No-Go責任者、切戻し条件を含めます。本番当日に初めて実行する手順を残さず、匿名化または許可されたデータでリハーサルします。

ロールバックは旧版へ戻す操作だけではありません。新システムで更新されたデータをどう扱うか、連携先へ送った取引をどう照合するか、紙運用へ切り替えた分をどう戻すかまで決めます。監視ダッシュボードの画面ではなく、アラートを誰が受け、何分後に誰へ上げるかを確認します。

稼働後サポートをSLAと運用証拠で比べる

「24時間サポート」という表現だけでは足りません。対象言語、受付手段、一次応答と復旧目標の違い、重大度判定、休日、タイムゾーン、現地訪問条件、第三者へのエスカレーション、月次報告を定義します。一次応答が速くても、受付番号だけで技術者が動かない契約では工場リスクを下げません。

稼働後30〜90日の安定化期間には、問い合わせ、欠陥、操作教育、改善要求を分けて集計します。既知の問題、回避策、変更履歴、構成台帳、バックアップ試験結果を顧客と共同管理します。保守を別会社へ移せるかを毎年小さく確認することも、ベンダーロックイン対策になります。

選定プロセスを社内で再現可能にする

現場観察と経営判断を一つの評価へつなぐ

製造システムの選定では、経営者、工場長、現場監督者、作業者、品質、経理、ITで見えている問題が異なります。経営者は投資効果と継続性、現場は操作と例外、ITは連携と保守を重視します。全員の希望を機能一覧へ足すだけでは、要求が膨らむ一方です。各部門の発言を「どの業務リスクを減らすか」「どの判断を早くするか」「何を証拠に達成とするか」へ変換します。

現場観察では、標準手順だけでなく、手書きメモ、表計算への転記、端末の共用、締め後修正、夜勤時の承認、通信断時の仮置きといった迂回作業を確認します。ただし、現状の迂回作業をそのままデジタル化する必要はありません。法令、品質、顧客要求に必要な統制と、過去のシステム制約から生まれた作業を分けます。候補会社には、観察結果を標準機能、設定、個別開発、業務変更の四つに分類してもらいます。

経営判断では、削減時間だけでなく、計画遵守、仕掛滞留、追跡時間、再入力、誤出荷など、案件の目的に直接結び付く指標を一つか二つ選びます。現状値を測っていない指標に改善率を約束させてはいけません。まず測定定義、データ源、除外条件、集計頻度を合意し、thin sliceで測れるか確認します。

意思決定ログで「言った・言わない」を防ぐ

会議議事録は会話の記録ですが、意思決定ログは実装を制御する記録です。決定ID、決定内容、理由、検討した代替案、影響する要件とテスト、決定者、決定日、再検討条件を持たせます。たとえば「ERP停止時は新規入荷をローカル保留する」という決定には、保持できる件数、端末紛失時の扱い、復旧後の順序、二重送信防止、監視を関連付けます。

未決事項も同じ台帳で管理します。担当者と期限だけでなく、未決のまま進めた場合の仮定と影響を記録します。ベンダーが仮定を明示しないまま実装すると、後で「変更要求」として費用と日程に現れます。逆に、顧客側が判断を遅らせた影響も見えるため、双方に公平な統制になります。

設計レビューでは資料の枚数ではなく、重要な決定が要件、インターフェース、データモデル、テストへ反映されたかをサンプル追跡します。毎回すべてを確認する必要はありません。高リスクな要件を数件選び、要求からコード変更、テスト証拠、本番構成までたどれるかを確認する方が、形式的な進捗率より実態を捉えられます。

候補会社へのリファレンス確認を構造化する

リファレンス先へ「満足しましたか」と聞くと肯定的な回答に偏ります。今回の評価軸に合わせて、提案時のチームが継続したか、重大な仮定がいつ共有されたか、受入不合格をどう修正したか、稼働後の重大障害で誰が動いたか、引継ぎ資料で別担当が作業できたかを尋ねます。回答できない機密情報を無理に求めず、進め方と成果物の再現性を確認します。

類似性も分解します。同じ業界でも、単一工場と多拠点、クラウドと工場内サーバー、参照連携と設備制御、多品種少量と連続生産ではリスクが違います。「製造業実績あり」という一行ではなく、今回と同じ部分、異なる部分、差を埋める担当者と検証方法を記録します。

最終選定の承認資料を短く保つ

最終承認資料には、候補会社の会社紹介を並べるより、失格条件の結果、100点評価、thin sliceの合否、主要な残存リスク、契約で軽減する項目、顧客側の前提をまとめます。点数が高くても、唯一のキーパーソン、未検証の設備接続、データ品質、第三者ライセンスなどの残存リスクは別枠で示します。

推奨会社を選ぶ理由と同時に、採用しない条件も明記します。たとえば「指定日までに顧客管理リポジトリへ移管できない場合は契約しない」「thin sliceの復旧試験が不合格なら再試験まで本開発を開始しない」という条件です。これにより、価格交渉の中で重要な統制が消えることを防げます。

契約後の最初の30日で確認すること

提案時の約束を実行計画へ固定する

契約直後には、提案書の内容をプロジェクト計画、役割表、成果物一覧、品質計画へ移します。提案時の実名メンバーが参加しているか、稼働率と担当範囲が一致するか、変更があれば同等性を誰が承認したかを確認します。営業資料だけに残った約束は、実行チームに伝わらない可能性があります。

要件追跡表、課題、リスク、決定、変更、テスト、リリースを別々の表にする場合でも、共通IDでつながるようにします。保管場所、更新責任者、承認状態、閲覧権限を決め、メール添付を正本にしません。顧客側も決定者、現場確認者、受入責任者、インフラ担当を指名します。

開発環境と証拠採取を早期に整える

ソースリポジトリ、課題管理、CI/CD、依存関係管理、秘密情報保管、ログ、テスト証拠の置き場所を早期に確認します。本番直前に顧客環境へ移す計画では、権限、ネットワーク、ライセンス、ビルド差異が遅れて発覚します。最初の小さな変更から顧客が閲覧できる形にし、少なくともリリース候補を同じ手順で再現します。

証拠はスクリーンショットだけに限定しません。テスト入力、実行時刻、バージョン、環境、期待値、実測値、ログへの参照を組み合わせます。不具合修正後は、失敗証拠を消さず、修正コミットと再試験結果を関連付けます。これにより、品質の説明が口頭報告から監査可能な履歴へ変わります。

早い段階で復旧を一度実行する

バックアップが設定されていることと、復元できることは別です。thin sliceまたは初期反復の段階で、許可されたデータを使い、別環境への復元、アプリケーション起動、主要レコード照合まで実行します。所要時間を市場標準と比べるのではなく、自社の合意した復旧目標と比較します。

連携の復旧も同様です。キューに滞留したデータを可視化し、再送対象を選び、重複を防ぎ、処理結果を照合できるか確認します。手動SQLでしか直せない設計なら、実行者、承認、バックアップ、監査記録を運用手順へ入れ、改善バックログにも登録します。

タイ システム開発会社に関するFAQ

タイ システム開発会社とは、どの会社を指しますか？

タイ法人の開発会社、海外企業のタイ拠点、現地導入を行うITベンダーなどを広く含みます。所在地だけで選ばず、タイ工場で必要な現場対応、言語、個人データ、契約、保守時間帯と、実際に割り当てられるチームを確認してください。

タイのシステム開発費用はどう比較すべきですか？

市場相場だけでなく、同じ要件、成果物、顧客側作業、受入条件、保証範囲で比較します。初期見積、ライセンス、クラウド、連携、データ移行、教育、稼働支援、保守、変更要求、終了時移行を総費用として並べます。本記事では一次情報に基づかない価格帯を提示していません。

日系ITベンダーなら日本企業に向いていますか？

日本語での合意形成や本社報告に利点がある場合はありますが、法人属性だけでは判断できません。実行チーム、タイ現場との連携、要件追跡、試験証拠、保守体制を同じ評価表で確認します。

バンコクのシステム開発会社は何社に提案を依頼すべきですか？

固定の正解はありません。書類ゲートで実行不能な候補を落とし、比較に必要な競争性と、自社が質疑・評価できる工数のバランスを取ります。thin sliceは有償なので、書類で絞った少数社に限定するのが現実的です。

PoCとthin sliceの違いは何ですか？

PoCは技術の実現可能性だけを確認する場合があります。本記事のthin sliceは、ひとつの業務を要件、画面、連携、例外、セキュリティ、テスト証拠、配備、引継ぎまで端から端へ通します。技術デモではなく、本案件の実行チームと進め方を評価するものです。

ソースコードは必ず受け取るべきですか？

個別開発では、契約上の権利と継続アクセス、再ビルド可能な手順を重視します。SaaSでは通常ソースは提供されないため、データ出力、API、設定、終了時支援、事業継続策を確認します。製品と個別開発で同じ条件を機械的に適用しないことが大切です。

PDPA対応は開発会社に任せればよいですか？

任せきりにはできません。顧客側も目的、データ項目、保存期間、アクセス者、法的根拠などを決め、役割と指示を明確にする必要があります。開発会社には安全措置、記録、侵害連絡、再委託、返却・削除を確認し、法的判断は専門家へ相談してください。

まとめ：会社ではなく実行証拠を選ぶ

タイのシステム開発会社選定では、営業資料や単価から始めるのではなく、代表的な一業務の成功条件を定義し、要件追跡表、実名チーム、テスト証跡、セキュリティとPDPA、ソース・設定の引継ぎ、配備・復旧、サポートルールを同じ形式で比較します。書類ゲートで必須条件を確認し、100点評価で候補を絞り、有償thin sliceで提案内容を実証してから契約することで、曖昧さを早い段階で減らせます。

RFPの作成前、候補会社の比較表を設計している段階、またはthin sliceの受入条件を整理している段階でも、TOMAS TECHへご相談いただけます。タイ製造現場の業務、既存ERP・設備、運用体制を踏まえ、特定製品を前提にせず評価可能な要件へ整理します。

参照した一次情報

• Thailand BOI: H1 2026 investment applications
• Thailand BOI: application forms for digital technology activities
• Thailand MDES: Personal Data Protection Act B.E. 2562
• DGA: sample development procurement requirements
• DGA: 2025年署名・2026〜2028年度対象のTOR例
• NIST SP 800-218: Secure Software Development Framework v1.1
• CISA: Secure by Demand Guide
• OWASP Application Security Verification Standard 5.0