Cursorは、短い指示でもコードの生成や修正を進められるAIコードエディタです。しかし、実務で使える品質を得るには、「何を作るか」だけでなく、既存仕様、変更対象、制約、作業手順、完了条件まで伝える必要があります。
指示が曖昧なままAgentへ実装を任せると、既存機能と似た処理を新しく作る、依頼していないファイルまで変更する、テストを実行せず完了と判断するといった問題が起こる可能性があります。生成速度が上がっても、レビューや手戻りが増えれば、開発全体の生産性は向上しません。
本記事では、Cursorプロンプトを構成する6つの要素、実務で使えるプロンプト例文12選、Project Rulesなどとの使い分け、精度を高める実行手順を解説します。コピー用の例文だけでなく、自社のコードベースや開発ルールに合わせて内容を調整するための判断基準も紹介します。
Cursorの機能名や設定画面は更新される可能性があります。本記事では、2026年7月時点で確認できるCursor公式ドキュメントを基準に説明します。
Cursorプロンプトで生成精度を高める6つの構成要素
Cursorへの指示は、次の6要素で構造化すると、依頼者とAgentの認識のずれを抑えやすくなります。
| 比較項目 | 曖昧な指示 | 改善後の指示 |
|---|---|---|
| 目的 | ログイン機能を実装する | 既存認証基盤を利用したログイン機能を追加する |
| 成果物 | 不明 | ログイン画面、API連携、エラー表示、テスト |
| 作業範囲 | Agentの判断に依存 | 調査、実装、テスト実行まで |
| 完了判定 | コードが生成された状態 | 指定テストと型チェックが通過した状態 |
| 主なリスク | 実装漏れ、過剰な変更 | 完成状態と確認方法を共有しやすい |
- 目的と成果物
- 背景と既存仕様
- 変更対象と変更禁止範囲
- 技術要件と品質基準
- 調査・計画・実装・検証の手順
- 完了条件と回答形式
すべてのタスクで長文のプロンプトを書く必要はありません。軽微な修正では要点だけを指定し、影響範囲が広い変更ほど6要素を詳しく記載することが重要です。
目的と成果物の明示
プロンプトの冒頭では、何をしてほしいのかと、最終的に何を返してほしいのかを分けて指定します。
「ログイン機能を実装してください」という指示だけでは、Agentは画面だけを作るのか、APIやテストまで変更するのかを判断できません。次のように、完成状態まで示します。
悪い指示：
「ログイン機能を実装してください」
改善後の指示：
「既存の認証基盤を利用し、メールアドレスとパスワードによるログイン機能を追加してください。ログイン画面、認証APIとの連携、エラー表示、単体テストを実装対象とします」
さらに、以下の区別も必要です。
- 関連コードの調査だけを依頼する
- 実装計画まで作成させる
- 実際のファイル変更を許可する
- テスト実行まで任せる
- 最終的な説明だけを求める
CursorのAgentは、コードベースの検索、複数ファイルの編集、ターミナルコマンドの実行などを行えます。そのため、回答だけを求めるのか、ファイル変更まで許可するのかを明記することが、意図しない操作の抑制につながります。
背景と既存仕様のコンテキスト
新しいコードだけを見て判断させるのではなく、対象機能が必要になった背景や、既存処理との関係を伝えます。
たとえば、次の情報がコンテキストの候補です。
- 機能の利用者と利用場面
- 関連する要件定義書やAPI仕様
- 参考にすべき既存実装
- 共通の型定義
- 呼び出し元と呼び出し先
- 関連するテスト
- 適用すべきProject Rules
- 過去に発生した不具合
Cursorでは、@Filesや@Foldersなどを使って、特定のファイルやフォルダをコンテキストとして明示できます。特定の関数やシンボルが分かっている場合は、対象をさらに限定する方法もあります。
ただし、コンテキストは多いほどよいわけではありません。大きなフォルダや長いファイルは、コンテキスト上限に合わせて圧縮・選別される場合があります。Agentが判断するうえで重要なファイルを優先して渡す必要があります。
「リポジトリ全体を見てください」ではなく、次のように優先順位を示します。
- 認証処理はsrc/auth/session.tsを基準にする
- APIレスポンス型はsrc/types/api.tsを参照する
- テスト形式はtests/auth/login.test.tsに合わせる
- legacy/配下のコードは参考にしない
- 自動生成されたファイルは編集しない
関連しそうなファイルをすべて渡すより、判断の基準になる実装を数点選ぶ方が、意図を伝えやすくなります。
変更対象と変更禁止範囲の指定
Agentへ実装を依頼する際は、変更してよい範囲だけでなく、変更してはいけない範囲も明記します。
指定する項目の例は次のとおりです。
- 変更可能なディレクトリ
- 変更可能なファイル
- 変更対象の関数やコンポーネント
- 変更してはいけない公開API
- 維持すべきデータベーススキーマ
- 変更禁止の設定ファイル
- 追加してはいけない依存パッケージ
- 維持すべきファイル名やエクスポート名
具体的な指示例は以下です。
「変更はsrc/features/login/と対応するテストファイルに限定してください。公開API、データベーススキーマ、共通認証モジュールは変更しないでください。範囲外の変更が必要な場合は、実装せず、必要な理由と変更候補を報告してください」
このように、変更可能範囲、要相談範囲、変更禁止範囲を分けると、レビュー対象を管理しやすくなります。
技術要件と品質基準の具体化
「適切に実装する」「きれいなコードにする」といった表現は、人間とAIのどちらにとっても完了判定が難しい指示です。
品質基準は、確認可能な条件へ置き換えます。
- 使用言語とバージョン
- フレームワークとバージョン
- 既存の設計パターン
- 命名規則
- 型安全性
- 例外処理
- ログ出力
- アクセシビリティ
- セキュリティ要件
- パフォーマンス条件
- テストの対象
- リンターやフォーマッター
たとえば、「エラーハンドリングを適切に実装する」ではなく、以下のように指定します。
「APIが401を返した場合はログイン画面へ遷移し、500の場合は再試行可能なエラーメッセージを表示してください。トークンや個人情報はログへ出力しないでください。既存のエラー型とログユーティリティを使用してください」
新しい独自ルールをプロンプト内で作るよりも、既存プロジェクトで利用しているリンター、フォーマッター、設計規約を優先させます。
| 品質項目 | 抽象的な指示 | 検証可能な指示 |
|---|---|---|
| エラー処理 | 適切に処理する | 401はログイン画面へ遷移し、500は再試行可能なメッセージを表示する |
| 型安全性 | 型を正しく使う | anyと型エラーの抑制を追加せず、既存のAPI型を利用する |
| セキュリティ | 安全に実装する | トークンと個人情報をログへ出力しない |
| テスト | 十分にテストする | 正常系、401、500、入力境界値のテストを追加する |
| コード品質 | きれいに書く | 既存リンターとフォーマッターを通過させる |
調査・計画・実装・検証の順序
影響範囲が広いタスクでは、Agentへすぐにコードを書かせず、次の順序で進めます。
- 関連コードの調査
- 現状と制約の整理
- 変更計画の作成
- 実装
- テストと静的解析
- 差分と残課題の報告
複数ファイルの変更、データベース変更、公開APIの変更、既存アーキテクチャへの影響がある場合は、調査と計画を実装から分ける方法が適しています。
一方、文言修正や限定的なテスト追加など、変更範囲が明確な作業では、調査から検証までを一括で依頼しても管理しやすいと考えられます。
失敗したコマンドについても、結果を隠さず報告させます。
「テストが失敗した場合は、失敗したコマンド、エラー内容、原因、実施した修正、再実行結果を記載してください」
完了条件と回答形式の指定
コードを書き終えたことと、依頼が完了したことは同じではありません。完了条件は、実行結果で確認できる形にします。
完了条件の例は次のとおりです。
- 指定した機能が実装されている
- 既存APIとの互換性が保たれている
- 単体テストが通過している
- 型チェックが通過している
- リンターエラーがない
- ビルドが成功している
- 変更禁止範囲に差分がない
- 未確認事項が明記されている
最終回答には、少なくとも次の項目を含めるよう指示します。
- 変更したファイル
- 各ファイルを変更した理由
- 実行したテストと結果
- 実装できなかった項目
- 推測して判断した箇所
- 残っているリスク
出力形式を細かく固定しすぎると、重要な情報が省略される場合があります。必要な報告項目を指定しつつ、説明方法までは過度に制約しないことが重要です。
以下は、6要素をまとめた基本テンプレートです。
# 目的と成果物
[実現したい目的]を達成するため、[作成・変更する成果物]を作成してください。
今回は[調査のみ／計画作成／ファイル変更／テスト実行]まで行ってください。
# 背景と既存仕様
- 利用者・利用場面：[内容]
- 既存仕様：[内容]
- 参考にするファイル：[ファイルパス]
- 参考にしないファイル：[ファイルパス]
# 変更範囲
- 変更可能：[ディレクトリ・ファイル・関数]
- 変更前に要相談：[対象]
- 変更禁止：[公開API・DB・設定など]
- 必要最小限の差分にしてください。
# 技術要件と品質基準
- 言語・フレームワーク：[内容]
- 適用する既存規約：[内容]
- 例外処理：[内容]
- セキュリティ：[内容]
- テスト：[内容]
# 作業手順
- 関連コードを調査する
- 現状と変更方針を整理する
- 対象ファイルとリスクを報告する
- [承認後／そのまま]実装する
- テスト・型チェック・静的解析を実行する
- 差分を説明する
# 完了条件と報告項目
- [完了条件]
- 変更ファイルと変更理由
- 実行したコマンドと結果
- 未確認事項
- 残存リスク
最初からすべての項目を埋める必要はありません。失敗したときに不足していた項目を追加し、再利用できる形へ整える方法が現実的です。
Cursorで使えるプロンプト例文12選
ここでは、新規実装、既存機能の改修、デバッグ、テスト、コードレビュー、ドキュメント作成で使えるプロンプト例文を紹介します。
[ ]で囲んだ箇所は、対象プロジェクトに合わせて置き換えてください。ファイル名や実行コマンドは、実際のリポジトリで使用しているものを指定します。
新規機能の設計と実装に使う3つのプロンプト
新規機能では、仕様だけを伝えてすぐに実装させると、既存の設計パターンや共通機能を見落とす可能性があります。変更規模に応じて、計画のみ、段階実装、一括実装を使い分けます。
例文1：関連コードの調査と実装計画
[機能名]の追加に向けて、関連コードを調査し、実装計画を作成してください。
この段階ではファイルを変更しないでください。
機能要件：
- [要件1]
- [要件2]
- [要件3]
優先して確認する対象：
- [参考ファイル・ディレクトリ]
- 類似機能
- 共通コンポーネント
- 型定義
- APIクライアント
- 関連テスト
- 呼び出し元
調査結果には以下を含めてください。
- 現在の処理フロー
- 再利用できる既存実装
- 新規作成が必要な要素
- 変更候補ファイル
- 影響範囲
- 技術的なリスク
- 不明点と確認事項
- 実装手順
推測で仕様を補わず、コードから確認できる事実と推測を分けてください。
置き換える項目：
- 機能名
- 機能要件
- 参考ファイル
- 調査対象
使用時の注意：
複数ファイル、データベース、公開API、認証処理へ影響する機能では、計画を確認してから実装へ進みます。
例文2：承認済み計画に沿った段階実装
以下の承認済み計画に沿って、[機能名]を実装してください。
承認済み計画：
[計画を貼り付ける]
変更可能範囲：
- [ファイル・ディレクトリ]
変更禁止範囲：
- [公開API]
- [データベーススキーマ]
- [共通モジュール]
- 依存パッケージの追加
- 無関係なリファクタリング
技術要件：
- [言語・フレームワーク・バージョン]
- [設計パターン]
- [命名規則]
- [例外処理]
- [セキュリティ要件]
実装後に以下を実行してください。
- [単体テストコマンド]
- [型チェックコマンド]
- [リンターコマンド]
- [ビルドコマンド]
最終回答には、変更ファイル、変更理由、テスト結果、未解決事項を記載してください。
計画外の変更が必要になった場合は、実装せず理由を報告してください。
置き換える項目：
- 承認済み計画
- 変更可能・禁止範囲
- 技術要件
- 検証コマンド
使用時の注意：
最初の計画から変更が生じた場合は、Agentの判断だけで範囲を広げず、人間が再確認します。
例文3：小規模機能の調査から検証までの一括実装
[小規模な機能]を追加してください。
調査、実装、検証まで一括で進めて構いません。
要件：
- [要件1]
- [要件2]
参考実装：
- [ファイルパス]
変更可能範囲：
- [対象ファイル]
- 対応するテストファイル
制約：
- 公開インターフェースを変更しない
- 新しい依存パッケージを追加しない
- 既存の命名規則とエラー処理を使用する
- 必要最小限の差分にする
作業手順：
- 参考実装と関連テストを確認する
- 変更方針を短く整理する
- 実装する
- [テストコマンド]を実行する
- 差分と結果を報告する
テストを実行できない場合は、完了とせず、理由と手動確認方法を記載してください。
置き換える項目：
- 機能要件
- 参考実装
- 対象ファイル
- テストコマンド
使用時の注意：
文言変更や小さなバリデーション追加など、影響範囲を短時間で確認できる作業に向いています。
| 種類 | 適した変更 | Agentへ許可する範囲 | 人間の確認時点 |
|---|---|---|---|
| 計画のみ | 複数ファイル、DB、公開APIへ影響する変更 | 読み取りと計画作成 | 実装前 |
| 段階実装 | 計画が承認済みの中規模以上の変更 | 承認済み範囲の編集と検証 | 計画変更時・実装後 |
| 一括実装 | 影響範囲が限定された小規模変更 | 調査、実装、検証 | 差分生成後 |
既存機能の修正とリファクタリングに使う3つのプロンプト
既存機能の修正では、動作変更と内部改善を分けて依頼することが重要です。両方を同時に進めると、不具合修正による差分とリファクタリングによる差分を区別しにくくなります。
例文4：既存挙動を維持した限定修正
[対象機能]の[修正内容]を、既存の挙動を維持したまま実装してください。
現在の問題：
- [症状]
- [再現条件]
- [期待する動作]
- [実際の動作]
変更対象：
- [ファイル・関数]
維持する仕様：
- [既存仕様1]
- [既存仕様2]
- 公開API
- 既存の型定義
- エラーレスポンス形式
制約：
- 対象外のリファクタリングを行わない
- 差分を必要最小限にする
- 既存テストを先に確認する
- 修正内容を確認できるテストを追加する
実装後は[テストコマンド]を実行し、変更前後で維持した振る舞いを報告してください。
置き換える項目：
- 問題の症状
- 再現条件
- 対象ファイル
- 維持する仕様
使用時の注意：
「既存挙動を維持する」だけでは不十分です。何を維持するのかを具体的に列挙します。
例文5：リファクタリング候補の分析と比較
[対象ファイル・モジュール]を分析し、リファクタリング候補を提示してください。
この段階ではコードを変更しないでください。
確認する観点：
- 重複コード
- 長大な関数
- 責務の混在
- 循環依存
- テスト困難性
- 例外処理の重複
- 不要な抽象化
各改善案について、以下を比較してください。
- 現在の問題
- 改善による実利
- 変更範囲
- 既存仕様への影響
- テストへの影響
- 実装コスト
- 採用しない場合のリスク
単にコード行数を減らす案や、用途が明確でない新しい抽象化は提案しないでください。
優先度が高い順に最大[件数]件を提示してください。
置き換える項目：
- 分析対象
- 提案件数
- プロジェクト固有の観点
使用時の注意：
AIは共通化できる箇所を過剰に抽象化する場合があります。改善による実利を説明できる案だけに絞らせます。
例文6：公開インターフェースを維持したリファクタリング
[対象モジュール]をリファクタリングしてください。
目的：
- [重複の解消／責務分離／可読性改善／テスト容易性の向上]
維持する条件：
- 外部公開している関数名と引数
- 戻り値の型
- 例外の種類
- APIレスポンス
- 既存の利用側コード
- 現在の機能上の振る舞い
制約：
- 新機能を追加しない
- 動作変更を含めない
- 依存パッケージを追加しない
- 新しい抽象化は、複数箇所で実際に再利用できる場合に限定する
作業手順：
- 既存テストと利用箇所を確認する
- 現在の振る舞いを整理する
- 回帰テストが不足している場合は先に追加する
- リファクタリングする
- 全テストと型チェックを実行する
- 変更前後で維持した仕様を報告する
置き換える項目：
- 対象モジュール
- 改善目的
- 維持するインターフェース
- 検証コマンド
使用時の注意：
リファクタリングと機能変更を同じプルリクエストへ混在させない運用にすると、レビューしやすくなります。
エラー調査とデバッグに使う2つのプロンプト
デバッグでは、エラーメッセージから推測した修正を繰り返すのではなく、再現条件とコードパスを確認し、根本原因を特定する手順を指定します。
例文7：原因候補を絞るエラー調査
以下のエラーについて、原因を調査してください。
この段階ではコードを変更しないでください。
エラーログ：
[機密情報を除去したログ]
再現手順：
- [手順]
- [手順]
期待する動作：
[内容]
実際の動作：
[内容]
直前の変更：
[変更内容またはGit差分]
優先して確認する対象：
- [関連ファイル]
- 呼び出し元
- データの入力元
- 例外処理
- 関連テスト
調査結果には以下を含めてください。
- 原因候補
- 各候補を支持する根拠
- 該当するコードパス
- 原因を切り分ける確認手順
- 追加が必要なログ
- 最も可能性が高い根本原因
相関関係だけで原因と判断しないでください。
情報が不足している場合は、修正を提案する前に必要な情報を示してください。
置き換える項目：
- マスキング済みログ
- 再現手順
- 直前の変更
- 関連ファイル
使用時の注意：
ログにAPIキー、トークン、メールアドレス、Cookie、内部URLなどが含まれていないか確認します。
例文8：最小差分の修正と回帰テスト
以下の確認済みの原因に基づいて、不具合を最小差分で修正してください。
確認済みの原因：
[原因]
再現手順：
[手順]
期待する動作：
[内容]
変更可能範囲：
- [対象ファイル]
- 対応するテストファイル
変更禁止：
- 公開API
- データベーススキーマ
- 無関係なリファクタリング
- 依存パッケージの追加
作業手順：
- 現在の不具合を再現するテストを追加する
- テストが修正前に失敗することを確認する
- 原因箇所を最小差分で修正する
- 追加したテストと既存テストを実行する
- 型チェックとリンターを実行する
最終回答には、根本原因、修正内容、回帰テスト、実行結果、残存リスクを記載してください。
置き換える項目：
- 確認済みの原因
- 変更可能範囲
- 実行コマンド
使用時の注意：
原因が未確認の段階では、この例文ではなく例文7から始めます。
テスト作成とコードレビューに使う2つのプロンプト
テスト作成では正常系だけでなく、異常系や境界値を含めます。コードレビューでは、好みの問題と、障害や脆弱性につながる問題を分けて報告させます。
例文9：既存方針に沿ったテスト追加
[対象機能]のテストを追加してください。
最初に以下を確認してください。
- 既存のテストフレームワーク
- テストファイルの配置
- 命名規則
- モックの方針
- 共通のテストユーティリティ
- 類似機能のテスト
テスト対象：
- [対象関数・コンポーネント・API]
含める観点：
- 正常系
- 異常系
- 境界値
- 空値・未定義値
- 権限不足
- 外部API失敗
- 再試行やタイムアウト
- 既存不具合の回帰
実装コードの内部構造ではなく、外部から確認できる振る舞いを優先してテストしてください。
同じ内容を複数のテストで重複確認しないでください。
実行後は、追加したテストケース、検出できる不具合、実行結果、未対応の観点を報告してください。
置き換える項目：
- テスト対象
- 必要なテスト観点
- 実行コマンド
使用時の注意：
すべての観点を機械的に含める必要はありません。対象機能で実害につながるケースを優先します。
例文10：リスクベースのコードレビュー
現在のGit差分をコードレビューしてください。
コードは変更せず、問題点を報告してください。
以下の順で確認してください。
- 仕様との不一致
- バグと回帰リスク
- セキュリティと権限
- データ破損・消失リスク
- エラー処理
- パフォーマンス
- 保守性
- テスト不足
各指摘には以下を含めてください。
- 重要度：[Critical／High／Medium／Low]
- 対象ファイルと箇所
- 問題の内容
- 問題になる理由
- 再現条件または発生条件
- 修正案
命名や記述スタイルの好みは、障害につながる問題と分けてください。
根拠のない可能性を指摘として断定しないでください。
重大な指摘がない場合も、確認した観点、確認できなかった範囲、残存リスクを報告してください。
置き換える項目：
- レビュー対象
- プロジェクト固有のリスク
- 重要度の定義
使用時の注意：
Agentによるセルフレビューは、人間のレビューを代替するものではありません。認証、権限、決済、個人情報などの高リスク領域は、経験者が差分と設計を確認します。
ドキュメント作成と仕様整理に使う2つのプロンプト
コードからドキュメントを作る場合は、確認できる事実と、AIが推測した内容を分けて記載させます。
例文11：コードからの技術ドキュメント作成
[対象コード]について、[想定読者]向けの技術ドキュメントを作成してください。
想定読者：
[新任エンジニア／レビュアー／運用担当者]
優先して確認する対象：
- [対象ファイル]
- 呼び出し元
- 型定義
- 関連テスト
- 設定ファイル
- 既存README
ドキュメントには以下を含めてください。
- モジュールの責務
- 主な処理フロー
- 入力と出力
- 依存関係
- 発生する例外
- 設定項目
- 利用例
- 変更時の注意点
- 関連テスト
コードから確認できる事実と、推測した内容を分けてください。
既存READMEと実装が異なる場合は、READMEを正しいものとして扱わず、差異を報告してください。
置き換える項目：
- 対象コード
- 想定読者
- 必要な章
- 参考資料
使用時の注意：
ドキュメントの読者を指定すると、説明する用語や詳細度を調整しやすくなります。
例文12：仕様書またはADRの下書き作成
以下の既存コード、関連資料、会話内容を基に、[仕様書／ADR]の下書きを作成してください。
参照対象：
- [既存コード]
- [Issue・要件]
- [会話または決定事項]
- [テスト]
作成する内容：
- 背景
- 解決する課題
- 現在の仕様
- 採用する方針
- 検討した代替案
- 採用理由
- 影響範囲
- 移行手順
- テスト方針
- 未決事項
ルール：
- コードから確認できる事実を明示する
- 会話で合意済みの内容を明示する
- 推測した内容には「要確認」と付ける
- 情報が矛盾する場合は、一方を選ばず差異を記載する
- 確認できない日付や意思決定者を作らない
最後に、人間が確認すべき項目を一覧化してください。
置き換える項目：
- 作成する文書の種類
- 参照対象
- 必要な章
- 合意済み事項
使用時の注意：
会話履歴や古い資料だけで仕様を確定させず、現行コードとテストも確認対象に含めます。
| No. | 用途 | 主な入力情報 | 期待する出力 |
|---|---|---|---|
| 1 | 新規機能の調査 | 要件、参考ファイル | 現状、再利用候補、実装計画 |
| 2 | 段階実装 | 承認済み計画、変更範囲 | 実装差分、テスト結果 |
| 3 | 小規模一括実装 | 小規模要件、制約 | 実装、検証、差分説明 |
| 4 | 限定修正 | 症状、維持する仕様 | 最小差分の修正 |
| 5 | 改善案の比較 | 対象コード、評価観点 | リファクタリング候補 |
| 6 | リファクタリング | 維持する公開仕様 | 内部改善と回帰テスト |
| 7 | エラー調査 | ログ、再現手順 | 原因候補と確認手順 |
| 8 | 不具合修正 | 確認済み原因 | 修正と回帰テスト |
| 9 | テスト作成 | 対象機能、既存方針 | 正常系・異常系・境界値テスト |
| 10 | コードレビュー | Git差分、レビュー基準 | 重要度付きの指摘 |
| 11 | 技術文書 | コード、想定読者 | 責務・処理・依存関係の説明 |
| 12 | 仕様書・ADR | コード、要件、合意事項 | 事実と推測を分けた文書 |
CursorプロンプトとRulesの違い
プロンプトは、現在のタスクに対する一時的な指示です。一方、Rulesは、複数のタスクで継続して参照させる規約や前提として使います。
Cursorの公式ドキュメントでは、Project Rules、User Rules、AGENTS.md、旧形式の.cursorrulesが案内されています。Project Rulesは.cursor/rulesに保存し、リポジトリ内でバージョン管理できます。User Rulesは個人環境へ適用するプレーンテキストの指示です。AGENTS.mdはMarkdownで管理できる簡潔な選択肢とされています。.cursorrulesは現在もサポートされていますが、公式にはProject Rulesへの移行が推奨されています。
個別タスクの条件を記載するプロンプト
タスクごとに変わる情報は、プロンプトへ記載します。
- 今回追加する機能
- 現在発生している不具合
- 変更するファイル
- 今回だけ維持する制約
- 今回の完了条件
- 今回だけ必要な回答形式
- 現在のエラーログ
- 今回の参考ファイル
過去の会話内容を前提にしすぎると、タスクに不要な条件が残る場合があります。重要な制約は、現在のプロンプト内で改めて示します。
同じ内容を何度も入力している場合は、Rulesへ移す候補として記録します。ただし、特定機能だけに関係する条件をAlways適用のルールへ入れると、無関係な作業にも影響する可能性があります。
開発方針と共通規約を記載するProject Rules
Project Rulesには、リポジトリ内で継続的に適用したい内容を記載します。
- 技術スタック
- ディレクトリ構成
- 命名規則
- 設計原則
- 共通の例外処理
- テストファイルの配置
- テストコマンド
- 禁止する実装
- セキュリティ上の注意
- 参考にすべきコード例
Project Rulesは、1つの巨大なファイルへまとめるより、フロントエンド、API、テスト、セキュリティなど、責務ごとに分けた方が管理しやすくなります。
CursorのProject Rulesには、Always、Auto Attached、Agent Requested、Manualという適用タイプがあります。Alwaysは常にコンテキストへ含まれ、Auto Attachedは指定したファイルパターンに応じて適用されます。Agent Requestedは説明に基づいてAIが必要性を判断し、Manualは明示的に指定した場合だけ適用されます。
適用範囲が限定できる規約はAuto Attached、頻繁には使わない専門的な手順はAgent RequestedまたはManualといった使い分けが考えられます。
正しいコード例、禁止例、確認コマンドを含めると、抽象的な理念だけを書くよりも具体的な判断基準を示せます。
個人・チーム・リポジトリの指示の分離
指示の管理場所は、適用対象と更新責任に応じて分けます。
User Rules：
- 応答言語
- 説明の詳しさ
- 個人の作業スタイル
- すべてのプロジェクトで使う個人的な好み
Project Rules：
- リポジトリ固有の設計規約
- コード構造
- テスト手順
- バージョン管理したい開発方針
AGENTS.md：
- Markdownで簡潔に管理するリポジトリ指示
- 既存のエージェント運用と共有したい基本方針
- 細かな適用条件を必要としない指示
Team Rules：
- 組織共通のセキュリティ方針
- 組織共通のレビュー方針
- 複数チームへ適用する開発ルール
なお、利用できるチーム管理機能や名称は契約プランやアップデートによって変わる可能性があります。導入時点の管理画面と公式ドキュメントを確認してください。
同じ指示を複数の場所へ重複して書くと、更新漏れや矛盾が生じます。それぞれのルールについて、正本となる管理場所を1つ決めることが重要です。
| 種類 | 適用範囲 | 主な管理者 | 適した内容 | 共有方法 |
|---|---|---|---|---|
| プロンプト | 現在のタスク | タスク担当者 | 目的、対象、今回の制約、完了条件 | 会話またはテンプレート |
| Project Rules | 対象リポジトリ | 開発チーム | 技術構成、設計規約、テスト手順 | .cursor/rulesをバージョン管理 |
| User Rules | 個人の全プロジェクト | 各利用者 | 応答言語、説明量、個人の好み | Cursorの個人設定 |
| AGENTS.md | 対象リポジトリ | 開発チーム | Markdownで管理する簡潔なエージェント指示 | リポジトリで共有 |
| Team Rules | 組織・チーム | 管理者 | 組織共通のセキュリティ・レビュー方針 | 契約プランの管理機能に応じて共有 |
Cursorプロンプトの精度を高める実行手順
Cursorの精度は、プロンプトの言い回しだけで決まりません。タスクの分割、コンテキストの選定、差分確認、テストまでを一連の開発プロセスとして設計する必要があります。
検証可能な単位へのタスク分割
大きな機能を一度に依頼すると、仕様漏れや広範囲な変更が発生した際に、どの工程で問題が起きたのかを特定しにくくなります。
たとえば、認証機能の追加は次のように分割できます。
- 現状の認証処理の調査
- 追加要件と既存仕様の整理
- データモデルとAPI設計
- API実装
- 画面実装
- 単体テスト
- 統合テスト
- 差分レビュー
機能単位だけでなく、調査、設計、実装、検証という確認可能な単位に分けることがポイントです。
ただし、小さく分けるほどよいわけではありません。各タスクが別々の前提で進むと全体の整合性を失うため、最初に全体の目的、アーキテクチャ、完了条件を共有します。
実装前のコード調査
実装前には、類似機能、共通処理、型定義、テスト、呼び出し元をAgentに調査させます。
調査結果には、次の項目を含めます。
- 再利用できる既存実装
- 拡張すべき既存コード
- 新規作成が必要な要素
- 変更候補
- 影響範囲
- 未確認事項
- 実装上のリスク
調査段階ではファイルを変更しないよう指示します。人間が計画を確認できる状態を作ることで、既存機能の重複実装や設計規約からの逸脱を早期に発見できます。
短縮プロンプト：
[機能名]に関連する既存コードを調査してください。
この段階ではファイルを変更しないでください。
類似実装、共通処理、型定義、テスト、呼び出し元を確認し、
以下を報告してください。
- 再利用できる実装
- 拡張すべき実装
- 新規作成が必要な要素
- 変更候補ファイル
- 影響範囲
- 未確認事項
「新しく作るもの」だけでなく、「既存コードを拡張するもの」を報告させると、重複実装を見つけやすくなります。
変更差分の確認と限定修正
初回の生成結果は完成品として扱わず、まず差分を確認します。
確認する項目は次のとおりです。
- 変更ファイル数
- 各ファイルの変更理由
- 差分量
- 公開APIへの影響
- データベースへの影響
- 依存パッケージの追加
- 無関係な命名変更
- 無関係なリファクタリング
- テストの追加・変更
- 設定ファイルの変更
問題がある場合は、「全部やり直してください」と指示するのではなく、修正対象、期待値、維持する箇所を限定します。
例：
「src/auth/login.tsのエラー処理だけを修正してください。APIクライアントと型定義の変更は維持し、その他のファイルは変更しないでください」
同じ修正を複数回依頼している場合は、今回のプロンプトに必要な条件が不足しているのか、Project Rulesに共通規約が不足しているのかを切り分けます。
テストと静的解析による完了判定
Agentの説明や「実装しました」という自己評価だけで完了を判断せず、テストや静的解析の結果を確認します。
既存プロジェクトに以下のコマンドがある場合は、実行対象として指定します。
- 単体テスト
- 統合テスト
- 型チェック
- リンター
- フォーマット確認
- ビルド
- セキュリティスキャン
テストがない変更では、重要な振る舞いを確認できるテストを追加させます。
コマンドを実行できない場合は、未検証のまま成功と報告させず、次の項目を出力させます。
- 実行できなかったコマンド
- 実行できない理由
- 未検証の範囲
- 人間が行う確認手順
- 想定されるリスク
テスト通過は必要な確認の一つですが、設計品質やセキュリティまで保証するものではありません。最終的には、人間が差分と影響範囲を確認します。
完了判定チェックリスト：
- 要件を満たしている
- 変更禁止範囲に差分がない
- 既存テストが通過している
- 追加機能のテストがある
- 型チェックが通過している
- リンターが通過している
- ビルドが成功している
- 未検証項目が明記されている
- 公開APIへの影響を確認した
- セキュリティ上の変更を確認した
Cursorプロンプトをチームで標準化する方法
個人のプロンプト技術だけに依存すると、メンバーごとに生成コードの品質や変更範囲が変わります。チームでは、プロンプトテンプレート、Rules、レビュー基準、効果測定をまとめて整備する必要があります。
頻出タスクのプロンプトテンプレート化
まずは、頻度が高く、失敗時の影響も大きいタスクからテンプレート化します。
- 新規機能の実装
- バグ修正
- リファクタリング
- テスト追加
- コードレビュー
- ドキュメント更新
テンプレートは、固定部分と置き換え部分に分けます。
固定部分：
- 調査・計画・実装・検証の手順
- 最小差分の原則
- テスト結果の報告
- 未確認事項の明記
- 変更範囲を越える場合の対応
置き換え部分：
- 今回の目的
- 対象ファイル
- 参考実装
- 制約
- 完了条件
- 実行コマンド
1つの長大な万能テンプレートではなく、用途別に短いテンプレートを用意します。
プロンプトテンプレート管理台帳の項目例：
- テンプレート名
- 利用場面
- 対象リスク
- 必須入力
- 任意入力
- 期待する出力
- 使用禁止場面
- 管理責任者
- 最終更新日
- 利用回数
- 改善履歴
コードと同様のRulesレビュー
Project Rulesは、一度作って終わりではありません。開発環境やアーキテクチャが変わると、古いルールが現行コードと矛盾する可能性があります。
Project Rulesをリポジトリで管理し、変更時には以下を確認します。
- ルールを追加する理由
- 対象となるファイル
- 既存ルールとの重複
- 既存ルールとの矛盾
- 適用タイプ
- 生成コードへの影響
- 正しいコード例
- 禁止例
- 確認コマンド
同じ失敗が繰り返された場合はRulesへの追加を検討し、使われなくなった指示は削除します。
CursorのProject Rulesはリポジトリ内の.cursor/rulesへ保存でき、適用範囲をパターンやディレクトリ単位で設定できます。
AI生成コードのレビュー責任
Cursorが生成したコードであっても、採用する開発者と組織が品質確認の責任を負います。
特に、以下の領域は人間による重点レビューが必要です。
- 認証
- 権限管理
- 決済
- 個人情報
- 暗号化
- インフラ設定
- データベース移行
- 外部公開API
- ログと監査
- ライセンス
Agentへセルフレビューを依頼することは有効ですが、人間のレビューを置き換えるものではありません。
レビュー記録には、生成コードであることだけでなく、次の情報を残します。
- 実行したテスト
- 確認した差分
- 確認者
- 設計レビューの有無
- セキュリティ確認の有無
- 未解決リスク
- 採用判断
AIが作ったかどうかより、どの確認を通過したコードなのかを記録する方が、運用品質を管理しやすくなります。
手戻りを含む導入効果の測定
Cursorの導入効果を、コード生成時間だけで評価すると、レビューや修正の増加を見落とす可能性があります。
評価候補は次のとおりです。
- 実装時間
- 調査時間
- レビュー時間
- 修正回数
- 差し戻し率
- 初回レビュー通過率
- 不要な変更ファイル数
- テスト追加数
- 本番障害件数
- 不具合の再発率
- プロンプト再利用率
- Rulesの更新回数
Cursor利用案件と非利用案件を比較する場合は、タスクの難易度や担当者の経験をそろえる必要があります。
また、プロンプトテンプレート導入前後で、初回レビュー通過率や不要差分の件数を測定すると、標準化の効果を把握しやすくなります。
短期的な生成速度だけでなく、レビューと手戻りを含む開発リードタイム、保守性、障害リスクまで評価することが重要です。
Cursorプロンプトの失敗要因と対策
Cursorの指示がうまく機能しない場合、プロンプトの表現だけでなく、コンテキスト、変更範囲、Rules、テスト、レビュー体制を確認します。
ここでは、代表的な失敗を「症状→原因→実害→対策」の順で整理します。
完成状態を判断できない抽象的な指示
症状：
- 機能自体は動くが、例外処理がない
- UIだけが実装され、API連携がない
- テストが作成されていない
- 既存仕様と異なる挙動になる
- Agentが独自に要件を補っている
原因：
「適切に実装する」「きれいに修正する」「使いやすくする」といった、検証できない表現だけで依頼していることが主な原因です。
実害：
不足項目がレビュー時に見つかり、追加実装や差し戻しが発生します。メンバーごとに「完成」の判断も変わります。
対策：
目的、対象範囲、技術要件、変更禁止事項、完了条件を6要素のテンプレートで示します。
曖昧なプロンプト：
ログイン画面を使いやすく修正してください。
改善例：
既存のログイン画面について、入力エラーをフォーム内に表示するよう修正してください。
変更対象：
- src/features/login/LoginForm.tsx
- 対応するテスト
維持する仕様：
- APIリクエスト形式
- 認証成功後の遷移先
- 既存のデザインシステム
完了条件：
- 必須項目が空の場合に各入力欄へエラーを表示する
- APIが401を返した場合に認証エラーを表示する
- 既存テストと追加テストが通過する
既存実装と重複するコンテキスト不足
症状：
- 既存の共通関数を使わない
- 同じ役割のAPIクライアントを新規作成する
- プロジェクトと異なる命名規則を採用する
- 既存の型を使わず、新しい型を定義する
- 類似機能と異なるエラー処理を追加する
原因：
参考ファイルや調査対象を指定せず、すぐに実装を始めさせていることが原因です。
実害：
重複実装が増え、将来の仕様変更で複数箇所を修正する必要が生じます。レビュー担当者も、どちらが正しい実装か判断しにくくなります。
対策：
類似実装、共通処理、型、テスト、呼び出し元を先に調査させ、再利用方針を計画へ含めます。
調査プロンプト：
実装前に、同じ役割を持つ既存コードを調査してください。
確認対象：
- 類似機能
- 共通関数
- APIクライアント
- 型定義
- テスト
- 呼び出し元
新規作成せず再利用できるものと、拡張が必要なものを分けて報告してください。
この段階ではファイルを変更しないでください。
コンテキストを無制限に増やすのではなく、判断の基準になる一次情報を優先します。
不要な変更を生む広すぎる依頼範囲
症状：
- 機能追加と無関係なリファクタリングが行われる
- 多数のファイル名が変更される
- 新しい依存パッケージが追加される
- 共通モジュールまで書き換えられる
- 1つの依頼で巨大な差分が生まれる
原因：
変更対象と変更禁止範囲を指定せず、複数の責務を1つのプロンプトへ詰め込んでいることが原因です。
実害：
レビュー範囲が拡大し、不具合が起きた際の原因特定も難しくなります。機能追加と内部改善のどちらが障害を起こしたのか分からない状態になります。
対策：
タスクを検証可能な単位へ分割し、変更可能なファイルと最小差分の条件を明記します。
範囲外の変更が必要な場合は、実行せず提案として報告させます。
長すぎるRulesと指示の矛盾
症状：
- あるルールでは最小差分を求め、別のルールでは積極的なリファクタリングを求める
- ファイルによって異なる命名規則が適用される
- 重要な禁止事項が反映されない
- 同じ依頼でも生成結果が安定しない
原因：
ルールを責務別に分けず追加し続け、適用範囲と管理元が整理されていないことが原因です。
実害：
Agentがどの指示を優先すべきか判断しにくくなり、チーム内でも正しい規約を確認できなくなります。
対策：
- Rulesを責務別に分割する
- 適用タイプを見直す
- 対象ファイルを限定する
- 重複するルールを削除する
- 相反する指示を統合する
- 個別タスクの情報をプロンプトへ戻す
- 正本となる管理場所を決める
Rules棚卸しチェックリスト：
- 現在も必要なルールか
- 適用対象が明確か
- 別のルールと重複していないか
- 別のルールと矛盾していないか
- Alwaysである必要があるか
- 正しいコード例が現行実装と一致しているか
- 禁止事項の理由が明確か
- 個別タスクの条件が混在していないか
- 管理責任者が決まっているか
- 最終更新日を確認できるか
Project Rulesは適用方法を分けられるため、すべてをAlwaysにせず、対象ファイルや利用場面に応じてスコープを設定します。
動作確認不足を生むテスト指定の欠如
症状：
- 正常系だけ動作する
- 型エラーを抑制して終了する
- 既存テストが失敗したままになる
- ビルドできない
- エラーを再現するテストがない
- コマンドを実行していないのに完了と報告する
原因：
実行すべきコマンドと完了条件を指定していないことが原因です。
実害：
レビュー後や本番反映後に不具合が見つかり、修正コストが増えます。
対策：
テスト、型チェック、リンター、ビルドの実行と結果報告を完了条件に含めます。
完了条件のテンプレート：
以下をすべて満たした場合に完了としてください。
- 指定した要件を実装している
- 既存テストが通過している
- 変更内容を確認するテストを追加している
- [型チェックコマンド]が通過している
- [リンターコマンド]が通過している
- [ビルドコマンド]が成功している
コマンドを実行できない場合は、成功と報告せず、
実行できない理由、未検証項目、手動確認手順を記載してください。
品質問題を見逃すAI出力の無検証採用
症状：
- 動作するが重複の多いコードが残る
- 関数が過度に複雑になる
- 例外処理が不足する
- アクセシビリティ上の問題が残る
- 権限確認が不足する
- 機密情報がログへ出力される
- 不要な外部依存が追加される
原因：
テスト通過やAIの説明だけで品質を判断し、人間の差分レビューを省略していることが原因です。
実害：
短期的には動作しても、保守性、セキュリティ、障害対応に長期的な負担が残ります。
対策：
- 重要度別のレビュー観点を定める
- 高リスク領域の承認者を定める
- 設計レビューが必要な変更を定義する
- テスト結果と未解決リスクを記録する
- AIのセルフレビューと人間のレビューを分ける
最終的な採用判断は、コードをレビューできる人間が行います。
失敗要因、リスク、対策、確認方法は表にまとめています。
| 失敗要因 | 主なリスク | 対策 | 確認方法 |
|---|---|---|---|
| 指示が抽象的 | 実装漏れ、独自解釈 | 6要素テンプレート | 要件と完了条件の照合 |
| コンテキスト不足 | 重複実装、規約逸脱 | 実装前調査、参考ファイル指定 | 類似実装と型の再利用確認 |
| 依頼範囲が広い | 巨大差分、障害原因の不明確化 | タスク分割、変更範囲固定 | 変更ファイル数と差分確認 |
| Rulesの重複・矛盾 | 出力の不安定化 | 責務別分割、適用範囲見直し | Rules棚卸し |
| テスト指定がない | 回帰、未検証の完了報告 | 検証コマンドと完了条件 | テスト・型・ビルド結果 |
| AI出力の無検証採用 | 品質・セキュリティ問題 | 人間のリスクベースレビュー | 承認記録と残存リスク確認 |
Cursorプロンプトを本番開発で利用する際の注意点
本番開発では、プロンプトの品質だけでなく、Cursorへ渡す情報、Agentに許可する操作、生成コードの採用基準を管理する必要があります。
プロンプトへ入力しない機密情報と認証情報
次の情報は、プロンプトや参照ファイルへ含めない運用を定めます。
- APIキー
- パスワード
- 秘密鍵
- アクセストークン
- Cookie
- 本番データ
- 顧客の個人情報
- 社外秘の認証設定
- 未公開の契約情報
- 機密情報を含むログ
ログを渡す場合は、メールアドレス、トークン、Cookie、内部URL、顧客IDなどをマスキングします。
.envや秘密情報を含むディレクトリを参照対象から除外することも重要です。Cursor公式のセキュリティ情報では、コードベースのインデックスから特定のファイルを除外する方法や、Privacy Modeに関する情報が案内されています。プライバシー設定やデータの取り扱いは更新されるため、利用時点の公式情報と契約条件を確認してください。
Cursor公式サイトは、Privacy Modeを有効にした場合、ユーザーデータを学習に利用しないことや、モデル提供者との契約・技術的制御を設けていると説明しています。企業利用では、この説明だけで判断せず、自社の情報区分、委託先管理、データ保持要件と照合する必要があります。
ターミナル操作と外部接続の権限制御
CursorのAgentは、設定されたツールを使ってコード編集やコマンド実行を行えます。Agentモードは複数ファイルの編集やターミナル操作に対応し、Askモードは読み取り中心の用途として案内されています。
以下の操作は、人間の承認対象として定義します。
- ファイルの大量削除
- データベース更新
- マイグレーション実行
- 本番環境への接続
- インフラ変更
- シークレットの更新
- パッケージ公開
- 外部APIへのデータ送信
- MCP経由の書き込み操作
- 権限設定の変更
本番環境の認証情報は開発環境から分離し、Agentが利用できる権限を最小化します。
MCPや外部ツールを利用する場合は、次の点を確認します。
- 接続先
- 取得する情報
- 外部へ送信する情報
- 読み取り権限
- 書き込み権限
- 削除権限
- 操作履歴の保存
- 認証情報の管理方法
コマンドの実行履歴と変更差分を後から追跡できる状態にします。
生成コードの責任範囲と採用基準
AIが生成したコードも、通常のコードと同じレビュー、テスト、セキュリティ確認を通します。
変更リスクに応じた採用基準の例は次のとおりです。
低リスク：
- ドキュメント修正
- コメント修正
- テストのたたき台
- 定型的なコード変換
確認内容：
- 担当者による差分確認
- 既存テストの実行
中リスク：
- 業務ロジックの変更
- API処理の変更
- 共通コンポーネントの変更
- 依存パッケージの追加
確認内容：
- 担当者とレビュアーによる確認
- テストと型チェック
- 影響範囲の確認
高リスク：
- 認証
- 権限
- 決済
- 個人情報
- データベース移行
- インフラ設定
確認内容：
- 経験者による設計レビュー
- 複数人承認
- セキュリティ確認
- ステージング環境での検証
- ロールバック手順の確認
AIが参照した内容や変更理由を説明できない場合は、確認できないまま採用しません。
外部コードの転載、ライセンス、依存パッケージの追加も確認項目に含めます。
Cursorプロンプト導入の判断基準
Cursorを全面的に導入するかどうかは、機能の多さではなく、タスクの反復性、コードベースの標準化状況、レビュー体制、情報管理の4軸で判断します。
個人利用から始めやすい開発業務
初期段階では、失敗しても本番環境へ直接影響せず、人間が短時間で成果物を確認できるタスクが適しています。
始めやすいタスク：
- テストケースのたたき台
- 既存コードの説明
- ドキュメント更新
- 定型的な型変換
- 限定的なリファクタリング候補の分析
- コードレビューの補助
- エラーログの整理
初期導入に適さないタスク：
- 本番データの直接更新
- 認証基盤の全面刷新
- 仕様が不明なレガシーコードの大規模編集
- 人間が検証できない専門領域
- ロールバックできないインフラ操作
個人で有効だったプロンプトは、利用場面、入力情報、生成結果、修正内容を記録します。複数回試して再現性が確認できたものだけを共有候補にします。
導入初期は、生成にかかった時間だけでなく、生成後の修正時間も記録します。
チーム標準化に向いている開発組織
次の条件がそろっている組織は、プロンプトテンプレートやProject Rulesを整備する効果が出やすいと考えられます。
- 同じ技術スタックを複数人が使用している
- コーディング規約が言語化されている
- ディレクトリ構成が一定している
- テストコマンドが標準化されている
- コードレビュー基準がある
- AI生成コードをレビューできる経験者がいる
- Rulesの管理責任者を置ける
- 導入効果を測定できる
チーム標準化の準備度診断：
規約：
- コーディング規約が文書化されている
- 正しい実装例を示せる
- 禁止する実装が明確である
テスト：
- 標準的なテストコマンドがある
- 重要機能に自動テストがある
- テスト失敗時の対応が決まっている
レビュー：
- AI生成コードをレビューできる
- 高リスク領域が定義されている
- 承認責任者が決まっている
情報管理：
- AIへ入力できない情報が定義されている
- ログのマスキング手順がある
- 外部ツールの権限を管理できる
効果測定：
- 実装時間を測定できる
- レビュー時間を測定できる
- 手戻りや差し戻しを記録できる
すべてが整ってから始める必要はありません。ただし、不足している領域を把握し、対象業務を限定したうえで導入します。
導入範囲を限定すべき開発業務
次の領域では、一般的な機能開発より厳格な管理が必要です。
- 決済
- 認証
- 権限管理
- 個人情報
- 医療
- 金融
- 重要インフラ
- 法令上の記録が必要な処理
- 本番データの更新
- 外部システムとの機密連携
仕様書もテストもなく、変更影響を確認できないレガシーコードでは、自動編集よりも、調査、説明、テスト候補の作成から始めます。
外部委託先や複数企業が関係する開発では、コードや情報をAIへ渡せるか、契約条件も確認します。
利用禁止か全面許可かの二択ではなく、次の順に範囲を広げます。
- 読み取りと説明
- テスト案の作成
- 限定ファイルの編集
- 複数ファイルの編集
- コマンド実行
- 外部ツールとの連携
CursorのAI開発活用支援は「フリーコンサルタント.jp」へご相談ください
フリーコンサルタント.jpでは、事業会社やコンサルティングファーム出身のプロ人材が、生成AI・DX活用の戦略設計から現場のルール整備、社内への知見移転までを伴走支援します。実務経験豊富な人材が、上流の方針づくりから実行段階まで一貫して関わることで、導入後の定着まで見据えた支援が可能です。
まずは自社のどの業務・データで試すか、小さく始めるところから相談してみるのがおすすめです。
フリーコンサルタント.jpによるAI導入支援の事例
フリーコンサルタント.jpでは、AI・DX推進領域全般で企業の支援実績があります。ここでは、社内に専門人材が不足していた企業の支援事例を2件紹介します。
事例①｜大手飲食企業：需要予測・発注レコメンドAIの開発支援
200店舗以上・400品目の発注業務を店舗担当者の経験と勘に頼っており、業務が属人化していた大手飲食企業の事例です。データサイエンティストなどAI活用の経験者が社内に不足し、AIの本格運用に向けたデータ活用の進め方が分からない状態でした。
| 当時の課題 | ・データサイエンティスト・データアナリスト人材、AI活用の経験者が社内に不足 ・店舗情報・POSデータをもとにした需要予測を、複数人が同じ精度で行うことが困難 ・発注業務が現場の勘に依存し、担当者の休暇・退職で業務が滞るリスクを抱えていた |
|---|---|
| 実施したこと | ・店舗ごとの特徴を踏まえた変数を定義し、データを整理 ・PoC（概念実証）を経て、店舗ごとに高い精度で需要予測ができるAIモデルを構築・運用 |
需要予測AIの活用により発注業務の多くを自動化し、作業時間を削減。バックオフィス業務の負荷が軽減し、店舗担当者が接客などの対応に時間を割けるようになりました。
事例②｜大手通信キャリア企業：デジタル活用推進に向けたCoE組織の立ち上げ支援
業務効率化を目的に、デジタル活用組織（CoE＝Center of Excellence。複数部門の知見を集約する専門組織）の立ち上げを決定したものの、組織立ち上げの推進とデジタル技術活用の両方を担える人材が社内に不足していた大手通信キャリア企業の事例です。
| 当時の課題 | ・デジタル領域の知見と組織立ち上げ経験を併せ持つ人材が社内に不足 ・業務効率化ツールの開発・運用体制をゼロから構築する必要があった |
|---|---|
| 実施したこと | ・CoE組織の立ち上げから全体設計・運用構築・実運用までを一気通貫で伴走支援 ・事業部門への課題ヒアリングをもとにしたツール開発の仕組みを構築し、プロパー社員が自走できる体制へ知見を移転 |
CoE組織の立ち上げと運用の安定化により、組織立ち上げ前と比較して業務工数を約25%削減。プロパー社員が主体的に運用できる体制を構築し、外部人材への依存から段階的に脱却しています。
まとめ
Cursorプロンプトの精度を高めるには、言い回しを工夫するだけでなく、目的、背景、対象、制約、作業手順、完了条件の6要素を組み合わせることが重要です。
大きなタスクは、調査、計画、実装、検証へ分割し、各段階の結果を人間が確認します。毎回変わる条件はプロンプトへ記載し、継続的に適用する開発規約はProject Rulesなどへ分離します。
また、AIの生成速度だけで導入効果を判断してはいけません。レビュー時間、手戻り、不要な差分、保守性、セキュリティまで含めて評価する必要があります。
まずは、本記事で紹介した6要素の基本テンプレートを、バグ修正やテスト作成などの頻出業務へ適用してください。そのうえで、同じ問題が繰り返される指示だけをProject Rulesへ移すと、過剰なルールを増やさずにチーム標準化を進められます。
