12K LoC を 200 LoC のスキルで置換 — David Gomes、Cursor

コードからプロンプトへ：Cursor が 12,000 行のコードを 200 行の Markdown で置き換えた理由

Cursor の開発者である David Gomes は、同社の高度機能「Git Work Trees」および「Best Event」の実装を劇的に見直しました。従来の数千行に及ぶ複雑なバックエンドロジックや依存関係を排除し、約 200 行の Markdown スキル（プロンプト）へと置き換える大規模リファクタリングを完了したのです。

この変革は、AI エージェント機能を「専用コード」で実装する従来の常識を覆す画期的な事例です。複雑な技術的負債を最小化しながら、保守コストを劇的に削減し、マルチリポジトリ環境での柔軟性を高めることに成功しました。

12,000 行のコードが 200 行のプロンプトに変わった背景

これまで Cursor で提供されていた「Git Work Trees」機能は、別々のチェックアウトを作成して並列で作業を行う強力な仕組みでした。しかし、その実装には約 12,000 行（一部では 15,000 行とも）の複雑なコードと、多数の依存関係、テスト、セットアップスクリプトが必要でした。

「エージェントがスコープ内に収まり、隔離されていることを確認し、作業中のワークツリーから脱出できないように保証する必要がありました」

この仕組みは、数百ものワークツリーを立ち上げたユーザーのディスク容量を圧迫したり、複雑なクリーンアップ処理を必要としたりするなど、運用上の課題を抱えていました。Gomes 氏は「90% のユーザーが使う機能ではない高度なパワーユーザー向け」と位置づけ、保守に割く時間を大幅に減らす決断を下しました。

新実装では、Cursor が既に持つ「スキル（Skills）」と「サブスキル（Sub-skills）」という既存の機能を組み合わせることで、同じ機能を Markdown だけで再構築することに成功しました。これにより、約 4,000 行だった Best Event の実装も、わずか 200 行程度のプロンプトで完結するようになりました。

スラッシュコマンドによる利便性とマルチリポジトリ対応

新機能は「/work tree」や「/best event」といったスラッシュコマンドとしてチャットに統合されました。これにより、ユーザーはチャットの途中で動的にワークツリーモードへ切り替えることが可能になりました。

以前の実装では、チャット開始時に設定を固定する必要があり、途中での切り替えは不可能でした。また、複数のリポジトリ（例：フロントエンドとバックエンドが別々）にまたがるプロジェクトでは、旧機能は動作しませんでした。新実装では、各リポジトリに対して自動的に独立したワークツリーを作成し、プルリクエストも同時に発行するなど、マルチリポ環境での動作を完全にサポートしています。

「ユーザーがチャットの途中でサイトでの作業を望むと決定すれば、/work tree でそれを行えます」

このスラッシュコマンド方式を採用した最大の理由は、プロンプトの制御権をサーバー側に保持し続けるためです。スキルやプロンプトを改善しても、ユーザーは Cursor のバージョンを更新する必要なく、常に最新のプロンプトを利用できるようになります。

モデルの逸脱という新たな課題と評価（Evals）による解決策

コードからプロンプトへ移行した代償として、モデルが指示されたワークツリーから「逸脱」する問題が発生しました。物理的に隔離されていた旧実装とは異なり、新実装ではモデルに「このディレクトリで作業してください」という信頼（雰囲気ベース）に依存しているためです。

特に小規模なモデルや、長時間のセッションにおいては、モデルが本来動作すべき範囲外（メインチェックアウトなど）で誤ってファイルを変更してしまうリスクがあります。これに対し、Cursor チームは以下の 2 つのアプローチで対応を進めています。

1. 自動評価（Evals）の実施: 「Brain Trust」などのツールを活用し、モデルがワークツリー内で正しく動作したか、あるいはメインチェックアウトを汚染していないかを自動でスコアリングする評価システムを構築しています。これにより、どのモデルが逸脱しやすいかの傾向を把握し、プロンプトの改善にフィードバックしています。
2. 強化学習（RL）とトレーニング: Cursor 独自のモデル「Composer」を用いた強化学習パイプラインに、このワークツリー制御タスクを追加しています。Composer 3 や 4 のリリース時には、これらの環境下での動作が大幅に改善される見込みです。

「評価の執筆は実は超簡単です。エージェントにプロンプトするだけで、すべてを代行してくれます」

今後のネイティブ実装と Git 以外の並列化へ

現在のスキルベースの実装はあくまで中間的な解決策です。Gomes 氏は、Cursor 3.0 の新 UI（エージェント中心のインターフェース）において、よりネイティブな並列処理機能を実装する計画を明かしています。

また、Git Work Trees 自体が抱える根本的な課題——作成に時間がかかること、ディスク容量を消費すること、Git リポジトリ内でのみ動作すること——も解決が必要です。将来的には Git に依存しないローカル並列化の新しいプリミティブの研究も進められており、これにより Git を使わないプロジェクトでも同様の並列処理が可能になることが期待されています。

まとめ

Cursor の今回のリファクタリングは、「複雑なコードで機能を実装する」のではなく「プロンプトエンジニアリングと既存機能の組み合わせ」で同等以上の価値を提供できることを示した重要な転換点です。開発者ツール業界において、技術的負債を最小化し迅速にイテレーションを行う新しい設計思想として、今後の業界標準となる可能性を秘めています。