著者 Matt Connor
常時稼働AI agentの料金を抑える方法
無人のAI agentはループごとに課金されます。上限、タスク予算、プロンプトキャッシュ、バッチ処理を使い、使用量フィールドで支出を記録する方法を解説します。
常時稼働する AI agent の料金を制御する方法
VPS（virtual private server）上の AI agent のコスト管理では、agent の起動前に上限を設定することが重要です。実行中に使用量を監視する人がいないためです。max_tokensですべての応答に上限を設定し、自分のコードでループ回数を制限し、変化しないプロンプト部分をキャッシュし、すべての応答の使用量をログに記録して、どのジョブがコストを消費しているか確認します。サーバーのレンタル料金は月額固定です。Model API は token 単位で従量課金されるため、監視されていないループは気付かないうちに token を大量に消費します。
ここでは、すでに構築済みで、所有するサーバーから Messages API を呼び出す agent を前提とします。VPS 上で Claude を使用して AI agent を構築するでは、agent 自体の仕組みを説明します。
無人エージェントでコスト構造が変わる理由
対話セッションには人間が参加しています。モデルが誤った方向に進んだり、40,000 行のログを読み込んだりしても、監視している人が停止できます。無人エージェントには、そのような制止役がありません。ループが終了するまで実行し、その後タイマーによって再び起動します。
見落とされやすいのが実行頻度です。5 分間隔で実行するジョブは、1 日に 288 回、1 か月に約 8,640 回実行されます。1 回の実行にかかるコストに、この回数を掛けます。「常時稼働」とされるエージェントの多くは、常時起動している必要がありません。数分以内に応答できればよく、その要件はスケジュールで実現できます。
エージェントには、チャットウィンドウにはないコストも発生します。
- ツール定義はすべてのリクエストに付加されます。 ツール使用用のシステムプロンプトは、
tool_choiceのautoまたはnoneを使用する Claude Opus 4.8 では 290 トークン、anyまたはtoolを使用する場合は 410 トークンです。bash ツールによって、さらに 325 トークンが加わります。接続する MCP サーバー ごとにスキーマが追加されるため、その分だけ増加します。MCP は model context protocol を指します。 - ツールの結果は入力トークンとして扱われます。 8,000 行を出力するコマンドを実行すると、その 8,000 行が次のリクエストに入り、そのターン内の後続のすべてのリクエストにも含まれます。
- 取得したページは入力トークンとして扱われます。 平均的な 10 kB の Web ページは約 2,500 トークン、500 kB の調査用 PDF は約 125,000 トークンに相当します。
max_content_tokensはテキストだけを切り詰めます。これは「PDF などのバイナリコンテンツではなく、テキストコンテンツに適用される」ためです。PDF には代わりにmax_usesとallowed_domainsで上限を設定します。 - Web 検索は検索単位で課金されます。 料金は検索 1,000 回あたり $10 で、返される結果の数は影響しません。エラーになった検索には課金されません。
これらは、1 回だけなら高額ではありません。しかし、すべてが 8,640 回分積み重なります。
ハード上限とソフト上限は異なる問題を解決します
max_tokens は強制されます。 これは、思考と応答テキストを合わせた 1 回のリクエスト全体の出力に対するハード上限です。Claude はこの上限を超えて生成せず、モデル自体はその数値を認識できません。上限に達すると stop_reason: "max_tokens" が返され、回答は途中で切り詰められます。エージェントでは、ツール使用ループ内の各リクエストにそれぞれ max_tokens が適用される点に注意してください。つまり、タスク全体ではなく 1 回の応答を制限します。4,000 で 10 回ツールを呼び出す場合、そのターンの上限は 40,000 トークンです。
タスク予算は参考値です。 task_budget は output_config の範囲内にあり、思考、ツール呼び出し、ツールの結果、出力を含むエージェントループ全体で使用できるトークン数をモデルに伝えます。
resp = client.beta.messages.create(
model="claude-opus-4-8",
max_tokens=4096,
betas=["task-budgets-2026-03-13"],
output_config={"task_budget": {"type": "tokens", "total": 64000}},
messages=messages,
)「タスク予算はソフトな目安であり、ハード上限ではありません。」Claude は処理の途中でこの予算を超えることがあり、出力に強制される上限は引き続き max_tokens です。「カウントダウンを確認できるのはモデルだけ」であり、応答に残りの予算を示すフィールドはありません。受け付けられる task_budget.total の最小値は 20,000 トークンで、それ未満を指定すると 400 エラーが返されます。作業に対して予算が小さすぎると、拒否に似た動作が発生します。そのため、モデルはタスクの範囲を縮小するか、早い段階で停止します。
1 つの設定が、節約ではなくコスト増につながることがあります。クライアントがフォローアップリクエストごとに task_budget.remaining を減算すると、変更された値によって、その値を含むキャッシュ済みプレフィックスが無効になります。最初のリクエストで 1 回だけ設定してください。
タスク予算は Claude Fable 5.1、Claude Fable 5、Claude Opus 5.5、Claude Opus 5、Claude Opus 4.8、Claude Opus 4.7、Claude Sonnet 5.5、Claude Haiku 5.5 でベータ版として提供されています。Claude Sonnet 5 と Claude Haiku 4.5 は Not supported と記載されています。また、タスク予算は Claude Code には適用されません。そのため、tmux でデタッチした Claude Code セッションでは、代わりにセッションの適切な管理が重要になります。
3 つ目の上限は Claude Console にあります。エージェント専用のワークスペースを作成し、そのワークスペースに月間支出上限と 1 分あたりのレート制限を設定します。「Default Workspace には制限を設定できません」。また、「組織全体の上限は、ワークスペースの上限を合計するとそれを超える場合でも常に適用されます」。支出通知も追加し、上限に達する前にしきい値の通知を受け取れるようにしてください。
ジョブごとのモデル選択と、実際に効果がある調整
モデルの選択はジョブごとに行います。2026 年 10 月時点の 100 万トークンあたりの料金は、入力、出力の順に、Claude Fable 5.1 と Fable 5 が $10 と $50、Claude Opus 5.5 が $4 と $20、Claude Opus 5、Opus 4.8、Opus 4.7 が $5 と $25、Claude Sonnet 5.5 と Sonnet 5 が $2 と $10、Claude Haiku 5.5 が 100,000 トークンまで $0.10 と $0.50（それを超える場合は $0.50 と $2.50。キャッシュされたトークンも件数に含まれます）、Claude Haiku 4.5 が $1 と $5 です。Anthropic は当初、Sonnet 5 を導入価格としてその料金で提供し、その後に標準価格へ変更して、予定していた $3 と $15 への値上げを中止しました。ログ行を分類するだけの処理に Opus は必要ありません。
負荷の高いスケジュールを無料利用で吸収できるとは考えないでください。Claude API のサインアップ時に付与される少額のクレジットを除くと、継続的に利用できる枠は Claude Max と Team プランに含まれる月次の API クレジットだけです。Max 5x は $100、Max 20x は $200、Team は共有枠として最大 $500 で、請求サイクルごとに更新されます。対象プランでは 7 日後に請求でき、支払い方法の登録は不要です。このクレジットは Claude API、Managed Agents、Agent SDK、playground には使用できますが、Claude Code には使用できません。各サイクルの終了時に失効し、繰り越されません。使用額は支出上限に加算され、使い切ると、組織が購入済みクレジットも保有していない限りリクエストは停止します。
2 つ目の調整要素は effort です。output_config.effort は low、medium、high、xhigh、max を受け付けますが、すべてのモデルがすべてのレベルに対応するわけではありません。ほとんどのモデルのデフォルトは high、Claude Opus 5.5 と Claude Haiku 5.5 のデフォルトは medium です。モデルのデフォルトを明示的に設定しても、省略した場合と同じです。effort を下げると、推論の長さだけでなく、ツール呼び出しの回数も減ります。ドキュメントによると、Claude は複数の操作を少ない呼び出しにまとめるようになります。エージェントではこの効果が大きく、回避されたツール呼び出しは、発生しなかったリクエスト全体に相当するためです。
注意点は、effort の変更がキャッシュと競合することです。リクエスト間でトップレベルの値を変更すると、プロンプトキャッシュが無効になります。Claude Opus 5.5 のドキュメント例では、リクエスト 2 が cache_read_input_tokens: 3546 を報告しました。リクエスト 3 では、そのモデルのデフォルトである medium から low に effort を変更し、3546 の cache_creation_input_tokens と 0 の cache_read_input_tokens を報告しました。そのため、ワークロード間ではトップレベルの effort を変更しても、1 つのキャッシュ済み会話の途中では変更しないでください。キャッシュを壊さずに深さを変更する方法は 2 つあります。Claude Fable 5.1、Opus 5.5、Opus 5、Sonnet 5.5、Haiku 5.5 では、メッセージ単位の effort 変更（beta、ヘッダー mid-conversation-output-config-2026-07-01）によって新しいレベルを設定でき、キャッシュ済みのプレフィックスは維持されます。どのモデルでも、代わりにプロンプトで指定できます。たとえば、最新の user メッセージに「熟考せず、直接回答してください。」という行を追加すると、それ以前のブレークポイントは維持されます。ただし Claude Haiku 5.5 では、この文によって思考が確実に減るわけではありません。
思考トークンは出力料金で課金され、max_tokens にも加算されます。そのため、回答が途中で切れる場合は、思考処理が予算を使い切った可能性があります。数値は usage.output_tokens_details.thinking_tokens で確認してください。Claude のトークン料金を実際に構成する要素で、メーターの内訳を説明します。
安定したプレフィックスをキャッシュし、誤って壊さない
5 分間キャッシュへのキャッシュ書き込みには、基になる入力料金の 1.25 倍がかかります。1 時間キャッシュでは 2 倍です。ほとんどのモデルではキャッシュ読み取りの料金が 0.1 倍であるため、「5 分間の有効期間では 1 回のキャッシュ読み取りで元が取れます（書き込みは 1.25 倍）。1 時間の有効期間では 2 回のキャッシュ読み取りで元が取れます（書き込みは 2 倍）」。最新モデルでは読み取り料金がさらに安く、Claude Opus 5.5 と Claude Sonnet 5.5 では 0.05 倍、Claude Fable 5.1 では 0.025 倍です。
常時稼働するエージェントに適している理由は、次の 1 行で説明できます。「キャッシュされたコンテンツが使用されるたびに、追加料金なしでキャッシュが更新されます」。5 分間キャッシュに対して 2 分ごとに実行されるジョブなら、1 回の書き込みで 1 日中プレフィックスをウォーム状態に保てます。
気付かないうちにキャッシュを失う原因は 3 つあります。
変化するプレフィックス。「キャッシュプレフィックスは、次の順序で作成されます: tools、system、続いて messages」。この順序で前の部分に 1 バイトでも変更があると、それ以降のすべてが無効になります。ツール定義を編集すると、キャッシュ全体が無効になります。典型的な自損事故は、システムプロンプトにタイムスタンプや実行 ID を含めることです。この場合、すべてのリクエストで異なるプレフィックスが送信されるため、1.25 倍の料金で新しいエントリに書き込み、キャッシュから何も読み取れません。同じように見える呼び出しで usage.cache_read_input_tokens が 0 になることが、その兆候です。変動するテキストは、最新のユーザーメッセージに移してください。
短すぎるプレフィックス。各モデルにはキャッシュ可能な最小長があり、それを下回るリクエストはキャッシュなしで処理されます。「エラーは返されません」。数値は、Claude Fable 5.1、Fable 5、Opus 5.5、Opus 5、Sonnet 5.5、Haiku 5.5 では 512 トークン、Claude Opus 4.8 と Claude Sonnet 5 では 1,024 トークン、Claude Haiku 4.5 では 4,096 トークンです。そのため、ジョブを Sonnet 5 から Haiku 4.5 に移すと、キャッシュが何も通知されずに無効になることがあります。
会話がルックバック範囲を超える。「ルックバックウィンドウは 20 ブロックです」。システムはブレークポイントごとに最大 20 個の位置を確認し、その後は停止します。ドキュメントの例では、35 ブロックを含むターンのブロック 35 にブレークポイントを設定すると、ブロック 35 から 16 までが確認されます。前のターンのブロック 15 にあるエントリはウィンドウの範囲外になるため、ヒットしません。1 ターンに複数のツール使用ブロックとツール結果ブロックを追加するエージェントアプリでは、2、3 ターンで 20 ブロックを超えます。リクエストごとに 4 つのブレークポイントを使えるため、そのうち 1 つを直近のメッセージに割り当ててください。
待機可能な処理は Batches API に送る
入力と出力の両方で、「すべての利用料金が標準 API 料金の 50%」になります。バッチ処理は非同期で、「ほとんどのバッチは 1 時間未満で完了します」。結果が返るのは、すべてのリクエストが完了した時点、または 24 時間後のいずれか早い方です。これは通常の目安であり、保証ではありません。
processing_status が ended になるまでポーリングします。errored、canceled、または expired を返すリクエストには課金されません。利用上限を設定している場合は、1 点注意が必要です。「バッチによって、Workspace に設定された利用上限をわずかに超える場合があります」。
割引は重ねて適用できます。また、バッチは 5 分を超えることがあるため、ドキュメントでは、コンテキストを共有するバッチに 1 時間のキャッシュを推奨しています。処理を分けてください。人や webhook が待つ処理はライブ処理に残し、夜間のダイジェスト生成や前日のログ分類は、料金が半額になるバッチに回します。
すべてのレスポンスの使用量フィールドを独自の保存先に記録する
記録していない支出を割り当てることはできません。すべてのレスポンスには、その処理にかかったコストが含まれます。
u = resp.usage
row = {
"job": job_name,
"model": resp.model,
"uncached_input": u.input_tokens,
"cache_write": u.cache_creation_input_tokens,
"cache_read": u.cache_read_input_tokens,
"output": u.output_tokens,
"stop_reason": resp.stop_reason,
}API 呼び出しごとに 1 行を JSON Lines ファイルへ追記し、ジョブ名を付けます。1 週間後には、どのジョブが支出し、どのジョブが処理しているように見えるだけなのかを確認できます。cache_read を監視してください。値がすべて 0 の列は、セルフホスト型エージェントで最もよくあるコスト計測のバグです。
誤読しやすいフィールドがあります。input_tokens は、最後のキャッシュブレークポイント以降のトークンだけを数えるため、実際のプロンプトサイズは total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens です。大きなプロンプトで input_tokens: 400 を報告するエージェントが、低コストとは限りません。残りはキャッシュから提供されています。
送信前に数えてください。トークン数の計測は無料で、レート制限もメッセージ作成とは別です。そのため、送信してから判明するのを待たず、count_tokens を使ってサイズ超過の添付ファイルを拒否します。結果は推定値なので、モデルごとに再計測し、別ベンダーの tokenizer で得た値を再利用しないでください。Claude Fable 5 と Claude Sonnet 5 を含む Claude 4.7 以降のモデルは、新しい tokenizer を使用します。この tokenizer は「同じテキストに対して約 30% 多くのトークンを生成」します。Claude Haiku 4.5 を含む Claude Sonnet 4.6 以前のモデルは、従来の tokenizer を使用します。
正確な情報を確認するには、Admin API で https://api.anthropic.com/v1/organizations/usage_report/messages に使用量、https://api.anthropic.com/v1/organizations/cost_report にコストが表示されます。どちらも admin key (sk-ant-admin01-...) を x-api-key: $ANTHROPIC_ADMIN_KEY として anthropic-version: 2023-06-01 とともに指定します。使用量レポートでは bucket_width=1d、group_by[]=model、api_key_ids[]= を指定できます。コストレポートは日次のみで、workspace_id または description でグループ化します。制限が 1 つあります。「Admin API は個人アカウントでは利用できません。」
api_key_ids[] パラメーターは、低コストで割り当てる方法です。ジョブごとに専用の API key を用意し、api_key_ids[] で使用量レポートを絞り込み、group_by[]=api_key_id で key ごとに分割します。フィルターは複数形で、グループ化のディメンションは単数形です。VPS 上で最初の Claude API アプリを構築する方法と同じように、key はコードではなく環境変数に保存してください。
ループに上限を設ける。ほかの仕組みは止めてくれない
ここでは反復回数の上限が必須です。ループを実装するのは自分なので、カウンターも自分で管理します。
for step in range(MAX_STEPS): # MAX_STEPS = 12, never "while True"
resp = client.messages.create(...)
if resp.stop_reason != "tool_use":
break
else:
log.warning("job %s hit MAX_STEPS=%d, giving up", job_name, MAX_STEPS)上記のどちらの上限も、この処理を代替しません。max_tokens は 1 回の応答を制限するだけで、モデルにはタスクの予算が通知されるだけです。ホスト型の製品なら、1 回のターン内のツール呼び出しに対する Claude の上限のように、呼び出し回数が多すぎるセッションを停止します。しかし、自分で作成したループには、上限を追加するまでこのような安全装置はありません。
プロセスの外側にも、別の停止条件を設けます。ジョブを常駐プロセスではなく systemd timer から実行し、service unit に実時間の上限を設定します。timer ジョブは通常 Type=oneshot であり、RuntimeMaxSec= は「Type=oneshot サービスには効果がない」ため、そこで TimeoutStartSec=600 を設定します。RuntimeMaxSec=600 は Type=simple unit でのみ使用してください。いずれの場合も、ハングした実行は気付くまで動き続けるのではなく、10 分後に強制終了されます。unit ファイル自体については、プログラムを systemd service と timer として実行するで説明しています。実行結果は journalctl -u triage-agent.service --since "1 hour ago" で確認します。
リトライにも上限を設けます。ハンドラーが無期限にリトライすると、試行のたびにコストが発生するためです。429 や 500 には、バックオフを入れて数回試行する価値があります。一方、400 では同じリクエストが同じ理由で失敗するため、リトライは不要です。
AI エージェントのコスト管理は、自分の使用量を確認することから始まります
常時稼働するエージェントのコストを他人が判断することはできません。コストは、1 回の実行で消費するトークン数に 1 日あたりの実行回数を掛けた値であり、その両方は利用者が決めるからです。1 回実行し、記録した使用量の行を確認して、スケジュールに基づいて計算します。2 日後にコストレポートを確認し、その計算結果と照合します。両者が一致しない場合、ほとんどの場合はキャッシュの破損か、想定より長く実行されたループが原因です。
ここでは、API key を使用することを前提とします。エージェントは、利用者自身のプログラムとして Messages API を呼び出すためです。自分の対話的な作業については、作業方法に合う Claude のプランでサブスクリプション側の選択を確認できます。ここに記載する料金と上限は、2026 年 10 月に Anthropic のドキュメントと照合済みです。予算を作成する前に、料金ページを再確認してください。
FAQ
常時稼働する AI agent を VPS で運用するには、どのくらいの費用がかかりますか？
請求は 2 種類あり、予測できるのは 1 つだけです。サーバー料金は月額固定です。Model API は token 単位の従量課金であるため、1 回の実行で消費する量に実行回数を掛けた金額が費用になります。Anthropic は self-hosted の常時稼働 agent について具体的な金額を公開していないため、提示された数字は推測として扱ってください。実際の 1 回の実行から usage を記録し、実行スケジュールに基づいて計算してください。
max_tokens と task budget の違いは何ですか？
max_tokens は model に見えない形で強制されます。1 回の request の出力を、思考を含めて制限し、上限に達すると stop_reason: "max_tokens" になります。Task budget はその反対です。model に数値を伝え、その範囲内で agentic loop の進行を調整させます。ただし、「Task budgets are a soft hint, not a hard cap」であり、実際に強制される上限は max_tokens です。
agent の cache_read_input_tokens が常に 0 なのはなぜですか？
呼び出しごとに prefix が変わっているか、cache の対象にするには短すぎることが原因です。よくある原因は、system prompt に timestamp や run id を埋め込んでいることです。cache は prefix をキーにするため、1 byte でも変わると、それ以降のすべてが無効になります。tool definitions やトップレベルの effort の値を変更した場合も同様です。それ以外ではサイズが原因です。短い prompt は cache されず、エラーも返されません。
AI agent が無限にループするのを止めるにはどうすればよいですか？
loop code で iteration 数を数え、固定した最大値で停止してください。max_tokens は 1 回の response を制限するだけであり、agent は複数回実行するためです。process の外側にも wall-clock の制限を追加します。systemd timer から job を開始し、oneshot unit には TimeoutStartSec= を、simple unit には RuntimeMaxSec= を設定すると、停止しない実行をスケジュールどおりに終了できます。retry loop では試行ごとに課金されるため、retry 回数にも上限を設定してください。
1 つの Claude API key に支出上限を設定できますか？
文書化されている支出上限は key 単位ではなく workspace 単位です。そのため、agent 専用の workspace を用意し、そこで月間支出の上限を設定してください。「You cannot set limits on the Default Workspace」。支出通知も追加し、しきい値に達した時点で先に通知されるようにします。利用状況を job 別に識別するには、job ごとに専用の key を発行し、group_by[]=api_key_id を使って usage report をグループ化してください。