Cursor 3は並列に3つのAIエージェントを起動します。こちらが、本当に機能するマルチエージェントのワークフローです。

2026年4月2日、Cursorはバージョン3.0を出荷し、「エージェントによってソフトウェアを構築するための統合ワークスペース」と呼びました。注目の機能はAgents Windowです。これはサイドバーで、あなたのすべてのリポジトリにまたがる、アクティブなエージェントセッションをローカルでもクラウドでもすべて一目で表示します。

私は過去3週間、それを実際のコードベース上で動かしてきました。これまでのどのAIコーディングツールとも体験が十分に異なるため、デモではなく、ちゃんとしたウォークスルーが必要だと感じました。実際のワークフローと、壊れやすいポイントまで含めて説明します。

TL;DR

1. Agents Windowとは実際に何か

Cursor 3より前は、ウィンドウごとに1つのエージェントセッションしかありませんでした。Cursorのウィンドウを複数開くことはできましたが、それらを統合した表示はありませんでした。Agents Windowは、すべてのアクティブなセッションを1つのサイドバーに集約することで、この問題を解決します。

Cmd+Shift+Pで開いて「Agents Window」を検索してください。そこで得られるのは、いま実行中のすべてのエージェントの一覧です。起動のきっかけとなったタスク、対象にしているリポジトリ、そしてローカルで動いているのかクラウドで動いているのかが分かります。任意のセッションをクリックすると、そのチャット履歴とファイル差分が見られ、リダイレクトもできます。

実用上の変化は「可視性」です。これまで3つのエージェントを並列に動かすには、3つのブラウザタブと大量のAlt+Tabが必要でした。今では、3行の情報を含む1つのパネルになります。

ただし、できないこともあります。エージェントの出力を自動でマージしません。同じファイルに2つのエージェントが書き込むことも防ぎません。また、セッション間の実行順序も強制しません。その調整は、相変わらずあなたの仕事です。だからこそ「機能」だけでは不十分で、ワークフローが必要になるのです。

2. 実行ターゲットが2つあることと、それぞれを使うべきタイミング

Cursor 3では、エージェントを実行できる場所が2つあります。

ローカルエージェント

ローカルエージェントは、Composer 2モデルを使って、開いているワークスペース内で動きます。ファイルシステム、ターミナル、そしてLSP（Language Server Protocol）にアクセスできます。関数をリファクタしてほしいと依頼すると、ファイルを読み、変更を書き込み、差分がすぐに見えます。プロンプトから編集までの往復は、多くのタスクで5〜15秒です。

タスクの時間が短いとき、リアルタイムで作業の様子を見たいとき、またはタスクがあなたが同時に編集しているファイルに触れるときは、ローカルエージェントを使います。Composer 2モデルは高速で、直接ファイルにアクセスできるため、あなたのワークスペース状態を最もよく理解しているモデルです。

クラウドエージェント

クラウドエージェントはCursorのインフラ上で動きます。ノートPCを閉じてもジョブは継続します。長いリファクタをキューに入れ、ふたを閉めて、4時間後にレビュー可能な状態のPRとして戻ってこられます。クラウドエージェントは、結果を検証できるようにスクリーンショットとデモ録画を生成します。

クラウドエージェントを使うべきなのは、監視したい時間よりも作業が長くなるとき、複数のリポジトリにまたがって作業しているとき、またはSlack、GitHub、Linearからトリガされる自動化を動かしているときです。Cursor Marketplaceには、外部ツールへのアクセスによってクラウドエージェントの能力を拡張するために特別に設計されたサブエージェントのプラグインも同梱されています。

ローカルとクラウドの間の引き継ぎは双方向です。ローカルで何かを始めて、スコープが広がったと気づいたらクラウドに引き渡す。または、クラウドの結果をローカルセッションに取り戻して、LSPの文脈を使った最終的な後片付けを行うこともできます。

3. 実例：3つのエージェントに分割したリファクタリングのパイプライン

以下は先週私が実際に行った分割です。あるサービスで、ログを構造化JSONに置き換え、エラーハンドリングを標準化し、テストカバレッジを埋める必要がありました。触るファイルの重なりはほとんどない、3つの明確に分かれた作業です。

設定

# ブランチ競合を避けるため、エージェントごとにワークツリーを作成
git worktree add ../refactor-logging feature/structured-logging
git worktree add ../refactor-errors feature/error-handling
git worktree add ../refactor-tests feature/test-coverage

Git worktreeは、それぞれのエージェントに対して、別々のブランチ上で個別の作業ディレクトリを与えます。エージェントは作業ツリーを共有しないため、ファイルレベルでの書き込み競合はありません。Agents Windowでは、3つすべてが同じサイドバーに表示され続けます。

プロンプトの構造

各エージェントには、スコープ付きのプロンプトを与えます。ログのエージェント：

src/services/ のすべての console.log および console.error 呼び出しを
src/lib/logger.ts の構造化ロガーに置き換えてください。出力は
フィールド: level, message, context を持つ JSON にしてください。
関数シグネチャは変更しないでください。
テストファイルには触れないでください。

エラーのエージェント：

src/services/ にあるすべての try/catch ブロックを、
src/errors/app-error.ts の AppError クラスを使うように標準化してください。
原因（cause）プロパティとして元のエラーを添えて再スローしてください。
ログ出力の呼び出しは変更しないでください。
テストファイルには触れないでください。

テストのエージェント：

Vitest を使って src/services/ の不足しているユニットテストを追加してください。
添付の lcov.info に基づき、最もカバレッジが低い3つのエクスポート済み関数を
対象にしてください。
ソースファイルは編集しないでください。

最初の2つのプロンプトにある「テストファイルには触れないでください」という制約は、任意ではありません。これがないと、エージェントは共有ファイルに触れる方向に流れてしまい、結果として3つのエージェントがそれぞれ src/lib/logger.ts を自分たちのものだと思ってしまいます。

Agents Windowでの監視

3つのエージェントをすべて動かしていると、Agents Windowには各セッションの現在のファイルと、最後に行ったアクションが表示されます。実行をずっと見ているわけではありません。10分おきに戻ってきて、どれかが黙ってしまっていないか、あるいはスコープ外の明らかにおかしな選択をしていないかを確認します。

最もよくある失敗パターンは、エージェントが1つのサブタスクを終えたあと、そのスコープ外の隣接ファイルに対して「改善」を始めてしまうことです。これは早めに捕まえます。各セッションのタブ内にある差分ビューには、エージェントがコミットのためにキューに入れたファイルがはっきり表示されます。

結果のマージ

各エージェントは自分専用のブランチで実行します。3つすべてが完了したら、マージの順番が重要です。ログの変更を最初にマージします。なぜなら、エラーハンドリングはロガーが正しいことに依存するからです。次にエラーハンドリング。そして最後にテストです。テストは両方を実際に動かすからです。

git checkout main
git merge feature/structured-logging
git merge feature/error-handling
git merge feature/test-coverage

最後のマージの後だけでなく、各マージの後にテストスイートを実行してください。テストのマージが失敗した場合、どちらの直前のマージによって問題が導入されたのかを知りたいからです。

4. オーケストレーションの落とし穴

並列エージェントは、状態を共有しないタスクでは逐次エージェントよりも高速です。しかし、単一エージェントのセッションでは回避できる3種類の失敗を導入します。

ファイル競合

2人のエージェントが同じファイルに同時に書き込むと、どちらも気づかないマージ競合が発生します。唯一信頼できる予防はプロンプトのスコープ設計です。各エージェントに「自分が所有するディレクトリの明示的なリスト」と「触ってはいけないディレクトリの明示的なリスト」を渡してください。ワークツリーはファイルシステムレベルでは役に立ちますが、別ブランチ上で2人のエージェントが同じパスを編集すること自体は防げません。

これを省略して競合が起きてしまった場合、3人目のエージェントに解決させないでください。マージ競合は手動で解決します。3-wayコンフリクトを正しく解決するのにエージェントが必要とするコンテキストは、役立つプロンプトに収まることが多くありません。

ブランチの分岐

十分長く動作するエージェントは、手動でリベースが必要な形でメインから分岐し始めます。月曜の朝に開始した4時間のクラウドエージェントジョブは、見ていない12件のコミットを含むメインブランチに戻ってくるかもしれません。特にアクティブなリポジトリでは、マージ前のリベースに充てる時間を見積もってください。

# どのエージェントブランチでもマージする前にリベースする
git checkout feature/structured-logging
git rebase main
# 競合を解決してからマージ

コストの上限

3人のエージェントが並列で動くと、1人の場合よりもトークンを3倍の速さで消費します。ローカルエージェントはCursorのサブスクリプション割り当てを使います。Cursorはクラウドエージェントの計算時間について、パブリックなドキュメントには少なくとも執筆時点で1分あたりのレートが見当たらないにもかかわらず、クラウドエージェントを別途課金します。初回実行の各エージェントについては、2時間未満で完了するスコープを設定してください。これらの実行から実際のトークンと時間のコストを学べるので、その後はより長いジョブを調整できます。

Agents Window（エージェントウィンドウ）には、バージョン3.4ではセッションごとの内蔵コスト表示がありません。アカウント設定で総利用量が確認できます。セッションごとのコスト可視性が必要なら、タスク開始時刻をログに残し、セッション終了後にアカウント利用状況を確認してください。

結論

Agents Windowは魔法ではありません。これは、並列作業のための調整面（コーディネーションの窓口）として扱うべきで、設計は依然としてあなたが行う必要があります。実際に私のところでうまくいったルールはこれです。各エージェントを「渡したファイルだけを読むプルリクエストのレビュー担当者」のように扱ってください。スコープ、ブランチ、もう一度スコープ、そして実行。

本当の利得は、1つのタスクのスピードではありません。以前は3回の逐次的な午後で終わっていた3つの独立したジョブが、1回で済むようになることが利得です。オーケストレーションの手間は確かにありますが、適切な種類の作業に対しては3倍の速度で回収できます。

あなたはどんな種類のタスクをエージェント間で分割していますか？最初の90分のコメントスレッドからは、私がまだ試していないアプローチがたいてい出てきます。あなたの案を下に貼ってください。

GDS K S · thegdsks.com · Xでフォロー @thegdsks

並列エージェントは、エージェント同士の「つなぎ目（seams）」を設計したときに限り速くなります。