Cursor実践ガイド③：大規模プロジェクトとチーム導入のベストプラクティス

個人で使う分にはCursorの導入は簡単です。ただ、チームで使う・大規模なプロジェクトで使うとなると、考えるべきことが増えます。今回は、プロジェクト設定の最適化からチーム導入まで、実運用のノウハウを共有します。

.cursorrulesの設計

前回触れた .cursorrules ファイル。小規模プロジェクトなら数行で十分ですが、チームで使う場合はきちんと設計した方が成果に直結します。

効果的な.cursorrulesの構成

# プロジェクト概要
このプロジェクトは、B2B SaaSの管理画面。
Next.js 16 + TypeScript + Tailwind CSS + Prisma + PostgreSQL。

# 技術スタック
- フレームワーク: Next.js 16 (App Router)
- 言語: TypeScript（strictモード）
- スタイリング: Tailwind CSS
- ORM: Prisma
- DB: PostgreSQL
- テスト: Vitest + Playwright
- パッケージマネージャ: pnpm

# コーディング規約
- 関数はアロー関数を使用
- コンポーネントはfunctional componentのみ
- 命名: camelCase（変数・関数）、PascalCase（コンポーネント・型）
- import順序: React → 外部ライブラリ → 内部モジュール → 型
- エラーハンドリングは Result型パターンを使用

# ディレクトリ構造
- src/app/ → ページ（App Router）
- src/components/ → 共有コンポーネント
- src/lib/ → ユーティリティ、API クライアント
- src/services/ → ビジネスロジック
- src/types/ → 型定義
- prisma/ → スキーマ、マイグレーション

# やってはいけないこと
- any型の使用
- console.logをコミットに含める
- 直接的なDOM操作
- インラインスタイル

ポイント

プロジェクト概要を書く。 AIが「これは何のプロジェクトか」を理解した上でコードを生成するので、文脈に合った提案が返ってきます。

「やってはいけないこと」を明示する。 AIは頼まれたことはやるが、暗黙のルールは知らない。禁止事項を書いておくだけで、レビューの手戻りが減ります。

チームで合意してリポジトリにコミットする。 .cursorrules はプロジェクトのルートに置いてGit管理。個人の好みではなくチームのルールとして運用してください。

大規模プロジェクトでのインデックス最適化

Cursorはプロジェクト全体をインデックスしてコンテキストを構築しますが、巨大なプロジェクトではノイズが増えます。

.cursorignoreファイル

.gitignore と同じ形式で、インデックスから除外するファイルを指定できます。

# ビルド成果物
dist/
.next/
out/

# 依存パッケージ
node_modules/

# 自動生成ファイル
*.generated.ts
prisma/generated/

# 大きなデータファイル
data/*.csv
fixtures/

除外すべきものを適切に設定すると、AIの応答速度と精度の両方が改善します。特に node_modules と自動生成ファイルは必ず除外してください。

@ファイル参照を活用する

チャットで質問するとき、関連ファイルを明示的に指定できます。

@src/services/auth.ts と @src/middleware/auth.ts を見て、
認証フローの全体像を説明して

プロジェクトが大きいほど、「どのファイルを見るべきか」をAIに教えてあげた方が正確な回答が返ってきます。

MCP連携

MCP（Model Context Protocol）を使うと、CursorからGitHub、データベース、ドキュメントなどの外部システムに接続できます。

よく使うMCPサーバー

GitHub MCP。 Issue やPRをCursorから直接参照・操作。

GitHub Issue #234 の内容を確認して、その修正をAgent Modeで実装して

データベースMCP。 開発用DBのスキーマやデータをCursorから直接参照。

usersテーブルのスキーマを確認して、
アクティブユーザー数を取得するクエリを書いて

Docs MCP。 Notion や Confluenceのドキュメントを参照。

Notionの仕様書を参照して、決済フローのAPIエンドポイントを実装して

設定方法

プロジェクトルートに .cursor/mcp.json を作成：

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "your-token"
      }
    }
  }
}

MCPの設定もリポジトリにコミットしてチームで共有できます（トークンは環境変数で管理）。

チーム導入のステップ

フェーズ1：パイロット導入（1〜2週間）

技術的に好奇心が強い2〜3名で先行導入。この段階でやること：

Cursorのインストールと基本操作の確認
.cursorrules のドラフト作成
「こういう使い方が良かった」「これはダメだった」のログを残す

フェーズ2：ルール整備（1週間）

パイロットの結果を踏まえて：

.cursorrules をチームで合意してコミット
.cursorignore の設定
機密情報の取り扱いルールの策定（Businessプランのプライバシーモードの要否判断）
コードレビューでのAI生成コードの扱い方を決める

フェーズ3：全員展開

ハンズオンセッション（30分程度で十分）
最初の1週間は「質問OK」の空気を作る
2週間後に振り返り。使っていない人がいれば個別にサポート

よくある失敗パターン

「各自好きに使って」で放置。 ルールなしだと品質がバラバラに。.cursorrules を共有するだけで大幅に改善します。

AI生成コードのレビューを省略。 「AIが書いたから大丈夫」は危険。特にセキュリティ関連のコードは、AIに任せきりにしない。

全員同時に導入。 一気に切り替えると混乱する。パイロットで知見を溜めてから展開するのが堅実です。

Cursor vs Claude Code：使い分け

どちらもAIコーディングツールですが、得意領域が異なります。

観点	Cursor	Claude Code
インターフェース	GUIエディタ	ターミナル（CLI）
得意な作業	日常的なコーディング、部分的な修正	大きなリファクタリング、プロジェクト全体の変更
コンテキスト	エディタで開いているファイル + インデックス	プロジェクト全体を深くスキャン
適したスタイル	対話しながら少しずつ進める	大きな指示を一発で投げる
組み合わせ	IDE内で完結する作業	CI/CD連携、自動化スクリプト

両方を使い分けるのが理想。日常のコーディングはCursor、プロジェクト横断の大きな変更はClaude Code、という棲み分けが自然です。

まとめ

Cursorの3回シリーズを通じて、基本操作→中級テクニック→プロジェクト運用と段階的に進めてきました。

改めてポイントを整理すると：

個人利用は今すぐ始められる。 インストールして、Tabを押すだけ
Agent Modeが本質。 コードを書かせるだけでなく、考えさせ、実行させ、修正させる
チーム導入は.cursorrulesから。 ルールを共有するだけで、AI生成コードの品質が揃う

AIがコードを書く時代に、エンジニアの価値は「何を作るか」の判断と、「AIの出力が正しいか」の検証にシフトしていきます。Cursorはそのシフトを加速するツール。まずは使ってみてください。

シリーズ: Cursor実践ガイド｜公開日: 2026年3月15日