生成AIを使ったバイブコーディングでE2Eテスト自動化をやってみた：気づきとナレッジ

１．バイブコーディングの課題

■コードの品質と信頼性

　AIモデルは時に「ハルシネーション」（もっともらしいが事実ではない情報を生成すること）を起こし、一見正しそうに見えるものの、微妙な欠陥、非効率性、論理エラーを含むコードを生成する可能性があります。厳格な検証なしにAIに依存すると、信頼性の低いソフトウェアにつながるリスクがあります。

■デバッグとメンテナンス

　ユーザーがAIに過度に依存し、生成されたコードを深く理 解していない場合、後からバグを発見して修正することが非常に困難になる可能性 があります。これは長期的なメンテナンスの問題を引き起こす原因となります。

■過度な依存の可能性

AIツールへの過度な依存は、開発者のスキルセットの停滞や、 AIが対応できない複雑な問題への対処能力の低下を招く可能性があります。AIはあ くまでツールであり、その出力を適切に評価し、必要に応じて修正できる人間の能 力が依然として重要です。

2. E2Eテスト自動化における生成AIの現状と課題

　E2E（End-to-End）テストは、システム全体がユーザーの視点から正しく機能するかを検 証する上で極めて重要なプロセスです。ユーザーが実際にアプリケーションを操作するシナリオをシミュレートすることで、個々のコンポーネントテストでは見過ごされがちな統 合上の問題や、ユーザー体験に直結する不具合を発見できます。しかし、E2Eテストはテ スト範囲が機能全体にわたるため、テストケースの作成、実行、そして特にシステム変更時のメンテナンスに多大な時間とコストがかかるという課題を抱えています。
近年、このE2Eテスト自動化の領域においても生成AIの活用が試みられています。主な活用方法としては、以下の二つのアプローチが挙げられます。

①仕様書からの直接操作

　生成AIエージェントにアプリケーションの仕様書や要件を直接入力し、AIがその内容を解釈してブラウザを操作し、テストを実行させるアプロ ーチです。AIが自律的にテストシナリオを構築し、実行することで、テストケース作 成の手間を省くことを目指します。

②テストコードの生成

　仕様書やテスト対象のUI情報に基づいて、AIがE2Eテストのコ ード（例：Selenium, Playwrightなどのフレームワークを用いたスクリプト）を自 動生成するアプローチです。生成されたコードを開発者がレビューし、必要に応じて修正しながらテストコードを作成・実行します。
これらのアプローチはE2Eテスト自動化の効率化に大きな期待を寄せられていますが、現状ではいくつかの課題も存在します。

３．現状の課題

■ セレクターの不安定さ

　テストコード生成のアプローチでは、生成されたテストコー ドのセレクター（UI要素を特定するための識別子）が不安定であるという問題があ ります。例えばテスト対象の仕様書やDOM構造を学習しているにも関わらず、AIが無効なセレクターを生成することがあります。これにより、生成されたコードのデバッグに時間を要し、結果的に人間がソースを確認してAIに教えたり、自分で修正した方が早いという本末転倒な状況に陥ることもあります。

■ コード修正の不安定さ

　生成AIによるコード修正は、修正のたびに対話の回数が増えるに比例して消費トークン数も増えます。全体をリファクタリングした場合、最初に生成されたコードとは全く違うコードが生成されることもあります。意図しない行が消えたり、修正結果がコンソールに出力されるだけでファイルに反映するのを忘れてしまうと思わぬ不具合が発生し、開発体験を損なうこともあります。そのため、コード修正はできるだけ詳細に具体的に指示することがポイントになります。

４．CURSORでテストケースとテストコードを作成、Playwrightでテスト実行

■自然言語での指示に対するコード生成の精度

　CURSORは、自然言語で記述したテストシナリオに対して、比較的高い精度でE2Eテストコードを生成してくれました。例えば、「ログインページにアクセスし、ユーザー名とパスワードを入力してログインボタンをクリックする」といった具体的な指示に対して、適切なセレクターと操作を伴うコードを生成することができました。必要なファイルも自動で作成してくれます。これにより、テストコードをゼロから 手書きする手間が大幅に削減され、開発初期段階でのテストカバレッジの迅速な確保に貢献しました。

■E2Eテストシナリオの記述のしやすさ

　CURSORのインターフェースは、自然言語で のプロンプト入力ができ、E2Eテストのシナリオを作成し、テストコード生成、Playwrightで実行まで行うことができました。これにより、テスト自動化の専門知識が少ないメンバーでも、テスト自動化の導入や運用に参加しやすくなり、チーム全体のテスト自動化への貢献度を高めることができると実感しました。

■デバッグ支援機能の有用性

　生成されたコードが期待通りに動作しない場合、 CURSORはデバッグ支援機能を提供してくれます。エラーメッセージの解析や、 問題箇所の特定をAIがサポートしてくれるため、デバッグにかかる時間を短縮し、 テストコードの修正を効率的に進めることができました。非エンジニアでもＡＩと自然言語で対話しながらデバッグすることができました。

５．課題点

■複雑なUI操作の表現の難しさ

　単純なフォーム入力やボタンクリックは得意とする一 方で、ドラッグ＆ドロップ、動的な要素の出現待ち、特定の条件分岐を伴う複雑な UI操作など、より高度なインタラクションを自然言語で正確に表現し、AIに意図通 りにコードを生成させることは困難でした。プロンプトの記述が曖昧だと、AIは意図しないコードを生成する傾向が見られました。

■予期せぬ挙動への対応

　最初に生成したコードだけでは正常動作せず、デバッグする必要があります。特に、AIが生成したコードの内部ロジックを人間が理解しないと、AIが提案する修正方法が間違っている場合がありました。

■生成されたコードの最適化の必要性

　AIが生成するコードは、機能的には動作するも のの、可読性や保守性、パフォーマンスの面で最適ではない場合があります。例えば、エラー修正時にテストを正常に通そうとするバイアスが働き、テストしても意味のないコードを提案してくることがありました。修正時は特にAIに任せにせず、確認モードで行う必要があります。プロンプトの指示があいまい、仕様が明確でない、学習データがとぼしい場合など、ハルシネーションが起きる可能性が高くなると想定されます。

6.得られたナレッジ

これらの経験から、生成AIを用いたE2Eテスト自動化を成功させるためのいくつかの重要 なナレッジを得ることができました。

■具体的なプロンプトの書き方

　AIに意図通りのコードを生成させるためには、プロン プトの質が極めて重要です。単に「ログインする」と指示するだけでなく、「ユーザ ー名フィールドに'testuser'と入力し、パスワードフィールドに'password'と入力し た後、'ログイン'と書かれたボタンをクリックする」のように、操作対象の要素を明 確に特定し、期待する動作を具体的に記述することが効果的でした。また、要素の特定にはCSSセレクターやXPathを直接プロンプトに含めることも有効な場合があります。 また、CURSORにはRAG機能はありませんが、Rules設定によりサンプルコードや仕様書などを学習させることができます。これは非常に重要です。

■AIが生成したコードのレビュー観点

　AIが生成したコードは、必ず人間の目でレビュ ーする必要があります。テストコードは比較的小規模なロジックの集まりのため、一般的なアプリケーション開発における静的コードレビューのレベルは必要ないと思いますが、実務で使用する場合には、特に、以下の点に注意することが必要です。

正確性：テストシナリオやカバレッジが意図通りに実装されているか。

堅牢性：UI変更に強いセレクターが使用されているか、適切な待機処理が組み 込まれているか。

可読性・保守性：他の開発者が理解しやすいロジックか、将来的な変更に対応しやすい構造か。コードにコメントをつけているか。

最適化：冗長な処理や非効率な記述やロジックがないか。

機密性：情報漏洩、不正アクセス対策、脆弱性対策

人間による調整の必要性とその範囲

　生成AIは強力な支援ツールですが、「銀の弾丸」 ではありません。特に複雑なシナリオや、AIが苦手とする領域（例：動的なUI操作、特定のビジネスロジックの検証）では、人間が細かく指示するか、手動でコードを補正する必要があるかもしれません。

繰り返し実行によるAIの学習と改善の可能性

　同じテストシナリオに対して異なるプ ロンプトを試したり、AIが生成したコードを修正してフィードバックを与えたりす ることで、AIのコード生成能力が向上する可能性があります。これは、AIモデル の特性によるものですが、継続的な利用とフィードバックが、より精度の高いテスト自動化につながることを示唆しています。

７. まとめ

生成AIを用いたE2Eテスト自動化は、まだ発展途上の領域でありますが、その一方で、バイブ・コーディングによって、テストの効率化と民主化の実現性が高いことを確認しました。CURSORのようなAIエディターを使えば、非エンジニアでもE2Eテスト自動化を実際に動作させることができましたが、実務においては、「バイブ・コーディング」ではなく、「AI駆動開発」とするのが良いかと思います。