2026年Cursor SpaceX Privacy Modeの確認手順
「Privacy Modeを有効にしたのに、コードがCursorのサーバーを通るのか分からない」という状態なら、まず設定画面と実際の通信経路を分けて確認します。
結論：学習利用だけを止めるならPrivacy Mode、自社モデルを使うならAPI keyまたは自建エンドポイント、コードをCursorのサーバーへ一切送れないなら直結対応の別ツールを選びます。 2026年8月19日時点の公式説明では、Privacy Modeを有効にした顧客データは学習に使われません。ただしAPI keyやカスタムBase URLを使っても、リクエストはCursorのバックエンドを経由します。(cursor.com)
この確認が必要なのは、2026年8月14日にCursorがSpaceXに加わり、8月12日公開のGrok 4.6がCursorで利用可能になったためです。ニュースだけでデータの扱いを判断せず、現在の設定、アカウント種別、チームポリシー、選択モデルを記録してください。(cursor.com)
最初に「学習禁止」「保存禁止」「経由禁止」を分けます
企業の驗収で最初に混同されやすいのが、次の3つです。
| 要件 | Privacy Modeで満たせる範囲 | 追加確認が必要な点 |
|---|---|---|
| コードを学習に使わせない | 公式説明ではPrivacy Modeで対応 | 現在のスイッチ、チームポリシー、モデル側の保持条件 |
| リクエストを保存させない | 通常の保存や学習を抑える説明がある | リスク分類器、非ZDRモデル、リモート機能の一時処理 |
| コードをCursorのバックエンドへ送らない | Privacy Modeでは満たせない | 直結対応のツールへ切り替える必要がある |
CursorのData Use説明では、Privacy Modeが有効な場合、Cursorによる学習利用を行わず、モデル提供者ともゼロデータ保持契約を結んでいると説明されています。一方、規約上はサービス提供、安全対策、法令対応のためにコンテンツを処理できます。危険行為の検出に反応した場合は、調査のために保存される可能性も明記されています。(cursor.com)
開始前に記録する項目
- Cursorのアプリ版と確認日時
- 個人アカウントか、チーム・企業ワークスペースか
- ワークスペース名
- 管理者ポリシーの有無
- 選択中のモデル
- Privacy Modeの表示状態
- API key、カスタムBase URL、Ollamaの利用有無
- 保護対象のデータ区分
古いスクリーンショットだけで判断するのは危険です。設定ラベルやモデル一覧は変更されるため、画面のスクリーンショットに確認日とアプリ版を添付します。
第一段階：Privacy Modeとチーム制御を照合します
公式ドキュメントの案内では、Cursor SettingsのGeneral内にPrivacy Modeがあります。macOSでは設定画面を開き、Generalの下部まで移動して、Privacy Modeまたはデータ共有に関する項目を確認します。公式のPrivacy & Securityガイドにも同じ設定経路が示されています。(docs.cursor.com)
個人アカウントなら自分で変更できる場合があります。しかし企業ワークスペースでは、管理者がPrivacy Modeを強制している、または変更をロックしていることがあります。スイッチが操作できない場合は、故障と決めつけず、チーム管理者に設定の所有者を確認してください。
Privacy Modeの驗収メモ
- Privacy Modeが有効か
- 「Share Data」などの共有状態になっていないか
- スイッチがロックされていないか
- ワークスペース名が会社の対象環境と一致しているか
- 選択モデルに非ZDRの表示や管理者承認がないか
- 画面を保存したか
Privacy Modeを無効にした場合、Cursorはコードベース情報、プロンプト、エディター操作、コード断片などを機能改善やモデル学習に利用・保存できると説明しています。したがって、SpaceXへの統合やGrok 4.6の追加を理由に推測するのではなく、現在のスイッチ状態を証跡として残すのが先です。(cursor.com)
ただし、Privacy Modeを有効にしても「Cursorのサーバーを通らない」という意味にはなりません。コードインデックス作成では、コードを小さな断片に分けてサーバーへ送り、埋め込みを計算する処理も説明されています。平文の一時処理と、メタデータや埋め込みの扱いを分けて確認します。
第二段階：Cursor API keyを認証情報として確認します
Cursor API keyを設定すると、自分のモデル提供者のアカウント、利用枠、請求先を使いやすくなります。公式のAPI Keysドキュメントでは、Cursor SettingsのModelsからAPI keyを入力し、Verifyで有効化する流れが案内されています。(docs.cursor.com)
しかし、API keyはプライバシー直結機能ではありません。Cursor公式は、API keyを使ってもリクエストがバックエンドを通り、最終的なプロンプト構築を行うと明記しています。つまり、次のように判定します。
- 禁止したいのが学習利用：Privacy Modeを確認します。
- 使うモデルと利用枠を自社管理したい：API keyを検討します。
- Cursorのサーバーへコードを送れない：API keyでは解決しません。
| 設定 | 解決しやすい問題 | 解決しない問題 |
|---|---|---|
| Cursor API key | モデル提供者の利用枠、請求、認証の分離 | Cursorバックエンドの経由 |
| Override OpenAI Base URL | 送信先モデルや自社推論基盤の指定 | Cursor側での最終プロンプト構築 |
| Privacy Mode | Cursorによる学習利用の停止、通常の保持抑制 | Cursorサーバーを使わない完全直結 |
.cursorignore |
特定ファイルをAIリクエストから除外する方針 | 機密コード全体の送信経路排除 |
API keyの驗収では、次の3点を別々に記録します。
- どの提供者のキーか。
- テストリクエストがどのアカウントの利用量へ計上されたか。
- Cursorのバックエンドを経由することを承知した上で許可できるか。
AgentやTabなど、一部の機能はカスタムAPI keyの対象外になることがあります。公式API keyドキュメントも、標準チャットモデル以外の機能は内蔵モデルを使い続ける場合があると説明しています。メインのチャットが成功しただけで、すべての機能が自社キーへ切り替わったとは判断できません。(docs.cursor.com)
第三段階：Ollamaと自建エンドポイントの限界を確認します
OllamaをMac上で動かす場合、一般的にはlocalhostや社内LANのアドレスでモデルを公開します。しかしCursorは最終プロンプトをバックエンドで構築する設計を明示しているため、Cursorアプリから見えるlocalhostを、そのままCursorのバックエンドが見られるとは限りません。
これは公式説明から導ける構造上の判断です。Cursorのバックエンドから到達できない本機専用アドレスは、リモートサービスの送信先になりません。コミュニティでも、カスタムBase URLを設定しても通信がCursor側から直接見えない、またプライベートネットワークへの接続が拒否されたという報告があります。ただし、これは個別環境の報告であり、全契約や全バージョンに共通する公式保証とは分けて扱います。(forum.cursor.com)
自建推論を使う場合の確認点は次の順番です。
- Cursor Settingsを開き、Modelsへ移動します。
- 使用する提供者のAPI keyを設定します。
- カスタムモデル名を指定します。
- 表示されるBase URL上書き項目を確認します。
- Cursorのバックエンドから到達可能な認証付きHTTPSエンドポイントを用意します。
- サーバー側でアクセス制御、ログ保存期間、キーの失効手順を設定します。
- チャット、Agent、子タスクを別々に確認します。
一時的なトンネルを公開エンドポイントとして使う場合は、認証、許可元IP、レート制限、監査ログが必要です。URLを知っているだけで推論APIを呼べる状態は、社内コードの運用環境には適しません。
Mac上のOllamaを完全ローカルで使いたい場合は、Cursorを接続先として無理に残すより、ローカルモデルへ直接接続できる編集環境や代理ツールへ分離する方が要件に合います。Ollamaを使うことと、Cursorを経由しないことは同じではありません。
第四段階：探針リクエストで経路を確定します
設定画面にモデル名が表示されても、実際の送信先が確認できたとは限りません。業務コードを使わず、次のような探針を用意します。
これは経路確認用の探針です。
機密情報は含めず、応答の先頭に TEST_ROUTE_OK とだけ返してください。
自建エンドポイント側では、少なくとも次の情報を記録します。
- 受信日時
- モデル名
- HTTP応答状態
- リクエスト識別子
- 認証キーの識別用プレフィックス
- 送信元のネットワーク情報
- プロンプトの保存可否
- 応答本文の保存可否
次に、普通のチャットだけでなくAgentや子タスクを実行します。Cursorの機能ごとに内蔵モデル、専用サービス、カスタムモデルの扱いが異なる可能性があるためです。
合格条件
- 自建サーバーに探針リクエストの記録がある
- 記録時刻がCursor側の操作時刻と一致する
- モデル名が設定した名前と一致する
- 応答状態が成功している
- 普通のチャットとAgentの両方で確認できる
- Cursor側で別モデルへの回落が起きていない
- Request IDとサーバーログを同じ驗収記録へ保存している
ログがない場合、次のどれかを疑います。
- Base URLが保存されていない
- モデル名の形式が提供側と一致していない
- Cursorのバックエンドからエンドポイントへ到達できない
- 対象機能がカスタムAPI keyに対応していない
- レート制限や認証失敗で別経路へ回落している
画面上で「接続済み」と表示されても、ログが一致しなければ未驗収です。エラー時はRequest ID、HTTP状態、表示されたエラー文を保存します。コミュニティの故障報告でも、API keyのレート制限、モデル名の不一致、Agentによる短時間の複数リクエストが問題になる例が報告されています。(forum.cursor.com)
5分で残せる驗収チェックリスト
- [ ] Cursorのアプリ版、OS、確認日時を記録した
- [ ] 個人アカウントかチームワークスペースかを確認した
- [ ] General内のPrivacy Modeを開き、状態を撮影した
- [ ] スイッチが管理者によりロックされていないか確認した
- [ ] 選択モデルのZDR表示または管理者承認を確認した
- [ ] API keyの提供者と利用量の記録先を確認した
- [ ] Cursor API keyを使ってもバックエンド経由であることを承認記録に書いた
- [ ] Ollamaのlocalhostを完全な直結経路と誤認していない
- [ ] 自建エンドポイントに認証とアクセス制御を設定した
- [ ] 業務コードを含まない探針リクエストを送った
- [ ] 自建側で時刻、モデル、応答状態、送信元を確認した
- [ ] チャットとAgentを別々に実行した
- [ ] Request IDとサーバーログを保存した
- [ ] 失敗時の回落、モデル不一致、ログ欠落を確認した
チームで共有する場合は、スクリーンショットだけでなく、判定結果を「学習禁止」「推論先指定」「Cursor経由禁止」の3列で残します。これにより、Privacy Modeが有効だから完全ローカルだという誤判定を防げます。
失敗後の選択：Cursor継続、接続分離、環境変更
要件別の結論は明確です。
- 学習利用だけを止めたい：Privacy Modeとチームポリシーを修正し、通常のCursor運用を継続します。
- 推論モデルを自社管理したい：API keyや管理下のHTTPSエンドポイントを使います。ただしCursorバックエンド経由を受け入れます。
- コードをCursorのサーバーへ送れない：API keyの追加では解決しません。ローカル直結に対応した編集環境へ切り替えます。
- Ollamaを常時稼働させたいが本機の電源、隔離、運用時間が足りない：リモートMac上で自托管モデルを運用し、アクセス制御とログ保存を設計します。
自宅Macだけで運用する場合、電源断、外部公開、家庭内ネットワークへの依存が残ります。クラウドGPUへ移す場合は、データ所在地、共有テナント、管理者権限、ディスク消去を確認する必要があります。リモートMacは、Mac環境を維持しながら専用の作業環境を分離できる一方、Cursorを組み合わせる限りバックエンド経由の問題は残ります。
ProxyMacのコンソールを使う場合も、先にモデル、同時実行数、データ境界、必要な稼働時間を整理します。料金や利用期間を比較する段階では、日本向けの料金案内だけでなく、機密データをどの層まで外へ出せるかを基準にしてください。
現在の方法とMac環境の比較
現在の方法が「手元のMacでOllamaを動かし、Cursorから接続する」構成なら、主な弱点は3つあります。第一に、Cursorのバックエンド経由を避けられません。第二に、本機の稼働時間とネットワーク公開に依存します。第三に、ログ、認証、隔離を個別に設計する必要があります。
一方、ProxyMacのリモートMacを使う構成では、開発環境を本機から分離し、モデルの常時稼働や管理用アクセスをまとめやすくなります。ただし、完全ローカル直結が絶対条件ならCursorとの組み合わせは適しません。自托管モデルを継続運用したいが本機の電源や隔離条件が不足している場合に、ProxyMacのヘルプで要件を確認し、モデル名、同時実行数、データ境界を添えて環境を選ぶのが現実的です。
