LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

テスト自動化外注とは何か

テスト自動化外注とは、E2E（エンドツーエンド）テスト・回帰テスト・負荷テストといった反復的なテスト工程をスクリプト化し、その基盤構築・運用を外部の専門パートナーに委託する取り組みです。手動テストを外注する体制構築とは異なり、「テストコード」を資産として蓄積しCI/CD（継続的インテグレーション／継続的デリバリー）パイプラインに組み込むことが目的となります。

手動テスト外注との根本的な違い

手動テスト外注では「人が画面を操作してバグを探す」工数を外注します。一方、テスト自動化外注では「再現性のあるテストスクリプト」という資産をどう設計・管理するかが中心です。スクリプトはコードであるため、保守・更新・CI連携といったエンジニアリング的な観点が求められます。

自動化基盤の構築には、テスト設計の知識だけでなく、対象アプリのアーキテクチャ理解・テストフレームワークの習熟・CI/CDパイプラインの設定スキルが必要です。これらをすべて内製で揃えるのが難しい場合に、外注による基盤構築が選択肢として浮上します。

テスト自動化外注の主な目的

開発組織がテスト自動化を外注する目的は、大きく3つに整理できます。第一に、スプリントごとの回帰テストを自動化してリリース速度を上げることです。第二に、E2Eテストスクリプトの初期構築を外注し、その後は自社開発者が保守する体制を作ることです。第三に、負荷テスト・パフォーマンステストを専門ツールで実施し、キャパシティプランニングに活かすことです。

自動化すべきテスト対象の優先順位

テスト自動化のスコープを決める際、「全部自動化しよう」という方針では費用対効果が出にくいです。自動化に向くテスト種別と手動向きの工程を整理し、優先順位を明確にすることが外注仕様の出発点になります。

自動化に向くテスト種別と手動が適切な工程

「仕様が固まっている機能」から着手することの重要性

スクリプトは「仕様変更のたびに更新が必要なコード」です。開発初期で仕様が揺れている機能に自動化テストを組むと、スクリプト保守コストがテストコストを上回る逆転現象が起きます。

外注で自動化基盤を構築する際は、リリース済み・仕様が安定している機能（ログイン・認証・コア購入フローなど）を最初のターゲットに設定するのが実務的な進め方です。仕様が確定していない開発中の機能は、一定の安定度が出てから追加する段階的なアプローチをお勧めします。

主要ツールの位置づけ — Selenium・Playwright・Cypress・Appium

テスト自動化の外注先を評価する際に、どのツールを使えるかは外注仕様の中心になります。主要ツールの特徴と適切な使い分けを理解することで、外注先の提案を適切に評価できます。

Selenium — 実績最長の多言語対応フレームワーク

Selenium（セレニウム）は、Selenium WebDriver・Selenium IDE・Selenium Gridの3コンポーネントで構成されるオープンソースのブラウザ自動化フレームワークです（Selenium公式サイト）。Java・Python・C#・Rubyなど複数言語に対応しており、既存の開発チームが慣れた言語でテストを書けるのが特徴です。

Selenium Gridを使えば、複数のブラウザ・OS環境で並列テストを実行できます。ただし、セットアップの手間や非同期処理のウェイト設定がPlaywright・Cypressより複雑になる傾向があります。既存のSeleniumスクリプト資産がある場合はそのまま活用でき、外注先の保守対応を求める際に最も実績のある選択肢です。

Playwright — モダンWebアプリ向けの信頼性の高い自動化

Playwright（プレイライト）は、Microsoftが開発・維持するオープンソースのE2Eテストフレームワークです（Playwright公式サイト）。Chromium・Firefox・WebKitの3ブラウザを統一APIで制御でき、ヘッドレス・ヘッド両モードに対応しています。

自動待機（Auto-waiting）機能により、要素が表示されるまで自動でウェイトを挿入するため、非同期処理への対処がSeleniumより簡潔に書けます。テスト分離やコンテキスト管理の設計が洗練されており、新規に自動化基盤を構築する場合に現時点で広く選ばれているフレームワークです。

Cypress — JavaScript環境に特化したデバッグ性の高いツール

Cypress（サイプレス）は、JavaScriptアプリケーションのE2Eテストに特化したフレームワークです（Cypress公式サイト）。GitHubでのスター数が49,000以上（2026年6月時点）あり、フロントエンド開発者コミュニティで広く採用されています。

ブラウザ内でテストが直接実行されるため、デバッグ時のフィードバックが速いのが特徴です。Cypress Cloudを使ったCI/CD並列実行にも対応しており、GitHub Actions・CircleCIなどとの統合が充実しています。JavaScriptスタックのフロントエンド重視のプロジェクトに向いています。

Appium — モバイルアプリのUIテスト専用フレームワーク

Appium（アピウム）は、iOS・Android・デスクトップアプリのUIテストを自動化するオープンソースフレームワークです（Appium公式ドキュメント）。モバイル（iOS/Android）・ブラウザ（Chrome/Firefox/Safari）・デスクトップ（macOS/Windows）と幅広いプラットフォームに対応しています。

ネイティブアプリ・ハイブリッドアプリ・Webビューアプリを対象にしたUIテストが可能です。iOSアプリにはXCUITest、AndroidにはUIAutomator2が内部で使われており、実機・エミュレーター両方のテストに対応しています。モバイルアプリを持つプロジェクトでSelenium/Playwrightと組み合わせて使われるケースが多いです。

ツール選定の判断フロー

ツール選定は外注先に委ねるのではなく、自社側でプロジェクトの技術スタック・チームスキルを踏まえて方針を決定することが大切です。外注先が得意なツールに合わせて要件側を変えると、将来的な保守・引き継ぎ時に問題が生じます。

CI/CD連携と自動化基盤の構築ステップ

テスト自動化を「ただスクリプトを書く作業」にしないためには、CI/CD（継続的インテグレーション／継続的デリバリー）パイプラインへの組み込みが不可欠です。CI/CDとは、コードの変更をリポジトリに反映するたびにビルド・テスト・デプロイを自動で実行する仕組みです。

自動化基盤の構築フェーズと外注スコープの定義

外注で自動化基盤を構築する際は、以下の4フェーズで進めることをお勧めします。フェーズごとに成果物を定義し、外注先への委託範囲を明確にすることが重要です。

フェーズ1：テスト環境とリポジトリの整備
テストコードを管理するGitリポジトリを作成し、テストフレームワークのインストール・設定ファイルの初期化を行います。この段階で「テストコードのフォルダ構成・命名規則・レビュールール」を自社開発チームと合意しておくことが大切です。

フェーズ2：優先シナリオのスクリプト実装
対象選定で洗い出した優先度の高いシナリオから順番にスクリプトを実装します。外注先には「実装したスクリプトのPRレビューをGitHub上で行う」契約を盛り込むことで、スクリプト品質を自社側が確認できます。

フェーズ3：CI/CDパイプラインへの組み込み
GitHub Actions（GitHub Actions公式ドキュメント）・Jenkins・CircleCIなどのCIツールにテスト実行ステップを追加します。プルリクエスト時・マージ時・定期実行の3タイミングでテストが走る構成を設計します。

フェーズ4：テスト結果のレポーティングと失敗通知設定
テスト結果をSlack・Jira・メール等で通知する仕組みを整備します。テスト失敗時に担当者が即時把握できる体制があることで、自動化テストが開発フローに定着します。

フレークなテスト（不安定テスト）の管理方針を事前に決める

テスト自動化で現場がよく直面する課題が「フレーキネス」（flakiness）です。これは、同じスクリプトが実行するタイミングによって合格・不合格の結果がばらつく状態を指します。フレークなテストが増えると、テスト結果への信頼が落ちてスキップされるようになり、自動化基盤が形骸化します。

外注先に対して「フレークなテストの件数・対応方針を週次レポートに含める」ことを成果物定義に加えておくと、基盤の品質劣化を早期に把握できます。Cypress・Playwrightどちらも不安定テストの検出機能を持っており、外注先がこれを活用しているかどうかは評価のポイントになります。

外注費用の考え方と契約形態の選択

テスト自動化外注の費用は、「基盤構築フェーズ」と「保守・拡張フェーズ」で性格が異なります。以下は市場参考値であり、一次資料に基づく確定値ではありません。実際の発注前に複数社への見積もり取得をお勧めします。

基盤構築フェーズの費用構造

初期の自動化基盤構築（テスト環境整備・優先シナリオ30〜50件程度のスクリプト実装・CI/CD連携）は、プロジェクト型の請負で受ける外注先の場合、規模・複雑さによって数百万円の幅があります（市場参考値・一次資料非確認）。自動化エンジニアを準委任で参画させる場合は、月額80〜120万円前後が目安とされています（市場参考値・一次資料非確認）。

ツール自体（Playwright・Selenium・Cypress）はオープンソースで無料で利用できます。ただし、Cypress Cloudのような商用クラウドサービスを使う場合は別途ライセンス費用が発生します。費用見積もりに「ツール・サービスのライセンスコスト」が含まれているかを確認することが大切です。

保守・拡張フェーズの費用構造

基盤構築後の保守フェーズでは、機能追加に伴うスクリプト更新・フレークなテストの修正・CIパイプラインの調整が継続的に発生します。保守フェーズを外注継続する場合は準委任が向いており、月単位で工数を確保する契約形態が一般的です。

一方、保守を内製に移管する場合は、外注先からのドキュメント引き渡し・社内エンジニアへのハンズオン研修を契約に含めることで、移管後のコストを抑えられます。この点については、次章で詳しく解説します。

※上記はすべて市場参考値です。一次資料（公的統計・業界調査）による確定値ではありません。

外注先の選定基準 — 3つの評価軸

テスト自動化の外注先は、手動テスト外注と同じ視点で選ぶと失敗します。「テストエンジニア」と「テスト自動化エンジニア（SDET：Software Development Engineer in Test）」はスキルセットが異なり、後者はアプリケーション開発者に近い能力が求められます。

評価軸1：ツール実装力とCI/CD組み込み経験

採用予定のツール（Playwright・Cypress・Seleniumなど）でのスクリプト実装経験があるかを確認します。さらに重要なのは、そのスクリプトをGitHub Actions・Jenkins・CircleCIなどのCIツールに組み込んだ実績があるかです。

提案段階で「過去プロジェクトのCIパイプライン構成図の提示」と「テストスクリプトのコードサンプル」を依頼することで、実力差が明確になります。サンプルコードの可読性・保守性（命名規則・コメント・ページオブジェクトパターンの採用有無など）は、長期的なスクリプト資産の品質を左右します。

評価軸2：スクリプト設計の標準化方針

「ページオブジェクトモデル」（POM：Page Object Model）は、UIテスト自動化のスクリプト設計において広く採用されているデザインパターンです。画面要素の定義とテストロジックを分離することで、UI変更時のスクリプト修正範囲を最小化できます。

外注先がPOMやそれに相当する設計パターンを採用しているかを提案段階で確認してください。パターンを使わずにスクリプトを書き散らすと、保守コストが膨らみ内製移管時に改修が必要になるリスクがあります。

評価軸3：スクリプト著作権と引き渡し条件の明確化

外注で作成したスクリプトの著作権・利用権が自社に帰属するかどうかは、契約書で明示的に定める必要があります。「外注先が保有したまま」の状態で契約が終了すると、スクリプト資産を失うリスクがあります。

契約に盛り込むべき事項は、「スクリプトの著作権の自社帰属」「GitリポジトリへのPush形式での成果物引き渡し」「引き渡し時のドキュメント（環境構築手順書・スクリプト設計書）の提出義務」の3点です。これらを仕様書の成果物定義に明記することが大切です。

内製移管の設計 — スクリプト資産を自社に残す

テスト自動化の外注は、継続的に外注に依存し続けるモデルと、一定期間後に自社エンジニアに運用を移管するモデルの2つが考えられます。後者の内製移管モデルでは、外注フェーズから「移管を前提とした設計」が必要です。

内製移管を前提とした外注設計の要点

移管を前提とした外注を行うには、以下の3点を最初の契約に盛り込んでおくことが重要です。

ドキュメント化の義務付け：スクリプトの設計書・実行手順書・CI/CD設定手順書を成果物として定義します。「コードだけあってドキュメントがない」状態での引き渡しは、移管後の内製エンジニアが大きな学習コストを負うことになります。

ペアプログラミング・ハンズオン研修の組み込み：外注期間の後半（最後の1〜2カ月程度）に、自社エンジニアが外注先のエンジニアとペアで作業する時間を設けます。スクリプトの設計意図・保守手順を直接伝えてもらうことで、移管後の問題発生リスクを抑えられます。

段階的な権限移管：最初は外注先が主担当・自社側がレビュアーという体制を組み、最終フェーズでは自社側が主担当・外注先がメンターという形に段階的に移行します。移管日を「ある日を境に完全切り替え」にするのではなく、3カ月以上かけて徐々に移行する設計をお勧めします。

内製移管が難しいケースと継続外注の選択

自社にテスト自動化を担える開発者がいない場合や、システムの規模・改修頻度が高くスクリプト保守に継続的な工数が必要な場合は、外注継続が現実的な選択肢です。その場合は、外注先をIT保守の元請として位置づけ、自動化基盤の品質・スクリプト増加ペースをKPIとして管理する体制を整えることが大切です。

IPA「ソフトウェア開発分析データ集2022」^*1は5,546件のプロジェクトデータを分析しており、テスト工程への投資水準がプロジェクトの信頼性に影響することを示しています。自動化基盤への投資判断の参考情報として確認することをお勧めします。

まとめ：テスト自動化外注を成功させる3つの判断軸

本稿では、QAテスト自動化を外注で構築する際の実務的な進め方を、対象選定・ツール・CI/CD連携・費用・外注先選定・内製移管の観点から整理しました。要点を3つに集約すると次の通りです。

第一に、自動化対象のスコープ（回帰・E2E・API・負荷）を優先順位付きで定義してから外注仕様を作ること。「全部自動化」という方針では費用対効果が出にくく、外注先の提案評価も困難になります。仕様が固まっている機能から優先的にスクリプト化する段階的アプローチが実務上有効です。

第二に、ツール選定は自社の技術スタック・チームスキルを踏まえて自社側で決定すること。Playwright・Cypress・Selenium・Appiumはそれぞれ適性が異なり、外注先の得意ツールに合わせて技術選定を変えると内製移管時に問題が生じます。CI/CDパイプラインへの組み込み経験を選定の主要評価軸にすることをお勧めします。

第三に、スクリプトの著作権・引き渡し条件・ドキュメント化義務を最初の契約に盛り込むこと。外注完了後にスクリプト資産を自社で活用・保守できるかどうかは、最初の契約設計で決まります。内製移管を前提とする場合は、ハンズオン研修の期間と段階的移行スケジュールを契約に含めてください。

よくある質問

PlaywrightとCypressはどちらを選べばよいですか。

プロジェクトの技術スタックと目的によって異なります。JavaScriptのフロントエンドアプリでデバッグのフィードバック速度を重視する場合はCypressが向いています。TypeScript・Pythonでマルチブラウザ対応が必要な場合や、モバイルWebも含めた広範なE2EテストにはPlaywrightが適しています。どちらもCI/CD連携・並列実行に対応しており、チームの習熟度と既存のCI環境に合わせて判断するのが実務的なアプローチです。

テスト自動化の外注期間はどのくらいが目安ですか。

基盤構築フェーズ（環境整備・優先シナリオのスクリプト実装・CI組み込み）は2〜4カ月程度を見込むケースが多いです（市場参考値・一次資料非確認）。その後、内製移管を前提とする場合はハンズオン期間として1〜2カ月を追加で確保することをお勧めします。スクリプト件数が多い場合や対象システムが複雑な場合は期間が延びます。プロジェクト開始前に「フェーズごとの成果物・期間」を外注先と合意しておくことが大切です。

外注で作ったスクリプトの著作権は自社に帰属しますか。

契約書で明示的に定めない場合、著作権は原則として制作者（外注先）に帰属する可能性があります。外注先がスクリプトを「自社の資産」として保有した場合、契約終了後に使用できなくなるリスクがあります。発注時の契約書に「成果物の著作権は発注者（自社）に譲渡する」旨を明記することが大切です。また、スクリプトのGitリポジトリへのアクセス権・バックアップも自社側で管理できる体制を確認してください。

テスト自動化と手動テストはどのように使い分ければよいですか。

回帰テスト・APIテスト・E2Eの主要フローは自動化が向いており、繰り返し実行するほどコスト優位が出ます。一方、新機能の探索的テスト・UX確認・業務要件の受入テスト（UAT）は人間の判断が必要で手動が向いています。実務上は「自動化が安定している機能には手動テスト工数を減らし、新機能・仕様変更部分には手動テストを集中させる」という使い分けが有効です。自動化テストは「手動テストの補完」として設計することをお勧めします。

テスト自動化基盤の外注先を選ぶ際に確認すべき質問はありますか。

提案段階では次の3点を確認することをお勧めします。①過去プロジェクトでどのCIツール（GitHub Actions・Jenkins等）に自動化テストを組み込んだか、②スクリプトのコードレビューはどのように行うか（PR形式か否か）、③プロジェクト終了時にスクリプト設計書・環境構築手順書を成果物として提出できるか。これらに具体的に答えられる外注先は、スクリプト資産の品質管理に実績があると判断できます。

著者：テレリモ総研編集部　鈴木 亮佑

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IPA（独立行政法人情報処理推進機構）「ソフトウェア開発分析データ集2022」（2022年9月公表、5,546プロジェクトを分析）