CursorのReviewに古い差分が残るときはKeep Allで確定する

PRをマージしたはずなのに、Cursorの「Review」パネルに古い差分がいつまでも表示され続けて戸惑った経験はないでしょうか。git側では特に問題が見当たらないだけに、「何が残っているのか分からない」という不安につながりやすい状況です。

この記事では、Review欄に旧diffが残る原因と、Keep Allで確定して解消する手順を、実際に確認した範囲で整理します。

今日の結論

• CursorのReviewはgit（HEAD/working tree）ではなく、Keepで確定するまで前進しない独自のbaselineを基準に差分を表示している
• commit・PR・マージをしても、旧diffは自動では消えない
• まずgit status -sbでgit側が正常か（未コミットが当日分のみか）を切り分ける
• ReviewパネルでKeep Allを実行するとbaselineが前進し、旧diffが消える
• PRマージ後の締め作業に「Keep Allで確定」を組み込むと、次バッチへの持ち越しを防げる

筆者は2026年7月19日16時30分台から17時ごろにかけて、PRマージ後もReviewパネルに旧diffが残る状況を実際に確認しました。手元のCursorバージョンは記録していなかったため、バージョン差による挙動の違いは未検証です。

なぜCursorのReviewに古い差分が残るのか

原因は単純。Reviewパネルが見ているのはgitの状態そのものではなく、Cursor側が内部的に保持しているbaseline判定です。

このbaselineは、ユーザーがReviewパネルでKeep（またはKeep All）を実行して初めて前進する仕組みになっています。そのため、以下のような操作をしても、Review欄の表示には反映されません。

• ローカルでcommitする
• リモートにpushする
• GitHub側でPRをマージする

git的には作業が完了していても、Cursorのレビュー基準は別軸で管理されているというのが実測した範囲での理解です。公式ドキュメントに明記された仕様は確認できていないため、将来的に挙動が変わる可能性はあります。

git側の状態を先に確認する

Review欄の表示だけを見て「差分が消えない」と判断する前に、git側の状態を確認しておくと切り分けが早くなります。

1. ターミナルでgit status -sbを実行する
2. main...origin/mainが同期しているか確認する
3. 表示された未コミットの変更が、当日作業した分だけかを確認する

ここでgit側に不整合がなければ、原因はgitではなくReviewパネルの表示（baseline）側にあると判断できます。逆にgit側にも差分がある場合は、Cursorの問題ではなく通常のgit運用の見直しが必要です。

Reviewパネルで Keep All を実行する

git側の状態を確認できたら、Reviewパネルの操作に進みます。

1. Cursorの Review パネルを開く
2. 残っている差分の一覧を確認する
3. Keep All を実行し、baselineを現在の状態まで前進させる

Keep Allを実行すると、それまで残っていた旧diffがReview欄から消えます。個別にKeepしていく方法もありますが、PRマージ直後のようにまとめて確定したい場面ではKeep Allの方が早く終わります。

再発を防ぐ運用チェックリスト

一度Keep Allで解消しても、次のPRマージ時に同じ現象が起きることがあります。マージ後の締め作業に次のチェックを組み込んでおくと、旧diffの持ち越しを防ぎやすくなります。

まとめ・次に読む

CursorのReviewパネルに残る古い差分は、git側の問題ではなく、Keepで確定するまで前進しない独自のbaselineによるものでした。commit・push・PRマージだけでは解消しないため、マージ後の締め作業にKeep Allを組み込んでおくと安心です。

Cursorの運用まわりは、無料版の実測を含めてHubにまとめています。あわせて確認してみてください。

• Cursor 無料版シリーズ Hub
• 本命CV記事の点検は3本メモと最小改善1本で回す

---

本記事の内容は2026年7月21日時点の情報です（実測は2026年7月19日）。この挙動はCursor公式ドキュメントに明記が見当たらず、仕様変更やバージョンによる差異の可能性があります。重要な判断をする前には、最新のCursor公式ドキュメントもあわせて確認してください。