著者 常時稼働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、Claude Opus 4.8、Claude Opus 4.7 でベータ版です。Claude Sonnet 5 と Claude Haiku 4.5 は Not supported と記載されています。また、タスク予算は Claude Code には適用されません。そのため、tmux から切り離した Claude Code セッション では、セッションを適切に管理する必要があります。
3 つ目の上限は Claude Console にあります。エージェント専用のワークスペースを用意し、そのワークスペースに月間利用額の上限と 1 分あたりのレート制限を設定します。「Default Workspace には制限を設定できません」。また、「Organization 全体の制限は、ワークスペースごとの制限の合計がそれを上回る場合でも、常に適用されます」。上限に達する前にしきい値を通知できるよう、利用額の通知も追加してください。
ジョブごとのモデル選択と、実際に効果がある調整
モデルの選択はジョブごとに行います。2026 年 7 月時点で、100 万トークンあたりの料金は、入力、出力の順に、Claude Fable 5 が $10 と $50、Claude Opus 4.8 および Opus 4.7 が $5 と $25、Claude Sonnet 5 が $3 と $15、Claude Haiku 4.5 が $1 と $5 です。Sonnet 5 は現在、表示価格より低い料金が適用されています。「入力/出力トークン 100 万件あたり $2/$10 の導入価格が 2026 年 8 月 31 日まで適用されます」。ログ行を分類するだけのステップに Opus は必要ありません。利用量の多いスケジュールを吸収できる無料枠もありません。Claude API には無料プランがないためです。ただし、登録時に付与される少額のクレジットはあります。
2 つ目の調整項目は effort です。output_config.effort は low、medium、high、xhigh、max を受け付けます。デフォルトは high なので、high を明示的に設定しても、省略した場合と同じです。effort を下げると、推論の長さだけでなく、ツール呼び出しの回数も減ります。ドキュメントによると、Claude は複数の操作を 1 回にまとめるようになります。エージェントでは、この効果による節約がより大きくなります。回避できたツール呼び出しは、発生しないリクエスト全体に相当するためです。
注意点は、effort の変更がキャッシュと競合することです。リクエスト間で値を変更すると、プロンプトキャッシュが無効になります。ドキュメントの例では、リクエスト 2 は cache_read_input_tokens: 3546 を報告しました。effort を high から medium に変更したリクエスト 3 は、3546 のうち cache_creation_input_tokens、0 のうち cache_read_input_tokens を報告しました。そのため、ワークロードごとに effort を変え、1 つのキャッシュ済み会話の途中では変更しないでください。キャッシュを無効にせず深さを調整するには、プロンプトで指示します。最新の user メッセージに「考え込まず、直接回答してください。」のような 1 行を追加すれば、以前のブレークポイントは維持されます。
思考トークンは出力料金で課金され、max_tokens に算入されます。そのため、回答が途中で切れる場合は、思考処理が予算を消費していることがよくあります。数値は usage.output_tokens_details.thinking_tokens で確認してください。Claude のトークン料金を実際に構成する要素で、料金メーターの内訳を確認できます。
安定したプレフィックスをキャッシュし、誤って壊さない
キャッシュへの書き込みには、5 分間のキャッシュでは基準入力価格の 1.25 倍、1 時間のキャッシュでは 2 倍のコストがかかります。キャッシュからの読み取りは 0.1 倍です。そのため、「5 分間のキャッシュでは 1 回の読み取りだけで元が取れます（書き込みは 1.25 倍）。1 時間のキャッシュでは 2 回の読み取りで元が取れます（書き込みは 2 倍）」。
常時稼働するエージェントに適している理由は、次の 1 行で説明できます。「キャッシュされたコンテンツが使用されるたびに、追加料金なしでキャッシュが更新されます」。5 分間のキャッシュに対して 2 分ごとに実行するジョブなら、1 回の書き込みで終日プレフィックスをウォーム状態に保てます。
気付かないうちにキャッシュを失う原因は 3 つあります。
変化するプレフィックス。「キャッシュのプレフィックスは、次の順序で作成されます: tools、system、messages」。この順序で前方にある内容のバイトが 1 つでも変わると、その後の内容がすべて無効になります。ツール定義を編集すると、キャッシュ全体が無効になります。よくある自損事故は、システムプロンプトにタイムスタンプや実行 ID を入れることです。するとリクエストごとに異なるプレフィックスが送られ、1.25 倍の料金で新しいエントリが書き込まれる一方、キャッシュからは何も読み取られません。同じように見える呼び出しで usage.cache_read_input_tokens が 0 になることが兆候です。変動するテキストは、最新のユーザーメッセージに移してください。
短すぎるプレフィックス。モデルごとにキャッシュ可能な最小長があり、それを下回るリクエストはキャッシュなしで処理されます。「エラーは返されません」。数値は Claude Opus 4.8 と Claude Sonnet 5 では 1,024 トークン、Claude Haiku 4.5 では 4,096 トークンです。そのため、ジョブを Sonnet から Haiku に移すと、キャッシュが静かに無効になることがあります。
会話がルックバック範囲を超える。「ルックバックウィンドウは 20 ブロックです」。システムは各ブレークポイントについて最大 20 個の位置を確認し、その後は停止します。ドキュメントの例では、ブロック 35 にブレークポイントを置いたターンが 35 ブロックを保持している場合、ブロック 35 から 16 までを確認します。前のターンのブロック 15 にあるエントリはウィンドウの範囲外になるため、ヒットしません。1 ターンに複数の tool-use ブロックと tool-result ブロックを追加するエージェントアプリでは、2、3 ターンで 20 ブロックを超えます。1 リクエストにつき 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 に注意してください。ゼロだけの列は、セルフホストのエージェントで最も多いコスト計測の不具合です。
誤読しやすいフィールドがあります。input_tokens が数えるのは、最後のキャッシュブレークポイント以降のトークンだけです。そのため、実際のプロンプトサイズは total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens です。大きなプロンプトで input_tokens: 400 を報告するエージェントが、安価とは限りません。残りはキャッシュから提供されています。
送信前に数えてください。トークン数の計測は無料で、レート制限もメッセージ作成とは別です。そのため、count_tokens を使ってサイズ超過の添付ファイルを拒否すれば、計測のために料金を支払わずに済みます。結果は推定値なので、モデルごとに再計測してください。別のベンダーの tokenizer で得た値を再利用してはいけません。Claude Opus 4.7 以降の Opus モデル、Claude Fable 5、Claude Sonnet 5 は、「同じテキストに対して約 30% 多くのトークンを生成する」新しい tokenizer を使用します。Claude Sonnet 4.6 以前と Claude Haiku 4.5 は、これらに含まれますが、従来の 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[]= を受け付けます。制限が 1 つあります。「Admin API は個人アカウントでは利用できません。」
最後のパラメータは、低コストでジョブを帰属させる方法です。各ジョブに専用の 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のツール呼び出し上限によって、多数のツール呼び出しを行ったセッションを停止するように、ここで処理を止めます。しかし、自分で書いたループには、上限を追加するまで、このような安全策はありません。
プロセスの外側にも、2つ目の停止条件を設けます。常駐プロセスではなく systemd timer からジョブを実行し、サービス unit に RuntimeMaxSec= を設定します。RuntimeMaxSec=600 を指定すると、停止した実行を気付くまで動かし続けるのではなく、10分後に強制終了できます。プログラムを systemd service と timer として実行するでは、unit ファイル自体について説明しています。実行内容は journalctl -u triage-agent.service --since "1 hour ago" で確認します。
リトライ回数にも上限を設けます。無限にリトライするハンドラーでは、試行のたびに課金されるためです。429 や 500 なら、バックオフを入れて数回試行する価値があります。400 では同じリクエストが同じ理由で失敗するため、リトライは不要です。
AI エージェントのコスト管理は、自分の数値を読むことから始まります
常時稼働するエージェントのコストを他人が判断することはできません。コストは、1 回の実行あたりのトークン数に 1 日の実行回数を掛けたものであり、どちらも利用者が決めるためです。1 回実行し、記録した使用量の行を確認して、スケジュールに基づいて計算します。2 日後にコストレポートをその計算結果と照合します。両者が一致しない場合、その差はほぼ必ず、壊れたキャッシュか、想定より長く実行されたループが原因です。
ここでは API key を使用することを前提とします。エージェントは利用者自身のプログラムであり、Messages API を呼び出すためです。自身の対話的な作業については、作業方法に合う Claude プランでサブスクリプションの選択を確認できます。ここに記載した価格と上限はすべて 2026 年 7 月に Anthropic のドキュメントで確認済みですが、予算を作成する前に pricing page を再確認してください。
FAQ
常時稼働する AI エージェントを VPS で運用するには、どの程度の費用がかかりますか？
請求は2種類あり、そのうち予測できるのは1つだけです。サーバー料金は毎月固定です。モデル API はトークン単位の従量課金なので、費用は1回の実行で消費する量に実行頻度を掛けたものになります。Anthropic は self-hosted の常時稼働エージェントについて具体的な金額を公開していないため、提示された数字は推測として扱ってください。実際の実行から usage を記録し、スケジュールに応じて掛け合わせます。
max_tokens と task budget の違いは何ですか？
max_tokens は強制適用され、モデルからは見えません。1回のリクエストにおける出力を、思考に使われる分も含めて制限し、上限に達すると stop_reason: "max_tokens" になります。一方、task budget はモデルに数値を伝え、その範囲内でエージェントループのペースを調整させます。ただし、「Task budgets are a soft hint, not a hard cap」であり、実際に強制される上限は引き続き max_tokens です。
エージェントの cache_read_input_tokens が常に0なのはなぜですか？
呼び出しごとにプレフィックスが変化しているか、キャッシュするには短すぎるためです。よくある原因は、システムプロンプトにタイムスタンプや実行 ID を埋め込んでいることです。キャッシュはプレフィックスをキーにするため、1バイトでも変わると、その後の内容がすべて無効になります。ツール定義や effort の値を変更した場合も同じです。それ以外ではサイズが原因です。短いプロンプトはキャッシュされず、エラーも返されません。
AI エージェントが無限ループするのを止めるにはどうすればよいですか？
ループのコードで反復回数を数え、固定した最大回数で停止させます。max_tokens は1回のレスポンスを制限するだけであり、エージェントは複数回実行するためです。プロセスの外側にも実時間の制限を設定します。RuntimeMaxSec= を設定した systemd timer からジョブを起動すると、停止した実行を予定どおり終了させられます。リトライも上限を設定してください。リトライするたびに課金されるためです。
1つの Claude API key に支出上限を設定できますか？
文書化されている支出上限は key 単位ではなく workspace 単位です。そのため、エージェント専用の workspace を用意し、そこで月間支出に上限を設定してください。「You cannot set limits on the Default Workspace」。支出通知も追加し、最初にしきい値の通知を受け取れるようにします。利用状況をジョブごとに分けるには、各ジョブに専用の key を発行し、group_by[]=api_key_id で利用状況レポートをグループ化します。