前置きなしで行く。
俺の環境はこうだ。MacBook Pro M3、メインはVSCode派だったけど最近はIDEを行き来してる。本業はFastAPI + PostgreSQL + Reactのマイクロサービス構成で、4人チームで開発してる。去年からAIコーディングツールをいくつか試してきたが、正直なところ「本当に速くなってるのか？体感じゃなくて実際に」という疑問が拭えなかった。
だから2週間、意図的にツールを切り替えながら同じ種類のタスク（APIエンドポイントの実装、バグ修正、リファクタリング）をこなした。以下はその記録だ。
GitHub Copilotは「補完ツール」という枠から出られていない
正直に言う。Copilotはもう限界が見えてる。補完精度自体は悪くない。むしろ細かい一行補完はかなり上手い。でも2026年の今、「補完が賢い」だけじゃ物足りない。
一番困ったのはコンテキストの薄さだ。たとえばこういう状況があった。
# models/user.py に既存の User モデル
class User(Base):
__tablename__ = "users"
id = Column(Integer, primary_key=True)
email = Column(String, unique=True, nullable=False)
created_at = Column(DateTime, default=datetime.utcnow)
is_active = Column(Boolean, default=True)
別ファイルで新しいエンドポイントを書こうとしたとき、Copilotの提案はこうだった:
# Copilotが出してきた提案
@router.get("/users/{user_id}")
async def get_user(user_id: int, db: Session = Depends(get_db)):
user = db.query(User).filter(User.id == user_id).first()
if not user:
raise HTTPException(status_code=404, detail="User not found")
return user
悪くはない。でも俺のプロジェクトではエラーハンドリングをUserNotFoundErrorというカスタム例外でラップしてて、dbセッションもAsyncSessionを使ってる。Copilotはそれを知らない。プロジェクト内の他のエンドポイントを見れば一目瞭然なのに、ファイルをまたいで「文脈を読む」能力が弱い。
ここがCopilotの根本的な問題だ。インラインの補完は上手い。でもプロジェクト全体のアーキテクチャを把握して、それに沿ったコードを出すのは苦手。GitHubとの統合という点ではこれが一番こなれてる——PRレビュー支援は地味に使えるし、それだけはCopilotを評価してる。月$19（Individualプラン）でJetBrains、VSCode、Neovimに対応してるのは間口が広くて、チームで環境がバラけてるときには助かる。
「プロジェクトを理解するAIアシスタント」ではなく「賢い補完エンジン」として使わないと、期待ハズレになる。それだけは明言しておきたい。
Cursorがコードじゃなくて思考の流れを変えた
Cursorに移ったとき、最初は「VSCodeのフォークでしょ」と舐めてた。1日目はそんなに変わらないなと思ってた。でも3日目くらいから何かが変わってることに気づいた。
Ctrl+Kでインライン編集、Ctrl+Lでチャット。このショートカットが体に馴染んでくると、「ファイルをまたいで考える」作業の重さが減る。
具体的に言うと、こういう場面があった。2週目の木曜日、認証周りのリファクタリングをしてた。JWTのデコード処理が3箇所に分散してて、それをauth/utils.pyに集約したかった。以前ならこのタスクは全ファイルをgrepで探して、ロジックを手動でコピーして、インポートを修正して、テストが通るか確認する——という流れで30〜40分かかってた。
Cursorのチャット欄で「JWTのデコード処理が散在してるからauth/utils.pyに集約したい。どのファイルを変更すればいいか教えて」と入れたら、プロジェクト内を走査して「3箇所あります、こういう順で変更しましょう」と返してきた。Applyを押すとdiff形式で変更が展開される。全部で15分くらいだった。
ただ、100%信用するのは危険だ。Cursorが提案した変更で一度だけCIのテストが落ちたことがある——金曜の夕方に気づいたやつで、焦った。原因は、Cursorが変更したファイルの中に、テストコードとの暗黙的な契約が存在してたのに、それをスルーしてたから。ツールの提案を鵜呑みにしないという基本は守らないといけない。
価格は月$20（Proプラン）。Copilotとほぼ同じ金額で、体感できる生産性の差はかなり大きい。ただしVSCodeのフォークなので、一部の拡張機能が動かなかったり設定を移行する手間がある。俺はGitLensが一部おかしくなって小一時間悩んだ——これ、移行前に誰かが教えてくれてたら助かったやつだ。
Windsurfの「Cascade」に最初は懐疑的だった
「Codeiumが作ったIDEでしょ」という印象で、最初はあまり期待してなかった。Cursorと似たようなもんだろうと。
ところが、Windsurfの「Cascade」機能が想定外だった。
Cascadeは単なるチャットじゃない。タスクを渡すと、Windsurfが自律的に複数のファイルを編集し、ターミナルコマンドを実行し、エラーが出たら自分で修正しようとする。試しにこういう指示を出してみた。「productsテーブルにdiscount_percentageカラムを追加するAlembicマイグレーションを作って、関連するAPIエンドポイントとスキーマ、テストも更新して」
Cursorだとこのタスクは段階的にやり取りしながら進める感じになる。Windsurfは1回の指示でマイグレーションファイルを生成し、schemas.pyを更新し、エンドポイントを修正し、既存のテストファイルに新しいケースを追加した。全部で5分もかからなかった。
本音を言うと——ここが微妙なところだ。
生成されたテストが、俺のプロジェクトのテストの書き方と微妙にずれてた。変数名の命名規則とか、pytestフィクスチャの使い方とか。小さい差だけど、チームで使うには地味にストレスになる。あとCascadeが自律的に動く分、「今何をやってるか」が見えにくい瞬間がある。俺みたいに変更の経緯を把握したい人間には、少し不安になる場面もあった。
価格はProプランが月$15で、Copilot・Cursorより安い。無料プランも使えるが、Cascadeの使用回数に制限がある。
バグ修正とリファクタリングで一番差が出た
2週間でこなしたタスクの内訳はざっくりこうだ:
- APIエンドポイントの新規実装: 各ツールで10本ずつ
- バグ修正（既存のテストが落ちてる状態から直す）: 各5件
- ドキュメント生成（docstring、OpenAPI仕様）: 各5件
新規実装ではCursorが一番バランスよかった。Windsurfは速いが後処理が必要なことが多く、Copilotは小さなエンドポイントなら十分だけど複数ファイルをまたぐ実装は辛い。
バグ修正が一番面白かった。Copilotはエラーメッセージをチャット欄に貼っても、ファイルのコンテキストが薄いから的外れな提案が多かった。CursorとWindsurfはトレースバックから関連ファイルを特定して、かなり的確な修正案を出してくれた。
一回、データベースのデッドロックが原因のバグが本番で出たことがあった——深夜2時に気づいたやつで、かなり焦った。CursorのチャットにDEADLOCK detectedのログを丸ごと貼ったら、SQLAlchemyのセッション管理の問題だと正確に特定してくれた。具体的には、非同期コンテキストの中でセッションを共有してたのが原因で、AsyncSessionをリクエストスコープで管理し直すという修正案を出してきた。それが正解だった。
ドキュメント生成はCopilotが意外と上手かった。docstringの品質が安定してて、この用途だけはCopilotを評価し直した。
「Windsurfが全部勝った」「Cursorが完璧」という話にはならない。用途によってかなり違う、というのが正直なところだ。
俺のチームはCursorを選んだ、その理由
ここをぼかすつもりはない。
俺のメインはCursorに固定した。
理由はシンプルで、「プロジェクトを理解した上で手を動かす」という感覚が一番Cursorで強かったから。チャットとインライン編集の組み合わせが、俺の思考のリズムと合ってる。コードの意思決定は自分でして、実装の手を速くしたい——そういう使い方にCursorがフィットした。
WindsurfのCascadeは魅力的だ。でも「自律的に動きすぎる」という感覚が俺には合わなかった。個人プロジェクトや、プロトタイピングのフェーズなら積極的に使いたいと思う。チームの本番コードベースで使うには、変更の透明性がもう少し欲しい——あと$15という価格は普通に安いので、Copilotから移行を検討してるなら試す価値はある。
Copilotは、JetBrainsを使ってるチームメンバーや、IDEを変えたくない人にはまだ意味がある。ただ、生産性を本気で上げたいなら、Copilotで止まってるのはもったいないと思う。
So、最後に一つ。どのツールを使うかより、ツールをどう使うかの方が結局大事だ。Cursorを使い始めた最初の3日間、俺はCopilotと同じ使い方をしてたから全然速くならなかった。チャット欄でプロジェクトのコンテキストを説明してから作業するという習慣が身についてから、一気に変わった。ツールへの投資は金額だけじゃなく、使い方を学ぶ時間も込みで考えた方がいい。