こんにちは、QAチームの草場です。
Claude Codeに代表されるAIエージェントの登場で、ソフトウェアテストの現場も大きく変わりつつあります。私のチームでも、テスト分析からテスト実行まで、テストプロセスの各工程をAIエージェントに任せる取り組みを続けてきました。大量の情報収集が短時間でできる、テストケースの下書きを数分で出せる、DBの検証やAPIの疎通確認も自律的に進めてくれるなど、AIによる効率化の手応えは確かにあります。
ただ、現状はあくまで人間が間に入る必要があり、人間による理解・レビューが必ず発生します。
「このAIテスト、どこまで信頼していいのか?」
将来的にはAIに任せる範囲はもっと広げたいです。AIの判断や生成物を人間が見なくても信頼できる領域を、少しずつで良いので作っていきたい。 しかし、広げてよいかを判断する材料が体感しかありません。そこで、AIテストプロセスそのものに品質メトリクスを仕込んで、計測を始めてみました。
この記事は、前後編に分けてお届けします。前編では、AIテストプロセスの信頼度を測るために設計した品質メトリクスと、その測定・記録を運用する仕組みを紹介します。計測から実際に見えてきた課題は、後編で紹介します。
AIにテストを任せる上での悩み
私の担当するプロダクトでは、JSTQBのテストプロセスに沿って、次の5つの工程をそれぞれAIエージェントに任せています。
- テスト分析（何をテストするかの洗い出し）
- テスト設計（テストケースの設計）
- テスト実装（実行可能な手順への具体化、テストデータ・環境の準備）
- テスト実行（ブラウザ操作・API呼び出し・DB検証）
- テストレビュー（成果物の相互チェック）
人間のQAエンジニアの役割は、AIの成果物のレビュー、実機でしかできない操作、そして最終的な品質判断です。
この協調型プロセスの全体像は、JaSST'26 Tokyoで発表しました。今回の記事は、その発表で紹介したプロセスを「どう計測し、どう信頼につなげるか」という続きにあたります。
AI協調型のプロセスを運用して、体感としての効率化は確かにありました。ただ、次の問いには即答できる状態ではありませんでした。
- AIが設計したテストケースは、どのくらいそのまま使えるのか
- AIのテスト実行は、どこまで人手なしで完結するのか
- AIの成果物には、どの工程でどんな誤りが混入しやすいのか
答えられないと、「人間の関与をどこまで薄くしてよいか」も「次にどこへ投資すべきか」も勘で決めるしかありません。品質の判断を勘でするわけにはいかない以上、実質は決められないままです。 AIへの信頼を、体感ではなく計測された事実の上で判断したい。それがメトリクス設計を始めたきっかけでした。
信頼度を測るためのメトリクス設計
「信頼できるか」という漠然とした感覚を数字に落とすためにまず始めたのは、プロセス全体を1つの数字で評価せず、工程別に「どこで何が起きたか」を帰属させることでした。
始めに設計したメトリクスは次の5つです。
| メトリクス | 何を測るか | どの工程の品質か |
|---|---|---|
| テストケース採用率 | AIが設計したテストケースのうち、実際に実行する価値のあるケースとして採用した割合 | テスト設計 |
| 実行方法の見立て精度 | AIが見立てた「そのテストの実行方法」（どのテストレベルで検証するのが効果的か、実機や特別な準備が必要か）が、実際に実行した結果と一致した割合 | テスト設計 |
| 実装品質（記述通り率） | テスト手順が書かれた通りに実行できた割合 | テスト実装 |
| AI自律実行率 | テスト実行のアクションのうち、人手介入なしで完了した割合 | テスト実行 |
| 欠陥密度 | 変更行数あたりのテストで検出した不具合数 | プロセス全体の出力 |
この5つから始めた理由は、分析・設計・実装・実行の各工程に、それぞれ品質の物差しを置きたかったからです（実は分析工程には、直接の物差しをまだ置けていません。今後の課題です）。欠陥密度だけは毛色が違い、古典的な品質指標がAIのテストプロセスに対しても機能するのかを試す目的で、実験的に入れました。
これに加えて、テストレビュー工程が検出した誤りを「分析由来」「設計由来」「実装由来」に分類するログと、レビュー自体の精度（誤検知・見逃し）のログも持っています。
この計測には、3種類の登場人物が関わっています。分析・設計・実装・実行を分担する各作業エージェント。その成果物をレビューする専用のレビューエージェント。そして、レビュー結果ごと成果物を確認する人間のQAエンジニアです。
AIの成果物をAIがレビューし、そのレビューをさらに人間が確かめる。この多層の構えにしているのは、「現時点でエージェントだけで品質を保てているか」と「エージェントだけで品質を保てるようになるには、どこを改善すべきか」を切り分けて確認するためです。
メトリクスを設計するにあたって、数字を「使える情報」にするために工夫した点が2つあります。1つ目はテストケース採用率の記録の仕方について、2つ目は実装品質・実行方法の見立て精度という2つのメトリクスに持たせた役割についてです。
工夫した点1: 採用率を「理由」まで分解する
1つ目の工夫は、採用率を「何%だった」で終わらせないことです。採用されなかったテストケースには、必ず理由があります。その理由を次の分類で記録します。
| 分類 | 意味 | 何のシグナルか |
|---|---|---|
| A1 | 重複・統合可能 | AIの過剰生成 |
| A2 | テスト対象外 | AIの過剰生成 |
| A3 | 粒度過剰 | AIの過剰生成 |
| B1 | 時間切れ | プロセス・優先度付けの問題 |
| B2 | 環境制約 | テスト環境・データの問題 |
| B3 | 設計変更 | 仕様側の変化（不可避） |
| C1 | 真の設計漏れ | AIが設計時に気づけたはずの観点 |
| C2 | 実行時の探索的発見 | 実行して初めて分かる観点 |
ポイントは、A系とB系の区別です。A系はAIの設計品質の問題。B系は環境やプロセスの問題。同じ「削除」でも、打ち手がまったく違います。この分類が、後述する「課題」の発見に直接つながりました。AIテストに限らず使える分類だと思うので、そのまま持ち帰っていただけます。
工夫した点2: 読むだけでは分からないことを、実行結果で確かめる
レビューエージェントは成果物を読んで検査しますが、読むだけでは分からないことがあります。「この手順は書かれた通りに実行できるのか」「『実機が必要』という見立ては正しいのか」は、実行してみて初めて分かります。もっともらしく書かれた誤りは、AIのレビューをもっともらしいまま通過してしまうのです。
そこで2つ目の工夫として、テスト実行のたびに、成果物と実行結果の答え合わせをしています。手順が書かれた通りに実行できなかったなら、それは手順の誤りがレビューをすり抜けていたということ。実行方法の見立てが実際と違ったなら、それは読むだけでは確かめようのない、AIの見立ての課題が1件見つかったということです。
このズレを数えたものが、メトリクスの表にある実装品質（記述通り率）と実行方法の見立て精度です。レビューエージェントの検査を、実行という現実で補う2つ目の網として働きます。この答え合わせから見つかった課題は、後編で紹介します。
（コラム）測定・記録の運用でつまずいたこと
メトリクスを設計し終えて測定・記録を始めると、記録の運用で少しつまずくことがありました。 今回のブログのメインテーマからは少し外れますが、誰かの参考になるようにエピソードを残しておきます。
AI手書きの数字は壊れる
最初はスプレッドシートにAIで記録していました。すると、あるとき「設計48件・削除5件なのに採用48件」という、計算の合わない行が生まれました。数値の計算や記録をAIに任せると、この種のミスは結構起きます。記録の仕方を最初にきちんと決めていなかったため、初めのうちは不整合な記録が生まれてしまっていました。
そこで、記録の方法を変えました。
- AIが入力するのは計算を伴わない値だけ
- 採用率などの計算は、スクリプトや関数に任せる
- 「設計 = 削除 + 採用」「Pass + Fail + Skip = 実行数」など定義した式をスクリプトが検算
なお、この仕組みを入れた後にも、検算の対象外のところでは粗が出ました（スプレッドシートの列ズレ、記録し忘れなど）。メトリクスの記録自体も検証対象である。テストプロセスを疑って計測するなら、その計測記録も疑って監査する必要がある、というのが運用してみての教訓です。
後編へ続く: 計測から何が見えたか
ここまでで、信頼度を測る物差し（5つのメトリクス）と、数字が壊れないようにする記録の仕組みができました。
後編では、この計測から実際に見えてきた、今のAIテストプロセスの4つの課題を紹介します。
We are Hiring!
エムスリーでは、AIが自律的に品質を担える未来に向けて、QAプロセスそのものを作り直していく仲間を募集しています。カジュアル面談もやっていますので、お気軽にお声がけください！
