こんにちは。AI Native の田中です。本記事では、クライアントワークにおけるAI活用の実務として、Cursor Agents（GPT-5）とClaude Codeをどのように使い分けているか、そして速度と品質、コストのバランスをどう設計しているかを共有します。
前提：AIは"使う"から"運用設計する"へ
AI活用は、ツールを触ってみる段階から、「どの局面で、どのAIを、どんな粒度で使うか」を決める運用設計のフェーズへ移りました。案件の緊急度・重要度、品質要件、守秘や再現性などの制約をふまえ、適切にAIを配置することが成果を左右します。
私の基本方針は次のとおりです。
- Cursor Agents（GPT-5）：明確な要件に対して実装速度を最大化。高い緊急度や差分実装に最適。
- Claude Code：探索・検討・説明責任が必要なフェーズで合意形成と最適化を支援。
加えて、Cursor内のAutoモード（GPT-5とComposer-1の自動切り替え）も利用しています。ただし、どのモデルが選択されたかは明示されず、切り替えロジックも非公開のため、最終的なモデル選択判断は人間が行う——ここが運用の肝です。
使い分けの基本方針：緊急度×重要度で決める
比較表：Cursor Agents (GPT-5) vs Claude Code
| 項目 | Cursor Agents (GPT-5) | Claude Code |
|---|---|---|
| 適したフェーズ | 実装・開発フェーズ | 要件定義・検討フェーズ（実装も含めた全体） |
| 緊急度 | 高い（即日〜24時間以内） | 低い（数日以内） |
| 得意なタスク | 差分編集、既存コード修正、追加実装 | 要件整理、設計比較、ドキュメント化、実装まで含めた全体進行 |
| スピード | 非常に速い | やや時間がかかる |
| 精度 | 高い（仕様が明確な場合） | 慎重で選択肢が豊富 |
| コスト | $60/月（プロプラン） | $200/月（プロプラン） |
| 価値 | 納期短縮＝クライアント価値 | 実装時の迷い減少＝総工数削減 |
💡 関連記事： Claude Code、Cursor Agent、Codex CLIのより詳細な比較については、Claude Code比較記事をご覧ください。
高い緊急度／明確な要件 → Cursor Agents（GPT-5）
- 仕様が固まり、短時間で確実に仕上げたい実装
- 既存コードへのインテグレーション、微修正、ガード付き差分
- 回帰リスクを抑えつつリードタイムを圧縮したいケース
ペアプロの延長で差分編集まで到達できるため、テスト→レビュー→反映までが圧倒的に早い。多少のコストを払っても納期短縮の価値が大きい局面では、迷わずGPT-5を選択します。
緊急度が低い／探索・検討が多い → Claude Code
- 未確定要件の壁打ち、設計代替案の比較、仕様ドキュメント化
- サンプル設計、検証用プロトタイピング、リスクとトレードオフ整理
- テンプレート化・パターン化などナレッジ資産の整備
- 要件定義からタスク管理、実装まで含めた全体の進行管理
Claude Codeは最適解に近づくまでに時間がかかる一方、説明と合意形成に強い。検討フェーズで「考え抜く」ことにより、実装に入ってからの迷いが減り、総開発時間が結果的に短縮されます。また、タスク分解から実装まで一貫して進められるため、緊急度が高くないプロジェクト全体の進行にも適しています。
プラン設計とコスト観：速度のために"必要コスト"を先払い
- Cursor：プロプラン（$60/月）
- Claude Code：プロプラン（$200/月）
クライアントワークでは「早く終わる＝価値が高い」場面が多い。私の結論は、速度を買うコストは投資として妥当、というものです。とくに、クリティカルなデプロイや障害対応、顧客レビュー前の最終調整では、GPT-5の生産性が価値に直結します。
試行の記録：Cursor内でのComposer-1検証
Cursor内でGPT-5に加えてComposer-1（Cursor独自開発のAIエージェントモデル）も検証しました。Composer-1はソフトウェアエンジニアリングに特化した強化学習でトレーニングされており、推論能力が高く、複雑な設計やコンテキストの理解に強みがあります。しかし、私の案件特性（要件が具体的で、素早い差分実装が価値に直結する）では、GPT-5の迅速な差分編集能力のほうがフィットしました。結果的に、実装フェーズはGPT-5をメインに、複雑なロジック設計時はComposer-1を併用する形に落ち着いています。
プロダクト開発は「いま目の前のお客様に価値を返すこと」が第一。理想論ではなく、ユースケースごとの実測で運用を最適化していく——その意味で、上記は"暫定の最適"であり、今後も継続的に見直します。
Cursor内のAutoモード活用：便利だが透明性に課題
Cursor内でGPT-5とComposer-1を使い分ける際、Autoモードでタスクに応じたモデル自動選択も試しています。とくに探索的な実装フェーズでは、コストと精度のバランスを自動で調整できるため便利です。
⚠️ 注意： Autoモードはどのモデルが選択されたか明示されず、切り替えロジックも非公開です。そのため、「このタスクでGPT-5が使われたのか、Composer-1が使われたのか」を確認する手段がありません。実務では、出力の品質や速度から推測するしかないのが現状です。
また、「緊急度・重要度・リスク許容度」はプロジェクト固有の条件であり、Autoモードはこれらの文脈を理解できません。したがって、最終的なモデル選択判断は人間が行うべきです。将来的には、チケットのメタデータ（納期、影響範囲、可用性要件、変更リスク）から推奨モデルを自動選定する仕組みを導入し、レビューのみ人間が担う形にしたいと考えています。
実務ワークフロー：判断からリリースまで
- 受注・要件整理（共通）
- スコープ、期待値、品質制約、データの取り扱いを明確化
- 重要度・緊急度・安全性の3軸でタスクをタグ付け
- モデル選定（人間の意思決定）
- 高緊急・既存コード変更少 → Cursor Agents（GPT-5）
- 低緊急・検討と合意形成重視 → Claude Code
- 迷う場合はAutoで開始し、途中で切替
- 実装フェーズ（Cursor中心）
- 差分提案→最小編集→即時テスト→レビュー→反映
- 失敗時のロールバック手順を事前合意
- 仕様・説明資料（Claude中心）
- 設計方針の比較表、リスクとトレードオフの記述
- 顧客・社内向けの再利用可能テンプレートに格納
- 品質保証
- 事前の受け入れ条件（Definition of Done）を明文化
- セキュリティ・PII・監査ログの観点をチェックリスト化
- リリース／効果測定
- MTTR、差分サイズ、デプロイ回数、手戻り率、顧客満足度（NPS）
スピードと品質の両立：判断基準と運用のコツ
- 「多少のコストでも早く終わる」を正当化する基準を決める
- 例：納期24時間以内、影響範囲中以上、顧客レビュー直前
- レビューポリシーを分岐させる
- 高緊急：小さな差分で頻繁にデプロイ。ロールバック容易性を重視
- 低緊急：設計レビュー重視。ドキュメント負債を残さない
- 検証を「コードの外」にも置く
- データ品質、監査ログ、運用マニュアル、担当引き継ぎメモ
ケーススタディ：どちらを選ぶ？
| タスク内容 | 選択ツール | 理由 |
|---|---|---|
| LPの文言最終調整（今日の18時レビュー） | Cursor (GPT-5) | 高緊急・明確な要件・即時対応必要 |
| APIのデグレ疑い調査と暫定パッチ | Cursor (GPT-5) | 障害対応・短時間で修正必須 |
| 新規機能の設計方針A/B比較とリスク洗い出し | Claude Code | 低緊急・検討フェーズ・説明資料必要 |
| 提案書／要件定義テンプレートの整備 | Claude Code | ナレッジ資産化・再利用性重視 |
| 既存フォームのバリデーション微修正＋テスト追加 | Cursor (GPT-5) | 既存コード修正・即時テスト確認 |
セキュリティとコンプライアンス
クライアントワークでは、スピードと同じくらい守秘と再現性が重要です。
- 入力データの最小化：PIIや機密情報は原則モック化して扱う
- プロンプト・設定のバージョン管理：意思決定の痕跡を残す
- 出力の検証責任：最後は必ず人間がレビューする
まとめ：価値に直結する"速さ"を買う
私は、Cursorをプロ（$60）に、Claude Codeをプロ（$200）に上げています。今のところ、最適解に近いアウトプットに辿り着くまでわずかに時間がかかるタスクはClaude Codeに、緊急度が高く"確実に早く"仕上げたいタスクはCursorのAgents（GPT-5）に任せる運用が、最も価値に直結しています。結果として、案件や自社サービスの開発時間を安定的に確保できる。コストは「速度を買うための投資」と割り切っています。
Autoモデル設定はコストとパフォーマンスのバランスに有効ですが、緊急度や重要度といった文脈判断は、現時点では人間の役割です。ここを将来的に自動化し、より高い粒度で"モデル運用の意思決定"をシステム化する——そのロードマップも引き続き描いていきます。
将来への展望
そもそも、こういったモデルやClaude Code、Cursorといったツールの使い分けを開発者自身が考えなくても良い時代が来るのではないかと思っています。これはあくまで短期的な使い方になってしまうかもしれませんが、今足元ではコスト・出力の精度・スピード・タスク管理を総合的に判断して使い分けなければならない——これが今の開発において最も大変なところの一つでもあるかもしれません。
特に、Cursor 2.0でエージェント機能が大幅に強化されたことで、新たな可能性が見えてきました。将来的には、新規エージェントを自動的に立ち上げ、Gitワークツリーで複数のブランチを並行開発する仕組みが実現されるかもしれません。そうなれば、モデルの切り替えも、フィーチャーブランチごとに異なるモデル（GPT-5、Composer-1など）で自動実装させ、それぞれの精度を比較した上で、最終的に人間が判断するというワークフローまで自動化できる可能性があります。
既にCodex（GitHub Copilot）などで一部の開発者が実践しているかもしれませんが、モデルごとの実装を自動的に並行実行し、アウトプットを比較評価するという手法は、今後さらに民主化が進んでいくのではないかと考えています。これにより、開発者はモデル選択の負担から解放され、より本質的な意思決定に集中できるようになるでしょう。
本稿がその判断の参考になれば幸いです。
💡 関連記事： Claude Code、Cursor Agent、Codex CLIの実体験に基づいた詳細比較は、Claude Code・Cursor Agent・Codex CLIを徹底比較！実際に使って分かった3つの違いと今後注目すべき1つのモデルで解説しています。
参考リンク
- Introducing Cursor 2.0 and Composer（Cursor公式ブログ）
- Composer: Building a fast frontier model with RL（Cursor公式ブログ）
- Cursor Changelog（Cursor公式ドキュメント）
開発の進め方やコンサルティングのご相談はお気軽に
私たちのAI活用や開発スタイルについて、より詳しく知りたい方、具体的なご相談がある方は、下記よりお問い合わせください。要件整理からPoC、設計・実装、運用まで並走します。
