『AIに負けない』より『AIと遊ぶ』」〜ワクワクが最強のテスト・QA学習戦略_公開用

JaSST’26 Kansaiで話した資料です。
https://jasst.jp/kansai/26-about/

Transcript

1. 『AIに負けない』より『AIと遊ぶ』 〜ワクワクが最強のテスト・QA学習戦略〜 大段智広 (DMM.com/ASTER) JaSST’26 Kansai 基調講演
2. 大段智広(おおだん ともひろ) 略歴: • 2012年4月 関西のメーカーソフト子会社に入社。その後、ソフト ウェア開発コンサルティング会社を経て、2021年4月より DMM.com所属。現在はQA業務のAI活用を部内で推進。 専門スキル(≒好きな領域) • ソフトウェア開発プロセスアセスメント(CMMI)、ソフトウェアテスティング • UMLモデリング、モデルベースドテスト • E2E自動テスト導入・開発・保守、開発インフラ構築・保守 主な社外活動 • NPO ASTER 理事 (テスト設計コンテスト担当) • ASTER テスト設計コンテスト実行委員兼U-30クラス審査委員長 • ISO/IEEE SC7 WG26 ソフトウェアテスト 委員 • JSTQB技術委員 個人情報: • 元JaSST Kansai実行委員 • 6月に育休明けの二児の父 SNS: • X：@dandan_611 • LinkedIn:Tomohiro Odan • Facebook: Tomohiro Odan 2
3. 目次 3 本講演で伝えたいこと QA/テストエンジニアの現状 いまからの学び方 AI時代の実践事例紹介 まとめ
4. 1.本講演で伝えたいこと 4
5. JaSST’26 Kansai シンポジウムテーマ 「シン・ソフトウェアテスト」 ～ 新時代に築き直すソフトウェアテストの入門・基礎 ▪ 節目となる第20回 ― 原点に立ち返り、次の10年に向けた方向性を描く ▪ AI駆動開発時代に「テストとは何か」「SQAの役割とは何か」を問い直す ▪ 複雑化するソフトウェア社会で品質を支える役割の重要性はさらに増す 本講演は「AIと遊ぶ」視点で、 このテーマを個人の学び方から掘り下げます。 5
6. QAforAI and AIforQAのどっちの話？ この講演では主に「AIforQA」の実践を深掘りしながら、 QAエンジニア/テストエンジニアの学び方を考えます。 QA for AI AIシステム自体の品質保証 ▼本講演の主軸 AI for QA QA/テスト業務へのAI活用 テスト生成・実行・分析・自動化 6 ＆
7. QA/テストって、 ワクワクする技術なんだぜ!!
8. 今日の私の講演ゴール 難しい話は後回し ― まず「楽しそう」と思ってもらうことが最優先！ Goal 1 AI活用の 具体的なイメージを 1つ持って帰ってもらう Goal 2 明日から試せる 学習アクションを 1つ決めてもらう Goal 3 「ワクワク」で テスト・QAに向き合う 気持ちになる 8
9. 2.QA/テストエンジニアの現状 9
10. これからのQA/テストエンジニアはどうなる？ 10 これまで若手が担ってきた「作業」が AIに置き換わることで、 若手が体験して学ぶ場がなくなるのではないか テスト作業の多くは効率化され、 手を動かすことが減り、見極めることが増える AIが出さないであろうテスト観点でテストする人たち 「探索テストのエキスパート」が重宝される エキスパートやマネジメント系をやってきた人に とっては、「誰が」作成したものなのかが変わる だけでやることは実は変わらない 組み込み系など ツールやAIが代替しにくい領域はなくならない AI活用によりベテランは若手に手を借りる 必要がなくなり、若手とベテランの格差が拡大 AIによって バグを狙えていない テストが量産されるのではないか 開発チームとの壁がなくなるのではないか QA/テストエンジニアの仕事ははAIに代替される
11. 良い面、 悪い面 を考えてみましょう
12. 良い面 ― AI時代のQA/テストエンジニアのチャンス • 若手の学びの質が向上する • AIが定型作業を担い、「なぜこのテストが必要か」を考える訓練に集中できる • QA/テストエンジニアはスペシャリストとして価値向上する • コモディティから高度判断・設計・戦略を担う専門職へ • QAが経営・開発上流の戦略的パートナーになる • 品質リスクを可視化する役割として発言力が増す • 機能安全・規制対応領域で需要増大する • AIが担えない「なぜ安全か」の説明責任で人間のQAが不可欠 • 探索的テスト思考・熟練判断力は高付加価値ポジションになる • 人間の「ひらめき・共感」はAIに代替されにくい • テスト品質を評価できるレビュアー需要が急増する • 「AIが作ったプロダクト/テストを批評できる人間」が希少かつ重要なポジションになる 12
13. 悪い面 ― QA/テストエンジニアが向き合うべき課題 ⚫体験なき理解は脆く、大きな失敗が発生しやすくなる ⚫ バグの嗅覚・テスト漏れの感覚は経験で身につく。 ⚫ 若手育成の仕組み再設計が急務。 ⚫新規メンバの参入障壁が高くなる ⚫ 業界への人材供給が細り、中長期的に人材が枯渇するリスクが高くなる ⚫スキルの再教育なしでは中間層が空洞化する ⚫ テスト実行が主業務だったQA/テストエンジニアが急に戦略・判断を求められても、 対応できない ⚫ベテランのAIへの過信が誤出力を見逃す ⚫ 「自分のやり方で問題ない」という過信が批判的評価を妨げる ⚫AIが量産する粗製テストがレビュー負荷を集中させる ⚫ 少数の熟練QA/テストエンジニアに負荷が集中し、疲弊・品質低下が同時に起こ るリスクが高くなる 13
14. 一概には言えないが、 海外ではどうなっている？
15. 【2025年12月】 Momentic — "Will AI Replace QA Engineers?" AIはQAエンジニアを「置き換える」が、その根本原因はAIではなく、 過去10年の業界トレンドとして、QAエンジニアは少しずつ衰退しつつある。 出典：Momentic, Dec 2025 | https://momentic.ai/blog/will-ai-replace-qa-engineers 従来型QAの問題点（2015年からの傾向） AIテストツールがもたらす解決策 ⚫ コストが高い • 10人チームで年間$1M超(予算25%以上) ⚫ リリース速度が低下する • ボトルネックになりやすい ⚫ 組織が分断される • 開発とQAの断絶が品質低下を招く ⚫ バグ発見の遅延する • 修正コスト増加＆リリース遅延する ⚫ Microsoft・Yahooは2015年に独立QA廃止 ⚫ コードレスでのテスト作成（自然言語入力） ⚫ 自己修復テスト（変更に自動追従） ⚫ CI/CDパイプラインとの直接統合 ⚫ AIエージェントが将来的にPRまで自動修正 ⚫ 64%の組織がQAにAIを導入済みまたは計画中
16. 【2026年1月】 Tricentis Transform 2025 — "QA Trends for 2026" 以下の4つの示唆が示されている。 出典：Tricentis / Sarah Welsh, Jan 2026 | https://www.tricentis.com/blog/qa-trends-ai-agentic-testing AI生成コードのリスクが増している • 昨年のコードの40%以上がAI生成。 • 88%の開発者がAI生成コードのデプロイに自信なし (Stack Overflow調査) • 29%がAIエラーによるロールバックを経験 (GitLab調査) QAの役割は根本的に変化している • QAチームの役割は「テストを書いて実行する」から、「品質目 標を定義しAIの出力を監督する」へ。 • AIが失敗するとエンタープライズ規模で失敗する時代に。 Human-in-the-Loopは必須である • AIパイロットの95%が不適切なガバナンスが原因で失敗。 • そのうち60%はコンプライアンス違反。AIは確率的であり、決 定論的ではないため人間の監視が前提となる。 AIをいち早く導入した企業が先行している • 「AIを知る人と知らない人のギャップは今が最も小さい。しか しこのギャップはこれから急速に広がる」 • Sophia Velastegui（元Microsoft Chief AI Officer）
17. 【2026年2〜3月】Applause — "State of Digital Quality in Testing AI 2026" (n=1,000+) 出典：Applause, State of Digital Quality in Testing AI 2026 (survey: Feb-Mar 2026) | applause.com/state-of-digital-quality-2026/ai-report/ AIプロダクト リリースの現実 54.5% がすでにAI機能を リリース済み 44.1% が運用コスト超過を 理由にAI機能を停止 29.6% でAIによる テスト予算が 開発予算より速く増加 高品質チームの共通点 & 警告 完全自律型AIを開発しているのは全体の25%未満。 大半は依然として人間監視が前提になっている 継続的評価ループ・ハイブリッド（人間×AI）テスト・ドメイン 専門家の関与が成功の鍵 「AIにテストを書かせると要件の検証が飛ばされる」— Adonis Celestine（Applause） レッドチームテスト(悪意ある攻撃のテスト)は必須。内部開発者 のみでは自分のコードの脆弱性を見逃しやすい
18. QA/テストエンジニアに対する昨今のトレンド ①完全代替は すぐに起きない 定型的QA作業の 40〜60%を2030年 までに自動化される 75%の組織が AIによるテストを戦略の 柱と位置づけ ➁新役割への 移行が加速する AI活用型QAエンジニア への転換 品質戦略エンジニア/ データ品質保証エンジニア の誕生 ➂スキルアップが 急務になっている 72.8%の QA/テストエンジニアが AIによるテストを 2026年の最優先に選択 70%の組織が QA人材の AIスキル習得を期待
19. 昨今のトレンド① 完全代替はすぐには起きない 出典：testrigor.com/blog/will-ai-replace-testers | testdevlab.com/blog/ai-augmented-software-testing-future-of-qa | qasource.com/blog/quality-engineering-ai-era 40〜60% 定型的QA作業が 2030年までに自動化 75% の組織がAIによるテストを 戦略の柱と位置づけ • AIは定型的・反復的なテスト実行を自動化するが、下記の検証は人間にしかできない。 • 探索的テスト • リスク評価 • ユーザー体験の検証 • 75%の組織がAIによるテストを戦略的優先事項とする一方で、実際に導入済みの組織は16%にとどまっ ており、計画と実装の大きなギャップが存在する。
20. 昨今のトレンド➁ 新役割への移行が加速する 出典：testcollab.com/blog/will-ai-replace-qa-testers | quashbugs.com/blog/qa-to-sdet-ai-2026 「テストを書く専門職」から「AIエージェントを指揮する品質責任者」へ変容する。 • テスト戦略の設計/AIの出力監督 / リスクベース優先付け / 開発チームへのコーチングが主要業務となる。 • より高付加価値な職種への昇格と見なされている。 従来のQA/テストエンジニア • テスト作成 • テスト実行 • バグ報告 現在（過渡期） • QA業務自動化 • 一部戦略立案 • AIツール活用 AI時代の新役割 AI活用型QAエンジニア 品質戦略エンジニア データ品質保証エンジニア
21. 昨今のトレンド➂ スキルアップが急務になっている 出典：quashbugs.com/blog/state-of-qa-automation-2026-report | witanworld.com/article/2025/12/03/ai-enhanced-qa-testing-predictions-and-opportunities-for-2026 今すぐ習得すべきスキルとして下記が示されている。 • AI駆動テスト生成の理解と活用 • 予測型品質分析 • リスクベース・自律テスト手法 • ノーコード / ローコード自動化ツール • プロンプトエンジニアリング • AIの出力を監督するガバナンス設計 72.8% QA/テストエンジニアが AIによるテストを 2026年の最優先に選択 70% の組織が QA人材の AIスキル習得を期待
22. AI活用型QAエンジニアへ スキルアップしましょう！ でも・・・どうやって？
23. 3.いまからの学び方 23
24. AI時代が変える「学び方」 変わったのはスピードだけでなく、学びを考えるのが自分以外の誰かや組織では なく、個人に移っている。 • インプット偏重 → アウトプット重視 • 誰かに教わる時代 → 自ら問いを立てて、実験するスタイルへ変化 24 15年前より以前 書籍 研修 OJT 15年前 オンライン学習 • Youtube • Udemy • Qiita など 今 AIとの対話学習
25. 自ら問いを立てて、 実験するとき… ワクワクしませんか？
26. あなたが強く感じるQA/テストの「ワクワク」は何ですか？ 1. 【発見】のワクワク 例：アプリの誰も触らないような深い階層で、誰も気づかなかった画面の崩れ（バグ）を偶然見つけたとき。 2. 【攻略・達成】のワクワク 例： 「再現確率10%」と言われるような、めったに起きない幻のバグを発生させる確実な手順（再現手順）を突き止めたとき。 3. 【創造】のワクワク 例：これまで手動で3時間かかっていたテストを、ボタン一発で5分で終わらせる「自動テストの仕組み」を設計しているとき。 4. 【予測・戦略】のワクワク 例：開発者の修正コードを見て、「この直し方だと、おそらく別のあっちの機能に影響（デグレード）が出ているぞ」と予測してテ ストに向かうとき。 5. 【共創・繋がり】のワクワク 例：リリース直前のバグをお祭りのようにチーム全員で探し、みんなで協力して品質をハイクオリティに仕上げたとき。 6. 【変身・なりきり】のワクワク 例：「超せっかちでボタンを連打するユーザー」や「システムを壊そうとする意地悪なハッカー」になりきってアプリを操作するとき。 26
27. 「あそび＝まなび」 という考え方もある
28. あそびが育む「生きる力」!! 28 「あそび」とは、 「やってみたい」という動機から自発的に始まるリアルな体験であり、 その結果として人を育んでいく過程のこと。(≠娯楽) 参考：https://www.bornelund.co.jp/mind/slogan.html 想像力 • 自由な発想で、限りなく広がるあそびの世界。 • 夢中になって遊んだ経験は、夢見る力につながってい きます。 発見と理解 • 見て聞いて、触って確かめて、発見が感動とともに学びや理 解につながっていきます。 創造性 • 誰もが持っている、その人だけの感性を生かすこと。 • 涌きあがるイメージを自らかたちづくる楽しさや、つくりあ げたときの達成感をもたらします。 コミュニケーション能力 • 楽しいこと、おかしいこと、時には秘密…。それらを誰かと共 有する楽しさ。こうしたことの積み重ねが、人と人(AI)の間に 信頼感を育みます。
29. AIと遊ぶことで私たち自身がさらに成長できると捉える • 人の考える力がなくなるといわれるが、それは人を育んでいく過程(あそび)にAIを組み込 もうと考えていないからとも思える。 • AIがやってくれること（今までの自分より早く情報をまとめたり、単純な知的作業)を人 の成長のきっかけにする。 • 踏み込んで「自由な発想」、「イメージの具現化」、「発見と理解」、「共有の楽しみ」を意識する。 29
30. 私たちはAIやロボットと どう付き合うかは知っているはず…
32. AIと遊ぶことで私たち自身がさらに成長できると捉える • 人の考える力がなくなるといわれるが、それは人を育んでいく過程(あそび)にAIを組み込 もうと考えていないからとも思える。 • AIがやってくれること（今までの自分より早く情報をまとめたり、単純な知的作業)を人 の成長のきっかけにする。 • 踏み込んで「自由な発想」、「イメージの具現化」、「発見と理解」、「共有の楽しみ」を意識する。 32 こんなこといいなできたらいいなを考える
33. 「ワクワク×AIとの遊び」が最強の学習戦略である理由 最初は危機感かもしれないが… 学習継続を決める最大要因は「楽しいかどうか」 • 義務感・焦り・恐怖からの学習は短期間しか続かない • 「AIに負けないために勉強する」は消耗する学び方 • 「AIと遊んでいまよりもちょっと面白いことをやりたい」は自然に続く学び方 • 内発的動機づけは外発的動機づけより長期パフォーマンスが高い 出典：Deci, E.L. & Ryan, R.M. (1985). Intrinsic Motivation and Self-Determination in Human Behavior. Springer. / Self-Determination Theory (SDT) — 内発的動機づけが長期パフォーマンスに優位であることを示す研究知見 消耗する学び 「AIに負けないために勉強する」 → 義務感・焦り・恐怖 ＝ 短期間しか続かない 続く学び 「AIと遊んで面白いことをやりたい」 → 内発的動機づけ ＝ 長期パフォーマンスが高い VS 33 まず「試してみたい」という感情を大切に！
34. 学習アプローチ＆戦略 ― 試して・つながって・続ける • インプット偏重から「試して学ぶ」アウトプット型学習へ • AIと対話しながら学ぶ • 思考の壁打ち相手・学習パートナーにする • スモールスタート • 明日から1つ試せることを見つける • 実践の場を積極活用する • 普段の業務でAI活用を小さく試し続ける「実験文化」を自分から作る • 実験したことをAIだけでなく、他の人にも共有する • 共有することで新たなアイデアや発想が生まれてくる • そのアイデアや発想を試す良いサイクルを回し続ける 34
35. 2025年 春
36. QA部の構成 36 COM系 支援グループ GAME系 支援グループ 全体効率化 QAのAX支援 グループ QA部 新設
37. よーし、みんなで AIと対話学習して 業務改善しよう！
38. AIツール触ったことないです！ By 現場メンバ
39. メンバの状態にあった 学習方法 を考えましょう。
40. AIとの対話学習の5段階 • 25年から学習の5段階を意識して進めています。 • メンバに対して、段階を一足飛びにしようとせず、「今自 分がどの段階か」を把握して、次の1段階を目指してい ます。 • メンバに対するAI活用推進活動例 • 数か月に一度のアンケート実施 • 定期的な活用ヒアリング・デモの実施 • 「いつもやっている一番面倒なことはありますか？」 • 「こうAIに依頼するとこんな風にできますよ！」 • 困ったときのフォロー • バイブコーディングの推奨 • テスト業務を効率化するツール開発 知らない 知っているが使えない 意識して使える 自然に使える 組織に展開できる
41. 一年間続けていたら AI対話学習の壁や落とし穴 が見えてきた
42. 知らない 知っているが使えない 意識して使える 自然に使える 組織に展開できる 壁 QAやテストの AI活用において ここには、壁や落とし があります 穴
43. AIにどう依頼したらいいか… AIの成果物を信用できない！ By 現場メンバ
44. 壁や落とし穴を回避して AIと遊びながら学ぶためには 4つのステップがある
45. AI時代のQA/テストエンジニア個人の学習ロードマップ 壁や落とし穴を回避してAIと遊びながら学ぶための4つのステップ 45 1 基礎を固める AIの不完全なアウトプット を見抜く基礎 を身に着ける 2 AIを使いこなす 思い通りにAIを動かす 指示＆レビューをする 3 開発全体を見渡す ミスを防ぐための 仕様確認と安全な修正 4 組織と社会を守る 安全性と信頼性を担保する ルールと仕組み
46. ステップ1：【基礎を固める】AIに振り回されない「不変の基礎」 なぜ最初に必要か？ • AIが出力したテストケースやコードの妥当性を評価する基準は人間にしか持てない。 • 出力が「網羅されているか」「偏りがないか」を、直感ではなくロジックで判断するため。 習得すべき知識やスキル 検証（Verification）と妥当性確認（Validation）の概念を知る 「正しく製品を作っているか」と「正しい製品を作っているか」の違いを明確に説明できる知識 テスト設計技法をマスターする 同値分割法・境界値分析・デシジョンテーブル・状態遷移テストを要求仕様から自力で設計できる思考を身に着ける 共通語彙、品質モデルを理解する(できれば、この段階でソフトウェアエンジニアリング手法も) JSTQB Foundation Levelの用語理解・ISO/IEC 25010の品質モデル（機能適合性・信頼性・使用性など）の把握 ソフトウェア開発のための手法(要求分析、設計、コーディング)として何があるかを把握
47. 「3つの要素」テンプレートで超ローコンテクスト指示を徹底する ステップ2：【AIを使いこなす】思い通りにAIを動かす「指示＆レビュー力」 壁や落とし穴： • 日本人は具体的に書くことに慣れていない人が多い • 主語・前提を省略 → AIから的外れな回答しか引き出せない • 綺麗な文章を書こうとして情報が不足し、AIのハルシネーションを誘発する 壁や落とし穴の回避方法： C Context（前提） 私は〇〇の機能のテストをしています C Constraint（条件） 異常系だけ、5パターン、表形式で出 してください C Criteria（基準） 期待される結果（何が正解か）も書 いてください
48. ステップ3：【開発全体を見渡す】ミスを防ぐための仕様確認と安全な修正 壁や落とし穴： • 既存システム全体の流れを理解し、仕様変更プロセスを組み立てるのはハードルが高すぎる • AIに修正コードを丸投げ → AIの「思い込み」で予期しない場所が壊れる（デグレード多発） 壁や落とし穴の回避方法： コード修正前の3ステップの仕組みを実践する ① 要求仕様の具体化：曖昧な要望をAIが誤解しないレベルで要求仕様としてドキュメント化する ② 影響範囲の可視化：変更仕様と既存コードの関係をコード修正前にリスト化する ③ 修正計画の明確化：変更前後のロジックの違いを自然言語で記述する チケット管理ツールの運用 & ユーザー視点のテストを設計する ・Jira/Redmineでのバグチケット正確な起票 & AIによる根本原因分析（RCA） ・ペルソナや利用シナリオ（ユースケース）を想定したシナリオテスト設計をする ・ Google Analyticsなどの行動ログを分析する ユーザー視点シミュレーション」で仕様の盲点を探る AIを「多様なユーザー」に変身させ、仕様の使いにくさを一緒に探るパートナーにする。 例：「あなたはこのシステムを明日から使わなければいけない『IT操作が少し苦手で、手順が複雑だと迷ってしまう心配性なユーザー』になりきってください。 『ここが少し分かりにくいかも』と感じるポイントを5つ、ユーザーのセリフ形式でフィードバックしてください」
49. ステップ4：【組織と社会を守る】安全性と信頼性を担保するルールと仕組み 静的解析・品質監査ツールの活用 例： SonarQube / lint系ツール AIが出力したコードのバグや技術的負債を自動検知する セキュリティ・ライセンス脆弱性診断 例： Snyk / FOSSA AI生成コードのOSSライセンス違反や脆弱性を自動スキャ ン・監査する CI/CDパイプラインへの組み込み＆構成管理 例：GitHub Actions / GitLab CI など 静的解析 → 脆弱性スキャン → 自動テストが自動で走 る品質ゲートの運用する AI品質基準（QA4AI）の理解 例： OWASP Top 10 for LLM AI特有の脆弱性を定義したセキュリティガイドラインの基本 把握する 重要：個人学習と組織実務は切り分けておく • 個人学習ではステップ4が最後だが、実務でセキュリティ対策を最後に回すのは絶対NG • 最初から自動的に脆弱性スキャンが走るなど「自動ガードレール」などの仕組みを全員に適用しておく ステップ3までを経て、ルール、仕組みを構築して、プロダクト品質だけでなく、AI開発がはらむ組織・社会的リスクをコン トロールする方法を検討する。
50. 順序を守ることの重要性 特に、基礎(ステップ1、2)を飛ばして、いきなりAI活用や高度な仕組みづくりに取り組むと… ✕ ツール(AI)に使われるQA/テストエンジニアになってしまう ✕ ツールやAIの要求仕様が変わった瞬間に何もできなくなる ✕ AIが作った成果物をただ眺めるだけになる ✕ 自身のキャリアの再現性が失われ、長期的な成長が止まる まず、自分の頭を鍛え、次にAIを武器にし、最後に組織を変えることを目指しましょう！
51. これらがそろえば、自ら問いを立てて、実験するワクワク状態に！！ 51 この4つに気をつけて健全にAIと遊んでQAとテストについて学びましょう！ 1 基礎を固める AIの不完全なアウトプット を見抜く基礎理論 を身に着ける 2 AIを使いこなす 思い通りにAIを動かす 指示＆レビューをする 3 開発全体を見渡す ミスを防ぐための 仕様確認と安全な修正 4 組織と社会を守る 安全性と信頼性を担保する ルールと仕組み
52. 4.AI時代の実践事例紹介 52
53. 【創造のワクワク】 QA/テスト AIエージェント開発 に取り組んでいます。
55. 毎週 リリース
56. 【創造】のワクワク：AIエージェントによるE2Eテスト開発 56 AIと創造したこと • Webブラウザ、モバイルアプリのテスト実行環境を構築して、テストケースがあれば、いつで も、どこでも、誰でもテストをできるようになりました。 • 環境構築には利用者に対して丁寧なフォローが必要だったが、AIが実施 テスト対象取得 テスト成果物 一括格納 テスト実行環境 テスト分析・設計 環境 AIツール (Cursor)
57. 【発見】のワクワク：AIエージェントによるE2Eテスト開発 57 AIと発見したこと • テストプロセスや成果物の冗長な個所を見つけてチームで共有/議論できた。 • 今までは、プロセスや成果物の収集・理解に、ものすごく時間かかり、断念していたがAIで可能に。 成果物定義(クラス図) IDトレース プロセス定義(DFD図) テスト 要件定義書 トレース可能なだけで 最終的な分析結果が 反映されていない 要件への FBがタスクが必要 要件への FBがタスクが必要 要件への FBがタスクが必要
58. AIと学んだこと(発見と理解)① 61 テスト 実行 テスト 実装 テスト 設計 テスト 分析 テスト要求の 獲得と整理 テストケースの列挙 手動／自動化 テストスクリプトの記述 テスト 報告 (完了) テストスクリプト実行 不具合リスト テスト完了レポート作成 テスト要件 定義書 テストケース 書 テスト スクリプト テスト 結果書 不具合 リスト テスト完了 レポート 仕様書 テスト対象システム （Webシステム） 実装 ドメイン 情報 ④人のテストケースの質 を確認する品質ゲート を作ろう ➂仕様書と実システムに 乖離がある場合はテスト ケース書を治すべきか チェックしよう ①実行結果を分析して、 実装ミスしたものは、 修正しよう ➁実システムに合わせず、 テストケース書の内容に 沿った実装にしよう
59. AIと学んだこと(発見と理解)➁ 62 人間 指示・レビュー (現場メンバ) 人間 (私たち) AI 作成 output 成果物 開発からの 成果物 コストに応じて 質が変動 大変！ スキルなど Input 成果物 工程を経る分だけ、 質が少しずつ下がっていく 負スパイラルに入る 人は言い間違えや あいまいに 伝えることがある こちらも人で作られてい るため誤りはある チェックする リミットが来ると質が下がる or コストがかかる
60. AIと学んだこと(発見と理解)➁ 63 人間 指示・レビュー (現場メンバ) 人間 (私たち) AI 作成 output 成果物 プログラム 開発からの 成果物 壊れやすいが 質が一定 コストに応じて 質が変動 成果物の自然言語チェック・修正ツールが必要。 (曖昧性の排除、適切な言葉遣いへの変換) レキシコン(語彙/字句)→シンタックス(構文)→セマンティクス(意味) スキルなど Input 成果物 工程を経る分だけ、 質が少しずつ下がっていく 負スパイラルに入る 人は言い間違えや あいまいに 伝えることがある こちらも人で作られてい るため誤りはある チェックする リミットが来ると質が下がる or コストがかかる ・コンテキスト(語彙/字句)の獲得(特にGAMES領域) ・人間とAIの理解を助ける知識の整理 （人間の自然言語と自動テストフレームワークとを通訳するための情報)
61. AIと学んだこと(発見と理解)③ 64 最終的には、すべて自然言語→プログラムに変換されるため、そのための事前知識が必要。 項目 説明 レキシコン (語彙/字句) if、print、(、)のような「そもそもどんな単語（トークン）が存在するか」を定義する段階。 実装では**字句解析器（lexer / tokenizer）**が担当し、文字の並びを意味のある 最小単位（トークン）に分割する。 シンタックス (構文) 定義されたトークンをどの順番でどう組み合わせれば正しい文（構文）になるかを定める ルール。実装では**構文解析器（parser）**が担当。 セマンティックス (意味) 正しく構文解析されたプログラムが実際に何をするか（実行時の振る舞い）を定める。 定義されたものはプログラムがチェック・修正 人間・AIが 妥当性確認
62. 【創造のワクワク】 いままでやったことない テスト作ってみよう に取り組んでいます。
63. 試せば試すほど、「ワクワク」はどんどん増えています。 1. 【発見】のワクワク ➢ 「全チームのテストプロセス、成果物を分析して統合するためのルールを見つけよう！」 2. 【攻略・達成】のワクワク ➢ 「FBを受けたその日に、自動テストの実行スピードを50秒→11秒に改善した。 」 3. 【創造】のワクワク ➢ 「Webブラウザ、モバイルアプリだけでなく、ゲームアプリのテスト実行環境を構築しよう！ 」 4. 【予測・戦略】のワクワク ➢ 「テストケースとテストスクリプトが一致していないのであれば、プロセス毎にチェックすることで 防ぐようにしよう！」 5. 【共創・繋がり】のワクワク ➢ 「開発チームが作っている仕様駆動ツールと連携できるようにしよう！ 」 6. 【変身・なりきり】のワクワク ➢ 「AIエージェントの成果物チェック機構にペルソナを利用しよう！ 」 etc,.., 67
64. 5.まとめ 68
65. AI時代のQA/テストエンジニア個人の学習ロードマップ 壁や落とし穴を回避して、AI活用型QAエンジニアになりましょう！ 69 1 基礎を固める AIの不完全なアウトプット を見抜く基礎理論 を身に着ける 2 AIを使いこなす 思い通りにAIを動かす 指示＆レビューをする 3 開発全体を見渡す ミスを防ぐための 仕様確認と安全な修正 4 組織と社会を守る 安全性と信頼性を担保する ルールと仕組み
66. まとめ • QA/テストエンジニアの役割はAI時代に大きく変容しつつある • 役割の消滅ではなく「高度化」 • 繰り返し作業はAIへ移譲し、人間は探索的テスト、リスク評価、品質戦略設計に集中する。 • 「テストを書いて実行する人」から「AIを監督する品質責任者」へ。 • Human-in-the-Loopは不可欠 • AIにテストを任せても要求や仕様検証は人間が担う必要がある。 • AIは最強の学習＆遊び相手 • 「負けない」より「遊ぶ」マインドでまずは活用してみませんか。 • ワクワクが最強の学習戦略 ― 今日から1つ、試してみましょう！ • この後のセッション、講演で「ワクワクすること」があれば、試せるものは試しちゃいましょう！ • とにかく試す、考えて試す、考えて試し続けるのが大事！ 70