はじめに
connpassから申し込んだイベントで、西田泰明さん（株式会社TOKIUMの一人目QA）の「QAによるハーネスエンジニアリングとQA組織の未来像」という発表を聞きました。
私は現在、新卒でQAエンジニアを目指しています。
長期インターンでテスト設計に取り組んだ際、仕様書を読むだけでは判断できない部分がありました。その中で、テストケースとして手順や期待結果を残すだけでなく、「なぜこの観点で確認するのか」という判断の根拠も、チームでどう共有すればよいのかが気になっていました。
今回の発表は、その疑問ともつながる内容でした。人が持っている判断基準を、ほかの人やAIも使える形にするには何が必要なのか。単にテストを自動化するだけでなく、その前提となる知識の扱い方にも関心を持ちました。
この記事では、発表内容の中でも「QAを自動化する仕組みを、どう信用できる状態にするか」に絞って、考えたことをまとめます。
特に気になったのは、AIでテストケースを生成できたことよりも、その後の運用で起きた問題です。
テスト資産が増え、利用者も増えた一方で、ナレッジの重複や衝突が起き、仕組みを作り直す判断に至ったそうです。
これを聞いて、「AIに正しい指示を渡せばよい」という話では終わらないのだと思いました。指示を守らせることに加えて、その指示が今も正しく、今回の対象に適用してよいものなのかまで確かめる必要があります。
発表の概要：QAの判断基準を、仕組みに組み込む
発表では、ハーネスを「ナレッジ」「検証」「実行環境」の3つで説明していました。
①ナレッジ（判断基準）
QAが持つテスト観点や記述ルール、ドメイン知識を、AIが毎回同じように読める形にしたもの。
↓ AI（Claude Code）によるテスト設計・実行
②検証（Hook群）
ルールを「知っている」から「破れない」にする。
生成された成果物がルールに従っているかを機械的に検証し、違反があれば差し戻す。
③実行環境（土台）
そのナレッジと検証が毎回働く実行環境を用意する、という構成です。
印象に残ったのが、次の表現でした。
ルールを「知っている」から「破れない」にする。
「必ずこの観点を確認してください」と指示するだけでなく、条件を満たさなければ次の工程へ進めないようにする。AIの注意力に期待するのではなく、周囲の仕組みで制約する考え方だと理解しました。
また、すべての処理を毎回AIに任せる設計ではなかった点も興味深かったです。生成したテストケースと実行コードを資産として残し、次回はAIを使わずに再実行する方針が示されていました。
AIが必要な場面で使い、繰り返し確認する部分はコードに残す。「どこまでAIに任せられるか」だけでなく、「どこからはAIに毎回判断させないか」も設計するのだと感じました。
1. ナレッジは、増やせば安心というわけではなかった
発表では、5か月の運用で6,482件のテストケースを生成し、そのうち607件がPlaywrightのコードになったと紹介されていました。
一方、運用中にはテストの所要時間や、Issue・PRの滞留が問題になりました。棚卸しをすると、同じルールが複数の場所に散らばり、1つのルールを直すために11ファイルの修正が必要になった事例もあったそうです。古くなって意味を失ったルールが動き続ける問題も挙げられていました。[^2]
ここで気になったのは、個々の追加や修正は、必要があって行われたはずだということです。
ある不具合を防ぐために注意事項を追加する。利用者からの要望を受けて、例外的な手順を残す。その時点では改善でも、積み重なると「どのルールを、どの場面で使えばよいか」が分かりにくくなる。
そう考えると、ナレッジを追加する際には、内容だけでなく、その適用条件も一緒に残す必要がありそうです。
例えば「この操作では再認証が必要」とだけ書かれていても、それが全プロダクト共通なのか、特定の認証方式だけの話なのか、一時的な回避策なのかで意味が変わります。
発表でも、プロダクトAの前提をプロダクトBのテストに誤適用する問題が紹介され、再設計では知識に適用範囲と優先順を持たせる方針が示されていました。
私はここから、ナレッジの品質を「どれだけ詳しく書かれているか」だけで評価してはいけないと思いました。
正しい知識であっても、使う場所を間違えれば、誤ったテストの根拠になってしまうからです。
2. 「ルールに従っている」と「正しく判定している」は違う
ハーネスの説明を聞いて、もう一つ考えたことがあります。
それは、検証を通過したという事実が、何を確認できたことになるのか、という点です。
ここからは、発表の事例ではなく、考えるための仮の例です。
あるWebアプリで、招待リンクの有効期限が24時間から72時間に変更されたとします。ところが、AIが参照するナレッジには、古い「24時間で失効する」という仕様が残っていたとします。
AIがその情報から、
「発行から48時間後の招待リンクは利用できない」
という期待結果を作った場合、テストケースとして必要な項目はそろっていても、現行仕様に対しては間違っています。正しく利用できる実装を、不具合として報告するかもしれません。
さらに、仮に実装とテストの両方が同じ古い仕様を参照していたら、誤った動作に対してテストが通る可能性もあります。
この場合、「テストが通った」は、実装と期待結果が一致したことを示していても、最新の要求を満たしたことまでは示していません。
だから、AIが生成したテストを確認する際には、手順や期待結果の文章だけでなく、「その期待結果をどの仕様から導いたのか」までたどれるようにしたいです。
必要な項目が埋まっていること、決められた形式に従っていること、期待結果が現行の要求に合っていることは、それぞれ別の確認です。
「検証を通ったから大丈夫」と一括りにせず、その検証が何を確認し、何を確認していないのかを説明できる状態が必要だと思いました。
3. 「人に戻す」は、自動化の失敗なのか
発表資料の付録には、旧ツールから引き継ぐ方針として、判定できない場合は人に確認を求めることや、走査結果が0件の場合は失敗とすることが記載されていました。
私は、このような「先に進めない条件」にも、QAの判断が表れると思います。
例えば仕様が矛盾しているときに、AIがどちらかを選んで最後まで処理すれば、見かけ上は自動化が完了します。しかし、その選択に根拠がなければ、後から結果全体を確認し直すことになるかもしれません。
それなら、「ここは判断できない」と止まり、確認すべき点を明示する方が、信頼して使える場面もありそうです。
ただ、人に戻す回数が多ければよいわけでもありません。毎回ほとんどの判断を人に渡していたら、期待した負担軽減にはつながりません。
そこで、単に人へ戻した件数ではなく、戻し方も見たいです。
「仕様が不明です」だけでは、確認する側が調べ直さなければなりません。一方で、「この2つの資料で有効期限が異なり、どちらが現行か確認できない」と示されていれば、確認する箇所を絞れます。
自動化を評価するときには、最後まで処理できた割合だけでなく、止まるべき場面で止まれたか、止まった後に人が判断しやすいかも確かめたいと思いました。
4. まずは「誤った前提を混ぜる」実験をしてみたい
今回の発表を受けて、小さなテストケース生成の仕組みから試してみたいと考えています。
発表資料の付録では、新旧の仕組みを比較する条件として、事前に固定した必須観点・既知の不具合に対する検出率や、人の確認時間を含めた所要時間が挙げられていました。
この考え方を参考に、私ならまず、生成件数よりも「参照すべき情報を適切に選べるか」を確認したいです。
先ほどの招待リンクのような小さな機能を題材にして、正しい仕様と期待する振る舞いを先に決めます。その上で、渡すナレッジを変えて比較します。
以下は、これから試してみたい検証案です。
| 渡すナレッジの条件 | 確認したい振る舞い |
|---|---|
| 対象プロダクトの現行仕様だけを渡す | 現行仕様に沿った期待結果を作り、不必要に処理を止めない |
| 失効済みと明示した旧仕様を混ぜる | 旧仕様を期待結果の根拠にしない |
| 別プロダクトの仕様を混ぜる | 適用対象が違う情報を採用しない |
| 有効な仕様同士に矛盾があり、優先順位も不明な状態にする | 勝手に正解を決めず、矛盾している箇所を示して確認を求める |
特に、問題のある入力だけでなく、最初の正常な条件も入れたいです。何でも人に確認を求める仕組みなら、矛盾した仕様を渡したケースには対応できても、実際には使いにくいからです。
同じ条件で複数回試し、判断が変わらないかも見たいと思います。さらに、人が生成結果を確認・修正する時間まで記録すれば、「生成は速くなったが、確認に時間がかかる」という状態も比較できそうです。
もちろん、この小さな実験だけで仕組み全体の信頼性を示せるわけではありません。それでも、「それらしいテストケースが出た」で終わらず、どの条件では任せられ、どの条件ではまだ難しいのかを具体的に説明する第一歩になると考えています。
おわりに
今回の発表で印象に残ったのは、QAを自動化する仕組みを作った後、その仕組み自体を棚卸しして見直していたことです。
なお、発表資料の時点では、再設計の一部はまだ実装途中で、作り直したことによる効果も未実測とされていました。
「作り直したから改善した」ではなく、何を測ってその判断を確かめるかまで示されていた点も、参考になりました。
期待結果の根拠を確認することや、古い仕様を疑うことは、AIが登場して初めて必要になった話ではないと思います。ただ、AIにテストの生成や実行を任せる範囲が広がるほど、その判断を個人の注意だけに頼らず、仕組みに組み込む必要があるのだと理解しました。
QAを目指す立場として、自動化の実装を学ぶことと、テストの判断基準を学ぶことを、別々にはしたくありません。
「このテストは何を確かめているのか」
「期待結果の根拠は何か」
「判断できないときは、どこで止めるのか」
自分で書くテストでも、AIが生成したテストでも、この問いを説明できるようにしたいです。
まずは小さな機能で、正しい仕様だけを渡す場合と、古い情報や矛盾した情報を混ぜる場合を比較してみます。自動化できた範囲だけでなく、任せられなかった条件とその理由まで、次のアウトプットに残したいと思います。