なぜ起きるのか
記録された各手順は、locatorで要素を対象にします。たとえば「Sign inというラベルのボタン」や「order-idという名前のフィールド」のような指示です。locatorは、生のCSSよりも安定した属性（role、表示テキスト、label、placeholder、test id）を優先します。これは、小さな見た目だけのサイト変更で記録が壊れないようにするためです。ただし、本格的なリデザイン、たとえばフィールド名の変更、チェックアウトフローの再構成、ボタンの移動があると、それまで有効だったlocatorが間違った要素に一致したり、何にも一致しなくなったりすることがあります。 その場合、決定論的なリプレイは本来すべきことを正確に行います。推測するのではなく、明確に失敗します。何が表示されるか
- オートメーションの呼び出しテーブルに、locator-mismatchエラーを伴う失敗した実行が表示されます。解決できなくなった具体的な手順とlocatorも表示されます。
- オートメーション自体の状態が公開済みから失敗中に変わり、Buildへ戻るディープリンク付きで**「サイトが変更されました — 再記録」**というバナーが表示されます。
- 再公開するまで、既存の呼び出し元には実際のエラーレスポンスが返り続けます。静かに間違った答えを返すことはありません。Jinba Trailは、壊れたlocatorに対して推測した結果を代わりに返すことはありません。
修正方法
タスクを再記録する
手順を生成をもう一度クリックします。エージェントは同じタスク説明でサイトを再操作し、変更された内容に適応します。初回と同じ、説明 → 記録 → HITLハンドオフのループをたどります。全体の手順はBuild Studioを参照してください。
入力または出力の形状も本当に変わっている場合（新しい必須フィールド、名前が変わった出力キーなど）、呼び出し元はリクエストまたはレスポンスの処理を更新する必要があります。オートメーションのDocsページには、常に現在のスキーマが反映されます。Docsページを読むを参照してください。
なぜ自動修復ではなく再記録なのか
Jinba Trailが代わりのlocatorを自動で推測することは可能かもしれません。しかしそれは、決定論性をベストエフォートのヒューリスティックと静かに引き換えることになります。これは、下層のエンジンが拒否しているのと同じトレードオフです（Jinba Trailとはを参照）。新しい記録を人間が一度確認することは、公開済みオートメーションが、レビューされ公開されたとおりの内容だけを返し続ける保証のための小さなコストです。次のステップ
Build Studio
ここで繰り返す、記録 → レビュー → 公開のループ。
PlaygroundとAPIキー
オートメーションを再実行して、修正を確認します。