TestSpriteのAuto-Heal Rerunはどのように機能するのか？
Rui Li
テストの失敗は常に問いを投げかけます。プロダクトが壊れたのか、テストが陳腐化したのか？
その判断は熟練した作業です。経験豊富なQAエンジニアは失敗したテストを確認し、プロダクトを開き、実際にフローを手で試してから判断を下します。ボタンは移動したがチェックアウトは機能するのでテストを更新すべきか、あるいはボタンが移動してチェックアウト自体が本当に壊れているのでプロダクトを修正すべきか。この判断を適切に行うことが、テストスイートの意味を保つことに直結します。
Auto-Heal Rerunは、TestSpriteが毎回の失敗に対して、結果があなたに届く前に自動でその判断を行う機能です。内部で何が起きているのかをご説明します。
トリガーとなる条件
StandardプランおよびそれDB以上で利用可能なAuto-Heal Rerunは、テストが失敗した際に起動します。すべての実行に対してではなく、一律のリトライポリシーとしてでもありません。これまで正常に動作していたテストが通過しなくなった状況に特化して対応します。
その状況には2つの原因が考えられ、それぞれ正反対の対応が求められます。プロダクトがリグレッションした場合は、失敗を即座に明確に通知しなければなりません。UIが単に変化しただけの場合、コンポーネントのリネーム、レイアウトの再編、要素の移動など、失敗はノイズであり、それを通知するとエンジニアが「プロダクトは問題なかった」という結論で終わる調査に時間を費やすことになります。
Auto-Heal Rerunの設計全体は、この2つのケースを同じように扱うことを拒否することにあります。
判断の基準：構造ではなく振る舞い
テストが失敗したとき、エージェントが問うのは「要素を再度見つけられるか？」ではありません。QAエンジニアが問うのと同じ問いです。プロダクトはユーザーに対して正しい結果を提供し続けているか？
他の検証ツールはコードを読んで推測します。TestSpriteはアプリを開いて実際に使用します。
エージェントは実際のユーザーと同様に、実行中のアプリケーションでフローを再実行します。送信ボタンがリネーム・リスタイルされていても、ユーザーがフォームを入力して送信を完了できるなら、振る舞いは維持されています。失敗は構造的なものです。テストはドリフトしたUIに適応し、再実行が完了し、結果は重要なことを報告します。フローは機能しています。
ユーザーがフローを完了できなくなった場合、フォームが送信されない、確認画面が表示されない、結果が誤っている場合は、振る舞いがリグレッションしています。適応は行われません。適応することは実際の不具合を覆い隠すことになるからです。失敗はプロダクトレベルの説明とともに通知されます。どのアクションが行われ、何が起きるべきで、実際に何が起きたか。
名称に「Rerun（再実行）」が含まれているのは文字通りの意味です。適応されたテストが再度実行されるため、ヒールは推測ではありません。現在のUIに対する検証済みのパスです。
Auto-Healが明示的に行わないこと
一点、明確にしておく価値のある境界があります。「セルフヒーリング」という言葉は業界で曖昧に使われることがあるからです。Auto-Heal RerunはUIのドリフトやレイアウト変更に対してテストを適応させます。アプリケーションコードを書き換えることはしません。
振る舞いが実際に壊れた場合、Auto-Healは修正を試みず、リグレッションの周りに回避策を当てず、プロダクトがどうあるべきかを独自に決定しません。報告するだけです。修正はあなたのワークフローに委ねられます。失敗の説明はMCP Server経由でIDEに返され、コードを書いたコーディングエージェントがあなたの関与のもとで修正案を提示します。
テストを修正することとプロダクトを修正することは別の仕事であり、この二つを分離することが、グリーンの結果を信頼できるものにします。実際のリグレッションに適応してしまうスイートは、スイートがない状態よりも悪い結果をもたらします。
AIコーディングチームにとって特に重要な理由
構造的なドリフトはかつては偶発的なものでした。AIコーディングツールの時代では、それが常態となっています。
Cursorのセッションがパフォーマンス改善の副作用としてコンポーネントツリーを再編します。Claude Codeのセッションがフックを統合しながら要素をリネームします。いずれもユーザー体験には影響を与えませんが、構造に依存したテストはすべて壊れます。1日に複数のセッションを実行するチームにとって、振る舞いの判断機能を持たないスイートは常に失敗し続け、毎回の失敗に対してエンジニアが「何も問題なかった」という結論を確認する作業を強いられます。
計算結果がテストの存続を左右します。失敗の9割が構造的なノイズであれば、エンジニアは失敗を読まなくなり、残りの1割、つまり本物のリグレッションがリリースされてしまいます。Auto-Heal Rerunは計算式を変えます。構造的なドリフトはサイレントかつ検証可能な形でヒールされ、チームに届く失敗は本当に注目すべきものだけになります。スイートは、他の方法ではスイートを崩壊させるような変化のペースの中でも、信頼性を保ち続けます。
シナリオ：1つの失敗、同一実行における2つの結果
あるチームがClaude Codeを使って非営利団体向け寄付プラットフォームを構築しています。あるセッションで寄付フォームが大幅に刷新されました。金額ボタンがスライダーコンポーネントに変わり、レイアウトが再構成され、継続寄付トグルの名称が変更されてオプションパネル内に移動されました。
夜間の実行が変更後のフォームに到達し、寄付フローのテストが初回実行で失敗します。Auto-Heal Rerunが起動します。
エージェントは実際のドナーと同様に新しいフォームを操作します。スライダーで金額を設定し、オプションパネルを開き、継続寄付を有効にして送信します。フローは完了し、確認画面には正しい金額と頻度が表示され、サンクスメールも送信されます。動作は正常です。テストは新しい構造に適応し、再実行はパスします。翌朝のレポートには誤検知のアラートではなく、修復が記録された上で寄付フローがグリーンとして表示されます。
同じ実行では領収書ダウンロードのテストも失敗し、ここで2つ目の結果が展開されます。エージェントはフローを再試行します。寄付を完了し、領収書を開きます。領収書は表示されますが、寄付金額が$0.00と表示されています。刷新されたフォームがスライダーの値をセント単位で渡すようになった一方、領収書テンプレートが依然としてドル単位でフォーマット処理（すでに除算済みの数値をさらに除算）を行っているためです。動作が破損しています。適応は行われません。どのフローで何が起きたか、領収書の表示内容と実際の寄付金額を含む詳細な検出結果が報告されます。
1回の実行、2件の失敗、2つの正確な判断。チームの朝は、本当に修正すべき1件だけから始まります。そしてコーディングエージェントにはすでに必要な説明が揃っています。
まとめ
Auto-Heal Rerunは、有用なテストスイートと騒がしいスイートを分ける判断を行います。すべての失敗に対し、実際のユーザーと同様にフローを再実行し、プロダクトの動作が正常か破損しているかを判定します。構造的なドリフトであれば適応して検証済みの再実行を行い、真の問題であれば正確な検出結果を報告します。
適応の対象はテストのみであり、アプリケーションコードには一切手を加えません。また、真のリグレッションを回避するような適応は絶対に行いません。AIコーディングセッションが毎週UIを再構成するチームにとって、自動かつ正確に行われるこの判断こそが、グリーンをグリーンたらしめるものです。
TestSprite Standardでスタンダードプランを有効にし、次のリファクタリングでもテストスイートが生き残れるようにしましょう。