AI時代におけるテストの基礎の再定義 / Rethinking the Fundamentals of Testing in the AI Era

AI時代到来です。
AIの台頭によって「このままテストをやっていて大丈夫なのか」「学んできたテスト技術は通用し続けるのか」と不安を感じているテストエンジニアも多いのではないでしょうか。
この講演では、AIを過度に恐れず、かといって過信もしないために、テストエンジニアとして押さえておきたい考え方を整理します。
またAIにより我々テストエンジニアができることも大きく広がりました。あなたがやりたかったこと、思い描いていることに手が届くようになったのです。テストや品質保証活動の楽しさが大きく広がったと言い換えられます。この広がったワクワクする世界についてもお伝えしたいです。
AIは、我々の仕事を単純に置き換えるだけの存在ではありません。
これまで学んできたテスト技術は、AIによって何が変わり、何が変わらないのか。
テストエンジニアがどう考え、どう動き、どう価値を出していくのか。
それらを整理し、今の時代におけるテストや品質保証活動を捉え直すお話をします。

***

The AI era has arrived.

With the rapid rise of AI, many test engineers may be wondering, *"Will my current testing work still matter?"* or *"Will the testing techniques I've spent years learning continue to be relevant?"*

In this session, we'll explore the mindset that test engineers should adopt to avoid both overestimating and underestimating AI.

At the same time, AI has dramatically expanded what test engineers are capable of achieving. Things you once wanted to do—or perhaps thought were out of reach—are now within your grasp. In other words, AI has greatly broadened the possibilities and excitement of testing and quality assurance. I'd also like to share this exciting new world and the opportunities it offers.

AI is not simply here to replace our jobs.

Instead, we'll examine what changes—and what doesn't—in the testing knowledge and techniques we've built over the years. We'll discuss how test engineers can think, act, and create value in the AI era.

Ultimately, this session will help you rethink testing and quality assurance from a modern perspective, clarifying what remains fundamental and what must evolve as AI becomes an integral part of our profession.

Transcript

1. AI時代におけるテストの基礎の 再定義 株式会社MIXI 開発本部 たんぽぽ室 QAグループ SDETチーム/QAEチーム マネージャー 松⾕峰⽣ ©MIXI
2. 我々が 実現したいことは何も変わっていない。 変わるのは実現⼿段である。 ©MIXI
3. ⾃⼰紹介 株式会社MIXI 開発本部 たんぽぽ室 QAグループ SDETチーム / QAEチームマネージャー 松谷 峰生 (まつや みねお) 趣味 : ロボット開発、小説執筆、マンガ執筆 DIY、プラモ、ゲーム開発 ペット : フクロモモンガ 僕が描いている商業マンガが出ていたりします。 今連載マンガ2本を持っています。 • あなたの知らないテストの言葉 • マンガではじめるMagicPod入門 ©MIXI 3
4. おっさんQAトークというYouTubeをはじめました 僕とさかたさんというQAの方で「おっさんQAトーク」というYouTubeをはじめまし た！ 10分くらい、テーマについておっさん2人が好き勝手に話すというものです(笑) 聞き流し用です。 基本的には「AI時代の～」文脈の話をする予定です。 第1回「AI時代のQAのキャリア」 第2回「AI時代テスト実行者はどう すればいいの？」 ©MIXI 4
5. 松⾕とAI ~AIまわりでよく声をかけられる⼈です~ 2017~2018 スマートスピーカーのQAマネージャー 言い方で出力が変わるなど、今もみんなが 苦戦している部分と当時から向き合う 2018~2023 QA4AI設立メンバー AIプロダクト品質保証ガイドラインの Voice User Interface領域を執筆 2018~2019 AIに対する品質保証についての講義/講演 IT検証フォーラムや宮崎大学で AIに対する 品質保証で講演や講義 2022~2023 AIスタートアップにjoin gpt-2を触っていた 2022 JaSST’22 ShikokuでAIについての招待講演 AIプロダクトの品質保証について 2024~2026 AIロボットの品質保証 メインはハードウェアだったけど ©MIXI 5
6. 講演の全体像 ©MIXI
7. 本⽇は三つを再定義します AIへの向き合い方 QA・テストの仕事と役割 AI時代に必要なテストの基礎 ©MIXI 7
8. AIは何を奪うのか？ 〜AIの現状を把握しよう〜 ©MIXI
9. QA/テストの仕事がAIに奪われるという話を聞くようになった とあるテストエンジニア x月x日 AIがテスト観点を山ほど出し てくれるようになった！ もう AIでいいのでは とあるQAエンジニア x月x日 全然自分よりイイカンジのア ドバイスするよな…。AIに聞 くでよくない？ ©MIXI とある自動化エンジニア x月x日 自動テストのコードをAIが秒 で作ってくれた！ 私はコーヒー飲みながら見 てるだけ とあるテストエンジニア x月x日 もう普通のテスト実行もAIが やってくれる時代になりそう … 9
10. 最近のAIができること 文章の作成 コーディング 長文の要約 デザイン アイディア出し ファイル操作 お絵描き/動画生成 ブラウザやPC操作 etc… ©MIXI 10
11. 単純作業だけではなく、知的作業も可能 ©MIXI 単純作業 知的作業 これまで 自動化を目指した領域 これまで 我々が侵害されないと 思っていた領域 11
12. テストの⽂脈で最近のAIができること ©MIXI テスト成果物 生成 テスト観点出し、テストケース生成、テストデータ生成など。 たたき台作成が速くなっている。 自動テスト 補助 E2E自動テスト生成、自己修復、ビジュアルリグレッショ ン。リグレッションテスト作成と保守の重さを下げている。 判断補助 失敗原因分析、flaky検知、品質ダッシュボード作成。 大量の結果から見るものを絞り、意思決定しやすくする。 12
13. 各テスト活動へのAI適⽤ 所感(あくまで松⾕の⾒解) テスト計画 あまり事例を見ない。品質目標は人が決めて欲しい。 リスク分析はAIが良い仕事をするように見えている。テストのアプローチは、人は自分 の領域依存に寄りやすいが、AIは各テストレベルやテストタイプを幅広く出せる。PJの 都合を細かく与える必要はある。 テスト観点出し 周りでもよく見るAI活用。一般的な観点を幅広く出すことができる。 これまで起きた気を付けるべきissueやよくあるCSお問合せ、暗黙の仕様などのドメイ ン観点はコンテキストとして与える、人が補完する必要がある。 モデルによってはごっそり観点が漏れることがあるので要注意。 ©MIXI 13
14. 各テスト活動へのAI適⽤ 所感(あくまで松⾕の⾒解) テスト設計 テストケース生成と同時に行われていそうなパターンはよく見る。 境界値や代表値は問題なく出せる。デシジョンテーブルテスト的なパターンも出せてい るように見えている。組み合わせが必要な部分は出せているか、ペアワイズで減らし たほうがいいか、状態遷移図や表でのパターンの部分は確認したほうがいい。 gpt-5.5ではパターンがごっそりない場合を確認している。 テスト実装 コードでのテストの生成はAIの得意分野。人用のテストケースもテスト設計が出来て いれば出せると思うが、手順は与えるコンテキストによるため、実際に実行できる手順 なのかは確認したいところ。(松谷は手順不要な確認でばかり作ることが多いため未 確認) ©MIXI 14
15. 各テスト活動へのAI適⽤ 所感(あくまで松⾕の⾒解) テスト実行 E2E自動テストの実装・実行はよく目にする。 人用のテストケース実行のAIエージェントも、松谷が開発したものなどがあるため後 ほど紹介。 また探索的テスト実行するAIエージェントも弊社では実働している。 テストレポート 情報まとめはAIが得意とする領域のひとつである。 普通に生成させてしまうと情報を全部盛り込もうとするため、skillsやテンプレートを 使って行うほうが良い。 ©MIXI 15
16. ⼈⽤の⼿動テストケースを実⾏できるAIエージェント 手動用のテストケースを実行できる AIエージェントを開発 しました。 スポンサーセッションで5分で簡単にお伝え予定です。 実際のテスト102件を対象に、ツールが想定した通りに動くかの実験を行いまし た。 検証結果 (gpt-5.5) 件数 割合 意図した通りのテストができた 87 / 102 85.2% 意図した通りのテストができなかった 15 / 102 14.8% ツールが意図した通り正しくテスト実行できたか。 バグ検出精度ではない ©MIXI 16
17. 計画からレポートまでを全⾃動で実⾏するSkill 各Skillのオーケストレーションにより計画から分析・設計・実装・実行・レポート までを全自動実行 するSkillを開発しました。 Unit／Integration／E2E／人間実行を分け、中間成果物を作り 次工程に渡しな がら進みます。 テストベース/リスク→観点→設計→項目と追えるように紐づけている ことが特徴 です。 ※Appendixに説明を入れています Skill構成 テスト計画 ©MIXI テスト 分析 Unit test設計 実装 実行 Integration test 設計 実装 実行 E2E自動テスト 設計 実装 実行 人間用テスト 設計 実装 実行 テストレポート 集計 17
18. AIは我々が行ってきた各作業を できるようになってきました。 それによって我々の仕事が 奪われてしまうのでしょうか？ ©MIXI
19. AI時代の 考え⽅の再定義 ©MIXI
20. 思い出すべきこと AIは道具です AIを過度に擬人化 してしまうと、人と同等のことができると思ってし まいます。 結果、まるで自分より優れていると思っている人が同じ部署に来て 自分の仕事に手を出してきた時のように、過度に不安 に思ってし まったりします。（または過度な期待 ） ©MIXI 20
21. 思い出すべきこと 道具は使うものです 道具は使う人次第です ©MIXI 21
22. AIの適⽤を設計するのは⼈の仕事 AIはとても便利です。便利なのですが、やはり道具なのです。 その道具をどのように使うかは、人次第なのです。 もう少しエンジニアっぽく言うと、 AIという道具を、何に対して、どのように適用するか を設計するのは人の仕事 ©MIXI 22
23. 「AIに全部任せちゃう」という設計をするぞ！ 僕は細かいことを考えるのが好き じゃないので、 AIに全部任せるという設計をしま すね！ ©MIXI 23
24. こんなたとえ話はどう？ AIで動くハサミ を作ったぞ！ もう美容院もいらないし、全部この ハサミでいいんじゃない？ ハサミよハサミよハサミさん。 髪が伸びてきたし、ちょっと切って よ。 AIはすごいから全部お任せ！ ©MIXI 24
25. 責任の所在はどこにある？ これで坊主刈りになったとしても「ハサミが悪い！」と言ったところでどうにもなりま せんよね。 AIは道具であり責任能力はありません。 どのように使うかは人次第であり、どう なったかもその道具を使った人の責任 です。 AIという道具を使って得た結果も責任も 使うと決定した人にある ©MIXI 25
26. ⼈が⾏うこと AIは道具であり、動作や結果の責任は判断した人にある どこはAIでどこは人がやるといった、戦略は人の仕事 AIをどのように適用するかといった、プロセス設計は人の仕事 AIの権限やガードレールといった、環境設計は人の仕事 ©MIXI ※これらを全てAIに考えてもらえますよね？は、AIに全て考えてもらうというプロセス自体を考えたのは人 26
27. ⼈が起点。⼈が道具を使い⽬的をなす。 AIは道具である以上、起点は人。 目的を果たすため、人が道具を上手に使う。 結局、人が何かの目的を達成するために、人が適切な道具を選び、人が適切に 道具を使うのです。 ©MIXI 27
28. 最後の例え話 原始時代。あなたは料理担当で、中でも火起こしに時間をかけていました。 木 の棒をグルグルして火を起こすのですが、コツも必要で専門職なのです。 ですがある時、なぜか突然「ライター」が出てきました。誰でも簡単に火が使える ようになりました。 あなたは「仕事がなくなってしまった…」と意気消沈です。 周りを見ると、みんな思い思いにマンモスの肉をライターの火で直炙り して「誰 でも料理できるやん！」とやっています。 あなたは「それでいいんだっけ？」と感じつつも、火が簡単に起こせてお肉を誰で も焼けるので、自分の仕事は終わった…と思いました。 ©MIXI 28
29. あなたの仕事の本当の価値は？ 料理担当のあなたの価値は、木の棒を回して火を起こせることではなかったはず です。 料理担当の本当の価値は、 火をどう使えば、お肉が美味しく、安全に、みんなに満足される形にな るか知っていること なのです。 奪われるのは仕事そのものではない 仕事だと思い込んでいた一部の作業である ©MIXI 29
30. あなたの仕事の本質はなんだ？ AI時代に生き残る人は 火起こしにこだわる人ではなく 料理人として再定義できる人 あなたの「火起こし」に当たる部分はなんですか？ あなたの「料理人」にあたる仕事の本質は何ですか？ ©MIXI 30
31. QA/テストエンジニアの 活動領域の再定義 ©MIXI
32. 品質活動 = テスト実⾏ではない 品質マネジメント活動 予防的・プロセス指向 品質保証(QA) プロセス改善 標準化 欠陥予防 品質コントロール (QC) テスト 形式的手法 シミュレーション etc… ©MIXI 検出・評価・是正的 プロトタイピング 32
33. 最近のAIができること コードでのテスト コンポーネントテスト コンポーネント 統合テスト 外部システムもつなげ てのテスト システム テスト システム全体での テスト システム 統合テスト 受け入れテスト 受け入れ当事者が 判断するためのテスト ©MIXI 33
34. 最近のAIができること テスト計画 テスト分析 テスト設計 テスト実装 テスト実行 テスト完了 ©MIXI 34
35. 品質活動 = テスト実⾏ではない ココ！ ©MIXI 35
36. 品質活動の世界は超広い！！ もしあなたが 「私の仕事はテスト実行専門だし」 と思っているなら視野を広げてみてください。 今あなたが見てる世界は本当のごく一部で 広大な未踏の領域が広がっているのです。 ©MIXI 36
37. 知らないから⼿が出せない そんなこと言ったって 他の部分のことなんて全然 知らないし… ©MIXI 37
38. 知らないから⼿が出せない / 思い浮かびもしない 今まで、システムテスト専門というみなさんは、その会社の文化もありつつも、「知 識不足で他の領域に手を伸ばせなかった」「知識不足ゆえに手を伸ばそうとい う考えさえ浮かばなかった」 があるのではないでしょうか？ APIをテスト …！？ 聞いたことあるけど絶対難しいや つ！！ わからない！！ ムリムリムリムリ～！！ ©MIXI 38
39. あなたは最強の武器を⼿に⼊れた！ エクスカリバーを 手に入れたッ !! しかし、あなたは今 現代技術を惜しげもなくつぎ込んだ、技術 の粋を結集した現代最強の武器 を手に入 れたのです。 この最強の武器で何をするのも あなた次第！ しゃべるタイプの 武器 ©MIXI 39
40. AIの登場で思い描いていたことができるようになった! AIの登場により、何かに挑戦する敷居が格段に低くなりました。 なので今までやりたいと思っていたことや、こういったイベントで見て「私もやって みたい！」と思ったことが簡単にできるようになったのです。 APIテストに切り込むぞ！ いけるか！ モチロンです。 APIテストをモノにしま しょう！ ©MIXI 40
41. 事例 : AIを使って冒険をはじめたNさんの例 今まで黒い画面(ターミナル)も見たことがないと言っていたQAのNさん。 AIを手にしたときに、その時困っていた「テストのやりにくいところ」を簡易化する ツールを AIを使って開発 してみました。そしたらそれが思った通り動く！ さらに細かな便利ツールを開発、それらツールをつなげてプロセスも構築したの です。 さらに、AIを使って開発者のコードを読み、それを軸に開発者と「～ってどうなっ ているのですか？」と話す ということまで今はしています。 今までやっていた「システムテスト実行」から AIを使い越境 したのです。 テストツール 開発 ©MIXI プロセスの 構築 開発のコードを 読み会話 41
42. ⾊んなことができるって、何？ 〜具体例〜 ©MIXI
43. ⾊んな事ができるとは⾔うけど、例えば？ 我々は現代最強の武器を手に入れました。 それにより、今まで壁だと思っていた部分を超え、色んな領域に冒険に出られる ようになりました。 では、AIを使うことによりどんなことができるのでしょうか？ 私が思い浮かぶ具体例をいくつか紹介していきます。 ©MIXI 43
44. 初級 : 今の仕事を整える 初級 今まで 「大変そう」「面倒だなぁ」と思って なおざりになっていた部分を整えてみよう ©MIXI 44
45. Case1 : テスト計画がしやすくなる 私が回ったWebやアプリ系ではあまりテスト計画作成は見かけませんでした。ど ういったアプローチで今回のテストを行えば効果的・効率的にできるのかを考える ことは非常に大切です。 例えば、与えた仕様などからリスクを列挙し、そのリスクを確認するためにどう いったテストのアプローチをすればいいかを AIを使って出す 、といったことも出 来るでしょう。 他にも、どういった場所は手動テストで、どういった場所はE2E自動テストで行う、 といった作戦も立てやすくなる でしょう。 ©MIXI 45
46. Case2 : トレーサビリティの確⽴ そのテスト項目はどのテスト設計の結果から出たものなのか、そのテスト結果は どのテスト観点から出たものなのか、そのテスト観点はどういった仕様やリスクか ら出たものなのか……といった紐づけを行うと、仕様変更などがあってもそこを たどって修正をすることができます。 理想としてはこういったことをしたほうがわかっていつつも、運用が大変で出来な かったりしました。（私はそう） そこで、AIを使って一連の紐づけを行い、テストの説明をしやすくする、メンテナン スをしやすくするようなことが考えられます。 ©MIXI 46
47. Case3 : これまでやったことがない技法にトライ 勉強会に出たりSNSや記事を見て「そのやり方を試してみたい！」と思いつつも、 難しそうで手が出せなかったという経験はみなさんあるかと思います。 そういった技法を取り入れるのも AIを使うことによりハードルが下がります。 一例として「テストマトリクスを使ってみよう！」とか「VSTePをやってみよう」(これ はちょっとハードルが高いかも…)などです。 ©MIXI 47
48. おまけ : 「JSTQBの教科書」を1周読むと、不⾜に気づける 社内でのテストは「これが自分たちのやり方だ」が出来上がってきます。 社内の文化やプロセスにフィットしたやり方ですが、実はそもそも基礎を知らずに 出来上がった我流だったり、他のやり方を知らない/忘れていた可能性もありま す。 そのときに「JSTQBの教科書」(JSTQBのシラバスでもいいけど難しめ)を1周読むと、「欠陥マネ ジメントをちゃんとできてないよね」など、基本的なプロセスで、やったほうがいい けどやっていなかった場所が見えてきます。 実際に我々も社内で週一で輪読会をしていますが、そこで気づかされることが多 いです。 ※ソフトウェアテスト教科書 JSTQB Foundation 第5版 シラバス 2023対応 (EXAMPRESS) 大西 建児 (著), 湯本 剛 (著), 町田 欣史 (著), 福田 里奈 (著), 角田 俊 (著), 藤原 考功 (著), 大段 智広 (著) ©MIXI 48
49. 初級まとめ 「やりたかったあれやこれ」 をAIを使って行い 自分たちの今の活動領域を 自分たちの理想形に近づける ©MIXI 49
50. 中級 : 隣接領域へ出る 中級 自分たちの今までの領域から 染み出す ©MIXI 50
51. Case1 : APIテストにトライ 今まではUIを通したシステムテストを行っていた人も、AIを使って画面の裏側の APIのテストに手を出してみるのもよいでしょう。 テストの目的を考えたとき、UIを通す必要がないものは APIの戻り値で確認でき る……それができるとテストのアプローチの幅が大きく広がります。 ©MIXI 51
52. おまけ : APIテスト 特定クエストクリア後に ようやく目的の項目表示 100項目も あるぞ 項目によってアレコレ計算 して結果を返す API サーバー UI 結果をデコレーションして表示 各項目で仕様通りの返答が されるかのロジックの テストをしたい データが受け取れて 表示出来るかはどれか一 つの項目で試そう ©MIXI 項目によってアレコレ計算 して結果を返す 項目のデータを送信 API サーバー 結果 52
53. Case2 : 開発側のテストを確認する AIを使ってリポジトリにある開発者のテストを確認する こともできます。 ただ「どんなテストをやってるの？」と出しても細かすぎてわからないはずです。 なので「～を確認しているテストはある？」といった聞き方や、「こういうユースケー スに当たる部分はテストでどれくらいカバーされている？足りなそうなところは？」 など、自分たちがわかりやすい粒度で調べたほうがよいです。 ©MIXI 53
54. Case3 : テストを補助するツール開発 AIを使うことで「何か作ること」もとてもハードルが低くなりました。 ユーザーに公開するようなモノを開発するとなると難しいですが、例えばテスト準 備を楽にしてくれるツールや、結果を整形してくれるツールなどを作るのは楽にな りました。 アイディア次第で、開発者に依頼せずとも様々なテスト効率化ツールを作れる ようになったのです。 実際私の周りではこの使い方が多いです。また開発過程で「開発者のテスト」を 経験として学ぶ人も多いです。 ツール自体のテストは我々の本職なのでがんばってくださいね！ ©MIXI 54
55. 中級まとめ AIを使って 今までの活動領域から一歩踏み出し 開拓してみよう ©MIXI 55
56. 上級 : 点を線にする 上級 品質活動を プロダクトやプロジェクト 全体に広げる ©MIXI 56
57. Case1 : 点と点を結び線にする (CI/CD的なイメージ) 今後皆さんはAIを使って様々なモノを用意すると思います。 テスト観点を生成する、テストケースを生成する、E2E自動テストする、などです。 開発側でもUnit testやIntegration testなどを作っているはずです。 それら「テストする何か」が点在している状態になります。 それらの便利ツールをつなげ、まるでドミノの様に自動的に点在している便利 ツールを実行する「プロセス」を作っていく ことが今後の活動として考えられま す。 ©MIXI 57
58. Case2 : プロダクト全体を通したテスト計画を⽴てる これまではシステムテストレベルが活動領域で、システムテストの範囲でのテスト 計画を立てている場所も多いかと思います。 ですがAIを使うことでシステムテストレベル以外の部分を把握することもできるよ うになってきています。 それに伴い、「システムテストレベルでのテスト」から「プロダクト全体を通したテ スト」が可能 になってきます。 テスト計画も、例えばロジック部分はUnit testでの確認、データ確認はAPIやレ ビューでの確認、UIを通した確認はE2E自動テスト……のようなテストレベル全 体を通した計画を立てることも考えられます。 ©MIXI 58
59. 上級まとめ 開発プロセス全体を通した テストの仕組みの構築 ©MIXI 59
60. AI時代の タスクのやり⽅の 再定義 ©MIXI
61. 現状でもう⾒えていること 基本的には 「タスク実行」の部分は 人の手を離れていく 例外も考えられる ・その時のAIでは求める精度に達しない部分 ・ミッションクリティカルな部分 ・ゲームやアプリの手触り部分 ・トークン使用料 ©MIXI 61
62. ⼈間の動き⽅はどうなるか？ 基本的な流れ 「こういうことをやりたい」という 要求の起点は人。 タスク設計 タスク 実行 AI AI AI 成果物の 妥当性の確認 ©MIXI AI タスク実行はAIや機械。 やった結果、求めていたものに なっているのか確認・判断する のは人。 62
63. ⼈間の動き⽅はどうなるか？ (細かめver) 要求の発生 タスクの方針を決める 何をAIで行うか決める タスクの設計をする テスト計画書をさくっと作りたいなー リスクベースドでいこう。 E2E自動テストと人でのシステムテストを 計画したい スケジュールは未fixで人が入れるから、リ スク出しとテストアプローチを今回のAIの タスクにしよう タスク実行 (AI) 成果物の妥当性確認 再利用出来るようにするなど完了作業 ©MIXI 63
64. ⼈間の動き⽅はどうなるか？ (細かめver) 要求の発生 テスト計画書をさくっと作りたいなー タスクの方針を決める 何をAIで行うか決める タスクの設計をする リスク出しはエージェントAを使って、それ が終わったらエージェントBでプロダクトリ スクに対応するテストアプローチを記載と するか。 必要となるドキュメントも集めないと。 タスク実行 (AI) 成果物の妥当性確認 再利用出来るようにするなど完了作業 ©MIXI リスクが十分に挙げられて、それを確認する テストアプローチも書けているな 繰り返し使うしチームで使うからSkill化してお こう 64
65. ⼈間による確認の重要性 我々が要求を出し、AIがタスク実行した結果、それが我々が思い描いた要求通 りになっているかは確認しなければわかりません。 重要なこととして「人間が正しく要求を出せているか」 ということもあります（「顧客 が本当に必要だったもの」で検索） 超ゴージャスなチョコパフェが食 べたい！ 要求 違う… そうじゃない… 成果物 へい、お待ち！ 高級チョコソースと こぼれるほどのイクラを のせた超高級パフェ！ (AIによる要求の解釈 ) ©MIXI 65
66. 実際に起きた事例 : テスト項⽬5件事件 これはGPT-5.5で本当にあったお話です……。 ある日、私はAIを使ってテスト観点出し→テスト設計→テスト項目をまとめて出そ うとしたのです。 仕様書や使うデータを用意して、プロンプトを書いてAIを実行しました。 そしたらモノの数分で成果物が出来たじゃありませんか。 私は「早いなー早いなー」と思いながら成果物をチラッと見ました。 そしたらですよ！ テスト項目が……5件しかないのです！！ 私は恐る恐るAIに聞きました。「なんで……？」って。 するとAIは言ったのです。 **おっしゃる通りです。この規模にしてはテスト項目が少ないですね** ©MIXI 66
67. 実際に起きた事例 : AI⼩説事件 私は趣味で小説を書きます。ある時AIを使って文庫1冊程度(10章構成くらい)の 文章を作ってみました。それを楽しみながら読んでいたのですが、途中でこんな 表現が…… 「回復アイテムもないんだ。諦めて地上へ戻るしかない」 彼は第5章と同じ表情を浮かべていた。 「AIが作ったものにレビューはいるのか」という話を聞くようになりました。レビュー 工数増大によるものです。AIはちょっとしたミスをすることもありますが、それより つらいのが、時折人間では起こらないような想像を超えた謎のミスをすることがあ ります。 人間のレビューか、何かしらのレビュー機構は必要です 。 ©MIXI 67
68. これからQA/テストエンジニアは どうなっていくのか？ ~ 役割の再定義 ~ ©MIXI
69. forプロダクト : テストシステム基盤の開発者 我々はシステムテストレベルだけではなく、開発プロセス全体での活動が出来る ようになります。 開発プロセス全体を通したテストについてのエンジニアリング、つまり開発プロセ ス全体を一気通貫でテストをする仕組み (システム )やパイプライン構築が出来 ること――これは組織が喉から手が出るほど欲しがります。 あくまで一例 テスト計画 全テストレベル対象 ©MIXI テスト 分析・設計 Unit test実装 実行 Integration test 実装 実行 E2E自動テスト 実装 実行 人間用テスト 項目生成 実行 テストレポート 集計 69
70. テストエンジニアの再定義 テスト活動にフォーカスして 開発プロセス全体のテスト活動を 整備・仕組み化する テストエンジニア ©MIXI 70
71. forプロジェクト : PJ全体の品質保証活動を導く 品質保証活動はPJメンバー全員で意識し行うものです。 しかしPJメンバー全員が品質保証に明るいわけではありません。 よって、PJが狙ったものを狙った通り作るためにも、モノづくりのルールやみんな の動き方 (プロセス )、AIの使い方やガードレール設定といった「良いものを作る 環境」を整備 する必要があります。 また、メンバーへの品質保証活動の教育・育成 を行うことも重要です。 よくある釣りの例えだと、「魚」を与えるのではなく、「釣り場」を整え「釣り方」を伝 えてメンバーが自分たちで魚を獲れるようにするといったイメージです。 人・AIを含めた PJのルール・プロセスの 設定 ©MIXI 品質保証観点での メンバーの 教育・育成 71
72. QAエンジニアの再定義 品質保証活動にフォーカスして 環境(ルール・プロセス )整備と教育を行い PJ全体で品質保証活動できるようにする QAエンジニア ©MIXI 72
73. 多くの活動がAIを使うことによって なくなった時代 ©MIXI
74. AIにより作業が削ぎ落されていった未来 AI使用は人が起点と言いましたが、テスト設計をAIで行う…テストプロセス全体を AIで行う…全体のプロセス整備をAIで行う…というように、AIだけで良しの部分が 増え、起点はどんどん上がっていくことが予想されます。 AIで、こういった作業が削ぎ落されていった結果、原初の問いに行きつきます。 ©MIXI 74
75. 我々は何を実現したかったのか？ 我々が実現したいことは何か？ ©MIXI 75
76. 我々は何を実現したかったのか？ ユーザーを 満足させたい！ ©MIXI 76
77. 実現したいことは変わらない。実現⼿段が変わっていく この「ユーザーを満足させたい！」は根源であり、これまでも、そしてAI時代になっ てからも変わることはありません。 これまではそれを手動テストで実現していましたが、昨今ではAIを使って実現して います。 我々が実現したいことは変わることはなく、実現手段が変わるのです。 ©MIXI 昔 ユーザーを満足させたい！ クリティカルなバグはない 方が満足できるよね 手動テスト 今 ユーザーを満足させたい！ クリティカルなバグはない 方が満足できるよね AIを使ったテスト 将来 ユーザーを満足させたい！ みなさん次第で出来ることは無限大！ 77
78. 我々の仕事の再定義 ユーザー満足を実現する 仕組みを作る ©MIXI 78
79. AI時代における テストの基礎の再定義 ©MIXI
80. テスト＝システムテストレベルではない テスト = 開発プロセス全体のテスト活動 現在のQA/テスト業界の暗黙の了解として「テスト」というと基本的にはシステムテ ストレベル以上の話であることが多いです。 しかしAIを使うことによって、今まで尻込みしていた場所に手を伸ばせるように なったのです。システムテストレベルだけのテストから飛び出すことができます。 テスト = 開発プロセス全体のテスト活動として捉え直すと視野も活動領域も広 がります。 ©MIXI 80
81. あなたの専⾨領域の知識が最重要① テストにまつわる知識を 学ぶ必要がある 作業するのはAIだとしても「こういうテストがしたい」や「こういうテストの仕組み を作りたい」という最初の起点 (要求)はあなたが出す必要 があります。これはあ なたの中にその「発想ができる種 (知識)」がないと芽生えません。 例えば「APIテスト」を知らなければ「APIの戻り値を確認して担保しよう」という発 想に至ることはありません。もちろんAIにその指示を出すこともできません。 ©MIXI 81
82. あなたの専⾨領域の知識が最重要② テストを学び 成果物を判断 (評価)できなければならない AIという便利な道具を手にしたところで、使うのはあなた です。 知識がなければ、AIの出力の妥当性の判断はできません。照らし合わせるベー スラインが頭の中にないためです。結果「AIの出力は全て合っている」という思い 込みも発生します。 テストを知らない人ほど「これでいいじゃん？」「レビューなんている？」となってい るのを見てきています。 自分の中に良し悪しがわかる判断材料を用意する必要 があります。 ©MIXI 82
83. 意図通りの指⽰が出来る⼒、読解する⼒ AIに自分の意図通りの指示が出来る力 AIの回答を読解する力 ~ 国語力 ~ AIが指示通り動いてくれないという人のプロンプトを見ると、曖昧な書き方をし ていることが多いです。 日本語は主語や目的語が抜けたりと、構造の自由度が大きい言語です。抜けに よって意図がAIに伝わらないことがあります。 またAIからの回答を読解できないと、AIの間違いや自分の考えとの齟齬に気づ けません。文章を正しく読み取る力も必要です。 ©MIXI 83
84. AIを使いこなせる⼒ AIを使いこなせる力 今後、より一層AIを使った業務が増えていきます。 これまでの「パソコンが使えること」や「Officeが使えること」レベルで当たり前に使 えることを求められるようになっていくと思われます。 先の国語力はもちろん、今のAIツールではどういったことが出来るかの基礎は 押さえておいたほうが良い でしょう。 ©MIXI 84
85. 使うモノに適したプロセスにできる⼒ Don’t pave the cow path. “牛が踏み固めてできた道を、そのまま舗装するな ” 牛が何度も歩いた結果、自然にできた曲がりくねった道を「昔から使われている から」という理由で、そのまま立派な道路にしてしまうイメージです。 古いやり方や非効率なテストを、見直さずにそのまま自動化や AI化してはいけ ません。 今はまさに転換期です。既存のやり方を、今のやり方に適したプロセスに変えら れる力が必要 です。 ©MIXI 85
86. AI時代のQA/テストエンジニアが 学ぶこと ©MIXI
87. AI時代のQA/テストエンジニアが学ぶこと AIの基礎知識 テストの基礎知識 開発の基礎知識 開発プロセス全体を通した 仕組み化をするための知識 ©MIXI 87
88. AIの基礎知識 ~ 重要部分ピックアップ ~ ©MIXI
89. AIの基礎知識 会社で使っていい AIを知る (情報漏洩、セキュリティ ) CodexやClaudeなど、現在は様々なAIツールがあります。 便利だからといって自由に選ぶのではなく、会社で使用を認められている AIだ けを使いましょう。 入力した情報が学習に利用されるか、どのくらい保存されるか、誰がアクセスでき るかは、サービスの契約や設定によって異なります。 機密情報、個人情報、顧客情報などを入力する前に、必ず社内ルールと利用条 件を確認してください。 未承認のツールに業務情報を入力すると、情報漏洩につながる 可能性があり ます。 89 ©MIXI
90. AIの基礎知識 AIが得意なこと、苦手なことを知る AIは、文章の作成や要約、情報の整理、アイデア出し、プログラムの作成などを 得意としています。 一方で、暗黙のルール、最新情報、正確性が必要な判断などは苦手です。 また、AIは自信があるように間違った回答をすることがあります。 大量の内容を一度に作らせたときに、一部が抜け落ちることもあります。 AIの得意・不得意を理解し、どこまでを AIに任せ、どこからを人が確認するのか を判断できることが大切 です。 ©MIXI 90
91. AIの基礎知識 コンテキストの与え方を知る AIの出力は、指示の書き方だけでなく、どのような背景情報 (コンテキスト )を与 えたかによって大きく変わります。 目的、対象、前提条件、制約、出力形式、参考資料、過去の事例などを与えるこ とで、AIはより状況に合った回答を出せるようになります。 逆に、必要な情報を与えずに「いい感じに作って」と頼んでも、期待した結果には なりにくいです。 単にプロンプトのテクニックを覚えるのではなく、AIを使って作業するために必要 な情報を整理し、過不足なく渡せるようになることが重要 です。 ©MIXI 91
92. AIの基礎知識 モデルを知る AIツールには複数のモデルがあり、それぞれ性能、速度、利用料金、得意な作業 などが異なります。 常に一番賢いモデルを使えばよいわけではありません。高性能なモデルほ ど、利用料金や処理時間が大きくなる場合があります。 文章の整形や簡単な分類などには軽量なモデルを使い、複雑な分析や設計には 高性能なモデルを使うなど、作業に応じた使い分けが必要です。 モデルは頻繁に変わるため、すべてを細かく覚える必要はありません。 どの程度の作業に、どの程度のモデルが必要なのかを試しながら把握し、品 質とコストのバランスを考えられる ようになりましょう。 ©MIXI 92
93. AIの基礎知識 ツールの機能を知る CodexやClaudeなどのAIツールは様々ありますが、できることは似通っていま す。重要な機能は把握しておくとよいです。 Skills… 「こういう処理をして」という作業指示書みたいなもの。定型作業の自動化の他、「テスト観点 skill」などを 作り、自分たちのやり方を他チームに渡すような使い方が可能 プランモード… 作業を始める前にどのように作業するかの計画を立てるモード。作業前に AIがどう作業しようとし ているかがわかる 外部ツール連携 (コネクタ/プラグイン/MCP)… 外部ツールとの接続を行う。例えば Notionとつないで、その内容を コンテキストとして読み込むなどが可能になる ©MIXI 93
94. テストの基礎知識 ~ 重要部分ピックアップ ~ ©MIXI
95. テストの基礎 テストの一般用語を知る 前に探索的テストのことを「ウォークスルー」と呼んでいた現場がありました。一般 的なテスト用語ではウォークスルーはレビュー方法です。 こういった現場でのみ通じる言葉でAIに「ウォークスルーのやり方を教えて」と いっても正しい回答を導けません。 まずは、一般的に通じるテストの共通語を覚えること がAIを使うためにも優先で す。 オススメ本 JSTQBのシラバス(無料) ソフトウェアテスト教科書 JSTQB Foundation 第5版 シラバス2023対応 大西 建児 (著), 湯本 剛 (著), 町田 欣史 (著), 福田 里奈 (著), 角田 俊 (著), 藤原 考功 (著), 大段 智広 (著) ©MIXI 95
96. テストの基礎 テストを体系的に知る テストと一言で言っても様々な活動があることを先に示しました。 どういった活動があるのか、その活動はどういったことを指しているのかを知る 必要があります。そうしないとAIで「仕様通り動くか確認するためのテストケース 作って」という状態になってしまいます。 また知ることで自分たちの立ち位置、足りないもの、余計なものも見えてきま す。 オススメ本 JSTQBのシラバス(無料) ソフトウェアテスト教科書 JSTQB Foundation 第5版 シラバス2023対応 大西 建児 (著), 湯本 剛 (著), 町田 欣史 (著), 福田 里奈 (著), 角田 俊 (著), 藤原 考功 (著), 大段 智広 (著) ©MIXI 96
97. テストの基礎 テスト設計を学ぶ・使う 「仕様通り動くか」だけではテストが足りません。 境界値だったときは問題がない のか、状態の遷移はひとつだけでいいのかなど、仕様からは見えないパターン までテストをする設計していく必要があります。 AIも出せますが、レビューをする と明らかにパターン不足の場合もあります。AIの成果物評価が出来るために も、テスト設計を理解できるように学び、実際に手を動かして把握しておく必要が あります。 オススメ本 ［改訂新版］マインドマップから始めるソフトウェアテスト 池田 暁 (著), 鈴木 三紀夫 (著) ソフトウェアテスト技法練習帳 ~知識を経験に変える 40問~ ©MIXI 梅津 正洋 (著), 竹内 亜未 (著), 伊藤 由貴 (著), 浦山 さつき (著), 佐々木 千絵美 (著), 高橋 理 (著), 武田 春恵 (著), 根本 紀之 (著), 藤沢 耕助 (著), 真鍋 俊之 (著), 山岡 悠 (著), 吉田 直史 (著) 97
98. 開発の基礎知識 ~ 重要部分ピックアップ ~ ©MIXI
99. 開発の基礎知識 プログラミングの基礎を知る 今のテストの領域を広げるためにもプログラミングの基礎を知っておくのは良いで す。メソッドが集まってプログラムは構成されている、などです。 本などで読んでも難しいので、AIを使って小さなツールやゲームを開発してみる のが早いです。 開発した後に一つずつ AIに質問してどう動いているか把握すると良いです。 い くら質問しても怒らないので理解できるまで質問してみましょう。 オススメ本 すぐわかる！ ぷよぷよプログラミング SEGA公式ガイドブック ©MIXI 紀平 拓男 (著) 99
100. 開発の基礎知識 Gitの基礎を知る 今のプログラムの管理はほとんどの組織がGitを使って行われます。 これを知ることで、開発側との協業もやりやすくなります。 プログラム作成練習を行ったら、Githubに保存するといった練習を行うとよいで す。また自分で作ったものならいくらでも失敗ができます。様々試してみましょう。 ここもAIを通して操作可能ですし、AIが詳しい領域です。わからないことは事細か に聞いて覚えるとよいです。 オススメ本 改訂2版 わかばちゃんと学ぶ Git使い方入門 ©MIXI 湊川あい (著), DQNEO (著) 100
101. 開発の基礎知識 Unit testの基礎を知る 恐らくUnit testの存在は知っていても、どんなテストなのか、システムテストと何が 違うのか知らない人もいるかと思います。 知ることによって、どういった場面で Unit testが有効なのかという理解も進み ます。 実際に作ったプログラムに対して、AIを使ってUnit testを書いてみると良いです。 またAIに詳細に話を聞いて把握するようにすると勉強になります。 日本語が使える言語なら、テストメソッド名を「何をテストするか」(テスト意図)を日 本語で記載するとわかりやすいです。 オススメ本 単体テストの考え方 /使い方 ©MIXI Vladimir Khorikov (著), 須田智之 (翻訳) 101
102. 開発の基礎知識 Webアプリの基礎を知る 今扱っているモノのほとんどが、クライアントがAPIを通してサーバーにアクセス し、サーバーがDBを読み書きするモノかと思います。 その一連の流れをおおよそ知っておくと、今後どういったテストが必要なのかを 知るきっかけとなります。 ここもAIを使って自作してみることをお勧めします。AWSなどは初心者が使うと課 金やセキュリティ周りで危ないので、ローカルで完結するような、ちょっとした保存 をする程度の小さな構成を作ってみましょう。FastAPI, SQLiteなどが使えます。 ©MIXI 102
103. 開発の基礎知識 DB, APIの基礎を知る APIのリクエストとレスポンス、HTTPメソッドやステータスコード、DBの検索・登録 ・更新・削除といった基礎を知ることで、画面の裏側で何が起きているのかを理解 できます。 その一連の流れがわかると、どこで不具合が起こり得るのか、どの層をどのよ うにテストすべきかを考えられるようになります。 これもローカルで動かせる小さなWebアプリをAIを使って開発し、API、DBの処理 を詳しくAIに聞いて学ぶのがよさそうです。 ©MIXI 103
104. 開発プロセス全体を通した 仕組み化をするための知識 ©MIXI
105. 開発プロセス全体を通した仕組み化をするための知識 プロダクト全体のテストを知る プログラミングや DB、APIを学ぶと、システムテストだけでは見えなかった必要 なテストが見えてきます。 システムテストの観点だけではなく、一連の開発を通して見える、どういったところ にどういったテストが必要なのかを学び、考えましょう。 自分のローカルでWebアプリを作ったら、そのWebアプリを公開するようなつもり で、開発プロセス全体でのテスト計画、テスト分析、テスト設計、テスト実装、テス ト実行、テストレポートの練習をしてみるとよいです。 ©MIXI 105
106. 開発プロセス全体を通した仕組み化をするための知識 仕組み化の方法を知る 今後AIを使って様々なテストを出来る様にしたり、品質保証活動の効率化をして いくことになります。 ただ、それが局所的に点在しているだけでは、上手に活用されない ことが考え られます。 点と点をつないで線にする、つまり、必要なテストや品質保証活動が継続的に 実行される仕組みにする必要があります。 こういった仕組みやパイプラインを作 るための知識をつけておくとプロセスづくりに活用できます。 一例としてはGitHub Actionsがあります。勉強方法として自分が作ったアプリに 対して一連のテストが動くようなGitHub Actionsを組んでみるのもよいでしょう。 ©MIXI 106
107. まとめ ©MIXI
108. まとめ① AIを擬⼈化しない。AIは⼈が使う道具である。 AIは道具である。 道具である以上、起点は人である。 目的を果たすため、人が道具を上手に使う。 奪われたのは仕事そのものではない。 一部のタスク実行工程である。 ©MIXI 108
109. まとめ② 品質の世界のどこにだって⾏ける あなたは最強の武器を手に入れました！ 広い品質の世界のどこにだって行けます。 あとはあなたがやりたいこと次第です。 ©MIXI 109
110. まとめ③ 役割の再定義 テストエンジニア テスト活動にフォーカスして 開発プロセス全体のテスト活動を整備・仕組み化する QAエンジニア 品質保証活動にフォーカスして 環境(ルール・プロセス )整備と教育を行い PJ全体で品質保証活動できるようにする 我々の仕事は … ユーザー満足を実現する仕組みを作ること ©MIXI 110
111. まとめ④ テストの基礎の再定義 テスト = 開発プロセス全体のテスト活動 テストの基礎知識を身に付けること 成果物の妥当性を評価できること 意図通り伝える /受け取るための国語力 AIを使いこなせること 今に適したプロセスに変えていくこと ©MIXI 111
112. 我々が 実現したいことは何も変わっていない。 変わるのは実現⼿段である。 ©MIXI
113. ©MIXI
114. Appendix① AI時代でも勉強は必要 ©MIXI
115. AI時代でも勉強は必要 AI時代だし、勉強しなくてもAIが教えてくれる… そう思っている方もいるのではないでしょうか？ しかし大事なこととして、「知らないことは AIに 伝えることができない /AIに聞くことができな い」ということがあります。 なぜなら知らないからです。あなたの世界にそ の言葉、その概念がないからです。 よって聞くことも近づくこともできないのです。 知識によって、あなたが見ることができる世界 が広がるのです。 ©MIXI テスターちゃん箸休め回『勉強するとどうなるの？』より 115
116. Appendix② AIがテスト⼯程を通しで実⾏する仕組み ©MIXI
117. テスト計画‧分析‧設計‧実装‧実⾏‧ レポートまでを通しで⾃動実⾏する Skillを開発した話 https://zenn.dev/jam0824/articles/c84a2ef393ee70 ©MIXI
118. AIでテストケースを作った際のトレーサビリティの問題 問題 いきなりテストケースを作ると 「そのテストケースはなぜ必要か」と 「何が抜けているか」を追えない ©MIXI 118
119. 計画からレポートまでを全⾃動で実⾏するSkill 各Skillのオーケストレーションにより計画から分析・設計・実装・実行・レポート までを全自動実行 します。 Unit／Integration／E2E／人間実行を分け、中間成果物を作り 次工程に渡しな がら進みます。 リスク→観点→設計→項目と追えるように紐づけている ことが特徴です。 Skill構成 テスト計画 ©MIXI テスト 分析 Unit test設計 実装 実行 Integration test 設計 実装 実行 E2E自動テスト 設計 実装 実行 人間用テスト 設計 実装 実行 テストレポート 集計 119
120. ⻑い⼯程ほど、⼯程ごとにレビューを閉じる 開始条件と入力 工程ごとに成果物とレビューを閉じる 方針・前提を確認 中間成果物を作成 問題に優先度を付けてレビュー 計画・分析・設計・ケース作成の各工程 で「成果物 → レビュー → 修正」を優先 度が高い修正がなくなるまで繰り返す。 大きな問題を修正 ©MIXI 大きな問題がなくなったか確認 不明点は質問票として書き出し、AIの推測で 埋めない。 次工程へ引き渡す 単純な連続実行ではなく、工程ごとにスレッド を分けて丁寧に進める。 120
121. IDの連鎖が、テストケースの「理由」を残す リスクID テストアプローチID テスト観点ID テスト設計ID コードベース用ケース E2E自動用ケース 人間実行用ケース 実行結果・Issue ©MIXI トレーサビリティを確立し 仕様変更時も、 IDをたどって影響範囲を追える 121
122. テストケースは、実⾏主体ごとに分けて出⼒する コードベース用 ©MIXI Unit／Integrationのテストコードを生成・レビュー・実行 E2E自動用 PlaywrightでUIを通すテストを生成・レビュー・実行 人間用 機械で判断できないもの(人が実行した方が良いもの) 質問待ち 不明点、未実装は質問を行う。推測でケースにしない。 122
123. 使い⽅ 最低限の入力は、仕様とコードの場所 過去バグやプロジェクト固有の観点も、追加の入力として渡せます。 入力：仕様、プロダクションコード、任意の追加情報 実行：run-test-process が工程ごとにskillを呼び出す 目安：サンプルでは全工程が約1時間15分。工程ごとに丁寧に進める ©MIXI ※リスクやテスト観点などは全て仕様などのテストベースから導かれる。その段階ではコードは使われない。 実装時にコードベースが必要なためコードの場所が必要 123
124. 実⾏結果は、未完了も含めて⾒える形に戻す 記事掲載の実例 ©MIXI AI側で完了した結果だけでなく、 ・実行率／ Pass／Fail ・未実行／質問待ち／未実装 ・コードベース／E2EのIssue を一画面にまとめます。 「完了」ではなく、人が次を判断する入口です。 124
125. 計画(全テストレベル)からレポートまでを全⾃動で実⾏するSkill AIは トレーサビリティと中間成果物の維持を 現実的にする。 Zenn: zenn.dev/jam0824/articles/c84a2ef393ee70 GitHub: github.com/jam0824/ai_test_process_skills ©MIXI 125
126. ©MIXI