1. はじめに
ナレッジワークでQAエンジニアをしているguncha(@gun_chari)です。
この記事は、「KNOWLEDGE WORK Blog Sprint」13日目の記事になります。
2024年11月にAnthropic社がModel Context Protocol（MCP）を発表して以降、2025年3月のPlaywright MCPの登場に加え、ナレッジワーク社内では社内汎用MCPも開発され、QA業務における新たなAIツール活用の可能性が生まれました。テスト分析や設計におけるAIツールの活用が広がる一方で、私はテスト実行フェーズにおけるMCP活用の可能性に特に興味を持ちました。
そこで2025年7月、Cursor + 社内汎用MCP + Playwright MCPを組み合わせたテスト実行実験に取り組みました。まだ本格運用には至っていませんが、自然言語で記載された簡単なテストの実行や想定外のテスト観点の発見など、一定の手応えを感じました。
本記事では、実験の背景、実験内容と結果、実験の効果、そして今後の展望について共有します。
2. 実験の背景
ナレッジワークでは、QAエンジニアがTestDesignDocを作成し、テスト分析・テスト設計の成果を管理しています。リグレッションテストについてはPlaywright × TypeScriptを用いたE2E自動テストが毎日実行されていますが、新規機能開発や既存機能の変更時の初回テスト実行は主に手動でのブラウザ操作に頼っており、一つひとつの操作と結果確認に時間がかかる場合がありました。
また、昨今のAIツールの台頭により実装スピードが向上する中で、開発プロセスの中でテスト実行フェーズがボトルネックになるリスクを感じていました。
3. 実験内容と結果
実験の概要
Cursorチャットから、社内汎用MCPのナレッジ取得toolを利用してTestDesignDocを読み込み、その内容をもとにPlaywright MCPを用いてテスト実行するように指示を与えました。
実験環境の構築
Cursorの「Cursor Settings > MCP & Integrations > New MCP Server」から社内汎用MCPとPlaywright MCPを設定しました。Playwright MCPの詳細な設定方法については、Playwright MCPの公式リポジトリをご参照ください。
テスト対象
今回のテスト対象は、パスワードログイン機能としました。TestDesignDocには、基本的なログインまでのフローの確認や、ログインエラーや監査ログに対するテストなど、多岐にわたるテスト観点が自然言語で記載されていました。
実験の実施
パスワードログイン機能の中で、まずはログイン処理を伴わないログインエラーのテストに絞って2回の実験を実施しました。
1回目の実験：社内汎用MCPでのTestDesignDoc参照失敗も想定外の発見あり
最初の実験では、以下のようなプロンプトを与えました。
ナレッジワークの「TestDesignDoc： パスワードログイン」の「テスト観点」の「ログインエラー」のテストを実行してください。
プロンプトで環境を指定していなかったため、利用可能な環境について質問され、回答しました。 その後、社内汎用MCPでのTestDesignDoc参照に技術的な問題が発生しましたが、Playwright MCPが以下のような観点から即興でテストを実行しました。
基本UI要素のテスト
メールアドレス入力欄、パスワード入力欄、ログインボタンの存在と動作が確認されました。
バリデーション機能のテスト
フォーム入力時のボタン状態変化や入力チェック機能が検証されました。
認証プロセステスト
無効な認証情報での適切なエラーハンドリングが実行されました。
アクセシビリティ観点のテスト
キーバインド操作によるアクセシビリティ観点のテストなど、私がTestDesignDocで意識していなかった観点まで自動で実行されました。
また、「テスト実行結果を.mdで出力して」と指示したところ、「パスワードログインテスト実行PoC.md」といったタイトルで以下のようなテスト実行結果も出力できました。
上記のテスト実行結果レポートを見て、「本当に社内汎用MCPを利用してTestDesignDocを参照してテスト実行しましたか？」と質問したところ、社内汎用MCPのナレッジ取得toolが利用できなかったため、自分で考えたテスト観点をもとにテストを実行した旨の返答がありました。
2回目の実験：社内汎用MCP + Playwright MCP連携に成功
2回目の実験は、社内汎用MCPでナレッジ取得toolを利用できる状態に修正してから実施しました。以下のようなプロンプトを与えました。
ナレッジワークの「TestDesignDoc： パスワードログイン」の「テスト観点」の「ログインエラー」のテストを実行してください。 TestDesignDocに記載されているエラー文言と実際に画面に表示されたエラー文言が一致しているかは句読点を含めて確認してください。取り消し線がついているテストはスキップして大丈夫です。環境は [テスト環境URL] を利用してください。
TestDesignDocの参照に成功
社内汎用MCPのナレッジ取得toolにより、TestDesignDocの詳細な仕様を直接取得し、その内容をもとにしたログインエラーのテストを実行してくれました。
TestDesignDocに意図的に埋め込んだ誤りの検出に成功
TestDesignDocの内容を本当に参照できているか確認するため、TestDesignDocに「誤った期待結果」を意図的に埋め込んで検証しました。例えば、パスワードの文字数超過時の実際の期待結果は「ログインボタンがDisabledになる」なのですが、TestDesignDocには「『パスワードが長すぎます』というエラー文言が表示される」といった間違った期待結果を記載しておきました。その結果、MCPが実際の挙動と期待結果の差異を正確に検出することに成功しました。
4. 実験の効果
ハルシネーションによる新発見
今回の実験で印象的だったのは、社内汎用MCPのナレッジ取得toolが利用できなかったことにより、結果的に私が想定していなかった観点のテストが実行されたことでした。キーバインド操作によるアクセシビリティ観点のテストなど、TestDesignDocでは考慮できていなかったテストが自動で実行されました。技術的には問題のある動作でしたが、結果的に未考慮の観点を発見するという予期しない価値を生み出しました。
誤り検出の確認
2回目の実験では、TestDesignDocと実際の挙動の差異を正確に検出できました。意図的に誤った期待結果を埋め込んだケースでも、実際の挙動とドキュメントの食い違いを的確に指摘してくれました。ただし、今回はログインエラーという比較的単純なテスト対象だったため、より複雑な機能での検出精度は今後の検証が必要です。
手動テストとの比較
従来であれば、今回対象としたログインエラーのテストもE2E自動テストが実装されていない段階においては手動でのブラウザ操作が必要でした。今回の実験では、この限定的な範囲において、自然言語で記載されたTestDesignDocを直接参照することでテスト実行を代行することに成功しました。
ただし正直なところ、MCPの設定作業やトラブルシューティングを含めると、現時点では手動実行の方が速かったであろうことが実情です。しかし、MCP設定は初回のみの作業であり、Rulesの活用やテスト環境情報の事前保存などの工夫により、今後の効率化が期待できます。
5. 今後の展望
今回の実験を通じて、MCP活用による初回テスト実行には2つの方向性があることが見えてきました。
①探索的テストへの活用
1回目の実験で社内汎用MCPが期待通りに動作しなかった際、Playwright MCPが即興でテストを実行し、アクセシビリティ観点など想定外のテスト観点を発見してくれました。この経験から、「特定の機能について、Playwright MCPに探索的テストを実行してもらう」という新たな活用方法の可能性に気づきました。事前に詳細なテストケースを準備することなくMCPに探索的テストの実行を任せることで、QAエンジニアでは思いつかない観点での検証が期待できそうです。特定の機能に対し、完全なフリースタイルでお任せする場合、テストチャーターを与える場合などのパターンで実験をしてみます。
②より複雑な設計済みテストの実行
2回目の実験では、TestDesignDocの情報をもとに限定的なログインエラーのテスト実行の成功を確認できました。今後はTestDesignDocに記載された情報をもとに、より複雑な機能や複雑なテスト観点での実行を試していき、実際のQAプロセスへの組み込み可能性を探っていきます。テスト観点の記載方法も重要であろうため、直近では以下の記事を参考にGherkin 構文に近い形式でTestDesignDocにテスト観点を記載し、テスト実行の試行錯誤をしています。
また、AIツールの変化が激しい時代であることを考慮し、実験結果がまとまり切るのを待たずに、今回のような実験の途中段階での発信も続けていきたいと思います。
6. まとめ
今回、Cursor + 社内汎用MCP + Playwright MCPを組み合わせた新規機能開発や既存機能の変更時の初回テスト実行を想定した実験を行い、限定的な範囲ながら手動テスト実行の代行に成功しました。特に印象的だったのは、技術的な問題により発生したハルシネーションが、結果的に想定外のテスト観点を発見するという予期しない価値をもたらしたことです。
この経験から、今後は探索的テストへの活用とより複雑な設計済みテストの実行という2つの軸で実験を継続していきます。AIツール活用により実装スピードが向上する中で、新規機能開発や既存機能の変更時の初回テスト実行の効率化は重要な課題であり、MCPやその他ツールの活用による解決の可能性を引き続き探っていきます。
同じような取り組みを検討されている事例、ご感想、実験へのアドバイスがありましたら、ぜひXでハッシュタグ #kw_blog_sprint を添えてお聞かせください！
KNOWLEDGE WORK Blog Sprint、明日の執筆者は sisisin さんです！
Views: 0
