Cursor 3.3 が PR レビュー機能を統合、計画を並列で動かす「Build in Parallel」も追加
Cursor の中で、PR レビューが完結するようになった。
Cursor が 2026 年 5 月 7 日、Cursor 3.3 のリリースで PR Review タブ・Build in Parallel・Split PRs の 3 機能を一気に投入した。コードを書く画面と、レビューする画面と、計画を回す画面が、IDE 内に並ぶ。
何が起きたか
Cursor の Changelog 5/7 付けによると、PR Review は Reviews / Commits / Changes の 3 タブ構成で動く。Reviews タブはインラインのレビュースレッドと PR 全体コメントを束ねて見せる。Commits タブは PR に紐付くコミット履歴専用ビュー。Changes タブはファイルツリーと「変更ピッカー」で、大きな PR を辿りやすくする作り。レビュアーのステータスや「pending review」のバナーも IDE 内に出る。
並行して、Build in Parallel が入った。プランの中で依存関係のないステップを切り分け、async サブエージェントが同時に走る。依存があるステップは順序を維持、と公式は書いている。Split PRs は multitask 中の変更を論理単位で切り分けて独立 PR 化 する Quick Action。スナップショットを先に取り、分割案を提示してから承認を待つ流れ。
誰に関係あるか
Cursor を主力 IDE にしているチームと、PR レビューと実装の往復で時間を使っている開発者。とりわけ、複数プランを同時に走らせている使い方をしてきた人にとって、Split PRs は「まとめてコミットされて PR が肥大化する」問題を直しに来た機能と読める。
問題はここで、Cursor 標準の Review 機能が増えたぶん、GitHub 側の Code Review との棲み分け が現場ごとに発生する。GitHub Actions / CODEOWNERS / Required reviewers と並行運用する場合、IDE 内 Review はあくまで「下書き／一次確認」に留めて、Approve は GitHub 側で出す、といった運用ルールを先に決めたほうがいい。
数字で整理
Improvements / Bug Fixes は changelog 上で 6 件 / 5 件 と整理されている。注目したのは次の 4 つ。
- Explore サブエージェント: 設定から動作を制御可能。Explore 専用のモデル指定、親エージェントと同じモデル継承、無効化のいずれかを選べる
- モデルエイリアス:
model: opusのように一般名を指定すると最新の Opus 系モデルを自動追従 /multitask: エディタ内から async サブエージェントを発火するスラッシュコマンドが正式に- MCP 周り: 接続挙動が予測可能に整理、再認証時に古いトークンを明示的にクリーンアップ
Bug Fixes 側ではターミナル操作のショートカット、MCP の transient 401 ハンドリング、マルチリポ環境のキャッシュ不整合といった、現場で踏みやすかった部分が直っている。
見落としがちだけど
Cursor 内に Review が増えた、というニュースは、裏返すと レビュー情報の取り扱い確認が必要になる という運用変化でもあります。社内コードを Cursor に流す前段で、すでに DLP / SOC2 系のガバナンスを整えているチームは、PR Review タブが踏むネットワーク経路や保管範囲を、Cursor 公式の Security ページと自社方針で再点検しておきたい。3.3 の changelog 自体は機能追加の告知に留まるので、この段落は「運用上の確認ポイント」として読むのが妥当です。
並列実行（Build in Parallel）も、依存推定がうまくいかなかった場合に 「独立だと判定したのに実は同じファイルを編集する」 ケースが理屈上ありうる。リリース直後はクリティカルパス（DB マイグレーション、認証周り）の変更を含むプランは、まず Run Sequential で従来通りに回すのが規制の文脈で言うと無難に見える。
注意点
3.3 の更新範囲（Stable に降りているか、Beta だけか）は changelog 本文には明記されていない。普段使いの Cursor が更新通知を出すかどうかで体感が変わる。5/7 付けの公式情報から確認できるのは「機能は出した」までで、自社チームに展開する前にはアプリ更新と動作の素振りを済ませたい。
で、どうする
PR Review タブと Build in Parallel は、まず個人ブランチでひと通り触って、Explore サブエージェントの挙動とモデルエイリアスを自分のリポジトリで確認する流れが安全。レビュー運用は GitHub 側 Approve とのダブルトラックにして、慣れたら IDE 内コメントの位置付けを社内ドキュメントに書き留めておく。Cursor 周りの動向は今後も追っておきたい。
