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

> Claude Code をチームに配る前に決めること。6つの許可モードの使い分け、deny→ask→allow の評価順、managed settings の配布と上書きできないキー、既定で無効なサンドボックス、hooks の統制、CI の信頼の罠を、2026年10月時点の公式ドキュメントで整理します。

- 公開日: 2026-10-12
- 著者: 友田 陽大
- タグ: Claude Code, AI駆動開発, セキュリティ, AI
- URL: https://tomodahinata.com/blog/claude-code-enterprise-security-governance-managed-settings-guide
- カテゴリ: AI駆動開発・開発生産性
- 総合ガイド: https://tomodahinata.com/blog/spec-driven-development-claude-code-ai-agent-production-workflow

## 要点

- Claude Code は開発者本人の権限でシェルとファイルを扱う。組織の設計は『何を自動で許し、何を確認させ、何を禁じるか』を決め、開発者が上書きできない managed settings に落とすこと
- 権限ルールは deny → ask → allow の順に評価され、どのスコープの deny も他スコープの allow に勝つ。ただし Bash ルールも Read の deny も公式に『セキュリティ境界ではない』とされ、OS レベルの強制はサンドボックスが担う
- サンドボックスは既定で無効で、有効にしても既定では ~/.ssh や ~/.aws/credentials を読める。hooks・ローカルの MCP サーバー・Read や WebFetch などの組み込みツールはサンドボックスの外で動く
- サーバー管理設定（claude.ai から配る管理設定）は Team / Enterprise 向けで、公式自身が『セキュリティ境界ではない』と明記し、Bedrock などの外部プロバイダ利用時は取得されない。端末側の管理（ファイル・MDM）と組み合わせる
- CI では `claude -p` が信頼ダイアログを出さずリポジトリの hooks と .mcp.json を動かす。--bare と dontAsk・--allowedTools で絞り、GitHub Actions は起動できる人と PR の扱いを先に決める

---

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

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

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

---

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

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

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

| 経路 | 何が起こりうるか | 主な統制 |
|---|---|---|
| ファイル | 秘密情報の読み取り、作業ディレクトリ外の書き換え | Read/Edit ルール、サンドボックスの filesystem |
| シェル | 任意コマンドの実行、子プロセス経由の迂回 | 許可モード、Bash ルール、サンドボックス |
| ネットワーク | 外部への持ち出し、未承認ホストへの接続 | サンドボックスの network、WebFetch ルール |
| 認証情報 | `~/.ssh` や `~/.aws`、環境変数の漏えい | denyRead、`sandbox.credentials`、環境変数の除去 |
| CI | 人が見ていない場所での実行、未信頼 PR からの指示 | `--bare`、`dontAsk`、Actions の起動条件 |

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

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

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

| モード | 確認なしで動くもの | 想定（公式） | 組織での扱いの例 |
|---|---|---|---|
| `default`（表示名は Manual） | 読み取りのみ | 一つずつ自分で確認する、機密性の高い作業 | 全員に許可。機密リポジトリの既定に |
| `acceptEdits` | 読み取り、ファイル編集、`mkdir` などの基本的なファイル操作 | レビューしながらの反復 | 日常の開発で許可 |
| `plan` | 読み取り（auto が使えるときは分類器が承認したコマンドも） | 変更前の調査 | 全員に許可 |
| `auto` | すべて（背景の安全チェックつき） | 長いタスク、確認疲れの軽減 | 方針次第。止めるなら `disableAutoMode` |
| `dontAsk` | 作業ディレクトリ内の読み取りと事前許可したツール。確認が必要なものは拒否 | 締めた CI やスクリプト | CI 専用 |
| `bypassPermissions` | すべて | 隔離したコンテナや VM のみ | 開発端末では無効化 |

`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 欄が根拠です。

| 区分 | 主なキー | 意味 |
|---|---|---|
| managed 専用 | `allowManagedPermissionRulesOnly`、`allowManagedHooksOnly`、`allowManagedMcpServersOnly`、`managedMcpServers`、`strictKnownMarketplaces`、`blockedMarketplaces`、`disableSideloadFlags`、`sandbox.network.allowManagedDomainsOnly`、`sandbox.filesystem.allowManagedReadPathsOnly`、`forceRemoteSettingsRefresh` | managed 以外に書いても効かない「鍵」 |
| どのファイルでも可 | `permissions.disableBypassPermissionsMode`、`disableAutoMode`、`allowedMcpServers`、`deniedMcpServers`、`enableAllProjectMcpServers`、`sandbox.enabled`、`sandbox.allowUnsandboxedCommands`、`cleanupPeriodDays`、`env` | managed に置けば上書きされないが、下位に書いても効く |
| 下位の厳しい値が勝つ例外 | `permissions.blockReadsOutsideWorkingDirectories: true`、`disableClaudeAiConnectors: true` など | どのスコープの `true` でも有効。managed の `false` でも外せない |

`allowedMcpServers` が managed 専用ではない点は特に誤解されやすいところです。`allowManagedMcpServersOnly` を立てない限り、ユーザーが自分の設定で許可リストを広げられます。詳しくは [MCP の記事](/blog/claude-code-mcp-server-security-third-party-trust-guide) で扱います。

## 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. 設定ごとに「何を防ぎ、何は防がないか」

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

| 設定 | 何を防ぐ | 何は防がない |
|---|---|---|
| `permissions.deny` の `Read(...)` | 組み込みファイルツールと認識できるコマンドでの読み取り | スクリプトや子プロセスが自分で開く読み取り |
| `permissions.deny` の `Bash(curl *)` | Claude がふつう書く形の `curl` | フルパス指定、`sh -c` 経由、別の通信手段 |
| `disableBypassPermissionsMode` | `--dangerously-skip-permissions` を含む bypass モード | auto モード（別途 `disableAutoMode`） |
| `sandbox.enabled` + `allowUnsandboxedCommands: false` | シェルコマンドと子プロセスのファイル・通信の逸脱 | hooks、ローカル MCP、組み込みツール、`!` で利用者が打つコマンド |
| `sandbox.filesystem.denyRead` | サンドボックス内のコマンドからの秘密ファイル読み取り | Read ツール（Read の deny で別途） |
| `sandbox.network.allowedDomains` | 許可外ホストへの通信 | 広く許可したドメイン経由の持ち出し、TLS の中身 |
| サーバー管理設定 | 管理された端末での設定の上書き | 管理されていない端末での回避、外部プロバイダ利用時 |
| `allowManagedHooksOnly` | 個人・リポジトリが持ち込む hooks | 組織が配った hooks 自体の不具合 |
| `--bare`（CI） | リポジトリの hooks、skills、`.mcp.json` の自動読み込み | プロジェクトの `env` ブロック |

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

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

```json
{
  "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 で作ったアプリのセキュリティ診断](/security-audit/ai-generated-code) を参照してください。

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