AIはコードからテスト要件を推論できるか？
Zeshi Du
できます。しかし「コードから推論する」というのは間違った目標です。
コードからテスト要件を推論すると主張するほとんどのツールは、まさにそれをしています。実装を読み、コードが何をするかをトレースし、それを一貫して実行することを検証するテストを生成します。出力されるのは、コードに対して正しいテストです。問題は、「コードに対して正しい」と「ユーザーにとって正しい」は別物だということです。
コードにバグがあれば、コードから要件を推論するツールは、そのバグを要件として推論します。テストはパスします。バグはリリースされます。ツールは主張通りに動作しましたが、それでも役に立ちませんでした。
正しい目標は、コードから要件を推論することではありません。コードからプロダクトの意図を推論し、プロダクトが実際にその意図を実現しているかどうかをテストすることです。
コード要件とプロダクト意図の違い
コード要件とは、実装が行うことです。プロダクト意図とは、プロダクトがユーザーのために実現するよう設計されたことです。
完璧なコードベースでは、これらは同一です。しかし現実のプロジェクトでは乖離が生じます。開発者は特定の動作を念頭に置いて機能を実装します。コードはその意図の一部を反映し、一部の前提を誤ってエンコードし、いくつかのエッジケースを完全に見落とします。実装は仕様ではありません。仕様の近似です。
実装を読んでそこからテストを生成するツールは、意図ではなく近似を捉えます。近似から構築されたテストは、コードが自分自身と一貫しているかどうかを検証します。プロダクトがユーザーの期待を満たしているかどうかは検証しません。
プロダクト意図に基づいてテストするということは、現在の実装がたまたま生み出すものとは独立して、プロダクトが何をすべきかにテストの目標を固定することを意味します。ふたつが乖離したとき、テストは失敗します。それこそが重要な失敗です。
TestSpriteが実装ではなく意図を推論する方法
PRDが存在しない場合、TestSpriteはMCPサーバーを使用してコードベースから直接プロダクト意図を推論します。コードが何をするかを問うのではなく、プロダクトが何を達成するために構築されたかを問うのです。
ルート定義は、プロダクトがサポートするよう設計されたユーザーアクションを明らかにします。APIコントラクトは、プロダクトが管理するデータフローを明らかにします。コンポーネントの構造と命名規則は、プロダクトがユーザーに提示しようとしているものを明らかにします。これらを合わせると、設計意図の証拠が形成され、TestSpriteはその証拠から構造化された内部モデルを構築します。
そのモデルが、以降のテスト生成の基盤となります。テストはコードの現在の出力ではなく、推測されたプロダクトの意図に基づいて構築されます。実装にバグがあり、関数が誤った値を返す場合、意図から構築されたテストは正しい結果を期待するため、適切に失敗します。実装が正しく機能している場合、テストはパスします。
これが、テスト生成が有用かどうかを左右する違いです。他の検証ツールはコードを読んで推測します。TestSpriteはアプリを開いて実際に使用します。
推測された意図からリアルな検証へ
何をテストすべきかを正しく推測することが第一歩です。それを正しく検証することが第二歩です。
コード解析からテストを生成するツールの多くは、検証においてもコードレイヤーにとどまります。プロダクトが何をすべきかを推測し、関数やコンポーネントに対してアサーションを記述し、それらが通過するかどうかを報告します。推測は合理的かもしれませんが、検証は依然としてコードレイヤーであるため、実際のユーザーが実際のフローを実行したときにのみ現れる障害を見逃してしまいます。
TestSpriteの探索エージェントは、推測された意図モデルを取得し、実際に動作しているアプリケーションに対して検証します。並列エージェントの集団がライブプロダクトにアクセスし、実際のユーザーと同じようにナビゲートします。ソースファイルに対してアサーションを実行するのではなく、UIフローをクリックして進み、実際の入力でフォームを入力し、複数ステップのジャーニーをたどり、各ステップで結果を観察します。
推測された意図が「ユーザーはプロフィール設定ページからメールアドレスを更新できるべき」と示している場合、エージェントはプロフィール設定ページに移動し、メールアドレスを更新して保存し、更新が反映されたかどうかを確認します。それが検証です。更新ハンドラー関数が入力を受け付けたというアサーションではなく、プロダクトが実現するよう設計されたことをユーザーが実際に行えるかどうかを確認します。
シナリオ：コードレビューで見逃したものを意図推測が検出する
個人開発者がWindsurfを使ってSaaSプロダクトの請求管理ページを構築しています。PRDは書きません。機能は頭の中で明確なため、そのまま実装に進みます。
プッシュ前に、TestSpriteを接続してWindsurf内からテストパイプラインを起動します。
TestSpriteのMCPサーバーがコードベースを解析し、請求ページのプロダクト意図を推測します。ルート定義とコンポーネント構造から、そのページがユーザーに現在のプランの確認、上位ティアへのアップグレード、支払い方法の更新を可能にするよう設計されていることを特定します。この証拠から意図モデルを構築し、実行中のアプリケーションに対して各機能を検証する探索エージェントをデプロイします。
エージェントは請求ページに移動し、プランアップグレードフローを見つけ、無料ティアから有料ティアへのアップグレードを試みます。UIフローは完了し、確認メッセージが表示されます。その後、エージェントはアカウント概要に移動し、プランがアップグレードを反映しているか確認します。
反映されていません。Windsurfセッション中に、アプリケーションデータベースのプランを更新するStripe webhookが誤ったエンドポイント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でプロダクト意図の推測と検証を始めましょう。