Cursor Rules / AGENTS.md 診断パックを始めます：AI開発が速くならない原因を見える化する

Last updated at 2026-05-26Posted at 2026-05-26

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 が迷わず動けるだけのルールと前提が用意されているかを見直すべきです。

補足：診断を試験的に受け付けています

自分のリポジトリや開発環境に適用したい方向けに、
Cursor Rules / AGENTS.md 診断パックを試験的に受け付けています。

対応内容は以下です。

既存の .cursor/rules / AGENTS.md / README のレビュー
Rules / AGENTS.md / README の役割分担診断
過剰・不足・重複しているルールの指摘
改善優先度の整理
そのまま Cursor に渡せる改善指示プロンプト作成

初回 Lite 診断は、3,000円〜5,000円を想定しています。

興味がある方は、プロフィールまたは各SNSから
「Cursor診断希望」とご連絡ください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up