【QAチーム ブログリレー7日目】の記事です。
- はじめに
- 前提：なぜPlaywrightへ移行したか
- 「まずコードを書けるようになろう」は諦めた
- 5つのステップで開発フローへ
- 現在地
- AIだけでは足りなかった：地道な活動
- AI導入と同時に向き合っている3つの負債
- おわりに
- We're hiring!
はじめに
こんにちは、QAエンジニアの末吉です。最近東京を離れ、楽器不可のマンションに引っ越したため、ピアノが弾けなくなりました。悲しいばかり。
突然ですが、私が担当するUnit4（m3.com開発チーム）のQAエンジニアには、開発経験がほとんどないメンバーもいます。
そういったメンバーが今では、ブランチを切り、Playwrightのテストコードを修正し、CIの失敗を自分で直してマージリクエスト（MR）を出せるようになっています。この半年で、チームが関わるリポジトリの8割以上にPlaywrightを導入した取り組みの話です。
この記事では、そこに至るまでのプロセスと、AI導入に伴って見えてきた「理解負債・技術負債・認知負債」という3つの課題への向き合い方を書こうと思います。
前提：なぜPlaywrightへ移行したか
mabl（ノーコードE2Eテストツール）からPlaywrightへの移行の背景についてはこちらの記事で詳しく書いています。
「まずコードを書けるようになろう」は諦めた
最初に考えたのは、チームメンバーにTypeScriptを学んでもらうことでした。ただ、現実的ではありませんでした。日常のQA業務をこなしながら、ゼロからプログラミングを習得するのは時間的にも心理的にもハードルが高い。そもそも作成すべきテストシナリオは山積みで、「学んでから始める」では間に合いません。
そこで発想を変えました。「コードを書けるようになる」のではなく、「AIを足場にして開発フローに参加できるようにする」という目標設定です。
5つのステップで開発フローへ
Step 1: Claude Codeに慣れる
まず取り組んだのは、生成AIそのものへの慣れです。Claude Codeをインストールし、日常業務の中で使う練習から始めました。
ここで大事にしたのは、「なんでも答えてくれる優しい先輩に聞く」感覚で使うことです。余談ですが、私自身も開発エンジニアに仕様を聞くとき、ちょっと恐る恐るになりがちです。忙しそうだし、初歩的な質問はどうかな、と。同じような感覚を持つQAメンバーは多いんじゃないかと思います。でもAIには何度聞いても怒られません。「こんなこと聞いていいのか」という壁がないことが、非開発者にとっては大きな入り口になります。うまくいかなければ「さっきの回答はうまくいかなかった、こういう状況なんだけど」と伝え直す。このやり取りの繰り返し自体が、後のステップで効いてきます。
Step 2: シナリオを「読む」
次に、Playwrightのテストコードを読めるようにしました。書くのはまだ先です。
ここで活用したのが、社内にすでにあったリポジトリです。エムスリーでは他チームが先にPlaywrightを導入しており、ある程度完成されたコードベースが存在していました。それを参考に、コードがどういう構造になっているかを把握していきました。
読む際にはClaude Codeを使いました。「このファイルは何をしているか」「この処理の意味は」と聞きながら読み進めると、ゼロから自力で読み解くより理解が早い。既存のテストシナリオと並べて「この操作がこのコードに対応している」と照らし合わせる作業を繰り返すことで、コードの構造が徐々に見えてきます。完全に理解できなくても、「だいたいこういうことをしているコード」が分かれば十分です。
Step 3: VS Code Codegenを使う
ブラウザを実際に操作すると、その操作に対応するPlaywrightコードが自動生成されるVS CodeのCodegen機能を使い始めました。
「コードは手書きするもの」という思い込みが崩れる瞬間です。自分の操作がコードになる体験を通じて、「コードは操作の記録だ」という直感が生まれます。これがあると、既存のコードを読む解像度も上がります。
このCodegenは、もともと使っていたテストツールのレコーディング機能と同じ感覚で使えました。ブラウザ操作を記録してテストを作るやり方に慣れているメンバーには、特に導入しやすかったです。
Step 4: mablシナリオの移行ができる
Step 1〜3が揃うと、mablのシナリオをPlaywrightに移行できるようになります。
実際の作業では改良の結果、Step 3以降の手順はマルチエージェントで一気通貫に実施しています。シナリオの解析・コード生成・レビューを自動化し、メンバーがやることはエージェントの出力を確認して意図通りかを判断すること。「書く」ではなく「確認して承認する」役割です。詳しい仕組みはこちらの記事をご覧ください。
Step 5: 積み重ねで改良・省力化へ
マルチエージェントで一気通貫の仕組みができてからも、改善は続きます。「このパターンはエージェントが苦手だ」「ここはいつも同じ修正が必要だ」という知見をもとに、エージェントへの指示を見直したり、新しいエージェントを追加したりする段階に入ります。
現在地
現在、チームのQAメンバーは以下ができるようになっています。
- ブランチを切ってコードを修正し、MRを作成する
- CIが失敗したとき、エラーを読んでAIと一緒に修正し、再度MRを出す
- mablシナリオをエージェントに渡して、Playwrightテストとして移行する
コードをゼロから書くことはまだできません。ただ、開発フロー全体を完結させることはできます。これが「AIを足場にする」ということです。
AIだけでは足りなかった：地道な活動
ここまでは5つのステップの話です。ただ、AIは移行を速く進めますが、移行後のテストが元のmablシナリオの意図を正確に再現できているかは別の話です。並行して地道な活動を続けたことが、品質を保つ上で重要でした。
レビューでテストの意図を確認する
AIが生成したコードはそれっぽく見えます。動いてもいます。でも「このステップは元のmablシナリオの何を検証しようとしていたか」を説明できないまま承認しているケースが出てきます。そこで、移行後のテストがmablの意図を正しく再現できているかをレビューで確認する工程を設けています。
リポジトリ導入時には開発者にもレビュアーとして入ってもらい、コメントをもらっています。テストコードへの開発者の視点は、QAだけで閉じていると気づけない観点を拾ってくれます。
リファクタリングで品質の均一化を図る
Playwrightの導入時期によって、リポジトリ間で品質に差が出ていました。早期に導入したものは設計の試行錯誤の跡が残っており、後から入れたものの方が洗練されている、という状態です。
そこで、ログインフローや管理画面のPage Objectなど、複数のリポジトリにまたがる共通コンポーネントをサブモジュール化し、品質の均一化を進めました。AIが個々のリポジトリで生成したコードをそのまま放置せず、共通化できる部分を人間が判断して整理する——この作業がなければ、リポジトリが増えるほど負債も増える一方でした。
AI導入と同時に向き合っている3つの負債
ここまでは成果の話です。並行して、AI活用に伴う3つの負債に向き合ってきました。もともとコードが書けないQAエンジニアがAIに頼る構造は、これらの負債が溜まりやすい。その分、意識的な対策が必要になります。
1. 理解負債：AIが書いたコードを誰も理解しない問題
GoogleのエンジニアリングリードであるAddy Osmaniは、AI生成コードによる「Comprehension Debt（理解負債）」を提唱しています。コードが生まれるスピードに理解が追いつかなくなり、「なぜこうなっているか」を誰も説明できない状態が蓄積していく、という問題です。
Anthropicの研究（How AI Assistance Affects Coding Skills）でも、AIを使ったグループは使わなかったグループより理解度テストのスコアが17%低く、特にデバッグ能力に最大の差が出たと報告されています。QAエンジニアにとって肝である問題を切り分けるデバッグ能力がAI依存によって落ちていくとしたら、深刻なリスクです。
私たちの対策： 前述のレビューがその実践です。マルチエージェントの自動レビューに加えて人間が確認する工程を残すことで、「誰も理解していないコードがマージされる」状態を避けています。Step 2（シナリオを読む）をあえて学習プロセスに組み込んだのも、同じ理由からです。
2. 技術的負債（新しい形）：AIツール自体の不安定性
私たちのプロセスはClaude Codeに大きく依存しています。そのClaude Codeが2026年3月〜4月にかけて品質低下のインシデントを起こしました（Anthropic公式ポストモーテム）。推論レベルの変更、キャッシングのバグ、システムプロンプトの変更——3つの独立した問題が重なり、ユーザーへの告知なしに品質が低下していた期間があります。
さらに構造的な問題として、マルチエージェントの補完には限界があります。
通常時： エージェントAが誤った出力 → エージェントBが検知 ✅ 推論劣化時： エージェントAが劣化した出力 → エージェントBも同じモデルで劣化したレビュー → 全体が静かに劣化 ⚠️
役割を分担していても、基盤のモデルは共通です。モデルが劣化すれば、多層化した全体が一緒に劣化します。
実際、この問題はチームで体験しています。品質低下の期間中、チームで定めていたエージェントへの指示ルールが丸ごと無視される形でコードが生成されるケースが発生しました。マルチエージェントで生成しているにもかかわらず、どの層でも検出できませんでした。最終的に発覚したのは、人間が手動でレビューしたときです。
私たちの対策： 根本的な解決は、多層化で「分散を吸収する」のではなく「そもそも分散を小さくする」方向にあると考え、現在取り組んでいます。具体的には、skillsやエージェントへの指示ルールの記述を見直しています。自然言語による指示（しかも継ぎ足しされるタイプ）はAIの解釈に幅が生まれ、それが出力のブレになります。そこで、解釈余地を持たせない構造化されたデータ形式やルールへの置き換えを進めています。公式もxmlタグフォーマットの使用を推奨しています。（prompting-best-practices）
3. 認知負債：AIへの過依存でチームの判断力が落ちる
ビクトリア大学のMargaret-Anne Storey教授は、生成AI・エージェントAIの普及によって技術的負債よりも「認知負債（Cognitive Debt）」が問題になると指摘しています。AIに設計や実装を任せるほど、開発者自身がシステム全体を理解できなくなっていく、という問題です。
Anthropicの研究が示すもう一つの示唆は、AIを使う「方法」によって結果が変わるという点です。受動的に「やっておいて」と丸投げするほど理解度は落ち、「なぜこうなるか」を問いながら使うほど理解が保たれる。自分で考えず、AIに判断を丸投げし続けることで、じわじわとチームの判断能力が下がっていく——これが認知負債の本質です。
私たちの対策： 現状は理解負債と同様に、レビューとリファクタリングの徹底が対策になると考えています。「この移行は元の意図を再現できているか」をレビューで確認し、共通化の判断を人間が行う。ブラックボックス化を避けるため、少しスピードを落とした地道な活動です。
おわりに
開発経験がほとんどないメンバーが中心のチームが、AIを足場にPlaywrightの開発フローに参加できるようになりました。 ただ、それは「うまくいった話」の半分です。AIを入れるだけでは負債が積み上がるという認識から、レビューやリファクタリングといった地道な活動を続けています。そういう積み重ねが、チーム全体の底上げにつながると感じています。
生成AIはテスト実行の外にも広がり、QAプロセス全体に及んでいくでしょう。その波に乗りながら、AIに任せた部分に「なぜ」を問い続けること。そのバランスを模索している方の参考になれば嬉しいです。
We're hiring!
エムスリーでは、QAエンジニアを募集しています。Claude Codeに限らず、あらゆるツールが使える魅力的な環境が整っています！是非ご応募ください。
