Claude Codeで機密情報を守る実践ガイド｜データ保護からPermission設定まで

Claude Codeと機密情報の関係を正しく理解する

Claude Codeは開発者のローカル環境で動作するAIコーディングアシスタントですが、入力されたコードやプロンプトはAnthropicのサーバーへネットワーク経由で送信されます。データはTLSで暗号化されて転送されるものの、ローカルで処理が完結するわけではありません（出典: Claude Code公式ドキュメント）。

つまり、.envファイルに記載されたAPIキーやデータベースの接続情報をClaude Codeに読み取らせると、その内容がAnthropicのサーバーに到達します。「AIが手元で動いているから安全」という誤解は、セキュリティ事故の原因となります。

プラン別のデータ学習・保持ポリシー

Claude Codeに送信されたデータの扱いは、契約プランによって大きく異なります。

項目	Consumer（Free/Pro/Max）	Commercial（Team/Enterprise/API）
モデル学習への利用	設定ON: 利用される / 設定OFF: 利用されない	利用されない（デフォルト）
データ保持期間	設定ON: 5年間 / 設定OFF: 30日間	30日間（ZDR設定で即時削除も可能）
学習設定の変更方法	claude.ai/settings/data-privacy-controls	デフォルトで学習OFF
Zero Data Retention	利用不可	API利用時に設定可能

（出典: Claude Code Data Usage）

Consumer プランでは、デフォルトでモデル改善のためにデータが利用される設定になっています。学習設定をOFFにしていても30日間はAnthropicのサーバーにデータが保持される点に注意が必要です。

学習オプトアウトだけでは不十分な3つの理由

「学習させない設定にしたから安全」と考えるのは早計です。学習OFFにしても見落としがちなリスクが3つあります。

1. 30日間のデータ保持は残る

学習設定をOFFにしても、Consumer プランではプロンプトとレスポンスが30日間サーバーに保持されます。この期間中にサーバー側のセキュリティ侵害が発生した場合、送信済みの機密情報が漏洩するリスクがゼロではありません。

2. /bugコマンドで全会話履歴が送信される

Claude Codeの/bugコマンドを実行すると、コードを含む完全な会話履歴のコピーがAnthropicに送信され、5年間保持されます（出典: Claude Code Data Usage）。デバッグ中に機密情報を含むセッションで/bugを実行してしまうケースは十分に起こり得ます。

3. テレメトリによる運用データの送信

Claude Codeはデフォルトで以下のテレメトリデータを外部サービスに送信します。

テレメトリ	送信先	内容	無効化する環境変数
運用メトリック	Statsig	レイテンシ・信頼性・使用パターン（コードやファイルパスは含まない）	`DISABLE_TELEMETRY=1`
エラーログ	Sentry	運用エラー情報	`DISABLE_ERROR_REPORTING=1`
バグレポート	Anthropic	完全な会話履歴（コード含む）	`DISABLE_BUG_COMMAND=1`

すべてを一括で無効化するには、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1を設定します。なお、Amazon Bedrock・Google Vertex AI・Microsoft Foundry経由で利用する場合は、これらのテレメトリはデフォルトでOFFです。

Permission設定で機密ファイルへのアクセスを遮断する

Claude Codeの権限管理は、settings.jsonによる宣言的なPermission設定で実現します。「そもそもAIに機密ファイルを読ませない」ことが、最も確実な防御策です。

settings.jsonの3層スコープと優先順位

設定ファイルは4つのスコープに分かれ、上位の設定が優先されます。

優先順位	スコープ	ファイルパス	共有範囲
1（最高）	Managed	`/etc/claude-code/managed-settings.json`（Linux）	IT管理者がデプロイ
2	Local	`.claude/settings.local.json`	個人（gitignore対象）
3	Project	`.claude/settings.json`	チーム（git管理）
4（最低）	User	`~/.claude/settings.json`	個人・全プロジェクト共通

（出典: Claude Code Settings）

Managed設定は他のすべてのスコープを上書きし、ユーザー側で変更できません。企業のセキュリティポリシーを強制的に適用する仕組みとして有効です。

.env・認証情報ファイルをdenyする具体例

プロジェクトの.claude/settings.jsonに以下を記述すると、Claude Codeが機密ファイルを読み取ること自体を拒否できます。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)",
      "Read(./**/serviceAccountKey.json)",
      "Read(~/.aws/**)",
      "Read(~/.ssh/**)",
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(cargo build *)",
      "Bash(cargo test *)"
    ]
  }
}

denyルールはevaluationの優先順位が最も高く、allowやaskより先に評価されます。ワイルドカード（*、**）を使って、パターンに一致するすべてのファイルやコマンドを一括で遮断できます。

curlとwgetはデフォルトでブロックされていますが、明示的にdenyに含めておくことで、設定の意図が明確になります。

Managed設定による組織全体の統制

企業でClaude Codeを展開する場合、IT管理者がManaged設定で全社共通のルールを強制できます。

Linuxの場合、/etc/claude-code/managed-settings.jsonに以下のように配置します。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./**/*credential*)",
      "Read(./**/*secret*)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(git push --force *)"
    ]
  },
  "disableBypassPermissionsMode": "disable",
  "allowManagedPermissionRulesOnly": true
}

disableBypassPermissionsModeを"disable"に設定すると、--dangerously-skip-permissionsフラグが無効になります。allowManagedPermissionRulesOnlyをtrueにすると、ユーザーやプロジェクトレベルの権限ルール追加が禁止され、Managed設定のルールのみが適用されます。

サンドボックスとdevcontainerで実行環境を隔離する

Permission設定でファイルアクセスを遮断しても、bashコマンド経由で間接的に機密情報へ到達するリスクは残ります。サンドボックスは、ファイルシステムとネットワークを分離することでこのリスクを軽減します。

サンドボックスの仕組みと制限事項

Claude Codeのサンドボックスは、bashコマンドの実行をファイルシステムとネットワークの両面で隔離する機能です。/sandboxコマンドで有効化できます。

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "excludedCommands": ["git", "docker"],
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org", "registry.yarnpkg.com"]
    }
  }
}

autoAllowBashIfSandboxedをtrueにすると、サンドボックス内のbashコマンドは自動承認されます。excludedCommandsに指定したコマンドはサンドボックスの外で実行されるため、gitやdockerなど外部接続が必要なツールを除外できます。network.allowedDomainsで、サンドボックス内からアクセスできるドメインをホワイトリスト方式で制限できます。

サンドボックスはmacOS、Linux、WSL2で利用可能です。

devcontainerによるより強固な分離

サンドボックスよりも強力な隔離が必要な場合、devcontainer（開発コンテナ）が有効です。devcontainerはDocker上に構築された完全に分離された開発環境を提供し、ホストマシンの機密ファイルへのアクセスをコンテナレベルで遮断します。

Claude Codeはdevcontainerをネイティブにサポートしており、コンテナ内で動作させることで、ホストマシン上の.envやSSH鍵に物理的にアクセスできない状態を作れます（出典: Claude Code公式ドキュメント）。

CLAUDE.mdとHooksで「ルールをコード化」する

Permission設定やサンドボックスは「制限」を設けるアプローチです。これに加えて、CLAUDE.mdでAIの行動指針を、Hooksでツール実行時の自動チェックを設定することで、防御を多層化できます。

CLAUDE.mdに書くべきセキュリティ指示

CLAUDE.mdはClaude Codeが起動時に読み込む指示ファイルです。プロジェクトルートに.claude/CLAUDE.mdとして配置し、チーム全体で共有できます。

# セキュリティルール

## 絶対に触れてはいけないファイル
- .env, .env.*, .envrc
- secrets/, config/credentials.json
- **/serviceAccountKey.json
- ~/.aws/**, ~/.ssh/**

## コマンド制限
- curl, wget は実行禁止
- git push --force は実行禁止
- rm -rf は実行禁止

## コードレビュー方針
- APIキーやトークンをハードコードしない
- 環境変数を直接表示するコマンドを実行しない
- ログ出力にシークレット情報が含まれないことを確認する

CLAUDE.mdはAIへの「指示」であり、技術的な強制力はPermission設定ほど強くありません。そのため、Permission設定（deny）との併用が前提です。CLAUDE.mdは「なぜそのルールが必要か」を含めて記述することで、AIが文脈を理解しやすくなります。

Hooksによるツール実行前の自動チェック

Hooksは、Claude Codeのツール実行ライフサイクルにカスタムコマンドを差し込む仕組みです。PreToolUseイベントを使うと、ツール呼び出しの前にスクリプトを実行し、条件に合わない場合は処理をブロックできます。

.claude/settings.jsonに以下のように設定します。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/check-secrets.sh",
            "timeout": 10
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/scan-written-file.sh",
            "timeout": 15
          }
        ]
      }
    ]
  }
}

check-secrets.shの例（bashコマンドにシークレット漏洩パターンがないかチェック）:

#!/bin/bash
INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

if echo "$COMMAND" | grep -qiE '(cat|less|head|tail|more)\s+.*\.(env|pem|key)'; then
  echo "機密ファイルへの直接アクセスは禁止されています" >&2
  exit 2
fi
exit 0

終了コード2を返すとツール呼び出しがブロックされ、stderrの内容がClaude Codeにフィードバックされます（出典: Claude Code Hooks）。

外部ツールとの連携でシークレット漏洩を多層防御する

Claude Code側の設定に加えて、gitリポジトリレベルでシークレットの混入を検知する仕組みを導入すると、防御がさらに強固になります。

git-secretsとgitleaksの導入

git-secretsはAWS Labsが提供するツールで、コミット時にAWSのアクセスキーやシークレットキーのパターンを検出します。

# インストール
git clone https://github.com/awslabs/git-secrets.git
cd git-secrets && make install

# リポジトリに適用
cd /path/to/your/project
git secrets --install
git secrets --register-aws

gitleaksはより汎用的なシークレット検出ツールで、APIキー・トークン・パスワードなど多様なパターンを検出します。

# インストール（Homebrew）
brew install gitleaks

# リポジトリ全体をスキャン
gitleaks detect --source /path/to/your/project

# コミット前のチェック（pre-commitフック）
gitleaks protect --staged

pre-commitフックとの組み合わせ

Claude Codeが生成したコードをコミットする前に、自動的にシークレットスキャンを実行する仕組みを作れます。

.git/hooks/pre-commitに以下を配置します。

#!/bin/bash
# gitleaksによるステージング済みファイルのスキャン
if command -v gitleaks &> /dev/null; then
  gitleaks protect --staged --no-banner
  if [ $? -ne 0 ]; then
    echo "シークレットが検出されました。コミットを中止します。"
    exit 1
  fi
fi

# git-secretsによるチェック
if command -v git-secrets &> /dev/null; then
  git secrets --pre_commit_hook -- "$@"
fi

この仕組みにより、Claude Codeがうっかり機密情報を含むコードを生成しても、コミット時点で自動的にブロックされます。

万が一の漏洩時に備えるインシデント対応

万全の対策をしていても、ヒューマンエラーで機密情報がAIに送信されてしまう可能性は残ります。漏洩発覚時の迅速な対応手順を事前に整備しておくことが重要です。

APIキー・トークン漏洩時の即時対応手順

即座にキーを無効化する - 漏洩が疑われるAPIキー・トークンを直ちにプロバイダー側で無効化（revoke）します
新しいキーを発行する - 無効化したキーに代わる新しいキーを生成し、アプリケーションの設定を更新します
アクセスログを確認する - 漏洩したキーが不正に使用された形跡がないか、クラウドプロバイダーのアクセスログを確認します
影響範囲を特定する - 漏洩したキーでアクセス可能だったリソース・データの範囲を洗い出します
チームに通知する - セキュリティチームと関係者に状況を報告し、必要に応じてインシデント管理プロセスを開始します

Anthropicへの報告方法

Claude Codeを通じて機密情報が送信されてしまった場合の対処:

セキュリティ脆弱性の報告: HackerOneプログラムを通じて報告できます
データ削除リクエスト: Anthropicのプライバシーポリシーに基づき、個人データの削除を要求できます
会話履歴の削除: Claude.aiのUIからチャット履歴を削除できますが、サーバー側の保持期間中（最大30日間）はデータが残ります

企業でClaude Codeを導入する際のチェックリスト

IPA/JDLAガイドラインへの準拠ポイント

IPAの「AIの安全な利用のためのガイドライン」（2024年7月公開）では、生成AIの業務利用におけるリスクを3分類で整理しています。

運用時のリスク: 意図しないデータ送信、学習への利用
法的・社会的リスク: 個人情報保護法、営業秘密の漏洩
攻撃に起因するリスク: プロンプトインジェクション、データ抽出攻撃

JDLAの「生成AIの利用ガイドライン」（2023年10月公開）では、入力時に注意すべき情報として以下を挙げています。

個人情報
NDA締結先から得た秘密情報
自組織の機密情報
著作物

Claude Codeを企業で利用する場合は、これらのガイドラインに照らして以下をチェックします。

プラン選定と導入の判断基準

チェック項目	確認内容	推奨対応
社内AI利用規程の有無	生成AI利用に関する社内規程が策定されているか	未策定の場合はIPA/JDLAガイドラインを参考に策定
取り扱うデータの分類	コードベースに個人情報・顧客データが含まれるか	含まれる場合はTeam/Enterprise/APIプランを選定
学習オプトアウトの要否	モデル改善にデータを利用されたくないか	Commercial プラン（デフォルトで学習OFF）を選定
ZDRの要否	サーバーにデータを保持されたくないか	APIプランでZDRを設定
権限管理の粒度	開発者ごとに異なるPermissionを設定する必要があるか	Managed設定でベースラインを統一
監査ログの要件	AI利用のログを保持する必要があるか	OpenTelemetryメトリクスで監視
SOC 2/ISO 27001	コンプライアンス要件でこれらの認証が必要か	Anthropic Trust Centerで証明書を確認
教育・周知	開発者向けのセキュリティ研修を実施しているか	CLAUDE.mdとPermission設定をテンプレート化して配布

最低限やるべき5つの設定

企業でClaude Codeを利用する場合、最低限以下の設定を実施します。

学習設定の確認 - Consumer プランの場合、claude.ai/settings/data-privacy-controlsで学習OFFに変更する
Permission設定の適用 - .claude/settings.jsonで機密ファイルのRead denyとcurl/wgetのBash denyを設定する
テレメトリの制御 - CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1を環境変数に設定する
pre-commitフックの導入 - gitleaksまたはgit-secretsでコミット時のシークレットスキャンを有効にする
CLAUDE.mdの配置 - プロジェクトルートにセキュリティルールを記述したCLAUDE.mdを配置し、チーム全体で共有する

これらの設定はPermission設定によるアクセス遮断、テレメトリ制御、外部ツール連携、AIへの行動指針の4層で防御を構成しています。いずれか1つだけでは不十分であり、組み合わせることで実効性のある機密情報保護が実現できます。

Claude Codeと機密情報の関係を正しく理解する#

プラン別のデータ学習・保持ポリシー#

学習オプトアウトだけでは不十分な3つの理由#

Permission設定で機密ファイルへのアクセスを遮断する#

settings.jsonの3層スコープと優先順位#

.env・認証情報ファイルをdenyする具体例#

Managed設定による組織全体の統制#

サンドボックスとdevcontainerで実行環境を隔離する#

サンドボックスの仕組みと制限事項#

devcontainerによるより強固な分離#

CLAUDE.mdとHooksで「ルールをコード化」する#

CLAUDE.mdに書くべきセキュリティ指示#

Hooksによるツール実行前の自動チェック#

外部ツールとの連携でシークレット漏洩を多層防御する#

git-secretsとgitleaksの導入#

pre-commitフックとの組み合わせ#

万が一の漏洩時に備えるインシデント対応#

APIキー・トークン漏洩時の即時対応手順#

Anthropicへの報告方法#

企業でClaude Codeを導入する際のチェックリスト#

IPA/JDLAガイドラインへの準拠ポイント#

プラン選定と導入の判断基準#

最低限やるべき5つの設定#