Cursor デバッグツールのセッションが停滞する理由
デバッグとは、観察する、仮説を立てる、変更する、再び観察する、というループです。ファイルだけを手がかりに動くエージェントは、この 4 つのうち 3 つをこなせます。できないのは観察です。スタックトレースを貼り付けたり、画面で見たことを説明したりするたびに、エージェントにできない唯一のステップを人間が手作業で代行していることになり、ループ全体の質は説明の的確さ以上にはなりません。
だからこそ、3 回目の往復は 1 回目より悪くなりがちです。人は疲れて説明は短くなり、エージェントは要約の要約をもとに推論することになります。
エージェントを誤らせる 3 つの説明
「動きません」
エージェントは、考えられる 5 つの失敗パターンのうちどれを指しているのかを推測するしかありません。
そして多くの場合、最も直しやすいものを選びますが、それが実際の問題であることはほとんどありません。
「このエラーが出ます」
エラーは、真の問題より後に、しかも何層も離れた場所で現れる症状です。
例外が発生した箇所を直せば症状は消えますが、欠陥はそのまま残ります。
「X はもう試しました」
X がアプリに実際どう作用したのかがわからなければ、エージェントは何一つ除外できません。
その結果、形を変えた X を再び提案してきます。
ループを閉じるもの
観察のステップを自分で代行するのではなく、エージェントに担わせることです。つまり、デプロイ済みのアプリケーションを人間と同じように操作し、そこで起きたことを文章ではなく証拠として報告する仕組みを用意する、ということです。
その証拠は、量よりも形が重要です。何を試したのか、アプリケーションが実際にどう振る舞ったのか、そして両者がどこで食い違ったのか。エージェントはこうした情報にそのまま対応できます。スクリーンショットとスタックトレースは、結局のところ人間の解釈を必要とし、抜け出そうとしていたループへ引き戻されてしまいます。
セットアップにより、検証用のスキルが Cursor 自体に組み込まれます。そのため、毎回ワークフローを説明しなくても、テストケースを作成し、実行し、結果を読み取る方法をエージェントが把握できます。
ターミナル
npm install -g @testsprite/testsprite-cli
testsprite setup
同じことは TestSprite のダッシュボードからも行えます。CLI が提供するその他のすべての機能については、こちらをご覧ください： CLI リポジトリ。
説明よりも、渡せる再現手順
最も効果が大きい習慣は、バグを説明するのをやめて、再現させることです。書き起こしたテストケースには、どのページを開き、何を操作し、その後どうなっていればよいかが記されています。そうした 3 行は、3 段落の説明を上回ります。曖昧さがなく、何度でも再実行できるからです。
エージェントとのやり取りも変わります。「ドロップダウンが壊れている」ではなく、ステップ 4 まで進んだところで誤った選択肢が選ばれていた、という実行結果が入力になります。解釈の余地はどこにも残りません。
テストケースは、3 回目の修正のあとではなく、最初の修正を試す前に書いてください。その時点なら、どう操作して問題を引き起こしたのかを正確に覚えているはずです。この種の知識は、誰もが思うより早く消えていきます。
ループが閉じる具体例
具体的な例で考えてみましょう。保存したフィルターを編集しても、ときどき元に戻ってしまうという報告がユーザーから届きます。それを説明すると、エージェントは 2 つの状態更新の競合を見つけ、ガード処理を提案します。適用して 1 回試すとうまく動いたので、次の作業に移ります。その 2 日後、同じ報告が再び届きます。
問題があったのは修正内容ではありません。手動で 1 回試すというのは、断続的に起きるバグに対してサンプル数 1 で臨むことであり、断続的なバグは 1 回の試行では、失敗するのと同じくらいの頻度で通ってしまうのです。実際に収束するループは違う形をしています。操作の流れをテストケースとして書き起こし、何度か実行して、その発生率を読み取るのです。10 回中 4 回の失敗という情報は、「壊れています」とはまったく別の指示としてエージェントに伝わります。決定論的な原因をまとめて除外し、タイミングの問題を指し示すからです。
もう一つ変わるのは、修正後の流れです。同じテストケースをもう一度、10 回実行すれば、発生率がゼロになるか、ならないかがわかります。手元に残るのは印象ではなく証拠です。しかもテストケースはスイートに残るため、3 度目の報告が届くことはありません。
疑うべき主張
「問題を修正しました」は、エージェントを使ったデバッグで最も高くつく一文です。この一文は変更を生み出したのと同じ推論から出てきたものであり、独立した情報を何も含んでいません。修正が確認されるのは、振る舞いが正しいと観察されたときです。そして定義上、その修正を書いたエージェント自身が、確認する側になることはできません。
これはモデルへの批判ではありません。パッチを書いたあと、何も実行しないまま正しいと宣言する人間も、レビューでは同じ反応を受けるはずです。
チェックをセッションの外に残す
バグを再現するために書いたテストケースは、修正中よりも修正後にこそ価値があります。そのまま残して変更ごとに実行すれば、同じ欠陥が 3 週間後に静かに戻ってくることはありません。
GitHub App は、TestSprite のダッシュボードで設定する webhook です。すでにパイプラインが生成しているデプロイイベントを待ち受けるため、リポジトリ側には何の変更も要りません。
GitHub Actions を使えば、このステップを自分のワークフローの内側に組み込めます。設定はターミナルから行います。
ループに検証ステップが入ると何が変わるか
TestSprite は、ループに欠けている観察を提供します。セットアップによって検証用のスキルが Cursor 自体に組み込まれるため、エージェントはテストケースを作成し、デプロイ済みのアプリに対して実行し、その結果を読み取れます。あなたが何かを伝え直す必要はありません。
デバッグセッションに現れる実際の効果は、同じ往復が繰り返されなくなることです。エージェントはもはや、あなたが何を見たかという記憶をもとに推論しません。何を試したのか、アプリケーションがどう振る舞ったのか、両者がどこで食い違ったのかという記録を持っています。提案された修正は、それを生み出した推論とは別のものによって確認されます。「修正しました」が情報になるのは、この方法しかありません。
再現手順もセッションより長く残ります。バグを見つけたテストケースはスイートに残り、変更ごとに実行されるため、同じ欠陥が 6 週間後に静かに戻ってくることはありません。
Cursor はアプリケーションを実行せずにデバッグできますか？
コードについて推論することはできますし、それによって欠陥を見つけられることも多くあります。特に、たどり方が明確なロジックの誤りではそうです。ただし修正を確認することはできず、アプリを動かしたときにだけ現れる状態・タイミング・連携の問題は見えません。
同じバグが再発するのはなぜですか？
再現手順が、テストではなくチャットの中に置かれたままになっているからです。会話が終われば、その振る舞いを確認するものは何も残りません。
これは Cursor でのデバッグワークフローを置き換えるものですか？
いいえ。欠けている観察のステップを補うものです。変更を提案するのは引き続き Cursor で、それが妥当かを判断するのはあなたです。そして検証が、その修正が機能したかどうかを両者に伝えます。
自分のコードはどこまで見られますか？
検証は、デプロイ済みのアプリケーションに対してそのインターフェース経由で実行されます。そのため、リポジトリを読むのではなく、振る舞いについて報告します。
バグが本番環境でしか出ない場合はどうすればよいですか？
それが再現する環境に向けて実行してください。環境によって振る舞いが異なるのであれば、多くの場合その差分こそが本当のバグであり、コードを変更する前に追う価値があります。