AIはコードからテスト要件を推測できるか？
Zeshi Du
はい。しかし、コードからの推測は間違った目標です。
コードからテスト要件を推測すると主張するほとんどのツールは、まさにそれを行っています。実装を読み取り、コードが何をするかをトレースし、それを一貫して行うかを検証するテストを生成します。出力されるのは、コードに対して正確なテストです。問題は、コードに対して正確であることと、ユーザーにとって正確であることは別物だということです。
コードにバグがある場合、コードから要件を推測するツールはそのバグを要件として推測します。テストはパスします。バグはリリースされます。ツールは主張どおりのことを正確に行いましたが、それでも役に立ちませんでした。
正しい目標は、コードから要件を推測することではありません。コードから製品の意図を推測し、その製品が実際にその意図を実現しているかをテストすることです。
コード要件と製品意図の違い
コード要件とは実装が行うことです。製品意図とは、製品がユーザーのために何を実現するよう設計されているかです。
完璧なコードベースでは、これらは同一です。しかし実際のプロジェクトでは乖離が生じます。開発者は特定の動作を念頭に置いてフィーチャーを実装します。コードはその意図の一部を反映し、いくつかの前提を誤ってエンコードし、いくつかのエッジケースを完全に見落とします。実装はスペックではありません。スペックの近似値です。
実装を読み取りそこからテストを生成するツールは、意図ではなくその近似値を取り込みます。近似値から作られたテストは、コードがそれ自体と整合していることを検証します。製品がユーザーの期待に応えているかを検証するものではありません。
製品意図からテストすることは、現在の実装が何を生成するかに関係なく、製品が何をすべきかにテストの目標を固定することを意味します。この二つが乖離した場合、テストは失敗します。それが重要な失敗です。
TestSpriteが実装ではなく意図を推測する方法
PRDが存在しない場合、TestSpriteはMCPサーバーを使用してコードベースから直接製品の意図を推測します。コードが何をするかを問うのではなく、製品が何を達成するために作られたかを問います。
ルート定義は、製品がサポートするよう設計されたユーザーアクションを明らかにします。APIコントラクトは、製品が管理するデータフローを明らかにします。コンポーネントの構造と命名規則は、製品がユーザーに提示しようとしているものを明らかにします。これらが合わさって設計意図のエビデンスを形成し、TestSpriteはそのエビデンスから構造化された内部モデルを構築します。
このモデルが後続のテスト生成を固定します。テストはコードの現在の出力ではなく、推測された製品意図に基づいています。実装にバグがあって関数が誤った値を返す場合、意図から作られたテストは正しい結果を期待して正しく失敗します。実装が正しく動作する場合、テストはパスします。
これこそがテスト生成が有用かどうかを決定する違いです。他の検証ツールはコードを読んで推測します。TestSpriteはアプリを開いて使用します。
推測した意図から実際の検証へ
何をテストすべきかを正しく推測することがステップ1です。それを正しく検証することがステップ2です。
コード解析からテストを生成するほとんどのツールは、検証もコードレイヤーにとどまります。製品が何をすべきかを推測し、関数やコンポーネントに対してアサーションを記述し、それらのアサーションがパスするかを報告します。推測は合理的かもしれません。しかし検証は依然としてコードレイヤーであるため、実際のユーザーが実際のフローを実行したときにのみ現れる失敗を見逃します。
TestSpriteの探索エージェントは、推測された意図モデルを取得し、実行中のアプリケーションに対して検証します。並列エージェントの群がライブ製品を訪問し、実際のユーザーと同じようにナビゲートします。ソースファイルに対してアサーションを実行するのではありません。UIフローをクリックし、実際の入力でフォームを入力し、複数ステップのジャーニーをたどり、各ステップで結果を観察します。
推測された意図がユーザーはプロフィール設定ページからメールアドレスを更新できるはずだと示す場合、エージェントはプロフィール設定ページに移動し、メールアドレスを更新して保存し、更新が保持されているかを確認します。これが検証です。更新ハンドラー関数が入力を受け付けたというアサーションではありません。ユーザーが製品の設計上できるようにされていることを実際にできるかどうかです。
シナリオ：コードレビューが見逃したものを意図推測が捉える
あるソロ開発者がWindsurfを使ってSaaSプロダクトの請求管理ページを構築しています。PRDは書きません。頭の中でフィーチャーが十分明確なため、そのまま実装に進みます。
プッシュする前に、TestSpriteを接続してWindsurf内からテストパイプラインをトリガーします。
TestSpriteのMCPサーバーがコードベースを解析し、請求ページの製品意図を推測します。ルート定義とコンポーネント構造から、このページがユーザーが現在のプランを確認し、上位ティアにアップグレードし、支払い方法を更新できるよう設計されていることを特定します。このエビデンスから意図モデルを構築し、実行中のアプリケーションに対して各機能を検証するための探索エージェントをデプロイします。
エージェントは請求ページに移動し、プランアップグレードフローを見つけ、無料ティアから有料ティアへのアップグレードを試みます。UIフローが完了します。確認メッセージが表示されます。エージェントはその後アカウント概要ページに移動し、プランがアップグレードを反映しているかを確認します。
確認画面が表示されたのは、アプリケーションデータベースのプランを更新するStripe webhookが、Windsurfセッション中に誤ったエンドポイントURLに設定されていたためです。UIはアップグレードの成功を楽観的に表示しましたが、実際のプランレコードは一切更新されませんでした。
コードレイヤーのテストであれば、アップグレード関数が実行され、確認コンポーネントがレンダリングされたことは検証できたでしょう。しかし、フロー全体をナビゲートし、UIの成功状態を確認したうえで、プランが実際に変更されたかどうかまで確認したエージェントだけが、この不一致を検出できました。
失敗は構造化された形式でWindsurfセッションに返され、同じセッション内で修正が適用されます。
PRDが存在する場合、インテント推論の精度が向上する
仕様書が存在しない場合でも、コードベースのみを用いた推論パスは有効に機能します。PRDが存在する場合、インテントモデルはさらに精緻になり、生成されるテストの網羅性も高まります。
TestSpriteは利用可能なPRDおよびユーザーストーリーを解析し、テスト目標を明示された製品要件に直接紐付けます。テストは実装の証拠から推論されるのではなく、明示的なプロダクトインテントから導出され、実際に動作するアプリケーションに対して検証されます。
これは特にAIが生成したコードにおいて重要です。AIコーディングエージェントがPRDをもとに機能を構築する場合、実装がPRDに指定された内容とわずかに異なるものになるリスクがあります。TestSpriteは、実装が生成したものではなく、PRDに記述されたインテントに対してテストを行うことで、この問題を検出します。
PRD解析とプロダクトレイヤー検証の組み合わせにより、コードレイヤーテストが残していたループを閉じることができます。それは、AIが生成したコードが要求された内容を実際に実現しているかどうかを検証することであり、単に内部的な整合性があるかどうかを確認するだけではありません。
インテントモデルを最新の状態に保つ
プロダクトインテントは進化します。機能が追加され、既存のフローが再設計され、新しいユーザージャーニーが生まれます。
TestSpriteのエクスプロレーションエージェントは、実行のたびにプロダクトインテントを再探索します。新機能がリリースされると、エージェントがそれを探索し、インテントモデルに追加し、テストを自動生成します。チームは新機能のカバレッジのためにテストスイートを手動で更新する必要はありません。カバレッジはプロダクトとともに拡張されます。
Auto-Heal Rerunは、UI変更によって既存のテストが動作上ではなく構造上の理由で失敗するケースに対処します。コンポーネントの名前が変更されたり、レイアウトが変わったりした場合でも、テストは自動的に適応します。一方、推論されたインテントが期待する動作をプロダクトが提供できなくなった本質的な動作リグレッションは、明確に検出されます。
GitHub Actionsとのインテグレーションにより、インテントに基づいたカバレッジをCIに組み込むことができます。すべてのプルリクエストが現在のインテントモデルに対する検証をトリガーします。Claude Code、Cursor、Windsurf、またはMCP対応IDEに統合されたTestSprite MCPサーバーを通じて、このカバレッジは単一の指示で実行できます。
まとめ
AIはコードからテスト要件を推論できます。しかし、この能力のより有用な形は、コードからプロダクトインテントを推論し、そのインテントを実際に動作するアプリケーションに対して検証することです。
実装から推論された要件は、バグも含め、コードが現在行っていることをそのままエンコードしたテストを生成します。設計の証拠からインテントを推論すれば、プロダクトが本来あるべき姿に根ざしたテストが生まれ、本当に重要な失敗を検出できます。
TestSpriteは、ルート、コントラクト、コンポーネント構造、命名規則といったコードベースに埋め込まれた証拠からインテントモデルを構築します。エクスプロレーションエージェントは、実際のユーザーのようにライブプロダクトをナビゲートすることでそのインテントを検証します。結果はIDEに構造化された形で返され、コーディングエージェントが直接アクションを起こせるようになっています。
正式な仕様書なしに開発するAIネイティブチームにとって、コードからのインテント推論は自律テストを始める方法です。PRDを持つチームにとっては、そのテストをさらに精緻にする方法です。
今すぐAI IDEからTestSpriteを使ってプロダクトインテントの推論と検証を始めましょう。