Claude Codeは情報漏洩しない？セキュリティ対策を実務者が徹底解説

「Claude Codeで情報漏洩しないか」——企業へのClaude Code導入を支援する中で、最も多く受ける質問です。

結論から言えば、正しいプラン選択と設定を行えば、企業の業務利用に十分なセキュリティ水準を確保できます。ただし、プランによってデータの取り扱いが根本的に異なるため、その違いを理解しないまま導入すると重大なリスクを抱えます。

Anthropic社の公式セキュリティドキュメントと、クライアント企業でのClaude Code導入・運用経験の両面から、情報漏洩リスクと対策を徹底的に解説します。

Claude Codeで情報漏洩は起きるのか？結論

最初に結論を整理します。

• Commercialプラン（Team / Enterprise / API）: 入力データがモデル学習に使用されない。情報漏洩リスクは最小限
• Consumerプラン（Free / Pro / Max）: 設定によってはデータが学習に使われる可能性がある。業務での機密データ入力は非推奨

つまり、プラン選択がセキュリティの9割を決めると言っても過言ではありません。

開発元Anthropicの信頼性と第三者認証

Claude Codeを提供するAnthropicは、AI安全性研究を企業理念の中核に置く会社です。セキュリティ認証は業界でもトップクラスで、社内稟議や情報セキュリティ委員会への説明で使える具体的な根拠が揃っています。

• SOC 2 Type I & Type II — Type Iが「ある時点でのセキュリティ体制」を評価するのに対し、Type IIは一定期間にわたってセキュリティ管理が継続的に機能しているかを監査する。「認証取得のため一時的に体制を整えた」のではなく、日常的にセキュリティが運用されている証拠。SOC 2 Type IIの詳細レポートはNDA締結のうえEnterpriseプランで閲覧可能
• ISO 27001:2022 — 情報セキュリティマネジメントシステム（ISMS）の国際規格。日本企業でも馴染みのあるキーワードで、社内の情報セキュリティ委員会への説明でも通りやすい
• ISO/IEC 42001:2023 — AI特有のリスクを管理する国際規格。Anthropicは2025年1月にフロンティアAI企業として世界初で取得（認証機関: Schellman Compliance, ANSI認定）。「AIを使うこと自体のリスクはどう管理されているのか」という経営層の疑問への明確な回答になる
• CSA STAR Level 2 — クラウドセキュリティ
• HIPAA BAA対応 — 医療データの取扱いに対応（Enterprise / APIのみ、BAA締結必須。Free / Pro / Max / Teamは対象外）。AWS Bedrock / Google Cloud / Microsoft Azure経由でもHIPAA準拠の環境でClaudeを利用可能
• GDPR対応 — 商用利用規約にDPA（Data Processing Addendum）とSCC（Standard Contractual Clauses）を組み込んでおり、EU個人データ保護要件に対応。EU域内のみの処理が必須の場合はAWS BedrockまたはGoogle Cloud Vertex AI経由を選択可能
• FedRAMP High / DoD IL4・IL5 — ClaudeはAmazon Bedrock GovCloud経由でFedRAMP High認証を取得しており、米国国防総省のImpact Level 4/5のワークロードにも対応。Claude EnterpriseはCUI（管理対象非機密情報）に関するNIST準拠の第三者評価も受けている

2026年上半期にはBYOK（Bring Your Own Key）の提供も予定されており、暗号化キーの管理を自社で行うことも可能になります。認証の詳細はAnthropic Trust Centerで確認できます。

累計資金調達は460億ドル以上。Google、Amazon、Microsoftなどが出資しており、スタートアップにありがちな「突然のサービス終了」リスクが極めて低い財務基盤を持っています。

【最重要】プラン別のデータ取り扱い — ここを間違えると危険

Claude Codeの情報漏洩リスクを語る上で、最も重要なのがプランによるデータ取り扱いの違いです。

Consumerプラン（Free / Pro / Max）のリスク

Free・Pro・Maxプランは「Consumer」カテゴリに分類されます。

• 設定がオンの場合、会話データがモデル改善（学習）に使用される可能性がある
• 学習許可ON: データが5年間保持される
• 学習許可OFF: 30日間保持後に削除
• Statsig・Sentry等のテレメトリデータも外部送信される

私はクライアントに対して、Consumerプランでの業務利用は明確に「やめてください」とお伝えしています。社内の機密情報、顧客データ、未公開の事業計画などを入力した場合、それがモデルの学習に使われる可能性があるからです。

2023年4月のSamsung事件が代表的な教訓です。Samsung半導体部門のエンジニアが3回にわたりChatGPT（Consumer版）にソースコード・会議メモを貼り付け、入力データが学習データに含まれるリスクが発生。Samsungはその後、社内でのChatGPT利用を禁止しました。この事件は「ツール自体の問題」ではなく、Consumer版で機密情報を入力した運用の問題です。

Commercialプラン（Team / Enterprise / API）の安全性

Team・Enterprise・APIプランは「Commercial」カテゴリです。データの取り扱いが根本的に異なります。

• モデル学習にデータを使用しない（明示的にopt-inした場合を除く）
• API入出力のログ保持: 7日間で自動削除（2025年9月に30日から短縮）
• IP許可制御、コネクタ・MCPの許可範囲設定など詳細な権限制御が利用可能

企業がClaude Codeを導入するなら、Commercialプラン（Team以上）は必須条件です。月額のコスト差を気にしてConsumerプランで業務利用するのは、セキュリティ上の大きなリスクを背負うことになります。

各プランのデータ保護の仕組み（暗号化・自動削除・ZDR）の詳細は、プラン別データ保護比較ガイドで解説しています。

Zero Data Retention（ZDR）— データを一切残さない選択肢

Enterprise APIおよびClaude for Enterpriseでは、Zero Data Retention（ZDR）が利用可能です。

• APIレスポンス返却後、入出力データをサーバーに保持しない
• 例外: 法令遵守に必要な場合、不正利用対策のためのUser Safety classifier resultsのみ保持
• 万が一サーバーに不正アクセスがあっても、データが残っていないという強力な防御策

Free / Pro / Max / Teamプランは対象外です。ZDRが必要な場合はEnterprise契約が必要です。

暗号化とデータ保護の技術仕様

• 転送中の暗号化: TLS 1.2以上。インターネット上でデータが傍受されるリスクを防止
• 保存時の暗号化: AES-256。サーバー上に保存されるデータも暗号化状態で管理

TLS 1.2+とAES-256は金融機関やヘルスケア業界でも採用される暗号化標準です。エラーログはSentry経由でAES-256暗号化されて保存されます。

Claude Codeの多層防御 — パーミッション・サンドボックス・Hooks

Claude Code自体にも、情報漏洩を防ぐ多層的なセキュリティ機能が実装されています。

パーミッションシステム

• デフォルトは読み取り専用。ファイル編集・コマンド実行には明示的な承認が必要
• 書き込みはプロジェクトディレクトリ以下に制限
• プロジェクト単位でallow/denyの権限を細かく設定可能
• Enterprise向けにIP許可制御・MCP許可範囲設定も利用可能

私自身、クライアント案件の機密性に応じてpermissions設定の厳しさを変えています。開発内容の機密性が高い案件では厳しく、低い案件では緩めに設定するのが実務的です。一律に厳しくすると確認ダイアログが増えすぎて「確認疲れ」が起き、中身を見ずにOKを押す癖がつきます。一律に緩くすれば当然リスクが上がります。案件の性質に応じてバランスを取るのが、複数プロジェクトを回す法人としての現実的な運用です。

サンドボックス機能

ファイルシステムとネットワークを分離したbash実行環境。/sandboxコマンドで有効化でき、macOSではseatbelt、LinuxではBubblewrapというOSレベルのセキュリティ機構を利用しています。Anthropic公式発表によると、サンドボックスにより権限プロンプトが84%削減されています。万が一プロンプトインジェクション攻撃を受けた場合でも、サンドボックスがデータ漏洩やマルウェアダウンロードを防ぎます。

プロンプトインジェクション対策

• curl / wget 等の危険コマンドをデフォルトでブロック
• 不審なbashコマンドはallowlist登録済みでも手動承認を要求
• Web fetchは分離されたコンテキストウィンドウで実行（インジェクション防止）

Hooks — 品質チェック＋セキュリティチェックの自動化

Hooks機能を使えば、AIが成果物を生成した後に自動でセキュリティチェックを走らせることができます。私の環境では、記事や提案書を作成するたびに以下を自動チェックしています。

• クライアントの特定情報（社名・URL・金額・担当者名）が含まれていないか
• 個人名が含まれていないか
• APIキーやパスワード等の機密情報が含まれていないか
• 表記ルール（一人称、敬体等）が守られているか

人間が毎回チェックリストを目視確認するのは限界があります。確認すべき項目が多いほど見落としが増える。Hooksで自動化すれば、AIが生成した成果物を別のチェックプロセスが機械的に検証するので、人的ミスを減らせます。実際に、AIが意図せずクライアントの具体的な情報を含めてしまうケースをHooksが何度も防いでいます。

実際のインシデント経験

クライアントのWebサイト制作中に、AIが意図せずrobots.txtのindexを許可する状態に変更し、そのままプッシュしてしまったことがありました。完成前のサイトが検索結果に表示されるリスクが生じたのです。GitHubのprivateリポジトリでも、Vercel等のホスティングサービスに自動デプロイが走るため、privateリポジトリだから安全とは限りません。

この経験以降、robots.txt、metaタグのnoindex指定、環境設定ファイル、.envなど、公開状態に関わるファイルには明確なdeny設定を入れています。本番環境への影響が大きいファイルの変更は、AIに任せず自分で行うという運用も併用しています。AIは便利ですが、「何でもやらせる」のではなく「やっていいことを明確に定義する」運用が必要です。

テレメトリの制御

Claude Codeは利用状況データを送信しますが、以下の環境変数で無効化できます。

• DISABLE_TELEMETRY=1 — Statsigメトリクス無効化
• DISABLE_ERROR_REPORTING=1 — Sentryエラーログ無効化
• CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 — 全非必須通信を無効化

Bedrock / Vertex / Foundry経由での利用時はテレメトリがデフォルトOFFになっています。

業界全体のAIセキュリティ動向

AIコーディングツールのセキュリティは、Claude Codeに限らず業界全体の課題です。

IBM Cost of a Data Breach Report 2025によると:

• 13%の組織がAIモデル/アプリケーションの侵害を報告
• 侵害を受けた組織の97%がAIアクセス制御を導入していなかった
• 63%の侵害組織がAIガバナンスポリシーを持っていないor策定中
• 5社に1社がシャドーAI（未承認AI利用）による侵害を経験

また、GitGuardianの「State of Secrets Sprawl 2026」レポートによると、AIコーディングツールを使ったコミットの秘密情報漏洩率は3.2%で、GitHub全体の平均1.5%の約2倍です。2025年にはGitHub上に2,865万件もの新しいハードコードされた秘密情報が追加されました（前年比34%増）。AIが便利になるほど、漏洩リスクも増えているのが現実です。

つまり、「ツール自体の脆弱性」ではなく「ガバナンス不在」がリスクの本体です。Claude Codeが危険かどうかではなく、「正しいプランと設定で使っているか」「社内ルールが整備されているか」が問われます。

運用で発生する実務リスクと対策

技術的なセキュリティ機能だけでは防げない、運用面で発生するリスクも整理しておきます。

MCP連携は「本当に必要か」で判断する

MCP（Model Context Protocol）は外部ツールとClaude Codeをつなぐ便利な機能ですが、接続している限り情報漏洩のリスクがゼロにはなりません。2026年2月にはCheck Point Researchが、悪意あるMCP設定によるリモートコード実行やAPIキー窃取の脆弱性（CVE-2025-59536、CVE-2026-21852）を報告しています（いずれも修正済み）。MCP連携の攻撃面が現実のものであることを示した事例です。

私が実践しているMCPの判断基準は3つです。

• 本当に必要か？ 「とりあえず入れておく」は危険。使わないMCPを許可状態にしておくメリットはゼロ
• 水際での対策が取れるか？ そのMCPがどんなデータにアクセスできるかを把握し、permissionsのdenyで補完できるかを確認
• 使わなくなったら外す。接続数は最小限に保つ。以前はデザイン系MCPも接続していましたが、別の方法で代替できると判断して外しました

アクセス権限はアプリ構造で強制する

Claude Codeのセキュリティとは少し視点が変わりますが、AIを活用したシステム開発におけるセキュリティ設計として、避けて通れないのがアクセス権限の問題です。

介護施設向けのAI記録システムを開発したとき、事務員・管理者・現場スタッフが同じデータベースにアクセスする構成でした。立場によってデータへのアクセス権限を分ける必要がありましたが、1つのアプリ内でアカウント認証を分けると、現場のスタッフは業務の合間にシステムを操作するため、ログインや認証の手間が増えると結局使われなくなります。

結論として、事務員・管理者向けアプリと現場スタッフ向けアプリを完全に分離しました。認証の手間なく、アプリ自体の入口で権限分けができます。技術的に高度な対策を積み上げるより、アプリの構造レベルで権限を分離するほうが現場に無理なく受け入れられるケースは多いです。総務省「令和6年版情報通信白書」でも、アクセス制御・権限管理の重要性が繰り返し指摘されています。

「設定・運用・人」の3レイヤーで守る

settings.jsonの初期設定はスタート地点にすぎません。IPA「情報セキュリティ10大脅威 2026」では、組織向け脅威の第4位に「内部不正による情報漏えい」、第7位に「不注意による情報漏えい」がランクインしており、人に起因するインシデントが依然として大きな割合を占めています。

• 設定レイヤー: permissions、sandbox、MCP管理。プロジェクト単位で適切に調整する
• 運用レイヤー: 自動デプロイの影響範囲を把握する。Hooksで自動チェックを組み込む。使わないMCPは外す
• 人レイヤー: 社内ガイドラインを制定する。AIツールの利用ルール、情報の取り扱い基準、インシデント発生時の対応フローを整備する

スタッフがAIとの会話画面をスクリーンショットで外部共有する、共有PCでセッションを閉じずに離席する——これらは技術設定では防げません。技術と人の両輪が揃って、はじめてセキュリティは機能します。

クライアント説明は「リスクから入る」

AIツールを使った開発を提案すると、クライアントから「セキュリティは大丈夫ですか？」と聞かれます。ここで「大丈夫です」と即答するのは最悪の対応です。私が実践しているフローは3ステップ。

1. まずリスクを説明する: 考えられるセキュリティリスクを正直に、網羅的に伝える
2. 次に対策を提示する: そのリスクを極限まで低く、あるいはゼロにする方法を、専門用語をできるだけ省いて説明する
3. 最後に人的リスクに言及する: 技術的に防げない、社員による人為的な情報漏洩のリスクを正直に伝え、クライアント側でもガイドライン制定を求める

リスクを先に提示することで、クライアントは安心します。逆に「大丈夫です」から入ると、後からリスクが発覚したときに信頼を失います。リスクと対策を透明に開示するアプローチが、結果的にクライアントの安心感につながります。

日本の法規制対応

個人情報保護法（APPI）

• Commercialプラン（学習に使われない）であれば、APPIの「第三者提供」リスクは低減
• ただし、入力データそのものに個人情報を含めないことがベストプラクティス
• 越境移転については社内文書の整備が別途必要

経産省・IPA ガイドライン

日本では以下のガイドラインが公開されており、AI導入時のセキュリティ判断の参考になります。

• AI事業者ガイドライン v1.1（2025年3月、総務省・経産省共同策定）— AI開発者・提供者・利用者すべてに向けた統一指針
• テキスト生成AI導入・運用ガイドライン（2024年7月、IPA）— 組織の生成AI導入時のセキュリティリスクを具体化
• AIセーフティに関する評価観点ガイド（2024年9月、IPA AIセーフティ・インスティテュート）

社内稟議で使える15項目チェックリスト

導入稟議の作成時、経営層やIT部門に「何をどう確認したか」を具体的に示せるチェックリストが必要です。3カテゴリ15項目で整理しました。

カテゴリ1：データ保護（5項目）

• □ データがモデル学習に使用されないか — Team Standard以上であれば契約レベルで保証。Free / Pro / Maxはオプトアウト可能（デフォルトはON）
• □ データの保持期間は明確か — API 7日削除、Consumer OFF時30日、Enterprise ZDRでゼロ保持
• □ データの暗号化（転送時・保存時） — TLS 1.2+ / AES-256。SOC 2 Type IIで第三者監査済み
• □ データ削除の手段はあるか — 会話データはユーザーがいつでも削除可能
• □ DPA（データ処理補遺）は締結可能か — Enterprise契約で締結可能、GDPR対応

カテゴリ2：アクセス制御（5項目）

• □ SSO / SCIM連携 — Enterprise契約でAzure AD / Okta等と統合可能。Team Standard/Premiumでは未対応
• □ IPアドレス制限 — Enterprise契約でIP allowlisting対応
• □ 監査ログの取得 — Enterprise契約で「誰が・いつ・何を」を追跡。コンプライアンス監査の証跡として活用可能
• □ ユーザー権限管理 — Team / Enterpriseで管理者による追加・削除・権限設定。退職者のアクセス即時停止が可能
• □ 多要素認証（MFA） — Anthropicアカウントの二要素認証に全プラン対応

カテゴリ3：運用セキュリティ（5項目）

• □ permissions（allow/deny）設定 — 全プランで案件ごとの権限制御が可能
• □ MCP接続の棚卸し — 使っていないMCPは外す。接続数は最小限に
• □ Hooksでのセキュリティチェック自動化 — 出力内容をチェックリストと自動照合。全プラン利用可能
• □ 自動デプロイ連携の制御 — robots.txt・.env等「AIが変更してはいけないファイル」をdenyで明示的に指定
• □ 機密情報の取り扱いルール策定 — CLAUDE.mdで禁止項目を明文化

注目すべきは、Claude Codeの「permissions」「Hooks」「MCP管理」が全プランで使える点です。他のツールではEnterprise契約でしか得られないセキュリティ制御が、Claude Codeでは個人プランから利用できます。高価な法人プランを契約しなくても運用レベルのセキュリティ対策を始められるのは、中小企業にとって特に有利です。一方、VPC（自社環境内）デプロイはDevinが最も積極的で、データが自社ネットワークから出ないことが絶対条件の場合はDevinのアーキテクチャに優位性があります。

情シス担当者が確認すべき6つの要点

1. プラン選定（最優先）: Team / Enterprise / APIプランを選択しているか？
2. データ学習可否の確認（最優先）: Commercialプランで「モデル学習に使用しない」ポリシーが適用されていることを確認
3. 保持期間・削除手順: API入出力の7日自動削除ポリシーを確認。ZDR適用条件を把握
4. テレメトリ制御: 必要に応じて環境変数で無効化
5. 権限設計: パーミッション・CLAUDE.md・Hooksでセキュリティポリシーを自動適用
6. 法令対応: DPA締結、APPI対応、越境移転の社内文書整備

特に1番と2番は導入初日から対応すべき最優先事項です。

まとめ — 正しく理解すれば安全に使える

• Commercialプランならデータがモデル学習に使われない
• SOC 2 Type II + ISO 27001 + ISO 42001（世界初取得）のトリプル認証。FedRAMP High / HIPAA / GDPRにも対応
• パーミッション・サンドボックス・Hooksで多層防御
• テレメトリは環境変数で無効化可能
• IBM統計: AIガバナンスなしが最大のリスク。ツールの問題より運用の問題
• 「設定・運用・人」の3レイヤーで守る

重要なのは、「Claude Codeが危険かどうか」ではなく、「正しいプランと設定で使っているかどうか」です。

Claude Codeの導入を検討中の方は、以下のガイドもご覧ください。

Claude Code導入ガイドを読む →

プラン別のデータ保護の仕組みはこちら。

Claude CodeClaude Codeの情報漏洩対策｜データの暗号化・学習オフ・自動削除をプラン別に比較

目的別のプラン選びガイドはこちら。

Claude CodeClaude Codeプランの選び方｜目的別診断で最適プランが見つかる