なぜ「AIテスト」は役に立たないカテゴリなのか
カテゴリ名は通常、問題を指すものです。ところがこの言葉が指しているのは技術です。だからこそ、症状も、買い手も、失敗の仕方も異なる3つの問題を、ひとまとめに覆ってしまいます。何かを比較する前に、自分が抱えているのはどれなのかを口に出して確認しておく価値があります。
タイプ1：テストを書いてくれるAI
解決する問題： テストのないコードがあり、手で書いていくのは遅くて退屈だ、という状況です。
実際の姿： 関数やファイル、あるいは仕様を指定すると、そのままコミットできるテストコードが生成されます。
限界： 生成されたテストは、生成元となったコードが置いている前提をそのまま引き継ぎます。実装があるエンドポイントの戻り値を誤解していれば、生成されたテストも同じ誤解をアサーションに書き、そのまま通ってしまいます。これがこのカテゴリ全体に共通する、表に出にくい限界です。カバレッジは上がりますが、信頼度は上がりません。少なくとも、数値が示唆するほどには上がらないのです。
これが必要なのは： 不足しているのが量である場合です。テストのないコードが大量にあり、誰にも手をつける時間がない、という状況です。
タイプ2：テストを実行し、維持するAI
解決する問題： すでにテストスイートがあり、それを生かし続けるコストが高い、という状況です。デザイン変更のたびにセレクタが壊れ、テストは不安定で、毎スプリントの少なくない割合がその修復に消えていきます。
実際の姿： 画面が変わっても、実行する側が追従します。ラベルや位置が変わったボタンでも見つけ出せるのは、各ステップがDOM上の固定された経路ではなく、意図として理解されているからです。
限界： この適応力は諸刃の剣です。本物のリグレッションを避けるように自己修復してしまうスイートは、素直に失敗するスイートよりたちが悪いと言えます。知りたかったことを覆い隠してしまうからです。役に立つのは、画面が変わったのか挙動が変わったのかを見分け、前者だけを許容するタイプです。
これが必要なのは： 不足しているのが保守の手当てである場合です。テストはすでにあり、それをグリーンに保つことが税金のようにのしかかっています。
タイプ3：AIが書いたコードを検証する
解決する問題： コーディングエージェントが生成したコードが、誰も読み切れない速さでリリースされていき、かつてミスを捕まえていたレビュー工程が、いつのまにか形式的なものになっている、という状況です。
実際の姿： デプロイ済みのアプリケーションが、人が使うのと同じように操作され、その結果が、エージェントがそのまま動ける根拠として返ってきます。修正は、変更と同じループの中で行われます。
組み合わせるもの： ロジックを見る高速なローカルのユニットテストと、負荷を見る専用のツールです。この層が答えるのは、その2つには答えられない問い、すなわち「その機能は動いているプロダクトの中で実際に機能しているのか」という問いです。
これが必要なのは： 不足しているのが信頼である場合です。コードの量は増えたのにレビューの余力は増えず、直近20件のマージが何かを壊していないかを、誰も自信を持って言えません。
自分に本当に必要なAIテストはどれか
短い診断です。問うべき順に並べています。
これに当てはまるなら
「テストがほとんどありません」
「テストは十分にありますが、その半分は自社プロダクトとは無関係な理由で赤くなっています」
「テストはグリーンなのにリリースは壊れ、いまやコードの大半はエージェントから出てきます」
抱えている問題は
量。タイプ1です。
保守。タイプ2です。
信頼。タイプ3です。
選び間違えると、こうなります
カバレッジは上がりますが、障害は減りません。
不安定さは減りますが、見逃す不具合は変わりません。
誰も開かないダッシュボードが残ります。誰も書いていないテストスイートについて報告しているからです。
立ち止まって考える価値があるのは3行目です。カバレッジの上昇も不安定さの減少も測りやすい指標ですが、どちらも本当に欲しかったものではありません。欲しかったのは、本番環境で驚かされる回数が減ることです。
本気のツールとデモを分ける、たった1つの質問
どのタイプを検討しているとしても、失敗したときに何が起きるのかを尋ねてください。
デモは赤い行を見せます。実務で使えるツールは、何をしようとしたのか、アプリケーションが代わりに何をしたのか、その2つがどこで食い違ったのかを、修正する担当者が経緯を一から辿り直さずに使える形で伝えます。失敗に対する答えがスクリーンショットとスタックトレースだけなら、解釈する作業は依然として人に残ります。そしてその人こそ、取り除こうとしていたボトルネックです。
修正するのが人ではなくエージェントである場合、この点の重要性は倍になります。エージェントには、スクリーンショットに目を凝らして意図を汲み取るということができないからです。
2つ目の質問：自分がいなくても動くか
ここで挙げたどのカテゴリも、誰かが思い出したときにしかテストが動かないのであれば、価値はゼロに帰します。スケジュールに従って、あるいはプルリクエストのたびに走るスイートは、仕事をしています。人が起動してくれるのを待っているスイートは、誰かがやろうとしていた仕事についての文書にすぎません。
ですから、導入時に問うべきなのは、どちらのツールのアサーション構文が優れているかではありません。最初のセッションを終えたときに残るのが、画面上のレポートではなく、パイプラインに組み込まれたチェックであるのはどちらか、ということです。
私たちの立ち位置を率直に
TestSpriteは3つ目の問題のために作られています。稼働中のアプリケーションを開き、実際のユーザーのように操作し、壊れた箇所を、コーディングエージェントがそのまま扱える1つのまとまりとして返します。テストケースの生成も行いますが、それは検証を支えるための手段であって、目的そのものではありません。
足りないものが信頼であれば、それこそがこの製品の想定する問題です。いちばん早い確かめ方は、今週エージェントがリリースした変更に対して実行し、返ってきた内容を読んでみることです。
TestSpriteが対象とするのは3つのうちどれか
3つ目です。TestSpriteは、テストはグリーンなのにリリースが壊れ、しかもコードが誰のレビューも追いつかない速さでエージェントから届くようになったチームのために存在します。
具体的には、稼働中のアプリケーションを開き、人が使うのと同じように操作し、壊れた箇所を、コーディングエージェントがそのまま扱える、内部で辻褄の合った1つのまとまりとして返します。テストケースはプロダクトから生成され、自然言語で調整できるため、カバレッジは誰かが半日を捻出できるかどうかに左右されません。各ステップはセレクタではなく意図として扱われるため、機能的には何も変えないデザイン変更でスイートが赤くなることはありません。
テストケースを生成する点では1つ目の不足に、画面の変更に耐えるステップという点では2つ目の不足に触れています。ただしそれらは判定を支えるための手段であって、目的ではありません。本当の不満がテストを書くのは面倒だということ、あるいは既存のスイートが不安定だということであれば、そのどちらかを中心に据えた製品のほうが役に立ちます。そしてそれは、トライアルの最中ではなく始める前に申し上げておくべきことです。
1つのツールで3つすべてをカバーできますか？
部分的には可能で、重なり合う領域は確かにあります。ただし、設計の中心はどうしても表に出ます。テストコードの生成を中心に据えた製品はカバレッジを最適化し、検証を中心に据えた製品は判定の質を最適化します。その製品が自らを何で測っているのかを尋ねてみてください。
AIテストは手動QAを置き換えますか？
置き換わるのは、繰り返しのリグレッション確認です。探索的テスト、何が重要かの判断、そして曖昧なフローにおいて「正しい」とは何かを決めることは、今も人の仕事であり、価値がこれまでずっとあったのは2つ目の部分です。
テストが通ったことに意味があるかどうかは、どう判断すればよいですか？
何をアサーションしたのかを確認してください。どのアサーションにも到達しないまま終わった実行は、合格ではありません。それを合格として報告するツールは、ツールがない状態より悪いと言えます。評価の段階で、意図的に何かを壊して確かめておく価値があります。
自己修復するテストスイートは信頼できますか？
画面の変更に対しては修復し、挙動の変更に対しては失敗する場合に限ります。その2つをどう見分けているのかを製品に問い、「AIが判断します」という答えで納得しないでください。
小規模なチームはどこから始めるべきですか？
壊れたときに最も恥ずかしい思いをするフローから始め、プルリクエストのたびに走るように組み込んでください。常に走るテストケース1本は、リリース前にだけ走る50本より価値があります。