10-3 Claude Code セキュリティ｜組織導入の安全設計

このレッスンで身につくこと

このレッスンは、レッスン 10-1（組織導入の戦略）と 10-2（Cowork による並行実行）で描いた絵を、実装レイヤーまで落とし込む ためのものです。10-1 は「何を決めるか」、本レッスンは「どう設定するか・どう監査するか」に焦点を当てます。

所要時間 — 約 60 分（手を動かしながらだと 90 分） 難易度 — ★★★★☆（情シス・SRE・セキュリティ担当向けの技術設計） 想定読者 — 情シス / SRE / セキュリティ責任者 / テックリード / EM / CTO

はじめに — 「便利な道具」は「危険な道具」と紙一重

Claude Code は、ローカルファイルを読み、シェルコマンドを実行し、外部サービスと通信できるエージェント です。これだけで、ChatGPT に 200 行貼るのとは まったく別のリスクプロファイル を持っています。rm -rf / を承認したらファイルは戻りません。.env を読み込ませれば本番 DB の接続文字列が Anthropic を通過します。「気をつける」 では絶対に止められない事故が、組織導入のスケールでは必ず起こります。本レッスンの目的は、それを 仕組みで止める ことです。

リスクモデル — 何が漏れる可能性があるか

設計に入る前に、何が漏れたら困るのか を解像度高く整理します。漏洩のシナリオは、大きく 5 つに分類できます。

リスク 1 — ソースコードの流出

Claude Code は、明示的に指示しなくても 関連ファイルを自動で読み込み、推論時に Anthropic API へ送ります。設計上、不可避な動作です。どこまでのコードを送ってよいか を組織として決めていないと事故ります。公開 / 社内限り / 秘匿 の 3 階層で判定し、秘匿コードは ==.claudeignore でブロックする以前に、リポジトリを分けて物理的に隔離== します。

リスク 2 — 認証情報の流出

.env、credentials.json、*.pem、SSH 鍵、API トークン、DB 接続文字列 — これらは 流出した瞬間に被害が確定 します。Claude が誤って生成コードに貼り付けたり、/compact の要約として表に出たりするルートを、設定で塞ぎます。

リスク 3 — 顧客個人情報（PII）の流出

顧客の氏名、住所、購買履歴を Claude Code に直接渡す行為は、個人情報保護法上の 「委託」 に該当する可能性が高く、委託先管理義務 の対象になります。Anthropic は SOC 2 Type II / ISO 27001 取得済みですが、自社 DPA レビューと顧客通知の 2 点は法務確認必須です。

リスク 4 — 危険なコマンドの実行

rm -rf、git push --force、drop table、terraform destroy — 承認なしに実行できる状態は 運用継続性への直接の脅威。bypassPermissions を全員に推奨すると、事故 1 回で会社が止まります。

リスク 5 — 不正な MCP サーバーからの情報吸い取り

サードパーティ製 MCP は Claude のコンテキスト全体を読める 構造です。悪意のある / 雑な MCP を入れると、プロジェクトの内容が知らないサーバーに垂れ流される可能性があります。

データの送信先 — Anthropic API、リクエスト/レスポンスのフロー

「Claude Code は、何を、どこに送っているのか」 — この問いに、4 行で 答えられないままセキュリティ設計を進めるのは無理があります。ここでフローを正確に押さえます。

標準フロー（Anthropic API 直叩き）

Claude Code が 1 回の指示を処理する間に、次の通信が走ります。

[ローカル]
  ユーザー入力 + ファイル読込結果 (Read/Glob/Grep)
  + CLAUDE.md + settings.json + 過去の会話履歴
        │  HTTPS (TLS 1.3)
        ▼
[Anthropic API] api.anthropic.com → モデル推論
        │  HTTPS (TLS 1.3)
        ▼
[ローカル] Claude の応答 + ツール実行 (Write/Edit/Bash)

重要なポイントは 4 つ。①コードの中身が API リクエストに含まれる（Read した瞬間に乗る）/ ②過去の会話履歴も毎ターン再送（API はステートレス）/ ③通信は TLS 1.3 で暗号化（経路盗聴リスクはゼロ）/ ④Anthropic 側のログ保持 は Standard で 30 日、Zero Data Retention（ZDR）契約で即時破棄。

Anthropic 側のデータ取扱い

Anthropic は 顧客 API のデータをモデル訓練に使用しません（2026 年時点の公式ポリシー、Claude.ai Consumer とは別扱い）。とはいえ ログとして 30 日間保持 がデフォルトのため、その期間「Anthropic 内に自社コードのスニペットが存在する」状態を許容できるかを、自社ポリシーで判断します。

「送信しない」を選ぶ仕組み

==.claudeignore でブロックされたファイルは、そもそも読み込まれません==。読まなければ API リクエストにも乗りません。これが最も確実な「送らない」の作り方です。CLAUDE.md に「秘匿ファイルは触らないで」と書くのは指示として効くだけで、誤読の可能性はゼロにできません。「指示で禁止」ではなく「設定でブロック」 を原則にします。

機密情報の除外 — .claudeignore / .gitignore / permissions

3 つのファイル / 仕組みが、似ているようでまったく違う役割を果たしています。混同すると確実に事故ります。

3 つの違いを 1 表で整理

==.gitignore に書いてあっても Claude は読みます。3 つを 同時に揃える== のが基本構成です。

.claudeignore の標準テンプレート

組織共通テンプレートとして、次の内容を 全リポジトリのスキャフォルディング に入れます。

# === シークレット ===
.env
.env.*
credentials.json
service-account*.json
*.pem
*.key
*.crt
.aws/
.gcp/
.azure/
.ssh/
.secrets/
vault/

# === ローカル DB ===
*.sqlite
*.db
dumps/
backups/

# === 内部限定ドキュメント ===
docs/internal/
docs/m-and-a/
docs/legal/

組織で扱うデータの種類に応じて、医療データ、PCI-DSS 対象データ、輸出規制対象コード のディレクトリも追加します。.claudeignore は 肥大化しても問題ない ので、迷ったら入れておきます。

.gitignore との二重化が必須

==.env を .gitignore だけに入れ、.claudeignore に忘れる== のが最多ミス。「Git にはコミットされないが、Claude には読まれて Anthropic に送られる」状態になります。両方に必ず入れる運用をテンプレで担保します。

# 新規リポジトリ作成時のスキャフォルディング
cp ~/templates/.gitignore .gitignore
cp ~/templates/.claudeignore .claudeignore
cp -r ~/templates/.claude .claude
git add .gitignore .claudeignore .claude
git commit -m "chore: add security baseline"

permissions による書き込み / 実行制御

読むのを止める のが .claudeignore、書く / 実行するのを止める のが permissions です。.claude/settings.json の deny は ツール × 引数 の組み合わせで指定します。

{
  "permissions": {
    "deny": [
      "Write(.env)",
      "Write(.env.*)",
      "Write(**/credentials.json)",
      "Edit(.env)",
      "Edit(.env.*)",
      "Bash(cat .env)",
      "Bash(cat .env.*)",
      "Bash(cp .env*)"
    ]
  }
}

「Claude が .env を読まない」だけでなく、「.env を書き換えたり、cat で出力したりもできない」状態にします。これで、誤ったコンテキスト経由で .env の内容が露出するルートを完全に塞げます。

permissions の 3 段階運用 — allow / ask / deny の組み立て

.claude/settings.json の permissions には 3 つの判定 があります。==allow は確認なしに自動実行、ask は毎回確認（デフォルト）、deny は絶対拒否。allow と deny に書いていない操作は自動的に ask 扱い== です。組織標準としては、安全で頻度が高い読み取り系は allow に、破壊的 / 外部通信 / 認証情報系は deny に、中間は ask に残します。

組織標準テンプレート

全リポジトリの .claude/settings.json にコミットします。

{
  "permissions": {
    "allow": [
      "Read", "Glob", "Grep",
      "Bash(ls *)", "Bash(pwd)",
      "Bash(git status)", "Bash(git diff)", "Bash(git log*)",
      "Bash(npm test)", "Bash(npm run lint)",
      "Bash(npm run typecheck)", "Bash(npm run build)",
      "Bash(go test ./*)", "Bash(go vet ./*)"
    ],
    "deny": [
      "Bash(rm -rf *)", "Bash(sudo *)", "Bash(chmod 777 *)",
      "Bash(git push --force*)", "Bash(git reset --hard*)",
      "Bash(git checkout -- *)", "Bash(git filter-branch*)",
      "Bash(curl *)", "Bash(wget *)", "Bash(ssh *)", "Bash(scp *)",
      "Bash(aws *)", "Bash(gcloud *)", "Bash(kubectl *)",
      "Bash(terraform *destroy*)", "Bash(terraform *apply*)",
      "Bash(docker system prune*)", "Bash(dd *)",
      "Write(.env)", "Write(.env.*)",
      "Edit(.env)", "Edit(.env.*)",
      "Bash(cat .env*)", "Bash(cp .env*)"
    ]
  }
}

allow / deny を組織で標準化する 3 つのルール

①迷ったら deny — 事故時の被害が大きいものは全部 deny に入れて、必要だと声が上がってから外す。②allow は積極的に拡張 — 安全で頻度が高い操作（テスト・lint・git status 等）は迷わず allow に。ask が多すぎると承認疲れで全部 yes を押すようになる。③環境別に差分を持つ — 本番に近いリポジトリでは deny を厳しく、新規プロトタイプでは allow を緩く。

ask の戦略的活用

ask に残すのは 「人間が見れば判断できるが、機械では事前判定できない」 もの。Bash(npm install <パッケージ名>) は文字列を見ないと安全性が分からないので、allow にも deny にも入れず ask に残します。

API キー管理 — 環境変数、Secret Manager、ローテーション

API キーは Claude Code 組織運用の 最重要シークレット。漏洩すると コスト青天井 / 利用ログ閲覧 / 悪意ある書き換え の 3 つが同時に起こります。

3 層のキー管理

組織標準は次の 3 層構成。Layer 1 個人ローカル は OS Keychain 経由、Layer 2 CI/CD は GitHub Secrets / GitLab CI Variables、Layer 3 本番運用ボット は AWS Secrets Manager / GCP Secret Manager から IAM で都度取得。

# Layer 1 — macOS Keychain に保管、利用時のみ環境変数化
security add-generic-password -a "$USER" -s "anthropic-api-key" -w "sk-ant-..."
export ANTHROPIC_API_KEY=$(security find-generic-password \
  -a "$USER" -s "anthropic-api-key" -w)

# Layer 2 — GitHub Actions の Secrets から注入
# env:
#   ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

# Layer 3 — Cloud Run / Lambda は Secret Manager から都度取得、IAM で権限分離

==.zshrc に平文で書く== のは最低限避けます。ノート PC 盗難 1 回で全社キーが漏れます。

1 人 1 キー原則

組織導入で必ず守るべきは 「1 人 1 キー」。共有キーを使うと誰がいつ何に使ったか追えず、不正利用の犯人が分かりません。Anthropic Console の Workspace 単位 でキーを発行し、個人別に割り当てます。

100 人規模までは 1 人 1 キーが現実的。それを超える規模では Bedrock / Vertex 経由で IAM ロール認証に切り替える設計が定石です。

ローテーションのルール

「いつかやる」では絶対にやりません。情シスのチェックリストに次を組み込みます。①90 日定期ローテーション / ②退職日当日に該当キー Revoke（オフボーディングに必須項目化）/ ③漏洩疑い時は即時 Revoke + 全キー一斉ローテーション / ④Notion / スプレッドシートで台帳管理。

漏洩時の対応フロー

「漏れたかも」と感じた瞬間に次の順で動きます。①console.anthropic.com で該当キーを即座に Revoke / ②Usage ページで直近 24 時間の異常利用を確認 / ③アクセスログから利用 IP を特定 / ④情シス・セキュリティ責任者に 30 分以内に第一報 / ⑤PII を扱うコードに関与していたら法務に通知 / ⑥事後ふりかえりで漏洩経路と再発防止策を決定。

MCP サーバーの安全な選び方 — 信頼できる発行元、ローカル sandbox

第 8 章で扱った MCP は、Claude Code に外部ツールを接続する強力な機能です。一方で、MCP サーバーは Claude のコンテキスト全体にアクセスできる ので、雑に入れると情報吸い取りツールに化ける リスクがあります。

MCP のリスクモデル

MCP サーバーをインストールすると、Claude が ①サーバーが提供するツールをユーザー指示なしに呼ぶ / ②コンテキストの一部 / 全部をサーバーに送信 / ③サーバー応答をコンテキストに取り込む 挙動を取れるようになります。サーバー側コードの動作はユーザーから見えません。AI エージェントは 判断を委任している ぶん、悪意のあるサーバーの影響を強く受けます。

3 つの信頼レベル

組織で使う MCP は次の 3 段階で分類し、L1 のみ全社展開 / L2 は情シス承認制 / L3 は禁止 が現実的なラインです。

MCP サーバーの評価チェックリスト

新しい MCP を業務利用する前に、発行元 / OSS かどうか / メンテ頻度 / Issue 対応速度 / 外部通信先 / 認証情報要求の最小性 / コンテキスト送信範囲 / SOC 2・ISO 27001 取得状況 の 8 項目を確認します。

ローカル sandbox での隔離

未知の MCP は 専用の隔離環境 で動かします。本番 Mac で直接実行せず、Docker / Devcontainer / VM 上の最小権限環境を用意します。

# Docker で隔離環境を作る例(認証情報も別キー)
docker run -it --rm --name mcp-sandbox \
  -v $(pwd)/sandbox-data:/workspace:rw \
  -e ANTHROPIC_API_KEY=$SANDBOX_KEY \
  --read-only --tmpfs /tmp:rw --memory=2g --cpus=1 \
  node:20-slim bash

認証情報も別キーを使う のがポイント。サンドボックスから本番リソースにも個人機密にもアクセスできない状態を作ります。

MCP の deny リスト

permissions と同様、MCP も deny リストを持てます。組織で禁止する MCP を情シスが管理し、各リポジトリの settings.json に同期します。

{
  "mcp": {
    "denyServers": [
      "unknown-vendor/file-system-mcp",
      "github.com/random-user/auto-deploy-mcp"
    ]
  }
}

ログ・監査 — どのコマンドを誰がいつ実行したか追跡

「事故が起こったときに、後から追える状態」を作るのが監査の本体です。監査ログがない組織は、事故が起こっても原因が特定できず、再発防止も組めません。

Claude Code の標準ログ

Claude Code は ~/.claude/projects/<hash>/ 配下に JSONL 形式でセッションログを蓄積します。開始 / 終了タイムスタンプ・ユーザー入力・応答・実行ツール名と引数・承認 / 拒否の判定 が記録されます。ローカルにしか残らない ので、組織監査としては不十分です。

集約ログの設計

各個人のセッションログを中央集約 する仕組みを作ります。3 パターン。A シェルラッパー — claude をラップして終了時にクラウドストレージに rsync、シンプルだがローカル依存。B Usage API — Anthropic Console から定期取得、コマンド粒度は取れないがコスト + 監査に有用。C Bedrock / Vertex 経由 — CloudTrail / Cloud Audit Logs が自動でフル記録、エンタープライズ環境では最有力。

# パターン A のシェルラッパー例(/usr/local/bin/claude-audited)
#!/bin/bash
USER_EMAIL=$(git config user.email)
TS=$(date -u +%Y-%m-%dT%H:%M:%SZ)

command claude "$@"
EXIT_CODE=$?

LATEST=$(ls -t ~/.claude/projects/*/session-*.jsonl | head -1)
aws s3 cp "$LATEST" "s3://company-claude-audit/$USER_EMAIL/$TS.jsonl"
exit $EXIT_CODE

監査ダッシュボードの最小要件

情シスが月次レビューするための最小 5 項目。①利用者別月次トークン消費 / ②deny にヒットした操作一覧 / ③permissions の変更履歴 / ④退職者の最終利用日 / ⑤コスト上限超過アラート。

監査ログ自体のセキュリティ

監査ログは本体と同等以上に厳重に守ります。過去のユーザー入力 / 出力がそのまま記録されているため、ログ漏洩 = 半年分の業務内容漏洩。ストレージは WORM、アクセスは情シス + セキュリティ責任者のみ、アクセス自体を別ログに記録（メタログ）、保管期間は法令準拠で 1〜7 年。

SaaS / オンプレ運用の選択 — Anthropic、Bedrock、Vertex AI

Claude Code は Anthropic 直 API 以外に AWS Bedrock / GCP Vertex AI 経由でも動きます。組織のセキュリティ要件に応じて選びます。

3 つの経路の比較

選び方の基本指針

A 個人 / スタートアップ — Anthropic 直。手間が少なく、最新モデルが即日使える。B エンタープライズ / 金融 / 医療 — Bedrock or Vertex。既存 AWS / GCP の Enterprise Agreement で追加契約不要、自社クラウド境界を超えない、CloudTrail / Audit Logs が監査要件を自動で満たす。C 日本国内データ要件 — Bedrock 東京 or Vertex asia-northeast1 でデータ越境を回避。D ハイブリッド — 開発は Anthropic 直、本番は Bedrock / Vertex の組み合わせ。

設定例

Bedrock 経由で Claude Code を動かす設定。

# Bedrock 経由(東京リージョン)
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=ap-northeast-1
export ANTHROPIC_MODEL=anthropic.claude-sonnet-4-20250514-v1:0
aws configure sso && claude

# Vertex AI 経由(東京リージョン)
export CLAUDE_CODE_USE_VERTEX=1
export CLOUD_ML_REGION=asia-northeast1
export ANTHROPIC_VERTEX_PROJECT_ID=my-gcp-project
gcloud auth application-default login && claude

コストの違い

3 経路ともほぼ同等価格、AWS / GCP のコミット割引が効けば多少安くなる程度。コストだけで決めるのは正解とは限りません。データレジデンシー / 監査要件 / 既存クラウド契約のほうが優先度が高い判断軸です。

失敗パターン — 組織導入で実際に起こった事故

組織導入の現場で実際に発生した失敗を 4 つ紹介します。すべて 事前に設計しておけば回避できた 例です。

失敗 1 — 秘匿情報をリポジトリにコミット

失敗 2 — 危険なシェルコマンドを承認した

失敗 3 — 個人 API キーをチームで共有

失敗 4 — Sub-agent / MCP への過剰権限

監査チェックリスト 10 項目

組織導入が一段落した段階で、四半期 1 回 の監査を回します。次の 10 項目を順に確認します。

<Checklist id="intro-ch10-3-audit" items={["全リポジトリに .claudeignore が存在し、組織標準テンプレと差分がない","全リポジトリの .claude/settings.json の permissions.deny が組織標準を満たしている","個人 API キーは 1 人 1 キー、共有キーが存在しない","API キーの最終ローテーション日が 90 日以内","退職者のキーが Revoke 済みで、台帳と一致している","監査ログがクラウドストレージに集約されており、過去 90 日分が閲覧可能","コスト Hard Limit / Soft Limit が個人別に設定されている","MCP サーバーの利用一覧があり、すべて L1 / L2 信頼レベル","Bedrock / Vertex 経由の場合、CloudTrail / Cloud Audit Logs に Claude 呼び出しが記録されている","過去 90 日間にセキュリティインシデントが発生しておらず、もしくはインシデント対応報告が完了している"]} />

このチェックリストは 情シス / セキュリティ責任者が独立して実施、結果を CTO / CEO に四半期報告 として上げるのが理想。「現場が自分で監査」では緩みが入るため、監督と現場を分離 するのが鉄則です。

経営層・情シスへの説明スライド構成

技術用語に詳しくない聴衆向けに、5 枚 を超えないように作ります。

スライド 1 何を守るか — ソースコード / 認証情報 / 顧客個人情報の 3 資産。漏洩時の最大被害を金額換算で示す。

スライド 2 どう漏れるか — リスク 5 シナリオを 絵で 説明。コード送信フロー、危険コマンド、MCP からの情報吸い取り。技術的正確さより「どこに穴があるか」が直感的に分かることが重要。

スライド 3 3 重防御の構成 — .claudeignore / permissions / 監査ログを 1 枚の概念図 に。「読まない / 書けない / 後から追える」のメッセージ。

スライド 4 運用ルール — 1 人 1 キー / 90 日ローテーション / 退職時 Revoke / MCP ホワイトリスト / 四半期監査 の 5 つ。項目ごとに責任者の役職 を明記。

スライド 5 コストとリスクのバランス — 完璧と無防備の中間点を示し、Phase 1 → 4 のロードマップで段階的に強化する旨を補足。

まとめ

このレッスンで押さえた Claude Code セキュリティ実装 の要点 8 つ。

1. データの送信先 — Read した時点で内容は Anthropic API に流れる。「指示で禁止」ではなく「ファイルシステムで隔離」が原則
2. 3 重防御 — .gitignore / .claudeignore / permissions.deny の 3 つを同時に揃える
3. permissions の 3 段階 — allow / ask / deny。迷ったら deny
4. 1 人 1 キー + 90 日ローテーション — 共有キー禁止、退職時即時 Revoke、Secret Manager 経由
5. MCP は 3 段階の信頼レベル — L1 のみ全社、L2 は情シス承認制、L3 は禁止
6. 監査ログは必ず集約 — Bedrock / Vertex 経由なら自動で監査要件を満たす
7. SaaS / Bedrock / Vertex の使い分け — パイロットは Anthropic 直、全社展開時にクラウドベンダー経由
8. 四半期 1 回の独立監査 — 現場と監督を分離、CTO / CEO に報告

セキュリティは「一度設定して終わり」ではありません。Claude Code は半年で挙動が変わり、MCP は週単位で増えます。運用ルール・設定・ローテーションを 生き物 として扱う組織だけが、長期的に安全な状態を保てます。

<Quiz question="Claude Code で .env ファイルを Anthropic API に絶対送信させないために、最も確実な方法はどれですか？" options={["CLAUDE.md に「.env を読まないでください」と書いておく",".gitignore に .env を追加する",".claudeignore に .env を追加し、permissions.deny で Read(.env) も拒否する"]} answer={2} />

<Checklist id="intro-ch10-3" items={["Claude Code のデータ送信フローを 4 行で説明できる",".gitignore / .claudeignore / permissions の役割の違いを明確に説明できる","allow / ask / deny の 3 段階を組織標準として設計できる","1 人 1 キー + 90 日ローテーションの運用フローを描ける","MCP サーバーの 3 段階信頼レベルで自社の利用 MCP を分類できる","監査ログをクラウドストレージに集約する設計を 1 つ持っている","Anthropic / Bedrock / Vertex の 3 経路から自社用の選択ができる","10 項目の監査チェックリストで自社の穴を見つけた"]} />

これで Claude Code 入門ガイドの全 30 レッスンが完了しました。おめでとうございます。ここから先は 実際に手を動かして組織に根付かせる フェーズ。10-1 のチャンピオン制度、10-2 の Cowork 設計、本レッスンのセキュリティ実装を自社文脈に翻訳して半年・1 年単位で運用し続けることで、Claude Code が「便利ツール」から「組織の生産性インフラ」へ 育ちます。

次のステップ

• 10-1: チーム活用 — チャンピオン制度の設計を読み返して、社内ロードマップに落とし込みましょう
• 10-2: Claude Cowork — Cowork 設計とオンボーディング教材の整え方をもう一度確認できます
• 9-1: API 料金の仕組み — 全社展開の前にコスト見積もりを精緻化したい方におすすめです