20
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AIを「ツール」でなく「後輩」に見立てたらQAと相性が良かった

Last updated at Posted at 2025-12-04

この記事はHubble Advent Calendar 2025の5日目の記事です。

はじめに

HubbleでQAをしている @miney です!
最近は業務効率化のためにAIに頼ることが多かったのですが、その中で思った
AIをただの「ツール」ではなく、頼りがいのある“後輩メンバー”として扱った方が、QAの仕事とは相性がいいかも?
という気づきを共有できたらと思います!

この記事は以下のような方々の一助となればと思ってます。

  • AI活用にモヤモヤしているQAエンジニア
  • AIともう少し仲良くなりたい人

QAのAI活用って開発に比べて難しいと感じませんか?

本題に入る前ですが、まず個人的に感じるのがQAは開発に比べてAI活用が遅れてる・ハードルが少し高い ということです。

開発エンジニアの業務では、Cursorなどの登場により [実装] や [修正] の効率化が劇的に進んでいると思います。
(もちろん苦悩もあると思います)
一方で、私たちQAの仕事は 「仕様に書ききれない曖昧な部分を紐解く」「ユーザーや他機能に与える影響などを考慮する」 といった、抽象度の高いタスクが中心なので活用が難しいのかなと思ってます。

AIとの向き合い方を変えてみた

開発が「コードへの変換」なら、QAでのAI活用は 「相談と立案」 だと思ってます。
なので、AIは「魔法のツール」というより

「頼れる後輩 + セカンドオピニオンをくれる相棒」

というポジションで考えればAIともうちょっと仲良くなれると感じています!

実際にやってみて良かったなと思った活用例を3つ紹介します!

1. AIに疑問点がないか聞いてみる

誰かにタスクを頼むときのように、説明した後で 「今の段階で分からないことありますか?」 と聞いてみるイメージ!

AIに疑問点を聞かない場合

仕様書を貼って、「この仕様のテストケース作って」と依頼。
→AIが気を利かせすぎて 「仕様の曖昧な部分」を勝手に想像で埋めてしまう
結果、「それっぽいけど、なんか違う」ケースが混ざり、確認の手間が増えた。

AIに疑問点を聞いた場合

仕様書を貼って、 「テスト作成する前に、事前確認しておきたいこと、今の段階で仕様に不明な点などはありますか?」 と聞いてみた。
スクリーンショット 2025-12-02 17.33.13.png
→今すぐテスト作ってくれそうな勢いだったのに質問が22個出てきたw

実際に出てきた質問

1. 既存データの移行ポリシー(制御まわり)

削除不可の範囲
 「削除不可」はUI非表示のみか、API/バックエンドもブロックか。
(仮説:両方でブロック)

確かに仕様では「削除不可」となっていても、削除できないUIなのかエラーを出すのか変わる。

2. フォルダ移動のブロック要件(ロジック系)

親フォルダを移動する際、その配下にあるアイテムのどこか1つでも「移動権限」を持っていなければ、フォルダ全体の移動はブロックされますか? そのチェックは再帰的に行いますか?
(仮説:再帰チェックを行い、1つでもNGなら移動不可とする)

フォルダ構成のHubbleにとって、子フォルダの状態によって親フォルダに影響を与えることもあるのでありがたい質問。

3. 文字数カウントの定義(QAあるある系)

「25文字以内」のカウント基準について確認です。サロゲートペアや結合文字、絵文字は1文字扱いですか?
仮説:ユーザー体感に合わせて1字=1カウントとする)

byte数なのか文字数なのかで変わるので、認識合わせを強固にしておく意味で助かりました。

2. 思ってた回答と違っても、すぐ直させず「根拠」を聞く

想定と違っても頑張ってアウトプットしてくれたものに対して根拠や背景を聞いてみるパターン!

AIでテスト設計をしているため、根拠を聞くのは特にアウトプットの質が変わると思います。

すぐ直させる場合

AIが出してきたテストケースを見て「このケース不要だから消して」とだけ指示するパターン。

→その場は修正してくれるが、次も想定してない回答が出る可能性がある。

まず「根拠」を聞く

「このテストケースを出した理由を教えて。どんなリスクを想定した?」と聞いてみる。

→「この一文から、こういうバグを防ごうとしました」と説明してくれるのでズレの原因が分かります。

新人メンバーへ教えるのと同じで、前提情報を完全に教えるのが難しいAIに対して 「ウチのプロダクトでは、ここは気にしなくていいよ」 と伝えてあげると、こちらの気持ちが分かってもらえたり精度も変わってきました。

3. 異なるLLMに「セカンドオピニオン」をもらう

「どっちが賢いか」ではなく、タイプの違う2人の後輩に同じテーマをレビューしてもらうイメージで使っています!

個人的にはGPTとGeminiにこんなイメージを持っています。
(過去の会話履歴が影響してる可能性もあるので主観です)

AI 特徴
ChatGPT 几帳面。ルール・フォーマット・網羅性を意識してくれる。
Gemini 文脈や目的を深掘って考えてくれる。

実験

「優秀なQAエンジニアとして〇〇を表形式にするプロンプトを作って」と依頼する

  • ChatGPT :表形式を崩さない様なルールを丁寧に書く
  • Gemini :優秀なQAエンジニアとはどんな視点を持ってるか仮定の部分を丁寧に書く

※ちなみに、今回はどちらも「高速モード」ではなく、じっくり考える 「思考モード」 (GPT:5.1ThinkingとGemini:3Pro)で試しました。

おわりに

  • いきなり丸投げせず、こちらの意図が伝わってるか疑問を出してもらう
  • 直させる前に、理由や背景を聞いて認識を合わせる
  • キャラの違いを活かして、セカンドオピニオンをもらう

AIはめちゃくちゃ頭も良くて、嫌とも言わずなんでもタスクをこなしてくれますが、前提情報を持ってない超優秀な新入社員の様だなと思ってます。

なのでいきなり全部任せるのではなく、「自分だったら、先輩にこうタスクを振ってもらえたら仕事しやすいな」というイメージで、AIへの依頼の仕方を考えてみると、活用が進んだなという共有です。

皆様のAI活用に少しでも役立てられたら幸いです。

明日はSREの@ktech9さんです!

20
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
20
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?