Cursorセキュリティ設定ガイド｜法人導入前に確認すべき主要8つの項目

Cursorのセキュリティは、Privacy Modeをオンにするだけでは完結しません。企業で使うなら、データ利用、チーム管理、SSO/SCIM、モデルやMCPの制御、社内ルール、研修をセットで確認する必要があります。

本稿は2026年6月15日時点で、Cursor公式のSecurity、Data Use、Enterprise、Trust Centerを確認して執筆しています。機能名やプラン内容は変わるため、最終判断では公式情報と自社規程を必ず照合してください。

CursorはAIでコード作成を支援するエディタです。個人で試すだけなら便利さを優先しがちですが、法人利用では「何を入力してよいか」「誰が使えるか」「ログをどう確認するか」まで決める必要があります。

この記事は、Cursorの導入可否を検討している情シス、開発責任者、DX推進担当者向けです。情報収集だけでなく、社内説明、PoC設計、セキュリティ審査に使える確認項目として整理します。

結論：Cursorを企業で使うなら、Privacy Modeとチーム管理を前提に確認する

Cursorを企業で使うか判断する時は、まず大きな方針を決めます。安全か危険かの二択ではなく、設定と運用でリスクを下げられるかを見るのが現実的です。

まず確認すべき3点

企業利用前に最初に見るべき項目は、次の3つです。

確認項目	見ること	理由
Privacy Mode	Customer Dataが学習利用されない設定か	コードやプロンプトの扱いに直結するため
データ管理	送信、保存、一時キャッシュ、インデックスの範囲	「学習されない」と「送信されない」は別だから
チーム管理	SSO、SCIM、ユーザー削除、監査ログ、モデル制御	個人任せでは退職者管理や監査に弱いから

Cursorのセキュリティ確認では、「AIに学習されるか」だけを見ないことが重要です。 AI処理のためにどのデータがどこを通るのか、組織としてどう制御するのかまで確認します。

この記事で扱う範囲

本稿では、インストール方法や基本操作は詳しく扱いません。基本操作を知りたい場合は、Cursor入門ガイドを確認してください。

ここでは、法人導入に必要な次の観点に絞ります。

Privacy Modeとデータ利用
コードベースインデックスとメタデータ
SSO/SCIMなどのID管理
モデル、MCP、エージェント機能の制御
社内ルールとレビュー責任
導入前チェックリストと研修設計

次に、検索者が特に不安を感じやすいデータ利用から整理します。

Cursorのセキュリティで検索者が知りたいこと

Cursorのセキュリティで多い疑問は、「コードが学習に使われるのか」「入力した情報がどこへ行くのか」です。ここを曖昧にしたまま導入すると、情シスや法務の確認で止まりやすくなります。

コードやプロンプトは学習に使われるのか

Cursor公式のData Useでは、Privacy Modeを有効にした場合、Customer DataはCursorによって学習に利用されないと説明されています。また、Cursorはすべてのプロバイダーとゼロデータ保持、つまりZDR契約を維持していると記載しています。

一方で、Privacy Modeがオフの場合は、AI機能の改善やモデル学習のために、コードベースのデータ、プロンプト、エディタ上での操作、コードスニペットなどを利用・保存する場合があると説明されています。

そのため法人利用では、個人の好みに任せず、組織の標準としてPrivacy Modeを有効にする前提で検討するのが安全です。

入力したコードはどこを経由するのか

Privacy Modeを有効にしても、AIの回答を作るにはプロンプトや必要な文脈を処理する必要があります。Cursor公式は、自社APIキーを使う場合でも、リクエストはCursorのバックエンドを経由すると説明しています。

これは「危険だから使えない」という意味ではありません。重要なのは、バックエンド経由、一時キャッシュ、モデルプロバイダー、インデックス作成を分けて理解することです。

論点	確認内容
学習利用	Privacy Mode有効時にCustomer Dataが学習に使われないか
通信経路	AI処理のためにCursorバックエンドを経由するか
一時保存	キャッシュや不正利用検知の保持があり得るか
インデックス	コードのチャンク、埋め込み、メタデータがどう扱われるか

「学習されない」と「一切送信されない」は違います。この違いを社内説明に入れると、過剰な安心や過剰な不安を避けられます。

個人利用と企業利用で何が変わるのか

個人利用では、本人がリスクを受け止めれば済む場面があります。企業利用では、顧客情報、契約情報、社内機密、監査対応、退職者管理まで影響します。

そのため、FreeやProの個人設定だけでなく、BusinessやEnterpriseで使える組織管理機能を確認します。Cursor公式のEnterpriseページでは、SAMLベースのSSO、SCIMユーザープロビジョニング、モデルアクセスやMCP、エージェントルールの集中管理などが紹介されています。

ここからは、最初の要点であるPrivacy Modeを詳しく見ます。

Privacy Modeの設定と法人利用時の注意点

データ利用の全体像を押さえたら、次はPrivacy Modeです。Cursor セキュリティの確認では、この設定を導入判断の出発点にします。

Privacy Modeで変わるデータ利用

Cursor公式Securityでは、Privacy ModeはSettingsで有効にでき、チームまたは企業の管理者も有効にできると説明されています。FreeまたはProでも利用可能とされています。

Privacy Modeを有効にすると、Customer Dataは学習に使用されません。さらに、モデルプロバイダーに対して技術的な制御と契約上の要件を適用すると公式ページに記載されています。

ただし、利用規約や使用ポリシー違反を検出するため、リスク分類器が実行される場合があります。不正使用検出に引っかかった場合は、各社の保持ポリシーに従って調査のためにデータが保存され、その後削除されることがある点も確認が必要です。

オフのまま使うリスク

Privacy Modeをオフにしたまま業務コードを扱うと、コードやプロンプトがAI機能改善やモデル学習に使われる可能性があります。これは、企業の情報管理ルールと衝突しやすい状態です。

特に避けたいのは、次のような使い方です。

顧客名や案件名をそのままプロンプトに入れる
未公開の設計資料を貼り付ける
認証情報や接続情報を含むファイルを読ませる
契約上、外部サービスへ送れないコードを扱う

Privacy Modeをオンにすることは出発点です。入力してよい情報の線引きも同時に決める必要があります。

組織単位で強制すべき理由

法人利用で危ないのは、利用者ごとに設定が違う状態です。ある人はPrivacy Modeをオン、別の人はオフのまま使うと、会社として説明しにくくなります。

Cursor公式Securityでは、新しいチームメンバーはチームのPrivacy Mode設定を引き継ぐと説明されています。企業導入では、管理者側で有効化し、利用者が勝手に弱い設定へ戻せないかを確認します。

設定手順そのものよりも、次の点が重要です。

管理者が標準設定を決められるか
新規メンバーに設定が継承されるか
設定変更の責任者が決まっているか
例外利用を誰が承認するか

次は、Privacy Modeだけでは説明しきれないデータ管理の論点です。

データ管理で確認すべき項目

Privacy Modeを確認しても、データ管理は終わりません。AI処理、インデックス、一時キャッシュ、メタデータ、サブプロセッサを分けて見る必要があります。

コードベースインデックスとメタデータ

Cursorでは、コードベースのインデックス作成を選ぶと、埋め込みを計算するためにコードが小さな単位へ分割され、Cursorのサーバーへアップロードされると公式Data Useに記載されています。

公式説明では、埋め込み計算のためのプレーンテキストのコードは、リクエスト処理が完了した時点で存在しなくなるとされています。一方で、埋め込みやコードベースに関するメタデータ、たとえばハッシュ値やファイル名などは、データベースに保存される場合があります。

つまり、本文やコードそのものだけでなく、ファイル名にも注意が必要です。顧客名、未公開プロジェクト名、契約名をファイル名に含める運用は見直した方が安全です。

一時キャッシュと暗号化

Cursor公式Data Useでは、レイテンシとネットワーク使用量を減らすため、ファイル内容をサーバー上で一時的にキャッシュする場合があると説明されています。

キャッシュされたファイル内容は、クライアント側で生成された固有の鍵を使って暗号化されるとされています。また、暗号鍵はリクエスト処理中のみCursorサーバー上に存在し、キャッシュされたファイル内容は恒久的に保存されないと説明されています。

ここでも、確認すべき点は「保存されるかどうか」だけではありません。セキュリティ審査では、暗号化、保持期間、処理経路、例外時の扱いをセットで確認します。

モデルプロバイダーとサブプロセッサ

Cursor公式Securityでは、サブプロセッサ一覧をTrust Centerで公開していると説明されています。サブプロセッサとは、サービス提供のために処理を委託する外部事業者のことです。

企業のセキュリティ審査では、次の観点を確認します。

項目	確認すること
モデルプロバイダー	どのAIモデルを使える状態にするか
サブプロセッサ	どの外部事業者が関わるか
地域・法令	GDPR、CCPAなど自社要件と合うか
契約	DPA、ZDR、保持ポリシーを確認できるか

Enterpriseページでは、GDPR/CCPA、SOC 2 Type II、年次ペネトレーションテスト、AES-256の保存時暗号化、TLS 1.2以上の通信時暗号化が紹介されています。必要に応じてTrust Centerから資料を確認します。

ファイル名・プロンプトに機密情報を含めない

実務で守りやすいルールは、難しい規程より効果があります。Cursorを使うチームでは、ファイル名とプロンプトに機密情報を入れない方針を明文化します。

たとえば、次の情報は入力禁止にします。

顧客の個人情報
秘密保持契約の対象情報
アクセストークンや秘密鍵
本番DBの接続情報
未公開のM&A、採用、財務情報
セキュリティ脆弱性の未公開詳細

Cursorに限らず、AI開発ツールは文脈を与えるほど便利になります。だからこそ、文脈として渡してよい情報の境界を先に決めます。

チーム利用で見るべき管理機能

データの扱いを整理したら、次はチーム管理です。企業利用では、個人アカウントの寄せ集めではなく、組織として管理できる状態を作ります。

SSOとSCIM

SSOは、会社のID基盤でログインを統一する仕組みです。SCIMは、入社、異動、退職に合わせてユーザーやグループを自動で作成・更新・削除する仕組みです。

Cursor公式Enterpriseページでは、SAMLベースのSSOとSCIM user provisioningが紹介されています。導入前には、自社のID基盤と接続できるか、退職者の削除が自動化できるかを確認します。

SSOとSCIMを入れる理由は、ログインを楽にするためだけではありません。退職者が使い続けるリスクを下げ、監査時に「誰が使える状態だったか」を説明しやすくするためです。

ユーザーの追加・削除と退職者管理

Cursorをチームで使う場合、ユーザー追加よりも削除の運用が重要です。導入時は盛り上がってアカウントを配りますが、退職、異動、外部委託終了時の削除が漏れるとリスクになります。

最低限、次を決めます。

アカウント発行の承認者
利用対象の職種と雇用形態
退職・異動時の削除期限
外部委託メンバーの契約終了時対応
管理者権限を持てる人数

小さなPoCでも、この運用を試しておくと本展開で詰まりにくくなります。

実務では、PoC期間中に「利用者追加はできたが、外部委託メンバーの削除手順が曖昧だった」という形で課題が見つかることがあります。早い段階で削除フローまで確認しておくと、本番展開時の監査説明がしやすくなります。

モデルアクセス制御

Cursor公式Enterpriseページでは、モデルアクセスをグローバルに設定できることが紹介されています。モデルごとに性能、費用、データ処理の条件が違うため、会社として許可モデルを決めます。

モデル制御では、次のように段階を分けると実務的です。

段階	方針
PoC	許可モデルを少数に絞る
部門展開	用途別に標準モデルを決める
全社展開	例外モデルの申請手順を作る

新しい高性能モデルが出るたびに全員が自由に切り替える運用は、セキュリティ審査と費用管理の両方で不安定になります。

MCP・エージェント・ルールの制御

MCPは、AIツールが外部サービスや社内ツールと連携するための仕組みです。エージェント機能やルール設定と組み合わせると便利ですが、外部接続や自動処理を伴うため、管理対象に含めます。

Cursor公式Securityでは、MCPのセキュリティ考慮事項、LLMの安全性と制御、エージェントのセキュリティなどのドキュメントが案内されています。またEnterpriseページでは、MCP controlsやsystem-level agent rulesの集中管理が紹介されています。

導入初期は、次の方針が安全です。

MCP接続先は許可リスト方式にする
外部APIキーは個人管理にしない
自動実行は最初から広く許可しない
ルール変更はレビュー対象にする
重要リポジトリでは段階的に開放する

AIエージェント周辺機能の考え方は、Agent Skillsの解説記事も参考になります。

監査ログと利用状況の可視化

企業利用では、問題が起きた時に後から確認できることも重要です。誰が、いつ、どの設定で使ったのかを追える状態にします。

Cursor公式Securityでは、企業向け管理の関連項目としてコンプライアンスログや監査ログへのリンクが案内されています。実際に使えるログの範囲や取得方法は、契約プランと最新ドキュメントで確認してください。

監査ログでは、少なくとも次の観点を確認します。

管理者操作の履歴
ユーザー追加・削除の履歴
重要設定の変更履歴
モデルやMCP設定の変更履歴
インシデント時に調査できる範囲

次は、これらの機能を社内ルールへ落とし込みます。

社内ルールに入れるべきCursor利用ポリシー

管理機能だけでは、現場の使い方は揃いません。Cursor セキュリティを実務に落とすには、利用者が迷わない社内ルールが必要です。

入力してよい情報・禁止情報

最初に決めるべきなのは、Cursorへ入力してよい情報と禁止情報です。難しい法務文書ではなく、日々の作業で判断できる粒度にします。

区分	例	方針
入力可	公開済み仕様、社内で共有可能な一般的コード	通常利用可
要注意	未公開機能、社内設計、匿名化済みデータ	チームルールに従う
入力禁止	個人情報、秘密鍵、本番認証情報、契約秘密	入力しない

「迷ったら入れない」「必要なら匿名化する」「判断に迷う情報は責任者に確認する」の3つを利用者へ伝えます。

リポジトリ/プロジェクトの利用範囲

全リポジトリで同時に解禁するのは避けます。まずは影響の小さいプロジェクトや検証用リポジトリから始めます。

利用範囲の決め方は次の通りです。

機密度の低いリポジトリでPoCする
禁止ファイルと禁止ディレクトリを決める
本番データを含む環境では使わない
成果物レビューの基準を作る
問題がなければ対象を広げる

いきなり全社導入するより、限定した成功パターンを作る方が早く定着します。

失敗しやすいのは、便利さだけを見て本番リポジトリへ広げるケースです。成功しやすいPoCでは、対象リポジトリ、禁止ファイル、レビュー責任者、質問窓口を先に決め、利用ログとレビュー結果を週次で確認します。

AI生成コードのレビュー責任

Cursorが出したコードも、最終責任は人間にあります。AIが書いたからという理由でレビューを省略してはいけません。

レビューでは、次を確認します。

仕様に合っているか
セキュリティ上の問題がないか
既存設計を壊していないか
ライセンスや著作権の懸念がないか
テストが十分か

AI生成コードは、下書きとして扱うのが安全です。人が読み、必要なら直し、テストで確認してから取り込みます。

AIコーディングツール全般の社内ルール設計は、Claude Codeのセキュリティルール解説も参考になります。Cursorでも、禁止情報、レビュー責任、承認が必要な操作を明文化する考え方は共通です。

自動実行・コマンド実行の扱い

Cursorのエージェント機能は強力です。だからこそ、自動実行やコマンド実行は最初から広く許可しない方が安全です。

特に次の操作は、承認制または禁止から始めます。

本番環境へ影響するコマンド
外部通信を伴う操作
認証情報を読む可能性がある操作
依存パッケージの大規模更新
破壊的なファイル操作

便利さを優先して最初から自動実行を広げると、問題が起きた時に原因追跡が難しくなります。成熟度に合わせて段階的に開放します。

ログ確認とインシデント時の対応

Cursor利用で問題が起きた時の対応も、事前に決めます。たとえば、機密情報を誤って入力した場合に誰へ連絡するか、どのログを確認するか、再発防止をどう共有するかです。

インシデント時の初動は、次の順で整理します。

入力した情報の種類を確認する
影響範囲を切り分ける
管理者とセキュリティ担当へ連絡する
必要ならアカウントやキーを無効化する
記録を残し、ルールと研修へ反映する

ルールを作っただけで終わらせず、現場が実行できるように練習することが大切です。

導入前チェックリスト：情シス・開発責任者・研修担当で確認すること

ここまでの内容を、導入前チェックリストにまとめます。Cursorを法人導入する時は、情シス、開発責任者、研修担当が別々に判断せず、同じ表を見て確認します。

情シス/セキュリティ担当の確認項目

確認項目	チェック内容
Privacy Mode	組織単位で有効化できるか
SSO	自社ID基盤と接続できるか
SCIM	入退社や異動に合わせてユーザー管理できるか
サブプロセッサ	Trust Centerで確認できるか
暗号化	保存時・通信時の暗号化要件に合うか
監査ログ	管理者操作や設定変更を追えるか
データ保持	ZDR、一時キャッシュ、例外時保持を説明できるか

情シスは「利用を止める部門」ではなく、安全に使える条件を定義する部門です。最初に合意できる条件を明文化します。

開発責任者の確認項目

確認項目	チェック内容
対象リポジトリ	PoC対象と禁止対象を分けたか
レビュー責任	AI生成コードの確認者を決めたか
モデル制御	利用可能モデルを決めたか
MCP	許可する接続先を決めたか
自動実行	承認制にする操作を決めたか
品質指標	レビュー品質、バグ混入、テスト通過率を見るか

開発責任者は、速度だけでなく品質と安全性を見ます。PoCでは、開発時間の短縮だけを成功指標にしないことが重要です。

人事・研修担当の確認項目

確認項目	チェック内容
対象者	エンジニア、PM、QAなど受講範囲を決めたか
研修内容	基本操作、社内ルール、レビュー観点を含むか
禁止事項	入力禁止情報と外部接続ルールを教えるか
定着確認	受講後の利用状況や質問窓口を用意したか
非エンジニア	開発者向けと別カリキュラムにするか

研修担当は、ツールの使い方だけでなく、会社のルールを現場の行動へ変換する役割を担います。

PoCで確認するKPI

PoCでは、効率化だけでなく安全な使い方ができているかを測ります。

利用率
レビューで差し戻された件数
禁止情報入力の有無
AI生成コードのテスト通過率
ルール違反の相談件数
参加者の理解度アンケート

次は、研修で何を揃えるべきかを具体化します。

Cursor研修でセキュリティと使い方をチームに定着させる

チェックリストを作っても、使う人が理解していなければ運用は崩れます。Cursor セキュリティは、設定、ルール、教育の3つで定着させます。

個人任せの導入で起きやすい問題

個人任せでCursorを広げると、利用者ごとに使い方がばらつきます。ある人はPrivacy Modeを確認し、別の人は設定を見ないまま業務コードを貼り付けるかもしれません。

よくある問題は次の通りです。

プロンプトに顧客名や案件名を入れる
AI生成コードをレビューせず取り込む
MCP接続先を個人判断で増やす
自動実行を便利だからと広げる
退職者や外部委託の権限削除が漏れる

これらは、ツールの機能不足だけが原因ではありません。使い方をチームで揃えていないことが原因です。

研修で揃えるべき操作・ルール・レビュー観点

Cursor研修では、単に「便利な使い方」を教えるだけでは不十分です。法人利用では、次の3領域を同時に扱います。

領域	研修で扱うこと
操作	Ask、Agent、Rules、MCP、モデル切り替えの基本
ルール	入力禁止情報、Privacy Mode、外部接続、承認手順
レビュー	AI生成コードの読み方、テスト、差分確認、責任範囲

当協会のCursor研修は、2時間で基本操作から応用機能まで扱う実践型の研修です。開発チームで同じ前提を持ちたい場合、PoC前後に研修を挟むと導入が安定します。

エンジニア向け研修と非エンジニア向け活用の分け方

Cursorは主に開発者向けのツールですが、社内にはドキュメント作成や軽い自動化に関心を持つ非エンジニアもいます。ただし、開発者向けと非エンジニア向けでは、教える内容を分けた方が安全です。

エンジニア向けでは、コードレビュー、MCP、Rules、リポジトリ運用を扱います。非エンジニア向けでは、機密情報を入れない使い方、業務文書の整理、簡単な自動化の範囲に絞ります。

非エンジニア部門での活用を検討する場合は、非エンジニア向けCursor活用研修も選択肢になります。ただし、本記事の主導線は開発チーム向けのCursor研修です。

よくある質問

最後に、Cursor セキュリティで導入担当者から出やすい質問へ短く答えます。詳細は公式情報と自社の契約条件を確認してください。

Cursorで書いたコードは学習に使われますか？

Privacy Modeを有効にした場合、Cursor公式Data UseではCustomer DataがCursorによって学習に利用されないと説明されています。モデルプロバイダーについてもZDR契約を維持していると記載されています。

ただし、Privacy Modeがオフの場合は、コードやプロンプトなどがAI機能改善やモデル学習に利用・保存される場合があります。法人利用では、Privacy Modeを組織標準にする前提で確認します。

Privacy Modeをオンにすれば機密情報を入れてもよいですか？

いいえ。Privacy Modeは重要な設定ですが、機密情報を自由に入れてよい許可証ではありません。AI処理のための通信、一時キャッシュ、不正利用検知、インデックス、メタデータなどの論点があります。

顧客情報、秘密鍵、本番認証情報、契約秘密などは、Privacy Modeの有無に関係なく入力禁止にするのが安全です。

自社APIキーを使えばCursorを経由しませんか？

Cursor公式Data Useでは、自社APIキーを使う場合でも、リクエストはCursorのバックエンドを経由すると説明されています。Cursorはそのバックエンドで最終的なプロンプトを構築すると記載しています。

そのため、「自社APIキーならCursorを通らない」と説明するのは避けてください。社内説明では、経由する処理と学習利用の有無を分けて伝えます。

Business/Enterpriseでないと企業利用は難しいですか？

小さな検証なら、個人プランで試すこともあります。ただし、本格的な企業利用では、SSO、SCIM、ユーザー削除、モデル制御、MCP制御、監査ログなどの組織管理が重要になります。

個人アカウントを集めただけの状態では、退職者管理や監査対応が弱くなります。業務利用へ広げる前に、BusinessまたはEnterprise相当の管理機能を確認してください。

GitHub Copilotとのセキュリティ比較も必要ですか？

既にGitHub Copilotを使っている企業では、比較も有効です。ただし、比較では料金や補完性能だけでなく、データ利用、管理機能、監査、社内ルールへの落とし込みを見ます。

ツール選定の違いを知りたい場合は、CursorとClaude Codeの比較記事も参考になります。Copilotと比較する場合も、最後は自社のセキュリティ要件に照らして判断します。

まとめ：Cursorのセキュリティは設定・権限・教育をセットで設計する

Cursor セキュリティの確認では、Privacy Modeだけを見て終わらせないことが大切です。データ利用、チーム管理、社内ルール、研修までつなげて初めて、法人利用に耐える運用になります。

確認項目の再掲

導入前に、次の項目を確認してください。

Privacy Modeを組織標準で有効にする
「学習されない」と「送信されない」を混同しない
自社APIキー利用時もCursorバックエンド経由を前提に説明する
コードベースインデックス、メタデータ、一時キャッシュを確認する
SSO/SCIMでユーザー管理と退職者削除を整える
モデル、MCP、エージェントルールを集中管理する
入力禁止情報とレビュー責任を社内ルールに入れる
PoCで速度だけでなくルール遵守も測る

次にやること

最初の一歩は、公式情報の確認です。Security、Data Use、Enterprise、Trust Centerを読み、自社の情報管理ルールと照合します。

次に、小さなPoCを行います。対象リポジトリ、参加者、禁止情報、レビュー基準、KPIを決め、問題がない範囲から始めます。

最後に、チームで使い方を揃えます。Cursorは個人の作業を速くするだけでなく、チームの開発プロセスにも影響します。設定、権限、教育をセットで設計すれば、安全性と生産性を両立しやすくなります。