分離できていない？並列開発で感じた VS Code と Cursor の違い

エージェントへ仕事を渡したあと、終わるまで待っていませんか。
待ってしまっているなら、実装速度は上がっても、開発の流れは直列のままです。

複数のエージェントを動かせることと、人間を含めて並列に開発できることは同じではありません。

仕事をエージェントへ切り出して管理する開発と、人間自身も IDE の中に残り、複数のエージェントと同時に作業する開発では、求められる仕組みが違います。

この記事では後者を前提に、並列開発で IDE に何が分離されている必要があるのかを、VS Code と Cursor での実務上の経験から、その課題を整理しています。

私は Cursor ユーザー

私は普段、Mac で Cursor を使っています。Codex も、作業によって補助的に、あるいはメインで利用しています。（最近は、Orca が気になっています。）

仕事を小さく分けて複数のエージェントに渡し、その間に自分も別の作業をどんどん進める。結果の通知が来たらレビューして、必要なものを取り込む。気に入らなければやり直し。人間も分業の中に入る、ヒューマン・イン・ザ・ループの並列開発です。

たとえば、Web サイトのヘッダーを実装するとします。

作業者	担当
Human	Header 全体を確認し、統合
Agent A	Nav を実装
Agent B	SearchBar を実装
Agent C	変更内容をレビュー

以下は、ヘッダーのファイル構成例です。

Header
├── Logo
├── Nav              <-- Agent A が実装する
├── SearchBar        <-- Agent B が実装する
├── ...

ヘッダー全体を一つのエージェントへ任せるのではなく、独立して実装できる単位ごとにチャットを分けます。コミット用、リファクタリング用など、チャットを別に作ることが多いです。

基本的に、単一のチャットセッションを長く使い続けることはありません。入力した内容と関係のない解釈が生じたり、その解釈や誤った推論のためのトークン消費を抑えるためです。エージェントは多いようですが、複数のエージェントが常時動いているわけではなく、新しいエージェントへ新しい仕事を依頼しています。

Agent A が動いている間に Agent B へ指示を出し、自分は Header.tsx を確認する。終了を待ってから、次の仕事を始めるわけではありません。

五つの開発の進め方

記事投稿時点の開発を、次の五つのスタイルで考えています。

スタイル	開発の進め方
一、	人間だけでコードを書く
二、	人間がコードを書き、AI が補完する
三、	エージェントがコードを書くが、人間は終了を待つ
四、	人間と複数のエージェントが仕事を分け、同時に進める
五、	Issue やタスク、Slack のメッセージなどを起点にクラウド上のエージェントが動き、人間または他のエージェントがレビューする

三番目では、その都度のプロンプトで進めることが多く、AGENTS.md などの指示ファイルは必須ではありません。

2026年に入ってから、私にとっては四番目が普通になりました。この段階になると、毎回のプロンプトだけでは足りません。AGENTS.md で開発上の前提やルールを共有し、Skills で作業手順を使い回せるようにしておく必要が出てきます。

五番目のスタイルでは、人間は、すべての実装を自分で始める人から、仕事を分け、進捗を見て、判断する側へ移っていきます。(私も早くプロジェクト管理ツールの Linear や Jira などを使って、IDE／ADE と連携した業務を行っていきたいです。)

ChatGPT の Codex アプリも、複数のエージェントへ別々の仕事を渡し、並行して進めるためのインターフェース設計のように思います。仕事でのタスクと、プライベートなタスクを、同一のアプリケーションで分けて行うことが、当然の利用方法です。

つまり、複数のエージェントへ仕事を分け、その間に別々の仕事を進めること自体は、特別な使い方ではなくなりつつあります。

組織管理されたリポジトリでは、自由にブランチを増やせない

組織で管理されたリポジトリでは、担当するブランチやマージのルールが決められていることも珍しくありません。個人の作業者が、エージェントごとにブランチや worktree をいくつも作り、自由に統合できるとは限りません。

今回使ったのも、セキュリティ管理の厳しい業務環境です。

支給された Windows で、VS Code (Version: 1.136, 1.137, 1.138) と GitHub Copilot の Business プランを使う機会がありました。

モデルは主要なものが一通り使え、自動モードのほか、GPT-5.6 Luna と Terra を主に、Claude Sonnet 5、Grok 4.6 などを選択して利用しました。

VS Code には、Agents Window と worktree を使って作業単位を分離する手段もあります。今回は、業務上の制約からその運用を前提にできなかったため、同一ワークスペース上の Chat view（サイドバーのチャット画面）で、どこまで並列に進められるかを見ています。

この記事で扱っているのは、Nav や SearchBar のような数十分から数時間で終わる日常的なフロントエンド実装です。作業ごとに別の環境を作るのではなく、普段の IDE 上で、人間と複数のエージェントがそのまま並行して作業できるかをテーマにしています。

レガシーな開発環境から移行した VS Code + GitHub Copilot で、普段 Cursor で行っているように、作業ごとにチャットを分け、複数のエージェントへ仕事を渡す並列開発を試してみました。

VS Code でも Cursor と同じように進めてみた

VS Code でも、複数のチャットセッションをタブで管理できるので、最初は Cursor と同じように使えるだろうと思っていました。

VS Code も、複数のセッションを並行して扱う方向へ進んでいます。しかし、私の感覚では、丁寧に会話を分けても、エディターの状態やターミナルのイベントまで分離されているとは感じられませんでした。少し使っただけで、何度も手が止まりました。

利用した GPT-5.6 は、Cursor、Codex でも使い慣れたモデルです。ただし、同じ名称のモデルでも、製品側のインストラクション、モデルへ渡されるコンテキスト、利用できるツールが異なれば、同じようには動きません。今回問題だったのは、モデルの性能ではなく、ツール側の振る舞いです。

一つのエージェントが動いている間に、私が別の仕事を進めたり、別のエージェントへ別ファイルの変更作業を頼んだりすると、その変更が、同一ワークスペース上の変化として稼働中のエージェントからも見え、実行中にそれを異常として扱い、脱線してしまう、という印象でした。

開いているファイルが、意図せずコンテキストになる

サイドバーのチャットからエージェントへ指示を送るとき、明示的に指定したファイルだけでなく、その時点で開いているファイルや選択範囲などの情報も、暗黙のコンテキストとして扱われることがあります。

一つのチャットで、開いているファイルについて質問するなら、それは自然ですが、メッセージ入力画面の表示が残り、含まれているのかどうなのか、分かりづらい UI です。

README.md を開いている状態で、AGENTS.md について質問する様子。README が選択されているのか分かりづらい UI。

画像は、README の例ですが、私が使用した環境では、チャットで Nav.tsx を指定して会話が続いているのに、送信時点のフォーカスが SearchBar.tsx だと、そのファイルがコンテキストに入り、エージェントは良かれと考えて SearchBar.tsx も変更する可能性があります。

作業者	いまやっていること
Agent A	Nav.tsx を実装中
Agent B	SearchBar.tsx を実装中
自分	Header.tsx を確認中

「いまエディターで開いているファイル」が強いコンテキストとして扱われると、人間の仕事とエージェントの仕事が混ざります。

2026年5月12日に作成された VS Code Issue #316051 では、複数の Copilot Chat セッションを使った際、一方のセッションへ別の作業で開いていたファイルの editorContext が入る問題が報告されています。

Session A では page-01.html、Session B では page-02.html を扱ったあと、Session A に戻って Add footer. と送ると、リクエストには page-02.html の情報が含まれ、そちらが編集されました。

チャットを分けたつもりでも、人間が現在見ているものが別のセッションへ影響する。

そうなると、一つのエージェントを動かしながら自分が別のファイルを見ることにも気を使います。

プロンプトで指定した位置と、実際に編集された位置がズレる

似たことは、コードの編集位置でもありました。

一つ目は、HTML の、上から 3 番目のセクションの末尾にある L282 （ファイルの行番号）を指定したところ、次の 4 番目のセクションが編集されたケースです。

二つ目は、メインビジュアル内の CTA がある L97 を指定したところ、L108 にある固定表示の CTA が編集されたケースです。同じページに似た役割の要素がありましたが、指示した対象とは異なります。

どちらも、行番号だけではなく、セクションや要素の役割も伝えていました。それでも別の場所が編集され、編集後に対象を指定し修正する必要がありました。

これとは別に、2026年4月10日に作成された Issue #308933 では、エディターで選択している行番号と、チャットの editorContext.selection に渡される行番号が一致しない事例が報告されています。私が経験した二つのケースと同じ原因かは確認できていません。

並列に仕事を進めていると、一つのチャットへ戻るたびに、指定した対象が編集されているかを確認し直す必要があります。人間が明示した位置と、実際に編集された位置を区別して正しく伝わらない、エージェントの認識を信頼できないことが、作業の負担になりました。

関係のないターミナル操作で、過去のチャットが再開した

VS Code のターミナルウィンドウで、npm run dev を自分でタイプして、実行した直後、以前のエージェントチャットが再開し、環境ファイルを変更したことがありました。サイドバーのチャットから新しい指示は送っていません。このとき確認した内容は、別の記事にまとめています。

複数エージェントが並列実行できること、並列開発できることは違う

複数のエージェントが同時に動いているだけなら、エージェントの並列実行です。

私がしたいのは、その間に人間も別の仕事をすることです。

作業者	担当
自分	Header 全体を確認する
Agent A	Nav を実装する
Agent B	SearchBar を実装する

並列開発では、次の五つが分かれている必要があります。

分離するもの	分かれていないと起きること
会話	別の仕事の履歴や指示が影響する
コンテキスト	開いているファイルや選択範囲が、意図しない仕事へ入る
実行環境	ファイルやプロセスを、人間とエージェントが取り合う
イベント	ターミナルの終了などが、関係のないチャットを動かす
変更	誰が何を変更したのか分からなくなる

ところが、どのファイルがエージェントへ渡されるコンテキストに入り、どの変更をエージェントが自分の仕事として扱い、どのイベントで再び動くのかが読めない。

そうすると、一つのエージェントが作業している間に、自分が別のファイルを変更するのが怖くなります。

実際には、次のような進め方になりました。

複数のエージェントを起動できていても、人間が「今は触らない」と手を止めることで排他制御している。

人間が mutex、つまり作業同士がぶつからないように、一つずつ順番に進める役になっています。

これでは、エージェントがコードを書く速度は上がっても、開発全体は直列のままです。

VS Code ではまた、エージェントの作業が終わると、私が別のファイルを編集していても、変更されたファイルの変更箇所へ、エディターがジャンプします。自分がコードを書いている最中に、表示がそちらへジャンプするのがストレスになります。

Cursor のインライン参照

Cursor では、選択したコードやファイル、フォルダへの参照を、プロンプトの文章中へそのまま挿入できます。「この範囲とこの範囲を、このフォルダへ移し、利用方法をこの範囲へ追記する」のように、参照同士の関係を文章として組み立てられます。

VS Code でも複数の選択範囲をコンテキストへ追加できますが、同じように行うと、それらは入力欄とは別の添付ファイルとして並びます。何をどの役割で参照しているのかを文章中に、会話文の中で対応付けにくく、ファイルパスや行番号を改めて書くことが増えました。

Cursor 型なら、[A] と [B] を [C] へ移し、使い方を [D] へ書く と表現できる。

Cursor では、あまりエージェントに待たされない

Cursor では、複数のチャットを開き、それぞれへ別の仕事を渡しやすい UI/UX です。一つのエージェントが動いている間に別のチャットへ移り、自分もエディターで作業します。作業完了の通知音を合図に、あとから自分のペースで確認します。

私が普段行っているのは、次の流れです。

同じファイルや、同じプロセス、生成物を同時に扱えば、もちろん競合します。自分も工夫が必要です。

私は Cursor を選びたい

長年 VS Code を使い続けてきましたが、2025年以降、コーディングエージェントを使い始めてから、IDE を選ぶ基準が大きく変わりました。開発スタイルが変わったからです。並列開発では、複数のエージェントに何を任せたのかを追い、返ってきた変更をレビューして、マージを行う、そんな進め方が必要になりました。

一度に何体のエージェントを走らせることができるかより、エージェントが動いているあいだも、把握して管理し、自分が集中して作業を続けられるかが重要です。

両者とも複数のエージェントを扱う UI へ向かっていますが、私が違いを感じたのは、チャットをいくつ開けるかではなく、安心して任せられるかでした。VS Code（Chat view）は、この進め方を支えるハーネスとして、まだ弱い印象です。

2026年9月現在、この進め方なら、私は Cursor を選びます。

私が、VS Code と Cursor で、複数のエージェントを動かすイメージ。gpt-image-2.5 で簡単に生成。

---

関連記事

以下は、Figma デザインから実装までの、フロントエンド開発で、Cursor と Figma MCP を使った進め方を紹介する記事です。

---

付録：エージェントを使って、効率化するためには

この記事の主題は「VS Code と Cursor の並列開発」の比較のようですが、その裏側に、エージェントを安定して使うための実践テクニックがいくつか含まれます。ここでは、いくつかのポイントを整理します。

• 最初は、エージェントへ一つの仕事を渡し、その間に自分が別の仕事を進める。慣れてから、同時に渡す仕事を増やす。
• 仕事は、単独で完了でき、あとで統合できる単位まで分ける。対象、完了条件、触らない範囲をチャットごとに決める。
• 仕事が変わったら新しいチャットを作る。前の仕事の指示や履歴を、次の仕事へ持ち越さない。
• 同じファイル、プロセス、生成物に触れる仕事は同時に進めない。分けられない仕事は順番に進める。
• 完了の通知が来ても、すぐに自分の作業を中断しない。区切りのよいところで結果を確認し、取り込むか、やり直すかを決める。
• 慣れてきたら、実装とレビューも別のチャットへ分ける。最後の確認と統合は人間が担当する。