Cursor をチーム展開する難しさ
個人ツールとしての Cursor は導入しやすい一方、10 人を超える組織でばらつきなく使うのは思った以上に難しい。本記事では FIXIT が実際に展開した 12 名・25 名のチームでハマったところと、解決策を共有します。AI 駆動開発で Cursor を組織標準 にしたい方を対象に書きました。AI 駆動開発全体の進め方は AI 駆動開発とは で解説しています。
中規模チームへの導入で直面する主な論点は次の 4 つです。
| 論点 | よくある症状 |
|---|---|
ルール (.cursor/rules) のばらつき | コードレビューで「この人の癖」が分かるほど属人化 |
| モデル選択 | 個人ごとに Auto/Opus/Sonnet が混在し、コストとレスポンスがぶれる |
| 機密データ取り扱い | 顧客データを context にコピペする事故が散発 |
| 文化的抵抗 | AI と並走することへの恥ずかしさ・苦手意識 |
それぞれの対処法を、実際の展開順に沿って解説します。
落とし穴 1: ルール (.cursor/rules) のばらつき
最も多い問題は「ルールが個人ごとにバラバラ」で、誰の PR か分かるくらい癖が出ること。AI ペアプログラミングが組織活動になる段階で、まず立ちはだかる壁です。
対策:
- リポジトリに
.cursor/rules/をコミットして共有する (これが大原則) - ルール変更は PR で議論する文化を作る
- ベースラインルールはテンプレートリポジトリで配布
具体的には、リポジトリのルートに次のような構造でルールを置きます。
.cursor/
└── rules/
├── 00-baseline.mdc # チーム共通の基本ルール
├── 10-tech-stack.mdc # 使用技術スタックと制約
├── 20-domain.mdc # ビジネスドメインの語彙
└── 90-personal.mdc # 個人設定 (gitignored)
90-personal.mdc だけを gitignore に入れ、それ以外はコミット対象。これで「個人カスタムの余地を残しつつ、チーム標準は共有」できます。
落とし穴 2: モデル選択
Auto モードで運用していると、コストやレスポンス品質がチームでまちまちになります。FIXIT では、
- 探索・ブレストは
Claude Sonnet - 大規模リファクタは
Claude Opus - 日常コーディングは
Auto
という使い分けをスタイルガイドで統一しました。「迷ったら Sonnet」という運用は AI 駆動開発の現場でも定着しており、月次コストが安定します。
| シーン | 推奨モデル | 理由 |
|---|---|---|
| 仕様の壁打ち | Claude Sonnet | コンテキスト長・推論の安定性 |
| 大規模リファクタ | Claude Opus | 多ファイル横断の保持力 |
| 日常タスク | Auto | コストパフォーマンス |
| 機密性高い領域 | Privacy Mode + Sonnet | データ流出ガード |
落とし穴 3: 機密データの扱い
社内 SaaS の API キーやお客様データをそのまま貼り付けたい衝動に駆られる場面があります。Cursor の Privacy Mode を組織標準で ON にし、貼り付けて良いデータの粒度をプレイブックで明文化しました。
FIXIT のプレイブックで明示している原則:
- 顧客個人情報 (PII): いかなる context にも貼らない
- API キー / Secret: vault に格納、Cursor には変数名のみで参照させる
- DB のサンプルデータ: 匿名化したスナップショットだけを参照
- 社内ナレッジ: Privacy Mode ON のみで使用可
「貼っていいデータ」を ホワイトリストで定義 するのが、漏洩事故の最大の予防策です。
落とし穴 4: ペアプロ文化への移行
「AI と並走する」開発に慣れていないと、AI に質問することすら躊躇するメンバーが出ます。導入直後の 2 週間は、毎日 30 分の「Cursor もくもく会」を開催し、ノウハウ共有とトラブル相談の場を作るのが効果的でした。
文化的な抵抗を解きほぐすには、
- 経験豊富なメンバーが「自分の使い方」を画面共有で見せる
- うまくいかなかった失敗事例を共有する (心理的安全性を作る)
- 小さい成功体験をチームで称える (Slack の reactji 文化)
の 3 つを 2 週間ほど続けると、自然と空気が変わります。
推奨: 共有設定のテンプレート
ユーザー設定ではなく リポジトリ同梱の .vscode/settings.json に置くと、新メンバーが clone した瞬間からチーム標準で動きます。
// .vscode/settings.json
{
// ─── モデル選択をチーム標準に揃える ──────────────────────
"cursor.chat.defaultModel": "claude-sonnet-4-6",
"cursor.composer.defaultModel": "claude-sonnet-4-6",
// ─── プライバシーモード (Pro 以上で利用可) ───────────────
// コード片が学習に使われない / モデル提供元への送信を抑制
"cursor.privacyMode": true,
"cursor.general.enableTelemetry": false,
// ─── プロジェクト固有のプレイブックを必ず読ませる ───────
// .cursor/rules を前提にし、ユーザールールより優先する
"cursor.rules.useProjectRules": true,
"cursor.rules.useUserRules": false,
// ─── エージェント機能はガードレールが整ってから ON に ───
"cursor.composer.agentMode": true,
}ライセンスとコスト管理
中規模チームでよく問題になるのが「無計画に Business プランを契約してしまい、利用率にバラつきが出る」パターン。
- 月次で利用ログをチェックする運用を組み込む
- 利用が極端に少ないメンバーは Free に戻し、ボトムアップで利用を促す
- 半年に一度プランを再評価する
FIXIT のクライアントワーク (25 名規模) では、Business 25 席のうち実利用 18 席という状態が 3 ヶ月続いたケースがありました。「使っていない人を Free に戻す」運用 を入れて、初期コストを 30% 削減できました。
効果を測る 3 つの KPI
Cursor 導入の効果を可視化する KPI です。
| KPI | 目標 | 計測方法 |
|---|---|---|
| アクティブ Cursor 利用率 | 80%+ | Business 管理画面の最終アクセス時刻 |
| PR 中央サイズ | 200 LOC 以下 | GitHub Insights |
| コードレビュー所要時間 | 4 時間以内 | GitHub Pull request analytics |
「PR が小さくなり、レビューが速くなる」のが AI ペアプログラミングの典型的効果です。逆にこれが起きない場合、ルール (.cursor/rules) が貧弱な可能性が高いので、Step 1 に戻って整備してください。
よくある質問
Q. Cursor と Claude Code はどう使い分ける？
A. IDE 統合の補完とエージェント駆動は Cursor、CLI 連携の自動化と大規模リファクタは Claude Code、と棲み分けるチームが多いです。詳しくは Claude Code 導入完全ガイド で説明しています。
Q. Cursor を導入する予算規模感は？
A. Business プラン (1 席あたり $40/月、年契約で $20/月) × 利用人数 + 導入支援工数。FIXIT が支援する場合、12 名規模で工数 60 万〜100 万円、25 名規模で 120 万〜180 万円が目安です。
Q. ルール整備をどこまで AI に任せられる？
A. 既存リポジトリの「コーディング規約 / アーキテクチャ図 / README」を Cursor に読ませて、.cursor/rules/00-baseline.mdc の初稿を作らせる までは AI に任せて問題ありません。その後の調整は人間 (Tech Lead) が PR レビューで行います。
関連リソース
- AI 駆動開発の全体像は AI 駆動開発とは を参照
- Cursor と相補的な Claude Code の組織導入は Claude Code 導入完全ガイド を参照
- AI ペアプログラミングのテスト先行ルールは AI 駆動 TDD の記事 で深掘りしています
- AI 駆動のクライアントワーク事例は 実績・事例 を参照ください
- 導入支援・ワークショップは お問い合わせ からどうぞ