AIモデルによるテスト設計レビュー：Claude Fable 5とOpus 4.8では検出できる欠陥クラスに明確な差
本記事は、QAエンジニアが自身の開発パイプラインにおける「レビュー役」のAIモデル選定に関するA/B実験の結果を報告している。目的は、同じテスト設計成果物に対し、異なる強度のClaudeモデル（Fable 5とOpus 4.8）を独立して適用し、どのクラスの欠陥を見逃すかという差異を検証することである。
実験では、「テスト設計書＋テストケース一覧(JSON)」の凍結済み成果物を題材とし、3つの公開素材（ASTER自販機、だんだん動物園、割り勘アプリ）を用いて実施された。形式的な不備（値の型不統一など）は両モデルとも検出可能であったが、決定的な差が出たのは「形式は存在するが中身が伴っていない」クラスの欠陥である。
具体例として、「だんだん動物園」のケースでは、テストケースが実在しない出典（「データ連携仕様書p.28の1秒要件」）を根拠としているにもかかわらず、Opus 4.8はこれを検出できなかった。一方、Fable 5はこれを指摘した。また、「割り勘アプリ」の境界値テストでは、計算上端数が発生しない入力が使われているという構造的な欠陥も、Fable 5の方が高い精度で検出した。
集計の結果、3題材における「重大指摘＋期待値対立」の件数において、Opus 4.8は全3走で「条件付き承認」を出しており、レビューゲートとして機能させるには不十分なケースが散見された。筆者は、モデルの強度はコストの問題ではなく、「どのクラスの欠陥を素通りさせるか」という選択基準になるという結論を得た。
さらに、生成側（テスト設計）をFable 5で強化した場合も改善は見られるものの、本質的な「目的とデータの整合性」といった非対称な緊張は残るため、「生成強化」と「レビュー強化」の併用が不可欠であるとしている。
背景
近年、大規模言語モデル（LLM）をQAエンジニアリングやテスト設計プロセスに組み込む試みが進んでいる。しかし、AI生成物には「形式は整っているが中身が伴わない」という静かな欠陥（Silent Failure）が生じやすいことが課題となっている。本記事の実験は、単なる性能比較ではなく、モデルが持つ認知バイアスへの耐性差を検証した点で重要である。
重要用語解説
- QAエンジニア: Quality Assurance Engineerの略称。ソフトウェアやシステムの品質を保証するためのテスト計画立案や実行を行う専門職。仕様書と実際の動作に乖離がないかを確認する役割を持つ。
- プロンプト: AIモデルに対して、期待する出力形式やタスク内容を指示する入力文（命令）。LLMの性能を引き出す鍵となるため、単なる質問ではなく詳細な制約を与えることが重要とされる。
- 境界テスト: ソフトウェア開発におけるテスト技法の一つ。システムの処理限界点（例：最小値、最大値、ゼロなど）を入力として与え、期待される挙動を検証する手法。端数や例外処理の検証に特に用いられる。
今後の影響
本結果は、AIによる自動レビューシステムの実装において、「モデルの絶対的な性能」よりも「どの種類の欠陥（出典の真偽、目的とデータの整合性など）を見逃すか」という検出クラスの差異が重要であることを示唆している。今後の開発では、単一の強力なモデルに依存するのではなく、複数の異なる視点を持つAIエージェントによる多層的なレビューゲート設計が必要となる。