Claudeは情報漏洩しない？Claude Codeの対策とZDRを解説

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

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

株式会社Fyveは、Anthropic社の公式ドキュメントと、クライアント企業でのClaude・Claude Code導入・運用経験の両面から、情報漏洩リスクと対策を2026年8月時点の情報で解説します。

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

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

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

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

そしてもう1つ、見落とされやすい前提があります。チャット版のClaude（claude.ai）とターミナルで動くClaude Codeは、同じアカウントとプランの設定に紐づいています。Proプランで学習許可をオンにしたまま業務に使えば、ブラウザのチャットもClaude Codeも同じ扱いになります。「Claude Codeだけ別に設定する」という考え方はできません。

本記事は「Claudeというサービス全体で、どこに何が残り、何を止められるか」を軸に、ZDRの実際の適用条件と、設定では止まらない漏洩経路まで整理します。

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

Claudeを提供する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経由を選択可能
• FedRAMP High / DoD IL4・IL5 — ClaudeはAmazon Bedrock GovCloud経由でFedRAMP High認証を取得しており、米国国防総省のImpact Level 4/5のワークロードにも対応。Claude EnterpriseはCUI（管理対象非機密情報）に関するNIST準拠の第三者評価も受けている

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

なお、暗号化キーを自社で保持・ローテーションするBYOK（Bring Your Own Key）は、2026年8月時点でAnthropic直販での一般提供が確認できません。暗号化キーの自社管理が要件になっている場合は、Amazon Bedrock経由（AWS KMSの顧客管理キー）またはGoogle Cloud経由（CMEK）を選ぶのが現実的な選択肢です。ここは要件定義の段階で確認しておくべきポイントです。

読者特典・無料ダウンロードClaudeのこの5つの設定、今すぐ見直した方がいい無料でダウンロード →↓

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

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

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

Free・Pro・Maxプランは「Consumer」カテゴリに分類されます。2025年8月28日の規約改定で、会話とコーディングセッションはオプトアウトしない限りモデル学習に使われる方式に変わりました。

• 学習許可ON: 非識別化された形で最大5年間、モデル学習パイプラインに保持される
• 学習許可OFF: 削除後30日以内にバックエンドから削除
• この設定はclaude.ai/settings/data-privacy-controlsでいつでも変更できるが、すでに学習に使われた分は取り消せない
• Statsig・Sentry等のテレメトリデータも外部送信される（環境変数で無効化可能・後述）

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

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

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

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

• モデル学習にデータを使用しない（明示的にopt-inした場合を除く）
• 標準のデータ保持は30日以内。Anthropic APIでは、受信または生成から30日以内に入出力をバックエンドから自動削除
• IP許可制御、コネクタ・MCPの許可範囲設定など詳細な権限制御が利用可能

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

「商用は学習されない」の唯一の例外 — Development Partner Program

Commercialプランでも、組織の管理者が明示的にオプトインした場合だけは学習に使われます。AnthropicのDevelopment Partner Programがそれです。

• 組織の管理者が明示的に参加を選択したときに限り、提供した素材がモデル学習に使われる
• 対象はAnthropic純正APIのみ。Amazon BedrockやGoogle Cloud経由の利用は対象外
• 導入時に「うちは参加していないか」を管理画面で確認しておく

稟議で「商用プランは学習に使われません」と説明するなら、この例外の存在まで押さえておくべきです。「絶対に使われない」ではなく「オプトインしない限り使われない」が正確な表現になります。

データが残る期間の早見表

「入力したものは、どこに、いつまで残るのか」——稟議で必ず聞かれる論点です。2026年8月時点の公式ドキュメントの記載を1枚に整理しました。

• Anthropic API（商用・標準）: 受信・生成から30日以内に自動削除
• Team / Enterprise のチャット: ユーザーが削除操作をすると、バックエンドから30日以内に削除
• Consumer（学習許可ON）: 非識別化した形で最大5年（学習パイプライン内）
• Consumer（学習許可OFF）: 30日以内
• シークレットチャット（Incognito）: 30日以内に削除。学習には一切使われない
• 利用ポリシー違反としてフラグされた場合: 入出力を最大2年、Trust & Safetyの分類スコアを最大7年保持
• Covered Models（Claude Fable 5 / Claude Mythos 5）: 提供されるすべてのプラットフォームで30日保持が必須
• フィードバック送信（/feedback・/bug・/share）: 会話履歴を5年保持
• セッション品質サーベイで文字起こしを共有した場合: 最大6ヶ月
• Compliance APIのアクティビティフィード・リモートセッション記録: 6年
• ローカルセッション記録（CoworkおよびユーザーPC上のClaude Code）: Compliance API経由で既定6年（組織で有限の保持期間を設定していればその期間）

この表で最も驚かれるのが最後の2行です。「ローカルで動いているから残らない」は成り立ちません。Enterprise組織では、各自のマシンで動かしたClaude CodeやCoworkのセッション記録も、Compliance API経由で組織が取得できる形で保持されます（ZDRが有効なローカルセッションと、HIPAA readinessを有効にした組織のローカルセッションは対象外）。統制側から見れば「監査の証跡が取れる」利点ですが、利用者側から見れば「ターミナルでの作業内容が6年残る」ということです。導入時に社内で共有しておかないと、後から発覚したときに不信感につながります。

各プランのデータ保護の仕組み（暗号化・自動削除・学習オフ）をプラン別に横並びで比較したい場合は、こちらの記事が詳しいです。

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

Zero Data Retention（ZDR）の実際 — 条件・対象外・使えなくなる機能

Zero Data Retention（ZDR）は、応答を返した後に入出力をサーバーに保持しない取り決めです。万が一サーバーへの不正アクセスがあってもデータが残っていない、という強力な防御策になります。

ただし、実務で使うには「どこまで効くのか」を正確に押さえる必要があります。ZDRを契約したのに想定と違った、というのは導入後に最も揉めるポイントです。

ZDRはEnterpriseに自動で付いてこない

ここが最大の誤解です。

• ZDRは標準のClaude for Enterpriseプランには含まれない
• 管理画面から有効化できない。Anthropicの営業またはアカウントチームに申請し、適格性の確認を受けたうえで、Anthropic側が有効化する
• 有効化は組織単位。同じアカウントの下に新しい組織を作ってもZDRは自動で引き継がれない。組織を増やすたびに個別申請が必要
• APIについては、従量課金のAPIキーでZDRを使っている場合、Claude for Enterpriseへ移行して管理機能を得ながらZDRを維持できる
• Free / Pro / Max、およびそれらのアカウントでClaude Codeを使う場合は対象外

「Enterpriseを契約したのでZDRが効いているはず」という前提で稟議を通してしまうと、実際には効いていなかった、という事故が起こります。契約書と管理画面の両方で、自組織がZDR対象になっていることを確認してください。

ログイン先を縛らないとZDRの外に出る

ZDRが適用されるのは、ZDR有効の組織に認証したリクエストだけです。開発者が個人アカウントでClaude Codeにサインインしたり、別組織のAPIキーを使ったりすると、そのセッションはZDRの対象外になります。

これを技術的に防ぐには、管理設定のforceLoginMethodとforceLoginOrgUUIDを配布して、claude.aiへのログイン先を自組織に限定します。ルールで「個人アカウントは使わないこと」と書くだけでは足りません。設定で強制するところまでが対策です。

ZDRがカバーしない範囲

ZDRを有効にした組織でも、以下は標準のデータ保持ポリシーに従います。

• claude.aiのチャット — Claude for EnterpriseのWeb画面での会話はZDRの対象外
• Cowork — Coworkのセッションは対象外
• Claude Code Analytics — プロンプトや応答は保存しないが、アカウントのメールアドレスや利用統計などのメタデータは収集する
• ユーザー・シート管理 — アカウントのメールアドレスや席の割り当てといった管理データは標準ポリシーで保持
• サードパーティ統合 — MCPサーバーや外部ツールが処理したデータはZDRの対象外。各サービスのデータ取り扱いを個別に確認する必要がある

つまりZDRは「Claude Codeの推論部分」を守る取り決めであって、Claudeというサービス全体を包む傘ではありません。ブラウザでチャットを使えばそちらは通常保持されます。ここを取り違えると、対策した気になっているだけの状態になります。

ZDRを有効にすると使えなくなる機能

プロンプトや応答の保存を前提とする機能は、ZDR有効時にバックエンド側で自動的に無効化されます。

• Claude Code on the Web — 会話履歴のサーバー保存が必須のため
• デスクトップアプリのクラウドセッション — プロンプトと応答を含む永続的なセッションデータが必要なため
• Artifacts — 公開ページの内容をAnthropic側のインフラに保存するため
• フィードバック送信（/feedback・/bug・/share） — 会話データをAnthropicへ送るため
• Remote Control — 端末間で会話を同期するためにセッション記録をAnthropicのサーバーに保存するため

これらは画面上に表示されていても、実行するとエラーになります。導入前に「この機能を使う予定があるか」を洗い出しておかないと、ZDRを有効にした途端に現場の作業が止まります。

ZDRを契約していても「自分で外に出る」機能がある

ここは特に注意が必要です。Claude APIの機能のうち、状態を保存する性質のものはZDRの対象外です。そしてZDRの場合、APIはこれらの機能をブロックしません。

HIPAA readinessでは対象外機能を含むリクエストが400エラーで拒否されますが、ZDRでは拒否されません。使った時点で、そのデータについて自らZDRの外に出る選択をしたことになり、その機能ごとの保持ポリシーが適用されます。

• Files API — 明示的に削除するまでファイルを保持
• バッチ処理 — 29日保持（非同期処理のため保存が必須）
• コード実行ツール — コンテナのデータを最大30日保持
• プログラマティックツール呼び出し — コード実行コンテナ上で動くため同じく最大30日
• MCPコネクタ — 標準ポリシーで保持
• Agent Skills — スキルデータを標準ポリシーで保持
• Claude Managed Agents — セッションは状態を持つリソースで、削除するまで記録が残る

一方、プロンプトキャッシュ・Web検索・Webフェッチ・構造化出力・メモリツール・コンピュータ操作などはZDR対象です（構造化出力はJSONスキーマのみ最終使用から最大24時間キャッシュされます）。

「ZDRを契約したから何をしても残らない」は成り立ちません。エラーで止まらない以上、実装側で気をつけるしかない領域です。開発チームにこの一覧を共有しておくことをおすすめします。

Claude Fable 5・Mythos 5はZDRでは使えない（2026年6月9日発効）

2026年に入って生まれた新しいトレードオフです。

Claude Fable 5とClaude Mythos 5はCovered Modelsに指定されており、安全性の確認のために30日間のデータ保持が必須とされています。この要件は、これらのモデルが提供されるすべてのプラットフォームに適用されます（発効は2026年6月9日）。結果として、ZDR組織ではこれらのモデルを使えません。

• Claude API では、保持設定が要件を満たさない組織からのリクエストは400 invalid_request_errorで拒否される
• Claude Codeでは、/modelのモデル選択に表示されないか、「ZDRの解除が必要」という注記付きで無効表示になる。クライアント側の設定に関わらずサーバーが拒否する
• bestエイリアスは、利用可能な環境ではFable 5に解決されるが、ZDR組織ではOpusに解決される
• ZDR契約のある組織でも、特定のワークスペースだけ30日保持を有効化すれば、そのワークスペースでCovered Modelsを使える。他のワークスペースはZDRのまま維持される
• Amazon BedrockやGoogle Cloud経由では、保持されるデータはクラウド事業者の環境内に留まる

実務上の意味はシンプルです。「最新最上位のモデルを使う」か「ZDRを維持する」かの二者択一が発生しました。全社ZDRのまま最上位モデルを使いたい場合は、ワークスペース分割で用途を切り分けるのが現実的な落とし所になります。

なお、ZDRを有効にしていても、法令遵守やポリシー違反への対応で必要な場合はデータが保持されます。ポリシー違反としてフラグされたセッションは、関連する入出力が最大2年間保持されます。

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

• 転送中の暗号化: TLS 1.2以上。インターネット上でデータが傍受されるリスクを防止
• 保存時の暗号化: 利用するモデルプロバイダによって仕組みが変わる

TLS 1.2+とAES-256は金融機関やヘルスケア業界でも採用される暗号化標準です。保存時の暗号化はプロバイダ別に次のようになります。

• Anthropic API — インフラレベルのディスク暗号化（AES-256）。サーバー側に一切残さないならZDRを併用する
• Amazon Bedrock — AWS管理キーによるAES-256。AWS KMSの顧客管理キーも利用可能
• Google Cloud — Google管理の暗号化キー。CMEK（顧客管理暗号鍵）も利用可能
• Microsoft Foundry — ホスティング方式による。Azure上でホストする構成ではプロンプトと応答はAzure内に留まり、利用メタデータと安全性システムがフラグした内容だけがAnthropicへ送られる

「データを自社のクラウド境界から出したくない」という要件があるなら、Anthropic直販ではなくBedrock・Google Cloud・Foundry経由を検討するのが定石です。要件定義の初期にここを決めておくと、後戻りがありません。

見落とされやすい漏洩経路 — 設定では止まらない場所

ここまではAnthropic側に何が残るかの話でした。実際の情報漏洩は、もっと手前の、自分の手元や運用フローで起きます。稟議のチェックリストからも漏れやすい箇所を挙げます。

セッション記録は自分のPCに平文で残る

Claude Codeは、セッションを再開できるようにするため、会話の記録を~/.claude/projects/配下に平文で保存します。既定の保持期間は30日です。

つまり、Anthropic側の保持期間をどれだけ短くしても、手元のマシンには30日分の作業内容がそのまま残っています。共有PC・貸与PCの返却・端末の紛失・バックアップサービスへの自動同期——このどれかで外に出る可能性があります。

• 保持期間はcleanupPeriodDays設定で変更できる
• 共有端末で使う場合は保持期間を短くするか、作業後に明示的に削除する
• PCのディスク暗号化（FileVault / BitLocker）は前提条件と考える

私自身、この挙動を知らないまま「サーバーに残らないから安全」と説明していた時期がありました。説明すべき対象はサーバーだけではありません。

フィードバック送信は会話履歴を5年保持する

/feedbackコマンドを実行すると、コードを含む会話履歴のコピーがAnthropicへ送られ、5年間保持されます。/bugと/shareも同じ経路で送信されます。

• 送信前に含める範囲を選べる（既定は現在のセッションのみ／同じプロジェクトの過去24時間または7日も選択可）
• データはTLSで暗号化して送信され、Google Cloud Storageに保存される
• 任意で公開リポジトリにGitHub Issueが作成される
• 無効化するには環境変数DISABLE_FEEDBACK_COMMAND=1を設定する

クライアント案件のコードを触っているときに、不具合報告のつもりで/bugを打つと、そのコードが外に出ます。機密性の高い案件では、組織のsettings.jsonで最初から無効化しておくのが安全です。

セッション品質サーベイの「はい」は文字起こしを送る

Claude Codeで「How is Claude doing this session?」という評価プロンプトが出ることがあります。評価そのものは評点だけを記録し、会話内容は送信しません。

問題はその後です。評価の後に「セッションの記録をAnthropicが見てもよいか」という追加の確認が出ることがあり、ここで「はい」を選ぶと、会話の記録・サブエージェントの記録・ディスク上の生ログがアップロードされます。APIキーやトークンの既知パターンは除去されますが、ソースコードやファイルの内容はそのまま送られます。保持は最大6ヶ月です。

• 明示的に「はい」を選ばない限り何も送信されない
• ZDR組織、組織ポリシーでフィードバックを無効化している場合、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICを設定している場合は、この確認自体が出ない
• サーベイを止めるにはCLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1を設定する

忙しい作業中に確認ダイアログを流し読みして押すのが、最も現実的なリスクです。組織として使うなら、聞かれる前に止めておくべき類の設定です。

共有リンクは検索エンジンに拾われうる

Claudeの会話は共有リンクを発行して他人に見せられます。この共有リンクが検索エンジンにインデックスされ、第三者から閲覧できる状態になった事例があります。「社内の人に見せるつもりで作ったリンク」が公開状態になるのが、最も起きやすい情報漏洩です。

仕組みと具体的な対処はこちらで詳しく解説しています。

Claude共有チャットがGoogle検索に表示された理由と対策

Remote Controlは会話記録をサーバーに置く

Remote Controlは処理そのものは手元のマシンで実行されますが、接続中は端末間で会話を同期するため、セッションの記録がAnthropicのサーバーに保存されます。「ローカル実行だから外に出ない」はこの機能には当てはまりません（ZDR組織では機能自体が無効化されます）。

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は分離されたコンテキストウィンドウで実行（インジェクション防止）
• URLを取得する前に、ホスト名だけをapi.anthropic.comへ送って安全性ブロックリストと照合する。フルURL・パス・ページ内容は送らない。この照合はCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICでは止まらず、止めるには設定のskipWebFetchPreflight: trueが必要

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 — 利用メトリクスを無効化。メトリクスにはコード・プロンプト・ファイルパスは含まれません（遅延・信頼性・利用パターンのみ）
• DISABLE_ERROR_REPORTING=1 — エラー報告を無効化。送信前に、既知のシークレット・ファイルパス・メールアドレス等のパターンは除去される
• DISABLE_FEEDBACK_COMMAND=1 — /feedback・/bug・/shareを無効化
• CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1 — セッション品質サーベイを無効化
• CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 — 上記をまとめて無効化

これらの環境変数はsettings.jsonに書いて配布できます。組織で統一するなら、個人の設定に任せず設定ファイルで配ってください。

また、Amazon Bedrock / Google Cloud / Microsoft Foundry / Claude Platform on AWS 経由での利用時は、メトリクス・エラー報告・フィードバックがいずれもデフォルトOFFです。テレメトリを止めたいという理由だけでも、クラウド経由を選ぶ価値があります。ただしセッション品質サーベイとWebFetchのドメイン安全性チェックは例外で、プロバイダに関わらず動作します。

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

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

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が危険かどうかではなく、「正しいプランと設定で使っているか」「社内ルールが整備されているか」が問われます。

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

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

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

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

前述のとおり、MCPサーバーが処理したデータはZDRの対象外です。ZDRを契約している組織ほど、MCPの棚卸しは重要になります。

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

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

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

Claudeのセキュリティとは少し視点が変わりますが、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. 最後に人的リスクに言及する: 技術的に防げない、社員による人為的な情報漏洩のリスクを正直に伝え、クライアント側でもガイドライン制定を求める

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

機密情報を入れてしまったときの初動

予防の話だけでは足りません。「入れてはいけないものを入れてしまった」と気づいた後に何をするかを、事前に決めておく必要があります。順番はこうです。

1. 該当の会話を削除する — チャット履歴からは即座に消え、バックエンドの保存領域からは30日以内に削除される。削除は取り消せないので、証跡が必要なら先にスクリーンショットを取る
2. 共有リンクを発行していないか確認して停止する — 検索エンジンに拾われるのはここ。会話の削除より優先度が高い場合がある
3. 学習設定を確認する — Consumerプランで学習許可がONだった場合、設定をOFFにしても、すでに学習に使われた分は取り消せません。この前提で影響範囲を評価する
4. 認証情報が含まれていたら即ローテーションする — APIキー・トークン・パスワードは、削除できたかどうかに関わらず無効化して再発行する。これが最も確実な封じ込め
5. ローカルの記録を確認する — ~/.claude/projects/配下のセッション記録にも残っている。既定30日
6. フィードバックを送っていないか思い出す — /feedback・/bug・/shareを実行していた場合、その分は5年保持される。実行していたなら、Anthropicのサポートへ削除を依頼する
7. 組織側で影響範囲を特定する — Enterprise組織なら監査ログとCompliance APIで、いつ誰が何を送ったかを追跡できる

1と4を混同しないことが重要です。会話を消しても、漏れた認証情報は無効になりません。逆に認証情報のローテーションさえ済ませれば、実害はほぼ止まります。「消す」より「無効化する」を先に考えてください。

日本の法規制対応

個人情報保護法（APPI）

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

経産省・IPA ガイドライン

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

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

中小企業がガイドラインを整備する具体的な進め方はこちらでまとめています。

中小企業がAI導入する前に知っておくべきガイドラインとセキュリティ対策

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

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

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

• □ データがモデル学習に使用されないか — Team以上であれば商用規約で保証。Development Partner Programにオプトインしていないことも併せて確認
• □ データの保持期間は明確か — 商用は30日以内、Consumer学習ONは最大5年、ポリシー違反フラグ時は最大2年
• □ データの暗号化（転送時・保存時） — TLS 1.2+ / AES-256。SOC 2 Type IIで第三者監査済み。保存時暗号化はプロバイダによって仕組みが異なる
• □ データ削除の手段はあるか — 会話データはユーザーがいつでも削除可能。バックエンドからは30日以内
• □ DPA（データ処理補遺）は締結可能か — 商用規約に組み込み済み、GDPR対応

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

• □ SSO / SCIM連携 — Enterprise契約でOkta / Microsoft Entra ID / Google Workspace等と統合可能。自動プロビジョニング（SCIM）が必要ならEnterprise
• □ IPアドレス制限 — Enterprise契約でIP allowlisting対応
• □ 監査ログの取得 — Enterprise契約で「誰が・いつ・何を」を追跡。Compliance API経由でアクティビティフィード（6年保持）も取得できる
• □ ユーザー権限管理 — Team / Enterpriseで管理者による追加・削除・権限設定。退職者のアクセス即時停止が可能
• □ 多要素認証（MFA） — Anthropicアカウントの二要素認証に全プラン対応

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

• □ permissions（allow/deny）設定 — 全プランで案件ごとの権限制御が可能
• □ MCP接続の棚卸し — 使っていないMCPは外す。接続数は最小限に。MCP経由のデータはZDRの対象外
• □ Hooksでのセキュリティチェック自動化 — 出力内容をチェックリストと自動照合。全プラン利用可能
• □ テレメトリ・フィードバックの停止 — CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC等をsettings.jsonで配布。ローカル記録の保持期間も決める
• □ 自動デプロイ連携の制御 — robots.txt・.env等「AIが変更してはいけないファイル」をdenyで明示的に指定。機密情報の取り扱いルールはCLAUDE.mdで明文化

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

よくある質問

Claude ProやMaxで仕事の話をすると学習に使われますか

データ利用の設定がオンなら使われます。オフにすれば新しい会話は学習に使われず、保持も30日以内になります。ただし設定をオフにしても、すでに学習に使われた分は取り消せません。業務利用ならプランをTeam以上に上げるのが確実です。

Teamプランを契約すればZDRが効きますか

効きません。ZDRの対象はEnterprise APIとClaude for Enterpriseで、Enterpriseでも標準では含まれず、営業経由の申請と適格性確認が必要です。TeamプランはZDRの対象外ですが、商用規約により学習には使われず、保持は30日以内です。

シークレットチャット（Incognito）なら安全ですか

シークレットチャットは学習に一切使われず、30日以内に削除されます。ただし利用ポリシー違反としてフラグされた場合は例外で、通常より長く保持されます。「学習に使われない」ことと「一切残らない」ことは別だと理解してください。

最上位モデルとZDRは両立しますか

2026年8月時点では両立しません。Claude Fable 5とClaude Mythos 5は30日保持が必須のCovered Modelsに指定されており、ZDR組織では利用できません。ワークスペース単位で30日保持を有効化すれば、そのワークスペースに限って利用できます。組織全体のZDRは維持されます。

オンプレミス（自社環境内）で動かせますか

Anthropicのモデル本体を自社サーバーに置くことはできません。データが自社のクラウド境界から出ないことが要件なら、Amazon Bedrock・Google Cloud・Microsoft Foundry経由での利用が現実的な選択肢です。Foundryの「Hosted on Azure」構成では、プロンプトと応答はAzure内に留まります。

ターミナルで使う分にはデータは外に出ませんか

出ます。Claude Codeは手元で動きますが、モデルとやり取りするためにプロンプトと応答をネットワーク経由で送信します。加えて、セッションの記録は~/.claude/projects/配下に平文で既定30日保存され、Enterprise組織ではCompliance API経由で既定6年保持されます。「ローカルだから残らない」は成り立ちません。

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

1. プラン選定（最優先）: Team / Enterprise / APIプランを選択しているか？
2. データ学習可否の確認（最優先）: 商用プランで「モデル学習に使用しない」ポリシーが適用されていること、Development Partner Programにオプトインしていないことを確認
3. 保持期間・削除手順: 商用の30日削除ポリシーを確認。ZDRが必要なら適格性の確認から着手し、カバー範囲と無効化される機能を事前に洗い出す
4. ログイン先の強制: forceLoginMethod・forceLoginOrgUUIDで個人アカウントでの利用を塞ぐ
5. テレメトリ・フィードバックの制御: 環境変数をsettings.jsonで配布して統一する
6. 権限設計: パーミッション・CLAUDE.md・Hooksでセキュリティポリシーを自動適用
7. 法令対応: DPA締結、APPI対応、越境移転の社内文書整備

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

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

• Commercialプラン（Team以上）ならデータがモデル学習に使われず、保持は30日以内
• SOC 2 Type II + ISO 27001 + ISO 42001（世界初取得）のトリプル認証。FedRAMP High / HIPAA / GDPRにも対応
• ZDRはEnterpriseに自動で付いてこない。申請と適格性確認が必要で、claude.aiのチャット・Cowork・MCP経由のデータは対象外
• Claude Fable 5・Mythos 5はZDRでは使えない（2026年6月9日発効）。ワークスペース分割で用途を切り分ける
• 設定では止まらない経路がある——ローカルの平文記録（既定30日）・フィードバック送信（5年）・共有リンク
• パーミッション・サンドボックス・Hooksで多層防御。テレメトリは環境変数で無効化可能
• IBM統計: AIガバナンスなしが最大のリスク。ツールの問題より運用の問題
• 事故ったら「消す」より先に認証情報のローテーション

重要なのは、「Claudeが危険かどうか」ではなく、「正しいプランと設定で使っているかどうか」です。株式会社Fyveでは、この判断を実際の業務要件に落とし込むところから支援しています。

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

Claude Code導入ガイドを読む →

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

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