はじめに:モデルが多すぎて選べない問題
Cursorを日常的に使っていると、必ずぶつかる壁があります。
それが「モデルが多すぎてどれを使えばいいかわからない」問題です。
TomoyaAnthropic系のClaudeやFable、OpenAI系のGPT5.6 sol・terra・Luna、GoogleのGemini、xAIのGrok 4.5、そしてGLM5.2……。
さらにCursor独自のComposer2.5まで加わり、選択肢は年々増える一方です。
しかし多くの人が契約しているのはProプラン。月々$20分の使用量しかない中で最高性能モデルを連発すると、あっという間に上限に達してしまいます。
Tomoya単一モデルだけを使い倒したいなら、むしろClaudeやGPT単体のプランに入った方が合理的なケースすらあります。
そこで今回は、Proプランでも無理なく使い続けられる「モデルの使い分け方」を、実際の運用ベースで紹介します。
個人開発は3段階でモデルを使い分ける
私が普段行っている個人開発では、作業を大きく3つの段階に分けています。
- 計画:要件を整理し、実装方針を固める段階
- 実行:計画に沿って実際にコードを書く段階
- チェック:書かれたコードをレビュー・修正する段階
土台がすでにあるプロジェクトなら既存コードを調査したうえで計画を立て、ゼロから作る場合はまず要件定義をMarkdownにまとめてから、それをインプットとして計画に落とし込みます。
Cursorにはこの「計画」を専用に行うための計画モードが用意されており、ここでどのモデルを使うかが、開発全体の質とコストを大きく左右します。
次のセクションでは、この「計画」段階でなぜ最高性能モデルを使うべきなのか、具体的に解説していきます。
計画段階では最高性能モデルを使え
計画段階で使うべきは、現時点での最高性能モデルであるFable5やGPT5.6 solです。
なぜここまで性能にこだわるのか。それは、計画段階こそがプロジェクト全体の設計図を決める工程だからです。
言語理解力や論理的な計画能力に長けたモデルを、いわば「PM(プロジェクトマネージャー)」として起用することで、後工程である実行・チェックの精度が大きく変わってきます。曖昧な指示や抜け漏れのある計画のまま実装に進んでしまうと、後になって手戻りが発生し、結果的にトークン消費も作業時間も増えてしまいます。
つまり計画段階への投資は、プロジェクト全体で見れば最も費用対効果の高い使い方だと言えます。
使用量が心配な方へ
「最高性能モデルを使うと使用量がすぐに尽きてしまうのでは」と不安に思う方も多いと思いますが、安心してください。
計画のみに使う場合、増加するのはせいぜいフロンティアの3%程度です。（検証済み）
理由はシンプルで、計画段階はそもそもトークンの消費量が限られているからです。FableやGPT5.6 solのような最高性能モデルは、長時間・大量のやり取りを伴う複雑な作業では大量のトークンを消費しますが、計画立案という比較的短いタスクではオーバースペックになるほどの消費量にはなりません。
逆に言えば、こうした最高性能モデルをちょっとした細かい作業にまで使ってしまうのは非効率です。適材適所を意識することが、Proプランで無理なく開発を続けるコツになります。
また、計画段階での調査(コードベースの読み込みなど)は基本的にComposer2.5 Fast(default)がサブエージェントとして担当するため、Fable5やGPT5.6 solが直接動く場面はそれほど多くありません。
この「サブエージェントに軽作業を任せる」設計自体が、使用量を抑えられる理由のひとつです。
実行段階では作業に適した低価格モデルを使え
計画が固まったら、次はいよいよ実行段階です。
ここで主役になるのが、Cursor独自モデルのComposer2.5です。
Composer2.5の最大の魅力は、超低価格でありながらコーディング能力においてClaude4.8 Opusに引けを取らないスコアを持っている点です。まさに「コーディングに特化したモデル」と呼ぶにふさわしい存在です。
計画段階でFable5やGPT5.6 solが練り上げた設計図を、このComposer2.5にそのままBuildingしてもらう。これが実行段階の基本の流れです。
最高性能モデルで方針を固め、実際の手を動かす部分はコストパフォーマンスに優れたモデルに任せる。この役割分担こそが、Proプランの限られた使用量の中で開発サイクルを回し続けるための鍵になります。
「実行は低価格モデルで大丈夫なのか」と不安になるかもしれませんが、計画段階でしっかり設計図ができていれば、Composer2.5は十分すぎるほどの実装力を発揮してくれます。
チェック段階では低価格〜ミドルモデルを使え
最後の工程が、実装されたコードを検証する「チェック」段階です。
「計画は最高性能モデルなのに、実行は少し劣るモデルで進めて品質にムラが出ないか?」と心配になる方もいるでしょう。だからこそ、このチェック段階を独立した工程として設けることが重要です。
本音を言えば、チェックにも最高性能モデルを使いたいところです。ただしここで最高性能モデルを投入すると、使用量が10%ほど増加してしまい、Proプランではやや無視できないコストになります。
とはいえ、本当に重要な局面であれば、ここは惜しまず最高性能モデルを使うべきです。良いプロダクトを作る上では欠かせない投資と言えます。
一方で、こつこつと着実に積み上げていくスタイルの開発であれば、ミドルモデルでもまったく問題ありません。今のモデルはどれを選んでも一定水準の優秀さがあり、エラーやバグもほぼ発生しませんし、万が一発生してもすぐに修正できます。
TomoyaGPT4時代は延々と続くエラーループとにらめっこすることも多々ありましたが、今はそうした苦労も減りました。
私自身がチェック段階でよく使っているのが、Grok4.5とGLM5.2 Maxです。
- Grok4.5:最近登場した新しいモデルで、低価格ながら優秀なスコアを持つ
- GLM5.2 Max:Maxグレードでも使用量の増加は3%程度に抑えられ、それでいてClaude4.8 Opusレベルの能力を発揮
Claude4.8 Opusを使い続けて総額$40かかるところを、これらのモデルなら$8程度で同等レベルの成果を得られる計算になります。
コストパフォーマンスの観点から見ても、チェック段階でこれらのモデルを選ぶ価値は十分にあると言えるでしょう。
まとめ:使用量を制するものが個人開発を制す
効率を求めて個人開発を続けていく上で、避けて通れないのが「使用量」というリソースの管理です。
- 計画:最高性能モデル(Fable5、GPT5.6 sol)
- 実行:低価格・高コスパモデル(Composer2.5)
- チェック:低価格〜ミドルモデル(Grok4.5、GLM5.2 Max)
この3段階の使い分けを意識するだけで、Proプランの限られた予算内でも、最高性能モデルの恩恵を受けながら開発を回し続けることができます。
Claudeをはじめとした市場のトレンドや、X(旧Twitter)上で話題になっているツイートに流されるのではなく、「自分の開発スタイルに合った使い分け」を日々模索し続けることが、開発者として大切な姿勢だと考えています。
誰かの正解をそのまま実行するのではなく、自分で試しながら最適解を見つけていくこと。そこにこそ、個人開発の面白さがあります。
皆さんはどのようにモデルを使い分けていますか?ぜひコメントで教えてください。この記事が役に立ったと思ったら、シェアもしていただけると嬉しいです。
コメント