【2026年最新】Claude Code全社ガバナンス｜利用モデルとスキル統制

「Claude Code、開発チーム全員に配ったはいいけど、誰がどのモデル使ってるか分からない」——これ、ここ数ヶ月で一番よく相談される話なんです。あるSaaS開発チーム（バックエンド中心、エンジニア60名規模）で実際に起きたのが、新人が深く考えず全タスクをOpusで回していて、月末のトークン消費が想定の3倍に膨らんでいた、というやつ。さらに別チームでは、誰かがネットで拾ってきたカスタムスキルを .claude/skills/ に置いて、その中の !`...` インラインシェルが社内サーバーで勝手に走っていた、というヒヤリも出ました。

正直、これは「個人のモラルの問題」じゃなくて仕組みの問題です。Claude Code には、こうした事故を管理者側で封じるためのガバナンス設定がちゃんと用意されています。この記事では、私が実際にこのSaaSチームの導入を整理したときの構成をベースに、公式ドキュメントで実在を確認した設定だけを使って「全社統制の最小セット」を組み立てます。

1. なぜ「個人設定」ではガバナンスが効かないのか

最初にハマるのがここ。Claude Code の設定には階層があって、~/.claude/settings.json（ユーザー）や .claude/settings.json（プロジェクト）は、本人が自由に書き換えられます。つまり「全員これ使ってね」とSlackで配っても、守らない人は守らない。ガバナンスとして成立しません。

これを解決するのが managed settings（管理者設定） です。OS の保護されたディレクトリに置く設定で、ユーザーは上書きできません。配置先は公式ドキュメントに明記されています。

OS	managed-settings.json のパス
macOS	/Library/Application Support/ClaudeCode/managed-settings.json
Linux / WSL	/etc/claude-code/managed-settings.json
Windows	C:\Program Files\ClaudeCode\managed-settings.json

補足として、ディレクトリ形式（managed-settings.d/）で分割配置もできます。MDM（Jamf や Intune）でこのファイルを各端末に配布すれば、開発者が vi で開いて書き換える余地のない、本物の全社ポリシーになります。なお Windows の旧パス C:\ProgramData\ClaudeCode\managed-settings.json は v2.1.75 以降サポート外になっているので、古い手順書をコピペしている場合は要注意です。

現場メモ： 「とりあえずプロジェクトの .claude/settings.json にガバナンス書いとけばいいでしょ」が一番やりがちな失敗。それは .gitignore も git pull も効く”提案”であって、”強制”ではありません。強制したい行は managed settings、共有したい便利設定はプロジェクト settings、と役割を分けます。

2. 利用モデルを全社でロックする（availableModels）

冒頭の「全部Opusで予算3倍」を防ぐ核がこれ。availableModels は、ユーザーがメインセッション・サブエージェント・スキル・アドバイザーで選べるモデルを許可リスト方式で制限する設定です。配列で渡します。

{
  "availableModels": ["sonnet", "haiku"]
}

これを managed settings に置くと、開発者は /model で sonnet と haiku しか選べなくなります。「日常のコーディングは Sonnet、軽い整形やコミットメッセージは Haiku、Opus は原則禁止（必要なときは申請制）」という運用を、設定ファイル1行で全社に効かせられるわけです。

使えるエイリアスは公式ドキュメントで定義されていて、主なものは次のとおり。アーキテクチャ設計をした側として、最低限この対応は頭に入れておくと運用設計が早くなります。

エイリアス	用途（公式記載ベース）
sonnet	日々のコーディングタスク向け（最新Sonnet）
haiku	軽量・高速なシンプルタスク向け
opus	複雑な推論タスク向け（最新Opus）
opusplan	プランモード中は opus、実行フェーズで sonnet に切り替わる特別モード
sonnet[1m] / opus[1m]	100万トークンの長尺コンテキスト用

ちなみに Anthropic API 上では opus が Opus 4.8、sonnet が Sonnet 4.6 に解決されます（Bedrock や Vertex では解決先のバージョンが異なるので、クラウドプロバイダー経由の組織はそこも合わせて確認してください）。エイリアスは「推奨バージョンへのポインタ」なので、バージョンを固定したいなら claude-opus-4-8 のようなフルネームを availableModels に書く運用もできます。

「Default」モデルの抜け穴を塞ぐ（enforceAvailableModels）

ここが地味に重要で、一度ハマったポイントです。availableModels だけだと、ユーザーが選ぶ「Default」オプションには制限がかからない場合があります。アカウント種別の推奨モデル（場合によっては Opus）に戻ってしまうんですね。

これを塞ぐのが enforceAvailableModels（v2.1.175 以降）。managed settings でこれを true にし、かつ availableModels が空でない配列のとき、Default オプションも許可リストの先頭の利用可能なモデルにフォールバックします。

{
  "availableModels": ["sonnet", "haiku"],
  "enforceAvailableModels": true
}

この2行セットで初めて「全社Opus禁止」が完成します。availableModels 単体で満足して “Default経由で抜けられる” のが、レビューで一番見落とされがちな穴です。フォールバックや障害時のモデル戻りも含めた可用性設計は、Claude CodeのfallbackModelによる組織レジリエンス設計の事例と合わせて読むと、平常時の統制と障害時の自動切替の両方が繋がります。

3. スキル経由のシェル実行を封じる（disableSkillShellExecution）

もう一つの事故の芽が、冒頭の「拾ってきたスキルがシェルを勝手に実行」問題。Claude Code のスキルやカスタムコマンドは、!`...` やコードブロックの ```! 記法でインラインシェルを実行できます。便利なんですが、出所不明のスキルを入れると、その中の任意コマンドが端末で走るリスクがある。

これを止めるのが disableSkillShellExecution です。

{
  "disableSkillShellExecution": true
}

これを有効にすると、ユーザー・プロジェクト・プラグイン・追加ディレクトリ由来のスキル/コマンドのインラインシェルは実行されず、[shell command execution disabled by policy] に置き換えられます。重要なのは、バンドルスキルとmanagedスキルは影響を受けないこと。つまり「公式・社内承認スキルは動かしつつ、野良スキルのシェルだけ止める」というちょうどいい線引きができます。公式ドキュメントも「managed settings で使うのが最も有効（ユーザーが上書きできないため）」と書いています。

失敗→修正の例：

❌ プロジェクトの settings に "disableSkillShellExecution": true を書いて満足 → 本人が .claude/settings.local.json で上書きして無効化できてしまう。

⭕ managed-settings.json に書く → 上書き不能。野良スキルのシェルだけが確実に封じられ、承認済みスキルは通常どおり動く。

4. 不要なバンドルスキルを丸ごと外す（disableBundledSkills）

「そもそも標準同梱のスキル群を全部いらない」というセキュアな環境（金融・規制業界のクローズドネットワークなど）では、disableBundledSkills が選択肢になります。

{
  "disableBundledSkills": true
}

true にすると、Claude Code に同梱されているスキルとワークフローが丸ごと除去されます。/init のような組み込みスラッシュコマンドは「打てば動くが、モデルからは見えない（自動で使われない）」状態になります。環境変数 CLAUDE_CODE_DISABLE_BUNDLED_SKILLS=1 と同等です。

注意点として、プラグイン・.claude/skills/・.claude/commands/ のスキルはこの設定の影響を受けません。なので「同梱の汎用スキルは消すが、自社で監査済みの社内スキルだけ配る」という、ホワイトリスト型のスキル運用がやりやすくなります。社内スキルを安全に量産・配布する設計は、Claude Codeのスキル自作・配布ガイドの事例が参考になります。

5. 全部まとめた「最小ガバナンスセット」

ここまでの4設定を、実際に SaaS 開発チームの managed-settings.json に入れた構成がこちらです。コメントは説明用なので実ファイルでは外してください（JSON はコメント不可）。

{
  "availableModels": ["sonnet", "haiku"],
  "enforceAvailableModels": true,
  "disableSkillShellExecution": true,
  "disableBundledSkills": false
}

このチームでは disableBundledSkills はあえて false のまま（同梱スキルの利便性を残す判断）にし、代わりに disableSkillShellExecution で危険なシェル実行だけ止めました。「全部禁止」ではなく「リスクの高い経路だけ塞ぐ」という発想です。実装後の実機検証は次の順でやると確実です。

1. 端末に managed-settings.json を配置（MDM 経由が理想）
2. Claude Code を再起動 → /model を開き、opus が選択肢から消えていることを確認
3. Default を選んでも Sonnet にフォールバックすることを確認（enforceAvailableModels が効いている証拠）
4. テスト用に !`echo hello` を含むスキルを .claude/skills/ に置き、実行が [shell command execution disabled by policy] に置換されることを確認

権限（ツール許可）まわりの統制は今回のスコープ外ですが、モデルとスキルを縛ったら次は許可ポリシーです。そこはClaude Codeのチーム向け権限設計ガイドとサンドボックス安全実行の事例を併読すると、モデル・スキル・権限・実行環境の4点が揃います。

6. よくある詰まりどころ（FAQ）

Q. settings.json に書いたのに制限が効きません

ほぼ確実に「ユーザー/プロジェクト settings に書いている」のが原因です。ガバナンス設定は managed settings（前述のOS別パス）に置かないと、本人の上書きで無効化されます。/status でどの設定がアクティブか確認しましょう。

Q. availableModels だけでOpusを禁止できますか？

不完全です。Default 経由で推奨モデルに戻る抜け穴があるため、enforceAvailableModels: true をセットで入れてください（v2.1.175 以降が必要）。

Q. 社内で作った承認済みスキルまで止まってしまいませんか？

disableSkillShellExecution は bundled / managed スキルには影響しません。承認済みスキルを managed 経路で配れば、シェル実行を残したまま野良スキルだけ封じられます。

Q. クラウドプロバイダー（Bedrock/Vertex）経由でも同じですか？

設定キー自体は同じですが、opus / sonnet エイリアスの解決先バージョンがプロバイダーで異なります。バージョン固定が必要なら、フルモデル名（例：claude-opus-4-8）や ANTHROPIC_DEFAULT_OPUS_MODEL 系の環境変数を併用してください。

まとめ：統制してから配る、が事故を最小化する

Claude Code の全社導入は「まず配って、問題が出たら対処」だと、トークン爆発と野良スキル事故の両方を踏みます。先に availableModels + enforceAvailableModels でモデルを縛り、disableSkillShellExecution で危険な実行経路を塞ぎ、必要なら disableBundledSkills でスキル面を絞る。この4設定を managed-settings.json に置くだけで、配布前のガバナンスはほぼ完成します。全部、公式ドキュメントに実在する設定だけで組めるのが安心材料です。

出典：Claude Code 公式ドキュメント（Settings / CLI reference / Model configuration / Authentication）code.claude.com。本記事の設定キー・パス・エイリアスはいずれも公式ドキュメント記載の内容に基づき確認しています。記述時点のバージョン挙動のため、導入前に最新の公式ドキュメントで再確認してください。