Cursor 3.3 — 「PR レビュー待ち」と「エージェント順番待ち」がなくなった日

「PR レビュー待ち」の終わり — Cursor 3.3 が IDE 内でプルリクエストを完結させる仕組みと、コンテキストスイッチがエンジニアの生産性に与える見えないコストを理解する

Cursor 3.3 がリリースした PR レビュー体験の新インターフェースは、これまで GitHub のブラウザ画面とエディタを往復していたコンテキストスイッチを削除する設計だ。公式リリースは forum.cursor.com に掲載されている（ https://forum.cursor.com/t/pr-review-build-plan-in-parallel-and-split-prs/160035 ）。

新しいインターフェースは Reviews タブ・Commits タブ・Changes タブの 3 つに整理された。Reviews タブでは他のメンバーからのコメントをリスト表示し、エディタを離れずに確認・返信できる。Commits タブでは PR に含まれるコミット履歴を時系列で参照でき、Changes タブでは差分全体をファイルツリー形式で俯瞰できる仕組みだ。

これにより、PR にコメントが付いた際に「GitHub を開く → 確認する → 修正する → エディタに戻る」という往復が不要になる。コメントを確認しながら同じ画面でコードを修正し、そのままコミットして返信するという一連の操作がエディタ内で完結する。

コンテキストスイッチには数値に表れない損失がある。ブラウザを開く動作だけでも注意は一時的に中断され、作業の深度が下がる。複数の PR を並行管理している場合や、レビューコメントへの対応と機能開発を同時進行している場合、このスイッチは一日に数十回発生する。Cursor 3.3 の PR 統合は、その一つひとつを削除することで実稼働時間を積み上げる設計だ。

レビューコメントを起点に修正・コミットまでを IDE 内で完結させる操作の流れを把握し、ブラウザ往復ゼロの開発スタイルに移行する

PR 統合に加えて、Cursor 3.3 はエージェントによるレビュー対応の自動化素地も強化している。レビューコメントの内容をエージェントに渡して修正案を生成させ、Changes タブで差分を確認した上でコミットするフローが最小限の操作数で完結する。

レビューコメントへの返信文もエディタ内から送信できる。PR レビューを起点とした作業サイクル全体が IDE に収まるようになったことで、リモートチームやレビュー待ち時間が長い開発環境では特に恩恵が大きい。コメントが届いた瞬間から対応が完了するまでのリードタイムが短縮されるだけでなく、他のタスクを中断して別画面に移動する精神的負荷も削減される。定常的に複数 PR を並行管理しているエンジニアにとっては、この変更が一日の作業の流れそのものを変える可能性がある。

Build in Parallel — 並列エージェントで「一度に一タスク」の制約がなくなり、エンジニアはエージェントの処理を待たずに複数の作業を同時に前進させられるようになる

Cursor 3.3 の二つ目の核心機能が「Build in Parallel」（並列エージェント実行）だ。これまで AI エージェントに作業を依頼した場合、そのエージェントが処理を完了するまで次のタスクを起動できなかった。Cursor 3.3 はこの制約を取り除く。

「Build in Parallel」ボタンを押すと、現在進行中のプランとは独立した非同期サブエージェントが起動する。サブエージェントはバックグラウンドで動作し、メインエージェントの処理を待たずに別のタスクを並行して実行できる。開発者はエージェントの処理中に別の作業に集中でき、複数のタスクを同時に前進させられるようになる。

具体的なシナリオで考えると影響がわかりやすい。機能 A のバグ修正をメインエージェントに依頼しながら、機能 B のリファクタリングを並列エージェントに同時依頼する。どちらも処理中に、開発者は別の設計作業や仕様確認に集中できる。従来は「エージェントが終わるまで待つ」という受け身の状態になっていたが、並列実行により能動的に複数タスクを前進させる使い方が現実になった。

これはエンジニアの生産性に対して乗数的に作用する。エージェントが処理する時間は変わらないが、人間がその時間を別の有益な作業に使えるようになる。エージェントの使用回数を増やしつつ並列に投資できるため、実稼働時間あたりのアウトプット密度が上がる。

クイックアクションのピン留めで頻用コマンドへのアクセスを最短化し、並列実行のたびに生じる操作コストをゼロに近づける

同アップデートで、よく使うクイックアクションをピン留めできる機能も追加された。一見小さな変更だが、繰り返し使うコマンドへのアクセスが加速する点でストレスを削減する。並列エージェントの起動、PR レビューの開始、特定エージェントモードへの切り替えなど、日常的な操作を最小クリックで呼び出せるようになる。小さな摩擦の積み重ねが集中の妨げになるという観点では、ピン留め機能は並列エージェントや PR 統合と同じく「待ち時間をなくす」文脈に位置する改善だ。頻用コマンドをピン留めしておくことで、並列エージェントを複数起動する際の操作が体に馴染みやすくなる。

/multitask と PR 分割 — 大規模変更を複数の独立した単位に分けて並走させることで、PR レビューの品質と速度を同時に引き上げ、技術的負債対応への心理的抵抗を取り除く

Cursor 3.3 は /multitask コマンドも新たに提供した。このコマンドは単一の大きなタスクを複数の独立したサブタスクに分割し、それぞれを並列エージェントに割り当てる機能だ。

大規模なリファクタリングや依存関係の更新作業では、変更の影響範囲が広くなる。単一の PR に多くの変更が含まれると、レビュー負荷が上がり、マージのリスクも増える。/multitask を使うと、大きな変更を意味的に独立した複数の単位に分割できる。それぞれが独立したサブエージェントで処理されるため、全体の完了時間も短縮できる。

さらに、変更を PR に分割する機能も Cursor 3.3 で加わった。/multitask で生成した複数のサブタスクをそれぞれ独立した PR として送信することで、レビュアーは小さく整理された差分を確認できる。一本の大きな PR よりも、複数の小さな PR に分割した方がレビュー品質と速度の両方が上がることは多くのチームが経験的に知っている。それを自動化するのが今回の PR 分割機能の役割だ。

実践例 — 横断的リファクタリングを /multitask で並走させ、モジュール単位の PR に分割して提出すると何が変わるかを具体的に確認する

たとえば「全モジュールの型定義を整備し、関数の命名規約を統一する」という横断的なリファクタリングを考える。従来は単一エージェントが順番に各ファイルを処理し、最終的に一つの巨大な PR になりがちだった。レビュアーは変更の全体像を把握するために長い時間をかけ、問題があっても切り戻しの範囲が広くなる。

Cursor 3.3 では /multitask でモジュールごとにサブタスクを分割し、並列エージェントがそれぞれを並行処理する。完了後は PR 分割機能でモジュールごとの独立した PR として提出できる。レビュアーはモジュール単位で確認・承認でき、問題が発生した際の切り戻し範囲も限定できる。

この変更がもたらす最も重要な効果は「大きい作業を避けたくなる心理的抵抗」の解消だ。変更範囲が大きいほど PR の作成とレビューが億劫になるバイアスが、技術的負債対応を後回しにさせる原因のひとつだ。分割と並列化を自動化することで、このバイアスが弱まり、大きな改善作業に着手しやすくなる。

今週の AI IDE 動向まとめ — OpenAI Codex Chrome 拡張でブラウザ自律操作が現実化し、Windsurf が Devin Review を全ユーザーに開放、AI コーディングツール全体が同時に前進した週

Cursor 3.3 が今週最注目の動きだが、同週には他の AI コーディングツールでも重要なアップデートが重なった。主要なものを整理する。

OpenAI Codex Chrome 拡張（2026-05-07 公開）

OpenAI が Codex の Chrome 拡張を正式公開した（ https://chromewebstore.google.com/detail/codex/hehggadaopoacecdllhhajmbjkdcmajg ）。Codex がタスク専用のタブグループ内でブラウザを操作し、複数タブのコンテキスト収集・開発者ツールの参照・フォーム入力・ダッシュボード確認などをユーザーのブラウジングを妨げずに実行できる。センシティブな操作については事前に確認を挟む設計だ。EU・UK では現時点で提供されていないが、日本は提供対象リージョンに含まれており、macOS と Windows の Codex アプリから有効化できる（ https://dataconomy.com/2026/05/08/openai-launches-codex-extension-for-google-chrome/ ）。

ブラウザ操作とコード編集の融合は、Web アプリの動作確認やステージング環境でのテスト実行を Codex に委任できる範囲を大幅に広げる。これまでコーディングエージェントが関与できなかった「ブラウザを使う手動作業」の一部が、エージェントの守備範囲に入り始めた。

OpenAI Codex CLI v0.129.0 / v0.130.0 正式リリース

同週には Codex CLI の正式版も相次いで公開された（ https://github.com/openai/codex/releases ）。v0.129.0（5 月 7 日）では TUI コンポーザーに Modal Vim 編集が追加され、Vim キーバインドに慣れた開発者の操作性が向上した。Linux 向けには Bubblewrap を使った sandbox フォールバックも含まれ、セキュリティ意識の高い環境での信頼性が上がった。v0.130.0（5 月 8 日）では新コマンド codex remote-control によるヘッドレスサーバーの遠隔起動が加わり、外部ツールから Codex を操作する自動化シナリオが公式サポートされた（ https://github.com/openai/codex/releases/tag/rust-v0.130.0 ）。

Windsurf v2.2.17 — Devin Review と Quick Review を全サブスクリプションユーザーに開放

Windsurf v2.2.17 では、これまで上位プランのユーザーだけが利用できていた Devin Review と Quick Review が、全サブスクリプションユーザーへ追加料金なしで開放された（ https://releasebot.io/updates/windsurf ）。既存の契約内容のまま AI コードレビュー機能が使えるようになる点が注目される。Agent Inbox にリスト表示オプションが追加され、セッションのソートとフィルタリングも改善された。Windows 環境での更新ブロック不具合と一部 MCP サーバーの問題も修正されている。有料プランを契約済みの Windsurf ユーザーであれば、設定変更なしに今日から Devin Review を試せる。

今すぐ確認すべきこと — Cursor 3.3 の取得と並列エージェント・PR 統合を実際に動かすための初期手順と、エージェント使用量拡大の確認方法

Cursor 3.3 はすでにリリース済みであり、既存ユーザーはアプリを開くか公式サイト（ https://cursor.com/changelog ）から最新版を確認できる。アップデートを取得した後、以下の手順で新機能を動かせる。

PR レビュー機能の確認は、エディタのサイドパネルから「Reviews」タブを開くことで始まる。連携済みのリポジトリがあれば、未対応のレビューコメントが一覧で表示される。コメントを選択すると対応するコードの差分がエディタ内に表示され、その場で修正とコミットを行える。初回確認として今進行中の PR が 1 件あれば十分で、実際の作業に即して操作感を確かめるのが最も速い習得方法になる。

「Build in Parallel」はエージェントにタスクを依頼した後に表示されるコントロール内のボタンから有効化できる。初回は挙動を確認するために、小さな独立したタスクで試すのが適切だ。メインエージェントとサブエージェントが並行して動く状態を一度確認した上で、本番の作業に適用していくと混乱なく移行できる。

/multitask コマンドはコマンドパレットから入力できる。タスクの説明を入力すると、Cursor がサブタスクへの分割案を提示する。分割案を確認・調整した上で実行することで、並列処理の精度が上がる。初回は大きすぎないリファクタリング対象で試して、エージェントの分割粒度が自分の作業スタイルと合っているかを確かめてから本格適用すると良い。

Cursor のエージェント使用量大幅拡大と Composer 1.5 の個人プラン導入も同時確認し、並列実行の枠を最大限に活用する

同週には Cursor のエージェント使用量の大幅引き上げも発表された（ https://cursor.com/blog/increased-agent-usage ）。Pro・Pro+・Ultra プランの使用量が増量され、Auto + Composer 用と API 用の 2 プールに分離することでモデル切り替えの柔軟性も確保された。並列エージェントを積極的に使っても月次の枠が従来より圧迫されにくくなる点は、「Build in Parallel」の実用性を直接高める。使用量を気にして並列化を手控えるシナリオが減り、「試してから判断する」という使い方がしやすくなった。

自社トレーニングモデル「Composer 1.5」も個人プランに導入された。Terminal-Bench 2.0 でのスコア評価ではフロンティアモデルと競合する結果が報告されており、Composer 1 比較で 3 倍の使用枠が割り当てられている。コスト効率を意識する場面では Composer 1.5 を選択するという判断軸が個人プランのユーザーにも加わった。

Cursor 3.3 は「エージェントの機能が増えた」だけでなく、エンジニアの待ち時間を具体的に削減する設計で構成されている。PR レビューの IDE 内完結と並列エージェント実行という組み合わせは、個々のエンジニアの実稼働時間密度を引き上げる変化だ。どちらか一方でも有意なアップデートだが、同じリリースで両方が届いた点が今週を際立たせる。同週には OpenAI Codex Chrome 拡張や Windsurf の全員開放など、AI コーディングツール全体が一斉に前進した週でもあった。今のうちに Cursor 3.3 を取得して新機能を試しておくことが、来週以降の作業密度に直結する。