「QAはもう、『テスター屋』じゃない」 ―― chocoZAPの品質保証は、AIでこう変わった

会員110万人*が日々使うchocoZAPで、品質保証（QA）の現場が大きく変わりつつあります。テスト設計はAIが下書きし、要件定義のレビューもAIが先に走る。公開済みプロジェクトのソースコードを全てClaude（生成AI）に読み込ませ、1年以上誰も解けなかったバグを10数個の手順で割り出す――。AIが「手を動かす作業」を巻き取ってくれる分、私たちは「お客様にとって本当にいいサービスとは何か」という問いに、まっすぐ向き合えるようになりました。

chocoZAP QAユニット長の鈴木に、AIが品質保証の最前線にもたらした変化を聞きました。

 QAユニットと「品質」の3つの軸

―― はじめに、自己紹介をお願いします。

鈴木：プロダクト開発統括1部のQAユニットでユニット長をしている鈴木です。会員110万人*のchocoZAPアプリやウェブサイト、各種サービスのシステム開発における「品質保証」と「品質管理」を担当しています。

―― 「品質」と一口に言っても、いろいろな解釈がありそうです。鈴木さんの中では、どう定義していますか？

鈴木：そうですね。私たちは「品質」を大きく3つの軸で捉えています。
1つ目は、ビジネス要求を満たしていること。会社の経営方針や、ビジネスとして開発部に期待される成果に応えていて、かつ業界標準に沿っていることです。
2つ目は、継続的に改善できる状態で、開発工程そのものが最適化されていること。一見、正しそうに動いていても、その場限りのやり方で作られているものを、私たちは「品質が高い」とは評価しません。
3つ目は、法律・社内規定・コンプライアンス・ガバナンスを守っていることです。

この3つが揃って、ようやく「品質が高い」と言えます。その状態に近づけるために、QAユニットはQCD（品質・コスト・納期）のバランスを意識しながら、あらゆる活動をしています。これが、私たちの仕事の輪郭です。
 

「QAはAIに真っ先に置き換わる」と言われ続けてきました

―― 新卒のエンジニア志望者から「AIに仕事を奪われるんじゃないか」という不安をよく聞きます。特にQAは、AIに置き換わりやすい仕事だと思われがちですよね。

鈴木：はい、本当によく言われます。「テストなんてAIが全部やれるでしょ？」と。
正直に言うと、半分は本当で、半分は違います。AIに任せられる部分は、ここ1～2年で大きく増えました。同じ時間でこなせる案件数は、以前とは比較になりません。

ただ、それで私たちの仕事が「なくなった」かというと、むしろ逆です。「AIには絶対にできないこと」に時間を使えるようになって、QAという仕事の意味そのものが変わってきている。これが、いまQAをやっていていちばん面白い部分です。

QAは、長らく「テスター」「バグ出し屋」というイメージを持たれてきました。エンジニアが書いたコードを後ろから検証する役割、というポジションです。AIが入ってからの私たちは、もう少し違う場所に立ち始めています。「プロダクトが正しく動くか」を確認する仕事の重心が、「プロダクトが本当にお客様の役に立つか」を見極める仕事へ移ってきているんです。AIが前者を引き受けてくれるから、後者に体重を載せられるようになりました。
 

1年間誰も再現できなかったバグを、AIが10数手順で解いた話

―― 具体的にどんな変化が起きているのか、エピソードで教えてください。

鈴木：けっこう劇的な話があります。

chocoZAPには、長らく原因の分からないバグがありました。仕様としては、年額プランへの変更はキャンペーン期間中にしかできないはずなのに、キャンペーン期間外なのに年額プランに変えられてしまうお客様が、月に1人くらい現れる。

―― 発生頻度が低く、再現性のないバグですね。

鈴木：そうなんです。何度調査しても再現できない。件数も限られているので、申し訳ないのですが、ずっと後回しになっていました。

最近、私たちはClaudeに「公開済みプロジェクトのソースコードを全部読み込ませる」という取り組みを始めました。入会導線、マイページ、決済まわり……と、ひとつずつClaudeに食わせていって、Claudeが内部仕様を「ほぼ覚えた」状態を作っていきました。

そんなときに、また同じバグの問い合わせがありました。「そういえば」と思ってClaudeに聞いてみました。「こういう問い合わせがたまにあるのですが、原因は何ですか？」と。

そうしたら、10数個の手順を返してきました。「以下の順番でこの操作をすれば、再現できます」と。さらに「ソースコードのこの箇所がおかしい」と、問題箇所まで列挙してきた。

その手順どおりに操作したら、1年以上誰も再現できなかったバグが、目の前で再現できました。

―― 1年越しの謎が、AIで解けたわけですね。

鈴木：はい。これ、iOSとAndroidのアプリでも同じことをやっています。実機テストで何度も再現できなかった事象を、AIがソースコードレベルで「ここですよ」と教えてくれます。いまでは毎週のように、こうしたバグが見つかってNG票として上がってきます。
 

テスト項目書を「50時間」から「30時間」へ。AIと人間が往復するサイクル

―― バグ発見以外でも、AIで変わった業務はありますか？

鈴木：QAの中核業務である「テスト項目書」の作成プロセスが、大きく変わりました。

以前、たとえば予約システムのテスト項目書を人間だけで作ると、作成に40時間、レビューと修正に10時間で、合計50時間ほどかかっていました。これがいま、4割減って30時間ほどで完成します。

―― どう作っているんですか？

鈴木：AIと人間が「6つのフェーズ」を行き来する形で進めています。具体的には、このような流れです。

　・フェーズ1：Claudeがテスト項目書の初稿を出力する／人間は次のレビュー観点を整理する
　・フェーズ2：人間がレビューと修正を入れ、Claudeに戻す／Claudeが追加項目を出力する
　・フェーズ3～5：要件のカバー範囲、エッジケース、ユーザー体験の観点を順にAIに通し、項目を厚くしていく
　・フェーズ6：人間が最終的なテスト項目書として整える

最初の出力は6～7割の出来ですが、それで構いません。Claudeが出力している間、人間はずっと次の判断の準備をしているので、AIが動くたびに人間の仕事も前に進んでいきます。「AIに任せて待つ」のではなく、AIと人間が常に並走している感覚です。だから工数が4割減っても、品質はむしろ上がっています。

―― なるほど、よく分かりました。要件定義書のレビューにも同じ仕組みを使っているんですか？

鈴木：はい。要件定義書の矛盾や抜け漏れを指摘する作業も、Claudeが最初に走るようになりました。以前は担当者の経験や記憶に左右されていましたが、いまはAIが均一な精度で指摘を出し切ったあとに、人間が検証する順番に変わりました。これも、品質の底上げに効いています。

―― ドキュメントやナレッジは、AIに渡しているんですか？

鈴木：はい、サービスのドキュメントは全てClaudeに食わせてあって、「万能ナレッジ」になっています。新しいメンバーが入ってきても、「あの資料、どこだっけ？」という会話自体がチームから消えました。Claudeに聞けばテスト対象も観点もすぐに返ってくるので、人間はその先の判断だけに集中できます。

それから、システムの内部構造まで見るホワイトボックステストにも踏み込めるようになりました。これまでQAはコードレベルの分析にはあまり踏み込めず、エンジニアのテストコードに任せる文化でした。いまはQA側から開発のソースコードを読みにいきます。Claudeが分岐の1つひとつまで全部チェックしてくれるので、私たちは「ここ怪しいよね」という判断に集中できます。

簡単な変更案件、たとえばテキストや画像の差し替え程度であれば、BacklogのチケットキーをClaudeに渡すだけで、QAそのものが自動で完結することも増えました。
 

開発部門が、直接お客様の声を受ける

―― QAの仕事を聞いていて、もう1つ気になりました。鈴木さんたちは、お客様の問い合わせをどう扱っているんですか？

鈴木：実は、私たちは開発部門が直接、お客様からの問い合わせを見にいきます。

―― 直接、ですか。普通はコールセンターやCS（カスタマーサポート）が一度受けて、報告会で開発に共有する、というケースが多いと思います。

鈴木：そうですね。多くの会社では、コールセンターやCSが問い合わせを受けて、週1とか月1の報告会で「こういう問い合わせがありました」と共有する。これが一般的な流れです。

でも、それだとお客様の困りごとと「アプリのバグ」が直感的に結びつきません。お客様は当然、「アプリのここにバグがあります」とは言いません。困りごとの言葉を聞いている限り、それがシステム由来なのかどうか、すぐには判断がつかないですよね。

私たちは、開発が直接見るから、瞬時に分かります。「あ、これあそこのバグだ」「これはアプリ側じゃない」と。問い合わせから不具合検知、修正、アップデートまでが、ほぼリアルタイムで回っていきます。

―― それは大きな違いですね。

鈴木：はい。お客様の声を真剣に受けて、すぐ直す。このサイクルが回っていると、品質に対する責任意識がチーム全体で大きく変わります。「不具合を起こしちゃいけない」という意識が、外から押しつけられるものではなく、内側から立ち上がってくる。

一時期、アプリストアのレビュー点数が低かった時期がありましたが、最近は回復傾向にあります。これは、いま話したサイクルが効いてきている結果だと思います。
 

AIには出せない、「お客様は本当に喜ぶ？」という問い

―― AIをそこまで使いこなしていると、「AIには絶対にできないこと」というのが逆に気になります。

鈴木：はい、ここが、QAの仕事のいちばん面白いところに繋がります。

AIは、ソースコードが設計通りかどうか、プロダクトが要件を満たしているかどうかは、ほぼ完璧にチェックできます。でも、「その要件って、お客様が本当に喜ぶんだっけ？」という問いには、AIは答えを出せません。

―― と言いますと？

鈴木：たとえば、ボタンの色ひとつでも、こういうことが起きます。あるボタンを緑色で実装したところ、コンバージョン（成果率）が上がって、デザインガイドラインにも沿っていて、AIは「問題なし」と判定する。でも、chocoZAP全体のブランドの世界観で見ると、「この緑、なんだか浮いていないか？」という違和感を覚えることがあります。

要件としては「正しい」けれど、サービスの体験としては「正しくない」――こういう違和感は、いまも人間にしか拾えません。

―― 「正しい」と「お客様が喜ぶ」のあいだに、隙間があるわけですね。

鈴木：そうなんです。AIが仕事を片づけてくれた後に、「これは本当にお客様にとっていいことなのか」と問い直す。それが、私たちQAの仕事の本質に近い部分です。

もう1つ、AIの出力に「抜け漏れがないことを証明する」のも、まだ難しい領域です。自分でゼロから書いたものを仲間と確認し合うより、AIが出してきたものを「これで全部だね」と保証するほうが、本当はずっと難しい。QAは精度要求がゼロ許容で、「傾向が合っていればOK」が絶対に通用しない世界です。だから、上流工程のAIのミスを最後に検知する責任は、いまもこれからも、人間が担う必要があると思います。

 課題を言語化できる人と、働きたい

―― 最後に、これから新卒で入ってくる方へメッセージをお願いします。

鈴木：「AIに仕事を奪われる」という不安は、たしかにあると思います。でも、私は少し違う見方をしています。

奪われるかどうかは、業種や職種の話ではなく、個人の話だと思います。AIを使いこなせる人と、そうでない人の差が、これからどんどん開いていく。これは、もう避けられない流れだと感じます。

―― その差を分けるのは、何だと思いますか？

鈴木：課題を「言葉にする力」だと思います。

いまの状態（As-Is）と、あるべき状態（To-Be）。この2つの乖離を自分の頭で認識して、AIに伝わる粒度で表現して、AIが出してきたものの良し悪しを判断する。この3つができる人が、これからのエンジニアの主役になります。

正直に言うと、私たちもまだ全員が手探りで学んでいる途中です。AIで働き方が完全に変わったので、毎日のように新しい使い方が生まれます。これはデメリットというより、チームが更新され続けている証拠だと思っています。学び続けることを楽しめる人と、ぜひ一緒に働きたいです。

AIが「手を動かす作業」をどんどん巻き取ってくれる時代だからこそ、人間に残るのは「判断の責任」です。バグ出し屋から、プロダクトの品質そのものに責任を持つ存在へ――QAという仕事の意味自体が、AI時代に書き換わったと感じています。

その責任を持って、110万人*のお客様に「これは本当にいいサービスだ」と思ってもらえる仕事を、一緒に作っていきたいですね。

*2026年5月時点