Claude Code セキュリティガイド｜法人導入のリスク評価と社内規約テンプレ【2026年版】

なぜ Claude Code は法人導入で監査対象になるのか

Claude Code は コードを編集する権限を持つ AI エージェント です。エディタ補完 (GitHub Copilot 等) とは異なり、ファイル編集・コマンド実行・複数ファイル横断の自律実行が可能。これは 生産性向上の源泉 であると同時に、情報セキュリティ・コンプライアンスの監査対象 になる新領域です。

法人導入時に監査対象となる 5 領域:

領域	主なリスク
1. ファイルアクセス	機密ファイル (.env, 認証情報, 顧客 DB) の読込・送信
2. コマンド実行	破壊的コマンド (rm -rf, git push --force, 本番 DB 操作)
3. 認証情報	API キー・SSH 鍵・パスワードの取扱
4. 出力コード	著作権侵害・脆弱性混入・依存ライブラリ追加
5. ベンダー契約	データ取扱方針 (DPA)・ZDR・SLA

各領域について、具体的な統制方法を以下で解説します。

1. ファイルアクセス制御

Claude Code のファイル読込ルール

Claude Code は CLAUDE.md と設定ファイルで「読み込んでよいファイル」を制御できます:

CLAUDE.md (プロジェクト規約) に書く:

## やってはいけないこと

- `.env`, `.env.*`, `credentials.json`, `*.pem` を読み込まない
- `/etc/`, `~/.ssh/`, `~/.config/` 配下を読み込まない
- 顧客個人情報を含むテストデータ (`tests/fixtures/customer_*.json`) を読み込まない
- `.env` や認証情報をコミット対象に含めない

これで Claude Code は対象ファイルへの操作を試行する前に確認します。完全な保証ではないため、.gitignore の整備・hooks による pre-commit チェック・CI でのシークレット検出 (gitleaks 等) を併用するのがセキュリティ多重化の基本。

機密ファイルを誤って読み込まれた場合の検知

Anthropic は ZDR (Zero Data Retention) を有効化すれば送信ログも残しません。ZDR を有効化していない場合、Anthropic Console の API logs で送信内容が確認可能。誤送信が判明したら、関係する認証情報を即時 revoke + 影響範囲調査 + インシデント記録、の流れが標準対応。

2. コマンド実行の統制

破壊的コマンドの自動拒否

Claude Code は以下のコマンドを実行前に必ず確認します:

• rm -rf / rm -r (再帰削除)
• git push --force / git reset --hard
• systemctl stop / systemctl disable
• DROP TABLE / DELETE FROM (データベース)
• docker rm / docker volume rm

ただし「事前許可」を出している場合は確認を省略します。法人運用では:

## 破壊的コマンドの事前許可は禁止

- 確認プロンプトを「常に表示」設定にする
- bypass-permission フラグの使用は禁止
- 開発者個人での settings.json 上書きは git で監査可能にする

本番環境への接続制限

## 本番接続の制限

- 本番 DB の接続文字列を CLAUDE.md にハードコードしない
- prod_db_url, prod_api_url 等の env を Claude セッションでは使わない
- staging / development 環境のみで実装・テストし、本番デプロイは別パイプライン

3. 認証情報の取扱

API キー管理のベストプラクティス

個人開発	法人開発
Claude Pro/Max サブスクリプション	Anthropic Console で Workspace 別キー
ANTHROPIC_API_KEY 環境変数	1Password / AWS Secrets Manager 等で管理
単一アカウント	退職者は即時 revoke、四半期で全キー rotation

Anthropic Console では Workspace 単位でキーを発行可能。「Engineering」「Data Science」など部門別に Workspace を作り、利用 spike や予算上限を別個に監視します。

.env コミット防止の多層化

1. Claude 側: CLAUDE.md に「.env はコミットしない」と明記
2. Git 側: .gitignore に .env, .env.*, *.pem 等
3. Pre-commit hook: gitleaks / detect-secrets で commit 前検査
4. CI 側: GitHub Actions で push 後の secret スキャン
5. GitHub 側: Secret Scanning Push Protection を有効化

これらすべてを組み合わせると、誤って .env を push する確率は 5 段階のフィルタを通り抜ける必要があり、実用上ほぼゼロになります。

4. 出力コードの監査

「AI が書いたコード」のレビューチェックリスト

通常のコードレビューに加えて、以下 5 観点を専用チェック:

• 依存追加の正当性: 新規ライブラリを安易に追加していないか? 既存依存で代替可能では?
• 既存ユーティリティの再利用: utils/ 配下を grep して類似実装が既にないか確認したか?
• try/except の握り潰し: 本来 raise すべき例外を catch して空処理にしていないか?
• 過剰なコメント: 自明なコメントを大量に書いていないか? 削減すべき
• 著作権類似性: GitHub Copilot Telemetry / Sourcegraph 等で既存 OSS との類似度をチェック

PR ラベル ai-assisted を必須化し、レビュアーがこの 5 観点を意識的に見るルールを徹底します。

脆弱性の検出

AI 出力コードの脆弱性検出には:

• SAST (Snyk Code / SonarQube / GitHub CodeQL): SQL インジェクション、XSS、パストラバーサル等
• 依存スキャン (Snyk / Dependabot / OSV-Scanner): 既知脆弱性のあるライブラリ追加検知
• Secrets scanning (gitleaks / detect-secrets): 認証情報の混入検知
• License scanning (FOSSA / Black Duck): 不適合ライセンスの混入検知

これらは AI が書いたコードに限らず必須ですが、AI 導入で書かれるコード量が増える分、自動検査の比重を上げる組織が多いです。

5. ベンダー契約・データ取扱方針

Anthropic 直送信構成

• メリット: 最新モデル (Sonnet 4.x, Opus 4.x) が即時利用可能、料金最安
• デメリット: コードが Anthropic 米国データセンターに送信される (ZDR で軽減可)

AWS Bedrock 経由

• メリット: AWS テナント内処理、AWS IAM ガバナンス、BAA / SOC2 / ISO27001 統合
• デメリット: モデル提供にラグ (Anthropic 直よりも 1-3 ヶ月遅れる傾向)、料金やや割高

Google Vertex AI 経由

• メリット: GCP テナント内処理、GCP IAM 統合、PII 自動削除機能あり
• デメリット: Bedrock より採用例少なめ、モデル提供ラグ

選択基準

業種	推奨	理由
一般 SaaS / Web 系	Anthropic 直 (ZDR)	最新モデル + 料金最安
金融・銀行	Bedrock	既存 AWS ガバナンス活用
医療	Bedrock or Vertex	BAA 必須、HIPAA 対応
防衛・政府	個別評価必要	FedRAMP / CMMC 等の要件次第
Google Workspace 中心	Vertex AI	GCP 統合

Claude Code 社内規約テンプレ (5 セクション)

以下を自社用にカスタマイズして「AI 利用ガイドライン」として展開してください。

セクション 1: 基本ルール

1. Claude Code の利用は `ai-assisted` ラベル付きの PR で明示する
2. 設計判断 (アーキテクチャ・データモデル・API 仕様) は人間が決定する
3. 実装の量産部分は Claude に任せ、必ず diff を目視確認する
4. 機密情報 (個人情報・顧客情報・認証情報) を含むファイルは読み込ませない

セクション 2: 禁止行為

1. .env, credentials.json, *.pem の Claude への送信
2. 本番 DB / 本番 API への直接接続を伴うタスク依頼
3. 破壊的コマンド (rm -rf, git push --force) の事前許可
4. 退職予定者による Claude セッション継続
5. 顧客個人情報を含むデータでのテスト依頼

セクション 3: API キー管理

1. Anthropic Console の Workspace を部門別に分ける
2. 個人 API キーは 1Password / AWS Secrets Manager で管理
3. キーは四半期で rotation、退職時は即時 revoke
4. 個人 Pro / Max 契約は会社経費精算で統一管理

セクション 4: レビュー基準

1. ai-assisted ラベル付き PR は専用チェックリスト適用
2. 依存追加・既存ユーティリティ再利用・例外握り潰し・著作権類似性を必須確認
3. テストカバレッジは通常 +10% を目安
4. 大規模変更 (50+ ファイル) は事前計画レビュー必須

セクション 5: インシデント対応

1. 機密情報誤送信判明 → 関係キー revoke + 影響範囲調査 + Anthropic に inquiry
2. .env 等のコミット判明 → force-push で履歴除去 + キー revoke + 監査ログ更新
3. AI 由来の脆弱性発覚 → 通常の脆弱性対応プロセス + AI 利用箇所の追加調査
4. インシデント記録は AI 利用ガイドラインの改訂材料に

監査でよく聞かれる質問への回答テンプレ

Q: AI ベンダーは何を使っていますか?

Anthropic Claude を Anthropic API 直接または AWS Bedrock 経由で利用。データ取扱は Anthropic Commercial Terms / AWS DPA に準拠、入力データは学習に使わない設定。ZDR (Zero Data Retention) を有効化済。

Q: 機密情報の漏洩防止策は?

(1) CLAUDE.md でファイル読込制限、(2) .gitignore + pre-commit hook + CI シークレット検出の 3 段階フィルタ、(3) Anthropic Workspace の権限分離、(4) 四半期キー rotation、(5) インシデント発生時の即時 revoke 手順を整備。

Q: 退職者の対応は?

Anthropic Console から該当 API キーを即時 revoke。共有 Workspace の利用権限を削除。退職者が CLAUDE.md / Pro 個人契約を持っていた場合は法人プラン Owner で seat を回収。

Q: AI 由来の脆弱性が出た場合は?

通常の脆弱性対応プロセスに加え、(1) AI 利用箇所の特定 (ai-assisted ラベル付き PR の grep)、(2) 同様パターンの横展開リスク評価、(3) AI 利用ガイドラインの改訂を実施。

法人での実装力定着が次のステップ

セキュリティガイドラインを整備しても、実際にエンジニアが Claude Code を使いこなせなければ ROI は出ません。実装演習を組織で展開するのが王道。

法人向け AI 研修: /lms/solutions/corporate で Owner 進捗 CSV + Slack 通知 + RAG チャット付きのチーム運用が可能。 中小企業向け: /lms/solutions/smb で 5 seat ¥288K/年 から段階導入。 概念把握には Anthropic Academy + 本サイトの実践 40 レッスン (4 週間限定無料): /lms/free/vibe-practice

関連ガイド:

• Claude Code 入門 — CLI セットアップから CLAUDE.md
• バイブコーディングとは — AI ペアプロの基礎と組織導入の 3 段階
• Anthropic Academy vs 実装力定着型研修 — 概念入門と実装演習の役割分担
• Claude Code vs Cursor 比較 — エディタ統合 AI ツールとの使い分け
• MCP 入門 — 社内ツール連携時のセキュリティ考慮事項
• AI Agent SDK 入門 — Agent 本番運用の 5 つの落とし穴

まとめ

• Claude Code 法人導入は 5 領域 (ファイル/コマンド/認証/出力/ベンダー) で監査対象
• CLAUDE.md + .gitignore + pre-commit + CI + GitHub Secret Scanning の 5 段階フィルタ
• AWS Bedrock / Vertex AI 経由でガバナンス要件に対応 (規制業種向け)
• 「AI が書いたコード」のレビューは 5 観点 (依存追加・再利用・例外・コメント・著作権) で
• 社内規約 5 セクションをコピペで導入可能、四半期で更新