Cursor デバッグモードの使い方（実例つき）

先に結論

Cursor のデバッグモードは、「コードを読んで推測する」よりも「実行ログで事実確認する」ことを強制するモードです。
今回の「異世界衰弱」不具合修正では、この流れを守ったことで、見た目では分かりにくい再戦処理の問題を特定できました。

---

デバッグモードで押さえるべき基本フロー

1. 仮説を複数立てる（3〜5個）
2. 仮説を判定できる最小限のログを入れる
3. ユーザーが再現操作を実行する
4. ログを読んで仮説ごとに「確定/否定/保留」を判定
5. 根拠がある修正だけ実施
6. もう一度再現して、修正後ログで改善を確認

「たぶんここが原因」だけで直さないのが最大のポイントです。

---

ボタンの意味（最初に迷いやすい点）

Proceed

• 意味: 「再現手順を実行したので、ログ解析を続けてよい」
• 使うタイミング: 不具合が出た直後、または指定した検証操作を終えた直後
• 期待される動き: エージェントがログを読み、仮説判定と次の修正案に進む

Mark as fixed

• 意味: 「こちらの確認では、現象が再発していない」
• 使うタイミング: 修正後の再テストで問題が再現しなかったとき
• 期待される動き: エージェントが最終確認に進み、ログ除去や締めの説明を行う

使い分けのコツ

• まだ不具合が出る段階では Proceed
• 直ったと判断できた段階で Mark as fixed

---

実例: 異世界衰弱の再戦フロー不具合

現象

4人対戦 + 観戦者で、ゲーム終了後に
A が「いいえ」、B/C が「はい」を選ぶケースで、30秒後に B/C の再戦が始まらず「対戦相手がいませんでした」になってしまう。

最初に疑ったポイント

• 再戦成立判定ロジック自体が間違っている
• クライアント表示だけ切り替わっていて、サーバー状態は成立している
• 背景タスクでのルーム離脱処理が例外で止まり、後続イベントが飛んでいない

ログで分かった事実

• rematch_countdown_leave_room_failed が出ていた
• 例外は Working outside of application/request context
• その結果、game_started が想定通りに発火せず、部屋期限切れ側の遷移が走っていた

修正内容

• 背景タスク内の leave_room 呼び出しを、request context 前提の関数から
  socketio.server.leave_room(...) に変更
• 背景タスクでも安全に離脱処理が行えるようにした

修正後の確認

• 同じシナリオで再実行し、rematch_started → game_started の流れを確認
• 例外ログが消えていることを確認
• 期待どおり B/C 再戦が開始し、観戦者も継続観戦できることを確認

---

実務での運用テンプレート（そのまま使える）

1. 「再現条件」を1つに絞る
2. その条件だけ判定できるログを2〜6本入れる
3. Proceed で1回目ログ取得
4. 仮説を捨てる/残すを明確化
5. 根拠あり修正のみ実施
6. Proceed で2回目ログ取得（修正後）
7. 問題が再発しなければ Mark as fixed

---

よくある失敗

• ログを十分に見ないまま修正を重ねる
• 修正前後で同じ再現条件を使っていない
• 直っていないのに Mark as fixed に進んでしまう

デバッグモードは、丁寧に1サイクル回すほど強いです。
ボタンの意味を理解して、Proceed と Mark as fixed を役割で分けると、修正精度が安定します。