AIコーディングツールにAPIキーを読ませない方法｜.env・deny設定・秘密情報対策

Claude Code、Codex、Gemini CLIなどのAIコーディングツールは、プロジェクト内のファイルを読み取り、検索し、必要に応じてShell Commandまで実行できます。

非常に便利ですが、プロジェクト内に、

.env
.env.local
credentials.json
service-account.json
*.pem
*.key

などがある場合は注意が必要です。

たとえば.envに、

DATABASE_URL=postgresql://...
OPENAI_API_KEY=...
STRIPE_SECRET_KEY=...
AWS_SECRET_ACCESS_KEY=...

が保存されている状態でAIコーディングエージェントへ、

このプロジェクトの設定を調べて

と依頼すると、問題解決のために環境設定ファイルを探し始める可能性があります。

ここで重要なのは、.gitignoreへ.envを書いているだけでは、すべてのAIコーディングツールから読み取りを禁止できるわけではないことです。

.gitignoreは本来、Gitが意図的に追跡しないファイルを指定する仕組みです。すでにGitで追跡されているファイルには.gitignoreを追加しても影響しません。AIツールのファイルアクセス制御とは目的が異なります。

安全性を高めるには、

Gitへ登録しない
↓
AIのコンテキストから除外する
↓
ファイル読み取りをdenyする
↓
Shellからも読めないようにする
↓
環境変数にも本番Secretを渡さない

という複数の層で対策する必要があります。

この記事では、2026年8月時点のClaude Code、OpenAI Codex、Gemini Code Assist／Gemini CLIを例に、AIコーディングツールへAPIキーや秘密情報を読ませないための設定方法を解説します。

最初に理解したいのは「.gitignoreだけではアクセス制御にならない」ということ

Node.jsプロジェクトでは、次のような.gitignoreを設定することが多いでしょう。

node_modules/
.env
.env.local
.env.production

これは非常に重要です。

しかし、.gitignoreが意味するのは、

Gitの追跡対象から除外する

ことです。

すべてのローカルプログラムから読み取り不能にする

ことではありません。

Git公式ドキュメントでも、.gitignoreは意図的に追跡しないファイルを指定する仕組みとされています。また、すでに追跡済みのファイルは.gitignoreでは除外されません。

つまり、

.envは.gitignore済み

だから、

Claude CodeもCodexもGeminiも絶対に読めない

とは限りません。

AIツール側にも別のアクセス制御を設定する必要があります。

.env.exampleと本物の.envを分ける

まずプロジェクト内には、実際のAPIキーではなく必要な変数名だけを示す.env.exampleを置く方法がおすすめです。

DATABASE_URL=
OPENAI_API_KEY=
STRIPE_SECRET_KEY=

Gitへ登録するのは、

.env.example

です。

本物の、

.env
.env.local
.env.production

は登録しません。

.gitignoreは次のようにできます。

.env
.env.*
!.env.example

secrets/
*.pem
*.key

これなら開発者やAIは、

このアプリにはOPENAI_API_KEYが必要

という構造は理解できますが、実際のSecret Valueを見る必要はありません。

AIへコード生成を依頼する場合も、本物のAPIキーではなく、

const apiKey =
  process.env.OPENAI_API_KEY;

という実装だけを見せれば十分です。

.envをAIに見せないこととアプリを動かすことは両立できる

AIコーディングツールが.envを読めないようにすると、

npm testが動かなくなるのでは？

と考えるかもしれません。

必ずしもそうではありません。

アプリケーションそのものは環境変数を利用しながら、AIエージェントには値を見せない構成にできます。

たとえば本番用の、

PROD_DATABASE_URL
STRIPE_LIVE_SECRET_KEY
AWS_SECRET_ACCESS_KEY

をAIセッションへ渡さず、テスト環境では別の、

TEST_DATABASE_URL
STRIPE_TEST_SECRET_KEY

を使用します。

AIコーディングツールへ渡すCredentialは、

本番Credential

ではなく、

開発専用
権限を限定
有効期限を短く
被害範囲を限定

したものにする考え方が重要です。

Claude Codeではpermissions.denyで.envをブロックできる

Claude Codeにはファイルアクセスを制限するPermission Ruleがあります。

2026年8月時点の公式ドキュメントでは、.claude/settings.jsonのpermissions.denyを使ってSecretや.envへのアクセスを禁止する方法が明示されています。

プロジェクト直下へ、

.claude/settings.json

を作成します。

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

これによりClaude CodeのRead Toolから対象ファイルを読み取れなくなります。

Claude CodeではPermission Ruleが、

deny
↓
ask
↓
allow

の順で評価され、Denyが優先されます。Deny Ruleはモデルへの単なる指示ではなくClaude Code側で実装されている権限制御です。

つまり、

CLAUDE.mdに「.envを読まないでください」と書く

方法より、

"deny": [
  "Read(./.env)"
]

のほうが強い制御になります。

CLAUDE.mdだけで秘密情報を守らない

次のような指示を書くこと自体は悪くありません。

# Security

.envやcredentialsファイルを読み取らないでください。
秘密情報をログへ出力しないでください。

しかしこれはモデルへのInstructionです。

モデルが何をしようとするかには影響しますが、物理的なアクセス権限ではありません。

Claude Code公式ドキュメントでも、PromptやCLAUDE.mdはモデルの行動を誘導するものであり、アクセス許可そのものを変更するにはPermission Ruleなどを使う必要があると説明されています。

秘密情報については、

読まないようお願いする

より、

読めないよう設定する

ほうを優先します。

Claude CodeではSandboxのdenyReadも使える

ここでもう一つ問題があります。

Claude Codeの、

"Read(./.env)"

を拒否していても、Shell Commandを使える環境なら、

cat .env

のような別経路を考える必要があります。

Claude CodeにはSandbox File System設定もあり、filesystem.denyReadでSandbox内のCommandから読み取れないPathを指定できます。

たとえば次のように設定できます。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": [
        "./.env",
        "./.env.local",
        "./.env.production",
        "./secrets"
      ]
    }
  }
}

これならClaudeのRead Toolだけではなく、Sandbox内で実行されるShell Commandに対しても読み取り境界を設けられます。

Claude CodeではSandboxのfilesystem.denyReadとRead PermissionのDeny Ruleが連携する仕様になっています。

.envをブロックしても環境変数からSecretが見えることがある

秘密情報対策で非常に見落としやすいのがEnvironment Variableです。

たとえば.envを完全に読めなくしていても、Claude Codeを起動したShellに、

export PROD_DATABASE_URL="..."
export GITHUB_TOKEN="..."

が設定されているとします。

その状態でAIがShell Commandを実行できるなら、

env

printenv

などを通じてEnvironment Variableへアクセスできる可能性があります。

つまり、

.envファイルを隠した

だけでは不十分です。

Agent ProcessへSecretがEnvironment Variableとして渡っているか

も確認します。

Claude Codeにはcredentials.envVarsもある

Claude Codeでは2026年時点で、Sandbox内CommandからCredential FileやEnvironment Variableを保護するsandbox.credentials機能が提供されています。

credentials.envVarsのmode: "deny"を利用すると、指定したEnvironment VariableをSandbox CommandのEnvironmentから取り除けます。Claude Code v2.1.187以降で利用できます。

たとえば本番Credentialを保護するなら、概念的には次のような設定です。

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "envVars": [
        {
          "name": "PROD_DATABASE_URL",
          "mode": "deny"
        },
        {
          "name": "STRIPE_LIVE_SECRET_KEY",
          "mode": "deny"
        },
        {
          "name": "AWS_SECRET_ACCESS_KEY",
          "mode": "deny"
        }
      ]
    }
  }
}

mode: "deny"では、Sandbox Command実行時に対象Environment Variableが取り除かれます。

Claude CodeにはCredentialを完全に消すdenyだけでなく、Sandbox内ではダミー値を見せ、許可された通信先へ送る瞬間だけ本物へ置換するmask機能も追加されています。maskモードはdenyより新しいClaude Code v2.1.199以降が必要です。さらにOSやTLS Termination、設定Scopeによる条件もあるため、単純にSecretを使わせたくない用途ならdenyのほうが理解しやすいでしょう。

Claude Codeの本番向け設定例

秘密情報をできるだけ読ませたくないプロジェクトなら、次のように複数の防御を組み合わせます。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)",
      "Read(./private-keys/**)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": [
        "./.env",
        "./.env.local",
        "./.env.production",
        "./secrets",
        "./private-keys"
      ]
    },
    "credentials": {
      "envVars": [
        {
          "name": "PROD_DATABASE_URL",
          "mode": "deny"
        },
        {
          "name": "AWS_SECRET_ACCESS_KEY",
          "mode": "deny"
        },
        {
          "name": "STRIPE_LIVE_SECRET_KEY",
          "mode": "deny"
        }
      ]
    }
  }
}

現在のClaude Codeではpermissions.denyでSensitive Fileを除外でき、Sandbox側でもFile ReadとCredential Environment Variableを制限できます。

ただし利用しているClaude Code VersionによってSandbox Credential機能の対応状況が異なるため、組織で強制する場合はClient Versionも管理します。

bypassPermissionsを使う場合は秘密情報対策が弱くならないか確認する

Claude CodeにはPermission確認を省略する強力なモードがあります。

便利ですが、

危険な操作を毎回確認するのが面倒

という理由だけでPermissionを全面的にBypassすると、せっかくのPermission設計を弱める可能性があります。

Claude CodeにはdisableBypassPermissionsModeがあり、組織ポリシーなどからBypass Permission Modeを無効化できます。

Secretを扱うRepositoryでは、

常時フルアクセス

より、

必要なPathだけ許可
Sensitive PathはDeny

という形を維持するほうが安全です。

OpenAI Codexでも.envをdenyできる

OpenAI CodexのCLI／IDE ExtensionにはFilesystem Permissionを細かく指定できるPermission Profileがあります。

現在の公式ドキュメントでは、Workspace全体を書き込み可能にしながら、

**/*.env

だけをdenyにする設定例が掲載されています。

たとえばconfig.tomlで次のように設定できます。

default_permissions = "project-edit"

[permissions.project-edit]
extends = ":workspace"

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

[permissions.project-edit.network]
enabled = false

この設定では通常のProject Fileは扱いつつ、Workspace内の.env系ファイルは読み取り禁止にできます。

CodexのFilesystem Permissionでは、

read
write
deny

を指定でき、より狭いDeny Ruleを広いRead／Write Grantの中へ設定できます。

Codexでは.env以外のCredentialもdenyする

.envだけを対象にすると漏れがあります。

たとえばRepository内に、

credentials.json
service-account.json
private.pem
certs/client.key
config/production.json

があるなら、それらも制限します。

default_permissions = "project-edit"

[permissions.project-edit]
extends = ":workspace"

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"
"**/credentials.json" = "deny"
"**/service-account.json" = "deny"
"**/*.pem" = "deny"
"**/*.key" = "deny"
"secrets" = "deny"

[permissions.project-edit.network]
enabled = false

Codex公式ドキュメントでも、Exact PathやGlobを使ってSecret FileをWorkspaceの通常Accessから切り離す方法が案内されています。

Codexではネットワークも必要以上に許可しない

Secret Fileを読めない設定にしても、AI Agentへ広範なNetwork Accessを与える必要がなければ無効化しておいたほうが安全です。

CodexのLocal CLI／IDE ExtensionはOSレベルのSandboxを使用し、標準ではNetwork AccessがOffで、Write Accessも主にActive Workspaceへ制限されています。

Networkが必要なら、

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.example.com" = "allow"

のようにDestinationを限定できます。CodexのPermission ProfileではDomain単位のAllow／Denyも設定できます。

Secret対策では、

何を読めるか

だけでなく、

読んだデータをどこへ送れるか

まで考えることが重要です。

Codex CloudではSetup用SecretとAgent実行環境が分離される

Codex Cloudでは、Setup PhaseでDependency InstallなどにSecretを利用できる一方、設定したSecretはAgent Phaseが始まる前に取り除かれる構造になっています。

これは、

npm installにはPrivate Registry Tokenが必要

だが、

実際にコードを調査・編集するAgentにはTokenを見せたくない

という用途で有効な考え方です。

ローカルAIツールでも同様に、

Setupに必要なCredential
Agentが作業中に必要なCredential

を分けると、露出範囲を小さくできます。

Gemini Code Assistでは.aiexcludeを使える

Gemini Code Assistには、特定ファイルをCode Generation、Completion、Transformation、Chat Contextなどから除外する.aiexcludeがあります。

また、標準ではWorkspace Rootの.gitignoreもContext Exclusionに利用されます。Gemini CLIについては.geminiignoreを利用できます。

たとえば.aiexcludeへ、

.env
.env.*
secrets/
*.pem
*.key
credentials.json
service-account.json

と書きます。

Google公式ドキュメントでは.aiexcludeが.gitignoreと同様のSyntaxを利用すると説明されています。

Gemini CLIでは.geminiignoreを使う

Gemini CLIでは、

.geminiignore

を作成できます。

.env
.env.*
secrets/
private/
*.pem
*.key
credentials.json

Gemini CLI公式ドキュメントでは、ディレクトリを指定する@./src/のような参照であれば、自動的なFile Discoveryの対象から.geminiignoreに一致するFileを除外します。

しかし、@.envのように単一Fileを明示的に指定した場合は.geminiignoreをバイパスし、そのFileはそのまま読み込まれます。.geminiignoreが制御するのは自動探索であり、明示的なFile参照ではありません。

つまり、

.envを.geminiignoreへ登録していても、
AIやユーザーが会話の中で@.envと入力すれば
内容が読み込まれる可能性がある

ということです。

.geminiignoreはOSレベルでFile Permissionを変更する仕組みでもありません。

そのため、

.geminiignoreを設定したので秘密情報は絶対安全

と考えず、Secret自体をWorkspaceへ置かない対策と組み合わせます。

Gemini Code Assistでは.gitignoreの扱いにも注意する

Gemini Code Assistでは、Workspace Rootの.gitignoreが標準でContext Exclusionに利用されます。

ただしGoogle公式ドキュメントでは、Subdirectoryにある.gitignoreはContext ExclusionのためにMergeされないとされています。

Monorepoで、

project/
  .gitignore
  apps/
    api/
      .gitignore
      .env

のような構成にしている場合、

apps/api/.gitignoreに.envを書いてあるから大丈夫

と決めつけないほうがよいでしょう。

AI用の除外設定はProject Rootから明示的に管理したほうが分かりやすくなります。

AI用IgnoreとGit用Ignoreは分けて考える

たとえば次の3ファイルがあります。

.gitignore
.aiexclude
.geminiignore

役割は同じように見えますが、完全に同じではありません。

.gitignoreはGit Trackingを制御します。

.aiexcludeはGemini Code AssistのContext Exclusionに使われます。

.geminiignoreはGemini CLIの対応Toolが扱うFileを除外します（ただし前述の通り明示的なFile参照はバイパスされます）。

Claude Codeでは専用Ignore Fileよりpermissions.denyが現在の公式方式です。旧ignorePatternsはDeprecatedで、Sensitive Fileを除外する場合はpermissions.denyを使うよう案内されています。

CodexではPermission ProfileのFilesystem denyを利用できます。

ツールごとにSecurity Boundaryが異なるため、一つのIgnore Fileだけを全AI Tool共通のアクセス制御として扱わないことが重要です。

本物のSecretをプロジェクト外へ置く方法も有効

さらに強く分離したい場合は、本物のCredential FileそのものをRepository Directoryの外へ移します。

たとえば、

~/projects/my-app/

の中には、

.env.example
src/
package.json

だけを置きます。

Secretは、

~/.secrets/my-app.env

など、AgentのWorkspace外へ保存します。

アプリ起動時にSecret ManagerやDeployment PlatformからEnvironment Variableとして注入します。

これならAgentがProject全体を検索しても、Secret Fileそのものが存在しません。

もちろん、AIツールにHome Directory全体へのRead権限を与えてしまえば意味が薄れるため、Workspace Boundaryも同時に設定します。

productionの.envをローカルPCに置かない

最も強い対策は、

AIへProduction Secretを読ませない

ではなく、

AIが動くPCにProduction Secret自体を置かない

ことです。

たとえばLocal Developmentでは、

localhost専用DB
Sandbox Payment Account
Read Only API Token
開発専用AWS Account

などを使用します。

Production DeploymentではCI/CDやHosting PlatformのSecret Storeから、

PROD_DATABASE_URL

を注入します。

AIコーディングToolはDevelopment Credentialしか触れない構成になります。

Credential Leak対策では、

Secretが漏れないよう慎重に扱う

だけでなく、

漏れてもProductionへ到達できないCredentialを使う

ことも重要です。

AIを起動するShellから不要なSecretを削除する

GenericなAI CLIでは、Processが親ShellのEnvironment Variableを継承する場合があります。

そのためAIを起動する前に、不要なProduction CredentialをShellから外す方法があります。

macOSやLinuxなら、たとえば、

env \
  -u PROD_DATABASE_URL \
  -u STRIPE_LIVE_SECRET_KEY \
  -u AWS_SECRET_ACCESS_KEY \
  claude

のように特定Environment Variableを除外してProcessを起動できます。

Codexなら、

env \
  -u PROD_DATABASE_URL \
  -u AWS_SECRET_ACCESS_KEY \
  codex

という考え方です。

Windows PowerShellなら、AIセッション用のShellで、

Remove-Item Env:PROD_DATABASE_URL -ErrorAction SilentlyContinue
Remove-Item Env:STRIPE_LIVE_SECRET_KEY -ErrorAction SilentlyContinue
Remove-Item Env:AWS_SECRET_ACCESS_KEY -ErrorAction SilentlyContinue

としてからツールを起動できます。

AI Tool自身の認証に必要なCredentialまで削除すると起動できなくなるため、

Agentが作業に不要なSecretだけを外す

ことがポイントです。

DockerやDev Containerで分離する方法もある

AI Coding AgentへHost OSのFile Systemを広く見せたくない場合は、専用Container内で作業させる方法があります。

Host
  ~/.ssh
  ~/.aws
  本番Credential

      ↓ 見せない

Dev Container
  source code
  test data
  test credential

という構成です。

ContainerへMountするDirectoryをProjectだけに限定し、本番Credential DirectoryをMountしません。

AIエージェントがShell Commandを実行しても、ContainerからHost側Secretへ到達しにくくなります。

Claude Code公式ドキュメントでも、Development ContainerでCloud Credentialを利用する際にはHost Credential FileのMountより、Environment VariableやCodespaces Secret、Workload Identityなどを使う方法が案内されています。

MCPサーバー経由でSecretが見える場合もある

File Accessだけを制限しても、AI Coding ToolがMCP Serverへ接続している場合があります。

たとえば、

AI Agent
↓
MCP Server
↓
AWS

という構成です。

MCP ServerのConfigに、

{
  "env": {
    "AWS_SECRET_ACCESS_KEY": "..."
  }
}

のようなSecretを直接書き、それをRepositoryへCommitすると別のLeak経路になります。

Claude Codeでは、CredentialをVersion Controlへ入れたくないMCP ServerについてLocal Scopeを使用し、設定をUser Home側へ保存する方法が案内されています。

MCPを利用する場合も、

Repository

と、

Credential Storage

を分離します。

package.jsonのScriptにAPIキーを書かない

.envだけを守っても、別の場所へSecretを書けば意味がありません。

たとえば、

{
  "scripts": {
    "deploy": "API_KEY=real-secret node deploy.js"
  }
}

ではSecretがRepositoryへ入ります。

同様に、

docker-compose.yml
.github/workflows/
Dockerfile
terraform.tfvars
npmrc
curlコマンド
README

などへCredentialを直接書かないようにします。

AIへ、

動くように設定してください

と頼むと、説明用の値をConfig Fileへ直接埋め込むコードを生成する場合があります。

Code Reviewでは、

.envだけ

ではなくRepository全体のSecret Exposureを確認します。

AIとの会話へAPIキーを貼らない

File Accessを完全に制限していても、ユーザー自身が、

このAPIキーで動かない原因を調べて

sk-xxxxxxxx

とPromptへ貼り付ければSecretはContextへ入ります。

AIへエラーを相談するときは、

Authorization: Bearer <REDACTED>

OPENAI_API_KEY=<REDACTED>

のように置換します。

AI APIへ個人情報を送る前に確認すること｜PIIマスキングをTypeScriptで実装で扱ったPII Maskingと同じ考え方で、AIへ送る前にSecretをRedactします。

AI Coding ToolのSecurityは、

AIが勝手に読む

経路だけでなく、

人間が自分で貼る

経路も考える必要があります。

.envが本当にGitから除外されているか確認する

.gitignoreを書いたら、Gitから本当に無視されているか確認します。

git check-ignore -v .env

Gitにはgit check-ignoreがあり、指定したPathがIgnore Ruleによって除外されているか確認できます。

たとえば、

.gitignore:3:.env    .env

のように表示されれば、どのRuleが適用されたか分かります。

すでに追跡されている.envには.gitignoreが効かない

ここは非常に重要です。

過去に、

git add .env
git commit

したあとで、

.env

を追加しても、そのファイルは自動的にはGit Trackingから外れません。

Git公式ドキュメントでも、すでにTrackedなFileは.gitignoreの影響を受けないとされています。

確認するなら、

git ls-files .env

を実行します。

.envが表示されるならTracking対象です。

必要であれば、

git rm --cached .env

でIndexから外したうえでIgnoreします。

ただし、すでに本物のAPIキーをCommitした場合はこれだけでは不十分です。

APIキーをCommitしたら削除だけで終わらせない

一度RepositoryやGit HistoryへSecretが入った場合、

ファイルから消した

だけでは安全になったとは限りません。

GitHubもLeakしたCredentialについて、最優先の対処はCredentialそのものを失効・Rotateすることだと案内しています。単にCodebaseから削除するだけでは不十分です。

たとえばOpenAI API Keyなら旧KeyをRevokeし、新しいKeyを発行します。

Database PasswordならPasswordを変更します。

GitHub TokenならTokenを失効します。

AWS Access Keyなら旧CredentialをDisable／Deleteして新しいCredentialへ切り替えます。

つまり、

漏れたSecretを隠す

のではなく、

漏れたSecretを使えなくする

ことが先です。

Secret Scanningも併用する

AI Coding Toolが意図せずSecretをSource Codeへ書き込むケースも考えられます。

GitHubではSecret ScanningによってRepository内のKnown Credential Patternを検出できます。Public RepositoryではSecret Scanningが自動で利用される範囲があり、組織のPrivate／Internal RepositoryではGitHub Secret Protectionの設定によって利用できます。

AI Coding Agentへ、

設定を直してください

と依頼した結果、

const token =
  "ghp_xxxxxxxxx";

のような変更が生成されても、CommitやPush時に別レイヤーで検出できる体制を作ります。

AI Tool側のDenyとRepository側のSecret Scanningは競合するものではなく、両方使うものです。

AI用のSecret対策テンプレート

一般的なNode.js Projectなら、最初に.gitignoreを設定します。

.env
.env.*
!.env.example

secrets/
private/
credentials.json
service-account.json

*.pem
*.key
*.p12
*.pfx

次に、公開可能な.env.exampleを用意します。

DATABASE_URL=
OPENAI_API_KEY=
STRIPE_SECRET_KEY=

Claude Codeなら.claude/settings.jsonへDeny Ruleを追加します。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./private/**)",
      "Read(./credentials.json)",
      "Read(./service-account.json)",
      "Read(./**/*.pem)",
      "Read(./**/*.key)"
    ]
  }
}

CodexならFilesystem Permission Profileで同等のDeny領域を作ります。

default_permissions = "project-edit"

[permissions.project-edit]
extends = ":workspace"

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"
"**/*.pem" = "deny"
"**/*.key" = "deny"
"**/credentials.json" = "deny"
"**/service-account.json" = "deny"
"secrets" = "deny"

[permissions.project-edit.network]
enabled = false

Gemini Code Assistなら.aiexclude、Gemini CLIなら.geminiignoreへ同じSensitive Pathを追加します。

deny設定が動いているか実際にテストする

Security設定は、

書いたから大丈夫

ではなく、実際に拒否されることを確認します。

テスト用に本物のSecretではない、

TEST_SECRET=THIS_IS_A_FAKE_SECRET

だけが入ったDummy Fileを作ります。

たとえば、

secret-test/.env

です。

そのPathをDeny設定へ追加したあと、AIへ、

secret-test/.envの内容を確認してください

と依頼します。

期待する結果は、

Permission denied

または、

ファイルへアクセスできない

状態です。

本物のProduction API Keyを使ってPermission Testを行う必要はありません。

deny設定だけでなく検索結果にも出ないか確認する

AI Coding Toolは明示的なFile Readだけでなく、

grep
search
index
file discovery

によってSecret Fileを見つける場合があります。

Claude Codeではpermissions.denyにMatchingするSensitive FileはFile DiscoveryやSearch Resultからも除外され、Read Operationも拒否されます。

Gemini Code Assistでは.aiexcludeや.gitignoreがCode Generation、Completion、Transformation、Chat Contextの除外に利用されます。

一方、ToolごとにIgnore機能の適用範囲が異なる製品もあるため、

直接Read
File Search
Shell
MCP
Environment Variable

の複数経路を想定して設定を確認します。

最も安全なのはAllowlist型のWorkspaceにすること

Secretを一つずつ、

.envを禁止
credentials.jsonを禁止
*.pemを禁止

と追加するDenylistには、必ず見落としの可能性があります。

たとえば来月、

production-token.txt

という新しいファイルが追加されたら、そのまま読めるかもしれません。

より強い構成は、

AIに必要なDirectoryだけをWorkspaceとして与える

方法です。

たとえば、

project/
  src/
  tests/
  package.json
  .env.example

だけをAIが扱えるWorkspaceにし、

~/.aws/
~/.ssh/
~/.config/
~/company-secrets/

などはWorkspace外へ置きます。

CodexではFilesystem Permission ProfileによってWorkspace Root以外をDenyし、必要最低限のRuntime PathだけをRead許可する構成も公式ドキュメントで紹介されています。

Secret対策は、

危険なファイルだけブロック

より、

必要なファイルだけ許可

のほうが強い設計になります。

AIコーディングツールとAPIキーに関するよくある質問

まとめ

AIコーディングツールへAPIキーを読ませないために、

.envを.gitignoreへ追加した

だけで終わらせるのは避けます。

.gitignoreはGitがTrackingしないFileを指定する仕組みであり、AI Coding Tool共通のFile Permissionではありません。すでにTrackedなFileにも自動では適用されません。

最初に、本物のSecretとSource Codeを分離します。

Repositoryには、

.env.example

だけを置き、本物の.env、Private Key、Credential FileはGitから除外します。

次にAI Coding Tool側でもAccess Controlを設定します。

Claude Codeなら、

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

を利用できます。Claude Codeでは現在、このpermissions.denyがSensitive Fileを除外する公式方式です。

さらにSandboxを利用すればfilesystem.denyReadによってShell CommandからのFile Readも制限でき、credentials.envVarsによってSandbox CommandへProduction Credentialを渡さない設定も可能です。

CodexではPermission ProfileのFilesystem denyを使い、

"**/*.env" = "deny"

のようにWorkspaceの一部を読み取り禁止にできます。

Gemini Code Assistでは.aiexclude、Gemini CLIでは.geminiignoreを利用してSensitive FileをContextから除外できますが、Gemini CLIの.geminiignoreは明示的な@ファイル名参照をバイパスすることも覚えておきます。

ただし、Ignore FileやDeny Ruleだけを最後の防御にしないことも重要です。

本番Credentialを開発PCへ置かず、AI Coding SessionにはDevelopment専用で権限を限定したCredentialだけを渡します。

最終的には、

SecretをGitへ入れない
↓
SecretをAIのWorkspaceへ置かない
↓
AIのFile Readをdenyする
↓
ShellからのReadも制限する
↓
不要なEnvironment Variableを渡さない
↓
Network Accessを必要最小限にする
↓
Secret Scanningで漏えいを検出する

という複数の層で守る構成が適しています。

AIコーディングツールの秘密情報対策で最も重要なのは、「AIにAPIキーを読まないよう頼む」のではなく、「AIがAPIキーへ到達できない実行環境を作ること」です。