AIで自動テストのプロセスを自動化する
上記はJaSST nano vol,50での発表スライドです。
この記事は、当日お話しした内容を補完する内容の記事です。
1. QA現場の課題感 & テスト自動化ツールを作ったきっかけ
私はQAの仕事の中でも、“バグを探索するためのテスト”やプロセス改善といった予防的なQA活動にクリエイティブな楽しさを見出し、そこにこの仕事の魅力を感じています。
一方で、決まった入力で分かりきった期待値を出す “チェック作業”――“ クネビンフレームワーク”でいうところの 『明確』 ばかり繰り返すのは、正直あまり楽しくないんです。
（もう完全に個人的な好き嫌いの話です）
私としては、できるだけササっと済ませてクリエイティブなQA活動に時間を使いたい。
でも現実は、想像以上に “チェック作業” が多くありますよね。
否定しているわけではないですが、プロジェクトによっては「QAチーム＝チェックだけやる集団」という認知もありそうです。
チェックを実行するといえば、
アジャイル開発に必要不可欠な「繰り返し実施するリグレッションテスト」に対しては様々なテスト自動化ツールが世に出回っています。
手数のかかるチェックを寝ている間に終わらせてくれる夢のツールです。めちゃくちゃありがたい存在ですね！
一方でリグレッションテストとしての自動化を意識した既存ツールは、ケースの組み立てや日々の修正に手間がかかる ので、そちらに工数リソースを取られるものが多いなという課題も感じています（ワガママ）。
そもそも “軽くサクッと” チェックしたい場面で使う用途ではないのだろうと推測していますが。
つまり、デプロイ直後に「とりあえず問題ないか？」とざっとチェック活動をしたいときには、テスト目的が違うのでリグレッション用の自動テストツールは適していません。
そして結局、本来やりたいと思っている、予防的なQAやバグを見つけるための探索的テスト に割く時間は奪われていきます。
「この時間を別のクリエイティブなQAに使いたい！」と感じる一方で、
「じゃあチェック作業にかかる時間はどうすれば減らせるのか……？」という課題感を抱えていました。
なら、自分で作ってみよう…かな…コーディングエージェントっていうの使ってみたいし…プログラミングやったことないけど…
「チェック作業も、AIを使っていい感じに自動で回る仕組みが作れたら素敵すぎないか？」 と思いつきました。
（余談：「思いつき」とは「思い至る」だと考えています。どこからか拾ってきた役に立つか分からないいつかの知識と、日頃の問題意識がうまいこと繋がる＝「思いつき」だったりします）
- 「テストしたいこと」をサラサラっと文章で入力する
- AIがそれっぽいテストケースを生成して
- Playwright でE2Eテストを実行
- 実行結果を受けてAIが新たなシナリオを提示する
- 手順2.へ戻るループ
でカバレッジが向上
（付属機能）
- 自動テストはコケるものなので、テスト実行が失敗したらAIが失敗原因を推測して修正して、再実行までやってくれる
これなら チェック作業はサクッと終わらせて、「探索的テスト」や「プロセス改善」といった、自分がやりたい仕事に集中できるんじゃないか。
そんな想いで、このAIを使ったテスト自動化ループのツール作成をスタートしました。
2. 直面した問題と、講じた対策
自動テストツールを開発する過程では、さまざまな課題に直面しました（まだしています改善の余地が大きい）。ここでは、主な問題点とその対策をいくつか紹介します。
そもそもの問題
恥ずかしながらプログラミングができません。
Hello Worldをいくつかの言語で出力できます。それだけです。
対策
Claude-4-sonnetがヤバイらしいので使う。クレジットカードで何とかする。
問題1）生成AIの暴走
頼んでもないテストケースをAIが生成してしまう問題です。テストしなくてもよい観点まで大量に洗い出してしまい、本来の目的以上に過剰なケースが作成されてしまいます。結果として、無駄なリソースを消費したり、通らないテストが増えてシナリオ自体が埋もれてしまいトレースが取れなくなります。
問題1）対策のアイデア
この問題への対策は、観点リストを用いて AI の出力を抑制することです。あらかじめ体系的に作成してある「テスト観点」から、「正常値の入力」のように必要な観点だけをリストアップして AI に与えます。
これにより、やってほしかったテストケースが生成され、なおかつAIの “暴走” を防ぐことができました。
（観点リストについて書いた記事）
問題2）現実とかけ離れたケースが多く成功率が低い
AI はテスト対象の画面について1mmも知らないため、想像に頼ってテストケースを作成します。その結果、現実の仕様とかけ離れたテストケースが多くなり、実行しても失敗してしまうケースが増えてしまいます。つまり、生成されたテストケースの実行成功率が低い状態です。
ex,)トグル選択の箇所なのに、チェックボックスとしてテストを生成する→要素がないため失敗する
問題2）対策のアイデア
この問題には、実際の画面の DOM 解析結果 を AI に入力して軌道修正させる方法をとりました。AI にテスト対象画面の実際の DOM（UI構造）情報を与えることで、想像に頼った誤ったケース生成をある程度は修正できます。その結果、生成されたテストケースの実行成功率は従来の約30～40%から65～85%程度へと大幅に向上しました。
（登壇後のXでの会話から、PlaywrightMCPをココで利用する方向も模索中）
問題3）動かしてみないと分からない画面構造の問題
最初の静的な DOM 解析だけでは把握できなかった 動的要素や特殊な DOM 構造 が存在し、それが原因でテストが失敗してしまう問題です。実際に画面を操作してみないと現れない要素や、初期ロードでは確認できない状態の存在によって、事前の想定通りにテストが進まないケースがありました。
問題3）対策のアイデア
テスト実行中に取得した 動的な DOM 構造 の情報を AI にフィードバックし、それに基づいてテストコードを修復させる方法を取っています。動的要素を反映した最新の DOM 解析結果を用いて AI がテストを自分で修正することで、テスト失敗の原因を絞り込みやすくなります。
これにより、テストが失敗した場合にそれがテストケース生成の不備によるものなのか、実際のバグの可能性が高いのかを判断しやすくなります。
ただし、ここでスクリプト修正を頑張りすぎると 本当のバグを通してしまう可能性 が出てきます。
追記：PlaywrightMCPサーバーを使う場合、賢すぎてバグっぽい動作をパスしてしまう場合もあったため、このツールからは外しています。偽陽性と偽陰性のバランス確保が現在も課題のひとつです
問題4）生成されるケースの冪等性が低い
そもそも生成AIに一字一句同じ情報を渡しても、毎回 一字一句同じ出力を得ることはできません。
それなりにAIで 遊んでいた 業務利用の道を探っていたので、生成AIとはそういうものだという前提知識がありました。
テストシナリオを渡しても、あるときはルート2で登頂し、別のときはルート3で登頂する―― AI の出力にばらつきがあり、毎回同じ登山道でテストを通すことは困難です。その結果、狙った通りのシナリオで実行することが難しく、テストの一貫性が損なわれます。
問題4）対策のアイデア
この問題への対策として、AI にさまざまなシナリオを発見させてループ実行する仕組みを導入しました。一度の生成・実行では特定のルートしか通らなくても、シナリオ探索と実行を繰り返すことで最終的に通ってほしかったルート1も含む経路を AI が踏破することになります。
結果的に、様々なシナリオをカバーできるためカバレッジが向上し、網羅的なテスト実行が可能になります。
ノースキル開発とコスト
AI×自動テストと聞くと、「どうせプログラミング経験がないと無理でしょ？」とか、「すごくお金がかかるのでは？」と思う方も多いかもしれません。
僕自身、ガチな開発者ではなく“QAメイン”なので、できるだけノーコード／ノースキルでどこまでやれるか？という挑戦でもありました。
実際のところ、ChatGPTなど生成AI＋コーティングエージェント の力を借りれば、自分でコードを書かなくてもやりたいことがかなり実現できました。
とはいえ、ゼロコストで自動化できるわけではありません。
実際に今回1ヶ月ほど試してみて、以下の金額になりました。
- OpenAIのAPI利用料 20ドル / 約3,000円
- API関連サービス利用 25ドル / 約3,700円
- 開発支援ツール利用料（Cursor/Claude-4等） 120ドル / 約17,800円
- 合計 約24,500円
という自腹の発生です（2025/7/17 時点の実例）
私のようにノースキルだとコーディングエージェントをガッツリ使うしかないのでコストはかさみます。
一方でAIのトークン量（本当に必要な入出力は何か？）については金額の増え方を気にしているうちに、「最適化するためにどうすれば...」と考えることもできました。
また、ノースキル開発でありがちな “ハマりポイント”としては、
- コーディングAIの甘言にダマされて利用料金が上がる
- claude「素晴らしい！完璧に修正しました」（同じエラー3回目）
- ぼく「よしよし、いいぞ！テストしたろ…」
- ログ「4回続けて同じエラーやで！」
- 順を追って原因分析するように仕向けるなど、指示を工夫する
- 「いきなりコーディングせずに、なぜこのエラーが出るのか、原因として考えられるものを3つ挙げて」
みたいな沼にハマっているエージェントを救いあげるような“監視の目”は絶対に必要です。
自走モードにしてたら、いくらかかったんでしょうか…
まとめると、 「問題意識と、解決への熱量さえあれば誰でも走りだせる！」 というのが私の実感です。
AIやノーコードツールの進化で、プログラミングスキルが無くても “自分で解決できる問題が増えた” ことは間違いありません。
「一歩踏み出す勇気」が結果につながる――そんな時代が本当にやってきたんだなぁと感じています。
追記：
「テスト対象にAIが組み込まれている」というプロダクトばかりになる日はそう遠くないと思います。
QAエンジニアとしては、いまのうちに生成AI使用時のクセみたいなものを経験として蓄積しておくと良さそうです。
EOF
Discussion