テスト自動化の選び方｜Selenium・PlaywrightとAI修復の確認点

ソフトウェアテスト自動化で最初に決めるのは、操作するツールより「何が起きれば合格か」です。ボタンを押せることと、正しい注文が保存されることは別の確認です。本記事では、2026年11月6日に確認した公式資料を基に、SeleniumとPlaywrightの比較、待機と再実行、AIによる修復の確認、CIで残す記録を整理します。確認表と試行の進め方は本記事の提案であり、特定ツールの導入効果を測定した結果ではありません。

テスト自動化は、操作と期待結果を別々に設計する

テスト自動化は、用意した条件でプログラムを動かし、その結果が期待した状態と一致するかを繰り返し確認する仕組みです。テストコードが最後まで実行されたことだけで合格にせず、確認したい仕様をアサーションとして表します。アサーションは、画面の文字、保存された値、エラーの表示などについて、満たすべき条件を検査するものです。ツールが自動化する操作と、担当者が決める正しさの基準を分けると、ケース数を増やす前に不足を見つけやすくなります。

例えば、注文の受付を題材にする場合、成功画面の表示だけでなく、品目・数量・受付番号が意図した結果と一致するかを検討します。入力に誤りがある場合は、エラーが出ることと、注文が確定していないことを確認対象にします。これらは架空の検討例です。自社の業務仕様と、テストで参照を許可された記録に合わせて期待結果を決めてください。画面から見えない結果を確認する方法や権限も、実装前に用意します。

確認する場面	操作の例	期待結果として決めること
正常な受付	必要項目を入力して送信する	受け付けた内容と保存先の値、表示する結果
入力の不足	必須項目を空にする	案内するエラーと、確定してはいけない処理
権限の違い	別の利用者として同じ画面を開く	閲覧・変更できる範囲と拒否した結果
途中の失敗	検証環境で外部処理の失敗を再現する	保留状態、利用者への案内、再開時の扱い

対象は、利用者への影響、変更頻度、繰り返し確認する負担から選びます。単体の計算や入力検査、サービス間の受渡し、ブラウザーからの一連の操作では、確かめられる範囲が異なります。ユニット・統合・E2Eテストの比率を固定の数字に合わせるより、重要な仕様をどの層で確認し、どこが未確認かを説明できる状態を目指します。各ケースには、開始時の利用者・権限、用意するデータ、終了後に残す状態も添えます。受付済みのデータを別のケースで使う場合などは、前の結果への依存を意図したものか確認し、順番が変わっても判定を説明できるようにします。画面が使いやすいか、要望に沿っているかなどの判断も含め、自動実行の結果と担当者の確認を組み合わせます。

SeleniumとPlaywrightは、待機・実行環境・既存資産で比べる

Seleniumの公式WebDriver解説は、言語バインディングとブラウザー制御の実装を説明しています。自社で採用する言語、ブラウザー、ドライバーと既存テストを組み合わせて確認します。一方、Playwrightの導入案内は、Playwright Testにテストランナー、アサーション、分離、並列実行などを含むと説明し、Chromium・WebKit・Firefoxの対応を示しています。この記事ではJS/TS向けのPlaywright Testを比較の対象とし、ライブラリと実行基盤の範囲をそろえます。

選定で重要なのが、画面の準備が整うまでの待機です。Seleniumの待機資料は、要素の検索に適用する暗黙待機と、指定した条件を確かめる明示待機を説明し、両者を混在させないよう注意しています。Seleniumに待機機構がないという比較は適切ではありません。ページの読込みが終わっても、後からJavaScriptで追加される要素が操作できるとは限らないことも確認します。

Playwrightの自動待機では、クリック前に対象が一つに定まり、表示・安定性・操作可能性などの条件を満たすかを調べます。必要な条件を制限時間内に満たさなければ失敗します。操作ごとに確認項目が違うため、クリックの説明をあらゆる操作へ広げません。また、自動待機は注文金額や保存内容の正しさまで判断する機能ではなく、期待結果の検査は別に設計します。

選定観点	試行で確認する内容
対象環境	利用するブラウザー・OS・実行基盤の組合せを、採用版の対応条件と照合する
待機と要素の指定	画面更新後に狙った要素を選べるか、失敗した条件を説明できるかを試す
既存資産	ケース、データ準備、補助ライブラリ、保守担当者の知識を再利用できるか調べる
運用	CIの実行・調査方法、更新時の再検証、担当者交代後の保守を比べる

この表は評価の提案です。同じ重要フローを使って、実装から失敗の調査まで一巡させます。新しいツールだから必ず移行すべき、既存資産があるから変更できない、と一律に決めず、維持する範囲と新規に試す範囲を選びます。導入後もツール本体とブラウザー、実行環境の版を記録し、更新後に同じケースを実行できるか確認します。

AIの生成・自己修復は、誤った合格を防ぐ検査と組み合わせる

AIを利用する場合も、テストケースの案、操作対象の変更、期待結果の変更は分けてレビューします。仕様からケースを作る用途では、仕様のどの箇所に対応するか、正常系だけに偏っていないか、判定すべき値が具体的かを確認します。生成されたテストが実行できても、重要な条件を検査していなければ、不具合を見逃したまま合格になる可能性があります。ケース数や生成したコードの量だけを品質の指標にしないことが大切です。

自己修復の例として、mablの2026年9月4日更新の公式資料は、既知の属性で対象要素を見つけられない場合に、似た要素を探す動作を説明しています。テストが合格した場合に修復を保存し、不合格の場合には保存しないとしています。アサーションの設定によっては別の要素へ修復して誤った合格や不合格になるため、自動修復を無効にする選択も案内しています。これは同製品の説明であり、全AIテストツールに共通する保存条件ではありません。

この注意を実務へ落とし込むなら、変更前後の要素、実行した操作、確認した値を残す方法が考えられます。例えば、注文を確定するボタンが見つからなくなったとき、別のボタンを押せたことだけで修復完了にしません。対象の意味、表示する結果、保存した内容を検査し、必要な条件が抜けていないかを担当者が確認します。期待結果を変更して失敗を消す場合は、製品の仕様変更によるものか、テストの誤りを直すものかを分け、根拠を記録します。

AIによる画面差分の説明や失敗原因の分類を検討する際も、説明の候補と確定した原因を区別します。見た目の差が仕様どおりか、同じ不具合が別の画面にもあるかは、担当者が結果と仕様を照合します。修復案や分類案の採用率を測るなら、対象ケース、採用基準、誤った提案と追加確認の負担をそろえます。個別製品の成功事例を、自社でも同じ精度や保守削減率になる根拠にしないでください。

テストに利用する画面やログには、利用者情報や機密情報が含まれる場合があります。検証用データと権限を用意し、外部AIへ渡す範囲、閲覧者、保存と削除の条件を確認します。実サービスの認証を省略した環境だけで成功しても、必要な権限で業務を実行できるかの確認は残ります。

CIでは最初の失敗と再実行を残し、保守まで評価する

継続的インテグレーション（CI）へ組み込む際は、どの変更でどのテストを動かし、不合格や未実行の場合に誰が判断するかを決めます。実行できなかったケースを合格に含めず、前提データを用意できなかった場合と、製品の期待結果が一致しなかった場合を区別します。外部システムを代わりの応答で試す場合は、そこで検証できた範囲と、実際の接続で確かめる範囲を記録します。すべてのテストが通っても、対象外の環境や未検査の仕様まで安全と判断しません。

Playwrightの再実行資料は、初回で合格したテスト、初回は失敗して再試行で合格したflaky、再試行しても失敗したテストを区別しています。再実行の最終結果だけを残すと、断続的な失敗が見えなくなります。本記事では、初回の失敗時点、実行環境、対象データ、再実行の有無と結果を残すことを提案します。毎回同じ操作を再送してよいか、準備処理や後片付けで状態を戻せるかもテストごとに確認します。

調査に必要な記録も選びます。PlaywrightのTrace Viewer資料は、記録した操作、エラー、コンソール、ネットワークの情報などを確認できると説明しています。導入する場合は、どの失敗で何を取得し、誰が参照し、いつ削除するかを定めます。ログに含まれるリクエスト本文や画面情報を、無制限に共有する運用にはしません。記録を残す設定と、実際に原因を調べられることを代表的な失敗で確かめます。

評価では、実行時間に加え、実行待ち、データ準備、失敗の切分け、誤検知の確認、仕様変更への追従を含めます。利用料、CI計算資源、記録の保管、導入と教育、保守をそろえ、時間の短縮と現金支出の減少を区別します。開発全体の待ち時間や体験とのつながりは、DevExと開発の指標を測る考え方も参考になります。テストの件数や実行時間を、そのまま開発者個人の能力へ置き換えないようにします。

判定結果や未確認事項を整理する画面、承認した情報の受渡し、結果と例外の記録などのIT実装を検討する場合は、要件整理・設計・実装・運用の対応範囲をご覧ください。連携はAPI、権限、形式、セキュリティ条件を確認して相談します。特定フレームワークの専門資格、全環境の品質保証や不具合の完全検出を一律に約束するものではなく、対象業務と確認条件を定めて進めます。