AIテストの罠
「今期はテスト数を40%増やしました」という言葉を聞いて、誰もが頷いている。
東京のあるSaaS企業で、このような光景を目にしました。QAリードは誇らしげで、経営陣は満足し、パイプラインはすべて「グリーン（正常）」でした。
しかし6週間後、決済システムが72時間にわたって停止しました。誰もその異変に気づきませんでした。なぜなら、AIが「正しいデータ」を確認するのではなく、「エラーが出ないこと」だけを確認するテストを書いていたからです。
これが「テスティング・ブラインドネス（テスト盲目）」です。
これは、チームが大量のテストを生成しながら、そのテストが自分たちに「嘘」をついている時に、それに気づけなくなる現象を指します。AIは、テストのカバレッジ（網羅率）をテストの品質と履き違えやすくさせます。
最近のQiitaの記事でも、まさにこの苦悩が語られています。あるエンジニアが、自動化されていなかったプロジェクトにAIを導入しました。テストは迅速に生成され、メトリクス（指標）は素晴らしく見えました。
しかし、そのエンジニアは結局、PlaywrightやAPIテストを自力で学ばなければなりませんでした。なぜか？ AIは構文（シンタックス）を書くことはできても、システムがどのように動作するかを理解していなかったからです。
テスティング・ブラインドネスには、主に3つの症状があります。
• アサーションの萎縮 (Assertion Atrophy): コードがクラッシュしないことだけを確認し、正しく動作するかどうかを確認していないため、テストがパスしてしまう。 • 境界値ケースへの盲目 (Boundary Case Blindness): AIは「ハッピーパス（正常系）」に集中しがちです。null入力やレースコンディション（競合状態）といったエッジケースを見逃します。 • 回帰テストへの過信 (Regression Confidence Inflation): テスト数が倍増したことで安心感を得てしまいます。しかし実際には、根拠のない自信を倍増させているだけです。
私の経験では、AIを使うことで、チームは数ヶ月でテスト数を0から1,200まで増やします。レポートは完璧に見えますが、実際のバグ検出率は低下します。
日本では、管理（kanri）やプロセスを重視するあまり、こうした高い数字を「成功」と捉えてしまいがちです。一方、欧米ではAIによってテストが容易になったことで、テスト自体をスキップしてしまうチームも少なくありません。どちらの道も、最終的には本番環境での障害につながります。
AIはメトリクスを最適化しますが、デバッグ能力を損なわせます。
QAにAIを使用する場合は、以下のルールに従ってください。
- 週に一度テストを監査する: AIが作成したテストをランダムに5つ選び、「どうすればこのテストは誤ってパスしてしまうか？」と自問してください。すぐに答えられないなら、そこに盲点があります。
- 境界値のノルマを設定する: AIによるテストが10個できたら、手動で2個のエッジケース用テストを書いてください。
- 「午前3時のテスト」を行う: そのテストが、午前3時に発生した障害を検知できるかどうかを考えてください。確信が持てないなら、そのテストは不十分です。
- 1つのモジュールは手動のままにする: 重要なセクションを一つ、手動でテストし続けてください。これにより、デバッグスキルを研ぎ澄ませることができます。
テストの量と質を混同しないでください。効率性が判断力を奪うことを許してはいけません。あなたを救うのは、あなたが真に理解しているテストなのです。
あなたのチームでは、AIを導入してからテストの品質が低下したことはありますか？ ぜひコメント欄で経験を共有してください。
学習コミュニティ（任意）: https://t.me/GyaanSetuAi