Cursorでエラー原因を調べるときの使い方

Cursorでerrorを調べるときは、error messageを貼ってすぐ修正させるのではなく、再現条件・観測事実・最有力仮説を分けます。Agentはcodebase検索やterminal実行を使って関連箇所を調べられますが、症状の一文だけでは原因を特定できません。最初に同じ操作で再現できる最小条件を作り、どのlayerで失敗したかを追ってからpatchを依頼します。

まず再現できる記録を集める

errorが出た画面、command、入力、期待した結果、実際の結果を揃えます。stack traceは最後の行だけでなく、関連するcall pathを含む範囲を保存します。環境差がありそうならOS、runtime、dependency version、feature flagを確認します。credentialや個人情報を含むlogはそのままpromptへ貼らず、秘匿値を安全に置き換えます。

表は横にスクロールできます

Evidence	記録すること	注意点
Repro steps	何をどの順で操作したか	毎回同じ条件にする
Input	最小の入力と境界値	private dataはmaskする
Expected / actual	期待値と実際の差	「動かない」を具体化
Error	status、message、stack	secretやtokenを除く
Environment	version、OS、設定	変わった条件だけ比べる
First bad point	最初に期待とずれた場所	後続症状と分ける

発生頻度も記録します。常に再現するのか、同時アクセス時だけなのか、特定データだけかで、race condition、入力依存、環境依存の仮説が変わります。

症状を層ごとに分ける

同じ「画面に値が出ない」症状でも、browser state、network request、server handler、database query、permission、renderingなど原因の層は異なります。いきなり最初に見つかったfileを直すのではなく、境界ごとに観測値を集めます。

表は横にスクロールできます

観測	次に見る層	切り分ける問い
click後にeventが発生しない	UI / event handler	controlがdisabledか、handlerが紐づくか
requestが送られない	client state	validationやearly returnがあるか
4xx response	request / auth / validation	payload・identity・permissionが合うか
5xx response	server / dependency	例外、timeout、dependency状態は何か
responseは正常だが表示されない	parsing / state / rendering	response shapeとcomponent stateが一致するか
testだけ失敗	test setup / environment	mock・clock・順序・fixtureが違うか

最初に失敗する地点を見つけると、下流で出た例外をroot causeと誤認しにくくなります。たとえばAPIが正しい値を返しているなら、databaseを変更する前にclient側のparseやstate更新を確認します。

仮説は根拠と反証条件をセットにする

Agentには「最有力原因」と一緒に、根拠file、観測された事実、反証できる追加checkを出させます。原因候補を複数並べる場合も、可能性の順と、その順を決めた証拠を示させます。

このerrorを修正せず調査してください。指定のreproductionを行い、最初に期待と違う値になる境界を特定してください。原因候補を最大3つ、各候補の根拠fileと確認できた事実、候補を棄却するcheckとともに出してください。実行commandは既存testまたは安全なlocal確認だけに限定し、install、migration、外部送信、production credential利用はしないでください。最後に、原因を確定できない点を未確認として残してください。

これなら、最初の仮説が外れたときに次の調査へ移れます。Agentの説明がrepositoryにないfunctionや設定を根拠にしているなら、その仮説は採用せず、実fileを再確認します。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  Cursor

  公式サイトを見るTool詳細を見る比較を見る

Terminalで仮説を試す

Cursor Agentはterminal commandを実行できます。実行前に、READMEやpackage scriptなどからproject既存のtest、lint、typecheck、build commandを確認します。Commandがexternal serviceやreal databaseへ接続するか、fileを生成・削除するかも調べます。

小さいtestで特定のhypothesisだけを検証できるなら、全buildや大量のdebug loggingを先に実行する必要はありません。たとえばnull入力だけで落ちる仮説なら、null fixtureのunit testを作り、落ちる箇所を確認します。再現した後、最小条件を使ったregression testを追加し、修正前後の結果を比較します。

TerminalのapprovalやRun Modeはversionにより変わるため、現在のpermission設定を見ます。実行permissionがあるというだけで、依頼に含まれないdelete、deploy、migrationまで行ってよいわけではありません。

修正の大きさを原因に合わせる

root causeが分かったら、症状を隠す対処ではなく、最初に誤った状態になる経路を直します。error messageを消すためのcatchを増やす、retryを無制限にする、validationを緩める、といった修正は、失敗を見えなくして別の問題を増やすことがあります。

表は横にスクロールできます

Root cause	修正例	回帰test
invalid inputが境界で拒否されない	入力検証を追加	空値・境界値
response shapeがcaller想定と異なる	contractに合わせてparse	正常・旧shape・異常shape
permission checkがない	server側でownership確認	owner / non-owner
timeout後に二重実行	idempotencyや状態照会	timeout後再試行
state race	更新順を固定または競合制御	concurrent update
dependency outage	bounded retry / fallback	timeout・連続失敗

安全な局所patchで済まない場合は、関連するAPIやdata contractを変える前に設計上の影響を確認します。設定やschemaの変更が必要なら、症状を隠す小手先の修正で押し切らず、その変更をgateへ戻します。

同じ条件で再発を確認する

修正後は元と同じ操作、input、environmentで再現を確認します。加えて、正常ケースと境界ケースを一つずつ試し、新しいerrorやconsole warningが出ていないか見ます。既存testがあるなら同じものを再実行し、失敗が今回の差分と関係するかを切り分けます。

再現できなくなっただけでは完了とは限りません。再現手順を保存し、失敗から成功へ変わった条件、追加したtest、実行できなかったcheckを記録します。再現が不安定なら、試行回数、時間、並行数などを明記し、「直った」と断定せず不確実さを残します。

調査ログに残す情報

他の人が再開できる最小限として、reproduction steps、最初の失敗地点、採用したroot cause、根拠file、patch、test結果を書きます。logの全文や環境変数をそのまま添付する必要はありません。token、cookie、customer data、private URLなどが含まれないか、共有前に確認します。

もしAgentが複数のfileを修正した場合は、原因説明とdiffを照らし、変更fileが仮説と一致するか確認します。直接関係しないrefactorやcleanupが混ざったら、今回必要な修正から分離します。作業の最終報告は「errorが消えた」ではなく、「どの条件で起き、どの境界を直し、何で再確認したか」を示します。

AIものさしの判断

Cursorをdebugに使うときは、fix生成より再現とroot causeの確認を先にします。最初の失敗地点、証拠、反証条件をそろえて小さいtestで仮説を確かめ、原因に合った範囲だけ修正します。同じ条件で再確認し、test・diff・未確認項目を残します。error messageを貼っただけで自動修正へ進むより、回帰や副作用を見つけやすくなります。

同じ症状を再現できない場合

再現しないとき2026-10-09、修正へ進まず、発生時刻・利用者影響・環境と入力の差を記録します。直近の変更、依存version、対象dataを一つずつ比較し、必要なloggingはtokenや個人情報を除いて追加します。観測材料が足りないままroot causeを断定せず、次に取る計測を決めてから再現を試します。