AIコーディングはQAチームに何をもたらすか——理解負債・技術負債・認知負債との向き合い方

【QAチーム ブログリレー7日目】の記事です。

はじめに

こんにちは、QAエンジニアの末吉です。最近東京を離れ、楽器不可のマンションに引っ越したため、ピアノが弾けなくなりました。悲しいばかり。

これは浜松ICにあるローランド製の電子グランドピアノ

突然ですが、私が担当するUnit4（m3.com開発チーム）のQAエンジニアには、開発経験がほとんどないメンバーもいます。

そういったメンバーが今では、ブランチを切り、Playwrightのテストコードを修正し、CIの失敗を自分で直してマージリクエスト（MR）を出せるようになっています。この半年で、チームが関わるリポジトリの8割以上にPlaywrightを導入した取り組みの話です。

この記事では、そこに至るまでのプロセスと、AI導入に伴って見えてきた「理解負債・技術負債・認知負債」という3つの課題への向き合い方を書こうと思います。

iOSビルドの凡ミスから学ぶ、FlutterのビルドキャッシュとAOTコンパイルの仕組み

ソフトウェアエンジニアの末永です。私は個人開発でFlutter製のモバイルアプリを開発しています。このアプリを開発している中でアプリのビルド周りでハマってしまったことがあり、その際ビルドシステムに関してしっかりと調査しました。この記事はその調査の際に書いたものです。*1

なお、本記事は次のバージョンを対象とした内容となっています。

• Flutter: 3.38.0
• Dart: 3.10.0

また、ビルド対象はiOSとAndroidのモバイルアプリのみとします。

*1:私は業務ではFlutterアプリの開発をしておらず、あくまで個人開発での経験に基づく内容です。

ICLR2026が開催中なので、エムスリー AI・機械学習チームの推し論文を勝手に紹介するぜ！

こんにちは。エンジニアリンググループのAI・機械学習チームに所属している鴨田 です。弊チームでは毎週1時間の技術共有会を実施しており、各自が担当するプロダクトの技術や、最近読んだ論文を紹介しています。今週はICLR2026が開催されていることもあり、同学会の論文読み会となりました。1セッションにつき1名が担当し、各自が選定した論文の詳細について解説しました。本ブログではその一部として、セッションごとの「推し論文」を紹介します。

まだ読んでいない方は前回のAAAI2026の輪読会ブログも是非ご覧になってください

www.m3tech.blog

ICLR 2026からトップページバナーを引用

PlaywrightとClaude Codeでやってみよう、手軽に始めるテスト自動実行

【QAチーム ブログリレー6日目】の記事です。

はじめに

こんにちは。エンジニアリンググループ QA （QualityAssurance） チームの中塚です。 2週間ほど前からバジルの水耕栽培にチャレンジしていて、少しずつ大きくなる双葉を見守るのが毎朝の楽しみです。肥料を溶かした水だけで本当にあんなに大きく育つのか？自由研究の気分で楽しく観察しています。

画像はAI（Gemini）により生成されたイメージです。このブログ記事の内容から生成してもらいました。バジルの鉢植えもあってかわいい！

さて、私は普段コンシューマ向けサービス全般のQAの設計、実施、計画、その他諸々の活動をしています。
その中で、時々このような手動でやるには辛いテストが必要になることがあります。

• サービスの各ページにアクセスし、契約期間内ならアクセスできるが契約期間外ならアクセスできないことを確認したい。ページのリストは無く事前調査が必要で、おそらく数十ページを繰り返しアクセスして比較する
• 特定のキーワードを検出し、警告するようなチェックシステムをテストしたい。外部LLMによるチェックなのでキーワードリストはないが、精度を見ておきたいのでさまざまなキーワードを試して動作確認したい。

このように、同じような操作を何回も繰り返したり、ページの調査やキーワードリストの準備といった事前調査などを含む地道な作業が必要になるテストを自動生成・自動実行できないか試したところ、PlaywrightとClaude Codeを使い手軽にテストコード生成〜実施〜レポート出力までが実現できたので、その実践例をご紹介します。

Playwright移行を自律化。Claude Codeで実現するマルチエージェント設計

【QAチーム ブログリレー5日目】の記事です。

こんにちは。エンジニアリンググループ QAチームの須賀です。 最近エムスリーに復帰しました。 私は2月1日に入社してからQAエンジニアも使い放題のClaude Codeを用いてmabl（ノーコードのE2Eテストツール）の自動テストをPlaywrightにリプレースしています。 AIエージェントを用いた開発は未経験だったため、最初は期待するコードをなかなか生成できず試行錯誤の連続でした。しかし、最近では人の介入なしで期待するコードが生成できることも増えてきました。 試行錯誤の結果、AIエージェントの活用において重要だったのは、実は『人間同士が円滑に仕事をするためのマネジメント方法』を適用することだと気づきました。

本記事では、次の参考書籍の知見をベースにしつつ、実際のリプレース業務において試行錯誤して私が構築した、6つのサブエージェントを活用したワークフロー設計の実例を紹介します。

参考書籍

gihyo.jp

仕様の文体はAIテスト生成に影響するか？クノー『文体練習』に倣って実験

【QAチーム ブログリレー4日目】

はじめに

こんにちは、QAチームの草場です。

レーモン・クノーの『文体練習』という本をご存知でしょうか？ 1947年に出版されたこの本は、とある短い１ストーリーを99通りの文体で書きわけるもので、語られるのは同じストーリーなのに文体を変えるだけで得られる情報や印象の変化を感じられる味わい深い本です。

今回は「文体練習」を参考に、システムの仕様を表す文体として最適なものは何か？ もしくは文体による差は無いのか？をカジュアルに実験してみました。

仕様は、書き手や場面によって様々な文体で書かれることがあります。決められた書式で厳密に書かれた物、広く知られた記法では無いが構造的に整理された物、Slackに貼られたメモのような物、ユーザーからの口伝を文字起こしした物など、多種多様です。どのテキストでも同じ機能の話をしているとして、そこから読み取れる情報量やテスト観点の数は、同じなのでしょうか？ 異なるのでしょうか？

このように、実験してみました。架空のフードデリバリーアプリの注文フローを11の文体で書き分け、それぞれをAIに読ませてテストケースを生成させ、事前に人間が作成したテストケースに対するカバレッジを比較するというものです。

結論を先に言うと、文体によるカバレッジの差はありました。ただし、それ以上にAIの実行ごとのブレや評価方法の影響が大きく、「文体にこだわる必要は薄い」という結果になりました。以下、実験の詳細と結果です。

QAエンジニアがClaude Codeを半年間使って気づいたこと 〜テスト自動化74%高速化を実現した3つの技術アプローチ〜

【QAチーム ブログリレー3日目】Claude Code、MCP、Playwrightを活用したE2Eテスト自動化の半年間の実践から得た気づきを共有します。技術的なアプローチだけでなく、「AI活用に不安があったけど、実はこれまでのドキュメント整備が土台になっていた」という発見についてもお伝えします。

テストプレイをサボりすぎたRPG

こんにちは、エムスリー QAチームの今井です。最近話題の「テストプレイをサボりすぎたRPG」をご存知でしょうか？ テストをサボりすぎてバグだらけになったRPGを、プレイヤーが「ミス」を探しながら進めるというフリーゲームです。私たちQAはそうならないよう、いかに効率よくテストを回すかが課題でした。

TL;DR

• エムスリーではClaude Code使い放題: QAエンジニアも最新AIツールをフル活用
• テスト実行時間74%短縮（既存ツール 105分 → Playwright 27分）、年間約68時間分のCI/CD待ち時間を削減
• 67件のMR/PRをマージ（E2Eテスト、リリース作業自動化、Agent開発など）
• MCP（Model Context Protocol）で外部ツールと連携し、テスト〜ドキュメント更新を一気通貫で自動化