Claude Enterpriseの消費管理 — RBACと支出上限の使い方

消費が跳ねる原因は利用形態と権限の初期設定にある

Claude Enterpriseは座席単位・従量課金の混成モデルで、組織のトークン消費プールは全ユーザーで共有されます。Claude CodeとCoworkは通常のチャットより大幅に高いレートでトークンを消費するため、初期設定のまま全員に開放すると想定外の消費が起きやすい構造です。

管理者が触れるレバーは、支出上限・RBAC(役割ベースのアクセス制御)・モデル選択の誘導・ユーザー教育の4つです。以下では、誰にどの利用形態を開けるか、上限をどの単位で置くか、上限に当たったとき何が起きるかを順に扱います。

どの利用形態がトークンを多く使うのか

同じ組織のプールを消費していても、利用形態によって強度は大きく異なります。

Claude for Microsoft 365(Excel・PowerPoint・Word・Outlookアドイン)、Claude Design、Claude in Chromeのサイドパネル(Coworkセッションとして動作)、Claude Tag(Slack内のClaude、ベータ)もそれぞれ別の製品としてAnalyticsや支出エクスポートに現れます。

このうちMicrosoft 365版とDesignは、組織・グループ・ユーザーの支出上限の対象です。Microsoft 365版にはモデル制限も同じく掛かり、Designは標準のAPI単価で組織の消費から課金されます。Claude in Chromeは、Organization settings → Coworkで管理します。

課金先が違うのはClaude Tagです。チャンネルでの作業は個人の座席ではなく組織全体の残高に課金されるため、ユーザー別・グループ別の上限では止められません。上限は claude.ai/admin-settings/usage/claude-tag で、チャンネル別の上限とあわせて別に置きます。DMでの利用は送信者本人のシートに課金されます。

最初のゲートはRBACによる利用形態の制限

RBACは、ユーザーを職務単位でグループ化し、各利用面へのアクセスと消費予算をまとめて扱う仕組みです。グループは組織図ではなく利用パターンで組みます。消費管理では「エンジニアリング」「セールス」のような用途別の方が、「北米」「EMEA」のような地域別より機能します。

グループは4〜6から始め、利用パターンがはっきり分かれたときだけ増やします。8〜10を超えると管理が煩雑になります。システム側の上限は別で、1組織あたり最大1000グループです。所属数に上限はないものの、250を超えると動作が遅くなる場合があります。

制限が効くのは組織ロールがCustomのメンバーだけ

「Claude Codeはエンジニアリンググループだけ」のような制限は、グループに割り当てたカスタムロールで実現します。ただし効くのは組織ロールが「Custom」のメンバーだけです。組み込みの「User」ロールのままのメンバーは、組織で有効な機能をすべて使えます。

Customのメンバーは既定の権限を一切持たず、所属グループのロールから得た権限だけで動きます。グループに入っていない、あるいはグループにロールが付いていないCustomメンバーは、どの製品にも入れず設定ページに着地します。

設定の順番にも落とし穴があります。機能を組織レベルで有効にするのは最後で、手順は次の順序です。

手順

ロールベースの制限を安全に入れる順番

1. 1

   カスタムロールを作る

   Organization settings → Rolesで、必要な権限を持つロールを用意します。

2. 2

   グループを作る

   Organization settings → Groupsで作成するか、IdPからSCIMで同期します。

3. 3

   ロールをグループに割り当てる

   グループの編集画面でカスタムロールを選びます。

4. 4

   メンバーをグループに入れる

   対象メンバーを各グループに追加します。

5. 5

   メンバーの組織ロールをCustomにする

   Organization settings → Membersで変更するか、IdPグループのマッピングで一括設定します。

6. 6

   最後に機能を組織レベルで有効にする

   先に有効化すると、ロールを切り替える前の短い間、以前の権限で機能に触れるメンバーが出ます。

SCIMのグループマッピングを使っている組織では、もう1つ注意が要ります。メンバーの役割はIdPのグループとロールの対応で決まるため、Members画面で手動で「Custom」にしても、次のフル同期でマッピング上のロールに戻ります。この戻りは監査ログに記録されず、カスタムロールの権限が理由なく効かなくなったように見えます。Customのまま維持するなら、Customにマップ済みのIdPグループへ入れて同期を実行します。

IdPで入れ子にしたグループも注意点です。Claudeが扱うのは直接のメンバーシップだけで、入れ子の関係はSCIM連携時に無視されます。IdP側がメンバーを平坦化してから送るかどうかで、子グループのメンバーが直接メンバーに見える場合と見えない場合が分かれるため、使うIdPの挙動を確かめる必要があります。

上限のレビュー担当は閲覧権限のロールで足りる

各部署に「グループオーナー」を置き、週次・月次のレビューを任せる形が回しやすいです。OwnerやAdminにする必要はなく、Analytics(Can view)と、必要に応じてBilling(Can view)を付けたカスタムロールで足ります。

そのロールを「利用状況レビュー担当」のグループに割り当てます。管理者権限もCustomのメンバーにだけ効き、Analyticsの閲覧範囲は自分のグループに限られず組織全体になる点は覚えておく必要があります。自チームだけを見せたい場合は、グループ単位でスマートレポートを実行させる設定が別にあります。

Enterpriseの支出上限は3階層に加えてプール予算がある

支出上限は組織・グループ・ユーザーの3階層で置けます。加えて、グループ全体に1つの月額予算を持たせるプール予算(ベータ)もあります。推奨は、まずグループとユーザーの上限から始めることです。組織全体の上限は、到達すると全員が同時に止まるため、混乱が大きくなります。

優先順位は個人が最強、組織が最終の天井

優先順位のルールは次の4つで決まります。

• 個人の上限は、それがグループの上限より高くても常にグループの上限より優先される
• 複数のグループに所属し上限が異なる場合は「Multi-group spend limit」の設定(高い方・低い方のどちらを適用するか)が決める。座席種別の既定の上限もこの比較に含まれる
• 組織全体の上限は常に最終的な天井として機能する
• 個人にもグループにも上限がなければ、その消費に上限はかからない

複数グループの解決方式は、Organization settings → UsageのSpending defaultsにある「Member limit from groups」で切り替えます。選べるのは「Higher group limit」と「Lower group limit」の2つです。大きなグループに広い上限を置いて、サブグループで締めるならLower。大きなグループに保守的な基準を置き、特定チームにだけ余裕を与えるならHigherが向きます。

グループ上限とプール予算はどう違うか

くらべる

グループ上限とプール予算の違い

1人あたり

グループ上限

グループの全員に同じ月額の個人上限を継承させます。設定はOrganization settings → Usage → By group/tierで「Edit limits」から行います。他のメンバーの消費は自分の枠に影響しません。

グループ共有

プール予算(ベータ)

グループに月額の共有枠を1つ持たせ、全員がそこから引き出します。チームの予算は決まっているが、メンバーごとの使用量に偏りがあるときの仕組みです。

プール予算の挙動には癖があります。リクエストごとに本人の月額上限とグループのプールの両方に加算され、先に尽きた方でそのメンバーは止まります。プールが尽きると、本人の上限に届いていなくてもグループ全員が止まります。個人上限は均等割ではなく防護柵として置きます。上限は止まる直前にわずかに超えることがあり、プールが尽きた場合は管理者が引き上げるか翌月にリセットされるまで止まったままです。

プールは作成後の支出だけを数え、毎月リセットされます。設定できるのは、Owner・Primary Owner・Admin・Billingロール、およびBilling(Can manage)を持つカスタムロールです。

設定はEdit limitsで「Pooled monthly budget」と「Member monthly limit」を入れます。先にグループに月額の上限を設定しておく必要があります。所属するプールが複数あるメンバーは、大きいプールから使われ、順序は「Pooled budget priority」で変えられます。

ベータの間は、Billing権限が組織全体に効きます。1つのグループのプールを編集できる人は、すべてのグループのプールを編集できます。プールはAdmin APIではまだ扱えません。

ユーザー別の上限が要る場面

ユーザー別の上限は、役割で必要量が大きく違う組織で意味を持ちます。日常的にClaude Codeを使う開発者と、コピーライティングでチャットを使うマーケターでは、同じ額が適切とは限らないためです。

軽量・標準・パワーユーザーのようなティアを先に決め、保守的な額から始めます。上限は後から引き上げる方が、超過してから戻す交渉より楽だからです。エンジニアやデータサイエンティストには高め、または無制限の個人上限を与え、そのぶん適切なモデルを選ばせて相殺します。

上限に達するとどうなり、どう見直すか

上限に達した時点で処理中のリクエストは完了しますが、以降のリクエストはブロックされます。マルチステップのClaude CodeやCoworkのタスクは途中で止まり得ます。作成済みの成果物は失われず、管理者が上限を引き上げるか、毎月1日00:00 UTCのリセットまで待つと再開できます。

ユーザーは上限に近づくとプロダクト内で通知を受け、到達後は「Request more usage」から管理者に引き上げを申請できます。承認者と想定される対応時間を、オンボーディングの時点で伝えておく必要があります。

見直しの材料は2つの画面にあります。

• Time at limit(Organization settings → Usageの冒頭): 今月、稼働中のシート1つあたり、メンバーが上限に当たっていた時間。全メンバーとパワーユーザー(支出上位10%)を、過去の月と予測線と並べて表示する。どのグループや上限種別が最も多いかも示される
• Blocked by a spend limit(Usage画面の最上部): 支出上限が組織にどう効いているかを示す節。従量課金型のEnterprise向けで、従量課金の座席を持たない組織では、いま止まっている、または上限に近いメンバーの人数だけが出る

グループが継続的に上限へ近づいているときは、自動的に引き上げず、まず理由を調べます。そのグループを対象にしたスマートレポートで支出の中身を確認するか、短いサーベイで直接尋ねます。結論が「effortの上限を下げる」「モデルの指針を明確にする」になることもあれば、高い価値の仕事だと分かって引き上げる場合もあります。上限に達したメンバーは、たいてい活用が進んでいる利用者です。逆に消費が極端に少ないユーザーは、まだ有効化されていない可能性があります。

モデルとeffort levelで消費の単価を変える

管理者が打てるもっとも効果の大きい一手は、タスクごとにどのモデルを使うかを明示することです。effort level(応答にどれだけ思考リソースを割くか)も消費に直結し、高いほど多くのトークンを使います。

同じ公式ガイドの中でも、既定モデルの示し方は場所で違います。上の表ではOpusを「ほとんどの役割の既定候補」とし、既定モデルの設定例では「Opusを組織の既定にして、もっとも難しい作業の役割にだけFableを与える」を挙げています。一方で、ユーザー向けの案内文例と組織インストラクションの例では「Sonnetが既定で、Opusは特定の用途」としています。

読み手が自分の組織に当てはめるなら、Sonnetを全員の既定にするか、Opusを既定にして重い役割だけ上げるかは、公式が1つに決めていない設計判断です。「単純作業が中心のグループはSonnet、複雑な作業が中心の役割はOpus」というグループ別の使い分けが、どちらの記述とも矛盾しません。

組織の既定モデルと、既定に戻す設定

既定モデルは「Organization settings → Models」で設定します。選べるのは、Anthropicの推奨モデルに自動追従させる方式と、特定モデルに固定する方式の2通りです。固定すると、消費の予測しやすさを優先できます。

この設定はチャット・Cowork・Claude Code(CLI 2.1.199以降)・Microsoft 365版の新規会話に適用されます。選んだモデルがその製品で使えない場合はAnthropicの推奨が使われ、Claude Code側でマネージド設定によるモデル固定があればそちらが優先されます。

既定では、モデルピッカーは「前回選んだモデルを覚える」動作です。同じ画面の「Always start with the default model and effort level」(ベータ)を有効にすると、新しい会話が必ず組織の既定モデルと既定のeffortから始まります。メンバーは会話の中で変更できます。ピッカーが覚えている前回のモデルは、リリースで既定モデルが変わると新しい既定へ自動で切り替わります。特定モデルに固定する方式とは別の挙動で、対象はチャット・Cowork・Claude Code・Microsoft 365版・Claude Design・Claude Scienceです。ロール単位で独自の既定を持つ場合も、ロールエディターに同じスイッチがあります。

アクセス自体を絞る

モデルへのアクセス制限は指針より強い手段です。組織レベルで無効化したモデルは、OwnerやAdminを含む全員のピッカーから消えます。カスタムロールはその内側でさらに絞るだけで、組織が無効化したモデルをロール側で有効化することはできません。

複数のロールに所属するメンバーはアクセスが加算されます。effortの上限もロール単位・モデル単位で設定でき、組織全体の上限は「どのロールも越えられない最大値」です。複数ロールの場合は、もっとも高い上限が優先されます。既定のeffortも上限を超えて設定することはできません。

この制御はチャット(Web・デスクトップ・モバイル)・Cowork・Claude Code(CLI 2.1.199以降)を含む多くの製品に適用され、Claude in ChromeとClaude Securityは未対応です。CLI 2.1.199より前では、制限されたモデルもピッカーに表示されます。実際に使うとリクエストが拒否されるので、古いCLIのメンバーには先にアップデートを案内します。ロール側の設定場所は「Organization settings → Roles → ロールを選択 → Modelsタブ」です。

指針の見直しでは、消費実績を見るのが手堅い方法です。消費の大半がOpusに集中しているなら、モデル選択の案内が届いていないというシグナルになります。要約や下書きのように件数が多くて複雑でない作業は、Haikuに切り替えて消費が下がるか試す余地があります。

組織インストラクションで利用行動を誘導する

組織インストラクション(Organization instructions)は、組織内のすべてのClaude会話に管理者側の標準的な指示を常時注入する機能です。組織向けのシステムプロンプトにあたり、ドキュメントを探しに行かなくても、利用のその場で規範が効く点が消費管理でも役立ちます。

消費に効く使い方は3つあります。

• トークンを大量に使う出力形式(簡単な用途でも毎回HTMLダッシュボードを生成する傾向など)が目立つとき、生成前にユーザーへ確認するよう指示する。機能は残したまま軽い歯止めをかけられる
• 社内wikiやベストプラクティス文書へのリンクを含め、関連する場面でClaudeに提示させる
• 「Sonnetが既定でOpusは特定のワークフロー専用」のような運用ルールを含め、ユーザー教育を補強する

消費と成果を追う手段

制御だけでなく、実際の消費を継続的に把握する仕組みも用意されています。

• Analyticsページ(claude.ai/analytics): 週間アクティブユーザー・シート稼働率・上位コネクタ・累計支出(月次/四半期/年次)・モデル別支出・支出上位10ユーザーを一覧できる。チャット、Claude Code、Cowork、Claude Designの製品別ビューもある
• 支出レポートCSV: Overviewタブの「How much is Claude costing?」で「Export spend report」を選ぶ。当月・先月・過去90日・任意期間(最大90日前まで)のユーザー別・モデル別支出を1回限りで出力できる
• Analytics chat: 「直近30日の日次支出を見せて」のような自然文の質問にグラフと要約で答える。既定は直近30日で、データは日次更新
• Analytics API: 利用者・トークン数・支出を、モデル・RBACグループ・コンテキストウィンドウ・地域・サービス階層別に取得できる。RBACグループ別にすると、ユーザー別の行を出さずに部署ごとの支出が分かる。1リクエストは最大31日分で、過去365日以内かつ2026年1月1日以降が対象

Analytics APIのキーは、Primary Ownerが「Organization settings → API」で read:analytics スコープ付きで作成します。コストと使用量のデータは通常4時間以内(最大24時間)で反映され、最大30日間は数値が修正され得ます。請求書と突き合わせる確定額として使うなら、30日以上前の日付を指定します。

スキルごとの費用対効果を計算する

AnalyticsのSkillsビューには、各Skillの利用者・1回あたりのコスト・総利用回数が出ます。グループやプロダクト別に絞り込めます。計算はプロダクトの外で行い、手順は次のとおりです。

1. Skillsビューからテーブルをエクスポートする
2. 各Skillに1回あたりの価値を割り当てる(置き換える社員の時間など)
3. スプレッドシートで「(1回あたりの価値 − 1回あたりのコスト) × 総利用回数」を出す

公式の例では、営業電話の準備Skillが1回$0.90で、価値を$20と見積もると、1回あたりの純価値は$19.10です。ガイドはこれを「20x」と表現しています。見積もりが粗くても、どのSkillに投資するかの判断材料になります。

消費の中身を見るスマートレポートとサーベイ

Analyticsが金額を示すのに対し、スマートレポート(ベータ)は支出が何を生んだかを見ます。チーム・期間・対象プロダクトを指定すると、Claudeが会話の標本を読み、作業の流れと成果物の種類ごとに支出を分解します。消費管理で見る節は、出力の種類ごとのセッション単価、よくある摩擦や非効率、再利用できるSkillの候補、もっとも高額なセッションの4つです。個人の評価ではなく、採用状況の把握と投資計画のための機能です。

サーベイ(ベータ)は、Analytics → Surveysから、グループを指定して短い質問を作業の切れ目にCoworkやチャットへ出します。使い道は、ROIの見積もりに使う「Claudeで節約できた時間」と、Claudeが役に立っていない場面を聞くことです。回答は匿名ではなく、エクスポートに回答者のメールアドレスが含まれます。PHIのような規制対象のデータは、回答に含めないでください。作成できるのはPrimary Owner・Owner・Admin、およびAnalyticsの閲覧権限を持つカスタムロールで、顧客管理の暗号鍵(CMEK)を使う組織ではまだ使えません。

通知の閾値はプールと組織で違う

数字

支出通知が届く水準

• 組織の上限

  75% / 90%

  Spend-threshold alerts。管理者へ通知

• プール予算

  50 / 75 / 95 / 100%

  Billing管理者へメール

通知は、誰かの作業が止まる前に上限を引き上げるかを検討する猶予になります。プールの通知は組織上限のアラートとは別に届きます。

Admin APIで上限管理を自動化する

多数のグループを持つ組織向けには、コスト管理をスクリプト化できるAdmin APIがあります。全メンバーの実効上限と当月の消費額を読み取り、ユーザー個別の上限を設定・解除できるため、引き上げ申請のレビューや上限接近の検知を自動化できます。

グループ・座席種別・組織レベルの上限とプール予算は、Organization settingsからしか設定できません。ユーザー管理系のエンドポイント(グループの作成、メンバーの追加削除、カスタムロールの読み取り)は、Enterprise組織向けのベータです。

使用量クレジットとの関係

ここで扱った支出上限は、従量課金制Enterpriseでは消費全体に掛かります。この制度では座席料金に加えて、最初の1トークンからAPI単価で課金され、使用量クレジットは適用されません。座席制Enterpriseでは、含まれる利用量を超えた後の使用量クレジットに対して、同じ組織・グループ・個人の上限(シート階層の上限を含む)が効きます。使用量クレジットの有効化手順や、Teamプランとの課金タイミングの違いはClaude Teamの使用量クレジットにまとめています。Agent SDK経由の消費が組織の消費プールにどう影響するかはClaude Agent SDKはプランの利用上限を消費するかで扱っています。

まとめ

消費が読めないときは、まず上限額でなく、Customロールに切り替えていないメンバーがClaude CodeやCoworkに触れていないかを確かめてください。そこが空いたままだと、グループの上限をどれだけ丁寧に置いても、制限したはずの面から消費が流れます。

上限の見直しはTime at limitが上がったグループから始め、理由を調べてから引き上げる順にすると、上限が業務を止める場面を減らせます。プランの選び方自体を検討している段階ならClaude Team・Enterprise契約ガイド、Enterprise自体の料金体系はClaude Enterpriseとはを参照してください。