システム開発 委託｜タイ製造業のRFP・契約・受入ガイド
システム開発 委託をタイの製造業で成功させるには、プログラムを書く会社を探す前に、発注者が業務、データ、責任、受入条件を言葉にする必要があります。本稿では、生産管理、在庫、品質、保全などの業務システムを対象に、RFP、契約、開発、受入テスト、保守までを一つの発注プロセスとして具体化します。市場平均を装った価格や失敗率は使わず、見積を比較できる構造と、各ゲートで残すべき証拠を示します。
システム開発の委託は「作業の外注」ではなく責任分界の設計
業務システム 開発の委託では、ベンダーに仕様書を渡した瞬間に発注者の仕事が終わるわけではありません。現場が何を良品、正しい在庫、完了実績とみなすかは、工場の管理ルールそのものです。品番変更、代替材料、再加工、分納、緊急割込み、棚卸差異、設備停止、ネットワーク断などの判断を、外部ベンダーだけで正しく決めることはできません。
発注者が残すべき責任は、業務オーナーの指名、優先順位、マスタデータの定義、例外時の決裁、法務・セキュリティ判断、受入判定です。ベンダーへ委ねやすいのは、技術方式の提案、設計、実装、テスト自動化、移行ツール、運用監視の構築です。境界を曖昧にすると、発注者は「当然入っている」と考え、ベンダーは「要件外」と考える空白が増えます。
委託対象を決めるときは、機能一覧より先に四つの軸で整理します。第一は競争力への直結度、第二は現場固有知識の深さ、第三は必要技術の希少性、第四は稼働後の変更頻度です。競争力と現場知識が高い領域は、実装を委託してもプロダクトオーナーを社内に残します。専門技術が希少で変更頻度が低い領域は成果物型で委託しやすく、変更頻度が高い領域は共同チームや段階契約が合います。
| 判断軸 | 発注者に残すもの | 委託しやすいもの | 危険な状態 |
|---|---|---|---|
| 競争力 | 業務原則、優先順位、KPI | 実装案、画面・API設計 | 重要ルールまでベンダー任せ |
| 現場知識 | 例外、権限、品質判断 | モデル化、ワークフロー実装 | 正常系だけで要件確定 |
| 技術希少性 | リスク許容度、採用基準 | クラウド、連携、セキュリティ実装 | 技術名だけで選定 |
| 継続運用 | 変更承認、データ責任、予算 | 監視、障害一次対応、改善開発 | 保守を納品後に初めて協議 |
タイBOIは2026年上期の投資奨励申請を1,299件、1.47兆バーツ、前年比37%増と発表し、デジタル分野は約1.12兆バーツでした。これは申請ベースであり、個別の工場システム需要や投資実行、奨励認定を保証する数字ではありません。ただし、タイでデジタル基盤への投資が大きく動く中、発注側が供給者、データ、運用継続性を自社の経営課題として扱う必要性は高まっています。
委託前に業務システム開発の前提を1枚にする
最初の成果物は詳細仕様書ではなく、プロジェクトチャーターです。なぜ今行うのか、対象拠点と工程、改善したい指標、変えてよい業務、変えない制約、意思決定者、予算枠、希望時期、段階導入の考え方を一枚にまとめます。「紙をなくす」「見える化する」では評価できないため、在庫差異の原因追跡、指図から実績までの遅延把握、品質保留品の誤出荷防止など、意思決定またはリスクの変化で表します。
次に、現行業務を正常系と例外系に分けます。受注、計画、指図、払い出し、実績、検査、入庫という主流だけでなく、欠品、代替、追加工、再検、廃棄、ロット分割・統合、ラベル再発行、過去日訂正も記録します。各ステップで入力、出力、責任者、承認者、利用システム、締め時刻、証跡を置けば、画面数より先にシステム境界が見えます。
データ棚卸しでは、品目、BOM、工程、設備、作業者、顧客、仕入先、倉庫、ロケーション、理由コードのオーナーを決めます。ERPに同じ品番があっても、現場の呼称、桁数、単位、改訂、無効化ルールが一致しないことがあります。移行対象件数より、重複、欠損、履歴、基準日、照合方法、修正責任を先に合意します。
また、生産管理システム導入の期間と進め方を参照し、設計、データ整備、連携、教育、並行稼働を同じ計画に入れてください。アプリの完成日だけを稼働日とみなすと、現場準備がクリティカルパスになります。
発注準備で最低限そろえる12項目
- 経営目的と、改善を判断する指標。
- 対象工場、部署、工程、ユーザー区分。
- 現行業務の正常系と主要な例外。
- システム境界と、ERP・設備・帳票との連携。
- マスタとトランザクションのデータオーナー。
- 必要な言語、時刻、単位、税・会計上の制約。
- 可用性、性能、バックアップ、監査証跡。
- 利用端末、工場ネットワーク、オフライン要件。
- 個人情報、機密情報、越境データの扱い。
- 社内の意思決定者、業務担当、IT、調達、法務の役割。
- 受入責任者と、本番判定のゲート。
- 保守時間、重大度、変更要求、終了支援の原則。
システム開発 RFPは画面一覧ではなく「証拠の要求書」にする
システム開発 RFPの目的は、ベンダーに同じ条件で考えてもらい、提案の差を比較可能にすることです。詳細設計を先回りして固定するのではなく、達成したい業務結果、制約、代表シナリオ、役割、受入方法を示します。「在庫管理画面」「進捗ダッシュボード」だけでは、各社が異なる前提で金額を出すため、安い提案ほど後から追加費用が出るとは限らないものの、比較そのものが成立しません。
RFPには、プロジェクト背景、スコープ、業務フロー、データ、連携、非機能、セキュリティ、移行、教育、受入、保守、提案フォーマットを含めます。要求ごとにIDを付け、Must、Should、Optionを区別します。ベンダーには標準対応、設定対応、追加開発、第三者製品、対象外のいずれかを回答させ、前提と証拠も記載してもらいます。
たとえば「在庫をリアルタイムに見える化する」ではなく、「払い出し登録後、同一ネットワーク条件で所定時間内に品目・ロット・ロケーション別残高へ反映し、二重送信時は重複計上せず、通信断時は端末に未送信状態を示し、復旧後に順序を保って同期する」と書きます。数値は工場の実測と業務必要性から決めます。根拠のない高性能要求は費用を上げ、低すぎる要求は運用リスクを残します。
| RFP章 | 発注者が提示する内容 | ベンダーに回答させる内容 |
|---|---|---|
| 目的・KPI | 現状、目標、測定方法 | 達成への設計仮説、制約 |
| 業務・例外 | シナリオ、権限、承認 | 標準/設定/追加開発の区分 |
| データ・連携 | 所有者、品質、接続先 | マッピング、再送、照合、監視 |
| 非機能 | 性能、可用性、復旧、監査 | 構成、測定方法、前提条件 |
| セキュリティ | データ分類、要求ID | 実装、検証証拠、未対応事項 |
| 移行・教育 | 対象、基準日、利用者 | リハーサル、教材、言語、役割 |
| 受入・保守 | シナリオ、重大度、期間 | テスト支援、SLA、体制、費用 |
ベンダー説明会では回答を全候補へ同条件で戻す
質疑は候補ごとに個別回答せず、機密情報を除いて質問と回答を全社へ共有します。現場見学では写真撮影、設備接続、サンプルデータ持ち出しのルールを先に決めます。RFP変更は版と変更理由を記録し、見積提出日も必要に応じて調整します。これにより、候補間の情報格差と「口頭で聞いた条件」を減らせます。
提案評価では、機能適合だけでなく、要求の理解、未確定事項の扱い、プロジェクト体制、下請構造、設計品質、テスト、移行、運用、終了時の引渡しを採点します。価格点を大きくしすぎると、除外の多い見積が有利になります。逆に技術点を抽象的にすると、説明が上手い会社が有利です。評価基準はRFP発行前に決め、証拠に基づく採点にします。
ICTベンダーのデューデリジェンスを契約前に行う
NIST SP 1326は2026年7月8日公開のICT supplier due diligence quick-start guideで、評価構成要素をForeign Ownership, Control, or Influence、Provenance、Resilience、Foundational Cyber Practices、Supply Chain Tiersに整理しています。タイ民間企業への法的義務ではありませんが、会社概要と認証書だけでは見えない供給網リスクを質問へ変換する枠組みとして使えます。
発注者は、契約主体、開発拠点、再委託先、主要クラウド、OSS・商用部品、ソース管理、バックアップ、要員交代、災害・事業撤退時の継続策を確認します。特定国籍や企業属性を機械的に排除するのではなく、誰が何へアクセスし、どの依存が止まると復旧できないかをデータフローと構成で評価します。
CISAのSecure by Demand Guideは、調達前、調達中、調達後に製品セキュリティを扱い、ベンダー企業の社内セキュリティと、納入する製品のセキュリティを区別します。ISO認証があっても、対象システムの安全な初期設定、ログ、脆弱性修正、更新通知、サポート期限が自動的に保証されるわけではありません。逆に小規模ベンダーでも、開発・配備・脆弱性管理の証拠が明確なら評価できます。
| 確認領域 | 質問例 | 求める証拠例 |
|---|---|---|
| 契約・所有 | 契約主体と開発主体は誰か | 登記、組織図、責任者、拠点一覧 |
| 来歴 | コードと部品はどこから来るか | リポジトリ方針、SBOM方針、依存一覧 |
| 再委託 | 誰がデータ・本番へ触るか | 再委託先、アクセス承認、契約フロー |
| 復旧力 | 要員離脱・障害時にどう継続するか | バックアップ、復旧試験、引継ぎ計画 |
| 基本対策 | 開発環境と製品をどう守るか | MFA、権限、レビュー、秘密情報管理 |
| 脆弱性 | 発見、通知、修正をどう行うか | 窓口、SLA、アドバイザリ、更新手順 |
システム開発 契約は本文と実務別紙を分ける
システム開発 契約では、法務条項だけでなく、日々の判断を動かす別紙が重要です。基本契約・個別契約に加え、SOW、要求一覧、責任分担、マイルストーン、検収、価格、変更管理、セキュリティ、データ処理、SLA、終了支援を版管理します。記事は法律相談ではないため、準拠法、裁判管轄、税務、PDPA、越境移転、電子署名の有効性はタイの専門家に確認してください。
契約方式は名称ではなく、不確実性と支払対象で選びます。要件と受入条件を高い確度で定義できる範囲は、成果物と価格を結びやすい固定価格が候補です。探索が必要な業務分析やアジャイル開発は、人・期間・優先順位を管理する準委任型が合う場合があります。実務上は、調査・プロトタイプを期間契約、本番範囲をゲート後の固定価格、運用改善を月次チームとする段階構成も可能です。
固定価格でも変更がゼロになるわけではありません。変更要求には、要求ID、理由、代替案、費用、納期、既存機能への影響、テスト範囲、承認者を記録します。口頭依頼やチャットの「軽微な修正」を積み上げると、どちらも原価と納期を説明できません。小変更用の定額枠を設ける場合も、未使用分、超過、優先順位、繰越のルールを決めます。
知財・ソースコード・データを別々に定義する
「成果物は発注者に帰属」だけでは不十分です。既存ライブラリ、汎用部品、新規個別コード、設定、設計書、テスト、データモデル、学習済みモデル、OSS、商用ライセンスを分けます。所有権を求めるのか、改変・再委託・海外拠点展開を含む利用権で足りるのかを決めます。ソースを受け取ってもビルド手順、依存、秘密情報、環境構成、運用知識がなければ保守できません。
データは、業務データ、ログ、バックアップ、統計、サポート時に複製されるデータまで対象にします。保存場所、アクセス者、暗号化、保持期間、削除、返却、事故通知を定めます。検証用に本番データを複製する場合、マスキングとアクセス期限も必要です。
ETDAはElectronic Transactions Actと電子契約に関するガイダンスを公開しています。一定の要件を満たす電子データや電子署名に法的効果を認める原則がありますが、「電子署名サービスを使えばすべて有効」とは限りません。権限者、同意、本人確認、文書の完全性、時刻、版、閲覧可能性、保管、証拠の取り出し方を設計し、取引種類と他の適用法を専門家に確認します。
OWASP ASVS 5.0を調達要件へ落とす
OWASP ASVS 5.0.0は、Webアプリケーションの技術的セキュリティ検証要求を整理し、調達時に契約の検証要求を定める基礎として使えると説明しています。ただし「ASVS準拠」と一行書くだけでは、対象、厳格度、除外、試験方法が不明です。対象システムのリスクに応じて要求を選び、v5.0.0-1.2.5のように版を含む要求IDで参照し、誰が何をどう証明するかを別紙にします。
たとえば認証、セッション、アクセス制御、入力検証、暗号、ログ、ファイル、API、設定を扱います。工場端末では共有利用、手袋操作、夜勤、ネットワーク断があるため、一般オフィスと同じ自動ログアウト時間が安全・生産性に合うとは限りません。リスクを下げながら運用可能な方式を、役割、端末、エリア、再認証条件で設計します。
CISA Software Acquisition Guideは、software development practices、supply chains、deployment、vulnerability managementというライフサイクルの対話を支援します。米政府向けガイドですが、発注者が開発完了時の診断だけでなく、依存部品、配備構成、運用後の脆弱性通知・修正まで契約に含める考え方は民間の工場システムにも応用できます。
| セキュリティ要求 | 契約へ書く内容 | 受入・運用で残す証拠 |
|---|---|---|
| ID・権限 | ロール、特権、MFA、退職処理 | 権限表、テスト、定期レビュー |
| 安全な開発 | レビュー、依存管理、秘密情報 | レビュー記録、スキャン結果、例外 |
| 検証 | ASVS版・要求ID・対象 | テスト結果、未解決、再試験 |
| 配備 | 初期設定、鍵、ネットワーク | 構成台帳、承認、復旧手順 |
| ログ | 事象、時刻、保護、保持 | サンプルログ、検索、時刻同期 |
| 脆弱性 | 通知窓口、重大度、修正期限 | 通知、パッチ、回帰試験、残余リスク |
| 終了 | サポート期限、移行、削除 | 引渡し一式、削除証明、アクセス停止 |
見積は総額でなく前提・除外・単価構造を比較する
システム開発委託の費用に、信頼できる一律相場はありません。対象工程、既存システム、データ品質、連携、稼働時間、拠点数、言語、セキュリティ、移行、教育、保守で構造が変わります。一次情報で裏付けられない平均価格を基準にすると、必要作業を除外した見積を安いと誤認しかねません。
候補各社には、同じWork Breakdown Structureで金額、工数、前提、除外、単価、支払条件を回答してもらいます。ライセンスと開発、初期と継続、必須とオプション、発注者負担とベンダー負担を分けます。複数通貨なら基準日と税の扱いをそろえます。工場訪問、休日作業、通訳、出張、端末、プリンタ、クラウド、回線、第三者APIも抜けやすい項目です。
| 比較項目 | 確認する変数 | 除外されやすい内容 |
|---|---|---|
| 要件・設計 | ワークショップ回数、成果物、承認 | 追加部門、追加言語、現場再調査 |
| 開発・設定 | 機能、ロール、帳票、ワークフロー | 例外処理、管理画面、監査機能 |
| 連携 | API数、方式、頻度、再送 | 接続先改修、VPN、証明書、監視 |
| データ移行 | 対象、履歴、クレンジング、回数 | 元データ修正、追加リハーサル |
| テスト | 単体、結合、性能、セキュリティ | テストデータ、再試験、第三者診断 |
| 教育・展開 | 言語、教材、train-the-trainer | 夜勤、追加拠点、新入社員教育 |
| 基盤 | クラウド、DB、監視、バックアップ | 通信、端末、保持量増加、DR試験 |
| 保守 | 時間帯、重大度、含有工数 | 機能改善、現地対応、第三者費用 |
| 変更・終了 | 役割別単価、引渡し、移行支援 | ソース整理、データ抽出、知識移転 |
WMSを含む場合は、タイ工場WMSの費用構造も参照し、ライセンス、端末、ラベル、ネットワーク、連携、棚卸、展開を分離してください。生産スケジューラを比較する場合は、タイ製造業向け生産スケジューラ比較のように、アルゴリズム名より制約モデル、再計画、説明可能性、ERP連携、運用者の調整権限を評価します。
TCOは少なくとも契約期間と終了時まで見る
初期費用だけでなく、サブスクリプション、クラウド、監視、バックアップ、セキュリティ更新、問い合わせ、軽微改善、OS・DB更新、データ増加、拠点追加、再教育、終了時のデータ出力を並べます。将来額を断定する必要はありません。数量単価、増加条件、価格改定方法を契約で可視化し、複数シナリオで比較します。
開発は成果物と意思決定のゲートで管理する
キックオフ後は、進捗率より未決事項と検証済み範囲を見ます。「開発80%」は、簡単な画面が終わり、難しい連携と移行が残っていても成立する表現です。業務フロー承認、アーキテクチャ、プロトタイプ、連携実証、移行リハーサル、UAT準備、本番判定というゲートを置き、通過条件を成果物と証拠で定義します。
各スプリントや週次会議では、完成した要求ID、デモ条件、未解決リスク、変更要求、発注者の宿題、次の意思決定を確認します。デモは作られた画面を見る場ではなく、代表シナリオを使って認識差を早期発見する場です。議事録には「誰が、何を、いつまでに」と、決定した前提の版を残します。
データ移行は終盤作業にしません。早期にサンプルを抽出し、文字コード、タイ語・日本語、日付、単位、重複、無効品、履歴量、参照整合を確認します。少なくとも複数回のリハーサルを計画し、抽出開始、業務停止、変換、投入、照合、差異処理、承認、ロールバックを時系列で実行します。回数はデータ品質とリスクに応じて決めます。
システム開発 受入テストはRFPから逆算する
システム開発 受入テストは、開発会社が自分で行う結合テストの再実施ではありません。発注者が、合意した業務を許容可能なリスクで運用できるかを判定する活動です。RFPの要求ID、契約の検収、業務シナリオ、データ移行、非機能、運用手順を一つのトレーサビリティ表で結びます。
テストは五層に分けると漏れを見つけやすくなります。第一は機能要求、第二は端から端までの業務シナリオ、第三は性能・可用性・セキュリティ、第四はデータ移行と照合、第五はバックアップ、監視、問い合わせ、権限変更を含む運用受入です。全項目を同じ重要度にせず、重大な業務停止、品質、出荷、会計、セキュリティへつながる条件を優先します。
工場のUATでは、正常品が一件流れるだけでは不足です。設備停止中の実績、通信断の再送、同じバーコードの二重読取、ラベル再発行、ロット分割、工程戻し、検査保留、再加工、棚卸差異、夜勤権限、日跨ぎ、月締め、マスタ改訂を含めます。実際の役割を持つ利用者が、実運用に近い端末、言語、ネットワーク条件で実施します。
| 受入層 | 代表的な確認 | 合否証拠 |
|---|---|---|
| 機能 | 要求IDごとの入力・処理・出力 | 期待値、結果、画面・ログ |
| 業務 | 受注から生産・検査・在庫まで | 役割別記録、伝票、残高照合 |
| 非機能 | 負荷、障害、権限、監査 | 測定条件、結果、未解決リスク |
| 移行 | 件数、金額、在庫、履歴、参照 | 差異一覧、修正、責任者承認 |
| 運用 | 監視、復元、問合せ、変更 | 手順実演、チケット、復旧記録 |
不具合の重大度と本番可否を先に決める
重大度は、技術者の修正難度ではなく業務影響で定義します。出荷停止、誤った品質判定、データ消失、権限逸脱などは重大です。代替手順があり影響が限定される表示崩れは低い場合があります。本番開始時に残せる不具合の数だけでなく、種類、回避策、修正期限、責任者、再試験を決めます。
すべてのテスト完了を待つだけでなく、開始前にGo/No-Go会議の入力を定義します。未解決不具合、移行照合、教育完了、サポート体制、バックアップ、ロールバック可能時間、旧システム停止、経営承認を確認します。本番判定はベンダーの納期都合ではなく、発注者の業務リスク判断です。
本番稼働後30・60・90日で保守へ移行する
稼働直後は、プロジェクト体制から通常保守へ一気に落とさず、安定化期間を設けます。最初の30日は、重大障害、データ差異、現場問い合わせ、手作業への退避を日次で確認します。60日までに原因別の傾向、教育不足、マスタ運用、性能、夜勤対応を整理します。90日では、未完了改善、SLA実績、変更バックログ、費用、運用責任を評価して通常体制へ移します。日数は例示であり、工場のリスクと締め周期に合わせて調整します。
保守SLAでは、「最優先」の言葉だけでなく、対象時間帯、受付、一次応答、回避策、復旧目標、除外、エスカレーション、報告を定義します。24時間操業でも、すべての障害に現地即応が必要とは限りません。一方、夜勤に止まると翌朝まで誰も判断できないシステムは、実運用要件を満たしません。障害分類と業務継続手順を対応させます。
KPIはチケット件数だけでなく、再発率、平均応答、復旧、未解決の滞留、データ差異、手動介入、ユーザー別エラー、変更リードタイムを見ます。問い合わせが減った理由が習熟なのか、諦めてExcelへ戻ったのかも現場観察で確認します。利用率を上げること自体を目的にせず、元の業務KPIと統制が改善したかを評価します。
ベンダーロックインを「避ける」でなく管理する
固有技術をすべて排除すると、価値あるサービスまで使えません。重要なのは依存を見える化し、退出可能性を契約と技術で確保することです。データ出力形式、API、ソース・設定、ビルド、環境構成、ライセンス、管理者権限、ドキュメント、引継ぎ時間、削除証明を定めます。契約終了時だけでなく、年次でバックアップと復旧、担当者以外による手順実行を確認します。
よくある失敗と発注者側の予防策
要件を全部決めてからベンダーを呼ぼうとする
業務目的と制約は発注者が決めますが、技術方式まで完全に決める必要はありません。早期情報提供依頼や有償ディスカバリーで選択肢を知り、その結果を公平なRFPへ反映します。ただし、特定候補だけが知る条件を本入札で放置しないよう情報をそろえます。
最安見積を選び、除外を後で知る
金額の大小より、含まれるシナリオ、役割、データ、連携、テスト、保守を横並びにします。空欄をゼロ円と解釈せず、未回答として確認します。発注者側の作業も工数と責任者を見積もります。
現場代表が一人だけで要件を決める
熟練者一人の説明は重要ですが、全シフトと例外を代表しません。製造、計画、品質、倉庫、保全、IT、管理の役割別に確認し、判断が違う部分をルールとして決裁します。合意形成をベンダー会議の中だけで行わないことも大切です。
UATを本番直前の操作説明会にする
教育と受入は目的が異なります。先に利用者を教育し、受入では要求とリスクを検証します。合格条件、テストデータ、不具合処理、再試験、署名を用意し、ベンダーのデモ操作だけで合格にしません。
保守契約を開発完了後に交渉する
本番時間帯、脆弱性対応、クラウド費、軽微変更、現地訪問、終了支援は選定時に比較します。後から交渉すると選択肢が狭くなります。開発提案と保守提案を分けて見せてもらい、総保有負担を確認します。
FAQ
システム開発の委託先はタイ企業と日系企業のどちらがよいですか？
国籍だけでは決められません。対象業務の実績、タイでの現場対応、日本語・タイ語・英語の運用、開発主体、再委託、セキュリティ、継続性、終了支援を同じ基準で評価します。契約窓口と実際の開発・保守拠点が異なる場合は責任分界を確認します。
業務システム開発のRFPはどこまで詳しく書くべきですか？
業務目的、範囲、例外、データ、連携、非機能、受入条件は具体化し、技術方式には提案余地を残します。確定事項と仮説、MustとOptionを分けると、ベンダーは不確実性を価格と計画へ反映できます。
システム開発契約は固定価格と準委任のどちらがよいですか？
要件の確度と支払対象で選びます。固定価格は範囲と受入が明確な部分、準委任型は探索と優先順位変更が多い部分に向く場合があります。調査、実証、本番、運用を異なる方式に分ける段階契約も検討できます。法的な契約類型は専門家へ確認してください。
システム開発委託の費用相場はいくらですか？
一律の平均額では判断できません。機能、例外、連携、データ移行、可用性、セキュリティ、言語、拠点、教育、保守を同じWBSで各社に回答させます。総額だけでなく、前提、除外、数量単価、変更単価、継続費を比較してください。
システム開発の受入テストは誰が行いますか？
受入判定の責任は発注者にあります。業務担当者、IT、品質、管理者など実際の役割でシナリオを実行し、ベンダーは環境準備、不具合解析、修正、証拠提供を支援します。開発者の結合テストだけで検収しません。
電子契約だけでタイの開発委託契約は有効ですか？
ETDAは電子データと電子署名の法的効果に関する原則・ガイダンスを公開していますが、個別の有効性は取引、権限、署名方式、完全性、保管、他の適用法によります。法務専門家に確認し、署名ログ、版、時刻、本人確認、文書保管を設計してください。
OWASP ASVS 5.0はすべてのシステムへ必須ですか？
法的に一律必須という意味ではありません。Webアプリのセキュリティ検証要求を選ぶ有用な標準です。リスクに応じて対象要求とレベルを決め、版付きID、除外、証拠、再試験を契約に記載します。
まとめ：RFPから保守まで同じ要求IDと証拠でつなぐ
タイ製造業のシステム開発 委託では、ベンダー選定より先に、発注者が業務オーナー、例外、データ、責任、受入を定義することが重要です。RFPは画面の買い物リストではなく、各社の前提と証拠を比較する文書にします。契約では変更、知財、データ、再委託、セキュリティ、終了支援を別紙で運用し、開発は意思決定ゲート、UATは業務リスク、保守は継続的な証拠で管理します。
TOMAS TECHでは、タイ工場の現状整理、業務システムRFP、ベンダー比較、要件定義、連携、受入計画の検討段階から相談できます。委託範囲や見積の比較軸がまだ固まっていない場合も、現在の業務フローと課題を添えてお問い合わせください。
参考情報URL
- NIST SP 1326: Cybersecurity Supply Chain Management Due Diligence Assessment Quick-Start Guide
- NIST SP 1326 DOI
- Thailand BOI: First-Half 2026 Investment Applications
- OWASP Application Security Verification Standard 5.0
- CISA Secure by Demand Guide
- CISA Software Acquisition Guide
- ETDA: Electronic Transactions Laws
- ETDA FAQ: Electronic Transactions Act
- Thailand BOI Investment Promotion Guide 2025
- Thailand BOI Eligible Activities
