AIエージェントに鍵を読まれないための点検リスト13項目：確認コマンド1行ずつと実機検証の記事まとめ（Claude Code・Codex・VPS）

結論

• AIエージェント（Claude Code・Codex CLI など）に作業を任せる前後に見ておきたい場所を、1項目＝確認コマンド1つの点検リストにまとめました。これまでこのシリーズで実機確認した13本の内容を、見返しやすい形に並べ直したものです。
• 大きく分けると「エージェントに読ませない設定」「手元に平文で残る場所」「Git・npm・ビルドに入る経路」「公開したサーバー」の4つです。
• 各項目の根拠と細かい条件は、リンク先の検証記事に書いています。このリストは「どこを見るか」を思い出すためのもので、見つからなかったからといって安全の保証にはなりません。

この記事は「AIエージェントと秘密情報」の検証シリーズです。新しい検証は X（@supportapp3_lab）でもお知らせしています。

使い方

上から順に、自分の環境に関係する項目だけ実行してください。コマンドはどれも読み取りだけです。キーの値が画面に出るものには注意書きを付けています。

npx github:supportapp3-lab/ai-secret-check ... は、筆者が作った点検用CLI ai-secret-check です（Node.js 20以上、MIT）。値は表示せず、点検自体は外部通信をしません（初回の npx 取得だけ通信します）。同じことは各記事の手作業のコマンドでも確かめられます。

A. エージェントに読ませない設定

1. Claude Code の deny が書けていて、読み込まれているか

/status

• Claude Code の中で実行し、Setting sources に deny を書いた settings.json が出ているかを見ます。
• permissions.deny に Read(./.env) と Read(./.env.*) を書くのが公式の例です。settings.json は厳密なJSONで、// コメントや末尾カンマがあると読み込まれません。
• 詳しく: Claude Codeに.envを読ませない設定は settings.json の permissions.deny に書く

2. Codex CLI で .env が本当に読めなくなっているか

codex sandbox -- cat .env.local

• Permission denied になれば効いています。公式例の "**/*.env" = "deny" だけだと .env.local は読めました（筆者の環境）。
• 詳しく: Codex CLIに.envを読ませない設定

3. リポジトリに、エージェントから読めそうな .env や鍵ファイルがあるか

npx github:supportapp3-lab/ai-secret-check scan

• ファイル名とパスだけで判定し、中身は開きません。Claude Code・Codex の拒否設定の有無もあわせて表示します。
• 詳しく: AIエージェントに.envを読まれていないか、ファイル名だけで点検する日本語CLIを作った

B. 手元に平文で残る場所

4. Claude Code の会話記録にキーが残っていないか

npx github:supportapp3-lab/ai-secret-check scan-logs

• 会話記録は ~/.claude/projects/ に平文で、既定では30日残ります（公式 Data usage）。ツールが読んだ .env の値も入ります。
• 期間は settings.json の cleanupPeriodDays（最小1）で短くできます。
• 詳しく: Claude Codeの会話記録は ~/.claude/projects/ に平文で30日残る

5. シェル履歴に export したキーが残っていないか

npx github:supportapp3-lab/ai-secret-check scan-shell-history

• export OPENAI_API_KEY=... や curl -H "Authorization: Bearer ..." は ~/.bash_history に平文で残りました。先頭スペースで残らないのは HISTCONTROL に ignorespace（か ignoreboth）があるときだけです。
• これから入れるなら read -rs OPENAI_API_KEY が履歴にも画面にも出ません。
• 詳しく: APIキーを export するとシェル履歴に平文で残る

6. pip で入れたパッケージに、起動のたびに動く .pth がないか

npx github:supportapp3-lab/ai-secret-check scan-python-startup

• .pth の import 行は、import しなくても Python を起動するたびに実行され、環境変数のキーも読めました（ダミーで確認）。setuptools のような正規のパッケージにもあるので、出たら中身で判断します。
• 入れる前に見るなら python -m zipfile -l パッケージ.whl | grep .pth です。
• 詳しく: pip install しただけで、import しなくても起動のたびに動く .pth

C. Git・npm・ビルドに入る経路

7. 過去のコミットに .env が残っていないか

git log --all --full-history --oneline -- '.env*' '**/.env*'

• git rm --cached .env しても、前のコミットからは git show HEAD~1:.env で中身が出ました。何か出たら、履歴を消す前に鍵を再発行します（GitHub公式）。
• CLI なら npx github:supportapp3-lab/ai-secret-check scan-history . で、パスと件数だけ出せます。
• 詳しく: 過去にコミットした.envはgitの履歴から読める：見つけ方と git-filter-repo での消し方

8. コミットの手前で止める仕組みがあるか

ls .git/hooks/pre-commit

• gitleaks を pre-commit に入れると、トークン形式の値を含む .env は止まりました。ただし平文のパスワードだけの .env は通ったので、ファイル名のチェックも足します。git commit --no-verify ではフックが飛ばされます。
• 詳しく: AIにコミットを任せる前に：.envと鍵をpre-commitで止める

9. npm パッケージに .env や鍵が入らないか

npm pack --dry-run

• .npmignore を置くと .gitignore は使われず、.env も鍵もパッケージに入りました。files にディレクトリを丸ごと書いた場合も、その中の .env.production が入りました。
• CLI なら npx github:supportapp3-lab/ai-secret-check scan-package . です。
• 詳しく: .npmignoreを置くと.gitignoreは使われない：.envと鍵がnpmパッケージに入る

10. フロントのビルド結果に .env の値が入っていないか

npx github:supportapp3-lab/ai-secret-check scan-dist .

• Vite では VITE_ で始まる変数は dist/ の JS に平文で入ります。loadEnv(mode, process.cwd(), '') を define で丸ごと渡すと、接頭辞のない DB_PASSWORD やシェルの環境変数まで入りました。
• 詳しく: Viteの.envはVITE_を付けるとビルドに入る

D. 公開したサーバー（VPS）

11. 公開ディレクトリの .env や .git が外から取れないか

curl -s -o /dev/null -w '%{http_code}\n' https://example.com/.env

• 手元のPCから実行し、200 なら中身を取られる状態です。/.git/config も同じように見ます。Nginx で deny しても、location ^~ /static/ の配下では 200 に戻りました。
• 詳しく: Nginxで.envをdenyしても ^~ のlocation配下では取れてしまう

12. どのポートが、どのアドレスで待ち受けているか

sudo ss -tlnp

• 0.0.0.0 や [::] で待ち受けているものは外から届く可能性があります。Docker で公開したポートには UFW の受信ルールが効かない（Docker公式）ので、中と外の両方で確かめます。
• 詳しく: UFWで閉じていてもDockerの公開ポートは別扱い

13. SSH の実際に効いている設定

sudo sshd -T | grep -E '^(passwordauthentication|permitrootlogin) '

• passwordauthentication no、permitrootlogin no（か prohibit-password）になっているかを見ます。書いた覚えではなく、今効いている値を見るのがポイントです。
• 詳しく: AIで作ったアプリをVPSに載せた直後に見る10項目

見つかったときの順番

どの項目でも、キーの値が読める状態だったと分かったら、最初に鍵を再発行します。ファイルや履歴を消しても、すでに読まれた鍵は無効になりません（GitHub公式の秘密情報削除の手順でも、最初にやることとして書かれています）。そのあとで、設定を直して同じコマンドでもう一度確かめます。

まとめ

• 読ませない設定は「書いた」ではなく「効いている」を確かめる（/status、codex sandbox -- cat）。
• 平文で残る場所は、会話記録・シェル履歴・Python の起動ファイル。
• 入る経路は、Git の履歴・npm パッケージ・フロントのビルド結果。
• 公開したサーバーは、外から .env を取りに行き、待ち受けと SSH の実効値を見る。

新しい検証を足したら、このリストも更新します。

※ 各項目の検証環境と条件はリンク先の記事に書いています。ai-secret-check のコマンドは 2026-10-25 に、ダミーのファイルだけを置いた一時ディレクトリで動作を確認しました。

更新情報やちょっとしたTipsは X（@supportapp3_lab）で発信しています。