想像でAIにテストケースを作成させないためのAgent Skills と MCP の活用方法

こんにちは。ダイの大冒険エンジョイ勢のbun913と申します。私はSDET(Software Development Engineer in Test)として、QAチームにいる何でも屋さんの意識で働いています。

みなさんは AI にソフトウェアテストケースを作らせたことはありませんか？私はあります。

要求や仕様などのドキュメントを渡して、規定のフォーマットにテスト技法や注意するべき観点を渡してテストを生成させることがあり、特にチェックの観点のテストケース作成には有効だと感じています。

一方でこんなことを感じたことがありませんか？

• 暗黙の前提条件や設定値が想像で作られてしまっている
  • AI「支払い制限設定を有効にする」
  • 私「そんな設定ないよ」
• 関連する機能の洗い出しなどが苦手
  • 当然次のリリースに関係する資料を渡すので、リグレッションや関連する機能のテストの生成は苦手ですよね

私は非常にあります。自分でテストするならともかく、人に見せるテストケースとしては「AIを使いました」感が丸出しで申し訳なくなってしまう時があります。
（もちろん成果物のチェックはしている前提で、ある程度の曖昧さを許容して早さを優先する時が多いです）

そこで、今回私たちのチームでは Agent Skills + MCP + 根性でこのような課題の解決に動いてみました。

前回までの取り組み

こちらの記事で紹介していますが、前回は Agent Skills + CLIツールを活用して、テストケースを作った後のテストマネジメントツールなどへの保存方法について改善していました。

https://zenn.dev/moneyforward/articles/c43cc7eff468a7

今回は、その前の以下の部分の改善になります。

• 🆕 AIに対する静的なインプットを決める
  • システムプロンプトやコンテキストによらない知っておくべきことなど
• （別途ご紹介） テスト分析・テスト設計でテストケースを生成する
  • AIに対して動的なインプットを与えて、成果物を生成させる
    • コンテキストやその場でのプロンプトなど
  • 成果物のフォーマットを人もプログラムも使いやすい形に調整
• （前回）生成したテストケースをテスト管理ツールに保存する

根性と効率の画面仕様作り

どんなものを作ったのか

さて、今回私がAIの生成するテストの具体的なステップや関連機能のピックアップのために用意した静的なフォーマットは「スクリーンショット付きの画面仕様（マニュアル）」のようなものです。

本当になんだよそれ。という形かもしれませんが、のちに紹介する仕組みを使って WebシステムとモバイルアプリケーションのスクリーンショットをAIに撮らせつつ、最低限テストに必要な観点や過去のバグの情報などを吹き込んでいきます。

構成としてはシンプルに以下のような仕上がりとなります。

/home
├── page.md
├── screenshots/
│   └── hoge.png
└── subpages/
    ├── user_settings/
    │   ├── page.md
    │   └── screenshots/
    └── office_settings/
        └── screenshots/

AIには私が言わずとも以下のようなことを一つのページ、そしてそこから確認できるボタンやリンクについて特徴をマークダウンファイルに書かせていきます。

• ボタンに表示されている文字
  • 押すと何が起こるのか
• リンク
  • どこに繋がるのか
  • リンク先はどんな目的のページか
  • 規約系なら最終更新日はいつになっているか

それに対して私は、以下のような指示を出してドメイン知識のようなものを最低限吹き込んでいきます。

• ドメイン知識
  • そのボタンは実は特殊な事業所でしか表示されないんだよね
  • 一度でもそのボタンを押すともう二度とその注意事項は表示されません
  • その注意事項は実は2人目以降のユーザーにしか表示されないよ
  • その設定項目を有効にしているときのみ、このfugaというマイクロサービスにデータが連携します
    • このURLだよ。もう画面は私が移動しといたからスクショを撮っておいてよ
• テスト/バグに関する知識
  • 実はその設定を有効にした後に、テスト環境の管理画面にアクセスしてこのシミュレーターを実行しないと機能をテストできません
    • URLはこれだよ https://example.com
    • ついでに、この画像がその管理画面のページのスクリーンショットだから一緒に保存しといて
  • そのページは実は設定できる項目が多くて、過去に複数のプロダクト間で表示する順番などが違ったんだよね
    • だから、複数プラットフォームの表示項目が一致しているか確認する必要があるんだよね

また、各 page.md には以下のようなメタデータを保存させるようにしています。

# ユーザーの種類などのどのような人向けの画面か
user: ["admin", "general"]
office: ["foreign", "domestic"]

# 機能やページを示すid
feature_id: office-selection

# 影響を与える画面や機能
affects:
  - home

# 影響を受ける場所や遷移する元
affected_by:
  - login
  - terms-of-use

# 影響を与える外部サービス
external_services:
  - ID_Platform

これらのメタデータは後でプログラムによりパースして、リリース対象の仕様や要求などから抽出させたキーワードやAI使用者との会話を元に、関連する機能やリグレッションテストを機械的にスコアリングするために利用します。

これらの情報を持たせていることにより、AIが想像でテストのステップや前提条件を書くことが大幅に減り、関連機能をテスト対象として抽出する精度が上がったように感じています。

それらを作った仕組み

タイトルにある通り、Agent Skills と MCPサーバーを活用して Claude Code にWebブラウザやモバイルのシミュレーターを動かす力を与えました。

Playwright CLI の活用

以下の記事などにあるように、最近 Playwright CLI が登場して、体感でもMCPを活用していた時よりも早く、かつトークン消費が抑えられるようになりました。

https://zenn.dev/dk_/articles/9db1e90ce8e28f

シンプルに以下のような形で、 SKILL.md を用意してブラウザを操作する方法を覚えてもらいました。

なお、私は rulesync という仕組みを導入しているため記法が少し特殊ですがご了承ください。

---
name: playwright-cli
description: Automates browser interactions for web testing, form filling, screenshots, and data extraction. Use when the user needs to navigate websites, interact with web pages, fill forms, take screenshots, test web applications, or extract information from web pages.
allowed-tools: Bash(playwright-cli:*)
---

# Browser Automation with playwright-cli

## Quick start

```bash
playwright-cli open https://playwright.dev
playwright-cli click e15
playwright-cli type "page.click"
playwright-cli press Enter
\```

また、一度自分で操作していく中でどんなことをしていくか固まってきたら、別途 knowledge-writer という形でスキルを作成し、呼び出すことである程度自動で画面の変化などを更新する仕組みを用意すると非常にスムーズに画面のドメイン知識ファイルを作っていけました。

Maestro MCP によるモバイルシミュレーターの操作

モバイルアプリに対しては、E2Eテストなどを記載できる Maestro が提供してくださっている Maestro の MCPを利用しました。

https://docs.maestro.dev/getting-started/maestro-mcp

あらかじめ Android Studio などを導入しておくことで、エミュレーターをPC上で起動できるようになります。

あとは、Playwright と同じように Maestro の MCP を使うように指示して、Webと同様のスクリーンショットを撮っていき、ドメイン知識ファイルを生成していきました。

注意事項

スクリーンショットを撮っていく関係で、大きなファイルを渡していくと意図せず Claude Code とのセッション内での会話が続けられなくなる事象がよくみられました。

そこでモバイルで取得できるスクリーンショットの解像度を設定で調整したり、本当にどうしようもない時は sips コマンドなどで解像度を調整することもありました。

しかし、一気に作業をしたい時でもいつチャットのセッションが再開できなくなってもいいように、「やっていること」や「どこまでやったか」といったタスクファイルを残しながら行うとスムーズに進めることができました。

なお、そこまで規模が大きくないページ数が40未満のアプリケーションに対して数営業日かけることで1プラットフォーム（Web/Mobile）のだいたいの知識ファイルが生成できました。

最初は本当につらくて挫けそうだったのですが、2回目以降はかなり楽に進められることを信じてやり抜きました。また、途中ですでにスクリーンショットやデザインがある画面はそのままそれらを渡して、「これでページ作って。注意点だけ伝えます」とサボることもありました。

大事なのはドメイン知識や注意点を書いてもらうことなので、サボれるところはサボっていくことが精神衛生上とても良かったです。

テストケース作成時に活用する

あとは、あらかじめ準備しているテストケース作成用の Agent Skills や プロンプトを呼び出す時に、システムに応じたドメイン知識ファイル群を参照してもらうようにしています。

ただし、そのまま参照させるとコンテキストを圧迫してしまうため、以下のような流れで機械的に関連するファイルをユーザーに提案して、ユーザーが許可したファイルのみを参照させるようにしています。

• AIに仕様書やリリースに関するドキュメントを渡す
• その際、今回のリリースに関するキーワードを抽出させ、時にはユーザーから「hoge設定画面が関係する」といったことを伝える
• プログラムで全てのドキュメントのメタデータを抽出し、feature_id や affects などのメタデータと関連しそうなファイルをスコアリングする
  • とても高度に聞こえますが、「外部サービスに関係しそうなものはポイント高いよ」「前提条件となるようなaffected_byはその次くらい」と指示をするだけで、もはやコードはAIが書いてくれるようになったので非常にシンプルに仕組みを作れます
  • システムの規模や性質によっては、この仕組みでは足りずRAGなどを活用される方が良い場面もあるかと思います
• スコアの高い順にユーザーに提案し、ユーザーが指示したファイルだけを読み込む
• あとはプロンプトに従ってテストケースを生成してもらう

といった形で活用をしています。

まとめ

• Agent Skills や MCP を活用してシステムのスクリーンショット付きドメイン知識ファイルを作成しました
• それらのファイルから関係しそうなファイルを抽出して、読み込ませた後に、テストケースを作成してもらうようにしました
• これにより、AIにテストケースを作成させる際に以下の利点が明確にありました
  • 想像で前提条件やテストのステップを書かれることがグッと減った
• これらを半自動で更新する仕組みも用意しているため、最初に頑張ればあとはかなり楽になると信じています
  • 本当に作っている間はつらかったです

また、今回はこの活用方法だけでしたが今後AIにテスト関連の作業をさせる時にも必ず役に立つファイル群になっていると信じています。

もちろん今回ご紹介した方法が合うチーム、システム、規模はそれぞれだと思いますが、何かの参考になれば嬉しいです。

以上、最後まで読んでいただき、ありがとうございました。