AIテスト実行の質、どう見極めますか

「やっていること」と「やるべきこと」のギャップ

AIテスト実行ツールを導入した。
ダッシュボードにはグリーンのチェックが並び、カバレッジは90%を超えている。

それでも、本番のバグは減っていない。
リリースのたびに、最後は人間のテストエンジニアが手を動かしている。

この違和感、心当たりはありませんか？

質問：AIテスト実行の質は、誰がどう判断すべきか？

AIテスト実行を導入した企業が抱える本当の課題は、「効果が出ているかどうか分からない」ことではありません。

「何を見落としているかが分からない」 — これが本質です。

AIテストは「実行したこと」を詳細に報告してくれます。しかし「実行すべきだったこと」は教えてくれません。

結論：AIテストの質は、V&V観点で「見極める」必要がある

AIテスト実行の質は、次の二つを区別して評価しなければ見えてきません。

• Verification（仕様基準）：仕様通りに作ったか
• Validation（価値基準）：正しいものを作ったか

AIテストはVerificationに強い。しかしValidationには構造的に手が届きません。なぜなら、Validationにはドメイン知識・利用文脈・リスクといったコンテキストが必要で、これらはAIには渡されていないからです。

理由：AIテストが見落とす3つの盲点

盲点1：仕様書に書かれない運用ルール

「クレームが起きた顧客には、自動リマインドメールを送らない」
「特定の取引先は、金額上限ロジックが他社と違う」
「月末金曜の17時以降に走るバッチは、翌営業日まで遅延させる」

こうしたルールは仕様書に書かれていません。過去のインシデント対応や、現場の運用チームの経験則として暗黙に共有されているだけです。AIに渡されていないルールは、テストにも現れません。

盲点2：仕様化されない異常系

空入力、境界値、同時アクセス、タイムアウト、認証切れ。これらが抜けるのは、AIの能力の問題ではありません。仕様書にはハッピーパスしか書かれていない——これが根本原因です。

異常系の多くは「起きないはず」として仕様化されず、現場の経験則の中に残っています。AIに渡すインプットに含まれていない以上、AIがそれをテストすることはできません。カバレッジ100%でも、リスクの網羅率は別の話です。

盲点3：自己検証のループ

近年は、AIで生成したコードに対してAIでテストを書かせるチームも増えています。この組み合わせでは、コードとテストが同じ前提・同じ盲点を共有するため、テストは「コードがしていること」を追認するだけになります。カバレッジが高くても、仕様との乖離は検出されません。

詳細：熟練QAエンジニアは、何を見ているのか

熟練のQAエンジニアがテスト設計を眺めるとき、彼らは二つの問いを同時に持っています。

• 仕様書に書かれたことを、漏れなくカバーできているか（網羅性の確認）
• 仕様書には書かれていないが、本当は必要なテストはないか（抜けの発見）

前者はAIでも確認できます。しかし後者には、仕様書の外にある情報を呼び起こす判断が必要です。

• 過去の不具合履歴（同じ箇所で、どんな障害が起きたか）
• 業務運用の文脈（このサービスは誰が、どう使うのか）
• ビジネス影響の濃淡（どこで障害が出ると、事業に響くか）
• 類似製品での事故事例

これらは仕様書には書かれていないコンテキストです。

AIテスト実行の質を見極めるときも、同じ二つの問いをAIテストにそのまま当てます。仕様を網羅できているか。そして、仕様には書かれていないが必要なテストが抜けていないか。この両方を点検して初めて、AIテストがカバーできている範囲と、カバーできていない範囲が整理できます。

まとめ：見極めの第一歩は、評価のフレームワークを持つこと

AIテスト実行は、品質保証の一部を確かに効率化しました。しかし、その質の良し悪しを自動で判断する仕組みは、AIテスト自体には組み込まれていません。

評価するのは、やはり人間です。そして人間が感覚ではなく構造的に評価するには、次の2軸×3観点のフレームワークが有効です。

この6セルで、導入済みのAIテスト実行の質を棚卸しする——それが、「やっていること」から「やるべきこと」へ視点を引き上げる第一歩です。