支出上限

これは5つの意思決定のうち4番目、支出についてです。メンバーが何を構築できるかのルールはすでに設定済みです。このレッスンでは支出上限について扱います。上限が設定される3つのレベル、メンバーが上限に達したときに何が起こるか、そしてエスカレーションの責任者は誰かについてです。

上限とは何か、どこに設定されるか

支出上限には、広い範囲から狭い範囲まで3つのレベルがあります。

1. 組織の上限（ceiling）： 組織が特定の月に使用できる総額です。グループ上限やメンバー単位のオーバーライドによって、これを超えて使用することはできません。
2. グループ上限：グループの全メンバーが継承するメンバー単位の制限で、そのグループの典型的な使用量に合わせて設定されます。
3. メンバー単位のオーバーライド：特定のメンバー自身の制限で、個別に設定され、そのメンバーが属するグループの数値より高くも低くもなり得ます。

グループ上限の下には、Spending defaultsで設定されるシート デフォルト制限があります。これは、グループ上限やオーバーライドを設定する前にメンバーが得る数値です。メンバーが上限を持つ2つのグループに所属している場合、組織全体の設定（Spending defaultsの下にあるMember limit from groups）がどちらを適用するかを決定し、高い方のグループ上限と低い方のグループ上限のどちらを優先するかを選択できます。この比較にはシート デフォルトも含まれるため、「Higher group limit」を選んでいる場合、グループの上限を上回るシート デフォルトがそのメンバーの数値になります。レッスン5の権限の和集合ルールでは常により広い付与が優先されるのとは異なり、ここでは決定はあなた次第なので、意図的に設定してください。

上限は実際にどう機能するか

メンバーが上限に達すると、その使用は一時停止されます。一時停止は障害ではなく、後で実行されるように作業がキューに入れられることもありません。メンバーは、新しい月になって制限がリセットされるか、承認されたリクエストによって解除されるまで、上限を超えてClaudeを使用できません。メンバーには、追加を申請するためのアプリ内プロンプトも表示されます。このリクエストは組織設定のUsageページに届き、Owner、Primary Owner、およびカスタムロールでBillingが「Can manage」に設定されている人が承認または拒否できます。

規模が大きくなったときに注意すべき点が1つあります。リクエストを承認できる人が、予算の責任者であるとは限らないことが多く、そのため製品内のリクエストが決定まで数日待たされることがあります。予算責任者がカスタムロールを持っている場合、Billingが「Can manage」に設定されたロールを使えば直接決定できます。この権限は、支出を承認すべき人が持つロールにのみ付与してください。大規模な組織では、上限引き上げのリクエストを独自のチケット制度で処理することが一般的です。Spend Limits APIを使えば、リクエストの一覧表示、承認、拒否に加えて、制限の設定も行えます。

メンバーごとに個別に上限を設定するのではなく、グループ上限を拡張の仕組みとして使用してください。グループの典型的な使用量に合わせてサイズを決め、メンバーシップによって割り当てを行わせます。グループ上限は、グループが共有するプールされた予算ではなく、必ずしも人数に比例するものでもありません。それが答えるのは「このグループの1人のメンバーが通常どれくらい必要とするか」という問いです。オーバーライドは、Claude Codeで毎月重いデータ分析ジョブを実行するアナリストのような、特定の例外のためのものです。これにより、そのアナリストが属するグループ全体の上限を引き上げることなく、必要なものを与えられます。

メンバー単位のオーバーライドが増えていく場合、Claude Enterprise Admin API（パブリックベータ版）の一部であるSpend Limits APIを使えば、プログラムによってそれらを設定できるため、プラットフォームチームが1つずつ手作業で設定する必要はありません。グループ上限は組織設定内にとどまります。オーバーライドのリストが増え続ける場合は、それを例外リストを長くすべきサインとしてではなく、それらのメンバーには専用のグループが必要だというサインとして捉えてください。

Plutoの上限

Plutoは、予算責任者の数値から組織の上限を設定し、各部門の典型的なメンバーに合わせてグループ上限のサイズを決めました。最初の月の使用状況レビューの後、Claude Codeでの作業がグループの典型的な使用量を大きく上回っていた数名のPlatformエンジニアには、Platformグループの上限を引き上げるのではなく、メンバー単位のオーバーライドが与えられました。グループ上限を引き上げると、すでに十分に上限内に収まっているエンジニアも含め、全エンジニアの上限が引き上げられてしまうため、オーバーライドは追加の余地を必要とする外れ値のメンバーだけを対象にしています。Payments & Trustは、自グループに関わるすべてのリクエストをレビューします。

以下のインタラクティブ ウィジェットでは、1人のメンバーについてグループ上限とメンバー単位のオーバーライドがどのように組み合わさるか、また彼女が2つのグループに所属している場合にMember limit from groups設定がどちらの上限を適用するかを示しています。

1 · あなたの意思決定

組織における上限はどこに設定されますか（上限、グループ上限、初日からのオーバーライド）。また、メンバーが上限に達したときのエスカレーションは誰が担当しますか。

2 · 選択できる内容

この意思決定は、単純な切り替えではなく判断が求められるものです。上限をどう設定するか、そして設定後のエスカレーションを誰が担当するかの両方について判断する必要があります。それぞれの検討事項を合わせて比較検討してください。

独自の仕組みを一から考案するのではなく、Claude Enterprise consumption guideのティア構造を活用できます。このガイドでは、ロールアウト前にロールタイプ別の消費ティア（light、standard、power）を定義することを推奨しており、これにより上限の割り当てと調整を一貫して行えます。エージェント型の作業は、短いチャットよりもセッションあたりの消費量が多くなることがあります。Claude Code、Cowork、そして統合Claude体験でCoworkのクラウドセッションに移行したチャットがこれにあたります。

自組織の使用履歴、またはアカウントチームからのサイジングガイダンスがあればそれをもとに、各ティアに数値を設定し、設定した日付を記録してください。そしてそれを目標値としてではなく、自組織の使用状況に合わせて調整していく初期値として扱ってください。最終的に決める数値は、予算責任者が保持する組織の上限と、レッスン6で各グループが実際に利用できるサーフェスという2つの要素によって制約されます。

上限の設定は、3つの検討事項と、前払いをしている場合の1つの制約に集約されます。それぞれを、どれだけの使用履歴があるか、そしてグループの作業の性質と照らし合わせて検討してください。

1. 典型的な使用量に合わせたサイズ設定： 典型的な適合です。グループ上限は各グループの典型的なメンバーに合わせてサイズを決め、メンバーシップによって割り当てを行います。
2. 厳しめに設定し、根拠に基づいて引き上げる： 使用量が本当に未知の場合（履歴がない、新しいサーフェスである場合）は、厳しめに始め、各リクエストを予算を適正化するために必要な使用実績として扱います。根拠に基づく引き上げとは、小刻みな増額を繰り返し承認するのではなく、最初の月の実績が裏付けとなった時点で、観測された使用量にグループの上限を再設定することを意味します。
3. 急増する作業のための計画的な余裕： 月末の分析や季節的な負荷があるグループには、繰り返しの緊急承認の代わりに、急増に合わせて設定し、その後取り除く、より高い上限またはオーバーライドを与えます。
4. 使用クレジットを前払いしている場合： 上限は残りの前払いクレジットです。クレジットがゼロになると、クレジットが追加されるまで組織全体で使用が一時停止されるため、上限の変更には必ず予算責任者が関与します。

エスカレーションの分担は、最初のリクエストが届いてからではなく、上限を設定する時点で決めてください。上記に挙げた承認者の中から、通常のリクエストを誰が承認するかを指名し、承認範囲について事前に予算責任者と合意しておきます。グループ上限や組織の上限を動かすようなものは、あなたの使用状況の説明を添えた上で、予算責任者の判断となります。正確な分担よりも、メンバーがこの仕組みの存在を知っていることの方が重要です。

3 · 後で変更する場合

上限は自由に変更できます。各変更はその時点から適用されます。

リソースの設定

決定したら、組織設定で上限、グループ上限、および各種オーバーライドを設定します。

• Enterprise Planでのグループとグループ支出上限の管理：グループに上限を設定する方法と、その上限がどこに位置するか。
• Team Planおよびシート制Enterprise Planの使用クレジットの管理：クレジットを前払いしている場合に、上限が消費する組織全体のクレジットプール。
• 使用量と長さの制限の仕組み：設定した上限の下に位置する、モデルおよびプランレベルの制限。

レッスンのアクティビティ

多くの組織では、予算責任者がこれらの数値を確定します。あなたの組織もそうである場合、コンパニオンのセクションは、予算責任者に渡す概要資料としても機能します。コンパニオンで、以下を作成してください。

• 上限表：上限、グループごとの数値、各グループに選んだティアとその理由。
• すでにオーバーライドが必要になると見込んでいるメンバー（いる場合）。
• エスカレーションの分担：当日中に承認するもの、予算責任者に回すもの。
• メンバーが上限のある2つのグループに所属している場合、どちらの上限が優先されるか。
• 組織の使用履歴（利用可能な場合）。各上限の根拠が依頼と一緒に伝わるよう、表と合わせて共有してください。

予算責任者に持参するもの：上限表、見込まれるオーバーライド、エスカレーションの分担、そしてそれらの根拠となる使用履歴。

→ これをワークアロング コンパニオンのレッスン9のセクションに記録してください。

次のステップ

次のレッスンでは、請求の仕組みと、上限に一切触れずに支出を動かせる設定について扱います。これにより、リクエストが届いたときに、数値を引き上げることが最初の選択肢ではなく最後の選択肢になります。