はじめに
AIと連携できるエディタは開発業務の効率化に大きく貢献します。しかし便利さの反面、外部に出してはいけないコードや設定ファイルに含まれる機密情報（AWSのアクセスキーなど）が、意図せず外部のAIサービスへ送信されるリスクも存在します。導入にあたっては機密データの漏洩を防ぐために技術的および運用的な対策を行わなければなりません。
この記事ではAI連携機能の仕組みや具体的なリスクを整理した上で、機密情報漏洩のリスクを最小限に抑えるための考察を記述します。具体的には要求されるセキュリティの段階として以下の2種を想定し、それぞれに適した対策や設定、運用ルール、代替手段について述べます。
- AIサービスへの送信は容認されるが学習利用は禁止すべきデータ
- AIサービスへの送信を一切禁止すべきデータ
なおAIサービスへの送信も学習利用も許可されるデータは特に気にすることがないためこの記事では取り上げません。
前提： CursorのAI連携機能の仕組みと機密情報漏洩リスク
公式サイトの説明によると、Cursorエディタではコーディング支援のためにバックエンドでAIモデルを活用しており、ユーザのエディタ上の情報が随時クラウドに送信されます。例えばチャット質問への回答生成時だけでなく、オートコンプリートのためキー入力ごとにAIリクエストが送信されるなど、様々な場面でリクエストが発行されています。このリクエストには最近閲覧したファイル、会話履歴、言語サーバー情報に基づく関連コードなどがコンテキストに含まれ、Cursor社のサーバ（AWS上）経由でAIモデル提供者（OpenAI、Anthropic、Googleなど）に送信されます。オンプレミス（あるいはAWSやAzureなど）でリクエスト・レスポンスを完結させてセキュアにしようとしても、現時点でその機能は提供されていません。
このような事情により、ソースコード中に含まれるあらゆる情報が外部に送信されうることになると考えねばなりません。問題は機密情報も例外ではないということです。門外不出のアルゴリズムを書いたソースコードはもちろん、コード中や設定ファイルに書かれたAWSのクレデンシャル、個人情報なども、AIに送られてしまう可能性があります。プライバシーモードになっていれば学習に使われないはずとはいえ、AIサービスへの送信（および一時保存）されること自体が不適切なデータもあります。
さらにCursor経由で接続される各種AIサービス側でのデータの取り扱いにも注意が必要です。Cursorから先の第三者AIサービスにおけるデータ保持ポリシーはサービスごとに異なります。Cursor社はOpenAI等とデータを保持しない契約(zero data retention agreement)を結んでいるとしていますが、契約が順守されるかは提供元次第です。
AIサービスへの送信は容認されるが学習利用は禁止すべきデータの扱い
外部AIサービスへの送信は容認できるものの、AIモデルの学習データとして再利用されたくないデータについての対策について述べていきます。具体的には下記のようなデータを想定します。
もちろん機密情報は含まない前提です。
推奨される技術的対策
プライバシーモードの利用
まず基本中の基本として、Cursorエディタの設定でプライバシーモードを必ず有効化(Enabled)します。これが無効になっていると送信されたデータをCursorが学習に利用できるようになるため危険です。すでに有効化している場合は決して無効化しないよう注意します。もし無効になっていたらすぐ有効化します。Freeプラン / Proプランいずれも有効化できます。
インストールする際に設定したはずですが、どちらになっているかわからない場合はすぐ確認しましょう。
File > Preferences > Cursor Settings > GeneralにPrivacy Modeの項目があります。Enabledなら有効化されています。
.cursorignore ファイルの利用
設定ファイル等の危険な情報を含みやすいファイルは .cursorignore ファイルに明示的に指定し、AIへの送信対象から除外しておきます。例えば環境変数ファイル（.env）や秘密鍵ファイル（.pem）などは指定しておくべきです。ですがこれは完璧にカットする仕組みではないと公式ドキュメントで明言されており、過信は禁物です。
ユーザ単位で設定したい場合は Global Ignore を用います。
AIサービスの選定と設定
Cursorエディタは複数のAIモデルプロバイダを利用可能ですが、プロバイダによってデータ保持や学習データ利用ポリシーが異なる可能性があります。信頼性が高くデータ保存を行わない契約(zero data retention agreement)を明確にしているAIサービスを利用するほうがよいでしょう。
なお"オンプレあるいはAWSやAzureなどの高セキュリティなクラウドで完結させられるAIだけを使いたい"というニーズもあると思いますが、残念ながらCursorは現時点で非対応とのことです。
AIサービスへの送信を一切禁止すべきデータの扱い
漏洩時の影響が甚大なデータは上述の対策でも不十分です。外部への送信を一切許可しないよう物理的・運用上の対策を徹底する必要があります。下記のようなデータが想定されます。
このようなデータはCursorから一切アクセスできなくしなければなりません。
機密情報を決して扱わせない
APIキーやパスワードなどの機密情報は、Cursorの権限が及ばない場所にすべて隔離します。Cursorが扱える場所にあると、その内容がCursorのサーバーに送られる可能性があります。
例えば下記のような記述がある設定ファイルは不適切です。
# AWSのアクセスキー。漏洩すると権限次第で重大なインシデントに AWS_ACCESS_KEY: AKIAxxxxxxxxxxxxx
またAPIキーなどがハードコーディングされているソースコードも同様の問題を抱えます。もし下記のような記述があると、CursorはAPIでサーバーに送ってしまう可能性があります。
aws_access_key = "AKIAxxxxxxxxxxxxx"
このような記述は実際の現場でしばしば見受けられますが、だからと甘く見ることなく、厳しく判断すべきです。上記のような記述が含まれている場合はCursor（だけでなくAI連携エディタは全て）を利用してよいかよく考えるべきでしょう。Cursor公式でもセンシティブな環境での利用には慎重になるよう注意喚起がなされています。
学習対象から除外する.cursorignoreもCursorにはあるのですが、これとて完璧な除外を保証しないことが公式ドキュメントで明言されており、厳しくセキュリティを要求される場合の対策としては不徹底です。付け加えるなら、これを設定していたところでチャットにコピペミスしただけでインシデントになってしまいます。
なお機密情報を取り扱う必要がある場合はAWS SSM Parameter StoreやGitHub Actions のシークレット情報など、安全性の高い場所から都度取得する方法があります。
危険なデータの隔離方法
漏洩させてはいけないデータは、たとえ一時的であってもCursorを使っている環境に置かずに済むように構築します。機密情報をどこでも取り扱わないというわけにいきませんが、操作ミスでCursorに機密情報を貼り付けてしまうだけで漏洩の可能性が生じますから、環境そのものを厳しく分離する必要があります。ポイントはCursorが稼働する端末と機密データを扱う端末を物理的または仮想的に分離することです。
できれば機密情報を取り扱う担当者自体も限定します。もちろんその担当者はCursorの利用に慎重になるべきです。それが難しい場合はOS上でCursorを使うアカウントを分離し、そのアカウントの読み取り権限を最小限に設定します。例えばWindows11 Proの場合、管理者でないCursor専用ユーザーを作成し、ディレクトリ単位のアクセス許可を使ってCursor専用ユーザーから（当然Cursorからも）機密情報の記されたファイルを読めなくすることができます。
また可能なら機密データの危険度自体を下げる工夫も行います。たとえば下記のような対応が考えられます。
- 権限を必要最小限に絞る
- 短時間で期限切れとなる一時的な情報を都度発行する（例・AWSの一時的な認証情報）
- MFAやIP制限などの多層防御を取り入れる
その他、完璧を期待することはできないものの、.cursorignoreや Global Ignoreを使って除外しておくことも多層防御の一つとして採用する価値があります。
社内啓発
ルール作りと技術的対策だけでなく、社内啓発をセットで実施することも有効でしょう。知らないとうっかり危険な行動をとってしまいがちです。
- 機密情報を決してCursorで扱ってはいけないことを周知（チャットで送信してはいけないのはもちろん、一時的にCursorを開いて機密情報をメモするのも危険）
- 必ずAIサービスへの送信が走ることを周知する。APIを直接使う場合はオンプレやAWS/Azure等のセキュアなクラウド内部で完結させることもできるため誤解されがち
- Cursorで扱っていい情報の範囲の明示（それ以外はNG）
まとめ
開発効率の向上に大きく貢献してくれるCursorですが、セキュリティ面には注意が必要です。プロジェクトに応じた対策を徹底することで、利便性を享受しつつも安全なプロジェクト運営を行えることでしょう。
