AIが前提になった2025年、QAに起きた変化
IVRyのQAエンジニアの関です。
この記事は「AI ブログリレー」11日目の投稿です。前日は、AIエンジニアのMachidaさんによる、"Agent, Agent, Agent (re:Invent 2025 参加記録) "が公開されていました。ぜひこちらの記事も読んでいただけると幸いです！
2025年は、AIが便利になったというより、AIがいる前提でQAの進め方を組み立てる場面が増えた年でした。
そこで今回は、IVRyでQAをしている私の視点から、AIを活用した情報キャッチアップやE2Eの作成・保守がどう変わったか、そしてその変化が改善や仕組みづくりの余白につながった実感を中心に振り返っていこうと思います。
①情報キャッチアップの工数が1/3になった
個人的に一番大きい変化は、QA設計に必要な情報を素早くキャッチアップできるようになったことです。
PRや仕様書を読む時間が減ったというより、AIを理解の代替ではなく補助として使うことで、結果的に初動の時間が大幅に短縮されました。
案件規模にもよりますが、以前は情報キャッチアップに30分〜1時間、開発者への仕様確認に15分ほどかかっていました。今は平均10〜15分でキャッチアップの土台を作り、その内容をもとに開発者と非同期で確認を進められるようになりました。
開発スピードを意識して進める中で、最初から要件を完璧に固めるより、ある程度の粒度で実装を進めながら、細かい仕様を固めていく場面があります。その際、情報源がSlackやNotionなどに分散し、ドキュメントの更新が追いつかなくなることもあります。この曖昧さや情報の分散に対して、AIにSlack MCP Notion MCPのようなものを組み合わせ関連情報を横断的に集約しAIにまとめてもらった上で、 決まっていること/ 曖昧なところ/ 未確定なこと を仕分けしてもらっています。さらに、根拠となるスレッドやページもセットで出力させることで、確認が必要なポイントだけを効率的に拾えるようになり、初動の整理がより短いサイクルで回せるようになりました。
こうした情報の整理に加えて、実装上どうなっているかを素早く辿れる状態を作ることもキャッチアップの速度に直結していきました。コードは複数のリポジトリに分かれているものの、仕様把握や不具合調査では横断的に追う場面が多く、それぞれで見ていると接続点や依存関係が見えづらい課題がありました。
そこで、複数のリポジトリをサブモジュールを用いて一箇所に集約し、擬似モノレポ化を行い、フロント・バックエンド・モバイル・電話機能までを一つの文脈として管理できるようにしました。この構成とCodemapsのような見取り図を使って関連領域を先に俯瞰することで、影響調査の当たりをつけるスピードがさらに上がりました。
結果としてキャッチアップだけでなく、バグ発見時の原因仮説の立てやすさや、バグ報告の精度にも効いてきたと感じています。
②E2Eの新規作成とメンテナンスの初動が一気に軽くなった
2025年は、E2Eシナリオの新規作成とメンテナンスの進め方が、はっきり別物になった年だったと思います。特に、新規作成時や改修の初動が軽くなった印象です。
2025年の前半では、Playwright MCP を使いながら試行錯誤してE2Eのテストコードを生成していましたが、狙った形のコードが一発で出ることは少なく、人が整える時間がまだそれなりに残る印象でした。
ただ2025年の後半になるにつれ、CursorやClaude Codeなどの生成精度や文脈理解が上がり、テストの叩き台が実務レベルに近い形で出てくるケースが増えてきました。CursorのPlan ModeやAgent系の改善によって、テストの狙いを整理しながら作る流れが自然になったのは大きい変化です。
さらにPlaywright Test Agentsを活用すると、計画を作るPlanner、コードに落とすGenerator、失敗を直すHealerという役割が用意されていることで、AIを使ったE2Eの新規作成・保守の進め方を整理しやすくなりました。特にCursorのComposer1と組み合わせると、計画の意図を保ったまま生成と修正を往復できるため、速度はもう一段上がる感覚があります。
またIVRyの特性上、テストシナリオに電話の発信や着信が絡むケースが多くあります。例えばログイン状態で着信を受けて通話に入り、その通話履歴が取得・表示されているかを確認するようなシナリオです。事前に、このケースでは電話発信が必要なため、特定のメソッドを用いるといったルールや補助情報をコンテキストとして読み込ませておくと、そうした前提も踏まえた形でコードを出力してくれるようになり、実装の精度と速度がさらに上がっていきました。
③AIを活用したことで生まれた時間によって改善や社外活動に割く時間が増えた
AIでキャッチアップや設計初動、自動テストの叩き台づくりが軽くなった分、改善活動や社外イベントへの参加・登壇に割ける時間が明らかに増えました。
単に作業が減ったというより、次、何を良くするか を考えて試す余白が生まれた感覚が近いです。
例えば、QA定例の場で、AI時代のQAプロセスをどう設計し直すべきかを議論したり、QAプロセス内のどこにAIを組み込めそうかを棚卸しして、実際に小さく試してみたり。自動テストについても、作り方だけではなく、メンテナンスの軸や判断基準を見直すところまで手を伸ばせたのは大きかったと思います。
また、登壇やテックブログの公開を通じて、IVRyが何に取り組んでいるかを対外的に発信する機会を増やすことができました。あわせて、地方で開催されるイベントにも初めて参加してみました。QAに限らずAI活用のリアルな悩みや最新事例に触れる機会が増え、社外の話を自分から取りに行く動きが、少しずつ日常になってきたと感じています。
④"まず試してみるか"が当たり前になった
もともと新しい技術が出たら早めに触ってみるほうでしたが、2025年はその回転がもう一段上がった年でした。新しいモデルやツールが出たらまず試し、今の環境で使えるか使えないかの勘所を短時間で掴む。この流れが、特別なイベントではなく普段の習慣として回るようになった感覚があります。
例えばE2Eのテストケース生成や観点のたたき台づくりを試すために、検証用の小さなアプリケーションをサクッと作って試す。良ければ本流に取り込み運用してみて微妙なら即撤退する。完璧に設計してから動くのではなく、まず動かして反応を見ながら最適化する前提が強くなったと思います。
このマインドの変化は、結果的にプロセス見直しやプロセス内にどう取り込んで見るか議論を前に進める土台にもなっています。AIをどう使うかだけでなく、AI前提でどう作り直すかを考えるフェーズに入りつつある。2025年は、その助走が揃った年だったと思います。
この文脈で今取り組んでいるのが、テスト資産の統合を目的とした内製システムの開発です。現状は、スプレッドシートやNotionなど複数のツールに情報が分散しており、リグレッション実施時に横断的に過去の情報を集める必要があったり、テストケースの更新がスムーズに進まなかったりします。過去のテスト結果も十分にまとまりきっておらず、再利用やAI活用の観点でも扱いづらさが残っています。結果として、過去の傾向を踏まえた判断や改善にもつなげにくい状態となっています。
そこで、QA項目、テストケース、テスト結果を一つのシステムで一貫して管理できる仕組みを作っています。テスト管理ツールも選択肢にはありましたが、ユーザー課金によるランニングコストや、AI活用を前提にした細かな要件とのズレを考えると、内製のほうが目的に合うと判断しました。あわせてLLMを組み込み、過去のログや結果から傾向を抽出したり、抜けやすい観点をサジェストしたりといった活用も進めていきたいと考えています。
この仕組みが整えば、テスト資産の検索や更新がシンプルになるだけでなく、過去のケースやバグ傾向を踏まえた観点サジェスト、リグレッション範囲の支援、レポート作成の省力化など、AIを活かしやすい状態に近づけるはずです。
このシステムの実装自体は、Claude CodeやCursorを活用して開発しており触ってみて痒いところやメンテナンスは、その場で実装しています。
2026年に向けて
現状はまず自分で試して手応えを掴み、QA内の最適化に落とし込むところまでを中心に進めていました。2025年は、キャッチアップや設計初動、E2Eの新規作成とメンテナンスなど、AIが効く箇所を自分の手元で小さく試し続けることで、どこまで実務に乗るかの解像度を上げられた年でした。
ただ、2026年はこの取り組みをもう一段広げたいと考えています。AIを前提にするというより、AIもあくまで手段の一つとして捉え、そこで本当に必要なことに対して最適なアプローチをもっと模索していく。その上で、テスト設計の進め方や開発者との分担、自動化の位置付け、リリース前後の品質判断といったテーマを、個人の工夫で終わらせず、プロジェクトの型として扱えるようにしていきたいです。
具体的には、開発側がテストを行うタイミングで使える補助的な仕組みや、案件の特性・過去傾向を踏まえた判断材料を取り出しやすくする仕組みを、プロジェクトに自然に組み込める形で整えていきたいです。初動の判断を速くしつつ精度も上げることで、品質を保ったまま開発サイクルをよりスムーズに回せる状態を目指しています。
2025年に個人の中で育った手応えを、2026年は チームやプロジェクトに反映していく そんな年にしていきたいと思っています。
おわり
2025年は、AIによって初動や判断の進め方が変わり、設計に集中できる時間が増えました。作業をこなすだけで終わらず、次に何を良くするかを試したり、外に向けてIVRyの取り組みを発信したりと、動ける範囲が広がった年だったと感じています。
AI時代のQAエンジニアのあり方やチームへの広げ方など、まだまだ試行錯誤中です。もし似たような課題感があれば、ぜひ気軽にお話しできたら嬉しいです！
