支出の管理

これは依然として5つの決定事項のうち4番目、「支出」です。3つの上限レベルはすでに設定済みです。ここからはそれらを実際に活用していきます。支出の管理には3つの要素があります。課金の仕組み、上限に達する前に支出を動かす設定、そしてどちらを変更すべきかを教えてくれるレビューの習慣です。目指すのは、上限引き上げのリクエストが自動的な承認ではなく、確認を促すきっかけになることです。

課金の仕組み

一般的なEnterprise契約では、メンバー単位のプラットフォーム料金に加えて、トークンで計測されるプール方式の消費量に対して料金を支払います。正式な情報源としては契約内容をご確認ください。トークンとは、Claudeが入力を読み取り、応答を書き込む際にカウントする小さなテキストの単位です。プロンプトや会話が長くなるほどコストは高くなる傾向があり、サーフェスによっても差があります。エージェント型のサーフェス（CoworkとClaude Codeのように、Claudeが自律的に多くのステップを実行するもの）は、単発のチャットのやり取りよりも裏側で多くの処理を行うため、タスクあたりの消費量が多くなる傾向があります。契約がセールス支援型の場合、その消費量は月次で後払いの形で請求されます。セルフサービス型のEnterpriseの場合は、クレジットを前払いし、使い切ると利用が一時停止します。Enterpriseプランの課金方法についてはヘルプセンターを、トークンと埋め込みについてはClaude Academyをご覧ください。

このレッスンで重要なのは、請求額を左右するのは人数だけでなく消費量であり、プールは組織全体で共有されているため、ある1つのグループが大量に消費した月には、全員のプールから差し引かれるという点です。あるグループが実際にプールを使い切ってしまうかどうかは、あなたが設定した上限（レッスン9）次第です。上限はどれも必須ではなく、上限を設定しなかったレベルは単純に無制限になります。

支出を動かす設定

支出の上限は天井を設定するものであり、これらの設定はグループがその天井にどれだけ速く近づくかを決めます。

• モデルのデフォルトとエフォートレベル： これらの設定がどこにあるかはレッスン6で扱いましたが、ここで重要なのはその支出への影響です。ほとんどのメンバーはピッカーに触れることがないため、デフォルトが高いエフォートレベルの最も高性能なモデルになっていると、それが最もコストの高い構成となり、利用の大部分がその構成で実行されることになります。（レッスン6で設定したように）組織全体、あるいはロールごとにミドルレンジのモデルをデフォルトに設定し、デフォルトのエフォートレベルを中程度に選び、組織全体またはロールの定型業務に対してエフォートに上限を設けることは、ほとんどの上限変更よりも大きく支出を動かします。
• 利用時点でのガイダンスとしての組織指示： 組織指示は、メンバーが探さなければならないドキュメントの中にあるのではなく、コストが発生するまさにその瞬間、会話の中でメンバーに届きます。消費量の抑制に役立ついくつかの指示の例としては、メンバーがそれ以上を求めない限り回答は短いバージョンにとどめること、添付されたすべてではなくタスクに必要なファイルだけを使って作業すること、最も高いエフォートは本当に必要な作業のために取っておくこと、などが挙げられます。これはClaudeの出力を形作るソフトな誘導であり、厳格な制限ではありません。
• 再利用レバーとしてのカスタマイズ： スキルはタスクが必要とするときにのみ読み込まれるため、毎回プロンプトを共有し直すよりもトークン消費が少なく、一貫性も高くなります。プロジェクトも同様の仕組みを提供します。プロジェクトの指示とファイルは、そのプロジェクトが共有されている全員に対して保持されますが、そのコンテキストはオンデマンドで読み込まれるのではなく、各プロジェクトの会話に常に存在する点が異なります。
• メンバーのエージェント型利用の習慣： エージェント型の作業では、開始されたまま放置されたタスクは、その所有者がもはや管理していなくても、プールから消費し続けます。例えばCoworkでは、スケジュールされたタスクは、誰かが見ているかどうかに関わらず、設定された頻度で消費を続けます。ここでの管理者側のレバーは大まかなものです。「Coworkをクラウドで実行する」（Enterpriseプランではデフォルトでオフ）は、CoworkのセッションがAnthropicのインフラ上で実行できるかどうかを決め、メンバーの支出上限は、到達した時点でそのメンバーの利用を一時停止します。統合Claude体験を利用するメンバーは例外で、この設定がオフでも、Anthropicのインフラ上でエージェント型の作業を実行します。本当の解決策はメンバーの習慣にあります。タスクの範囲を絞り、関係するファイルを指定し、スケジュールされたタスクを定期的に見直して、もう不要になったものは削除することです。誰も読まない定期レポートの作成をやめるのと同じ考え方です。

引き上げる前にレビューする

支出を単に上限で抑えるだけでなく、きちんと管理された状態に保つための習慣が3つあります。

1. すべての増額を疑う： リクエストを承認する前に、その追加の支出が単なる症状ではなく正当な理由によるものであることを確認します。
2. 繰り返しの増額も疑う： 同じグループの上限が繰り返し引き上げられる場合、利用が増加していることを意味することもあれば、上限がメンバーの実際の必要量を下回る水準に設定されていたことを意味することもあります。後者の場合、根本的な支出を抑えるのではなく、実際の業務を妨げているだけです。レビューの役割は、どちらが起きているのかを見極めることです。利用が症状であれば設定を調整し、上限そのものが原因であれば上限を再設定します。
3. 一定の頻度で、両方向から上限をレビューする： どのメンバーやグループが上限に達しているか、そしてどのグループが利用不足になっているかを確認します。そうすることで、リクエストに反応するのではなく先回りして対応でき、組織全体で支出のバランスをより良く取るための調整ができます。

支出を読み解く

3つのサーフェスがそれぞれ異なる種類の質問に答えてくれるので、目的に合ったものを使いましょう。

グループ単位で把握したい場合、Analytics APIは利用状況とコストをグループ別に分解でき、分析ダッシュボードにはGroupsビューがあります（含まれる内容はTeamプランおよびEnterpriseプランの利用状況分析を表示するに記載されています）。支出CSVはメンバー単位なので、それ以外のグループ単位の見方をしたい場合は、グループのマッピングと結合してください。自動化する際に適切なツールを選べるよう、範囲に関する注意点を一つ挙げておきます。Analytics APIは利用状況を読み取るものであり、一方でSpend Limits API（レッスン9）はメンバーごとの上限を設定するものです。

Plutoの支出ガバナンス

Plutoはミドルレンジのモデルを組織のデフォルトに設定し、ダッシュボードを毎月レビューしています。2か月目、Platformが上限に達し、増額リクエストが届きました。レビューの結果、その支出の大部分は、定型的なプルリクエストの要約を実行する最も高性能なモデルによるものだと分かったため、PlutoはPlatformのメンバーが持つEngineeringロールのデフォルトモデルを引き下げ、上限はそのままにしました。翌月、Platformは同じ作業量のまま上限を下回って運用できました。

以下のインタラクティブなウィジェットでは、Plutoの2か月目をシミュレーションできます。Plutoが変更する設定（上限を引き上げる、デフォルトを変更する、エフォートの上限を設定する）を選び、翌月の支出と上限がどう変化するかを確認してみましょう。

1 · あなたの決定

あなたの支出ガバナンスの姿勢はどのようなものですか。デフォルトはどこに設定するか、どのくらいの頻度でレビューするか、そして上限を動かす前に何が行われるか、を考えてみましょう。

2 · あなたが下せる選択

この決定は選択肢のリストから選ぶものではなく、判断によるものです。2つの判断がこれを構成します。どのくらいの頻度でレビューするか、そしてどこかのグループの支出に、それに加えて独自のレビューが必要かどうかです。

1. どのくらいの頻度でレビューするか： まずは月次から始めましょう。デフォルトが設定されれば支出の動きはゆっくりとしたものになるため、分析ダッシュボードを月に一度確認すれば、まだレバーを引ける段階でトレンドを捉えるには十分です。状況がまだ固まっていない間（例えば、ロールアウトの最初の数か月、新しいサーフェスやグループが稼働し始めたとき、予算に余裕がないときなど）は、週次または隔週に頻度を上げ、変更の必要性が落ち着き始めたら、再び頻度を下げていきます。
2. 規制対象のグループに独自のレビューが必要かどうか： 支出に個別の監督が必要な規制対象のグループには、組織の他の部分がどのような頻度で運用していようと、それに加えて独自のレビューと独自の担当者を設けるべきです。

3 · 後で変更する場合

デフォルトモデル、エフォートの上限、レビューの頻度は、いずれもデータが集まるにつれて調整していく設定であり、それぞれの変更はその時点から適用されます。

リソースを設定する

判断が固まったら、デフォルトとエフォートの上限は組織設定の中にあり、組織指示はレッスン8で設定した場所にあり、レビューは分析ダッシュボードを使って行います。

• Claude Enterprise消費ガイド：利用状況がどのように計測されるか、さらにAnalyticsチャット、Analytics API、組織指示について。あらゆる支出レビューの背景となる資料です。
• Enterpriseプランの課金方法は？：請求額がどのように計算されるかについて。増額や削減が想定通りの結果になるようにするためのものです。
• 組織のモデルアクセスを管理する：組織全体およびロールごとのモデルアクセスとエフォートの上限について。モデルの組み合わせを調整する習慣の背後にあるレバーです。
• TeamおよびシートベースのEnterpriseプランの利用クレジットを管理する：クレジットプールの購入、追跡、補充について。

レッスンの演習

組織全体のデフォルトモデル、デフォルトのエフォートレベル、モデルごとのエフォート上限を書き出し、さらに異なる設定が必要なカスタムロールがあれば、そのデフォルトモデルとエフォート上限も書き出します。次に、組織全体のレビューの頻度を設定し、最初のレビューをカレンダーに登録し、増額リクエストが来たときに最初に確認する3つの項目をメモします。組織指示に追加する3行を下書きし、ロールアウト時に送るメモとして、自分の言葉でメンバー向けのガイダンスを書きます。

予算の担当者に持っていくべきもの： 提案するデフォルト設定、レビューの頻度とその実施者、そして増額を承認する前に適用するルールです。

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

次のステップ

次のモジュール「可視性」では、何を測定できるか、そして会話データがどのくらいの期間保持されるかを扱います。これは、何が起きたのかを誰かに尋ねられたときに提示する記録です。