Cursorにプロジェクトを開かせた瞬間、頭をよぎるのは「このコード、どこまで送られているのだろう」という疑問だ。オープンソースのライブラリなら気にならなくても、顧客情報を扱うAPIキーや、未公開のアルゴリズムが含まれる社内リポジトリでは話が違う。実際、Cursorの公式ドキュメントやプライバシーに関する開示情報を読むと、渡す範囲をコントロールする仕組みは用意されている。ただし、すべての情報を一律に守れるわけではなく、設定の組み合わせと運用ルールによって安全性の度合いが変わる。ここでは、公式のセキュリティ情報やプライバシーポリシーを基に、どのような条件でリスクが変わるのかを整理する。
プライバシーモードが守る範囲と、それでも残る通信の実態
Cursorには「プライバシーモード」と呼ばれる設定がある。設定画面から有効にすると、コードや入力内容がCursor社やモデルプロバイダーによる学習に使われないことが保証される。公式の[料金ページ](https://cursor.com/ja/pricing)にも、「プライバシーモードを有効にすると、コードデータが当社または当社のモデルプロバイダーによる学習に使用されないことを保証します」と明記されている。
しかし、これは「データが一切保存されない」こととはイコールではない。実際の動作としては、コード補完やチャット機能を使うたびに、必要なコード片が暗号化された通信経路でサーバーへ送られる。プライバシーモードがオンの場合でも、処理のために一時的なキャッシュが行われる可能性は否定されていない。あるユーザーがCursor運営に直接問い合わせた事例によると、プライバシーモード有効時にはインデックス用の埋め込みデータやメタデータも保持されない、という回答が得られたと報告されている。ただし、この回答は個別の問い合わせに対するものであり、全ユーザーに適用される契約条件ではない点に注意が必要だ。
つまり、プライバシーモードは「学習目的の保存」を防ぐが、「処理のための通信」そのものを止める機能ではない。機密性の高いコードを扱う場合は、この違いを理解しておかないと、思わぬところで情報が社外に出る可能性がある。
インデックス機能を使うなら、除外設定が必須になる理由
Cursorにはコードベース全体を解析し、チャットや補完の精度を高めるためのインデックス機能が備わっている。この機能を有効にすると、リポジトリ内のファイルが分割されて埋め込みベクトルが計算され、メタデータとともにクラウド上で処理される。公式ドキュメントでは、プライバシーモードがオンであればインデックスデータも保持されないと説明されているが、そもそもインデックス対象から外しておくに越したことはない。
具体的には、`.cursorignore` ファイルを使って、インデックスやコンテキストとして送信したくないファイルやディレクトリを指定できる。たとえば、`.env` ファイルや `credentials/` ディレクトリ、社内仕様書が置かれた `docs/internal/` などを除外する設定が考えられる。`.gitignore` と同様の記法が使えるため、既存のGit管理から外れているファイルをそのまま指定することも可能だ。
ただし、`.cursorignore` はインデックスとコンテキスト収集の対象を制御するものであり、チャットやエージェント機能で手動でファイルを開いたり、直接コードを貼り付けたりした場合の送信まではブロックしない。あくまで自動収集の範囲を絞る仕組みと捉える必要がある。
チームプランと法人契約で変わる、管理者が握る設定項目
個人のHobbyプランやProプランでは、プライバシーモードのオン・オフは利用者自身の判断に委ねられる。しかし、TeamsプランやEnterpriseプランに移行すると、管理者が組織全体の設定を強制できるようになる。
[公式の料金ページ](https://cursor.com/ja/pricing)によれば、Teamsプランでは「社内ルール、スキル、プラグインのためのチームマーケットプレイス」や「共有チームコンテキスト」が提供される一方、管理者はメンバーに対してプライバシーモードを一括で有効にできる。さらに、EnterpriseプランではSAML/OIDCによるシングルサインオンや、監査ログ、IP制限といったセキュリティ機能が追加される。
チームでCursorを導入する場合、個人の判断に任せていると、うっかりプライバシーモードをオフにしたまま機密リポジトリを開いてしまうリスクがある。管理者が設定をロックできるかどうかは、契約前に確認すべき重要なポイントだ。特に、インドネシアやベトナムのオフショア開発チームとコードを共有するケースでは、端末単位の設定漏れが情報流出の入り口になりかねない。
実際の運用で起こりがちな「うっかり」とその対策
設定を正しく行っていても、日々の開発の中で情報が漏れる場面はいくつかある。たとえば、以下のようなケースだ。
- チャット機能で「このエラーの原因を調べて」と依頼した際、スタックトレースに本番環境のURLや内部ホスト名が含まれていた。
- エージェント機能に「ログイン処理をリファクタリングして」と頼んだところ、ファイル全体が送信され、中にテスト用の固定APIキーが残っていた。
- プライバシーモードをオンにしていたが、`.cursorignore` を設定しておらず、顧客名が入ったテストデータのCSVがインデックスされていた。
これらのリスクを減らすには、コードを送信する前に「このファイルには何が書いてあるか」を意識する習慣が必要になる。具体的には、以下のような運用ルールをチームで共有するとよい。
- チャットにコードを貼り付ける前に、APIキーやシークレット情報が含まれていないかgrepする。
- エージェント機能を使う際は、作業対象のファイルを限定し、リポジトリ全体をコンテキストとして渡さない。
- `.cursorignore` のテンプレートをチームで共有し、新規プロジェクトの立ち上げ時に必ず適用する。
また、Gitのpre-commitフックを使って、`.env` ファイルや秘密鍵がコミットされるのを防ぐ仕組みを併用すれば、そもそも機密情報がリポジトリに含まれる状態を回避できる。
公開コードと社内コードで異なる、Cursorに渡してよい情報の線引き
Cursorにコードを渡す範囲を考えるとき、最初に区別すべきは「公開しても問題ないコード」と「社外に出せないコード」だ。オープンソースプロジェクトや、個人の学習用コードであれば、プライバシーモードをオフにしてインデックス機能をフル活用してもリスクは小さい。
一方、以下のような情報を含むコードは、原則としてCursorに渡すべきではない。
- 顧客の個人情報（氏名、メールアドレス、購買履歴など）
- 本番環境の接続文字列やAPIキー
- 未公開のアルゴリズムや特許出願前のロジック
- 社内のインフラ構成が推測できる設定ファイル
どうしてもAIの支援が必要な場合は、問題の箇所だけを抽象化したサンプルコードを作成し、それをチャットに貼り付ける方法が有効だ。たとえば、実際の顧客IDを `user_123` に置き換え、APIエンドポイントを `https://api.example.com` に変更した上で質問すれば、本物の情報を送信せずに済む。
結局、どのプランでどの設定にすれば安心できるのか
ここまでの内容を踏まえると、安心してCursorを使うための条件は、扱うコードの機密レベルによって変わってくる。
- 個人開発やオープンソースのみの場合: HobbyプランまたはProプランで、プライバシーモードは任意。インデックス機能をオンにしても大きな問題はないが、APIキーの誤送信には注意。
- 社内コードを扱うが、顧客情報は含まない場合: Proプランでプライバシーモードをオンにし、`.cursorignore` で社内仕様書や設定ファイルを除外する。チャットに貼り付けるコードは都度確認する。
- 顧客情報や本番環境のシークレットを含む場合: Teamsプラン以上で管理者がプライバシーモードを強制し、インデックス機能はオフにする。可能であれば、機密情報を含むリポジトリではCursorを使わず、別のエディタで作業する。
なお、Enterpriseプランでは、オンプレミス環境や専用クラウドでのホスティングが可能かどうかは、個別の契約交渉次第となる。公式情報だけでは判断できないため、導入を検討する場合は営業チームへの問い合わせが必要だ。
よくある疑問と確認ポイント
プライバシーモードをオンにすれば、コードは一切保存されないのか
保存されないのは「学習目的」のデータ保持のみです。処理のための一時的なキャッシュや、通信経路上での暗号化された送信は行われます。完全なオフライン利用は、現在のCursorのアーキテクチャでは想定されていません。
`.cursorignore` で除外したファイルは、チャットに貼り付けても送信されないのか
`.cursorignore` はインデックスと自動コンテキスト収集の対象を制御するものであり、手動で開いたファイルやチャットへの貼り付けまではブロックしません。貼り付けた内容は、そのまま処理のために送信されます。
チームで使う場合、メンバーが勝手にプライバシーモードをオフにできないか
TeamsプランやEnterpriseプランでは、管理者がプライバシーモードを一括で有効にし、メンバーによる変更を制限できます。契約前に、管理コンソールでこれらの設定が可能かどうかを確認してください。
無料のHobbyプランでもプライバシーモードは使えるのか
使えます。設定画面からプライバシーモードを有効にすれば、Hobbyプランでも学習目的のデータ保存はブロックされます。ただし、利用できるモデルやリクエスト数に制限があるため、実用的な利用にはProプラン以上が推奨されます。
Cursorが送信するデータの内容をログで確認する方法はあるか
一般ユーザー向けの機能としては提供されていません。Enterpriseプランでは監査ログが利用できる場合がありますが、詳細は契約内容によります。どうしても通信内容を検証したい場合は、プロキシサーバーを挟んでパケットを解析する方法もありますが、暗号化されているため現実的ではありません。
まずは自分のリポジトリに含まれる情報を棚卸しすることから
Cursorにコードを渡す範囲に迷ったとき、最初にすべきは設定の見直しではなく、リポジトリの中身の棚卸しだ。`.env` ファイルがGit管理から外れているか、テストデータに本物のメールアドレスが混ざっていないか、社外に出せない仕様書が同じディレクトリに置かれていないか。
これらを確認した上で、プライバシーモードのオン、`.cursorignore` の設定、そしてチームなら管理者による一括管理という三段階の対策を積み上げれば、多くのケースで安全にCursorを使い始められる。どうしても不安が残るなら、機密性の高いプロジェクトでは別のエディタを併用するという選択肢も現実的だ。
情報を渡す範囲の判断は、最終的には組織のセキュリティポリシーに従うべきものであり、Cursorの設定だけで完結する話ではない。公式のセキュリティページやプライバシーポリシーを改めて読み込み、自社のルールと照らし合わせる時間を取ることが、結局は最も確実な判断につながる。
コメント