Cursor は AI 支援型プログラミングのすべてがバイブコーディングではない（でもバイブコーディングは素晴らしい） において、バイブコーディング に使われる人気ツールでありながら、もともとはそのために設計されたものではないツールとして登場する。Simon Willison は、Cursor が当初プロのデベロッパー向けに意図されていたことを指摘し、その出自こそが、生成されたコードにできることを Cursor がほとんど制約しない理由だと説明している。
AI エージェント型プログラミングに関するサーベイ AI エージェント型プログラミング: 手法、課題、機会に関するサーベイ は、Cursor を、会話的なインタラクション、過去の編集の記憶、構造化されたコマンド実行によって IDE アシスタントの機能を拡張したものと説明している。同じサーベイは比較分析の別の箇所で、Cursor の基盤モデルを Claude 3.5 Sonnet または GPT-4、デフォルトのコンテキストウィンドウを 128,000 トークン、永続メモリをプロジェクト履歴に対するセマンティック検索として実装したものと報告し、独自の分類法において Cursor を、リアクティブでツールを利用するがマルチターンでも適応的でもない IDE アシスタントに分類している。
機能
このブログ記事による唯一の直接的な特徴づけは比較によるものである。Cursor は Claude Artifacts と比べて安全装置がはるかに少ない。Claude Artifacts のサンドボックスは、レビューされていないコードがネットワークに到達したり、プロジェクトの外で害を及ぼしたりすることを防いでいる。
同じ記事で引用されている Karpathy のバイブコーディングについての説明では、彼が作業していた環境として Sonnet モデルで動く Cursor Composer が挙げられており、タイピングではなく音声で話しかけていたと述べられている。これは当時の彼自身のワークフローの説明であり、製品が一般的に提供するものについての記述ではない。
長時間稼働エージェントに関する後の記事は、Cursor がバックグラウンドのクラウドエージェントも提供していると説明している。これはデベロッパー自身のラップトップではなく Anysphere のクラウドインフラ上で実行される長時間タスクであり、8 時間に及ぶリファクタリングやコードベース全体の移行も、ラップトップの蓋を閉じても中断されない。タスクはローカルで開始し、時間がかかりそうだとわかった時点でクラウドでの実行に送り、後で別のデバイスから再接続できる。各バックグラウンドエージェントはそれぞれ分離された git ワークツリー内で実行され、その結果はプルリクエストを通じてマージされる（Git ワークツリー を参照）。同じ記事は、Cursor 独自のフロンティアコーディングモデルとして説明される Composer 2 にも触れており、これは Cursor 3 に搭載されている。
その記事はまた、Cursor の本番環境の長時間稼働エージェントを支える調整システムについても説明している。それは Planner/Worker/Judge というロール分割であり、それ以前の 2 つの調整設計（ロックを使ってファイルを共有する対等なエージェント群、次いで楽観的並行性制御）がいずれもボトルネックや調整の失敗に直面した後にたどり着いたものである（Planner-Worker モデル を参照）。記事によれば、長時間の自律的な作業に限っては GPT モデルが Opus を上回った。Opus は早めに停止して近道をとる傾向があったためであり、同じシステム内でも役割によって適したモデルが異なるということである。
AI IDE におけるルールの分類法と進化：マイニングと調査による研究 は Cursor を AI IDE（既存のエディタに対するプラグインとしてではなく、AI を中核的なアーキテクチャ要素として組み込んで構築されたエディタ）として扱い、デベロッパーが AI IDE ルール を定義できる 5 つのツールの 1 つとして位置づけている。Cursor のルールファイルは .cursor/rules/ 以下に置かれる。この研究は Cursor のルールファイルの置き場所として旧形式の .cursorrules も挙げており、こうした旧形式はその後ディレクトリベースの仕組みに置き換えられたと記している。この研究は Cursor のリリース日を 2023 年 4 月 6 日としており、この日付は VS Code ベースのアーキテクチャに移行したバージョンに対応すると注記している。
2025 年の実務家によるブログ記事 AI プログラミングツールの進化とバイブコーディングについて は、Cursor がそれ以前の IDE プラグインをリードした要因を コンテキストエンジニアリング に帰し、その最初のブレークスルーとしてコードベースインデックスを挙げている。同記事の説明によれば、プロジェクトが開かれると Cursor はローカルでコードベースを小さなチャンクに分割して Cursor のクラウドサーバーにアップロードし、そこで埋め込みモデルによって埋め込みが計算され、クラウドのベクトルデータベースに保存される。質問がなされると、プロンプトが埋め込まれ、Turbopuffer が最近傍探索を実行し、難読化されたファイルパスと行範囲がクライアントに返され、クライアントはそれらのコードチャンクをローカルで読み込む。記事によれば、こうして得られる複数ファイルにまたがるコンテキストによって、モデルはファイルをまたぐ呼び出しの実装、複数ファイルにまたがるバグの修正、モジュール全体のリファクタリング、多くのファイルに関わる機能の追加が可能になる。さらに、Cursor ではユーザーがファイルやフォルダを直接 @ でメンションでき、後に Git 履歴やドキュメントのインデックス化も追加され、Rules もサポートしていると述べている。記事は Rules を、生成されるコードがプロジェクトのアーキテクチャ、スタイル、技術スタックと一貫するよう、モデルに一般的なコーディングルールを与えるものと説明している。これとは別に、記事は Cursor が Tab 補完用に構築した独自モデルを評価しており、それが十分に高速かつ正確であるため、著者はその提案を採用する割合が高いと報告している。
同じ記事は、検索をめぐる議論の反対側の見解も紹介している。セマンティックな類似性は、コードが実際に依存しているコンテキストと同じではないこと、そして Cursor のようにファイルハッシュの Merkle ツリーによって同期が保たれるインデックスは、大規模なリファクタリング中やインデックスサーバーに負荷がかかっているときに古いコードを返す可能性がある、というものである。著者の経験では、小規模・中規模のタスクでは Cursor と Claude Code の性能は同程度だが、10 を超えるファイルに関わる大規模なタスクでは Claude Code のほうがはるかに優れている。
採用とエコシステム
Willison は Cursor を他の人気のバイブコーディングツールと同列に扱っており、これはプロ向けに作られたツールを初心者が手に取るツールの中に位置づけることになる。彼が提起する安全性の懸念はまさにこのミスマッチから生じている。彼がバイブコーディングの条件として挙げるもの（リスクが低いこと、シークレットや個人データの扱いに注意すること、厳格な課金上限を設けること）は、ツールがそれらを強制しない場合、ツールではなく人が満たさなければならない。
ルール分類研究の実務家調査では、99 人の回答者のうち 57 人が挙げた Cursor が最も広く採用されている AI IDE であり、51 人の VS Code と Copilot の組み合わせがこれに僅差で続いた。ただしこの研究は後者を AI IDE ではなくプラグイン構成として数えている。マイニングの側でも、Cursor はこの研究のプロジェクトデータセットで最大の割合を占めた。分析対象の 83 プロジェクトのうち 46 件であり、これらはキーワード、ルールファイル、手作業によるフィルタリングを経る前の当初 18,790 件の候補から抽出されたものである。
上記のブログ記事は、コードをクリーンに保たなければならない場合の Cursor の使い方について、ある実務家の説明を加えている。著者は、本格的なエンジニアリング作業で最もよく使う機能は Tab 補完だと報告している。レイヤー構成、抽象化、コメント、メソッド名は手で書き、残りを補完に生成させるという使い方である。その理由は、著者の経験では LLM は抽象化が苦手だからであり、モデルに完全なコードを出力させるために会話を繰り返し調整するよりも、このほうが効率的なことが多いという。