東南アジア システム開発：委託先モデル・契約・受入の実務ガイド

東南アジア システム開発を複数国で進めるとき、発注者が決めるべきなのは「どの国が安いか」ではありません。単一プライム、各国ベンダー、ハイブリッドのどれで責任を束ね、RFP・SLA・越境データ・セキュア開発・引継ぎ・受入証跡をどう一つの統制へ落とすかです。本稿は、タイ、ベトナム、シンガポールなどに事業拠点を持つ製造業・物流業の本社、地域統括、現地法人が、委託方式を比較し、提案依頼から契約、受入までを具体化するための実務ガイドです。

先に結論：ASEAN システム開発は「契約の本数」より責任境界で選ぶ

三つの方式に絶対的な正解はありません。単一プライム方式は責任窓口を一本化しやすい一方、各国の現場知識が二次委託に埋もれる可能性があります。各国ベンダー方式は現場適合を高めやすい一方、共通設計、障害切り分け、変更管理を発注者自身が束ねなければなりません。ハイブリッド方式は地域共通の中核をプライムに、各国固有部分を現地ベンダーに分けますが、境界設計が曖昧なら「どちらの範囲でもない穴」が生まれます。

選定では、候補会社の人数や開発単価より先に、次の七つを一枚にしてください。

1. 誰が地域共通アーキテクチャを決めるか。
2. 誰が各国の法令・商習慣・言語要件を確認するか。
3. 障害時に誰が一次切り分けを行い、復旧指揮を執るか。
4. 個人データ、製造データ、ソースコードがどの国を通るか。
5. セキュア開発の証拠を誰が作り、誰が確認するか。
6. ベンダー交代時に何を、どの形式で、いつ引き渡すか。
7. 受入判定を機能、性能、運用、セキュリティ、データ移行のどの証跡で行うか。

この七点が曖昧なまま見積を比べても、安い提案は「発注者が後で負担する作業」を除外しているだけかもしれません。見積比較では、同じ作業分解、同じ前提、同じ責任境界に正規化することが出発点です。

なぜ今、海外 システム開発 委託を地域単位で再設計するのか

ASEANではデジタル統合の制度整備が続いています。ASEANのSenior Economic Officialsは2026年6月、ASEAN Digital Economy Framework Agreement（DEFA）の交渉で未解決事項を解消し、交渉が成功裏に完了したと発表しました。ASEAN事務総長は2026年9月、DEFAが効果的に実施された場合、地域のデジタル経済が2030年までに最大2兆米ドルへ拡大する可能性に言及しています。これは確定予測ではなく「成功裡の実施」という条件付きの公式見通しです。

発注者にとって重要なのは巨大な市場推計そのものではなく、信頼できる越境データ流通、サイバーセキュリティ、相互運用性が地域事業の前提になっている点です。一国向けシステムを国ごとに複製すると、顧客、品目、設備、権限、監査ログの定義が分かれます。逆に、本社標準をそのまま全拠点へ押し込むと、現地の税務、個人データ、言語、通信、保守時間の違いに耐えません。

したがって今回の論点は、タイでの会社選びやベトナムでの開発拠点選びではありません。個別国の選定はタイのシステム開発会社を選ぶ実務ガイドとベトナム システム開発の発注ガイドを参照してください。本稿は、複数国を一つのポートフォリオとして扱う委託先モデルと、契約・受入統制に限定します。

3つの委託先モデルを比較する

単一プライム方式が向く場合

ERP周辺、MES、WMS、データ基盤などを地域共通化し、稼働日も連動させたい場合に向きます。契約上は、プライムが下請会社を使っても、成果物、品質、セキュリティ、納期、知財、再委託先管理についてプライムが一元責任を負う形を明確にします。「現地会社の作業なので対象外」という逃げ道を残さないことが重要です。

ただし、窓口一本化と実行能力一本化は同じではありません。提案書では各国の配置、常駐・リモートの比率、現地言語のサポート時間、データを扱う開発拠点、再委託先を開示させます。主要担当者の交代条件と承認権も必要です。

各国ベンダー方式が向く場合

国ごとに業務や法制度が大きく異なり、共通部分がAPI、データ辞書、ID管理などに限定できる場合に向きます。現地の意思決定が速く、運用担当との距離が近いことが利点です。一方、発注者側に地域アーキテクト、データ責任者、セキュリティ責任者、統合テスト責任者が必要です。

契約を国ごとに分けても、共通付属書は統一します。API規約、ログ形式、時刻、文字コード、脆弱性対応、成果物台帳、変更要求票、重大度定義、受入証跡の保存場所が国ごとに違うと、後の統合コストが膨らみます。

ハイブリッド方式が向く場合

地域共通の製品・マスタ・認証・データ基盤をプライムが担い、各国の帳票、税務連携、周辺設備、言語、現地サポートをローカルベンダーが担う方式です。実務では最も柔軟ですが、責任の継ぎ目が多いため、インターフェース管理文書と統合責任者が不可欠です。

境界ごとに「設計する者」「実装する者」「試験データを用意する者」「障害を切り分ける者」「最終承認する者」を分けます。単なるRACIだけでなく、入力物、出力物、期限、判定基準を記載した作業パッケージにします。

システム開発 RFPを比較可能な形にする

良いRFPは、ベンダーに自由作文を競わせる文書ではありません。発注者の未決事項を見える化し、同じ条件で解法とリスクを比較するためのデータセットです。少なくとも次の章を用意します。

要求を「検証可能な文」にする

「使いやすい」「高性能」「安全」といった形容詞は比較できません。たとえば「ピーク時に速い」は、対象取引、同時利用者、データ量、応答時間の測定点、パーセンタイル、ネットワーク条件を決めます。「監査ログを残す」は、対象イベント、利用者識別、時刻基準、改ざん保護、保持期間、検索・出力、閲覧権限を決めます。

まだ基準値を決められない項目は、無理に数字を作らず「提案段階で計測方法を提示し、設計ゲートで基準化する」とします。市場平均らしい数字を出典なしで置くより、決定プロセスを契約化する方が安全です。

前提・除外・依存関係を価格表と結ぶ

見積の末尾に小さく書かれた前提は、後の追加費用の入口です。前提IDを付け、価格項目、日程、責任者、成立確認日と結びます。たとえば「既存APIは利用可能」という前提なら、API仕様、試験環境、性能、認証、所有者をいつ確認するかを書きます。不成立時の変更手順も決めます。

見積は総額ではなく同一式へ正規化する

東南アジアのオフショア開発を比較するとき、単価だけを比べると誤ります。総比較額は、次のように同じ構成へ直します。

比較対象額 ＝ 初期設計・開発 ＋ 各国ローカライズ ＋ データ移行 ＋ 連携・環境 ＋ セキュリティ保証 ＋ 教育・展開 ＋ 保守運用 ＋ 発注者側統合工数 ＋ リスク調整 − 明示された再利用効果

ここでの発注者側統合工数が重要です。各国ベンダー方式で、地域PMO、アーキテクト、統合テスト、翻訳、会議調整に社内工数が必要なら、その人月を比較に入れます。単一プライムでも、変更要求が契約外になりやすいなら、変更単価と想定件数を感度分析します。

仮定例：金額ではなく構造を比較する

以下は市場相場ではなく、比較方法を示す架空の指数例です。三方式とも基本機能を100とし、各項目を同じ物差しで見積もったと仮定します。

この仮定では単一プライムが低く見えますが、ロックインや変更単価が高ければ逆転します。逆に各国ベンダー方式でも、発注者が既に強い地域PMOと共通基盤を持つなら統合工数は下がります。必要なのは「どの方式が常に安いか」ではなく、自社の能力とリスクを同じ式へ入れることです。

SLAはシステム稼働率だけでなく業務復旧で設計する

複数国ではタイムゾーン、祝日、現地の夜間作業、ネットワーク事情が異なります。SLAには少なくとも次を分けます。

• サービス受付時間と対応言語
• 重大度の定義と宣言権者
• 初動応答、回避策提示、復旧、恒久対策の各時刻
• システム可用性の測定点と除外条件
• バッチ、API、データ同期の遅延基準
• バックアップ、復元、災害復旧の試験頻度
• 脆弱性・インシデントの通知と是正期限
• 再発障害の問題管理と根本原因報告

「重大障害」を技術用語だけで決めず、出荷停止、製造実績未計上、法定帳票不能、個人データ誤開示など業務影響で定義します。一次復旧は現地、根本原因は地域チームという分担なら、引継ぎ時刻と必要ログも契約へ入れます。

サービスクレジットだけでは業務は戻りません。復旧訓練、連絡網、代替手順、判断権限を受入前に実演させます。月次SLA報告は平均値だけでなく、重大障害ごとのタイムライン、再発、バックログ、既知リスクを含めます。

越境データは「移転するか」ではなくデータ経路で管理する

ソースコードのリポジトリがシンガポール、開発者がベトナム、利用者がタイ、サポート担当が別国という構成では、本番DBを移していなくても、ログ、画面共有、チケット添付、バックアップ、分析データを通じて越境アクセスが発生し得ます。最初にデータフロー台帳を作ります。

ASEAN Data Management Frameworkは、データガバナンスとライフサイクル管理の共通的な考え方を提供します。ASEAN Model Contractual Clauses（MCCs）は越境データ流通に関する契約上の保護策を検討する材料になります。ASEAN MCCsとEU Standard Contractual Clausesを併せて扱う共同ガイドも公開されています。ただし、これらを貼り付ければ各国法への適合が自動的に保証されるわけではありません。対象国、データ、当事者、処理目的に応じ、現地の法務・プライバシー専門家へ確認してください。本稿は法務助言ではありません。

開発環境には本番個人データを原則持ち込まず、匿名化・合成データで試験します。障害再現で本番データが必要な例外は、承認、最小範囲、隔離環境、期限、アクセスログ、削除証明を必須にします。リモートサポートも、常時権限ではなく申請に基づく期限付き昇格と録画・監査を検討します。

セキュア開発を宣言ではなく証拠で受け入れる

NIST SP 800-218のSecure Software Development Framework（SSDF）は、特定の開発方式に限定されない高水準のセキュア開発実践を示し、ソフトウェア調達者と供給者の共通語としても利用できます。RFPでは「ISO認証あり」「セキュアに開発」だけで終えず、次の証跡を要求します。

1. 開発者、レビュー者、リリース承認者の分離。
2. リポジトリ、CI/CD、クラウド管理面への多要素認証と最小権限。
3. コードレビュー、静的解析、依存関係・秘密情報スキャンの結果。
4. OSSとライセンスの一覧、SBOMまたは同等の部品台帳。
5. 脆弱性の重大度、修正期限、例外承認、再検証。
6. ビルド成果物とソース、承認、配備先を結ぶ追跡性。
7. 開発・試験・本番の分離と本番データ利用の例外記録。
8. 退職・異動・契約終了時の権限剥奪記録。

CISAの中小企業向けベンダー・サプライヤー評価資料は、供給者のサイバーリスクを確認する入口として利用できます。発注者は質問票だけでなく、重大項目の証拠サンプルを提案時に確認し、契約後の監査権、是正計画、再委託先への同等義務を定めます。

また、組織の情報セキュリティ管理を扱うISO/IEC 27001:2022は、管理システムの枠組みを確認する参照先になります。ただし、組織認証の範囲と今回の開発拠点・サービスが一致するかを確認してください。認証書があることと、今回の成果物が安全であることは同義ではありません。

マルチベンダー 開発の統合統制

各国ベンダーまたはハイブリッド方式では、週次会議を増やすだけでは統合できません。共通の「統合コントロールブック」を作り、最新版を全社が参照できる場所に置きます。

最低限そろえる共通台帳

• 要求IDと受入テストIDの追跡表
• API、ファイル、イベント、マスタのインターフェース台帳
• 環境、URL、証明書、秘密情報の所有台帳（秘密そのものは記載しない）
• 意思決定ログと設計例外
• リスク、課題、依存関係、変更要求
• リリース構成、既知制約、ロールバック手順
• 脆弱性、OSS、ライセンス、是正状況
• 成果物、所有者、版、承認、保管場所

会議の議事録ではなく、決定の証跡を残します。たとえばAPIの項目を変更した場合、誰が承認し、どの国のどの機能、試験、移行データ、教育資料へ影響するかを結びます。国ごとの課題管理ツールが異なるなら、地域レベルで必要項目だけを同期します。

変更管理を価格・日程・受入へ接続する

変更要求には、発生理由、対象要求、設計影響、データ影響、セキュリティ影響、各国影響、費用、日程、試験、文書更新を記載します。小さな画面変更でも、共通コンポーネントや翻訳、権限へ波及することがあります。口頭合意で着手せず、緊急変更の事後承認期限も決めます。

90日でRFPから受入ゲートまで進める仮定例

以下はプロジェクト規模を問わず使える固定日程ではなく、検討を前進させるための仮定例です。大規模ERP刷新ではより長い期間が必要です。

90日でシステム全体を完成させるという意味ではありません。契約後に「誰も決めていなかった」と判明しやすい境界を先に検証し、本開発へ進む条件を整える期間です。特に、代表API、データ移行サンプル、権限モデル、障害復旧、成果物引継ぎを小さく実演すると、提案書だけでは見えない実行力を確認できます。

契約で押さえる10の論点

契約本文、SOW、SLA、データ処理付属書、セキュリティ付属書のどこに記載するかは法務と整理しますが、実務上は次を欠かさないようにします。

1. 成果物と完成条件：文書名だけでなく、内容、形式、更新頻度、承認者を定義。
2. 知的財産と利用権：新規コード、既存資産、OSS、設定、テンプレートを区別。
3. 再委託：事前承認、所在地、業務、データアクセス、同等義務、変更通知。
4. データ：目的制限、所在地、越境、事故通知、返還・削除、監査。
5. セキュリティ：開発統制、アクセス、脆弱性、インシデント、証跡。
6. 品質と受入：テスト責任、欠陥重大度、再試験、条件付き受入、みなし受入。
7. 変更：見積方法、承認権、緊急変更、基線更新、累積影響。
8. 保証と保守：欠陥修正、サービス時間、SLA、バージョン・依存関係更新。
9. 終了支援：終了理由を問わない引継ぎ、期間、単価、協力義務。
10. 監査と証拠保持：閲覧範囲、頻度、保存期間、第三者報告の利用。

現地法、税務、雇用、個人データ、輸出管理、紛争解決は国や契約関係で異なります。必ず適格な専門家へ確認してください。

引継ぎを最終月の作業にしない

ベンダー交代が決まってから文書を集めると、最新版がなく、環境構築者も退職し、秘密情報の所在も分からない状態になります。引継ぎは月次成果物として積み上げます。

契約終了時には、リポジトリ、クラウド、ドメイン、証明書、監視、チケット、設計資産の管理権を発注者または後継者へ移します。秘密情報は安全な経路で再発行し、旧ベンダーのアクセスを失効させます。データ削除証明だけでなく、バックアップの保持期限と失効方法も確認します。

受入は「動いた」ではなく追跡可能な証跡で決める

受入判定は、要求IDからテスト、結果、欠陥、再試験、承認へ追跡できることが基本です。画面のスクリーンショットだけでなく、ログ、API結果、データ照合、性能計測、復旧記録、アクセス記録を残します。

五つの受入レーン

1. 機能：通常、例外、取消、権限、各言語、各国差分。
2. 統合・データ：API、再送、重複、順序、移行照合、時刻、文字。
3. 非機能：性能、容量、可用性、監視、バックアップ、復旧。
4. セキュリティ：権限、ログ、脆弱性、秘密情報、開発証跡。
5. 運用・引継ぎ：手順、教育、サポート、エスカレーション、再現ビルド。

欠陥ゼロだけを条件にすると、軽微な表示崩れが受入を止める一方、運用不能な文書不足が見逃されます。重大度は業務影響で定義し、条件付き受入では、残件、期限、回避策、責任者、支払留保、再試験を明示します。「一定期間返答がなければみなし受入」とする場合も、必要証跡が提出されていないと時計が始まらない条件を検討します。

発注者が準備する運営体制

ベンダーの能力だけでプロジェクトは成功しません。地域経営責任者、業務責任者、地域IT、各国IT、データ、セキュリティ、法務・調達が、どのゲートで何を決めるかを定義します。

経営会議は個別欠陥を議論せず、スコープ、効果、重大リスク、依存関係、予算、展開判断を扱います。設計会議は例外と標準を判断します。運用会議は障害、SLA、容量、技術負債を扱います。同じ資料を全会議で使い回さず、意思決定に必要な粒度を分けます。

各国からは「代表者一人」だけでなく、実際の承認者と利用者を参加させます。本社の英語会議で合意しても、現地作業者の入力方法、帳票、シフト、保守連絡が検証されなければ稼働後に戻ります。重要な操作と教育資料は現地語で受入します。

よくある失敗と予防策

国ごとに同じ質問票を配り、回答を並べる

回答粒度が異なり比較不能になります。回答テンプレート、価格分解、証拠欄、前提IDを統一してください。

プライムに任せれば統合されると考える

プライムの統合責任をSOWと受入へ落とし、再委託先の作業も含めた成果物と障害指揮を明記します。

越境データを本番DBだけで判断する

ログ、チケット、画面共有、バックアップ、開発データ、監視サービスまでデータ経路を描きます。

セキュリティ質問票の「はい」で終える

権限記録、レビュー例、スキャン結果、リリース承認など、機密を過度に開示しない範囲で証拠サンプルを確認します。

稼働直前に引継ぎ文書を要求する

文書を月次成果物にし、別担当者による再現テストを受入ゲートへ入れます。

各国の稼働日だけを分け、共通部を同時変更する

共通APIやマスタの版を管理し、旧版との共存期間、互換性、ロールバック条件を決めます。海外拠点システム導入の展開ガバナンスも併せて参照してください。

FAQ

東南アジア システム開発の費用は？

一律の市場相場で判断するのは危険です。対象国数、業務範囲、既存連携、データ品質、現地語、セキュリティ保証、移行、夜間対応、引継ぎ条件が費用を左右します。「初期開発＋各国差分＋移行・連携＋セキュリティ・受入＋教育・保守＋発注者側統合工数」の同一式へ正規化し、前提と除外を並べて比較してください。本文の費用指数は方法を説明する仮定例であり、市場価格ではありません。

単一プライムと各国ベンダーはどちらがよい？

共通化と一元責任を優先し、発注者の地域PMOが小さいなら単一プライムが候補です。国ごとの差が大きく、発注者に強いアーキテクトと統合力があるなら各国ベンダーも有効です。共通基盤と各国固有部分を明確に分けられるならハイブリッドが適します。会社数ではなく、設計、障害、データ、受入の責任境界で決めます。

越境データはどう扱う？

データ集合ごとに発生国、保存国、閲覧国、目的、当事者、再委託先、保護策、削除を記録します。本番DBだけでなく、ログ、チケット、バックアップ、リモート保守も対象です。ASEANのDMFやMCCsは検討材料になりますが、各国法への適合は個別に確認が必要です。現地の専門家へ相談してください。

受入条件は？

機能だけでなく、統合・データ、性能・復旧、セキュリティ、運用・引継ぎの五つに分け、要求IDとテスト証跡を結びます。欠陥重大度、再試験、条件付き受入、未提出証跡、支払条件も事前に定義します。

システム開発 RFPでは何を共通化すべき？

回答様式、価格内訳、前提ID、成果物、非機能、データ経路、セキュリティ証跡、SLA、受入、引継ぎを共通化します。国固有要件は別紙にし、地域共通部分との差分が見える構成にします。

ベンダーが再委託する場合の確認点は？

会社名と所在地だけでなく、業務範囲、データ・環境へのアクセス、主要要員、セキュリティ義務、事故通知、監査、変更時の事前承認、契約終了時の削除・返還を確認します。プライムの一元責任を曖昧にしないでください。

まとめ

東南アジアの複数国にまたがるシステム開発では、国別単価の比較より、責任をどこで束ねるかが成否を分けます。単一プライム、各国ベンダー、ハイブリッドを、共通設計、現地適合、障害責任、越境データ、発注者PMO、引継ぎの同じ軸で比較してください。RFPは検証可能な要求と共通価格式を用意し、SLAは業務復旧まで定義します。受入では機能、データ、非機能、セキュリティ、運用の証跡をつなぎ、引継ぎを毎月積み上げます。

TOMAS TECHでは、委託先を決める前のRFP整理、複数国の責任境界、受入証跡の設計段階からご相談いただけます。タイを含む東南アジア展開で、単一プライム・各国ベンダー・ハイブリッドのどれが自社に合うかを整理したい場合は、お問い合わせください。

参考情報

1. ASEAN, “Secretary-General of ASEAN delivers Keynote Address at the 2026 DEFA Foresight and Strategic Cooperation Pre-Summit Forum” — https://asean.org/secretary-general-of-asean-delivers-keynote-address-at-the-2026-defa-foresight-and-strategic-cooperation-pre-summit-forum/
2. ASEAN, “Statement of the Chairperson of the ASEAN Senior Economic Officials (SEOM) on the Conclusion of ASEAN DEFA Negotiations” — https://asean.org/statement-of-the-chairperson-of-the-asean-senior-economic-officials-seom-on-the-conclusion-of-asean-defa-negotiations/
3. ASEAN Digital Sector, Key Documents — https://asean.org/our-communities/economic-community/asean-digital-sector/key-documents/
4. ASEAN, “Joint Guide to ASEAN Model Contractual Clauses and EU Standard Contractual Clauses” — https://asean.org/book/joint-guide-to-asean-model-contractual-clauses-and-eu-standard-contractual-clauses/
5. Singapore Personal Data Protection Commission, “ASEAN Data Management Framework and Model Contractual Clauses on Cross Border Data Flows” — https://www.pdpc.gov.sg/help-and-resources/2021/01/asean-data-management-framework-and-model-contractual-clauses-on-cross-border-data-flows
6. ASEAN, “ASEAN Cybersecurity Cooperation Strategy 2026–2030” — https://asean.org/book/asean-cybersecurity-cooperation-strategy-2026-2030/
7. Thailand Board of Investment, “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/
8. NIST, “SP 800-218: Secure Software Development Framework (SSDF) Version 1.1” — https://csrc.nist.gov/pubs/sp/800/218/final
9. CISA, “Assisting Small and Medium-sized Businesses to Assess Vendors and Suppliers” — https://www.cisa.gov/resources-tools/resources/assisting-small-and-medium-sized-businesses-assess-vendors-and-suppliers-fact-sheet
10. ISO, “ISO/IEC 27001:2022 Information security management systems” — https://www.iso.org/standard/27001
11. Viet Nam Ministry of Science and Technology, “Decree No. 13/2023/ND-CP on Personal Data Protection” — https://mst.gov.vn/van-ban-phap-luat/24993.htm

※本稿はシステム開発の発注・統制に関する一般情報であり、法務、税務、個人データ保護その他の専門的助言ではありません。適用法令や契約条項は、対象国の適格な専門家に確認してください。