QAテスターへのテスト委託で決める合格条件｜バグ件数と完了の定義

2026年5月2日

中西直美

この記事のポイント

✓QAテスター委託の検収で失敗しないために
✓合格条件・バグ件数の基準・完了の定義をどう契約書に落とし込むかを
✓費用相場と発注先の選び方まで含めて具体的に解説します

「自社にQAの専任がいないので、テストだけ外注したい。でも何をどこまで任せられて、いくらかかるのかが分からない」。QAテストの外注を検討し始めた発注者の方から、最初に届くのはほぼこの質問です。開発は外注に慣れていても、テスト工程だけを切り出して他社や個人に任せる経験はない、という会社は珍しくありません。

この記事では、QAテストを外注するときの全体像を最初に整理します。外注できるテスト業務の範囲、依頼形態別の費用相場、依頼先3タイプ（テスト専門会社・開発会社・フリーランス）の違い、見積もり依頼から検収までの流れ。そのうえで、外注で最ももめやすい「どこまでやったら完了なのか」「バグが何件残っていたら不合格なのか」という合格条件と検収の決め方を、契約書に書ける粒度まで落として解説します。そのままコピーして使える見積もり依頼メールの例文、バグレポートのフォーマット、検収条項の文例も載せています。

QAテストの外注で任せられる業務と費用相場

まず結論から示します。QAテストの外注は「テスト工程まるごと」でも「一部の工程だけ」でも依頼できます。自社にテスト計画やテストケースが既にあるなら実行だけを切り出せますし、何もない状態から設計を含めて丸投げすることも可能です。

外注できるテスト工程の一覧

QAテストは大きく7つの工程に分解できます。どこを自社で持ち、どこを外に出すかを最初に決めておくと、見積もりのブレが一気に小さくなります。

工程	具体的な作業内容	外注のしやすさ	発注時に自社が用意するもの
テスト計画	テストの目的・範囲・体制・スケジュール・完了基準の策定	やや難しい（仕様理解が前提）	要件定義書、リリース計画
テスト設計	テスト観点の洗い出し、テスト種別の選定、優先度づけ	やや難しい	仕様書、画面設計書
テストケース作成	手順・入力値・期待結果を1件ずつ書き起こす	出しやすい	仕様書、既存ケースがあれば提供
テスト実行	テストケースに沿って操作し、合否を記録する	最も出しやすい	検証環境、テストデータ、アカウント
バグ報告と再現確認	不具合の起票、再現手順の特定、修正後の確認	出しやすい	バグ管理ツールのアカウント
リグレッションテスト	修正が既存機能を壊していないかの再検証	出しやすい	対象範囲の指定
テスト自動化	自動テストの実装、CI連携、メンテナンス	専門性が必要	リポジトリへのアクセス、CI環境

初めてQAテストを外注する会社に最も多いのは、「テストケース作成」から「テスト実行」「バグ報告」までをまとめて出すパターンです。ここが人手のかかる部分であり、かつ社内の判断を必要とする度合いが比較的低いため、切り出しやすいのです。

逆に、テスト計画とテスト設計を最初から外に出すのはハードルが上がります。プロダクトの仕様とユーザーの使われ方を理解していないと、そもそもテスト観点が立たないからです。とはいえ、経験のあるQAエンジニアであれば仕様書のキャッチアップから引き受けてくれます。その場合は、キャッチアップ期間分の工数を見積もりに含めてもらうのが前提になります。

テスト種別ごとの外注イメージ

「テスト」とひとことで言っても中身はさまざまです。何を依頼したいのかを言語化するために、代表的なテスト種別も整理しておきます。

テスト種別	何を確かめるか	外注時の依頼のしやすさ
機能テスト	仕様どおりに動くか	定番。テストケースがあれば即依頼可能
探索的テスト	仕様書に書かれていない穴を経験則で探す	単発依頼と相性が良い
リグレッションテスト	改修が既存機能を壊していないか	定期・継続依頼と相性が良い
互換性テスト	ブラウザ・OS・端末ごとの表示や動作	実機を持つ相手に出すと効率的
性能テスト	負荷をかけたときの応答速度や耐久性	専門ツールの経験者が必要
セキュリティ診断	脆弱性の有無	専門業者の領域。QAテストとは別枠で考える
ユーザビリティ評価	使いにくさ、迷いやすさ	定量評価が難しく、期待値の擦り合わせが必須

セキュリティ診断だけは毛色が違います。一般的なQAテスターの守備範囲を超えるため、「ついでにセキュリティも見てほしい」と混ぜて依頼するとトラブルの元になります。別契約・別見積もりにするのが無難です。

依頼形態別の費用相場

発注者が支払う金額の目安です。テストの規模、対象の複雑さ、必要なスキルレベルによって上下しますが、予算取りの出発点としてお使いください。

依頼形態	費用の目安（発注者が支払う額）	向いているケース
単発・スポット（探索的テスト1回）	3万円から15万円	リリース前に第三者の目を入れたい
単発・テストケース作成込み	15万円から50万円	テストケースが社内にない
月額・継続（週2日程度の稼働）	15万円から40万円	定期リリースがあり毎回テストが必要
人月（フルタイム相当）	50万円から100万円	開発チームに常時1名QAを置きたい
テスト自動化の構築	50万円から200万円	回帰テストの工数を恒久的に減らしたい
従量・テストケース単価	1件あたり300円から1,500円	大量のケース実行だけを外に出したい

単発の探索的テストが3万円から15万円で収まるのは、成果物が「発見した不具合の一覧」に限定されるからです。ここにテストケースの作成や設計まで含めると、作業量が数倍になるため金額の桁が変わります。見積もりを比較するときは、まず「どの工程まで含まれた金額なのか」を揃えてから並べてください。

人月単価で見ると、QAエンジニアの相場は月50万円から100万円のレンジに収まることが多く、テスト実行が中心なら下限寄り、テスト設計や自動化まで担うなら上限寄りになります。開発エンジニアの相場と比べて安く見積もられがちですが、テスト設計ができる人材は市場に多くないため、安さだけを狙うと「実行はできるが観点が出せない」人に当たります。

見積もりが跳ね上がる要因

同じ「テスト外注」でも、次の条件が付くと金額は上振れします。事前に自覚しておくと、見積もりを見たときに驚かずに済みます。

・検証環境を発注者側で用意できず、外注先に構築を依頼する場合・対応ブラウザやOSのバージョンが多く、同じケースを何度も回す必要がある場合・実機（スマートフォンやタブレット）の種類を多く指定する場合・仕様書が存在せず、動くものを見ながら仕様を起こす作業が発生する場合・リリース直前で短納期を要求する場合・NDAに加えて、作業場所や端末の制限（セキュリティルーム内作業など）がある場合

とくに「仕様書がない」は費用に直結します。テストは仕様と実装を突き合わせる作業なので、正解が文書化されていないと、テスターは開発者への質問を繰り返すことになり、その分の工数が乗ります。仕様書が整っていない自覚があるなら、最低限「主要画面でできることの一覧」だけでも用意してから見積もりを取ると、金額も精度も改善します。

依頼先は3タイプ。テスト専門会社・開発会社・フリーランスの違い

QAテストの依頼先は大きく3つに分かれます。それぞれ得意分野と費用構造が違うので、対象の規模とリスク許容度で選び分けます。

比較項目	テスト専門会社	開発会社（テストも受託）	フリーランスQAテスター
費用感	高め（管理費・営業経費が上乗せ）	中から高	低から中（中間マージンなし）
得意なこと	大規模、実機多数、体制構築	開発と一体での品質担保	特定領域の深い検証、柔軟な稼働
立ち上がりの速さ	遅い（契約手続きが重い）	中	速い（数日で着手可能）
品質の安定性	高い（社内標準とレビュー体制）	会社による	個人差が大きい。選定が全て
代替要員	いる	いる	いない。稼働停止リスクを負う
小規模案件の受注	断られることがある	断られることがある	受けやすい
ドキュメント整備力	高い	中	人による
秘密保持・体制監査	対応しやすい	対応しやすい	個別にNDAを締結する

テスト専門会社は、リリース規模が大きく、対応端末が数十種類に及ぶような案件で強みを発揮します。テスト設計の標準やレビュー体制が社内にあるため、成果物の粒度が安定します。反面、小さな案件は最低受注金額に届かず断られることがありますし、契約から着手までに時間がかかります。

開発会社にテストも合わせて頼む形は、開発とテストの責任分界点が曖昧になるという構造的な弱点があります。作った本人が作ったものを検証するため、仕様の思い込みがそのまま検証の穴になりやすい。第三者検証としての価値を求めるなら、開発とは別の相手に出すのが原則です。

フリーランスのQAテスターに直接依頼する形は、費用面のメリットが最も大きい選択肢です。会社を経由すると、テスターの人件費に加えて管理費と営業経費が上乗せされます。直接契約であればこの中間マージンが発生しないため、同じ予算でより多くのテスト工数を確保できます。手数料0%で直接契約できるマッチングサービスを使えば、この構造上のメリットをそのまま享受できます。

ただし、個人に依頼する以上、その人が体調を崩したときの代替要員はいません。リリース日が動かせない案件で単独のフリーランスに全面依存するのはリスクがあります。対策としては、テストケースと進捗を共有ドキュメントで常に見える状態にしておき、引き継ぎ可能な形を保つこと。あるいは重要度の高い時期だけ2名体制にすることです。

どれを選ぶかの判断軸

・リリース規模が大きく、対応端末が多い、もしくは監査対応が必要 → テスト専門会社・開発の一部として品質を担保したく、第三者性を求めない → 開発会社・予算を工数に最大限まわしたい、小回りを利かせたい、継続的に付き合いたい → フリーランス

初めての外注であれば、まずフリーランスに小さな単発案件（探索的テスト1回など）を出して、成果物の質とコミュニケーションを確かめるのが現実的です。そこで信頼できると分かってから、継続契約や範囲拡大に進めば、失敗したときの傷が浅く済みます。

QAテスト外注の進め方。依頼から検収までの7ステップ

依頼の流れを把握しておくと、どこで何を決めるべきかが見えます。

ステップ1. 外注する工程を決める

前掲の工程一覧を使って、自社で持つ範囲と外に出す範囲を線引きします。この線引きが曖昧なまま声をかけると、相手ごとに前提の違う見積もりが返ってきて比較できません。

ステップ2. 必要な情報を揃える

見積もりを依頼する前に、次を用意します。揃っているほど見積もりの精度が上がり、着手も早くなります。

・テスト対象の概要（サービス内容、主要機能、想定ユーザー）・仕様書、画面設計書、または操作できる検証環境・対応ブラウザ・OS・端末の一覧・既存のテストケース（あれば）・希望する期間とリリース予定日・使用するバグ管理ツール（Jira、Backlog、Notion、スプレッドシートなど）

ステップ3. 複数社・複数名に見積もりを依頼する

最低でも2件から3件は取ります。金額だけでなく、含まれる作業範囲の粒度まで比較します。

ステップ4. 契約形態と合格条件を決める

請負にするか準委任にするか、何をもって完了とするか、バグが何件残っていたら合格なのか。この記事の後半で詳しく扱う部分です。ここを飛ばして着手すると、必ず最後にもめます。

ステップ5. キックオフとテスト計画の合意

テスト範囲、優先順位、スケジュール、バグ報告のフォーマット、連絡手段と頻度を握ります。テストケース一覧を先に出してもらい、発注者側がレビューして合意してから実行に入るのが安全です。

ステップ6. テスト実行と日次または週次の共有

進捗（実行済みケース数、消化率、発見バグ数）を定期的に共有してもらいます。終盤で一気に報告されると、修正の時間が足りなくなります。

ステップ7. 納品と検収

テスト結果一覧、バグレポート、テスト完了報告書を受け取り、事前に合意した合格基準に照らして合否を判定します。

そのままコピーして使える見積もり依頼メールの例文

初回の問い合わせで情報が足りないと、往復が増えて着手が遅れます。次の文面を自社の内容に差し替えてお使いください。

件名：QAテスト業務のお見積もり依頼（Webサービス／実行工程）

○○様

はじめまして。株式会社△△の□□と申します。
弊社で運営しているWebサービスのQAテストについて、
外部委託を検討しており、お見積もりをお願いしたくご連絡いたしました。

■ テスト対象
・サービス名：（サービス名／URL）
・種別：ブラウザ向けWebアプリケーション
・主要機能：会員登録、ログイン、商品検索、カート、決済、管理画面
・画面数：約40画面

■ 依頼したい工程
・テストケース作成（既存ケースなし。仕様書からの作成をお願いします）
・テスト実行
・バグ報告（Backlogへの起票）
・修正後の再確認テスト（1巡分）
※テスト計画の策定は弊社側で行います。

■ 対応環境
・Google Chrome（Windows／macOS 各最新版）
・Safari（macOS／iOS 最新版）
・Android Chrome（最新版）

■ 提供できるもの
・機能仕様書（PDF、約60ページ）
・検証環境およびテスト用アカウント
・Backlogのアカウント

■ 希望スケジュール
・着手希望：2026年○月○日
・テスト完了希望：2026年○月○日
・リリース予定：2026年○月○日

■ 契約条件
・契約形態：準委任契約を想定（ご提案があればご相談させてください）
・秘密保持契約の締結をお願いしております

■ お見積もりでお知らせいただきたい事項
1. 総額および内訳（工程別の工数と単価）
2. 想定されるテストケース件数
3. 稼働体制（担当人数、週あたりの稼働見込み）
4. 成果物の一覧と提出形式
5. 再テストの対応範囲（何巡まで見積もりに含まれるか）
6. 類似案件のご実績とバグレポートのサンプル

お手数をおかけしますが、○月○日までにご回答いただけますと幸いです。
不明点がございましたらお気軽にお問い合わせください。

よろしくお願いいたします。

株式会社△△
□□ □□
メール：
電話：

このメールのポイントは、5番目の「再テストの対応範囲」と6番目の「バグレポートのサンプル」です。この2つを最初に聞いておくだけで、後述するトラブルの大半を予防できます。

発注前に決めておくこと。検収と合格条件の設計

ここからが、外注実務で最ももめやすい領域です。QAテストの外注では「テストが完了した」という状態の定義が曖昧になりがちで、そこが検収の紛争に直結します。

ソフトウェア開発の外注では「完成したシステムを納品する」というゴールが分かりやすい一方、テスト業務の委託では、バグを100件見つけたら完了なのか、それとも仕様書に書かれたテストケースを全て実行したら完了なのかが判然としません。この基準が発注前に合意されていないと、検収の段階で「まだテストが甘い」「いや、契約範囲は全部実施した」という水掛け論になります。

システム開発の委託契約実務においては、この種の紛争は珍しくありません。

ベンダの報酬請求権は，ベンダが請負契約の目的物であるシステムを完成させ，完成したシステムをユーザに引き渡したときに発生します（民法633条本文）。多くの開発委託契約では，納品とともにユーザが検査を行い，その検査に合格したとき（検収合格ともいいます。）に納入物の引き渡しが完了することとされています。この場合には検収合格により報酬請求権が発生します。出典: it-houmu.com

つまり「検収」という手続きは、単なる社内チェックではなく、報酬支払いの発生条件そのものです。QAテスターへの委託でも同じ構造が当てはまるため、検収の基準を曖昧にしたまま契約すると、支払いのタイミングそのものが宙に浮いてしまいます。

そもそも「検収」とは何を指すのか

検収とは、発注者が納品物を受け取った後、それが契約で定めた内容・水準を満たしているかを検査し、合格・不合格を判定する手続きのことです。QAテスターへの委託で言えば、テスターが提出する「テストケース実行結果」「バグレポート」「テスト完了報告書」といった成果物が、事前に合意した基準を満たしているかを発注者側が確認する工程にあたります。

検収の考え方は、委託の契約形態によって大きく変わります。ここが多くの発注者が最初につまずくポイントです。

請負契約と準委任契約で検収の扱いが違う

QAテスターへの委託契約は、大きく「請負契約」と「準委任契約」のどちらかで結ばれます。この違いを理解しないまま契約書を作ると、検収の主張が通らなくなることがあります。

請負契約は「仕事の完成」を約束する契約です。テストの完了という成果物の完成に対して報酬を支払う形になるため、検収というプロセスがそのまま馴染みます。発注者は納品されたテスト結果を検査し、合格すれば報酬を支払う義務が生じ、不合格であれば修正を求めることができます。

準委任契約は「業務の遂行」自体を約束する契約で、成果物の完成そのものは契約の目的になりません。テスターが定められた稼働時間や工数の範囲で誠実にテスト業務を行えば、その時点で契約上の義務は果たされたことになります。この場合、法律上は検収という手続きは必須ではありません。

準委任契約は検収が不要であるのに対し、同じく業務委託契約の一種である請負契約では検収が求められます。出典: biz.moneyforward.com

ただし実務上は、準委任契約であっても発注者側が「テスト業務が契約通りに行われたか」を確認したいという要望は自然にあります。そのため多くの現場では、準委任契約であっても契約書や業務委託仕様書のなかに「検収に準じる確認プロセス」を任意で盛り込むケースが一般的です。法的な義務ではなくても、実務上の安心材料として確認工程を設けておくべきだということです。

どちらを選ぶかの実務的な目安は次のとおりです。

判断材料	請負契約が向く	準委任契約が向く
依頼範囲	テストケース作成など成果物が明確	期間中のテスト業務全般
期間	単発、短期	継続、月額
仕様の確定度	仕様が固まっている	開発と並走し仕様が動く
支払い条件	検収合格後に一括	稼働時間や月額で定期
発注者の関与	少なくて済む	日々の優先度指示が必要

QAテスターへの委託を検討する際は、まず自分が結ぼうとしている契約が請負なのか準委任なのかを明確にし、そのうえで検収の要否と手続きを契約書に明記することが出発点になります。

合格条件をどう設計するか

検収でもっとも揉めやすいのが「何をもって合格とするか」の基準です。ここを曖昧にしたまま発注してしまうと、テスターは「契約範囲の作業は終えた」と主張し、発注者は「まだバグが残っているから不合格だ」と主張する、典型的な平行線に陥ります。

バグ件数を基準にするのは危険

「バグをゼロにすること」を合格条件にしたいという発注者の気持ちはよく分かります。しかし、これは現実的な基準として機能しにくいという点は押さえておく必要があります。

ソフトウェアには「バグがゼロである」ことを証明する方法が原理的に存在しません。テスターがどれだけ網羅的にテストしても、テストケースに含まれていない操作パターンや、特定の環境でしか再現しない不具合は発見できない可能性が残ります。「バグゼロ」を合格条件にすると、テスターは無限に責任を負わされる立場になり、まともな契約が成立しません。

代わりに実務でよく使われるのが、以下のような多段階の基準です。

・重大度（Critical / High / Medium / Low）ごとにバグの残存許容件数を分けて定義する・「事前に合意したテストケースを100%実行し、その実行結果と発見バグの一覧を提出すること」を成果物の完了条件にする・Critical・Highレベルのバグは全件修正確認まで含めて検収対象とし、Medium・Lowレベルは別途改修計画を合意すれば合格とする

例えば「重大度Highのバグは0件、Mediumは3件以内であれば合格」といった数値基準を契約前に握っておくと、検収時の判断がぶれません。

重大度の判定基準を具体例つきで定義する

重大度の定義そのものが、発注者とテスターの間で認識の食い違う最大のポイントです。「これはHighでしょう」「いやMediumです」という応酬を避けるため、抽象的な言葉ではなく具体例を添えて定義します。次の表をそのまま契約別紙に貼って使えます。

重大度	定義	具体例	対応方針
Critical	サービス全体が停止する、データが破損する、金銭や個人情報の実害が出る	ログインできない、決済が二重に走る、他人の個人情報が表示される、注文データが消える	即時修正。1件でも残っていれば不合格
High	主要機能が使えない。回避手段がない、または著しく困難	カートに商品を追加できない、管理画面から商品を登録できない、特定ブラウザで画面が真っ白になる	全件修正のうえ再確認。残存0件が合格条件
Medium	主要機能は使えるが不便。回避手段がある	検索結果の並び順が仕様と違う、エラーメッセージが不親切、入力値が保持されない	許容件数を定めて合格判定（例：3件以内）
Low	業務影響がほぼない。見た目や表記の問題	ボタンの余白が数ピクセルずれる、文言の表記ゆれ、スクロール時の軽微なちらつき	改修計画に載せれば合格。件数制限なし

この表を発注前に相手と読み合わせ、判断に迷った事例が出たら都度追記していくと、案件を重ねるごとに精度が上がります。

なお、重大度と優先度を分けて管理する運用もあります。重大度は「不具合そのものの深刻さ」、優先度は「いつ直すか」です。表示崩れ（重大度Low）でもトップページの目立つ場所なら優先度は高い、という判断があり得ます。テスターに起票してもらうのは重大度まで、優先度は発注者側が決める、と役割を分けておくと混乱しません。

合格基準の記載例

契約別紙にそのまま書ける文例です。

【合格基準】
本業務の検収は、次の各号をすべて満たしたときに合格とする。
(1) 別紙1「テストケース一覧」に定めるテストケースの実行率が100%であること。
    ただし、環境要因等により実行不能となったケースについては、
    その理由を書面で報告し、甲の承認を得た場合は実行済みとみなす。
(2) 重大度Criticalおよび重大度Highに区分される不具合の残存件数が0件であること。
(3) 重大度Mediumに区分される不具合の残存件数が3件以下であり、
    かつ残存する各不具合について甲乙間で改修方針の合意がなされていること。
(4) 重大度Lowに区分される不具合について、一覧および再現手順が提出されていること。
(5) 別紙2「成果物一覧」に定める成果物がすべて提出されていること。

「完了」の定義を仕様書レベルで明文化する

もう一つ重要なのが「テストの完了」をどう定義するかです。これは検収仕様書、あるいはテスト計画書と呼ばれる文書に落とし込むのが最も確実な方法です。

検収仕様書等の記載事項に沿ってシステムなどを制作しなければ、検収段階で不合格となり、修正や納品のやり直しが生じてしまいます。受注者としては、検収仕様書等の記載事項をあらかじめよく確認して、その内容に忠実に納品物を制作することが大切です。実際の開発担当者（開発者）に対しても、検収仕様書等の内容の遵守を徹底させましょう。検収仕様書等の内容に疑義がある場合には、受注の段階で発注者に確認して解消しておきましょう。また、制作途中で疑義が生じた場合にも、その都度発注者に確認して疑問点を解消すべきです。出典: corporate.vbest.jp

この考え方はシステム開発の受託者向けに書かれたものですが、QAテスターへの委託を検討する発注者側にとっても示唆に富みます。つまり、検収でもめる根本原因の多くは「発注時点で仕様（この場合はテスト範囲・合格基準）が具体的に文書化されていなかったこと」にあります。口頭やチャットでの合意だけに頼らず、以下の項目は必ず書面（検収仕様書や業務委託契約の別紙）に落とし込んでおくべきです。

・テスト対象の範囲（画面・機能・API・対応ブラウザやOSのバージョンなど）・使用するテスト手法（探索的テスト、シナリオテスト、リグレッションテストなど）・テストケース数の目安、またはテスト工数の上限・バグの重大度分類とその判定基準・合格基準（残存バグの重大度別許容件数）・検収期間（納品後何営業日以内に検収結果を通知するか）・不合格時の再修正・再テストの回数と追加費用の有無

これだけの項目を並べると身構えてしまうかもしれませんが、実際にはテンプレートを一度作ってしまえば、次回以降の発注では流用できます。最初の1回に時間をかける価値は十分にあります。

発注前チェックリスト

発注ボタンを押す前に、次の項目に全部チェックが入るかを確認してください。ひとつでも空欄があれば、そこが後日の紛争ポイントになります。

【対象と範囲】・テスト対象の画面・機能を一覧化したか・対応ブラウザ・OS・端末のバージョンまで指定したか・テスト対象外の範囲を明記したか（決済の本番実行は行わない、など）

【成果物】・提出してもらう成果物の名称と形式を決めたか（テスト結果一覧はスプレッドシート、報告書はPDF、など）・バグレポートのフォーマットを指定したか・中間報告の頻度と形式を決めたか

【契約】・請負か準委任かを決めたか・報酬の支払時期と条件（検収合格後何日以内か）を決めたか・秘密保持契約を締結したか・成果物の著作権や、テストケースの二次利用可否を定めたか・再テストの回数と、超過時の追加費用を定めたか

【判定】・重大度の判定基準を具体例つきで共有したか・合格基準（重大度別の残存許容件数）を数値で決めたか・検収の最終判断者を1名に決めたか・検収期間と、期間経過時の扱い（みなし合格の有無）を決めたか

【環境】・検証環境とテストアカウントを用意したか・テストデータの準備担当を決めたか・環境が落ちたときの連絡先と復旧責任者を決めたか

バグレポートのフォーマットを最初に渡す

バグレポートの粒度が揃わないと、開発側が再現できず修正が止まります。フォーマットは発注者側から先に提示するのが鉄則です。次の項目を必須にしておけば、まず困りません。

項目	記載内容	記入例
ID	通し番号	BUG-0042
件名	現象を一文で	カート画面で数量を0にすると合計金額がマイナスになる
重大度	Critical / High / Medium / Low	High
発生環境	OS、ブラウザ、バージョン、端末	macOS 15.2 / Chrome 132.0 / MacBook Air M2
対象URL	発生した画面	https://stg.example.com/cart
アカウント	使用したテストアカウント	test_user_03
前提条件	再現に必要な事前状態	商品Aを1点カートに入れた状態
再現手順	番号付きで1操作1行	1. カート画面を開く 2. 数量欄に0を入力 3. 更新ボタンを押す
期待結果	仕様上どうあるべきか	数量0は入力エラーとなり、合計金額は変わらない
実際の結果	何が起きたか	合計金額が「-1,200円」と表示される
再現性	常に / 時々（回数）	常に（5回中5回）
証跡	スクリーンショット、動画、ログ	screenshot_0042.png
発見日時	いつ見つけたか	2026年○月○日 14:20

「再現性」の欄は軽視されがちですが、外注では特に重要です。5回中1回しか出ない不具合と、必ず出る不具合では、修正の優先度も調査コストもまったく違います。この欄がないフォーマットを使っている外注先には、追加をお願いしてください。

検収期間が過ぎた場合の扱いにも注意する

検収でもう一つ見落とされがちなのが「検収期間」の設定です。納品されたテスト結果をいつまでに確認し、合否を通知するかという期限を契約書に明記していない発注者は少なくありません。

検収期間を定めずに放置してしまうと、発注者側の都合でいつまでも検収が完了しない状態が続き、テスター側の報酬支払いも先延ばしになってしまいます。これはテスター側にとって大きな負担であると同時に、発注者側にとっても「検収期間内に何も通知しなければみなし合格になる」という規定が契約書にある場合、うっかり確認を怠ってバグの残った成果物をそのまま受け入れてしまうリスクにつながります。

一般的な実務では、検収期間は納品後5営業日から2週間程度で設定されることが多いです。テスト対象の規模が大きい場合はもう少し長く取ることもありますが、いずれにせよ「いつまでに」「誰が」「どのような方法で」合否を通知するかを契約書に明記しておくことが、双方にとっての安全策になります。

業務委託契約書に入れる検収条項の例文

契約書に落とし込むときの文例です。甲を発注者、乙を受託者としています。自社の法務や顧問弁護士の確認を経たうえでご利用ください。

第○条（納品および検収）
1. 乙は、個別契約に定める納期までに、別紙2「成果物一覧」に定める
   成果物を甲の指定する方法により甲に提出するものとする。
2. 甲は、前項の提出を受けた日から10営業日以内（以下「検収期間」という）に、
   別紙3「合格基準」に従い検査を行い、その合否を書面または電子メールにより
   乙に通知するものとする。
3. 甲が検収期間内に前項の通知を行わない場合、当該成果物は
   検収期間の満了をもって合格したものとみなす。
4. 甲が不合格と判定した場合、甲は不合格と判断した具体的な理由および
   該当箇所を明示して乙に通知するものとし、乙は通知を受けた日から
   5営業日以内に無償で修補のうえ再提出するものとする。
   再提出後の検収については前2項を準用する。
5. 前項に定める無償の修補は2回を上限とし、これを超える対応、
   および甲の仕様変更に起因する修補については、
   甲乙協議のうえ別途費用および納期を定めるものとする。
6. 検収に合格した時点をもって、成果物の引渡しが完了したものとする。

第○条（再テストの範囲）
1. 乙は、甲またはその指定する開発者が行った不具合の修補について、
   当該不具合の再現確認を1巡分、本契約の範囲内で実施するものとする。
2. 前項の再現確認に伴い必要となるリグレッションテストの範囲は、
   別紙1「テストケース一覧」のうち甲乙が別途合意した範囲に限るものとする。
3. 前2項の範囲を超える再テストが必要となった場合の費用および期間は、
   甲乙協議のうえ定める。

第○条（検収責任者）
1. 甲は、本契約に基づく検収の合否を判断する責任者1名を定め、
   契約締結時に乙に通知するものとする。
2. 検収に関する乙への指示は、前項の責任者を通じて行うものとし、
   甲の他の従業員等による指示は、本契約上の指示としての効力を有しない。
3. 責任者を変更する場合、甲は速やかに乙に書面により通知するものとする。

第4項の「不合格と判断した具体的な理由および該当箇所を明示して」という一文と、第5項の修補回数の上限は、必ず入れてください。理由を明示しない不合格通知は無限のやり直しを招き、回数上限がない修補義務は受託者側が受けられない条件になります。結果として、まともなテスターほど契約を断るようになります。

QAテスト外注でよくあるトラブルとその回避策

実際の現場で起きやすいトラブルのパターンを整理しておきます。事前に知っておくだけで、多くは回避可能です。

トラブル1：テストケースの解釈がずれる

発注者が想定していたテスト範囲と、テスターが実際に実施したテスト範囲が食い違うケースです。「基本機能は当然テストするだろう」という発注者側の思い込みと、「明示された仕様書の範囲だけをテストする」というテスター側の受け止め方がずれることで発生します。対策は、テストケース一覧を事前にレビューし、双方が合意したうえで着手してもらうことです。

トラブル2：バグの再現手順が不十分で修正側が対応できない

テスターが発見したバグの報告に、再現手順・環境情報・スクリーンショットが不足していると、開発側が修正できず検収が進みません。前掲のバグレポートのフォーマットをあらかじめ指定しておくことで防げます。

トラブル3：修正後の再テスト範囲でもめる

一度バグを指摘して修正してもらった後、その修正が別の機能に影響していないかを確認する「リグレッションテスト」の範囲について、追加費用が発生するのか、当初の契約範囲に含まれるのかで対立するケースです。契約時点で「軽微な修正後の再テストは1回まで契約範囲に含む」など、再テストの回数と範囲をあらかじめ定義しておくと安心です。

トラブル4：検収の合否判断者が曖昧

発注者側の担当者が複数いる場合、誰が最終的な合否判断を下すのかが不明確だと、テスター側は誰の指摘に従えばよいのか分からなくなります。検収の責任者を1名に明確化し、その人物の承認をもって正式な合格とするフローを決めておくべきです。

私自身、自分が運営するオンラインカウンセリングの予約システムを外部に発注した際、この「合否判断者の曖昧さ」で苦労した経験があります。私と業務パートナーの二人がそれぞれ別のタイミングで別の指摘をテスターに伝えてしまい、テスター側から「どちらの指摘を優先すればよいか分からない」と困惑された連絡を受けました。窓口を一本化していなかった自分のミスだと反省し、以降は必ず検収の最終判断者を1人に決めてから発注するようにしています。小さなことのようですが、これだけで進行のスムーズさがまるで違います。

トラブル5：検証環境が使えずテストが止まる

外注先が着手した初日に検証環境が落ちていた、テストデータが古くて操作できない、アカウントの権限が足りない。これらは発注者側の準備不足で起きる典型的な事故です。準委任契約なら、待機している時間も稼働時間として費用が発生します。着手前日までに、外注先と同じ手順で自分でも一度ログインして動かしてみてください。

トラブル6：仕様が確定しないまま並走して手戻りが出る

開発と並走してテストを進める場合、仕様変更のたびにテストケースの書き直しが発生します。この作り直しを「当然含まれている」と思っている発注者と、「追加作業」と考える受託者で衝突します。仕様が動く前提の案件なら、最初から準委任契約にして、テストケースの改訂も稼働時間の中で行う建て付けにするのが合理的です。

トラブル7：バグの起票が多すぎて開発が回らない

第三者検証を入れると、初回は想定を超える件数のバグが起票されることがあります。これ自体は外注が機能している証拠ですが、修正のキャパシティを超えると開発が止まります。対策は、着手時に「Critical と High は発見次第すぐ連絡、Medium 以下は日次でまとめて共有」という報告ルールを決めておくことです。

失敗しないQAテスターの選び方

検収でトラブルを起こさないためには、そもそも発注前の選定段階で見極めるべきポイントがあります。

第一に、過去の実績で扱った対象領域を確認することです。Webアプリケーションのテスト経験が豊富なテスターと、組み込み機器のテスト経験が豊富なテスターでは、得意とする観点がまったく異なります。自社のテスト対象と近い領域での経験があるかを確認しましょう。

第二に、バグレポートのサンプルを事前に見せてもらうことです。過去にどのようなフォーマットでバグを報告していたかを確認すれば、コミュニケーションの精度をある程度事前に判断できます。再現手順が具体的か、重大度の判断基準が明確かをチェックしてください。

第三に、テストケースの設計を任せられるかどうかです。既存のテストケースを実行するだけのテスターと、要件からテストケースを設計できるテスターとでは、スキルレベルも報酬水準も異なります。自社の状況（すでにテストケースがあるのか、ゼロから設計してほしいのか）に応じて、必要なスキルを持つ人材を選定する必要があります。

第四に、見積もりの内訳を必ず比較することです。私が初めて外部のQAテスターに発注しようとしたとき、複数の見積もりを取らずに最初に連絡が来た1社の提示額だけで即決してしまい、後になって別の候補者がほぼ同じ内容をより明確なテストケース設計込みで提示していたことを知りました。金額だけでなく、見積もりに含まれる作業範囲の粒度まで比較しないと、安いように見えて実は必要な工程が抜けている、ということが起こり得ます。以来、最低でも2件から3件は見積もりを取り、金額と作業範囲の両方を突き合わせるようにしています。

第五に、質問の質を見ることです。見積もり依頼に対して「対応ブラウザのバージョンはどこまでですか」「決済は本番環境での実行を含みますか」「既存の不具合は起票対象に含めますか」といった具体的な確認を返してくる相手は、実務経験があります。逆に、こちらの情報だけで即座に金額を出してくる相手は、後から「それは範囲外です」と言い出す可能性が高いと考えてください。

選定時に必ず聞く5つの質問

・類似領域（Webサービス、業務システム、モバイルアプリなど）での実績を教えてください・バグレポートのサンプルを1件見せていただけますか（機密部分はマスキングで構いません）・テストケースの設計から対応できますか。その場合の追加費用はいくらですか・再テストは何巡分まで見積もりに含まれていますか・稼働が止まる可能性のある予定（他案件、長期休暇など）はありますか

運営者の視点から見えるQAテスト外注の実態

フリーランス・在宅ワーク市場を長く運営してきた立場から見ていると、QAテスターとして継続的に案件を受けている人ほど、単発のテスト実行だけで終わらせず、発注者側の「合格条件をどう決めればよいか分からない」という不安に寄り添う提案をしていることに気づきます。バグレポートのテンプレートを自分から提示したり、テスト範囲の切り分け方を発注前に一緒に整理したりするテスターは、次の案件でも指名される傾向が強い。技術力だけでなく、検収という手続きを発注者と一緒に設計できる姿勢が、継続発注につながっているように見えます。

発注者の側から見ると、これは選定の判断材料になります。募集に対して「テストケースをいただければ実行します」とだけ返してくる人と、「まず対象範囲と合格基準の擦り合わせをさせてください」と提案してくる人。後者を選んだ案件のほうが、検収でもめたという相談はほとんど届きません。

もう一つ運営者として見えてきたのは、中間マージンが乗らない直接契約の構造が、発注者とテスターの双方に無理のない関係を作りやすいという点です。仲介会社を通した契約では、発注者が支払う金額とテスターの手取りの差が大きくなりがちで、その差額分を埋め合わせるために、どうしても検収の基準や修正対応の範囲がシビアになりやすい傾向があります。一方、直接契約で手取りが厚い状態であれば、テスター側にも「多少の追加確認には応じよう」という余裕が生まれやすく、結果として検収のやり取りも柔らかくなる。金額の大小だけでなく、その予算がどう配分されているかという構造が、実務の摩擦の少なさに直結しているというのが、長く現場を見てきた実感です。

そしてもう一点。QAテストの外注は、一度きりで終わらせるより、同じ相手に継続して依頼したほうが確実に費用対効果が上がります。プロダクトの仕様やクセを理解している人が2回目、3回目のテストを担当すると、キャッチアップの時間がゼロになり、同じ予算で回せるテスト範囲が広がるからです。初回だけを見て「思ったより高い」と判断してしまうのはもったいない。初回はキャッチアップ込みの費用、2回目以降が本来のランニングコスト、という見方をしてください。

契約実務を進めるうえでの参考情報

QAテスターへの委託を含め、業務委託契約全般で押さえておくべき基本事項をまとめたチェックリストとしては、業務委託契約書テンプレート｜発注者向けチェックリスト付き【2026年版】が参考になります。検収条項や合格基準の記載例など、契約書に落とし込む際の実務的なひな型を確認できます。

また、テストだけでなく開発工程全体を外部に委託することを検討している場合は、アプリケーション開発のお仕事のガイドで、開発フェーズごとにどのような外注の切り分け方があるかを把握しておくと、QAテスターを単独で発注すべきか、開発とテストをまとめて依頼すべきかの判断がしやすくなります。

マーケティングや広告運用など他の業務領域を外注する際の費用感と比較したい場合は、マーケティング業務委託の費用相場｜代理店vs個人フリーランス比較でも、代理店経由と個人フリーランス直接依頼のコスト差について解説しています。QAテスターの委託と同様に、仲介の有無が費用構造に与える影響という点で共通する考え方が確認できます。

QAテスター自身の年収・単価相場を把握しておきたい発注者の方は、近しい職種としてソフトウェア作成者の年収・単価相場のデータも参考になります。開発側の相場感を知っておくことで、テスト工程に妥当な予算を割り当てる判断材料になります。

QAテストの外注は、工程を切り分けて依頼先を選び、合格条件と検収の手続きを先に決めておけば、決して難しい発注ではありません。外注できる工程の一覧から自社が出す範囲を決め、費用相場を目安に予算を取り、依頼先3タイプから対象規模に合う相手を選ぶ。そして発注前に、重大度の判定基準、残存バグの許容件数、検収期間、再テストの回数、この4つを文書に落とす。ここまでやっておけば、「言った言わない」の紛争はほぼ起きません。最初の1回にテンプレートを作る手間をかけておくと、2回目以降の発注は驚くほど軽くなります。