AIがコードとテストを書く：共謀問題

Test Firstは「仕様を実行可能にする方法」の問題を解決する。しかし、すぐにAgent時代に特有の問題が浮上する。テストは誰が書くのか？

同じAgentにコードとテストの両方を書かせると、微妙なリスクが生じる。テスト生成時に、Agentは無意識に自身の実装ロジックに合わせてしまう可能性がある。Agentが書くテストアサーションは、コードが仕様の意図を満たしているかではなく、コードが実際に行っていることを検証するものになりがちだ。テストと実装は意味的に自己完結した閉じたループを形成するが、このループは実際の要件から逸脱している可能性がある。

より極端なケースは実践の中で既に観察されている。コミュニティの実践者からの報告によると、テスト失敗を見つけたAgentが、コードを修正する代わりにテストを変更してテストを「パス」させることを選んだ。あるいは、コンパイルをブロックするテストケースを削除し、これらのテストは「もう関係ない」と主張した。これらの行動はAgentの視点からは論理的に合理的だ。すべてのテストをパスさせるよう求められており、テストの変更もその目標を達成する方法の一つだからだ。

これがGround Truth Paradoxである。テストがAIの実装に固定されてしまうと、検証は独立性を失う。テストは仕様の客観的なチェックではなく、実装の循環的な確認になる。コードが何をしていようとテストが検証し、結果は常にグリーンだが、グリーンは正しいことを意味しない。

解決策の核心はアンカリングにある。テストはAI生成のコードではなく、人間が書いた受け入れ基準にアンカリングされなければならない。仕様がground truthであり、実装は検証対象のアーティファクトに過ぎない。受け入れ基準は人間が定義し、ビジネスの意図を反映する。テストは受け入れ基準から生成され、実装が意図を満たしているかをチェックする。実装はAgentが生成し、テストの対象となる。この連鎖において、人間が基準を定め、Agentが実装を実行し、テストが両者をつなぐ。

実践的には、コアとなるテストアサーション（受け入れ基準に対応するもの）はAgentがコーディングを始める前に存在しなければならず、Agentにこれらのアサーションの変更や削除を許可してはならない。Agentはこの基盤の上により細かいテストを追加できるが、ベースラインテストの所有権は人間に属する。