機能テストだけでは足りない。「ユーザー視点」の回帰テストをAIで再構築した話。

サムネイル

想定読者
はじめに
本活動の背景
本取り組みの流れ
- 使用したツール
調査フェーズ: サイト分析と機能の把握
- 人間なら「見ればわかる」、AIには「教える必要がある」
設計フェーズ1: ユーザーシナリオの具現化
- AIに教えた「2つの顔」
設計フェーズ2: ユーザーストーリーの構築
- フロー図による「抜け漏れ」の可視化
- 「0→1」と「1→100」の役割分担
設計フェーズ3: テストケース化
実行フェーズ：Playwright MCPによるテスト実行
まとめと今後の展望

想定読者

本記事は以下のような方々を想定読者としています。

「AIを導入したいが、どこから手を付ければいいかわからない」と悩んでいるQAエンジニア
プログラミングスキルに不安があり、自動テストへの挑戦を躊躇している方
ユーザー体験（UX）を重視したテスト設計を実現したいと考えている方

はじめに

こんにちは、QA部の鈴木剣一です。

過去のQA部発の記事でもお伝えしているとおり、現在QA部ではすべてのテスト工程に対してAIを適用し、AIとの協働やAIへの業務置換を目指しています。

この記事では、AIツール「Cursor」と「Playwright MCP」を活用して、DMM通販サイトの回帰テストをユーザー中心の設計思想でゼロから再構築したプロセスを紹介します。

分析→設計→実行をAI主導で一気通貫させた実践例です。

developersblog.dmm.com

回帰テストの定義

プログラムの改修により、既存の機能に影響が出ていないかを確認するテストです。

一般的には「リグレッションテスト」とも呼ばれますが、本記事では「回帰テスト」と表記します。

本活動の背景

DMM通販サイトは歴史が長く、現在も様々な機能追加や改修が続いています。また、DMM通販モダナイズプロジェクトも進行しているなかで、日常的な回帰テストの実施と品質の定点観測の重要性が高まっています。

機能的観点の回帰テストはすでに充足しているものの、より手厚いテストを行い、高い品質を維持するにはどうするべきか。

その答えとして、DMM通販サイトを利用してくれるユーザーに寄り添った「ユーザー視点」のテストを再構築し拡充することにしました。

inside.dmm.com

本取り組みの流れ

「人間は極力作業せず、AIに任せられることはすべて任せる」。

そんな思想のもと、サイト調査から実行まで、AIが主体となって進む全体のフローは以下の通りです。

フロー

調査フェーズ

AIがサイトを巡回・分析し、画面や機能を把握します。

設計フェーズ

調査結果からユーザーシナリオを具現化し、それらを組み合わせることで、実利用に即したユーザーストーリーを構築します。さらに実行可能なテストケースへと変換します。

実行フェーズ

生成されたテストケースを用い、Playwright MCPによる自動テストを実行します。

使用したツール

ツール	用途	選定理由
Cursor	AIペアプログラミング	ドキュメント生成と分析に優れる、自然言語での指示が可能
Playwright MCP	ブラウザ操作・自動化	サイト構造の解析から、実際のテスト操作まで実行可能
Mermaid	フロー図作成	テキストベースで管理しやすく、バージョン管理に適している
Markdownファイル	ドキュメント管理	可読性が高く、Gitで管理しやすい
CSVファイル	テストケース管理	スプレッドシート等で編集可能、テスト実行ツールとの連携が容易

調査フェーズ: サイト分析と機能の把握

まず、AI（Playwright MCP）を使って、DMM通販サイトの各フロアを実際に見て回ってもらいました。

DMM通販サイトは、専門店ではなく、複数の巨大な売り場が集まったデパートのような場所です。 AIには多角的な視点でサイトを見て回るよう指示し、サイトの構造や機能を徹底的に調査してもらいました。すると、単なる機能リストに留まらず、画面と画面がどう繋がっているかも含めて、思いのほか深いところまで整理してくれました。

以下の表は、AIが「具体的に何を調査・学習したのか」を示した調査結果の概要です。

このように、AIは個々の「機能」だけでなく、それらがどう繋がっているかという「相互関係」も含めてサイトを構造的に理解します。また、学習した内容をマトリクス表やフロー図として可視化して提示してくれるため、AIが正確に認識できているかを人間が一目で検証できる点も大きな強みです。

人間なら「見ればわかる」、AIには「教える必要がある」

この作業の裏テーマとしてもう一つ期待していたことがあります。それが、テストの合否を判定するための「客観的な判断基準（期待値）」の確立です。

人間なら「ボタンを押したら該当ページが表示された」と直感的・経験的に判断できることも、AIには「具体的に何のデータを見れば正解なのか」という明確な基準を教える必要があります。

本来であればとても骨の折れる作業ですが、今回はAIに実際のサイトを巡回させることで、この人間の感覚を、AIが扱えるデータへと変換することに成功しました。

例えば、「ページ遷移」の判定基準は以下のように変換されます。

人間（直感的・経験的に判断）：

画面が切り替わったか
カテゴリー名が表示されているか

AI（客観的データによる判断）：

URLが遷移先ページ向けのパターンに変化しているか
HTMLのタイトルタグ内に、選択したカテゴリー名が記述されているか

このように、属人的な目視確認に頼らず、「データに基づく客観的な期待値」を確立できたことは、後のテスト実行フェーズで「AIが迷わず正解を判定できる」ための重要な布石となりました。

設計フェーズ1: ユーザーシナリオの具現化

サイト巡回で得られた情報を基に、次はユーザーがどのような目的でサイトを訪れるかを定義する「ユーザーシナリオの具現化」へと進みます。

AIに作成してもらったユーザーシナリオは、「ひとつの目的が達成される最小単位」という粒度で統一しています。

従来のテストケースのような「ボタンAを押す→画面Bを確認する」といった細かい手順指定（How）は行いません。

代わりに、「〇〇の条件で商品を探し出す」といった達成すべきゴール（What）のみを定義しています。

複雑すぎず、単純すぎないこの粒度は、AIエージェントが迷子にならずに自律的に探索できる最適なサイズ感であり、かつ人間が見ても「何を目的としているのか」を直感的に把握できる構成になっています。

シナリオ

ユーザーシナリオの特徴:

単体で実行可能: 1つの行動として完結している
組み合わせ可能: 複数のユーザーシナリオを組み合わせてユーザーストーリーを作成できる
テスト可能: 実際にPlaywright MCPの調査に基づいて実行できる具体的な操作として表現されている

AIに教えた「2つの顔」

今回のユーザーシナリオ生成では、DMM通販サイトを単なる「ショッピングサイト」として扱わず、「ファンのためのプラットフォーム」として定義しました。

前述の表のように、一般的なECサイトとしての機能だけでなく、DMM通販サイト特有の体験に直結するユーザーシナリオも重点的に学習させています。

これにより、例えば「買い物はできるけど、DMMポイントが使えない（=DMM通販サイトに来た意味がない）」といった、ビジネス価値を損なう不具合をAIが見逃さないように設計しています。

これらのユーザーシナリオを後続のユーザーストーリー作成時に柔軟に組み合わせることで、多様なユーザーの行動パターンをカバーできるようになりました。

設計フェーズ2: ユーザーストーリーの構築

設計フェーズ1 で作成したユーザーシナリオを組み合わせて、具体的なユーザーストーリーを複数作成してもらいました。

実際に作成された一例です。

ストーリー

ユーザーストーリーの構成要素:

ユーザーストーリー名: ユーザーの目的を表現
説明: ユーザーの動機に基づいて何をするか
アクションフロー: 具体的な操作手順（複数ステップ）

この例では、検索・試聴・フロア移動・お気に入り追加など、複数のアクションが組み合わされています。

構成自体はシンプルですが、多岐にわたるアクションが、一つのユーザーストーリーとして統合されており、単機能テストではカバーしきれない複合的なテストが可能になっています。

これにより、単機能のエラーチェックに留まらず、「ユーザー視点でのリアルな利用体験」に合わせた操作を検証範囲に含めることができました。

通常、これほど横断的なユーザーストーリーを複数設計するには膨大な工数がかかりますが、AIによって短時間で構築・量産することに成功しました。

フロー図による「抜け漏れ」の可視化

テキスト形式のユーザーストーリーは「読む」には適していますが、「見落とし」に気づきにくいという欠点があります。

文字で書かれた手順を読んでいると、私たちは無意識に「すべてが上手くいった場合」だけを想像してしまいがちだからです。

そこで、Cursorにこう指示しました。

「このユーザーストーリーを Mermaid 形式のフロー図に変換して」。

返ってきたのが以下の図です。

チャート

リスト

非常にシンプルな図が生成されました。いわゆる「メインフロー」ですね。しかし、テストの現場にいる方なら、「ユーザーの行動はこんなに綺麗じゃない」と即座に思うはずです。

現実はもっと泥臭く、気まぐれなものです。

ここからがAIの真骨頂です。このシンプルなフロー図を、より現実的なものにしてみます。

「事前の仕様調査レポートを参考に、起こりうる代替フローと例外フローを肉付けして」

と依頼しました。

するとAIは、サイトの仕様を考慮したうえで、瞬時に以下の図を描き出しました。

チャート2

表示しきれないくらい描き出してくれたので、S1~S4にフォーカスしてみましょう。

ズーム

いかがでしょうか。

「検索結果が0件だったら？（例外）」「未ログイン状態だったら？（代替）」など、メインフローの裏側に隠れていたこれだけの分岐が一瞬で可視化されました。さらに深い分析とパターンの肉付けを依頼すれば、もっと多くの代替フローや例外フローを抽出してくれます。

「0→1」と「1→100」の役割分担

人間が頭の中でシミュレーションすると数時間はかかる「網羅的な洗い出し」も、AIなら一瞬です。

圧倒的スピードでユーザーストーリーとフロー図が完成しましたが、これでテスト設計が完了したわけではありません。

正直に言えば、製品固有の仕様や、特殊な条件下での仕様に基づいた補完は、やはり人間の手による修正が必要です。

しかし、その事実はAIの価値を損なうものではありません。なぜなら、人間が複数のユーザーストーリーを作成する際、ゼロからこの量を書き出すには数日かかりますが、AIはそれを数分で「たたき台」として提供してくれたからです。

「白紙の状態から悩みながら書く」時間をゼロにし、「出来上がったものを現場の視点でブラッシュアップする」時間に充てる。

面倒な「作業」をAIに任せることで、人間は本来時間を費やすべき「どうすればもっと良くなるか」を考えることに集中できる、そんな相棒と言える存在です。

設計フェーズ3: テストケース化

次は、作成したユーザーストーリーを、Playwright MCPで実行可能なテストケース（CSVファイル）へと変換する工程です。

ここでの私の仕事は、データの「器（列構成）」を定義するだけ。中身の作成はすべてAIにお任せしました。

カラム

テストケースの例

ユーザーストーリー構築の実例として、前項のストーリーをベースにテストケースを作成しました。

Cursorに指示を出して出力された実際のCSVファイルがこちらです。

（一部の具体的なパラメータなどは伏せ字にしています。）

テストケース

特筆すべきは、このファイル内の「手順」や「期待値」などのテキストを、私は1行たりとも書いていないという事実です。

私が渡したのは「カラムの枠組み」だけで、具体的な操作手順も、検証すべきURLや画面文言も、すべてAIが「サイト巡回（仕様調査）」で得た知識から自動的に導き出し、埋めてくれたものです。

もちろん、これをそのままテストに使えるかと問われれば、答えは「NO」です。

最終的には、手順の不足を補ったり、期待値を精査したりと、「人間の目による見直しと修正（チューニング）」が不可欠です。

「テストケース（What）」と「実行手順（How）」を同時に生成する

ここで注目していただきたいのが、「Playwright MCP実行手順」列の存在です。通常、テストケース作成と自動化スクリプトの実装（コード記述）は別工程になりがちです。しかし、AIを活用すればこれらを同時に生成できます。

私はCSVファイルで枠組みを渡す際、AIにこう指示しました。

「E列（手順）を実現するための具体的なPlaywright MCPの操作手順を記述して」

するとAIは、直前のサイト調査フェーズで得た知識（画面のIDやセレクタ、URL構造など）を調査レポートから読み解き、具体的な操作手順まで一気に書き出してくれました。

簡単な指示で、「設計した瞬間に、AIが実行可能なマニュアルも完成している」という状態を作り出せました。

プログラミング知識がないQAエンジニアでも、このI列を見れば「AIがどう動こうとしているか」を理解・修正でき、スムーズに自動テストへの一歩を踏み出すことができます。

補足：テストケースのフォーマットについて。

生成されたデータを見ると、IDがユースケース単位で共通化されていたり、1つの手順に複数の期待値が含まれているような構成になっています。実際の現場では「ステップごとのユニークID付与」や「1手順につき1期待値」などのルールが決まっていることも多いでしょう。その場合は、プロンプトでルールを詳細に指示するか、「このサンプルと同じ形式で出力して」と既存のテストケースを数行インプットとして渡すことで、AIの出力を自社の形式に完全に合わせる必要があります。

さらなる安定性を求めて：スクリプト化への道

もちろん、このCSVファイルを「設計図」として、AIにPythonやTypeScriptのテストスクリプトへ変換してもらうことも可能です。スクリプト化することで、CI/CDパイプラインへの組み込みや、複雑な条件分岐の制御がより容易になり、堅牢なテスト基盤を構築できるメリットがあります。

ただ、今回は「誰でもすぐに始められるユーザー中心テスト」を実証するため、あえてスクリプト化までは行わず、このCSVファイルの指示内容（Playwright MCP実行手順）をAIに直接読み込ませて実行するアプローチを採用しました。

実行フェーズ：Playwright MCPによるテスト実行

テストケースの準備が整いました。いよいよ自動実行のフェーズです。

机上で作成したものが実際にブラウザ上でどう動くのか。ここからはAIとの答え合わせの時間です。

注意

今回の検証ではまず「メインフロー（正常系）」の疎通確認を優先するため、前段のフロー図で洗い出した代替フローや例外フローはあえてテスト対象から除外して実行します。

以下は実行時のログの一部です。

一見問題なく進行していますが、しばらく実行していると、リンクの踏み間違いなどの「迷い」が生じている場面もあります。

しかし、従来のスクリプトテストと決定的に違うのは、「間違った画面に遷移した」と自ら判断し、ブラウザバックして軌道修正する点です。

実行2

このように、多少の想定外があっても自律的にゴールを目指す挙動は、人間が操作しているプロセスそのものです。

初回実行で発見した2つの問題

初回実行はプロンプト調整の甲斐もあり、最後までテストを実行できました。が、実行中、AIの挙動に不自然な点が二つ見つかりました。

不自然な挙動1: サンプル動画視聴後の不自然な遷移

前提：この時渡していたテストケース記述。

手順: サンプル動画画面を閉じる
期待値: 商品詳細画面に遷移する

私の脳内（暗黙の前提）: 「サンプル再生画面が閉じれば自動的に商品詳細画面に戻るから問題ないよね」

しかし、AIの解釈と行動は違いました...

サンプル1

なぜこうなったのか？

私は「動画を閉じれば元の画面に戻る」ことを暗黙の了解としていましたが、AIには「どう戻るか」が指示されていませんでした。そのため、AIは文脈に依存せず、確実に商品詳細画面へ辿り着ける「トップからの再検索」という遠回りなルートを選んでしまったのです。

不自然な挙動2: カート追加の非効率な動線

前提：この時渡していたテストケース記述。

手順: CDをバスケットに追加する
期待値: バスケットにCDが追加される

私の脳内（暗黙の前提）: 「さっきお気に入りに追加したCDを、そのままバスケットに追加してくれるよね」

ここでも、AIの解釈と行動は違いました...

サンプル2

なぜこうなったのか？

私は「直前にお気に入りに追加したCD」という文脈をAIが利用すると期待しましたが、AIは「CDをバスケットに追加する」という指示を独立したタスクとして解釈しました。直前で実施した手順の文脈を理解できずに、確実に対象商品を見つけるために「トップからの再検索」という遠回りなルートを選んでしまったのです。

「察して」が通用しないもどかしさ

この2つの事例はエラーではありませんが、ユーザーの行動としては不自然であり、AIと人間の「常識」のズレを象徴するものでした。 AIには「直前の文脈」や「人間の経験則」が通用しないこと、そして手順の省略が「迷走」を生むことを痛感しました。手順が抽象的だと、AIは「さっきのアレ」といった文脈を利用できず、目の前の画面から確実に実行できる（結果として遠回りな）ルートを選んでしまうのです。

一見理不尽にも思えますが、人間なら「常識」で補完できる部分も、具体的に指示しないと動けない、この「実直すぎる癖」もまた、現在のAIの特性と言えるかもしれません。

ケースの記述と実際の挙動を一致させるには、このAIの癖に寄り添いながら、AIに伝わる言葉で「明確な手順」を再定義（プロンプト化）していく必要がありました。

この過程は、複雑なコードを書くのとは違い、「新人スタッフに業務手順を丁寧に教える」感覚に近く、誰でも感覚的に取り組める「対話」のプロセスでした。

テストケースの修正と再実行

問題を踏まえ、テストケース（CSVファイル）を修正しました。AIに「察して」もらうのではなく、文脈を明記する方針に変更。

修正内容:

「商品詳細画面に遷移する」→「サンプル動画再生画面を閉じると、自動的に商品詳細画面に戻る」
「CDをバスケットに追加する」→「お気に入り一覧に登録済みのCDをバスケットに入れる」

修正後の再実行では、すべての操作が人間の操作と同様の自然な動きで完了しました。

テストデータは「生きたデータ」を使うべき

テスト実行中に痛感したもう一つの重要なポイントは、テストデータの「鮮度」です。

今回の実行では、テストサーバーにある商品データのステータスが想定していたものではなかった（以前使用した時から変わっていた）ため、中断するケースがありました。

データ

AIは指示に対して忠実です。そのため、検索キーワード（商品名など）が古くてヒットしなかったり、対象商品が予期せず「取り扱い終了」になっていたりすると、人間のように「似た商品で代替する」といった機転を利かせるのではなく、そこで正直に立ち止まってしまいます。

「ロジックは正しいが、データが古い」

この事象を防ぐためには、テストケースのロジックだけでなく、「今、その環境で有効なデータ」を慎重に選定・管理することが、AIテスト成功の鍵であると再認識しました。

まとめと今後の展望

今回の成果

劇的な工数削減と質の向上

AI導入の成果をフェーズごとの工数削減率で比較しました。ここから、「AIの得意な領域」と「人間が注力すべき領域」が明確に見えてきます。

今回の実行フェーズの数値は、全ユーザーストーリーの中から一部を抜粋して実施した結果に基づく考察です。全量への適用は今後のステップとなります。

圧倒的な「初速」の向上

「回帰テストに対してAIを適用する」という当初の目的に対して、サイト構造の把握やユーザーシナリオなどの洗い出しといった「ゼロからイチを作る（たたき台作成）」工程において、AIは圧倒的なパフォーマンスを発揮しました。人間が数日かける作業をわずか数時間で完了できる点は、AI導入の最大のメリットと言えます。

複雑さと向き合う「調整」の時間

一方で、「テストケース化」の削減幅は0〜30%と限定的であり、かつ結果に幅があります。これは、対象となるユーザーストーリーの規模や複雑度によって、AIの生成精度が変動するためです。

単純なフローであれば一瞬で完了しますが、複雑な条件分岐を含むユーザーストーリーの場合、「AIが生成した手順の動作確認」や「意図通り動かすためのプロンプト調整（チューニング）」に、人間がじっくり時間を割く必要があります。

結論：AIと人間の役割分担が明確になった

AIが生成したものを調整する作業は確かに必要ですが、それはあくまで通過点に過ぎません。本質的な成果は、単純作業から解放された私たちが、「ユーザーにとって本当に使いやすいか？」という、プロダクト品質を向上させるための思考に時間を割けるようになったことです。 AIには「仕様どおりに動くか」の検証（Verification）を任せ、人間は「ユーザーにとって価値があるか」の妥当性確認（Validation）に向き合う。このシフトこそが、AI時代におけるQAエンジニアの新しいあり方かもしれません。