Upgrade to Pro — share decks privately, control downloads, hide ads and more …

生成AI活用で「品質」と「開発生産性」を両立 〜 テスト自動化のいまを知る

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers. →
Avatar for MagicPod MagicPod
September 30, 2026

生成AI活用で「品質」と「開発生産性」を両立 〜 テスト自動化のいまを知る

2026/9/29~9/30
未来をつくるテクノロジー展 日経クロステックNEXT 東京
AIリーダーズEXPO
https://events.nikkeibp.co.jp/xtechnext/2026tky/

セミナー資料

Avatar for MagicPod

MagicPod

September 30, 2026

More Decks by MagicPod

Other Decks in Technology

Transcript

  1. 自己紹介 MagicPod エバンジェリスト 伊藤 由貴 / Yoshiki Ito QAエンジニア・テスト自動化エンジニアを 10年以上経験。

    テスト自動化技術の普及推進チーム立ち上げや、 事業会社でのQAチーム立ち上げを経て、 2025年よりMagicPodエバンジェリスト。 『ソフトウェアテスト技法練習帳』共著。 JSTQBテスト自動化エンジニアシラバス 翻訳メンバー。
  2. MagicPodの生成AI関連機能 MagicPodは、テスト作成のMagicPod Autopilot、結果確認のAIアサーション、 メンテナンスのAI自動修復の3つの機能を搭載し、自動テストの継続を強力にサポートします。 テスト作成 テスト結果確認 テストメンテナンス MagicPod Autopilot AIアサーション

    AI自動修復 ユーザーの指示に基づき、テスト 画面の内容やテキストを理解し、 UIに変更があった場合に、AIがテ を自動で作成します。既存テスト 従来は人間が検証する必要があっ ストケース側の修正を提案・修復 の修正などにも幅広く対応しま たテスト項目も自動化します。 します。 す。
  3. ワークフローの全体像(例) 1.仕様変更 人間が生成AIを活用し、 仕様変更を ドキュメントとして まとめる。 テスト観点(オプション) テストに関連する 社内ナレッジ集 2.コード改修

    ClaudeやCodex等のAIが仕様変更を読み、 必要な改修を自動で行い、 完了し次第テスト環境にデプロイ。 3.テストケース更新 2と並行し、AIが仕様変更を読み、 既存テストケース中の影響範囲を分析。 該当箇所と変更すべき内容を判断し、更新。 4.自動テストの修正・実行 テストケースの更新内容を読み、 実装済みの自動テストを修正。 テスト環境に対して実行し、 テスト更新とコード改修を確認。
  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の「対応状況」とテストケース一覧の両方に結果を書き戻す ``` (以下略)