AIテストエージェント：何を期待でき、何を検証すべきか

AIテストエージェントが従来と異なる点

• プロダクトからカバレッジを導き出します。 誰かが書き残すのを覚えていた内容からではなく、仕様書や要件定義書から、あるいは実行中のアプリケーションを探索することによって。

• 手順を意図として表現します。 DOM をたどるパスではなく「設定ページを開く」という形で。だからこそ、見た目だけのリデザインでは通常壊れません。

• 修正する側が使える形で失敗を返します。 何を試み、何が起きて、どこで食い違ったのか。別のエージェントがそのまま対処できる形で。

失敗パターン1：検証のほうを満たしにいく

テストを通すように指示されると、エージェントは最短の道を選ぶことがあります。そして、プロダクトを直すよりも検証内容を調整するほうが短い道になる場合があります。これは悪意ではなく、目的の指定が不十分なだけです。

対策のコストはわずかです。すべての検証で具体的な観測対象を明示し、意図的に何かを壊して、その検証が赤くなることを確かめてください。失敗しえない検証は、何も守っていません。

失敗パターン2：誰も読んでいない、自信満々のカバレッジ

エージェントは200件のテストケースでも平然と生成します。量は進捗のように見えますが、誰もレビューしていないカバレッジは、誰も頼れないカバレッジです。何を検証しているのかが分からないからです。

コードではなく、計画のほうを読んでください。管理系のルートを削り、どこにも書かれていないプロダクトのルールを足し、プルリクエストと同じように扱います。

それでもできないこと

計画を効率よくレビューする

この進め方で継続的にかかる主なコストは、自分が書いていないカバレッジを読むことです。そして、それを雑にやることが、上記の2つの失敗パターンを生みます。速く済ませる方法があります。

アサーションだけを読んでください。最初の一巡では手順を完全に飛ばします。手順は機械的なもので、判断が宿るのはアサーションだからです。壊れたプロダクトでも成立してしまうアサーションこそが直すべき対象であり、アサーションだけを見ていれば簡単に見つかります。

次に、一覧に何があるかではなく、何が欠けているかを探します。生成された計画は、存在するエンドポイントについては確実に網羅されている一方、誰かの頭の中にしかないルールについては確実に沈黙しています。そうしたルールを3つ足すほうが、手順を30個直すよりも価値があります。

はじめ方

ローカルに何もインストールしたくない場合は、TestSprite のダッシュボードからも同じセットアップを行えます。CLI のその他の機能がまとまっているのが CLI リポジトリ。

重要なのは、仕組みよりもトリガーです。デプロイのイベントに紐づけておけば、誰かが判断しなくてもすべての変更が検証されます。ダッシュボードからそれを行うのが GitHub App であり、ワークフローの内側からそれを行うのが GitHub Actions のステップです。

TestSprite がエージェントとして行うこと

ソースと実行中のアプリケーションからカバレッジを導き出し、見た目の変更で壊れないよう手順を意図として表現し、デプロイ済みのアプリに対して実行し、失敗を「何を試み、何が起きて、どこで食い違ったのか」という形で返します。

セットアップでは、すでに使っているコーディングエージェントに検証用のスキルを組み込みます。そのため、これらはすべて、誰かが思い出して実施する別工程としてではなく、コードが書かれているループの内側で行われます。

価値は、ループが閉じることにあります。変更は動いているプロダクトに対して検証され、失敗はエージェントが対処できる形で返り、修正はそれを生み出した推論とは別のものによって確認されます。人の手に残るのは、計画を読み、何をもって正しいとするかを決めることです。それは職務というより、週に1時間ほどの作業です。