背景：AI前提の開発における新たなリスク
CursorやClaudeのようなコード生成AIを活用した開発（バイブコーディング）は、プロジェクト全体をコンテキストとして取り込む前提で設計されています。この挙動は開発効率を劇的に引き上げる一方で、環境変数の取り扱いを誤ると、意図せぬシークレット漏洩の経路になり得ます。
特に .env や env.json のようなファイルは「ローカル限定だから」とプロジェクトルートに置かれがちですが、AIのインデックス対象になることで、外部サーバーへ送信されるリスクが生じます。
「ローカルに置いてあるから安全」という従来の前提はもはや成立しません。この記事では、AI環境下で環境変数を安全に扱うための基本対策から、実務向けの強固なアーキテクチャまでを整理します。
【基本編】漏洩経路を塞ぎ、最小限の共有に留める
環境変数の基本原則は 「見せない」「持たない」「教えない」 です。
1. .cursorignore による「第一防御層」の構築
.gitignore でVCSから除外するのは当然として、AIツール向けにインデックス対象から外す設定が必須です。プロジェクトルートに .cursorignore を作成し、以下のように記述します。
# secrets
*.env
*.env.*
env.json
env.local.json
Secrets.*
ただし、これはあくまで「漏洩経路を減らす」ためのものであり、手動でチャットに貼り付けた場合や、ログ経由での流出は防げません。
2. サンプルファイルは「仕様書」として活用する
AIや他の開発メンバーに構造を伝えるため、値を除いた env.sample のみをリポジトリにコミットします。単なる空ファイルにするのではなく、用途やフォーマットのヒントを含めるのがポイントです。
# API endpoint (required)
API_ENDPOINT=https://api.example.com
# Supabase anon key (public)
SUPABASE_ANON_KEY=your_anon_key
# Stripe secret key (server only, required)
STRIPE_SECRET=sk_test_***
AIにコード生成を依頼する際も、生の .env ではなくこの env.sample を渡し、「このキーを参照して実装して」と指示することで、AIの誤生成とシークレット送信の両方を防げます。
3. CursorのPrivacy設定の正しい認識
Cursorの Privacy Mode は有効化すべきですが、これは「学習データへの利用を抑制する」ものであり、プロンプトとしての送信自体を完全に止めるものではありません。ファイル管理や実行環境の分離の方が優先度は高いと認識しておきましょう。
【運用・設計編】アーキテクチャで防御力を上げる
基本的な運用に加えて、システム構成やチーム規模に応じてセキュリティレベルを一段引き上げるための選択肢です。
1. Secret Managerへの集約（ファイルからの脱却）
ローカルファイル（.env）での管理は開発初期には便利ですが、本番運用では避けるべきです。
AWS Secrets Manager、GCP Secret Manager、Dopplerなどのシークレット管理サービスに集約し、アプリケーションは起動時にAPI経由で取得します。これにより、ローカル・CI・本番で取得フローが一元化され、IAMロール等でアクセス権限を厳密に制御できます。
2. 環境変数ファイルの暗号化管理
どうしてもファイルベースで管理したい場合の選択肢です。sops や git-crypt を使い、.env 自体を暗号化した状態でリポジトリに配置します。復号はローカル起動時やCI実行時にKMS（AWS/GCP）などを用いて行います。「ファイルが漏れても即シークレット漏洩にはならない」状態を作れます。
3. CI/CD経由での環境変数注入
GitHub Actions Secrets や GitLab CI Variables を活用し、ビルドやデプロイのタイミングで初めてシークレットを注入します。実行環境にのみ存在させることで、「開発者の手元にフルシークレットが無い状態」を実現できます。
4. ログ・例外へのシークレット混入防止（重要）
実務上、AI経由ではなく「ログからの漏洩」は非常に多いです。
- ログ出力時のマスキング（例:
****への置換） - エラーメッセージに環境変数を含めない設計
- Datadog等、APMやログ基盤側での送信内容制御・スクラブ処理
これらを徹底する必要があります。
5. 権限スコープの最小化とキーローテーション
シークレット自体の持つリスクを下げる設計も重要です。
- APIキーは用途ごとに分割し、Read/Write権限を分離する
- IP制限やドメイン制限をかける
- 漏洩を前提とし、StripeやSupabaseなどの外部APIキーは定期的にローテーション（再発行と段階的無効化）する仕組みを作る
おわりに
これら全ての対策を最初から導入する必要はありません。
-
小規模:
.cursorignore+env.sampleの徹底 - 中規模: + CIでの注入 / Secret Managerの導入
- 大規模: + ファイル暗号化 / 自動ローテーション / 厳密な権限制御
このように、プロジェクトのフェーズに合わせて段階的に適用していくのが実用的です。重要なのは「どこでシークレットが露出しうるか」をチーム全体で把握し、レイヤーごとに適切な対策を持つことです。安全な環境を構築して、快適な開発ライフを送りましょう。