テスト代行の費用相場は？中堅IT企業のリアルな見積もり感

2026 5/22

2026年5月22日

テスト代行の費用相場が分からず、上長への説明で会話が止まってしまう——複数案件を並行して回している受託開発のPMから、最も多く聞かれる相談のひとつです。社内では兼任中心のQA運用が続き、リリース直前にテストが間に合わずヒヤッとした経験を持つ方も少なくないはずです。だからこそ外注を検討したいのに、稟議の場では「で、いくらなの？」の一言で議論が止まってしまいます。

本記事では、テスト代行の費用感を、人月単価・契約形態・案件規模別の見積もり例という3つの切り口から整理します。さらに、内製・採用との比較や、見積もり依頼前に整えておくべきチェックポイントまで踏み込み、上長や経営層への提案資料に使える「数字感」を共有していきます。複数のベンダーから相見積もりを取る際の前提条件の揃え方や、トライアル契約の評価軸まで掘り下げているので、初めてテスト代行の発注を検討する方も、過去の発注で失敗した経験を踏まえて再検討したい方も、自社の状況に合わせて使い分けてください。

テスト代行の費用相場をざっくり押さえる人月単価

最初にぶつかる壁が「結局、人月単価いくらなの？」という疑問です。外注の見積もり水準は、提供側の業態（独立系の第三者検証ベンダーか、SIer系か、人材派遣型か）、テスター個人の経験レベル、対象システムのドメインによって大きく振れます。ここではまず、現場で語られることが多い目安レンジを整理します。

人月単価の代表的なレンジ

ここで示すレンジは、複数のテスト代行ベンダーが公開している料金プランや、受発注マッチングサイトのコラムを横断したときに語られる業界目安値です。特定の統計に基づくものではなく、あくまで初期検討時の「あたり」を付けるための数字としてご覧ください。なお、これはJSTQBが定義するテスト担当者・テストアナリスト・テストマネージャといった役割定義とは別軸で、発注側の見積もり感覚に合わせた経験レベル別の整理になっています。

テスト実行中心のジュニア層：おおむね40万〜60万円/人月
テスト設計まで担当できるミドル層：おおむね60万〜90万円/人月
テストリーダー・テストアーキテクト級：100万円/人月を超えるケースも

エンジニア単価そのものの参照軸としては、IPAが公開している「ITスキル標準」や「ITSS+」が活用できます（参考：IPA ITスキル標準 / ITSS+）。

林尚平『ソフトウェアテスト自動化の教科書』では、開発工程全体に占めるテストの割合が大きく、品質を上げる技術ばかりを伸ばすと「テストの負のサイクル」に陥ると指摘されています。単価交渉の前提として、テストにかける工数そのものを見直す視点も忘れたくないところです。

なお、上記レンジはあくまで「正社員相当のテスター1名を月160時間相当で稼働させた場合」の感覚値です。フリーランス契約や副業ベースで部分稼働を組む場合、時間単価は4,000〜8,000円程度に分解されることもあります。複数ベンダーを比較する際は、稼働前提（フル稼働なのか0.5人月相当なのか）と、有給・欠勤時の代替体制を含むかどうかまで揃えて比較しないと、見かけ上の単価差に振り回されやすくなります。

単価を上下させる5つの要素

実際の見積もりでは、同じ「ミドル層1名」でも次の要素で1.2〜1.5倍程度の幅が出ます。

対象ドメインの専門性：金融、医療、組込み、決済など、業務理解にコストがかかる領域
テストレベル：コンポーネント・コンポーネント統合の実行中心か、システム・受け入れの設計まで含むか
非機能要件の有無：性能・セキュリティ・互換性など、専用環境やツールが必要な領域
稼働の柔軟性：常駐／リモート、夜間・休日リリース対応の有無
報告・ドキュメントの粒度：軽い実施結果共有で済むのか、出荷判定用の正式ドキュメントが必要か

このうち「ドメイン専門性」と「非機能要件」は、ベンダー側が初期キャッチアップに要する学習工数として単価に転嫁されやすい項目です。たとえば金融系の決済フローで取引整合性のテストを含む場合、業務知識のある人員アサインの希少性から、同じミドル層でも標準レンジの上限を超えることが珍しくありません。逆に、社内向け業務ツールでBtoC的な複雑性が薄い案件であれば、ジュニア層中心の編成でもレンジ下限に張り付けられるケースが多くなります。

なぜ「人月単価だけ」では費用を見誤るのか

人月単価レンジを並べても、最終的な総額は「準備工数」で大きくぶれます。Lee Copeland『ソフトウェアテスト技法』では、Beizerの指摘として、トランザクションテストにおいてはテストリソースの30〜140%もがテストデータの生成・収集・抽出に費やされる、という観点が紹介されています。あくまでトランザクション処理を扱うテストに限定した数字ですが、自社案件にデータ準備の重い処理が含まれる場合は、見積もり時にテストデータ整備の工数を別立てで確認するのが安全です。

加えて、見積もりに「立ち上げ期間」が明示的に切り出されているかも要確認ポイントです。初週〜2週目はベンダー側のチームが仕様キャッチアップに費やすため、純粋なテスト実行は半分以下のスループットしか出ません。ここを発注側が見落とすと、「見積もりどおりの人数を入れたのに、初月のテスト進捗が想定の6割しか出ていない」といった食い違いが起こります。立ち上げ工数を別費目として明示してもらえるベンダーは、見積もりの透明性が高いと判断してよいでしょう。

契約形態で変わる費用構造の見極め方

外注の費用を読み解くうえで、契約形態の選び方は単価以上にインパクトを持ちます。同じ業務スコープでも、契約形態が変われば総額もリスク分担もまったく違うものになるためです。

準委任契約（人月精算）：仕様が動く案件向き

仕様変更が頻繁に発生する受託開発では、準委任契約が最も使い勝手のよい選択肢です。月単価×稼働人数で総額が決まり、テストスコープの調整に柔軟に対応できます。一方で、「成果物の品質保証」は契約上担保されないため、完了条件と検収基準を別途握っておく必要があります。

準委任で陥りがちなのが「気付いたらズルズル稼働が伸びていた」というパターンです。月次の稼働報告と進捗の突き合わせを習慣化し、想定スコープの何%を消化したか・残作業はあと何人月かを毎月可視化することで、稼働延長の判断を早い段階で打てるようになります。

請負契約（成果物責任）：仕様が固まっている案件向き

仕様凍結済みの保守リリースや、回帰テストのパッケージ化が進んでいる案件では、請負契約による固定金額契約が向きます。ベンダー側が成果物（テスト実施結果・不具合報告）に責任を持つ代わりに、単価は準委任よりも1〜2割高くなることが一般的です。

請負を選ぶときに必ず握っておきたいのが、仕様変更時の追加見積もりルールです。「画面1枚追加で◯万円」「テストケース10件追加で◯万円」のような単位を、本契約の前に書面で固めておきます。これが曖昧なまま走ると、軽微な追加のたびに毎回見積もりを取り直すことになり、結果として準委任よりも管理コストが高くついてしまいます。

スポット契約・テストケース単価型：短期・小規模向き

数日〜2週間程度の短期検証や、特定機能だけを切り出すケースでは、テストケース単価型のスポット契約が選ばれます。最小ロット感としては、テストケース100件で20〜30万円前後から受けるベンダーが多く、トライアルにも使いやすい形態です。トライアル後の評価軸としては、バグ検出件数・重大度別の検出率・社内対応工数との比較などを事前に決めておくと、本契約への移行判断がぶれません。

スポット契約のもうひとつの活用パターンが「採用前評価」です。本格的に外注ベンダーを選ぶ前に、3〜5社を同じスコープでスポット発注し、レポート品質・コミュニケーション速度・不具合の再現手順の丁寧さを実測してから本契約先を決める方法は、初期コストはかかるものの、長期で見ると外れベンダーを掴むリスクを大幅に下げられます。

Copeland『ソフトウェアテスト技法』が「適応型計画」として論じているように、現代のテスト計画はプロジェクトの局面ごとに動的に立て直すものです。契約形態も「最初に決めて終わり」ではなく、フェーズに応じて準委任から請負へ、あるいはその逆へと組み替えていく前提で設計すると無理がありません。

具体的には、要件定義〜結合テストフェーズは仕様流動性が高いため準委任、システムテスト〜出荷判定フェーズは仕様凍結後なので請負、運用フェーズの定期回帰はスポットや年次保守契約、といったレイヤード構成が現実的です。契約形態の組み替えを年度単位で見直すことを前提にしておくと、ベンダーロックインのリスクも下げられます。

案件規模別の見積もり例（小／中／大）

「自社案件はどの規模に当てはまるのか」を判断しやすくするため、画面数・テストケース数の目安と総額レンジをセットで整理します。

小規模案件のサンプル見積もり（数十万円〜100万円台）

画面数20以下、テストケース200程度、テスト期間2〜3週間規模の案件を想定したレンジです。ミドル層1名を準委任で0.5〜1人月、ジュニア層1名を実行フェーズだけスポットで投入する、といった構成で組み立てると、総額は数十万円〜150万円前後に収まります。Webサービスの小規模機能追加や、内部管理ツールのリリース前検証で選ばれる規模感です。

このクラスでは、テスト計画書の作成にどこまで工数を割くかが総額を左右します。社内のテスト観点リストが整っている前提なら、計画書は5〜10ページの簡易版で済ませ、設計・実行に工数を寄せたほうがコスト効率は良くなります。逆に観点リストが未整備の状態でいきなり外注すると、計画工数が膨らんで小規模案件のはずが200万円近くに着地することもあります。

中規模案件のサンプル見積もり（200〜500万円前後）

画面数50〜100、テストケース500〜1,500、テスト期間1〜2か月規模の案件を想定したレンジです。テストリーダー1名（ミドル〜シニア）が計画・設計を担当し、ジュニア層2〜3名で実行フェーズを回す構成が一般的で、総額は200〜500万円前後に着地します。BtoB SaaSの中規模リリースや、業務システムのバージョンアップ案件でよく見られる規模感です。

中規模になるとリーダー1名の力量で総額が2割近く変動します。特にリーダーが要件定義段階から関与できるかどうかは、後工程のテストケース設計品質に直結し、結果的に実行フェーズの不具合戻りを減らす効果があります。リーダー単価を惜しんで実行担当を増やす構成にすると、不具合戻りや手戻り工数で結局総額が膨らみやすくなる、というのが現場でよくあるパターンです。

大規模案件のサンプル見積もり（1,000万円超）

画面数200超、回帰込みで5,000ケースを超えるテストケース、コンポーネント統合・システム・システム統合・受け入れの複数テストレベルが絡む案件です。テストアーキテクト級1名がリードし、リーダー2〜3名・実行担当5名以上のチームを3〜6か月編成する構成で、総額は1,000万円を超えるケースも珍しくありません。金融・決済・大規模基幹系の入れ替えなど、品質責任が重い案件で選ばれます。

大規模案件では、テスト管理ツール（TestRail・Qase・Zephyrなど）のライセンス費用や、性能テスト用のクラウドインフラ費用が見積もりの数%〜10%を占めることもあります。これらをベンダー持ちにするか発注側持ちにするかで総額が変わるため、見積もり比較時には「ツール・インフラ費用を含むか」の前提条件を必ず揃えてください。

実際の規模感を見立てる際は、IPA「ソフトウェア開発分析データ集」のような公開データで自社プロジェクトの規模を相対化しておくと、上長への説明資料に客観性が出ます（参考：IPA ソフトウェア開発分析データ集）。

見積もり書の内訳と単価の変動要因

見積もり書をベースに読み解くと、単価レンジだけでは見えなかった変動要因が浮かび上がります。ここでは、ベンダーの見積もり書に頻出する費目構成と、価格を動かす要因を整理します。

費用の内訳（計画／分析／設計／実装／実施／完了／管理）

ISO/IEC/IEEE 29119が定義するテストプロセスに沿って整理すると、見積もり書の費目はおおむね次の構成になります。

テスト計画：スコープ・体制・スケジュール設計
テスト分析：テスト観点・リスクの抽出
テスト設計：テストケース・データ条件の設計
テスト実装：テスト手順書・テストデータの準備
テスト実施：実行・不具合報告
テスト完了：終了基準の判定・最終レポート作成
テスト管理：進捗・品質メトリクスの可視化

このうち「分析・設計・実装」の比率が高い見積もりは、設計品質に投資する姿勢が読み取れる一方、実行フェーズの単価だけを切り出して比較すると割高に見えることがあります。見積もりを比較するときは、合計金額だけでなく「総額に対する設計フェーズの比率」を並べてみてください。設計比率が極端に低いベンダーは、現場で行き当たりばったりにテストを進める可能性が高く、結果として不具合の見落としや手戻りが増えがちです。

単価を押し上げる5要因

ドメイン専門性／非機能要件／環境構築の難易度／報告ドキュメントの厳格さ／短納期・夜間休日対応の5つは、いずれも単価に直接効きます。特に「環境構築」と「夜間休日対応」は、見積もり比較の段階では見落とされがちなので、RFPの時点で前提を揃えておくと比較がフェアになります。

たとえば「夜間にリリース判定テストを実施し、朝7時までに結果レポートを提出する」といった要件がある場合、深夜稼働手当として通常単価の1.25〜1.5倍が乗ります。年に数回しかない夜間対応であれば、特定の月だけ追加見積もりを取る形にすれば、年間総額を抑えられます。

単価を下げられる3つの発注側の工夫

逆に、発注側で次の3点を整えるだけで、同じスコープでも単価レンジの下限に寄せられます。

テスト対象・スコープを文書化：仕様書・画面設計書・APIドキュメントを事前共有
テスト観点の素案を提示：過去案件の観点リストや既知のバグパターンを共有
テスト環境・データを発注側で用意：環境準備のリードタイムを短縮

継続発注を前提にする場合は、ドメイン理解の学習曲線と、テスト観点・チェックリストといったテスト資産の再利用が効いてきます。同じベンダーに2〜3案件続けて発注すると、初回案件で重く乗っていた立ち上げ工数が次案件以降は薄まり、実質的な単価が下がっていきます。

なお、外注前提を取らずに社内で打てる手については受託開発でテストを効率化する5つの方法で詳しく整理しています。社内で何ができて何ができないかを棚卸ししたうえで、残った領域だけを外注対象にすると、外注費を最小限に抑えられます。

内製・採用と外注のコスト比較

外注の費用感を判断するときに欠かせないのが、「採用 vs 外注」のコスト比較です。上長や経営層に説明するときも、外注単価だけを並べるより、内製コストとの差分を見せたほうが説得力が出ます。

テスト専任採用にかかる年間総コストの試算

QA専任を1名採用するときの年間総コストは、ざっくり「年収の1.5倍」と見ておくと外しません。年収600万円のミドル層を採用する場合、内訳の目安は次のとおりです。

年収本体：600万円
法定福利費：約90万円
採用費（エージェント・媒体）：約80万円
PC・各種ライセンス：約30万円
教育・立ち上げ工数（受け入れ側の負担）：約100万円

合計でおおむね900万円前後、つまり年収の1.5倍弱が「採用1名」の年間総コストになります。離職リスクを織り込むと、さらに数百万円の上振れ要因が乗ります。

特に見落とされがちなのが「教育・立ち上げ工数」です。新任QAが独力でテスト計画から実行まで回せるようになるには、社内の業務理解込みで3〜6か月かかるのが一般的です。この期間は受け入れ側のシニアエンジニアやPMが指導工数を取られるため、見えにくいですが本来の業務スループットが落ちる隠れコストとして計上しておくべきです。

外注で同じ工数をカバーした場合の年間コスト

同等スキルのミドル層を準委任で1名分（月額75万円想定）通年で確保すると、年間900万円と計算上は採用とほぼ同水準です。ただし、外注の場合は案件の繁閑に合わせて稼働を0.5人月／月単位で増減でき、教育コストや離職リスクも発注側に乗りません。

加えて、外注は「個人ではなくチームを契約している」とも捉えられます。アサインメンバーが離脱した場合でも、ベンダー側で代替要員を立てる責任を負うため、属人化リスクを発注側が抱え込まずに済みます。これは採用1名では実現できない冗長性であり、コスト比較表に載せにくいですが意思決定上は無視できない要素です。

「採用 vs 外注」を決める3つの判断軸

稼働の安定性：通年でフル稼働させ続けられるか、案件の波があるか
ドメインの蓄積要件：自社プロダクトの仕様理解を社内に残したいか
品質責任の所在：出荷判定の最終責任を社内に置きたいか、外部に分担したいか

通年でフル稼働、かつ自社プロダクト中心であれば採用が有利、案件の波が大きく複数顧客の仕様を扱うなら外注が有利、という整理に落ち着くケースが多いはずです。実際の中堅IT企業では、「主要プロダクトの担当として正社員QAを1〜2名抱えつつ、案件ピーク時には外注で2〜3名を増員する」というハイブリッド型が現実解になりやすい構図です。

見積もりを取る前に整えておく5つのチェックポイント

複数社の見積もりを比較するときに、依頼内容の解像度が低いまま投げると、見積もり間で前提が揃わず比較になりません。発注前に最低限整えておきたいのが、次の5点です。

テスト対象・スコープを文書化する

対象システムの画面一覧・機能一覧、対象外とする領域、対応プラットフォーム・ブラウザを箇条書きでまとめておきます。RFPに添付するだけで、各社の見積もり前提が揃います。1ページのスコープ定義書があるかないかで、各社の見積もり工数と精度が大きく変わるため、ここに半日かけてでも整備する価値があります。

完了条件（出荷判定基準）を発注前に握る

「重大度Aのバグが残ゼロ」「主要シナリオの100%パス」など、終了基準を数値で握ります。基準が曖昧だと、ベンダー側がリスクを織り込んで単価を上げざるを得ません。終了基準は受発注双方の「ここまでやれば終わり」の合意点であり、見積もり段階で握っておけば追加見積もりのトラブルも大幅に減らせます。

テスト観点・既知の不具合パターンを共有する

過去案件のテスト観点リストや、よく出るバグパターンを共有すると、テスト分析・設計フェーズの工数を圧縮できます。観点リストが未整備でも、過去のバグチケットからカテゴリ別に上位20件を抜き出して共有するだけで、ベンダー側は「この案件で重点的にケアすべき領域」を把握でき、設計品質が上がります。

テスト環境・データ提供の責任分界を決める

検証環境の準備、テストデータの作成、本番相当データのマスキングなどを「どちらが用意するか」明示します。データ準備のボリュームによっては、見積もりの構造そのものが変わります。特に個人情報を含むデータのマスキング処理を依頼するか自社で処理するかは、コンプライアンス面でも見積もり面でも大きな分岐点になります。

情報共有フェーズを工数に含めるか確認する

キックオフ・週次定例・終了報告会などのコミュニケーション工数を、見積もりに含めるかどうかを事前に確認します。含めないと、追加見積もりが後から発生しがちです。週次定例1時間×8週間でも、リーダー単価で換算すると数十万円規模の費目になるため、見積もり比較時には「会議体の運営工数」が含まれているか必ずチェックしてください。

テスト観点を体系的に整理する手法については、JSTQBのシラバスや関連教材も参考になります（参考：JSTQB シラバス・教材）。社内のテスト観点を体系化しておくと、外注時のキャッチアップ工数を圧縮できるだけでなく、テスト漏れの根本原因を抑える効果もあります。

テスト代行の費用相場を踏まえた次の一歩

ここまで整理してきた相場感を、実際の意思決定にどうつなげるかを最後に整理します。

費用対効果で語る

外注単価そのものではなく、「現状の障害対応コスト」「リリース遅延による機会損失」「兼任エンジニアの本来業務への復帰効果」と並べて比較すると、稟議の通り方が変わります。たとえば月200万円のテスト外注費は単体では高く見えても、リリース後の障害対応で月100万円相当のエンジニア工数を消費していたり、リリース遅延で月数百万円規模の機会損失が出ていたりすれば、外注のほうが安いという結論になることも珍しくありません。

まずは小さく試す

いきなり大型契約に踏み切らず、スポット契約や小規模案件で1社〜2社をトライアルし、バグ検出力・レポート品質・コミュニケーション速度を実測してから本契約に進む流れが安全です。トライアル予算としては50〜100万円程度を見ておけば十分で、ここで見極めができれば年間数千万円規模の発注判断を安心して進められます。