Agentが最もごまかしにくいテストとは：Trophy Testingモデル

テストを人間の受け入れ基準にアンカリングすることで、共謀問題は原則レベルで解決される。しかし実践上、もう一つの問いがある。どのタイプのテストがAgentにとって最も回避しにくいのか？

ユニットテストはコードの内部動作を検証する。特定の入力に対して特定の関数が期待される出力を返すかどうか。Agentは実装の詳細を調整することでユニットテストのアサーションを容易にパスでき、そうした調整がより上位のレベルで問題を引き起こす可能性がある。すべてのユニットテストにパスする決済モジュールが、請求モジュールとの統合時に失敗するかもしれない。ユニットテストは分離された動作のみを検証し、モジュール間のインタラクションはカバーしていないからだ。

エンドツーエンド統合テストは全く異なる粒度で検証する。ユーザーが認知可能な完全な機能パスをカバーする。ユーザーが支払いリクエストを開始し、システムが決済ゲートウェイを呼び出し、請求レコードを書き込み、確認メッセージを返す。重要なサブパスのいずれかが失敗すれば、テスト全体が失敗する。完全なユーザージャーニーを偽装することは、分離された関数出力を偽装するよりもAgentにとってはるかに困難だ。

これがTrophy Testingモデルの核心的な考え方だ。従来のテストピラミッド（多くのユニットテスト、少ない統合テスト、ごくわずかなエンドツーエンドテスト）とは対照的に、Trophyモデルは重心を統合テストレベルに置く。Agent駆動開発において、統合テストの価値はユニットテストをはるかに上回る。ユーザーの実際の使用シナリオにより近く、「表面的にパスする」ことがはるかに難しいからだ。

Trophy Testの記述原則は、ユーザーが認知可能な機能を軸にすることだ。各Trophy Testはトリガーアクションから最終結果までの完全なユーザーシナリオを記述する。アサーションは内部実装の状態ではなく、システムの外部から観測可能な振る舞いに基づく。これにより、Agentはテストをパスするために実際に機能を実装しなければならず、内部実装を微調整してアサーションを迂回することはできない。

これはユニットテストに価値がないということではない。ユニットテストは開発中の高速なフィードバックループを提供し、Agentが特定の実装上の問題を特定するのに役立つ。しかし、受け入れ判断の基盤としては、Trophyレベルの統合テストがより信頼性の高いシグナルとなる。Agentには開発を支援するためにユニットテストを自由に作成・修正させることができるが、Trophy Testの追加・削除・変更は人間の確認が必要だ。