Claude Codeセキュリティ設計ガイド

実践レシピの権限設定でセキュリティと利便性を両立するでは、個人開発を主な対象に、allow/denyリストの基本的な書き方を解説しました。本ガイドはその発展編として、組織導入を見据えたセキュリティ設計に焦点を当てます。個人の設定ファイルをどう書くかではなく、チーム・組織としてどういう方針でClaude Codeのセキュリティを設計すべきか、という一段上の視点で整理します。

このガイドで学べること

• Claude Codeの権限システムが前提としている設計思想
• 個人開発・チーム開発・エンタープライズ、それぞれに適したallow/denyリストの設計パターン
• CLAUDE.mdに書いてはいけない機密情報の種類
• サンドボックス環境での実行という選択肢
• 監査ログ・権限変更の運用フロー
• インシデント発生時に踏むべき対応フローの考え方

権限システムの設計思想

Claude Codeは、ファイルの読み書きやコマンド実行といった「システムに影響を与える可能性のある操作」を行う前に、確認を求める仕組みを基本としています。これは、AIエージェントが自律的に動作することの利便性と、意図しない操作によるリスクとのバランスを取るための、根本的な設計判断です。

権限ルールには3種類あり、**deny（拒否） > ask（確認） > allow（許可）**という優先順位で評価されます。重要なのは、この優先順位が「どこか一箇所でdenyに指定されていれば、他のすべての設定でallowになっていても拒否される」という、安全側に倒れる設計になっている点です。組織のセキュリティポリシーを設計する際は、この性質を逆手に取り、組織レベルのdenyリストを「最後の砦」として機能させるという考え方が基本になります。

graph TD
    A["コマンド実行の要求"]
    B{"いずれかのレベルで<br/>denyに該当?"}
    C["拒否"]
    D{"いずれかのレベルで<br/>askに該当?"}
    E["確認ダイアログ表示"]
    F{"allowに該当?"}
    G["自動許可"]
    H["デフォルトの確認"]
 
    A --> B
    B -->|該当| C
    B -->|非該当| D
    D -->|該当| E
    D -->|非該当| F
    F -->|該当| G
    F -->|非該当| H
 
    style C fill:#fee,stroke:#c00
    style G fill:#e8f5e9,stroke:#2e7d32

allow/denyリストの設計パターン: 規模別の考え方

権限設計の適切な粒度は、組織の規模やガバナンス要件によって大きく変わります。ここでは3つの規模別に、設計の考え方を整理します。

個人開発: 効率優先の設計

個人開発では、自分一人がリスクを引き受ける立場にあるため、よく使うコマンドを積極的にallowリストに加え、確認の手間を減らすことを優先しても大きな問題にはなりません。ただし、rm -rfやgit push --forceのような、取り返しのつかない操作だけは個人開発であってもdenyに入れておくことを強くおすすめします。一瞬の判断ミスや、AIの誤動作によって失われるものの大きさを考えれば、ここだけは妥協すべきではありません。

チーム開発: 標準化と個人差のバランス

チーム開発になると、「チームとして統一すべきルール」と「個人の裁量に任せてよい部分」を切り分ける設計が重要になります。.claude/settings.json（gitにコミットしチーム共有）と.claude/settings.local.json（gitignoreされ個人専用）という2つのファイルの役割分担が、ここで効いてきます。

エンタープライズ: ガバナンスを起点にした設計

組織規模になると、個々のプロジェクトのsettings.jsonだけに依存する設計には限界があります。プロジェクトごとに設定がバラバラになったり、退職者が残したsettings.local.jsonに古い許可設定が残り続けたりするリスクが生じるためです。エンタープライズ規模では、組織レベルで強制力を持つポリシー設定（マネージド設定）を導入し、各プロジェクト・各個人の設定がそれを上書きできないようにする設計が基本になります。

エンタープライズ設計で意識すべき原則は次の3点です。

1. 組織レベルのdenyは個人設定で上書きできないようにする: マネージド設定によって、本番環境への直接操作や機密ディレクトリへのアクセスなど、組織として絶対に許可すべきでない操作を一元的にブロックします。
2. プロジェクト種別ごとのテンプレートを用意する: フロントエンド・バックエンド・インフラなど、プロジェクトの性質に応じたsettings.jsonのひな形を用意し、新規プロジェクト作成時にコピーする運用にすると、ばらつきを抑えられます。
3. MCPサーバーの許可リストも組織で管理する: 個々のプロジェクトが任意のMCPサーバーに接続できる状態は、データ流出経路の管理が困難になります。利用を許可するMCPサーバーを組織レベルで明示的にリスト化し、それ以外は拒否する設計が安全です。

graph TD
    subgraph "ガバナンスの階層"
        Org["組織レベルの<br/>マネージド設定<br/>（上書き不可）"]
        Team["チームレベルの<br/>.claude/settings.json"]
        Personal["個人レベルの<br/>.claude/settings.local.json"]
    end
 
    Org -->|"強制力を持って制約"| Team
    Team -->|"チーム標準を提供"| Personal
 
    style Org fill:#fee,stroke:#c00
    style Team fill:#fff3e0,stroke:#e65100
    style Personal fill:#e8f4fd,stroke:#1a73e8

機密情報の取り扱い: CLAUDE.mdに書いてはいけないこと

CLAUDE.mdはプロジェクトの「記憶」として非常に便利な仕組みですが、その性質上、会話のたびにコンテキストへ読み込まれ、ログやセッション履歴にも残りやすいという特性があります。この特性を理解せず機密情報を書き込んでしまうと、意図しない経路で情報が漏えいするリスクが生じます。

書いてはいけないものの具体例

CLAUDE.local.mdの活用

個人のローカル環境固有の情報（自分のローカルDBのポート番号など、機密性は低いが共有不要な情報）はCLAUDE.local.mdに書き、.gitignoreに含めることで、チーム共有のCLAUDE.mdを汚さずに済みます。ただし、これも「機密情報を書いていい場所」という意味ではなく、あくまで「個人固有だが機密ではない情報」のための置き場であることに注意してください。

サンドボックス環境での実行

allow/denyリストによる権限制御は、コマンド単位での制御です。これに対してサンドボックス実行は、OSレベルでファイルシステムやネットワークへのアクセス自体を制限する、より強力な隔離の仕組みです。

サンドボックスを有効にすると、Claude Codeは定義された境界（特定のディレクトリ配下のみ書き込み可能、特定のネットワーク先のみアクセス可能、など）の中でより自由に動作できるようになります。これは一見矛盾するようですが、「境界の外には絶対に出られない」という保証があるからこそ、境界の内側では確認の頻度を減らし、自律的な作業を任せやすくなるという発想です。

組織導入の観点では、特に以下のようなケースでサンドボックスの活用を検討する価値があります。

• 信頼度の低い外部リポジトリ・外部コントリビューターのコードを扱うプロジェクト
• CI/CD環境など、人間が逐一確認できない無人実行の環境
• 検証目的で、本番に近い構成だが隔離されたい環境

監査ログ・権限変更の運用フロー

組織導入が進むほど、「誰が、いつ、どんな権限設定を、なぜ変更したか」を追跡できる仕組みの重要性が増します。

権限変更を「コードの変更」として扱う

.claude/settings.jsonはリポジトリの一部であるため、Gitの差分として変更履歴が自然に残ります。プルリクエストのレビューフローに乗せることで、「誰が・いつ・なぜ」変更したかを、追加のツールなしで追跡できます。これは特別な仕組みを構築する前に、まず徹底すべき最も基本的な運用です。

マネージド設定の変更は別途承認フローを設ける

組織レベルのマネージド設定は、個々のプロジェクトのリポジトリの外側で管理されることが多いため、Gitの差分だけでは追跡できません。マネージド設定の変更については、変更申請・承認・反映という独立したワークフローを設け、セキュリティ担当者やインフラ管理者の承認を必須にする運用が望まれます。

実行ログの位置づけ

Claude Codeが実際に何を実行したかというログは、インシデント調査やコンプライアンス対応において重要な証跡になります。組織として何を、どこまで記録・保持するかは、利用するプラン・契約条件によって扱いが異なるため、自組織の契約内容を確認した上で、ログの保持方針をセキュリティポリシーに明記しておきましょう。

インシデント発生時の対応フロー（概念レベル）

どれだけ権限設計を入念に行っても、設定ミスや想定外の挙動によってインシデントが発生する可能性をゼロにはできません。重要なのは、発生を完全に防ぐことではなく、発生したときに被害を最小化し、速やかに収束させる体制を事前に用意しておくことです。

flowchart TD
    A["異常な挙動・<br/>意図しない操作を検知"]
    B["影響範囲の特定<br/>（何が・どこまで変更されたか）"]
    C["該当セッション・<br/>関連プロセスの停止"]
    D["変更内容の復旧<br/>（Git履歴・バックアップから）"]
    E["原因分析<br/>（権限設定・指示内容・MCPサーバー等）"]
    F["再発防止策の設計<br/>（allow/denyリストの見直し等）"]
    G["影響を受けた<br/>関係者への報告"]
 
    A --> B --> C --> D --> E --> F --> G
 
    style A fill:#fee,stroke:#c00
    style C fill:#fff3e0,stroke:#e65100
    style F fill:#e8f5e9,stroke:#2e7d32

検知してからの初動

異常に気づいたら、まず該当のセッションを停止し、それ以上の変更が進行しないようにします。次に、Gitの差分やログを確認し、「どのファイルが」「どのコマンドによって」変更されたのかを特定します。Claude Codeが行った変更は基本的にファイルシステム上の変更として残るため、Gitのコミット履歴やワーキングツリーの差分が、最初に確認すべき最も確実な情報源になります。

原因分析で確認すべき観点

インシデントの原因は、大きく分けて「権限設定の不備（許可すべきでない操作がallowになっていた）」「指示内容の問題（曖昧な指示が意図しない解釈をされた）」「MCPサーバー経由のリスク（外部コンテンツ経由のプロンプトインジェクション等）」のいずれかに分類できることが多いです。どの分類に該当するかによって、再発防止策の方向性も変わってきます。

まとめ

組織導入を見据えたセキュリティ設計は、個人の設定ファイルの書き方を知っているだけでは完結しません。allow/deny/askという権限システムの優先順位を理解した上で、個人・チーム・エンタープライズという規模に応じた設計パターンを選び、CLAUDE.mdに書いてよい情報とそうでない情報を切り分け、サンドボックスのような多層防御も視野に入れる。そして、権限変更を追跡可能にし、インシデント発生時の対応フローをあらかじめ用意しておく。

これらはどれも、Claude Codeを「便利だが管理されていないツール」から「組織として安心して任せられる仕組み」へと引き上げるための、地道だが欠かせない設計作業です。個人開発の延長線上で組織導入を進めようとすると、規模が大きくなるにつれて綻びが生じやすくなります。早い段階から、本ガイドで紹介した規模別の設計パターンを意識しておくことをおすすめします。