Agent ワークフローには、1つではなく3つの予算が必要

Agent ワークフローには、1つではなく3つの予算が必要

コーディング Agent に token 上限を設定すると制御できたように見えますが、token は自律実行の一側面にすぎません。上限内でも、試行回数が増えすぎたり、長時間待機したり、有効な変更がないまま何度も繰り返したりします。管理すべき単位は「1つのプロンプト」ではなく、観測可能な成果を持つ、境界付きの作業ループです。

情報源で確認できた事実

Qwen Team が 2026 年 9 月 17 日に公開した更新によると、Qwen Code v0.23.3、v0.23.4、v0.24.0 には、名前付きワークフロー、ターンごとの token 上限、Goal のターン数とアクティブ時間の制限が追加されました。また、上限到達後には引き継ぎ用の1ターンが与えられます。これはベンダー文書の説明であり、本サイトの実測ではありません。2026 年 10 月 12 日に確認した Goals 文書では、token、ターン、アクティブ時間が別々の枠であり、最初に到達した制限によって引き継ぎ後に停止すると説明されています。時間制限はターン間で確認されるため、実行中のターンは途中で中断されません。

この考え方は、多くのコーディング Agent に使える4層の境界へ一般化できます。

1. Token 予算：モデル消費量を制限する。 2. ターン予算：繰り返し試行を制限する。 3. 時間予算：実行環境や開発者の注意を占有する時間を制限する。 4. 操作範囲：変更可能なファイル、必須チェック、そして人の承認なしに行ってはいけない push、削除、デプロイ、公開を定める。

自律実行の前に証拠を定義する

「チェックアウトを高速化する」は、共有された閾値なしに完了を宣言できるため弱い目標です。より強い例は「ベンチマークが終了コード 0 で終わり、p95 が 250 ms 未満と表示される。テストも終了コード 0。ベンチマークを変更せず、テストをスキップしない」です。Qwen の Goals 文書も、成果、二値の完了条件、禁止事項、予算、ブロック時の報告という構造を示しています。

Agent が「テストに通った」と述べるだけでは証明になりません。証拠は、直近の終了コード、ベンチマーク行、差分、対象システムからの読戻しなど、ツール結果であるべきです。人の承認も、推測ではなく実際のメッセージでなければなりません。

自作の予算例

計画時には次を使えます。

最大エクスポージャー = ターン上限 × 1ターンの最大 token

これは予測ではなく上限です。保守作業を最大 8 ターン、各 40,000 token とすると、理論上限は 320,000 token です。アクティブ時間も 25 分に制限する場合、最初に到達した境界で終了します。これらの数値は本サイトが作成した例であり、Qwen の価格やベンチマークではありません。

さらに、測定可能な進展が2ターン連続でない場合は別の方法へ切り替えるかブロックとして停止し、最後の1ターンは最新の証拠、変更ファイル、残るリスク、人に必要な判断をまとめる引き継ぎ専用にします。目的は Agent を消極的にすることではなく、失敗を有限でレビュー可能にすることです。

実践課題

単一エンドポイントへの入力検証追加など、元に戻せる小さなリポジトリ作業を選びます。そして、成果、コマンドと期待出力を含む2つの二値チェック、変更禁止のファイルと不可逆操作、6ターン・20分・適切な1ターン token 上限、ブロック時に返す証拠と人が決めるべき1点を書きます。

ブランチまたは使い捨てワークスペースだけで実行し、各ターンを「進展・再試行・ブロック」に分類してください。コード変更が完成しなくても、最終報告に指定した証拠があり、3つの予算内に収まっていれば成功です。これは検証可能な課題ですが、本サイトが実験を実行したという意味ではありません。

出典：Qwen Code Weekly、2026-09-17 ↗、Qwen Code Goals 文書、2026-10-12 確認 ↗。