T-CREATOR

Cursor プロンプト定番 30：仕様化・分割統治・根拠提示・差分出力の句型集

Cursor プロンプト定番 30：仕様化・分割統治・根拠提示・差分出力の句型集

AI エディタ「Cursor」を使いこなすには、適切なプロンプトの書き方が重要です。特に複雑な開発タスクでは、単に「これを作って」と指示するだけでは期待通りの結果を得られません。

本記事では、Cursor で効果的に開発を進めるための「句型（プロンプトパターン）」を 30 個厳選して紹介します。仕様化、分割統治、根拠提示、差分出力という 4 つの観点から、実務で即使えるテクニックを解説していきます。

句型早見表

#カテゴリ句型名概要使用場面
1仕様化要件定義句型機能要件を明確化プロジェクト開始時
2仕様化ユースケース指定利用シーンを具体化機能設計時
3仕様化制約条件明示技術的制約を列挙アーキテクチャ設計時
4仕様化入出力定義データ形式を規定API 設計時
5仕様化エラー条件指定異常系を網羅エラーハンドリング実装時
6分割統治段階的実装指示小さな単位で実装複雑な機能開発時
7分割統治レイヤー分離指示責務を層ごとに分割アーキテクチャ構築時
8分割統治ファイル分割要求モジュールごとに分離コード整理時
9分割統治機能単位分割機能ごとに実装大規模開発時
10分割統治テスト分割指示テストケースを分割テスト実装時
11根拠提示技術選定理由選択の根拠を要求技術選定時
12根拠提示実装パターン理由設計判断の説明コードレビュー時
13根拠提示エラー原因分析エラーの根本原因デバッグ時
14根拠提示パフォーマンス根拠性能判断の理由最適化時
15根拠提示セキュリティ判断安全性の根拠セキュリティ実装時
16差分出力変更箇所明示修正部分のみ表示コード修正時
17差分出力追加コード指定新規追加部分のみ機能追加時
18差分出力削除指示不要コードの除去リファクタリング時
19差分出力修正前後比較ビフォーアフターコードレビュー時
20差分出力マーカー付き出力変更箇所に印レビュー効率化時
21複合型仕様 → 分割 → 実装段階的開発フロー新機能開発時
22複合型分析 → 根拠 → 提案問題解決フローバグ修正時
23複合型設計 → 根拠 → 実装設計駆動開発アーキテクチャ構築時
24複合型差分 → 理由 → テスト変更管理フロー保守開発時
25複合型要件 → 分割 → 差分段階的リファクタリングコード改善時
26効率化テンプレート指定定型フォーマット利用繰り返し作業時
27効率化コンテキスト継承前提条件の引き継ぎ連続作業時
28効率化バッチ処理指示複数ファイル一括処理大量修正時
29品質管理チェックリスト適用品質基準の確認リリース前
30品質管理ベストプラクティス要求業界標準の適用コード品質向上時

背景

Cursor におけるプロンプトの重要性

Cursor は AI によるコード生成を支援する強力なツールですが、その性能を最大限に引き出すには「どう伝えるか」が鍵となります。曖昧な指示では意図しないコードが生成され、手戻りが発生してしまいます。

従来のエディタでは、開発者自身がすべてのコードを書いていました。しかし AI エディタでは、開発者は「設計者」「指示者」としての役割が強くなり、プロンプトを通じて AI に意図を正確に伝える必要があります。

プロンプトパターンが生まれた理由

実務で Cursor を使い続けると、特定の場面で効果的なプロンプトの「型」が見えてきます。これらは以下のような課題を解決するために自然発生的に生まれました。

  • 仕様の曖昧性: 要件が明確でないと、AI は想定外の実装をしてしまう
  • 複雑性の爆発: 大きなタスクを一度に指示すると、品質が低下する
  • 判断の不透明性: AI の選択理由がわからず、レビューしにくい
  • 変更管理の困難: 全コードを再生成されると、差分確認が大変になる

これらの課題に対応するため、句型（定型的なプロンプトパターン） が有効であることがわかってきました。

以下の図は、プロンプトの質が開発プロセス全体に与える影響を示しています。

mermaidflowchart TB
  dev["開発者"] -->|プロンプト| cursor["Cursor AI"]
  cursor -->|コード生成| code["生成コード"]
  code -->|レビュー| review["品質チェック"]
  review -->|OK| deploy["デプロイ"]
  review -->|NG| rework["手戻り"]
  rework -->|再指示| cursor

  style rework fill:#ffcccc
  style deploy fill:#ccffcc

プロンプトの質が低いと、手戻りループに入ってしまいます。句型を使うことで、最初から高品質なコードを生成しやすくなるのです。

課題

Cursor 利用時によくある問題

Cursor を使い始めた開発者が直面する典型的な問題は以下の通りです。

1. 生成コードが期待と異なる

「ログイン機能を作って」という指示だけでは、AI はどの認証方式を使うべきか、エラーハンドリングをどこまで実装すべきかがわかりません。結果として、後から大幅な修正が必要になります。

2. コード全体が再生成されてしまう

既存のファイルに機能を追加したいだけなのに、ファイル全体が書き直されてしまうことがあります。これでは差分レビューができず、意図しない変更が混入するリスクが高まります。

3. AI の判断根拠がわからない

「なぜこの実装方法を選んだのか?」「他の選択肢はなかったのか?」といった疑問に対して、AI からの説明がない場合、コードレビューや保守が困難になります。

4. 大きなタスクで品質が低下

「EC サイトを作って」のような大きすぎる指示では、AI は全体設計を考慮せず、断片的なコードを生成してしまいます。結果として、統一性のない低品質なコードベースができあがります。

以下の図は、プロンプトの粒度と生成コードの品質の関係を示しています。

mermaidflowchart LR
  subgraph large["大きすぎる指示"]
    large_prompt["ECサイトを<br/>作って"]
    large_result["統一性のない<br/>低品質コード"]
  end

  subgraph vague["曖昧な指示"]
    vague_prompt["ログイン機能を<br/>作って"]
    vague_result["期待と異なる<br/>実装"]
  end

  subgraph good["適切な句型"]
    good_prompt["認証方式:JWT<br/>エラー:401返却<br/>DB:PostgreSQL"]
    good_result["高品質で<br/>意図通りのコード"]
  end

  large_prompt --> large_result
  vague_prompt --> vague_result
  good_prompt --> good_result

  style large_result fill:#ffcccc
  style vague_result fill:#ffcccc
  style good_result fill:#ccffcc

これらの問題を解決するために、句型を使った体系的なプロンプト設計が必要になります。

句型が解決する問題の整理

句型は以下の 4 つの観点から問題を解決します。

#観点解決する問題
1仕様化要件の曖昧性、期待と異なる実装
2分割統治タスクの複雑性、品質の低下
3根拠提示判断の不透明性、レビュー困難
4差分出力全体再生成、差分確認の困難

次のセクションでは、これらの観点ごとに具体的な句型を紹介していきます。

解決策

1. 仕様化句型（5 パターン）

仕様化句型は、要件を明確に AI に伝えるためのパターンです。曖昧さを排除し、期待通りの実装を得るために使います。

1-1. 要件定義句型

機能要件を構造的に伝える句型です。

typescript// 悪い例
「ユーザー登録機能を作って」

// 良い例
「以下の要件でユーザー登録機能を実装してください:
- 必須項目: email, password, username
- バリデーション: emailは RFC5322準拠, passwordは8文字以上
- 既存ユーザーチェック: emailの重複を禁止
- 成功時: 201ステータスとユーザーIDを返却
- 失敗時: 400エラーとエラーメッセージを返却」

この句型により、AI は必要な実装要素をすべて把握できます。抜け漏れが減り、一度の指示で完成度の高いコードが得られます。

1-2. ユースケース指定句型

利用シーンを具体的に示すことで、実装の方向性を明確にします。

typescript// 句型テンプレート
「以下のユースケースに対応する実装をしてください:
ユースケース 1: [シーン1の説明]
  - 入力: [具体的なデータ]
  - 処理: [期待する動作]
  - 出力: [結果の形式]

ユースケース 2: [シーン2の説明]
  ...
」

// 具体例
「以下のユースケースに対応するログイン機能を実装してください:
ユースケース 1: 初回ログイン
  - 入力: email, password
  - 処理: 認証後、アカウント設定画面へリダイレクト
  - 出力: JWTトークン + リダイレクトURL

ユースケース 2: 通常ログイン
  - 入力: email, password
  - 処理: 認証後、前回のページへリダイレクト
  - 出力: JWTトークン + リダイレクトURL」

ユースケースを明示することで、AI はエッジケースも含めた実装を考慮できます。

1-3. 制約条件明示句型

技術的制約を列挙し、実装の選択肢を絞り込みます。

typescript// 句型テンプレート
「以下の制約条件下で実装してください:
技術スタック:
  - 言語: [言語名とバージョン]
  - フレームワーク: [フレームワーク名]
  - データベース: [DB種類]
パフォーマンス要件:
  - レスポンスタイム: [時間]
  - 同時接続数: [数値]
セキュリティ要件:
  - 認証方式: [方式名]
  - 暗号化: [暗号化方式]」

// 具体例
「以下の制約条件下でAPI実装してください:
技術スタック:
  - 言語: TypeScript 5.0
  - フレームワーク: Next.js 14 App Router
  - データベース: PostgreSQL 15
パフォーマンス要件:
  - レスポンスタイム: 200ms以内
  - ページネーション: 50件/ページ
セキュリティ要件:
  - 認証方式: JWT (有効期限1時間)
  - パスワード: bcryptでハッシュ化」

制約条件を明示することで、AI は適切な技術選択を行い、要件を満たす実装を生成できます。

1-4. 入出力定義句型

API やメソッドの入出力を明確に定義します。

typescript// 句型テンプレート
「以下の入出力仕様で[機能名]を実装してください:
入力:
  - パラメータ1: 型, 説明, 例
  - パラメータ2: 型, 説明, 例
処理:
  - [ステップ1の説明]
  - [ステップ2の説明]
出力:
  - 成功時: ステータスコード, データ形式, 例
  - 失敗時: エラーコード, エラー形式, 例」

// 具体例
「以下の入出力仕様でユーザー検索APIを実装してください:
入力:
  - query: string, 検索キーワード, 例: "yamada"
  - page: number, ページ番号(1始まり), 例: 1
  - limit: number, 1ページあたりの件数, 例: 50
処理:
  - PostgreSQLで部分一致検索
  - createdAtの降順でソート
  - ページネーション適用
出力:
  - 成功時: 200, { users: User[], total: number, page: number }
  - 失敗時: 400, { error: string, code: string }」

入出力を明確にすることで、型安全性が高く、ドキュメント化しやすいコードが生成されます。

1-5. エラー条件指定句型

エラーハンドリングを網羅的に指定します。

typescript// 句型テンプレート
「以下のエラー条件を処理してください:
エラー1: [条件]
  - 検知: [検知方法]
  - レスポンス: [ステータスコード, メッセージ]
  - ログ: [ログレベル, 内容]
エラー2: [条件]
  ...」

// 具体例
「以下のエラー条件を処理してください:
エラー1: バリデーション失敗
  - 検知: zodスキーマバリデーション
  - レスポンス: 400, { error: "Validation failed", fields: [...] }
  - ログ: warn, バリデーションエラー詳細
エラー2: データベース接続失敗
  - 検知: try-catchでPrismaエラーをキャッチ
  - レスポンス: 500, { error: "Internal server error" }
  - ログ: error, スタックトレース含む
エラー3: 認証失敗
  - 検知: JWT検証失敗
  - レスポンス: 401, { error: "Unauthorized" }
  - ログ: info, 失敗したトークン(ハッシュ化)」

エラー条件を明示することで、堅牢なエラーハンドリングが実装され、運用時のトラブルシューティングが容易になります。

2. 分割統治句型(5 パターン)

大きなタスクを小さく分割し、段階的に実装を進めるためのパターンです。

2-1. 段階的実装指示句型

複雑な機能を段階ごとに実装します。

typescript// 句型テンプレート
「以下の順序で段階的に実装してください:
ステップ1: [最小機能の説明]
  - ゴール: [このステップで達成すること]
  - 実装: [具体的な実装内容]
ステップ2: [機能追加の説明]
  - ゴール: [このステップで達成すること]
  - 実装: [具体的な実装内容]
...
各ステップ完了後、動作確認してから次へ進んでください。」

// 具体例
「以下の順序でユーザー管理機能を段階的に実装してください:
ステップ1: ユーザー作成API
  - ゴール: 基本的なCRUD操作の作成機能のみ
  - 実装: POST /api/users エンドポイント、最小限のバリデーション
ステップ2: バリデーション強化
  - ゴール: 入力値の厳密なチェック
  - 実装: zod追加、エラーメッセージ詳細化
ステップ3: データベース永続化
  - ゴール: Prismaでデータ保存
  - 実装: Prismaスキーマ、マイグレーション、CRUD実装
各ステップ完了後、cURLでテストしてから次へ進んでください。」

段階的に実装することで、各ステップでのレビューが容易になり、問題の早期発見が可能になります。

2-2. レイヤー分離指示句型

アーキテクチャの層ごとに実装を分割します。

typescript// 句型テンプレート
「以下のレイヤー構造で実装してください:
レイヤー1: [層の名前]
  - 責務: [この層の役割]
  - ファイル: [ファイル名やディレクトリ]
レイヤー2: [層の名前]
  - 責務: [この層の役割]
  - ファイル: [ファイル名やディレクトリ]
依存関係: レイヤー1 → レイヤー2 の方向のみ許可」

// 具体例
「以下のレイヤー構造でユーザー管理機能を実装してください:
レイヤー1: プレゼンテーション層
  - 責務: HTTPリクエスト/レスポンスの処理
  - ファイル: app/api/users/route.ts
レイヤー2: ビジネスロジック層
  - 責務: バリデーション、ビジネスルール適用
  - ファイル: lib/services/userService.ts
レイヤー3: データアクセス層
  - 責務: データベース操作
  - ファイル: lib/repositories/userRepository.ts
依存関係: プレゼンテーション → ビジネスロジック → データアクセス」

レイヤー分離により、テストしやすく、保守性の高いコードが得られます。

2-3. ファイル分割要求句型

モジュールごとにファイルを分割します。

typescript// 句型テンプレート
「以下のファイル構成で実装してください:
ファイル1: [パス]
  - 役割: [このファイルの責務]
  - エクスポート: [公開する関数・型]
ファイル2: [パス]
  - 役割: [このファイルの責務]
  - エクスポート: [公開する関数・型]
...」

// 具体例
「以下のファイル構成で認証機能を実装してください:
ファイル1: lib/auth/types.ts
  - 役割: 認証関連の型定義
  - エクスポート: User, AuthToken, AuthError型
ファイル2: lib/auth/jwt.ts
  - 役割: JWT生成・検証ロジック
  - エクスポート: generateToken, verifyToken関数
ファイル3: lib/auth/middleware.ts
  - 役割: 認証ミドルウェア
  - エクスポート: authMiddleware関数
ファイル4: lib/auth/index.ts
  - 役割: 公開APIの集約
  - エクスポート: 全モジュールの再エクスポート」

ファイル分割により、コードの見通しが良くなり、複数人での並行開発が容易になります。

2-4. 機能単位分割句型

機能ごとに独立した実装を行います。

typescript// 句型テンプレート
「以下の機能を独立して実装してください:
機能1: [機能名]
  - 入力: [入力パラメータ]
  - 出力: [出力形式]
  - 依存: [他機能への依存]
機能2: [機能名]
  ...
各機能は独立してテスト可能にしてください。」

// 具体例
「以下の機能を独立して実装してください:
機能1: メール送信
  - 入力: SendEmailInput型(to, subject, body)
  - 出力: Promise<SendEmailResult>
  - 依存: なし(環境変数からSMTP設定を取得)
機能2: メールテンプレート生成
  - 入力: TemplateType, TemplateData
  - 出力: { subject: string, body: string }
  - 依存: なし
機能3: ユーザー招待メール送信
  - 入力: User型
  - 出力: Promise<void>
  - 依存: 機能1と機能2を組み合わせ
各機能は独立してテスト可能にしてください。」

機能を独立させることで、単体テストが書きやすくなり、再利用性が向上します。

2-5. テスト分割指示句型

テストケースを体系的に分割します。

typescript// 句型テンプレート
「以下のテストケースを実装してください:
正常系:
  - ケース1: [シナリオ]
  - ケース2: [シナリオ]
異常系:
  - ケース3: [シナリオ]
  - ケース4: [シナリオ]
境界値:
  - ケース5: [シナリオ]」

// 具体例
「以下のテストケースをJestで実装してください:
正常系:
  - ケース1: 有効なemailとpasswordでログイン成功
  - ケース2: JWTトークンが正しく生成される
異常系:
  - ケース3: 存在しないemailでログイン失敗(404)
  - ケース4: 間違ったpasswordでログイン失敗(401)
  - ケース5: 無効なemailフォーマットでバリデーションエラー(400)
境界値:
  - ケース6: パスワード7文字でバリデーションエラー
  - ケース7: パスワード8文字で成功」

テストを体系的に分割することで、網羅的なテストカバレッジが得られます。

3. 根拠提示句型(5 パターン)

AI の判断理由を明確にし、レビューや保守を容易にするパターンです。

3-1. 技術選定理由句型

技術選択の根拠を説明させます。

typescript// 句型テンプレート
「[機能名]を実装し、以下の点について理由を説明してください:
- 採用した技術・ライブラリとその理由
- 他の選択肢と比較した結果
- パフォーマンスやセキュリティへの影響」

// 具体例
「ファイルアップロード機能を実装し、以下の点について理由を説明してください:
- 採用したライブラリ(例: multer, formidable)とその理由
- S3直接アップロードとサーバー経由アップロードの比較結果
- ファイルサイズ制限、セキュリティ対策の根拠」

根拠を求めることで、AI は盲目的に実装せず、選択肢を比較した上で最適な実装を提案します。

3-2. 実装パターン理由句型

設計判断の説明を求めます。

typescript// 句型テンプレート
「[機能名]を実装する際、以下の設計判断について理由を説明してください:
- 採用したデザインパターン
- クラス設計 vs 関数設計の選択理由
- 状態管理の方法とその根拠」

// 具体例
「ショッピングカート機能を実装する際、以下の設計判断について理由を説明してください:
- 採用したデザインパターン(Repository, Factory, Strategyなど)
- クラス設計 vs 関数設計の選択理由
- 状態管理の方法(Context API, Zustand, Reduxなど)とその根拠」

設計の根拠を明示することで、将来の変更時に判断の背景を理解でき、適切なリファクタリングが可能になります。

3-3. エラー原因分析句型

エラーの根本原因を分析させます。

typescript// 句型テンプレート
「以下のエラーについて、根本原因を分析してください:
エラーメッセージ: [エラー内容]
発生箇所: [ファイル名:行番号]
分析観点:
  - エラーが発生する条件
  - 直接原因と根本原因の区別
  - 同様のエラーを防ぐための対策」

// 具体例
「以下のエラーについて、根本原因を分析してください:
エラーメッセージ: TypeError: Cannot read property 'id' of undefined
発生箇所: lib/services/userService.ts:42
分析観点:
  - エラーが発生する条件(どのような入力で発生するか)
  - 直接原因(undefinedアクセス)と根本原因(データ取得失敗)の区別
  - 同様のエラーを防ぐための対策(バリデーション、型ガード)」

根本原因を分析することで、表面的な修正ではなく、本質的な問題解決が可能になります。

3-4. パフォーマンス根拠句型

性能判断の理由を明確にします。

typescript// 句型テンプレート
「[機能名]のパフォーマンス最適化を実施し、以下の点を説明してください:
- ボトルネック箇所の特定方法
- 最適化手法の選択理由
- 最適化前後の計測結果(想定値でも可)」

// 具体例
「ユーザー一覧表示のパフォーマンス最適化を実施し、以下の点を説明してください:
- ボトルネック箇所の特定方法(N+1問題の有無、クエリ数など)
- 最適化手法の選択理由(eager loading, インデックス追加, キャッシングなど)
- 最適化前後の計測結果(レスポンスタイム、クエリ数の変化)」

パフォーマンスの根拠を示すことで、過剰最適化や誤った最適化を防ぎ、効果的な改善が可能になります。

3-5. セキュリティ判断句型

セキュリティ対策の根拠を説明させます。

typescript// 句型テンプレート
「[機能名]のセキュリティ対策を実装し、以下の点を説明してください:
- 想定される脅威(OWASP Top 10など)
- 採用したセキュリティ対策とその根拠
- 残存するリスクと受容理由」

// 具体例
「ログイン機能のセキュリティ対策を実装し、以下の点を説明してください:
- 想定される脅威(ブルートフォース攻撃、SQLインジェクション、XSSなど)
- 採用したセキュリティ対策(レート制限、パラメータ化クエリ、CSP)とその根拠
- 残存するリスク(例: セッションハイジャック)と受容理由」

セキュリティの根拠を明示することで、セキュリティレビューが容易になり、脆弱性の見落としを防げます。

4. 差分出力句型(5 パターン)

既存コードへの変更を最小限に抑え、レビューしやすい形で出力するパターンです。

4-1. 変更箇所明示句型

修正部分のみを出力させます。

typescript// 句型テンプレート
「[ファイル名]の以下の箇所のみを修正してください。ファイル全体ではなく、変更箇所のみを出力してください:
修正箇所1: [行番号または関数名]
  - 現状: [現在のコード]
  - 変更内容: [変更の説明]
修正箇所2: ...」

// 具体例
「lib/services/userService.ts の以下の箇所のみを修正してください。ファイル全体ではなく、変更箇所のみを出力してください:
修正箇所1: createUser関数(30-45行目)
  - 現状: パスワードの平文保存
  - 変更内容: bcryptでハッシュ化してから保存
修正箇所2: getUserById関数(50-60行目)
  - 現状: passwordフィールドを含めて返却
  - 変更内容: passwordを除外してから返却」

変更箇所のみを出力することで、差分レビューが容易になり、意図しない変更を防げます。

4-2. 追加コード指定句型

新規追加部分のみを出力させます。

typescript// 句型テンプレート
「[ファイル名]に以下のコードを追加してください。既存コードは変更せず、追加部分のみを出力してください:
追加箇所: [場所の説明]
追加内容: [機能の説明]」

// 具体例
「lib/services/userService.ts に以下のコードを追加してください。既存コードは変更せず、追加部分のみを出力してください:
追加箇所: ファイルの末尾
追加内容: パスワードリセット機能
  - resetPassword関数: emailを受け取り、リセットトークンを生成
  - verifyResetToken関数: トークンの有効性を検証
  - updatePassword関数: 新しいパスワードに更新」

追加部分のみを明示することで、既存機能への影響を最小限に抑えられます。

4-3. 削除指示句型

不要なコードを除去します。

typescript// 句型テンプレート
「[ファイル名]から以下のコードを削除してください:
削除箇所1: [場所の説明]
  - 削除理由: [なぜ削除するか]
削除箇所2: ...」

// 具体例
「lib/services/userService.ts から以下のコードを削除してください:
削除箇所1: getUserWithPassword関数(80-90行目)
  - 削除理由: セキュリティリスク、使用箇所なし
削除箇所2: デバッグ用のconsole.log文(12行目, 35行目, 68行目)
  - 削除理由: 本番環境に不要」

削除理由を明示することで、誤った削除を防ぎ、後から判断を振り返ることができます。

4-4. 修正前後比較句型

ビフォーアフターを明示します。

typescript// 句型テンプレート
「[ファイル名]の以下の変更を実施し、変更前後のコードを並べて表示してください:
変更箇所: [場所の説明]
変更内容: [変更の説明]

出力フォーマット:
【変更前】
[既存コード]

【変更後】
[新しいコード]

【変更理由】
[なぜこの変更が必要か]」

// 具体例
「lib/api/auth.ts の JWT検証ロジックを変更し、変更前後のコードを並べて表示してください:
変更箇所: verifyToken関数
変更内容: トークンの有効期限チェックを追加

出力フォーマット:
【変更前】
export function verifyToken(token: string) {
  return jwt.verify(token, SECRET_KEY);
}

【変更後】
export function verifyToken(token: string) {
  const decoded = jwt.verify(token, SECRET_KEY);
  if (decoded.exp < Date.now() / 1000) {
    throw new Error('Token expired');
  }
  return decoded;
}

【変更理由】
有効期限切れのトークンを明示的に拒否し、セキュリティを向上させるため」

ビフォーアフターを並べることで、変更の意図が明確になり、レビューが効率化されます。

4-5. マーカー付き出力句型

変更箇所に印をつけます。

typescript// 句型テンプレート
「[ファイル名]を修正し、変更箇所に以下のマーカーをコメントで付けてください:
// [ADDED] - 新規追加行
// [MODIFIED] - 変更行
// [DELETED] - 削除行(コメントアウトで残す)」

// 具体例
「lib/services/userService.ts を修正し、変更箇所にマーカーをコメントで付けてください:

出力例:
export async function createUser(input: CreateUserInput) {
  // [MODIFIED] バリデーション強化
  const validated = userSchema.parse(input);

  // [ADDED] パスワードハッシュ化
  const hashedPassword = await bcrypt.hash(validated.password, 10);

  // [DELETED] const user = await db.user.create({ data: input });
  // [MODIFIED] ハッシュ化されたパスワードで保存
  const user = await db.user.create({
    data: { ...validated, password: hashedPassword }
  });

  return user;
}」

マーカーを付けることで、コードレビュー時に変更箇所を一目で把握でき、レビュー時間が大幅に短縮されます。

5. 複合型句型(5 パターン)

複数の句型を組み合わせた、実践的なパターンです。

5-1. 仕様 → 分割 → 実装句型

段階的な開発フローを実現します。

typescript// 句型テンプレート
「以下のフローで[機能名]を開発してください:

ステップ1: 仕様定義
  - 要件: [機能要件]
  - 制約: [技術制約]
  - 入出力: [データ仕様]

ステップ2: 実装分割
  - コンポーネント1: [責務と実装内容]
  - コンポーネント2: [責務と実装内容]

ステップ3: 段階的実装
  - フェーズ1: [最小機能]
  - フェーズ2: [機能追加]
  - フェーズ3: [最適化]

各ステップで判断の根拠を説明してください。」

// 具体例
「以下のフローでコメント機能を開発してください:

ステップ1: 仕様定義
  - 要件: ユーザーが記事にコメント投稿、編集、削除できる
  - 制約: Next.js 14 App Router, PostgreSQL, 最大500文字
  - 入出力: POST /api/comments { articleId, content } → Comment型

ステップ2: 実装分割
  - コンポーネント1: データ層(Prismaスキーマ、Repository)
  - コンポーネント2: ビジネスロジック層(バリデーション、権限チェック)
  - コンポーネント3: API層(ルートハンドラ)

ステップ3: 段階的実装
  - フェーズ1: コメント投稿のみ(CRUD操作のCreate)
  - フェーズ2: 編集・削除機能追加(Update, Delete)
  - フェーズ3: ページネーション、楽観的ロック追加

各ステップで判断の根拠を説明してください。」

仕様から実装まで一貫した流れで進めることで、手戻りが少なく、高品質な実装が得られます。

5-2. 分析 → 根拠 → 提案句型

問題解決のフローを明確にします。

typescript// 句型テンプレート
「以下のフローで[問題]を解決してください:

ステップ1: 問題分析
  - 現象: [何が起きているか]
  - 影響範囲: [どこに影響があるか]
  - 再現手順: [どうすれば再現するか]

ステップ2: 原因究明
  - 直接原因: [表面的な原因]
  - 根本原因: [本質的な原因]
  - 根拠: [なぜそう判断したか]

ステップ3: 解決策提案
  - 提案1: [解決案とメリット・デメリット]
  - 提案2: [解決案とメリット・デメリット]
  - 推奨: [どれを推奨するか、その理由]」

// 具体例
「以下のフローでパフォーマンス問題を解決してください:

ステップ1: 問題分析
  - 現象: ユーザー一覧ページの読み込みに5秒かかる
  - 影響範囲: /users ページのみ、1000件以上のデータがある場合
  - 再現手順: /users にアクセス → Network タブで確認

ステップ2: 原因究明
  - 直接原因: SQLクエリが遅い(2秒)、シリアライズに3秒
  - 根本原因: N+1問題、ユーザーごとにプロフィール画像を個別取得
  - 根拠: Prismaのログで1001回のクエリを確認

ステップ3: 解決策提案
  - 提案1: Eager Loading (include で一括取得)
    - メリット: 簡単、1クエリで完結
    - デメリット: メモリ使用量増加
  - 提案2: ページネーション + 部分取得
    - メリット: メモリ効率的、スケーラブル
    - デメリット: 実装コスト高
  - 推奨: 提案2(長期的にスケールするため)」

分析から提案まで体系的に進めることで、根本的な問題解決が可能になります。

5-3. 設計 → 根拠 → 実装句型

設計駆動開発を実現します。

typescript// 句型テンプレート
「以下のフローで[機能名]を実装してください:

ステップ1: アーキテクチャ設計
  - レイヤー構造: [層の定義]
  - データフロー: [データの流れ]
  - 依存関係: [コンポーネント間の依存]

ステップ2: 設計判断の根拠
  - パターン選択: [採用したパターンとその理由]
  - トレードオフ: [何を優先し、何を犠牲にしたか]

ステップ3: 実装
  - 変更箇所のみを差分で出力
  - コメントで設計意図を明記」

// 具体例
「以下のフローでAPI認証機能を実装してください:

ステップ1: アーキテクチャ設計
  - レイヤー構造: Middleware → Controller → Service → Repository
  - データフロー: リクエスト → JWT検証 → ユーザー取得 → コンテキスト注入
  - 依存関係: Middleware は Service に依存、Service は Repository に依存

ステップ2: 設計判断の根拠
  - パターン選択: Dependency Injection(テストしやすさ重視)
  - トレードオフ: コード量増加を許容し、保守性とテスト容易性を優先

ステップ3: 実装
  - lib/middleware/auth.ts (新規作成)
  - lib/services/authService.ts (新規作成)
  - app/api/protected/route.ts (修正)
  - 変更箇所のみを差分で出力
  - コメントで設計意図を明記」

設計から実装まで一貫性を保つことで、メンテナンスしやすいコードが得られます。

5-4. 差分 → 理由 → テスト句型

変更管理を徹底します。

typescript// 句型テンプレート
「以下のフローで[変更内容]を実施してください:

ステップ1: 差分出力
  - 変更ファイル: [ファイル名]
  - 変更箇所: [マーカー付きで表示]
  - 変更前後: [ビフォーアフター]

ステップ2: 変更理由
  - 背景: [なぜ変更が必要か]
  - 影響範囲: [どこに影響があるか]
  - リスク: [潜在的な問題点]

ステップ3: テスト追加
  - 新規テストケース: [追加するテスト]
  - 既存テストへの影響: [修正が必要なテスト]」

// 具体例
「以下のフローでバリデーションロジックを変更してください:

ステップ1: 差分出力
  - 変更ファイル: lib/validation/userSchema.ts
  - 変更箇所:
    // [MODIFIED] email バリデーション強化
    email: z.string().email().refine(isDisposableEmail, ...)
  - 変更前後:
    【変更前】email: z.string().email()
    【変更後】email: z.string().email().refine(...)

ステップ2: 変更理由
  - 背景: 捨てアドレスによる不正登録が多発
  - 影響範囲: ユーザー登録、メールアドレス変更機能
  - リスク: 正規のメールが誤って弾かれる可能性

ステップ3: テスト追加
  - 新規テストケース:
    - 捨てアドレスでバリデーションエラー
    - Gmail, Outlookなどの正規メールは通過
  - 既存テストへの影響:
    - userService.test.ts の登録テストケースを確認」

変更の影響を明確にすることで、安全なリリースが可能になります。

5-5. 要件 → 分割 → 差分句型

段階的リファクタリングを実現します。

typescript// 句型テンプレート
「以下のフローで[対象]をリファクタリングしてください:

ステップ1: 要件定義
  - 目的: [なぜリファクタリングするか]
  - ゴール: [どのような状態を目指すか]
  - 制約: [変更してはいけないこと]

ステップ2: リファクタリング計画
  - フェーズ1: [最初の変更]
  - フェーズ2: [次の変更]
  - 各フェーズで動作確認すること

ステップ3: 差分出力
  - 各フェーズの変更箇所のみを出力
  - マーカーで変更理由を明記」

// 具体例
「以下のフローで userService.ts をリファクタリングしてください:

ステップ1: 要件定義
  - 目的: 肥大化した userService を分割し、保守性を向上
  - ゴール: 単一責任原則に従った小さなモジュール
  - 制約: 既存のAPIインターフェースは変更しない

ステップ2: リファクタリング計画
  - フェーズ1: バリデーションロジックを validation/userValidation.ts に抽出
  - フェーズ2: データアクセスを repositories/userRepository.ts に抽出
  - フェーズ3: userService.ts はビジネスロジックのみに集中
  - 各フェーズで既存のテストが通ることを確認

ステップ3: 差分出力
  - フェーズ1:
    // [ADDED] validation/userValidation.ts
    // [MODIFIED] userService.ts - バリデーション呼び出しに変更
  - フェーズ2:
    // [ADDED] repositories/userRepository.ts
    // [MODIFIED] userService.ts - Repository経由でDB操作
  - 各変更にマーカーと理由を明記」

段階的にリファクタリングすることで、動作を保証しながら安全にコード改善ができます。

6. 効率化句型(3 パターン)

繰り返し作業を効率化するパターンです。

6-1. テンプレート指定句型

定型フォーマットを利用します。

typescript// 句型テンプレート
「以下のテンプレートに従って[対象]を生成してください:

テンプレート:
[フォーマットの定義]

生成対象:
  - 項目1: [具体的な値]
  - 項目2: [具体的な値]」

// 具体例
「以下のテンプレートに従ってCRUD APIを生成してください:

テンプレート:
- GET /api/[resource] - 一覧取得(ページネーション付き)
- GET /api/[resource]/[id] - 詳細取得
- POST /api/[resource] - 作成
- PUT /api/[resource]/[id] - 更新
- DELETE /api/[resource]/[id] - 削除

生成対象:
  - リソース名: products
  - スキーマ: { name: string, price: number, stock: number }
  - バリデーション: name必須, price>0, stock>=0」

テンプレートを使うことで、一貫性のあるコードを素早く生成できます。

6-2. コンテキスト継承句型

前提条件を引き継ぎます。

typescript// 句型テンプレート
「前回の会話で定義した[内容]を前提として、[新しいタスク]を実施してください。

前提条件の確認:
  - [確認項目1]
  - [確認項目2]

新しいタスク:
  - [タスク内容]」

// 具体例
「前回の会話で定義したユーザー認証機能を前提として、パスワードリセット機能を実施してください。

前提条件の確認:
  - JWT認証を使用
  - ユーザーテーブルは users
  - メール送信機能は sendEmail関数を使用

新しいタスク:
  - パスワードリセットトークン生成
  - リセットメール送信
  - トークン検証とパスワード更新」

コンテキストを継承することで、毎回前提を説明する手間が省けます。

6-3. バッチ処理指示句型

複数ファイルを一括処理します。

typescript// 句型テンプレート
「以下のファイルに対して[処理内容]を一括実施してください:

対象ファイル:
  - [パターン1] 例: src/**/*.ts
  - [パターン2] 例: lib/services/*.ts

処理内容:
  - [共通の変更内容]

出力:
  - 変更箇所のみを各ファイルごとに表示」

// 具体例
「以下のファイルに対してESLintエラー修正を一括実施してください:

対象ファイル:
  - lib/services/*.ts
  - lib/repositories/*.ts

処理内容:
  - unused imports 削除
  - any型を適切な型に変更
  - 非同期関数に await漏れがあれば追加

出力:
  - 変更箇所のみを各ファイルごとに表示」

バッチ処理により、大量の修正を効率的に実施できます。

7. 品質管理句型(2 パターン)

コード品質を担保するパターンです。

7-1. チェックリスト適用句型

品質基準を確認します。

typescript// 句型テンプレート
「以下のチェックリストに従って[対象]をレビューしてください:

チェック項目:
  ☐ [項目1]
  ☐ [項目2]
  ☐ [項目3]

各項目について:
  - OK/NG判定
  - NGの場合は修正案を提示」

// 具体例
「以下のチェックリストに従って実装コードをレビューしてください:

チェック項目:
  ☐ 型安全性: any型を使っていないか
  ☐ エラーハンドリング: try-catchで適切に処理しているか
  ☐ バリデーション: 入力値チェックを実施しているか
  ☐ セキュリティ: SQLインジェクション対策があるか
  ☐ テスト: 単体テストが書かれているか
  ☐ コメント: 複雑なロジックに説明があるか

各項目について:
  - OK/NG判定
  - NGの場合は修正案を提示」

チェックリストにより、レビュー漏れを防ぎ、一定の品質を担保できます。

7-2. ベストプラクティス要求句型

業界標準を適用します。

typescript// 句型テンプレート
「以下のベストプラクティスに従って[対象]を実装してください:

適用する規約:
  - [規約1] 例: Airbnb JavaScript Style Guide
  - [規約2] 例: OWASP セキュリティガイドライン

重点項目:
  - [項目1]
  - [項目2]

実装後、準拠状況を説明してください。」

// 具体例
「以下のベストプラクティスに従って API実装してください:

適用する規約:
  - RESTful API Design (HTTPメソッド、ステータスコードの適切な使用)
  - OWASP API Security Top 10 (認証、認可、レート制限)

重点項目:
  - 適切なHTTPステータスコード(200, 201, 400, 401, 404, 500)
  - エラーレスポンスの統一フォーマット
  - 認証が必要なエンドポイントへのミドルウェア適用
  - レート制限(1ユーザーあたり100req/min)

実装後、各項目への準拠状況を説明してください。」

ベストプラクティスを適用することで、保守性が高く、セキュアなコードが得られます。

具体例

実践シナリオ 1: 新機能開発

ブログサイトに「いいね機能」を追加する場合の句型活用例を見ていきましょう。

ステップ 1: 仕様化

まず、要件定義句型で機能要件を明確にします。

typescript「以下の要件でいいね機能を実装してください:

必須項目:
  - ユーザーは記事に対していいねできる
  - 同じユーザーは同じ記事に1回のみいいね可能
  - いいねの取り消しも可能

技術仕様:
  - エンドポイント: POST /api/articles/[id]/likes
  - 認証: JWT必須
  - データベース: PostgreSQL, Prisma

データモデル:
  - likes テーブル: id, userId, articleId, createdAt
  - 複合ユニークインデックス: (userId, articleId)

レスポンス:
  - 成功時: 201, { likeId: string, totalLikes: number }
  - いいね済みエラー: 409, { error: "Already liked" }
  - 未認証エラー: 401, { error: "Unauthorized" }」

これにより、AI は実装に必要なすべての情報を把握できます。

ステップ 2: 分割統治

次に、レイヤー分離指示句型で実装を分割します。

typescript「以下のレイヤー構造でいいね機能を実装してください:

レイヤー1: データベーススキーマ
  - ファイル: prisma/schema.prisma
  - 内容: likes モデル定義、リレーション設定

レイヤー2: Repository層
  - ファイル: lib/repositories/likeRepository.ts
  - 責務: データベース操作(作成、削除、カウント)

レイヤー3: Service層
  - ファイル: lib/services/likeService.ts
  - 責務: ビジネスロジック(重複チェック、権限確認)

レイヤー4: API層
  - ファイル: app/api/articles/[id]/likes/route.ts
  - 責務: リクエスト/レスポンス処理

依存関係: API → Service → Repository」

レイヤーごとに実装することで、テストしやすく保守性の高いコードが得られます。

ステップ 3: 段階的実装

段階的実装指示句型で、少しずつ機能を追加します。

typescript「以下の順序で段階的に実装してください:

フェーズ1: 最小機能
  - いいね作成のみ(POST)
  - 重複チェックなし
  - 動作確認: cURLでテスト

フェーズ2: 重複チェック追加
  - 既にいいね済みの場合は409エラー
  - 動作確認: 同じリクエストを2回送信

フェーズ3: いいね削除機能
  - DELETE /api/articles/[id]/likes
  - 動作確認: 作成→削除→再作成

フェーズ4: いいね数カウント
  - レスポンスに totalLikes を追加
  - 動作確認: 複数ユーザーでいいね→カウント確認

各フェーズ完了後、次へ進んでください。」

段階的に進めることで、問題の早期発見と修正が可能になります。

ステップ 4: 根拠提示

技術選定理由句型で、実装判断の根拠を明確にします。

typescript「いいね機能の実装において、以下の判断について理由を説明してください:

1. 複合ユニークインデックスの採用理由
  - 他の選択肢(アプリケーション層でのチェックなど)との比較

2. 楽観的ロック vs 悲観的ロック
  - どちらを選択したか、その理由

3. いいね数のカウント方法
  - リアルタイムカウント vs キャッシュ
  - パフォーマンスへの影響」

根拠を明示することで、将来の変更時に判断の背景を理解でき、適切なリファクタリングが可能になります。

以下の図は、いいね機能のデータフローを示しています。

mermaidsequenceDiagram
  participant Client as クライアント
  participant API as API層
  participant Service as Service層
  participant Repo as Repository層
  participant DB as データベース

  Client->>API: POST /api/articles/123/likes
  API->>API: JWT検証
  API->>Service: likeArticle(userId, articleId)
  Service->>Repo: findLike(userId, articleId)
  Repo->>DB: SELECT
  DB-->>Repo: null(未いいね)
  Repo-->>Service: null
  Service->>Repo: createLike(userId, articleId)
  Repo->>DB: INSERT
  DB-->>Repo: like作成成功
  Repo-->>Service: like
  Service->>Repo: countLikes(articleId)
  Repo->>DB: COUNT
  DB-->>Repo: 42
  Repo-->>Service: 42
  Service-->>API: { likeId, totalLikes: 42 }
  API-->>Client: 201, { likeId, totalLikes: 42 }

このシーケンス図により、各層の役割とデータの流れが一目でわかります。

実践シナリオ 2: バグ修正

既存のログイン機能でエラーが発生している場合の句型活用例です。

ステップ 1: エラー分析

エラー原因分析句型で根本原因を特定します。

typescript「以下のエラーについて根本原因を分析してください:

エラーメッセージ:
  TypeError: Cannot read property 'id' of null
  at lib/services/authService.ts:67

発生条件:
  - 存在しないメールアドレスでログイン試行時
  - 環境: 本番環境のみ(開発環境では発生しない)

分析観点:
  - 直接原因と根本原因の区別
  - なぜ開発環境では発生しないのか
  - 同様のエラーが他の箇所でも発生しうるか」

AI は以下のような分析を返します。

typescript「分析結果:

直接原因:
  - authService.ts:67 で user.id にアクセスしているが、user が null

根本原因:
  - ユーザーが見つからない場合のエラーハンドリングが不十分
  - 開発環境では同名のテストユーザーが存在するため発生しなかった

影響範囲:
  - 同様のパターンが userService.ts:42 にも存在
  - パスワードリセット機能でも同じ問題が潜在

推奨対策:
  1. null チェックの追加
  2. 型ガードの導入(User | null → User型に絞り込み)
  3. エラーハンドリングの統一パターン策定」

ステップ 2: 差分修正

変更箇所明示句型で、必要最小限の修正を行います。

typescript「lib/services/authService.ts の以下の箇所のみを修正してください。ファイル全体ではなく、変更箇所のみを出力してください:

修正箇所: login関数(60-70行目)
  - 現状: user が null の場合の処理がない
  - 変更内容: null チェック追加、適切なエラー返却」

AI は以下のような差分を返します。

typescript「【変更箇所】lib/services/authService.ts:60-70

【変更前】
export async function login(email: string, password: string) {
  const user = await userRepository.findByEmail(email);
  const isValid = await bcrypt.compare(password, user.password);
  // ...
}

【変更後】
export async function login(email: string, password: string) {
  const user = await userRepository.findByEmail(email);

  // [ADDED] ユーザー存在チェック
  if (!user) {
    throw new AuthError('Invalid email or password', 401);
  }

  const isValid = await bcrypt.compare(password, user.password);
  // ...
}

【変更理由】
存在しないメールアドレスでのログイン試行時、null アクセスでクラッシュするのを防ぐため。
セキュリティ上、emailの存在可否を明示しないよう、パスワード誤りと同じエラーメッセージにしています。」

ステップ 3: テスト追加

テスト分割指示句型で、再発防止のためのテストを追加します。

typescript「以下のテストケースを lib/services/authService.test.ts に追加してください:

異常系:
  - ケース1: 存在しないemailでログイン試行 → 401エラー
  - ケース2: 正しいemailだが間違ったpassword → 401エラー
  - ケース3: email が null → 400エラー

境界値:
  - ケース4: 空文字列のemail → 400エラー」

テストを追加することで、同じバグの再発を防げます。

以下の図は、エラーハンドリングのフローを示しています。

mermaidflowchart TD
  start["ログインリクエスト"] --> find["ユーザー検索"]
  find --> exists{ユーザー<br/>存在?}
  exists -->|はい| check["パスワード検証"]
  exists -->|いいえ| err401["401エラー<br/>Invalid credentials"]
  check --> valid{パスワード<br/>一致?}
  valid -->|はい| token["JWTトークン生成"]
  valid -->|いいえ| err401
  token --> success["200 成功レスポンス"]

  style err401 fill:#ffcccc
  style success fill:#ccffcc

エラーハンドリングのフローを可視化することで、漏れのない実装が可能になります。

実践シナリオ 3: リファクタリング

肥大化した userService.ts を整理する場合の句型活用例です。

ステップ 1: 要件定義

要件 → 分割 → 差分句型で、リファクタリング計画を立てます。

typescript「以下のフローで userService.ts をリファクタリングしてください:

ステップ1: 要件定義
  - 目的: 500行のuserServiceを分割し、保守性向上
  - ゴール: 各ファイル100行以内、単一責任原則に従う
  - 制約: 既存のAPIインターフェースは変更しない、テストは全て通す

ステップ2: リファクタリング計画
  - フェーズ1: バリデーションロジックを抽出
  - フェーズ2: データアクセスロジックを抽出
  - フェーズ3: ビジネスロジックのみ残す

ステップ3: 差分出力
  - 各フェーズの変更箇所のみをマーカー付きで出力」

ステップ 2: 段階的分割

ファイル分割要求句型で、具体的な分割計画を指示します。

typescript「以下のファイル構成でリファクタリングしてください:

新規ファイル1: lib/validation/userValidation.ts
  - 責務: 入力値のバリデーション
  - エクスポート: validateCreateUser, validateUpdateUser

新規ファイル2: lib/repositories/userRepository.ts
  - 責務: データベース操作
  - エクスポート: findById, create, update, delete

修正ファイル: lib/services/userService.ts
  - 責務: ビジネスロジックのみ(権限チェック、トランザクション制御)
  - 依存: userValidation, userRepository をインポート

各ファイルは独立してテスト可能にしてください。」

ステップ 3: 差分確認

修正前後比較句型で、変更内容を確認します。

typescript「フェーズ1完了時の変更を、変更前後で比較表示してください:

対象: lib/services/userService.ts の createUser 関数

出力フォーマット:
【変更前】
[既存コード]

【変更後】
[新しいコード]

【抽出されたコード】
lib/validation/userValidation.ts:
[抽出されたバリデーションロジック]」

ビフォーアフターを並べることで、レビューが効率化されます。

以下の図は、リファクタリング前後のアーキテクチャを示しています。

mermaidflowchart LR
  subgraph before["リファクタリング前"]
    service1["userService.ts<br/>(500行)<br/>・バリデーション<br/>・ビジネスロジック<br/>・DB操作"]
  end

  subgraph after["リファクタリング後"]
    service2["userService.ts<br/>(100行)<br/>ビジネスロジック"]
    validation["userValidation.ts<br/>(50行)<br/>バリデーション"]
    repo["userRepository.ts<br/>(80行)<br/>DB操作"]

    service2 --> validation
    service2 --> repo
  end

  before -.->|リファクタリング| after

  style service1 fill:#ffcccc
  style service2 fill:#ccffcc
  style validation fill:#ccffcc
  style repo fill:#ccffcc

リファクタリング前後のアーキテクチャを図示することで、変更の意図が明確になります。

図解で理解できる要点

本章で示した具体例から、以下の点が理解できます。

  • 新機能開発: 仕様化 → 分割統治 → 段階的実装 → 根拠提示の流れで進める
  • バグ修正: エラー分析 → 差分修正 → テスト追加で再発を防止
  • リファクタリング: 要件定義 → 段階的分割 → 差分確認で安全に実施

これらのシナリオを通じて、句型を組み合わせることで複雑なタスクも体系的に進められることがわかります。

まとめ

本記事では、Cursor で効果的に開発を進めるための 30 の句型を紹介しました。これらの句型は、以下の 4 つの観点から AI とのコミュニケーションを改善します。

4 つの観点の振り返り

#観点効果主要な句型
1仕様化要件の曖昧性を排除し、期待通りの実装を得る要件定義、制約条件明示、入出力定義
2分割統治複雑なタスクを小さく分割し、品質を向上段階的実装、レイヤー分離、機能単位分割
3根拠提示AI の判断理由を明確にし、レビューを容易化技術選定理由、実装パターン理由、エラー原因分析
4差分出力変更を最小化し、差分レビューを可能に変更箇所明示、追加コード指定、修正前後比較

句型活用の実践ポイント

句型を実務で活用する際のポイントは以下の通りです。

1. 状況に応じた句型の選択

すべての句型を毎回使う必要はありません。タスクの性質に応じて、適切な句型を選択しましょう。

  • 新機能開発: 仕様化 + 分割統治 + 根拠提示
  • バグ修正: 根拠提示 + 差分出力
  • リファクタリング: 分割統治 + 差分出力
  • コードレビュー: 根拠提示 + 品質管理

2. 句型のカスタマイズ

本記事で紹介した句型はテンプレートです。プロジェクトの特性に合わせてカスタマイズしてください。

たとえば、セキュリティ要件が厳しいプロジェクトでは、セキュリティ判断句型をすべての実装で必須にする、といった工夫が有効です。

3. チームでの共有

効果的な句型は、チーム内で共有し、標準化することが重要です。プロジェクトの README やドキュメントに「推奨プロンプトパターン」として記載しておくと、チーム全体の生産性が向上します。

4. 継続的な改善

実際に使ってみて、うまくいった句型、いかなかった句型を記録し、継続的に改善していきましょう。プロジェクトごとに最適な句型は異なります。

AI エディタ時代の開発スタイル

Cursor のような AI エディタの登場により、開発者の役割は「コードを書く人」から「AI に指示を出す人」へとシフトしつつあります。

従来の開発スタイルでは、開発者がすべてのコードを自分で書いていました。しかし AI エディタ時代では、開発者は「設計者」「指示者」「レビュアー」としての役割が強くなります。

本記事で紹介した句型は、この新しい開発スタイルにおける「指示の技術」を体系化したものです。適切な句型を使いこなすことで、AI との協働がよりスムーズになり、高品質なコードを効率的に生成できるようになります。

次のステップ

本記事で紹介した句型を実際のプロジェクトで試してみましょう。最初は 1 つか 2 つの句型から始めて、徐々に増やしていくのがおすすめです。

特に以下の 5 つは汎用性が高く、すぐに効果を実感できるはずです。

  1. 要件定義句型: 新機能開発時に要件を明確化
  2. 段階的実装指示句型: 複雑なタスクを小さく分割
  3. 変更箇所明示句型: 既存コード修正時に差分を最小化
  4. 技術選定理由句型: 実装判断の根拠を明確化
  5. チェックリスト適用句型: コード品質を担保

これらの句型を使いこなすことで、Cursor を使った開発がより快適で生産的なものになるでしょう。

関連リンク

Cursorの記事Cursor

もっと見る

記事Article

もっと見る

ブログBlog

もっと見る

書籍レビューReview

もっと見る