「.env見るな」は通じない－AI時代のシークレット管理術
はじめに
Claude Codeをはじめとした AIコーディングエージェントが普及するなか、こんな疑問を持ったことはないでしょうか。
「
.envは読むな」とシステムプロンプトに書いてある。でも、プロンプトインジェクションで言い方を変えれば読まれる、という話を聞いた。じゃあどうやって管理すればいいの？
この記事では、その疑問に正面から答えます。結論から言えば──
「禁止命令で守ろうとする」設計自体を捨てることが解決策です。
問題の構造：なぜ「禁止」だけでは防げないのか
AIは「禁止」を意図で判断する
LLM（大規模言語モデル）は、すべての入力テキストをフラットなコンテキストとして処理します。「システム指示」と「ユーザー入力」と「外部取得コンテンツ」を区別するよう設計されていますが、表現の巧みさによってその境界が曖昧になります。
これはアーキテクチャ上の制約であり、現時点では完全に解決されていません。
実際の攻撃パターン
悪意ある外部コンテンツ
↓（WebFetch等で取得）
プロンプトコンテキストに混入
↓（インジェクションされた指示として解釈）
AIエージェントが「正常な作業」として実行
↓（cat .env など）
ログ・出力・コードに漏洩
| 攻撃手法 | 検知難易度 | 備考 |
|---|---|---|
| CSSで非表示にした指示文 | 低 | Claudeが視覚的に隠された指示に気づく |
| 「デバッグTips」として偽装 | 低 | 意図が明らかすぎる |
| コードのprint文に自然に混入 | 高 | 正常なデバッグコードに見えるため検知されない |
特に3つ目が厄介です。print(os.environ.get('API_KEY')) のようなコードは、デバッグ目的として自然に見えるため、AIが異常と判断しにくい。
対策：優先度順に整理する
優先度1（根本対策）：機密情報をAIの手の届かない場所に置く
.envファイルを「より安全な場所に隠す」のではなく、AIが動作する環境に機密情報を置かない設計が攻撃面積を大幅に縮小します。
| 手段 | 説明 | ユースケース |
|---|---|---|
| AWS Secrets Manager | クラウド上のシークレット管理サービス | 本番・ステージング環境 |
| HashiCorp Vault | オンプレ対応の統合シークレット管理。短命トークン発行可能 | VPS・自社インフラ環境 |
| GitHub Actions Secrets | CI/CDパイプライン上のシークレット管理 | パイプライン実行時のみ注入 |
| direnv + 環境変数参照 |
.envrcに実値を書かず参照パスだけ記載 |
ローカル開発環境 |
核心：.envファイル自体を撤廃し、実行時にのみシークレットが環境変数へインジェクトされる構成にする。ファイルが存在しなければ、AIがどれだけプロンプトインジェクションされても読めません。
ただし注意が必要です。シークレットマネージャーを導入しても、AIがそのアクセストークン（IAMキーなど）を読める環境なら同様のリスクがあります。「どこかに認証情報がある」構造は変わらないという点を忘れないでください。
→ 対策として：短命トークン（有効期限1時間以内）+ IPアドレス制限 + 最小権限スコープの3点セットが有効です。漏洩しても「即時無効化できる・使用範囲が限定されている」設計にすることで被害を最小化します。
優先度2（緩和策）：Claude Code固有の設定
# .claudeignore に追加（不完全だが必須の基本対策）
.env
.env.*
*.pem
*.key
*secret*
*credential*
加えて：
-
Plan Mode（
claude --plan）を活用する ── Claudeが実行前に計画を提示するモード。ファイルの読み書きを伴う操作を事前に確認できます - auto-acceptモードを無効化する ── 全アクションを手動承認することで、意図しないファイル読み取りをブロックできます
- 許可ツールを限定する ── 不要なBashコマンド実行を禁止し、攻撃の手段を減らします
なお、.claudeignoreは報告された事例では無視されたケースがあることが確認されています。あくまで補助的な対策として位置づけてください。
優先度3（アーキテクチャ対策）：AIをサンドボックス内で動かす
DockerコンテナでClaude Codeを動作させ、ホストの.envにアクセスできない環境を作る方法です。コンテナに渡す情報を必要最小限に絞ることで、プロンプトインジェクションが成功してもコンテナ外の情報には触れさせません。
「漏洩前提」の発想に切り替える
ここまで防御策を紹介しましたが、一つ重要な発想の転換があります。
「AIに読まれないようにする」ではなく
「漏洩しても大丈夫な設計にする」
機密情報は「漏洩前提」で管理する。短命・スコープ限定・即時失効可能なトークン設計が、AIエージェント時代のセキュリティ設計の基本です。
まとめ：今すぐやること
コスト低・即効性あり
-
.envを.claudeignoreに追加する（完全ではないが基本） - Claude Codeの
auto-acceptモードを絶対に使わない - AI生成コードを取り込む前に
grep -r "print\|log\|console" <生成ファイル>でシークレット出力がないか確認する
本格対応（アーキテクチャ変更）
-
シークレットマネージャーに移行し、
.envファイル自体をなくす - Dockerサンドボックス内でClaude Codeを実行し、ホスト環境の機密情報にアクセスさせない
- 短命トークン設計（1時間以内）で、漏洩しても被害を限定する
「禁止命令で守る」限界を理解したうえで、設計レベルで対処する。これがAIエージェント時代のシークレット管理の正解です。
Discussion