02Enterprise
Grok Bot の法人・Enterprise 導入
結論
法人で Grok Bot を使う入口は、セルフサーブの Cursor Teams か、アカウント担当を通じて有効にする Cursor Enterprise です。Teams でも全メンバーが使えますが、Network Controls・監査ログ・Action Recording・SCIM・MCP allowlist などは Enterprise 限定のため、業務データを扱う全社展開なら Enterprise を前提に設計することをお勧めします。
確認日：2026年9月16日本ページの情報は確認日時点の公式情報にもとづくもので、変更される可能性があります。最新の内容は各出典の公式ページをご確認ください。
本サイトは株式会社プレミアムヒューマンが運営する独立した導入支援サービスで、xAI の公式サイトではありません。
企業向け提供開始の公式発表（2026年9月3日）
- 企業向けに提供開始：xAI は2026年9月3日に「Grok Bot for Enterprise」を発表し、企業が Bot を大規模に統制するための、アクセス・ネットワーク・監査の管理機能を追加しました。
- 発表時の無料期間：Grok と Cursor の Enterprise 顧客は「今後2週間」無料で利用でき、シートのない人も含めて組織全体を招待できると案内されました。発表日から数えた期間のため、現在の条件は公式に確認してください。
- 公開されている利用企業の例：Legora、Supermicro、ServiceTitan。発表では、利用が最も多いのは開発以外の部門だとしています（xAI の発表であり、当社の支援実績ではありません）。
- それ以前の経緯：2026年8月11日の提供開始時点では、Enterprise の利用者はウェイトリストでの受付でした。
会社で使う方法は、Teams と Enterprise の2つ
| 契約 | Grok Bot の使い方 | 料金 |
|---|---|---|
| Cursor Teams（セルフサーブ） | Grok Bot が含まれ、全メンバーが使える。利用量はそのシートの利用枠に従う | Standard 1ユーザー月額40米ドル／Premium 120米ドル |
| Cursor Enterprise | Cursor のアカウント担当に連絡して、組織で Grok Bot を有効にする | 個別契約 |
公式は「この表は利用できるかどうかであって、管理機能の一覧ではない」と注記しています。Teams でも Grok Bot は使えますが、次の表のとおり、いくつかの設定は Enterprise 限定で、セルフサーブの Teams には表示されません。Cursor の料金ページでも、請求書払い・利用量の共有（プール）・高度なセキュリティが必要な大きな組織には Enterprise を勧めています。
なお、xAI の9月3日の発表は「Grok と Cursor の Enterprise 顧客」を対象としていますが、Cursor のヘルプでは SuperGrok Team / Enterprise の紐づけは非対応とされています。xAI 側の法人契約（Grok Business / Enterprise）で Grok Bot を使う手順は確認できなかったため、該当する場合は xAI の営業窓口に確認してください。
Teams と Enterprise の管理機能の違い
| 管理機能 | 内容 | Teams | Enterprise |
|---|---|---|---|
| Grok Bot の有効化スイッチ | 組織全体で有効／無効を切り替える。無効にしてもメンバーのコンピューターは削除されない | なし | あり |
| Network Controls | チームのコンピューターが接続できる宛先を制御。4つのモード、ディレクトリグループ単位の設定、ロック。ポリシーのないチームは「すべて許可」が既定 | なし | あり |
| Team Setup | 全員のコンピューターで実行される、管理者のインストールスクリプト | なし | あり |
| Action Recording | Bot の操作を記録（既定はオフ、90日保持）。監査ログの画面には表示されない | なし | あり |
| コンピューター管理 | 組織管理者がメンバーのコンピューターを検索し、作成日と最終利用を確認し、停止できる | なし | あり |
| 監査ログ | 管理・セキュリティ・認証のイベント。ダッシュボードで見るか、SIEM に送る | なし | あり |
| OpenTelemetry Export | Action Recording のイベントを自社の収集基盤に送る | なし | あり |
| SCIM | SCIM 2.0 によるアカウントの払い出しと削除 | なし | あり |
| MCP allowlist | コネクタポリシーのうち、許可する MCP サーバーの一覧 | なし | あり |
| チームのモデル許可リスト | Enterprise 限定。ただし順守は保証されない（導入時に同意を求められる） | なし | あり |
| コネクタポリシー | チームの Cursor のコネクタ（MCP）ポリシーをそのまま継承する | あり | あり |
| Cloud Agents | Cursor Cloud Agents への委任を許可／禁止（既定はオン） | あり | あり |
| 公開テンプレート共有 | Bot のテンプレートをチーム外に公開できるかを制御。Enterprise は既定でオフ、それ以外のチームは既定で許可 | あり | あり |
| Team Rules | 全メンバーの Bot に常に適用されるルール | あり | あり |
| Auto Review のチーム指示 | チーム全体の許可／禁止の指示。レビューモデルの判断に使われる | あり | あり |
公式は、「Enterprise 限定」はセルフサーブの Teams では非表示で、あとから有効にできる既定値ではないと説明しています。また、Auto Review の強制（enforcement）はプランによる差ではなく、Cursor が全ユーザーで有効にしています。オフにできるのは各メンバー自身の設定で、組織単位でロックする機能は現時点でありません。
契約・展開の前に確認しておくこと
公式ドキュメントが「展開の前に」として挙げている項目と、セキュリティ審査でよく聞かれる前提です。
- Privacy Mode（Legacy）を解除する：この設定が有効だと Grok Bot は使えません。有効化の前に変更を求められます。
- 送信元 IP による制限：クラウドコンピューターは Grok Bot の利用者間で共有される固定の出口 IP を使い、顧客専用の IP はありません。
- 社内ツールへのサインイン方法：Grok Bot へのサインインは既存の Cursor の SSO 設定に従います（SAML 2.0。Okta、Microsoft Entra、Google Workspace、OneLogin に対応）。
- ホスティングとデータの所在：Cursor がホストするクラウドコンピューターのみで、オンプレミスや自社イメージでの運用は非対応です。コンピューターは現在米国で稼働しています。
- データの保持と削除：コンピューターのファイルとブラウザのセッションは永続ディスクに残ります。サービス終了後は、DPA に基づき書面の指示から30日以内に削除または返却されます。組織単位の保持ポリシーはありません。
- 認証：Cursor の運営会社 Anysphere が ISO/IEC 27001 と ISO/IEC 42001 を取得しており、Grok Bot は現在の ISO の範囲に含まれています。
Teams で試すか、Enterprise を前提にするか
当社の考え方公式の管理機能の差を、導入の現場での判断に置き換えると、次のように整理できます。
Teams で小さく試してよい
- 公開情報の調査や、社内向けの下書き作成など、社外への送信を伴わない業務
- 顧客データや個人情報を Bot のコンピューターに置かない
- 少人数で、使い方と使用量を確かめる段階
Enterprise を前提に設計したい
- Bot が接続できる宛先を制限したい（Network Controls）
- 誰が何をしたかの記録が、社内規程や監査で必要（監査ログ・Action Recording）
- 入退社に合わせてアカウントを自動で管理したい（SCIM）
- 退職や事故のときに、管理者がコンピューターを止められるようにしたい（コンピューター管理）
見落としやすい点：プラグイン（コネクタ）を禁止しても、そのサービスの Web サイトはブラウザから使えます。コネクタポリシーとネットワークポリシーは別の層で、両方の経路を閉じるには Enterprise 限定の Network Controls が必要です（公式）。
全社展開までの進め方
当社の考え方公式の推奨設定を土台に、当社は次の順で進めます。
- 対象業務と成功基準を決める1部署・1業務に絞り、作業時間・修正率・完了率・人の確認時間など、本導入を判断する指標を先に決めます。
- 管理設定の初期値を決めるNetwork Controls のモードと許可リスト、コネクタポリシー、公開テンプレート共有、Cloud Agents の委任、ローカル PC での実行の方針を決めます。公式は、公開テンプレート共有と Cloud Agents はどちらも許可寄りの既定値で出荷されるとしています。
- 承認境界とルールを書くTeam Rules は短く少なく、実際の強制は Auto Review のチーム指示で行うのが公式の推奨です。本番デプロイ・社外メール・支払い・法的条件への同意は、代表的な禁止指示の例として挙げられています。
- PoC で検証する読み取り専用の作業と下書きから始め、送信・公開・購入・削除・本番変更は承認の後ろに置いたまま、品質と使用量を測ります。
- 止める条件と拡大の判断どの指標が基準に届かなければ止めるか、どうなれば対象部署を広げるかを、結果報告の場で判断します。
当社の導入支援でできること
情報システム部門と一緒に、展開の設計を
- 契約形態の判断Enterprise 限定の機能が必要かどうかを、対象業務と社内規程から判断します。
- 管理設定の初期値の設計Network Controls、コネクタポリシー、公開テンプレート共有、Team Rules、Auto Review のチーム指示の案をつくります。
- セキュリティ審査への準備データの所在、保持と削除、ID 連携、ログなど、審査で問われる項目を公式情報に沿って整理します。
- PoC から全社展開までの計画1部署・1業務の45日PoC から、段階的に対象を広げる計画と社員研修をご提案します。
Teams で始めるか、Enterprise を前提にするか。
対象業務と社内規程から整理します。