Claudeのエージェントにドル建て上限。停止は上限ちょうどでなく少し超える

Claude Managed Agents のセッション予算は、エージェントの 1 セッションが使う金額にドル建ての上限を設ける機能です。

📖 この記事で分かること

• セッション単位のドル建て上限の設定方法
• 上限超過が1リクエスト分だけ起きる理由
• 予算の削除が一方通行である運用上の注意
• デプロイメントの予算が縛る範囲

💡 知っておきたい用語

• セッション予算: エージェントの一続きの作業に対してかける金額の上限。使い切ると新しい仕事を始めなくなる、ブレーカーのような仕組み

最終更新日: 2026年8月8日

▶ 公式ページ

• Session budgets(Claude Platform ドキュメント)
• Claude Platform リリースノート(Claude Platform)

Claude Managed Agents にセッション予算が追加

この記事のポイント

• Anthropic が2026年8月7日、Claude Managed Agents にセッション予算を追加しました(2026年8月時点)。
• 上限は米セントの整数を文字列で指定し、通貨は USD のみ。到達したセッションは停止理由 budget_reached で待機します。
• 停止は上限ちょうどではなく、スレッドあたり1モデルリクエスト分だけ超えます。

Anthropic は2026年8月7日、Claude Managed Agents に「セッション予算(Session budgets)」を追加しました。エージェントの1セッションが使う金額に上限を設け、その額に達したセッションは新しいモデルリクエストの発行を止めます。無人で長時間走るエージェントの費用を、プラットフォーム側が強制的に区切る仕組みです。

同日の更新はこれを含めて4件あります。ほかは、主スレッドがターンの途中で同等以上のモデルに戦略的助言を求められる「アドバイザー」、推論の実行場所を指定する inference_geo、そしてセッションがマウントしたリポジトリのルート .claude/skills からスキルを自動検出する機能です。

上限はセッション作成時に budget フィールドで渡します。{"type":"limit","max_list_cost":{"amount":"2500","currency":"USD"}} のように書き、amount は米セントの整数を文字列で指定します。"2500" が25.00ドル、"50" が50セントです。"25.00" のような小数形式は拒否されます。数値ではなく文字列を使うのは、金額に浮動小数点の丸めを一切かけないためです。通貨は USD のみ対応しています(2026年8月時点)。

何にいくらかかるかは「リスト価格」で数える

予算が比較する相手は、実際の請求額ではなく公開リスト価格で算定した「list cost」です。

list cost に積まれるのは3種類です。各モデルのリスト価格で数えるモデルトークン、1,000回あたり10ドルのウェブ検索、そして1時間あたり0.08ドルのセッション稼働時間です(2026年8月時点)。

ここに実務上の注意があります。list cost は契約価格ではありません。組織に交渉済みの割引がある場合、セッションが止まるのはあくまでリスト価格の合計が上限に達した時点で、実際に請求される額は上限より低くなることがあります。予算は「支払う金額の上限」ではなく「定価換算での作業量の上限」として読む必要があります。

なお Managed Agents の API【エーピーアイ】リクエストには managed-agents-2026-04-01 ベータヘッダーが必要です(メモリストアのエンドポイントのみ agent-memory-2026-07-22)。

上限に達したセッションは終了せず待機する

上限判定はモデルリクエストとリクエストの「間」で行われ、リクエストの途中では行われません。この設計から、停止時の金額は上限ちょうどにはなりません。

上限を越えさせた最後のリクエストは、まだ上限未満だった時点で受理済みのため最後まで完走します。結果として、上限 "50"(50セント)のセッションが list_cost "53" で停止することがあります。これは課金エラーではなく仕様で、超過分はスレッドあたり1モデルリクエストに限定されます。公式ドキュメントも、予算を正確な停止点ではなく新規作業の境界として扱い、この1リクエスト分の余裕を見込んで上限を決めるよう求めています。

到達したセッションは終了せず、停止理由 budget_reached で待機状態に入ります。履歴とサンドボックスは通常の待機セッションと同じく保持されます。イベントは、各スレッドの session.thread_status_idle、累計使用量を載せた session.usage、最後に session.status_idle の順に流れます。

待機中に受け付けられるのは、進行中の作業を決着させるイベントだけです。具体的には user.tool_confirmation、user.tool_result、user.custom_tool_result、user.interrupt の4種類で、user.message のように新しい作業を始めるイベントは400エラーで拒否されます。再開するには予算を変更するか削除します。更新が受理されれば、止まっていた作業は自動的に再開します。

運用で効く3つの注意点

仕様を読むと、費用の保険として入れる前に決めておくべき点が3つあります。

第1に、予算はセッション作成時にしか付けられません。予算なしで作成した既存セッションに後から追加するのは400エラーです。すでに動いている無人パイプラインは、セッション作成側のコードを直さない限りこの機能の恩恵を受けられません。

第2に、削除は一方通行です。budget に null を設定すると上限は完全に外れますが、一度外したセッションに新しい予算を付け直すことはできません。上限を維持したまま緩めたいなら、削除ではなく変更を選ぶ必要があります。変更時の値は消費済み list cost より厳密に大きくなければ400エラーになるため、旧上限ではなく usage.list_cost を基準に、報告値が丸められている分を見て1セント以上上を設定します。

第3に、デプロイメントの予算は累計ではありません。定期実行のデプロイメントも同じ budget オブジェクトを受け取りますが、上限は開始する各セッションにコピーされるため、縛られるのは1回の実行ごとです。デプロイメント全体の月次総額を抑える機能ではない点は、費用管理の設計を誤りやすい箇所です。なおデプロイメントの予算はセッションと違い、null で消してから後で再設定できます。

マルチエージェント構成では、予算はセッション全体で1つを共有し、スレッドごとの上限はありません。各スレッドの消費はそれぞれが使うモデルの価格で算定され、アドバイザーへの相談も同じ予算にアドバイザーモデルの価格で計上されます。保留中の確認要求は上限より優先され、片方が確認待ち、もう片方が予算到達の場合、セッション全体は確認待ちを報告します。

編集部の見方

編集部は、今回の追加で最も効くのは上限そのものより、上限を後から付けられず、外したら戻せないという非対称な制約だと見ます。

• 根拠1: 予算はセッション作成時のみ付与でき、後付けは400エラーです。既存の自動実行基盤は作成コードに手を入れるまで効果がゼロで、「入れておけば安心」という性質の機能ではありません。
• 根拠2: 削除が一方通行のため、障害対応で「とりあえず上限を外して流す」判断をした瞬間、そのセッションは以後上限を持てなくなります。運用手順書のレベルで、外すのではなく引き上げると決めておく必要があります。
• 根拠3: デプロイメントでは上限が各実行にコピーされるため、1日に何度も走る設定では総額が実行回数に比例します。1回分の上限を決めるだけでは月次のコスト上限にはなりません。

この見方が変わる条件は、後付けと再設定が許可された場合です。制約が外れれば、セッション予算は設計判断を先に迫るものではなく、既存のパイプラインに後から挿せる純粋な保険として扱えます。

よくある質問

Q: 予算に達するとセッションのデータは失われますか。

A: 失われません。セッションは終了ではなく待機状態に入り、履歴とサンドボックスは通常の待機セッションと同じく保持されます。予算を変更または削除すれば作業が自動的に再開します。

Q: 上限を50セントにしたのに53セント使われました。不具合ですか。

A: 仕様です。上限判定はリクエストとリクエストの間で行われ、上限を越えさせたリクエストは受理済みのため完走します。超過はスレッドあたり1モデルリクエスト分に限定されます。

Q: どのモデルでも予算を設定できますか。

A: 公開リスト価格のないモデルを使うエージェントやアドバイザーを含む場合、予算付きセッションの作成は400エラーになります。利用途中で価格のないモデルが混ざった場合は支出を測れなくなり、予算の変更も拒否されるため、削除して再開することになります。

まとめ

Claude Managed Agents のセッション予算は、無人で走るエージェントの費用にドル建ての上限を設ける機能です(2026年8月時点)。上限は公開リスト価格で算定され、モデルトークンに加えてウェブ検索と稼働時間も積まれます。停止はスレッドあたり1リクエスト分だけ上限を超える設計のため、正確な停止点ではなく新規作業の境界として上限額を決めることになります。予算はセッション作成時にしか付けられず、削除すると付け直せないため、導入は作成側のコードと運用手順を含めた設計判断になります。

【用語解説】

• list cost: 公開リスト価格で算定した、セッションが消費した金額の running 合計。契約割引の有無に関わらず定価で数えるため、実際の請求額とは一致しないことがある
• budget_reached: 予算に達したセッションに付く停止理由。終了ではなく待機を意味し、予算の変更か削除で再開する
• デプロイメント: エージェントのセッションを定期的に開始する仕組み。予算は各セッションにコピーされ、1回の実行ごとに適用される

引用元:

• [1] Session budgets(Claude Platform ドキュメント)
• [2] Claude Platform release notes(Claude Platform)
• [3] Multiagent orchestration(Claude Platform ドキュメント)
• [4] Data residency(Claude Platform ドキュメント)

この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。

エージェントの費用管理という観点では、Claude Enterprise の利用分析とコスト管理機能もあわせて読むと理解が深まります: