Cursorの生成コードをそのまま受け入れると、セキュリティホールや設計の歪みを見落とす可能性は否定できない。ただし、公式が提供するレビュー機能やプライバシー設定を正しく組み合わせれば、リスクの大半は開発フローの中で吸収できる。この判断は、扱うプロジェクトの性質やチームの契約プランによって変わる。
なぜCursorの出力は「動くけど危うい」のか
Vibe Codingという言葉が広がり、AIにコードを書かせる開発スタイルが一般的になった。CursorやWindsurf、GitHub Copilotといったツールの出力は、動作確認さえ通ればそのまま採用されがちだ。しかし、動くコードと安全なコードは別物である。OWASPや各種セキュリティレポートでも、AI生成コード特有のリスクパターンが繰り返し指摘されている。
複数の調査では、AIが生成したコードの4割以上に何らかのセキュリティ上の問題が含まれると報告されている。たとえば、SQLクエリやコマンド実行のコードを生成する際、入力値のバリデーションを省略するケースは珍しくない。見た目は正しく動くのに、SQLインジェクションやコマンドインジェクションの穴が残る。ユーザー入力を扱うコードは、生成後に必ずバリデーション処理の有無を確認する必要がある。
さらに、APIキーやパスワードをコード内に直接ハードコードしてしまう事例も多い。AIは環境変数やシークレットマネージャーの利用を提案しないことがあり、そのままGitHubにプッシュすれば認証情報が公開される。Vibe Codingで構築されたサービスでAPIキーが大量に漏洩したという報告も現実にある。
見落としがちな設計の歪みと依存関係の落とし穴
Cursorの提案は、目の前の関数やコンポーネント単位では筋が通っていても、プロジェクト全体の設計思想とずれることがある。たとえば、エラーハンドリングの規約、ディレクトリ構成のルール、社内ライブラリの呼び出し方といった「そのリポジトリで暗黙的に共有されている前提」をAIが学習しているとは限らない。
依存関係の提案にも注意が必要だ。AIが実在しないライブラリ名を提案することがあり、これは「パッケージ幻覚攻撃」と呼ばれるリスクにつながる。攻撃者がその名前で悪意あるパッケージを事前に登録しておけば、開発者が何気なくインストールした瞬間にサプライチェーンが汚染される。npmやPyPIで見覚えのないパッケージ名が提案されたら、公式ドキュメントやダウンロード数を確認してからインストールする習慣を徹底したい。
Cursor公式が用意するレビュー機能をどう使うか
Cursorには、ローカル変更を対象とするAgent Reviewと、プルリクエスト（PR）を対象とするBugbotという二つのレビュー機能がある。これらを「AIが書いたコードをAIにレビューさせる」という二段構えで使うと、人間の見落としを減らせる。
Agent Reviewは、変更後に「Review」から「Find Issues」を実行するだけで起動できる。さらに、Source Controlからmainブランチとの差分に対してレビューをかけることも可能だ。変更が複数ファイルにまたがる場合は、`@Branch`を使って現在のブランチ全体を文脈として渡すと、差分全体を見ながらのレビューができる。
レビュー観点は漠然と「レビューして」と頼むより、具体的に指定したほうが実用的な指摘を得やすい。たとえば、「本番で起きそうなバグ」「認証や権限の漏れ」「nullやundefinedの扱い」「失敗時のエラーハンドリング」「テスト不足」といった観点を列挙し、表面的なスタイル指摘は不要と伝える。lintで拾えるものはlintに任せ、AIにはロジックや仕様の穴を見てもらうのが効果的だ。
BugbotはPRのdiffを分析し、バグ、セキュリティ、コード品質の問題をコメントとして残す。GitHubやGitLabと連携して、PR更新時に自動で走らせることもできる。チーム開発では、ローカルのAgent ReviewよりもPR上のBugbotのほうが運用に乗せやすい。`.cursor/BUGBOT.md`にルールを記述すれば、プロジェクト固有のチェック観点を追加することも可能だ。
プライバシーモードとデータの取り扱いを理解する
Cursorのコード提案を安心して使うには、入力したコードがどのように扱われるかを把握しておく必要がある。Cursorにはプライバシーモードが用意されており、これを有効にすると、コードデータがCursorやモデルプロバイダーによる学習に使用されないことが保証される。設定はSettingsから、またはチーム管理者が一括で有効にできる。
プライバシーモードがオンの場合、ゼロデータ保持が実施され、コードは保存も学習もされない。コードベースインデクシングを使うとコードがチャンク単位でアップロードされ、埋め込みの計算やファイルメタデータの保存が行われるが、プライバシーモード有効時にはこれらのデータも保持されない。一時的なキャッシュについても、使用後に完全に削除されることが公式に確認されている。
企業プランでは、請求書払いや使用量のプール、高度なセキュリティ要件に対応する。管理者ダッシュボードから組織内のCursor使用量を確認・管理できるため、セキュリティポリシーと照らし合わせながら導入を進めやすい。詳細は[Cursorの料金プラン](https://cursor.com/ja/pricing)で確認できる。
深刻な脆弱性事例から学ぶ「自動化の裏側」
2026年には、CursorにおいてCVSS 9.9（緊急）と評価される脆弱性CVE-2026-26268が報告された。これは、AIエージェントの自律的な動作とGitの標準仕様が組み合わさることで、リモートコード実行（RCE）を引き起こすというものだ。攻撃の核心は、Git Hooksを悪用し、AIが信頼できないリポジトリをクローンした際に自動でスクリプトが実行される点にある。
この事例が示すのは、AIが自律的にコマンドを実行する状況では、開発者が「暗黙の承認」を与えたのと同じ状態になりうるというリスクだ。対策として、Cursorのバージョンを2.5以降にアップデートすること、信頼できないリポジトリのクローンを禁止すること、AIエージェントの自律的なGit操作を無効化することが挙げられる。組織内の端末でCursorのインストール状況を把握し、EDRで不審なプロセスツリー（Cursor -> git -> sh/curl/wget）を検知するルールを適用することも有効だ。
テストで押さえるべき範囲と人間の判断が要る境界
AIが生成したコードのテストは、単に期待通りの出力が得られるかどうかだけでは不十分だ。境界値テストやエッジケース、異常系のテストを重点的に追加する必要がある。特に、nullやundefinedが渡された場合の挙動、ネットワークエラー時のフォールバック、認証切れの際のリダイレクト処理などは、AIが見落としがちなポイントだ。
設計の境界で人間の判断が求められるのは、アーキテクチャの一貫性や技術的負債のトレードオフに関わる部分だ。たとえば、パフォーマンス最適化のためにキャッシュを導入するかどうか、マイクロサービス間の通信プロトコルをどう選ぶかといった判断は、プロジェクトの長期的なビジョンやチームのスキルセットを踏まえて下すべきである。Cursorの提案はあくまで「たたき台」として捉え、採用するかどうかの最終判断は開発者が責任を持つという姿勢が欠かせない。
安全に使いこなすための確認リスト
Cursorのコード提案を本番環境に取り込む前に、以下の点を確認する習慣をつけると、リスクを大幅に減らせる。
- プライバシーモードが有効かどうかをSettingsで確認する。
- 生成されたコードにハードコードされたシークレットがないか、gitleaksやtruffleHogなどのツールでスキャンする。
- ユーザー入力が絡む箇所では、バリデーションとサニタイズ処理が実装されているか目視でチェックする。
- 提案された依存パッケージが実在するか、npmやPyPIの公式レジストリでダウンロード数や更新日を確認する。
- Agent ReviewやBugbotを実行し、セキュリティとバグに焦点を絞った指摘を確認する。
- PRをマージする前に、必ず人間のレビュアーがコード全体の設計意図との整合性を判断する。
- Cursor自体のバージョンが最新かどうかを定期的に確認し、脆弱性修正が適用された状態を保つ。
Cursorのコード提案は、短いスクリプトやプロトタイプの作成では強力なアシスタントになる。しかし、認証や決済、個人情報を扱う本番システムのコードを任せる場合は、レビューとテストの工程を手厚くする必要がある。
チームで使うなら、Bugbotとプライバシーモードを組み合わせ、コードレビューの自動化とデータ保護を両立させるのが現実的な落としどころだ。個人で試す段階でも、Agent Reviewと依存関係の確認を習慣化すれば、致命的なミスを早期に摘み取れる。
コメント