Claude Codeを企業利用するときのベストプラクティス

シンジです。社内でClaude Codeを本格展開するときに、何も考えずにアカウントだけを渡していませんか？Claude Codeは社内システムを破壊するほどの強力な道具です。本来は配布前に以下のような課題があるはずです。

• 社内の誰がClaude Codeを使えるのか
• 会社管理アカウントだけに寄せられるのか
• どのコマンドを実行してよいのか
• どのファイルを読ませてよいのか
• MCPサーバーを自由に追加させてよいのか
• 利用状況やコストをどう可視化するのか
• 開発者ごとにバラバラな設定になるのをどう防ぐのか

それらを解決するアプローチのひとつとして、 claude-code-starter-kit をOSSとして公開・運用しながら、同時にClaude Codeを組織でどう配布・管理するべきかを検討してきました。

1行コピペで社員全員プログラマーになれるClaude Codeセットアップを作った | CloudNative BLOGs 本記事では、1行のコピペで社員全員をプログラマーにするClaude Codeのセットアップを解説します。テンプレートエンジン、プラグインシステム、フックのアセンブリ、Codex MCPの統合について整理しました。 https://blog.cloudnative.co.jp/articles/claude-code-starter-kit-one-liner/

シンジは、「Starter Kitを配ればClaude Codeの組織管理は終わり」だと思っていません。

Claude Codeには公式の組織管理機能が存在しますので、これを併用します。Starter KitとClaude Code公式の組織管理機能は、そもそも担っているレイヤーが違います。

• Starter Kitは、開発者に推奨設定・エージェント・コマンド・スキル・フックを配るためのもの
• Claude Code公式のmanaged settingsは、組織ポリシーを強制するためのもの

前者は「開発者体験と標準ワークフローの配布」です。後者は「組織として外せない境界線の強制」です。

片方だけでは不十分で、Starter Kitだけでは、生産性は上がってもガバナンスは効きません。逆にmanaged settingsだけでは、統制はできますが、開発者にとって使いやすい標準環境にはなりません。

この記事では、Claude Code公式の管理機能とStarter Kitを整理し、用途・違い・できること/できないこと・正しい組み合わせ方、そして企業規模・人数別の配布指針までをまとめます。

本記事の事実確認方針：Claude Code公式機能はAnthropic / Claude Code公式ドキュメントを一次情報とし、Starter Kitの記述はGitHubリポジトリ本体を確認対象にしています。

1. 結論：Claude Codeの組織配布は「3つのレイヤー」で考える

Claude Codeを企業に展開するとき、役割の異なる3層に整理できます。

重要なのは、Starter Kitは③の標準環境配布層に位置するということです。

Starter Kitは、Claude Codeを使いやすくするためのエージェント、コマンド、スキル、ルール、フックなどを ~/.claude 配下に展開します。これは開発者本人が編集・削除できるユーザー領域です。

一方で、Claude Code公式のmanaged settingsは、IT部門やセキュリティ部門が配布する管理設定です。ユーザー設定やプロジェクト設定では上書きできません。

つまり、役割は次のように分けて考えるべきです。

一言でいうと、道具はStarter Kitで配り、境界線はmanaged settingsで強制するという設計が基本です。

2. Claude Code公式の組織管理機能

Claude Code公式側で提供されている管理機能は、大きく次の領域に分かれます。

1. 認証・アカウント管理
2. managed settings
3. permissions
4. hooks
5. MCP管理
6. plugin / marketplace管理
7. sandbox
8. model / login制御
9. ログ・可視化・監査
10. データ保護・保持

2-1. 認証・アカウント管理

Claude Codeを企業で使う場合、最初に決めるべきなのは「誰のアカウントで使わせるか」です。

個人のClaude Pro / Maxをバラバラに使わせる運用は、企業配布としては望ましくありません。

理由は次の通りです。

• 退職時に利用停止しにくい
• 誰が使ったか可視化しにくい
• コスト管理が分散する
• 個人のClaude Free / Pro / MaxアカウントでClaude Codeを使う場合はConsumer製品のデータ利用条件が適用される。モデル改善設定がオンの場合、チャットやcoding sessionはモデル改善に使われ、保持期間は5年。オフの場合は30日保持。
• 会社Org外のアカウントで認証した場合、会社Orgから配信されるserver-managed settingsは配信されない。ただし、端末側にMDM / OS-level policy / file-based managed settingsを配っている場合、その端末側の制御は別途残る。
• MCPやpluginの統制が効きにくい

企業では、原則としてClaude for TeamsまたはClaude for Enterpriseの会社管理アカウントに寄せるべきです。

Claude / Claude Consoleのユーザープロビジョニングについては、Anthropic公式Help Centerの「Set up JIT or SCIM provisioning」で、JIT provisioningとSCIM provisioningの提供条件が明示されています。JIT provisioningはTeam plans、Enterprise plans、Console organizationsで利用できます。一方、SCIM provisioningはEnterprise plansとConsole organizationsでのみ利用でき、Team plansやTeam planのparent organizationに参加しているConsole organizationsでは利用できません。SCIM directory syncを使うと、IdP上の割り当てに基づいてユーザーを自動プロビジョニング / デプロビジョニングできます。前提として、SSO設定、ドメイン検証、IdP側のAnthropicアプリ設定、ClaudeのOwnerまたはConsoleのAdmin権限が必要です。

認証方式としては、Claude.aiアカウントによるOAuth、Claude Console、Amazon Bedrock、Google Vertex AI、Microsoft Foundryなど複数の選択肢があります。

ただし、企業統制という意味では注意が必要です。

Claude.aiのTeam / Enterpriseであれば、Claude Codeの管理機能やアカウント管理と結びつけやすくなります。一方で、Bedrock / Vertex AI / Foundryを使う場合、認証・課金・権限は各クラウド側のIAMに寄るため、Claude Code側の一部管理機能とは適用範囲が異なります。

特に、server-managed settingsはClaude.aiのTeam / Enterprise組織に紐づく仕組みです。第三者プロバイダやカスタムAPIエンドポイントを使う構成では適用されない制約があります。

2-1-1. アカウント切り替えは、企業統制の境界を変えてしまう

Claude Codeの企業利用で見落とされやすいのが、会社アカウントの利用枠やクレジットが尽きたときに、個人契約のClaudeアカウントへ切り替えてしまうケースです。

これは、意図的な統制回避の場合もあれば、本人に悪意はなく「仕事を止めないために自分のアカウントで続けただけ」という場合もあります。しかし企業側から見ると、会社のTeam / Enterprise組織外へ切り替えることで、会社Orgを前提にしたserver-managed settings、analytics、billing visibility、Enterprise監査の境界から外れます。端末側managed settingsやOSレベル制御を別途配っている場合は、その制御は残ります。

特に、会社のTeam / Enterprise組織で認証していることを前提に、server-managed settings、usage analytics、Compliance API、billing visibility、MCP制御、permission rules、hooks、モデル制限、ログ設定を配っている場合、個人アカウントへ再ログインされると、その多くが会社Orgの管理外になります。

重要なのは、会社アカウントの利用枠不足は、個人アカウント利用を許可する理由にはならないという点です。

会社のサブスクリプション内でトークンや利用枠を使い切るユーザーがいるなら、それは個人アカウントへの切替で解決するのではなく、次のように運用設計で対処すべきです。

• 利用量の多いユーザー・チームをusage analyticsやOTelで把握する
• 業務上必要な高利用なのか、非効率な使い方なのかを切り分ける
• 必要なら上位プラン、追加枠、API利用、Bedrock / Vertex / Foundryなどへ分離する
• 自動化・CI/CD・SDK利用は人間のサブスクリプション枠と分ける
• 高コストな利用パターンをStarter Kitのルールや社内トレーニングで抑制する
• 個人契約アカウントや個人API keyへの切替は禁止事項として明文化する

技術的には、forceLoginOrgUUID をmanaged settingsで設定すれば、指定したAnthropic organizationに属さないアカウントでのログインを防げます。ただし、この設定でブロックできるのは、会社のAnthropic organizationに属さないアカウントのOAuthログインと、ANTHROPIC_API_KEY / ANTHROPIC_AUTH_TOKEN / apiKeyHelper による起動です。Amazon Bedrock / Google Vertex AI / Microsoft Foundry など第三者プロバイダ経由のセッションは、Anthropicではなく各クラウド側で認証されるため、forceLoginOrgUUID ではブロックされません。これらは各クラウドのIAMで利用可能なアカウントを制限する必要があります。また、組織の端末管理状況によって強制力は変わります。MDMやOS-level policyで配布しているのか、file-based managed settingsだけなのか、ユーザーにローカル管理者権限を与えているのかによって、改変耐性と検知可能性は変わります。sudoが使えるなら意図的にこの強制を排除できます。

アカウント切り替えは、単なるライセンス運用の問題ではありません。Claude Codeがファイル編集、Bash実行、MCP接続、外部サービス連携まで行える以上、認証アカウントの切替は、企業のセキュリティ境界そのものを切り替える行為として扱うべきです。

2-2. managed settings：組織配布の中核

Claude Codeの企業配布で最も重要なのが managed settings です。

Claude Codeには複数の設定スコープがあります。

設定の優先順位は、高い順に次の通りです。

1. Managed
2. コマンドライン引数
3. Local
4. Project
5. User

このうち、Starter Kitが主に書き込むのは ~/.claude 配下、つまりUserスコープです。これは最も優先順位が低い層です。

一方、managed settingsは最も優先順位が高く、ユーザーやプロジェクト設定では上書きできません。

したがって、企業導入では次のように役割分担します。

2-3. managed settingsの配信方法

managed settingsには複数の配信方法があります。

ここで注意したいのは、適用優先順位と改ざん耐性は別物という点です。

Claude Codeのmanaged tier内では、server-managed settings、MDM/OS-level policy、file-based、HKCUの順に評価されます。server-managed settingsが有効な場合、その設定が先に使われ、同じmanaged tier内のMDM/OS-level policyやfile-based settingsとは基本的に併用マージされません。

一方で、管理対象端末における改ざん耐性という意味では、MDM/OS-level policyやシステム領域の managed-settings.json の方が強い保証を持ちます。server-managed settingsは、MDMがない組織や非管理端末、BYODに対して中央配信できる点が強みです。

つまり、こう整理すると分かりやすいです。

組織規模や端末管理状況によって使い分けるのが現実的です。

• MDMがない小〜中規模組織：server-managed settingsから開始
• 管理対象Mac / Windowsが中心：Jamf / Intune / Group PolicyでOS-level policy配布
• Linux / WSL開発が中心：file-based managed settingsを構成管理で配布
• 規制業種・高セキュリティ環境：MDM / OS-level policyを主軸にし、ログ・監査で補完
• BYODや外部委託を含む：server-managed settings + SSO + domain capture + 利用規程

2-4. server-managed settingsの利点と制約

server-managed settingsは、Claude.ai管理コンソールからClaude Codeの管理設定を配信できる強力な仕組みです。

MDMがない組織でも、中央からpermissions、hooks、MCP制限、モデル制限、ログ設定などを配れる点が大きな利点です。

ただし、企業配布では制約も理解しておく必要があります。

第三者プロバイダ利用時の制約も確定情報として押さえておく必要があります。

server-managed settingsは、Amazon Bedrock、Google Vertex AI、Microsoft Foundry、カスタム ANTHROPIC_BASE_URL、LLM gatewayなど、第三者モデルプロバイダ利用時には利用できません。また、forceLoginOrgUUID や forceLoginMethod でもBedrock / Vertex / Foundryセッションはブロックできません。これらはAnthropicではなく各クラウド側で認証されるため、利用可能なクラウドアカウントは各クラウドIAMで制限します。

可視化面でも、Claude Code Analytics APIが追跡するのはClaude API上のClaude Code利用であり、Claude Platform on AWS、Microsoft Foundry、Amazon Bedrock、Vertex AI経由の利用は含まれません。さらに、Bedrock / Vertex / Foundry / Claude Platform on AWSでは、Claude Codeのerror reporting、telemetry、bug reporting、/feedback reportsは既定で無効です。ただし、host platformが CLAUDE_CODE_PROVIDER_MANAGED_BY_HOST を設定する場合、v2.1.126以降ではVertex / Bedrock / Foundryのmetricsが既定オンになり、DISABLE_TELEMETRY による通常のopt-outに従います。第三者プロバイダごとの具体的なデータ保持設定値は、Anthropic公式ドキュメントではなく、各クラウド公式ドキュメントで確認する必要があります。

特に重要なのは forceRemoteSettingsRefresh です。

既定では、remote settingsの取得に失敗するとCLIはmanaged settingsなしで起動を継続します。これを避けたい場合、forceRemoteSettingsRefresh: true を使い、remote settingsを新しく取得できない場合はCLIを起動させないfail-closed設計を検討します。

企業配布では、server-managed settingsを「便利な中央配信」として評価しつつ、高セキュリティ環境ではMDM/OS-level policyや監査ログと組み合わせるべきです。

2-5. permissions：実行時制御の中心

Claude Codeのpermissionsは、AIに対するお願いではありません。Claude Codeクライアント側でツール利用を実際に許可・確認・拒否する仕組みです。

基本は次の3種類です。

例えば、次のような制御ができます。

• .env や secrets/** の読み取りを拒否
• rm -rf や sudo を拒否
• git push --force を拒否または確認
• curl や wget を拒否または確認
• npm test や npm run lint は許可
• MCPツールの利用を制限
• WebFetchを制限

企業導入で重要なのは、ユーザーやプロジェクト側でpermission rulesを追加・変更できる状態を許すかどうかです。

Claude Codeには allowManagedPermissionRulesOnly というmanaged settings専用の設定があります。これを有効にすると、user / project設定由来の allow / ask / deny permission rulesは定義できず、managed settingsのpermission rulesだけが適用されます。

これは非常に重要です。

Starter Kitにもdenyリストや安全設定がありますが、それは基本的にはユーザー領域の設定です。allowManagedPermissionRulesOnly: true を有効にする場合、Starter Kit側のpermission rulesを活かし続けるのではなく、組織として必要なdenyルールをmanaged settings側へ移植・昇格する設計が正しいです。

つまり、次のように考えるべきです。

おすすめは、Starter Kitのdenyリストを棚卸しし、次の3つに分類することです。

1. 全社で必ず禁止するもの
2. 部門・リポジトリによって判断するもの
3. 個人の自衛として残すもの

このうち1はmanaged settingsに昇格します。

2-6. hooks：組織ガードレールを作る仕組み

Claude Codeのhooksは、特定のイベントで外部コマンドやHTTPエンドポイントなどを実行できる仕組みです。

企業導入では、次のhookが特に重要です。

Starter KitにもSafety NetのようなPreToolUse hookがあります。これは、rm -rf、git reset --hard、git push --force などの破壊的操作を検査するための安全網です。

ただし、Starter Kitのhookは基本的にユーザー領域に配置されます。ユーザーが削除・無効化できるため、企業統制としては強制力が不足します。

企業で必須のhookは、managed settings側に移す必要があります。さらに allowManagedHooksOnly: true を使えば、managed hooks、SDK hooks、managed settingsでforce-enabledされたplugin hooksだけをロードし、user / project由来のhooksをブロックできます。

ただし、これも導入順序に注意が必要です。

いきなり allowManagedHooksOnly を有効にすると、user / project由来のhooksと、managed settingsでforce-enabledされていないplugin hooksはロードされません。Starter Kit由来hookを使う場合はmanaged hook化またはforce-enabled plugin化が必要です。最初は監査モードで棚卸しし、必要なものをmanaged hook化してから締めるのが安全です。

2-7. MCP管理：最も慎重に扱うべき領域

Claude Codeの企業導入で最も注意すべきなのがMCPです。

MCPは非常に強力です。GitHub、Slack、Google Drive、Notion、社内API、データベース、チケット管理システムなどと連携できます。

一方で、MCPはデータ流出経路にもなります。

ユーザーが自由にMCPサーバーを追加できる状態では、次のリスクがあります。

• 社内ソースコードが外部MCPに渡る
• Google DriveやSlackの情報が意図せず取得される
• 個人が作ったMCPサーバーに機密情報が流れる
• MCP経由のprompt injectionを受ける
• 管理者が利用状況を把握できない
• 退職者や委託先の接続管理が不十分になる

Claude Codeでは、managed settingsにより allowedMcpServers、deniedMcpServers、allowManagedMcpServersOnly などを使ってMCP利用を制御できます。

また、file-based managed settingsでは managed-mcp.json を配布できます。managed-mcp.json を使うと、管理者が配布する固定MCP構成を定義できます。

ただし、server-managed settingsでは managed-mcp.json を直接配布できない点に注意が必要です。承認済みMCPの固定配布が必要な場合は、file-based配布、MDM、構成管理、またはplugin / marketplaceの設計を組み合わせます。

企業では、MCPの扱いを次のように段階化するのがよいです。

MCPはClaude Codeの価値を大きく引き上げますが、企業導入では「便利だから自由に使わせる」ではなく、「承認済みのMCPだけを、監査可能な形で使わせる」設計にすべきです。

2-8. plugin / marketplace管理

Claude Codeにはplugin marketplaceの仕組みがあります。

これは、commands、agents、skills、hooks、MCP server定義などをpluginとして配布するための仕組みです。

企業配布では、このplugin / marketplace管理が非常に重要になります。

なぜなら、Starter Kitのような標準環境を、将来的にplugin marketplace形式で配布できれば、次のような運用が可能になるからです。

• 会社公式のClaude Code標準環境をplugin化する
• strictKnownMarketplaces で会社承認済みmarketplaceだけを許可する
• blockedMarketplaces で未承認marketplaceを拒否する
• enabledPlugins で必要pluginを自動有効化する
• strictPluginOnlyCustomization でuser / project由来のskills、agents、hooks、MCPをブロックし、pluginまたはmanaged由来だけに限定する

ただし、ここは誤解しないように注意が必要です。

現時点の claude-code-starter-kit は、主にワンコマンドセットアップとプロファイル配布の形で提供されています。そのまま enabledPlugins に cn-starter@cloudnative のような名前で指定すれば動く、という意味ではありません。

Starter Kitを公式plugin marketplace方式で配布するには、別途plugin manifestやmarketplace定義を用意し、Claude Codeのplugin仕様に沿って公開・配布する必要があります。

したがって、本記事で示すplugin化は「現時点でそのまま実行できる設定」ではなく、企業配布に向けた推奨アーキテクチャとして位置づけます。

現実的には次の2段階がよいでしょう。

2-9. sandbox：permissionsの隙間をOSレベルで補う

permissionsだけでは防げないケースがあります。

例えば、WebFetch をdenyしても、Bashが許可されていれば curl や wget などで外部URLへ到達できます。

つまり、Claude Code上のツール単位の制御と、OSレベルのネットワーク・ファイルシステム制御は別物です。

このギャップを埋めるのがsandboxです。

企業では、次のように二重化して考えるべきです。

特に外部送信系コマンドを許可する場合、permissionsだけに頼らず、sandboxやEDR/DLP側でも制御するのが安全です。

2-10. ログ・可視化・監査

Claude Codeの企業利用では、利用状況とコストの可視化が必須です。

Claude Codeでは、OpenTelemetryを使ったusage monitoringが利用できます。また、Claude Code Analytics APIやClaude Enterprise Analytics APIにより、利用状況・コスト・生産性指標を集計できます。

ただし、Compliance API / audit logsとOpenTelemetryは役割が違います。

Audit logsはEnterprise organizationsのみで利用でき、過去180日分の組織イベントをエクスポートできますが、chatやprojectのtitle / contentは含まず、unique identifier等のメタデータ中心です。

Compliance APIはClaude Enterprise customers向けに、Activity Feed、users / roles / groups directory、organization metadata / settings、Claude.ai組織のchats / files / projectsへプログラムアクセスを提供します。Claude Console organizationsではリクエストによりActivity Feedのみ利用でき、Admin API keyはActivity Feed以外のCompliance API endpointにはアクセスできません。Team plan向けのCompliance APIアクセスは公式ドキュメント上、提供対象として示されていません。

Claude Codeとの関係では、Compliance API / audit logsで確認できるClaude Code関連イベントは、server-managed settingsの設定変更などの管理イベントに限られます。Claude Codeのコーディングセッションの中身、prompt、tool呼び出し、ファイル編集内容をCompliance APIやaudit logで監視できるわけではありません。Claude Code活動そのものの監視・可視化は、OpenTelemetryやClaude Code Analytics APIを使う設計に分ける必要があります。

取得すべきログは、最初から「全部」ではなく、目的に応じて決めるべきです。

prompt本文やtool input / outputまでログに残すと、監査上は有用ですが、ソースコードや機密情報をSIEMやログ基盤に二次保存することになります。

そのため、最初は次のような方針が現実的です。

• 利用者、モデル、トークン、コスト、tool種別、MCP利用、Bashコマンド名を取得
• prompt本文やraw bodyは取得しない
• 高リスク部門や特定リポジトリだけ詳細ログを有効化
• ログ保持期間を明確化
• SIEM連携時はDLP・アクセス制御を設計する

2-11. Zero Data Retention（ZDR）の扱い

Claude CodeのZero Data Retention（ZDR）は、Claude for Enterpriseのqualified accounts向け機能です。標準のClaude for Enterprise planには含まれず、admin settingsから自己有効化することもできません。利用にはsalesまたはAnthropic account team経由での個別有効化が必要で、Anthropic側でeligibility確認後にorganization単位で有効化されます。ZDRの有効化操作はaudit-log化されます。

ZDRが有効なClaude Code organizationでは、Claude Code session中のpromptとmodel responseはリアルタイム処理され、response返却後にAnthropicへ保存されません。ただし、法令遵守や不正対策に必要な場合は例外があります。Usage Policy違反としてflagされたsessionでは、関連するinput / outputが最大2年保持される場合があります。

ZDR下では、promptやcompletionの保存を必要とする機能がbackend levelで無効化されます。公式ドキュメントで明示されている対象は、Claude Code on the Web、Desktop appからのcloud sessions、/feedback submissionです。また、Claude Code Analyticsはpromptやmodel responseを保存しませんが、account emailやusage statisticsなどのproductivity metadataは収集します。

ZDRはAnthropicのdirect platform上のClaude Code inferenceに適用されます。Amazon Bedrock、Google Vertex AI、Microsoft Foundry上のClaude deploymentは対象外で、各プラットフォームのdata retention policyに従います。MCP serverやthird-party toolsなどの外部integrationsで処理されるデータもZDR対象外です。

ZDR契約の適用範囲は、eligible Anthropic APIs、Commercial organization API keyを使うAnthropic products（API経由のClaude Codeを含む）、Claude Code for Enterprise plansです。一方で、具体的に何をもってqualified accountsと判定するかは公式ドキュメントでは公開されていないため、資格基準は断定できません。

モデルにも注意が必要です。Claude Fable 5とClaude Mythos 5はCovered Modelsとして30日保持が必要で、ZDRでは利用できません。ZDR organizationからこれらのmodelへrequestすると、data retention configurationが要件を満たさないため 400 invalid_request_error になります。ZDR契約があるorganizationでも、Claude Consoleのworkspace単位で30-day data retentionを有効化すれば、指定workspaceでFable 5 / Mythos 5を利用できますが、そのworkspaceではZDRではなく30日保持の扱いになります。

3. Starter Kitとは何か

ここからは、クラウドネイティブが公開している claude-code-starter-kit を整理します。

GitHub - cloudnative-co/claude-code-starter-kit: One-command setup of a complete Claude Code development environment with interactive wizard One-command setup of a complete Claude Code development environment with interactive wizard - cloudnative-co/claude-code-starter-kit https://github.com/cloudnative-co/claude-code-starter-kit

Starter Kitは、Claude Codeの開発環境をワンコマンドでセットアップするためのツールキットです。シンジが普段使っている環境をほぼ再現しているので、セキュリティ対策に振り切っています。

主な目的は、次の通りです。

• Claude Codeを導入した直後から実務で使える状態にする
• チームや会社で標準のagents / commands / skills / rulesを配る
• 安全な初期設定を配る
• 開発者の使い方を標準化する
• 初学者でもClaude Codeを迷わず使い始められるようにする

macOS と Windows（WSL2）を対象としたワンコマンドセットアップ、対話型ウィザード、Minimal / Standard / Full のプロファイル、agents、rules、commands、skills、hooks、pluginsなどが提供されます。

3-1. Starter Kitの基本構成

Starter Kitは、主に次の要素を配布します。

Starter Kitの価値は、Claude Codeを単なるCLIとしてではなく、「開発チームの標準作業環境」として整える点にあります。

3-2. プロファイル：Minimal / Standard / Full

Starter Kitには、導入レベルに応じたプロファイルがあります。

企業配布では、いきなりFullを全員に配るのはおすすめしません。まずは小さく検証してください。

Fullは便利ですが、導入される機能が増えるほど、セキュリティレビュー対象も増えます。まずはStandardをベースにし、自社に不要なものを削り、必要なものを追加した「社内Standard」を作るのが現実的です。このGithubをベースに自社オリジナルワンライナーも作れるはずです。

シンジ自身はFullで使っていますし、目の届く範囲内のユーザーは全員Fullで使っています。結局これが一番便利に使える状態を整えてくれるからです。作者だから中身が分かっている前提があるので、仕組みを理解してから社内向けのものを作るのがオススメです。

3-3. Starter Kitのセキュリティ機能

Starter Kitには、セキュリティ上有用な設定やhookも含まれます。

代表例はSafety Netです。

Safety Netは、Claude CodeのPreToolUse hookを使い、危険なBashコマンドを実行前に検査・ブロックする安全網です。

例えば、次のような破壊的なBashコマンドを検査対象にします。

• rm -rf
• git reset --hard
• git checkout -- <file>
• git push --force
• git clean -f / git restore（未コミット変更の破棄）
• git branch -D / git stash drop
• dd / mkfs / shred などディスク・ファイルを破壊する操作

これは非常に有用です。

なお、Safety Net（実体はnpmパッケージ cc-safety-net）はBashコマンドの破壊的操作を解析してブロックするガードであり、.env や ~/.ssh などの機密ファイル読み取りの禁止や sudo の制限は対象外です（ファイル読み取りはBashコマンド経由でも既定ではブロックされません）。これらはSafety Netではなく、permissionsのdenyルール（例: Read(**/.env)、Read(~/.ssh/**)、Bash(sudo *)）で制御します。

ただし、企業統制としては注意が必要です。

Starter Kitのhookやpermission設定は、基本的にユーザー領域に入ります。つまり、ユーザーが削除・変更できます。ただ、変更が容易というわけでもないので、実際に確認してみてください。いずれにしても、組織として強制する禁止ルールやhookは、managed settings / managed hooksへ昇格する必要があります。

したがって、次のように分けるべきです。

特に、allowManagedPermissionRulesOnly を有効にするとuser / project由来のallow / ask / deny permission rulesは定義できず、allowManagedHooksOnly を有効にするとuser / project由来hooksはロードされません。この場合は、Starter Kitのセキュリティ設定をそのまま残すのではなく、必要なものをmanaged settings側へ昇格する必要があります。

3-4. Starter Kitでできること

Starter Kitでできることは、主に「標準環境の配布」です。

Starter Kitは、Claude Codeを導入する会社にとって非常に有用です。特に、利用者ごとに使い方がバラバラになるのを防ぎ、会社としての「よい使い方」を配布できる点に価値があります。

3-5. Starter Kitでできないこと

一方で、Starter Kitだけではできないことがあります。

Starter Kitは、企業統制基盤ではありません。あくまで、許可された範囲内で開発者が成果を出すための標準環境です。

4. 公式管理機能とStarter Kitの違い

両者の違いを整理すると、次のようになります。

一言でいうと、公式管理機能は「ガードレール」、Starter Kitは「標準作業台」です。

5. 正しい組み合わせ方

企業でClaude Codeを配布するなら、次の設計が基本になります。

[IdP / Claude for Teams or Enterprise]
  SSO
  domain capture
  role / seat management
  必要に応じてSCIM

[Claude Code managed settings]
  forceLoginMethod
  forceLoginOrgUUID
  permissions
  hooks
  MCP allowlist / denylist
  sandbox
  model restriction
  telemetry
  marketplace restriction

[端末管理]
  Jamf / Intune / Group Policy
  /etc/claude-code/managed-settings.json
  managed-mcp.json
  EDR
  DLP
  disk encryption

[Starter Kit]
  agents
  commands
  skills
  rules
  safety-net
  profiles
  onboarding

5-1. 不変条件をmanaged settingsに昇格する

最初にやるべきことは、Starter Kitの中にあるセキュリティ設定やdenyリストを棚卸しし、「組織として必ず守らせたいもの」をmanaged settingsへ昇格することです。

例えば、次のようなものです。

• .env の読み取り禁止
• ~/.ssh の読み取り禁止
• secrets/** の読み取り禁止
• sudo の禁止
• rm -rf の禁止
• git push --force の禁止または承認制
• 外部送信系コマンドの承認制
• 本番環境操作の禁止または承認制

概念例は次の通りです。

{
  "permissions": {
    "deny": [
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(**/secrets/**)",
      "Read(~/.ssh/**)",
      "Bash(sudo *)",
      "Bash(rm -rf *)",
      "Bash(git push --force *)"
    ],
    "ask": [
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "allow": [
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(npm test *)",
      "Bash(npm run lint *)"
    ]
  },
  "allowManagedPermissionRulesOnly": true,
  "disableBypassPermissionsMode": "disable"
}

注意点として、allowManagedPermissionRulesOnly: true を有効にすると、user / project由来のpermission rulesは適用されなくなります。そのため、Starter Kitのpermission rulesをそのまま併用するのではなく、必要なものをmanaged settings側に移植する必要があります。

5-2. hookはmanaged hook化する

Starter KitのSafety Netは有用ですが、ユーザー領域にある限り、ユーザーが削除できます。

組織として必須のhookはmanaged settings側に移し、必要に応じて allowManagedHooksOnly: true を有効にします。

概念例は次の通りです。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "/usr/local/bin/company-claude-guard --pre-tool-use"
          }
        ]
      }
    ],
    "ConfigChange": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "/usr/local/bin/company-claude-guard --config-change"
          }
        ]
      }
    ]
  },
  "allowManagedHooksOnly": true
}

ただし、導入初期から allowManagedHooksOnly を有効にすると、既存のproject hookやStarter Kitのhookが効かなくなります。まずはログを取り、実際に使われているhookを棚卸ししてから段階的に締めるのが安全です。

5-3. MCPは承認制にする

MCPは最もリスクが高い領域です。

企業では、次のいずれかの方針にするべきです。

概念例は次の通りです。

{
  "allowedMcpServers": [
    {
      "serverName": "github"
    }
  ],
  "deniedMcpServers": [
    {
      "serverName": "filesystem"
    }
  ],
  "allowManagedMcpServersOnly": true
}

ただし、固定MCP構成を配る managed-mcp.json はserver-managed settingsでは直接配布できません。そのため、管理対象端末ではMDMやfile-based配布を使う必要があります。

5-4. Starter Kitは社内標準版として配る

Starter Kitは、そのまま全社員にFullで配るより、社内標準版を作る方が安全です。

おすすめは次の構成です。

company-claude-code-kit/
  agents/
    security-reviewer.md
    architect.md
    code-reviewer.md
  commands/
    plan.md
    tdd.md
    verify.md
    handover.md
  skills/
    security-review/
    verification-loop/
    backend-patterns/
  rules/
    security.md
    coding-style.md
    git-workflow.md
  hooks/
    safety-net/
  profiles/
    developer.conf
    sre.conf
    security.conf
  docs/
    user-guide.md
    mcp-policy.md
    security-policy.md

最初はcurl / PowerShell / MDMスクリプトで配布し、将来的にはClaude Code plugin marketplace形式への移行を検討します。

6. 企業規模別の推奨パターン

6-1. 個人〜5名

この規模では、まずStarter Kitで標準環境を作るだけでも十分効果があります。

ただし、会社のソースコードを扱うなら、個人Pro / Maxをバラバラに使うのは避けた方がよいです。

6-2. 5〜30名

この規模になると、Starter Kitだけでは統制が不足します。

MDMがない場合は、server-managed settingsが有力です。Linux / WSL中心なら、/etc/claude-code/managed-settings.json を構成管理で配布するのも現実的です。

6-3. 30〜100名

この規模では、アカウント管理・MCP・ログ設計が重要になります。

この段階では、Starter Kitを社内forkして、自社のセキュリティルール・レビュー観点・開発標準を反映するのがよいです。

6-4. 100名以上

100名を超えると、Claude Codeは単なるツールではなく、開発プラットフォームの一部になります。

この規模では、Starter Kitを「個人向け便利ツール」ではなく、社内Claude Code標準ディストリビューションとして扱うべきです。

6-5. 規制業種・公共・機密開発

規制業種、公共、重要インフラ、機密性の高い開発では、さらに慎重な設計が必要です。

この領域では、server-managed settingsの利便性だけに頼らず、MDM/OS-level policy、EDR、DLP、SIEM、IdP制御を組み合わせるべきです。

6-6. 統制が外れたときに企業が被る被害

Claude Codeは、ファイル編集、コード生成、Bash実行、MCP経由の外部サービス連携、CI/CDやSDKによる自動化まで扱えるツールです。そのため、個人アカウントへの切替、未承認MCPの利用、permissionsやhooksの無効化、ログ未取得のままの利用は、単なる「利用ルール違反」ではなく、監査不能、データ保護境界の逸脱、未承認外部連携、コスト管理外化、本番変更リスクにつながります。

想定すべき被害は次の通りです。

この中で特に厄介なのは、本人に悪意がないケースです。

たとえば、会社のClaudeアカウントの利用枠が尽きたので、作業を続けるために個人アカウントへ切り替える。あるいは、便利そうなMCPを見つけたので個人環境に追加する。こうした行為は、本人から見ると業務を進めるための工夫かもしれません。しかし企業から見ると、監査・コスト・データ保護・権限管理の境界をすり抜ける行為になります。

したがって、企業は「悪意ある回避」だけでなく、「善意の抜け道利用」も前提にして設計する必要があります。

6-7. 組織の整備状況別ベストプラクティス

Claude Codeの統制は、すべての会社で同じ形にすればよいわけではありません。MDMがあるか、ユーザーにローカル管理者権限があるか、対象が正社員だけか外部委託を含むか、扱うコードやデータの機密性が高いかで、現実的な対策は変わります。

ポイントは、技術統制とトレーニングのどちらか一方ではなく、組織成熟度に応じて組み合わせることです。

MDMがない会社で、いきなり大企業並みの強制統制を作ろうとしても運用に乗りません。一方で、MDMがあり、機密性の高いコードを扱っている会社が「利用者教育だけ」で済ませるのも不十分です。

特に、アカウント切り替えとコスト枯渇への対処は、次のように分けるとよいです。

企業にとって重要なのは、Claude Codeの利用を止めることではありません。むしろ、正しく使えば開発・レビュー・調査・運用自動化の生産性は大きく上がります。だからこそ、利用枠・アカウント・MCP・コスト・ログの逃げ道を放置せず、業務が止まらない正式な受け皿を用意する必要があります。

7. 導入時の最小ガードレール

Claude Codeを企業で配布するなら、最低限次を設計すべきです。

認証

• Claude for Teams / Claude for Enterpriseを使う
• 個人Pro / Max利用を原則禁止する
• SSOを必須化する
• domain captureを検討する
• forceLoginMethod を検討する
• forceLoginOrgUUID を検討する
• SCIM provisioningはEnterprise plansとConsole organizationsで利用できる。Team plansでは利用できない
• Team plans、Enterprise plans、Console organizationsではJIT provisioningを利用できる
• JIT / SCIM provisioningを使う場合は、事前にSSO設定、ドメイン検証、IdP側のAnthropicアプリ設定、ClaudeのOwnerまたはConsoleのAdmin権限を用意する

アカウント切り替え対策

• 会社業務での個人Claudeアカウント利用を禁止する
• 会社アカウントの利用枠不足時に、個人アカウントへ切り替えないことを明文化する
• 利用枠不足時の申請・増枠・API利用・自動化枠の切り分け手順を用意する
• forceLoginOrgUUID を設定し、会社Org以外でのログインを防ぐ
• forceLoginMethod を設定し、認証方式を統制する
• MDMがある場合は、OS-level policyでログイン制御を配布する
• MDMがない場合は、server-managed settingsまたはfile-based managed settingsを使い、定期監査で補う
• sudo/admin権限を持つユーザーがいる場合は、設定変更検知、MDM再適用、EDR / SIEM連携を組み合わせる
• 個人API key、個人Console、個人Bedrock / Vertex / Foundry資格情報の業務利用も禁止または申請制にする
• 高利用ユーザーは制限する前に、業務上必要な利用なのか、使い方の改善で減らせるのかをレビューする

permissions

• .env、.env.*、secrets/** のReadをdeny
• ~/.ssh/** のReadをdeny
• sudo、rm -rf をdeny
• git push --force をdenyまたはask
• curl、wget 等の外部送信系をaskまたはdeny
• test / lint / buildはallow
• allowManagedPermissionRulesOnly は段階導入
• Starter Kit側のdenyを棚卸しし、必要なものをmanagedへ昇格

hooks

• Safety Net相当をmanaged hook化する
• PreToolUseで危険コマンドを検査
• ConfigChangeで設定変更を監査
• PostToolUseで重要操作を記録
• allowManagedHooksOnly は段階導入
• ユーザーhookをいきなり全遮断しない

MCP

• 初期PoCではMCPを原則禁止
• 必要なMCPだけ承認制にする
• allowedMcpServers を使う
• 高セキュリティ環境では managed-mcp.json を検討
• allowManagedMcpServersOnly を段階導入
• Google Drive / Slack / Notion / GitHub等はデータ分類ごとに許可範囲を決める
• MCP利用ログを取得する

plugin / marketplace

• 未承認marketplaceを許可しない
• strictKnownMarketplaces を検討する
• blockedMarketplaces を設定する
• 将来的にStarter Kitを社内plugin marketplace化する
• strictPluginOnlyCustomization は既存運用への影響を確認してから導入する

ログ

• OpenTelemetryを有効化する
• Claude Code活動そのものの監視はOpenTelemetry / Claude Code Analytics APIで設計する
• Compliance API / audit logsはserver-managed settingsの設定変更など管理イベントの監査に使い、prompt、tool呼び出し、編集内容の監視手段として扱わない
• Audit logsはEnterprise organizationsのみ、保持180日、メタデータ中心であることを前提にする
• user / team / repo / model / token / cost / tool / MCPを取得する
• prompt本文やraw API bodyは原則取得しない
• SIEM連携する場合はログ自体の機密性を評価する
• ログ保持期間を定める

コスト

• Team / Enterpriseのusageを確認する
• 部門別・チーム別に利用量を見える化する
• API利用とサブスクリプション利用を分けて管理する
• PoC期間中に1人あたりの利用量を測定する
• MCPや自動化で想定外のコストが出ないようにする

利用規程

• 個人アカウント利用禁止
• 機密データ入力ルール
• MCP追加申請フロー
• 本番環境操作禁止
• 生成コードレビュー必須
• ライセンス・著作権確認
• セキュリティレビュー手順
• インシデント時の停止手順

8. 導入ステップ

Step 1：情シス・セキュリティ部門で検証

まずは小さく検証します。

確認すべき項目は次の通りです。

• 認証方式
• SSO
• domain capture
• managed settings
• server-managed settings
• MDM / OS-level policy
• permissions
• hooks
• MCP制御
• OTel
• Starter Kitの構成
• Windows / WSL / macOSの挙動

この段階ではStarter KitはMinimalまたはStandardで十分ですが、Fullとの違いも確認するのをお勧めします。

Step 2：開発チームで限定PoC

次に、1〜3チームでPoCします。

• 対象リポジトリを限定
• MCPは原則禁止
• permissionsは緩めから開始
• hooksはログ中心
• OTelで利用状況を取る
• Starter Kit Standardを配る
• 2〜4週間で効果・リスク・コストを評価

この段階で、Starter Kitのどの機能が実務に効くかを確認します。

Step 3：Starter Kitの社内版を作る

PoC結果をもとに、Starter Kitを社内向けに調整します。

• 不要なagentを削る
• 必要な社内agentを追加
• security-reviewerを社内基準に合わせる
• /handover や /verify を社内運用に合わせる
• rulesに社内コーディング規約を追加
• MCP利用ルールをdocsに追加
• hooksをmanaged化するものとuser層に残すものに分ける

Step 4：managed settingsで統制する

次に、公式管理機能で統制します。

• 重要denyをmanaged settingsへ昇格
• forceLoginOrgUUID を設定
• MCP allowlistを設定
• hooksをmanaged化
• OTelを有効化
• forceRemoteSettingsRefresh を検討
• requiredMinimumVersion を設定
• 必要に応じてsandboxを有効化

Step 5：段階的に展開する

最後に、対象を広げます。

• 先行チーム
• 開発部門全体
• SRE / Security / Platformチーム
• データエンジニア
• 必要に応じて非開発部門

ただし、Claude Codeは全社員に配るべきツールとは限りません。

非エンジニアには、Claude.ai、Claude for Enterprise、社内AIポータル、Claude Desktopなどの方が適している場合があります。

9. よくある誤解

誤解1：Starter Kitを入れれば企業統制できる

できません。

Starter Kitは標準環境を配るものです。企業統制にはmanaged settings、SSO、MCP制御、OTel、MDMが必要です。

誤解2：server-managed settingsがあればMDMは不要

必ずしもそうではありません。

server-managed settingsは中央配信に優れています。しかし、管理対象端末での改ざん耐性という意味では、MDM / OS-level policyやsystem-level file-based settingsの方が強い場合があります。

高セキュリティ環境では、server-managed settingsだけでなく、MDM、EDR、DLP、SIEMも組み合わせるべきです。

誤解3：permissionsでWebFetchをdenyすれば外部通信は止まる

不十分です。

Bashが許可されていれば、curl、wget、各種CLIで外部通信できます。外部通信を本当に制御したい場合は、permissions、hooks、sandbox、EDR、ネットワーク制御を組み合わせる必要があります。

誤解4：MCPは便利なので自由に使わせてよい

企業では危険です。

MCPは社内データや外部SaaSと接続できるため、自由追加を許すとデータ流出リスクになります。承認済みMCPだけを使わせ、ログを取る設計が必要です。

誤解5：promptに「危険なことをしないで」と書けば十分

不十分です。

CLAUDE.mdやrulesは重要ですが、強制力はありません。企業統制では、prompt上のお願いではなく、permissions、hooks、managed settings、sandboxによる実行時制御が必要です。

10. まとめ

Claude Codeを企業に配布するなら、次の考え方が基本です。

道具はStarter Kitで配り、境界線はmanaged settingsで強制する。

Starter Kitは、これからの開発者にとって非常に有用です。agents、commands、skills、rules、hooksをまとめて配ることで、Claude Codeを実務で使いやすい標準環境にできます。

しかし、Starter Kitだけでは企業統制にはなりません。~/.claude はユーザー領域であり、開発者が編集・削除できます。

企業として外せない境界線は、Claude Code公式のmanaged settingsに置く必要があります。

特に重要なのは次の点です。

• 個人アカウント利用を避け、Team / Enterpriseに寄せる
• SSO、domain capture、JIT / SCIM provisioningの適用条件を整理する
• Audit logs / Compliance API / ZDRはEnterprise前提の機能として扱い、Team planで代替できる前提にしない
• Claude Codeのセッション監視はCompliance APIではなくOpenTelemetry / Analyticsで設計する
• ZDRは標準Enterprise機能ではなく、qualified accounts向けの個別有効化機能として扱う
• 重要なdenyルールはmanaged settingsへ昇格する
• allowManagedPermissionRulesOnly 有効時はStarter Kit側permission rulesが効かない前提で設計する
• 必須hookはmanaged hook化する
• MCPは自由追加させず、承認制にする
• server-managed settingsとMDM/OS-level policyの違いを理解する
• 高セキュリティ環境ではMDM / EDR / DLP / SIEMと組み合わせる
• Starter Kitは社内標準版として整備する
• 将来的には社内plugin marketplace化を検討する

Claude Codeは強力なツールです。だからこそ、自由に配るのではなく、正しく配る必要があります。

Starter Kitは「全社で同じ良い道具を配る」ための仕組みです。managed settingsは「全社で同じ最低ラインを守らせる」ための仕組みです。

この2つを混同せず、組み合わせて使うことが、Claude Codeを安全に、かつ最大限活用するための基本設計です。

この記事の内容でイベント登壇しますので、よろしければお越し下さい。先着50名です。

AI活用・導入の壁と越え方 ― シャドーAI、ガバナンス、コスト、セキュリティの壁【情シスの本音トーク】 | イベント | 株式会社クラウドネイティブ 情シス／コーポレートITの現場目線で、AI活用を阻む4つの壁（シャドーAI／ガバナンス／コスト／セキュリティ）への向き合い方を、クラウドネイティブ・マネーフォワードi・パソナの3社が実体験ベースで本音で語るオフラインイベント。@南青山 PASONA SQUARE。 https://cloudnative.co.jp/events/20260729/

参照情報

一次情報：Anthropic / Claude Code公式

• Claude Code settings
• Claude Code authentication / IAM
• Configure server-managed settings
• Create and distribute a plugin marketplace
• Set up JIT or SCIM provisioning
• How SCIM sync works for Enterprise organizations
• Access audit logs
• Compliance API
• Get access to the Compliance API
• Zero data retention
• API and data retention
• Claude Code Analytics API
• Data usage

一次情報：リポジトリ

• cloudnative-co/claude-code-starter-kit