AIでテスト自動化はどこまでできる？できること・できないことの線引き

「AIを使えばテストを自動化できるのでは」
そう考えて調べ始めると、期待値の異なる情報が並びます。

全部おまかせでできるように見える宣伝もあります。
一方で、現場では思ったほど楽にならなかった話も聞きます。

結論として、AIは「テストを作る」と「壊れたテストを直す」に強く、「何を確かめるべきかを決める」は苦手です。
この線引きを知らないまま導入すると、期待とずれます。

この記事では、AIテスト自動化でできることと限界を整理します。
主なツール、導入手順、費用対効果の判断まで解説します。

結論｜AIテスト自動化で変わるのは「作る」と「直す」

先に全体像を示します。
テスト自動化の工程ごとに、AIの効きめは大きく違います。

工程	AIの効果	実際のところ
何を確かめるか決める	小さい	仕様と事業リスクの理解が要る。人の判断が中心
テストケースを作る	中程度	下書きは出せる。網羅性は人が確認する
テストコードを書く	大きい	雛形生成は実用段階。レビューは必要
テストを実行する	変わらない	従来の自動化と同じ。AIでなくても自動化できる
壊れたテストを直す	大きい	画面変更に追従する自動修復が実用化
テスト結果を分析する	中程度	失敗の分類は支援できる。最終判断は人
リリース可否を決める	なし	事業判断。委ねてはいけない

つまり、AIは自動化の「入口」と「維持」の負担を下げます。
一方、テストの中身を決める仕事は人に残ります。

従来のテスト自動化ツールとの違い

テスト自動化そのものは、20年以上前からある技術です。
SeleniumやPlaywrightを使えば、AIがなくても自動化できます。

では何が変わったのか。
違いは「壊れにくさ」と「作る速さ」の2点に集約されます。

比較軸	従来型の自動化	AIテスト自動化
要素の指定方法	IDやCSSセレクタを固定で書く	画面の意味を解釈して特定する
画面変更への対応	スクリプトを人が直す	自動修復で追従する場合がある
作成の手間	コードを書く技術が必要	操作記録や自然言語から生成できる
実行の仕組み	決められた手順を再現	同じ（実行自体は変わらない）
費用	ツールは無償、人件費が中心	月額利用料＋人件費

最大の違いは、画面が変わったときにテストが落ちにくいことです。
この機能は一般に「自動修復（セルフヒーリング）」と呼ばれます。

従来型の自動化が続かない最大の原因が、この保守の手間でした。
詳しくはテスト自動化の失敗はなぜ起きる？塩漬けからの立て直し方で扱っています。

AIが関わるテスト自動化の3つの層

「AIテスト自動化」という言葉は、3つの異なるものを指しています。
混同すると、比較検討がかみ合いません。

層1｜生成AIにテストコードを書かせる

ChatGPTやClaudeなどに、テストコードを書いてもらう使い方です。
コード生成の支援であり、実行の仕組みは従来どおりです。

導入の障壁が最も低く、今日から試せます。
その代わり、生成物の品質確認は自分で行います。

層2｜AI機能つきのテスト自動化ツールを使う

画面の操作を記録し、変更に自動で追従するサービス群です。
要素の指定が変わっても、テストが壊れにくくなります。

この自動修復が、AIテスト自動化の中核的な価値です。
プログラミングの知識がなくても運用できる製品が多くあります。

層3｜AIエージェントにブラウザを操作させる

自然言語の指示で、AIが画面を操作して確認する方式です。
Playwright MCP などが、この仕組みを提供します。

探索的な確認や、テストの下書き作成に向きます。
ただし毎回同じ結果になるとは限らず、回帰テストの主軸には向きません。

層	向いている用途	導入コスト	必要な技術
1．生成AIでコード生成	既存の自動化を加速する	低い	プログラミング
2．AI機能つきツール	保守負担を下げて継続する	中〜高（月額）	不要な製品が多い
3．AIエージェント操作	探索的確認、下書き作成	低〜中	環境構築の知識

自社の課題がどの層に当たるかを、先に決めます。
層を決めずにツールを比較しても、判断軸が定まりません。

AIテスト自動化でできること5つ

実務で効果が出ている領域は、次の5つです。
いずれも「作業量が多く、判断が少ない」仕事です。

1．テストコードの雛形生成

画面や仕様を渡すと、実行できる形の下書きが出ます。
ゼロから書く時間を大きく減らせます。

ただし、そのまま使える品質とは限りません。
確認すべき点はAI生成テストコードのレビュー観点｜そのまま使えないコードの見分け方にまとめました。

2．要素指定の自動修復（セルフヒーリング）

ボタンのIDが変わっても、テストが落ちずに追従します。
画面の文言や位置など、複数の手がかりから同じ要素を探すためです。

最も費用対効果が高いのが、この自動修復です。
自動化が続かない原因の大半が、保守の手間だからです。

3．テストデータの生成

氏名や住所などの人工データを、大量に作れます。
本番データを持ち込まずに済むため、情報漏えいの危険も下がります。

データの作り方はテストデータの作り方｜本番データ利用のリスクとマスキングの実務手順で解説しています。

4．テスト結果の分析と失敗の分類

失敗したテストが、不具合なのか環境要因なのかを仕分けます。
実行件数が多いほど、この仕分けの手間が効いてきます。

5．既存スクリプトの移植

ツールを乗り換えるときの書き換え作業を任せられます。
機械的な変換が中心のため、生成AIと相性が良い作業です。

主なAIテスト自動化ツール

代表的な製品を挙げます（2026年8月時点）。
機能は更新されるため、検討時は公式情報を確認してください。

ツール	提供	特徴
Autify	国内	ノーコードで作成でき、変更への自動追従を備える
MagicPod	国内	自己修復型。Webとモバイルの両方に対応
mabl	海外	AIを前提に設計されたテスト自動化基盤
Tricentis Testim	海外	要素検出にAIを用いる。大規模開発での実績
Functionize	海外	自然言語からのテスト生成に対応
Playwright MCP	オープンソース	AIエージェントにブラウザ操作をさせる仕組み

製品ごとの選び方は、AIテスト自動化ツール比較｜Autify・MagicPod・mabl・Playwright MCPの選び方で詳しく比較しています。

Playwright MCP の導入手順は、Playwright MCPでE2Eテストを自動化する方法｜導入手順と使いどころにまとめました。

導入で得られる効果

効果は3つの方向に出ます。
ただし、いずれも条件つきです。

効果	内容	効果が出る条件
工数の削減	実行と保守にかかる人手が減る	同じテストを繰り返し実行している
品質向上	実行頻度が上がり、不具合を早く見つけられる	回帰テストの範囲が広い
リリース高速化	確認待ちの時間が短くなる	リリース頻度が高い

注意したいのは、削減できるのは「実行」の工数だという点です。
設計と保守の工数は残り、当初は逆に増えます。

試算の方法はAIテスト自動化の費用対効果｜削減工数の試算方法と3つの落とし穴で解説しています。

AIテスト自動化の限界と4つの課題

逆に、任せると事故につながる領域もあります。
共通するのは「正解を外部から知る必要がある」仕事です。

課題1．何を確かめるべきかは決められない

AIは、渡された情報の範囲でしか観点を出せません。
仕様書に書かれていない業務上の制約は、拾えません。

たとえば「この金額は経理の締め後に変更できない」といった前提です。
こうした知識は、人が補う必要があります。

課題2．期待値の正しさを保証できない

生成されたテストは、現在の実装をなぞることがあります。
実装が間違っていれば、間違いを正解として固定します。

これは最も見つけにくい失敗です。
期待値は仕様から決め、人が確認します。

課題3．網羅性を担保できない

生成されたケースは、それらしく見えても偏ります。
境界値や異常系が抜けていても、見た目では気づきません。

観点表と突き合わせて、抜けを確認します。
手順はテスト観点の洗い出し手順｜観点表と抜け漏れ防止にまとめています。

課題4．リリース可否は判断できない

残った不具合を受け入れるかは、事業判断です。
利用者と売上への影響を引き受ける人が決めます。

任せてよい	人が持つ
コードを書く手間	何を確かめるかの決定
保守の追従作業	期待値が正しいかの確認
データの用意	網羅性の担保
失敗の一次分類	リリース可否の判断

「テストケース作成」と「テスト自動化」は別物

この2つは、混同されやすい言葉です。
しかし解決したい課題が違います。

比較	テストケース作成	テスト自動化
成果物	確認項目の一覧（設計書）	実行できるコードや設定
解決する課題	何を確かめるか決まらない	毎回の実行に人手がかかる
効果が出る場面	新規開発、仕様が固まる前	回帰テスト、リリース頻度が高い
AIの使い方	観点とケースの下書き	コード生成と保守の追従

毎回同じ確認を繰り返しているなら自動化、何を確かめるかで悩んでいるならケース作成です。
課題が違えば、選ぶ手段も変わります。

ケース作成側の進め方は、生成AIでテストケース作成を効率化する方法【実践ガイド】で解説しています。

導入すべきか判断する4つの問い

AIテスト自動化は、どの現場でも効くわけではありません。
次の4つに答えると、向き不向きが分かります。

問い	はいの場合	いいえの場合
1．同じテストを月2回以上繰り返しているか	自動化の効果が出る	手動のほうが安い
2．画面や仕様の変更が頻繁か	AI機能つきツールが効く	従来の自動化で足りる
3．テストケースが文書として存在するか	すぐ着手できる	まずケースの整理から
4．保守する担当を置けるか	継続できる	外部委託を検討する

3番目が「いいえ」の場合、自動化より先にやることがあります。
確認項目が曖昧なままでは、何を自動化するかも決まりません。

4番目が「いいえ」なら、体制ごと外部に任せる選択肢もあります。
判断軸はテストの内製と外注はどちらが得か｜判断の物差しで整理しています。

導入手順｜スモールスタートで効果を検証する

最初から全機能を自動化しようとすると、まず失敗します。
効果が出やすい範囲から始めます。

• STEP1：毎回必ず実行する、主要導線の正常系を1本選ぶ
• STEP2：生成AIに雛形を書かせ、期待値だけ人が直す
• STEP3：CIに組み込み、変更のたびに実行する
• STEP4：2〜3か月運用し、保守にかかった時間を記録する
• STEP5：保守負担が重ければ、AI機能つきツールを検討する

重要なのは、STEP4の記録です。
保守時間を測っていなければ、ツール導入の是非も判断できません。

ツールを使わない基本的な自動化の手順は、Webアプリのテスト自動化入門｜ツール選定とE2E導入手順も参考になります。

何から自動化するか｜対象の選び方

自動化を決めたあと、次に詰まるのが対象の選定です。
件数が多いテストから手を付けると、たいてい続きません。

2つの軸で並べ替えると、着手順が決まります。
「実行頻度」と「変更のされにくさ」です。

実行頻度＼画面の安定度	安定している	よく変わる
毎回実行する	最優先で自動化する	2番目。AI機能つきツールが効く
ときどき実行する	3番目。余力があれば	自動化しない
まれにしか実行しない	自動化しない	自動化しない

左上の「毎回実行する×安定している」から始めます。
ここが最も費用を回収しやすい領域です。

自動化に向かないテスト

次のものは、AIを使っても人が続けたほうが確実です。
無理に自動化すると、保守だけが増えます。

• 見た目の確認：崩れているかの判断は、人のほうが速い
• 使い勝手の評価：迷わず操作できるかは、機械では測れない
• 初回の機能確認：仕様の解釈が固まる前に自動化すると作り直しになる
• 想定外を探す探索的テスト：決まった手順がないため自動化できない
• 年に数回の業務：年次処理などは、回収できない

探索的テストの進め方は、探索的テストの進め方｜規律ある4ステップ実践ガイドで解説しています。

よくある質問

プログラミングができなくても導入できますか

AI機能つきのツールなら、操作の記録だけで作成できる製品があります。
ただし、失敗の原因を調べる場面では技術的な理解が要ります。

生成AIの出力は、なぜ毎回変わるのですか

生成AIは確率的に文章を作るため、同じ指示でも結果が揺れます。
だからこそ、生成したコードは固定して版管理し、実行は従来どおり決まった手順で行います。

手動テストは不要になりますか

なくなりません。
初回の確認、使い勝手の評価、想定外を探す探索的テストは人が担います。

どのくらいで効果が出ますか

作成の初期工数を回収するには、同じテストを繰り返し実行する必要があります。
実行頻度が低い場合、回収できないまま保守だけが残ります。

まとめ｜AIは手間を減らすが、判断は代わらない

AIテスト自動化は、作る手間と保守の手間を確実に下げます。
一方で、テストの中身を決める仕事は残ります。

• 効くのは「コードを書く」と「壊れたテストを直す」
• 従来型との最大の違いは、自動修復による壊れにくさ
• 限界は「何を確かめるか」と「期待値の正しさ」
• テストケース作成と自動化は、解決する課題が違う
• 繰り返し回数が少ないなら、自動化しないほうが安い
• 主要導線1本から始め、保守時間を測って判断する

まずは毎月手で実行しているテストを数えてみてください。
その回数が、自動化で取り戻せる時間の上限です。

次に読むならこの記事

• 受託開発のAI時代における品質保証｜実務ガイド
• Playwright MCPでE2Eテストを自動化する方法｜導入手順と使いどころ
• テストのAI活用｜効く工程と始め方・限界

テストの手戻りを減らしたい方へ

テスト仕様書のExcelテンプレートを無料で配布しています。自社で整備する場合も、外部に任せる場合も、まずは型を持つところから。

テスト仕様書テンプレートを無料DL テスト代行について相談する