Claude Opus 5.5のマルチエージェントに経過時間を伝えて完了を早める

このTipsでできること

Claude Opus 5.5は経過時間の情報に強く反応するモデルです。リードエージェントがサブエージェントに作業を委任するマルチエージェント構成で、この性質を使うと完了を早められます。

やり方は単純です。実行基盤(ハーネス)がモデルに送り返す各メッセージの末尾に、経過時間を示す短い行を足します。時間予算を見積もれるならelapsed 340s / 1200sの形、見積もれないなら経過時間だけです。どちらもClaude Opus 5.5のプロンプトガイドに載っている手法です。

難所は、この行が毎ターン変わることにあります。置き場所を間違えると、プロンプトキャッシュや過去のthinkingブロックが無効になります。本稿は、この置き場所の選び方に紙幅を割きます。

自分のタスクはどちらの合図か

予算を決められるかどうかで、モデルに渡す合図が分かれます。

時間予算(タイムボックス)は、ハーネスがタスクの目安時間を先に決め、経過をその比率で伝え続ける手法です。

効き方にも特徴があります。モデルの思考量を削るのではなく、より多くのエージェントを並列で動かし続ける方向に働きます。Anthropicの評価(研究タスクを担う小規模なエージェントチーム)では、どちらの合図もシグナルなしの単一エージェントより早く終わりました。予算つきのチームは、回答品質を単一エージェントと同程度に保ったまま、かなり早く完了しています。

実装1 — 時間予算を見積もれるとき

予算は、実際にかけたい時間より少し多めに設定し、値は自分のタスクのサンプルで調整します。

送る行はこの1行です。

elapsed 340s / 1200s

クライアント側のツールループでは、tool_resultを運ぶuserメッセージが届くたびに行がクリアされます。見せ続けるには、tool_resultのたびに新しい行を追記します。この行は毎ターン内容が変わるので、会話の先頭に固定するシステムプロンプトには向きません。clear_at: "next_user_message"を付けた会話途中のシステムメッセージとして送ります。

リクエスト全体は次の形です。ベータヘッダーを付け、messagesの末尾に経過時間のsystemメッセージを積みます。

curl https://api.anthropic.com/v1/messages \
  -H "anthropic-beta: mid-conversation-system-clear-at-2026-08-21" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 32000,
    "messages": [
      {"role": "user", "content": "..."},
      {"role": "assistant", "content": [...]},
      {"role": "user", "content": [{"type": "tool_result", "tool_use_id": "...", "content": "..."}]},
      {"role": "system", "clear_at": "next_user_message", "content": "elapsed 340s / 1200s"}
    ]
  }'

たとえばコードレビューを複数のサブエージェントに分担させ、全体に30分を充てるなら、秒に直してelapsed 340s / 1800sのように送ります。

clear_atの仕様で押さえる点

clear_at: "next_user_message"のメッセージは、後ろにuserメッセージが来るまでの間だけモデルに見えます。tool_resultだけを運ぶuserメッセージも、このuserメッセージに数えられます。見えなくなった行は配列には残ったまま、入力トークンも消費しません。

• ベータ機能で、mid-conversation-system-clear-at-2026-08-21ヘッダーが要ります。ヘッダーなしでclear_atを送ると、未知のフィールドとして拒否されます。通常の会話途中システムメッセージにはベータヘッダーが要らないので、clear_atの有無でヘッダーの要否が分かれます。
• 中身はテキストのみです。tool_addition・tool_removal・output_config・cache_controlは載せられません。
• 一度クリアされた後も、後続のリクエストにバイト単位で同じまま含め続けます。
• 対応モデルはOpus 5.5を含みます。Claude Sonnet 5では使えず、トップレベルのsystemフィールドを使う案内になっています。
• 連続するsystemメッセージは1つのシステム区間として扱われます。

もう1点あります。systemの位置に置いた文は、Claudeが運営者の指示として扱います。経過時間のようにハーネス自身が作った事実だけを載せ、ツール出力や取得した文書をそのまま入れないでください。

実装2 — 時間予算を見積もれないとき

目安時間を事前に決められないなら、経過時間だけを見せます。システムプロンプトの末尾に次の一文を足します。

Time matters here: do not spend time that can be avoided, and the earlier a correct result is obtained, the better.

この一文は毎ターン変わらないので、トップレベルのシステムプロンプトに入れて構いません。ただしOpus 5.5では、セッションの最初のリクエストから含めておきます。途中で足すとsystemが変わったとみなされ、それ以前のthinkingブロックが無効になります。

経過時間の行は実装1と同じく毎ターン変わります。こちらもclear_at付きの会話途中システムメッセージで送ります。

毎ターン変わる情報をどこに置くか

経過時間の行をトップレベルのsystemに書き換えて入れる実装は、見た目には簡単です。しかしそれが最も高くつきます。同じ「毎ターン変わる指示」でも、置き場所によって壊れるものが違います。

effortを会話の途中で動かしたいときは、キャッシュを保てるmid-conversation effortの切り替えを使います。時間予算のclear_atとは扱う対象が違いますが、どちらも前の部分を変えずに追記する発想です。

時間予算とeffort引き下げは別の手段

どちらも作業を速めますが、効いている場所が違います。混同すると、期待した速度が出なかったり、品質が想定以上に落ちたりします。

Opus 5.5の既定effortはmediumで、Opus 5のhighより一段低い値です。時間予算を足しても、effortの設定自体は変わりません。xhighやmaxで動かす長いエージェントターンでは、思考トークンの分までmax_tokensを確保します。128,000(モデルの上限)が、Anthropicの検証でうまくいった値として挙げられています。thinkingの中身を返さない設定でも、思考はmax_tokensに数えられます。

別の予算軸としてトークン消費から作業量を見積もる方法もあります。Opus 5.5のタスクコストを試算する方法が参考になります。時間予算は所要時間の軸、こちらはコストの軸です。

運用上の注意点

予算の上限ではモデルが止まらない

予算は助言で、上限に達してもモデルは強制停止しません。ハード停止が必要な処理には、自前のタイムアウトを別に用意します。

時間圧力で検証が甘くなることがある

時間圧力の下では、モデルが検索や確認を少し省くことがあります。本番投入の前に、自分のタスクで回答の品質を見ます。

システムメッセージの置ける位置は決まっている

systemロールで本文を持つメッセージは、messagesの最初の要素にできません。直前はuserターン(tool_resultを含むものも可)か、サーバーツールの結果で終わるassistantターンです。tool_useブロックとそのtool_resultの間にも置けず、外れると400エラーになります。

早すぎる終了は時間予算では防げない

Opus 5.5は、長いタスクの途中でテキストだけのメッセージを返してend_turnすることがあります。これは時間予算とは別の問題です。ループがそれを完了とみなすと、そこで止まります。

対策は、タスクの残項目をTODOツールやファイルで追跡することです。未完了の項目が残り、阻害要因も述べられていないなら、残項目を挙げた短いuserメッセージで続行を促します。ただし自動の続行は2〜3回で打ち切ります。本当に詰まっている実行を、いつまでも繰り返さないためです。

進捗更新と経過時間は併用できる

Opus 5.5はツール呼び出しの合間に短い進捗更新を書きます。既定のthinking.displayではその中身が空で返るため、textブロックだけを描画するクライアントでは何も出ないように見えます。display: "updates"(ベータ、thinking-display-updates-2026-08-18ヘッダー)を設定すると、各更新の要約を受け取れます。

進捗更新が長く途切れるときは、同じclear_atの仕組みが使えます。display: "updates"を設定したうえで、テキストも進捗更新も無いツール呼び出しがたとえば5回続いたら、最新のツール結果の後ろにリマインダーを追記する方法です。Anthropicの検証では、長い無言区間のあるタスクの割合がおよそ半分になり、コストの変化は計測されませんでした。リマインダーも2〜3回で打ち切ります。

単位は秒で書く

公式の例はすべて秒単位です(elapsed 340s / 1200s)。まず秒のまま試し、分などへ変えるなら自分のタスクで比べます。

複数エージェントの設計との関係

マルチエージェントの組み方そのものは、Claude Codeのサブエージェント機能と共通の発想です。役割ごとにモデルを振り分ける設計はClaude Codeサブエージェントのモデル配分設計にあります。時間予算はそこに重ねられる追加のシグナルで、役割設計の代わりにはなりません。

まとめ

最初に確かめるのは、手元のハーネスが現在時刻やトークン予算をトップレベルのsystemに毎回書き込んでいないかです。書き込んでいるなら、その行をclear_at付きの末尾追記へ移すだけで、thinkingブロックの無効化は止まります。