TL;DR
- Nuxt2/JS → Nuxt3/TS移行でCursorの制限（月500回）に早々に到達、Roo Codeでも一貫性維持に時間を要する
- Claude Codeを1週間試用した結果、依存関係の理解と長時間タスクの実行能力で圧倒的な差を実感
- Claude Code(Maxプラン)はCursorの5倍の価格だが、大規模リファクタリングやロングランタスクでは投資対効果が高い
- 日常的な小規模開発にはCursor、重厚なタスクにはClaude Codeの使い分けが最適か？
技術スタック
| 項目 | Before | After |
|---|---|---|
| フレームワーク | Nuxt2 | Nuxt3 |
| 言語 | JavaScript | TypeScript |
| 開発ツール | Cursor(Gemini 2.5 Pro) | Claude Code (Maxプラン) + Cursor(Gemini 2.5 Pro) |
背景・課題感
プロジェクトの背景
弊社では長年Nuxt2 + JavaScriptでフロントエンドを運用してきました。これまでリソース的に着手できずにいましたが、ようやく体制が整ったため、Nuxt3 + TypeScript移行プロジェクトを開始することになりました。
移行方針
- 全ての推奨実装を行うのではなく、レビューコストを考慮
- 破壊的変更は最小限に抑制
- 基本的な型定義と必要最小限の修正で完了させる
- 段階的移行によるリスク軽減
既存の開発環境
社内ではCursor(Businessプラン)を契約しており、日常的な機能拡張で大いに活用していました：
- Cursor + Gemini 2.5 Proで高速開発
- MCPによるFigma連携などの外部サービス統合
- 小〜中規模の新機能追加etcでは十分な性能を発揮
リファクタリング作業での壁
しかし、大規模リファクタリングを開始すると、Cursorに限界を感じました：
1. プレミアムリクエストの枯渇
- 月間500回の制限を作業1日目で消費
- 複数ファイルの依存関係を含むリファクタリングでは、すぐに上限に到達
2. コンテキスト制御の難しさ
- 大きなプロンプトになると指示以外のことを実行
- 「最小限の変更」を指示しても、より広範囲なリファクタリングを実施
- 変更差分の把握が困難になる問題
3. 不完全な依存関係理解
- ファイルの一部のみを読んで満足してしまう
- フォルダ構成の適切な把握ができない
- 依存先の変更に伴う呼び出し元の修正が不十分
Roo Codeでの試行錯誤
次にRoo CodeのBoomerang Tasksを試しました。
Boomerange Tasksでは、指示をベースに、タスクを細分化し、全体と統合する大タスクと、個別のタスクを行うサブタスクに分割されます。大タスクは、サブタスクの進行や、タスクの結果を次のサブタスクに渡します。サブタスクでは、コンテキストをリセットした上でタスクを実行し、結果を大タスクに返します。
大タスク ⇄ サブタスク A
⇄ サブタスク B
⇄ サブタスク C
サブタスクでコンテキストがリセットされるため、より正確にタスクをこなしくれるのではないかと期待していました。
実際のプロンプト概要：
## サブタスクA: SFC構造更新
- defineNuxtComponentでラップ、Options API維持、最小限変更
## サブタスクB: Vue機能移行
- v-model移行、filters置換、.native削除などVue3互換化
発生した問題：コンテキストの分断による一貫性の欠如
サブタスクごとにコンテキストをリセットすることで、修正内容の改善を期待して利用を開始したものの、この仕様が、リファクタリングにおいて、問題を引き起こしました。
(当たり前ですが、、)「前のサブタスクによる変更や、タスクAで守られたルールを、タスクBでは忘れてしまう」のです。
例えば、以下のような状況が発生しました。
-
サブタスクAにて、「
Options APIを維持する」というルールでコンポーネントを修正。 - 続くサブタスクBでは、コンテキストがリセットされているため
Options API維持のルールは忘れ去られます。 - 結果、サブタスクBは良かれと思って
Composition APIに書き換えてしまい、一貫性のないコードが生成されました。
例：実際に発生した不一致
// サブタスクAの実行後: dataプロパティは維持される
data() {
return { count: 0 }
}
// サブタスクBの実行後: Aのルールを無視してrefに変更してしまう
const count = ref(0) // ←「Options APIを維持する」という文脈が失われている
プロンプトを調整すれば、状況は改善するはずですが、プロンプト調整やセルフレビュー、修正コストを踏まえると、細かい粒度でCursorを使用する方が効率的だと感じました。
救世主、Claude Code
Claude Sonnet4やOpus4が登場し、上記課題の解決を期待して検証を行った結果、期待を上回る成果が得られました。
作業フローのBefore・After
Cursorでの作業コストetc
- 作業時間: 1日でも完了せず（制限により中断）
- 手動介入: 頻繁（依存関係の修正、一貫性チェック）
- 品質: 部分的な修正、テストエラー多発
- 一貫性: コンテキスト分断により不統一
Claude Codeでの作業コストetc
- 作業時間: 2-3時間で完了（約70%短縮）
- 手動介入: ほぼゼロ（最終確認のみ）
- 品質: 一貫性のある変更、テスト通過率向上
- 一貫性: プロジェクト全体を通した統一された修正
具体的な改善点
1. 指示に対する修正の正確性
- 指示以外のことを実行してしまう
+ 指示以外のことを実行しない
- 制御が困難、予期しない結果
+ 制御しやすく、期待通りの結果
2. 依存関係理解の優秀性
- ファイルの一部のみを読んで満足
+ ファイル全体の内容を読み込み
- フォルダ構成の把握が不適切
+ フォルダ構成の適切な把握
- 依存先→依存元の修正が不十分
+ 依存先→依存元の変更を一貫して実行
3. タスク完遂能力
- 短時間で中断、継続困難
+ 長時間の自律実行
- 単一ステップで停止
+ 複数ステップを完了まで継続
バーンダウンチャートをご紹介
こちらが実際のバーンダウンチャートです。
青ラインは理想線(作業当初の実績から現実的な理想のペースを設定しました)、赤ラインが実績を表しています。
すごくなだらかな下り坂だった赤線が、滝のように落ちるようになりました！Claude Codeを試し始めたのは5/25で、そこから急激にポイント消化できています。
青の線を見ると分かりやすいのですが、途中でタスクが増え、ポイントが増えていますが、Claudeパワーで押し切っています。
補足情報
1. Claude Codeの実行方法
Claude Codeをより安全かつ、自律的に実行するために、Dev Containerを使用しました。Homebrewなどのパッケージマネージャーを使用していれば、簡単にセットアップできます。
# Dangerous Skipモードでの実行
claude --dangerously-skip-permissions
２. 遭遇した問題と解決方法
API制限エラー（Opus 4使用時）：
- 問題：タスク中に何度かエラーにぶつかり、タスクが中断
- 対策：Sonnet 4で十分な品質と安定性があるため、固定化
コンテナ環境の必要性：
- 問題：ローカルマシン上での実行では細かめに承認が必要
- 対策：DevContainer + Dangerous Skipモードで完全自動化
まとめ
Claude Codeは大規模リファクタリングにおいて、Cursorの制限を大幅に超越する能力を示しました。特に以下の点で優秀です。
- 依存関係の理解力：プロジェクト全体を俯瞰した適切な変更
- タスク完遂能力：長時間の自律実行で人間の監視コストを削減
- 指示の正確性：創造性よりも確実性を重視した実行
Cursorと比較し、価格差（Personalプランだと約5倍）はありますが、重要なリファクタリングや時間のかかるタスクでは十分にペイする投資対効果があります。
リファクタリングなどの大規模タスクを控えていたり、細かいFBの連続でAIに疲れている方は、一度試してみることをオススメします。
今後は、Cursorは日常的な細かい作業のお供として利用し、Claude Codeは差分が多数のファイルにわたる大規模な変更や、長時間にわたる自律的なタスク実行の依頼先として使いたいと考えています。
Discussion