Cursor RulesとMCPを使って全自動Githubのワークフローを実現
Cursor Rules: AI ペアプログラミングを最適化する 8 つのルール
はじめに
Cursor Rules とは
Cursor Rules は、Cursor で AI とのペアプログラミングを最適化するために設定できるルール体系です。.cursor/rules/
内に定義するファイルや Cursor の設定画面で定義することで、AI に対して開発方針、コーディング規約、プロジェクト固有の制約などを伝えることができます。
私が作成した Cursor Rules はすべて Github に公開していますので、参考にしてください。
https://github.com/lvncer/cursor-rules
また、Github 連携時に各種ドキュメントのテンプレートを公開していますので、こちらも合わせて参考にしてください。
https//github.com/lvncer/team-git-rules
最近の課題:Cursor Agent の Rules 無視問題
しかし、最近の Cursor Agent(特に新しいバージョン)では、設定した Rules を無視する傾向が強くなっています。特に、プロジェクトの最初には自動で読み込んでくれていたルールも、進むにつれてだんだんと見なくなって方向性がずれていきます。
実際に発生した問題例
環境固有の問題:
- コマンド操作の提案が Bash になっていて、PowerShell ではエラーになる
-
ls
やrm
など Linux コマンドを提案され、Windows で実行できない - 複数コマンドの実行が
&&
で提案され、Windows では動作しない
技術スタック無視の問題:
- GET API を作成しようとする(Next.js Server Components 優先ルールを無視)
- SWR ライブラリを使わずに fetch を直接使用
- Shadcn/ui を使わずに独自の UI コンポーネントを作成しようとする
プロジェクト構造の問題:
- SQL スキーマ定義ファイルを
/public/sql
以外に配置 - 指定したディレクトリ構造を無視して独自の構造を提案
- 既存の UI コンポーネントを変更しようとする(UI 変更禁止ルールを無視)
開発フローの問題:
- Issue 作成やブランチ作成をせずにいきなりコード実装を始める
- フェーズ管理を無視して一気に全機能を実装しようとする
- コミットメッセージが英語になる(日本語指定を無視)
これらの問題により、修正作業に多くの時間を費やすことになり、開発効率が大幅に低下するケースが頻発しています。
Claude Sonnet 4 の高性能がもたらすパラドックス
興味深いことに、Claude Sonnet 4 の性能が高すぎることで、逆に Rules よりも優れたワークフローを自然と実施してくれるケースが増えています:
Claude 4 は Rules を超えて、エラーハンドリング、型安全性、パフォーマンス最適化を自動的に考慮した提案をしてくれます。
Cursor Rules と MCP と Claude Sonnet 4 を活用した AI ペアプログラミングにおいて、効率的な開発を実現するための包括的なルール体系について解説します。
8 つのルール詳細解説
全ルール共通事項
- すべてのファイルの先頭に参照したらファイル名を発言するように
1. グローバルルール
変更の必要: ほとんどなし | 適用タイミング: 常時
核心原則:予測可能性の確保
- 明示的指示以外の変更禁止
- 不明点は必ず確認を取る
- ステップバイステップ実行
- 重複機能の確認
2. Next.js ベストプラクティス
変更の必要: 場合による | 適用タイミング: 常時
重要な原則:
- GET API 作成禁止 → Server Components でデータフェッチ
- POST/PATCH/PUT/DELETE のみ作成
- Server Actions 積極活用
ディレクトリ構造:
src/
├── app/ # ルーティング・ページ
├── components/ # Reactコンポーネント
│ ├── ui/ # ShadCn UIコンポーネント
│ └── layouts/ # レイアウト
├── hooks/ # カスタムフック
└── lib/ # ユーティリティ
├── constants/
├── types/
└── utils/
3. 技術スタック
変更の必要: あり | 適用タイミング: 常時
フロントエンド: React, Next.js, TypeScript, Shadcn/ui, Tailwind CSS, Clerk
バックエンド: Prisma, Supabase
その他: Server Actions, Zod, date-fns
などなど
4. ユーザー環境ルール
変更の必要: 場合による | 適用タイミング: 常時
Windows 11 + PowerShell 環境への最適化
- Bash コマンド使用禁止
- Windows 固有の考慮事項
5. ワークフローループ
変更の必要: ほとんどなし | 適用タイミング: 常時
Issue → ブランチ → 開発 → PR → マージの完全自動化
- GitHub MCP 連携
- フェーズ管理システム
6. UI/UX 設計・実装ルール
変更の必要: ほとんどなし | 適用タイミング: .tsx
最重要制約:
- 既存 UI 変更は承認なしで禁止
- Shadcn/ui コンポーネント優先使用
- Tailwind CSS ユーティリティクラス使用
7. データベース設計ルール
変更の必要: 場合による | 適用タイミング: マニュアル
命名規則:
- モデル:パスカルケース(
User
,Post
) - フィールド:キャメルケース(
firstName
,createdAt
) - 外部キー:
[参照テーブル名]Id
8. テスト駆動開発(TDD)ルール
変更の必要: ほとんどなし | 適用タイミング: マニュアル
Red-Green-Refactor サイクル徹底
- Jest + React Testing Library 使用
- 80%以上のカバレッジ目標
-
/src/components/__tests__/
に配置
ワークフローループ:GitHub MCP 連携の核心
GitHub MCP(Model Context Protocol)とは
GitHub MCP により、AI が直接 GitHub と連携できるようになりました。これにより、Issue 作成から PR マージまでの全開発プロセスを AI が自動管理できます。
完全自動化された開発フロー
Issue 作成 → ブランチ作成 → フェーズ開発 → コミット → PR 作成 → 手動マージ
1. Issue 作成(MCP 自動実行)
最初のステップとして、必ず Issue を作成します:
create_issue(
title="機能名: 具体的な説明",
body="Issue template使用",
labels=["enhancement"],
assignees=["username"]
)
2. ブランチ作成とフェーズ管理
Issue 作成後、自動的にブランチを作成し、フェーズテンプレートを適用:
## 実装フェーズ
- [ ] **Phase 1: 環境設定・準備**
- [ ] ブランチ作成 (`feat/123-feature`)
- [ ] 依存関係追加
- [ ] **Phase 2: [具体的な作業内容]**
- [ ] 詳細タスク 1
- [ ] 詳細タスク 2
- [ ] **Phase N: テスト・検証**
- [ ] ビルドテスト
- [ ] 機能テスト
3. 開発とコミット管理
重要: コミットはコマンドラインで実行
# 各フェーズ完了時に必ずコミット
git add .
git commit -m "フェーズ2完了: ユーザー認証機能 (#123)"
git push origin feat/123-user-auth
コミットメッセージの規則:
- 簡潔な日本語で記述(50 文字以内)
- Issue 番号を必ず含める
- フェーズ完了時とフェーズ内の意味のある単位でコミット
4. 進捗管理(MCP 自動実行)
フェーズ完了時に自動で Issue を更新:
# フェーズ完了時の自動更新
update_issue(
issue_number=123,
body="更新されたフェーズチェックリスト"
)
add_comment(
issue_number=123,
body="Phase 2完了。コミット: abc1234"
)
5. PR 作成(MCP 自動実行)
全フェーズ完了後、自動で PR を作成:
create_pull_request(
title="feat: ユーザー認証機能実装 (#123)",
body="PRテンプレート使用",
head="feat/123-user-auth",
base="main"
)
6. マージと完了(手動実行)
- 自動チェック通過確認
- 手動レビュー
- 手動マージ実行
- Issue 自動クローズ
- ブランチ削除
ワークフローループの利点
- Single Source of Truth: 進捗は Issue 内で一元管理
- 完全なトレーサビリティ: Issue 番号でコミットと PR を追跡
- 自動化による効率化: プロジェクト管理の負担を大幅軽減
- 品質保証: フェーズ管理による段階的な品質チェック
この仕組みにより、開発者はコードに集中でき、プロジェクト管理は AI が自動で行います。
実際の開発プロンプト例
実際のプロジェクト(ライトニングトーク管理サイトでの開発)で発生した会話例です。
新機能実装 - 無効なリンクの実装手順
Exported on 5/31/2025 at 19:39:29 GMT+9 from Cursor (0.50.7)
User
実装を始めていきましょう。今回は簡単です。Hero セクションの Featured Talks と Topics の各リンクを無効にしてください。ここであなたには cursor rules に従って @workflow.mdc に沿って丁寧に実装を進めてください。
Cursor
workflow.mdc
に従って、Hero セクションの Featured Talks と Topics のリンクを無効にする実装を進めます。まず、Issue 作成から始めましょう。
まず、現在のリポジトリ情報を確認してから Issue を作成します。
リポジトリ情報を確認できました。owner:
lvncer
, repo:lt
です。Issue を作成します。
Issue #62 が作成されました。次にPhase 1: 環境設定・準備を開始します。ブランチを作成します。
ブランチが作成されました。次に現在の Hero セクション構造を確認します。
現在の Hero セクション構造を確認できました。次に、具体的にどのリンクを無効化する必要があるかを詳しく見てみます。
現在の構造を理解しました。Phase 1 が完了したので、Issue を更新して Phase 2 に進みます。
Phase 2: リンク無効化実装を開始します。まず、Featured Talks の"View all talks"ボタンを無効化します。
"use client";
import TalkCard from "@/components/talks/TalkCard";
import { Button } from "@/components/ui/button";
import Link from "next/link";
import { ArrowRight } from "lucide-react";
import { Talk } from "@/types/talk";
interface FeaturedTalksProps {
featuredTalks: Talk[];
}
export default function FeaturedTalks({ featuredTalks }: FeaturedTalksProps) {
return (
<section className="py-16 md:py-24 bg-accent/50">
<div className="container mx-auto px-4">
<div className="flex flex-col md:flex-row justify-between items-start md:items-center mb-12">
...省略
</div>
<div className="grid grid-cols-1 md:grid-cols-3 gap-6">
{featuredTalks.map((talk: Talk) => (
<TalkCard key={talk.id} talk={talk} />
))}
</div>
</div>
</section>
);
}
次に、Topics セクションの各トピックリンクを無効化します。
import HeroSection from "@/components/ui/heroSection";
import FeaturedTalks from "@/components/ui/featuredTalks";
import HowItWorks from "@/components/ui/howItWorks";
import { Button } from "@/components/ui/button";
import Link from "next/link";
import { Zap } from "lucide-react";
import { SAMPLE_TALKS } from "@/lib/data";
export default function Home() {
return (
<>
<HeroSection />
<FeaturedTalks featuredTalks={SAMPLE_TALKS} />
<HowItWorks />
{/* Topics Section */}
<section className="py-16 md:py-24">
<div className="container mx-auto px-4">
<div className="text-center mb-16">
...省略
</div>
<div className="grid grid-cols-2 md:grid-cols-3 lg:grid-cols-4 gap-4">
{[
"React",
"Next.js",
"TypeScript",
"JavaScript",
"CSS",
"Accessibility",
"Performance",
"State Management",
].map((topic) => (
<div
key={topic}
className="flex items-center justify-center p-4 rounded-lg border bg-card opacity-50 cursor-not-allowed text-center"
>
<span>{topic}</span>
</div>
))}
</div>
</div>
</section>
// ... existing code ...
Phase 2 が完了しました。次に Phase 3 のテスト・検証を行います。まず、ビルドテストを実行します。
ESLint エラーが発生しました。使用していない Link インポートを削除します。
"use client";
import TalkCard from "@/components/talks/TalkCard";
import { Button } from "@/components/ui/button";
import { ArrowRight } from "lucide-react";
import { Talk } from "@/types/talk";
// ... existing code ...
再度ビルドテストを実行します。
ビルドが成功しました!次に開発サーバーを起動して機能テストを行います。
Phase 2 と 3 が完了しました。変更をコミットします。
コミットメッセージが長すぎたようです。シンプルなコミットメッセージで再試行します。
ブランチをプッシュします。
Issue を更新して完了状況を報告します。
最後に PR を作成します。
最終的に Issue に完了報告をします。
## 🎉 実装完了!
`workflow.mdc`に従って、Hero セクションの Featured Talks と Topics のリンク無効化を完了しました。
### 実装内容
**Featured Talks セクション** (`src/components/ui/featuredTalks.tsx`)
- "View all talks" ボタンのリンクを無効化
- `disabled` 属性と視覚的スタイルを適用
**Topics セクション** (`src/app/page.tsx`)
- 各トピックの `<Link>` を `<div>` に変更
- 視覚的無効化スタイルを適用
### 視覚的変更
- 無効化されたリンクは透明度 50%で表示
- カーソルが `not-allowed` に変更
- ユーザーが無効化状態を明確に認識可能
### 完了したワークフロー
✅ **Issue #62** 作成
✅ **ブランチ作成**: `feat/62-hero-disable-links`
✅ **3 つのフェーズ完了**: 準備 → 実装 → テスト
✅ **コミット**: `40a53f2`
✅ **PR 作成**: #63
### テスト結果
✅ ビルドテスト成功
✅ ESLint エラーなし
✅ 機能テスト完了
✅ UI/UX 確認完了
実装が完了し、PR #63 が作成されました。レビュー後にマージしていただければと思います。
運用上の重要な注意点
TODO ファイル管理の失敗例
推奨しない方法:ローカル TODO ファイルの使用
当初、.cursor/todos/
ディレクトリで TODO を管理し、完了したタスクを .cursor/todos/done/
に MCP で移動する方法を採用していました。
.cursor/
├── todos/
│ └── done/
│ │ └── feature-dashboard.md
│ ├── feature-auth.md
│ ├── bug-login.md
問題点:Single Source of Truth (SSoT) 原則の崩壊
- ローカルの TODO ファイルと GitHub Issue の間で齟齬が発生
- どちらが最新の情報か判断できなくなる
- 進捗管理が二重化され、メンテナンスコストが増大
- チーム開発時に情報の同期が困難
結論:TODO ファイルの作成は推奨しない
GitHub Issue を唯一の情報源(Single Source of Truth)として使用し、ローカルでの TODO 管理は避けるべきです。
プロンプト履歴の保存管理
推奨方法:.cursor/prompts/
でのチャット履歴保存
Issue 完了時に、AI とのチャット履歴を手動で保存する仕組みを採用しています。
.cursor/
└── prompts/
├── 20250520-01/
│ ├── daily-schedule-issue.md
│ └── auth-implementation.md
└── 20250521-02/
└── bug-fix-login.md
命名規則(提案):
-
YYYYMMDD-NN/
形式でディレクトリ作成 - Issue 番号や機能名を含むファイル名
- Markdown 形式でチャット履歴をエクスポート
利点:
- 保存と続きの機能: 過去のコンテキストを参照して開発を継続
- ナレッジベース: 類似の問題解決時の参考資料
- 学習履歴: AI との対話パターンの蓄積
- デバッグ支援: 問題発生時の原因追跡
運用方法:
- Issue 完了段階で手動でチャット履歴をエクスポート
- 重要な技術的議論や解決策を含む会話を優先的に保存
- 将来の類似タスクで参照可能な形で整理
この方法により、AI ペアプログラミングの知見を蓄積し、継続的な開発効率の向上を実現しています。
(おまけ)最新の AI 開発トレンド
Claude Code による並列開発
最近、Claude Code による並列開発が注目を集めています。AI が複数のタスクを同時に処理し、開発速度を大幅に向上させる手法です。
小規模アプリケーションでの利点:
- 迅速なプロトタイプ作成
- シンプルな機能の高速実装
- 学習プロジェクトでの効率化
大規模アプリケーションでの注意点:
しかし、規模が大きく要件定義を細かく行う必要がある場合は注意が必要です:
- 方向性の乖離: AI が想定と異なる実装方針を選択するリスク
- 要件の誤解: 複雑な仕様を正確に理解できない可能性
- 一貫性の欠如: 複数の並列タスク間での整合性が取れない
- デバッグの困難: 問題発生時の原因特定が複雑化
推奨アプローチ:
厳密な Issue 定義と実施手順の明記により、AI の暴走を防ぐことが重要です。特に大規模プロジェクトでは、フェーズ管理と段階的な確認を徹底することで、方向性のずれを早期に発見・修正できます。
Claude Code Actions による自動 PR レビュー
Claude Code Actions による自動 PR レビューも急速に普及しています。
主な機能:
- コード品質の自動チェック
- セキュリティ脆弱性の検出
- パフォーマンス最適化の提案
- コーディング規約の自動確認
期待される効果:
- レビュー時間の大幅短縮
- 人的リソースの制約解消
- 一貫性のあるコード品質維持
これらの技術により、AI ペアプログラミングはさらに進化し、開発者の生産性向上が期待されています。
この記事は実際の Cursor Rules 運用経験に基づいて執筆されています。
Discussion