# コーディングエージェントのタスクに厳格な支出上限を設定するには？ > 厳格な支出上限は、タスク予算を所有するゲートウェイが、モデルまたは有料ツールの各呼び出し前に強制する必要があります。最大費用を予約し、実使用量を精算し、収まらない呼び出しを拒否し、役立つチェックポイントを残して停止します。 # コーディングエージェントのタスクに厳格な支出上限を設定するには？ 厳格な予算は受け入れ制御の問題です。課金対象の呼び出し前に、信頼できるゲートウェイが最大費用を残高で賄えると確認します。事後アラートでは既に発生した超過を止められません。 入力、最大出力、再試行、フォールバック、サブエージェント、埋め込み、検索、sandbox、すべての有料ツールを対象にします。 ## 厳格な上限と柔軟な目標を分ける 3 つの値を使います。 | 制御 | 目的 | 動作 | |---|---|---| | 目標 | 期待費用 | 警告または安価な計画を選択 | | ソフト上限 | エスカレーション点 | 承認を求めるか品質を下げる | | ハード上限 | 最大承認額 | 次の呼び出し前に拒否 | 例として、目標 $0.60、$0.90 で承認、$1.00 で停止とします。ハード上限はプロンプトだけでなくサーバーに置きます。 ## すべての有料処理を一つのゲートウェイに通す エージェントには自社ゲートウェイだけを呼べる短期認証情報を渡します。ゲートウェイが `task_id` を付け、予算を照会し、次の処理を見積もって予約または拒否します。 会計を迂回できるプロバイダーキーを公開しません。検索、sandbox、コード実行、有料検索にも同じ規則を適用します。 ## 呼び出し前に予約し、後で精算する 既知の入力 token と最大出力から上限を見積もります。原子的に予約し、呼び出し後に実使用量で置き換えます。 ```text remaining = hard_limit - committed_cost - open_reservations worst_case = input_cost + max_output_cost + tool_allowance if worst_case > remaining: reject("task_budget_exceeded") else: reserve(worst_case) call_provider() reconcile(actual_cost) ``` 原子予約により、二つのサブエージェントが同じ残高を使うのを防ぎます。 ## バージョン付き料金表を使う 各見積もりに使った価格をイベントと保存します。価格や規則は変わるため、過去使用量を今日の料金で再計算しません。 最終費用が返る場合は見積もりと両方を残します。token だけなら呼び出し前の料金表を使います。未知のツール費用には余裕を加え、最大を決められない呼び出しは拒否します。 ## ストリーミングを安全にする ストリームを開く前に許可された出力費用全体を予約します。使用量を精算しても、クライアント切断が直ちに課金停止になるとは仮定しません。キャンセルは最適化であり、強制境界ではありません。 呼び出し単位の出力上限とタイムアウトを設けます。タスク上限は全ストリーム、再試行、フォールバックを合算します。 ## 再試行とサブエージェントを含める すべての試行を同じ親台帳から差し引きます。再試行で新しい予算を開くと上限が無効になります。 階層予算を使えます。 | 台帳 | 上限 | 規則 | |---|---:|---| | 親タスク | $1.00 | 絶対上限 | | 実装サブエージェント | $0.55 | 親残高を超えない | | テスト分析 | $0.25 | 未使用予約を返す | | 最終レビュー | $0.20 | 残高がある場合のみ実行 | 子上限は配分であり追加資金ではありません。 ## 有用なチェックポイントで停止する 次の処理が収まらなければ型付きエラーを返し、拒否された呼び出しを繰り返しません。 既存コンテキストから次を含むチェックポイントを作ります。 * 完了した変更とテスト。 * 残作業とブロックされた処理。 * 現在のリポジトリ状態。 * 必要な追加予算の見積もり。 * 再開 token またはタスク ID。 これにより、予算停止を制御された引き継ぎにできます。 ## プロバイダー制御を予備防御にする アカウント上限は影響範囲を減らしますが、タスク単位では精密でないことが多く、複数リポジトリを合算したり、反映が遅れたり、ツール費用を含まなかったりします。 Atlas Cloud のようなマルチモデルゲートウェイでも、正本台帳は自社オーケストレーションに置き、照合用の使用量 ID を記録します。モデルが変わっても上限は維持されます。 ## 財務統制として試験する 並行呼び出し、長いストリーム、タイムアウト、使用量欠落、再試行、フォールバック、台帳障害を試します。予算サービス障害時は既定で拒否し、確定費用と予約の合計が上限を超えないことを確認します。 ## 結論 本当のハード上限は支出前に、原子予約と全課金処理を含む一つの台帳で強制します。使用後に警告するだけなら、それは監視であり厳格な上限ではありません。 ## FAQ ### max_tokens は金額の厳格な上限ですか？ いいえ。1 回の出力長を制限するだけで、総費用、入力 token、再試行、モデル変更、有料ツールは制限しません。金額上限には全課金処理を囲む予算台帳が必要です。 ### エージェント予算はどこで強制すべきですか？ すべてのモデルと有料ツール呼び出しが通るサーバー側ゲートウェイまたはオーケストレーション層で強制します。クライアント側のカウンターは迂回や競合の恐れがあります。 ### ストリーミング応答はどう予算化しますか？ ストリームを開く前に許可された最大出力費用を予約し、終了後に報告使用量で精算します。対応する場合はキャンセルできますが、それだけに依存しません。 ### 再試行は元のタスク予算を共有しますか？ はい。再試行、フォールバック、サブエージェント、評価呼び出しは、別予算が明示的に承認されない限り同じ台帳から差し引きます。 ### 残予算が不足したらどうなりますか？ 次の課金呼び出しを拒否し、既存コンテキストからチェックポイントを作らせます。完了作業、未解決事項、継続に必要な追加予算を含めます。 ### プロバイダーのアカウント上限で代用できますか？ 通常はできません。アカウント全体を保護し、反映が非同期な場合があります。タスク単位のゲートウェイで即時分離し、アカウント上限は予備防御にします。