Cursor が Claude 3.5 Sonnet の限界突破を検証
開発ツール「Cursor」が、Claude 3.5 Sonnet を用いて最難問の 1% に該当する複雑な課題を解決できることを実証し、AI エージェントの自律的推論能力における新たな到達点を示した。
キーポイント
最難問タスクの実証
Cursor は Claude 3.5 Sonnet を「 hardest 1% of problems(最難問の 1%)」と定義される極めて複雑な問題に適用し、その能力を実際に検証した。
推論能力の限界突破
従来のモデルでは困難とされていた高度な論理的思考や多段階の計画立案を必要とするタスクにおいて、同モデルが安定して成功する可能性を示した。
開発ツールとの統合効果
IDE である Cursor と LLM の連携により、単なるコード生成を超えた、複雑なシステム設計やデバッグにおける自律的な問題解決能力が引き出された。
重要な引用
How Cursor knew Claude Fable 5 was ready for the hardest 1% of problems
applying it to the hardest 1% of problems
影響分析・編集コメントを表示
影響分析
この記事は、大規模言語モデル(LLM)が単なる情報生成ツールから、複雑な問題解決を担う自律的なパートナーへと進化しつつあることを示す決定的な証拠の一つです。特に開発現場における実用性の限界を超えつつある現状は、ソフトウェアエンジニアリングの未来像や AI エージェントの役割拡大に大きな影響を与えるでしょう。
編集コメント
「最難問の 1%」という基準での成功は、AI の推論能力が実社会の複雑な課題に耐えうるレベルに達したことを示唆する画期的な事例です。開発ツールとの連携によるシナジー効果も注目すべき点であり、今後はより自律的なコーディング支援への期待が高まります。
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 の利用を開始する*
原文を表示
Cursor is an AI coding agent for building professional software. It supports every major frontier model alongside Cursor's own, which makes the company an unusually neutral judge of how each one actually performs.
Nate Schmidt is the engineer who maintains that scorecard. He works on evals and model behavior at Cursor: studying how models succeed, how they fail, and what makes a developer quietly switch away from one mid-task. When colleagues and customers want a read on a new release, they come to him.
Over time, Schmidt's team noticed that public benchmark scores and real developer reception to these models had stopped lining up, so they built their own: CursorBench.
CursorBench was built to capture the messy, underspecified ways engineers actually prompt their models. One eval task is just a stack trace pasted in with the single word "fix," and the model has to infer the intent, find the root cause, and validate the change on its own. Another tells the model the wrong module is broken, to see whether it challenges the user's assumption or follows it into a dead end.
When Claude Fable 5 ran the eval, the model achieved 72.9% at Max effort, setting a new high, and capturing what agentic coding tools were capable of when paired with the right models.

But when Schmidt was using the model on his own engineering workflows and personal tests, he'd stopped having to repeat his goals. The constant babysitting—reminding the model of context, spelling out the solution, auditing the results—wasn't necessary anymore. He could hand over a problem, from the gnarly refactor he was putting off to reasoning about nuanced edge cases, and Claude Fable 5 could solve it.
"I don't feel like I have to bootstrap Claude Fable 5 to understand the world I exist in and the problem I'm trying to solve," Schmidt says. "The model just has a sense of it out-of-the-box."
Reasoning about the entire mission
When Schmidt's team runs a new model through CursorBench, the right answer is table stakes. What they're scoring is whether the model understood what it was being asked.
"Many evals look like this: here's a well-defined problem, here are the constraints, go fix it. But the prompts we get from real users don't really look like that," Schmidt says. "The model has to infer that the user has a problem and what they're trying to convey, identify the root cause, fix it, validate the fix, and report back."
Claude Fable 5 scored so well on these ambiguous tasks, the Cursor team started to feel suspicious.
"One of two things is happening: either the model's very smart, or the model is cheating," he says. So the team looked into the traces, reading the model's actual reasoning on the hardest tasks, the ones where the prompt looks simple but cracking it requires understanding the whole system.
"We just kept seeing the model dig out wins that no other model was doing previously," he says. It was also getting there with fewer operations: token-efficient relative to the work it completed.
Then Schmidt put Claude Fable 5 on one of his favorite personal tests: landing on the moon.
A few weeks earlier he'd wired Claude Opus into a programmable space-flight simulator with a one-line prompt—build a rocket and land it on the moon—and let it run on a second monitor for twelve to sixteen hours. The model would launch, run out of fuel in orbit, add a lot more fuel, then fail to clear the atmosphere because the rocket was now too heavy.
He re-ran the experiment with the same blank-slate prompt, this time using Claude Fable 5. A few minutes in, the rocket went up, parked in low orbit, and came back down. Same failure as before. Then Schmidt read the transcript.
"Fable decided it wouldn’t go to the moon on its first attempt. It wanted to do an initial mission just to go into orbit and collect telemetry, then use that to inform the next trip." A few attempts later, the engine noise on his second monitor stopped. There was a lander on the moon. The whole run took a couple of hours, against Opus's twelve-plus with no result.
"With Opus, it was doing local reasoning—thinking about what just happened and what's immediately about to happen," Schmidt says. "With Fable it's global reasoning. It's thinking about the entire mission."

When to reach for the global optimum
Schmidt has settled on a simple rule for when to use Claude Fable 5 over cheaper, less intelligent models.
"If you have a good sense of what the path from A to B looks like, you might not need Fable. If you're at A and you have no idea where B is, Fable is an excellent choice,” he says. "When I want to build something the right way, Fable is the first model I think of."
Claude Fable 5 has also allowed his team to focus on projects the team had previously shelved—rewrites everyone agreed would be better but nobody could justify spending weeks on—because the model can carry enough of the skeleton. "It lowers the activation energy to work on these types of tasks," Schmidt says. "It lets us move in search of a global optimum rather than a local one."
It also changes how the team coordinates. Cursor runs lean, with intense individual ownership and few standups. Now, before touching shared code, Schmidt has an agent read his teammate's recent commits and flag conflicts, so neither of them has to stop what they’re doing to check in.
To balance cost and performance, his team pairs Claude Fable 5 with faster, lighter models for routine work and brings it in for the problems where capability is the constraint. In that configuration, he says, the combination is the most effective setup they've run.
“If I'm getting into a really gnarly problem–the p99 of problems–the thing I'm trying to optimize for is time to solution,” he says. “And I think Fable is the best model for solving our hardest problems.”

What's next
Despite putting the model through its paces on CursorBench and sending it to the moon, Schmidt is still looking for Claude Fable 5’s limits. Next, he wants to see how long the model can manage a back-end system unattended; days-to-weeks runs are his next experiment. Inside Cursor, the team is using the model to hunt performance bottlenecks and user pain points proactively rather than waiting for reports, and to build the more sophisticated, closer-to-reality eval environments that will measure whatever comes next.
"There's a class of problems people weren't even thinking about because it didn't seem approachable," he says. "With Fable, I'm excited to push at that."
*Get started with *Claude Fable.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み