- 公開日
Agentの費用を一定額に収めるには、使用量の記録に加え、次の処理に必要な予算を実行前に確保し、確保できない要求を実行環境で止めます。並列処理では全要求が同じ予算を参照し、未確定の費用も使用可能額から差し引く必要があります。プロンプトに「予算内で調べて」と書いただけでは、この制御を実装したことにはなりません。
ここでのAgentは、モデルによる判断と外部ツールの呼び出しを繰り返して調査を進める仕組みです。費用上限は、金額だけでなくトークン、呼び出し回数、反復回数、経過時間と組み合わせます。どれか一つの条件を満たせなければ、新しい処理を始めない設計にします。
計測する金額と止められる範囲を決める
予算は「一つの依頼を受けてから、部分結果を返して終了するまで」に割り当てます。モデルの文章生成だけを集計すると、検索、再試行、最後の要約などが枠外になります。親Agentと子の処理に同じタスク識別子を付け、どこまでを同じ予算へ計上するかを定めます。
使用量を記録する計測、しきい値を知らせる通知、次の要求を拒否する実行制限は別の機能です。提供者の予算設定にも違いがあります。2026年10月19日確認のOpenAI APIのSpend limitsでは、通知用のspend alertと、組織・プロジェクト単位の月次hard spend limitが区別されています。後者では上限到達により対象要求が拒否されますが、制限の反映は即時ではなく、追加使用が生じ得ると説明されています。
したがって、提供者の制限を利用しつつ、一件の調査に割り当てた予算も実行側で管理します。月次の枠と一件の枠は集計期間が異なり、外部の検索サービスなどの料金が同じ枠へ自動的に含まれるとも限りません。管理画面では、設定名に加えて対象料金、集計期間、停止が反映される時点を確認します。
同じ課金条件で反復ごとの費用を足す
計算の基本は、各要求の課金対象量に対応する単価を掛け、その合計をタスク単位で足すことです。たとえば、入力トークン費用、出力トークン費用、検索回数の費用を分けます。トークンはモデルが扱うテキストなどの単位で、文字数とは一致しません。
現行のOpenAI API Pricingには、入力、キャッシュ関連、出力などの料金区分と、ツールの別課金が掲載されています。検索では呼び出し料に加え、検索内容のトークン費用が生じる条件もあります。利用時には対象モデル、処理方式、コンテキスト長、キャッシュの成立条件を照合し、単価表の確認日を記録します。異なる条件の安い列だけを組み合わせて見積もることはできません。
入力には依頼文だけでなく、履歴、ツール定義、検索結果なども入ります。Counting tokensの説明に沿って、送信する実際の構造を対象に見積もり、返却された使用量と照合します。Tokenizerは入力をトークンへ分割する仕組みです。ローカルで数える場合はその版とモデルとの対応を固定し、API側の計数と差が出る条件を確かめます。
出力の扱いにも注意が必要です。OpenAIのReasoning modelsでは、内部の推論に使うトークンも出力として課金されます。出力合計に含まれる推論分を、別欄だからと再加算すると二重計上になります。可視文章が短いことや、上限で回答が完成しなかったことは、費用が小さい、あるいは無料だったことの証拠にはなりません。
記録にはタスク、要求、試行の識別子、使用モデルと料金条件、入力・出力の使用量、ツールの課金単位、確定額、未確定額を持たせます。同じ使用量の通知を重複受信しても二度加算せず、再試行として新しく発生した料金は落とさないようにします。請求明細と照合できるまでの計算値を、請求確定額と混同しません。
架空の調査一件で累積を計算する
以下は計算と停止判断を説明する架空例です。実在モデルの価格や性能ではなく、Agentも検索も実行していません。依頼は「公開資料から三製品の仕様を比較し、出典と未確認項目を返す」です。同じ依頼、価格、検索対象、回答条件のまま、予算を各処理が別々に見る場合と、共有して予約する場合を比べます。
集計期間は一件の依頼の開始から終了まで、通貨は米ドル（USD）とします。課金は次の三項目だけと仮定します。
| 費目 | 仮定の単価 | 集計する量 |
|---|---|---|
| 入力 | 100万トークン当たり2 USD | 履歴・ツール定義・取り込んだ検索結果を含む入力 |
| 出力 | 100万トークン当たり8 USD | 課金対象の推論などを含む出力合計 |
| 検索 | 1回当たり0.0100 USD | 実際に課金対象となった検索要求 |
キャッシュ割引は使いません。保存、画像、コンテナなどは使わず、その料金は発生しない設定です。税、為替換算、運用人件費は比較の対象外とします。検索内容が入力に入る場合は入力側で数え、別料金として重複加算しません。この仮定に合わない課金項目が実環境にあれば、別枠で加えるまで同じ計算は使えません。
ある反復で入力1,200トークン、出力300トークン、検索1回が発生した場合、費用は次のようになります。
- 入力：1,200÷1,000,000×2＝0.0024 USD
- 出力：300÷1,000,000×8＝0.0024 USD
- 検索：1×0.0100＝0.0100 USD
- 合計：0.0024＋0.0024＋0.0100＝0.0148 USD
最初の二反復が同じ使用量なら、累積は0.0296 USD、入力・出力合計は3,000トークン、検索は2回です。これは仮定値を計算した結果で、測定実績ではありません。内部の金額判定では小数を途中で丸めず、表示だけ小数第4位までとします。実装では固定精度の整数などで比較し、実際の請求丸めがある場合はその規則も計算へ入れます。
発行前に共有予算を予約する
この調査の総予算を0.0600 USDとし、そのうち0.0100 USDを最後の結果整理用に残します。この予備枠は、調査に回してよい残金とは分けます。整理にもモデルを使うなら、予備枠の中で入力・出力上限を設定し、生成が失敗したときには取得済み記録を定型文で返せるようにします。
次に、二つの処理AとBが同時に追加調査を求めるとします。一処理はモデル要求一つと検索一つから成り、入力は最大2,000トークン、出力は最大500トークン、検索は最大1回に制限できる仮定です。その処理が使い得る上限額は、2,000÷1,000,000×2＋500÷1,000,000×8＋0.0100＝0.0180 USDです。平均使用量ではなく、この上限額を予約します。
ここでいう予約は、課金そのものではありません。処理が終わって実績と照合できるまで、その額を他の処理に渡さず確保することです。新しい要求の許可条件を「確定済み費用＋未精算の予約額＋新しい要求の予約額＋結果整理用の予備枠が、総予算以下」と定めます。
二反復後は、調査に使える額が0.0600−0.0296−0.0100＝0.0204 USDです。AとBがそれぞれ同じ残額を読み、後から計上すると、各予約額0.0180 USDは残額0.0204 USD以内なので、両方とも実行可能と判断してしまいます。両方を最大まで使えば、予備枠を含めて0.0756 USDとなり、総予算を超えます。
共有台帳で残額確認と予約を一つの不可分な更新として処理すると、判断は変わります。Aを先に予約した場合、合計は0.0576 USDで許可できます。その直後のBの要求は0.0756 USDとなるため、発行しません。データベースのトランザクションなどを使い、AとBが同じ予算を同時に取り合っても更新が食い違わないようにします。
予約を通すのは、課金を生む要求を実行環境から発行する直前です。送信する入力が設定した上限内かを確認し、超える場合は資料を絞って再計数するか、実行を保留します。予約識別子を一つの要求へ結び付け、同じ予約を別の要求へ使い回せないようにします。子Agent、別の実行サーバー、SDKの自動再試行も同じ入口を通します。台帳へ接続できないときに記録を後回しにして実行を続けると、強制できる上限ではなくなります。
金額以外の上限も同じタスクへ適用する
金額の予約だけでは、無料の処理が延々と続く場合や、遅い検索で終了しない場合を止められません。例では、次の上限も実行側へ設定します。値は説明用であり、推奨標準ではありません。
| 上限 | 架空の設定 | 発行・継続時に確認すること |
|---|---|---|
| トークン | 入力・出力合計10,000トークン | 確定使用量と予約量を共有し、整理用2,000トークンを残す |
| ツール呼び出し | 検索4回まで | 子処理と再試行の検索も含め、発行前に回数を確保する |
| 反復 | 制御ループ4回まで | 最後の1回を整理用とし、分岐した要求数も別途数える |
| 経過時間 | 全体60秒まで | 待ち行列と再試行待ちを含め、50秒で新規調査を止める |
| 並列実行 | 同時2処理まで | 空き枠があっても予算不足なら許可しない |
反復の一回を「制御ループが判断して、必要な処理の結果を受け取る一巡」と定義します。一巡から複数のモデル要求が出る場合、反復数と要求数は一致しません。回数上限の実装がどちらを数えているかを確認し、再試行や子処理で数がリセットされないようにします。
トークンも金額と同じく予約します。二反復の3,000トークンに、Aの最大2,500トークンと整理用2,000トークンを足すと7,500トークンで、この条件は満たします。ただし、Bを同時に許可できるかは金額条件にも従うため、トークンの空きだけを理由に発行できません。
OpenAIのmax_output_tokensは、対象APIで生成する出力全体の上限です。一件の依頼に含まれる全入力や外部検索費用まで制限する設定ではありません。使用するAPIとモデルの仕様を確認したうえで、要求ごとの上限とタスク全体の台帳を接続します。
全体の期限は、時刻の補正で逆戻りしない経過時間用の時計で管理します。個々の通信で応答を待つ期限とは分けて設定します。通信だけがタイムアウトしても、外部処理まで終わったとは限りません。50秒以降の10秒で整理を終えられる保証もないため、60秒では追加生成を止め、確認できた記録から部分結果を返す経路を用意します。
実績と精算し、不明な費用を解放しない
Aの使用量が仮に入力1,600トークン、出力400トークン、検索1回で確定した場合、その費用は0.0032＋0.0032＋0.0100＝0.0164 USDです。予約0.0180 USDを実績へ置き換え、差額0.0016 USDだけを戻します。予約を消す処理と実績の加算も、一つの不可分な更新にします。
累積は0.0296＋0.0164＝0.0460 USDとなり、整理用を除く残額は0.0040 USDです。次の調査に必要な0.0180 USDを確保できないので、予算を使い切る前に調査を終了します。上限管理では、残高がゼロになることより、次の要求を許可できるかが判断点になります。
最後の整理を入力1,000トークン、出力500トークン、検索なしで行えたと仮定すると、追加は0.0060 USDです。総額0.0520 USD、合計6,500トークン、検索3回、反復4回で終了します。整理用予備枠は入力最大1,000、出力最大1,000トークンで0.0100 USDに収まる設計です。未使用分は完了を確認して解放します。
一方、Aの応答が届かず費用も分からないなら、0.0180 USDの予約を残します。時間切れや予約の有効期限切れだけを理由にゼロへ戻すと、実際には処理中の要求と新しい要求に同じ予算を配るおそれがあります。AWSの再試行に関する解説も、応答不着と副作用がないことを区別しています。識別子で先行要求を照会し、処理・課金の状態が確認できるまで安易に再送しません。
費用上限を厳密に守れるのは、予約額が課金額を覆い、すべての課金経路が管理下にある場合です。単価や出力量の上限が不明、第三者ツールが追加課金を起こし得るなど、最大費用を決められない経路は、この枠での自動実行を保留します。後から実績が予約額を超えた場合も新規発行を止め、差額、原因、台帳と請求のずれを調べます。事後の検知で超過前に戻れたことにはしません。
止めた後に返す内容まで予算へ含める
終了処理では、まず新規要求と待ち行列からの発行を止めます。処理中の要求は、取消を要求できるかと実際に止まったかを分けて確認します。検索費用、外部への保存、すでに行われた更新などが、Agentの停止で消えるとは扱いません。実行器を再起動しても同じ台帳と要求状態を引き継ぎます。
今回の架空例で返す部分結果は、「確認できた三製品の仕様と出典」「未確認の仕様」「追加調査を止めた理由」「仮定上の確定費用0.0520 USD」です。費用不明の要求があれば、確定額とは別に予約額と確認待ちの要求を示します。残る処理や副作用を誰が確認するかも記録します。
導入前には、課金されない模擬環境で、AとBが同時に予算を求める状態、使用量通知の重複、応答不着、期限到達、台帳停止を確認します。期待するのは、許可できない要求が外部へ出ず、不明な予約が残り、取得済み情報が返ることです。この例は未実行の設計です。実際に試す際は料金・API仕様・実行器の版を記録し、外部へ出た要求と台帳を照合します。拒否予定の要求が出ていたり、未確定費用が解放されていたりすれば導入を保留し、発行経路と精算処理を直します。上限や接続先を変える場合も、影響する条件を再確認します。
実行順序と時間・費用・回数の上限をまとめて決める基本は「AIエージェントの実行順序と時間・費用・回数の上限を決める」で解説しています。
