既存のコードベースからテストを生成する方法

実際のプロジェクトのほとんどは、PRDが最新の状態に保たれていません。そもそも存在したことさえないかもしれません。仕様はコミットメッセージ、Slackのスレッド、そして創業者の記憶の中にあります。だからといって自動テスト生成が不可能なわけではありません。起点がドキュメントからコード自体にシフトするだけです。その仕組みと、生成されたものを信頼する前に確認すべき点を説明します。

コードのみによるテスト生成がPRD駆動の生成とは異なる問題である理由

書かれたPRDが存在する場合、エージェントはプロダクトが明示的に何をすべきかにテスト目標を紐付けられます。PRDがない場合、利用可能なシグナルはコードが現在行っていることだけです。これは特定のリスクをもたらします。実装にバグがある場合、その実装だけから生成されたテストは、照合すべき独立した意図の宣言がないため、そのバグを正しい動作としてひっそりとエンコードしてしまう可能性があります。

優れたコードベース推論は、現在の実装を説明するだけではありません。コードが行ごとにたまたま何をしているかではなく、コードが何を達成しようとしているか、つまり意図を推論しなければなりません。その区別こそが、本当に有用な推定PRDと、既存のバグをそのまま反映するだけのテストスイートを分けるものです。

実践的なプロセス

1. 実行中のアプリケーションとリポジトリをエージェントに指定してください。コードベースベースの生成では、エージェントがソースを読むだけでなく直接探索するため、アプリが実行中である必要があります（ローカル、ステージング、またはプレビューデプロイメント）。また、プロジェクト構造もスキャンします。フレームワークの検出（React、Vue、Angular、Node.jsなど）、コンポーネント階層、およびAPIルートです。

2. エージェントに、見つけた内容から正規化された内部PRDを構築させてください。このステップは、静的コード分析と、より高機能な実装では、コードだけでは明らかにならないフロー（多段階のオンボーディングウィザードや、メニューの奥に隠れた設定ページなど）を発見するためにアプリを実際にクリックして探索するエージェントとを組み合わせます。出力は、以前は書かれた成果物として存在しなかったが、今や実際のPRDと同じアンカリング機能を果たす構造化された要件ドキュメントです。

3. 生成されたテストを信頼する前に推定PRDをレビューしてください。これは、コードベースのみの生成において最も重要なステップです。照合する別の真実のソースがないため、推定PRDはエージェントが誤った意図を推論したケースを捕捉する唯一の機会です。たとえば、コード内の回避策を後で誰かが修正するつもりだった暫定的な対処ではなく、意図された設計と見なしてしまう場合などです。

4. レビュー済みの意図から生成・実行してください。推定PRDが妥当に見えたら、テストケースの生成と実行は、書かれたPRDからの場合と同じように進みます。UIフロー、APIルート、認証、エラー状態にわたるエンドツーエンドのカバレッジが、分離された環境で実行されます。

5. 最初の実行をキャリブレーションとして扱い、最終的な真実としないでください。コードベース推論テストの最初のパスは、生成されたテストが通過するかどうかだけでなく、記憶している実際の意図と照らし合わせて、いくつかの生成されたテストをスポットチェックする良い機会です。バグを期待される動作として正しく検証したために通過したテストは、本物の問題を指摘して失敗するテストより悪い結果です。

コードベース推論の信頼性を高める・低める要因

明確な命名、一貫したパターン、視認性の高い構造（明確なルート名、適切に命名されたコンポーネント、予測可能なファイル構成）を持つコードベースは、内部的な一貫性なく有機的に成長したコードベースよりも、推論エンジンにはるかに多くの情報を提供します。これはより乱雑なプロジェクトでのコードベースベースの生成を避ける理由ではありません。最初のレビューパスがそのプロジェクトではより重要になること、そして生成されたカバレッジを完全に信頼する前に推定PRDの確認に少し余分な時間を確保すべき理由です。

探索ベースの発見が真の価値を発揮する場面

複数のエージェントが同時にライブアプリケーションをナビゲートして見つけた内容の構造化されたマップを報告する並列探索アプローチは、純粋な静的コード分析では見落とすフローを捕捉します。特定のユーザーロールの背後にゲートされた機能、特定のアクション後にのみ表示される多段階ウィザード、または静的分析だけではコードから表面化しないエッジケースのUI状態などです。その探索が行われるのを見守ること（多くの場合、ライブプレビューとユースケースフローグラフを通じて）は、それ自体として有用なサニティチェックでもあります。探索エージェントが重要なフローを見落とした場合、それは結果としてのテストカバレッジを信頼する前に対処すべきシグナルです。

書かれたPRDがまだ書く価値がある場合

コードベース推論は真に有能なフォールバックであり、意図のドキュメント化の永続的な代替ではありません。プロジェクトが成熟して複数の人が取り組むようになった場合、または機能の正しい動作がコードだけでは明らかでない場合（誰かの頭の中にのみ存在するエッジケースを持つビジネスルール）、その時点でたとえ短いPRDを書くだけでも、そこから生成されるテストの精度が著しく向上します。

コードのみの推論への信頼を時間をかけて構築する実践的な方法

コードベース推論を信頼するかどうかを一度決めて先に進むのではなく、最初の数回のセッションを特にキャリブレーション期間として扱ってください。最初の3〜4回の実行それぞれの後、推定PRDの機能の説明と、それを構築した際に実際に意図していたことを数分かけて比較してください。両者が密接に一致するケースは、推論エンジンがその種の機能に対してコードの構造を正確に読み取っていることを示します。両者が乖離するケースは、一度限りの修正としてではなく、パターンとして注目する価値があります。なぜなら、それらはしばしば特定のスタイルのコード（暗黙のビジネスロジック、意図的に見える回避策）を指し示しており、それが特定のコードベースでのコードのみの推論を一貫して躓かせるからです。そのパターンは、より高リスクなものに推論されたテストを頼る前に知っておく価値があります。

まとめ

PRDなしで既存のコードベースからテストを生成することは、妥協ではなく、実際に実行可能な道筋です。ただし、レビューの注意を向ける場所がシフトします。すでに信頼しているドキュメントと生成されたテストが一致しているかを確認するのではなく、推論された意図が実際に自分の意図と一致しているかを、その推論が下流のすべての基盤となる前に確認します。このレビュー習慣は最初の数回の実行で数分のコストがかかりますが、誤った前提がカバレッジの永続的な盲点になる前に捕捉した最初の瞬間に元が取れます。TestSpriteのMCP Serverは、PRDが存在しない場合でもコードベースから直接この推論を処理します。開始するために別のドキュメント化のステップは不要です。