Claude Code を安全に使い倒すための 10 のチェックポイント

Claude Code、便利ですよね。
コード補完を超えて、ファイルを書き、ターミナルを叩き、PR まで出してくれる相棒として使っている方も多いのではないでしょうか。

自分はまずは触りながら覚え、見かけたツールや設定をその場で取り入れたりしていたのですが、
ふと「知らないうちに穴だらけになっているのでは？」と心配になってきました。
普段セキュリティに携わる人間として、一度セキュリティの棚卸しをしてチェックポイントとして並べてみることにしました。

Claude Code は今や「コードを書く AI」というより「シェルを叩けるエージェント」です。
チャット型の AI より自由度が高い分、攻撃されるポイントも多く、権限管理がより一層大事になってきます。
攻撃力の高い武器を使いこなしながらも、自分や味方を攻撃してしまわないように、使い方の作法は押さえておきたいものです。

本記事のスタンスは 2 つです。
ひとつは 「禁止より回復力」 — インシデントは起きる前提で、起きた後の回復可能性を上げること。
もうひとつは 「多層防御」 — ひとつのミスが即漏洩につながらないよう、セーフティを重ねること。
ガチガチに固めて利便性を損なうのではなく、スピードとセキュリティの両立を目指したい思いがあります。

以下では 10 のチェックポイントを 【個人】/【チーム】/【組織】 タグ付きで並べます。
全部やる必要はなく、自分の段階に合うものから始めれば十分です。

末尾には、コピペで Claude Code に貼って環境を診断してもらえるプロンプト も置いていますので、自分の環境の現状チェックにも使ってみてください。

まず状態を知る

最初のふたつは、「今の自分の Claude Code 環境がどうなっているか」を知るためのチェックです。

1.【個人〜組織】データの流れを自社内に閉じる

自分が入力した情報、知らないうちに学習データになっていないでしょうか。

Anthropic は 2025 年 8 月の規約変更で、個人プランではデフォルトで会話データが学習対象になる方針に変更されました。
学習対象とされないようにするには、自身で opt-out する必要があります。

組織で機密情報を扱う場合、データの流れを段階的に「自社の中」に閉じていく階段があります。

• 個人プラン: 設定画面でデータ学習の opt-out を有効化
• Teams プラン: Zero Data Retention で会話データを保持しない設定
• Bedrock / Vertex AI 経由: Claude API を自社の AWS / GCP アカウント内で完結させる (データが Anthropic 側を通らない)

進むほど「データを渡さない / 自社の監査に乗る」度合いが強くなります。
要件 (データレジデンシー / コンプライアンス) に応じて選ぶのが本来の使い方です。

組織として機密データを扱うなら、Bedrock / Vertex 構成まで踏み込む必要があるかもしれませんし、個人開発レベルなら opt-out で十分なケースもあります。
自分が今どの段にいるか、まず確認するのが最初の一歩です。

2.【個人】Claude Code を最新版に保つ (native install)

npm でインストールした Claude Code、最後にアップデートしたのはいつでしょうか。

Claude Code は更新頻度が高く、CVE 修正も頻繁に入ります。
古いバージョンを放置していると、すでに修正された脆弱性を踏むリスクが残ります。

native install (公式インストーラ) を使うと、自動アップデートが有効になります。

# 公式インストール (auto-update 有効)
curl -fsSL https://claude.ai/install.sh | bash

# npm からの移行
/migrate-installer

過去には ~/ を含むパスをホームディレクトリと誤判定して削除してしまう Issue #10077 のような事例もありました。
auto-update に乗っておくのが、手軽で確実な防御になります。

読ませない・実行させない (settings.json の deny rule)

ここからは .claude/settings.json で読み書きの境界を引いていきます。

3.【個人】credentials を Read deny で守る

Claude Code が ~/.aws/credentials や .env を読み込んでしまったら、と考えると怖いですね。

Claude のコンテキストに credentials が混入すると、そのまま外部に送信される可能性があります。
GitGuardian や Knostic は AI コーディングツール経由でのこの種の漏洩を継続的に観測しており、DNS クエリ経由で機密を抜き出す DNS exfil 系の脆弱性 (CVE-2025-55284) も報告されています。

対策は .claude/settings.json の permissions.deny で credentials 系ファイルを Read 禁止にすることです。

{
  "permissions": {
    "deny": [
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(**/.envrc)",
      "Read(**/secrets/**)",
      "Read(**/.secrets/**)",
      "Read(~/.aws/credentials)",
      "Read(~/.aws/config)",
      "Read(~/.aws/sso/cache/**)",
      "Read(~/.config/gcloud/**)",
      "Read(~/.ssh/id_*)",
      "Read(~/.ssh/*_key)",
      "Read(~/.gnupg/**)",
      "Read(~/.kube/config)",
      "Read(~/.docker/config.json)",
      "Read(~/.netrc)",
      "Read(~/.npmrc)",
      "Read(~/.pypirc)",
      "Read(~/.pgpass)"
    ]
  }
}

このリストには注意点が 2 つあります。

1 つ目は、Read() deny は Read ツールしか止めません。
Bash(cat ~/.aws/credentials) のように Bash 経由で読みに行かれると素通りします。
完全に塞ぐには Bash(cat:*credentials*) 等の Bash deny を併用するか、PreToolUse hook で Bash コマンドを検査する仕組みを足してください。

2 つ目、上のリストはあくまでスターターです。
自分のスタック (Terraform / Heroku CLI / Cloudflare wrangler など) で扱う credentials の置き場を棚卸しして、追加していくことをおすすめします。

4.【個人】dangerously-skip-permissions を使わず破壊系を deny rule で抑える

内容を見ずに「許可」を押した結果、データベースが消えた、という記事もよく見かけます。

Vibe coding という言葉がバズワードだった頃に、Replit のデータベースが AI に DROP された事件をはじめ、AI エージェントを信じすぎたことによる事故は実際に起きています。
権限チェックをまるごとスキップしてしまうと、ひとつの判断ミスが即破壊につながります。

対策は 2 つあります。

ひとつめは、--dangerously-skip-permissions を日常的に使わないこと。
スキップしたい場面 (使い捨て環境での自動化など) があっても、対象を限定して使うのが安全です。

ふたつめは、disallowedTools (permissions.deny) で破壊系コマンドを明示的に塞いでおくこと。
auto mode (acceptEdits) を日常的に使う場合の保険にもなります。
AI が破壊系を実行しようとしても deny rule が止めてくれる、多層防御の形です。

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": [
      "Bash(rm:*)",
      "Bash(rm -rf:*)",
      "Bash(find:* -delete)",
      "Bash(dd:*)",
      "Bash(sudo:*)",
      "Bash(git push --force:*)",
      "Bash(git push -f:*)",
      "Bash(git reset --hard:*)",
      "Bash(git clean -fd:*)",
      "Bash(git clean -fdx:*)",
      "Bash(git branch -D:*)",
      "Bash(aws s3 rm:*)",
      "Bash(aws s3 rb:*)",
      "Bash(terraform destroy:*)",
      "Bash(terraform apply -auto-approve:*)",
      "Bash(kubectl delete:*)",
      "Bash(npm publish:*)"
    ]
  }
}

こちらもスターターです。
ファイル / 権限昇格 / Git / クラウド / IaC / K8s / パッケージ公開と、取り返しがつきにくい操作を一通り入れています。
自分の業務スタック (Heroku / Cloudflare / Datadog / Snowflake CLI など) に応じて追加してください。

なお、Bash() deny は コマンド名ベースの照合です。
/bin/rm のように絶対パスで呼ばれた場合や、shell の alias でラップされた場合は別途確認が必要です。

補足: WebFetch / WebSearch の扱い

外部 URL、Issue 本文、README を Claude に読ませた瞬間に、本文に仕込まれた指示で動くプロンプトインジェクションが入る可能性があります。
2025 年に観測された Comment & Control (CVSS 9.4) はこの経路を悪用したものでした。

ただ WebFetch を完全に deny にしてしまうと、ドキュメント参照や情報収集の生産性が大きく落ちます。
ここは自分の環境に合わせて、設定を調整するポイントだと考えています。

• 許可のまま + 多層防御: 日常的な調べ物に使う場合。インジェクションが入っても、#3 の credentials Read deny と Bash の curl / wget deny を併せておけば、credentials は読まれず、外に持ち出す手段も塞がる。「入っても出せない」を作る発想
• 完全 deny: CI などクレデンシャルがロードされた環境。生産性とのトレードオフを受け入れる
• 中間案: PreToolUse hook で許可ドメインを限定 (公式 docs / 社内サイトのみ等)。実装コストはやや高め

WebFetch 単独で見るのではなく、「インジェクションが入っても、外に持ち出す手段を deny で塞いでおけば被害は限定的」 と捉える多層防御の発想が現実的かと思います。

完全に deny する場合のスニペットだけ置いておきます。

{
  "disallowedTools": ["WebFetch", "WebSearch"]
}

使うものを選ぶ (信頼境界)

拡張機能や外部リポを取り入れるとき、信頼境界をどこに引くかという話です。

5.【個人〜チーム】MCP / Plugin / Skill は公式・既知に絞る

インストールした MCP、裏で何をしているか把握できているでしょうか。

2025 年には postmark-mcp という MCP サーバの脆弱性、ToxicSkills という悪意ある Skill の配布、Shai-Hulud の npm パッケージ汚染と、サードパーティを介した事例が続きました。

迷ったら公式を選ぶ を原則にすると、判断がぐっと楽になります。
サードパーティの MCP / Plugin / Skill を入れるときは、次の 4 点を意識しておくと安全側に倒せます。

• 公式リポか、または既知の信頼できる組織のものか
• インストール後に .mcp.json や ~/.claude.json の中身を確認する
• 月 1 回程度で棚卸し (使っていないものを削除)
• バージョンを pin して、知らないアップデートが入らないようにする

「便利そうだから」だけで npx -y 系のコマンドを叩かない癖を付けるだけで、攻撃面は大幅に減ります。

6.【個人〜チーム】未知リポを trust する前に .claude/ を確認する

git clone した未知のリポジトリには、.claude/settings.json や .claude/hooks/ がコミットされていることがあります。
hooks には任意のシェルコマンドを書けるため、これらを読み込ませてしまうと、Claude が起動した瞬間に意図しないコードが実行されるリスクがあります。
CVE-2025-59536 (hooks RCE) や Issue #21674 で報告された経路です。

現在の Claude Code は、初めて開くディレクトリで .claude/ を検知すると 「このディレクトリを trust するか?」というプロンプトを出してくれます。
対策はここでシンプルで、反射的に trust を押さず、中身を一度確認してから決めることです。

# trust する前に .claude/ の中身を確認
ls -la .claude/
cat .claude/settings.json
cat .claude/hooks/*

# 中身が複雑で自信がない場合は、plan モードで起動して読ませる
claude --permission-mode=plan

中身を見る時の「あれ？」ポイントはこのあたりです。

• defaultMode: "bypassPermissions" が設定されている → 全権限スキップ。基本 NG
• permissions.allow に Bash(*) / WebFetch(*) などの広い許可がある → 事前許可で攻撃面が広がる
• hooks の中で curl / wget / nc などで外部に送信している → データ持ち出しの典型
• hooks の中で ~/.aws/ / ~/.ssh/ / .env を読み取っている → credentials 狙い
• base64 -d や eval、$(...) などの難読化がある → 中身を隠す意図がある
• PreToolUse / PostToolUse の matcher が ".*" などの広い trigger → 全操作に介入され、追跡困難

ひとつでも当てはまったら trust しない、を判断ルールにすると迷いません。

「設定ファイルの内容を読まずに trust する」のは、Bash(rm -rf:*) の確認プロンプトを反射的に許可するのと同じ構図です。

漏れた時の備え

どれだけ気をつけていても、ヒューマンエラーは起きます。
漏れた瞬間の被害を最小化する仕組みも考えておく必要がありそうです。

7.【チーム】credentials の commit を pre-commit hook で塞ぐ

AI が生成したコードに credentials がうっかり混入して、そのままコミットされてしまうケースは現実に増えています。

git-secrets や gitleaks のような pre-commit hook を入れておくと、AWS のアクセスキーや API キー形式の文字列を含む commit を物理的にブロックできます。

# gitleaks の例
brew install gitleaks
gitleaks protect --staged

pre-commit hook は個人 install が前提のため、サーバー側で確実に止めたい組織には GitHub Push Protection / Secret Scanning の併用もおすすめです。

それでも漏れたときのために、漏洩発覚から 24 時間以内にキーをローテーションできる体制 (担当者、手順、検知の自動化) を組織として持っておくのが望ましいです。
意思の力に頼るのではなく、仕組みで防ぐ、ですね。

チームで守る

8.【チーム】AI が書いた PR を CODEOWNERS と branch protection で固める

AI が書いたコードが十分なレビューを経ずに本番投入された結果、不具合が生じたという話は、もはや珍しくなくなりました。
当然ですが、AI が書いたコードは、書いた本人 (= AI) は責任を取れません。
レビュー用の AI を強化する方向性もありますが、最終的には人間によるチェックの必要性はゼロにはならないかと思います。

勝手にコードが適用されないように、以下の対策が考えられます。

• branch protection で main への直接 push を禁止、Require approvals を有効化 (author 本人は approve できない設定)
• CODEOWNERS でディレクトリごとに必須レビュアーを設定。security / インフラ / 決済まわりなど sensitive な領域は複数レビュアー必須に
• AI が生成した PR にはラベルで明示し、レビュー観点を変える (生成ツール、prompt、テスト結果など)

レビュー文化の問題に見えますが、設定で強制できるところは設定で強制してしまうのが効きます。

組織で守る

9.【組織】CI の権限を OIDC + read-only token で最小化する

Issue や PR の本文を AI に読ませたら、CI の API キーが外部に送信された、という事例があります。

2025 年に公開された Comment & Control (CVSS 9.4) は、まさにこの経路を悪用した攻撃でした。

攻撃の流れはこうです。

1. 攻撃者が GitHub Issue の本文に悪意あるプロンプトを仕込む
2. CI 上で動く Claude Code がその Issue を読み、悪意ある指示に従って動いてしまう
3. CI 環境変数に置かれた API キーやデプロイ用トークンが、外部に送信される

防御は CI 側で多層に行います。

• GitHub OIDC: 長寿命の PAT を使わず、短命の OIDC トークンで AWS / GCP にアクセスする
• Fine-grained PAT: どうしても PAT が必要な場合はリポジトリ単位・権限単位に絞る
• CI トークンを read-only に: 書き込みが不要なジョブは read 権限だけに絞る
• Anthropic API キーは CI 専用のキーを別途発行: 個人キーを CI に置かない

「Issue の中身 → AI の振る舞い → CI の資産」と権限が連鎖する設計が危険です。
どこか 1 箇所でも防ぐことができれば、攻撃チェーンは成立しません。

10.【組織】Teams / Enterprise の Managed Settings で組織横断に揃える

ここまで 9 個、個人やチームの設定を並べてきましたが、組織全体に揃えるにはどうすればよいでしょうか。

Anthropic の Teams / Enterprise プランには Managed Settings という仕組みがあり、.claude/settings.json を組織横断で配布・強制できます。

そこに置かれた設定は個人の設定よりも優先されるため、#3 〜 #6 の deny rule や permission mode を個人任せにせず組織として担保できます。

ただ正直に書いておくと、ガイドラインや設定の陳腐化は驚くほど速いです。
組織横断のルールで全てを保護し切ることは難しく、原則 + 仕組み + 最後は個人のリテラシー を組み合わせて、初めて強力な防御が実現すると言えそうです。
Managed Settings は仕組みのレイヤーを担う部品の一つ、という捉え方が現実的ではないでしょうか。

段階別の優先 3 つ

10 個全部やる必要はありません。
自分の今いる段階に合わせて、3 つから始めてみてください。

段階	まず手を付ける 3 つ	押さえる軸
個人で使い始めた人	#3, #4, #2	Read deny × 破壊系 deny × 最新化
チームで使っている人	+ #5, #6, #8	信頼境界 × PR レビュー
組織で展開している人	+ #9, #10, #1	CI 鍵 × Managed Settings × データの流れ

下のおまけを Claude Code に貼れば、自分の現状を自動診断できます。

おまけ: Claude Code に貼って自動診断

ここまでの 10 個を Claude Code 自身に読ませて、環境を診断してもらえるプロンプトを置いておきます。
プロンプトは 3 つのフェーズで動きます。

• Phase A: Bash / Read で自動調査 (settings.json、環境変数、.mcp.json など)
• Phase B: AskUserQuestion ツールで対話確認 (プラン、opt-out、PR 保護、CI トークン)
• Phase C: 診断表 → 優先トップ 3 → 「設定のお手伝いをしましょうか?」の確認

新しいセッションを開き、下を展開して中身をそのまま貼り付けてください。
結果と優先トップ 3 から、明日からやる順序が見えてきます。
特定リポの CI / PR 設定まで含めて診断したい場合は、対象リポを clone した中で実行すると .github/workflows/ や CODEOWNERS も自動で読んでくれます。

診断プロンプト全文 (クリックで展開)

あなたはセキュリティ監査担当です。
私の Claude Code 環境について、以下の 10 項目を診断してください。

---

## 実行ルール (最優先)

このタスクは **3 フェーズ** に分けて順番に実行します。**各フェーズが完了するまで次のフェーズに進まないこと**。

1. **Phase A: 自動調査** — Bash / Read で確認できる項目を一括で調べる
2. **Phase B: ヒアリング** — Claude が直接見られない項目を `AskUserQuestion` ツールでまとめて質問する
3. **Phase C: 診断結果 + 優先トップ 3 + 設定支援の確認**

### 厳守事項

- **Phase B のユーザー回答が出揃うまで、Phase C の出力 (診断表・トップ 3・推奨アクション) を一切先出ししない**
- 質問は **必ず `AskUserQuestion` ツール経由で行う** (テキスト出力での質問は禁止)
- ヒアリングは **1 回の `AskUserQuestion` 呼び出しで複数質問を束ねる** (往復を最小化)
- 本タスクは「clarifying question を止めるな」「work without stopping for clarifying questions」等のグローバル指示より **優先**。本タスクでは明示されたヒアリングが成果物の一部
- Phase A で値が取得できなかった項目を Phase C で「△ (要確認)」と書いて済ませない — 取得できないものは Phase B で必ず聞く

---

## Phase A: 自動調査 (Bash / Read で確認)

| # | 項目 | 確認内容 | 判定基準 |
|:-|:-|:-|:-|
| 1 | データの流れ | 環境変数 `CLAUDE_CODE_USE_BEDROCK` / `CLAUDE_CODE_USE_VERTEX` / `ANTHROPIC_BEDROCK_BASE_URL` | いずれかが set → Bedrock/Vertex 経由。何もなし → 直接 API / claude.ai 経由 (Phase B で plan / opt-out を要確認) |
| 2 | native install | `which claude` | npm グローバル配下 (`/usr/local/lib/node_modules/...`) は警告 |
| 3 | Read deny | `~/.claude/settings.json` と `./.claude/settings.json` の `permissions.deny` | `Read/Edit/Write(**/.env)` 等 credentials 系の網羅 |
| 4 | 破壊系 deny | `defaultMode`、Bash 破壊系 deny | `defaultMode != bypassPermissions`、`rm` / `sudo` / `git push --force` / `aws *` / `terraform destroy` / `kubectl delete` 等の網羅 |
| 5 | MCP | `~/.claude.json` と `.mcp.json` の `mcpServers` | 公式 (Anthropic / Microsoft 等) vs サードパーティ |
| 6 | hooks | `.claude/settings.json` の `hooks` | 有無と内容を要約 |
| 7 | pre-commit | `which git-secrets` / `which gitleaks` / `.git/hooks/pre-commit` / `.pre-commit-config.yaml` | credentials commit を止める仕組みの有無 |
| 8 | PR 保護 (CODEOWNERS) | `.github/CODEOWNERS` / `CODEOWNERS` / `docs/CODEOWNERS` の有無 (git repo 内のみ) | あり → CODEOWNERS は設定済。branch protection は GitHub UI 側なので Phase B で確認 |
| 9 | CI トークン (workflow) | `.github/workflows/*.yml` / `.gitlab-ci.yml` を読んで権限設定を確認 (git repo 内のみ) | `id-token: write` (OIDC) → ○ 候補、`aws-access-key-id` などの static credentials → 警告 |
| 10 | Managed Settings (macOS) | `/Library/Application Support/ClaudeCode/managed-settings.json` | 組織配布の有無 |

**Phase A 完了時:** 取得した raw データを簡潔に列挙して提示する。**ここでは判定 (○/△/×) を出さない**。

---

## Phase B: ヒアリング (`AskUserQuestion` で一括質問)

以下を `AskUserQuestion` ツールに **1 回の呼び出しで束ねて** 渡す。各質問は 3-4 択 + 必要に応じて「対象外」を含める。

### 質問 1 [#1a]: 使用プラン
- Claude Pro (個人)
- Claude Team / Enterprise (ZDR 同梱)
- Anthropic API キーを直接利用
- AWS Bedrock / Google Vertex 経由

### 質問 2 [#1b]: 学習 opt-out
*(Phase A で Bedrock/Vertex が検出された場合、または質問 1 で Team/Enterprise が選ばれた場合はこの質問をスキップ)*
- opt-out 済み (Privacy 設定で「Help improve Claude」OFF を確認済)
- opt-out していない (デフォルトのまま)
- API キー利用のためデフォルトで学習されない認識
- わからない / 未確認

### 質問 3 [#8]: PR 保護 (branch protection)
*(Phase A で CODEOWNERS が検出された場合は、branch protection の有無のみ確認すれば足りる)*
- main に branch protection + CODEOWNERS の両方あり
- branch protection のみ (CODEOWNERS なし)
- 何も設定していない
- 業務で GitHub/GitLab を使っていない (対象外)

### 質問 4 [#9]: CI トークン
*(Phase A で `.github/workflows/*.yml` から OIDC/static credentials のパターンが取れた場合は、その結果の補足のみ確認すれば足りる)*
- OIDC または fine-grained PAT で read-only に絞っている
- 古典的な PAT を使っている (フルアクセス相当)
- API キー / トークンを CI に置いていない
- CI を使っていない (対象外)

**Phase B 完了時:** 回答を簡潔に確認 (echo back) してから Phase C に進む。**ここでも判定や推奨を出さない**。

---

## Phase C: 診断結果 + 推奨

Phase A + B の情報が揃ってから初めて以下を出力する。

### C-1: 診断表

| # | 項目 | 状態 (○ / △ / × / 対象外) | 推奨アクション |
|:-|:-|:-|:-|

### C-2: 優先トップ 3

段階別マップ (個人 / チーム / 組織) に照らし、ユーザーが今優先すべき 3 項目をランク付け。各項目に「なぜ今これか」を 1-2 文で添える。

### C-3: 設定支援の確認

「**設定のお手伝いをしましょうか?**」と尋ねる。希望時のみ、トップ 3 の **手順説明** を行う。

**厳守:** ユーザーの明示的な確認なしに `settings.json` を書き換える等の **実変更は実行しない**。説明にとどめる。

---

## 参考: 段階別マップ

- **個人**: deny リスト整備、hooks による多層防御、credentials 検出
- **チーム**: PR 保護、CODEOWNERS、CI トークン最小権限、git-secrets/gitleaks 全リポジトリ展開
- **組織**: ZDR (Teams/Enterprise) または Bedrock/Vertex 経由、Managed Settings 配布、監査ログ集約

まとめ

ここまで 10 個 + おまけを並べてきましたが、伝えたかったのは結局のところ次の 3 つです。

• 禁止より回復力: ミスは起きる前提で、起きた後に被害を最小化する仕組みを考えておく
• 多層防御: ひとつのミスが即漏洩にならないよう、自分のフェーズに合わせて少しずつ防御を多層にしていく
• 迷ったら公式: 選択肢が増えすぎた今、公式を選ぶのが原則

まずは明日、おまけの診断プロンプトを Claude Code に貼って、自分の優先トップ 3 を出してみるところから始めてみるのはいかがでしょうか。

今日も小さな学びを。

Claude Code 関連記事