こんにちは。GxPの廣田です。
グロースエクスパートナーズグループのリレーブログ企画8日目です。
前回の記事は１年目に工数見積もりで失敗したときの話でした。
まだご覧になっていない方は、ぜひそちらもチェックしてみてください！

はじめに

自分の案件では、品質担保のためにテストへ多くの工数を使っていました。
その必要性は理解しつつも、同時に「AIを使ってテスト工数をもう少し下げられないか？」という課題感がありました。

この検証を始めた時点では、正直「何をどう作るべきか」は見えていませんでした。
最初から正解を設計できたわけではなく、次の繰り返しで前に進めました。

とりあえず触ってみる
失敗する
直す

この記事では、GitHub CopilotのAgentモード、Playwright関連の仕組み、Pythonによるテストコードを使って、手探りで進めた過程をまとめます。
実装手順についてではなく、検証を通じた判断の変化と運用上の学びを中心に書きます。

こんな人向け

テスト自動化を始めたい
ただ、設計の切り口がまだ曖昧

前提

チームのテストの進め方

画面の初期表示時点のキャプチャを取得
指定操作を行い、操作後のキャプチャを取得
画面遷移後のキャプチャを取得

これを画面ごとに繰り返して、シナリオを最後まで実行します。
保存したキャプチャは、証跡と目視確認の両方に使います。

検証時の環境と条件

OS: Windows 11
実行言語: Python
ブラウザ操作: Playwright for Python
AI操作: GitHub CopilotのAgentモード
MCP: Playwright MCP
ブラウザ: Google Chrome, Microsoft Edge

検証途中ではPlaywright MCPをAgentから利用しましたが、最終的にはPlaywright for Pythonに操作手段を統一しました。
検証結果は、ブラウザ別のケース数や結果を分けず、検証全体の集計として記載しています。

最初に置いた目標

最初から汎用的な仕組みを作るのではなく、まずは「自動化手法を成立させる」ことを目標にしました。

テスト工数を削減したい
ただし品質は落としたくない
AIによるブラウザ操作が現場で実用になるか確認したい

検証途中では、次のように実行手段を使い分けました。

手順を厳密に制御したい画面: Python側でPlaywrightを実行
比較的単純な操作画面: Playwright MCPをAgentから実行

ただし最終的には、操作手段をPython側へ統一し、すべてのシナリオを共通テストランナーで実行する構成に切り替えています。

品質確認の考え方

今回自動化したのは、ブラウザ操作、URLと必須要素の確認、画面キャプチャ取得です。
一方で、この構成だけで画面の正しさを完全自動判定するわけではありません。

少なくとも次は別途確認が必要です。

期待画面へ遷移しているか
URLと必須要素が想定どおりか（自動確認）
エラーメッセージや入力値が想定どおりか
キャプチャに表示崩れや意図しない表示がないか（目視確認）

つまり「テスト実行の自動化」と「結果判定の自動化」は分けて考えました。

まずやったことと、最初の壁

1. Playwright MCP + Copilot Agentで直接自動化

最初は、Agentに画面操作とテスト実行をそのまま任せる方式を試しました。

2. すぐ壁に当たった

実際には、次の問題が頻発しました。

特定画面で遷移できずループする
画面キャプチャが安定しない
動的表示項目への追従が不安定

特に厳しかったのは、動的フォーム制御です。

A入力後にBが表示される
条件成立までボタンや入力欄が disabled のまま
style や活性状態が複数箇所で切り替わる

入力順が重要な画面では、instructionsやAgentファイルを調整しても安定せず、同じ画面を抜けられないことがありました。
この時点で「全部を自動でいい感じにやってくれる」は一旦あきらめました。

方針転換

3. 不安要素のある画面だけPythonテストコードで実行

次に、「全部をAgentに任せる」から「画面ごとに実行手段を分ける」へ変更しました。

不安要素がある画面: Pythonのテストコードで手順と待機条件を明示
比較的単純な画面: Playwright MCPで操作

ここでいう不安要素は、例えば次です。

入力後に別項目が非同期で表示される
入力順で次の項目やボタン活性が変わる
画面状態を見て待機完了を判断する必要がある

4. まず1ケースだけ通す

最初から汎用化は狙わず、1ケース限定で「最後まで通る」ことを目標にしました。

いきなり正解を作らない
まず1ケース通す

に振り切ったのが結果的によかったです。

加えて、クレジット消費を抑える運用として、想定外挙動が1回でも出た実行は止めてユーザー判断へ切り替えるルールにしました。

5. 1ケースで得た知見をinstructionsへ反映

待機条件、要素特定、失敗時分岐など、1ケースで得た知見を都度instructionsへ追記しました。

効いたのは次のセット運用です。

その場しのぎで直す
直した内容をルールとして残す

6. 3〜5のサイクルで複数ケースへ展開

ケースを作る
失敗を観測する
instructionsを改善する
次ケースへ適用する

このサイクルでケース数を増やせましたが、未知画面や想定外フローでは不安定さが残りました。

最終的に採用した「テストコード中心」方式

PythonとPlaywright MCPの分担構成も試しましたが、最終的には安定性を十分確保できませんでした。
操作手段をまたぐことで、失敗時に追う対象が増え、キャプチャ取りこぼしも追跡しづらかったためです。

そこで、すべてのシナリオをテストコードで実行する方針に切り替えました。
Playwright MCPやCopilot Agentから個別に画面を操作せず、次を共通テストランナーへ集約しました。

ケース読み込み
画面操作
画面遷移の確認
ログ・スクリーンショット保存

ただし、ケースごとにフル個別実装する方式ではありません。
画面操作を再利用可能な単位に分け、ケース側は組み合わせと入力値だけ定義します。
Copilot Agentはこの再利用可能な関数を呼び出す順番、入力値を決定し、あとはPythonがテストを実施します。

この構成で重視したのは次の3点です。

実行手段を1つにそろえ、失敗時の調査対象を明確化
画面操作を再利用し、同じ待機や要素特定の重複を減らす
実行前にケースと仕様書の対応を検証し、定義ミスを早期検知

操作後は、次画面のURLと必須要素を確認し、想定外画面ならその場で失敗として扱います。

検証結果

25ケースにて検証を行いました。

操作完了率: 21/25
実行時間（1シナリオ）: 手動平均5分程度 → 自動 1分20秒程度
主な失敗要因: はじめて遷移する画面での次画面遷移失敗
消費クレジット: 検証全体で約2,500クレジット

※操作完了とは、全ステップを実行し、最終画面のURLと必須要素の確認まで完了した状態を指します。画面表示の目視確認は含みません。

現時点の学び

個人的にいちばん大きかった学びは次です。

今回手探りで採用したPythonによるテストコードを作ることは、振り返ってみると、E2Eテストコードを書くことと本質的な違いはないように感じました。
差が出るのは「書くかどうか」ではなく、「画面操作をどう再利用し、保守をどう回すか」にあります。

以前案件内で、E2E自動化がうまく続かなかった理由は、実装そのものより保守コストだったそうです。

画面変更でセレクタが壊れる
例外ケースが増えて分岐が肥大化する

今回の検証では、保守作業の一部をAIに支援してもらえる感触がありました。

特に効果を感じたのは、次の作業です。

失敗内容の整理
修正案のたたき台作成
instructionsへの反映文案の作成

特に効いたのは、改善サイクルを短く回せることです。

失敗する
失敗要因を整理する
すぐ instructions / Agent ファイルに反映する
次の実行で検証する

このあたりを毎回ゼロから人が考えなくてよくなるだけでも、運用負荷は大きく下がります。

言い換えると、AIの価値は「魔法みたいに全部自動化してくれること」ではなく、
失敗後の原因整理や修正案作成を支援し、保守サイクルを短く回せることにあると感じました。

また、未知のフローをその場で全自動解決するより、既知操作の再利用率を上げ、不足している画面や処理は実装してからテストする設計に寄せる方が、自分の環境では運用しやすいと分かりました。
育てるテスト支援ツールとして、活用していければと思います。

おわりに

今回の検証では、「Agentにすべてを任せる」より「画面操作を再利用可能な関数として積む」方式の方が、自分の環境では安定して運用できました。

テスト自動化を始めるときは、次の順序が現実的だと感じています。

まず1ケースを最後まで通す
失敗内容をルールとして残す
次のケースへ再利用する
ある程度のケース数を網羅できたら、多ケースに対応できる仕組みをAIと考える

AIは魔法の全自動装置というより、失敗後の原因整理と修正案作成を支援し、サイクルを短くする道具として使うのが有効でした。