AIにテストを任せるなら実行と判定を分ける

AIエージェントにテストを書かせて回させると、判定がいちばん信用できない。 コードは書ける。実行もできる。だが、失敗の原因がテストにあるのかアプリにあるのかを、自分では切り分けない。

そこで、テストを実行する役と判定する役を分ける。

起きること

実行役に判定まで任せると、次の4つが繰り返し起きる。

起きること	例	見抜き方
テスト側の不備をfailにする	画面が操作可能になる前に入力し、値が入らない	同じ条件をAPIやDBで直接確かめる
前提不足のエラーをpassにする	期間を締めていないためのエラーを「期待どおりの拒否」と読む	拒否の理由が項目の意図と一致するかを見る
1か所の失敗を全体に広げる	準備が1つ失敗し、後ろの項目をまとめて未実施にする	項目ごとに独立して判定させる
期待値をアプリに合わせる	集計の誤りに期待値を合わせて作り替え、passにする	期待値をアプリを見る前に決めさせる

4つ目がいちばん危ない。テストは緑になり、不具合は消えたように見える。

手順

1. 項目と期待値を先に固定する。 期待値は、仕様・業務の原則・公的な基準から決める。アプリの出力を見て決めない
2. 実行役には範囲を絞って渡す。 項目の表、見てよいファイル、書き方の手本になる既存のテスト。仕様書を丸ごと読ませない
3. 判定を4値にする。 pass / fail / blocked / not-run。未実施をpassに読み替えない。blockedは「環境上どうしても試せない」場合だけにする
4. 判定役が1件ずつ疑う。 failは、アプリ側のファイルと行、APIやDBでの再現を根拠に求める。passは、項目の期待を全部確かめたかを見る
5. 差し戻しの理由を次の指示に足す。 「入力の前に待つ」「前提不足を拒否と読まない」「期待値を書き換えない」。同じ種類の誤りが減る
6. 2回続けて同じ結果になるかを見る。 テストデータの作り方が冪等でないと、2回目で結果が変わる

思考量を下げない

トークンを節約しようとして実行役の思考量を下げると、画面の値を読まずに固定値と比べるだけのテストが出てくる。書き直す手間がかかり、全体では高くつく。

削るなら、渡す情報を削る。仕様書全文ではなく、項目の表と参照ファイルに絞る方が効く。

判定役に残すもの

実行役に任せてよいのは、テストコードの作成と実行と、項目ごとの一次判定まで。 次の3つは判定役が持つ。

• 期待値の決定
• 失敗の原因の切り分け(テスト側か、アプリ側か)
• 最終判定

実際にClaude CodeとCodexで188項目を回した経緯は 二刀流の流浪人、188番勝負の武者修行に出る に書いた。 エージェントへの指示で道具を封じてしまう話は 制約がツールを封じる を参照。