手順(プロンプト)だけで テストを自動作成～テスト作成エージェントを使いこなすための 実践プロンプト術

2026年4月8日に開催したmablウェビナーのスライドです。

Transcript

1. 手順(プロンプト)だけで テストを自動作成 テスト作成エージェントを使いこなすための 実践プロンプト術 2026年4月8日(水) 13:00~14:00 | 舟木 将彦 (Sales Engineer, mabl)
2. 今日お伝えすること • 効果的なプロンプトの書き方 • 既存資産の活用 (共通フローの再利用) • ローカル vs クラウド並列作成の使い分け • トラブルシューティング • まとめ・Q&A
3. 事前準備
4. 最新のモデルを適用する 0. 事前準備 ワークスペース > LABS から設定可能な 早期アクセス機能をオンにする ※ LABS で設定可能な機能は 　「ワークスペース単位」にオン／オフの 　設定が可能 → 必要に応じて、現在のテスト用の 　ワークスペースとは別の「実験用」 　ワークスペースを用意して試してみる
5. AIの出力結果で使用する言語を指定する 0. 事前準備 ワークスペース > ワークスペース から設定可能な 生成された成果物の言語を Japaneseにする。 (ワークスペース単位で有効) ※mablデスクトップのUI言語は 　「ユーザー単位」で有効
6. 効果的なプロンプトの書き方
7. テスト作成エージェントとは 1. 効果的なプロンプトの書き方 AIがプロンプトを読んでテストを自動作成 • 入力: テスト手順を記述した内容 (プロンプト) • 処理: エージェントがアプリを実際に操作しながらテストを記録 • 出力: 再実行可能なmablテストケース ポイント • AIはプロンプトを「指示書」として読む • 曖昧な指示 → 意図と違うテストが生成される • 具体的な指示 → 狙い通りのテストが一発で 生成される
8. プロンプトのテンプレート例 1. 効果的なプロンプトの書き方 # {テスト名 } ## テスト概要 - **対象URL**: https://www.example.com/{path} - **テスト名 **: {テスト名 } - **目的**: {1文で記述} - **ラベル**: `ai-generated`, `{カテゴリ}` → 現時点では指定しても適用されない ## 画面構成 {目視で確認できるUI要素の説明、位置関係など } (次スライドに続く)
9. プロンプトのテンプレート例(続き) 1. 効果的なプロンプトの書き方 ## テスト手順 ### 1. {セクション名 } 1. {ステップ } 2. {ステップ } ## 期待される結果 - {箇条書き } ## 注意事項 - {mabl実行時の制約や既知の問題 }
10. テスト作成エージェントでできないこと 1. 効果的なプロンプトの書き方 サポートされていない操作 • ヘルプの「テスト作成エージェントの機能」中の サポートされていない操作を参照 https://help.mabl.com/hc/ja/articles/37947539774612 ポイント • 現時点では「未実装」のためサポートされていない操作と、 技術的に実装が難しいのでサポートされていない操作がある • ここに挙げられていない例としては、「３秒ぐらいで消える メッセージの内容のアサーション」など
11. プロンプトをどう作成するか 1. 効果的なプロンプトの書き方 人が作成する • 前述のテンプレートに沿った形で、人がプロンプトを作文していく • ゼロから作文していくのは (画面上の操作でテストを作成するより )大変な面もあるが、 ◦ アプリが未完成でもテストプロンプトは作文可能 ◦ 実績のあるプロンプトをコピー＆ペーストで再利用可能 (IaCと同じ考え) LLM (GitHub Copilot, Claude Code…) に作成させる • コード生成に使う「仕様書」や「コード自体」から「 mablのテスト生成エージェントがテストを作成するため の操作手順をテンプレートに沿った形で提案してください。」といった形で作成させる • 既存のテスト仕様書からプロンプトを作成させることも可能 • mabl MCPを利用していれば、そのまま mablにテストを作成させることも可能
12. プロンプトの３原則 1. 効果的なプロンプトの書き方 意図通りのテストを生成するために 1. 対象URLを明示する ◦ 「ページにアクセス」するではなく、具体的な URL または アプリケーション名を指定する (mablのアプリ x 環境定義に該当する URLがあれば、そのアプリ x 環境設定が使われる ) 2. UI要素を目視情報で説明する ◦ 「ボタンをクリック」ではなく、「 ログイン と表示されたボタンをクリック」と書く (data-testidのような属性の指定はテスト生成には使われないが指定しても問題はない ) 3. 失敗ケース → 成功ケース の順に書く ◦ バリデーションを先に確認してから、正常操作を行う ◦ エラー処理がもれなくカバーできる
13. NG例 vs OK例 1. 効果的なプロンプトの書き方 顧客新規登録のプロンプト プロンプトの書き方 ❌ NG 「顧客登録フォームを開いて、必要な情報を入力して保存する」 ✅ OK 1. /customers/new に直接アクセスする 2. 名前欄を空のまま保存ボタンをクリックし、エラーが表示されることを確認する 3. 各項目(名前・メール・電話・会社名・ステータス )を入力する 4. 保存ボタン(data-testid=”save-button”)をクリックする 5. 顧客一覧(/customers)に遷移し、登録した名前が表示されることを確認する NG: エージェントが何をテストすればよいか判断できない。 OK: URL・要素・確認内容がすべて明確。
14. デモ① 1. 効果的なプロンプトの書き方 顧客新規登録テストを生成する
16. 既存資産の活用 (共通フローの再利用)
17. 共通フローとは 2. 既存資産の活用 テスト間で再利用できる操作手順のまとまり • 課題: 複数のテストが同じログイン手順から始まる ◦ プロンプトに毎回ログイン手順を書くのは冗長 ◦ ログインURLが変わると、全プロンプトを修正する必要がある • 解決策: ログイン操作を 共通フロー として切り出す 共通フローの使い方 1. mablでログイン操作を共通フローとして保存する 2. 各テストのプロンプトに「ログイン済み状態を前提とする」と記述する 3. エージェントが自動的に共通フローを呼び出してからテストを開始する
18. 共通フロー活用のメリット 2. 既存資産の活用 プロンプトがシンプルになる ログイン手順の記述 共通フローなし 全テストにログインの６ステップを記述 (URL・メール入力・パスワード入力・ボタン クリック・リダイレクト確認・ ...) 共通フローあり 「ログイン済み状態 のダッシュボードから始める」の１行だけ 効果 • プロンプトの記述量: 約60%削減 • 修正コスト: ログインURLが変わっても 共通フロー１か所の修正で完結 • テスト品質: ログイン部分のブレがなくなり、再現性が向上
19. デモ② 2. 既存資産の活用 顧客検索 + フィルターテストを生成する
21. ローカル vs クラウド並列作成の 使い分け
22. ２つの実行モード 3. ローカル vs クラウド並列作成の使い分け ローカル作成 vs クラウド並列作成 項目 ローカル作成 クラウド並列作成 実行環境 手元のブラウザ mablクラウド 同時実行数 1テストずつ 複数テスト同時 生成速度 遅い(直列) 速い(並列) 途中確認 できる できない 向いている用途 試行錯誤・調整 量産・一括生成
23. 使い分けの判断基準 3. ローカル vs クラウド並列作成の使い分け どちらのモードを選ぶか ローカル生成を選ぶ場面 • 新しいプロンプトを初めて試すとき • 生成結果を見ながらプロンプトを改善したいとき • 動的なIDや複雑なUI操作が含まれるとき クラウド並列生成を選ぶ場面 • プロンプトが十分に検証済みのとき • 複数機能のテストをまとめて生成したいとき（例 : 5件以上） • 時間を短縮して一気に量産したいとき 推奨ワークフロー : ローカルで１件検証 → OK なら同じプロンプトの一部を変更したような テストをクラウドで並列生成
24. デモ③ 3. ローカル vs クラウド並列作成の使い分け ３テストをクラウドで並列生成する
25. トラブルシューティング
26. よくある失敗パターン 4. トラブルシューティング テスト生成が失敗する４つの原因 パターン 原因 対処法 要素を特定できない 一覧の複数行に[編集][削除] のように共通するボタンが含 まれる 「テスト太郎の行にある編集 ボタン」のように顧客名で区 別する ステータス選択が動かない <select>を実際に開いてn番 目の項目を選んでいるわけで はない 「ステータスフィルターで 取引 中を選択」のように、選択す る項目値を明記する 確認を含む操作が失敗する ブラウザネイティブの window.confirm を想定して いる カスタムモーダルであれば操 作手順を正しく記述する
27. 本日のまとめ
28. テスト作成エージェントを使いこなす４つのコツ 5. 本日のまとめ • プロンプトには「URL・要素の目視情報・順序」の３つを明示する ◦ 失敗ケースを先に欠くことでバリデーションが自動的に網羅できる • ログインなどの繰り返し操作は共通フローに切り出して再利用する ◦ プロンプトがシンプルになり、保守コストが大幅に下がる • 新しいプロンプトはまずローカルで検証、検証済みならクラウドで並列量産する ◦ 「ローカル検証 → クラウド量産」のワークフローを習慣化する • アプリ固有の挙動(カスタムモーダルなど)はプロンプトに明記する ◦ 失敗したら「AIが判断できなかった情報は何か」を起点に修正する