Skip to content
第4部 · 実践編

第 23 章 チーム版とエンタープライズ導入 ​

チームに Grok Bot を導入する際、主な課題・ボトルネックとなるのは以下の点です。

  • ゲートウェイがハンドシェイク段階で遮断し、クラウドコンピュータに接続できない。
  • Linux VM に MDM クライアントがインストールされていないため、企業の IdP から信頼されていないデバイスと判定される。
  • クレデンシャル漏洩やイントラネット貫通のリスクが存在し、クライアントのサイレント配布手段も不足している。

手順に沿って SSO とセキュリティゲートウェイの除外設定を行い、プライベートネットワークアクセスを開通させれば、一括ライフサイクル管理を実現できます。

チーム版とエンタープライズ導入

チーム版とエンタープライズ版の管理制御:アーキテクチャと機能境界 ​

チーム版とエンタープライズ版の管理制御:アーキテクチャと機能境界

概要 ​

各ユーザーにクラウドの Firecracker microVM が1台専有して割り当てられ、ローカルから指示の送信や承認を行い、コードとブラウザはクラウド上で動作します。

注意すべき点として、自身の配下にあるすべての Bot がこの仮想マシンを共有するため、ファイルやログインセッションは完全に共通化されます。

2026-10-12 の The X Subscription プランでは、2つの権限エディションに区分されています:

  • チーム版:全員デフォルトで有効、共有静的送信元(エグレス)IP を経由、基本的な監査ログとチームルールを搭載。
  • エンタープライズ版:グループごとの認可と SCIM 2.0 に対応、sudo やネットワーク許可リストの利用が可能、操作レコーディングおよび OpenTelemetry エクスポートに対応(cursor.surface=grok_bot タグを付与)。

ドキュメントは Teams およびエンタープライズ版向け Grok Bot を参照してください。

手順 ​

日常の設定はすべて Cursor ダッシュボードの Grok Bot ページ で行い、主に4つのステップに分かれます。

  1. 権限の区分と基本スイッチ
  • カナリア(段階的展開)期間中は Manage Group Access をクリックしてパイロットグループにチェックを入れます。クラウドコーディングを使用しない場合は Cloud Agents をオフにし、外部流出を防ぐため公開テンプレート共有はオフのままにしておきます。
  • ローカル実行は Never allow に設定することを推奨し、同時に迂回転送を防ぐためローカル出口ルーティングを無効化します。
  • サイドバーの Bot は、Auto-add 列で All team または指定グループを選択して固定します。
  1. 承認ロックとルールの設定
  • Enforce Auto-review モードを有効にすると、メンバーはクライアント側で自動レビューを勝手にオフにできなくなります。
  • 本番環境へのデプロイや外部メール送信などの高リスク操作は Ask first に設定し、限定的な読み取り専用操作は Allow automatically に設定します。
  • チームルールと個人ルールが競合した場合、システムは強制的に Ask first を優先します。
  1. ネットワークとシークレットの設定
  • ネットワークはチーム許可リストのみ、またはデフォルト値を追加し、ドメインと IP レンジを入力します。システムの改ざんを防ぐため、デフォルトで有効になっている sudo を無効化することもできます。
  • Team Secrets はチームあたり最大 100 件追加可能で、1件あたり上限 32 KB、総容量上限は 96 KB です。保存後は平文で表示されません。
  • シークレット変数名には、PATH、HOME、および SAND_ または LD_ で始まるシステム予約名の使用は禁止されています。
  1. グループレベルポリシーの設定
  • Members > Groups からグループに入ります。設定の原則は「緩和のみ可能で、より厳格にはできない」ことです。
  • Don't enforce for this group にチェックを入れると、自動レビューのロックを解除できます。
  • ネットワークポリシーは例外で、グループ設定がチーム設定を直接上書きします。メンバーが複数のグループにまたがる場合、ネットワークは最も厳格なものが適用され、権限は最も緩和されたものが有効になります。

達成基準 ​

  • ダッシュボード上でパイロットグループと未認可グループが明確に区別されており、未認可のユーザーはクライアント側で Bot をアクティベートできない。
  • チームルールと Auto-review ルールがロックされており、メンバーはクライアントの設定画面でチームルールを確認できるものの、編集および削除ボタンが無効化されている。
  • 高リスク操作(外部通信、ファイルの破壊、特権コマンド)で 100% 承認インターセプトがトリガーされる。

アイデンティティと SSO:全社アクセスの開通とデバイストラストの互換性 ​

概要 ​

Grok Bot は Cursor のアカウント体系を踏襲しているため、IdP 側で個別にアプリケーションを作成する必要はありません。参考ドキュメント:アイデンティティとアクセスの設定。

Bot はクラウド上の Linux 仮想マシンで動作し、MDM が未導入であるため、FastPass や Hybrid Join の要件を満たすことができません。決して全体でデバイスコンプライアンスを一括無効化してはならず、遮断ルールの手前で対象グループ向けのバイパス(許可)ポリシーを設定する必要があります。

手順 ​

  • Okta の割り当て拡大:Cursor アプリケーションの Assignments > Assign to Groups に移動して対象業務グループにチェックを入れます。SCIM を有効にしている場合は、同時に割り当ててプッシュ(Push Groups)します。

    SAML SSO と SCIM は必ず同時に割り当てる必要があり、SSO の割り当てが漏れるとログインが遮断されます。

  • Entra ID の割り当て拡大:Cursor アプリケーションの Users and groups で Add user/group をクリックしてグループを追加します(P1/P2 ライセンスが必要、ネストされたグループは非対応)。プロビジョニングアプリケーションにも同じグループを同期して割り当てます。

  • Okta での Linux 許可:認証ポリシーの遮断ルールの手前に新規で Grok Bot computer (Linux) を作成します。

    ユーザーは Cursor グループに限定し、Device platform は Other Desktop を選択(単独の Linux 項目がないため)、Device state は Any を選択します。認証方式には Password + Another factor を選択し、フィッシング耐性要件にはチェックを入れません。

  • Entra ID での Linux 許可:優先度の高い新規ポリシーを作成し、Cursor グループと対象アプリケーションを指定します。Device platforms には Linux を含め、Windows と macOS を除外します。Grant では Require multifactor authentication にチェックを入れます。既存のコンプライアンスポリシーからは、当該グループまたは Linux プラットフォームを必ず除外してください。

達成基準 ​

  • 業務ユーザーが企業の SSO を使ってデスクトップクライアントにログインした際、User is not assigned to this application のエラーが出ない。
  • Bot ブラウザにおいて、パスワードと二要素認証によりイントラネットへアクセスでき、FastPass やデバイス非準拠の遮断ポップアップが表示されない。
  • 従業員が各自の PC からアクセスした際は、従来の FastPass やデバイスコンプライアンスが依然として厳格に適用されている。

プライベートネットワーク接続:デスクトップルーティングと Team Setup スクリプトによる自動化 ​

プライベートネットワーク接続:デスクトップルーティング与 Team Setup 脚本自动化

概要 ​

Grok Bot はクラウド上で動作するため、イントラネットへのアクセスにはプライベートネットワークの開通が必須です。

  • デスクトップクライアントルーティング:一時的なデバッグに適しています。クライアントで Settings > Computer > Route traffic through this computer を有効にすると、トラフィックがローカルマシンの NIC を経由します。管理者は管理画面からワンクリックで無効化できます。
  • Team Setup によるクライアントインストール:常時アクセス向けであり、エンタープライズ版限定です。IT 部門がスクリプトを一元管理し、Bot の起動またはリフレッシュ時に自動で起動してイントラネットに参加します。

詳細は プライベートネットワークへの接続 を参照してください。

手順 ​

チーム環境セットアップスクリプトはダッシュボードの Bot Computers 配下にあり、Debian Linux 仮想マシン内で sudo 権限を持つ一般ユーザーとして実行されます。スクリプトは起動時に実行され、約1日周期でリフレッシュされます。タイムアウトの上限は 30 分です。

  • check の終了コードが 0 であればインストールをスキップし、インストール完了後に再度 check を実行して検証します。
  • 実行に失敗してもコンピュータの起動はブロックされず、次回の定期リフレッシュ時に再試行されます。

Tailscale ネットワーク接続プラン ​

  1. Team Secrets を開き、Tailscale 認証キー TS_AUTHKEY(値は tskey-auth-...)を追加し、Tailscale 管理コンソールで専用の ACL タグ(例:tag:grok-bot)を紐付けてアクセス権限を厳格に制限します。
  2. チーム環境セットアップスクリプトに移動し、+ をクリックしてマニフェストを新規作成します。Manifest ID に private-network-tailscale を入力し、JSON またはフォームモードに切り替えて設定を入力します:
Tailscale ネットワーク接続プラン
json
{
  "manifestId": "private-network-tailscale",
  "entries": [
    {
      "id": "install-tailscale",
      "setup": "#!/usr/bin/env bash\nset -euo pipefail\ncurl -fsSL https://tailscale.com/install.sh | sh\nsudo tailscale up --authkey=\"$TS_AUTHKEY\" --accept-routes --hostname=\"grok-vm-${USER}\"",
      "check": "command -v tailscale && tailscale status"
    }
  ]
}

Cloudflare Tunnel 接続プラン ​

  • プライベート HTTP サービス:トンネルルーティングのドメインに直接アクセスし、Cloudflare Access による認証を行い、Bot ブラウザでのインタラクションにより認証を完了します。
  • プライベート TCP サービス(データベース、SSH など):マニフェストで cloudflared をインストールし、接続が必要な際に Shell でコマンドを実行してローカル転送ポートを開きます:

cloudflared access tcp --hostname db-internal.corp.com --url localhost:5432

Cloudflare Tunnel 接続プラン
json
{
  "manifestId": "private-network-cftunnel",
  "entries": [
    {
      "id": "install-cloudflared",
      "setup": "#!/usr/bin/env bash\nset -euo pipefail\ncurl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null\necho 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared bullseye main' | sudo tee /etc/apt/sources.list.d/cloudflared.list\nsudo apt-get update && sudo apt-get install -y cloudflared",
      "check": "command -v cloudflared"
    }
  ]
}

ネットワークポリシーに合わせたコントロールプレーンエンドポイントの許可 ​

チームでチーム許可リストのみのネットワーク制御を有効にしている場合、ネットワークツールのコントロールプレーンを必ず許可リストに追加する必要があります。そうしないとクライアントの認証が完了しません。例えば Tailscale を使用する場合、ポリシー内で協調(コーディネーション)サーバーおよび DERP リレーサーバーのドメインを許可する必要があります。ポリシーの変更は約1分で仮想マシンに反映されます。

達成基準 ​

  • 新規作成または再構築された Bot コンピュータが起動完了後、Tailscale または Cloudflare の管理コンソールのデバイス一覧に自動的に表示され、ステータスがオンラインになっていること。
  • マニフェスト内の check スクリプトが、その後の毎日の定期リフレッシュにおいて安定して 0 を返し、インストール処理が重複実行されないこと。
  • 機密トークンが完全に Team Secrets から注入されており、マニフェスト本文や実行ログに平文の認証情報が一切含まれていないこと。

プロキシと企業ゲートウェイの落とし穴回避:許可ルールと TLS インスペクションの除外 ​

エンタープライズゲートウェイ(Zscaler、Palo Alto など)により、チャットは正常に行えるもののスクリーンショットの取得やターミナルの制御ができないという事象が頻発します。

その原因は、コントロールプレーンが <computer>.<cluster>.cursorvm.com という2段階のネストされたドメインによる HTTP/2 または SSE ストリーミングの永続接続を使用しており、通常の単一階層ルールではマッチしない点にあります。

公式の説明は TLS インスペクションプロキシの設定 を参照してください。

設定のポイント ​

ゲートウェイでは以下のドメインを許可し、エンドツーエンドのハンドシェイク失敗やストリーミングのタイムアウトを防ぐため、レスポンスバッファリングを無効化し、TLS インスペクションを除外する必要があります:

  • *.cursor.sh:コア API
  • *.cursorvm.com および *.*.cursorvm.com:コントロールチャネル(2階層ワイルドカードのサポートが必須)
  • *.cursor-cdn.com、*.cursorapi.com、downloads.cursor.com およびメインサイト:静的アセットとアップデートのダウンロード

ポリシー設定完了後は、従業員の社外接続や在宅勤務時の接続不能を防ぐため、必ず Off-Network(ローミング)設定にも同期してください。

デバイスのトラブルシューティングと検収 ​

従業員の PC ターミナルで以下の手順に従って確認します:

  1. 証明書が改ざん(インスペクションによる置換)されていないか検証します。正常な発行者は Amazon RSA である必要があります:
bash
   curl -v https://api2.cursor.sh |& grep -C1 issuer:
  1. 多階層 DNS 解決を検証します。失敗した場合は nslookup test.us9.cursorvm.com 1.1.1.1 と比較してください:
bash
   nslookup test.us9.cursorvm.com
  1. ストリーミング転送を確認します:データは1行ずつ出力される必要があります。数秒間停止した後に突然まとめて出力される場合は、ゲートウェイのバッファリングが無効化されていません。

検収基準:社内ネットワークおよび自宅ローミング環境のいずれでも 5 秒以内にクラウドコンピュータへ接続できること。証明書は Amazon RSA が直接パススルーされ、ストリーミング永続接続にバッファリングによる遅延がないこと。

デスクトップクライアントの配布とバージョン管理 ​

プラットフォームと更新メカニズム ​

プラットフォームインストール形式更新ロジック
macOS.dmg(Apple Silicon / Intel)起動時に自動で更新を確認、ポリシーによる無効化は非対応
WindowsSetup .exe(x64 / Arm64)起動時に自動で更新を確認、ポリシーによる無効化は非対応
Linux.deb、.rpm、AppImagedeb と rpm はパッケージマネージャーが管理。AppImage は自動で更新を確認
iOSApp StoreiOS 18 以降が必要
AndroidGoogle PlayAndroid 9 以降が必要、マネージド配信に対応

公式のデプロイ説明は 組織への Grok Bot のデプロイ を参照してください。

デプロイとバージョン管理 ​

  1. インストーラーの取得 インストーラーを取得する際、Web ページを手動でクリックするのではなく、公式の JSON フィード(https://api2.cursor.sh/updates/api/download/stable/{platform}/sand)を直接呼び出します。 {platform} は macOS(darwin-arm64、darwin-x64)、Windows(win32-x64-user、win32-arm64-user)、および Linux(linux-x64、linux-arm64)に対応しています。
bash
curl -s https://api2.cursor.sh/updates/api/download/stable/win32-x64-user/sand

API は version、commitSha、downloadUrl、および Linux 向けの debUrl と rpmUrl を返します。macOS と Windows は、命名規則に従ってインストーラーの URL を直接組み立てることも可能です:

  • Windows: https://downloads.cursor.com/grokbot/stable/win32-x64/{version}/Grok_Bot_{version}_Setup.exe
  • macOS: https://downloads.cursor.com/grokbot/stable/darwin-arm64/{version}/Grok_Bot_{version}.dmg
  1. MDM による配信
    • Windows(Intune / SCCM):サイレントインストール用のパラメータに /S を指定します。インストーラーはデフォルトで現在のユーザーの %LOCALAPPDATA%\Programs に書き込まれるため、必ずユーザーコンテキスト(User Context)で実行する必要があります。

      ローカル SYSTEM アカウントは決して使用しないでください。インストール先のパスが異なり、従業員がアプリケーションを見つけられなくなります。

cmd
  Grok_Bot_1.0.0_Setup.exe /S
  • macOS(Jamf / Kandji / Intune):該当アーキテクチャの .dmg を /Applications ディレクトリにプッシュ配布するだけです。
  • Linux(Ansible / Puppet):.deb または .rpm パッケージをインストールすると、システムが自動的に公式リポジトリ設定を書き込みます。
  1. バージョン管理と固定(ロック) macOS および Windows では、ポリシーによって自動アップグレードを完全に無効化することはできません。

Linux 環境では、パッケージマネージャーによってバージョンを固定するか、/etc/apt/sources.list.d/grok-bot.sources で Enabled: no に設定する、あるいは /etc/yum.repos.d/grok-bot.repo で enabled=0 に設定して同期を一時停止できます:

bash
  sudo apt-mark hold grok-bot

Cursor は旧バージョンに対してサポート期限を設定しています。クライアントがサポートの最低閾値を下回ると、全画面で「Update required」のポップアップが表示され強制的にブロックされます。Linux でバージョンを固定して期限を超過した場合も同様にブロックされます。運用保守チームは、テスト済みの新しい安定版を 2〜4 週間ごとに段階的(カナリア)リリースする必要があります。

検収基準 ​

  • 業務端末への MDM によるサイレントインストールが完了し、新入社員が端末を起動した時点でデスクトップの準備が整っていること。
  • IT チームが定期的なバージョンローテーションのリズムを確立し、公式の強制ブロックが発生する前に組織内のバージョン更新を完了していること。

Bot コンピュータの管理:一括運用保守とライフサイクル ​

Bot コンピュータの管理:一括運用保守とライフサイクル

主要な操作と権限 ​

アクセス口は Cursor ダッシュボードの Grok Bot ページ の Bot Computers セクションにあり、Manage Bot Computers をクリックしてアクセスします。

この機能はエンタープライズ版の組織管理者(Organization Admins)限定であり、通常のチーム管理者には表示されません。

ドキュメントは Grok Bot コンピュータの管理 を参照してください。

操作名基盤動作データおよびファイルの保持状態適用シナリオ
VM の再構築(Recreate VMs)最新イメージで再インストールし環境スクリプトを再実行保持。ディスクはそのまま保持され、Bot、個人ファイル、Cookie はすべて維持される。独自にインストールしたシステムソフトウェアのみ消去環境スクリプト変更の反映、新規イメージの段階的導入
VM の終了(Terminate VMs)実行中またはスリープ中のインスタンスを直ちに破棄し、現在の処理を中断保持。ディスクは保持され、次回クライアントからメッセージを送信した際にクリーンな仮想マシンが再起動されるインスタンスのフリーズ解消、クラウド占有リソースの解放
仮想マシンとデータの削除仮想マシンを破棄し、基盤に紐付いた永続ストレージを完全に削除保持しない。データは完全に消去され、次回利用時はクリーンな初期状態のコンピュータとして再初期化される従業員の退職時のクリーンアップ、データ破損時の完全初期化

コンソール操作とトラブル回避 ​

  1. ページに入って管理をクリックし、氏名またはメールアドレスで検索してメンバーを絞り込みます。単一選択、複数選択、または Select all に対応しています。
  2. Manage selected ドロップダウンから対象の操作を選択し、影響を受ける人数を確認して実行を開始します。
  3. 実行完了後は必ずカード上の Done ボタンをクリックする必要があります。各チームで同一時間に実行できる一括操作は1件のみであり、Done をクリックしないと以降のボタンがロックされたままになります。

スキップまたは失敗のステータスが発生した場合は、結果ログに応じて対応します。

  • スキップ(VM なし / 操作を完了できません):配下に VM がない、またはキュー待ちの間にチームから離脱したため、対応は不要です。
  • 失敗(別の再構築が進行中 / VM スキャン未完了):他の更新が終了していないか、バックエンドが一時的にステータスを取得できていません。数分待ってから再試行してください。
  • 失敗(操作を完了できません):Bot が高負荷なタスクを実行中でタイムアウトが発生しました。メンバーに Bot を一時的にアイドル状態にしてもらい、再試行してください。

自動化と検収基準 ​

操作ボタンの上部にある Terminate Inactive Computers スイッチをオンにします。メンバーのコンピュータが連続して 30 日間アクティビティがない場合、自動的に終了されます。計算インスタンスのみが解放され、ディスクは保持され、システムがローリング周期でクリーンアップします。

複数チームの一括運用保守には 組織 Admin API を呼び出すことができます。

呼び出し時には admin:* 権限を持つ組織 API キーを提供し、チーム ID、メンバーのメールアドレス配列、およびアクションタイプ(recreate または terminate)を渡して進捗をポーリングします。こちらもチームごとに単一の同時実行制限を受けます。

検収時は主に以下の2つの指標に注目します。

  • データを失うことなく、スムーズにインスタンスの一括再構築ができること。
  • 30 日間のアイドル状態での自動終了を有効化し、休眠状態のゾンビ仮想マシンが組織のクラウドクォータを占有するのを防ぐこと。

エンタープライズセキュリティベースライン設定と実践プロンプト ​

管理者設定 ​

  1. ネットワークを「チーム許可リストのみ」に固定し、公開テンプレートとメールチャネルを無効化します。
  2. Enforce Auto-review を有効にし、不正な自己ダウングレードを防ぐためローカル実行を Never allow に設定します。
  3. 本番 API の呼び出しや DB 変更、または外部メール送信、規約・合意締結、main へのマージに関わる操作は、必ず Ask first に設定します。ログクエリやコンパイルはそのまま許可します。

従業員向けルール ​

  1. 認証情報は環境変数を使用し、対話入力欄に平文パスワードを貼り付けることを厳禁とします。
  2. 機密性の高い承認は Allow once を選択し、常時許可は選ばず、使用後は速やかに終了します。

実践プロンプト ​

実践プロンプト
text
你现在负责对内部服务进行接口与架构调研。
请遵循以下严格的安全限制:
1. 本次任务为纯只读模式,严禁对目标服务发起任何 POST、PUT、DELETE 请求。
2. 检查网络连通性:尝试向内部端点 http://api-monitor.corp.internal/health 发起 GET 请求并打印状态码。
3. 如果遇到证书问题或连接被重定向,记录错误日志,不要尝试使用任何提权手段。
4. 将调研结果汇总输出为 Markdown 表格,包含服务名称、响应耗时、健康状态。
5. 完成后暂停执行,等待我的进一步指令,不要擅自读取其他网段资产。
実践プロンプト
text
请按规范完成本周发版代码的对比检查与 PR 草稿创建:
1. 切换到工作区代码目录,拉取 origin/main 最新分支。
2. 比对 feature/sso-login 分支与 main 分支的改动差异,列出所有变动的文件列表。
3. 检查是否有硬编码的密钥、密码或私钥文件被提交。如果发现任何形如 'AKIA...' 或 'BEGIN PRIVATE KEY' 的文本,立即中断任务并向我告警。
4. 在本地运行静态检查脚本:npm run lint 和 npm run test。
5. 准备 PR 描述文本草稿,包含变更摘要与测试结果。
6. 注意:严禁直接推送到远程仓库。把 PR 描述保存为 local-pr-draft.md 后向我申请确认。得到明确授权前不得执行 git push。
実践プロンプト
text
请处理今天未分配的内部支持工单:
1. 打开浏览器,访问内部工单控制台 https://tickets.corp.internal。
2. 过滤出状态为 'New' 且优先级为 'High' 的所有工单。
3. 逐条提取工单的核心问题,按照以下类别打标签:[账号登录]、[权限申请]、[网络故障]。
4. 为每条工单生成标准回复模版,存入草稿区。
5. 涉及权限开通的工单,一律在回复中注明:'需直属主管在 OA 提交审批流,当前仅作信息预审'。
6. 严格要求:所有邮件和系统回复只保留在草稿状态,严禁点击 'Send' 或 'Submit'。生成处理清单供我逐条审查。

よくある落とし穴 ​

  1. ゲートウェイでの多階層ワイルドカードの設定漏れ:ホスト名は <vm-id>.<cluster-id>.cursorvm.com であるため、*.cursorvm.com のみの設定では 99% で停止します。*.*.cursorvm.com を追加設定する必要があります。
  2. プロキシのバッファリング有効化によるストリーム切断:Zscaler で Response Buffering を有効にすると接続が切断されます。Cursor ドメインに対しては必ずバッファリングを無効化し、Server-Sent Events をパススルーしてください。
  3. ローミングポリシーでのホワイトリスト設定漏れ:帰宅時に接続できなくなるのは、Zscaler が Off-Network ポリシーに切り替わったことが原因です。ドメイン許可リストと TLS 除外設定を忘れずに社外ポリシーへ同期してください。
  4. 旧版プライバシーモードの誤有効化:管理画面で「プライバシーモード(旧版)」を有効にすると Bot が完全に無効化されます。チーム設定でオフにしてください。
  5. IdP による準拠デバイスの強制:クラウドの Linux VM は MDM 管理下にないため FastPass を実行できません。Okta/Entra ID で Linux(Other Desktop)向けの優先度が高いルールを追加し、パスワード+スマホの二要素認証による許可へ切り替えてください。
  6. スクリプトへのシークレット平文保存:Team Setup は平文の JSON です。トークンは Team Secrets に保存し、スクリプトからは "$TS_AUTHKEY" で読み取ってください。
  7. SYSTEM 権限インストールによるアプリ消失:プログラムは %LOCALAPPDATA%\Programs にインストールされます。必ず現在のユーザーコンテキストで /S インストールコマンドを実行してください。
  8. 終了(Terminate)と権限剥奪の混同:Terminate はプロセスを停止してディスクを保持するだけであり、メッセージを送信すると再び起動します。権限を完全に剥奪するには、IdP で割り当てを解除するか Manage Group Access から削除してください。
  9. 複数チーム所属によるシークレットの喪失:Team Setup が設定されたチームに2つ以上所属していると、すべての Team Secrets の受け取りが拒否されます。不要なチームから脱退すれば解決します。
  10. バージョン固定が下限を下回る問題:apt-mark hold で固定したバージョンがライフサイクルの下限を下回ると、「Update required」によりブロックされます。固定を解除してアップグレードしてください。

完了後の検証・検収 ​

ネットワークとゲートウェイ ​

  • 業務端末で curl -v https://api2.cursor.sh |& grep -C1 issuer: を実行し、証明書が Amazon RSA であることを確認する。
  • nslookup test.us9.cursorvm.com を実行して多階層ドメインの解決をテストする。スマホのテザリングに切り替えてクラウドコンピュータに接続し、証明書の警告が出ないことを検証する。

アイデンティティと SSO ​

  • 非開発者のアカウントで Grok Bot にログインし、Cursor SSO で1回で正常にログインできることを確認する。
  • Bot のブラウザで「パスワード+スマホ認証コード」により社内 SSO にログインし、FastPass による遮断ポップアップが出ないこと、業務端末のコンプライアンスポリシーは通常どおり有効であることを確認する。

プライベートネットワークと環境スクリプト ​

  • Tailscale または Cloudflare の管理コンソールで、新しいマシンが自動的にネットワークに参加し、タグが正しいことを確認する。
  • ターミナルで社内ホストに対して ping や curl を実行して疎通を検証する。Team Setup のログにタイムアウトがなく、シークレットがマスクされていることを確認する。

クライアントとセキュリティベースライン ​

  • Windows の一般ユーザーアカウントで %LOCALAPPDATA%\Programs にサイレントインストールされ、デスクトップショートカットが生成されること。
  • 「設定 > 一般 > 自動レビュー」でグローバルルールがロックされて変更できないこと。ルートディレクトリのファイル削除や未認可 Webhook の呼び出しをテストし、システムが強制的に承認ポップアップを表示することを確認する。

コンピュータのライフサイクル ​

  • 管理者がコンソールで VM の再構築を実行し、元のファイルと履歴がそのまま保持されていることを確認する。
  • 一括タスク完了後に Done をクリックし、システムが正常に次のラウンドを開始できることを確認する。

参考文献・関連リンク ​