はじめに
2026年6月3日、Cursor は Enterprise 顧客向けに Organizations 機能を一般提供（GA） しました。
これまで Cursor の Enterprise 管理は「チーム」単位が最上位でしたが、Organizations の導入により Organizations → Teams → Groups という3階層の管理構造が使えるようになりました。複数の部門・子会社・地域拠点にまたがって Cursor を展開している企業にとって、ガバナンス・予算管理・セキュリティ設定を一元化できる大きな変更です。
📌 影響を受ける人
- 複数の Cursor チームを持つ Enterprise 契約者
- Cursor の管理を IT 部門・セキュリティ部門が担っている組織
- 部門ごとに異なる AI ツール利用ポリシーを設定したい企業の管理者
変更の全体像
旧構造 vs 新構造
管理フローの変化
変更内容
3階層の管理構造
| 階層 | 名称 | 役割 | 主な設定項目 |
|---|---|---|---|
| 第1層 | Organization | 企業全体のアイデンティティ管理コンテナ | IdP 管理、全社支出のロールアップ、全チーム横断の使用量分析 |
| 第2層 | Teams | 部門・地域・子会社単位の運用単位 | セキュリティ設定、ガバナンスポリシー、予算・機能制御 |
| 第3層 | Groups | チームを横断する軽量なユーザー集合 | モデルアクセス権限、支出上限、エージェント権限の分離付与 |
新機能 5 点の詳細
① マルチチームサポート
ユーザーが複数のチームに同時所属できるようになりました。以前は1ユーザー = 1チームという制約があり、部門をまたいだプロジェクトへの対応が困難でした。複数チーム/グループに所属する場合は最も寛容な設定が優先されます。
② 組織レベルの IdP 管理
SAML / SCIM などの Identity Provider（IdP）設定を Organization レベルで一元管理できます。チームごとに個別設定していた IdP 連携を集約でき、SSO の管理コストを削減できます。
③ 組織レベルの使用状況分析
各チームへのドリルダウンを含む組織全体の使用状況ダッシュボードが追加されました。トークン使用量・支出を全チーム横断で把握できます。
④ ユーザーのチーム間移動
ダッシュボード UI・Admin API・CSV インポートの3つの方法でユーザーのチーム間移動が可能になりました。大規模な組織再編時の一括移行にも対応しています。
⑤ 設定・権限の自動継承
新規ユーザーがチームに参加した際、そのチームの設定・権限を自動的に継承します。オンボーディング時の手動設定ミスを防ぎます。
影響と対応
💡 Tips
既存の Enterprise 顧客は現行チームがそのまま保持されます。既存チームが新しい Organization の配下のデフォルト Teams として扱われ、ログイン・ルーティング・新チーム作成のデフォルトホームになります。強制的な移行作業は不要です。
移行判断フロー
管理者が取るべきアクション
| 優先度 | アクション | 対象 |
|---|---|---|
| 高 | Organization を作成し、既存チームを配下に整理 | 複数チームを持つ全 Enterprise 顧客 |
| 中 | IdP 設定を Organization レベルに移行 | SAML/SCIM を利用中の管理者 |
| 中 | Groups を活用したモデルアクセス権限の見直し | チームをまたいだプロジェクトを抱える組織 |
| 低 | Admin API を用いたユーザー管理の自動化 | 大規模組織・頻繁に人事異動がある企業 |
コード例
Admin API によるチーム間ユーザー移動（イメージ）
Organizations GA に伴い、Cursor Admin API にチーム管理エンドポイントが追加されています。
Before（旧: チーム単位の個別管理）
# 旧来: チームAのユーザーをチームBに移すには手動でのダッシュボード操作が必要
# API による一括移動は未サポートだった
After（新: Admin API によるユーザー移動）
# ユーザーをチーム間で移動する
curl -X POST https://api.cursor.com/admin/v1/organizations/{org_id}/users/{user_id}/teams \
-H "Authorization: Bearer {ADMIN_API_KEY}" \
-H "Content-Type: application/json" \
-d '{
"from_team_id": "team_engineering",
"to_team_id": "team_platform",
"role": "member"
}'
CSV による一括移動（大規模組織向け）
user_email,from_team_id,to_team_id,role
alice@example.com,team_engineering,team_platform,member
bob@example.com,team_design,team_platform,admin
carol@example.com,team_sales,team_enterprise,member
Groups による権限分離の設定例
{
"group_name": "AI-Heavy-Users",
"team_ids": ["team_engineering", "team_data"],
"permissions": {
"model_access": ["claude-opus-4", "gpt-4o", "gemini-2.5-pro"],
"monthly_spend_limit_usd": 500,
"agent_permissions": {
"file_write": true,
"terminal_access": true,
"web_search": true
}
}
}
💡 Tips
ユーザーが複数の Teams/Groups に所属している場合、最も寛容な設定が優先されます。厳格な制限をかけたいユーザーには、制限の強い Group のみに所属させる設計が必要です。
まとめ
| ポイント | 内容 |
|---|---|
| 何が変わった | Enterprise の管理構造が「チーム」単位から Organization → Teams → Groups の3階層へ |
| なぜ重要 | 複数部門・子会社を抱える企業が、チームごとのガバナンスを保ちつつ全社を一元管理できるようになった |
| 既存顧客への影響 | 既存チームはそのまま保持。強制移行なし |
| 管理者が注目すべき機能 | マルチチーム所属・組織レベル IdP 管理・使用状況分析・Admin API |
| 対応の緊急度 | 複数チームを持つ Enterprise 顧客は早期に Organization 構造へ移行することで管理コストを削減できる |
Cursor を全社展開している企業にとって、Organizations 機能は部門ごとのポリシー管理と全社コスト可視化を両立させる重要なマイルストーンです。Admin API を活用した自動化と組み合わせることで、大規模組織でも運用負荷を最小化できます。