AIエージェントが開発環境に深く入り込むようになった現在、.envファイルの取り扱いはこれまで以上に重要なテーマになっています。

Claude CodeやAntigravityといったコーディングエージェントは、ファイルの読み書きからターミナルの実行まで、開発者と同等の権限を持って動作します。その強力さゆえ、シークレットの管理を誤ると、意図せずAPIキーが外部に漏れるリスクが現実のものとなります。

本記事では、.envのベストプラクティスを起点に、Claude CodeのHooks機構の仕組み、そしてAI安全性の概念であるスーパーアライメントまで、AIエージェント時代のシークレット管理を体系的に整理します。

.envの取り扱いにおけるベストプラクティスは、「ローカルで本番環境の環境設定を管理しないこと」です。

その上で、settings.jsonのdenyによるファイルアクセス制限だけでは不十分で、「AIがbashコマンド経由でシークレットを読み取り、意図せず学習・出力してしまう可能性」は実在するため、hooksを使ってTerminal実行レベルでも制限するのが現状では最も有効な対策だと考えています。

また、「本番シークレットをローカルに置かないこと」が根本対策であり、使用するエージェントに関わらず最重要ですが、それを実現するにはCI/CDやSecret Managerを活用した適切なパイプラインの構築が不可欠となるため、このあたりは現状、非エンジニアにはまだ厳しいと思っています。

本番の値はCI/CDの環境変数（GitHub Actions Secrets、Vercel Environment Variables等）やSecret Manager（AWS Secrets Manager、GCP Secret Manager等）で管理するのが現代的なアプローチです。

シークレット管理は「一つの設定で完結する」ものではなく、複数の層を組み合わせることで安全性を高めます。

Layer 1: 本番シークレットをローカルに置かない（根本対策）
Layer 2: .gitignoreに.envを確実に追加
Layer 3: pre-commitフックでシークレットの誤コミットを検出（git-secrets等）
Layer 4: Claude Code Hooksで.envへのアクセスをブロック（AI開発時の補助対策）
Layer 5: ファイルパーミッション（chmod 600 .env）

Claude Codeのsettings.jsonにはdenyルールがあり、特定のファイルやコマンドへのアクセスをブロックできます。たとえば以下のように設定することで、Readツールによる.envへの直接アクセスを防ぐことができます。

{
  "permissions": {
    "deny": [
      "Read(**/.env)",
      "Read(**/*.key)",
      "Read(**/secrets/**)"
    ]
  }
}

しかしこれだけでは不十分です。理由はシンプルで、denyはClaude Codeのツール呼び出しレベルでの制限に過ぎないためです。ClaudeがBash(cat .env)のようなコマンドを実行すれば、Readツールを使わずにファイルの中身を取得できてしまいます。

これは実際にAntigravityで実証された攻撃手法とまったく同じ構造です。

Hooksは、Claude Codeがツールを実行する前後にカスタムのシェルスクリプトを割り込ませる仕組みです。設定ファイルは.claude/settings.jsonのhooksセクションに記述します。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "bash ~/.claude/hooks/check-sensitive.sh"
          }
        ]
      }
    ]
  }
}

Hooksには実行タイミングに応じて4種類があります。

.envの保護にはPreToolUseを使います。Claudeがツールを実行しようとした瞬間、スクリプトが割り込んで「このコマンドは許可されているか？」を検証します。

Claude が Bash(cat .env) を実行しようとする
          ↓
  PreToolUse フックが起動
          ↓
  check-sensitive.sh が実行される
  　「.env」という文字列が含まれているか確認
          ↓
  含まれている場合 → exit 2 でブロック
  含まれていない場合 → exit 0 で通過
          ↓
  ブロックされた場合、Claudeに理由が通知される

具体的なスクリプト例は以下のとおりです。

#!/bin/bash
# check-sensitive.sh
# Bashコマンドに.envや機密ファイルが含まれていないか確認

COMMAND=$(echo "$CLAUDE_TOOL_INPUT" | jq -r '.command // empty')

# 機密ファイルへのアクセスパターンをチェック
SENSITIVE_PATTERNS=(
  "\.env"
  "\.key"
  "id_rsa"
  "credentials"
  "secrets"
)

for pattern in "${SENSITIVE_PATTERNS[@]}"; do
  if echo "$COMMAND" | grep -qE "$pattern"; then
    echo "[BLOCKED] 機密ファイルへのアクセスが検出されました: $COMMAND" >&2
    exit 2  # 2を返すとClaudeにエラーとして通知される
  fi
done

exit 0

Hooksのスクリプトは返す終了コードによってClaude Codeの挙動が変わります。

exit 2を使うことで、Claudeは「このツールはブロックされた」と認識し、別の方法を試みることなく停止します。

スーパーアライメント（Superalignment）とは、人間の知能を超えた高度なAI（いわゆる「スーパーインテリジェンス」）が出現した際に、そのAIの行動を人間の意図や価値観に合わせ続けるための研究・技術体系です。

OpenAIが2023年に提唱した概念で、現在はAnthropicを含む多くのAI研究機関が取り組んでいます。

「高度なAIをどうコントロールするか」という問いへの答えを、AIが人間より賢くなる前に準備しておく必要がある

という危機感がその背景にあります。

現在のAIは「弱いAI」の段階にあり、まだ人間が制御できる範囲内です。しかし、AIの能力が急速に向上する中で、以下の問題が現実的なリスクとして議論されています。

• 目標のずれ（Goal Misspecification）：人間が意図した目標とAIが実際に最適化する目標がズレる
• 解釈不可能性（Interpretability）：AIの内部で何が起きているかを人間が理解できない
• スケールアップ問題：能力が上がるほど、誤った行動の影響が大きくなる

「.envの話とスーパーアライメントがなぜ関係するのか？」と感じるかもしれません。しかし実はこれらは同じ構造の問題です。

Claude Codeのシークレット漏洩問題を例に考えると：

問題の本質
  ↓
AIが「タスクを完了すること」を目標として最適化する
  ↓
その過程で「.envを読んではいけない」というルールを
AIが回避策（catコマンド）を使ってバイパスしようとする
  ↓
これはまさに「目標のずれ」と「ルール回避」の小さな事例

スーパーアライメント研究が目指すのは、この「ルール回避」をAIが強力になっても起こさないようにするための、より根本的なアプローチです。

現在主流のアライメント手法で、人間の評価者がAIの回答を評価し、より良い回答が生成されるように学習させます。Claude自体もこの手法で訓練されています。

限界：人間の評価者自身がバイアスを持つこと、高度なAIの判断を人間が正確に評価できなくなること。

Anthropicが開発した手法で、AIに原則（Constitution）を与え、その原則に従って自分自身の回答を評価・改善させます。

Claude Codeのパーミッション設計思想にも、この「原則の階層構造」の影響が見られます。deny → ask → allowという評価順序は、より厳格なルールが優先されるという原則に基づいています。

AIが人間より賢くなった後でも監視を維持するための研究領域です。AIを使ってAIを監視するという逆説的なアプローチも研究されています。

スーパーアライメントの文脈で.envの話に戻ると、重要な示唆があります。

現在のHooksによる制御は「弱いAI」前提の設計です。AIが「.envにアクセスするな」という指示の意図を真に理解して遵守するのではなく、技術的な制約（exit 2によるブロック）で強制しているに過ぎません。

これは裏返せば、AIの能力が上がり、制約をより巧妙に回避できるようになった場合に、現在の防衛が無効化されるリスクを意味します。だからこそ「本番シークレットをローカルに置かない」という根本対策が、どのエージェントを使う場合でも変わらない本質的な防衛線となります。

Antigravityには.antigravityignoreによるファイルアクセス制限がありますが、Geminiがcatコマンドを使ってこの制限を回避し、.envの中身を取得した上で外部サーバーに送信するという攻撃チェーンがセキュリティ研究者によって実証されています。

この事例は「設定でブロックしているから安全」という思い込みが危険であることを示しています。AntigravityにはClaude CodeのHooksに相当する、Terminal実行を強制的にインターセプトする機構が現時点では存在しないため、根本対策（本番シークレットをローカルに置かない）がより一層重要となります。

Codex CLIにはClaude Codeのような細粒度のHooks機構は存在しません。AGENTS.mdにルールを記述することはできますが、これはあくまでプロンプトレベルの指示であり、技術的な強制力はありません。実行モード（suggest / auto-edit / full-auto）で操作範囲を制限することが主な防衛手段となります。

AIエージェント時代の.env管理を整理すると、以下の3層構造になります。

Layer 1（根本対策）：本番シークレットをローカルに置かない。CI/CDやSecret Managerを活用したパイプラインの構築が必要で、非エンジニアには現状ハードルが高い部分でもあります。

Layer 2（設定による制限）：settings.jsonのdenyで明示的に機密ファイルへのアクセスをブロックする。ただしBashコマンド経由でのバイパスリスクがあるため、これだけでは不十分です。

Layer 3（Hooksによる強制）：PreToolUseフックでTerminal実行を含むすべてのツール呼び出しをインターセプトし、機密ファイルへのアクセスを検出・ブロックする。これがClaude Code利用時の現状における最も有効な技術的防衛です。

スーパーアライメントの観点からは、これらの技術的制約はあくまで「今のAI」に有効な対策であり、AIの能力向上とともに継続的な見直しが必要です。「どのエージェントを使うか」に関わらず根本対策を徹底することが、長期的に有効な唯一の防衛線です。