.cursorignoreで除外しますが、ターミナルやMCPのツールからは読まれうるので、それだけに頼らないことが大切です。
お疲れ様です！IT業界で働くアライグマです！
「Cursorを業務で使いたいけど、コードが外部に送信されるのが心配…」
「セキュリティポリシーが厳しい企業環境で、どう設定すれば安全に使えるの？」
こんな悩みを抱えているエンジニアの方は多いのではないでしょうか。
AI支援型エディタのCursorは開発効率を大幅に向上させる一方で、データ送信に関するセキュリティ懸念が常に付きまといます。
本記事では、Cursorの公式ドキュメント（2026年11月時点）で確かめた内容をもとに、企業環境で押さえたい設定と運用を解説します。
Cursorのデータ送信設定を理解する
Cursorを安全に使うための第一歩は、どのようなデータがどこに送信されるのかを正確に理解することです。
漠然と不安に思うより、仕組みを知っておくほうが、適切な対策を選べます。
デフォルト設定で送信されるデータの範囲
Cursorの公式ヘルプによると、Cursor本体のAI機能（チャット・Agent・Tab補完など）を使うと、プロンプトとコードの文脈が、OpenAI・Anthropic・Googleなどのモデルの提供元に送られます。
しかも、リクエストはモデルの提供元へ直接ではなく、最終的なプロンプトを組み立てるために必ずCursorのサーバーを経由します。自分のAPIキーを使う場合も同じです。
送られる範囲は、使う機能と頼み方で変わります。
チャットやAgentに「このプロジェクト全体を見て」と頼めば、その分だけ多くのファイルの内容が文脈として送られることになります。
データ保持期間とプライバシーポリシー
送信されたデータがどう扱われるかも重要な検討事項です。
Cursorのドキュメントでは、大半のモデルはCursorとモデルの提供元のゼロデータ保持（ZDR）契約の下で動き、提供元は入力と出力を保存せず、学習にも使わないと説明されています。
ただし、例外もあります。
提供元の側でデータの保持が必要なモデルもあり、Enterpriseやプライバシーモードを有効にした組織では、そうしたモデルの利用に管理者の承認が要るとされています。
また、自分のAPIキーを使った場合はZDRが適用されず、そのAPIの提供元のプライバシーポリシーに従います。
ネットワークトラフィックの監視方法
Cursorの通信先は、公式ドキュメントのネットワーク設定のページに一覧があります。
大半のAPIリクエストはapi2.cursor.sh、Agentはapi5.cursor.sh、Tab補完はapi3.cursor.shのように、*.cursor.shなどのCursorのドメインに送られます。
会社のネットワークで通信を確かめたり許可したりするときは、OpenAIやAnthropicのドメインではなく、この一覧のCursorのドメインを対象にします。
どのホストに接続しているかは、次のようなコマンドでも確認できます。
# Cursorが接続している通信先を確かめる（macOS / Linux）
sudo lsof -i -P | grep -i cursorCursorからローカルLLMを使う方法と、Cursor本体のAI機能との違いは、CursorでローカルLLMを使う設定ガイドで詳しく解説しています。
IT女子 アラ美
ITアライグマプライバシー保護のための基本設定
Cursorの基本設定を適切に調整することで、多くのプライバシーリスクを軽減できます。
ここでは、すぐに実施できる実践的な設定項目を紹介します。
プライバシーモードをオンにする
最初に確かめたいのがプライバシーモードです。
Cursorの公式ヘルプでは、プライバシーモードをオンにすると、コードがCursorやモデルの提供元の学習に使われることはないと説明されています。
個人で使う場合は、次の手順でオンにします。
- 「Cmd + Shift + J」（Mac）または「Ctrl + Shift + J」（Windows・Linux）でCursor Settingsを開きます。
- サイドバーの「General」を押します。
- 「Privacy Mode」をオンにします。
なお、使用状況のデータ（テレメトリ）だけを個別に止める設定は、公式ドキュメントでは確認できませんでした。
「Send telemetry data」のような項目があると紹介している記事もありますが、手元のバージョンの設定画面で実際にあるかを確かめてから案内してください。
送る文脈を自分で絞る
チャットやAgentに渡す文脈は、頼み方で変わります。
「プロジェクト全体を見て」と頼むより、@で関係するファイルだけを指定して頼むほうが、送られる範囲を絞れます。
秘密情報を含むファイルを開いたまま、そのファイルについてAIに質問しないことも基本です。
特定ファイルとディレクトリの除外設定
プロジェクト内の機密情報を含むファイルやディレクトリを、Cursorのアクセスから除外することが重要です。
.cursorignoreファイルを作成することで、.gitignoreと同様の記法で除外パターンを指定できます。
# .cursorignoreの例
.env
.env.*
config/secrets.yml
private/
*.key
*.pem
credentials/公式ドキュメントによると、.cursorignoreに書いたファイルは、AgentとTab補完からアクセスされるコード、@での参照から外されます。
.env*などは既定でも除外されていますが、自分のプロジェクトの秘密情報の置き場所に合わせて追加しておきます。
ただし、注意点が2つあります。
1つは、Agentが使うターミナルやMCPサーバーのツールは、.cursorignoreで防げないことです。Agentがターミナルでcatを実行すれば、除外したファイルも読めてしまいます。
もう1つは、公式ドキュメントにも、LLMの動きは予測しきれないため完全な保護は保証されないと書かれていることです。
秘密情報は、そもそもリポジトリの中に置かず、シークレット管理の仕組みや環境変数で渡すのが一番確実です。
チームで同じ除外設定を使うには、.cursorignoreをリポジトリに含めて共有します。
パスワードなど認証情報の考え方は、NISTパスワードガイドラインの解説も参考になります。
IT女子 アラ美ITアライグマ企業環境でのセキュリティ強化設定
企業環境では、個人利用よりも厳格なセキュリティ要件が求められます。
ここでは、組織全体でCursorを安全に運用するための設定を解説します。
プライバシーモードを組織全体で強制する
公式ヘルプによると、チームではプライバシーモードが全メンバーで既定でオンになっていて、管理者はcursor.com/dashboardから組織全体に強制し、メンバーがオフにできないようにできます。
新しく入ったメンバーにも、チームのプライバシーモードの設定が引き継がれます。
個人の設定に任せず、管理者がこの強制をかけておくのが、会社で使うときの一番の基本です。
プロキシ経由での通信制御
企業ネットワークでは、プロキシサーバー経由でCursorの通信を制御することが一般的です。
Cursorのドキュメントでは、多くのプロキシ構成で動くものの、一部のプロキシ設定では応答のストリーミングに問題が出ることがあると説明されています。
ネットワークで許可が必要なドメインは、公式ドキュメントで*.cursor.sh・*.cursor-cdn.com・*.cursorapi.comなどのワイルドカードで示されています。
ワイルドカードを使えない場合の個別のホスト名（api2.cursor.shなど）や、SSLインスペクションを外すよう勧められているドメインも、同じページに一覧があります。
Cursorは既定でHTTP/2の双方向ストリーミングを使い、うまくいかないと自動でHTTP/1.1に切り替わります。
プロキシとの相性で不安定なときは、「Cursor Settings」→「Network」の「HTTP Compatibility Mode」を「HTTP/1.1」にします。
チーム共通の設定ファイル管理
組織全体で統一されたセキュリティ設定を維持するには、リポジトリに置ける設定をバージョン管理することが効果的です。
.cursorignoreや、Agentに守らせたいルール（プロジェクトのルールファイル）はリポジトリに含めて共有できます。
ただし、個人のAPIキーやアクセストークンは含めないよう注意が必要です。
機密情報は環境変数や別の仕組みに分離し、.gitignoreで除外します。
定期的なセキュリティ監査の実施
設定が適切に維持されているかを確認するため、定期的なセキュリティ監査が重要です。
四半期ごとなど時期を決めて、次の項目を確かめます。
- ダッシュボードでプライバシーモードが強制されているか
.cursorignoreが新しく増えた機密ファイルを含んでいるか- 自分のAPIキー（ZDRが適用されない）を使っているメンバーがいないか
- プロキシや許可ドメインの設定が最新の一覧と合っているか
また、Cursorのバージョンアップ時には設定項目が変わることがあるので、リリースノートと公式ドキュメントを確かめます。
IT女子 アラ美ITアライグマローカルLLMとの組み合わせでデータ流出を防ぐ
コードを外部に出したくない作業には、手元で動くローカルLLMを使う方法があります。
ただし、Cursor本体のAI機能のリクエストはCursorのサーバーを通るので、ローカルLLMを使うのは拡張機能からになります。
Ollamaとの統合設定
まず、手元のPCにOllamaを入れ、Qwen2.5-Coderなどのコーディング向けのモデルをダウンロードします。
# Ollamaのインストールと設定
curl -fsSL https://ollama.com/install.sh | sh
# コーディング用モデルのダウンロード
ollama pull qwen2.5-coder:7bCursorの設定のモデル一覧に「http://localhost:11434」を足す方法が紹介されることもありますが、Cursor本体のリクエストはCursorのサーバーから送られるため、手元のPCの中だけで動くlocalhostには届きません。
公式の手順で確認できるのは、CursorにClineなどの拡張機能を入れ、その接続先を手元のOllamaにする方法です。
具体的な手順は、CursorでローカルLLMを使う設定ガイドで解説しています。
性能とセキュリティのトレードオフ
ローカルLLMを使用する場合、性能とセキュリティのトレードオフを理解することが重要です。
手元のPCで動かせる大きさのモデルは、クラウドの大きなモデルに比べて、複雑な文脈の理解やプロジェクト全体を考えた提案が苦手なことが多くあります。
そこで、機密性の高い部分はClineとローカルLLMで、公開しても問題のないコードやテストはCursor本体のAI機能で、という使い分けが考えられます。
どこまでを外に出してよいかは、社内のセキュリティポリシーと照らし合わせて、チームで先に決めておきます。
使い分けのルールを決める
Cursorの設定で、ディレクトリごとに使うモデルを自動で切り替える仕組みは、公式ドキュメントでは確認できませんでした。
そのため、「src/core/のような機密性の高いディレクトリはClineで扱い、Cursor本体のAIには渡さない」のように、人が守るルールとして決めておき、.cursorignoreと組み合わせて運用します。
IT女子 アラ美ITアライグマ監査ログとアクセス制御の実装
企業環境では、誰がいつどのようなデータを送信したかを記録する監査ログが重要です。
ここでは、Cursorの使用状況を追跡する実践的な手法を紹介します。
通信ログの収集と分析
Cursorの通信ログを収集するには、プロキシサーバーやネットワーク監視ツールを活用します。
Squidプロキシの場合、access.logに記録される接続先とタイムスタンプから、誰がいつCursorを使っていたかを把握できます。
# SquidのログからCursorのドメインへの接続を抽出する
grep -E "cursor\.sh|cursorapi\.com" /var/log/squid/access.log > cursor_access.logHTTPSの通信は暗号化されているため、SSLインスペクションをしない限り、ログで分かるのは接続先とおおよその量までです。
Cursorのドキュメントでは、Cursorのドメインに対してはSSLインスペクションを外すよう勧めているので、中身の確認ではなく「いつ・誰が・どれくらい使ったか」を追う目的で使います。
ユーザーごとのアクセス制御
組織によっては、特定のメンバーのみがCursorのAI機能を使えるようにする必要があります。
プロキシサーバーの認証機能を使えば、Cursorのドメインへの接続を特定のグループだけに許可できます。
ただし、ネットワークで細かく止めるより、Cursorのチームの管理画面でメンバーとプライバシーモードを管理するほうが、設定の漏れが起きにくくなります。
インシデント発生時の追跡手順
万が一、機密情報が外部に送信されてしまった場合の追跡手順を事前に定めておくことが重要です。
通信ログから該当するリクエストを特定し、送信されたデータの内容を推測します。
タイムスタンプとユーザー情報から、誰がどのファイルを編集していたかを特定します。
インシデント対応の手順書には、たとえば次の流れを書いておきます。
通信ログから該当時刻の接続を確認、同じ時刻のGitの履歴とCursorのチャット履歴を確認、送信された可能性のあるファイルを特定、影響範囲の評価と対策の実施、という流れです。
手順は、実際に起きる前に一度訓練で試しておくと、本番で慌てずに済みます。
IT女子 アラ美ITアライグマセキュリティインシデント発生時の対応手順
どれだけ対策を講じても、セキュリティインシデントのリスクをゼロにすることはできません。
ここでは、インシデント発生時の具体的な対応手順を解説します。
初動対応とエスカレーション
セキュリティインシデントが疑われる場合、まず初動対応として以下を実施します。
該当メンバーのCursor使用を即座に停止し、プロキシサーバーで該当ユーザーのアクセスをブロックします。
通信ログを保全し、削除や上書きを防ぎます。
エスカレーション基準も明確にしておく必要があります。
個人情報や認証情報が送信された可能性がある場合は、即座にセキュリティ責任者とCISOに報告します。
一般的なソースコードのみの場合でも、プロジェクトマネージャーへの報告は必須です。
特に気をつけたいのは、秘密情報をチャットに直接貼り付けてしまうケースです。
.cursorignoreはファイルへのアクセスを止める仕組みなので、チャットに貼り付けた文字はそのまま送られます。
APIキーやパスワードを貼ってしまったら、送られた前提で、そのキーを無効にして作り直すのが確実です。
影響範囲の特定と評価
インシデント発生後は、影響範囲を正確に特定することが重要です。
通信ログから送信されたデータのサイズとタイムスタンプを確認し、該当時刻にどのファイルが編集されていたかをGit履歴から特定します。
Cursorのチャット履歴も確認し、どのようなプロンプトが使用されたかを把握します。
送信された可能性のあるデータの機密性を評価し、以下のカテゴリに分類します。
公開情報（影響なし）、内部情報（低リスク）、機密情報（中リスク）、個人情報・認証情報（高リスク）という分類です。
リスクレベルに応じて、後続の対応手順が変わります。
再発防止策の実装
インシデント対応の最終段階として、再発防止策を実装します。
根本原因を分析し、設定の不備、教育の不足、プロセスの欠陥のいずれに起因するかを特定します。
設定の不備が原因であれば、.cursorignoreの更新やプロキシルールの強化を実施します。
教育の不足が原因であれば、全メンバーへのセキュリティ研修を再実施します。
プロセスの欠陥が原因であれば、レビュー手順やチェックリストを改善します。
インシデントのあとは「ポストモーテム」で原因と対策をまとめ、個人を責めずに、仕組みの問題として共有します。
IT女子 アラ美ITアライグマよくある質問
Cursorのプライバシーモードをオンにすると何が変わりますか？
公式ヘルプでは、プライバシーモードをオンにすると、コードがCursorやモデルの提供元の学習に使われることはないと説明されています。
チームでは既定でオンになっていて、管理者が組織全体に強制できます。
.cursorignoreに書いたファイルは絶対に送られませんか？
AgentとTab補完、@での参照からは外されますが、Agentが使うターミナルやMCPのツールからは読まれうると公式ドキュメントに書かれています。
完全な保護は保証されないので、秘密情報はリポジトリに置かないのが確実です。
Cursorの設定にlocalhostのOllamaを登録すれば、完全にオフラインで使えますか？
使えません。Cursor本体のリクエストはCursorのサーバーを経由するので、手元のlocalhostには届きません。
手元のOllamaを使うなら、Clineなどの拡張機能から呼び出します。
IT女子 アラ美ITアライグマまとめ
Cursorのセキュリティ設定とプライバシー保護について、公式ドキュメントで確かめた内容をもとに解説しました。
Cursor本体のAI機能のリクエストはCursorのサーバーを経由してモデルの提供元に送られるので、まずプライバシーモードをオンにし、チームでは管理者が強制することが基本です。
そのうえで、.cursorignoreで秘密情報のファイルを外しますが、ターミナルやMCPからは読まれうるので、秘密情報はそもそもリポジトリに置かないようにします。
企業環境では、許可ドメインの一覧に沿ったプロキシ設定と、定期的な監査も重要になります。
コードを外に出したくない作業には、ClineなどからローカルLLMを使う方法があります。
性能とセキュリティのトレードオフを理解し、プロジェクトの要件に応じて使い分けてください。
監査ログとアクセス制御により、使用状況を追跡し、インシデント発生時に迅速に対応できる体制を整えることも忘れないでください。
セキュリティは一度設定すれば終わりではなく、継続的な改善が必要です。
本記事で紹介した手法を参考に、あなたの組織に合ったCursorのセキュリティ設定を整えてください。
IT女子 アラ美ITアライグマ
