本文へ移動
記事一覧

Claude Codeのセキュリティ|法人導入前に決める権限とデータ管理

公開 2026-07-23更新 2026-07-23読了目安 8分

Claude Codeのセキュリティを法人導入前に判断するなら、見るべき中心はツール名より境界です。どのリポジトリで起動するか、どの操作を事前許可するか、会話へ入れてよいデータをどこまでにするか、承認と監査を誰が見るか。この4点が曖昧なまま利用範囲だけを広げると、便利さに合わせて権限が増え、あとから説明しにくい運用が残ります。 2026年7月23日に確認したAnthropicの公式情報では、Claude Codeは既定で読み取り中心に始まり、ファイル編集や多くのBash実行では明示的な承認を求める設計です。起動ディレクトリを作業境界にする考え方、allow、ask、denyによる権限ルール、商用利用時のデータ学習方針、標準保持期間、OpenTelemetryによる可視化も公開されています。安全策は用意されていますが、会社ごとの機密区分、本番環境への近さ、外部連携の有無までは自動で判断してくれません。 導入前の答えは、全社一律の利用可否では出しにくいものです。通常の開発リポジトリ、顧客データに近い領域、運用手順を含むリポジトリでは、許せる失敗の大きさが違います。導入時は、権限、入力データ、承認、監査を、開発チームが日常作業で守れる粒度まで具体化します。

SECTION 01

Claude Codeのセキュリティは作業境界で決まる

Claude Codeは、ターミナルやIDE上でコードを読み、変更案を作り、必要に応じてテストやコマンド実行まで進める開発支援ツールです。Claude Codeの基本を理解すると、法人導入時の論点は自然に絞られます。コードを読める範囲、編集できる範囲、実行できるコマンド、外部サービスへ触れる経路です。これらは便利さの源泉であると同時に、社内規程で説明できる形にしておくべき操作面でもあります。

公式ドキュメントでは、Claude Codeは読み取り中心の既定動作から始まり、ファイル編集やBashコマンドには承認を挟むと説明されています。起動したフォルダとその配下を主な作業境界とし、親ディレクトリへの書き込みには明示許可が必要です。作業ディレクトリ外の読み取りも承認対象になります。つまり、どこで起動するかという何気ない習慣が、実際のセキュリティ境界になります。

社内ルールでは、Claude Codeを単なるチャットAIとして扱うより、開発端末で動く権限付きエージェントとして扱う方が実態に合います。人間の開発者が持つ権限の範囲内で動く場面が多くても、提案、編集、実行が短い間隔で連続するため、確認の質が落ちると影響が広がります。導入初期に決めるべきものは、AIへの信頼度より、失敗したときに止まる場所です。

SECTION 02

権限は作業単位で設計する

権限設計の出発点は、許可コマンドの羅列より作業単位です。調査、テスト実行、フォーマット、軽微な修正、依存関係の追加、本番運用ファイルの変更は、同じ「開発作業」でもリスクが違います。Claude Codeにはdefault、acceptEdits、plan、auto、dontAsk、bypassPermissionsなどの権限モードがあり、allow、ask、denyのルールでツール利用を制御できます。モード名だけで安全性を判断せず、どの業務に割り当てるかを決める必要があります。

通常のアプリケーション開発では、テスト、型チェック、フォーマッタ、read-onlyの調査を事前許可に寄せる設計が現実的です。機密度の高いリポジトリではplanモードや手動承認を基本にし、秘密情報に近いファイル、顧客固有情報、運用手順、マイグレーションはaskまたはdenyへ寄せます。本番資格情報が端末やリポジトリの近くにある場合、Claude Code以前に端末管理とファイル配置を見直すべきです。

特に注意したいのはbypassPermissionsです。公式ドキュメントは、このモードが多くの許可プロンプトを省く一方、コンテナやVMのような隔離環境で使うものだと説明しています。autoも利便性が高いため、組織のmanaged settingsで無効化するか、対象チーム、端末、リポジトリ、期間を紐づけて扱う方が監査時に説明しやすくなります。

deny、ask、allowはこの順に評価され、広いdenyは狭いallowより優先されます。守る領域を先に拒否してから、低リスク作業だけを許可する組み立てにすると、例外が肥大化しにくくなります。CLAUDE.mdやプロンプトの指示はClaudeが試みる行動を整えますが、権限そのものを変える仕組みではありません。強制力が必要な境界は設定、管理ポリシー、端末運用で閉じます。

SECTION 03

入力データと保持期間を分けて見る

データ管理では、学習利用、サーバー側保持、ローカル保存、フィードバック送信を分けて確認します。2026年7月23日に確認した公式情報では、Team、Enterprise、APIなど商用条件のClaude Code利用について、顧客が明示的にモデル改善へ提供する場合を除き、AnthropicはClaude Codeへ送信されたコードやプロンプトを生成モデルの学習に使わないと説明しています。この説明は重要ですが、学習に使われないことと保存が発生しないことは別の論点です。

公式のData usageでは、商用ユーザーの標準的な保持期間は30日とされています。Claude for Enterpriseの適格アカウントではZero Data Retentionが利用できる場合があるものの、標準Enterpriseプランに自動付帯しないため、Anthropic側での個別有効化が必要です。さらに、Claude Codeクライアントはセッション再開のため、既定でローカルに平文のセッションtranscriptを30日保存すると説明されています。社内のデータ管理でサーバー側だけを見ると、このローカル保存が抜け落ちます。

フィードバック送信も個別に扱うべき領域です。/feedback、/bug、/shareで共有されたtranscriptは5年間保持されると公式に説明されています。セッション品質調査の後続確認で明示的にYesを選ぶと、会話transcriptやローカルログがアップロードされ、共有transcriptは最大6か月保持されます。既知のAPIキーやトークンパターンはアップロード前に編集されると説明されていますが、ソースコードや会話内容はそのまま含まれ得ます。

入力してよい情報は、機密区分に合わせて具体化します。公開済みコード、社内限定コード、顧客固有情報、秘密鍵や.env、未公開の脆弱性情報、契約上の制限があるデータは同列に扱えません。Claude Codeのセキュリティを検討する際は、モデル学習方針だけを確認して終わらせず、保持期間、ローカル端末、フィードバック経路、MCPや外部連携先まで含めたデータ境界を作る必要があります。

SECTION 04

承認と監査を開発体験に組み込む

承認は、多ければ安全というものではありません。確認が頻発すると、開発者は内容の吟味より作業継続を優先しやすくなります。Claude Codeには、よく使う安全なコマンドを許可する仕組みがあります。だからこそ、事前許可はnpm test、型チェック、フォーマット、読み取り調査のような低リスク作業へ寄せ、外部ネットワークアクセス、パッケージ追加、git push、マイグレーション、秘密情報に近いファイル操作は承認または拒否の対象にします。

監査では、ローカルCLI、Claude Code on the web、Remote Controlの違いを分けておきます。公式情報では、Claude Code on the webのクラウド実行はAnthropic管理の分離VMでセッションが動き、クラウド環境の操作は監査目的でログ化されます。Remote Controlはローカルマシン上のClaude CodeプロセスへWeb UIが接続する形で、コード実行とファイルアクセスはローカルに残ります。監査ログに残る範囲を誤解すると、事故時の再現に必要な情報が足りなくなります。

組織全体の可視化にはOpenTelemetryの利用が公式に説明されています。Claude Codeは使用量、コスト、ツール活動などをメトリクスやイベントとしてエクスポートでき、管理者はmanaged settingsで組織横断の設定を配布できます。SIEM(セキュリティログを集約・分析する基盤)へ送るか、既存のObservability基盤へ送るか、導入初期は軽いレビューに留めるかは会社の成熟度で変わります。それでも、誰が、どのリポジトリで、どの権限モードを使い、どの種類の操作をしたかを追える線は必要です。

監査の目的は、開発者を疑うことではありません。事故時に再現できること、許可ルールが実態に合っているか見直せること、禁止したはずの運用が抜け道になっていないか確認できることです。AI駆動開発の考え方を組織に入れるなら、ツール利用の拡大と同時に観測点も増やします。承認と監査が日常の開発体験から浮くと、ルールは守られる前に迂回されます。

SECTION 05

法人導入前に決める実務項目

導入前のセキュリティレビューは、運用に落ちる決定へ変える必要があります。対象リポジトリ、起動ディレクトリ、禁止ファイルと禁止パス、許可するBashコマンド、使える権限モード、MCPサーバーの信頼基準、フィードバック送信、セッション調査への回答ルール、ローカルtranscriptの扱い、OpenTelemetryやクラウド実行ログを見る責任者を決めます。抽象的な利用規程のままだと、開発者が目の前の承認画面で判断できません。

試験導入でも境界は先に置きます。個人の裁量だけで始めると、便利な許可がローカル設定に残り、あとから全社ポリシーへ戻しにくくなります。一方で、すべてを禁止した状態では実務上の価値や負荷が見えません。対象チーム、対象リポジトリ、許可コマンド、扱ってよいデータ、レビュー方法をセットにし、短い期間で見直せる形にすると、速度と説明責任の両方を評価できます。

CotomuのAI駆動開発支援では、研修、導入パッケージ、技術顧問として、こうした境界設計をチームの開発実務に合わせて整理します。公開LP上の提供内容は、研修30万円、導入パッケージ50万円から、技術顧問15万円/月、初回60分相談無料です。生産性や品質向上を保証せず、Claude Code、Codexなどの公式パートナーまたは認定を示す表現も使いません。扱う範囲は、会社ごとの権限、データ、承認、監査の決め方です。

日常作業を止めずに守れる粒度へ落とし込めるかが、法人導入の判断条件です。2026年7月時点の公式情報を前提にすると、法人が決めるべき最小単位は、作業領域、権限モード、入力データ、保持と送信、監査ログ、例外承認です。この6つをリポジトリの機密度ごとに定義できれば、Claude Codeのセキュリティ検討は漠然とした不安から、試験導入できる条件の確認へ変わります。

FAQ

よくある質問

Q. Claude Codeは法人利用のコードやプロンプトを学習に使いますか?

2026年7月23日に確認した公式情報では、Team、Enterprise、APIなど商用条件のClaude Code利用について、顧客が明示的にモデル改善へ提供する場合を除き、Anthropicはコードやプロンプトを生成モデルの学習に使わないと説明しています。標準保持、ローカル保存、フィードバック送信は別の論点として確認が必要です。

Q. Claude Codeの権限はどこまで制限できますか?

Bash、Read、Edit、WebFetch、MCPなどに対してallow、ask、denyのルールを設定できます。managed settingsを使えば、組織として使える権限モードやMCP、フックなども制御できます。自然言語の指示には強制力がないため、設定で境界を作ることが重要です。

Q. bypassPermissionsは法人導入で使ってよいですか?

公式ドキュメントでは、bypassPermissionsは多くの許可プロンプトを省く強いモードとして説明され、コンテナやVMのような隔離環境で使うものとされています。法人導入では標準利用を避け、managed settingsで無効化するか、例外条件を明確にする運用が現実的です。

Q. 監査ログは何を見ればよいですか?

少なくとも、誰がどのリポジトリで利用したか、どの権限モードだったか、どの種類のツール操作が行われたか、例外的な承認があったかを追える状態にします。Claude CodeはOpenTelemetryでメトリクスやイベントを出せるため、既存の監視基盤やSIEMとの接続方針を導入前に決めると運用しやすくなります。

公式情報・参考資料