Claude Codeのセキュリティと社内導入時の注意点｜法務・情シス向け

開発チームから「Claude Codeを導入したい」と申請が上がってきたとき、セキュリティ部門・法務・情シスが最初に知りたいのは「社内のコードやデータはどこに送られ、どう扱われるのか」です。この問いに対して、開発側が「たぶん大丈夫です」と曖昧に回答してしまうと、導入が数ヶ月単位で遅延する原因になります。

本記事は、Claude Codeの社内導入を審査・承認する立場の方（セキュリティ、法務、情シス）と、申請する側の開発チームの両方に向けて、承認プロセスを効率的に進めるための情報を整理します。データフローの正確な理解、Anthropicのデータポリシーの要点、Bedrock/Vertexによる閉域構成、そして社内承認で実際に求められる4つの資料のテンプレートを提供します。

Claude Codeの機能面についてはClaude Code完全ガイドを、料金体系については料金プラン解説を参照してください。

結論 — 「何が送信されるか」を正確に把握し、ポリシーと照合するのが出発点

Claude Codeのセキュリティ評価で最も重要なのは、感覚ではなくファクトに基づいた判断です。「コードが外部に送られるのは危険」という直感的な反応は理解できますが、「何が、どこに、どのような条件で送信され、どう扱われるのか」を具体的に分解すれば、合理的なリスク評価が可能です。

判断のフレームワークはシンプルです。

1. データフローの可視化: 入力 → 送信 → 処理 → 出力の各段階で何が起きるか
2. ベンダーポリシーの確認: Anthropicのデータ取扱方針（学習利用・保存期間・アクセス範囲）
3. 構成の選択: 直接API / Bedrock / Vertex のどの構成を採用するか
4. 自社ポリシーとの照合: 上記1〜3を自社のセキュリティポリシーに当てはめる

この4ステップを順に進めれば、「禁止」でも「無条件許可」でもない、条件付き許可の設計が可能になります。

データフロー — 入力から出力まで何が起きるか

Claude Codeを使用する際のデータの流れを4段階に分解して解説します。セキュリティ審査では、各段階で「何が、どこに、どのように」を把握することが重要です。

段階1: 入力（開発者のローカル環境）

開発者がClaude Codeに指示を出すと、以下のデータがローカル環境で収集されます。

• ユーザーの指示文（プロンプト）
• タスク遂行に必要なファイルの内容: Claude Codeがタスクに関連すると判断したソースコードファイル
• プロジェクトのメタ情報: ディレクトリ構造、設定ファイルの内容など

重要なポイントとして、リポジトリ全体が送信されるわけではありません。Claude Codeはタスクに必要な範囲のファイルを選択的に読み取ります。ただし、どのファイルが読み取られるかは Claude Code の判断に依存するため、機密ファイルが意図せず含まれる可能性は排除できません。

段階2: 送信（ローカル → API）

収集されたデータは、HTTPS（TLS 1.2以上）で暗号化された通信路を通じてAPIサーバーに送信されます。送信先は構成によって異なります。

構成	送信先	通信経路
Anthropic直接API	Anthropicのサーバー	インターネット経由（HTTPS）
AWS Bedrock	AWSインフラ	VPC内 or VPN経由
Google Vertex AI	Google Cloudインフラ	VPC内 or VPN経由

段階3: 処理（APIサーバー側）

送信されたデータをもとに、Claudeモデルが推論を行い、応答を生成します。この処理は構成に応じたインフラ上で実行されます。

段階4: 出力（API → ローカル環境）

生成された応答（コードの変更提案、コマンド実行の提案など）がローカル環境に返されます。Claude Codeのパーミッションモデルに基づき、ファイルの変更やコマンドの実行は開発者の承認を経て実行されます。

データフロー図のまとめ

[開発者のローカル環境]
  │
  │ 指示文 + コンテキスト（関連ファイル）
  │
  ▼
[HTTPS暗号化通信]
  │
  ▼
[APIサーバー]  ← Anthropic直接 / AWS Bedrock / Google Vertex AI
  │
  │ 推論処理（モデルによるコード生成）
  │
  ▼
[HTTPS暗号化通信]
  │
  ▼
[開発者のローカル環境]
  │
  │ 変更提案の表示 → 開発者が承認 → ファイルに反映
  ▼
[ローカルファイルシステム]

Anthropicのデータ取扱方針 — 確認すべき3つのポイント

セキュリティ審査でベンダーのデータポリシーを確認する際、以下の3点が最重要です。

ポイント1: API経由のデータは学習に使用されない

Anthropicは、API経由で送信されたデータをモデルの学習に使用しない方針を公表しています。これは利用規約およびプライバシーポリシーに明記されています。

Claude Codeは内部的にAnthropicのAPIを呼び出すため、Claude Code経由で送信されたコードもこの方針の適用対象です。

ただし、この方針はAnthropicの直接APIを利用する場合に適用されます。Bedrock / Vertex経由の場合は、AWS / Googleのデータ取扱方針も併せて確認する必要があります。

ポイント2: データの保存と保持期間

APIリクエストのログは、安全対策・不正利用防止の目的で一定期間保持される場合があります。保持期間やアクセス範囲の詳細は、Anthropicの公式ドキュメントに記載されています。

社内審査では、**「データが保持される可能性がある期間」と「保持されたデータにアクセスできる人物の範囲」**を確認し、自社のデータ分類基準と照合してください。

ポイント3: Trust & Safety目的のレビュー

Anthropicは、利用規約違反の検知や安全性の確保のために、送信データの一部を人間がレビューする場合があることをポリシーに記載しています。これは「学習利用」とは異なるカテゴリの処理ですが、機密性の高いコードが人間の目に触れる可能性として認識しておく必要があります。

閉域構成（Bedrock / Vertex）を採用した場合、このTrust & Safetyレビューの適用範囲が異なる可能性があります。具体的な条件は各クラウドプロバイダーの契約内容を確認してください。

重要: 上記はいずれも執筆時点の情報です。ポリシーは更新される可能性があるため、導入判断の際は必ずAnthropicの最新のプライバシーポリシーを直接確認してください。

Bedrock / Vertex AI — 閉域構成の設計

規制の厳しい業界（金融、医療、官公庁など）や、自社のセキュリティポリシーが「社外クラウドへの直接的なデータ送信を禁止」している場合、AWS BedrockまたはGoogle Cloud Vertex AI経由でClaudeモデルを利用する閉域構成が選択肢になります。

AWS Bedrock経由の構成

AWS Bedrockを利用する場合、以下のセキュリティ上の利点があります。

• データの閉じ込め: データはAWSインフラ内で処理され、Anthropicのサーバーに直接送信されない
• 既存セキュリティ基盤の活用: VPC、IAM、CloudTrail、KMS（暗号化キー管理）などを統合できる
• 監査ログの統合: CloudTrailで全APIコールを記録し、既存のSIEM基盤に流せる
• コンプライアンス認証: SOC 2、ISO 27001、HIPAA BAA、PCI DSSなどのAWSの認証適用範囲に含まれる
• PrivateLink対応: インターネットを経由せず、AWSの内部ネットワーク経由でアクセス可能

Claude CodeからBedrock経由でClaudeを利用する場合、環境変数で接続先を指定します。

# Bedrock経由での利用設定
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=ap-northeast-1
export ANTHROPIC_MODEL=anthropic.claude-sonnet-4-20250514-v1:0

Google Cloud Vertex AI経由の構成

Google Cloud Vertex AIを利用する場合の利点は以下の通りです。

• データの閉じ込め: データはGoogle Cloudインフラ内で処理される
• 既存セキュリティ基盤の活用: VPC Service Controls、IAM、Cloud Audit Logsとの統合
• リージョン指定: データが処理されるリージョンを指定可能
• コンプライアンス認証: SOC 1/2/3、ISO 27001、FedRAMPなどの認証適用範囲

# Vertex AI経由での利用設定
export CLAUDE_CODE_USE_VERTEX=1
export CLOUD_ML_REGION=asia-northeast1
export ANTHROPIC_VERTEX_PROJECT_ID=your-project-id

構成の比較表

観点	Anthropic直接API	AWS Bedrock	Google Vertex AI
データの送信先	Anthropicサーバー	AWSインフラ	Google Cloudインフラ
学習利用	なし（ポリシー準拠）	AWSの契約に準拠	Googleの契約に準拠
ネットワーク	インターネット	VPC / PrivateLink	VPC Service Controls
監査ログ	Anthropicダッシュボード	CloudTrail	Cloud Audit Logs
コンプライアンス認証	SOC 2	SOC 2, ISO 27001, HIPAA等	SOC 1/2/3, ISO 27001等
導入の容易さ	最も簡単	AWSの知識が必要	GCPの知識が必要
コスト	API従量課金	AWS料金体系	GCP料金体系

推奨: すでにAWSまたはGoogle Cloudを利用している場合は、既存のクラウド基盤上にBedrock / Vertex経由の構成を構築するのが最も効率的です。新規にクラウド基盤を構築するコストと比較して、直接APIの利用をセキュリティポリシーの範囲内で許可する方が現実的なケースもあります。

社内承認に必要な4つの資料

Claude Codeの社内導入を申請する際に、セキュリティ部門や法務から実際に求められる資料を4つ整理します。それぞれの資料に含めるべき項目も具体的に示します。

資料1: データフロー図

上述の4段階（入力 → 送信 → 処理 → 出力）を、自社の環境に当てはめた図を作成します。

含めるべき項目は以下の通りです。

• 送信されるデータの種類（ソースコード、設定ファイル、テストデータ）
• 送信先（Anthropic直接 / Bedrock / Vertex）
• 通信の暗号化方式（TLS 1.2以上）
• データの保存場所と保持期間
• 返却されるデータの種類（コード提案、コマンド提案）
• 送信されないデータの明示（.envファイル、認証情報など — 設定による除外）

資料2: ベンダーセキュリティ評価

Anthropicのセキュリティ体制に関する情報を、自社のベンダー評価テンプレートに当てはめて整理します。

参照すべき公式情報は以下の通りです。

• プライバシーポリシー: データの収集・利用・保持に関する方針
• 利用規約: サービスの利用条件
• セキュリティ情報: セキュリティ体制・認証に関する情報

Bedrock / Vertex経由の場合は、AWS / GoogleのSecurity Whitepaperや第三者監査レポート（SOC 2レポートなど）も添付すると承認が通りやすくなります。

資料3: アクセス制御・利用ルール

社内でのClaude Codeの利用範囲を定めるルールを文書化します。

# Claude Code 社内利用ルール（例）

## 利用資格
- 対象: 開発部門の正社員・業務委託（NDA締結済み）
- 承認: 部門長の事前承認が必要

## 利用可能なリポジトリ
- 社内ツール・管理画面系: 利用可
- 顧客向けプロダクション: チームリードの承認後に利用可
- 認証・決済・個人情報を扱うコード: 利用不可（または Opus モデルでのレビュー専用）

## 禁止事項
- 本番環境の認証情報・APIキーをプロンプトに含めない
- 顧客の個人情報をテストデータとして入力しない
- Claude Codeの出力をレビューなしで本番環境にデプロイしない

## ログ管理
- Claude Codeの操作ログは [期間] 保持する
- インシデント発生時に操作ログを提出できる体制を整備する

資料4: リスク評価シート

上記3つの情報をもとに、自社のセキュリティポリシーとの適合性を評価するシートを作成します。

# リスク評価シート（例）

## リスク1: ソースコードの外部送信
- 影響度: 中〜高
- 発生可能性: 確実（ツールの仕様上）
- 対策: Bedrock/Vertex経由の閉域構成を採用 / 機密コードの除外設定
- 残存リスク: 許容可能

## リスク2: 機密情報の意図しない送信
- 影響度: 高
- 発生可能性: 低（設定で除外可能）
- 対策: .claudeignore で機密ファイルを除外 / 利用ルールで禁止事項を明示
- 残存リスク: 許容可能（教育と設定で対処）

## リスク3: 生成コードの品質・セキュリティ
- 影響度: 中
- 発生可能性: 中
- 対策: コードレビュー必須 / セキュリティスキャン（SAST）をCI/CDに組み込み
- 残存リスク: 許容可能（既存のレビュープロセスでカバー）

## 総合判定
- 判定: 条件付き許可
- 条件: [上記の対策を全て実施すること]

パーミッションモデルの設計

Claude Codeには、ツールが実行できる操作の範囲を制御するパーミッションモデルがあります。社内導入では、このパーミッション設定を適切に設計することが重要です。

パーミッションの種類

Claude Codeの操作は大きく以下のカテゴリに分類されます。

• ファイルの読み取り: ソースコードや設定ファイルの参照
• ファイルの書き込み: コードの追加・変更
• コマンドの実行: ターミナルコマンドの実行（テスト、ビルドなど）
• ネットワークアクセス: 外部APIへのリクエスト

社内向けパーミッション設計の指針

# パーミッション設計（例）

## 許可する操作
- プロジェクトディレクトリ内のファイル読み取り
- プロジェクトディレクトリ内のファイル書き込み
- テスト・ビルド・Lintコマンドの実行

## 承認が必要な操作
- 新しいパッケージのインストール（npm install）
- git操作（commit, push）
- シェルスクリプトの実行

## 禁止する操作
- プロジェクトディレクトリ外へのアクセス
- 本番環境への接続コマンド
- sudo権限での実行

Claude Codeのセッション開始時に、各操作の許可・拒否を設定できます。チーム開発では、この設定をCLAUDE.mdや設定ファイルで統一しておくことで、個人の判断による設定漏れを防げます。

.claudeignore による機密ファイルの除外

.gitignore と同様の構文で、Claude Codeが参照しないファイルやディレクトリを指定できます。

# .claudeignore の記述例
.env
.env.*
credentials/
secrets/
**/config/production.*
**/keys/
*.pem
*.key

この設定により、認証情報や暗号鍵が意図せずClaude Codeのコンテキストに含まれることを防げます。

導入時の実務的な進め方

ステップ1: 小規模な試験導入

全社一斉導入ではなく、1〜2チーム・数リポジトリの範囲で試験導入から始めるのが現実的です。

試験導入で確認すべき項目は以下の通りです。

• 利用ルールが現場で運用可能か
• パーミッション設定が適切か（緩すぎないか、厳しすぎないか）
• 開発者の利便性とセキュリティのバランスが取れているか
• インシデント発生時の対応フローが機能するか

ステップ2: 評価と改善

試験導入期間（推奨: 1〜3ヶ月）の後、以下を評価します。

• セキュリティインシデントの有無
• 利用ルールへの違反の有無
• 開発生産性への影響（定量的に測定できれば理想）
• 開発者からのフィードバック

ステップ3: 範囲の拡大

試験導入の結果を踏まえて、利用ルールを必要に応じて調整し、対象チーム・リポジトリを段階的に拡大します。

他ツールとの比較 — フレームワークの統一

Claude Code以外にもGitHub Copilot、Cursor、Amazon Q Developerなど、コードが外部に送信されるAI開発ツールは複数あります。いずれも「ソースコードを外部APIに送信する」という基本的なデータフローは共通しています。

ツール単体のリスク比較よりも、「AI開発ツール全般に適用するセキュリティ評価フレームワーク」を社内で策定しておく方が、長期的には効率的です。フレームワークがあれば、新しいツールの導入検討時にも同じ基準で迅速に判断できます。

まとめ — 「禁止」ではなく「条件付き許可」の設計を

AIコーディングツールの導入は、今後避けて通れない流れです。重要なのは、「危険だから禁止する」ではなく、「どの条件を満たせば許可できるか」を明確にすることです。

• データフローを正確に可視化し、何が送信されるかを把握する
• Anthropicのデータポリシーを公式ソースで確認し、自社基準と照合する
• Bedrock / Vertexの閉域構成を検討し、自社のセキュリティ要件に合った構成を選ぶ
• 4つの承認資料（データフロー図、ベンダー評価、利用ルール、リスク評価）を整備する
• パーミッションモデルと .claudeignore で技術的な制御を実装する
• 試験導入 → 評価 → 拡大の段階的プロセスで進める

これらを整理すれば、セキュリティ部門として「条件付き許可」の合理的な判断が可能になります。開発チーム側も、上記の資料を事前に準備してから申請すれば、承認プロセスを大幅に短縮できます。