Claude Managed Agentsのセッション予算とは、1セッションの支出上限のことです。
AIエージェントに商品データの整形や競合調査を任せると、1回の実行でいくらかかるかは終わるまで分かりません。AI評価企業の Vals AI が2026年10月に公開した検証では、同じ Claude Opus 5.5 でも設定の違いだけで1課題あたりの費用が23.77ドルから122ドルへ5.1倍に膨らみました。Anthropic のエージェント実行基盤「Claude Managed Agents」に用意されたセッション予算は、この読めない費用に、1回あたりの上限を先に打ち込むための仕組みです。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル(うるチカラ運営)の現場知見にもとづき、公式ドキュメントの仕様とEC業務での上限の決め方を5つの手順で整理します。
なぜ今「1回あたりの上限」が要るのか:エージェントの費用は終わるまで読めない
セッション予算が必要な理由は、エージェントの費用が「処理件数」ではなく「エージェント自身の判断」で決まるからです。人が書いたプログラムなら、1,000SKUを処理すれば1,000回分の費用で終わります。エージェントは違います。調べ足りないと判断すれば検索を重ね、作業を分けた方が早いと判断すればサブエージェントを起こします。Vals AI の検証では、Claude Opus 5.5 を最大の推論設定でチーム構成にした場合、1つのWebアプリを作るためにサブエージェントだけで中央値2億2,400万トークンを使っていました。この検証の詳細はAIエージェントのチーム化は費用最大5.1倍|効果は4設定中1つのEC3論点で解説しています。
Claude Managed Agents の課金は、モデルのトークン代だけではありません。公式ドキュメントによると、セッションの費用は「モデルのトークン(各モデルの定価)」「Web検索(1,000回あたり10ドル)」「セッションの稼働時間(1時間あたり0.08ドル)」の3つを合計して計算されます。検索を多用する競合調査や、長時間走る夜間バッチでは、トークン以外の項目も無視できない金額になります。
EC事業者にとって厄介なのは、エージェントの使いどころが「定期的に、無人で、大量に」回す業務に集中している点です。毎朝の価格モニタリング、週次の商品マスタ点検、月末の在庫レポート作成など、人が画面を見ていない時間帯に走ります。現場で繰り返し見るのは、検証段階では1回数十円で済んでいた処理が、本番で対象SKUを増やした途端に想定の数倍に跳ね、月末の請求で初めて気づくパターンです。
Anthropic のコンソールには組織やワークスペース単位の月間上限もあります。ただしこれは「月の合計」を止める仕組みで、上限に達すると他の業務も含めてすべて止まります。1本の暴走したセッションが、その月の予算を食い潰して受注処理の自動化まで止めてしまう。セッション予算は、この連鎖を1セッションの単位で断ち切るための、より細かい安全装置という位置づけです。
うるチカラでは以前、Claude Managed AgentsでEC業務エージェントを組む方法を取り上げました。本記事はその続編として、作ったエージェントを本番で安心して回すための「費用の柵」に絞って解説します。
セッション予算の仕組み:定価ベースで測り、上限で一時停止する
セッション予算の要点は、「定価で測る」「リクエストの合間で止める」「止まっても消えない」の3つです。ここを正確に押さえておかないと、上限の数字を決めても期待どおりに止まりません。
設定はセッション作成時の1回だけ
予算はセッションを作成するときに budget という項目で渡します。中身は {"type": "limit", "max_list_cost": {"amount": "500", "currency": "USD"}} のような形で、type は常に limit、金額は「米セントの整数を文字列で書く」決まりです。"500" は5ドル、"50" は50セントを意味し、"25.00" のような小数表記は400エラーで弾かれます。通貨は米ドルのみです。
最も注意すべき制約は、予算は作成時にしか付けられないことです。予算なしで作ったセッションに後から予算を追加しようとすると400エラーになります。「まず動かしてみて、問題がありそうなら上限を付ける」という順番は使えません。本番で動かすセッションは、最初から予算付きで作る運用に揃える必要があります。
測るのは請求額ではなく「定価での利用額」
予算と比べられるのは、セッションが消費したものを公開定価で積み上げた「list cost」です。法人契約で割引を受けている場合でも、上限判定は定価ベースで行われます。つまり実際の請求額は上限より安くなることはあっても、上限を超えて高くなることは原則ありません。社内で予算を説明するときは「定価で見積もった上限」と伝えるのが正確です。
止まるのはリクエストとリクエストの間
上限のチェックは、モデルへの各リクエストを送る直前に行われます。処理中のリクエストを途中で切ることはしません。そのため、上限を超える原因になったリクエストは最後まで実行され、停止時の利用額は上限をわずかに超えます。公式ドキュメントの例では、50セントの上限で53セントで止まるケースが示されています。Claude Cookbook のデモでも、0.10ドルの上限に対して0.12ドルで停止しました。超過分はスレッドごとに最大1リクエスト分で、請求の誤りではありません。
止まったセッションは「一時停止」で、作業は残る
上限に達したセッションは終了せず、budget_reached という停止理由つきでアイドル状態になります。会話履歴もサンドボックス内のファイルもそのまま残ります。上限を引き上げると、止まった作業が自動で再開します。Cookbook のデモでは、0.10ドルで止まったセッションの上限を5ドルに上げたところ、作業が再開して最終的に1.83ドルで完了しました。
上限中のセッションは、新しい仕事を始める user.message を受け付けません。受け付けるのは、ツールの承認結果やツールの実行結果など、すでに進んでいる作業を片づけるイベントだけです。上限を変える場合は、すでに消費した額より高い値にする必要があり、低い値を指定すると400エラーになります。
予算の削除は取り消せない
予算は budget に null を渡すと外せますが、一度外したセッションには二度と予算を付けられません。上限を一時的に緩めたいときは、削除ではなく金額の引き上げで対応するのが安全です。
定期実行と複数エージェントでの扱い
定期実行の「デプロイメント」にも同じ予算を設定できます。この場合の上限は、デプロイメント全体の合計ではなく、そこから起動される1回ごとのセッションに個別に適用されます。5ドルの上限で200回走れば、最大で1,000ドル近くになる計算です。複数のエージェントが協調するマルチエージェント構成では、1つの予算をすべてのスレッドで共有し、スレッドごとの上限はありません。定価が公開されていないモデルを含む構成は、予算付きで作成できない点も覚えておきます。
なお、Messages API には「タスク予算」という似た名前の機能がありますが、こちらはモデルが自分で配分を調整するためのトークン数の目安で、強制力のある上限ではありません。セッション予算は米ドル建てでプラットフォームが強制する、別物の仕組みです。
EC業務で上限を決める5つの手順
ここからは、EC業務にセッション予算を組み込む手順を5つに分けて説明します。各手順で使えるプロンプトを3本用意しました。ChatGPT・Claude・Gemini のどれでも動く書き方にしてあります。
手順1:業務ごとに「1回あたりの実費」を試走で測る
最初にやるのは、自動化したい業務ごとに、1回の実行にいくらかかるかを実測することです。いきなり本番の上限を決めても、根拠がないため緩すぎるか厳しすぎるかのどちらかになります。Cookbook と同じ考え方で、意図的に低い上限(たとえば50セント)を付けて試走し、止まった時点の利用額と作業の進み具合を記録します。これを数回繰り返すと、「この業務は1回あたりおよそいくら」という相場が見えてきます。
試走の前に、自動化候補の業務を棚卸ししておくと測定がぶれません。次のプロンプトで、業務ごとの特徴と測定方法を整理できます。
プロンプト1:エージェント化する業務の棚卸しと試走計画
あなたはEC事業のAI運用設計に詳しいコンサルタントです。
以下の業務リストを、AIエージェントで自動化する前提で整理してください。
業務リスト:
{業務名1:例 毎朝の競合価格チェック(対象{SKU数}件)}
{業務名2:例 週次の商品マスタ表記ゆれ点検(対象{SKU数}件)}
{業務名3:例 月末の在庫・売上レポート作成}
各業務について次の6項目を出してください。
1. 1回の実行で処理する件数の目安
2. Web検索が発生するか(する場合は1件あたりの想定回数)
3. 1回の実行にかかる想定時間
4. 失敗したときの影響の大きさ(大・中・小)と理由
5. 試走で測るべき指標(利用額、処理件数、所要時間など)
6. 試走の進め方(少ない件数から段階的に増やす手順)
最後に、試走を行う順番を「影響が小さく、測りやすい業務」から並べて提案してください。
手順2:上限は「実測の上振れ+1リクエスト分」で決める
上限の決め方の基本は、試走で測った1回あたりの費用のうち、高めに出た回を基準にして、そこに余白を足すことです。平均値を上限にすると、半分近くの実行が途中で止まってしまいます。余白には、停止時に必ず生じる「1リクエスト分の超過」も含めて考えます。運用上の目安としては、試走5回のうち最も高かった回の1.5倍を初期の上限にし、1か月運用してから見直す方法が扱いやすいでしょう。
ここで効いてくるのが、対象件数との関係です。競合価格チェックの対象を100SKUから500SKUに広げれば、1回あたりの費用もおおむね比例して増えます。件数を変えたら上限も見直す、という運用ルールを先に決めておきます。上限を件数と連動させておけば、担当者が対象を増やしたときに上限だけが古いまま、という事故を防げます。
手順3:定期実行はデプロイメントに予算を付ける
毎朝や毎週の定期実行は、デプロイメントに予算を設定して、起動されるすべてのセッションに上限が付く状態にします。デプロイメントの予算は、セッションと違って一度外しても再設定できるため、運用しながら調整しやすいのが利点です。公式ドキュメントの例では "amount": "2000"、つまり1回20ドルの上限が示されています。
ただし前述のとおり、デプロイメントの予算は1回ごとの上限で、合計の上限ではありません。毎日1回20ドル上限の業務なら、月30日で最大600ドルが理論上の上限です。月の合計を管理したい場合は、コンソール側の月間上限と組み合わせます。
エージェントの指示文の側でも、作業範囲をはっきり書いておくと上限に当たりにくくなります。調べる範囲が曖昧なまま「徹底的に調べて」と指示すると、エージェントは際限なく検索を重ねます。Cookbook のデモでも、調査範囲を区切らない指示のエージェントは、0.10ドルに達するまでに11回のWeb検索を行っていました。
プロンプト2:作業範囲を区切ったエージェント指示文の作成
あなたはAIエージェントの指示文(システムプロンプト)を設計する専門家です。
以下の業務を担当するエージェントの指示文を作成してください。
業務内容:{業務の説明}
対象:{対象SKU数や対象ページ数}
使えるツール:{Web検索、Webページ取得、ファイル書き込みなど}
指示文には次の要素を必ず含めてください。
1. 調査する対象の上限(件数、サイト数、検索回数の目安)
2. 情報が見つからない場合に打ち切る条件(例:同じ項目で3回検索して見つからなければ「不明」と記録して次へ進む)
3. 作業を分割してサブエージェントに任せてよい条件と、任せてはいけない条件
4. 途中経過をファイルに保存するタイミング(止まっても再開できるように)
5. 最終的な出力ファイルの形式と保存先
指示文は日本語で、箇条書きを使わず段落で書いてください。
手順4:上限到達を通知で受け取り、人が判断する
上限に達したセッションは静かにアイドルになるため、誰も気づかなければ作業は止まったままです。Cookbook では、ストリームを開きっぱなしにする代わりに session.budget_reached のWebhookを購読する方法が推奨されています。このイベントはセッションごとに1回だけ届き、どのセッションが止まったかが分かるため、Slackなどに転送して担当者が「上限を上げて続けるか、止めたままにするか」を判断する流れを作れます。
判断の材料として、止まった時点の作業状況を短く要約させると便利です。次のプロンプトは、イベントログや途中経過のファイルを渡して、上限を上げるべきかの判断材料を作らせるものです。
プロンプト3:上限到達時の判断レポート作成
あなたはEC事業のAI運用を監督する担当者の補佐です。
AIエージェントの作業が、費用の上限に達して一時停止しました。
以下の情報から、担当者が「上限を上げて続けるか」を判断するためのレポートを作成してください。
業務内容:{業務の説明}
設定していた上限:{上限額} 米ドル
停止時点の利用額:{利用額} 米ドル
処理済み件数/全体件数:{処理済み}/{全体}
途中経過の要約またはログの抜粋:{ログ}
レポートには次の4点を含めてください。
1. ここまでで完了した作業と、残っている作業
2. 残りを終えるのに必要な追加費用の見込みと、その計算根拠
3. 費用が想定より膨らんだ原因の推測(検索回数、件数の増加、作業の分割など)
4. 推奨する対応(上限を上げて続ける/止めて指示文を見直す/対象を絞って再実行する)とその理由
推測の部分は「推測」と明記してください。
手順5:月次の上限と二重にかけ、見直しを定例化する
最後に、セッション予算を「最後の砦」にしないことです。Cookbook も、セッション予算は組織・ワークスペース・日次の上限を置き換えるものではなく、組み合わせて使うものだと明記しています。1回ごとの上限で暴走を止め、月の上限で全体の予算を守る、という二重の柵にします。
そのうえで、月に1回、業務ごとの「上限到達回数」と「1回あたりの平均費用」を見直す時間を取ります。上限に頻繁に当たる業務は、上限が低すぎるか、指示文の作業範囲が広すぎるかのどちらかです。逆に一度も当たらない業務は、上限を下げても問題ない可能性があります。
よくある失敗例と回避策
1つ目は、予算なしで本番セッションを作ってしまう失敗です。試作のときに予算を付けずに作ったコードを、そのまま本番に流用すると起きます。前述のとおり、予算は後から付けられません。回避策は、セッションを作成する処理を1か所にまとめ、予算の指定がない呼び出しはエラーにするなど、仕組みで漏れを防ぐことです。
2つ目は、デプロイメントの上限を月の予算だと誤解する失敗です。「デプロイメントに100ドルの上限を付けたから安心」と考えていたら、実際には1回100ドルまで使える設定で、毎日走れば月3,000ドルの枠になっていた、という勘違いです。上限を決めるときは「1回あたり×実行回数」で月の最大額を必ず計算し、社内の稟議資料にもその数字を書きます。
3つ目は、上限に当たるたびに予算を削除して続けてしまう失敗です。急いでいると、上限を引き上げる代わりに予算そのものを外したくなります。しかし削除は取り消せず、そのセッションは以後、上限なしで動き続けます。止まったら金額を引き上げる、という対応を手順書に明記しておきます。
KPI設計と費用の目安
運用の良し悪しは、3つの数字で測れます。1つ目は「業務1回あたりの平均利用額」で、月ごとの推移を見ます。2つ目は「上限到達率」で、全実行のうち何%が上限で止まったかを示します。立ち上げ直後は上限に当たる実行が一定数出るのが普通で、指示文の作業範囲を絞るにつれて下がっていきます。たとえば「上限到達率5%以下」のような基準を業務ごとに社内で決めておくと、見直しの判断がしやすくなります(数値は運用上の目安で、業務によって適正値は異なります)。3つ目は「上限到達から再開までの時間」で、通知の仕組みがうまく回っているかを確認できます。
費用の構造も整理しておきます。稼働時間の料金は1時間0.08ドルなので、1日1時間の処理を30日回しても稼働時間分は2.4ドルです。Web検索は1,000回で10ドルなので、1回の実行で50回検索する業務を毎日回すと、検索代だけで月15ドルになります。残りがモデルのトークン代で、ここが業務ごとに最も差が出る部分です。仮に1ドル=150円で換算すると、1回1ドルの業務を毎日回して月4,500円、1回20ドルの業務なら月9万円が上限の目安になります。
今後の展望:エージェント時代の予算管理は「仕事単位」へ
セッション予算の登場は、AIの費用管理の単位が「月の合計」から「仕事1件ごと」に移りつつあることを示しています。人に仕事を頼むときに「この調査は3万円の範囲で」と決めるのと同じ発想が、AIエージェントにも持ち込まれた形です。
EC事業者にとっての次の論点は、業務ごとの「1件あたりの適正価格」を社内で持てるかどうかです。競合価格チェック1回いくら、商品マスタ点検1,000SKUでいくら、という相場が分かれば、外注と比較した費用対効果の判断や、自動化する業務の優先順位づけがしやすくなります。セッション予算は単なる安全装置ではなく、この相場を測るための計測器としても使えます。
うるチカラでは、Anthropic の営業チームが Managed Agents で問い合わせ対応を作り直した事例も紹介しています。エージェントを本番業務に入れる企業が増えるほど、費用の柵を最初から設計に組み込んでいるかどうかが、運用を続けられるかを分ける要素になると見ています。
よくある質問
Claude Managed Agentsのセッション予算とは何ですか
セッション予算とは、Claude Managed Agents の1セッションが使える金額に、米ドル建ての上限をかける機能のことです。トークン代、Web検索代、稼働時間の料金を定価で合計し、上限に達すると次のリクエストを送らずに一時停止します。作業内容は残るため、上限を上げれば続きから再開できます。
予算は後から追加できますか
いいえ、後から追加はできません。予算はセッションを作成するときにしか付けられず、予算なしで作ったセッションに追加しようとすると400エラーになります。本番で使うセッションは最初から予算付きで作成する運用にしてください。
上限ちょうどで止まらないのはなぜですか
上限のチェックがリクエストを送る直前に行われるためです。上限を超える原因になったリクエストは最後まで実行されるので、停止時の利用額は上限をわずかに上回ります。超過分はスレッドごとに最大1リクエスト分で、公式ドキュメントでも想定どおりの挙動とされています。
割引契約があっても上限は定価で判定されますか
はい、定価で判定されます。セッション予算は公開定価で計算した利用額と比べるため、割引契約がある場合は実際の請求額が上限より低くなります。社内では「定価ベースの上限」として説明すると誤解がありません。
デプロイメントの予算は月の合計ですか
いいえ、1回ごとの上限です。デプロイメントに設定した予算は、そこから起動される各セッションにコピーされ、それぞれに個別に適用されます。月の合計を抑えたい場合は、1回あたりの上限×実行回数で最大額を計算し、コンソールの月間上限と組み合わせてください。
上限に達したら予算を削除して続けてもよいですか
おすすめしません。予算の削除は取り消せず、そのセッションには二度と予算を付けられないからです。続けたい場合は、すでに使った額より高い金額に上限を引き上げれば、止まった作業が自動で再開します。
まとめ
Claude Managed Agents のセッション予算は、終わるまで費用が読めないAIエージェントに、1回あたりの上限を先に決めるための機能です。予算は作成時にしか付けられない、上限は定価で判定される、停止は一時停止で作業は残る、という3つの性質を押さえたうえで、業務ごとの実測、余白を持った上限設定、デプロイメントへの設定、上限到達の通知、月次上限との併用という5つの手順で組み込みます。最初の一歩は、自動化したい業務を1つ選び、50セント程度の低い上限で試走して1回あたりの実費を測ることです。
参考文献
- Claude Platform Docs・Session budgets
- Claude Cookbook・Budgets: cap what a session can spend
- Claude Platform Docs・Task budgets
- Vals AI・Do Agent Teams Pay Off? A Case Study on Vibe Code Bench
著者:齋藤竹紘(株式会社オルセル 編集長/5,000社以上のEC支援実績/書籍3冊)
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談(30分)も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘(株式会社オルセル代表 / 19年・5,000社のEC支援実績)

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。