AIエージェント入門 第八章(前編)!Claude Codeを全社展開する前に管理者が押さえておきたい組織運用のポイント
第一章〜第七章では、Claude Code・Cursor・Antigravity の機能を比較してきました。ここからは視点を変えて、組織の管理者として AI エージェントツールをどう安全に運用するか に焦点を当てます。
第八章の前編では Claude Code を取り上げます。「managed-settings.json って何?」「権限をどう絞ればいい?」「MCP サーバーの野良追加をどう防ぐ?」といった、管理者が実際にぶつかる疑問に答えていきます。
まずはチェックリストで全体像を把握して、気になる項目から詳細セクションに飛んでもらう、という読み方がおすすめです。
⚠️ 本記事は、筆者がこれから Claude Code を組織で管理するために事前学習した内容をまとめたものです。実環境での検証を経ていない、公式ドキュメントや調査ベースの記述も含まれます。実運用で気付いた点があれば随時更新します。
管理者向け「知っておいた方が良さそうなこと」リスト
①最低限やるべきこと
- Spend Limit を設定する
- 組織外アカウントの利用を防ぐ
- 機密ファイルの読み取りをブロックする
- 使える MCP サーバーをコントロールする
- ポリシー未適用なら起動させない
②セキュリティを強化するなら
- 権限をコントロールする
- 権限モードを決める
- 実行環境を隔離する
- MCP サーバーのコントロール
- プラグイン・エージェント・スキル・フック・MCP・チャネルを安全に配布する
- プラグイン経由(推奨)
- ファイル配置
- 配布のロックダウン
- 自律稼働をコントロールする
- 自律稼働モードを禁止する
- フックの制限
- リモート・チャネルをコントロールする
③コストと運用を最適化するなら
- コストの目安
- コストの確認方法
- 総額を把握する
- 誰が使っているかを把握する
- 異常検知
- トークンをコントロールする
- トークンを節約する設定
- Rate Limit(瞬間の利用速度上限)
④運用を監視・監査する
- デフォルトで取れるログ
- 操作ログを取得する
- リアルタイムで利用状況を観測する
- 設定変更履歴を追跡する
以下、各セクションで詳細を解説していきます。
設定の階層を理解する
すべてのセクションの前提となる知識です。Claude Code の設定には 優先順位 があり、上の行ほど強い設定です。
| 設定箇所 | スコープ(影響範囲) | 適用方法 |
|---|---|---|
| Claude.ai 管理コンソール | 組織の全ユーザー(最高優先) | 管理画面で保存すると自動配信(Teams / Enterprise) |
| MDM ポリシー | デバイス上の全ユーザー | 本記事では割愛(管理コンソールからの配信が優先されるため。配布方法が異なるだけで設定できる内容は同じ。詳細は公式ドキュメント参照) |
managed-settings.json | デバイス上の全ユーザー | システムディレクトリにファイルを手動配置 |
~/.claude/settings.json | 自分のみ(全プロジェクト共通) | 手動でファイル編集 |
.claude/settings.json | リポジトリの全コラボレーター | Git リポジトリに含めてチームで共有 |
.claude/settings.local.json | 自分のみ(このプロジェクトのみ) | 手動でファイル編集(gitignore 対象) |
managed settings とは
上の表の上3行(管理コンソール・MDM・managed-settings.json)を総称して managed settings と呼びます(公式ドキュメントでも同じ用語)。ユーザーやプロジェクトの設定では上書きできないため、組織のセキュリティポリシーはここに置けば利用者が勝手に緩めることはできません。ただし PC の管理者権限を持つユーザーはファイルを直接編集できるため、より堅牢な保護が必要な場合は MDM や管理コンソールからの配信を使います。
管理コンソールからの配信
管理コンソール(Admin Settings → Claude Code → Managed settings)から JSON を入力するだけで、組織内の全ユーザーの Claude Code に設定が自動配信されます(現在パブリックベータ)。Claude for Teams と Claude for Enterprise で利用可能で、MDM を導入していない組織やアンマネージドデバイスの管理に向いています。クライアントは起動時と1時間ごとに設定をポーリングし、ネットワーク障害時はキャッシュされた設定が適用されます。
注意点として、管理コンソールからの配信は現時点で 全ユーザーに一律適用 され、グループ単位の設定分けには非対応です。また MCP サーバー設定(managed-mcp.json 相当)は管理コンソールからの配信に未対応なので、MCP の管理はファイルベースで行う必要があります。
managed-settings.json での適用
ファイルベースの配置先はこちらです。
| OS | パス |
|---|---|
| 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/ ディレクトリに複数の JSON ファイルを置いて、設定ファイルの管理責任を分割 できます。最終的にすべてのファイルがマージされて1つの設定として全ユーザーに適用されますが、ファイルを分けることで「1つの JSON を複数チームで奪い合う」問題を避けられます。
/etc/claude-code/
├── managed-settings.json # ベース設定
└── managed-settings.d/
├── 10-telemetry.json # テレメトリチームの設定
├── 20-security.json # セキュリティチームの設定
└── 30-platform.json # プラットフォームチームの設定
managed-settings.json がベースとしてまずマージされ、managed-settings.d/ 内のファイルがアルファベット順に上書きマージされます。この例では 30-platform.json が最も後に読まれるため、同じ設定キーが複数ファイルにある場合は 30-platform.json の値が優先されます(配列値は全ファイル分が結合されます)。
参考リンク
①最低限やるべきこと
Spend Limit を設定する
想定外の利用量で請求が跳ね上がる事故を防ぐため、Claude Console(platform.claude.com)の Workspace → Limits で Spend Limit(月のコスト上限)と Spend Notifications(事前アラート)を設定します。
- Spend Limit: 月の上限額(USD)到達で API リクエスト拒否(事故防止のハードリミット)
- Spend Notifications: 設定額に達したら管理者にメール通知(上限到達前の事前警告)
料金を API レートで支払うプラン(API PAYG・Team・Enterprise)が対象です。Pro / Max は月額固定なので不要。
組織外アカウントの利用を防ぐ
組織の UUID を指定するだけで、組織外のアカウントでの Claude Code 利用を完全にブロックできます。配列で複数の UUID を指定することもできます。設定が簡単な割にセキュリティ効果が高く、最初に入れるべき設定です。
{
"forceLoginOrgUUID": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}
機密ファイルの読み取りをブロックする
permissions.deny で機密ファイル(.env・secrets/・認証情報)の読み取りと、curl / wget による外部通信をブロックします。評価順序は deny → ask → allow で、deny が最優先です。
{
"permissions": {
"defaultMode": "acceptEdits",
"deny": [
"Bash(curl *)",
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)"
]
}
}
使える MCP サーバーをコントロールする
最も厳格な MCP 制御方法です。managed-mcp.json を managed-settings.json と同じシステムディレクトリ(「設定の階層を理解する」セクションの OS 別パス表を参照)に配置すると、このファイルに定義したサーバー以外はユーザーが一切追加できなくなります。組織として使ってよい MCP サーバーを完全に固定したい場合に使います。
ファイル形式は通常の MCP サーバー設定と同じです。
サンプル(managed-mcp.json の中身):
{
"mcpServers": {
"github": {
"type": "http",
"url": "https://api.githubcopilot.com/mcp/"
},
"company-internal": {
"type": "http",
"url": "https://mcp.internal.corp/"
}
}
}
個別のサーバーを明示的に禁止したい場合は、②の「MCP サーバーの制御」で解説する deniedMcpServers を使います。
ポリシー未適用なら起動させない
forceRemoteSettingsRefresh を有効にすると、管理コンソールからの配信を使っている場合に CLI 起動時に最新のポリシーをサーバーから取得し、取得に失敗したら Claude Code 自体の起動を拒否 します。ネットワーク障害などで一時的にポリシーが取得できない場合に、「ポリシーなしで動いてしまう」ことを防ぐための設定です。⚠️ このキーは managed settings でしか効きません。
{
"forceRemoteSettingsRefresh": true
}
②セキュリティを強化するなら
権限をコントロールする
権限モードを決める
permissionMode は、Claude Code がファイル編集やコマンド実行などの操作をするときに ユーザーに毎回確認するか、自動で進めるか を決めるセッション全体のモードです。permissions.defaultMode で組織のデフォルトを指定できます。
| モード | 動作 | 使いどころ |
|---|---|---|
default | 標準の権限チェック(毎回確認) | 初期導入時、セキュリティ重視 |
acceptEdits | ファイル編集は自動承認 | 信頼できるプロジェクトでの通常作業 |
auto | AI 分類器が安全性を判断して自動承認 | 中級者向け、バランス重視 |
plan | 読み取り専用 | コードレビュー、調査 |
dontAsk | 権限プロンプトを自動拒否 | スキル実行時の安全モード |
bypassPermissions | すべての権限チェックをスキップ | CI/CD 無人実行(要注意) |
組織のデフォルトは permissions.defaultMode で指定します。
{
"permissions": {
"defaultMode": "default"
}
}
なお、bypassPermissions(すべての権限チェックをスキップ)や auto(AI 分類器の判断で自動承認)のような自律稼働モード自体を組織として禁止したい場合は、「自律稼働を制御する」セクションで解説します。
加えて、allowManagedPermissionRulesOnly: true を managed settings に設定すると、個別の権限ルール(allow / ask / deny)も管理者に集中させることができます。⚠️ このキーは managed settings に書いた場合のみ有効 で、ユーザーやプロジェクトの settings.json で書いた権限ルールは無視されます。
{
"allowManagedPermissionRulesOnly": true
}
実行環境を隔離する
Claude Code にはファイルシステムとネットワークを分離する サンドボックス 機能があります(macOS / Linux / WSL2 対応。Windows ネイティブは非対応)。
{
"sandbox": {
"enabled": true,
"failIfUnavailable": true,
"filesystem": {
"denyRead": ["~/.aws/credentials", "~/.ssh/"],
"allowWrite": ["/tmp/build"],
"allowManagedReadPathsOnly": true
},
"network": {
"allowedDomains": ["github.com", "*.npmjs.org"],
"allowManagedDomainsOnly": true
}
}
}
failIfUnavailable: true でサンドボックスが起動できない環境では Claude Code 自体の起動を拒否します。sandbox.filesystem.allowManagedReadPathsOnly と sandbox.network.allowManagedDomainsOnly は ⚠️ managed settings でしか効かないキー です。
MCP サーバーのコントロール
MCP サーバーの制御方法は大きく2つあり、用途に応じて使い分けます。
① 使えるサーバーを固定する(managed-mcp.json)
最も厳格な方法で、managed-mcp.json で使えるサーバーを完全に固定します。設定方法は ①の「使える MCP サーバーを固定する」で解説済みのため、そちらを参照してください。
② 許可/拒否リストでコントロールする
ユーザーが独自に MCP サーバーを追加できる前提で、許可/拒否のポリシーを適用する柔軟な方法です。managed-settings.json に記述します。
allowedMcpServers— 許可するサーバーのリストdeniedMcpServers— 拒否するサーバーのリストallowManagedMcpServersOnly: true— managed settings の許可リストのみを有効にする(⚠️ managed settings のみ)
サンプル(managed-settings.json に記述):
{
"allowedMcpServers": [
{ "serverName": "github" },
{ "serverUrl": "https://*.internal.corp/*" }
],
"allowManagedMcpServersOnly": true
}
参考リンク
プラグイン・エージェント・スキル・フック・MCP・チャネルを安全に配布する
配布方法は大きく2つあります。
| パターン | 何を配布できるか | やり方 |
|---|---|---|
| プラグイン経由 | スキル・エージェント・フック・MCP・チャネル(Telegram / Discord / iMessage 等)をまとめて | プラグインと Marketplace を Git リポジトリに置き、managed-settings.json で配布設定 |
| ファイル配置 | スキル・エージェント・フック・MCP | 組織全体なら managed-mcp.json(①で解説済み)を含むシステムディレクトリに、プロジェクト単位なら .claude/ や .mcp.json を Git リポジトリに含める |
複数コンポーネントをまとめて配布するなら プラグイン経由、単体を手軽に配布するなら ファイル配置 が向いています。なお、チャネルは プラグインとして実装される ので配布経路はプラグインと同じです。利用制限(どのチャネルプラグインを許可するか)は後述の「リモート・チャネルをコントロールする」で解説します。
① プラグイン経由(推奨)
スキル・エージェント・フック・MCP サーバーをまとめて配布できる最も汎用的な方法です。以下の3ステップで進めます。
1. プラグインを作る
配布したいコンポーネントを1つのディレクトリにまとめます(第六章で解説したプラグイン構造)。
my-plugin/
├── .claude-plugin/
│ └── plugin.json # {"name": "my-plugin", "version": "1.0.0"}
├── skills/
│ └── security-review/
│ └── SKILL.md
├── agents/
│ └── code-reviewer.md
└── hooks/
└── hooks.json
2. Marketplace を作る
プラグインを含む Git リポジトリのルートに .claude-plugin/marketplace.json を作成します。このファイルが Marketplace の定義になります。
your-org/claude-plugins/ # GitHub リポジトリ
├── .claude-plugin/
│ └── marketplace.json # ← これが Marketplace の定義
└── my-plugin/ # ← ステップ1で作ったプラグイン
├── .claude-plugin/
│ └── plugin.json
├── skills/
├── agents/
└── hooks/
marketplace.json の中身:
{
"name": "company-tools",
"owner": { "name": "DevTools Team" },
"plugins": [
{ "name": "my-plugin", "source": "./my-plugin" }
]
}
3. managed-settings.json で全員に配布する
extraKnownMarketplaces で Marketplace を登録し、enabledPlugins でプラグインを自動有効化します。
{
"extraKnownMarketplaces": {
"company-tools": {
"source": {
"source": "github",
"repo": "your-org/claude-plugins"
}
}
},
"enabledPlugins": {
"my-plugin@company-tools": true
}
}
これで組織の全ユーザーに、プラグイン内のスキル・エージェント・フック・MCP サーバー・チャネルがまとめて配布されます。
② ファイル配置
プラグインを作らなくても、エージェント定義ファイル・スキルのフォルダ・フック定義・MCP サーバー定義を直接配置することで配布できます。配置先によって配布範囲が変わります。
組織全体に配布する場合
managed-settings.json と同じシステムディレクトリに配置します。これらは managed settings に属する設定として扱われ、ユーザーやプロジェクトに同名のエントリがあっても上書きされません。
- エージェント・スキル:
.claude/agents/や.claude/skills/にファイルを配置 - フック:
managed-settings.jsonのhooksセクションに JSON で記述 - MCP サーバー:
managed-mcp.jsonに記述(①の「使える MCP サーバーを固定する」で解説済み)
/Library/Application Support/ClaudeCode/ # macOS の例
├── managed-settings.json # 組織ポリシー(フックもここに記述)
├── managed-settings.d/ # ポリシー分割管理
├── managed-mcp.json # MCP 排他制御
└── .claude/
├── agents/
│ └── security-reviewer.md # managed エージェント
└── skills/
└── code-review/
└── SKILL.md # managed スキル
managed-settings.json でフックを配布する場合の例:
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{ "type": "command", "command": "/usr/local/bin/auto-format.sh" }
]
}
]
}
}
プロジェクト単位で共有する場合
プロジェクトルートの .claude/ 配下にファイルを配置し、Git リポジトリに含めます。リポジトリを clone したメンバー全員が、そのプロジェクト内でエージェント/スキル/フック/MCP サーバーを使えるようになります。
- エージェント・スキル:
.claude/agents/や.claude/skills/にファイルを配置 - フック:
.claude/settings.jsonのhooksセクションに JSON で記述 - MCP サーバー: プロジェクトルートの
.mcp.jsonに記述
my-project/ # Git リポジトリ
├── .mcp.json # プロジェクト専用 MCP サーバー
├── .claude/
│ ├── settings.json # フックはここに記述
│ ├── agents/
│ │ └── reviewer.md # プロジェクト専用エージェント
│ └── skills/
│ └── project-setup/
│ └── SKILL.md # プロジェクト専用スキル
├── src/
└── README.md
組織全体で使わせたい場合は前者、特定プロジェクトのチーム内だけで共有したい場合は後者、という使い分けです。
配布のロックダウン
strictKnownMarketplaces でユーザーが追加できる Marketplace を制限できます(⚠️ managed settings のみ)。
| 値 | 動作 |
|---|---|
| 未設定 | 制限なし |
[](空配列) | 完全ロックダウン |
| ソースの配列 | 一致する Marketplace のみ追加可能 |
{
"strictKnownMarketplaces": [
{
"source": "hostPattern",
"hostPattern": "^github\\.example\\.com$"
}
]
}
特定の Marketplace をブロックするには blockedMarketplaces(⚠️ managed settings のみ)、信頼メッセージのカスタマイズは pluginTrustMessage(⚠️ managed settings のみ)を使います。
参考リンク
自律稼働をコントロールする
自律稼働モードを禁止する
Claude Code には、利用者の確認なしで操作が進む 自律稼働モード が2つあります。
bypassPermissions— すべての権限チェックを スキップ します。確認なしで何でも実行する、最もAIに頼るモードで、その分、信頼できる環境以外で使うのはリスクが高いですauto— AI 分類器が各ツール呼び出しを評価し、安全と判断したものは自動承認、危険と判断したら従来どおり人間に確認 します。利便性と安全性のバランスを取るモードです
これらを組織として禁止したい場合、以下の設定を使います。
disableBypassPermissionsMode: "disable"—bypassPermissionsモードを完全禁止。--dangerously-skip-permissionsフラグも無効化されるdisableAutoMode: "disable"—autoモードを禁止。Shift+Tab のサイクルからも除外される
{
"permissions": {
"disableBypassPermissionsMode": "disable"
},
"disableAutoMode": "disable"
}
これらはどのスコープでも書けますが、managed settings に置けば利用者に上書きされません。
フックの制限
| 設定キー | 効果 | スコープ制限 |
|---|---|---|
allowManagedHooksOnly: true | ユーザー・プロジェクト・プラグインのフックをすべて無効化し、managed hooks のみ許可 | ⚠️ managed settings のみ |
disableAllHooks: true | すべてのフックを無効化 | どこでも書ける |
allowedHttpHookUrls | HTTP フックの送信先を許可リストで制限 | どこでも書ける |
httpHookAllowedEnvVars | HTTP フックが参照できる環境変数を制限 | どこでも書ける |
{
"allowManagedHooksOnly": true,
"allowedHttpHookUrls": ["https://audit.internal.corp/*"],
"httpHookAllowedEnvVars": ["AUDIT_TOKEN"]
}
参考リンク
リモート・チャネルをコントロールする
Claude Code はローカル CLI だけでなく、Web(claude.ai/code)や外部サービス経由でも実行できます。なかでも チャネル(Channels)は、Telegram・Discord・iMessage などの外部チャットツールから Claude Code のローカルセッションにメッセージや Webhook を push して、Claude にリアクションさせる仕組みです。たとえば外出中に Telegram でメッセージを送ると、起動中の Claude Code がそれを受け取って作業を進め、結果を Telegram に返してくれます。
なお、Slack 連携は別機能の「Claude in Slack」で、@Claude メンションでクラウド側に新しいセッションを起動するものです。Channels(既存のローカルセッションに push)とは別物です。
便利な一方で、外部サービスから自社コードベースへの入口が増える ことを意味します。悪意ある第三者が Telegram などのチャネル経由で不正な指示を送ったり、不審なチャネルプラグインが組織に導入されたりするリスクがあるため、管理者は「どのチャネルを許可するか」を明示的に制御する必要があります。
チャネルはプラグインとして実装されているため、配布自体は「プラグイン経由で配布する」で解説したのと同じ仕組み で行われます。このセクションで解説するのは配布後の 利用制限 です。
{
"channelsEnabled": true,
"allowedChannelPlugins": [
{ "marketplace": "claude-plugins-official", "plugin": "telegram" },
{ "marketplace": "claude-plugins-official", "plugin": "discord" }
]
}
channelsEnabled が false(デフォルト)ならチャネルメッセージはブロックされます。有効にする場合は allowedChannelPlugins で許可するチャネルを明示的に限定してください。⚠️ channelsEnabled と allowedChannelPlugins は managed settings でしか効きません。
参考リンク
③コストと運用を最適化するなら
コストの目安
以下は API PAYG(従量課金)契約と、Team / Enterprise プランでシート費に含まれない追加利用分 に該当する話です。Pro / Max などの個人サブスクリプションは月額固定でトークン消費量に関わらず料金が変わらないため、このセクションの内容は該当しません。
Claude Code はトークン消費に応じて API レートで課金されます。モデル選択やサブエージェントの並列実行で大きく変動するため、パイロットグループで実測してから全社展開するのが公式の推奨です。
参考リンク
- Manage costs effectively — Claude Code Docs(パイロット展開の推奨)
- How am I billed for my Enterprise plan? — Help Center(Enterprise プランでもトークン消費分は API レートで請求される根拠)
コストの確認方法
Claude Code のコスト・利用状況を確認する手段は複数あります — Console の Usage / Cost ページ、Analytics Dashboard、CLI の /cost コマンド、Usage and Cost API、Claude Code Analytics API、OpenTelemetry。それぞれ見られる内容や粒度が異なりますが、組織のコスト管理という観点では、以下の3軸を押さえれば十分です。
① 総額を把握する
platform.claude.com の Workspace → Cost で、月次のトークンコストを確認できます。
- トークンコスト(モデル別、日別グラフ)
- Web 検索コスト
- Code execution コスト
- Workspace / API キー / モデル / 月で絞り込み・CSV エクスポート可
API PAYG・Team・Enterprise はいずれも、トークン消費分が API レートで請求される仕組みのため、このページで請求書ベースの月次総額を確認します。Pro / Max(個人サブスク)は月額固定なのでこの確認は不要です。
② 誰が使っているかを把握する
platform.claude.com/claude-code で、メンバー別の利用状況とコストを確認できます(Developer / Billing / Admin / Owner / Primary Owner ロールで閲覧可)。
- メンバー別の月次 Spend / コード行数(Team insights テーブル)
- コード受入行数・Suggestion 受入率
- Activity(DAU / セッション数の日別推移)
- Spend 日別推移
「誰がどれくらい使っているか」を見られる Console 画面です。部門別に切り分けたい場合は Workspace を部門ごとに作成しておくと、Cost ページでも部門別に分離して見られます。
なお、Team / Enterprise プランは別途 claude.ai/analytics/claude-code でも PR 数・Adoption・Leaderboard などの貢献度メトリクスを確認できます(コスト情報はないが、使われていない席を発見するのに有用)。
③ 異常検知
コストの急騰を検知・抑止する Spend Limit / Spend Notifications は ①の「Spend Limit を設定する」で解説済みのため、そちらを参照してください。
さらにリアルタイムでメトリクスを観測ツール(Datadog・Grafana 等)に流して、任意の条件でアラートを出したい場合は OpenTelemetry(④で詳述)が選択肢になります。
参考リンク
- Cost and Usage Reporting in the Claude Console — Help Center
- Track team usage with analytics — Claude Code Docs
- Rate limits — Claude API Docs(Spend limits セクション)
トークンをコントロールする
トークンを節約する設定
コストは「使うモデル × 1リクエストあたりのトークン量 × リクエスト回数」で決まります。上限を設定するだけでなく、そもそもの消費を減らす設定を組織のデフォルトに入れておくとコストが安定します。
まずは managed-settings.json で設定できる3つのキーです。
| 設定 | 効果 |
|---|---|
availableModels: ["sonnet", "haiku"] | Opus を除外してコストを抑える |
effortLevel: "medium" | Claude の「考える深さ」のデフォルトを中程度に |
fastModePerSessionOptIn: true | Fast モードをセッション単位のオプトインに |
Fast モードは Opus の応答を高速化する代わりに追加コストがかかるモードで、デフォルトでは一度 ON にすると次のセッションでも自動的に ON のまま引き継がれます。fastModePerSessionOptIn: true にすると 各セッションは必ず Fast モード OFF で開始され、必要なときだけユーザーが /fast で明示的に有効化することになるため、「気付かずずっと Fast モードで動いてコストが膨らむ」を防げます。
次に、運用ガイドラインとしてチームに周知したいポイントです。こちらは設定ではなく運用の工夫ですが、トークン消費への影響が大きいので管理者から共有しておくと効果的です。
- 未使用の MCP サーバーを無効化 — MCP サーバーを追加するたびにツール定義がコンテキストに入るので、使わないものは無効化する
- CLAUDE.md を 200 行以下に保つ — CLAUDE.md はセッション開始時に全文読み込まれるため、肥大化するとすべてのメッセージのコストが上がる
- エージェントチームは小規模に — エージェントチームは通常セッションの約 7 倍のトークンを消費する。チームメイトの数は最小限に
Rate Limit(瞬間の利用速度上限)
Rate Limit を設定する
リクエスト数/分(RPM) と トークン数/分(TPM) をモデルティアごとに設定します。Spend Limit が「月単位で止める」のに対し、Rate Limit は「瞬間的に一部のユーザーがリソースを占有するのを防ぐ」役割です。超過しても一時的にリクエストが拒否されるだけで、待てば回復します。
設定値は Workspace 全体の合計 です。チーム規模別の「1人あたりの目安」が公式ドキュメントの Rate limit recommendations に掲載されているので、これにユーザー数を掛けて Workspace の値とします。大規模組織ほど同時利用率が下がるため、1人あたりの割り当ては減っていきます。
Rate Limit の消費状況を監視する
設定後の実際の消費は、Console の Usage ページ に表示される Rate Limit - Input Tokens / Rate Limit - Output Tokens の専用チャートで可視化されます。毎時の最大消費量・現在の上限値・キャッシュ率が並んで表示されるので、「ピーク時に上限へ近づいているか」「キャッシュを効かせて余裕を作れるか」を判断できます。プログラム的に残量を取りたい場合は、API レスポンスの anthropic-ratelimit-*-remaining ヘッダーから残りリクエスト数・残りトークン数・リセット時刻を取得できます。
参考リンク
- Manage costs effectively — Claude Code Docs
- Rate limits — Claude API Docs(Console のレート制限チャート / レスポンスヘッダー)
④運用を監視・監査する
組織として AI エージェントを運用するうえで、「誰が・いつ・何をしたか」を事後に追跡できる仕組みは重要です。コンプライアンス要件がある組織はもちろん、インシデント発生時の調査や、利用者の利用状況の把握にも役立ちます。
デフォルトで取れるログ
まず「何も設定しない状態」で取れるログを整理します。
| ログの種類 | デフォルトで利用可能か | 内容 |
|---|---|---|
| セッショントランスクリプト | ✅(ローカル保存) | 会話の全履歴(JSONL)。cleanupPeriodDays(デフォルト 30日)で保持期間制御 |
| Console の Analytics Dashboard | ✅(設定不要) | ユーザー別のセッション数・コード変更量・ツール受入率・推定コスト |
| 管理コンソールの設定変更ログ | ✅(管理コンソールからの配信利用時に自動) | 管理コンソールでの設定変更履歴 |
| Hooks による操作ログ | ❌(要設定) | ツール呼び出しの詳細(1操作ごと) |
| OpenTelemetry | ❌(要設定) | カスタム監視基盤へのメトリクス・イベント送信 |
以下では、表のうち追加設定や条件付きで取れる3つ(操作ログ・リアルタイム観測・設定変更履歴)について個別に解説します。
操作ログを取得する
PostToolUse フックで、ツール呼び出しの詳細(session_id・tool_name・tool_input・tool_response)を1操作ごとに記録できます。
{
"hooks": {
"PostToolUse": [
{
"hooks": [
{
"type": "command",
"command": "cat >> /var/log/claude-audit.jsonl"
}
]
}
]
}
}
HTTP フックで外部の SIEM やログ基盤に直接送信することもできます。allowManagedHooksOnly: true と組み合わせれば、利用者がこの監査フックを無効化できません。
リアルタイムで利用状況を観測する
OpenTelemetry(OTel)は、アプリの動作データを外部の監視ツールに送るオープンな標準規格です。Claude Code では メトリクス(セッション数・トークン・コスト等の集計)と イベント(プロンプト送信・ツール結果・API リクエストの個別記録)の2種類を出力できます。
{
"env": {
"CLAUDE_CODE_ENABLE_TELEMETRY": "1",
"OTEL_METRICS_EXPORTER": "otlp",
"OTEL_LOGS_EXPORTER": "otlp",
"OTEL_EXPORTER_OTLP_ENDPOINT": "https://otel.internal.corp:4317"
}
}
デフォルトではプロンプト内容やツール入力は記録されません。OTEL_LOG_USER_PROMPTS=1 / OTEL_LOG_TOOL_DETAILS=1 で有効化できますが、機密情報に注意してください。
設定変更履歴を追跡する
管理コンソールでの設定変更は自動的に監査ログに記録されます(compliance API / audit log export で取得)。記録内容: 操作種別・アカウント・デバイス・変更前後の値。ファイルベース(managed-settings.json 手動編集)は対象外です。
参考リンク
まとめ
Claude Code の組織管理は managed settings を中心にした階層設計 が核です。最高優先の managed settings に設定を置けば、ユーザーやプロジェクトから上書きされないため、「利用者が勝手に設定を緩めて事故を起こす」シナリオを構造的に防げます。
個人的に押さえておきたいなと思ったのは以下の3点です。
まずは①の最低限5項目から着手する — Spend Limit で請求事故を防ぎ、
forceLoginOrgUUIDで組織外利用をブロック、permissions.denyで機密ファイルをガード、managed-mcp.jsonで MCP を固定、forceRemoteSettingsRefreshでポリシー未適用時の起動を拒否。どれも managed settings に1行足すだけで効果が大きく、入れ忘れると事故に直結するのでここから環境を絞って fail-closed 運用にする — macOS / Linux / WSL2 では
sandbox.failIfUnavailable: trueでサンドボックス必須化、管理コンソールからの配信を使う場合はforceRemoteSettingsRefresh: trueでポリシー未取得時の起動を拒否。両方を揃えると「安全な状態でないと動かない」組織基盤になります(Windows ネイティブはサンドボックス非対応。Windows 利用者には WSL2 上での利用を案内するか、failIfUnavailableを除外する)監査ログは運用開始時点から仕込む — Hooks による全ツール呼び出しの記録、OpenTelemetry による利用状況の可視化、管理コンソールの設定変更ログの3方式を組み合わせると、「誰が・いつ・何をしたか」を事後に追跡できます。後から入れると過去分が取れないので最初から仕込むのがおすすめ
Claude Code はエンタープライズ向けの管理機能が豊富ですが、全部を一度に設定する必要はありません。まずはチェックリストの「①最低限やるべきこと」から始めて、組織の成熟度に合わせて段階的に強化していくのが現実的かなと思います。