Claude Code は機密情報を送信してしまいませんか？

`.env` や認証情報を含むファイルは `.gitignore` と Claude Code の permissions 設定で読み込み対象から除外できます。社外秘ファイルは settings.json の `permissions.deny` で明示的にブロックするのが推奨です。

勝手にコマンドを実行されないか不安です。

デフォルトの権限モードでは、ファイル書き込みや bash 実行のたびに確認ダイアログが表示されます。慣れるまで `acceptEdits` や `bypassPermissions` には切り替えず、default モードで運用するのが安全です。

本番環境では使ってもいいですか？

本番 DB の DROP や force push など破壊的操作は `permissions.deny` で禁止しておくのが鉄則です。CI/CD と組み合わせる場合は専用の API キーを発行し、IP 制限と利用上限を必ず設定してください。

ブログ一覧

2026-03-05（更新: 2026-05-19）活用10分で読める

著者: BlueAI編集部

監修: 酒井歩乃加

早稲田大学文化構想学部卒業 / フリーランス編集者・ライター / 元マイベスト編集ディレクター / SEO対策記事・取材記事執筆

監修: 平原尚樹

株式会社BlueAI 代表取締役CEO / ソフトウェアエンジニア / プロダクトエンジニア / Google Cloud Architect / 元AIスタートアップ(Doorkel)

import { BlogInternalLink } from "../../app/components/blog/blog-internal-link"; import { BlogLessonLink } from "../../app/components/blog/blog-lesson-link"; import { BlogCtaBanner } from "../../app/components/blog/blog-cta-banner";

Claude Code セキュリティ設定完全ガイド｜安全に使う7つの設定 (2026年版)

「Claude Code は便利そうだけど、ファイルを勝手に書き換えたりしないか不安」「機密情報が漏れるリスクはないのか」——AI コーディングツールを導入するとき、セキュリティへの懸念は避けて通れません。

Claude Code はファイルシステムへの直接アクセスやターミナルコマンドの実行など、強力な機能を備えています。だからこそ、適切なセキュリティ設定と運用ルールを整えたうえで使うことが重要です。

本記事では、Claude Code を安全に使うためのセキュリティ対策を包括的に解説します。パーミッション設定、ネットワーク外部通信の制御、機密ファイルの保護、環境変数の取り扱い、CLAUDE.md でのセキュリティルール記述、チーム運用でのガードレール、コードレビューの重要性、そして本番環境での注意点まで網羅しています。この記事を読み終えるころには、Claude Code をチーム全体で安心して運用するための知識が身についているはずです。

7つの安全に使うための設定

Claude Code を安全に使ううえで、まず押さえるべき7つの設定をまとめます。各項目は本記事の以降のセクションで詳しく解説します。

最小権限のパーミッション設定 — .claude/settings.json の allow / deny を明示する
ネットワーク外部通信の制御 — curl、wget、ssh を deny で塞ぐ
.claudeignore による機密ファイル除外 — .env、秘密鍵、認証情報を読ませない
環境変数を .env.example で管理する — 実値をプロンプトに渡さない
CLAUDE.md にセキュリティルールを明文化する — 禁止事項を AI に学習させる
.gitignore とシークレットスキャンの連携 — コミット前にシークレットを止める
本番環境では使わない・CI/CD では読み取り専用 — 破壊的操作の経路を断つ

設定項目と推奨値の早見表

主要なセキュリティ設定の推奨値とリスクを一覧にしました。

設定項目	推奨値	放置した場合のリスク
`.claude/settings.json` の `deny`	`rm -rf `、`git push --force`、`curl`、`wget`、`ssh`	破壊的コマンド・外部通信が誤実行される
`.claude/settings.json` の `allow`	`Read`、`Glob`、`Grep`、`Bash(npm test)`、`Bash(git status)` のみ	全承認状態で意図しない書き込みが走る
`.claudeignore`	`.env`、`.pem`、`*.key`、`credentials.json`、`.ssh/`	機密ファイルが LLM コンテキストに混入する
`CLAUDE.md` のセキュリティ節	禁止事項を箇条書きで明記	AI が危険なパターンを生成する
ネットワーク許可	プロキシ / API エンドポイントのみ	内部リソースが外部へ送信される可能性
API キー管理	個人ごと発行 + Console で上限設定	不正利用検知が遅れる
CI/CD でのツール制限	`--allowedTools "Read,Glob,Grep"`	自動実行で本番環境が書き換わる

詳細な設定値の解説はも参照してください。

Claude Code のセキュリティモデル概要

Claude Code のセキュリティは「許可ベースのアクセス制御」を基本としています。デフォルトではすべての操作に対してユーザーの承認が必要であり、明示的に許可しない限り、ファイルの変更やコマンドの実行は行われません。

このモデルの主な特徴は以下の通りです。

操作ごとの承認: ファイルの読み書き、コマンドの実行など、操作の種類ごとに承認が求められる
ローカル実行: コードの分析と変更はすべてローカルマシン上で行われる
セッション単位の制御: パーミッションの許可はセッション単位で管理でき、セッション終了時にリセットされる
設定ファイルによる永続化: 繰り返し使う許可ルールは設定ファイルに書いて永続化できる

つまり、Claude Code はデフォルトで「最小権限の原則」に従って動作します。安全性を高めるために追加設定をする必要があるのではなく、利便性のために必要な権限を明示的に開放していくアプローチです。

Claude Code の基本的な使い方については、以下の記事で詳しく解説しています。

パーミッション設定（許可/拒否のツール制御）

Claude Code のパーミッションシステムは、どのツール（操作）を許可し、どのツールを拒否するかを細かく制御できます。

パーミッションの種類

Claude Code では操作を大きく3つのカテゴリに分けて管理しています。

読み取り操作: ファイルの内容を読む、ディレクトリを一覧する、検索するなど
書き込み操作: ファイルの作成・編集・削除
コマンド実行: ターミナルコマンドの実行（npm install、git commit など）

セッション中のパーミッション管理

Claude Code がツールを使おうとすると、承認プロンプトが表示されます。ここで選べる選択肢は以下の通りです。

Allow once（一度だけ許可）: その操作だけを許可する
Allow for session（セッション中は許可）: 同じ種類の操作をセッション中は自動許可する
Deny（拒否）: その操作を拒否する

セッション中の自動許可は便利ですが、すべての操作を自動許可にするのは避けましょう。特にファイルの削除やシステムコマンドの実行には毎回確認を挟むことを推奨します。

設定ファイルによる永続的なパーミッション

プロジェクトごとに繰り返し使うパーミッションルールは .claude/settings.json に記述して永続化できます。

{
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "Bash(npm test)",
      "Bash(npm run lint)",
      "Bash(npm run build)",
      "Bash(git status)",
      "Bash(git diff)",
      "Bash(git log)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force)",
      "Bash(curl*)",
      "Bash(wget*)"
    ]
  }
}

この設定では以下を実現しています。

読み取り系の操作: 常に許可（ファイル読み取り、検索、grep）
安全なコマンド: テスト実行、リント、ビルド、Git の読み取り系コマンドを許可
危険なコマンド: 再帰的な削除、強制プッシュ、外部通信を拒否

ポイントは deny のリストです。明示的に拒否するコマンドを定義しておくことで、誤って危険な操作が実行されるリスクを排除できます。

パーミッション設定のベストプラクティス

パーミッション設定で心がけるべき原則をまとめます。

最小権限から始める: デフォルトの全承認を維持し、よく使う安全な操作だけを allow に追加する
危険なコマンドは明示的に deny: rm -rf、git push --force、chmod 777 などは必ず拒否リストに入れる
外部通信を制限する: curl、wget、ssh などの外部通信コマンドは基本的に拒否する
チームで設定を統一する: .claude/settings.json をリポジトリにコミットしてチーム全体で共有する

ネットワーク外部通信の許可・拒否

Claude Code を安全に運用するうえで、ネットワーク経由の外部通信を厳しく制限することは非常に重要です。curl や wget を許可してしまうと、AI が誤って機密データを外部サーバーへ送信する経路を作ってしまう可能性があります。

外部通信コマンドを `deny` で塞ぐ

.claude/settings.json の deny リストに、外部通信を伴うコマンド群を明示的に追加します。以下は推奨される基本セットです。

{
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "Bash(npm test)",
      "Bash(npm run lint)",
      "Bash(git status)",
      "Bash(git diff)"
    ],
    "deny": [
      "Bash(curl*)",
      "Bash(wget*)",
      "Bash(ssh*)",
      "Bash(scp*)",
      "Bash(rsync*)",
      "Bash(nc*)",
      "Bash(ncat*)",
      "Bash(telnet*)",
      "Bash(ftp*)",
      "Bash(sftp*)"
    ]
  }
}

外部通信が必要なケースの例外設定

開発上どうしても外部通信が必要な場面では、ホワイトリスト的に「特定 URL のみ許可」する形にします。たとえば社内 GitHub API へのアクセスだけを許可したい場合は次のように書けます。

{
  "permissions": {
    "allow": [
      "Bash(curl https://api.github.com/*)",
      "Bash(curl https://api.internal.example.com/*)"
    ],
    "deny": [
      "Bash(curl*)",
      "Bash(wget*)"
    ]
  }
}

deny のワイルドカードよりも allow の具体パターンの方が優先されるため、特定ホストへの通信だけが許可されます。* を含む広いパターンは deny 側に置き、必要なホストだけを allow で開ける構成が安全です。

プロキシ・ファイアウォール側の制御

クライアント設定だけに頼らず、企業ネットワーク側でも以下を整備しておくと多層防御になります。

エグレス制御 — 開発端末からのアウトバウンドを api.anthropic.com と社内エンドポイントのみに絞る
DNS フィルタ — 既知の悪性ドメインや個人クラウドストレージへのアクセスをブロックする
プロキシログ — Claude Code 経由の通信ログを残し、異常検知に使う

ネットワーク設定の見直しは「Claude Code が動かなくなるリスク」と「機密漏えいリスク」のトレードオフです。本番に近い環境ほど後者を重視し、deny を厚くするのが原則です。

CLAUDE.md でのセキュリティルール記述例

CLAUDE.md はプロジェクトのルートに置く Claude Code 向けの指示書です。ここにセキュリティルールを明文化しておくと、AI が生成するコード自体がそのルールに沿うようになります。

最低限書いておくべきセキュリティ節

以下のテンプレートを CLAUDE.md の冒頭 (または ## Security セクション) に追加してください。

## セキュリティルール (絶対遵守)

- .env / .env.* / credentials.json / *.pem / *.key の内容は読み取らない
- API キー・パスワード・トークンをコードや CLAUDE.md にハードコードしない
- 外部 API への直接リクエスト (curl / wget / fetch to external) を実行しない
- 本番 DB への接続文字列を含むコマンドを実行しない
- rm -rf、git push --force、git reset --hard などの破壊的コマンドを実行しない
- ユーザー入力を取り扱うコードでは必ずバリデーションとエスケープを行う
- SQL は必ずプレースホルダ (パラメータバインド) を使う
- 認証・認可のチェックは全エンドポイントに実装する

## レビュー時の自己チェック

- 機密ファイルへの参照が含まれていないか
- 環境変数を直接ハードコードしていないか
- エラーメッセージに内部パスやスタックトレースが露出していないか
- 外部送信が新たに増えていないか

プロジェクト固有のルールも追記する

汎用ルールに加えて、プロジェクト固有の制約も書いておくと AI が迷わなくなります。

## プロジェクト固有のセキュリティ制約

- 個人情報を扱うテーブル (users, customers) は SELECT * を禁止
- マイグレーション SQL は手動レビュー必須 (AI で自動実行しない)
- /api/admin/* 配下のエンドポイントは管理者ロール必須
- ログには user_id を出力可、メール / 電話 / 住所は出力禁止

CLAUDE.md の詳しい書き方はで解説しています。

.gitignore / シークレットスキャン連携

.claudeignore で Claude Code に読ませない設定をしても、人間がうっかり機密情報をコミットしてしまえば、結局リポジトリ経由で漏えいします。.gitignore とシークレットスキャンを併用して、多層的に守る運用が現実的です。

.gitignore と .claudeignore は同じ機密パターンを共有する

最低限、以下のパターンは .gitignore と .claudeignore の両方に入れます。

# 環境変数
.env
.env.*
!.env.example

# 認証情報・鍵
*.pem
*.key
*.crt
*.p12
*.pfx
credentials.json
service-account-key.json
.ssh/

# クラウド CLI のキャッシュ
.aws/
.gcp/
.azure/

# ローカルシークレット
.secrets/
vault/

シークレットスキャンを CI に組み込む

うっかりコミットを止めるには、シークレットスキャナーを CI で必須化します。主要な選択肢は以下の通りです。

GitHub Secret Scanning — Public/Private リポジトリで自動有効化。push protection を ON にすると検知時にコミットがブロックされる
Gitleaks — OSS のスキャナー。GitHub Actions / GitLab CI に組み込みやすい
TruffleHog — エントロピー検出が強力。過去コミット履歴のスキャンにも対応
detect-secrets (Yelp 製) — pre-commit フックで実行し、ローカルでブロックできる

GitHub Actions に Gitleaks を入れる最小例は次のような形になります。

name: gitleaks
on: [pull_request, push]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

pre-commit フックでローカル流出を止める

CI に流れる前に、ローカルの pre-commit フックでも防御層を用意します。.pre-commit-config.yaml に detect-secrets を組み込む例です。

repos:
  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.5.0
    hooks:
      - id: detect-secrets
        args: ["--baseline", ".secrets.baseline"]

.secrets.baseline を最初に生成しておくと、既存の許容済みパターンと新規検出を区別できます。Claude Code でリファクタリングや一括置換をしたあとに、人間が git commit するタイミングで自動的にチェックが走るため、AI と人間の二段防御になります。

.claudeignore で機密ファイルを保護する

.claudeignore は、Claude Code に読み込ませたくないファイルやディレクトリを指定するための設定ファイルです。.gitignore と同じ書式で記述できます。

.claudeignore の基本

プロジェクトのルートに .claudeignore ファイルを作成し、除外したいパスを記述します。

# 環境変数ファイル
.env
.env.*
.env.local
.env.production

# 認証情報
credentials.json
service-account-key.json
*.pem
*.key
*.crt

# シークレット管理
.secrets/
vault/

# AWS / GCP / Azure の認証情報
.aws/
.gcp/
.azure/

# SSH鍵
.ssh/

# パスワードファイル
**/passwords*
**/secrets*

.claudeignore に記載されたファイルは Claude Code の読み取り対象から完全に除外されます。これにより、たとえ「プロジェクト内のすべてのファイルを読んで」という指示が出されても、機密ファイルが Claude Code に渡ることはありません。

なぜ .claudeignore が重要なのか

Claude Code はプロジェクト全体を理解するためにファイルを読み込みます。その過程で、意図せず API キーやデータベースの接続文字列が読み込まれるリスクがあります。.claudeignore を設定しておけば、このリスクを根本から排除できます。

特に以下のファイルは必ず .claudeignore に追加してください。

.env ファイル: API キー、データベース接続文字列、外部サービスの認証情報
秘密鍵ファイル: SSL 証明書、SSH 鍵、JWT 署名鍵
サービスアカウントキー: GCP の service-account-key.json など
ローカル設定ファイル: IDE の認証トークン、クラウド CLI の認証キャッシュ

.claudeignore と .gitignore の使い分け

.gitignore と .claudeignore は目的が異なります。

.gitignore: Git のバージョン管理から除外するファイル
.claudeignore: Claude Code の読み取り対象から除外するファイル

多くの場合、.gitignore に含まれるファイルは .claudeignore にも含めるべきです。ただし、.gitignore には含まれないがClaude Code には読ませたくないファイル（例: チーム内共有の内部ドキュメントやNDA関連ファイルなど）もあるため、両者は独立して管理してください。

環境変数・シークレットの取り扱い

環境変数やシークレットの管理は、Claude Code を安全に運用するうえで最も注意が必要な領域です。

環境変数を直接プロンプトに書かない

以下のような使い方は絶対に避けてください。

# 悪い例: APIキーを直接プロンプトに含めている
DATABASE_URL=postgres://user:password@host:5432/db を使って接続テストして

代わりに、環境変数はファイルで管理し、Claude Code にはファイル名だけを伝えます。

# 良い例: 環境変数の参照方法だけを指示する
.env.example を参考にして、データベース接続の設定処理を書いて。
実際の値は .env から読み込むようにして。

.env.example の活用

チーム開発では .env.example（実際の値を含まないテンプレート）をリポジトリにコミットし、Claude Code にはこのファイルを参照させます。

# .env.example（リポジトリにコミットする）
DATABASE_URL=postgres://localhost:5432/myapp_dev
REDIS_URL=redis://localhost:6379
API_KEY=your-api-key-here
STRIPE_SECRET_KEY=sk_test_xxxx

# .env（.claudeignore と .gitignore の両方に追加する）
DATABASE_URL=postgres://user:realpassword@prod-host:5432/myapp
REDIS_URL=redis://prod-redis:6379
API_KEY=sk-live-XXXXXXXXXX
STRIPE_SECRET_KEY=sk_live_XXXXXXXXXX

Claude Code が .env.example を読むことで、必要な環境変数の構造を理解できます。実際の値は .env に保持し、.claudeignore で保護します。

シークレット管理サービスとの連携

本格的な運用では、シークレット管理サービス（AWS Secrets Manager、GCP Secret Manager、HashiCorp Vault など）を使い、コードにはシークレットへの参照のみを記述するアーキテクチャを推奨します。

シークレットは GCP Secret Manager から取得する設計にして。
直接環境変数にハードコードしないで。

Claude Code にこの方針を伝えておけば、シークレット管理のベストプラクティスに沿ったコードを生成してくれます。

チーム運用でのガードレール設定

チームで Claude Code を運用する場合、個人の裁量に任せるのではなく、組織的なガードレールを設定することが重要です。

プロジェクト共有の設定ファイル

.claude/settings.json をリポジトリにコミットすることで、チーム全員が同じパーミッション設定で Claude Code を使えます。

{
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "Bash(npm test)",
      "Bash(npm run lint)",
      "Bash(npm run typecheck)",
      "Bash(git status)",
      "Bash(git diff)",
      "Bash(git log)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force)",
      "Bash(git reset --hard)",
      "Bash(git checkout -- .)",
      "Bash(curl*)",
      "Bash(wget*)",
      "Bash(ssh*)",
      "Bash(scp*)",
      "Bash(docker rm*)",
      "Bash(docker system prune*)"
    ]
  }
}

CLAUDE.md によるルールの明文化

CLAUDE.md にセキュリティに関するルールを明記しておくと、Claude Code がそのルールに従ったコードを生成します。

# CLAUDE.md

## セキュリティルール
- .env ファイルの内容を読み取らない
- APIキーやパスワードをコード内にハードコードしない
- 外部APIへの直接リクエストを実行しない
- データベースへの直接接続やマイグレーションを実行しない
- 本番環境のURLやエンドポイントを含むコマンドを実行しない
- rm -rf、git push --force などの破壊的コマンドを実行しない

## コーディング規約（セキュリティ関連）
- 外部入力は必ずバリデーションする
- SQLクエリにはプレースホルダを使用する（SQL インジェクション対策）
- ユーザー入力をHTMLに出力する際はエスケープする（XSS対策）
- 認証・認可チェックをすべてのエンドポイントに実装する

チーム内の運用ルール

設定ファイル以外にも、以下のような運用ルールをチームで合意しておくことを推奨します。

Claude Code で生成したコードは必ずレビューを通す: 自動生成だからといってレビューを省略しない
機密性の高いファイルを変更するPRは手動で作成する: 認証・認可、暗号化、決済関連のコードは特に慎重に
新しいパーミッションの追加はチームで議論する: allow リストの変更は全員の合意を得る
定期的にパーミッション設定を見直す: 不要になった許可を削除し、最小権限を維持する

コードレビューの重要性（AI 生成コードの検証）

Claude Code が生成するコードは高品質ですが、AI が生成したコードだからこそ、人間によるレビューが欠かせません。

なぜ AI 生成コードにレビューが必要か

AI は以下のような問題を見落とすことがあります。

ビジネスロジックの正確性: 要件の微妙なニュアンスを取り違える可能性がある
セキュリティホール: 一見正しく見えても、特定の入力パターンで脆弱性が生じるケース
パフォーマンスの問題: 機能的には正しいが、大量データで性能が劣化するコード
既存コードとの整合性: プロジェクト固有の暗黙的なルールに反する実装

レビューで確認すべきセキュリティポイント

Claude Code が生成したコードをレビューする際に特に注意すべきポイントです。

入力バリデーション

生成されたAPIエンドポイントに対して:
- リクエストボディのバリデーションは十分か
- パスパラメータの型チェックは行われているか
- ファイルアップロードのサイズ・形式制限はあるか

認証・認可

- 認証チェックが漏れているエンドポイントはないか
- 他のユーザーのリソースにアクセスできる状態になっていないか
- 管理者権限のチェックは適切か

データ処理

- SQLインジェクションの可能性はないか
- XSSの可能性はないか
- 機密データがログに出力されていないか
- エラーメッセージに内部情報が含まれていないか

レビュー効率を上げるコツ

Claude Code を使ってレビューの効率を上げることも可能です。

直前のコミットのセキュリティ上の問題点をチェックして。
特にインジェクション、認証漏れ、機密情報の露出を重点的に。

Claude Code 自身にセキュリティレビューを依頼し、指摘された点を人間がさらに精査するという二段構えのアプローチが効果的です。

ネットワークセキュリティ（APIキーの管理）

Claude Code の利用にはAPIキーが必要です。このAPIキーの管理もセキュリティ上の重要なポイントです。

APIキーの安全な管理

APIキーをコードにハードコードしない: 環境変数やシークレット管理サービスを使う
APIキーをチャットに貼り付けない: Claude Code のプロンプトにAPIキーを入力しない
APIキーのローテーション: 定期的にAPIキーを更新する
使用状況のモニタリング: Anthropic Console でAPIキーの使用状況を定期的に確認する

利用制限の設定

Anthropic Console では以下の制限を設定できます。

月次の利用上限: 想定外の大量利用を防止する
レート制限: 単位時間あたりのリクエスト数を制限する

チーム運用では、個人ごとのAPIキー発行が推奨されます。共有APIキーを使うと、誰がどの程度利用しているかの追跡が困難になり、不正利用の検知が遅れます。

ネットワーク制限

企業ネットワークでの運用では、以下の点を確認してください。

プロキシ設定: 企業プロキシを経由する場合の設定が正しいか
ファイアウォールルール: Anthropic の API エンドポイントへのアクセスが許可されているか
VPN との併用: VPN 環境での動作を事前に確認する

本番環境での注意点

Claude Code を本番環境に近い場所で使う場合には、特別な注意が必要です。

本番環境では使わない

大前提として、Claude Code を本番サーバー上で直接実行することは推奨しません。開発マシンやステージング環境での使用に限定してください。

本番データベースに接続した状態で使わない: 誤った SQL が実行されるリスクがある
本番の認証情報を使わない: ステージング用の認証情報を別途用意する
デプロイコマンドを自動許可しない: デプロイは人間が確認してから実行する

CI/CD パイプラインでの利用

Claude Code を CI/CD パイプラインに組み込む場合は、非対話モード（-p フラグ）を使い、実行できるコマンドを厳密に制限します。

# CI環境での安全な実行例
claude -p "このPRのコード変更をレビューして、セキュリティ上の問題があれば報告して" \
  --allowedTools "Read,Glob,Grep"

CI/CD 環境では書き込み権限を与えず、読み取りと分析のみに制限するのが安全です。

インシデント対応の準備

万が一のセキュリティインシデントに備えて、以下を準備しておきましょう。

APIキーの即座な無効化手順: Anthropic Console からのキー削除方法を文書化する
変更の巻き戻し手順: Git の操作で変更前の状態に復旧する手順を確認する
ログの確認方法: Claude Code の操作ログを確認する方法を把握する

セキュリティチェックリスト

Claude Code を安全に導入・運用するためのチェックリストです。プロジェクトに導入する際に一つずつ確認してください。

導入時のチェック

.claudeignore を作成し、.env、秘密鍵、認証情報ファイルを除外している
.claude/settings.json を作成し、パーミッションの allow / deny を設定している
CLAUDE.md にセキュリティルールを明記している
.env.example をリポジトリに含め、実際の .env は .claudeignore に追加している
チームメンバー全員がパーミッションの仕組みを理解している

日常運用のチェック

AI が生成したコードは必ず人間がレビューしている
機密ファイルの変更を含む PR は特に慎重にレビューしている
API キーの利用状況を定期的に確認している
パーミッション設定を定期的に見直している
破壊的コマンド（rm -rf、git push --force）が deny リストに含まれている

定期的な見直し

月次で .claudeignore の対象ファイルを見直す
四半期でパーミッション設定をレビューする
API キーのローテーションを計画的に実施する
新しいチームメンバーへのセキュリティガイダンスを実施する

まとめ

Claude Code のセキュリティ対策の要点を振り返ります。

パーミッションは最小権限で始める: 必要な操作だけを明示的に許可し、危険な操作は拒否リストに入れる
.claudeignore で機密ファイルを保護する: .env、秘密鍵、認証情報は必ず除外する
環境変数は .env.example で管理する: 実際の値を Claude Code に渡さない
チームで設定を統一する: .claude/settings.json と CLAUDE.md をリポジトリで共有する
AI 生成コードは必ずレビューする: 自動生成だからといってレビューを省略しない
本番環境では使わない: 開発・ステージング環境での利用に限定する

セキュリティは一度設定すれば終わりではありません。チームの成長やプロジェクトの変化に合わせて、定期的に設定を見直し、ルールをアップデートしていくことが大切です。Claude Code の強力な機能を最大限に活かしながら、安全な開発環境を維持していきましょう。

Claude Code のセキュリティや運用について体系的に学びたい方は、以下のレッスンで詳しく解説しています。

Claude Code の活用テクニックをさらに深掘りしたい方は、以下の記事も参考にしてください。