Cursor を入れた。
AI に実装も調査もレビューも頼めるようになった。
それなのに、思ったほど開発が速くならない。
この状態は、かなりよくあります。
原因は単純で、AI IDE は「入れただけ」では開発プロセスに馴染まないからです。
AI にコードを書かせるだけなら簡単です。
しかし、実務で必要なのはコード生成そのものではありません。
- 既存設計を壊さない
- 仕様変更と実装修正を混同しない
- 影響範囲を確認する
- レビュー観点をそろえる
- チーム内の判断基準を統一する
- 不明点を勝手に補完しない
- 作業ログを残す
こうした前提がないまま Cursor を使うと、出力はそれっぽくても、実務では危ないものになります。
この記事では、Cursor Rules / AGENTS.md / README / レビュー観点をどう診断し、どこを整備すべきかを整理します。
あわせて、個人開発者・小規模チーム・システムエンジニア向けに試験的に始める「Cursor Rules / AGENTS.md 診断パック」の内容も紹介します。
対象読者
この記事は、以下のような人向けです。
- Cursor を入れたが、AI の出力品質が安定しない
-
.cursor/rulesに何を書けばよいか分からない -
AGENTS.mdと Rules の役割分担が曖昧 - AI が勝手に大きな修正をして困っている
- 実装、調査、レビューの指示が毎回ブレる
- チームで AI 開発を使いたいが、運用ルールがない
- README や設計メモが散らばっていて、AI に前提を渡しにくい
逆に、すでにチーム内で AI 開発標準、レビュー基準、プロンプト運用、ドキュメント管理がかなり整っている場合は、この記事の内容は初歩的に感じるかもしれません。
Cursor を入れても速くならない典型パターン
Cursor を使っていて開発が速くならない場合、だいたい次のどれかに該当します。
1. 毎回プロジェクト説明をしている
毎回チャットで、
- このプロジェクトは何か
- どの技術スタックか
- どのディレクトリを触るべきか
- 命名規則は何か
- 触ってはいけないファイルはどれか
- どの粒度で出力してほしいか
を説明しているなら、かなり効率が悪いです。
人間に毎回オンボーディングしているのと同じです。
AI にも、最初に読む前提資料が必要です。
2. AI に任せる範囲が曖昧
AI に「いい感じに修正して」と頼むと、AI は本当にいい感じに修正しようとします。
問題は、その「いい感じ」が現場の期待と一致しないことです。
たとえば、以下の境界が曖昧だと危険です。
- DB 定義を変えてよいか
- 共通部品を修正してよいか
- 既存仕様を変えてよいか
- 外部ライブラリを追加してよいか
- 画面文言を変えてよいか
- テストコードを追加してよいか
- 影響範囲をどこまで見るべきか
AI は明示されていない制約を読み切れません。
だからこそ、Rules や AGENTS.md に「やってよいこと」「やってはいけないこと」を書く必要があります。
3. 実装用とレビュー用の指示が混ざっている
Cursor に実装させる指示と、レビューさせる指示は分けた方が安定します。
実装時に必要なのは、
- 目的
- 変更対象
- 受け入れ条件
- 制約
- 既存仕様との整合
- 出力形式
です。
一方で、レビュー時に必要なのは、
- 仕様逸脱がないか
- 既存設計を壊していないか
- 例外処理は足りているか
- テスト観点は十分か
- 影響範囲は妥当か
- セキュリティ上の問題はないか
- 保守性は下がっていないか
です。
この2つを同じプロンプトで処理しようとすると、AI の出力は散らかります。
4. README が人間向けにしか書かれていない
README は人間向けの説明としては十分でも、AI に作業させる前提資料としては不足していることがあります。
AI にとって重要なのは、セットアップ手順だけではありません。
- このプロジェクトの目的
- 主要な業務・機能
- ディレクトリの責務
- 重要な設計判断
- やってはいけない変更
- テスト・レビューの方針
- 変更時に確認すべき観点
こうした情報がないと、AI はコードの表面だけを見て判断します。
Rules / AGENTS.md / README の役割分担
個人的には、最小構成は次のように考えています。
project/
├── README.md
├── AGENTS.md
├── .cursor/
│ └── rules/
│ ├── 00_project_overview.mdc
│ ├── 10_coding_policy.mdc
│ ├── 20_review_policy.mdc
│ └── 30_output_format.mdc
└── docs/
├── ai_context.md
└── decision_log.md
それぞれの役割は以下です。
| ファイル | 主な役割 |
|---|---|
README.md |
人間とAIの両方に向けたプロジェクト概要 |
AGENTS.md |
AIエージェントに対する作業方針・責務・制約 |
.cursor/rules/*.mdc |
Cursor 上で常に効かせたいルール |
docs/ai_context.md |
AIに渡したい背景情報や業務文脈 |
docs/decision_log.md |
設計判断や運用判断の記録 |
重要なのは、全部を1ファイルに詰め込まないことです。
ルールが長すぎると、AI が守るべき要点を見失います。
逆に、分割しすぎると管理が破綻します。
最初は、以下の4つぐらいに絞るのが現実的です。
- プロジェクト概要
- コーディング方針
- レビュー方針
- 出力フォーマット
AGENTS.md の最小テンプレート
まずは、このくらいから始めるのが扱いやすいです。
# AGENTS.md
## 目的
このプロジェクトでは、AIエージェントに実装・調査・レビュー補助を行わせる。
AIエージェントは、既存設計と業務上の制約を尊重し、
推測で仕様変更を行わないこと。
## 基本方針
- 既存設計を優先する
- 変更前に影響範囲を確認する
- 不明点は推測せず「未確認事項」として明示する
- 仕様変更に該当する可能性がある場合は、人間に確認する
- 実装後はレビュー観点とテスト観点を必ず提示する
- 秘密情報、認証情報、個人情報を出力しない
- 大きな変更は小さなステップに分割して提案する
## 禁止事項
- 明示されていない仕様変更
- 無断での外部ライブラリ追加
- 既存の共通処理への大規模変更
- DB定義やマイグレーションの無断変更
- APIキーや認証情報の出力
- テストなしの大規模リファクタリング
## 出力形式
作業後は、必ず以下の形式で報告する。
- 実施内容
- 変更ファイル
- 判断理由
- 影響範囲
- リスク
- テスト観点
- 未確認事項
- 人間に確認してほしい点
この時点で、Cursor への指示はかなり安定します。
.cursor/rules の例
00_project_overview.mdc
---
description: "プロジェクト概要と前提情報"
globs:
- "**/*"
alwaysApply: true
---
# プロジェクト概要
このプロジェクトは、既存の業務要件を満たすためのアプリケーションである。
AIは、実装前に以下を確認すること。
- 対象機能の目的
- 既存コードとの整合性
- 変更対象ファイル
- 影響範囲
- 仕様変更に該当するかどうか
不明点がある場合は、推測で補完せず「未確認事項」として出力する。
10_coding_policy.mdc
---
description: "コーディング方針"
globs:
- "**/*.ts"
- "**/*.tsx"
- "**/*.js"
- "**/*.jsx"
- "**/*.cs"
- "**/*.sql"
alwaysApply: true
---
# コーディング方針
- 既存の命名規則に合わせる
- 既存のディレクトリ構成を尊重する
- 共通処理を変更する場合は、影響範囲を明示する
- 例外処理を省略しない
- 不要な抽象化を追加しない
- 変更は最小単位に分ける
- 実装後にテスト観点を提示する
20_review_policy.mdc
---
description: "レビュー観点"
globs:
- "**/*"
alwaysApply: true
---
# レビュー観点
AIは実装後、以下の観点で自己レビューする。
- 既存仕様との整合性
- 影響範囲の妥当性
- 例外処理
- 境界値
- セキュリティ
- パフォーマンス
- テスト観点
- 可読性
- 保守性
- 不要な変更が含まれていないか
30_output_format.mdc
---
description: "出力フォーマット"
globs:
- "**/*"
alwaysApply: true
---
# 出力フォーマット
作業後は、以下の形式で出力する。
## 実施内容
## 変更ファイル
## 判断理由
## 影響範囲
## リスク
## テスト観点
## 未確認事項
## 人間に確認してほしい点
診断で見るポイント
Cursor Rules / AGENTS.md を診断するときは、単に「書いてあるか」ではなく、実務で効く状態になっているかを見ます。
1. 前提情報が足りているか
- プロジェクトの目的があるか
- 技術スタックが明記されているか
- ディレクトリ構成の責務が分かるか
- 重要な制約が書かれているか
- 触ってはいけない領域が分かるか
2. AI に任せる範囲が明確か
- 調査だけなのか
- 実装してよいのか
- レビューしてよいのか
- DB や共通処理を触ってよいのか
- 人間に確認すべき条件があるか
3. レビュー観点があるか
- 仕様整合性
- 影響範囲
- セキュリティ
- 例外処理
- テスト観点
- パフォーマンス
- 保守性
4. 出力形式が決まっているか
AI の回答が毎回違う形式だと、レビューが面倒になります。
出力形式は、最低でも以下を固定した方がよいです。
## 実施内容
## 変更ファイル
## 判断理由
## 影響範囲
## リスク
## テスト観点
## 未確認事項
## 人間に確認してほしい点
5. 重複・矛盾がないか
ありがちなのが、Rules と AGENTS.md と README に似たようなことが書かれていて、しかも微妙に内容が違うパターンです。
たとえば、
- README では「テスト必須」
- Rules では「必要に応じてテスト」
- AGENTS.md ではテストに言及なし
のような状態です。
これだと、AI も人間も判断に迷います。
診断パックでやること
今回、試験的に用意するのは「Cursor Rules / AGENTS.md 診断パック」です。
これは、テンプレートを売るものではありません。
既存のリポジトリやドキュメントを見て、AI開発が速くならない原因を診断し、改善案に落とすためのものです。
対応内容
- README の確認
- ディレクトリ構成の確認
- 既存の
.cursor/rulesの確認 -
AGENTS.mdの確認 - AI に渡している指示文の確認
- ルールの不足・重複・矛盾の洗い出し
- 改善優先度の整理
- Cursor に渡せる改善指示プロンプトの作成
依頼時に送ってほしいもの
最低限、以下があると診断しやすいです。
- README
- ディレクトリ構成
- 既存の .cursor/rules
- AGENTS.md
- package.json / csproj / requirements.txt など技術スタックが分かるもの
- Cursor で困っていること
- AI の出力で困った具体例
実案件や社内コードを送る場合は、必ず以下をマスキングしてください。
- 社名
- 顧客名
- 個人情報
- APIキー
- 認証情報
- 接続文字列
- 内部URL
- 本番環境情報
- 契約上公開できない情報
診断に必要なのは、機密情報ではなく、構造・ルール・運用の癖です。
納品物
初回の診断では、以下のようなものを返します。
1. 現状診断レポート
2. 不足しているRules一覧
3. 過剰・重複しているRulesの指摘
4. AGENTS.md改善案
5. README改善案
6. 優先的に整備すべきファイル一覧
7. そのままCursorに渡せる改善指示プロンプト
単なる感想ではなく、次の修正に進める形にするのが目的です。
診断レポートのイメージ
たとえば、以下のような形で返します。
# Cursor Rules / AGENTS.md 診断レポート
## 総評
現在の構成は、基本的なプロジェクト説明は存在するが、
AIエージェントに任せる範囲、禁止事項、レビュー観点が不足している。
特に、共通処理やDB変更に関する制約が明記されていないため、
AIが過剰な修正を提案するリスクがある。
## 良い点
- README にセットアップ手順がある
- 技術スタックが明記されている
- ディレクトリ構成がある程度整理されている
## 課題
- AGENTS.md が存在しない
- Cursor Rules が作業別に分かれていない
- レビュー観点が明文化されていない
- 出力フォーマットが固定されていない
- 不明点をどう扱うかのルールがない
## 優先度高の改善
1. AGENTS.md を追加する
2. 30_output_format.mdc を作成する
3. 20_review_policy.mdc を作成する
4. README にAI向けの前提情報を追記する
## Cursor投入用改善プロンプト
以下の方針で、AGENTS.md と .cursor/rules を整備してください。
- 既存READMEの内容を前提にする
- 仕様変更を勝手に行わない制約を明記する
- 出力形式を固定する
- レビュー観点を追加する
- 不明点は未確認事項として出力する
価格感
試験的な初回価格は、以下を想定しています。
Lite 診断：3,000円〜5,000円
- README / AGENTS.md / .cursor/rules の簡易診断
- 改善ポイント整理
- Cursor投入用プロンプト作成
Standard 整備：15,000円〜30,000円
- AGENTS.md 作成
- .cursor/rules 作成
- README改善案
- レビュー観点整理
- 運用チェックリスト作成
Team / 業務運用設計：50,000円〜
- 小規模チーム向けAI開発ルール設計
- Rules / AGENTS.md / レビュー運用の標準化
- 引き継ぎ・属人化防止のためのドキュメント整備
まずは Lite 診断から始める想定です。
このパックで解決したいこと
このパックで解決したいのは、「Cursor の使い方を教えること」ではありません。
本質的には、以下の状態を作ることです。
- AI が迷わない
- 人間が毎回説明しなくていい
- AI の出力形式がそろう
- レビュー観点がそろう
- 触ってはいけない範囲が明確になる
- 実装後に人間が判断しやすくなる
- プロジェクトの暗黙知が少しずつ明文化される
AI IDE の導入で重要なのは、ツールの設定だけではありません。
AI に仕事を渡せるように、プロジェクト側の情報を整えることです。
まとめ
Cursor は強いツールです。
ただし、導入しただけでは開発は速くなりません。
開発が速くなるのは、以下が整ったときです。
- プロジェクトの前提情報
- AI に任せる範囲
- 禁止事項
- レビュー観点
- 出力フォーマット
- ドキュメント更新ルール
- 判断ログ
言い換えると、Cursor 活用はプロンプトの問題だけではなく、開発運用の問題です。
.cursor/rules や AGENTS.md は、その運用を AI に伝えるための入口になります。
Cursor を入れても速くならない場合、次に見るべきなのは別の AI ツールではありません。
まずは、自分のプロジェクトに対して、AI が迷わず動けるだけのルールと前提が用意されているかを見直すべきです。
補足：診断を試験的に受け付けています
業務系システム開発に携わっているシステムエンジニアです。
C#、SQL Server、Oracle、Spring Boot、PostgreSQLなどを扱う開発・保守業務に関わりながら、近年はCursor、Claude Code、Codex、ChatGPTなどを活用したAIコーディング環境の整備に取り組んでいます。
AIツールは導入するだけでは、必ずしも開発が速くなるわけではありません。
・AIの出力品質が安定しない
・毎回同じ前提を説明している
・既存コードと異なる実装が生成される
・AIが必要以上に大きな変更を行う
・Rules、AGENTS.md、READMEの役割が曖昧
・チーム内で使い方が統一されていない
こうした問題は、AIの性能不足というより、プロジェクト固有の前提情報、制約、レビュー観点、作業手順が整理されていないことが原因であるケースが多いです。
私は、AIツールを「入れただけ」で終わらせず、実務で継続的に使える状態へ整備する支援を行っています。
【対応可能な内容】
・Cursor、Claude Code、Codex向けのAI開発環境診断
・AGENTS.md、.cursor/rules、READMEの設計・改善
・実装、調査、レビュー、テスト用プロンプトの整備
・AIが参照しやすいMarkdownドキュメントの作成
・Excel設計書、既存資料、業務知識の整理
・既存ルールの重複、矛盾、抜け漏れの確認
・小規模チーム向けのAI開発運用ルール作成
・SQL、C#、業務系システムに関する調査・改善支援
【このような方におすすめです】
・Cursorを導入したが、期待したほど開発が速くならない
・AIに何をどこまで任せてよいか分からない
・プロジェクトごとの指示書を作りたい
・個人依存の使い方から、再利用可能な運用に変えたい
・既存のRulesやAGENTS.mdを見直したい
・チーム内でAI活用の基準をそろえたい
【進め方】
- 現状とお困りごとを確認
- README、ディレクトリ構成、既存ルールなどを確認
- 課題、優先順位、改善方針を整理
- 必要なドキュメントやプロンプトを作成
- 実務で使える形に調整して納品
案件情報やソースコードを扱う場合は、必要最小限の範囲で確認します。
社名、顧客名、個人情報、APIキーなどの機密情報は、事前にマスキングをお願いします。
小さな診断からでも対応可能です。
「何を依頼すればよいか分からない」という段階でも、現在の状況を確認した上で整理します。
まずはお気軽にご相談ください。