結論：予算はセッション作成時に、停止後の判断まで決める
先に答えると、Claude Managed Agentsの費用を制御するには、セッション作成時にSession budgetsの上限を米ドルのセント単位で設定し、監視するlist cost、到達時の担当者、増額または終了の判断基準まで一組にします。上限は新しいモデルリクエストを止める硬い境界ですが、請求額を一円単位で固定する機能ではありません。
読者の具体的な困りごとは、長い自律処理や複数threadの実行で、誰がどの時点で費用を止めるか説明できないことです。読了後は、上限額、対象費用、停止時の挙動、再開条件を決められます。次の行動は、代表タスク一回の許容額と、上限到達後に結果を確認する担当者を一行ずつ書くことです。
Session budgetsが止めるものと止めないもの
公式のSession budgetsは、Managed Agentsの一つのsessionへ設定する任意のhard spend ceilingです。Platformはモデルtoken、Web search、session running timeを公開リスト価格で継続的に評価し、その合計であるlist costが上限へ達すると、新しいmodel requestを開始しません。Web searchは1,000件あたり10ドル、running timeは1時間あたり0.08ドルとして説明されています。公開直前には公式料金を再確認してください。
ここで重要なのは、list costと実際の請求額を同じものとして扱わないことです。組織の契約に割引があっても予算判定は公開リスト価格で行われるため、請求額が上限より低い場合があります。反対に、上限をまたぐ時点ですでに動いているmodel requestは途中で切られず完了します。50セントの上限でも記録されたlist costが53セントになる例が公式文書にあり、これは請求異常ではなく実行中requestの完了によるものです。
予算は一つのsession全体へ効きます。multiagent sessionでもthread別の上限はなく、主agent、subagent、advisorを含む複数threadが一つの枠を共有します。deploymentへ付けたbudgetは累計額ではなく、deploymentが新しく開始する各sessionへ個別にコピーされます。日次総額、部署総額、契約請求の統制は別の予算管理で補完します。
上限額を決める4つの比較軸
第一軸は成果物です。調査メモ、コード変更、複数資料の統合など、何を一回のsessionの完了条件にするかを固定します。完了条件がないまま金額だけ決めると、安く止まっても使える成果がなく、増額判断もできません。第二軸は代表ケースの消費です。通常例、難例、停止例を小さく試し、token、search、running timeを分けて記録します。
第三軸は並列性です。multiagentでは複数threadが同じ上限を消費し、上限直前に複数のrequestが動いていれば、それぞれの完了分だけ余地を超える可能性があります。上限を厳密な請求額ではなく、新しい仕事を始めない境界として設計し、同時実行数と一requestの最大負荷を考慮します。
第四軸は停止後の価値です。途中成果を確認して増額するのか、次回はタスクを分割するのか、作業自体を見送るのかを決めます。単に「上限へ達したら担当者へ連絡」では判断が属人化します。達成済み条件、残作業、追加上限、承認者、再実行可否を停止票へ記録します。
予算上限を設定する7手順
- 一つのsessionで得る成果物と、完了を判定する条件を一文で固定します。
- 通常例、難例、停止例を小さく実行し、model token、Web search、running timeを記録します。
- 代表消費、並列thread、一request分の超過余地を含めて上限案を決めます。
- session作成時のbudgetへ、typeをlimit、amountを先頭ゼロのないセント文字列、currencyをUSDとして設定します。
- session.usage、list_cost、active_seconds、search request数を監視し、業務IDへ紐づけます。
- budget_reachedを受けた担当者が、成果、残作業、増額額、停止理由を確認します。
- 代表タスクを再評価し、上限、タスク分割、model、search利用、並列数を更新します。
amountは「25.00」のような小数ではなく、「2500」のような整数セントを文字列で指定し、現在はUSDのみです。予算なしで作成したsessionへ後からbudgetを追加すると400 errorになります。最初の試験でも小さな上限を付け、予算境界を含む運用を最初から検証します。
上限到達、増額、削除の違い
上限へ達したsessionは終了せず、stop_reasonがbudget_reachedのidleになります。historyとsandboxは保持されます。実行中のtool結果を収める一部のsettle eventは受け付けますが、新しい仕事を始めるuser.messageは拒否されます。停止を障害と誤認しないよう、監視ではbudget_reachedと通信障害、認証失敗、task完了を別の状態へ分類します。
再開にはbudgetを変更するか削除します。増額後の上限は、すでに消費したlist costより厳密に大きい必要があります。表示値は丸められるため、旧上限ではなくsessionのusage.list_costを確認し、それより少なくとも1セント以上大きい値を使います。増額は「続けたいから」ではなく、残作業と追加成果を確認した承認記録と一緒に行います。
budgetをnullへ変更すると上限を削除でき、停止中の作業は自動的に再開します。ただしsessionから一度削除したbudgetは再追加できません。予算統制を続けたい場合は削除せず上限を変更します。無制限化が必要なら、理由、承認者、終了時刻、外部監視の上限を別途残します。
監視チェックリストとよくある質問
成果物と完了条件があるか／session作成時にbudgetを付けたか／セント文字列とUSDを確認したか／list costと請求額を分けたか／multiagentの共有枠を考慮したか／一request分の超過余地を見たか／budget_reachedを状態分類したか／増額承認者を決めたか／budget削除の一方向性を理解したか／日次・部署予算を別管理したか、を確認します。
上限を超えたら失敗ですか？
いいえ。少し超えるのは実行中requestが完了した結果として仕様上起こります。成果と残作業を確認し、正常停止、増額、タスク分割を判断します。
予算へ達したsessionを再利用できますか？
上限を消費額より大きく変更するかbudgetを削除すれば再開できます。削除後は同じsessionへbudgetを再追加できません。
deploymentのbudgetで月間総額も止まりますか？
deploymentのbudgetは新しく作る各sessionへ個別に適用されます。月間・部署全体の累計統制は別に設計します。
公式情報と次の行動
上限の設定、list cost、budget_reached、変更と削除はAnthropic公式Session budgets、sessionの作成、version固定、eventの開始方法はAnthropic公式Start a sessionで確認できます。2026年8月7日の追加はClaude Platform release notesで確認しました。
API全体の費用削減はClaude API料金を削減する方法、Claude Codeの利用者別統制はClaude Codeのコスト管理、企業導入の停止条件はClaude Code企業導入チェックを参照してください。Miraigentの無料診断では、成果条件、予算枠、監視、停止後の承認を業務単位で整理します。