Cursor for Teams：エンタープライズ機能と管理コントロール
個人でのCursor利用からチームでの展開に移行すると、請求、プライバシー、管理に関する疑問が生じる。このガイドでは、チーム管理者が知る必要があることをカバーする：管理者が何を見ることができるか、請求がどう機能するか、どのようなプライバシー保護があるか、そして複数の開発者環境でCursorをどう設定するか。
チームプランの概要
Cursorは2つのチーム向けティアを提供する：
| 機能 | Pro（個人） | Business（チーム） | Enterprise（カスタム） |
|---|---|---|---|
| 料金 | $20/月 | $40/人/月 | カスタム料金 |
| 最小座席数 | 1 | 2 | 25+ |
| 無制限Fastリクエスト | 不可（500/月） | 可 | 可 |
| 管理ダッシュボード | 不可 | 可 | 可 |
| SSO / SAML | 不可 | 可 | 可 |
| 監査ログ | 不可 | 可 | 可 |
| カスタム契約 | 不可 | 不可 | 可 |
| 優先サポート | 不可 | 可 | 可 |
| データレジデンシー | 不可 | 不可 | 利用可能 |
Businessプランは、ほとんどの組織にとって標準的なチームオファリングだ。Enterpriseは、カスタムのコンプライアンスや調達要件を持つ大企業向けだ。
管理者が見ることができるものとできないもの
これは、チームがCursorを導入するときに最も一般的な懸念事項だ。管理者に可視化されるものを明確にしよう。
管理者が見ることができるもの
| データ | 管理者に可視？ | 詳細 |
|---|---|---|
| 座席利用状況 | はい | 誰がライセンスを持ち、いつ参加したか |
| リクエスト数 | はい | ユーザーごと、チームごとの集計利用量 |
| 請求情報 | はい | 請求書、支払い方法、請求履歴 |
| ログイン活動 | はい | SSOログインイベント、セッションデータ |
| AIモデル利用 | 一部 | どのモデルが使われたか、内容は見えない |
| コード内容 | いいえ | 管理者はAIに送信されたプロンプトやコードを見ることができない |
| チャット履歴 | いいえ | 管理者はチャットメッセージを読むことができない |
| ファイル内容 | いいえ | 管理者はプロジェクトファイルにアクセスできない |
"管理者は私が何をしているか見えるのか？"という問いへの短い答えはいいえだ。Cursorの管理ダッシュボードは利用メトリクスと請求データを表示し、実際のコードやAIに送信したプロンプトは表示しない。
管理ダッシュボードに表示されるもの
Businessプランの管理ダッシュボードには以下が含まれる：
- ユーザー管理：座席の追加/削除、ユーザーの招待、アカウントの無効化
- 利用分析：総リクエスト数、ユーザー別内訳、モデル分布
- 請求概要：現在の支出、請求履歴、今後の料金
- セキュリティ設定：SSO設定、セッションポリシー
管理者ビューの例：
- チーム：Engineering
- 座席：12/15使用中
- 今月のリクエスト：34,200（無制限プラン）
- 人気モデル：Claude Sonnet 4（68%）、GPT-4o（22%）、o3-mini（10%）
- ユーザー活動：[編集済み——カウントのみ表示、内容は非表示]
チーム請求の説明
Cursorのチーム請求は座席ベースでシンプルだが、理解しておくべき詳細がある。
請求の仕組み
- 日割り座席：月中にユーザーを追加すると、現在のサイクルに対して日割りの金額を支払う
- 年間割引：Enterpriseプランでは年間請求の割引が提供される場合がある
- 請求頻度：デフォルトで月次；Enterpriseでは年次が利用可能
- 支払い方法：クレジットカードまたは請求書（Enterpriseのみ）
座席管理
チームメンバーの追加：
1. 管理者がCursorダッシュボードを開く
2. Team > Membersに移動する
3. "Invite Member"をクリックする
4. メールアドレスを入力する
5. ユーザーが招待リンクを受信する
6. ユーザーが承諾してチームに参加する
ユーザーの削除：
- 座席を無効化すると、再割り当てのために解放される
- 無効化された座席は次の請求サイクルから課金されない
- 無効化されたユーザーのデータは猶予期間（通常30日間）保持される
季節的な採用や請負業者がいる場合は、座席の追加と削除を請求サイクルに合わせて計画して無駄を最小化しよう。チームメンバーが退職したら、すぐに座席を無効化すること。
コスト比較：個人版 vs チーム版
| シナリオ | コスト |
|---|---|
| 5人の開発者が個人Proを使用 | 5 x $20 = $100/月（Fastリクエスト合計2,500回） |
| 5人の開発者がBusinessを使用 | 5 x $40 = $200/月（無制限リクエスト） |
| 20人の開発者がBusinessを使用 | 20 x $40 = $800/月 |
| 20人の開発者がEnterpriseを使用 | カスタム（大規模では通常$30-35/人/月） |
Businessプランは個人プランあたり約2倍のコストだが、アクティブなチームにとって無制限のリクエストがそのコストを正当化することが多い。
シングルサインオン（SSO）の設定
BusinessおよびEnterpriseプランは、SAML 2.0プロバイダー経由のSSOをサポートする。
サポートされるアイデンティティプロバイダー
- Okta
- Azure AD / Entra ID
- Google Workspace
- OneLogin
- 汎用SAML 2.0
設定手順
-
Cursor管理ダッシュボードで：
- Security > SSOに移動する
- アイデンティティプロバイダーを選択する
- ACS URLとEntity IDをコピーする
-
アイデンティティプロバイダーで：
- 新しいSAMLアプリケーションを作成する
- ACS URLとEntity IDを貼り付ける
- SAML証明書をダウンロードする
-
Cursorに戻って：
- SAML証明書をアップロードする
- ユーザー属性をマッピングする（メール、名、姓）
- SSOを有効にしてログインをテストする
<!-- SAML設定メタデータの例 -->
<md:EntityDescriptor entityID="cursor-team-yourcompany">
<md:SPSSODescriptor>
<md:AssertionConsumerService
Location="https://cursor.com/auth/saml/callback"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
</md:SPSSODescriptor>
</md:EntityDescriptor>
SSOの強制はオプションだ。移行中はSSOとパスワードログインの両方を許可し、全員が移行したらパスワードログインを無効にできる。
SSOのメリット
- 集中アクセスコントロール：既存のIDシステムを通じてオンボーディングとオフボーディング
- パスワードポリシー準拠：組織のパスワード要件を継承
- MFA強制：IdP経由で多要素認証を要求
- セッション管理：セッション期間と再認証要件をコントロール
チームモードでのプライバシー
AIツールがチーム環境に入ると、プライバシーへの懸念が高まる。以下がCursorがチームプライバシーをどう処理するかだ。
コードプライバシー
| 質問 | 回答 |
|---|---|
| チームメイトは私のチャットを見られるか？ | いいえ、チャットは自分のアカウントにプライベート |
| 管理者は私のプロンプトを読めるか？ | いいえ、プロンプトの内容は公開されない |
| 私のコードはモデル訓練に使われるか？ | いいえ、Cursorはユーザーコードで訓練しないと表明している |
| 私のコードはどこに行くのか？ | 推論のみのためにモデルプロバイダー（Anthropic、OpenAI）に送信される |
チームでのプライバシーモード
個人ユーザーはチームプランでもプライバシーモードを有効にできる：
Settings > General > Privacy Mode
これにより以下が無効化される：
- Cursorへのテレメトリと分析の送信
- コードスニペット付きのクラッシュレポート
- 利用メタデータのログ記録
プライバシーモードは、推論のためにLLMプロバイダーにコードが送信されるのを防ぐわけではない。Cursor自身のテレメトリにのみ影響する。厳格なデータ取り扱い要件を持つチームは、Cursorプライバシーとセキュリティガイドを確認すること。
チームデータ取り扱いポリシー
チームポリシーの確立を検討しよう：
## チームCursor利用ポリシー
1. 本番環境のシークレット、APIキー、PIIをAIチャットに貼り付けない
2. .cursorignoreを使って、機密ファイルがインデックスされないようにする
3. すべてのチームメンバーがプライバシーモードを有効にする
4. AIが生成したコードをコミット前にレビューする
5. 疑わしいデータ漏洩があれば、すぐに管理者に報告する
監査ログ
BusinessおよびEnterpriseプランには、コンプライアンスとセキュリティ監視のための監査ログが含まれる。
ログに記録されるもの
| イベント | ログに記録されるデータ |
|---|---|
| ユーザーログイン | タイムスタンプ、IPアドレス、SSOプロバイダー |
| 座席変更 | 誰が座席を追加/削除したか、いつ |
| 設定変更 | 管理者設定の変更 |
| 請求イベント | 請求書生成、支払い成功/失敗 |
| モデル利用 | モデルごとの集計カウント（内容は含まない） |
監査ログへのアクセス
- Cursor管理ダッシュボードを開く
- Security > Audit Logsに移動する
- 日付範囲、イベントタイプ、またはユーザーでフィルタリングする
- 外部分析のためにCSVまたはJSONにエクスポートする
監査ログを月次でエクスポートし、組織のセキュリティドキュメントシステムに保存しよう。これにより、コンプライアンス監査とインシデント調査が簡素化される。
チームポリシーの設定
技術的な設定を超えて、成功するチーム導入には明確なポリシーが必要だ。
オンボーディングチェックリスト
各新しいチームメンバーについて：
- 座席のプロビジョニング：管理者がダッシュボードでユーザーを追加する
- SSO設定：ユーザーが組織のアイデンティティプロバイダー経由でログインする
- プライバシー設定：ユーザーがプライバシーモードを有効にする
- プロジェクトアクセス：関連リポジトリへのアクセスを付与する
- トレーニング：
.cursorignoreの設定と安全な利用方法を説明する - モデルデフォルト：設定でチームが好むデフォルトモデルを設定する
モデル利用の標準化
チームは一貫したモデル選択から恩恵を受ける：
// 推奨チームデフォルト（ドキュメント経由で共有）
{
"cursor.defaultModel": "claude-sonnet-4",
"cursor.tabModel": "claude-sonnet-4",
"cursor.fallbackModel": "gpt-4o"
}
どのタスクにどのモデルを使うかを文書化して、ジュニア開発者が些細な質問でプレミアムリクエストを浪費しないようにしよう。
共有.cursorrules
チーム全体で一貫したAI動作のために、リポジトリに共有の.cursorrulesファイルを維持しよう：
# チームプロジェクトの.cursorrules
## コードスタイル
- コードベースの既存のパターンに従う
- TypeScript strictモードを使用する
- Reactでは関数コンポーネントを優先する
## テスト
- すべての新しい関数にテストを書く
- JestとReact Testing Libraryを使用する
- 80%以上のカバレッジを目指す
## ドキュメント
- 公開APIにはJSDocコメントを追加する
- アーキテクチャ変更時にはREADME.mdを更新する
チームのセキュリティベストプラクティス
.cursorignoreによるファイル除外
すべてのチームプロジェクトには.cursorignoreファイルが必要だ：
# .cursorignore
.env
.env.local
.env.production
secrets/
config/production.yml
*.key
*.pem
tokens/
credentials.json
これにより、機密ファイルがインデックスされ、AIコンテキストに誤って含まれるのを防ぐ。
APIキー管理
チームメンバーが自分のAPIキーを持ち込む場合：
- 推奨しない：代わりにチームプランで一元化する
- 必要な場合：キーは環境変数に保存し、コードには絶対に入れない
- 定期的なローテーション：APIキーローテーションのポリシーを設定する
コンプライア ンス上の考慮事項
| 規制 | Cursorチームの考慮事項 |
|---|---|
| SOC 2 | 監査ログは利用可能だが、監査人と確認すること |
| GDPR | ユーザーデータはリクエストに応じてエクスポート/削除可能 |
| HIPAA | CursorはHIPAA認証を受けていない；プロンプトにPHIを入力しないこと |
| ISO 27001 | Cursorのセキュリティドキュメントを確認すること |
Cursorはセルフホスト型またはair-gapped型のデプロイメントを提供していない。コンプライアンス要件がデータがインフラストラクチャを離れてはならないことを義務付けている場合、CursorのクラウドベースのAI機能は適切でない可能性がある。
チーム問題のトラブルシューティング
ユーザーがチームに参加できない
- 招待メールが正しいアドレスに送信されたか確認する
- SSOが強制されている場合、SSOが正しく設定されているか確認する
- チームに利用可能な座席があることを確認する
利用量の急増
リクエストの利用量が予期せず高い場合：
- 管理ダッシュボードでユーザー別内訳を確認する
- 1人のユーザーが不釣り合いにリソースを消費していないか特定する
- バックグラウンドエージェントやComposerが過度に使われていないか確認する
- チームにリクエスト効率的なワークフローのガイドラインを設定する
請求の不一致
- 月中に座席を追加した場合の日割り料金は正常だ
- 無効化された座席は次のサイクルから課金 が停止し、即時ではない
- 請求書に関する質問はCursorサポートに連絡する
まとめ
Cursorのチーム機能は実用的だが、専用のエンタープライズAIプラットフォームほど成熟しているわけではない。Businessプランは本質的なものをカバーする：無制限のリクエスト、SSO、監査ログ、管理コントロール。管理者はコードやチャット内容を見ることができないが、利用メトリクスを見たり座席を管理したりできる。
チーム管理者の重要なポイント：
- 集中アクセスコントロールのために早めにSSOを設定する
- オンボーディング前に
.cursorignoreとプライバシーポリシーを確立する - コンプライアンスとセキュリティ監視のために監査ログを使う
- コスト管理のためにモデル利用ガイドラインを文書化する
- Cursorはクラウドベースであることを理解し、機密性の高いプロジェクトに応じて計画する
ほとんどの開発チームにとって、Businessプランは能力とコストの間で適切なバランスを取っている。カスタム契約、データレジデンシー、専用サポートが必要な場合のみ、Enterpriseを検討する価値がある。