Claude Code セキュリティは権限だけで守れるか？3論点で見極める

Claude Codeのセキュリティは、法人導入時に権限・隔離環境・データ利用条件の三つに分けると、安全対策に不足があるか判断できます。

Claude Code自体が初めての方は、Claude Codeの用途と違いで基本を押さえると、この先の安全対策を理解しやすくなります。

第一は権限です。Permission rules（操作ごとの許可・拒否を定める設定）で制御します。機密ファイル、コマンド、通信、MCP（AIと外部ツールを接続する共通規格）は、Deny（常に拒否）またはAsk（実行前に確認）に指定可能です。Managed settings（管理者が全社配布する強制設定）は、利用者やプロジェクトの設定より優先してルールを適用します。確認を省略するbypassPermissionsモードも、組織ポリシーで無効化してください（Claude Code Docs）。

第二は隔離環境です。対応環境では、Bashサンドボックス（シェル操作の範囲を制限する隔離機能）を使えます。シェルコマンドが書き込める場所と接続先を絞れます。ただし、隔離の中心はBashです。ファイル操作やMCPを含むClaude Code全体を囲う仕組みではありません。

第三はデータ利用条件です。Team、Enterprise、APIを商用条件で使う場合、送信データは、顧客が開発パートナープログラムへの参加を選ばない限り、生成モデルの学習に使われません。Free、Pro、Maxの個人向けアカウントでClaude Codeを使う場合とは、条件を分けて確認してください（Anthropic Privacy Center）。

Claude Codeのセキュリティ設定だけで情報漏洩を防ぐことはできません。利用者が承認内容を読まずに許可すれば、Askは防波堤にならないからです。承認前にコマンドを確認し、秘密情報を除外するほか、利用を認めるリポジトリ（コードと変更履歴を管理する保管単位）と外部接続先を社内ルールで決めます。

情シスが機密リポジトリの導入試験で/permissionsを開き、確認なしで読める範囲やローカル設定由来の許可を見つけた時点で、審査は止まります。情シスは三つの判断軸のうち、端末上の操作範囲と外部への到達範囲を経路別に具体化して最初に確認します。機密ファイルを読めるかはファイルの重要度ではなく設定範囲で決まるため、対象パスはPermission rulesでDeny（操作を拒否する設定）にし、判断が必要な範囲はAskです。

curlなどのBash（コマンドを実行するシェル）通信だけを止めても、WebFetch（Web上の情報を取得する機能）やMCPには別の経路が残ります。通信手段ごとにClaude Codeの権限対象が異なるためです。社内で許可する外部接続先とMCPを定め、それ以外の通信経路はDenyまたはAskにします。

設定を配った後も、端末側の別設定を確認してください。Managed settingsはユーザーやプロジェクトの設定より優先されます。強制後に/permissionsを開き、有効なルールと設定元を照合します。

対応環境では、Bashサンドボックスで承認後のBashコマンドがアクセスできる場所や通信先を絞れます。ただし、中心対象はBashです。承認内容を読む責任や、Claude Code全体を完全に隔離する役割までは担いません。ファイル操作やMCPには権限ルールを残し、Bashの書き込み先と接続先だけをサンドボックスで狭めます（Claude Code Docs）。

法務担当者が導入審査票で「学習利用なし」を確認しても、保存や任意送信の扱いまで決まるわけではありません。データ利用条件は設定画面の有無だけで判断せず、契約文書、導入時点の公式文書、実機で確認した挙動を分けて記録します。

確認項目は、一つの「AI利用可否」ではなく、次の四分類です。

Claude Codeの商用利用では、標準の保持条件とゼロデータ保持契約の適用可否を分けて確認する必要があります。Claude Codeのローカルクライアントは、セッション再開のため、既定で最大30日間、ローカルにセッション記録を保存しています。/feedback、/bug、/shareは会話データを送信する場合があるため、導入前に無効化設定と保持条件を確認してください（Claude Code Docs）。

端末や組織内に残るデータは、文書だけで結論を出さず、導入予定の構成で実機検証します。端末管理、共有環境、監視を有効にした場合のログ運用も含め、記録が残り得る場所、閲覧できる人、削除の担当者を社内基準で定めます。

情シス担当者（社内ITを管理する情報システム部門）がManaged settingsを配布しても、社内規程の禁止事項が空欄のままでは導入審査は終わりません。導入可否を分けるのは、製品の設定を「誰に何をさせないか」という社内ルールに変換できるかどうかです。

ここまでに確認した個別条件は、一つの判定票に集約します。製品側で使えるのは、権限、管理設定、隔離手段。許可する情報や接続先を決める責任は会社側に残ります。Claude Code法人導入の検証を始める条件は、次の六項目です。

• 設定の強制力を確認し、Managed settingsでPermission rulesのDeny・Askを配布して、利用者が上書きできない状態にします。

• 確認を飛ばす経路を確認し、組織としてbypassPermissionsモードを禁止したうえで検証を始めてください。

• コマンドの隔離範囲を確認し、対応環境ではBashサンドボックスも使って、書き込み先と通信先を制限します。

• 作業対象を確認し、許可するリポジトリ、除外する機密ファイル、外部接続先、MCPをClaude Codeの社内ルールに明記してください。それ以外はDenyまたはAskです。

• 承認手順を確認し、利用者が実行前にコマンドの変更先と送信先を読み、秘密情報を作業対象から外す運用にします。

• データ条件を確認し、契約と規程に反映してください。ゼロデータ保持は標準機能ではなく、対象組織ごとに適格性確認と有効化が必要です（Claude Code Docs）。

全部を満たせない場合は、まずDeny・Askの強制とbypassPermissionsモードの禁止を優先してください。管理設定で禁止を強制できない端末や、保持・送信条件を確認できない利用形態では、情報漏洩対策が利用者の注意頼みになります。そうした端末や利用形態は、機密情報を扱う検証から外します。

- Claude Code Docs「Permissions」 - Anthropic Privacy Center「Does Anthropic Act as a Data Processor or Controller?」 - Claude Code Docs「Security」 - Claude Code Docs「Data usage」 - Claude Code Docs「Managed settings」 - Claude Code Docs「Zero data retention」