生成AIエージェントを用いた、 手動テスト手順書から自動テストへの 変換手法の検討

2026/9/11開催
ソフトウェア品質シンポジウム(SQiPシンポジウム) 2026 B3-1 経験発表資料

Transcript

1. ソフトウェア品質シンポジウム2026 【B3-1】経験発表 生成AIエージェントを用いた、 手動テスト手順書から自動テストへの 変換手法の検討
2. 目次 1. はじめに 2. 取り組みの背景 3. テスト手順書の特徴の違い 4. テスト手順書の変換の手法 5. 手法の評価 6. 活用事例 7. まとめ
3. 発表の概要 システムテスト自動化において、既存のテスト手順書をインポートして自動化 したいというニーズがある。しかし、工夫無しにインポートするとさまざまな 不都合が生じる。手動実行用のテストと自動実行に適したテストとで条件や前 提が異なるためである。 そこで、生成AIを用いて手動実行用のテスト手順書を自動テスト向けの手順書 に変換する方法について検討した。結果、手動テストをそのままインポートす る場合と比べて自動化成功率が向上した。
4. 自己紹介 MagicPod エバンジェリスト 伊藤 由貴 / Yoshiki Ito QAエンジニア・テスト自動化エンジニアを 10年以上経験。 テスト自動化技術の普及推進チーム立ち上げや、 事業会社でのQAチーム立ち上げを経て、 2025年よりMagicPodエバンジェリスト。 『ソフトウェアテスト技法練習帳』共著。 JSTQBテスト自動化エンジニアシラバス 翻訳メンバー。
5. ノーコードテスト自動化ツール AIが自動テストの作成からメンテナンスまでサポート。 効果的なテスト自動化で、開発全体の効率UPへ。
6. 目次 1. はじめに 2. 取り組みの背景 3. テスト手順書の特徴の違い 4. テスト手順書の変換の手法 5. 手法の評価 6. 活用事例 7. まとめ
7. 取り組みの背景：システムテスト自動化時の課題 MagicPodの導入やユーザー支援の際によく聞く意見・コメント テストケースがすでに存在するが、これを手動で自動化する余裕がない 既存の手動テストを効率的に自動化したい 昨今は生成AIを活用し、自然言語で記載されたテスト手順をもとに 自動テストスクリプトへと変換できるツールも存在する。 そのため、生成AIを使えば既存のテストを一気に自動化することも 可能に思える。
8. 利用例 ❶ ホテルの予約サイト ホテルの予約サイトに必要項目を入力するテストの生成 入力した指示 宿泊日は2025/08/04、2泊、2人、確 認連絡は希望せず、適当な名前を入力 し、確認ページへ進んで宿泊予約をし てください。
9. 利用例 ❶ ホテルの予約サイト テストステップが生成され、テスト実行まで自動で完了 生成された テストステップ
10. 生成AIによるテスト作成：Playwright Agents Playwright v1.56: From MCP to Playwright Agents
11. 取り組みの背景：単純な自動化の問題点 しかし、AIに対して既存のテスト手順書を渡すだけでは 手動テストと自動テストでは適切な粒度や実行単位が異なる 人間に理解できる手順であっても、AI（および自動テストツール）に理解できない といった理由から、作成した自動テストが適切に動かない、 テストケースの数が多すぎる、等の問題が生じる。 そのため、生成AIを用いて手動テスト手順書を自動テスト向けに再構成し、 それを自動テストツールと生成AIで自動化するという流れを考えた。
12. 目次 1. はじめに 2. 取り組みの背景 3. テスト手順書の特徴の違い 4. テスト手順書の変換の手法 5. 手法の評価 6. 活用事例 7. まとめ
13. 手動テストと自動テスト、テスト手順の違い 前提事項として、 一般的な手動テスト手順書のフォーマットのパターン 手動実行を前提として作成されたテスト手順書の特徴 手動テストと自動テスト、それぞれに適した書き方の違い などを確認。
14. 手動テスト手順書のフォーマット スプレッドシート形式 ページ形式 0~複数の操作と1つの確認項目 1テストケースあたりの粒度が細かめ（1行1ケース） 複数の操作と複数の確認項目 1テストケースあたりの規模が大きい ページ形式に対しても本手法の適用は可能だが、採用割合が少なく見えること や、本手法の適用必要性が少ないことから、 今回はスプレッドシート形式を対象とする。
15. スプレッドシート形式のテスト手順書のサンプル
16. 手動テスト手順書の特徴 操作手順や確認項目の記述の抽象度が高い テスト担当者のドメイン知識や経験を前提とした省略が存在 例： 「初期状態に戻す」 「承認フローを通す」 1ケースの粒度が細かい ユーザーが行う一連の処理が複数のテストケースに分かれている テストケース間の依存関係が強い 手順書の上から下へと続けて実行した場合の効率が最大化されている 前のテストケースの終了状態が次のテストケースの事前条件 開いている画面や作成したデータ等を引き継ぐ前提
17. 自動化に適したテスト手順の特徴 操作手順や確認項目の記述が具体的 画面や要素、値を明示した手順が必要 AIエージェントが画面を操作しながら探索する技術や手法もあるが、今回の背景のようにま とまった量のテストケースを自動化する場合には、手順側の具体化のほうが効果的と判断 1ケースの粒度がユーザーの一連の操作に対応 手動テストの粒度をそのまま自動化すると、テストケース数が増え、実行時間や保 守コストも増大する恐れがある テストケースが独立して実行可能 前のテストの状態やデータに依存せず、事前準備が自己完結している 自動実行は手動実行に比べて多少の事前準備オーバーヘッドが許容されるため、依存関係の 解消を優先
18. 手動テスト手順書をそのまま自動化した場合の例 各タブにおけるメニューバーのUIの変化をテストするケース、があったとき 一つのテストケースにまとめて自動化したほうが効率が良い。
19. 手動テスト手順書をそのまま自動化した場合の例 AIはテスト手順書の1行ごと、別の自動テストとして実装してしまった。
20. 手順書の差異を中間ファイルの作成で解決 ここまでの内容から、手動テスト手順書を自動テストに変換する場合、 操作手順・期待結果の曖昧さ テストケースの粒度、およびテストケース間の依存関係のミスマッチ が問題。 そこで、生成AIを用いて中間ファイル＝自動化用のテスト手順書を作成する。 本発表の主な範囲 Input 手動テスト手順書 （Excel） 中間ファイル 自動化用 テスト手順書 Output 自動テストスクリプト （各種ツール）
21. 目次 1. はじめに 2. 取り組みの背景 3. テスト手順書の特徴の違い 4. テスト手順書の変換の手法 5. 手法の評価 6. 活用事例 7. まとめ
22. 手動テスト手順書から自動テスト手順への変換フロー 手動テストケース （全量） 追加知識 （マニュアル等） 自動化可否 判断 画面遷移図 作成 曖昧箇所 検出・修正 画面遷移図 自動化候補 テストケース 自動化候補 テストケース CRUD ・依存分類 依存関係 分析 テストケース 再構成 自動化用 テスト手順書
23. 手動テスト手順書から自動テスト手順への変換フロー 手動テストケース （全量） 追加知識 （マニュアル等） 自動化可否 判断 画面遷移図 作成 曖昧箇所 検出・修正 画面遷移図 自動化候補 テストケース 自動化候補 テストケース CRUD ・依存分類 依存関係 分析 テストケース 再構成 自動化用 テスト手順書
24. 操作手順・期待結果の曖昧さへの対策 画面遷移図作成による曖昧さの検出 テスト手順書を元に画面遷移図を作成させ、到達不可能な遷移等を検出 画面上でどの要素を操作すればいいかわからない、はAIエージェントや自動化ツール側の性 能向上が期待できるし、そもそもシステムのUI/UX設計の問題でもある 単純に「記載が曖昧な点を検出せよ」とだけ指示するより有効な指摘が得られる コンテキスト追加によるAIの自己解決 ユーザーマニュアルや仕様書等を知識として与える 上記の結果、それでも不足している情報があれば人間が補完。
25. 手動テスト手順書から自動テスト手順への変換フロー 手動テストケース （全量） 追加知識 （マニュアル等） 自動化可否 判断 画面遷移図 作成 曖昧箇所 検出・修正 画面遷移図 自動化候補 テストケース 自動化候補 テストケース CRUD ・依存分類 依存関係 分析 テストケース 再構成 自動化用 テスト手順書
26. テストケースの粒度・依存関係への対策 テストケースの粒度を自動化に適したものにするために、 どのケースを連続して実行すべきなのか どのケースは分割すべきなのか 分割＝依存関係が存在する部分に対して、データの準備など適切な処理を追加し、分ける といったテストケースの依存関係を判断する必要がある。 本手法では、以下を行っている。 3種類の依存関係を検出 画面操作のCRUD分類
27. 3種類の依存関係を検出 依存関係を以下の3種類に分類し、それぞれに適した対応を行う。 SUT CRUD
28. CRUD分類 テストケース内の各操作をCRUD（作成・参照・更新・削除）に分類し、 主にデータ準備の要否を明らかにする。 Read → Create Update Delete → →
29. 手動テスト手順書から自動テスト手順への変換フロー 手動テストケース （全量） 追加知識 （マニュアル等） 自動化可否 判断 画面遷移図 作成 曖昧箇所 検出・修正 画面遷移図 自動化候補 テストケース 自動化候補 テストケース CRUD ・依存分類 依存関係 分析 テストケース 再構成 自動化用 テスト手順書
30. 自動化用テスト手順書のサンプル
31. 目次 1. はじめに 2. 取り組みの背景 3. テスト手順書の特徴の違い 4. テスト手順書の変換の手法 5. 手法の評価 6. 活用事例 7. まとめ
32. 本手法の評価 自動化用テスト手順書の良し悪しを単独で評価することは困難なため、 今回はテスト自動化ツールに取り込んだ自動テストが期待通り動作するか で、間接的に中間処理の成果を評価することとした。 評価の範囲 本手法の範囲 Input 手動テスト手順書 （Excel） 中間ファイル 自動化用 テスト手順書 Output 自動テストスクリプト （各種ツール）
33. 補足：応募時点からの状況変化 経験発表への応募時点では本手法による効果が大きい状態であったが、このあと 共有する最新の結果では、手法有無による成功率の差分が少なくなっている。 環境：Claude Desktop Opus4.7 + MagicPod Autopilot MagicPod 45.45% 77.27% 当初本手法は成功率向上を目的の一つとしていたが、AIモデルおよびテスト自動 化ツール側の機能追加や能力向上により、本手法なしの場合の成功率は今後も向 上すると予想される。 今後は、テストケース粒度の調整や依存関係の最適化など、「より保守性の高い 自動テストを生成するための中間処理」として考えるほうが望ましい。
34. 評価方法 1. 本手法の有無による自動化成功率の変化 本手法を適用した自動テスト向けテスト手順を介して変換した場合 単純に「このテスト手順書を自動化して」とAI＆自動化ツールに指示した場合 前者のほうが成功率が高ければ、手法が有効であると考えられる 自動化成功率の考え方は次頁 2. ツールによる成功率変化の影響 本手法の有無による成功率の変化を、PlaywrightAgents、MagicPodの2種類のツ ールで確認 いずれのツールでも、手法適用時のほうが成功率が高ければ、ツールを問わずに有効である ことが期待される
35. 自動化成功率の考え方 生成AI・テスト自動化ツールで作成した自動テストが、 そのままで動作する場合：成功（⚪） 軽微な修正で動作する状態にできた場合：成功（△） 明確な不備があり、自動テストが動かない場合：失敗（×） 手順が不足している、期待結果の確認に誤りがあるなど と判断する。 自動化成功率＝自動化対象ケース数のうち、どれだけの割合が⚪or△か
36. 結果概要 ブラウザテストのサンプル22ケースでの自動テストの成功率 MagicPod 73.91% 100% Playwright 82.61% 100% MagicPod: Claude Desktop(Sonnet5 Medium) + MagicPod MCP, Playwright: ClaudeCode(Sonnet5 Medium) + Playwright Agents
37. ブラウザテストのサンプルテストケース MagicPod自体を対象 ブランチ機能 Chromeバージョン選択機能 テストケースID、大中小項目、事前条件、テスト手順、期待結果で構成 その他の特徴 手順書だけでは読み取れない操作（コンフリクト発生ブランチを事前 に用意）が存在 1つの自動テストにまとめたほうが効率的な操作（タブ毎の表示確認） が存在
38. MagicPodで自動化した際の結果 本手法を適用した結果、自動化失敗が無くなり成功もしくは軽微な修正で の成功が100%となった × ⚪ 16 1 6 73.91% 20 3 0 100.00%
39. Playwrightで自動化した際の結果 本手法を適用した結果、自動化失敗が無くなり成功もしくは軽微な修正で の成功が100%となった × ⚪ 18 1 4 82.61% 22 1 0 100.00%
40. 自動化失敗（×）の原因 MagicPodでの自動化 特定の状態を前提としたテスト手順を作成してしまう 初期表示や、他テストケース実行後の状態 手順で指定したアサーションの欠落 手順で指定していないアサーションを挿入 Playwrightでの自動化 手順で指定したアサーションの欠落 可変値に対して固定値でのアサーション 指定と異なるテストを実装
41. 失敗例：指定と異なるテストを実装 本来は「マージが成功すること」の正常系テストだが、マージが不要な場面では ボタンが非活性であることを確認するテストを勝手に実装。 マージ可能なブランチを作る事前条件を把握できなかった結果、「現在の画面」 を正としたテストを作ったと考えられる。
42. 本手法の適用による効果 情報の不足や自動化可否判断精度の向上 手順書だけでは情報が不足している場合に、適切にユーザー確認を行うようになる AIエージェントに任せると、GUI探索によって不足を補おうとしてしまい、工数とトークン を不必要に消費してしまう 手順書と異なる操作・アサーションの低減 実動作に合わせて操作やアサーションを勝手に改変する、という失敗が減る
43. 目次 1. はじめに 2. 取り組みの背景 3. テスト手順書の特徴の違い 4. テスト手順書の変換の手法 5. 手法の評価 6. 活用事例 7. まとめ
44. 社内での適用事例 MagicPod社では、顧客から受領したテスト手順書をもとに 自動テストの一括作成を行う機会がある。 その際に、本発表の手法に追加で実施している工夫を紹介する。 自動化困難パターンの知識ベースをAIに提供 各種共通化処理の導入
45. 自動化困難パターンの知識ベースをAIに提供 MagicPodの技術的な制約や、実行環境毎の自動化可否などを集約。 変換時に参照させることで自動化可否判断の精度を向上させ、 技術的に困難なテストをAIが自動化しようとする等のロスを避ける。 表：自動化困難パターン表のイメージ（実物とは異なります）
46. 各種共通化処理の導入 Selenium/Playwright等では、保守性の高い自動テストを作成するためのデザ インパターンとしてPageObjectパターン等がよく知られている。 MagicPodにも共通関数を作成・管理する機能が存在するため、これを活用す ることでより効果的な自動テストが作成できる。 実運用時には共通化に関するルールをプロンプトに記載し、 自動化用テスト手順書の中に共通関数の作成と呼び出しについても明記。
47. MagicPodで実際に行なっているフローのイメージ Phase1 分析 テスト手順書 補助資料 自動化可 否判断 分析レポート 画面遷移 図作成 画面遷移図 テストケ ース分析 テストケース Phase2 設計 Phase3 実装 共通関数 設計 共通関数 設計書 プロンプ ト作成 自動化 プロンプト 自動テス ト設計 自動テスト 手順書 自動化 自動テスト 自動化ログ
48. 生成ファイル例 HTML形式で過程を出力し、人間によるレビューや後工程でのAI用インプットに
49. 目次 1. はじめに 2. 取り組みの背景 3. テスト手順書の特徴の違い 4. テスト手順書の変換の手法 5. 手法の評価 6. 活用事例 7. まとめ
50. まとめ 本発表では、主にスプレッドシートに記載された手動テスト用の手順書を自動 テストツールに取り込むにあたり、生成AIを用いて自動化に適した形式に変換 する手法について紹介した。 本手法を適用することで、最終的に自動テストツールに取り込んだ際の成功率 向上や自動テストの保守性向上が期待できる。 本手法のうち、CRUD分析や粒度の判断などは自動化ツールを問わずに適用で きる部分であり、 既存の手動テスト資産を元に自動テストを整備する際の参考にしてほしい。
51. Appendix
52. プロンプト実例：テストケースの再構成 合意した粒度方針に基づき、まずCRUD・依存関係の分析を行い、その結果をもとにグルーピング・分割を判断する。 1. **CRUD・依存関係の分析（先行）**: 後述のA〜E属性（特にA: 操作の性質・D: 依存関係）を 仮判定する。これにより「どのテストケースを一緒にまとめられるか」「どこで分割すべきか」が見えてくる 2. 粒度方針に従い、仮判定結果を踏まえて関連するテストケースをグルーピングする 3. グルーピングしたテストケース群について必要に応じて再分割する - 手順の長さ（目安: 20手順超）は意味のある区切りで分割する 4. 再構成後の各テストケースに新しいID（再構成後テストケースID）を付与する。 5. **トレーサビリティの確認**: 母集団に存在する元テストケースIDが、再構成後のいずれかのテストケースに1件以上 対応していることを確認する。対応漏れがあれば再構成のミスとして扱い、修正する 6. **[レビュー]** 再構成結果（グルーピング方針・トレーサビリティ確認結果）をユーザーに提示し、合意を得る
53. プロンプト実例：依存関係分析観点 **A. 操作の性質** **D. 依存関係** | 分類 | 判定基準 | | ------ | --------- | | 判定 | 基準 | | 参照 | データ・設定を一切変更しない | | :----: | ------ | | 作成 | 新しいデータを追加する | | 独立 | 他テストに依存しない | | 変更 | 既存のデータまたは設定を書き換える | | 順序依存 | 特定テスト実行後の状態を前提とする | | 削除 | データまたは設定を削除・無効化する | | データ依存 | 他テストが作成するデータを使用する | **B. データ準備の要否** **E. 手順の抽象度** | 判定 | 基準 | 対応方針 | | 判定 | 基準 | | :----: | ------ | --------- | | :----: | ------ | | 不要 | 参照のみ、または作成がテスト対象 | そのまま実行可能 | | 具体的 | 操作対象・操作内容・期待結果がすべて明示 | | テスト内作成 | 編集・削除対象のデータをテスト冒頭で作成できる | エポック時変数で名称重複防止 | 部分的に曖昧 | 一部の手順で不明確 | | | 抽象的 | WHATのみでHOWがない | | 外部準備 | テスト内で作成困難 | Setupケースとして設計 | **C. 後片付けの要否** | 判定 | 基準 | 対応方針 | | :----: | ------ | --------- | | 不要 | 参照のみ、または他テストに影響しない | 後片付け不要 | | テスト内復元 | テスト末尾で元に戻せる | 復元ステップを含める | | Teardown必要 | 復元が複雑 | Teardownケースとして設計 |
54. プロンプト実例：自動化可否判定 A〜Eの判定結果を総合し、各テストケースを以下に分類する: | トラック | 条件 | | :-------: | ------ | | ファストトラック | コマンドマッチング全て明確、操作の性質が「参照」か「作成」、データ準備不要orテスト内 作成、依存なし、手順が具体的 | | ノーマルトラック | 一部不明確だがClaudeの推測で補完可能 | | 要確認トラック | 抽象的、外部準備が必要、または自動化困難パターンの「要確認基準」に該当する操作を含む | | 投入見送り | 自動化困難パターンの「不可基準」に該当 |
55. プロンプト実例：共通処理の切り出し #### 共有ステップ化の判断基準 以下の2パターンのいずれかに該当する操作を共有ステップ化する。それ以外はインライン実装とする。 - 繰り返し登場する操作列 - 複数のテストケースで同じ操作列が登場する。画面到達手順の共通化もここに含む（画面ごとの共有ステップをさら に呼び出す上位共有ステップとして実現する） - 2テストケース以上で登場する場合に共有ステップ化 - バリエーション操作 - 同一テストケース内で同じ操作を異なる入力値/状態で繰り返す。呼び出し前に変数（`${変数名}`）に値をセット し、共有ステップを繰り返し呼び出す形で実現する - 同一テストケース内で3回以上繰り返す場合に共有ステップ化 共有ステップ化しないケース: 1つのテストケースでしか使わない操作 ／ テストケース固有の状態に強く依存する操作