はじめに
Cursorで開発を進める際、「Planモード」と「Build（Planの実行）」のフェーズで、皆さんはどのLLMモデルを選択していますか？
「とりあえずAutoにしておけばいい」「最新のモデルをずっと使えばいい」と考えているとしたら、AIの真のポテンシャルを引き出せていないかもしれません。
結論から言うと、2026年2月現在のAIコーディングにおけるベストプラクティスは、**「日常タスクにはComposer 1.5/Autoを使い、高難度タスクではClaude Opus 4.6に手動で切り替える」**ことです。
かつて最適とされた「o3-miniでPlanを書き、Claudeでビルドする」というモデル・リレー戦略は、2025年末のCursor 2.0リリースとモデルの急速な進化により、大幅にアップデートが必要になりました。
本記事では、SWE-bench Verified、Terminal-Bench 2.0、Aider Polyglotといった客観的ベンチマーク、Cursor公式ブログの情報、および海外コミュニティでの議論に基づき、各フェーズにおける最適なモデル選択の根拠を解説します。
1. 2026年2月のモデル勢力図：まず全体像を把握する
具体的なワークフローに入る前に、現在のLLMコーディング能力の勢力図を客観的データで確認しましょう。
重要な前提：ベンチマークは複数存在し、それぞれ別物である
AIコーディング能力を測るベンチマークは複数あり、それぞれ運営組織も測定対象も異なります。記事で混同されがちなので、まず整理します。
| ベンチマーク | 運営 | 測定対象 | URL |
|---|---|---|---|
| SWE-bench Verified | SWE-bench Team | GitHub Issueの解決能力（Python中心、500タスク） | swebench.com |
| SWE-bench Pro | Scale AI | より複雑な実コードベースの修正能力（多言語、1,865タスク） | scale.com |
| Terminal-Bench 2.0 | Laude Institute | ターミナル上でのエージェント型操作能力 | （別サイト） |
| Aider Polyglot | Aider (Paul Gauthier) | 6言語にまたがるコード編集・差分適用能力（225問） | aider.chat |
| SWE-rebench | 独立研究チーム | SWE-bench再評価（統一的なスキャフォールドで再実行） | swe-rebench.com |
SWE-bench Verified 公式リーダーボード
SWE-bench公式サイト（swebench.com）のVerifiedタブでは、mini-SWE-agent v2という統一されたスキャフォールド（最小限のbash環境のみを使うReActエージェント）で全モデルを公平に評価しています。
2026年2月の公式リーダーボード上位は以下の通りです。
| 順位 | モデル | 備考 |
|---|---|---|
| 1 | Claude 4.5 Opus (high reasoning) | Anthropic |
| 2 | Gemini 3 Flash (high reasoning) | |
| 3 | MiniMax M2.5 (high reasoning) | MiniMax（中国、オープンウェイト） |
| 4 | Claude Opus 4.6 | Anthropic |
| 5 | GLM-5 (high reasoning) | Zhipu AI（中国） |
| 6 | GPT-5.2 (high reasoning) | OpenAI |
| 7 | Claude 4.5 Sonnet (high reasoning) | Anthropic |
| 8 | Kimi K2.5 (high reasoning) | Moonshot AI（中国） |
ソース: SWE-bench公式 - Verified Leaderboard（Verifiedタブ → Agent: mini-SWE-agent v2を選択）、Simon Willison - SWE-bench February 2026 leaderboard update
注意：自己報告スコアとの違い
各モデル提供企業は、自社開発のスキャフォールド（エージェントフレームワーク）を使って独自にSWE-bench Verifiedを実行し、その結果を発表しています（例：Anthropicは80.8%、80.9%等）。これらの数値はサードパーティのリーダーボード集約サイト（marc0.dev等）に掲載されますが、公式サイトの統一スキャフォールドによる結果とは異なります。スキャフォールドの品質がスコアに10〜20ポイント以上の差を生むことが確認されています。
本記事では、公式リーダーボードの結果を優先して引用します。
ソース: Simon Willison - SWE-bench February 2026 leaderboard update（*「ラボによる自己報告ではなく、公式チームが統一条件で実行した結果であることが重要」*という趣旨のコメント）
Terminal-Bench 2.0（SWE-benchとは別のベンチマーク）
Terminal-Bench 2.0は、Laude Instituteが運営するSWE-benchとは完全に別のベンチマークです。AIがターミナル上でエージェントとして動作する能力を測定します。SWE-benchの公式サイトにはこのベンチマークのタブはありません。
| 順位 | モデル/エージェント | スコア |
|---|---|---|
| 1 | Codex CLI (GPT-5) | 77.3% |
| 2 | GPT-5.3-Codex | 75.1% |
| 3 | Droid + Claude Opus 4.6 | 69.9% |
| 4 | Claude Opus 4.6（Anthropic自己報告） | 65.4% |
| 5 | Composer 1.5 | 47.9% |
| - | Claude Sonnet 4.5 | 41.6% |
ソース: Cursor Blog - Introducing Composer 1.5（Composer 1.5のTerminal-Bench 2.0スコアを公式に報告）、DigitalApplied - Cursor Composer 1.5 Guide、marc0.dev - SWE-Bench Leaderboard February 2026（Terminal-Bench 2.0の比較表）
ここで重要なのは、Composer 1.5がClaude Sonnet 4.5（41.6%）を上回る47.9%を記録している点です。Cursor独自のモデルが、フロンティアモデルの一角を超えています。
Aider Polyglot（コード編集・差分適用能力）
Aiderのpolyglotベンチマークは、C++、Go、Java、JavaScript、Python、Rustの6言語にまたがる225の難問でLLMのコード編集能力を測定します。
| 順位 | モデル | スコア |
|---|---|---|
| 1 | Claude Opus 4.5 | 89.4% |
| 2 | GPT-5 | 88.0% |
| 3 | Gemini 2.5 Pro | 82.2% |
| 4 | Grok 4 | 79.6% |
Aider PolyglotでもClaude系がトップを維持しており、コード編集・差分適用というCursorのBuildフェーズに直結するタスクにおけるClaude系の優位性は依然として健在です。
SWE-rebench（独立した再評価ベンチマーク）
SWE-rebenchは、独立した研究チームがSWE-benchを統一的なスキャフォールドで再評価するプロジェクトです。
「Claude Opus 4.6がリーダーボードの1位を獲得。比較的低いSEM（標準誤差）は、他のモデルと比較してこのベンチマークでの安定したパフォーマンスを示唆している。Claude Codeのpass@5は他の全モデルを上回る。」
2. ゲームチェンジャー：Cursor 2.0とComposerモデルの登場
2025年末、Cursorは大型アップデートとなるCursor 2.0をリリースし、開発体験を根本から変えました。
Composerモデルとは何か
Composerは、Cursor自身が開発した初のプロプライエタリ・コーディングモデルです。
- MoE（Mixture-of-Experts）アーキテクチャを採用し、実際のコードベースの中で強化学習（RL）により訓練
- 250トークン/秒で生成。同等知能のモデルと比較して約4倍の高速性
- トレーニング中は、ファイル検索、エディタ、ターミナルコマンド、セマンティックサーチなどの実際の開発ツールにアクセスした環境で学習
ソース: Cursor Blog - Composer: Building a fast frontier model with RL、VentureBeat - Cursor releases first in-house LLM, Composer
Composer 1.5：RLを20倍スケール
2026年2月9日にリリースされたComposer 1.5は、前モデル（Composer 1）から大幅に進化しています。
- 強化学習を20倍にスケール。ポストトレーニングの計算量がプリトレーニングの計算量を上回るという前代未聞の規模
- Adaptive Thinking（適応的思考）: 簡単な問題には少ない思考トークンで高速に応答し、難しい問題には深く推論
- Self-Summarization（自己要約）: コンテキストが溢れそうになると、学習済みの要約を生成して探索を継続。再帰的に繰り返すことで、精度を落とさず長いタスクを処理
Cursor公式は以下のように述べています。
「Composer 1.5はTerminal-Bench 2.0においてSonnet 4.5を上回るスコアを記録したが、最良のフロンティアモデルには及ばない」
ソース: Cursor Blog - Introducing Composer 1.5、Cursor Blog - Increased Agent Usage
Auto + Composerの使用量枠の大幅拡大
Cursorは2026年2月11日、全個人プラン（Pro / Pro Plus / Ultra）において使用量枠を再編しました。
- Auto + Composer枠: AutoまたはComposer 1.5を選択時、大幅に増加した使用量が適用
- API枠: Claude Opus 4.6などのフロンティアモデルを手動選択した場合、月$20以上のAPI使用量が適用（従来通り）
- Composer 1.5はComposer 1の3倍の使用量（ローンチ時期には一時的に6倍）
つまり、AutoやComposer 1.5を使う方がはるかに多くのリクエストを消費でき、コスト効率が良い設計になっています。
3. Planモード（計画作成）：エージェント時代の新しいPlan
Plan Modeの仕組み
Cursorの公式Plan Modeは2025年10月に導入されました。エージェントの入力でShift + Tabを押すと有効になります。
- AIがコードベースをリサーチし、関連ファイルを探索し、ドキュメントを確認し、明確化のための質問を返す
- ファイルパスやコード参照を含むMarkdownファイルとして計画を生成
- 計画を直接インラインで編集でき、満足したら「Build」で実装に移行
Planモードに最適なモデル
日常的なPlan作成：Composer 1.5 / Auto
Composer 1.5のAdaptive Thinkingは、計画作成においても有効です。簡単な機能追加やリファクタリングの計画なら、十分な品質で高速に生成できます。Auto + Composer枠で大量に使えるため、気軽にPlanを何度でも書き直せます。
複雑なアーキテクチャ設計：Claude Opus 4.6
複雑な要件定義や、大規模なリファクタリングの計画では、最高峰の推論力が必要です。
- SWE-bench Verified公式で4位（mini-SWE-agent v2使用）、SWE-rebenchでは1位を獲得
- 1Mコンテキストウィンドウ（ベータ）: Opus系モデルとして初めて100万トークンのコンテキストに対応。巨大リポジトリの全体像を把握したPlan作成が可能に
- 128Kトークン出力: 非常に詳細な計画を一度に出力可能
ソース: LogRocket - AI dev tool power rankings Feb. 2026（「Claude 4.6 Opusは80.8%のSWE-benchスコア、1Mコンテキストウィンドウ（ベータ）、128K出力でデビュー」）、SWE-rebench Leaderboard
超巨大リポジトリの初期分析：Gemini 3 Pro / Gemini 3 Flash
数百のファイル群が存在するモノレポなど、とにかく大量のコードを一度に読み込ませたい場合は、Geminiシリーズの数百万トークンを処理できるコンテキストウィンドウが有効です。
特にGemini 3 Flashは、SWE-bench Verified公式で2位を記録するなど、コーディング能力自体も非常に高い水準にあります。軽量モデルでありながらProに匹敵する実力を持ち、コストも低いため、大量のコードを読み込ませるPlanフェーズの初期段階に向いています。
ソース: SWE-bench公式 - Verified Leaderboard、SWE-rebench（「Gemini 3 Flash PreviewはGemini 3 Pro Previewをpass@1でわずかに上回った（57.6% vs 56.5%）。これはGoogleのSWE-bench Verified結果と一致する」）
4. Buildモード（実装）：差分適用の正確性は依然として重要
Plan（指示書）が完成したら、次は「Build」で実際のファイル群にコードを適用します。
Build時のモデル選択がなぜ重要なのか
Aider Polyglotベンチマークが示しているのは、コードの問題を解く力と、それを既存ファイルの文脈に合わせて正確に差分適用する力は、別のスキルであるということです。
Aiderの測定では、モデルが出力した編集が指定フォーマットに従っているか（Percent using correct edit format）も同時に測定されます。いくらロジックが正しくても、Diff適用でフォーマットが崩れれば手戻りが発生します。
ソース: Aider - Code editing leaderboard、Aider Polyglot - Epoch AI
Buildモードに最適なモデル
日常的なBuild：Composer 1.5 / Auto
Composer 1.5はCursorのツール（ファイルエディタ、ターミナルコマンド、セマンティックサーチ）の中で直接訓練されているため、Cursorの差分適用フォーマットとの親和性が最も高いモデルです。Terminal-Bench 2.0でClaude Sonnet 4.5を上回る47.9%を記録しており、日常のBuildタスクには最適です。
高精度が要求されるBuild：Claude Opus 4.6 / Claude Sonnet 4.5
Aider PolyglotでClaude Opus 4.5が89.4%でトップ、SWE-bench VerifiedでもClaude系がトップ3のうち2つを占める（1位と4位）現状、高難度の差分適用にはClaude系が依然として強いです。
特に以下のような場面では、API枠を消費してでもClaude系に切り替える価値があります。
- 複数ファイルにまたがる大規模リファクタリング
- 既存の複雑なロジックへの機能追加
- テストを壊さずにインターフェースを変更する作業
5. 「Autoは避けるべき」は本当か？：2026年の検証
かつて「Autoは避ける」ことが推奨されていましたが、2026年2月現在、この主張は再検討が必要です。
直近のテスト（2026年2月、TypeScript/Reactプロジェクト）では、Autoモードは手動でSonnetを選択した場合と同等以上の結果を示しました。テストを実施した開発者は以下のように結論しています。
「『Autoモードがあなたのアウトプットをダウングレードしている』という懸念は、少なくともこれらのタスクタイプに関しては成立しない。Autoは測定可能な全ての指標で、手動のSonnet選択と同等かそれ以上だった。」
ただし、このテストは5タスク・クリーンなプロジェクトという限定的な条件であり、大規模で複雑なコードベースでの結果は異なる可能性がある、とも付記されています。
ソース: DEV Community - I Tested Whether Cursor's Auto Mode Actually Picks the Right Model
また、Cursorの公式フォーラムでも、Auto vs 手動選択についてフルスタックエンジニアの議論が行われています。
6. エージェント中心の新しいワークフロー
Cursor 2.0以降、ワークフローは「チャット + 手動切り替え」から**「エージェント中心のオーケストレーション」**へと移行しています。
マルチエージェントの並列実行
Cursor 2.0では、最大8つのAIエージェントを同時に並列実行できます。例えば、1つがリファクタリング、1つがテスト修正、1つがUI調整を行い、それぞれをブランチやPRのように切り替えて監督できます。
Background Agents
Ultra / Teams / Enterpriseユーザーは、2026年2月12日からBackground Agentsを利用できます。
- Plan-First Architecture: エージェントが事前に完全な依存関係分析を行ってから変更を開始
- Cross-Module Awareness: モジュール間の関係をスキャンし、副作用を編集前に予測
- PR-Quality Output: テスト、ドキュメント、リファクタリングを単一のアトミック操作として出力
メインエージェントがタスクをサブエージェント（Terminal / Docs / Test / Refactor）に分解して並列処理するため、従来の「PlanモデルとBuildモデルを手動で切り替える」オペレーション自体が不要になりつつあります。
7. 結論：2026年2月版「最強のワークフロー」
以上のベンチマークデータ、公式情報、コミュニティの検証結果を総合すると、Cursorにおける現時点のベストプラクティスは以下のようになります。
推奨ワークフロー
| フェーズ | 推奨モデル | 理由 |
|---|---|---|
| 日常のPlan + Build全般 | Composer 1.5 / Auto | 高速・低コスト・Cursorに最適化。Auto+Composer使用量枠が大幅に大きい |
| 複雑なアーキテクチャ設計 | Claude Opus 4.6 | SWE-rebench 1位、1Mコンテキスト（ベータ）で巨大リポジトリにも対応 |
| 精緻なDiff適用・大規模リファクタリング | Claude Opus 4.6 / Sonnet 4.5 | Aider Polyglotで89.4%（Opus 4.5）。差分適用精度でトップ |
| 超巨大リポジトリの全体把握 | Gemini 3 Flash / Gemini 3 Pro | 数百万トークンのコンテキスト + SWE-bench Verified公式2位（Flash） |
| コスト最優先の大量リクエスト | Composer 1.5 | Auto枠で消費、API枠を温存できる |
実践のポイント
- まずはComposer 1.5 / Autoで始める: 日常の80%以上のタスクはこれで十分。高速でコスト効率が良い
- 壁にぶつかったらClaude Opus 4.6に切り替える: 複雑な設計判断や、Composerでは手戻りが発生するタスクに限定して使う
- Autoを恐れない: 現在のAutoは以前より賢くなっており、手動選択と同等の品質を出せるケースが多い
- Background Agentsを活用する: タスクを分解してエージェントに任せることで、人間はアーキテクチャ設計とレビューに集中できる
コラム：ベンチマークの「落とし穴」にも注意
最後に注意点を1つ。各モデル企業が発表する自己報告のSWE-bench Verifiedスコアと、SWE-bench公式サイトでの統一スキャフォールド（mini-SWE-agent v2）による結果には大きな差があります。
各企業は自社が最適化したエージェントフレームワーク（スキャフォールド）を使って計測するため、スキャフォールドの品質がスコアに10〜20ポイント以上の差を生みます。ベンチマークスコアを比較する際は、同じスキャフォールドで実行された結果かを必ず確認しましょう。
さらに、SWE-bench Verifiedのデータ汚染問題も指摘されています。OpenAI自身の調査により、GPT-5.2、Claude Opus 4.5、Gemini 3 Flashといった全てのフロンティアモデルが、SWE-bench Verifiedの特定のタスクに対してゴールドパッチを逐語的に再現できることが判明しています。OpenAIはVerifiedのスコア報告を停止し、SWE-bench Proへの移行を推奨しています。
ソース: Morph - What is SWE-Bench Pro?（「OpenAIの自社監査により、全フロンティアモデルがVerifiedタスクに対して汚染されていることが判明」）、Scale AI - SWE-Bench Pro
したがって、ベンチマークスコアは参考指標として活用しつつ、自分のプロジェクト・コードベースで実際にテストすることが、結局は最善の「モデル選択戦略」です。
コラム：同じコードでも消費する「コンテキスト量（トークン）」はモデルによって違う？
Cursorでプロジェクト全体を読み込ませる際、「Claude 4.6とGemini 3 Proで、コンテキストの消費量は同じですか？」という疑問を持つ方がいます。
結論から言うと、「同じテキストやコードを読み込ませても、消費するコンテキスト量（トークン数）はモデルによって全く異なります」。
各社で異なる「トークナイザー（Tokenizer）」の仕様
AIは入力されたテキストをそのまま読むのではなく、「トークン（Token）」という最小単位に分割して処理します。この分割ルール（辞書）をトークナイザーと呼びますが、開発企業ごとに採用している技術が異なります。
-
OpenAI (GPT/Codex系):
tiktoken(o200k_baseなど) を使用 - Anthropic (Claude系): 独自のBPE（Byte-Pair Encoding）トークナイザーを使用
- Google (Gemini系): 独自のSentencePieceベースのトークナイザーを使用
ソース: Anthropic API Documentation - Tokenization、Google Cloud Vertex AI - Token limit and counting
日本語やコード記号での「トークン消費効率」の差
英語であれば「1単語 ≒ 1トークン」になりやすいですが、日本語（漢字・ひらがな）やプログラミングの特殊記号は、モデルによって分割のされ方が大きく異なります。
たとえば、あるモデルでは「関数」を2トークンで消費するのに対し、別のモデルでは1トークンで済む場合があります。この蓄積により、同じリポジトリを読み込ませても、最終的な消費トークン数に10%〜30%以上の差が生まれることが確認されています。
Cursorにおける実践的な対策
- 日常タスク: Composer 1.5 / AutoならCursorに最適化されたトークン効率で動作するため、コンテキスト上限を意識する必要が少ない
- 巨大リポジトリのPlan作成: 数百万トークンのコンテキストを持つGemini 3 Flash / Gemini 3 Proを指定することで、コンテキスト溢れ（Context Limit Exceeded）を回避
- 特定ファイルの精緻なBuild: 変更対象が絞り込めている状態なら、Claude Opus 4.6 / Sonnet 4.5に切り替えて実装させるのがベスト
参考ソース一覧
ベンチマーク・リーダーボード（公式）
- SWE-bench公式 - Verified Leaderboard（タブ: Verified / Multilingual / Lite / Full / Multimodal）
- SWE-bench Pro (Scale AI)
- SWE-rebench Leaderboard
- Aider LLM Leaderboards
- Aider Polyglot (Epoch AI)
- Vellum - Best LLM for Coding
ベンチマーク・リーダーボード（サードパーティ集約サイト）
- marc0.dev - SWE-Bench Leaderboard February 2026（自己報告スコアを含む）
- vals.ai - SWE-bench
- Epoch AI - SWE-bench Verified
Cursor公式情報
- Cursor Blog - Introducing Plan Mode（2025年10月）
- Cursor Blog - Composer: Building a fast frontier model with RL（2025年10月）
- Cursor Blog - Introducing Composer 1.5（2026年2月）
- Cursor Blog - Increased Agent Usage（2026年2月）
- Cursor Forum - Introducing Composer 1.5
- Cursor Forum - Share your experience with Composer 1.5!
モデル分析・比較
- Simon Willison - SWE-bench February 2026 leaderboard update
- LogRocket - AI dev tool power rankings Feb. 2026
- marc0.dev - Best AI for Coding 2026: SWE-Bench Breakdown
- Morph - What is SWE-Bench Pro?
- DigitalApplied - Cursor Composer 1.5 Guide
- Codecademy - Cursor 2.0: New AI Model Explained
コミュニティの検証・議論
- DEV Community - I Tested Whether Cursor's Auto Mode Actually Picks the Right Model（2026年2月）
- Cursor Forum - Best Practices for Model Selection: Is 'Auto' mode reliable?（2026年1月）
- GitHub - cursor-ai-tips（2026年2月更新）
メディア記事
- VentureBeat - Cursor releases first in-house LLM, Composer（2025年12月）
- NearForm - Cursor vs. Copilot: What tool has the best planning mode?（2025年12月）
- Prismic - Cursor AI Review 2026