SECTION 01
用語の整理：Agent・Composer・モデルの関係
最初に用語を整理しておきます。2026-04-10 時点の Cursor では、AI がコードを生成・修正する機能全体を「Agent」と呼んでいます。
一方 Composer は、Cursor が自社開発しているモデルの系統名です。Composer 1 → 1.5 → 2 と更新されており、2026-03-19 に公開された Composer 2 が現行の最新版です。
つまり「Agent という実行環境の中で、Composer 2 などのモデルを選んで使う」という構成になっています。本記事では Agent の操作面と Composer のモデル面を分けて説明します。
SECTION 02
結論：Cursor Agent は「計画ありき」なら実務で使える
Cursor Agent は、計画を先に立てれば実務で十分に戦えるツールです。ただし「作って」と丸投げした瞬間に、コードベースが予想外の方向に壊れ始めます。
これまでの試行錯誤の中で、計画なしの丸投げが最も危険なパターンだとはっきりわかりました。「会員登録機能を作って」のような漠然とした指示を出すと、AI が要件の解像度を理解しないまま進み、関係ないファイルまで変更されて泥沼にはまります。
今はまず実装の計画書を AI に作らせて、自分がレビューしてから Go を出す流れに変えています。この計画フェーズを挟むかどうかで、最終的なコードの安定度がまるで違います。
Agent が得意な作業と苦手な作業を整理すると、判断がしやすくなります。
- 得意: ゼロからの新規ファイル生成、ドキュメントに沿った一括実装、定型的な CRUD 構築
- 苦手: 複数ファイルにまたがる既存コードの修正、暗黙の依存関係がある箇所の変更、大きなリファクタリング
つまり Agent の実務価値は「使う側の準備」で決まるということです。計画書を渡して範囲を絞れば精度は高く、丸投げすれば精度は低い。ツールの性能よりも、指示の解像度がボトルネックになります。
SECTION 03
Agent の実務性能：新規実装と既存コード修正で何が変わるか
Agent の強みが最も活きるのは、新規実装でドキュメントと関連ファイルをまとめて渡す方式です。開発プロジェクトごとにドキュメントを 1 つ作り、関連ファイルを全部渡して一気に生成させるやり方に変えてから、精度の手応えが明らかに変わりました。
公式には、Cursor はコードベース索引やサブエージェントによる探索、計画生成などの機能を訴求しています。ただし筆者の環境では、明示的に関連ファイルを添えたほうが安定した結果が得られました。コードベース索引が効く場面もありますが、プロジェクト構成や規模によって精度にばらつきがある印象です。
一方、既存コードの修正では精度が明確に落ちます。とくに失敗しやすいのは次のようなパターンです。
- 複数ファイルにまたがる状態管理の変更
- 暗黙の命名規則や設計方針に依存した箇所の修正
- テストコードと本体コードを同時に整合させる作業
既存コードの修正で成功させるコツは、変更対象のファイルだけでなく、依存先・依存元も明示的にコンテキストに含めることです。Agent は自動で関連ファイルを探索する機能を持っていますが、筆者の経験上、手動でコンテキストを補完したほうが安定するケースが多くありました。
新規と修正の使い分けを意識するだけで、Agent への期待値が適切になり、無駄な手戻りが減ります。新規は Agent に任せる、既存コードの修正は慎重にファイルを選んで渡す。このシンプルな切り分けが実務では効きます。
SECTION 04
Composer モデルの世代と使いどころ
Cursor の自社モデル Composer は、1 → 1.5 → 2 と世代を重ねて進化しています。2026-04-10 時点の最新は、2026-03-19 に公開された Composer 2 です。
それぞれの世代には異なる特性があり、作業内容に応じた使い分けが有効です。
- Composer 1 / 1.5: レスポンスが速く、軽い修正に向いています。変数名のリネーム、定型バリデーションの追加、短いユーティリティ関数の生成といった日常作業を高速にさばけます
- Composer 2: より高度なコード理解と生成が可能になっています。複雑な実装タスクや、文脈を多く必要とする作業での精度向上が期待できます
日常の開発作業を振り返ると、実は大半が「ちょっとした修正」の積み重ねです。
- 変数名やメソッド名のリネーム
- 定型的なバリデーションの追加
- コメントの整理やフォーマット調整
- 短いユーティリティ関数の生成
こうした軽い作業を高速にさばけることが、Composer の軽量モデルの本当の価値です。重い実装タスクだけが AI エディタの評価軸ではありません。
Cursor が独自モデルを持っていることは、特定のモデルプロバイダに依存しないという点で長期的な強みになります。外部モデルの API 制限やプラン変更に左右されにくい独自路線は、リスク分散として理にかなっています。
SECTION 05
Windsurf に乗り換えて見えた Agent の限界
筆者が当時使っていた Cursor（Composer 1 ベース）と Windsurf を、既存コードの保守・改修が中心の案件で比較したところ、筆者環境では Windsurf のほうが安定して成果が出るという実感に変わりました。決め手はコード全体の検索力と、作業前の事前調査の徹底度です。
Windsurf は作業に取り掛かる前に、プロジェクト全体を調査してから修正に入る傾向があります。この「事前調査フェーズ」が当時の Cursor には薄く、それが既存コード修正での失敗数の差として表れました。
筆者環境で感じた差は次の通りです。
- コード全体の検索: Windsurf のほうが関連ファイルの発見精度が高かった
- 事前調査の深さ: 変更の影響範囲を先に把握してから動く傾向があった
- 失敗数の減少: 関係ないファイルを巻き込む事故が明らかに減った
ただし、これは筆者が特定の案件・特定のバージョンで体感した結果です。公式上は Cursor も Windsurf もコードベース理解や探索機能を訴求しており、モデルの世代・IDE のバージョン・案件の規模・言語・プロンプト手法によって結果は変わります。
また Cursor はその後 Composer 2 をリリースしており、当時の比較がそのまま現行版に当てはまるとは限りません。新規実装の速度感や Composer の軽量モデルの軽快さは、Windsurf にはない魅力です。どちらが「上」かではなく、どの作業にどちらが向くかで判断するのが現実的です。
SECTION 06
乗り換えで引き継げるもの・失うもの
Cursor から Windsurf への移行を考えるとき、最も気になるのは既存の設定や拡張機能がどこまで残せるかという点です。
どちらも VS Code をベースにしていますが、Windsurf は Open VSX ベースのマーケットプレイスを採用しています。そのため、VS Code Marketplace 専用の拡張機能や一部の独自拡張は互換性がない場合があります。
引き継ぎやすいものと、注意が必要なものを整理します。
- 引き継ぎやすい: VS Code OSS 系・Open VSX で公開されている拡張機能、基本的なキーバインド、テーマ設定
- 非互換の可能性がある: VS Code Marketplace 専用拡張、他社 AI 拡張、一部の独自拡張
- 再設定が必要: AI 関連の独自設定、カスタムルール、プロジェクト固有の指示ファイル
- 失う可能性がある: Cursor 独自機能への依存（Composer モデル、Cursor 固有の UI 機能）
移行の心理的ハードルは、AI 性能の差よりも「今の環境が壊れるかもしれない」という不安から来ることが多いです。実際には多くの拡張機能が問題なく動きますが、事前に主要な拡張の Open VSX 対応状況を確認しておくとスムーズです。
ショートカットキーの競合にも注意が必要です。Cursor と Windsurf で同じキーに異なる AI 機能が割り当てられていることがあり、最初の数日は指が迷います。
もう一つ大事なのは、完全に乗り換える必要はないということです。両方インストールしたまま、タスクに応じて切り替える運用のほうが現実的です。移行は「引っ越し」ではなく「部屋を増やす」感覚で捉えるのがおすすめです。
SECTION 07
タスクの重さと集中力で使い分ける現実解
実務での最適解は、タスクの重さと自分の集中力の残量で道具を切り替えることです。一つのツールで全部をまかなおうとすると、どこかで必ず非効率な場面にぶつかります。
日中は頭が動いているので、Cursor か Windsurf で細かく指示を出しながら確認しながら進めるのが効率的です。コードの意図を理解しながら AI と対話するスタイルは、集中力があるときに最も成果が出ます。
夕方に疲れてきたら、自律性の高いエージェントツールに任せるという切り替えも有効です。自分で判断する余力が減っているときは、AI の自律度が高いほうが作業が前に進みます。
ただし長いファイルの修正でコストが爆増する罠には注意が必要です。ファイルが大きくなるほどトークン消費が増え、思ったよりコストがかさむケースがあります。次のような判断基準が役立ちます。
- 修正対象が数百行以内 → そのまま Agent や Windsurf で対応
- 修正対象が大きなファイル → 修正案だけ出させて、別のツールで適用する
- 繰り返し試行が必要 → Composer の軽量モデルで素早く回す
この使い分けは固定のルールではなく、自分の状態に合わせて柔軟に変えるものです。「今日はどのツールで始めるか」を朝の時点で決めておくと、切り替えの判断コストも減ります。
SECTION 08
数ヶ月単位で判断が変わる市場の現実
AI エディタ市場は数ヶ月単位で勢力図が変わるのが当たり前の世界です。「これがベスト」と確信した判断が、次のアップデートで覆ることは珍しくありません。
40 個以上のサービスをつくってきた経験からいえるのは、ツール選びに完璧な正解を求めないほうがいいということです。Cursor・Windsurf・Cline のどれか一つだけでも十分に戦えます。大事なのは一つに絞ることではなく、切り替える判断力を持つことです。
実際に起きた変化を振り返ると、その速さが実感できます。
- Agent（旧 Composer 機能）の登場で「AI に一括生成させる」スタイルが定着
- 新しいモデルの登場で Windsurf の事前調査が強化され、筆者の主軸が移った
- Google が Antigravity という新しい AI コードエディタを発表し、市場がさらに動いた
Antigravity については、報道では Windsurf 創業メンバーの一部が Google DeepMind に加わったとされていますが、この関係づけは主に二次報道ベースの情報です。
こうした変化に対して、特定のツールに全賭けするのはリスクです。メインツールは持ちつつも、半年に一度は他の選択肢を試す習慣をつけておくと、乗り遅れずに済みます。
結局のところ、今の自分のプロジェクトと開発スタイルに合っているかどうかが唯一の基準です。他人のおすすめや比較表ではなく、自分で触って判断するプロセスを大事にしてください。
SECTION 09
無料枠と有料枠で実務体験がどこから変わるか
Cursor も Windsurf も無料枠が用意されていますが、無料で試せる範囲と有料で本格運用する範囲では体験がまるで違います。無料枠だけで「このツールは使えない」と判断するのは早計です。
無料枠で確認すべきことと、有料でないとわからないことを整理します。
- 無料枠で確認できる: UI の操作感、基本的なコード補完の品質、拡張機能の互換性
- 有料でないとわからない: 高性能モデルでの長時間作業、Agent の大規模生成、エージェント機能のフル活用
趣味の個人開発なら無料枠でもかなりの作業がこなせます。ちょっとした Web アプリやスクリプトの作成なら、制限に引っかかることはそれほどありません。
一方、業務で毎日ヘビーに使うなら有料プランは必須です。高精度モデルのリクエスト上限に達すると作業が止まるため、課金のタイミングは「毎日使い始めたとき」がひとつの目安になります。
どちらのエディタも頻繁にプランの内容が変わるので、契約前に最新の料金ページを必ず確認することをおすすめします。比較記事の情報は書かれた時点のもので、数ヶ月後には変わっている可能性が高いです。
SECTION 10
開発スタイル別：Cursor が向く人・Windsurf が向く人
最終的な選び方は、自分の開発スタイルがどちらに近いかで決まります。ツールの性能差よりも、自分の作業パターンとの相性のほうが重要です。
Cursor が向く人は次のような開発者です。
- ゼロイチの新規開発が多い
- ドキュメントを先に書いてから実装に入るスタイル
- 軽い修正を高速に繰り返す作業が中心
- Composer の軽量モデルの速度感を重視する
Windsurf が向く人は次のような開発者です。
- 既存コードの保守・改修が業務の大半
- プロジェクトの規模が大きく、ファイル数が多い
- AI に事前調査を丁寧にやってほしい
- 失敗のリスクを最小限に抑えたい
チーム開発の場合は、メンバー全員が同じツールを使う必要はありません。各自が得意なツールを使い、コードの品質はレビューで担保するほうが合理的です。ツールの統一よりもレビュープロセスの統一のほうが大事です。
個人開発者の場合は、まず Cursor Agent で新規プロジェクトを一つ作ってみるのがおすすめです。そこで手応えを感じたらしばらく使い続け、既存コードの修正で不満が出てきたら Windsurf も試す。この順番が自然です。
どちらを選んでも、「計画を先に立ててから AI に実装させる」という基本は変わりません。ツール選びに時間をかけすぎるより、まず一つを使い込んで計画駆動の開発フローを身につけることが、実務で成果を出す最短ルートです。
