イベント概要
- イベント：Merpay Tech Talk 〜QAはAIでどう進化する？メルカリグループのAI × QA実践〜
- 主催：株式会社メルペイ
- 登壇者
- yu-gaさん（Merpay QA）：テスト管理ツール「MerQA」を作った人
- komatsunaさん（Merpay QA）：MerQAのテスト設計の判定の仕組みを担当
- taruさん（Merpay QA）：QA Enablement teamで回帰テストの自動化を担当
- masamichiさん（Merpay QA Engineering Director）：モデレーター
印象に残った話を発表ごとにメモしました。発言は要約しています。
発表1：メルカリのAI Nativeをテスト管理から支えるツール MerQA（yu-gaさん）
作ったきっかけ
- 会社の変化
- メルカリの「AI Native」方針。仕事や組織をAI前提で変えていく
- 職能や部門の境界を越える方針。品質の確認もQAだけの仕事にせず、エンジニアもQAできるようにしたい
- 当時のQAの課題
- テスト管理ツールがプロダクトごとに違い、AIの使い方も人それぞれ
- テスト設計・ケース・リグレッション・ナレッジが別々の場所にあり、全体はQAしか把握していなかった
- AI前提にすること、誰でもQAできること、テスト資産を再利用できることを目指して自作
- PoCを上長に見せたのがきっかけで、全社のツールになった
設計の考え方
- AIが先に作業し、人は回答・レビュー・修正をする
- 流れは4工程
- 仕様：AIがQA観点でレビューして質問 → 人が回答
- テスト設計：AIが作成 → 人がレビュー
- テストケース：AIが作成 → 人がレビュー
- 実行・バグ起票：AIが実行 → 人がエビデンスを確認
- 「プロジェクト」の中にリグレッション・ナレッジ・案件ごとのテストプランをまとめる
- 過去のテストプランとナレッジを次の生成で参照する。使うほどプロジェクトに合ったケースが出る
- 画面のほか、ローカルのAIエージェントやSlackボットからMCP経由でも使える
AIを使っている機能
- 静的テスト
- コードの差分とテストケースをAIに渡し、実行せずに成功・失敗を推論させる
- 失敗と判定されたケースは、実行時に優先して確認する
- 足りないテストケースの提案もする
- テスト実行
- 実行先は社内のエージェント基盤か、自分のPCのClaude Code
- E2Eのコードを書くのではなく、ブラウザや実機でケースを1つずつ操作する
- ステップごとに証跡を残す。実行できなければ理由をつけてBlockedにする
- 証跡レビュー
- 別のAIが、スクショ・録画・ログを手順や期待結果と比べる
- 最後に承認するのは人
デモ
- ホテル予約のサンプルサイトで実行
- ローカル実行を選ぶとClaude Codeが立ち上がり、ブラウザを操作（約2分）
- 結果はFailed。必須項目が未選択で先に進めなかった
- 失敗の原因がケースの手順か、プロダクトかは人が判断する
使われるようになって変わったこと
- テスト資産がMerQAに集まってきた
- エンジニアのセルフQAを、QAエンジニアがレビューする使い方が増えた
- 社内ツールなので人数課金がなく、QA以外にも広げやすい
- 社内OSSとして、他のQAからもPRが来る
- yu-gaさんの直近の案件では、テスト実行の約8割をAIが担当（個人の案件の数字）
課題と今後
- 人が触って感じる違和感を拾う機会が減ったと感じた
- 「テストケースを実行できた」と「使いやすさを確認できた」は別の話
- 今後は、実装からQAまでAIがループし、人は最後にまとめてレビューする形を目指す
発表2：MerQAのQAプロセスの設計から、AI生成の品質改善まで（komatsunaさん）
プロセスを先に設計した
- テスト設計を自動化する上で一番大事なのはプロセス
- 8工程に整理：仕様入力 → 仕様Q&A → テスト分析・設計 → 設計レビュー → テストケース作成 → ケースレビュー → 実行 → 結果報告
- テスト分析・設計と、テストケース作成を分けた
- 分析・設計で「何を・どう確認するか」を先に確定する
- ケースのレビューは期待値と手順を見るだけで済む
- リスクに合わせて2つのフローを用意
- フル：設計とケースのレビューが必須
- ライト：途中のレビューを省き、仕様の入力、対象サービスの選択、AIの質問への回答で進める。成果物は最後にまとめて確認できる
テストレベルの振り分け
- 観点ごとに「どの層で見るか」と「どのテストレベルで見るか」を判定する
- テストレベルは5段階：ユニット、サービスAPI、バックエンドフロー、コントラクト、UIフロー
- 下のレベルで網羅し、上のレベルでは代表的な動きだけ見る。同じことを上でやり直さない
- 判定フローは文書にしてQAのレビューで合意してから、MerQAに実装した
AI生成の品質を上げる工夫
- 成果物を見せる
- 最初はテストケースしか出ず、何を見ているかが分からなかった
- テスト分析・設計の結果も出すようにした
- 仕様書が根拠の観点には、仕様書の言葉をそのまま使わせる。ハルシネーション対策
- QAが経験で使っている材料をAIにも渡す
- チームのナレッジ
- 過去のテストケース（何年分も取り込む）
- コードの静的解析による既存仕様
- 仕様書のリンク先
- 関連PR
- 関連PRと仕様書が食い違っていたら、どちらが正しいかを質問として出す
- 過去のケースのインポート機能で、初回から質の高いケースを出せるようにした
- 判断できないときに黙って決めさせない
- 迷ったら広く拾う方に倒す（層が分からなければ両方、レベルが分からなければ下から）
- 「要確認」の印をつけ、人が直すと消える
発表3：4年前の課題から見る、AI時代におけるMerpayのテスト自動化（taruさん）
4年前の課題
- 自動化チームは1人。エンジニアも複数プロジェクトを兼務しており、自動化の時間を確保しづらかった
- バックエンドのテストツールがチームごとにバラバラで、状況を追いにくかった
- アプリの自動化率は14%程度で、成功率も不安定
- 当時の目標は「各チームが自動テストを書いてメンテできる状態」
今の状況
- バックエンド
- ツールをScenarigoに統一し、定期実行の結果を社内ダッシュボードで一元管理
- よく使う短いシナリオを共通基盤としてまとめた
- 既存シナリオの移行や新規作成はAIで進めた
- クライアント
- 自動化率は約70%に（測り方は当時と違う）
- 直近は、定期実行の成功率が90％を超える週が増えている
- AIエージェントがシミュレーターや実機を操作し、画面を見ながら実装・修正する
- 一番大きいのは、メンテできる人が増えたこと
- 機能を変えた本人が、そのテストを直せる機会が増えた
- 成功率の改善は、AIだけでなく協力体制のおかげ
- 各ドメインのQAが自分たちのリグレッションテストを管理する体制を作り始めている
- 4年前の理想に、ようやく近づいてきた
これから
- テストを作るのが簡単になった分、増え続けるテストをどう品質保証に生かすかが新しい課題
- 本数を増やすだけでは効率化しない。変更に関係するテストを選んで実行することが大事
- テストを「どの機能を検証しているか」が分かる資産として管理したい
- 最終的には「この変更にこのテストを実行したので、ここまで確認できた」と説明できる状態を目指す
Q&A
- MerQAはどう作ったか（yu-gaさん）
- コードはほぼAIが書いている。最初は自分で確認していたが、モデルの性能が上がって減った
- 自分が一番のユーザーとして使い、使いにくい所を直すループを回した
- 静的テストの精度は？（yu-gaさん）
- Claude Opus 5.5で、失敗と判定したケースのおよそ9割が実際に失敗していた
- 期待結果があいまいなケースは判定できない
- AIで実行できなかった残り2割は？（yu-gaさん）
- iOSシミュレーターでプッシュ通知が来ないなど、環境の制約
- 認証などの都合でテストデータを自動で準備できず、人が用意する必要があった
- テストレベルの判定精度は？（komatsunaさん）
- かなり良い。間違っても設計レビューで直せる
- トークン削減の工夫は？
- 過去のテストケースを全部分析させるのが一番トークンを使う
- 近いケースだけを選んで渡すようにしている。まだ課題
- 自動テスト同士でテストデータがぶつからないか？
- PR単位で環境を分けるなど、データ基盤が整っているので自動テストではあまり起きない
- 環境を分けにくい処理は、時間を決めて環境を借りる
感想
- 自分がテスト設計をしたときも、仕様書だけでは判断できない部分があった。AIが曖昧な点を勝手に決めず、質問として返す設計に納得した
- 「ケースを実行できたことと、使いやすさを確認できたことは別」という話が印象に残った。AIに実行を任せても、自分で触って考える時間は大事にしたい
- 自動化のスピードだけでなく、テストを直せる人が増えたという話がよかった。QAだけで抱えず、開発者も一緒に品質を支えられる仕組みを考えていきたい
- 第二弾も参加したい！
- 日時：2026年11月25日（水）19:00〜
- イベント：Merpay Tech Talk 〜AIで進化するQA自動化、その仕組みと実践〜