Claude Enterprise の組織設定をどう決めるか、セキュリティポリシーから考えてみた
コーヒーが好きな emi です。
Claude の利用を組織に広げるにあたり、最近はどのようなルールやシステム設定が必要かという相談をいただくことが多くあります。
一般の利用者へ展開する前に、どこまで制限するのか、利用者へ何を守ってもらうのか、管理者側では何を設定できるのか……管理機能を順番に有効化すればよいようにも見えますが、実際には組織のデータ区分や端末管理方針、Claude に任せたい作業によって適切な設定が変わります。
そこで Anthropic が一般公開している情報をもとに、Claude Enterprise プランで利用できる主な管理機能、Claude Code の設定ファイルの違い等を整理し、実際にありそうなセキュリティポリシーを組織設定へ落とし込む例を考えてみました。
1. Claude のプラン
以下のプランがあります。
| 区分 | プラン | 位置づけ |
|---|---|---|
| 個人向け | ・Free ・Pro ・Max |
個人で Claude を利用するためのプラン。会話データのモデル改善への利用可否は利用者ごとのデータ設定や適用される規約に依存する。組織による一括したデータ利用設定、支払い、モニタリング、統制の機能はない。 Claudeプランを選択 | Anthropicヘルプセンター |
| 組織向け | Team | チームでの共同利用、メンバー管理、請求管理などを行うプラン。シート単位の課金で、週ごとの利用上限がある。上限を超えた分は usage credits で従量的に追加できる。最大 150 シートまでで、超える場合は Enterprise へアップグレードする。 Team プランとは何ですか？ | Anthropicヘルプセンター |
| 組織向け | Enterprise | Team の機能に加え、高度なセキュリティ、コンプライアンス、組織管理を必要とする組織向けのプラン。 エンタープライズプランとは何ですか？ | Anthropicヘルプセンター |
なお、Claude には、従業員がチャットや Claude Code などを利用する使い方と、API を使って自社サービスへ Claude を組み込む Claude Platform という使い方があります。この記事で扱うのは前者の組織での利用です。
1-1. 「シート」とは
組織向けプランで出てくる「シート」は、利用者 1 人が Claude を使うための枠のことです。組織はシートをまとめて購入し、メンバーへ割り当てて使います。たとえば Team プランの「最大 150 シート」は、その組織で同時に利用者を割り当てられる上限が 150 人分ということです。
2. Claude Enterprise プランで利用できる主な管理機能
SSO、SCIM、ロールベースアクセス制御、支出制御、監査ログ、Compliance API、データ保持制御などが Enterprise 向けの機能として案内されています。
何を管理するための機能なのかで整理すると、以下のようになります。
| 統制の目的 | 主な機能 |
|---|---|
| 利用者を管理する | SSO、ドメイン管理、SCIM・JIT、ロールベースアクセス制御 |
| データを管理する | データ保持制御、Enterprise 向けの暗号鍵やデータ処理場所に関する機能 |
| 利用機能を管理する | 製品、コネクタ、組織データへのアクセス制御 |
| コストを管理する | 組織・利用者の支出管理、利用状況の分析 |
| 利用状況を確認する | 監査ログ、Compliance API、Analytics API、OpenTelemetry |
「機密情報を守りたい」という方針だけでは、必要な統制は決められません。
機密情報の Claude への入力自体を禁止したいのか、データが外部の Web サイトへ送信されるのを防ぎたいのか、保存データを一定期間後に削除したいのか、あるいは利用状況を事後に監査できればよいのかなど、具体的な要件によって設定内容を確定させます。
3. 組織での利用を 3 つの層で考える
Claude を組織で利用するときは、次の 3 つの層に分けて考えると整理しやすくなります。
3-1. A 組織全体に共通する設定
アカウント、認証、データ保持、支出、監査など、Claude を利用する組織全体に共通する設定です。
たとえば組織の IdP を使った SSO、SCIM によるユーザーの追加・削除、ロールによるアクセス制御などが該当します。退職者や異動者のアカウントをどう扱うか、利用状況をどのように確認するかといった方針も、この層と関係します。
3-2. B 製品・ライブラリ・アクセスの設定
Claude Enterprise では、Claude Code や Cowork などの製品、プラグイン、コネクタ、スキルなどを管理できます。利用可否、接続先、共有範囲、実行権限などを設定します。
Claude Code では、組織管理画面から settings.json をアップロードし、Server-managed settings として配信できます。配信した設定は、Managed settings という最上位の設定階層で適用されます。実行できるコマンド、参照できるファイル、通信先、MCP サーバーなどを制御できます。
3-3. C 利用ルールと運用
Claude の設定だけでは制御できない、入力可能な情報、生成物のレビュー責任、例外申請、インシデント対応などを定める層です。Claude の設定としてではなく、利用者の使い方、社内ルールなどを定め順守していく部分です。
ちなみに Claude の組織管理画面で「組織の指示」としてプロンプトを記載することもできますが、それだけでファイル参照や外部通信を技術的に確実に遮断できるわけではありません。あくまでもプロンプトなので、利用者の指示によっては想定していない利用ができてしまう場合もあります。
4. 事故を防ぐ設定と利用状況を確認する仕組み
実行前に止める仕組み、実行後に確認する仕組み、人が運用する仕組みの組み合わせでガバナンスを考えるとよいです。
| 分類 | 目的 | 例 |
|---|---|---|
| 予防 | 実行前に禁止・制限する | SSO、機能制限、Claude Code の権限ルール（permissions.deny など）、サンドボックス、通信先制限 |
| 検知 | 実行後に利用状況を確認する | 監査ログ、Compliance API、利用分析 |
| 運用 | 設定だけでは完結しない判断を行う | 例外申請、ログ確認、インシデント対応、設定の定期見直し |
Compliance API は、活動イベント、チャットデータ、ファイルの内容、監査ログのイベントなどを取得し、DLP や SIEM などの既存ツールと連携して、利用状況の監視・検知・監査を行うための仕組みです。
Compliance API が Claude Code のすべてのツール実行、ローカルファイルアクセス、コマンド内容を記録するわけではありません。監査要件に応じて、Compliance API、監査ログ、Claude Code の OpenTelemetry、端末・ネットワーク側のログを組み合わせます。
5. Claude Code の設定ファイルの適用範囲
ここからは、3 つの層のうち「B 製品・ライブラリ・アクセスの設定」の具体例として、Claude Code を取り上げます。
Claude Code の設定は JSON 形式で記述します。ファイルの保存場所や配信方法によって、設定の適用範囲と優先順位が決まります。
Claude Code settings には、次のスコープがあります。
| スコープ | ファイル・配信方法 | 適用範囲・主な用途 |
|---|---|---|
| Managed | サーバー管理設定、MDM・OS ポリシー、システム領域の managed-settings.json |
管理者が組織のポリシーとして配布・強制する設定 |
| User | ~/.claude/settings.json |
利用者個人のすべてのプロジェクトに適用する設定 |
| Project | .claude/settings.json |
リポジトリに含め、チームで共有するプロジェクト設定 |
| Local | .claude/settings.local.json |
特定の利用者とプロジェクトにのみ適用する、リポジトリでは共有しない設定 |
5-1. 設定元の優先順位
同じ設定項目が複数の場所に指定されている場合、原則として次の一覧の上にある設定元の値が優先されます。
- Managed settings
- 起動時のコマンドライン引数
.claude/settings.local.json.claude/settings.json~/.claude/settings.json
例えば、.claude/settings.json に次の設定があるとします。
{
"model": "fable"
}
一方、~/.claude/settings.json には次の設定があります。
{
"model": "opus"
}
.claude/settings.json は ~/.claude/settings.json より優先順位が高いため、使用されるモデルは fable です。
Managed settings は最優先であり、通常の設定項目については、組織が指定した値を利用者側の設定で上書きできません。
5-2. 権限ルールとその適用方法
Claude Code は、ファイルの読み取りや編集、シェルコマンドの実行、Web へのアクセスなどを「ツール」として実行します。これらの操作を禁止するか、利用者へ確認するか、確認なしで許可するかを設定できます。この設定を「権限ルール」といいます。
権限ルールは、Claude Code の設定用 JSON にある permissions オブジェクトの中に記述します。User、Project、Local の各スコープでは settings.json や settings.local.json、Endpoint-managed settings では managed-settings.json が設定用 JSON に当たります。
たとえば、次のように設定します。
{
"permissions": {
"deny": [
"Read(.env)"
],
"ask": [
"Bash(git push *)"
],
"allow": [
"Bash(npm test)"
]
}
}
この例では、.env の読み取りを拒否し、git push の実行前には利用者へ確認し、npm test は確認なしでの実行を許可しています。
この記事では、JSON 内の階層を permissions.deny のようにドットでつないで表記します。permissions.deny は、settings.json などの設定用 JSON にある permissions オブジェクトの中の deny という項目を意味します。
各項目の動作は次のとおりです。
| 設定項目 | 動作 |
|---|---|
permissions.deny |
一致する操作を拒否する |
permissions.ask |
一致する操作の実行前に利用者へ確認する |
permissions.allow |
一致する操作を確認なしで許可する |
権限ルールでは、特定のファイルを読み取る Read、シェルコマンドを実行する Bash、Web へアクセスする WebFetch などを対象にできます。対象となる操作は、Read(.env) や Bash(git push *) のようなルールとして指定します。
権限ルールは、通常の設定項目とは適用方法が異なります。permissions.deny、permissions.ask、permissions.allow に書かれたルールは、複数のスコープから集めて適用されます。そのうえで、実行しようとする操作に一致するルールを次の順に判定します。
permissions.deny（実行を拒否）permissions.ask（実行前に確認）permissions.allow（確認せずに実行を許可）
たとえば、Managed settings の permissions.allow と Project settings の permissions.deny が同じ操作に一致する場合、その操作は拒否されます。これは Project settings が Managed settings を上書きしたのではなく、複数のスコープから集められた権限ルールの中で deny が先に判定された結果です。
利用者やプロジェクトが追加した権限ルールを適用せず、Managed settings のルールだけを使う場合は、Managed settings で allowManagedPermissionRulesOnly を設定します。
5-3. サンドボックスとその役割
サンドボックスは、Claude Code が実行するコマンドを OS の機能で隔離し、参照できるファイルや通信先を制限する仕組みです。設定は settings.json の sandbox オブジェクトに記述します。Configure the sandboxed Bash tool によると、対応環境は macOS、Linux、WSL2 です。
sandbox の主なオブジェクトは次のとおりです。
| 設定 | 制限する対象 |
|---|---|
sandbox.filesystem |
読み取り・書き込みできるパス |
sandbox.network |
接続できるホストやドメイン |
sandbox.credentials |
認証情報を含むファイルや環境変数 |
権限ルールとサンドボックスは、止めるタイミングが異なります。権限ルールは、Claude Code がツールを実行する前に可否を判定します。サンドボックスは、実行されたコマンドとその子プロセスが動いている間のアクセスを制限します。権限ルールで許可したコマンドが、内部で想定外のファイルや通信先へアクセスする場合は、サンドボックスで制限します。
5-4. Managed settings の配信方法
Managed settings は、組織が配布する設定のスコープです。配信方法は 2 種類あります。
| 配信方法 | 設定元 | 主な適用先 |
|---|---|---|
| Server-managed settings | 管理画面へアップロードする settings.json |
対応する Claude Code クライアント、クラウドセッション |
| Endpoint-managed settings | MDM・OS ポリシー、システム領域の managed-settings.json |
管理対象端末の Claude Code |
両方を同時に配信した場合、既定では両者が結合されません。どちらが採用されるかは配信元の優先順位で決まるため、併用する場合は事前に検証してください。
端末を MDM で管理できる場合、OS 側で改変を防げる Endpoint-managed settings のほうが強い保証を持ちます。クラウドセッションも対象にする場合は Server-managed settings が必要です。
5-5. 設定の確認方法
ターミナルで Claude Code を起動し、対話セッション内で /status を入力します。表示された画面の「Status」タブにある Setting sources の行で、現在読み込まれている設定元を確認できます。
$ claude
> /status
Setting sources は読み込んだ設定元を示すもので、どのキーをどの設定元から採用したかまでは表示されません。
以下は Status タブの表示例です。
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Settings Status Config Usage Stats
Version: 2.1.219
Session name: /rename to add a name
Session ID: xxx
cwd: xxx
Login method: Claude Enterprise account
Organization: xxx
Email: xxx
Model: opus[1m] (claude-opus-5[1m])
MCP servers: 4 connected, 20 need auth · /mcp
Setting sources: User settings, Project local settings, Enterprise managed settings (remote)
System diagnostics
⚠ xxx
適用後の権限ルールも、Claude Code の対話セッション内で /permissions を入力すると確認できます。Allow、Ask、Deny のタブを切り替えると、それぞれに適用されているルールを確認できます。
$ claude
> /permissions
以下は Allow タブの表示例です。
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Permissions Recently denied Allow Ask Deny Workspace
Claude Code won't ask before using allowed tools.
╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ⌕ Search… │
╰────────────────────────────────────────────
1. Add a new rule…
2. Bash(.venv/bin/pip freeze *)
3. Bash(.venv/bin/python -c ' *)
4. Bash(.venv/bin/python xx)
5. Bash(xx)
6. Bash(xx)
7. Bash(xx)
8. Bash(xx)
9. Bash(xx)
↓ 10. Bash(echo "EXIT_CODE=$?")
←/→ to switch · ↓ to select · Esc to cancel
Server-managed settings の取得結果は、ターミナルから claude doctor を実行し、Managed settings (remote) の行で確認できます。表示される項目は Claude Code のバージョンによって変わるため、利用時点の公式ドキュメントも確認してください。
$ claude doctor
以下は実行結果です。
emiki@<hostname>:~/xx$ claude doctor
Claude Code doctor
Running: npm-global (2.1.248)
Commit: 8c9482ad0510
Platform: linux-x64
Path: /home/emiki/.npm-global/lib/node_modules/@anthropic-ai/claude-code/bin/claude.exe
Config install method: global
Search: OK (bundled)
Auto-updates: enabled
Auto-update channel: latest
Last update attempt: failed (install_failed) — 2026-09-02
Managed settings (remote): loaded
Remote Control
xx
No installation issues found.
For a full setup checkup that can also fix issues, run /doctor in a Claude Code session.
emiki@<hostname>:~/xx$
5-6. ~/.claude.json との違い
~/.claude.json は、サインイン状態やプロジェクトごとの状態などを保持するファイルです。設定を記述する settings.json とは役割が異なります。
6. settings.json と CLAUDE.md の役割の違い
Claude Code では、CLAUDE.md にプロジェクトの構成、ビルドコマンド、コーディング規約などを記載できます。
settings.json は、Claude Code がどのモデルを利用するか、どの操作を許可するか、どのファイルや通信先へアクセスできるかといった動作や権限を設定するものです。CLAUDE.md は Claude へ継続的な指示やプロジェクト情報を渡すものです。
7. Claude Code で設定できること
Settings reference には多数の設定キーが掲載されています。組織で検討することが多そうな項目を抜粋すると、次のようになります。
| 制御対象 | 主なキー・設定 | 適用のしかた |
|---|---|---|
| ログイン先 | forceLoginMethod、forceLoginOrgUUID |
5-1 の優先順位で決まる |
| コマンド・ツール | permissions.allow、permissions.ask、permissions.deny |
5-2 の権限ルールとして判定される |
| 権限モード | permissions.disableBypassPermissionsMode、permissions.disableAutoMode |
5-1 の優先順位で決まる |
| ファイル・通信・認証情報 | sandbox.filesystem、sandbox.network、sandbox.credentials |
5-1 の優先順位で決まる（対象の一覧は結合される） |
| MCP | allowedMcpServers、deniedMcpServers |
5-1 の優先順位で決まる（一覧の扱いはキーごとに異なる） |
| MCP・Hooks の制限 | allowManagedMcpServersOnly、allowManagedHooksOnly |
5-1 の優先順位で決まる |
| プラグイン | strictKnownMarketplaces、strictPluginOnlyCustomization |
5-1 の優先順位で決まる |
| モデル | availableModels、enforceAvailableModels |
5-1 の優先順位で決まる |
| バージョン | requiredMinimumVersion |
5-1 の優先順位で決まる |
権限ルールだけが 5-2 の扱いになります。複数のスコープから結合され、deny、ask、allow の順に判定されます。
それ以外のキーは 5-1 の優先順位で決まります。ひとつの値を持つキーは、優先順位が最も高いスコープの値が採用されます。一覧を持つキーは、複数のスコープから結合される場合と、優先順位の高いスコープの一覧がそのまま使われる場合があります。どちらになるかはキーごとに異なるため、Settings reference で確認してください。
8. 組織のセキュリティポリシーから settings.json の設定を考える
ここからは組織のセキュリティポリシーを例に考えてみます。
8-1. 秘密情報を Claude Code から参照させたくない
.env、SSH 鍵、クラウド認証情報を Claude Code から参照させない。
というポリシーがあるとします。
Claude Code 内蔵のファイルツールによる参照は、permissions.deny で拒否できます。ただし、コマンド経由の参照をすべて防げるわけではありません。OS レベルで制限する場合は、サンドボックスの credentials を使います。
Managed settings へ配置する json の例です。
{
"permissions": {
"deny": [
"Read(.env)",
"Read(.env.*)",
"Read(secrets/**)",
"Read(~/.ssh/**)",
"Read(~/.aws/credentials)"
]
},
"sandbox": {
"enabled": true,
"failIfUnavailable": true,
"allowUnsandboxedCommands": false,
"credentials": {
"files": [
{
"path": ".env",
"mode": "deny"
},
{
"path": "~/.ssh/id_rsa",
"mode": "deny"
},
{
"path": "~/.ssh/id_ed25519",
"mode": "deny"
},
{
"path": "~/.aws/credentials",
"mode": "deny"
}
],
"envVars": [
{
"name": "GITHUB_TOKEN",
"mode": "deny"
}
]
}
}
}
"sandbox" が、サンドボックスに関する設定です。enabled でサンドボックスを有効にし、credentials.files に保護するファイル、credentials.envVars に保護する環境変数を指定しています。mode が "deny" の項目は、Bash コマンドとその子プロセスから参照できないようにします。
permissions.deny とサンドボックスでは、制御する経路が異なります。permissions.deny は、Claude Code がツールを実行する前の可否を判定します。sandbox.credentials は、サンドボックス内で動くコマンドと子プロセスからの参照を制限します。
サンドボックスが認証情報を自動的に判別してくれるわけではありません。上の例にない SSH 鍵、クラウドサービスの設定ファイル、トークンを格納した環境変数などがある場合は、組織の環境に合わせて追加します。
なお、ここでは一般的な SSH 秘密鍵として id_rsa と id_ed25519 を例示しています。別のファイル名で秘密鍵を管理している場合は、そのパスも設定対象に含めます。
8-2. 本番反映や外部への書き込みは人が確認したい
git pushや本番反映は、実行前に利用者の確認を必要とする。
というポリシーがあるとします。
{
"permissions": {
"ask": [
"Bash(git push *)",
"Bash(terraform apply *)"
],
"disableBypassPermissionsMode": "disable"
},
"allowManagedPermissionRulesOnly": true
}
permissions.disableBypassPermissionsMode は、権限確認を省略する bypassPermissions モードを禁止する設定です。値は Boolean ではなく文字列の "disable" を指定します。
allowManagedPermissionRulesOnly を有効にすると、User、Project、Local の権限ルールではなく、Managed settings のルールを権限判定の基準にできます。
何を本番反映とみなすかは組織ごとに異なります。terraform apply だけでなく、クラウドサービスの CLI、データベース操作、SaaS への書き込みなども洗い出す必要があります。
この設定は、指定したコマンド文字列に一致する操作へ確認を要求する例です。本番反映を意味的に判定するものではないため、ラッパースクリプト、CI/CD、クラウド CLI、MCP など別経路の統制も必要です。
8-3. コマンドの外部通信先を承認済みドメインへ限定したい
Claude Code が起動するコマンドからの外部通信は、業務上必要なドメインだけに限定する。
というポリシーがあるとします。
{
"sandbox": {
"enabled": true,
"network": {
"allowedDomains": [
"github.com",
"api.github.com",
"registry.npmjs.org"
],
"strictAllowlist": true,
"allowManagedDomainsOnly": true
}
}
}
sandbox.network は、Bash コマンドとその子プロセスの通信先を制限する設定です。allowedDomains に許可するドメインを指定し、strictAllowlist で未登録の通信先を拒否します。allowManagedDomainsOnly を有効にすると、利用者による許可先の追加も防げます。
この設定が対象とするのは、サンドボックス内で動くコマンドの通信です。Claude Code 内蔵の WebFetch は別の経路なので、この JSON だけでは制限できません。WebFetch も制御する場合は、permissions.deny や permissions.allow に WebFetch(domain:example.com) のような権限ルールを追加します。許可するドメインは、実際に利用するサービスに合わせて決めてください。
8-4. 管理外の MCP・Hooks・プラグインを使わせたくない
MCP、Hooks、プラグインを使うと、Claude Code を社内システムや開発フローへ組み込めます。これらには外部通信やローカルコマンドの実行を伴うものもあります。
次のポリシーを想定します。
組織が確認した拡張機能だけを利用可能にする。
この場合、次の設定が候補になります。
| 目的 | 設定 |
|---|---|
| MCP サーバーを許可・拒否する | allowedMcpServers、deniedMcpServers |
| 管理者の MCP 許可リストだけを使う | allowManagedMcpServersOnly |
| 管理者が配布した Hooks だけを実行する | allowManagedHooksOnly |
| プラグインの入手元を限定する | strictKnownMarketplaces |
| プラグインなどをコマンド引数で読み込ませない | disableSideloadFlags |
strictKnownMarketplaces は、プラグインを個別に承認する設定ではなく、追加とインストールを許可するマーケットプレイスを限定する設定です。これらのキーには例外や前提条件があるため、適用する前に公式ドキュメントで動作を確認してください。
許可するかどうかは、提供元と更新方法、接続先と送信するデータ、実行できる操作の範囲等を考えて判断します。
同じ MCP サーバーでも、社内ドキュメントを検索するだけのものと、Issue の作成や本番環境の操作まで行えるものでは、影響範囲が違います。サーバー単位で許可するだけでなく、そのサーバーが提供するツールで何ができるかまで確認します。
8-5. 利用モデルと Claude Code のバージョンを統一したい
組織によっては、承認済みのモデルだけを利用させたい、古い Claude Code による設定漏れを防ぎたいという要件が出てくる場合があります。
| 目的 | 設定 |
|---|---|
| 選択可能なモデルを制限する | availableModels |
| デフォルトの選択肢も許可リスト内に収める | enforceAvailableModels |
| 古い Claude Code の起動を拒否する | requiredMinimumVersion |
| 新しすぎるバージョンの起動を拒否する | requiredMaximumVersion |
availableModels だけではデフォルトの選択肢まで制限されないため、組織として統一する場合は enforceAvailableModels と組み合わせます。
モデルを制限するとコストを抑えられますし、組織で検証したモデルだけを使ってもらうこともできます。
バージョンを制限する場合は、更新方法も一緒に用意するのが良いです。最低バージョンだけ設定して更新手段がないと、ある日突然 Claude Code を起動できなくなる可能性があります。
モデル名やバージョンは日々アップデートされるため、利用時点の Settings reference で有効な値を確認してください。
9. 組織設定の進め方
設定は厳しければよいとは限りません。制限によって必要な業務まで止めないよう、次の順序で検討します。
- 利用者、用途、扱うデータを整理する
- 禁止する操作と許可する操作を決める
- 組織全体の管理設定、Claude Code の Managed settings、利用ルールへ落とし込む
- 一部の利用者で検証してから展開する
- 例外対応と定期的な見直し方法を決める
この記事の JSON は設定方法を示す例であり、そのまま本番利用することを想定したものではありません。利用する Claude Code のバージョンや OS、業務への影響を確認し、/status、/permissions、claude doctor や実際の操作で適用結果を検証してください。
おわりに
Claude Enterprise の組織設定について勉強しながら、どんな設定ができるか考えてみました。設定できる項目が多いので、全部網羅するより、何を制御したいのか先に考えるのがおすすめです。
この記事が、自社のセキュリティポリシーに合った設定を検討する際の参考になれば幸いです。
本記事への質問やご要望については画面下部の「DevelopersIOへのご意見」からお問い合わせいただけます。
参考情報
