Cursor が Claude 3.5 Sonnet の限界突破を検証

Cursor は、プロフェッショナルなソフトウェア開発を支援する AI コーディングエージェントです。主要な最先端モデルすべてをサポートし、自社製モデルも用意しているため、各モデルの実際の性能を評価する際、極めて中立な立場で判断できる存在となっています。

その評価基準を管理しているのがエンジニアのネイト・シュミット氏です。氏は Cursor においてモデルの評価や挙動の研究を担当しており、モデルがどのように成功し、どこで失敗するのか、また開発者が作業中に特定のモデルから静かに離れてしまう要因是什么かを解明しています。同僚や顧客が新リリースの性能を確認したいと依頼する際、彼らは必ずシュミット氏に相談します。

長年の調査を通じて、シュミット氏のチームは「公開されたベンチマークスコア」と「実際の開発者からの評価」が一致しなくなっていることに気づきました。そこで彼らは独自の評価基準「CursorBench」を構築しました。

CursorBench は、エンジニアたちが実際にモデルに指示を出す際に見られる、曖昧で不完全な状況を再現するように設計されています。例えば、単にスタックトレースを貼り付けて「fix」という一言だけを送るタスクでは、モデルがその意図を推測し、根本原因を見つけ、自身で変更を検証する必要があります。また別のタスクでは、「誤ってモジュールが壊れている」という情報をモデルに与え、ユーザーの前提を疑い反論するのか、それともその誤った前提に従って行き詰まるのかを試します。

Claude 3.5 Sonnet（原文：Claude Fable 5）がこの評価基準でテストされた際、最大限のパフォーマンスを発揮して 72.9% のスコアを達成し、新しい最高記録を更新しました。これは、適切なモデルと組み合わせることで、エージェント型コーディングツールが到達できる可能性の限界を示す結果となりました。

Claude Fable 5 は Max Effort で 72.9% を達成し、新たな最高記録を叩き出しました。しかし、シュミット氏が自身のエンジニアリングワークフローや個人的なテストでこのモデルを実際に使ってみると、目標を繰り返して指示する必要がなくなっていることに気づきました。

文脈の再確認や解決策の詳細説明、結果の監査といった、常態化していた「ベビーシッター」的な介入は不要になりました。彼は難解なリファクタリングから、微妙なエッジケースへの推論まで、あらゆる課題をモデルに任せるだけで済むようになったのです。

「Claude Fable 5 を起動して、自分が置かれている世界や解決すべき問題を理解させる必要はありません」とシュミット氏は語ります。「このモデルは、最初からその感覚を持っているんです」

ミッション全体への推論

シュミット氏のチームが新しいモデルを CursorBench で評価する際、正解を出すことは当然の前提です。彼らがスコアリングしているのは、モデルが「何を求められているのか」を理解できているかどうかです。

「多くの評価基準では、『ここに明確な問題があり、制約条件はこれだ。これを直せ』という形式で提示されます」とシュミット氏は指摘します。「しかし、実際のユーザーから届くプロンプトはそうではありません。モデルには、ユーザーに課題があることを推測し、何を伝えたいのかを汲み取り、根本原因を特定し、修正を行い、その結果を検証して報告するまでを一貫して行う能力が求められます」

Claude Fable 5 はこうした曖昧なタスクでも驚異的なスコアを記録したため、Cursor チームは逆に疑念を抱き始めました。

「起こっているのは、この二つのどちらかだ。モデルが非常に賢いのか、それとも何か裏技を使っているのか」と彼は言う。そこでチームは、プロンプトは一見シンプルだが、システム全体を理解しないと解けないような難問における、モデルの実際の推論プロセスを追跡して読み解いた。

「以前から他のどのモデルも達成できていなかった勝利を、私たちは何度も確認できたのです」と彼は語る。また、完了した作業量に対して必要な操作数が少なく、トークン効率にも優れていたという点も特徴だった。

その後、シュミット氏は、自分が最も信頼する個人的なテストの一つとして、月面着陸に Claude Fable 5 を挑戦させた。

数週間前、彼は Claude Opus をプログラム可能な宇宙飛行シミュレーターに接続し、「ロケットを構築して月に着陸させる」という一行のプロンプトだけで実行させた。そして、それを別のモニターで 12〜16 時間ほど走らせた。モデルはロケットを発射したが、軌道上で燃料切れになり、さらに大量の燃料を追加したものの、今度は重くなりすぎて大気を抜けられずに失敗してしまった。

シュミット氏は、同じく何もない状態からのプロンプトで実験を再実行した。今回は Claude Fable 5 を使用した。数分後、ロケットは上昇し、低軌道に投入されたが、再び着陸には至らず、以前と同じ結果の失敗に終わった。そこでシュミット氏は、その実行ログ（トランスクリプト）を読み始めた。

フェイブルは、初回挑戦で月面着陸に挑むつもりはありませんでした。まずは軌道投入とテレメトリーデータの収集という初期ミッションを完遂し、その結果を次の飛行に活かす方針だったのです。

試行を繰り返すうち、2 回目のモニターからエンジン音が止まりました。そこにはすでに月面に着陸したランダーがありました。この一連の作業は数時間で完了しましたが、オプス（Opus）が 12 時間以上かけても結果を出せなかったのと対照的です。

「オプスは局所的な推論を行っていました。直前の出来事や、今まさに起きようとしていることだけに焦点を当てていたのです」とシュミット氏は説明します。「一方、フェイブルはグローバルな推論を行います。ミッション全体を見渡して思考しているのです」

Cursor は、実際の開発作業をシミュレートしたタスクでモデルを評価するための内部ベンチマーク「CursorBench」を全モデルに適用しています。

グローバル最適解を求めるべきタイミング

シュミット氏は、より安価で知能が低いモデルではなく Claude Fable 5 を使うべきか否かの判断基準として、シンプルなルールを定めています。

「A から B への道筋が明確にイメージできるなら、フェイブルは不要かもしれません。しかし、A にいるのに B がどこにあるのか見当もつかない場合こそ、フェイブルが最適な選択肢です」と彼は語ります。「正しい方法で何かを構築したいと考える時、私が最初に思い浮かべるのはフェイブルです」

Claude Fable 5 の登場により、チームは以前棚上げしていたプロジェクトに再び注力できるようになりました。誰もが「書き直せばもっと良くなる」と認めつつも、「数週間かけるコストに見合わない」と判断して手をつけられなかった案件です。モデルがコードの骨格を十分に担ってくれるおかげで、こうしたタスクに取り組む際の心理的・技術的なハードル（活性化エネルギー）が下がったのです。シュミット氏はこう語ります。「これにより、私たちは局所的な最適解に固執するのではなく、より広い視点でのグローバルな最適解を探求できるようになりました。」

また、チームの連携方法も変化しました。Cursor は少人数で構成され、個人の責任範囲が明確で、定例ミーティング（スタンドアップ）も最小限です。現在では、共有コードを編集する前に、シュミット氏がエージェントに同僚の直近のコミット履歴を読み込ませ、競合がないかを確認しています。これにより、双方が作業を中断して手動で確認を行う必要がなくなりました。

コストとパフォーマンスのバランスを取るため、チームは日常的なタスクには高速で軽量なモデルを使い、能力がボトルネックとなる複雑な問題に対してのみ Claude Fable 5 を投入するハイブリッド構成を採用しています。シュミット氏によれば、この組み合わせこそが現在までに試した中で最も効果的な設定だといいます。

「非常に難易度の高い問題、つまり p99（上位 1%）の課題に直面した場合、私が最適化しようとしているのは『解決までの時間』です。そして、我々の最難関問題を解決するには、Fable が最適なモデルだと確信しています。」

ネイティブ・シュミット氏は、新しいモデルをさまざまな評価基準でテストしています。その中には、宇宙飛行シミュレーターでの実地試験も含まれています。

次のステップ

CursorBench での厳しき検証や月面への送出といった試練を経ていても、シュミット氏はまだ Claude Fable 5 の限界を探り続けています。次は、バックエンドシステムを無人でどれほど長く運用できるかを検証する実験です。数日から数週間にわたる長期運転がその対象となります。

Cursor 社内では、このモデルを活用してパフォーマンスのボトルネックやユーザーの不満点を、報告を待つのではなく能動的に発見しています。また、次世代の評価基準となる、より洗練された現実味のある評価環境の構築にも取り組んでいます。

「これまで人々が『手が出せない』と感じていて、問題として認識さえしていなかった課題の一種があります」とシュミット氏は語ります。「Fable なら、その領域に挑戦できるはずです。そうしてこそ、私は興奮を覚えます。」

*Claude Fable の利用を開始する*