Cursor実践ガイド②：Agent Mode、リファクタリング、テスト生成

前回の入門編では基本操作を押さえました。今回はCursorの真価を引き出す中級テクニック。特にAgent Modeは、使いこなすと開発の進め方そのものが変わります。

Agent Mode：AIが自律的にコードを書く

Agent Modeは、Cursorの中で最も強力な機能です。通常のチャットが「聞いたことに答える」のに対して、Agent Modeは自分でファイルを読み、コードを書き、実行し、エラーを修正する。

起動方法

サイドチャット（Cmd+L）で、モデル選択の隣にあるドロップダウンから「Agent」を選択。あるいは Cmd+I でComposerを開いてAgentモードで使います。

使い方の例

例1：新機能の追加

ユーザープロフィールページを作ってください。
- /profile のルートを追加
- 名前、メール、アバターを表示
- 編集ボタンを押すとモーダルで編集できる
- 既存のデザインシステム（src/components/ui/）を使う

Agent Modeはこの指示を受けて、ルーティング設定、コンポーネント作成、スタイリングまで自律的にファイルを作成・編集します。途中で既存のコードを参照して、プロジェクトのコーディングスタイルに合わせてくれます。

例2：バグの修正

ログインページでメールアドレスにスペースが含まれているとエラーになるバグを修正して。
テストも追加して。

Agentがバグの原因を特定→修正→テスト追加まで一気通貫で実行。

例3：複数ファイルにまたがる変更

APIのレスポンス形式を { data: T } から { data: T, meta: { timestamp: string } } に変更して。
関連するすべてのファイルを更新して。

手動でやると影響範囲の調査だけで30分かかるような変更を、Agent が依存関係を追跡しながら処理してくれます。

Agent Modeのコツ

指示は具体的に。 「いい感じにして」ではなく、何を・どこに・どういうルールで作るかを明示する
差分を必ず確認する。 Agentが生成したコードは、マージ前に差分を一つずつチェック。盲目的にAcceptしない
小さく試す。 いきなり大きなタスクを投げず、まず小さな機能追加から。Agentの癖を掴んでから範囲を広げる

リファクタリング

既存コードの改善は、CursorのAI機能が最も活きる場面の一つ。

パターン1：関数の分割

長くなりすぎた関数を選択して Cmd+K：

この関数を、単一責任の原則に従って3〜4つの小さな関数に分割して。
関数名は処理の内容がわかるようにして。

パターン2：型の強化

JavaScriptからTypeScriptへの移行、あるいは既存のTypeScriptの型をより厳密にしたいとき：

このファイルのany型をすべて具体的な型に置き換えて。
推測できない場合はTODOコメントを残して。

パターン3：パフォーマンス改善

このコンポーネントの不要な再レンダリングを特定して、
useMemoやuseCallbackで最適化して。
変更理由をコメントで残して。

どのパターンでも「変更理由をコメントで」と追加するのがおすすめ。後から見返したとき、なぜその変更をしたのかがわかるようになります。

テスト自動生成

テストを書くのは面倒だけど重要。Cursorを使えば、テストの「書き始める心理的ハードル」を大幅に下げられます。

基本的な使い方

テストしたい関数やコンポーネントを選択して Cmd+K：

この関数のユニットテストを書いて。
- 正常系3パターン
- エッジケース2パターン
- エラーケース1パターン
- Vitestを使用

テスト対象が複雑な場合

サイドチャットでAgent Modeを使う方が向いています：

src/services/payment.ts のPaymentServiceクラスについて、
以下の観点でテストを書いて。

- 決済成功のフロー
- カード情報不正の場合
- タイムアウトの場合
- 二重決済の防止
- テストファイルは src/services/__tests__/payment.test.ts に作成
- 外部APIはモックする

Agentがテストファイルを作成し、モックの設定、テストケースの実装まで一気にやってくれます。

生成されたテストの扱い方

AIが生成したテストは、あくまで出発点です。以下を必ず確認してください。

テストが実際に意味のあるアサーションをしているか（「テストが通る」だけでは不十分）
エッジケースが本当にエッジケースか（ドメイン固有の知識が必要な場面はAIが弱い）
モックの設定が実際の挙動と一致しているか

コードレビューのアシスタントとして使う

自分やチームメンバーが書いたコードを、マージ前にCursorでレビューさせるテクニック。

変更したファイルを開いて、サイドチャットで：

このファイルの変更をレビューして。以下の観点でチェック。
- バグの可能性
- セキュリティ上の問題（SQLインジェクション、XSS等）
- パフォーマンスの懸念
- テストの漏れ
- コーディング規約への準拠

人間のレビュアーの代替にはなりませんが、明らかな問題を事前にキャッチするフィルターとして機能します。レビュー依頼を出す前にCursorでセルフチェックする習慣をつけると、レビューの差し戻し率が下がります。

デバッグの効率化

エラーが出たとき、エラーメッセージをコピーしてチャットに貼り付けるだけでも効果的ですが、もう一歩踏み込んだ使い方があります。

スタックトレースの解析

以下のエラーが出ました。原因と修正方法を教えて。
関連するファイルも確認して。

[スタックトレースを貼り付け]

Cursorはプロジェクト全体をインデックスしているので、スタックトレースに含まれるファイルを自動で参照し、原因箇所を特定してくれます。

「なぜ動かないか」を聞く

このコードは期待通りに動きません。
入力: [具体的な入力値]
期待する出力: [期待する結果]
実際の出力: [実際の結果]

原因を特定して修正して。

具体的な入出力を添えると、AIの問題特定精度が格段に上がります。「動きません」だけだと、的外れな回答が返ってくる確率が高い。

まとめ：中級者のワークフロー

ここまでの内容を踏まえた、日常的な開発ワークフロー：

新機能 → Agent Modeでスキャフォールディング → 差分確認 → 手動で微調整
バグ修正 → エラー内容をチャットに貼り付け → 原因特定 → Agent Modeで修正+テスト追加
リファクタリング → 対象コードを選択 → Cmd+Kで指示 → 差分確認
コードレビュー → マージ前にCursorでセルフレビュー

次回の「Cursor実践ガイド③」では、大規模プロジェクトでの活用、.cursorrulesの設計、MCP連携などの上級テクニックを取り上げます。

シリーズ: Cursor実践ガイド｜公開日: 2026年3月15日