AI時代のQAは「テストする人」から「品質の基準を設計する人」へ

AIに任せる作業と、人が判断すること

コードやテストケースの下書きにAIを使うと、作業時間を短縮できる場合があります。ただし、確認や修正にかかる時間も含めて見る必要があります。ここでは、AIで補助できる作業と、人が責任を持つ判断を分けてみます。

ボトルネックは「判断基準」に移る

表の右の列を判断するには、プロダクトの目的や利用者、許容できるリスクを知る必要があります。私は、AIで下書きを作る機会が増えるほど、QAが判断基準を設計し、それが守られているかを確かめる役割も大きくなると考えています。

生成AIを機能に組み込む場合、同じ入力でも出力が変わることがあります。自由な文章を返す機能では、期待する文との完全一致だけで品質を評価するのは難しいため、次のような観点を決めます。

• 評価観点：正確さ、指示への従い方、禁止事項を守っているか、文体、日本語として自然か
• 判定の基準：合格・要確認・不合格の境界を、具体例つきで決める
• サンプルの選び方：通常の入力だけでなく、境界的な入力や誤用されやすい入力を含める
• 継続的な確認：モデルやプロンプトを変えたときに、同じ評価セットで回帰確認する

テスト設計の考え方はAIの評価にも使える

入力を分類して代表例を選ぶ考え方や、リスクに応じて優先順位をつける方法は、AIの評価でも使えます。説明用の架空の例として、問い合わせ回答機能なら「情報がそろった質問」「情報が足りない質問」「回答してはいけない内容」を分けて評価します。入力文字数に上限がある機能なら、その前後も確認します。

評価セットと判定基準に加え、モデル、プロンプト、利用データなどの条件を残すと、変更前後を比べやすくなります。出力にばらつきがある場合は、一度の成功だけで判断せず、同じ入力を複数回試すことも必要です。

QA体制は、人とAIの担当を先に決める

体制を作るときは、ツールを選ぶ前に「誰が何を判断するか」を決めます。AIを使う場合は、AIに任せる作業と、人が責任を持つ判断を分けて書いておきます。

QA体制を立ち上げる順番

「AIが作ったものを誰がどこまで確認したか」を記録に残すと、後から問題が見つかったときに、どの工程を直せばよいかがわかります。いきなり全体に広げるより、1つの機能で回る形を作ってから横展開する方が、現場の負担が少なく済みます。

• 品質の目標を決める：利用者に対して、何が起きたら困るのかを書き出す
• リスクの優先順位をつける：影響の大きさと起きやすさで並べる
• 役割と判断の範囲を決める：人とAIの担当を分ける
• 記録の置き場所と書き方をそろえる：テストケース、結果、不具合、判断理由
• 小さく始めて振り返る：1つの機能で回してみて、手順と基準を直す

要件定義から品質を上げる：テストできる形で書く

要件の書き方があいまいだと、実装と期待する動きがずれる原因になります。「いい感じに表示する」「エラー時は適切に案内する」では、開発者もテスト担当も、そしてAIも、別の解釈で進める可能性があります。要件をレビューするときは、次の点を確認します。

• 入力の範囲（上限・下限・空欄・形式）が決まっているか
• 正常時だけでなく、失敗時の動きが書かれているか
• 「適切に」「なるべく」など、判断できない言葉が残っていないか
• 受け入れ条件が「〜のとき、〜になる」の形で書かれているか
• 既存機能への影響範囲が挙げられているか
• 確認が難しい条件（時間、外部サービス、権限）の扱いが決まっているか

受け入れ条件の書き換え例

以下は説明用に作った架空の検索機能の例です。あいまいな受け入れ条件を、操作と結果がわかる形に書き換えてみます。この形なら、テストケースの期待結果を作る根拠になります。AIに下書きを頼む場合も、要件と候補を照らし合わせやすくなります。

【書き換える前】
検索結果が多すぎる場合は、適切にページを分けて表示する。

【書き換えた後】
- 検索結果が21件以上のとき、1ページに20件ずつ表示する
- 21件目以降は「次へ」から表示できる
- 検索結果が0件のとき、「該当する結果がありません」と表示する

AIを要件レビューに使うときの注意

AIに「この要件のあいまいな点を挙げて」と頼むと、レビューの候補を集められます。見落としや誤った指摘もあり得るため、人も確認します。指摘をどう解消するかはプロダクトの方針次第です。

AIの指摘は「質問リスト」として扱い、答えはプロダクトオーナーや関係者と決めます。AIが出した解釈をそのまま仕様として採用しないようにします。

AIレディとAIネイティブを分けて考える

社内の工程にAIを取り入れる構想を、この記事では次の2つの段階に分けて考えます。用語の使い方は組織によって異なるため、話し合う際は、どの状態を目指すのかも確認しておきます。

工程を4つの観点で棚卸しする

「ベテランに聞けばわかる」ルールが残っていると、AIにも新しく入った人にも必要な前提が伝わりません。AIが参加する工程を考える前に、まず次の4点が共有できているか確認します。

• 入力：その作業に必要な情報は、どこに書かれているか
• ルール：守るべき基準や禁止事項は文章になっているか
• 出力：成果物の形式と、合格の条件は決まっているか
• 確認：誰が、何を見て、OKと判断しているか

整っている工程から順にAIを入れる

入力・ルール・出力・確認がそろった工程なら、AIに何を渡し、何を評価するかを決めやすくなります。まず一つの工程で試し、修正時間も含めた作業時間や、見逃した誤りを振り返ってから、広げるかどうかを判断します。

たとえば開発で使うAIエージェントには、プロジェクトのルールを書いた設定ファイル（Claude CodeのCLAUDE.mdなど）を読ませる仕組みがあります。人に向けた手順書を、AIにも読める形で置いておくという考え方です。

AI活用の構想を話し合うときの問い

社内でAI活用の構想を議論するときは、ツールの比較から始めるより、次の問いから始めると話がまとまりやすくなります。

• AIに任せたい作業で、今いちばん時間がかかっているのはどこか
• その作業の「正しい結果」を、言葉で説明できるか
• AIが間違えたとき、誰がどうやって気づけるか
• 気づけなかった場合、利用者や業務への影響はどれくらいか
• 最初に試すなら、失敗しても影響が小さい工程はどこか

間違いに気づける仕組みがあるかで判断する

前の問いのうち、3つ目と4つ目がQAの視点です。AIの導入は「速くなるか」だけでなく、「間違いに気づける仕組みがあるか」で判断したいところです。

テストの実行に加えて、何を確認するか、誰が判断するかまで考える。そこにもQAの知見を活かせると思います。まず一つの工程で判断基準を言葉にし、関係者と認識がそろうか確かめてみてください。

ご相談をお受けしているテーマ

このブログを書いているかさね抄は、QAエンジニアとして働いています。第三者検証を中心に、7社の複数のプロダクトでテストに関わってきました。リーダー代行やQAチームの運営支援も担当しています。資格はJSTQB Foundation Levelです。

得意なのは、テスト設計、不具合分析、回帰テスト、ローカライズQAです。AIを活用したQAや、AIの出力の評価（日本語の品質評価を含む）にも取り組んでいます。この経験をもとに、次のようなテーマのご相談をお受けしています。

• AI時代のQAのあり方に関する設計、議論
• QA体制の構築支援
• 要件定義から開発工程までの品質向上に関するコンサルティング
• 社内のあらゆる工程をAIレディ、AIネイティブにするための構想策定、ディスカッション

お問い合わせの方法

「まずは話を聞いてみたい」という段階でも大丈夫です。ページ上部のメニューにある「お問い合わせ」からご連絡ください。