# システムテスト費用の相場｜外注範囲と選び方

- 公開日: 2026-09-13
- 監修: 代表取締役 兼 StockSun創業メンバー 板橋 晟星
- URL: https://www.geek-bridge.com/column/system-test-outsourcing-cost

システムテストの外注費用は、小規模なら20万〜150万円、中規模なら150万〜500万円、大規模なら500万〜1,500万円以上が一般的な目安です。費用は対象機能、端末数、テスト設計の有無、再テスト回数によって大きく変わります。

システムテストとは、個別機能だけでなく、システム全体が要求どおりに動作するかを確認する工程です。外注先にはテスト実行だけを頼む方法と、テスト計画・設計・実行・結果報告まで一括して頼む方法があります。

発注時に重要なのは、総額だけを比較することではありません。「どこまで確認するか」「不具合修正後の再テストは何回含むか」「テスト環境やデータを誰が用意するか」をそろえて比較する必要があります。本記事では、システムテストを外注する発注者に向けて、費用相場、期間、準備、見積もり、外注先の選び方を解説します。

## システムテスト外注の費用相場

システムテストの費用は、テスト担当者の人数と期間を基礎に算出されることが一般的です。QA（Quality Assurance＝品質保証）の専門性、テスト対象の複雑さ、利用する端末や外部サービスの数によっても変動します。

以下は、一般的なWebシステムやスマホアプリを外注する場合の目安です。金額は税別を想定した概算であり、実際の見積もりは要件や品質目標によって異なります。

|規模・依頼内容|費用の目安|期間の目安|想定される内容|
|---|---:|---:|---|
|限定的なテスト実行のみ|20万〜60万円|1〜2週間|既存のテスト仕様書に沿って主要機能を確認|
|小規模な設計・実行|50万〜150万円|2〜6週間|1つのWebサービスや業務システムの主要機能を確認|
|中規模な設計・実行|150万〜500万円|1〜3か月|複数権限、外部連携、スマホ対応などを含む確認|
|大規模・複数システム|500万〜1,500万円以上|3〜6か月以上|基幹システム、複数部署・拠点、複雑な連携を含む確認|

小規模でも、決済、個人情報、複雑な権限管理などを含む場合は費用が上がります。一方、大規模なシステムでも、重要機能に対象を絞れば初回の外注費用を抑えられることがあります。

### 工程別の費用目安

テスト外注には、実行以外にも計画、設計、環境準備、結果分析などの工程があります。

|工程・追加テスト|費用の目安|主な作業|
|---|---:|---|
|テスト計画・テスト設計|30万〜150万円|対象範囲、確認方法、合否基準、テスト項目の作成|
|端末・ブラウザ検証|30万〜200万円|複数のスマートフォン、OS、ブラウザでの表示・動作確認|
|負荷テスト|50万〜300万円|同時利用やアクセス集中を想定した性能確認|
|テスト自動化の初期構築|100万〜500万円以上|繰り返しテストを自動実行する仕組みの構築|
|セキュリティ診断|50万〜300万円以上|脆弱性や不正アクセスにつながる問題の確認|

これらは単独メニューの目安であり、通常のシステムテスト費用と重複する作業もあります。追加料金として単純に合算するのではなく、見積書上の作業範囲を確認してください。

また、セキュリティ診断は通常の動作テストとは目的や専門性が異なります。システムテストを実施しただけで、セキュリティ上の安全性まで確認できたとは限りません。

### 人月単価から見た費用

人月とは、1人が1か月稼働する作業量の単位です。テスト外注における人月単価の一般的な目安は次のとおりです。

|役割|人月単価の目安|主な役割|
|---|---:|---|
|テスト実行担当者|40万〜80万円|テスト実行、証跡取得、不具合報告|
|テストリーダー|70万〜120万円|進捗管理、品質管理、不具合の整理|
|QA・テスト設計担当者|80万〜150万円|計画、リスク分析、テスト設計、結果評価|

人月単価は担当者の給与ではなく、外注会社の管理費や設備費などを含む契約上の単価です。

例えば、テストリーダーが0.5人月で45万円、実行担当者2人が2か月稼働して240万円、端末・環境費が30万円、再テストの予備費が50万円なら、概算は365万円です。これは計算方法を示す例であり、標準価格を意味するものではありません。

## 費用と期間を左右する要素

システムテスト費用を左右するのは、画面数や機能数だけではありません。仕様の明確さ、利用環境、データの組み合わせ、不具合修正の進み方まで含めて工数が決まります。

### 1. テスト設計をどこから依頼するか

テスト仕様書が完成していれば、外注先は実行から着手できます。ただし、テスト仕様書が古い、期待結果が書かれていない、現在の機能と一致していない場合は、そのまま実行しても正しい合否判定ができません。

依頼範囲は大きく次の3種類に分かれます。

|依頼範囲|向いている状況|注意点|
|---|---|---|
|テスト実行のみ|社内や開発会社が仕様書を作成済み|仕様書の不備による追加費用が発生しやすい|
|テスト設計・実行|機能仕様はあるがテスト項目がない|仕様確認に発注者の協力が必要|
|計画・設計・実行・報告|品質管理を一括して任せたい|責任分担と成果物を明確にする必要がある|

発注のご相談を受ける開発会社の立場から見ると、「仕様書はあるので実行だけ頼みたい」という相談でも、確認すると期待結果や例外時の動作が決まっていないケースがあります。安く発注するために工程を省くより、最初に仕様書の状態を確認してもらう方が、総額を抑えやすくなります。

### 2. 対象機能と組み合わせの数

ログイン画面が1つでも、一般利用者、管理者、承認者など複数の権限があれば、確認する組み合わせは増えます。料金プラン、支払方法、承認段階、在庫状態などの条件が掛け合わされるシステムも同様です。

機能数だけでなく、次の条件を伝えることが重要です。

- 利用者の権限と役割
- 正常時だけでなく、入力エラーや通信失敗時の動作
- 外部システムやAPIとの連携数
- メール、SMS、プッシュ通知の種類
- 月末、締め日、年度更新などの時間条件
- 扱うデータ量とデータ形式
- 決済、返金、キャンセルなどの業務パターン

### 3. 端末・OS・ブラウザの数

スマホアプリや一般消費者向けWebサービスでは、確認対象となる端末、OS、ブラウザが増えるほど費用も増えます。すべての組み合わせを均等に確認するのではなく、利用者が多い環境や事業上重要な環境を優先するのが現実的です。

対応環境は「主要ブラウザ」とだけ書かず、対象となるOS、ブラウザ、バージョン、端末の範囲を具体化してください。実機を外注先が用意する場合は、端末利用料が別途発生することもあります。

### 4. 不具合修正と再テストの回数

再テストとは、修正された不具合が解消したかを改めて確認する作業です。さらに、修正によって別の機能が壊れていないかを確認する回帰テストも必要になる場合があります。回帰テストとは、変更の影響が既存機能へ及んでいないかを確かめるテストです。

見積もりには、次のいずれで再テストを扱うかが記載されます。

- 再テスト1回または2回までを定額に含む
- 想定工数をあらかじめ確保する
- 実績時間に応じて追加精算する
- 契約期間内で優先順位を調整する

不具合が多いほどテスト会社の作業量も増えます。定額契約であっても、再テストが無制限に含まれるとは限りません。

### 5. 開発とテストを並行するか

開発中の機能を順番に受け取りながらテストする方法は、早期に問題を見つけられる反面、仕様変更やビルドの差し替えによって再確認が増えます。ビルドとは、テストや公開ができる状態にまとめたプログラム一式です。

費用と期間を安定させるには、次の条件を決めておきます。

- テストへ渡す機能の完成条件
- テスト版を更新する曜日や時間
- 緊急修正を受け入れる条件
- 仕様変更時の連絡方法
- テスト終了後に変更を凍結する期間

納期だけを固定したまま開発完了が遅れると、テスト期間が圧縮されます。短期間に人員を増やしても、仕様確認や不具合修正が追いつかなければ品質は安定しません。

## テスト外注の依頼準備と進め方

テスト外注を円滑に進めるには、完成した仕様書をすべて用意する必要はありません。まず、テストの目的、対象範囲、希望時期、現在ある資料を共有すれば、外注先が不足情報を整理できます。

### 依頼前に準備するチェックリスト

最低限、次の項目を整理してください。

- テスト対象となるシステムやアプリの概要
- テストの目的と公開・稼働予定日
- 対象機能と対象外にする機能
- 利用者の権限、主な業務、利用環境
- 仕様書、画面一覧、機能一覧、業務フローの有無
- 対応するOS、ブラウザ、端末
- 外部システムやAPIの連携先
- テスト環境、アカウント、テストデータの準備担当
- 不具合を修正する開発会社と連絡担当者
- 個人情報や機密情報の取り扱い条件
- 希望する成果物と報告頻度
- 想定予算と見積もり提出期限

機能の全体像が整理されていない場合は、先に[機能一覧の作り方｜システム開発の依頼準備](https://www.geek-bridge.com/column/system-function-list-preparation)を参考に、利用者別の機能と優先順位をまとめると見積もり精度を高められます。

### ステップ1：品質目標と優先順位を決める

すべての不具合をゼロにすることを目標にすると、費用も期間も際限なく増えます。まず、事業上止めてはいけない機能と、公開後の修正でも対応できる機能を分けます。

例えば、次のように優先順位を設定します。

- 最優先：ログイン、注文、決済、データ保存など事業継続に関わる機能
- 優先：検索、通知、帳票など主要業務に関わる機能
- 標準：設定変更や補助的な管理機能
- 限定確認：利用頻度が低く、影響範囲が小さい機能

優先順位は、テスト項目を減らすためだけのものではありません。限られた期間で重大な問題を先に発見するために使います。

### ステップ2：資料を共有して概算見積もりを取る

機密保持契約を締結したうえで、機能一覧、画面、仕様書、スケジュールなどを共有します。仕様が固まっていない場合は、最初から確定見積もりを求めず、概算と前提条件を提示してもらう方法が適しています。

おすすめは、次の二段階で見積もる方法です。

1. 資料確認とテスト計画の段階で概算を出す
2. テスト設計後、項目数と実行条件をもとに金額を更新する

初回見積もりから金額が変わる可能性はありますが、曖昧な前提のまま一式金額を確定するより、追加費用の理由を把握しやすくなります。

### ステップ3：役割分担と合否基準を決める

テスト会社は不具合を検出できますが、仕様そのものの正しさや、事業として公開してよいかを単独で決めることはできません。最終的な受入判断は発注者が担います。

事前に、次の役割を決めてください。

|作業|主な担当候補|
|---|---|
|仕様に関する回答|発注者・開発会社|
|テスト計画と設計|テスト会社・開発会社|
|テスト環境の構築|開発会社・インフラ担当|
|テストデータの用意|発注者・開発会社・テスト会社|
|不具合の修正|開発会社|
|修正後の再テスト|テスト会社|
|公開可否の最終判断|発注者|

合否基準には、「重大な不具合が0件」「中程度の不具合は対応方針が決まっている」など、公開判断に使える条件を設定します。重大度の定義も、不具合報告が始まる前にそろえておきます。

### ステップ4：設計レビュー後にテストを実行する

テストケースとは、操作手順、入力値、期待する結果をまとめた確認項目です。実行前にテストケースをレビューし、重要な業務や例外処理が漏れていないかを発注者・開発会社・テスト会社で確認します。

実行中は、件数だけでなく次の情報を共有してもらいます。

- 実行済み、合格、不合格、保留の件数
- 重大度別の不具合件数
- 仕様確認が必要な事項
- テストを妨げている環境問題
- 現在の進捗から見た完了予測
- 発注者や開発会社に求める対応

不具合が多数見つかった場合は、トリアージを行います。トリアージとは、不具合の影響度や緊急度を整理し、修正の優先順位を決めることです。

### ステップ5：結果報告を受けて受入判断をする

テスト完了時には、単なる合格件数ではなく、未解決の問題と残存リスクを確認します。成果物として、次の資料を受け取れるか契約前に確認してください。

- テスト計画書
- テスト仕様書・テストケース
- 実行結果と操作証跡
- 不具合一覧と対応状況
- 未実施・保留項目の一覧
- 品質評価と残存リスク
- 次回以降に再利用できる回帰テスト項目

テストケースや証跡の所有権、契約終了後のデータ返却・削除方法も明確にしておくと、保守や追加開発で再利用しやすくなります。

## 見積もりの見方と外注先の選び方

良い見積もりは、金額が安いものではなく、対象範囲、前提、成果物、追加料金の条件が読み取れるものです。「システムテスト一式」とだけ記載された見積もりでは、各社の比較も契約後の管理も難しくなります。

### 見積書で確認する項目

|確認項目|確認する内容|
|---|---|
|対象範囲|機能、画面、権限、連携、端末の対象と対象外|
|作業工程|計画、設計、実行、再テスト、報告のどこまで含むか|
|体制|QA担当、リーダー、実行担当者の人数と稼働期間|
|テスト環境|構築、保守、アカウント発行を誰が担当するか|
|テストデータ|作成、匿名化、初期化を誰が担当するか|
|再テスト|含まれる回数・工数と追加料金の条件|
|成果物|計画書、仕様書、証跡、不具合一覧、完了報告書|
|不具合修正|プログラム修正費用が含まれるか|
|仕様変更|テスト中に仕様が変わった場合の精算方法|
|機密情報|データの保管場所、アクセス制限、削除方法|

特に誤解されやすいのが、不具合の修正費用です。テスト会社が開発も担当していない限り、通常は不具合の発見・報告と再テストまでが範囲で、プログラム修正は別料金です。

### 外注先を比較する質問

候補会社には、実績件数だけでなく、テストの進め方を質問してください。

- 重要機能とリスクをどのように整理するか
- 仕様書に不足があった場合、どのように確認するか
- テストケースを誰がレビューするか
- 不具合の重大度をどの基準で判定するか
- 日次・週次で何を報告するか
- 開発会社との問い合わせを誰が管理するか
- 個人情報や本番相当データをどう保護するか
- 担当者の交代時にどのように引き継ぐか
- 再委託の有無と、再委託先をどう管理するか
- 遅延や不具合多発時にどのような代替案を提示するか

業務知識が必要なシステムでは、業界経験の有無だけでなく、仕様を理解するための質問力も重要です。発注者の説明をそのまま受け取るだけでなく、例外処理や権限差、データ不整合の可能性を確認できる会社が適しています。

第三者のテスト会社に依頼すれば、開発チームとは異なる視点で確認できる利点があります。一方、開発会社とテスト会社が別になることで、仕様確認や不具合の切り分けに時間がかかることもあります。どちらが適しているかは、独立性だけでなく連携体制まで含めて判断してください。

### よくある失敗と回避策

|よくある失敗|起こりやすい問題|回避策|
|---|---|---|
|最安値だけで決める|設計、再テスト、報告が対象外だった|各社へ同じ範囲と成果物を提示する|
|テスト項目数だけで品質を判断する|似た項目が多く、重要なリスクが漏れる|重要機能と業務影響を基準にレビューする|
|開発遅延分をテスト期間で吸収する|確認不足のまま公開日を迎える|機能を絞るか、公開日を含めて再調整する|
|本番データをそのまま渡す|個人情報や機密情報が漏れる可能性がある|匿名化したテストデータを用意する|
|受入判断まで外注先へ任せる|事業要件とのずれを見落とす|最終判断者と合否基準を発注者側で決める|
|再テスト条件を決めない|想定外の追加費用が発生する|回数、工数、単価、終了条件を契約に記載する|

テスト会社は品質を確認し、リスクを可視化する役割を担いますが、曖昧な要件を自動的に正したり、短期間であらゆる不具合を発見したりできるわけではありません。発注者、開発会社、テスト会社の三者で判断基準を共有することが重要です。

見積もりの前提整理や、開発とテストを含む体制について相談したい場合は、[開発のご相談はこちら](https://www.geek-bridge.com/#contact)からお問い合わせください。

## まとめ

- システムテストの外注費用は、小規模で20万〜150万円、中規模で150万〜500万円、大規模で500万〜1,500万円以上が一般的な目安です。
- 費用は、対象機能だけでなく、権限やデータの組み合わせ、端末数、外部連携、再テスト回数によって変わります。
- テスト実行だけを依頼する場合でも、既存のテスト仕様書と期待結果が正しいかを事前に確認する必要があります。
- 見積書では、計画・設計・実行・再テストの範囲、成果物、不具合修正の扱い、追加料金の条件を確認します。
- テスト会社は不具合を検出してリスクを可視化しますが、公開可否の最終判断は発注者が担います。
- 価格だけで外注先を選ばず、リスクの整理方法、報告内容、開発会社との連携、機密情報の管理まで比較することが重要です。

## よくある質問

### システムテストの外注費用はいくらですか？

一般的な目安は、小規模なテスト実行のみで20万〜60万円、設計を含む小規模案件で50万〜150万円、中規模案件で150万〜500万円です。大規模案件や複数システムにまたがる案件は500万〜1,500万円以上になることもあります。対象機能、端末数、テストデータ、再テスト回数などで変動します。

### テストの実行だけを外注できますか？

既存のテスト仕様書、テスト環境、アカウント、テストデータ、期待結果がそろっていれば、実行だけの外注も可能です。ただし、仕様書が古い場合や期待結果が曖昧な場合は、テスト設計の見直しから依頼した方が手戻りを抑えられます。

### テスト費用に不具合の修正費用は含まれますか？

通常、テスト会社の見積もりに含まれるのは不具合の検出、報告、修正後の再テストまでで、プログラムの修正費用は含まれません。開発会社とテスト会社が別の場合は、不具合の切り分けや問い合わせ対応の担当も契約前に決めておく必要があります。

### システムテストはいつ外注先へ相談すべきですか？

テスト開始予定日の1〜2か月前を目安に相談するのが一般的です。中規模以上の案件、スマホアプリの多端末検証、負荷テストを含む案件では、2〜3か月以上前から相談すると、範囲調整や環境準備を進めやすくなります。