Grok Botを全社導入する前に、Teamsでは使えない管理機能を確認

SpaceXAIは2026年9月3日、常時稼働型エージェント「Grok Bot」の企業向け提供を発表した。SpaceXAIの発表 では、GrokとCursorのEnterprise顧客が既存シートを持たない従業員を含め、組織全体を招待できるとしている。

同日に公開された管理者向け資料を確認すると、TeamsでもGrok Bot自体は利用できるが、全社有効化、Network Controls、Action Recording、監査ログ、MCP許可リストはEnterprise限定だ。9月4日付の AI Stack Currentの検証記事 も、9月3日の企業向け提供と、この統制範囲の差を報じている。

Teamsの製品アクセスとEnterpriseの管理権限は別

契約判断で最初に分けるべきなのは、Grok Botを利用できるかどうかと、組織として一括管理できるかどうかだ。Teamsでは各メンバーに製品アクセスが含まれる一方、組織全体を有効化または停止する管理スイッチは提供されない。

SpaceXAIの管理者向け機能表 は、プラン別の範囲を次のように区別している。

• Enterprise限定：組織全体の有効化スイッチ、Network Controls、Team Setup、Action Recording、コンピューター管理、監査ログ、OpenTelemetry Export、SCIM。
• TeamsとEnterpriseの両方：Cloud Agentsへの委任制御、公開テンプレート共有の制御、Team Rules、コネクター方針、Auto Reviewのチーム指示。
• Enterpriseで追加される制御：コネクターを許可または遮断する方針は両プランにあるが、MCPサーバーの許可リストはEnterpriseに限られる。

この違いにより、Teamsで部門単位の試用が成立しても、その構成を全社展開へそのまま移せるとは限らない。通信先の限定、操作証跡の収集、入退社に伴う自動プロビジョニングが必須なら、製品へのアクセスではなくEnterprise限定機能の有無が契約条件になる。

Network Controlsがなければ通信先を限定できない

Network Controlsは、Grok Botのクラウドコンピューターが到達できる宛先を管理する機能で、Enterpriseだけに提供される。Enterpriseでは複数の動作モード、ディレクトリグループ単位の適用、設定のロックを利用できるが、セルフサービス型Teamsには宛先許可リストの管理画面がない。

Teamsにネットワーク方針が設定されていない場合、通信先は初期状態でallow-allとなる。コネクター方針で特定のMCPサーバーや連携先を遮断しても、ブラウザーによる同じサービスへのアクセスまで止める制御ではないため、コネクターとネットワーク経路は分けて評価する必要がある。

社内APIやステージング環境への到達を認める場合も、Network Controlsだけで最小権限が完成するわけではない。接続先サービスのアカウント権限、認証情報、変更承認を含め、Botが実行できる操作の上限を確定する必要がある。

Action Recordingと監査ログは記録対象が異なる

Enterprise限定のAction Recordingと監査ログは、別の記録層だ。監査ログが管理、セキュリティ、認証に関するイベントをダッシュボードやSIEMで扱うのに対し、Action RecordingはBotが行った操作を記録する。

Action RecordingはEnterpriseを契約しても初期状態では無効で、記録されたイベントは通常の監査ログ画面には表示されない。操作記録を自社の収集基盤へ送るには、同じくEnterprise限定のOpenTelemetry Exportを設定する必要がある。

したがって、監査ログが利用できるという理由だけで、Botの操作まで追跡できるとは判断できない。インシデント調査や内部統制で操作単位の証跡が必要なら、Action Recordingの有効化、外部転送、転送先での保存期間と検索方法を一つの要件として確認することになる。

分離環境と承認ゲートにも境界がある

Grok Botでは、ユーザーごとの作業が専用のFirecracker microVMで実行され、他のユーザーからハードウェアレベルで分離される。Botは初期状態でアカウントやプラグインへのアクセスを持たず、ユーザーまたはチームが明示的に認めた範囲で動作する。

ただし、計算環境の境界はBot単位ではなくユーザー単位だ。同じユーザーが動かす複数のBotは一つの永続的なクラウドコンピューターを共有するため、その中のファイル、ブラウザーセッション、アプリのログイン状態をBotごとに分離された資格情報領域とは見なせない。独立した環境と認証情報が必要な業務には、別のCursorユーザーを割り当てる設計が求められる。

機密性の高い操作では、独立した審査モデル「Auto Review」が許可、拒否、人間による承認要求を判断する。Team RulesとAuto Reviewのチーム指示はTeamsでも使えるが、通信先制御や接続先システムの権限を代替するものではない。承認ゲート、通信可能範囲、保有する認証情報、接続先での最終権限は、それぞれ別の制御層である。

全社導入前に照合すべき統制要件

全社導入では、Botが業務を完了できるかだけでなく、必要な統制を選択したプランが提供するかを先に確認する必要がある。管理者とセキュリティ担当者の契約前チェックは、次の項目に絞れる。

1. メンバーごとの利用で足りるのか、組織全体を一括で有効化・停止する必要があるのか。
2. 通信先を許可リストで限定し、部署やディレクトリグループごとに適用する必要があるのか。
3. 一般的なコネクター方針に加え、MCPサーバーの許可リストが必要か。
4. 管理・認証イベントの監査ログと、Botの操作記録のどちらを保存する必要があるか。
5. Action Recordingを有効にし、OpenTelemetry Exportの転送先と保存方法を用意できるか。
6. 同じユーザーの複数Botがコンピューター、ファイル、ログイン状態を共有する設計を許容できるか。
7. 入退社時のプロビジョニングとデプロビジョニングにSCIMが必要か。

公開資料から確認できるのは、Grok Botの企業向け提供開始、Teamsでの製品アクセス、Enterprise限定の管理機能までだ。日本向けの価格、契約条件、データ所在地に関する個別の確約は示されておらず、Enterpriseの有効化にはCursorの担当窓口への連絡が必要とされている。地域条件を含む契約内容と、自社が必要とする統制機能の照合が残る。