本講演では、Cursorチームが開発したAI支援コーディングツールの進化について解説している。プログラミングの歴史をパンチカードから現代のAI時代まで振り返り、特にコンテキストエンジニアリングとコーディングエージェントの発展に焦点を当てている。タブ補完機能の改善、セマンティック検索の導入、複数エージェントの並行実行など、具体的な技術的進歩が紹介される。また、自律型エージェントが長時間タスクを実行し、開発者が創造的な作業に集中できる未来のビジョンが示されている。Cursorは単なるコード補完ツールではなく、開発者の生産性と創造性を最大化するための包括的なプラットフォームを目指している。
ソフトウェア開発の進化
私はリーと申しまして、Cursorチームに所属しています。本日はソフトウェア構築がどのように進化してきたかについてお話しします。ご参加いただきありがとうございます。
私たちは1960年代のパンチカードと端末から始まりました。当時プログラミングは新しい超能力でしたが、ほとんどの人々にとってはアクセス困難なものでした。そして1970年代には、プログラマーたちがApple IIやCommodore 64でBASICを書きながら成長しました。
1980年代にはGUIが主流になり始めましたが、それでもほとんどのプログラミングはテキストベースの端末で行われていました。1990年代と2000年代になってようやく、プログラミングがグラフィカルインターフェースへとシフトし始めました。皆さんも覚えているかもしれませんが、FrontPageやDreamweaverといったツールが、初心者がドラッグアンドドロップでウェブサイトを構築できるようにしました。
そしてVisual Studioのような新しいエディタやIDEが、プロフェッショナルが非常に大規模なコードベースで作業することを容易にしました。もちろん、私のお気に入りのテキストエディタであるSublime Textもここに加えなければなりません。皆さんの中にも使ったことがある方がいらっしゃると思います。素晴らしいエディタです。
そして今、AIによって、ソフトウェア構築はかつてないほどアクセスしやすく強力になっています。端末からグラフィカルインターフェースへのゆっくりとしたシフトとは異なり、AIでコードを書くという変化は本当に急速に進んでいます。数十年分の進歩がわずか数年で起きているのです。そして反復を重ねるごとに、インターフェースとUXが変化し、モデルがより野心的なタスクを達成できるようになっています。
コンテキストエンジニアリングとCursorの視点
そこで私は、コンテキストエンジニアリングと、過去数年間でコーディングエージェントがCursorの視点からどのように進化してきたかについてお話ししたいと思います。次のアクションを自動補完することから、完全に自律的なコーディングエージェントへと移行してきた過程をお見せします。
そして最後に、Cursorの最高経営責任者であるマイケルが、私たちがソフトウェアエンジニアリングの将来がどこへ向かうと信じているかについてお話しします。
それでは、タブ機能から始めましょう。Cursorにインスピレーションを与えた製品の一つがGitHub Copilotでした。これは自動補完のUXの改善とより優れたモデルによって、コードを書くことをはるかに簡単にできることを示しました。
私たちは2023年にタブの最初のバージョンをリリースしました。そしてその体験は、次の単語を予測することから次の行へ、そして最終的にはカーソルが次にどこへ移動するかを予測するところまで進化しました。タブは現在、1日あたり4億件以上のリクエストを処理しています。つまり、ユーザーがどの提案を受け入れ、どれを拒否するかについて、私たちは大量のデータを持っているということです。
これにより、既製のモデルから、次のアクション予測に特化したモデルのトレーニングへと移行しました。このモデルを改善するために、私たちはデータを使用して、受け入れられた提案につながる行動を積極的に強化し、拒否された提案を否定的に強化します。そしてこれをほぼリアルタイムで行うことができます。つまり、提案を受け入れると、30分後にはそのフィードバックに基づいてオンライン強化学習を使用してタブモデルが更新されているのです。
この体験を正しく実現するには、多くの反復が必要でした。提案の速度、提案の質、そして表示方法の一般的なUXの間には、微妙なバランスがあります。200ミリ秒より遅いと、フローから外れてしまいます。しかし、速いけれど役に立たない提案を見たくもありません。
ですから、最新リリースでは、表示する提案の数を減らしましたが、それらが受け入れられる確率についてより高い信頼性を持っています。私たちは、AIモデルがまだそれほど役に立っていない領域で、タブが本当に役立つことを発見しました。そしてここでのボトルネックは、実際には自分自身のタイピング速度なのです。
さて、ほとんどの人は1分間に約40語をタイプします。もちろん、皆さん全員が1分間に90語以上タイプすると確信していますが、そうですよね。ここには素晴らしいタイピストがたくさんいます。
では、AIモデルに私たちのためにもっとコードを書かせたらどうなるでしょうか。ここでコーディングエージェントが登場し、これがAIでコーディングする次の進化なのです。CursorやCodeXで見たように、製品内でモデルと直接対話し、コードブロック全体を作成または更新させることができます。
自律性のレベルと初期機能
Cursorで本当に重点を置いてきたことの一つは、モデルと作業する際の自律性のレベルをコントロールできるようにすることです。2023年に追加した最初の機能の一つは、インライン提案を追加するようモデルにプロンプトを送ることでした。これは現在の行と、より広範なファイルコンテキストを取得し、それをモデルに渡して差分を提案させるものでした。
その直後、私たちはコーディングエージェントへの最初のステップをリリースしました。それはComposerと呼ばれる機能で、長年のCursorユーザーファンの方々は覚えているかもしれません。初期バージョンの一つについて、ピクセル化されたTwitterのデモもここに含めました。これにより、より会話的なUIで複数ファイルの編集を行うことがはるかに簡単になりました。
そして2024年には、完全に自律的なコーディングエージェントを追加しました。これにより、モデルはツール呼び出しでより優れた性能を発揮するようになり、より多くのトークンを使用するようになりました。そしてCursorが自ら独自にコンテキストを収集できるようになったのです。以前のバージョンでは、そのすべてのコンテキストを事前に提供する必要があり、それは少し難しいものでした。
コンテキストエンジニアリングの最適化
それでは、Cursorエージェントハーネスを最適化してきた方法のいくつかについてお話ししましょう。最近、プロンプトエンジニアリングの進化としてのコンテキストエンジニアリングについて多くの議論がなされており、私個人としては本当に役立つと感じています。
モデルが向上するにつれて、高品質な出力を得ることは、特定のプロンプティングトリックについてのものではなくなってきています。もちろんそれらは依然として役立つこともありますが、より重要なのは、モデルに適切なコンテキストを与えることです。そして単なるコンテキストではなく、意図的なコンテキストです。
モデルは、コンテキストのサイズが増加するにつれて情報を思い出すのが下手になります。実際には、コンテキストウィンドウの限界に挑戦したくはありません。最小限の高品質なトークンを使用したいのです。そしてこれが、コードの検索が実際にコンテキストエンジニアリングにとって本当に重要で基本的である理由です。
より大規模なコードベースでコードを検索する例を見てみましょう。モデルに非常に強力なツールを与えると、コードが受け入れられる率を大幅に改善できることがわかりました。現在、多くのコーディングエージェントは、ファイルやディレクトリ全体で直接文字列一致を検索するために、grepやRip Grepのようなコマンドを使用しています。
新しいモデルがツール呼び出しでトレーニングされ、エージェントがツールの使用で向上するにつれて、検索品質は向上します。しかし、コードベースを自動的にインデックス化し、埋め込みを作成することで、検索をさらに改善できることがわかりました。
これによりセマンティック検索が可能になります。つまり、エージェントに「トップナビゲーションを更新して」と依頼できますが、ファイルが実際にはheader.tsxという名前だった場合でも、セマンティック検索によってエージェントは埋め込みを生成する検索プロセス中に正確なコードを迅速かつ正確に見つけることができます。
私たちはまた、既製の埋め込みモデルから、より正確な結果を生み出すのに役立つカスタムモデルのトレーニングへと移行しました。そして、セマンティック検索の使用のパフォーマンスを常にABテストしています。grepだけを使用する場合と比較して、ユーザーはより多くのフォローアップ質問を送信し、より多くのトークンを使用することがわかりました。ですから、セマンティック検索は本当に役立ちます。
しかし、最大の勝利の一つは、計算が発生する場所をシフトさせることです。エージェントが実際に呼び出される推論時ではなく、インデックス化中に事前に計算とレイテンシを費やします。言い換えれば、オフラインで重い作業を行っているため、パフォーマンスを犠牲にすることなく、またそれをユーザーに負担させることなく、実行時により速く安価な応答を得ることができるのです。
ですから、ここでの要点は、最良の結果を得るにはおそらくgrepとセマンティック検索の両方が必要だということです。そして、これらの結果のいくつかについて話す完全なブログ投稿を近日中に公開する予定です。
CLIとエージェントの拡張性
モデルにより良いツールを与えることは、品質の向上に役立ちます。しかし、これらのコーディングエージェントを実際に使用する際のUXはどうでしょうか。OpenAIのCodeXからClaudeまで、そしてCursor独自のCLIまで、コーディングCLIを使った多くの探求が行われてきました。ここでのアイデアは、モデル上の最も最小限の抽象化を見つけ、ハーネスを反復し、エージェントを拡張可能にすることです。
しかし、私たちはCLIがコーディングエージェントと作業する最終状態や最終目標だとは考えていません。私がターミナルについて気に入っているのは、コーディングエージェントが実行できる新しいサーフェスを開くことです。これはCLIで可能です。ウェブ上でも、スマートフォンからでも可能です。Slackでのバグレポートからでも可能で、私はこれをいつも使っています。
Linearのバックログアイテムから自動的にトリアージすることもできます。CLIベースのエージェントはスクリプト化可能なので、あらゆる種類の環境で使用できるため、本当に便利です。私たちは内部でこれを使用して、ドキュメントを自動的に書いたり、コードベースの一部を更新したりしています。そして、cursor-pを実行してプロンプトを入力するだけで、テキストや、さらにはJSONのような構造化された形式が返ってくるというシンプルなものにすることができます。
また、より特化したエージェントが必要になると私たちは考えています。これは今日の基調講演を見れば理にかなっています。昨年、私たちはAIモデルを使用してコードを書いたり編集したりするのではなく、コードを読んでレビューする実験を始めました。そして、コード内の意味のあるロジックバグを見つけるのに役立つBugbotという内部ツールを作成しました。
約6ヶ月間内部で使用した後、コードレビューで見逃していた多くのバグを実際にキャッチしていることがわかりました。そこで公開することにしました。そして面白いことに、実際にBugbot自体をダウンさせるバグをキャッチしました。もちろん、私たちは誤ってそれを無視してしまいました。そのため、Bugbotのコメントに本当に注意を払うことを学びました。
長期タスクとエージェントの計画
新しいモデルは、より長期的なタスクでも非常に優れた性能を発揮するようになっています。そこで、Cursor内でエージェントをより長く実行させる方法の一つは、事前に計画と調査をより多く行わせることです。これにより、構築しようとしているものの要件を検証し、途中で軌道修正する機会が得られるだけでなく、生成されるコードの品質が大幅に向上することもわかりました。これは理にかなっていますよね。モデルにはるかに高品質な入力コンテキストを与えているのですから。
そして、これをうまく行うには、「より良く計画せよ」といった単純なプロンプトの変更以上のものが必要です。実際には、計画の保存方法、ファイルの編集方法、そしてモデルに新しいツールを与えることについて、より深い製品統合が必要なのです。
また、エージェントがToDoリストを作成して管理できるようにすることも理にかなっています。これにより、モデルは作業中のタスクを忘れたり、トークンを無駄にしたりしないための重要なコンテキストを得ることができます。そして、常に参照できるメモのようなものを持つことができます。
私たちがまだ探求している領域の一つは、ToDoリストを取得して、コードベースという同じ真実の情報源にすることです。これは私個人が、完全に機能を備えたタスク管理ツールを必要としないような小規模プロジェクトで使用したいものです。
エージェントの拡張性のもう一つの重要な部分は、ワークフローをパッケージ化してチームと共有できるようにすることです。カスタムコマンドはプロンプトを共有する方法であり、ルールはすべてのエージェント会話に重要なコンテキストを含めることを可能にします。
私たちのエンジニアが内部で本当に役立つと感じている方法の一つは、コミット標準とガイドラインをパッケージ化し、それらをslashcommitに入れて、作業中のLinearチケットを渡すようにチケットを渡すことができるようにすることです。
私が気づいたもう一つのことは、コンテキストエンジニアリングのブレークスルーの多くが、実際には最初にユーザー空間で起こるということです。つまり、パワーユーザーである皆さん全員が、実際に本当にうまく機能するワークフローとパターンを見つけ出し、それらが採用されると、機能としてコア製品に戻ってくるのです。
計画、記憶、ルールについて見ると、実際にはすべてこのようなものです。チームといえば、これらのエージェントにコードを書いてもらいたいと思うでしょう。しかし、それには人間をループに入れておく必要があります。そのため、エージェントがシェルコマンドを実行しようとすると、Cursorは一度だけ実行したいか、もし快適であれば、将来自動実行するために許可リストに追加できるかを尋ねます。
そして、これらの設定はすべてコードに保存でき、特定のシェルコマンドやアクションをブロックすることを含め、チームと明示的に共有できます。最新リリースにはカスタムフックもあるので、エージェント実行のあらゆる部分にタップできます。たとえば、エージェントが終了したときに実行されるシェルスクリプトが必要な場合などです。
複数エージェントの管理
さて、ここまで多くの内容をカバーしてきました。コーディングエージェントは過去1年間でかなり進化しており、非常に強力なツールを与えると、どんどん良くなっています。そして、モデルがより有能になるにつれて、実際にはもう必要のない過度に正確な指示をシステムプロンプトから削除できるようになりました。
では、エージェントを大幅に長く実行させたらどうなるでしょうか。複数のコーディングエージェントを管理するための適切なインターフェースとは何でしょうか。エージェントを使ったコーディングを始めたばかりの場合、すぐに複数のエージェントを同時に使いこなそうとすることはお勧めしません。
正直に言って、9つのCLIを並行して実行することで、本当に生産的になっているでしょうか。おそらくそうではありません。まだそうではないでしょう。つまり、並行エージェントを実行するためにローカルマシンをセットアップする必要があるだけでなく、これらすべてのエージェントの出力をレビューするのも難しいのです。
ですから、このフォームファクターが最終目標や最終状態だとは考えていませんが、ここには可能性があります。過去数ヶ月間、私たちが内部で試してきたことの一つは、複数のコーディングエージェントを管理するための新しいタイプのインターフェースです。
そして、これは内部で本当に役立つことがわかりました。たとえば、フォアグラウンドにエージェントがいるけれども、コードベースについて質問したり、統合したいツールについて調査したり、小さなリファクタリングをしたりする必要がある場合などです。
このフォアグラウンドに高速なコーディングモデルがあると、本当にフローを維持できます。そして、並行エージェントがバックグラウンドで他のタスクを実行し、それらははるかに長く実行される可能性があります。これらはマシンのフォアグラウンドにある場合もあれば、クラウドのバックグラウンドにある場合もあります。
これらの決定のそれぞれには固有の制約があり、現時点では考えて多くの時間を費やす必要があります。クラウドにいる場合は、サンドボックス仮想マシンが得られ、非常に長期的なタスクには本当に優れていますが、トレードオフは通常起動に時間がかかり、作業している環境で初期設定をセットアップする必要があることです。
しかし、エージェントをローカルで並行して実行することは、異なる種類の分離です。ローカルマシン上の同じファイルセットを変更しようとしている複数のエージェントがいる場合、git worktreeのようなツールが必要になります。これにより、独立して実行できるコードベースの異なるコピーを持つことができます。
そして、異なるポートでワークツリーにアクセスしたり、データベースにアクセスしたりするなど、ローカル開発の他のすべての部分についても考える必要があります。そして、初期の段階で一部の開発者と話をしましたが、この多くがユーザーランドで起こっており、人々はこれを本当にうまく機能させるためにスクリプトやハックを書いています。
そして、私たちが取り組んでいて探求していることは、実際にこれをCursor製品にネイティブに組み込むことです。複数エージェントについて探求し始めたもう一つのアイデアは、モデルを互いに競わせることができるようにすることです。
GPT-5 high reasoningとmediumまたはlow reasoningを対決させて、最良の結果を選択したり、Cursorのエージェントで異なるモデルプロバイダー間で結果を比較したりできたらどうでしょうか。これは間もなく、任意のプロンプトと任意のモデルについて、1からnに移行するオプションになります。
エージェントのコンテキストエンジニアリングの一部は、自分の作業をチェックできるようにすることです。ですから、エージェントはコードを実行し、テストし、実際に正しく機能していることを検証できる必要があります。そのため、エージェントにコンピュータ使用を与えることを探求しています。
そうすれば、ブラウザを制御してネットワークリクエストを表示したり、DOMのスナップショットを取得したり、ページのデザインについてフィードバックを与えたりすることができます。ご覧のとおり、複数のコーディングエージェントを管理するための適切なインターフェース、適切な製品体験については、まだ解明すべきことがたくさんあります。
今お見せしたもののいくつかは、今日のCursorでベータ版として利用可能です。ですから、興味があれば試してみてください。そして、今月後半に安定版リリースを予定しています。しかし、将来的にコーディングエージェントとどのように作業したいかについて、皆さんのフィードバックをぜひお聞きしたいと思います。後で私を見つけて、それについて話しましょう。
ソフトウェアエンジニアリングの未来
そして、未来といえば、ソフトウェアエンジニアリングが次にどこへ向かうかについて話すために、マイケルをステージにお迎えしたいと思います。
ありがとう、リー。Cursorでの私たちの目標は、コーディングを自動化することです。私たちは、その半分がモデルの問題であり自律性の問題だと考えています。そして、その半分がソフトウェア構築の行為がどのように見えるかという人間とコンピュータのインタラクションの問題だと考えています。
私たちは、エンジニアがより野心的で、より創造的で、より充実感を得られるようにしたいのです。そして今日、私たちが一緒に創造できると信じている未来の姿を少しお見せしたいと思います。AIが、ソフトウェア構築の中で皆さんが愛している部分に取り組むためのより多くの時間を解放する未来です。
朝目覚めてCursorを開くと、退屈な作業がすべて既に処理されていることを想像してみてください。オンコールの問題は夜間に修正されトリアージされています。書きたくなかったボイラープレートは生成され、テストされ、マージする準備ができています。コードレビューが実際に楽しくなる世界も想像してください。
雑用に埋もれる代わりに、あなたのエネルギーは、そもそもエンジニアリングにあなたを引き付けたもの、つまり難しい問題を解決すること、美しいシステムを設計すること、そして重要なものを構築することに向けられます。
コードベース、チームのスタイル、そして製品センスを深く理解するエージェントを想像してください。長期間、本当に長期間作業した後に戻ってきて、より高レベルのプログラミング言語で作業を見せるエージェントです。アイデアを提案し、新しい方向性を探求するのを手伝い、複雑なプロジェクトを受け入れ、拒否、または改良できるピースに分解するエージェントです。
あなたの野心を拡張しますが、決してあなたの思考と判断を奪うことはないものです。エージェントには複雑すぎる問題がある場合、彼らは試したことを見せます。ランタイムログやデバッグツールを引き出して。決してゼロから始めることはありません。
これが私たちが目指している未来です。ソフトウェアを構築することが苦役というより遊びのように感じられ、創造性が焦点となる世界です。そして、これはこの部屋にいる最も野心的な人々でさえ考えるよりも早く実現可能だと思います。
このビジョンがあなたを興奮させるなら、ぜひお話ししたいと思います。そして、まだCursorを試していない方は、私たちはエージェントとエディタに多くの改善を導入しています。ぜひご意見をお聞かせください。ありがとうございました。
コメント