Grokをチームで使う管理者のために：Business／Enterpriseの管理者設定、データ保護、SSOとSCIM、請求、APIのチーム管理を、公式ドキュメントで確かめる

この記事は、公式ドキュメントを2026年10月24日に読んでまとめたものです。この記事は、実際に使って確かめた記録ではありません。運営者はGrokを入れていますが、使い心地はこの記事には書いていません。メニュー名、設定のキー、コマンドは、公式のページに書かれていたとおりに写したか、その説明から短く組み立てたもので、動作確認はしていません。公式の文章は要約として取得したため、引用はせず言い換え、読み切れていない箇所は「確認できていない」と書きます。契約、法律、セキュリティの助言ではありません。契約の条文は原文で、必要なら専門家に確かめてください。

先に結論

• まず「どの入口の契約か」を確かめる。 console.x.ai の「Grok Business」画面（権限はTeam Read-Write、Billing Read-Write）と、grok.com/dashboard の「Members」（役割はMember、Admin）は、別の画面です。
• SSOとSCIMはEnterprise向け。 /organization のページで設定し、SSOは有効にすると組織全体で強制、SCIMは公式が「very disruptive」と警告しています。
• データ保護は3段で読む。 規約と発表（学習に使わない）、チーム全体のZDR（入れると使えない機能が多い）、Enterprise向けのVault（詳細は読んだ範囲では薄い）。
• 共有は Product Sharing で上限を決める。 Private、Team、Organization、Publicの4段階で、引き締めは即時に効きます。
• APIのチーム管理は、管理キーとキーごとのACL。 ただし各エンドポイントに必要な権限の表は、見つかりませんでした。

前提：用語をそろえる

• ライセンス（license）。 Grok Businessの画面で、人に割り当てる「使う権利」です。種類は、SuperGrok と SuperGrok Heavy の2つと、公式は書いています。購入した分は「available pool（使えるプール）」に入り、人に割り当てると、その人のチームワークスペースが使えます。
• 席（seat）。 The X Subscriptionのチームプランで使う言葉です。Free、Premium、Super、Ultraの席があり、各席は、同じ名前の個人プランと同じ使用量だと書かれています。
• ワークスペース。 grok.com で切り替える作業場所です。個人用（Personal Workspace）と、チーム用（Team Workspace）があります。チーム用はライセンスがないと開けません。別に、The X Subscriptionでは「1つのワークスペースが1つの購読と1つの請求」という意味でも使われます。
• チーム（team）。 consoleの中の単位です。APIキー、請求、ライセンスは、チームに結びつきます。Organization（組織） は、複数のチームを束ねる上位の単位で、Enterpriseだけです。
• Team Read-Write／Billing Read-Write。 consoleの権限の名前です。前者は招待とライセンスの割り当て、後者はライセンスの購入と解約に必要です。
• 管理キー（Management Key）。 Management APIを呼ぶための、APIキーとは別のキーです。
• ACL。 キーや役割に付ける「できること」の文字列です。たとえば api-key:model:* です。
• ZDR（Zero Data Retention）。 プロンプトと出力をディスクに残さない、チーム全体の設定です。
• SSO、SCIM。 SSOは会社のIdPでログインさせる仕組み、SCIMはIdPのユーザーとグループを自動で同期する仕組みです。

全体の地図：入口は3つ（とEnterpriseの上位）

公式の目次（docs.x.ai の llms.txt）を読むと、法人向けの情報は、次のように分かれていました。

注意点を2つ書きます。

1つめ。Grok Businessの画面は、「Grok Business」「ライセンス」「SuperGrok／SuperGrok Heavy」という名前で書かれ、The X Subscriptionの画面は「Premium／Super／Ultraの席」「Member／Admin」という名前で書かれています。同じ「チームでGrokを使う」ことを、2つの体系で説明しています。The X Subscriptionのチームプランのページには、Grok Businessを払っていたチームは、切り替え（Unify）のときに解約され、使っていない日数が返金される、と書かれています。つまり、いまは過渡期です。

2つめ。Grok Botのチーム向けページは、管理の画面が「Cursorのダッシュボード」で、SCIM 2.0はEnterpriseだけ、1人のBotが1台のコンピューターを共有する、といった別の注意があります。この記事では扱いません。

プランの選び方：BusinessとEnterprise

公式の価格ページ（x.ai/grok/business）と、2025年12月30日の発表（x.ai/news/grok-business）を、確認日2026年10月24日に読んだ内容です。

この表は、公式の比較表の整理です。次の点は、読んだ範囲で食い違いや空白があります。

• 「Advanced audit and security controls」の置き場所。 価格ページは両方のプランの機能一覧に載せています。一方、2025年12月30日の発表は、Enterprise側の追加項目として書いています。どちらが正しいかは、確認できていません。
• 「Custom data retention」の置き場所。 価格ページは、両方のプランの機能一覧に「Custom data retention」を載せています。一方、ユーザーガイドは、カスタムの保持ポリシーはEnterprise向けと書いています。どちらが正しいかは、確認できていません。
• ドメインの認証。 価格ページは両プランの機能に載せていますが、Organizationのページ（docs.x.ai/grok/organization）は、ドメインの関連付けをEnterpriseの機能として書いています。そのページには、認証（DNSなど）の手順は書かれていませんでした。
• VaultがEnterprise専用か。 発表はEnterpriseの追加項目と書き、価格ページは「Enterprise専用」とは書いていません。

僕らの見立てです。 小さなチームで、SSOもSCIMも要らず、まず試したい場合は、Businessで足りるかどうかを、価格ページの比較表で見るのが近道です。IdPのグループで席を自動で配りたい、個人用ワークスペースを止めたい、といった要望が1つでもあるなら、Enterpriseの話になる、と読めます。ただし価格や条件は、営業との相談になります。

最初の10分でやること（Business）

公式のユーザーガイドと「License & User Management」のページに書かれている手順です。ここは、公式の記載を順に並べたもので、動作確認はしていません。

1. console.x.ai にログインし、チームを選び、「Grok Business」の概要ページを開く。
2. 請求の設定を先に確かめる。 公式は、中断を避けるために、チームの請求（Billing Settings）が正しく設定されているか確かめるよう書いています。
3. 概要ページで、ライセンスの種類（SuperGrok か SuperGrok Heavy）と数を選び、必要なら支払いの情報を入れ、購入を確定する。買った分は、すぐ割り当てられるプールに入ります。
4. 「Invite users to Grok Business」を押し、メールアドレスを入れ、招待に付けるライセンスの種類を選んで送る。空きのライセンスがあれば、承諾した時点で自動で割り当てられます。
5. 招待の状況は、概要ページの「Pending invitations」で見られます。
6. すでにチームにいる人に渡すときは、概要ページでその人を選び、使えるライセンスを選んで割り当てる。すぐ有効になります。
7. 受け取った人は、grok.com で、画面左下のワークスペースの切り替えから、チーム用ワークスペースを選びます。

招待したのに割り当てが失敗する場合、公式の説明は、ライセンスが足りないことです。追加で買うか、使っていない人の分を取り消します。

ライセンスと席の管理：できることと注意

Grok Business（console.x.ai）

公式は、これらの権限は通常チームの管理者だけが持つ、役割の設定は概要ページで調整できる、と書いています。権限がない人は、チームの管理者に頼む形です。

The X Subscriptionのチームプラン（grok.com/dashboard）

公式の「Team plans, seats, and invites」のページに書かれている内容です。

• 役割は、招待のときに Member か Admin を選びます。席は Free、Premium、Super、Ultra で、チームの席として買えるのは、Premium、Super、Ultraです。Plusはチームでは使えません。
• 招待は、grok.com/dashboard の「Members」で「Invite」を押し、メールアドレス（コンマか改行で区切る）、Role、Seatを選んで「Send invites」。リンクをコピーして渡すこともできますが、Freeの席には使えません。
• 招待が承諾されると、空いている席があればそれを使い、なければ新しい席が買われて、請求期間の残りの日数ぶんが日割りで課金されます。
• メンバーの削除。 「Members」で「⋯」から「Remove from team」、「Remove access」。アクセスは即時に止まりますが、席はプランに残り、次の人が使えます。支払いを止めるには、「Billing & invoices」でプランのメニューから「Edit seats」、「Reduce seats」。減らした席は、請求期間の終わりに消えます。自分自身は削除できません。
• 席の変更。 アップグレードは即時で、差額を日割りで請求し、更新日は変わりません。ダウングレードは請求期間の終わりに効きます。保留中のダウングレードは、現在の席を選び直して「Keep」で取り消せます。Freeへの変更は即時ですが、有料の席はプランに残るので、「Reduce seats」が別に必要です。
• Xの特典。 メンバーがXの特典を受けるには、管理者がPremium以上の席を割り当て、かつ本人が自分のXアカウントをつなぐ必要がある、と書かれています。

落とし穴。 削除しても席は残る、つまり請求は続きます。「人を外した」ことと「支払いを止めた」ことは別の操作です。

統合（Unify）の警告

同じページに、チームの統合は「永久」で、サポートでも元に戻せない、と書かれています。統合を始められるのは、Cursorのチームのオーナーか管理者で、Grokのチームを持ち込む場合は、そのチームのオーナーか請求の管理者でもある必要があります。一般のメンバーは始められません。個人プランは、チームに入っても自動では解約されません。自分で解約する必要がある、とも書かれています。

共有ポリシー：Sharing & Retention

「License & User Management」のページに、console.x.ai の Sharing & Retention → Product Sharing で設定する、と書かれています。会話、プロジェクト、スキルのそれぞれに、別のポリシーを置きます。

• 公開リンクは会話だけです。プロジェクトとスキルは、Organizationまでです。
• 食い違いがあります。ユーザーガイドは「共有リンクはライセンスのあるチームメンバーだけが開ける」と書いており（前のガイド02にもそう書きました）、Publicレベルの説明（社外の人にも開ける公開リンク）と合いません。どちらが実際の動きかは確認できていません。
• 既定は、会話とプロジェクトが組織全体に共有できる状態、スキルはPrivateから、と書かれています。
• ポリシーを狭めると、すぐ効きます。メンバーはより広い共有を作れなくなり、すでにある共有も、新しい上限を超える範囲では、アクセスが制限されます。

使い方の見立て（僕らの見立てです）。 既定のままだと、会話とプロジェクトは組織全体まで共有できます。社外秘を扱うチームは、導入の初日に、まず会話をTeamに引き締めてから、必要なところだけ広げるほうが、あとから「広げすぎた共有」を回収するより楽だと読めます。引き締めが即時で効く、という公式の記載は、この順番を後押しします。

個人用ワークスペースと、保持の設定

• ユーザーガイドによると、組織がEnterpriseのライセンスで個人用ワークスペースを無効にしている場合、一部のユーザーには個人用ワークスペースが表示されません。有効にするか無効にするかを選べるのは、Enterpriseのプランです。
• チーム用ワークスペースのプライバシー保護は、SpaceXSIの企業向け規約に従う、と書かれています。
• Enterpriseの階層には、事業向けに合わせた保持ポリシー（custom retention policies）が含まれる、とあります。ただし、保持期間や設定画面の説明は、そのページにはありません。カスタムの保持の具体的な設定方法は、読んだ範囲では見つかりませんでした。

コネクタの管理

公式の「Connector Management」のページから、Business／Enterpriseの管理者の手順です。

1. console.x.ai にログインし、チームを選び、Grok Business → Connectors を開く。
2. + Add Connector を押し、サービスを選び、必要な設定を終える。Microsoftのサービスのように、管理者の同意（admin consent）が必要なものがあります。
3. 追加すると、チームの利用可能なコネクタに並びます。メンバーは、各自のアカウントで grok.com/connectors から接続します。
4. 自分のMCPサーバーを足す場合は、「+ Add Connector」で「Other」を選び、MCPサーバーのURLを入れて、必要な認証を済ませる。ローカルのマシンにあるサーバーは、公式の「Custom MCP Tunneling」のガイドを見るよう書かれています（そのガイドは読んでいません）。

管理の操作は、「Configure」（アクセス制御、許可するサイト、サービス固有の設定）と「Remove」の2つです。Removeは、コネクタをチームから外し、メンバーは接続も使用もできなくなり、関連づけられたインデックスのデータが消えることがある、と書かれています。追加と削除には Team Read-Write が必要です。SharePoint、OneDrive、Salesforceには、専用の手順のガイドがありますが、読んでいません。

読んだ範囲では見つからなかったこと。 有効と無効を切り替えるスイッチ、OAuthの詳しい仕組み、コネクタ経由のデータの保持の説明は、このページにはありませんでした。前のガイド（04）に書いたとおり、コネクタのデータの扱いは、別のページでも確認できていません。

Organization：ドメイン、SSO、SCIM（Enterprise）

公式の「Organization Management」のページです。console.x.ai/organization は、組織の管理者だけが開けます。組織のメンバーが作ったチームは、自動で組織にひもづき、ダッシュボードに出ます。

ドメインの関連付け

組織にメールのドメインを結びつけると、そのドメインのアドレスで登録またはログインした人は、自動で組織に関連づけられます。ダッシュボードの「Users」には、ドメインに関連づいたユーザーと、所属チーム、アクセスの状態が並びます。「Teams」には、関連づいたチームと、メンバー、大まかな使用量が出ます。公式は、これらの画面を、コンプライアンスの確認、使われていないアカウントの発見、増加の把握に使える、と書いています。

前のガイド（01）に書いたとおり、規約には、会社のメールで登録したアカウントが、組織のEnterpriseの購読にひもづき、管理者が監視や管理をすることがある、という趣旨の記載があります。従業員は、会社のメールで個人のGrokを使うと、会社の管理の対象になりうる、と読めます。

SSOの設定

1. /organization のページで「Configure SSO」を押す。
2. 対応するIdPの一覧から選ぶ。
3. IdPごとの手順に従い、設定、メタデータの交換、属性の対応づけをする。
4. 保存して、SSOをテストする。

有効にすると、SSOは 組織全体で強制 され、ユーザーは次のアクセスからSSOでのログインが必要になります。ログインの入り口の細かい動き（ドメインのアドレスを入れたときの移り方など）は、読んだ範囲では確認できていません。公式は、混乱を減らすために、事前にユーザーに知らせるよう書いています。

SCIMの設定（5つの段階）

有効化のあとは、「Provisioning」タブで、役割の追加（Create Role）、優先順位の変更（Reorder Priority）、各役割のメニューからチーム、権限、ライセンスの更新ができます。

公式の警告。 SCIMは「very disruptive」で、ユーザーがリソースへのアクセスを得たり失ったりしうる。組織に知らせ、プレビューの段階で全部確かめてから有効化する、と書かれています。

僕らの見立てです。 SCIMは、「グループ → 役割 → チーム、ACL、ライセンス」という一本の線で、席を人の手でなくIdPのグループで決める形です。始める前に、グループの一覧と、どのグループにどのライセンスを付けるかを紙に書いておくと、段階2〜4で迷いません。高い順位に「全員が入るグループ」を置かないよう、気をつけたいところです。

読んだ範囲では見つからなかったこと。 ドメインの所有の確認（DNSなど）の手順、SSOの対応プロトコル（SAMLかOIDCか）の説明、SSOのテスト用のログインのやり方、SSOを有効にしたあとの緊急用の入口（ブレークグラス）の有無は、ページにありませんでした。Organizationのページは、監査（auditing）に、集中管理の利点として触れるだけでした。

サインインのドメインが変わる（2026年10月30日）

The X Subscriptionの「Sign-in domains」のページに、次のとおり書かれています。この記事の確認日（10月24日）から見て、あと6日です。

• 社内のファイアウォールやプロキシの許可リストに、10月30日の前に足します。ブックマークや社内文書も直します。
• accounts.spacex.ai か accounts.x.ai がブロックされたままだと、移行のあと、ログインできません。
• SSOのIdPの設定（OktaのタイルやACS URLなど）は、変えなくてよい、タイルはそのまま動く、と書かれています。すでにサインインしているセッションは維持され、強制ログアウトにはなりません。
• 既存のEnterpriseの顧客は、自動では新しい体系に移されません。プラン、席、請求、SSO、ユーザーのプロビジョニングは、そのまま続きます。統合できる組織は一部で、資格の確認や変更は、アカウントの担当に連絡する形です（「Enterprise account unification」のページ）。そのページには、統合の手順や期限は書かれていませんでした。

データ保護：何が、どこまで書かれているか

法人向けの約束（発表と規約）

• 2025年12月30日の発表は、「顧客のデータは学習に使わない」と書いています。転送中と保存中の暗号化への言及は、Vaultの説明の中にあります。Google Driveのコネクタは、Drive側の既存の権限を守り、見られるのは本人が見られるファイルだけ、とあります。
• Enterprise向けの利用規約（Terms of Service, Enterprise。2026年8月14日更新と表示）は、事業者向けのAPIと関連サービス（Grokを含む）の、18歳以上の事業顧客が対象です。次のような条文があります（条番号は規約の表示）。

この規約が、セルフサービスで登録した小さなチームにも適用されるのか、読んだ要約では確かめられていません。個人データとZDRの条文の正確な範囲も同じです。原文で確かめてください。 なお、ユーザーガイドは、チーム用ワークスペースのプライバシー保護は「SpaceXSIの企業向けの利用規約に従う」と書いています。

APIのデータ：保存、ZDR、地域

API側の公式FAQ（Security）の内容です。前のガイド（05）にも書いた内容を、管理者の視点でまとめ直します。

公式のFAQは、ZDRを多くの顧客に勧めているわけではなく、使えなくなる機能が多い点を、はっきり書いています。Enterpriseの個別契約では、保持が別に決まることがある、ZDRの質問は sales@x.ai へ、とあります。

認証と、暗号化の高度な選択肢

• SOC 2。 API FAQは「SOC 2 Type 2」と書き、NDAを結べば trust.x.ai のTrust Centerを見られる、とします。価格ページは「SOC 2 compliance (Type I & II)」と書き、バッジに SOC 2 Type II、HIPAA、GDPR & CCPA を並べます。ただし、どのバッジがどのプランに当たるかは、価格ページに書かれていません。API FAQは、HIPAAの適合は主張せず、BAAは申請フォーム（x.ai/legal/baa）から求められる、とします。x.ai/security のページには、認証、暗号化、サブプロセッサの記載がありませんでした（脆弱性の報告先は HackerOne か vulnerabilities@x.ai）。
• Vault（Enterpriseの追加）。 発表と価格ページは、アプリケーション層の暗号化、顧客管理の暗号鍵（CMEK）、他の顧客から隔離された専用のデータ面、と書いています。鍵の管理の方法、対応するクラウド、データの置き場所は、読んだ範囲では書かれていません。

請求：誰がどこで何を見るか

Businessと、The X Subscriptionのチーム

• Grok Businessは、1ユーザー月30ドルです。ライセンスの購入と解約は Billing Read-Write の権限が必要です。解約の返金は、対象なら請求の手段に戻り、処理に数日かかることがあります。
• The X Subscriptionのチームは、Premium 30ドル、Super 100ドル、Ultra 200ドル（1席あたり月額、表示は2026年10月24日、税別）で、同じチームの中で席の種類を混ぜられます（例：Premium 3席とSuper 1席）。チーム向けの年払い価格は、公式のページには書かれていませんでした（Premium 300ドル、Super 1,000ドル、Ultra 2,000ドルという年払いの表示は、個人プランのものです）。チームには、請求の一本化、管理、使用状況の分析が付く、とあります。チームの席数の上限は、読んだ範囲では書かれていませんでした。
• 使用量は、各席が週ごとのプールを持ち、プールを超えた分が「Additional Usage」（追加使用）で、前払いのクレジットから払われます。チームの席は、ワークスペースの前払い残高を共有します。
• 追加使用の上限（Spending cap）。 月ごとの上限は、個人プランとセルフサービスのチームプランで使えます。チームでは、管理者が、チーム全体に1つの上限を、固定額か、席あたりの額で決めます。上限に達すると、前払いの残高が残っていても、追加使用は止まります。残高を足しても上限は上がりません。アラートは使用を止めず、止めるには上限が必要です。既定の上限額は書かれていません。上限を決めなければ、上限はありません。
• 自動チャージ（Auto Top-up）。 残高がしきい値まで下がったときに、保存した支払い手段に課金する機能です。既定はオフで、The X Subscriptionに切り替えてもオンにはなりません。チームでは、管理者だけが設定を変えられます。しきい値、チャージ額、最低の購入額の数字は、ページに書かれていませんでした。前払いクレジットの有効期限も、読んだ範囲では見つかりませんでした。
• 請求書と返金。 The X Subscriptionの請求書はダッシュボードにあります。古い購読を解約したときの返金は、日割りで元の支払い手段に戻り、クレジットにはなりません。Apple App StoreやGoogle Playで買った購読は、それぞれで手続きが必要です。
• 払い方。 チームの支払い手段、請求書払い、ACH、電信送金は、支払い方法のページには書かれていませんでした。Enterpriseの規約には、カード、ACH、小切手、電信送金が出ます（5.2）。切り替えは、未払いの請求書があるあいだはできません。

APIの請求（前払いと後払い、ティア、費用の見方）は、前のガイド（03と05）に書きました。

APIのチーム管理：Management API

前のガイド（05）の末尾で触れたManagement APIを、チームの管理者の視点で、もう一段詳しく見ます。公式の「Using Management API」のガイドと、リファレンスの「Accounts and Authorization」「Billing Management」「Audit Logs」を読んでまとめました。

まず管理キーを作る

• ベースURLは https://management-api.x.ai で、推論のAPI（api.x.ai）とは別です。
• 管理キーは、ConsoleのSettingsの「Management Keys」で作ります。通常のAPIキーとは別物です。作るには、アカウントに「Management Keys」の Read + Write の権限が必要で、見えない場合は、チームの管理者が有効にする、とリファレンスにあります。
• ヘッダーは Authorization: Bearer <管理キー> です。

管理キーが有効かを確かめる、権限なしで呼べるエンドポイントが、公式のガイドにあります。

curl https://management-api.x.ai/auth/management-keys/validation \
    -H "Authorization: Bearer <Your Management API Key>"

レスポンスには、キーのID、名前、権限（ACL）、スコープ（SCOPE_TEAM か SCOPE_ORGANIZATION）、許可するIPの範囲（ipRanges）が含まれる、と書かれています。公式の例のキーは、チームのスコープで、team-token:endpoint:ListApiKeys のような権限を持っています。

チームでAPIキーを発行する（ACLとレート制限）

発行は、チームのIDを指定します。チームIDは、consoleのチーム設定のページで見つかる、と書かれています。公式のガイドの例は次のとおりです。

curl https://management-api.x.ai/auth/teams/{teamId}/api-keys \
    -X POST \
    -H "Authorization: Bearer <Your Management API Key>" \
    -d '{
            "name": "My API key",
            "acls": ["api-key:model:*", "api-key:endpoint:*"],
            "qps": 5,
            "qpm": 100,
            "tpm": null
        }'

• ACLがないキーは、何もできません。 リファレンスは、キーには既定でアクセスがなく、ACLなしでは全部のリクエストが失敗する、と書いています。
• ACLの形は、api-key:endpoint:<エンドポイント名> と api-key:model:<モデル名> です。* で全部です。エンドポイントの例は chat、embed、image、models、sample、tokenize、documents です。使えるモデル名は、GET /auth/teams/{teamId}/models で、使えるエンドポイントのACLは、GET /auth/teams/{teamId}/endpoints で調べられます。
• qps、qpm、tpm は、そのキーごとの上限です。tpm は、上限を超えたあとで新しいリクエストを断り、進行中のものは止めません。リファレンスは、tpm が厳密に上限を超えたときにだけ働く、とも書いています。
• expireTime で有効期限を付けられます。
• 返ってくる apiKey（秘密の本体）は、作ったときだけ見えます。apiKeyId は、更新と削除に使います。新しいキーは、すべてのクラスタに行き渡るまで少しかかることがあり、GET /auth/api-keys/{apiKeyId}/propagation で確かめられます。
• 一覧は、管理者はチームの全部のキーを、メンバーは自分のキーだけを見られる、と書かれています。

更新（名前、レート制限など）は、PUT で、変える項目と fieldMask を送ります。公式の例は次のとおりです。

curl https://management-api.x.ai/auth/api-keys/{apiKeyId} \
    -X PUT \
    -H "Authorization: Bearer <Your Management API Key>" \
    -d '{
            "apiKey": {
                "qpm": 200
            },
            "fieldMask": "qpm"
        }'

削除は、取り消せません。

curl https://management-api.x.ai/auth/api-keys/{apiKeyId} \
    -X DELETE \
    -H "Authorization: Bearer <Your Management API Key>"

シークレットのローテーション。 リファレンスには、POST /auth/api-keys/{apiKeyId}/rotate があります。本文の項目は、expireTime（新しいシークレットの期限。指定しなければ古いものを引き継ぐ）と、oldSecretExpireTime（古いシークレットが止まる時刻。期限切れでないキーでは既定で24時間後、最大で7日先まで）です。ただし、同じページの警告は、ローテーションで古いキーが「永久に無効になる」と書いており、oldSecretExpireTime の仕様と合いません。どちらが実際の動きかは、確認できていません。 本番のキーで試す前に、テスト用のキーで確かめるのが安全だと、僕らは見立てます。

監査ログを取り出す

チームの設定、APIキー、メンバーシップ、その他の管理操作の変更が、監査のイベントになる、と公式のガイドに書かれています。

curl "https://management-api.x.ai/audit/teams/{teamId}/events?pageSize=10" \
    -H "Authorization: Bearer <Your Management API Key>"

• 絞り込みは、eventFilter.userId、eventFilter.query（説明の全文検索）、eventFilter.eventId、eventTimeFrom、eventTimeTo（時刻の形式は、読んだ範囲ではページに明示がありませんでした）、並び順の orderBy（TIME_ASCENDING か TIME_DESCENDING）です。次のページは、レスポンスの nextPageToken を pageToken に入れます。
• 各イベントは、時刻、ID、英語の自由な説明（例：「API key 'Production Key' was created」）、ユーザーの情報です。メールアドレスは、必ず入るとは限りません。
• 読んだ範囲では見つからなかったこと。 イベントの種類の一覧、ログの保持期間、呼ぶのに必要な権限は、ページに書かれていません。

請求の情報をAPIで見る

「Billing Management」のリファレンスのエンドポイントです。パスは /v1/billing/teams/{team_id}/... の形で、ベースURLは、Management APIのリファレンスに書かれた https://management-api.x.ai です。

公式のページに載っているのは、請求先の情報（/billing-info）、請求書の一覧（/invoices、金額は米ドルのセント）、支払い手段の一覧と既定の設定（追加と削除はconsoleで行う、とあります）、後払いの当期のプレビューと月ごとの上限（/postpaid/...）、前払いの残高と追加（/prepaid/...）、使用量の集計（POST /usage）です。

後払いの月ごとの上限は、公式のページでは、リクエストが desiredSoftSpendingLimit の val に "20000" を入れる形でした（単位は米ドルのセントなので200ドル）。リクエストの形は次のとおりです（ページの記述から書いたもので、curlの完全な例ではありません）。

{ "desiredSoftSpendingLimit": { "val": "20000" } }

• 前払いのクレジットは、いつも先に使われます。
• ページの食い違い（公式のページ内）。 税のIDの書き方が、請求先の例では us_ein、支払い手段の例では us-ein です。列挙の綴りの誤り（FAILED_TO_GEMNERATE_INVOICE）は、原文のまま使うよう、ページに注記があります。請求書や使用量の取得に、ページ送りの説明はありません（使用量は、打ち切りを limitReached で知らせます）。
• 各エンドポイントに必要な権限（ACLや Billing Read-Write）は、請求のページには書かれていませんでした。

Grok Build（CLI）の管理者設定

Grok BuildをチームのPCに配るなら、公式の「Enterprise deployments」のページに、ネットワーク、設定ファイル、ログインの制限、権限の固定が書かれています。このページは、ベータか正式版かを書いていません。

• ネットワーク。 すべてHTTPS（443）。必須のホストは cli-chat-proxy.grok.com、auth.x.ai、エンタープライズOIDCならIdPのドメインです。TLSは1.2か1.3だけで、無効にできず、TLSを検査するプロキシはそのCAをOSの信頼ストアに入れる必要があります。
• 設定ファイルの5層（弱い順）。 /etc/grok/managed_config.toml、~/.grok/managed_config.toml、~/.grok/config.toml、~/.grok/requirements.toml、/etc/grok/requirements.toml。requirements.toml の値は「固定」され、下の層、リモートの設定、環境変数、ユーザーの設定で上書きできません。MDMやゴールデンイメージには、/etc/grok/ に置く、とあります。
• ログインの制限。 次の項目は、requirements.toml の [grok_com_config] に置きます。

• 危険なモードの固定。 [ui] の disable_bypass_permissions_mode = true で、--yolo、--permission-mode bypassPermissions、セッション中の切り替え、* や ** のような何でも許可するルールを止められます。拒否のルールは働き続けます。この固定は、root所有の元（/etc/grok/requirements.toml など）から読まれたものだけが効き、~/.grok/requirements.toml では効きません。Claude Codeの disableBypassPermissionsMode は、Grokには引き継がれません。
• 設定が効いているかは、grok inspect で確かめます。

ページの説明から短く組み立てると、固定のファイルは次のような形になります。キーの置き場所（どのテーブルか）は上の説明のとおりですが、完全な公式の例ではなく、動作確認もしていません。

# /etc/grok/requirements.toml（説明から組み立てた形）
[grok_com_config]
disable_api_key_auth = true

[ui]
disable_bypass_permissions_mode = true

[sandbox]
profile = "workspace"

force_login_team_uuid の値の書き方（文字列か一覧か）の例は、読んだ要約には出ていないので、この例には入れていません。公式の原文で確かめてください。

ZDRは、チームやEnterpriseで有効にすると、Grok Buildにも適用される、とあります。ZDRのときのビデオの出力は、自分で用意した保存先が必要で、別ページに書かれています（読んでいません）。

展開の順序（僕らの整理です）

ここから先は、公式の記載を読んだうえでの僕らの整理で、見立てです。

1. どの入口で契約しているかを確認する（console.x.ai のGrok Business、grok.com/dashboard、Enterpriseの担当）。
2. 10月30日までに、サインインのドメインを許可リストに足す。
3. 管理者の権限（Team／Billing Read-Write、Admin）を、最小の人数にする。
4. 共有ポリシーを、最初にTeamに引き締める。
5. 請求の設定、追加使用の上限、アラートを先に決める。
6. 少人数に席を配って試し、取り消しの手順を一度通す（取り消しは即時、席は残る）。
7. APIを使うなら、キーごとに最小のACL、レート制限、期限を付け、ZDRが必要かを決める。
8. Enterpriseなら、SSOを試し、SCIMはプレビューを何度も読んでから有効化する。
9. 契約の条文（保持、ZDR、個人データ、更新と解約）を、原文で、必要なら専門家と確認する。

気をつけること

• この記事は、実際に使って確かめた記録ではありません。運営者はGrokを入れていますが、使い心地はこの記事には書いていません。コマンド、JSON、TOMLは、公式の例を写したか、説明から短く組み立てたものです。上限、画面名、権限の名前は、更新で変わりやすい点です。
• いまはGrok Business（console.x.ai）とThe X Subscription（grok.com/dashboard）の過渡期で、同じ作業の説明が2か所にあります。
• 2026年10月30日にサインインのドメインが変わります。許可リストを直さないとログインできなくなる、と公式が書いています。
• SCIMの有効化は、公式が「very disruptive」と警告しています。SSOは有効にすると組織全体で強制されます。
• ライセンスの取り消しは即時、席を外しても支払いは別に止める必要があり、チームの統合は元に戻せません。ZDRは、入れる前にFilesとCollectionsの削除が必要で、消した内容は戻せません。
• 公式のページ間に食い違いがあります（Custom data retentionのプランの扱い、共有リンクの範囲、価格ページと発表での「Advanced audit and security controls」の置き場所、SOC 2の表記、キーのローテーションの警告と仕様、税IDの書き方）。どちらが正しいかは確認できていません。
• 読めなかった、または読んでいないもの。console.x.ai の画面そのもの（取得に失敗）、ユーザーガイドの別URL（取得に失敗）、Trust Center（NDAが必要）、DPA、BAA、サブプロセッサの一覧、Enterpriseの個別のFAQ、Vaultの技術的な説明、Custom MCP Tunneling、SharePointやSalesforceの管理者向け手順。
• 法律、契約、セキュリティの助言ではありません。契約や規約は、原文で、必要なら専門家に確かめてください。

出典

• Introducing Grok Business and Grok Enterprise（x.ai、2025年12月30日、確認日2026-10-24）
• Grok Business and Enterprise（x.ai、日付の表示なし、確認日2026-10-24）
• Business & Enterprise：ユーザーガイド（docs.x.ai、日付の表示なし、確認日2026-10-24）
• License & User Management（docs.x.ai、日付の表示なし、確認日2026-10-24）
• Connector Management（docs.x.ai、日付の表示なし、確認日2026-10-24）
• Organization Management（docs.x.ai、日付の表示なし、確認日2026-10-24）
• Team plans, seats, and invites（docs.x.ai、日付の表示なし、確認日2026-10-24）
• Enterprise account unification（docs.x.ai、日付の表示なし、確認日2026-10-24）
• Sign-in（docs.x.ai、日付の表示なし、確認日2026-10-24）
• Sign-in domains（docs.x.ai、日付の表示なし、確認日2026-10-24）
• Plans and usage（docs.x.ai、日付の表示なし、確認日2026-10-24）
• Spending caps and alerts（docs.x.ai、日付の表示なし、確認日2026-10-24）
• Prepaid balance and automatic top-ups（docs.x.ai、日付の表示なし、確認日2026-10-24）
• Extra usage credits and top-ups（docs.x.ai、日付の表示なし、確認日2026-10-24）
• Invoices & Refunds（docs.x.ai、日付の表示なし、確認日2026-10-24）
• Payment methods（docs.x.ai、日付の表示なし、確認日2026-10-24）
• Terms of Service, Enterprise（x.ai、2026年8月14日更新と表示、確認日2026-10-24）
• FAQ：Security（docs.x.ai、日付の表示なし、確認日2026-10-24）
• Trust & Security（x.ai、日付の表示なし、確認日2026-10-24）
• Management API Guide（docs.x.ai、日付の表示なし、確認日2026-10-24）
• Management API（リファレンスの概要、docs.x.ai、確認日2026-10-24）
• Management API：Accounts and Authorization（docs.x.ai、確認日2026-10-24）
• Management API：Billing Management（docs.x.ai、確認日2026-10-24）
• Management API：Audit Logs（docs.x.ai、確認日2026-10-24）
• Grok Build：Enterprise deployments（docs.x.ai、日付の表示なし、確認日2026-10-24）
• Grok Bot：Teams and enterprises（docs.x.ai、日付の表示なし、確認日2026-10-24）
• Grok Bot：Identity and access（docs.x.ai、日付の表示なし、確認日2026-10-24）
• docs.x.ai llms.txt（目次、docs.x.ai、確認日2026-10-24）