【ITニュース解説】Exploring Cursor, Windsurf and Copilot with GPT-5

最近、システム開発の現場では、AI（人工知能）がコードを書く手助けをするツールが急速に進化している。この記事では、特に注目されている3つの開発環境（IDE）、「Cursor」「Windsurf」「Copilot」を、最新のAIモデルであるGPT-5と組み合わせて試した結果が報告されている。これらのツールが、新しいプロジェクトをゼロから作る「グリーンフィールド」の状況と、既存のコードを修正・拡張する「ブラウンフィールド」の状況でどのように機能するかが検証された。開発は「仕様書先行開発」という、まず設計書をしっかり作ってからコードを書き始める方法で行われている。

この記事の著者は、これら3つのIDEが最終的に求められた作業を完了したと述べているが、その違いは作業のしやすさ、見た目の完成度、そしてAIがどれだけ開発者に手厚くサポートしてくれるかという点で現れたとしている。特定のツールが圧倒的に優れているというよりは、開発者の好みやチームのやり方に合わせて選ぶべきだというのが基本的な見解だ。

まず「グリーンフィールド」のシナリオ、つまり全く新しいプロジェクトを立ち上げるケースでは、開発者は各ツールにアーキテクチャや技術スタック（MERNスタックなど）を記述した仕様書を与え、それに基づいてプロジェクトを実装し、テストを生成・調整するよう求めた。その結果、どのツールも似たような仕様書を出力し、すべて動作するコードを生成したという。

個々のツールの特徴として、CursorはUIが非常にプロフェッショナルで、丁寧な説明をしてくれた。ただし、一度だけ仕様書からのプロジェクト自動構築を拒否した場面もあったようだ。しかし、問題なく構築できた際には、きれいに整理された構造とテストコードを生成し、仕様変更にも正確に対応したという。CursorはAIが一度に処理できる情報量（コンテキスト）の使用状況を表示する機能も持っており、これは開発者にとって役立つ情報となる。処理速度はCursorとCopilotが同程度で、Windsurfより速かった。ただし、コードの構造を改善する「リファクタリング」の質では、WindsurfとCursorがCopilotを上回ったとされている。

Windsurfはプロジェクト構築において非常に積極的で、追加の指示なしにフォルダやファイルの構造を自動的に作成した。チャット画面でAIの「思考」やコマンドの実行、問題点が分かりやすく表示される点も評価されている。

Copilot（VS Code版）は、チャット内でファイルのパス情報と共に内容を表示することが多かったが、すぐにディスク上に具体的なファイルツリーを作成することはなかった。しかし、開発環境内で直接ブラウザプレビューができる機能は、素早い確認に非常に便利だったようだ。

テスト生成に関しては、WindsurfとCursorが生成したテストは初回から問題なくパスした。Copilotは最も強力なテストを生成し、テスト対象の一部を一時的に代替する「モック」の扱いが細かく、特殊なケースもカバーしていた。ただし、それらのテストをパスさせるには少し手間がかかったものの、自己完結型のモジュール構造になっていたため、失敗の原因を特定しやすかったという。

次に「ブラウンフィールド」のシナリオ、つまり既存の大きなコードベースを修正・拡張するケースでは、まず開発環境を立ち上げるまでの速さが検証された。Copilotが最も速くサーバーを起動し、次にWindsurf、Cursorが続いた。Cursorは既存の環境設定ファイルを見つけられず、新しいファイルを作成してしまい、これが作業を遅らせる原因となった。

既存コードの理解度については、Windsurfが既存コードを非常に分かりやすく説明し、その応答形式やハイライト表示が最も優れていたと評価されている。CursorとCopilotも既存コードを効果的に読み解き、説明することができた。

新しい機能（ツール詳細ページの追加など）の実装では、どのツールも仕様書に基づいてうまく機能し、適切なテストも生成された。これは、仕様書が明確であればあるほど、AIによるコード生成の結果も具体的で質の高いものになるという重要な教訓を裏付けている。

デバッグの能力に関しては、WindsurfとCursorが特定のバグ（PostHogの遅延初期化バグ）をより速く特定したが、Copilotはそのバグを見落としたという。このバグはコード内にコメントとしてヒントが書かれていなかったため、純粋な診断能力が試された形だ。

複数のファイルにまたがる変更の要求では、3つのツールすべてが指示された手順を実行し、変更を適切に準備した。ただし、アプローチは異なり、Copilotは変更を適用するまでに開発者からの承認を多く（Windsurfの3回、Cursorの1回に対し7回）求めた。これは慎重さの表れでもあるが、作業の流れを遅くする要因にもなった。また、Copilotが「この問題にしばらく取り組んでいる」と表示して処理が停止することがあったのに対し、他のツールは完了するまで繰り返し試行する傾向があったという。

開発環境のUIと開発者体験（DX）に関して、ターミナル（コマンド入力画面）とチャットの連携はWindsurfが最も優れ、次にCursor、Copilotの順だった。Copilotはチャット画面とは別にコマンドを実行するため、会話の流れが途切れてしまうことがあった。Cursorは全体の見た目や進捗状況の表示が最も統一感があり、Windsurfは何が起きているかを最も明確に伝えてくれた。Copilotは開発環境内でのブラウザプレビューやマークダウン表示が優れている。

AIの記憶力（コンテキストとメモリ）については、Windsurfがセッションを通して情報を「ただ覚えている」かのように感じるほど強力だった。Cursorはルールやメモを活用して記憶力を補うが、長時間のセッションでは情報の流れを見失うことがあった。Copilotはシンプルな設計のため、情報保持が一時的になりがちだという。

特筆すべき点として、Windsurfは開発者がコードの変更点をレビューしている間も、バックグラウンドで次の変更を提案し続けることができ、作業の流れを維持するのに役立った。Cursorの複数ファイル編集機能は強力だが、「Ask」モードと「Agent」モードの切り替えを忘れた際に通知があるとさらに良いだろうとしている。Copilotの「Ask」モードは、説明よりも行動を優先することがあり、新しいチャットを開始すると現在の編集セッションが終了してしまう欠点もあった。また、Copilotで一度無限ループに陥ったことがあったが、再起動で解決したものの、AI自身で解決できなかった点に疑問を呈している。

最終的な推奨としては、これらのツールはすべてVS Codeをベースにしており（WindsurfとCursorは派生版、CopilotはVS Code内で動作）、機能的な大きな違いは少ない。キーボード操作やAIモデル、APIも似ているため、違いはAIがどのように計画を立て、どれだけ説明し、ターミナルとチャットの流れがどうか、そしてUIが開発者の作業をどれだけ助けるかといった、細かな部分に現れる。

個々のツールは異なる利用シーンで役立つとされている。Cursorは、見た目の完成度、複数ファイルの編集のしやすさ、そしてAIが実行すべきかチャットで説明すべきかを適切に判断する感覚を重視する開発者に向いている。特にスタートアップや小規模チームで構造と速度を求めるシニアエンジニアやフルスタック開発者に適しているだろう。

Windsurfは、AIの記憶力と、作業の流れを重視し、AIが何をしているかを逐一説明してくれるUIを評価する開発者に向いている。大規模なコードベースや長期にわたるリポジトリで「情報を見失わないこと」が重要となる、スタッフエンジニアやプリンシパルエンジニア、メンテナーといった役割の開発者に強力な選択肢となる。

Copilot（VS Code版）は、信頼性と「人間が介在する」作業の流れを好む開発者向けだ。すでにMicrosoftやGitHubのエコシステムに属している企業チームには非常に馴染みやすいだろう。チームリーダーやGitHub標準化された組織の個別貢献者で、信頼できるデフォルト設定やガバナンス（統制）を重視する開発者に向いている。

ただし、これらの評価は検証の複雑さ、テストカバレッジ、コードベースの規模など、いくつかの制限があることも認識すべきだと著者は述べている。そのため、最終的には開発者自身やチームのニーズに合わせて実際に試して選ぶことを推奨している。

現在のAI開発ツールの状況は変化が速く、それぞれのIDEがどれだけ迅速に新機能をリリースできるかが競争の鍵となる。Cursorは独自のインライン編集機能を開発しており、今回の検証でもその効果が実感された。Copilotは比較的開発が遅い傾向にあるようだ。Windsurfは最近の買収とその後のリーダーシップ変更により、今後のリリース速度に変化があるかもしれない。

現在のAI開発ツールにはまだ限界があることも指摘されている。例えば、「仕様書先行開発」が完全には統合されていない点が挙げられる。ツールは仕様書からコードを生成できるが、そのワークフローは依然として開発者が手動で仕様書を追加し、どのコードがどの要件を満たしているかを追跡しにくいままだ。また、仕様の実装が正式に検証される仕組みも不足している。AIの記憶力も改善はしているものの、アーキテクチャ上の重要な決定やセッションをまたいだ制約を維持するのには苦労する。テストやモックの生成品質も、開発者の指示の仕方によって大きく変動し、網羅性や特殊なケースへの対応に体系的なアプローチがない。

さらに、AIが生成したコードの変更履歴が残らない、開発者やプロジェクトごとのコストが把握できない、既存の管理プロセスとの統合がないといった課題も指摘されている。チーム全体でのコードスタイルの統一性も問題となる。各開発者のAIアシスタントが異なるパターンを学習することで、コードベース全体にスタイルのばらつきが生じる可能性がある。企業固有のアーキテクチャパターン、セキュリティ要件、コンプライアンスルールをAIレベルで強制する手段も存在しない。

これらの課題は、次世代のIDEにとって大きな機会を示している。未来のIDEでは、仕様書が単なるドキュメントではなく実行可能な契約となり、AIエージェントが組織の標準を理解し維持し、生成されたコードには出所と責任が明確になるような進化が期待されている。