Claude Codeを使うときのセキュリティチェックリスト：6カテゴリで「危険な変更」を未然に防ぐ

結論：Claude Codeは「権限と境界」で守る。鍵は/permissions・/sandbox・denyルール・人間レビュー

Claude Codeは強力なエージェントですが、与えた権限以上のことはできません。逆に言うと、不用意に広い権限を与えると、プロンプトインジェクションや誤作動の影響範囲が一気に広がります。公式のSecurityページも、「Claude Code only has the permissions you grant it. You’re responsible for reviewing proposed code and commands for safety before approval.」と明記しています。

本記事では、AIコーディングで起こりがちな事故を6カテゴリに整理し、各カテゴリで何を確認し、どう設定するかをチェックリスト形式でまとめます。

1. 秘密情報の取り扱い（API鍵・トークン・個人情報）
2. 依存関係の管理（npm/PyPI等の追加と更新）
3. 入力検証とインジェクション対策
4. 認証・認可の境界
5. 権限とサンドボックス（Claude Code側の設定）
6. レビューとログ

秘密情報の細部はClaude Codeに秘密情報を渡さないための実践ルール、Git/PR運用はClaude Codeで安全にコミットとPRを作るワークフロー、AIレビューの使い方はClaude Codeをコードレビューに使う方法と人間が見るべきポイントに詳しいので、本記事は**横断的な「事故を起こさせない設定」**にフォーカスします。

カテゴリ1：秘密情報の取り扱い

最も漏えいリスクが高いのが、.env・APIキー・個人情報です。Claude Codeは読んだファイルの内容をモデルに送るため、何を読ませるかの制御が一次防衛になります。

チェック項目

• .env、.envrc、secrets/、credentials.jsonをRead deny ruleでブロックしているか
• .gitignoreで.env*を除外しているか
• CLAUDE.mdの禁止事項に「秘密情報を読まない・コピーしない・ログに出さない」を明記しているか
• gitleaksやtrufflehogなどのスキャナをCIで動かしているか
• 誤コミット時の鍵ローテーション手順をチームで共有しているか

deny ruleは.claude/settings.jsonに書きます。

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

注意点として、Read deny ruleは内蔵Readツールにしか効きません。Bashのcat .envは別経路で読めてしまうので、サンドボックス（後述）と併用するか、Bash側にもBash(cat:*)相当のask/denyを足してください。詳細はClaude Codeに秘密情報を渡さないための実践ルールで扱います。

カテゴリ2：依存関係の管理

AIコーディングで地味に怖いのが、Claudeが新しい依存パッケージを勝手に追加するケースです。タイポスクワッティング（似た名前の悪意あるパッケージ）や、メンテが止まった古いライブラリを混入させる可能性があります。

チェック項目

• CLAUDE.mdで「新しい依存追加は人間が承認」と明記しているか
• PRレビュー時にpackage.json / Cargo.toml / go.modの差分を必ず確認しているか
• 依存追加時にライセンス・更新頻度・GitHubスター数を確認する運用にしているか
• npm audit、pip-audit、cargo audit等をCIで実行しているか
• lock file（package-lock.json等）を必ずコミットしているか

依存追加を完全にブロックしたい場合、Bash deny ruleで止める手があります。

{
  "permissions": {
    "deny": [
      "Bash(npm install *)",
      "Bash(npm i *)",
      "Bash(pnpm add *)",
      "Bash(yarn add *)",
      "Bash(pip install *)"
    ]
  }
}

ただし、Claude自身が「テスト実行のために必要」と判断してnpm ciやnpm installをしたいケースもあるため、追加（add / install <name>）だけ止めて、復元（ci / install単独）は許す設計が現実的です。

カテゴリ3：入力検証とインジェクション対策

AIが書いたコードでも、入力検証はAIに任せきってはいけません。SQLインジェクション、コマンドインジェクション、XSS、SSRFは、テンプレ的に欠落しがちな観点です。

チェック項目

• ユーザー入力をSQL文に直接埋め込んでいない（プリペアドステートメント／ORMバインディング）
• 外部コマンドへの引数をシェルメタ文字でエスケープしているか（またはspawn/execFileの配列形式）
• テンプレートエンジンの自動エスケープを切っていないか
• ユーザー指定URLからのfetchでSSRF対策（プライベートIP帯のブロック）をしているか
• 入力サイズ・型・許容文字種のバリデーションをサーバー側で実施しているか

依頼文段階で**「入力検証を必ず入れる」**を完了条件に書く運用が効きます。

## 完了条件
- 受け付ける入力の型・長さ・許容文字種をバリデータで検証している
- DB操作はプリペアドステートメントを使っている（文字列結合禁止）
- 外部コマンド呼び出しは引数配列形式（`exec` 文字列形式禁止）
- 出力先のテンプレートエンジンの自動エスケープを切っていない

/security-reviewコマンドを併用すると、インジェクション・認証・データ漏えいの観点で差分を機械的に見直してくれるため、レビューの一次フィルタとして組み込む価値があります。

カテゴリ4：認証・認可の境界

「ログインしていなくても叩けるエンドポイント」「他人のリソースを操作できるID指定」は、AIが量産しがちなバグです。

チェック項目

• 新規エンドポイントに認証ミドルウェアが付いているかを必ず確認しているか
• オブジェクトレベルの認可（このユーザーがこのリソースを操作してよいか）をルートで確認しているか
• パスワード・トークンのハッシュ化（bcrypt、argon2等）が入っているか
• セッショントークンの有効期限・ローテーションが設計されているか
• 管理者専用APIに専用のロールチェックが入っているか

CLAUDE.mdに「新規ルートを足すときは必ずrequireAuthミドルウェアを通す」のようなプロジェクト固有のルールを書いておくと、生成コードの欠落を抑えられます。

カテゴリ5：権限とサンドボックス（Claude Code側）

ここはAIコーディング特有の防衛層です。Claude Code自体に何ができるかを絞ります。

Permission rules（基本）

Permissionsでは、deny → ask → allowの順でルールが評価されます。denyが最強なので、触ってほしくないものはまずdenyに書くのが鉄則です。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git status:*)",
      "Bash(git diff:*)"
    ],
    "deny": [
      "Bash(git push *)",
      "Bash(rm -rf *)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Read(./.env*)",
      "Edit(./.git/**)"
    ]
  }
}

Bash(curl *)のdenyは重要です。公式のSecurityページでも、任意のWebコンテンツを取得するコマンドはデフォルトでブロックされていること、許可するときはdomain指定のWebFetchに寄せるのが推奨されると説明されています。

Sandboxing（OS-levelの境界）

Sandboxingは、Bashコマンドのファイルシステム・ネットワークアクセスをOS側で制限する機能です。macOSはSeatbelt、LinuxとWSL2はbubblewrapで実装されています。

セッション内でこのコマンドを打つとサンドボックスモードを切り替えられます。サンドボックス有効時は、

• 書き込み：作業ディレクトリとサブディレクトリのみ
• 読み込み：基本許可、denyReadで個別ブロック
• ネットワーク：プロキシ経由で許可ドメインのみ

が強制されます。プロンプトインジェクションでClaudeが「悪意ある決定」を下しても、OS側が止めるのが最大の意義です。

bypassPermissionsは隔離環境でだけ

/permission-mode bypassPermissionsは権限プロンプトを全部スキップしますが、コンテナやVMでだけ使うのが公式推奨です。ローカルマシンで常用すると、ガードがほぼ全部外れた状態で動くことになります。

additionalDirectoriesを絞る

--add-dirやadditionalDirectories設定で作業範囲を広げすぎていないかを確認します。Claudeが触れる範囲を狭めることが、事故時の被害範囲を縮める一番素直な方法です。

カテゴリ6：レビューとログ

最後の防衛線は人間のレビューと事後の追跡可能性です。

チェック項目

• PRマージ前に人間がgit diffを読み切る運用になっているか
• /reviewと/security-reviewを併用しているか
• 重要操作（DB migration、本番デプロイ、鍵生成）に人間の承認ステップを入れているか
• Claudeセッションのログ・コマンド履歴が残る運用か（/feedbackでの報告ルートも整備）
• OpenTelemetry監視を有効化しているか（チーム利用の場合）

PreToolUseフックを使うと、コマンドが実行される直前にカスタムスクリプトで判定できます。「特定のディレクトリへの編集を絶対に止める」のような決定論的な制御は、ルールよりフックの方が確実です。

まとめ：6カテゴリの最小構成

最低限これだけ揃えておく、という構成を1枚に圧縮します。

この6カテゴリのうち、1つでも欠けると他5つの強度が落ちる設計だと考えてください。秘密情報を守っても権限が緩ければ意味がなく、サンドボックスを張っても認証なしAPIが量産されたら意味がない、という相互依存があります。

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

• .claude/settings.jsonをコミットしない：チーム全員に同じ守りが効かなくなる
• bypassPermissionsをホストマシンで常用：プロンプトインジェクションが直撃する
• Bash(*)を許可してから個別denyで絞る：抜け漏れが必ず出る。最小許可＋必要なものだけ追加が原則
• deny ruleがあるからレビューしない：ルールは抜け道がある。最後は人間の差分読み
• 「Claudeに任せれば安全」：Claudeは与えた権限の範囲内でしか守れない

チェック実行用テンプレ

新規プロジェクトでClaude Codeを導入するときに、上から順に確認するテンプレです。

[セットアップ時]
1. .claude/settings.json を作成し、最小deny rule（.env、.git push、curl/wget）を入れた
2. .gitignore に .env* と secrets/ が入っている
3. /sandbox を有効化した（macOS or Linux/WSL2の場合）
4. CLAUDE.md に禁止事項（依存追加・秘密情報・本番DB操作）を書いた
5. CIに gitleaks/trufflehog と npm audit を入れた

[日常運用]
6. PRマージ前に /review と /security-review を走らせた
7. git diff を人間が最終確認した
8. 依存追加があれば、ライセンス・更新頻度を確認した
9. /permissions で現在のルールを定期的に棚卸ししている

[インシデント時]
10. 鍵ローテーション手順をすぐ実行できる状態にしてある
11. ログから「いつ・誰の・どのセッションが」原因かを追える

このテンプレを.claude/security-checklist.mdとしてコミットしておくと、新メンバーのオンボーディングや監査時にもそのまま使えます。

次に読む

• Claude Codeに秘密情報を渡さないための実践ルール — .env、APIキー、個人情報の具体的な扱い
• Claude Codeで安全にコミットとPRを作るワークフロー — Git運用とPRレビューの組み立て方
• Claude Codeをコードレビューに使う方法と人間が見るべきポイント — /reviewと/security-reviewの使い分け