Claude Code セキュリティ完全ガイド｜企業導入の設定・リスク管理

Claude Codeはファイルシステムへの読み書きとシェルコマンド実行を自律的に組み合わせるAIコーディングエージェントであり、従来のIDEプラグイン型ツールとは異なるリスクプロファイルを持つ。公式ドキュメントに基づく正確なパーミッション設計とデータポリシーの把握が、企業導入における安全運用の前提となる。

Claude Code セキュリティの全体像：企業が把握すべきリスク構造

企業の意思決定者がまず把握すべきは、リスクの類型とその制御可能性だ。Claude Codeにおけるセキュリティリスクは大きく「APIキー漏洩」「機密コードの外部送信」「.env混入（環境変数ファイルの誤コンテキスト混入）」の3類型に集約される。これらはいずれも設定と運用規律によって制御可能なリスクであり、適切な設定を施した状態と無策のままの状態とでは、組織が負うリスクの大きさが根本的に異なる。

Anthropic公式セキュリティドキュメントは、Claude Codeがデフォルトで読み取り専用パーミッションを採用し、ファイル編集・テスト実行・コマンド実行など追加の操作が必要な場合には明示的な許可を要求する設計であることを明記している。さらに、書き込みアクセスはClaude Codeが起動されたフォルダとそのサブフォルダに限定され、親ディレクトリのファイルを明示的な許可なく変更することはできない。これはセキュリティ境界として機能する重要な設計上の制約だ。

独立行政法人情報処理推進機構（IPA）は「AIセキュリティ短信」を継続的に発行し、生成AIツールの業務利用に際するセキュリティ上の留意点を公表している。AIシステムに対するプロンプトインジェクション攻撃への継続的な注意喚起と、組織的なリスク管理体制の重要性が強調されており、Claude Codeを導入する企業はIPAが示す観点を照らし合わせたリスクアセスメントを社内手続きとして組み込むことが、ガバナンス上の基本姿勢となる。

なお、本記事ではセキュリティ設定と運用ガバナンスに特化して解説する。ツールの基本動作や料金体系については、Claude Codeの使い方ガイドおよびClaude Code料金・プラン解説を参照されたい。

APIキー漏洩 環境変数・設定ファイルに 記載したキーが 外部に露出するリスク → denyルール・Secrets Manager 技術レイヤーで制御可

機密コード送信 ソースコードが推論APIを 経由してAnthropicへ 送信される → Enterprise DPA・プロキシ制御 契約レイヤーで制御可

.env混入 環境変数ファイルを誤って コンテキストに含め てしまうリスク → denyルール・ファイル制限 技術＋運用レイヤーで制御可

出典: Anthropic公式セキュリティドキュメント等をもとに構成

Claude Code パーミッションシステムの構造：公式仕様に基づく詳細

パーミッション評価の順序

Anthropic公式パーミッションドキュメントによれば、Claude Codeは階層的なパーミッションシステムを採用しており、ツール実行要求に対して次の順序で評価を行う。

1. ホック（Hooks）の実行：最初にフックが実行される。フックは呼び出しを拒否するか、次のステップへ渡すかを決定できる。
2. denyルールの確認：disallowed_toolsとsettings.jsonのdenyルールを照合する。denyルールが一致した場合、bypassPermissionsモードであってもツールはブロックされる。
3. パーミッションモードの適用：アクティブなパーミッションモードを適用する。
4. allowルールの確認：allowed_toolsとsettings.jsonのallowルールを照合する。
5. canUseToolコールバック：上記いずれでも解決されない場合、canUseToolコールバックで判断を求める。dontAskモードではこのステップがスキップされ、ツールは拒否される。

重要な設計上の特性として、同ドキュメントはdenyルールの動作の違いを明記している。ベアネームのdenyルール（例：Bash）はツールそのものをClaudeのコンテキストから除去するため、Claudeはそのツールの存在を認識しない。一方、スコープ付きdenyルール（例：Bash(rm *)）はツールは利用可能なまま残し、Claudeが当該パターンに一致する呼び出しを試みた際にブロックする。この違いは.envファイルや機密パスの保護設計において実践的に重要な意味を持つ。

また、パーミッションルールはClaude Codeによって執行されるものであり、モデル自体によって執行されるのではない点にも注意が必要だ。プロンプトやCLAUDE.md内の指示はClaudeが試みる動作を形成するが、Claude Codeが許可・拒否する内容を変更するものではない。

ツール種別とパーミッションの関係

公式ドキュメントが示すツール種別ごとのパーミッション要件は次の通りだ。

ツール種別	例	承認要否	「今後確認しない」の有効範囲
読み取り専用	ファイル読み取り、Grep	不要	該当なし
Bashコマンド	シェル実行	要	プロジェクトディレクトリとコマンドの組み合わせで永続的に有効
ファイル変更	編集・書き込み	要	セッション終了まで有効

出典：Anthropic Claude Code — Configure permissions

パーミッションモードの概要

公式パーミッションドキュメントによれば、Claude Codeはsettings.jsonのdefaultModeで設定可能な複数のパーミッションモードをサポートしている。また、公式セキュリティドキュメントが説明するAccept Editsモードは、ファイル編集とmkdir・touch・rm・mv・cp・sedなど固定のファイルシステム系Bashコマンドを作業ディレクトリ内パスに限って自動承認する。それ以外のBashコマンドとスコープ外パスは引き続き確認プロンプトが表示される。各モードの詳細な使い分けについては公式ドキュメントで確認されたい。

/permissionsコマンドを使用することで、すべてのパーミッションルールとその設定元となるsettings.jsonファイルを一覧表示し、管理することができる。

サンドボックスによる隔離

公式セキュリティドキュメントによれば、/sandboxコマンドでBashコマンドをファイルシステムおよびネットワーク分離でサンドボックス化できる。これにより、パーミッションプロンプトを増やすことなくセキュリティを維持しながら、Claude Codeが自律的に作業できる境界を定義することが可能だ。設計思想として「最小権限の原則」が採用されており、エージェントが意図せず重要ファイルへアクセスしたり、外部ネットワークへ不正に接続したりするリスクを低減する。

企業導入時のClaude Code セキュリティ設定：具体的な実装方針

settings.jsonによるdenyルールの設計

公式パーミッションドキュメントによれば、settings.jsonのパーミッション設定はバージョン管理システムにチェックインして組織内の全開発者に配布できる。同時に、個々の開発者による個別カスタマイズも可能な階層構造を取っている。

実装上の優先事項は次の通りだ。

• 機密情報を含むファイルパス（.env、*.pem、*.key、*credentials*など）をdenyリストに明記し、コンテキスト混入を構造的に排除する。ベアネームdenyルールを使用するとツールがコンテキストから完全に除去されるのに対し、スコープ付きdenyルールはツールを残したまま特定パターンの呼び出しのみをブロックするという動作の違いを踏まえて設計する
• 本番環境のデータベース接続情報が格納されるディレクトリへのアクセスを制限し、操作範囲を開発・ステージング環境に限定する
• シークレットマネージャー（AWS Secrets Manager、HashiCorp Vaultなど）を経由したAPIキー管理を徹底し、コードへの直書きを組織ポリシーとして禁止する
• Pre-Tool Use Hookを活用し、破壊的な操作（ファイル削除、本番データベースへの書き込みなど）の実行前に人間の承認ステップを挿入する
• 設定ファイル自体をGit管理し、変更時にはコードレビューと同等の承認フローを経ることを義務付ける

特に注意が必要なのは、denyルールはClaude Codeの自律的なファイルアクセスを制限するものであって、コード内で定義された外部API呼び出しまでは制御できない点だ。ネットワーク通信の制御は後述のプロキシ設計と組み合わせて実装する必要がある。

データポリシーの確認：モデル学習への利用有無

機密コードの取り扱いに関して、Anthropic公式データ利用ポリシーは以下の区分を明示している。

• 商用ユーザー（TeamおよびEnterpriseプラン、API、サードパーティプラットフォーム、Claude Gov）：顧客が明示的にデータ提供を選択しない限り、Claude Codeに送信されたコードやプロンプトを生成モデルの学習に使用しない
• コンシューマーユーザー（Free、Pro、Maxプラン）：設定により、将来のClaudeモデル改善のためのデータ利用を許可するかどうかを選択できる。これらのアカウントからClaude Codeを使用する場合も同様だ

また、同ドキュメントによれば、/feedbackコマンドを使用してフィードバックを送信した場合、そのフィードバック（トランスクリプトを含む）は5年間保持される。セッション品質調査（「How is Claude doing this session?」プロンプト）の評価自体は会話内容を収集しないが、その後に表示される任意のフォローアップ調査でYesを選択した場合は会話トランスクリプトがAnthropicにアップロードされる。既知のAPIキーとトークンのパターンはアップロード前に編集処理されるが、ソースコードやファイル内容はそのままアップロードされる点に注意が必要だ。共有されたトランスクリプトは最大6ヶ月間保持される。

企業導入においては、これらのデータポリシーをAPIを通じて送信されたコードの知的財産保護の観点から法務・情報セキュリティ部門が精査することが求められる。

IPAの指摘する生成AIセキュリティ観点との対照

IPAが公表する「AIセキュリティ短信」では、生成AI活用における組織的なリスク管理の必要性が繰り返し強調されている。同資料が示す観点は、(1)データ送信先と利用規約の確認、(2)インプットデータの機密分類、(3)出力物の品質検証、(4)利用ポリシーの策定と教育——の4点に集約される。Claude Codeの導入においても、この4観点に照らした内部審査を導入判断の前提とすることが、IPAのガイダンスに沿った対応となる。

ネットワーク・アクセス制御の設計方針

企業のセキュアな開発環境でClaude Codeを運用する場合、以下のネットワーク制御が推奨される。

• Claude CodeのAPIエンドポイントへの通信を企業の認証済みプロキシ経由に限定し、全通信ログを一定期間保持する
• 開発端末から本番環境への直接アクセスを遮断し、Claude Codeの操作対象を開発・ステージング環境に限定する
• CI/CDパイプラインへの脆弱性スキャンを組み込み、Pull Requestのマージ条件として位置付ける
• フック（Hooks）を活用して操作イベントを外部システムと連携させ、異常なファイル操作やコマンド実行をリアルタイムで検知するルールを設定する

スラッシュコマンドの活用方法についてはClaude Code スラッシュコマンド解説を参照されたい。

プロンプトインジェクション対策：公式の保護機構

公式セキュリティドキュメントは、プロンプトインジェクション——攻撃者がコードのコメント・外部ファイル・依存パッケージのドキュメントに悪意のあるテキストを埋め込み、エージェントの指示を上書きまたは操作しようとする手法——に対してClaude Codeが複数の保護機構を備えていることを記載している。具体的な保護機構の詳細については公式セキュリティドキュメントを参照されたい。

ただし、この攻撃ベクターはdenyルールやサンドボックスだけでは防御が難しく、現時点で完全な排除は保証されていない。IPAのAIセキュリティ短信でも、AIシステムを標的にした入力改ざん攻撃への継続的な注意喚起がなされている。エージェントに与えるコンテキスト範囲を必要最小限にとどめるという設計原則の徹底が、現実的な緩和策となる。

Claude Code セキュリティの限界と導入判断のための評価フレームワーク

構造的な限界：技術設定で制御できないリスク

どれほど精緻なセキュリティ設定を施しても、Claude Codeを含むAIコーディングエージェントには現時点で解消されていない構造的な限界が存在する。意思決定者はこれを正確に認識した上で導入判断を行う必要がある。

プロンプトインジェクション攻撃への対応：悪意のあるテキストがコードのコメントや外部ファイル、依存パッケージのドキュメントに埋め込まれた場合、エージェントがその指示に従って意図しない操作を行うリスクは、現時点では完全には排除されていない。この攻撃ベクターはdenyルールやサンドボックスだけでは防御が難しく、エージェントに与えるコンテキスト範囲を最小化するという設計原則の徹底が現実的な緩和策となる。

生成コードの品質とセキュリティ：Claude Codeが生成するコードは、セキュリティ上の脆弱性を含む可能性がある。公式セキュリティドキュメントも「Claude Codeはあなたが付与したパーミッションの範囲内でのみ動作する。提案されたコードとコマンドを承認前に安全性の観点でレビューする責任はユーザーにある」と明示している。重要なコード変更に対しては引き続き人間によるコードレビューが不可欠だ。

バージョン更新の急速さ：Claude Codeは高頻度でリリースが続いており、新機能が新たなセキュリティ上の考慮事項を生み出す可能性がある。企業の変更管理プロセスにおいて、バージョンアップの事前評価サイクルを定めることが必要だ。特にサンドボックスのようなOSレベルの機能変更は、既存のセキュリティ設定に影響を与える可能性があるため、リリースノートの精読を義務付ける体制が求められる。

競合ツールとのセキュリティ特性比較

AIコーディングツールの選定において、セキュリティ特性の比較は重要な評価軸の一つとなる。以下の表は公開情報をもとに主要ツールの特性を整理したものだ。各社の最新仕様は公式ドキュメントで直接確認することを求める。

評価項目	Claude Code	GitHub Copilot	Cursor
サンドボックス分離	/sandboxでファイルシステム・ネットワーク分離を有効化（公式）	IDE内動作・エージェント機能は限定的	IDE内動作・エージェント機能あり
デフォルトの書き込み制限	起動フォルダとサブフォルダのみ（公式）	IDE設定に依存	設定ファイルで制御可
監査ログ・外部連携	Hooks機能で操作イベントを外部システムと連携可（公式）	GitHub Audit Logとの連携	限定的
ファイルアクセス制限	settings.jsonのdenyルールで制御可（公式）	IDE設定に依存	設定ファイルで制御可
モデル学習への非利用（商用）	Team/Enterprise/API利用時は原則不使用（公式）	Microsoft Enterprise契約で対応	Cursor Business/Enterpriseで対応
パーミッション評価の透明性	5ステップの評価順序を公式ドキュメントで明記（公式）	公開情報に基づく	公開情報に基づく
プロンプトインジェクション対策	複数の保護機構を実装（完全な防御は現時点で困難）（公式）	同様に課題あり	同様に課題あり

※本表は各社公開情報をもとに整理。各社の最新仕様は公式ドキュメントで確認のこと。自社製品DeepAIは本比較表の対象外。

Claude CodeとCursorの詳細比較についてはClaude Code vs Cursor 比較記事を、Claude CodeとOpenAI Codexとの比較についてはClaude Code vs Codex 比較記事も参照されたい。

組織的なセキュリティガバナンスの構築

ツールレベルの設定だけでは不十分であり、組織的なガバナンスの整備が導入の前提条件となる。具体的には以下の体制整備が求められる。

• 利用ポリシーの文書化：どのプロジェクト・データ分類でClaude Codeを使用してよいかを明文化し、開発者全員に周知する。機密情報の定義と扱いについて、情報セキュリティポリシーとの整合を確認する。
• APIキー管理の一元化：個人アカウントによるAPIキー利用を禁止し、組織単位でキーを発行・定期ローテーションする体制を整える。キーの発行・失効履歴を監査証跡として保持する。
• インシデント対応手順の整備：機密情報の誤送信や不審な操作が検知された際の連絡経路と対応手順を事前に定め、年1回以上の訓練を実施する。
• 定期的なセキュリティレビュー：メジャーバージョンアップのたびに新機能のセキュリティ影響を評価するサイクルを組織的に維持する。評価結果をポリシーに反映するまでの期間（例：2週間以内）を明文化する。
• 開発者教育：Claude Codeの動作原理とリスク類型について、全利用者に対してオンボーディング時の教育を実施する。特に.env混入のリスクと防止方法は、実習形式で体験させることが定着に有効だ。

Claude Codeの導入を体系的に進めたい場合は、Claude Code はじめ方ガイドも参照されたい。API利用コストの試算についてはClaude Code API料金ガイドが参考になる。

まとめ：経営・IT責任者がとるべき次のアクション

Claude Code セキュリティを企業として適切に管理するためには、技術設定・契約・組織ガバナンスの三層で対策を講じる必要がある。

技術設定の観点：公式セキュリティドキュメントが示す通り、デフォルトの読み取り専用モードと書き込み制限（起動フォルダとサブフォルダのみ）を基盤として、/sandboxによるファイルシステム・ネットワーク隔離、denyルールによる機密ファイルパスの制限、Pre-Tool Use Hookによる破壊的操作前の承認フローの設定が第一優先事項だ。これらは導入初日から設定可能であり、設定コストに対するリスク低減効果が大きい。

契約の観点：公式データポリシーによれば、Team・Enterpriseプラン・APIの商用利用においては、顧客が明示的に選択しない限りコードはモデル学習に使用されない。この確認を法務・情報セキュリティ部門が行い、知的財産と個人情報保護に関するリスクを評価することが求められる。

組織ガバナンスの観点：IPAが「AIセキュリティ短信」を通じて継続的に発信するガイダンスを参照しながら、利用ポリシー・インシデント対応手順・定期レビューサイクルを整備することが、長期的なリスク管理の基盤となる。プロンプトインジェクションのような技術的に完全な排除が困難なリスクに対しては、コンテキスト範囲の最小化という設計原則と、人間によるレビューの維持が現実的な対応策だ。

段階的な導入——まず開発環境のみに限定し、セキュリティ設定と教育体制を整えた後に段階的に適用範囲を拡大する——という方針が、持続可能なAI活用の条件となる。Claude Codeの全体像についてはClaude Code総合解説ページをあわせて参照されたい。

---

弊社が開発するDeepAIについて：弊社クリスタルメソッドでは、機械学習・深層学習（CNN）を用いた2D画像認識・異常検知ソリューション「DeepAI」を開発・提供している。弊社DeepAIでは実際に、ソファーなど形状の不定な対象物の画像分類（正常・異常判定）を得意とし、実導入においておよそ99%の判定精度を実現している。AIコーディングツールの活用と並行して、製造・品質管理領域でのAI導入をご検討の方は、DeepAIのサービス紹介もご参照いただきたい。

---

参考文献

• Anthropic「Configure permissions」Claude Code公式ドキュメント
  https://code.claude.com/docs/en/permissions
• Anthropic「Security」Claude Code公式ドキュメント
  https://code.claude.com/docs/en/security
• Anthropic「Data usage」Claude Code公式ドキュメント
  https://code.claude.com/docs/en/data-usage
• Anthropic「Configure permissions（Agent SDK）」Claude Code公式ドキュメント
  https://code.claude.com/docs/en/agent-sdk/permissions
• Anthropic「Control execution with hooks」Claude Code公式ドキュメント
  https://code.claude.com/docs/en/agent-sdk/hooks
• Anthropic「Trust Center」
  https://trust.anthropic.com
• IPA「AIセキュリティ短信 2026年3月号」独立行政法人情報処理推進機構
  https://www.ipa.go.jp/digital/ai/security/rcu1hd0000007gji-att/2-1_202603.pdf
• IPA「AIセキュリティ短信 2025年7月号」独立行政法人情報処理推進機構
  https://www.ipa.go.jp/digital/ai/security/rcu1hd0000007gji-att/2-2-1_202507.pdf
• IPA「AIセキュリティ短信」一覧ページ、独立行政法人情報処理推進機構
  https://www.ipa.go.jp/digital/ai/security/ai-security-bulletin.html

関連記事

• Claude Codeとは（基本ガイド）
• Claude Codeのベストプラクティス
• Claude CodeのメモリとCLAUDE.md活用
• Claude Codeが動かない・起動しない時の対処法
• Claude CodeとGitHub/Gitの連携