Claude Code を企業で使うときのセキュリティで確かめることは、3点に絞れます。
商用条件で学習に使われないこと、記録がどこに何日残るか、管理者が配る設定で全社に統制を効かせられるか。
公式文書の該当箇所と確認日（2026年10月17日）付きで整理します。

企業で確かめることは「学習・保存・統制」の3つ

情報システム部門の相談で必ず出る3つの問い

私はRe-railで、約50社・20業界のClaude Code / Codex法人セットアップに立ち会ってきました（2026年7月時点）。
情報システム責任者との打ち合わせで出る質問は、言い方こそ違ってもこの3つに集約されます。

• 学習：送ったデータがモデルの学習に使われないか
• 保存：社内の秘匿情報がどこに、いつまで残るか
• 統制：全社の端末にどう統制を効かせるか

この3つに出典付きで答えられれば、導入の可否判断は前に進みます。

公式文書のどこを見るか、確認日を残す理由

2026年に入ってからも、管理用の設定キーが追加され、権限の既定モードが変わり、外部連携の許可リストの挙動まで変わりました。
本記事はすべて2026年10月17日時点の確認として出典URLを併記します。
社内の判断記録にも、確認日とバージョンを書き添えてください。

①送ったデータは学習に使われるのか

商用条件では学習に使わない（規約の該当条項）

商用規約（発効2025年6月17日）のSection B「Customer Content」に、「Anthropic may not train models on Customer Content from Services」（サービスを通じて受け取った顧客のコンテンツでモデルを学習させない）と明記されています（出典：Commercial Terms of Service）。
公式ドキュメントは、Team・Enterprise・API・Amazon Bedrock・Google Cloud について、商用条件下でClaude Codeに送られたコードやプロンプトで生成モデルを学習しないと書いています（出典：Data usage）。

個人のFree・Pro・Maxは設定次第、Claude Code経由も対象

個人向けのFree・Pro・Maxは、claude.ai のプライバシー設定（モデル改善へのデータ利用）がONなら学習の対象です。
公式は「including when you use Claude Code from these accounts」と、Claude Codeからの利用を明示的に含めています。
つまり、個人サブスクのアカウントで業務コードを扱うことが、学習の面では最大の穴になります。
この設定をオフにすれば外れますが、個人アカウントの設定を管理者が強制する手段はありません。

例外は自社がデータ提供に同意した場合

商用条件下で学習に使われる例外は、組織が自らデータ提供に同意した場合です。
公式が例に挙げるのはDevelopment Partner Programです。
この例の対象はAnthropicが直接提供するAPI（一次API）のみで、Amazon BedrockやGoogle Cloud経由では使えません。

②秘匿情報はどこに・いつまで残るのか

Anthropic側のサーバーに残る期間は用途ごとに違う

公式のData usageが保持期間を示すのは、Team・Enterprise・API（標準30日）と個人（学習ONで5年・OFFで30日）です。
Amazon Bedrock・Google Cloud経由の記録は同ページに記載がないため、各基盤の契約で確認してください。
感想や不具合、会話を送る操作（/feedback・/bug・/share）の内容は5年、品質アンケートで共有した会話は最大6ヶ月です。
「30日」の一語で社内規程に書くと、この差分が落ちます。

会話の記録は開発者の端末に平文で既定30日残る

公式は、セッションの記録を開発者の端末の ~/.claude/projects/ に平文で既定30日保存すると明記し、cleanupPeriodDays で期間を変えられるとしています。
ただしデスクトップアプリのClaude Desktop、またはClaudeの別製品であるCoworkで開始した会話と、最後の続きをそのどちらかで操作した会話の記録は、既定では30日の自動削除の対象外です。
端末に残る記録が論点から落ちている現場をよく見ます。
端末の暗号化、資産管理、退職時の回収手順に直結します。

ゼロデータ保持（ZDR）の正しい条件

ゼロデータ保持（ZDR）は、送ったプロンプトと応答を、応答後にAnthropic側へ保存しない扱いにする仕組みです。
公式の原文は「ZDR is not included in the standard Claude for Enterprise plan and cannot be enabled from your admin settings」です（出典：Zero data retention）。
Enterpriseを契約すれば付いてくるものではなく、管理画面からも有効化できません。
適格と確認された組織だけが対象で、Anthropicの営業窓口（contact sales）か担当のアカウントチームに依頼して有効化してもらいます。
ZDRは組織単位で、新しく作った組織には引き継がれません。
claude.aiのチャット、Coworkのセッション、Claude Code Analyticsが集める稼働のメタデータ（アカウントのメールアドレスや利用量）、外部連携（MCP）、利用者と席（契約上の利用枠）の管理は、ZDRの対象外です。
Anthropicの利用ポリシー違反としてフラグが立った会話は、ZDR下でも最大2年保持されます。
ZDRを有効にすると、/feedback・/bug・/share の送信が無効になります。
Anthropicのサーバー上でセッションを動かすクラウドセッション、自分の端末で動いているセッションをスマートフォンや別のパソコンから続けて操作するRemote Control、セッションの結果をclaude.ai上の対話的なページとして公開し、社内の相手に共有できるArtifactsも無効になります。
claude.aiのチャットとCoworkを1つにした画面（Chat and Cowork unified）と、Slackのスレッドで応答するClaude Tagも無効になります。
どれを業務で使っているかを確かめてから依頼します。

③全社に統制を効かせる管理者の設定

配布経路は4つ、プラン要件があるのは1つだけ

配布経路は、claude.ai管理コンソール経由のサーバー管理設定（起動時に取得し1時間ごとに再取得）、macOSの構成プロファイル（plist）とWindowsのレジストリの管理者領域（HKLM配下）のポリシー、端末上のファイル、利用者が書き換えられるレジストリ領域（HKCU配下）の4つです（出典：Set up Claude Code for your organization）。
公式はHKCUを、利用者が管理者権限なしで書き換えられるため、強制手段ではなく既定値として扱えと警告しています。
ファイル・plist・レジストリでの配布はプランに依存しません。
プランが必要なのは、管理コンソール経由のサーバー管理設定のほうです。
既定では、設定のキーを1つでも配った最初の経路だけが使われます（出典：Deploy managed settings）。

全員のPCに同じ設定を配り、開発者が項目を消せない形にする

全員の端末に同じ設定が届き、Claude Code で /status を実行した画面で効いていることを確かめるまでが完了です。
私のセットアップでは、キックオフから設定完了までを2〜4週間で見ています（Claude Code / Codex 法人セットアップのページ）。
経路を見る順番と、設定の優先順位は別物です。
前者は上の表の順番です。
経路をまたいでキーを分けると、下位の経路は読まれません。
env など例外になるキーがあるため、経路に分ける前に出典（Deploy managed settings）で確認してください。
もう1つは管理者が配る設定（上の表の4経路）と開発者側の設定を比べる5階層で、管理者が配る設定、起動時に指定する設定ファイル（claude --settings）、.claude/settings.local.json、.claude/settings.json、~/.claude/settings.json の順に優先されます。
操作を許可する一覧（permissions.allow）と拒否する一覧（permissions.deny）は、この5階層では各段の項目を足し合わせるため、開発者は項目を足せても、管理者が配る設定の項目は消せません（出典：Settings files and precedence）。

個人アカウントでの業務利用を技術的に止める

個人アカウントでの業務利用は、ログイン方法を固定する forceLoginMethod と、所属組織を固定する forceLoginOrgUUID で止めます。
接続先の提供元（AnthropicのAPIや各クラウド基盤）を限定する allowedProviders は Claude Code v2.1.285以降です。
forceLoginMethod を "gateway"（自社で運用する中継の仕組み（ゲートウェイ）経由でサインインさせる値）にする場合は、Claude Code v2.1.261以降が必要です。
ただし "gateway" の値はサーバー管理設定からは読まれないため、plistやHKLM配下のポリシー、または端末のファイルで配ります（出典：Server-managed settings）。
設定値によって必要な版が変わるため、出典（Authentication）で確認してください。
ただし公式自身が抜け道を挙げています。
認証用のトークンを発行する操作（claude setup-token）とGitHub連携を入れる操作（/install-github-app）は組織を検証しないため、利用者が別組織のトークンを発行できます。
Console（APIキーを管理する開発者向けの画面）からのログインも組織を検証しません。
サーバー管理設定は組織認証済みのアカウントにしか届かないため、公式は同じ設定キー（forceLoginMethod と forceLoginOrgUUID）をclaude.ai管理コンソールと端末の両方に置くよう指示しています（出典：Authentication）。
これは4経路を見る順番とは別で、設定が届かない端末に備えた重複です。

外部連携（MCP）の絞り方の基準

使うものを絞る、名前ではなくコマンドとURLで縛る

外部連携（MCP）は、Claude Codeから社内ツールや外部サービスを呼び出す接続の仕組みです。
私は、ここを最初に絞る対象として扱っています。
managed-mcp.json を配ると、そこに書いたサーバーと、設定キー managedMcpServers で管理者が配ったサーバーが読み込まれます。
このファイルは端末へ配る必要があり、管理コンソール（サーバー管理設定）からは配れません。
コンソールから配れるのは allowedMcpServers などの設定キーです。
managed-mcp.json を配ると、利用者やプラグインが追加したサーバーと claude.ai のコネクタ（claude.ai でつないだ外部サービス）が読み込まれなくなります。
コネクタを管理下のサーバーと一緒に読み込ませるには、管理者が配る経路（サーバー管理設定・plist/HKLM・managed-settings.json）で allowAllClaudeAiMcps: true を設定します。
利用者やプロジェクトの設定に書いても効きません（出典：Control MCP server access）。
managed-mcp.json を配った端末で起動時に設定ファイル（--mcp-config）を渡すと、渡したサーバーが無視されるのではなく、Claude Code が起動時に終了します（出典：Control MCP server access）。
開発用エディタVS Codeの拡張やデスクトップアプリが自分で登録するサーバーは対象外で、読み込まれ続けます。
デスクトップアプリが渡すコネクタは、claude.aiの組織設定で管理します（出典：Control MCP server access）。
統制の手段はほかに、設定のキーで管理者がサーバーを配る managedMcpServers（v2.1.259以降、URLで接続するサーバーだけが対象）、許可する allowedMcpServers、拒否する deniedMcpServers、管理者が配った許可リストだけを適用する allowManagedMcpServersOnly があります（細部はControl MCP server access）。
公式は、許可リストでも拒否リストでも、serverName の項目はセキュリティ制御にならないと明記しています。
サーバー名は利用者が自由に付けるラベルなので、どのサーバーにも github と名付けられます。
強制したいなら、サーバーを起動するコマンド（serverCommand）か接続先のURL（serverUrl）で縛ってください。

Claude Code の更新（v2.1.259）で許可リストの挙動が変わった

v2.1.259以降、自社が managed-mcp.json に書き、許可リスト allowedMcpServers に載せずにいたサーバーは、利用者が同版以降を初めて起動した時点で警告なく読み込まれます（設定値に変数を差し込む ${VAR} の記法を使うサーバーは、引き続き許可リストで判定されます）。
この変更は管理者が配ったサーバーの話です。
allowedMcpServers で利用者やプラグインのサーバーを判定するのは managed-mcp.json を配っていない端末です。
配った端末では、利用者やプラグインのサーバーは許可リストに載せても読み込まれません。
公式は、managed-mcp.json に書いたまま使わせたくないサーバーを、利用者が更新する前に serverCommand か serverUrl で拒否リスト（deniedMcpServers）へ追加するよう警告しています。
どのMCPサーバーもAnthropicは安全性の検査も管理もしない（原文：「doesn't security-audit or manage any MCP server」）と明言しており、つないだものは自社の責任範囲です。
managed-mcp.json に {"mcpServers": {}} だけを書いて配ると、利用者やプラグインが追加した分は読み込まれなくなり、claude.aiのコネクタは既定で止まります。
設定キー managedMcpServers で管理者が配った分は、この空ファイルでも読み込まれ続けます。
このキーを設定していなければ、空ファイルで残るのは、前に挙げたVS Codeの拡張やデスクトップアプリが登録するサーバーだけです。
利用者の画面には、自分が追加したサーバーが使えない理由が組織の方針だとは表示されないため、事前の周知が要ります。

権限とサンドボックスで守れる範囲

権限の既定モードはClaude Codeの版で変わる

権限は permissions の許可（allow）・確認（ask）・拒否（deny）と、管理者の規則だけを使わせる allowManagedPermissionRulesOnly、すべての確認を飛ばすモードの禁止、既定モードの指定で組みます。
Claude Code v2.1.283以降は、対話型ターミナルとVS Codeの既定開始モードが auto です。
auto は、利用者への確認の代わりに、別のモデル（分類器）が操作を審査するモードです。
公式は審査にかける操作と審査を飛ばす操作を分けており、すべての操作が審査されるわけではありません。
それ以前の版では、autoが既定の開始モードになるのは Pro・Max・Team のプランだけです（出典：Permission modes）。
「手動確認が既定」という前提で書かれた社内手順は、見直しが必要です。

サンドボックスで誤解されやすい限界

サンドボックス（実行できる範囲を区切る仕組み）には、誤解されやすい限界が3つあります。

• 対象は端末から実行する命令（シェルコマンド）だけ。Claudeのファイル操作、MCP、フック（決まった場面で自動実行する設定）はサンドボックスの外で動く
• 対応OSは macOS・Linux・WSL2（Windows上でLinuxを動かす仕組み）のみ。WSL2を使わないWindowsでは、シェルコマンドが区切りなしで実行される（対処はWSL2の中でClaude Codeを動かすこと）
• sandbox.enabled の既定は未設定で、結果として無効

出典はSandboxingです。
ファイル操作とMCPが対象外である以上、サンドボックスだけで秘匿情報を囲う設計は成り立ちません。

外部の文章に紛れた指示（プロンプトインジェクション）は防ぎきれない前提で設計する

外部から読み込んだ文章に紛れた指示は、完全には防げません。
公式の日本語版セキュリティ文書も「これらの保護機能はリスクを大幅に軽減しますが、どのシステムもすべての攻撃に完全に免疫があるわけではありません」と書いています（出典：セキュリティ）。
Anthropicの情報セキュリティ担当の副責任者（Deputy CISO）が、企業の情報セキュリティ責任者（CISO）向けに書いたガイド（2026年7月17日）は、攻撃の成功率は下がり続けているがゼロではないとし、最も強い対策は送信先の限定（egress allowlisting）だとしています（出典：CISO's guide to agentic AI）。
sandbox.network.allowedDomains で通信先を絞る根拠になります。
ただしこの設定が及ぶのは端末から実行する命令だけで、外部連携（MCP）やファイル操作の通信は対象外です。
ネットワーク側の制限と併せ、権限の確認は外しません。

配った設定が効いているかを確かめる

効いている設定の出どころを画面で確認する

/status の Setting sources 行で実際に効いている設定の出どころを確認し、claude mcp list でつながっている外部連携を確かめ、claude doctor で環境を点検します。
私は初期構築の完了判定に、この3つの確認を入れています。

サーバー管理設定が適用されない不具合が実際にあった

2026年9月29日に、脆弱性の告知（アドバイザリ）が公表されました。
GHSA-gfvf-j8jh-jxxw / CVE-2026-103012、深刻度Lowです。
保存済みのAPIキーが組織のサインインより優先され、組織のサーバー管理設定が適用されませんでした。
影響範囲は Claude Code の 2.0.68以上2.1.260未満で、2.1.260で修正済みです。
MDMやファイルでの配布は影響を受けないとされています（出典：GHSA-gfvf-j8jh-jxxw）。
「配ったつもりで効いていない」状態が実在したことが、画面での確認を手順に入れる理由です。
監査の記録は、稼働の記録を社内の監視ツールへ送り出す仕組み（OpenTelemetry）や、活動履歴を取得するCompliance APIで残します。
Compliance APIを使える条件は、Anthropicの公式ドキュメントで確認してください。
設定キーも既定値も版で変わるので、四半期に1回は公式の変更履歴を確認してください。

生産性と統制は二者択一ではない

指示書・作業フォルダ・手順の三層は、管理者が配る設定とサンドボックスで囲った範囲の中で使わせる

統制を足すと使いにくくなるとよく言われます。
実際には、文脈を教える仕組みを先に作るほうが効きます。
社内の判断基準を書いた指示書（CLAUDE.md）、作業する場所を1つのフォルダにまとめること、よく使う作業の手順という三層で文脈を渡すと、毎回ゼロから説明しなくて済みます。
この三層を、管理者の設定とサンドボックスで囲った範囲の中だけで使わせるのが私の構築の型です（指示書の書き方はClaude Code 法人導入チェックリスト）。

最初の業務を1つに絞り、再現できるところまで確かめる

導入の最初に、ログイン方式を確認してください。
APIキー方式は使った分だけの従量課金になるため、想定外の金額になることがあります。
Amazon BedrockやGoogle Cloud、Consoleでの従量課金を選ぶ理由がないなら、Team・Enterpriseのサブスクのアカウントでログインします。
最初に任せる業務は1つに絞り、つないだツールで1操作が成功すること、主目的の業務を最後まで1回通せること、担当者が自分の手で1回再現できることを確かめてから広げます。

よくあるご質問

導入前に確認するチェックリスト

• ログイン方式を決めたか（従量課金のAPIキー方式を選ぶ理由を確認したか）
• 個人アカウントでの業務利用を止める設定を配ったか（管理コンソールが使えるなら端末と両方、使えないなら端末のファイルかポリシーに）
• 学習に使われない条件（商用条件に該当するか）を文書で確認したか
• 端末に平文で残る記録（既定30日）の扱いを社内規程に書いたか
• 保持期間の要件を整理し、ゼロデータ保持が必要かを判断したか
• MCPをサーバー名ではなく、コマンドかURLで縛ったか
• サンドボックスの対象外（ファイル操作・MCP・フック・WSL2を使わないWindows）を把握したか
• 配った設定が効いているかを /status などの画面で確認したか

本記事の内容は、すべて2026年10月17日時点の確認です。
公式の仕様は版で変わるため、判断の前に公式ドキュメントで再確認してください。
統制の設計と全社配布で判断に迷う箇所があれば、法人導入のページからご相談いただけます。