Share
Embed
生成AI活用で「品質」と「開発生産性」を両立 〜 テスト自動化のいまを知る
2026/9/29~9/30
未来をつくるテクノロジー展 日経クロステックNEXT 東京
AIリーダーズEXPO
https://events.nikkeibp.co.jp/xtechnext/2026tky/
セミナー資料
MagicPod
September 30, 2026
Transcript
22 slides
-
自己紹介 MagicPod エバンジェリスト 伊藤 由貴 / Yoshiki Ito QAエンジニア・テスト自動化エンジニアを 10年以上経験。
テスト自動化技術の普及推進チーム立ち上げや、 事業会社でのQAチーム立ち上げを経て、 2025年よりMagicPodエバンジェリスト。 『ソフトウェアテスト技法練習帳』共著。 JSTQBテスト自動化エンジニアシラバス 翻訳メンバー。 -
生成AI活用の現状と開発生産性 ソフトウェア開発の現場では、ソースコード生成やテストケース生成、自動テ ストの実行など生成AI活用が拡大。AIを活用した開発生産性向上が求められて いる。 しかし、目先の開発生産性のみを追求すると弊害もある。 障害対応、不具合修正をはじめ開発部門以外も含めた負荷がかかる 目先の生産性が上がっ(たように見え)ても、ユーザーに届ける価値の生産性が上が らない “品質保証の時間を削ってリリース日を守ると、障害はリリース後に一気に噴き出しま す。リリース後30分で20件を超える問い合わせが入るといった事態は、削った検証時
間の請求書として返ってきます。 ” 引用:スピードの誤解 ~「速く出せば生産性は上がる」は本当か~|CodeZine(コードジン) -
システム(E2E)テストの自動化とは クリックや文字入力などの画面操作、画面表示の確認などをコンピュータで実行可能な形で 実装。主に新規追加・改修箇所以外に影響が出ていないことを確認する回帰(リグレッション) テストで活用できる。 テストの効率化が期待できる一方で、自動化に関するタスクも発生。 現場レベルでは「自動化の導入に失敗した」 「結局手動テストに戻ってしまった」といった声も よく耳にした。 効果:テストの効率化 テストの頻度向上
テストの範囲拡大 不具合をスピーディに検知 課題:工数増リスク vs 自動化そのものの手間 メンテナンスが手間 運用の手間 -
生成AI活用が進み、テスト自動化も行いやすく テスト分野における生成AI活用の例 テストケース生成 テストケースの優先順位付け テストの拡充・改善 自動テストの生成・編集 期待結果の判定 テスト自動修復 自動テストの 作成・メンテナンス・運用効率UP
不安定さの軽減 工数増リスクを抑え、自動テストを破綻せずに運用できる -
MagicPodの生成AI関連機能 MagicPodは、テスト作成のMagicPod Autopilot、結果確認のAIアサーション、 メンテナンスのAI自動修復の3つの機能を搭載し、自動テストの継続を強力にサポートします。 テスト作成 テスト結果確認 テストメンテナンス MagicPod Autopilot AIアサーション
AI自動修復 ユーザーの指示に基づき、テスト 画面の内容やテキストを理解し、 UIに変更があった場合に、AIがテ を自動で作成します。既存テスト 従来は人間が検証する必要があっ ストケース側の修正を提案・修復 の修正などにも幅広く対応しま たテスト項目も自動化します。 します。 す。 -
テスト結果確認:AIアサーション 「AIで確認」コマンドは画面の情報をAIが読み取って、意味を理解した上で検証します。 これまでは人間による目視確認が必要だったテスト項目も、自動化できるようになりました。 1 検索欄に「東京都千代田区」と入力 2 検索ボタンをクリック 3 OK! OK!
千代田区 検索結果画面で「千代田区に位置アイコン が表示されているか」を AIで確認 千代田区にアイコンが 表示されています -
ワークフローの全体像(例) 1.仕様変更 人間が生成AIを活用し、 仕様変更を ドキュメントとして まとめる。 テスト観点(オプション) テストに関連する 社内ナレッジ集 2.コード改修
ClaudeやCodex等のAIが仕様変更を読み、 必要な改修を自動で行い、 完了し次第テスト環境にデプロイ。 3.テストケース更新 2と並行し、AIが仕様変更を読み、 既存テストケース中の影響範囲を分析。 該当箇所と変更すべき内容を判断し、更新。 4.自動テストの修正・実行 テストケースの更新内容を読み、 実装済みの自動テストを修正。 テスト環境に対して実行し、 テスト更新とコード改修を確認。 -
ワークフローSKILLの例 --name: spec-change-impact-sync description: 仕様変更のDesignDoc(Notion)を起点に、既存E2Eテストへの影響分析、MagicPodでのテスト修正・新規テスト作成、一括実行での検証、Notionへの結果反 映までを一気通貫で自動実行する。 「仕様変更をテストに反映して」 「この仕様変更の影響分析して」 「DesignDocを見てMagicPodのテストを直して」など、Notion上の仕様変更ドキュメントを起点にE2Eテ スト(MagicPod)を追随させたいときに使う。
--# 仕様変更 影響分析&テスト同期スキル Notion上の仕様変更ドキュメント(DesignDoc)を起点に、 「既存のE2Eテストが壊れないか」 「新しいテストが必要か」を判断し、MagicPod上のテスト修正・新規作成・実行検証、そしてNotionへの結果反映までを一つの流れとして進める。 ## いつ使うか - Notionに仕様変更のDesignDoc(変更前/変更後、期待される挙動が書かれたページ)があり、それがE2Eテストに与える影響を確認・反映したいとき - 「このDesignDocの内容をMagicPodのテストに反映して」のように、Notion→MagicPod→Notionの一連の流れをまとめて頼まれたとき ## 全体の流れ(5フェーズ) ``` 1. DesignDoc確認 Notionの仕様変更ドキュメントを読み、変更前/後・期待挙動を把握する 2. 影響分析 既存のE2Eテストケース一覧を読み、どのテストが影響を受けるか判定する 3. テスト対応 影響を受けるテストを修正し、必要な場合は新規テストを作る(テスト観点DBを参照) 4. 検証 個別実行→一括実行(バッチラン)で全体が壊れていないことを確認する 5. Notion反映 DesignDocの「対応状況」とテストケース一覧の両方に結果を書き戻す ``` (以下略)