AIエージェントが本物のAPIレスポンスを観測してからバックエンドテストを生成できるとしたら？
Zeshi Du
バックエンドテストを生成するほとんどのAIツールは、誤ったやり方で行っています。ソースコードを読み込み、APIが返すべきものを推測し、その推測に基づいてアサーションを記述します。
推測されたアサーションの問題点は、それらが期待値を装った推測に過ぎないことです。コードはAPIがuser_idというフィールドを返すと示しています。アサーションはuser_idをチェックします。しかしAPIが実際に返すのはuserIdです。テストは最初の実行で失敗しますが、その原因は製品のリグレッションとは無関係です。エンジニアが調査し、AIが誤って推測した命名の不一致を発見し、テストを更新します。
これは些細な摩擦ではありません。バックエンドコードが迅速に生成され頻繁に変更されるAIコーディングツールを使用しているチームでは、ハルシネーションされたアサーションが蓄積し、テストスイートを信頼できないものにするノイズの問題となります。スイートが継続的に誤検知を発するようになると、本物のAPIコントラクト違反が見逃されます。
正しいアプローチは、アサーションの前に観測を行うことです。まずAPIを呼び出します。実際に何が返ってくるかを確認します。それに基づいてアサーションを生成します。
推測されたアサーションと観測されたアサーションの違い
推測されたアサーションはコード分析から構築されます。ツールはルートハンドラーを読み込み、returnステートメントを特定し、returnステートメントが生成するものをレスポンスが含むというアサーションを記述します。
これはコードアナライザーが考慮していない多くの方法で推測が誤る可能性があることに気づくまでは、合理的に聞こえます。
APIはハンドラーのreturnとワイヤーレスポンスの間で、コードアナライザーが考慮していないトランスフォーメーションを適用するかもしれません。シリアライザーはアナライザーが知らない規則に従ってフィールドの名前を変更するかもしれません。レスポンスは環境によって異なる場合があります。APIは実際の実行時にのみ現れる方法で、異なる入力状態に対して異なる動作をするかもしれません。
観測されたアサーションは実際のレスポンスから構築されます。エージェントはエンドポイントを呼び出し、返ってきた内容を読み取り、実際に存在したものに対してアサーションを記述します。フィールドが userId であるのは、レスポンスにそのフィールドが含まれていたからです。ステータスコードが 201 であるのは、作成成功時にエンドポイントがそのコードを返したからです。レスポンスの形状がスキーマと一致するのは、エージェントが実際のレスポンスからそのスキーマを確認したからです。
観測されたアサーションはハルシネーションを起こしません。起こしようがないのです。それらは現実から導き出されているからです。
観測ファーストアプローチが実際にどのように機能するか
TestSprite はこれを Backend Testing 2.0 を通じて実装しています。Backend Testing 2.0 は、観測ファーストの原則を全面的に採用して構築されています。
バックエンドのテスト計画を生成する前に、エージェントはエンドポイントを呼び出し、実際にどのように応答するかを観測します。実際のステータスコード。実際のフィールド名。実際のレスポンスの形状。エージェントは実際の呼び出しからレスポンス構造全体をキャプチャし、すべてのアサーションをその観測に基づいて構築します。
他の検証ツールはコードを読んで推測します。TestSpriteはあなたのアプリを開いて実際に使います。
バックエンド API を利用するということは、それを呼び出すということです。エージェントは、API を手動でテストする開発者と同じようにエンドポイントにアプローチします。リクエストを送信し、返ってきた内容を読み取り、実際に確認したものに基づいてアサーションの対象を決定します。
これにより、アサーションは API の予測ではなく、API の実際の仕様を反映したものになります。API に特有の挙動がある場合、コードとは異なる命名規則、入力によって変化するレスポンスの形状、ハンドラーが返すように見えるものとは異なるステータスコードがある場合でも、エージェントが実際の動作を観測しているため、アサーションは実際の動作を反映します。
動的変数：観測が不可欠になる場面
単一エンドポイントの観測は命名や形状のエラーを検出します。複数ステップの API フローには、さらなる機能が必要です。あるレスポンスから値をキャプチャし、それを後続の呼び出しで使用することです。
ユーザーが登録します。登録レスポンスに userId が返されます。ユーザーのプロフィールを取得する次の呼び出しでは、URL にその userId が必要です。実際の登録レスポンスから取得した実際の userId なしには、テストを記述することができません。
作成エンドポイントがリソースを生成します。そのリソースに id が付与されます。更新エンドポイントにはその id が必要です。削除エンドポイントにもその id が必要です。完全な CRUD ライフサイクルテストでは、後続のすべてのステップにその id を渡すために、実際の作成レスポンスから取得した実際の id が必要です。
コード推論ツールではこれを確実に実行できません。ID のフォーマットを推測することはできますが、動的に生成される値を推測して作成したテストは、毎回のテスト実行で失敗します。
TestSprite は実際のレスポンスから実際の値をキャプチャします。登録エンドポイントが { "userId": "usr_4f7d2b" } を返すと、その値は自動的にキャプチャされ、次のステップに渡されます。プロフィール取得には実際のユーザー ID が使用されます。テストは初回の実行で成功します。なぜなら、予測ではなく観測に基づいて構築されているからです。
動的変数は、エンジニアが手動でつなぎ合わせることなく、複数ステップのシーケンスを通じて自動的に流れます。CRUD ライフサイクルテストは初回の試行でエンドツーエンドで機能します。複数のエンドポイントにまたがる統合テストは、推測された形状ではなく、観測されたデータから組み立てられます。
シナリオ：初日から実行できた API テストスイート
あるバックエンドチームが、Claude Code を使用して フィンテック SaaS 製品用の REST API を構築しています。この API は、アカウント作成、残高管理、取引履歴を処理します。以前にテストを生成しようとするたびに、API の動作とは無関係な理由でアサーションが即座に失敗していたため、チームは正式なバックエンドテストを避け続けていました。
チームは TestSprite を接続し、バックエンドテストのパイプラインを起動します。
観測エージェントが実際のリクエストで各エンドポイントを呼び出し、レスポンスをキャプチャします。アカウント作成エンドポイントは accountId をキーとするレスポンスを返します。残高エンドポイントは acct_id というクエリパラメータを使用します。取引履歴エンドポイントは、レスポンス内の cursor フィールドを使用してページネーションを行います。
これらはいずれも、コード推論ツールがハンドラーを読み取って生成するものとは一致しませんでした。ハンドラーは内部で異なる変数名を使用していました。シリアライゼーション層が命名規則を適用していました。コード推論ツールはハンドラーから変数名を推測していたでしょう。観測されたテストは実際のレスポンスから取得した実際の名前を使用します。
最初のバックエンドテスト実行では、完全なアカウントライフサイクルをカバーする 12 件のテストが合格し、入出金フローの 6 件の統合テストが合格し、ステージング環境の認証設定に調整が必要な 2 件のテストが Blocked となります。
ハルシネーションによるアサーションからの失敗はゼロです。テストは、推測ではなく観測に基づいて構築されていたため、初回の試行で正しく実行されました。
Claude Code のセッションが残高エンドポイントのレスポンス形式を更新すると、次のテスト実行でその変更が検出されます。balance だったフィールドが currentBalance になっています。テストは balance を期待していました。この変更は具体的な検出事項として浮かび上がります。どのエンドポイントか、どのフィールドが変更されたか、テストが期待した値、実際に受け取った値。開発者はハンドラーのドキュメントを更新して意図的な変更を反映し、テストもそれに合わせて更新されます。
実行後のリソースクリーンアップ
観測ベースのテストは実際のシステムに実際のリソースを作成します。ユーザーを作成し、残高を更新し、取引履歴を読み取るテストは、クリーンアップが行われなければ状態を残します。
TestSprite は、テストが作成したリソースを毎回の実行後に依存関係の順序でクリーンアップします。アカウントフローをテストするために作成されたユーザーは、実行後に削除されます。そのユーザーに関連する残高の更新も削除されます。取引記録も削除されます。
テスト環境は次の実行に向けてクリーンな状態を保ちます。以前の実行から蓄積されたテストデータが新しい観測に干渉しません。
まとめ
バックエンドテストを生成する前に実際の API レスポンスを観測できる AI エージェントとは、まず API を呼び出し、返ってきた内容を読み取り、コード分析ではなくその観測からアサーションを構築するエージェントです。
TestSprite の Backend Testing 2.0 はこの原則に基づいて構築されています。エンドポイントを呼び出し、実際のレスポンスをキャプチャし、観測された動作に基づいたアサーションを構築し、動的変数を実際のレスポンスから複数ステップのシーケンスに渡し、毎回の実行後に作成したリソースをクリーンアップします。
その結果、バックエンドテストはコードが生成するものの予測ではなく現実から導き出されているため、初回の試行で正しく実行されます。
今すぐ AI IDE 内から TestSprite を使用して、観測に基づいたバックエンドテストの生成を開始しましょう。