「Claude Codeを入れると情報漏洩しないか」という質問に対して、担当者が答えられずに導入検討が止まる、という相談を受けることがある。だが実際に公式ドキュメントを読むと、確認すべき点はそれほど多くない。「学習に使われるか」「どこにどれだけ残るか」「どこまで技術的に塞げるか」の3系統、具体的には6項目に分解できる。それぞれの合否基準と、詰まりやすい箇所を整理する。
確認すべき6項目
- 学習利用ポリシー
- 保持期間とローカルキャッシュ
- サンドボックスによるネットワーク・ファイルアクセス制御
- MCPサーバー経由のデータ処理
- 組織全体のガバナンス（managed settings）
- フィードバック・セッションログの送信経路
1. 学習利用ポリシー
公式ドキュメントは、Team・Enterprise・API・サードパーティプラットフォーム・Claude Govを含む「商用ユーザー」について、「顧客がDevelopment Partner Programのような形で明示的にデータ提供を選ばない限り、商用契約でClaude Codeに送られたコードやプロンプトを使ってモデルを学習することはない」と明記している。
合否基準： 契約がTeam/Enterprise/APIの商用契約になっているか、Development Partner Programに(意図せず)opt-inしていないかを確認する。
詰まりやすい箇所： 個人のFree/Pro/Maxアカウントは、学習利用の可否を選べる設定になっており、オンにしている場合はそのアカウントでのClaude Code利用データも学習に使われる。「会社で契約しているから大丈夫」と思っていても、実際に使っているのが個人アカウントなら前提が変わる。
2. 保持期間とローカルキャッシュ
同じドキュメントによると、商用ユーザーの保持期間は標準30日。ゼロ保持(Zero Data Retention/ZDR)は「Claude for Enterpriseの適格なアカウントに限定」して提供され、標準のEnterpriseプランには含まれない。アカウントチームへの個別申請と審査を経て組織単位で有効化される。
見落としやすいのがローカル側だ。Claude Codeのクライアントは、セッションの再開を可能にするため、セッションのやり取りをローカルの~/.claude/projects/配下に平文で保存する。既定の保持期間は30日で、cleanupPeriodDaysで調整できる。
合否基準： 自社の要件が「学習に使われないこと」で足りるのか、「保持もされないこと」まで必要かを先に決める。前者なら商用契約の標準設定で足り、後者ならEnterpriseへの移行とZDRの個別申請が要る。
詰まりやすい箇所： ZDRを契約すればサーバー側の保持はなくなるが、ローカルのキャッシュは別の設定(cleanupPeriodDays)で管理されている。共有端末や紛失リスクが高い環境で運用するなら、この期間を短く設定するか、端末側の暗号化(ディスク暗号化)と合わせて考える必要がある。
3. サンドボックスによるネットワーク・ファイルアクセス制御
公式ドキュメントによると、Manual modeでは既定でClaude Codeは起動したフォルダとそのサブフォルダにしか書き込めず、親ディレクトリの変更には明示的な許可が必要になる。加えてサンドボックス機能を有効にすると、OSレベルのファイルシステム・ネットワーク分離を追加でき、到達できるドメインを許可リストで絞り込める。
合否基準： 機密情報を含むディレクトリへのアクセス範囲と、到達可能なネットワーク先を、既定の書き込み境界だけに頼らず明示的に絞っているか。
詰まりやすい箇所： ネットワーク面の許可・拒否をWebFetchツールの許可ルールだけで管理しようとすると穴が残る。Bashコマンドの実行自体を許可していれば、curlやwgetで同じ宛先に到達できてしまうため、ネットワークの制御はサンドボックスの許可リストで塞ぐ必要がある。この4つの壁の関係は以前の記事で詳しく扱った。
4. MCPサーバー経由のデータ処理
公式ドキュメントは、MCPサーバーについて「Anthropicは掲載基準に沿ってディレクトリに追加する前にレビューするが、MCPサーバーそのもののセキュリティ監査や管理は行わない」と明記している。信頼できる提供元のサーバーを使うか、自社でMCPサーバーを書くことを推奨する書き方になっている。
合否基準： 追加しようとしているMCPサーバーの提供元が信頼できるか、許可設定をバージョン管理下の設定として共有できているか。
詰まりやすい箇所： 「Anthropicのディレクトリに載っている」ことを「Anthropicが安全性を保証した」と読み違える。掲載基準のレビューと、サーバー内部のセキュリティ監査は別物だとドキュメント自身が線引きしている。確認項目の詳細は以前のMCPチェックリスト記事にまとめてある。
5. 組織全体のガバナンス（managed settings）
同じ公式ドキュメントの「チームセキュリティ」の項目は、managed settingsを使って組織の基準を強制すること、承認済みの許可設定をバージョン管理で共有すること、ConfigChangeフックで設定変更の監査・ブロックを行うことを挙げている。
合否基準： 「何を許可し何を確認制にするか」というルールが、個々の開発者の手元設定に委ねられず、組織側から配布・強制できる形になっているか。
詰まりやすい箇所： ルールを文書やCLAUDE.mdに書くことと、技術的に強制することは別レイヤーだという点を混同しやすい。ここは以前の記事で扱った内容がそのまま当てはまる。
6. フィードバック・セッションログの送信経路
/feedbackコマンド(/bug・/shareも同じ経路)を実行すると、会話履歴がコードごとAnthropicへ送信され、5年間保持される。送信範囲は「現在のセッションのみ(既定)」「同じプロジェクトの過去24時間」「過去7日間」から選べる。Amazon Bedrock・Google Cloud’s Agent Platform等のサードパーティ経由で使っている場合や、Anthropicの認証情報が設定されていない場合は、送信されず~/.claude/feedback-bundles/配下にローカル保存されるだけになる(既知のAPIキー・トークンのパターンは事前に伏字化される)。
合否基準： /feedbackを実行する開発者が、送信範囲を選べること・機密情報を含むセッションでは安易に送らないことを理解しているか。
詰まりやすい箇所： サードパーティ経由の契約なのに「フィードバックを送ったから開発元に情報が渡った」と誤解する、あるいは逆に商用契約だからと安心して機密性の高いセッションのログをそのまま送ってしまう。どちらも実際の挙動と一致していない。
詰まりやすい箇所（まとめ）
6項目を並べて見えてくるのは、「Enterpriseと契約すればZDRも自動的に付いてくる」「ローカルで動かしていれば外部にデータが出ない」「MCPサーバーを追加してもAnthropicが安全性を保証している」という3つの思い込みが、実際にはどれも公式ドキュメントの記述とずれているという点だ。いずれも一段階の申請・確認・提供元の見極めが別途要る。
自社で確認する基準
上の6項目のうち、契約・申請で決まるもの(1・2・4)と、設定として自社で作り込むもの(3・5・6)は分けて考えるとよい。前者は法務・契約担当と一緒に、後者は実際にClaude Codeを使う開発チームと一緒に確認する話になる。どちらも「決めた」で終わらせず、/statusや/permissionsで今の設定が意図通りになっているかを実際に確認するところまでが対策になる。社内ルールとして文書化する場合の書き方は、生成AIの利用規程に何を書くかにまとめた「技術で縛れる部分」と「人に約束させるしかない部分」の分け方がここでも使える。
自社の契約形態・運用体制でどこまで対策できているか整理したい場合は、パイロット・構築のフェーズで一緒に確認できる。まずは30分の無料診断から相談してほしい。