この業務で解決したいこと
Cursorを使う目的は、AIにコードを大量に書かせることではありません。既存のファイルを理解し、変更案を小さく作り、表示やテストで確かめ、差分をレビューするまでの時間を整えることです。自然言語で依頼できても、要件、権限、公開判断、顧客への影響をAIへ丸投げすることはできません。
この記事では、非エンジニアがCursorを使い始めるときに、何を任せ、何を人が確認するかを整理します。最初から新しいサービスを作るのではなく、戻し方が分かる小さな変更から試すと、AIの提案を安全に評価できます。
Cursorを使う前に決める4つのこと
| 観点 | 決める内容 | 例 |
|---|---|---|
| 目的 | 何を改善したいか | 記事ページの読みやすさを直す |
| 対象 | 変更してよいファイル | 特定のCSSとテンプレートだけ |
| 確認 | 何で正しさを確かめるか | ブラウザ表示、テスト、差分 |
| 戻し方 | 問題があればどう戻すか | Git、バックアップ、以前のZIP |
依頼が「いい感じに直して」だけでは、Cursorも人も結果を判断できません。対象ファイル、変えてよい範囲、完成条件、触れてはいけない情報を短く書きます。まず計画を出させ、実装前に対象が正しいかを確認するだけでも、意図しない変更を減らせます。
活用例
既存サイトの修正、IDE内の補完、ターミナル中心の開発支援を作業ごとに比較する。
この例では、Cursorへいきなり本番反映を依頼しません。最初に「対象ファイルと変更案を示す」「目的以外は変更しない」「確認手順を最後に出す」と依頼します。次に、人が差分を読み、ローカルまたは検証環境で確認します。期待と違うときは、変更を追加する前に戻し、依頼文か要件を修正します。
PLAN → BUILD → TEST → REVIEW の進め方
- PLAN：現状、変更する場所、完了条件、触れてはいけない範囲を文章にします。Agentを使う場合も、最初は調査と計画だけを依頼します。
- BUILD：変更は一つの目的に絞ります。複数の機能、ファイル、依存関係を一度に変えず、差分を読み切れる大きさに分けます。
- TEST：画面、入力、エラー時の動き、既存のテストを確認します。Cursorがテスト結果を示しても、何を確認したかを人が理解します。
- REVIEW：変更差分、実行したコマンド、追加された依存関係、秘密情報の混入を確認します。公開・マージ・本番操作は責任者が行います。
CursorのAgentは、検索、編集、ターミナル操作を組み合わせて作業できます。便利な反面、対象外のファイルやコマンドまで進む可能性があります。最初は承認を求める設定を保ち、計画と差分を確認する習慣を作ります。Background Agentや外部サービス連携は、権限とデータの扱いを組織で決めてから検討します。
AIへ渡す指示の型
次の5項目を揃えると、依頼の曖昧さを減らせます。
| 項目 | 書く内容 | 例 |
|---|---|---|
| 目的 | 何を良くするか | 申込み導線を読みやすくする |
| 対象 | 読んでよい範囲 | assets/css/article.cssのみ |
| 制約 | してはいけないこと | HTML構造と公開設定は変えない |
| 確認 | 完了の条件 | PC・スマホで崩れないこと |
| 出力 | 最後に報告すること | 変更ファイルと確認手順 |
たとえば「対象のCSSだけを確認し、変更案と影響範囲を先に説明してください。実装はまだしないでください」と依頼すれば、計画段階で止まれます。実装を許可するときも「変更後に差分と確認方法を示してください」と続けます。AIの回答が速いほど、依頼とレビューの型を固定する価値があります。
使う前に確認すること
- リポジトリ、フォルダ、ファイルのうち、今回見せてよい範囲
- APIキー、パスワード、個人情報、顧客情報を含むファイルの扱い
- Agentが実行しようとするコマンドと、追加・削除・更新されるもの
- 画面確認、テスト、レビュー、公開を担当する人
- 変更を戻す手順と、想定外の動きが出たときに止める基準
Cursorのプライバシー設定、データの扱い、チーム管理、料金は変わり得ます。導入前と設定変更時には、必ず公式ドキュメントと自社の情報管理ルールを確認します。個人の試用と、チームのリポジトリやGitHub権限を扱う利用は、同じ判断ではありません。
よくある誤りと直し方
最も多い誤りは、変更の目的を決めずに大きな依頼を出すことです。「このサイトを改善して」と依頼すると、文章、CSS、テンプレート、依存関係まで広く変更される可能性があります。最初は「この見出しを二行以内にする」「このボタンの余白を確認する」のように、一つの画面・一つの目的へ絞ります。変更が正しいかを確認できたら、次の小さな変更へ進みます。
次に多いのは、AIが作ったコードを読まずに採用することです。表示が一度うまく見えても、別の画面幅、既存機能、エラー時の動き、セキュリティまで正しいとは限りません。差分で何が変わったかを確認し、テストやブラウザ確認を行います。読めない差分は受け入れず、説明を求めるか、変更単位を小さくします。
また、秘密情報を含むフォルダをそのまま開くことも避けます。設定ファイル、顧客データ、鍵、トークンは、必要最小限の範囲に分けます。チームでは、誰が閲覧でき、誰が編集や公開を承認できるかを決めます。AIの利用量ではなく、意図しない変更を止められたか、確認にどれだけ時間がかかったかを振り返ると、導入範囲を適切に広げられます。
Cursorを使わない・止める判断
Cursorは、要件が決まっていて、変更の結果を確認でき、問題があれば戻せる作業で力を発揮します。反対に、目的が決まっていない新規事業の判断、法務・会計・人事の最終判断、顧客へ影響する本番操作、障害中の緊急変更を、説明なしで任せる用途には向きません。急いでいるときほど、AIの提案を検証する時間が省かれやすいためです。
止めるべき兆候も決めておきます。対象外のファイルを触ろうとする、意味を説明できないコマンドを実行しようとする、想定外の依存関係を追加する、秘密情報や外部サービスへの送信が見える、テストが失敗する、といった場合は実装を続けません。作業を中断し、最初の計画、対象範囲、権限、バックアップへ戻ります。
「AIを使わない」という判断は、導入の失敗ではありません。人が決めるべきことと、AIが下書きにできることを分けられた状態です。まず人が十分に理解できる小さな変更で成果を確認し、その後にルール、テスト、自動化の順で広げます。Cursorを速さのためだけに使うのではなく、変更の理由と確認の記録を残すために使うと、チームでも続けやすくなります。
関連記事
参考情報
CursorとGitHub Copilot・Claude Codeの違いで確認したい判断基準
このテーマで大切なのは、作業量を増やすことではなく、変更の理由と確認結果を残すことです。最初の数回は、Cursorが提案した内容をそのまま採用せず、人が修正した箇所を記録します。修正が集中する部分は、要件が足りない、既存コードの前提を読めていない、または人の判断が必要な工程です。原因ごとに、依頼文、プロジェクトルール、テスト、レビューのどれを改善すべきかを分けます。
Cursor RulesやAGENTS.mdを使う場合も、長い社内規程を丸ごと入れるより、今回のプロジェクトで守る行動へ分けたほうが機能します。たとえば「変更前に対象ファイルを列挙する」「削除の前に理由を書く」「本番設定を変えない」「テストを実行できないときは理由を報告する」といった短い規則です。規則はコードと同じように見直し、守れなかった理由を次の更新へ反映します。
小さく始めるためのチェック
| 確認項目 | 最初の基準 | 見直すタイミング |
|---|---|---|
| 対象範囲 | 一つの画面または一つの機能 | 差分を読み切れないとき |
| 実行環境 | ローカルまたは検証環境 | 本番に近い条件が必要なとき |
| 品質 | 表示・テスト・差分を確認する | 修正や差し戻しが続くとき |
| 権限 | 必要な人だけに限定する | 担当者や連携先が変わるとき |
このチェックを通過した作業だけを、次の範囲へ広げます。AIの提案を断ることや、途中で作業を止めることも、失敗ではありません。確認できない変更を本番へ入れないことが、長期的にはもっとも速い改善につながります。