Claude Code を組織に導入するときのセキュリティ・ガバナンス設計 — 権限モード・managed settings・サンドボックス・CI

結論から書きます。Claude Code を組織に入れるときに設計すべきなのは、モデルの賢さではなく「開発者の端末で、その人の権限で動くエージェントに、何を自動で許し、何を確認させ、何を禁じるか」です。 そして決めたことは、開発者が上書きできない managed settings（管理設定） に落とし、権限ルールだけでは止まらない部分をサンドボックスと端末管理で補います。

個人や小さなチームが自分の settings.json を固める話は、Claude Code を本番運用に耐えさせる — 権限設計・hooks・CLAUDE.md・セキュリティゲート に書きました。この記事はその先、CTO・インフラ・セキュリティ担当がチーム全体に配るときの設計です。MCP サーバーの採否は 第三者 MCP サーバーの信頼と統制 に分けました。

設定キー・パス・既定値は、すべて 2026年10月12日に取得した公式ドキュメント（code.claude.com/docs）で確認したものです。Claude Code は更新が速く、バージョンで挙動が変わる箇所が多いため、導入時点の版で必ず確かめてください。

1. 脅威モデル：開発者本人の権限で動くエージェント

守る対象は「Claude Code というツール」ではなく、それが触れる開発者の端末とその先です。 Claude Code はローカルで動き、開発者のユーザー権限でファイルを読み書きし、シェルを実行します。公式の Security ページも、作業ディレクトリの境界は権限プロンプトにすぎず、「承認した Bash コマンドは、ユーザーアカウントが書ける場所ならどこにでも書ける」と書いています。

被害の広がり方は、次の5つに分けて考えると漏れがありません。

入口として特に注意すべきなのはプロンプトインジェクションです。外部の内容（Issue 本文、Web ページ、MCP サーバーの応答）に紛れた指示が、エージェントの判断を乗っ取ろうとします。モデルの判断に頼らず、判断が乗っ取られても届かない範囲を設定で作るのが、組織の設計の基本方針になります。

2. 許可モード：6つのうち、どれを誰に許すか

2026年10月時点で許可モードは6つあり、組織としては「bypassPermissions を開発端末で使わせない」ことと「auto モードを許すか」を最初に決めます。

auto は、別の分類器モデルが利用者の代わりに操作を審査し、危険と判断したものを止める仕組みです。v2.1.283 以降ではターミナルで始めたセッションの既定のモードが auto になっている点に注意してください。組織で止めるには managed settings で disableAutoMode（permissions.disableAutoMode としても受け付けます）を "disable" にします。

bypassPermissions は確認と安全チェックを外すモードで、公式は「インターネットにつながらないコンテナ・VM・dev container のような隔離環境でのみ使う」よう警告しています。permissions.disableBypassPermissionsMode を "disable" にすると、--dangerously-skip-permissions フラグも拒否されます。

モードに関係なく効くのが deny ルールです。公式は「deny ルールは bypassPermissions を含むすべてのモードで止める」と明記しています。また、プロジェクトの .claude/settings.json に defaultMode: "bypassPermissions" や "auto" を書いても、そのファイルからは効きません。クローンしたリポジトリが勝手にモードを緩めることはできない設計です。

3. allow / ask / deny の評価順と、スコープをまたぐ deny

ルールは deny → ask → allow の順に評価され、最初に一致したものが結果になります。より具体的なルールを書いても、この順番は変わりません。

この順序はスコープもまたぎます。公式の言葉では「ユーザーの deny はプロジェクトの allow を止める。どのスコープの deny も allow より先に評価されるから」です。managed settings の deny は --allowedTools でも上書きできず、逆に --disallowedTools は制限を足せます。

組織にとっての含意は2つあります。

• 禁止は deny に書けば、下位のどこで allow されても負けない。 秘密情報や git push --force のように絶対に通したくない操作は、managed settings の deny に置きます。
• allow は「広げる」操作なので、出どころを絞りたいことがある。 allowManagedPermissionRulesOnly: true にすると、ユーザー・プロジェクト・ローカル・--settings の allow / ask / deny と --allowedTools が無視され、「常に許可」の選択肢も消えます。強力ですが、開発者の確認疲れが増えるので、規制の強い部門から段階的に使うのが現実的です。

なお、プロジェクトの .claude/settings.json にある permissions.allow は、そのフォルダのワークスペース信頼ダイアログを承認するまで適用されません。deny と ask は制限するだけなので、この対象外です。

4. ルール構文の限界：Bash ルールも Read の deny も境界ではない

権限ルールは「Claude がふつう書くコマンドの形」に一致させる仕組みで、プログラムそのものを囲う境界ではありません。 ここを誤解すると、設定したつもりで穴が残ります。

Bash ルールについて、公式ははっきり「セキュリティ境界ではない」と書いています。Bash(curl *) を deny にしても、/usr/bin/curl https://example.com や sh -c 'curl https://example.com' には一致しません。また curl や wget は既定で自動承認されないだけで、組み込みの禁止リストに入っているわけではありません。止めたいなら deny に書き、確実に止めたいならサンドボックスのネットワーク許可リストと組み合わせます。

Read / Edit の deny も同様です。組み込みのファイルツール、cat・head・sed などの認識できるコマンド、> file のようなリダイレクトには効きますが、ファイル名を書かない grep -r pattern . や、Python・Node のスクリプトが自分でファイルを開く場合には効きません。.claudeignore は効果がないので、使っているなら Read の deny に移します。

パスの書き方にも罠があります。/path はファイルシステムのルートではなく「その設定ファイルの場所」が基準です。ユーザー設定に Read(/secrets/**) と書くと、ブロックされるのは ~/.claude/secrets/** です。絶対パスは //path、ホーム基準は ~/path で書きます。

5. 設定の階層と、managed settings の配り方

managed settings は最上位の層で、ユーザー設定・プロジェクト設定・--settings のどれからも上書きできません。 優先順位は高い順に、managed settings → コマンドラインの --settings → .claude/settings.local.json → .claude/settings.json → ~/.claude/settings.json です。リスト型のキー（permissions.allow など）は上書きではなく結合されます。

配り方は4通りです。

• ファイル：macOS は /Library/Application Support/ClaudeCode/managed-settings.json、Linux と WSL は /etc/claude-code/managed-settings.json、Windows は C:\Program Files\ClaudeCode\managed-settings.json。旧来の C:\ProgramData\ClaudeCode\managed-settings.json は読まれません。同じ場所の managed-settings.d/ に分割ファイルを置くと、アルファベット順に結合されます。
• MDM / OS のポリシー：macOS は com.anthropic.claudecode の管理プリファレンス、Windows は HKLM\SOFTWARE\Policies\ClaudeCode の Settings という値（REG_SZ または REG_EXPAND_SZ）。
• サーバー管理設定：claude.ai の管理画面から配ります。Claude for Teams か Claude for Enterprise が必要で、編集には Owner か Primary Owner のロールが要ります。
• HKCU レジストリ：ユーザーが書き換えられる場所なので、管理者のソースとしては扱われません。

ここで見落としやすいのが、複数の配り方を併用したときの挙動です。既定（managedSourcesBehavior が "first-wins"）では、Claude Code はポリシーを含む最上位のソースだけを使い、残りは結合せずに無視します。順位はサーバー管理設定 → MDM → ファイル → HKCU です。サーバー管理設定を少しだけ試したら、ファイルで配っていたサンドボックス設定が効かなくなった、ということが起こりえます。両方を効かせたいなら managedSourcesBehavior: "merge" を検討し、どのソースが効いているかは /status で確認します。

サーバー管理設定には、さらに2つの制約があります。

• 公式は「クライアント側の統制であり、セキュリティ境界ではない。管理されていない端末では、ユーザーは管理者権限なしで回避できる」と明記しています。
• CLAUDE_CODE_USE_BEDROCK などのプロバイダ変数や既定以外の ANTHROPIC_BASE_URL をシェルで設定していると、取得自体がスキップされます。Amazon Bedrock、Google Cloud の Agent Platform（旧 Vertex AI）、Microsoft Foundry を使う組織は、端末側の管理か、自前で運用する Claude apps gateway で配ります。

6. managed 専用のキーと、どこにでも書けるキー

「managed settings に書いたから強制される」キーと、「どのファイルにも書けるので、managed に置くことで初めて上書き不可になる」キーを分けて覚えます。 設定リファレンスの Scope 欄が根拠です。

allowedMcpServers が managed 専用ではない点は特に誤解されやすいところです。allowManagedMcpServersOnly を立てない限り、ユーザーが自分の設定で許可リストを広げられます。詳しくは MCP の記事 で扱います。

スポンサーリンク

最近、仕事楽しめてますか？！社内SEへ転職するなら【社内SE転職ナビ】

7. サンドボックス：既定で無効、有効にしても ~/.ssh は読める

サンドボックスは既定で無効です。有効にしても、既定では ~/.ssh や ~/.aws/credentials を含むマシンの大部分を読めます。 組織で使うなら、有効化と読み取り禁止をセットで managed settings に入れます。

サンドボックスは Claude が実行するシェルコマンドとその子プロセスを、macOS では Seatbelt、Linux と WSL2 では bubblewrap で囲います。既定の範囲は次のとおりです。

• 書き込み：作業ディレクトリ、ユーザーごとの一時ディレクトリ、追加したディレクトリ。
• 読み取り：マシンの大部分。sandbox.filesystem.denyRead で塞ぎます。Read の deny ルールに書いたパスもここに結合されます。
• ネットワーク：直接の経路はなく、ローカルのプロキシが allowedDomains と照合します。許可リストは最初は空です。
• 環境変数：Claude Code から引き継ぐので、そこに秘密が入っていれば見えます。

範囲の外で動くものも把握しておきます。Read・Edit・Write・WebFetch・WebSearch などの組み込みツールは、サンドボックスではなく権限ルールに従います（denyRead は Read ツールを止めません）。command hooks、ローカルの MCP サーバー、LSP サーバー、ステータスラインのコマンドや apiKeyHelper は、利用者のフル権限で動きます。

強制するときの公式の構成は enabled: true、failIfUnavailable: true、allowUnsandboxedCommands: false の3点です。最後の1つを入れないと、サンドボックス内で失敗したコマンドを Claude が dangerouslyDisableSandbox で外に出して再試行できます。failIfUnavailable を入れると、サンドボックスが動かないネイティブ Windows では起動時に終了するので、Windows の開発者は WSL2 かコンテナに寄せるか、OS ごとに配り分けます。

許可ドメインは狭く保ちます。プロキシは TLS を既定では終端も検査もしないため、github.com のような広いドメインを許すと、ドメインフロンティングなどで許可外のホストに届く経路になりうると公式が警告しています。allowUnixSockets で /var/run/docker.sock を許すことは、実質的にホストへのアクセスを渡すことです。開発者が設定を広げないよう、allowManagedDomainsOnly と allowManagedReadPathsOnly も検討します。

8. 秘密情報：どこに置き、どこから見えなくするか

秘密情報は「ツールに読ませない」「子プロセスに渡さない」「平文で残さない」の3層で考えます。

1. 読ませない：Read の deny（組み込みツール向け）と sandbox.filesystem.denyRead（シェル向け）を両方書きます。秘密ファイルを使わせつつ中身を隠したい場合は、sandbox.credentials で deny や mask を指定できます。
2. 渡さない：CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 を設定すると、Bash コマンド・hooks・stdio の MCP サーバーなど、Claude Code が起動する子プロセスの環境から認証情報が取り除かれます（GitHub トークンとプロキシ設定は残ります）。
3. 平文で残さない：設定ファイルの env に書いた値は平文で、すべての子プロセスに渡ります。API の認証情報は apiKeyHelper で保管庫から都度取得する形にします。また、セッションの記録は ~/.claude/projects/ に平文で既定30日保存されます。cleanupPeriodDays で短くできます。

Claude Code 自身の API キーやトークンは、macOS では利用できる場合 Keychain に、Linux ではモード 0600 のファイルに保存されます。

9. hooks：組織が配るものだけを動かす

hooks は利用者のフル権限でシェルコマンドを実行するので、「誰の hooks を動かすか」自体が統制の対象です。 allowManagedHooksOnly: true を managed settings に置くと、managed の hooks、Agent SDK の hooks、managed で強制有効にしたプラグインの hooks だけが動き、ユーザー・プロジェクト・ローカルの hooks は止まります。

逆に、組織が配った hooks は、下位のスコープの disableAllHooks では止められません。PreToolUse hook が "allow" を返しても deny ルールは覆らないので、hooks は「止める」方向の補強として使うのが安全です。

設定変更の監査には ConfigChange hook が使えます。ユーザー・プロジェクト・ローカルの設定ファイルや skill ファイルがセッション中に変わったときに発火し、記録したり変更を止めたりできます。ただし、managed のファイルの変更は止められず、サーバー管理設定・macOS の管理プリファレンス・Windows レジストリの変更ではそもそも発火しません。

10. データの扱い：学習・保持期間・ZDR

商用規約（Team・Enterprise・API・外部プラットフォーム）では、顧客が自ら提供を選んだ場合を除き、Claude Code に送ったコードやプロンプトは学習に使われません。 社内規程と照合するときは、次の点を押さえます。

• 商用の標準の保持期間は30日です。
• /feedback などで送った記録は5年間保持されます。業務のコードを含む場合の扱いを決めておきます。
• ゼロデータ保持（ZDR）は Claude for Enterprise の対象アカウント向けで、標準の Enterprise プランには含まれず、管理画面から有効化することもできません。Anthropic による個別の有効化が必要で、適用されるのは Anthropic の直接のプラットフォームだけです。
• 通信は TLS 1.2 以上で暗号化されます。Anthropic に送られる利用メトリクスにコード・プロンプト・ファイルパスは含まれず、DISABLE_TELEMETRY=1 で止められます。

11. 可観測性と監査

利用状況は OpenTelemetry で自社の収集基盤に送れ、管理者は managed settings の env で全員に設定できます。 CLAUDE_CODE_ENABLE_TELEMETRY=1 と OTEL_* の exporter を設定します。managed で送信先を指定すると、開発者が設定した送信先は起動時に取り除かれます。リポジトリの設定ファイルからは exporter の変数を設定できません。

プライバシーの面では、プロンプト本文の記録（OTEL_LOG_USER_PROMPTS）は既定で無効です。ツールの引数（OTEL_LOG_TOOL_DETAILS）なども既定では記録されません。何を記録するかは、労務や個人情報の規程と合わせて決めます。

Team と Enterprise では、Admin と Owner が claude.ai の分析ダッシュボードで利用状況を見られます。設定変更の監査ログについて、公式はコンプライアンス API か監査ログのエクスポートで取得でき、Anthropic のアカウントチームに問い合わせるよう案内しています。

12. CI：-p の信頼の罠と GitHub Actions

CI で一番危ないのは、claude -p がワークスペース信頼ダイアログを出さないことです。 --bare を付けないと、一度も信頼していないフォルダでも、リポジトリの .claude/settings.json にある hooks を実行し、.mcp.json のサーバーに確認なしで接続します。公式は scripted な呼び出しと SDK に --bare を推奨しています。ただし --bare でもプロジェクトの env ブロックは適用されるので、それだけに頼らないでください。

CI のジョブは、--permission-mode dontAsk と --allowedTools で使えるツールを正確に列挙し、確認が必要なものは拒否させるのが基本形です。

GitHub Actions（anthropics/claude-code-action）では、次の点を先に決めます。

• 起動できる人：Issue と PR のイベントでは、起動したユーザーにリポジトリの書き込み権限が必要です。allowed_non_write_users でこれを外すことは「重大なセキュリティリスク」とされています。bot は allowed_bots に載せない限り拒否されます。
• PR の設定：PR に対して動くとき、Action は .claude/・.mcp.json・CLAUDE.md などの設定パスをベースブランチのものに戻してから Claude を起動します。PR で書き換えられた設定のまま Claude が動かないようにする仕組みです。
• pull_request_target と workflow_run：これらはベースリポジトリの secrets で動くので、未信頼の ref をワークスペースのルートにチェックアウトしてから Action を動かしてはいけません。
• 隠れた指示：Action は HTML コメントや不可視文字などを取り除きますが、公式は新しい迂回手法が出てくる可能性を認めています。外部の人が書いた Issue や PR を Claude に読ませるワークフローは、権限を最小にします。
• API キー：リポジトリにコミットせず、GitHub Secrets に置きます。

13. 設定ごとに「何を防ぎ、何は防がないか」

どの設定も単独では完結しません。 導入レビューでは、次の表で穴を確認します。

14. 組織のベースラインとなる managed-settings.json の例

次の例は、公式ドキュメントで確認したキーだけで組んだ出発点です。 そのまま配らず、自社のパッケージレジストリや社内 MCP サーバーに合わせて値を変え、試用グループで動作を確かめてから広げてください。

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(secrets/**)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": ["~/.ssh", "~/.aws"],
      "allowManagedReadPathsOnly": true
    },
    "network": {
      "allowedDomains": ["registry.npmjs.org", "packages.example.internal"],
      "allowManagedDomainsOnly": true
    }
  },
  "allowManagedHooksOnly": true,
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.example.internal/*" }
  ],
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "https://otel.example.internal:4317"
  },
  "cleanupPeriodDays": 14
}

この例の意図を補足します。

• Bash(curl *) の deny は、通常の形を止めるだけです。持ち出しを確実に止めているのはサンドボックスのネットワーク許可リストのほうです。
• github.com をあえて許可ドメインに入れていません。広いドメインは持ち出しの経路になりうるためです。git の操作が必要なら、影響を理解したうえで足すか、excludedCommands で特定のコマンドだけを外に出します（外に出したコマンドはフル権限で動きます）。
• auto モードを止める disableAutoMode は入れていません。止めるかどうかは組織の方針で決め、止めるならここに足します。
• failIfUnavailable があるので、ネイティブ Windows の端末には別のファイルを配るか、WSL2 に寄せます。
• 配ったら、1台で /status を開き、Setting sources に Enterprise managed settings (file) と出ることを確認します。

15. 段階的なロールアウト：試用 → 方針 → managed → CI

最初から全員に厳しい設定を配ると、例外の申請と個人設定での回避が増えます。 次の4段階で進めるのが現実的です。

1. 試用：数人のチームで、Manual と acceptEdits を中心に使い、どのコマンド・ドメイン・MCP サーバーが本当に必要かを記録します。/permissions で実際の許可を定期的に見直します。
2. 方針：試用の記録から、全員に許すもの、確認させるもの、禁止するものを決めます。auto モードを許すか、どの MCP サーバーを認めるか、秘密情報をどこに置くかもここで決めます。
3. managed settings：方針をファイルか MDM で配ります。サーバー管理設定を併用するなら、first-wins の挙動と、管理されていない端末では回避できることを前提にします。ConfigChange hook と OpenTelemetry で、効いているかを観測します。
4. CI：最後に、人が見ていない場所での実行を --bare・dontAsk・--allowedTools と Actions の起動条件で締めます。

まとめ：ツールの統制と、作ったアプリの診断は別の仕事

Claude Code の組織導入で決めるのは、開発者の権限で動くエージェントに、どこまでを許すかです。deny を先に書き、managed settings で上書きできないようにし、権限ルールが届かないところはサンドボックスと端末管理で補う。そして、公式自身が「境界ではない」と書いている部分を、境界だと思い込まないことが要点です。

なお、これは「ツールを安全に使う」設計であり、Claude Code で作ったアプリそのものの脆弱性を見る話とは別です。アプリ側の認可や RLS の確認が必要なら、AI で作ったアプリのセキュリティ診断 を参照してください。

自社の方針を managed settings・サンドボックス・MCP の許可リスト・CI の設定に落とす作業を外部に頼みたい場合は、Claude Code 組織導入のセキュリティ・ガバナンス設計 で相談を受け付けています。