Article

Claude Codeに秘密情報を渡さないための実践ルール：APIキー・個人情報の3層防御

Claude CodeにAPIキーや個人情報を渡さないための実践ルールを、Read deny rule・サンドボックス・gitleaksなどの3層防御で整理します。`.env`／OS資格情報ストア／クラウドCLIの扱い、誤コミット時の鍵ローテ手順、ログ出力時の注意まで、公式ドキュメントを根拠にまとめます。

This article is not published in this language yet, so the Japanese version is shown instead.

結論：秘密情報は「渡さない・読ませない・残さない」の3層で守る

Claude Codeはあなたが読ませたファイルの内容を、Anthropicのモデルへ送ります。だから秘密情報の扱いの基本は単純で、そもそも読ませないことです。漏えい経路は大きく次の3つに分けられます。

「渡してしまう」経路：.envを直接読む、貼り付ける、依頼文に書き込む
「読まれてしまう」経路：Bashでcat .env、env、echo $TOKENが走る
「残してしまう」経路：ログ・チェックポイント・git履歴に残ってしまう

公式のSecurityページも、APIキーは暗号化された資格情報ストアに保存することを前提に設計されており、「人間がAIに直接見せる」のは想定外の運用だと読み取れます。

本記事では、3つの経路それぞれに対する多重防御を、コピペ可能な設定とチェックリスト形式で整理します。包括的なチェックリストはClaude Codeを使うときのセキュリティチェックリスト、Git運用はClaude Codeで安全にコミットとPRを作るワークフロー、Claude Code自身の認証経路はClaude Codeの認証方法とログインできないときの確認ポイントを参照してください。

渡してはいけない情報の一覧

まず「Claudeのコンテキストに入れてはいけないもの」を共通言語にします。

情報の種類	例	リスク
API鍵・トークン	OpenAI、AWS、Stripe、GitHub PAT	直接叩かれる／クレジット消費
クラウド資格情報	`~/.aws/credentials`、`~/.config/gcloud/`	アカウント乗っ取り
SSH秘密鍵	`~/.ssh/id_rsa`、`id_ed25519`	サーバー侵入
OAuthリフレッシュトークン	`.credentials.json`の中身	長期なりすまし
個人情報	顧客の氏名・メール・電話・住所	個人情報保護法・GDPR違反
業務上の機密	M&A情報、未公開の財務データ	内部情報漏えい
暗号資産の鍵	seed phrase、mnemonic	資産流出

これらは依頼文に貼らない・ファイルとして読ませない・出力に含めさせないの3点を徹底します。Claudeは便利な翻訳・分析役ですが、「人間にしか見せたくない情報を見せる相手」ではないという割り切りが基本です。

第1層：渡さない（依頼文・コピペ）

チェック項目

スタックトレースにシークレットが含まれていないか確認してから貼る
エラーログを貼る前にAPI鍵・トークン・メアド・電話番号を伏字化する
cat /tmp/curl-output.json | claudeのような生データのパイプ流し込みで機密が混じっていないか確認する
顧客データを使ってデバッグするときはダミーデータに差し替えてから渡す

ログを伏字化する簡易スクリプトをtools/に置いておくと運用が楽です（例：sedでsk-から始まるトークンをsk-***に置換するなど）。

`CLAUDE.md`での宣言

CLAUDE.mdにプロジェクト共通の禁止事項を書いておくと、Claude側からも「これは秘密情報なので私からは出力しません」と動いてくれる確率が上がります。

# 禁止事項（秘密情報）
- `.env`、`.envrc`、`secrets/`配下、`~/.aws/`、`~/.ssh/`、`~/.config/gcloud/`を読まない
- 環境変数（`process.env.*` / `os.environ[*]`）の値そのものを出力しない
- API鍵・トークン・パスワードを依頼文・出力に含めない
- 顧客データ（メアド、電話番号、住所）を本物のままで出力しない

第2層：読ませない（Read deny rule＋サンドボックス）

Read deny ruleで内蔵Readを封じる

PermissionsのReadルールはgitignore互換のパターンで書きます。.claude/settings.jsonに次のように足します。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./.envrc)",
      "Read(./secrets/**)",
      "Read(./credentials.json)",
      "Read(~/.aws/**)",
      "Read(~/.ssh/**)",
      "Read(~/.config/gcloud/**)",
      "Read(~/.kube/config)",
      "Read(~/.netrc)",
      "Read(~/.pgpass)"
    ]
  }
}

注意点として、/Users/...のような**先頭スラッシュ1つは「プロジェクトルートからの相対」**になります。ホーム配下を絶対指定したいときは~/プレフィックスを使います（//Users/...の絶対パスも可）。

Bashの`cat`等は別経路で漏れる

公式ドキュメントは明確に警告しています。

Read and Edit deny rules apply to Claude’s built-in file tools, not to Bash subprocesses. A Read(./.env) deny rule blocks the Read tool but does not prevent cat .env in Bash. — Permissions

つまり、Readを塞いでもcat .env、env、printenv、grep API_KEY .envはBash経路で読めてしまいます。これに対するOS-level enforcementがSandboxingです。

サンドボックスで確実に塞ぐ

/sandbox

サンドボックス有効時は、denyReadに~/を入れてallowReadに作業ディレクトリだけを許可する書き方が強力です。

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    }
  }
}

これでホームディレクトリ全体（~/.aws、~/.ssh、~/.config/gcloudなど）へのBashからの読み取りもOSが止めます。プロンプトインジェクションでClaudeが「鍵を読んで」を実行しようとしても、Seatbelt（macOS）／bubblewrap（Linux/WSL2）が手前で遮断します。

Bash deny ruleの併用

サンドボックスを使えない環境では、Bash側でも禁止しておきます。

{
  "permissions": {
    "deny": [
      "Bash(cat .env*)",
      "Bash(cat ~/.aws/*)",
      "Bash(cat ~/.ssh/*)",
      "Bash(env)",
      "Bash(printenv)",
      "Bash(set)"
    ]
  }
}

ただし、公式が警告するようにBash deny ruleは引数のパターンマッチで脆い面があります（cat .envのような空白違いや、bash -c 'cat .env'のような迂回）。Bash denyは追加の堤防であり、メインの守りはサンドボックスとファイル配置の方に置くべきです。

第3層：残さない（Git・ログ・チェックポイント）

`.gitignore`の整備

最低限、次は除外します。

.env
.env.*
!.env.example
.envrc
secrets/
*.pem
*.key
.credentials.json

.env.exampleだけは追跡し、鍵名（変数名）の一覧を共有用に残します。鍵の値そのものは絶対にコミットしません。

gitleaks／trufflehogをCIで動かす

ローカルでうっかりコミットしてしまった鍵を、CI側でpush前 or push直後に検出します。

ツール	強み
gitleaks	設定がシンプル、規模小〜中で速い
trufflehog	検出器が豊富、検証付きスキャン可能

pre-commitフックに入れると、コミット時点で止まるため修復コストが最小です。

Claudeセッションのチェックポイント

Claude Codeはアクションごとにチェックポイントを作ります（公式）。便利な一方、間違って読んだファイル内容もそこに残ります。

秘密情報を誤って読ませてしまったら、そのセッションのチェックポイントは早めに整理する
もしClaudeが秘密情報を含む出力をしたら、/clearで履歴をリセットする
セッション履歴はPrivacy Centerに従って保管されているが、送ってしまった時点で「漏えいした」と扱うのが安全運用

ログ出力の注意

意外な漏えい経路がアプリのログです。生成されたコードがエラー時に**console.error(req.headers)**のように丸ごと出力していると、Authorizationヘッダのトークンがログに残ります。

依頼文に明示的に書く

## 完了条件
- ログ出力にリクエストヘッダ全体を出さない（Authorization、Cookie、X-Api-Keyを伏字化）
- エラーオブジェクトをそのままダンプしない（payload、bodyを除外する）
- 環境変数の値をログに出さない（変数名のみ）

## 禁止事項
- console.log(process.env) を書かない
- console.log(req.body) を書かない（PIIを含む可能性）
- スタックトレースに query parameter を含めない

社内ナレッジ共有や障害ログの貼り付け時に**OpenAI Privacy FilterのようなPII検出器**を入口に置く運用も、AI周辺の標準パターンになりつつあります。

誤コミット時の復旧手順

最悪のシナリオ──「鍵を含む.envをpushしてしまった」──の対応です。順序が大事で、git履歴を消す前にローテーションを必ずやります。

発見即ローテ：該当鍵を先に無効化する（再発行・削除）。git履歴を消す前に止めるのが最優先
影響調査：その鍵で叩かれた可能性のあるAPIログ・課金ダッシュボードを確認
チーム連絡：Slack等でSECURITY: rotated [provider] keys at [time]を共有
履歴の整理：git filter-repo等で過去履歴から鍵を除去（push済みなら全員に再cloneを依頼）
再発防止：gitleaksをpre-commitに追加、Read denyに該当ファイルパスを追加

「履歴削除よりローテーションを先」という順序を、チーム全員に染み込ませてください。GitHubはpush済みのコミットを内部キャッシュに残すことがあり、消したつもりでも見られる窓があります。鍵を無効化していれば、その窓は実害につながりません。

チェックリスト：3層防御の最小セット

新規プロジェクトでClaude Codeを使い始めるときに、最初に揃える設定です。

.gitignoreで.env*、secrets/、*.pem、*.keyを除外
.claude/settings.jsonにRead denyを追加（./.env*、~/.aws/、~/.ssh/、~/.config/gcloud/、~/.netrc、~/.pgpass）
.claude/settings.jsonにBash denyを追加（cat .env*、env、printenv等）
/sandboxを有効化、denyRead: ~/／allowRead: .を設定
CLAUDE.mdの禁止事項に「秘密情報」「環境変数値の出力禁止」を明記
CIにgitleaksまたはtrufflehogを追加
pre-commitフックで秘密情報スキャンを走らせる
チームの鍵ローテ手順をRunbook化

8項目すべてを揃えなくても、1〜3項目だけでも入れることで漏えい確率は大きく下がります。完璧を目指して着手が遅れるより、最低限を今日入れる方が現実的です。

やってはいけないアンチパターン

.envをClaudeに読ませて「環境変数を整理して」と頼む：内容が全部送信される
エラーログを伏字化せずに貼る：Authorization: Bearer ...が混じる事故
bypassPermissionsをホストマシンで常用：Read denyすら飛ばされる
「ローカルのClaudeセッションだから安全」と思う：プロンプトはAnthropicのモデルに送信される
誤コミット時、履歴削除を先にやる：ローテーションが先。順序が逆だと意味がない

次に読む

Claude Codeを使うときのセキュリティチェックリスト — 秘密情報以外の5カテゴリを含む全体像
Claude Codeで安全にコミットとPRを作るワークフロー — Git運用と多重防御の組み立て
Claude Codeの認証方法とログインできないときの確認ポイント — Claude Code自身の認証経路と資格情報の保存先

管理人

編集者 / オーナー