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

このTipsでできること

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

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

以下では、時間予算がある場合とない場合それぞれの実装、effortを下げる方法との違い、運用上の注意点までを扱います。

Opus 5.5が経過時間に反応する仕組み

時間予算(タイムボックス)とは、ハーネスがタスクの目安時間をあらかじめ決め、経過時間をその予算に対する比率としてモデルへ伝え続ける手法です。見積もりの正確さより、モデルにペース感覚を持たせることが狙いです。

Claude Opus 5.5は経過時間の情報に細心の注意を払います。マルチエージェント構成、たとえばリードエージェントが複数のサブエージェントへ作業を割り振る形では、この性質を使って作業を速められます。

仕組みは思考量を削ることではありません。予算を与えられたモデルは、より多くのサブエージェントを同時に稼働させたまま作業を進める方向に寄ります。単一エージェントの思考を浅くするのではなく、並列で動くエージェントの数を保つ効果です。この違いは後述する「時間予算とeffort引き下げの違い」で詳しく比較します。

背景にはOpus 5.5の既定effortの変化もあります。既定effortはmediumで、Opus 5のhighより一段低い値です。effortを上げ直さなくても、時間予算を足すだけで並列度を保ちながら仕上げを早められる点は、この既定値の変化と合わせて捉えると理解しやすくなります。

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

タスクにかかる時間をおおよそ見積もれるなら、モデルに時間予算を与えます。ハーネスがモデルへ送り返す各メッセージの末尾に、予算に対する経過秒数を示す短い行を追加します。

elapsed 340s / 1200s

モデルは予算内に収まるようペースを調整し、たいてい予算を余して終えます。そのため予算は実際にかけたい時間より少し多めに設定し、自分のタスクのサンプルで調整します。

この行は毎ターン内容が変わるため、会話の先頭に固定で置くシステムプロンプトには向きません。clear_at: "next_user_message"を使い、tool_resultメッセージの直後に毎回新しい行を追記する形になります。

{
  "role": "system",
  "clear_at": "next_user_message",
  "content": "elapsed 340s / 1200s"
}

古い行は配列に残したまま消さず、新しい行だけをtool_resultの後に足していきます。ベータヘッダーmid-conversation-system-clear-at-2026-08-21が必要です。この形なら過去のメッセージが変わらないため、プロンプトキャッシュがヒットし続け、Opus 5.5で会話に紐づくthinkingブロックも有効なまま保てます。

リクエスト全体では、ベータヘッダーを付けたうえで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分の予算を設定すると、その枠に収まるよう担当範囲の割り振りが進みます。

実装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では、セッションの最初のリクエストから含めておく必要があります。途中で追加するとシステムプロンプトが変わったとみなされ、それ以前のthinkingブロックが無効になります。

経過時間の行自体は実装1と同じく毎ターン変わるので、clear_at付きの会話途中システムメッセージで送ります。予算という分母が無いぶん、モデルは「早く終えるほど良い」という一文だけを手がかりに作業ペースを調整します。

実装できるのはどこか

この仕組みはClaude APIのMessagesエンドポイントを直接呼ぶハーネスのための実装パターンです。ハーネス自身がmessages配列を組み立て、モデルへ送り返す立場にある実装が対象になります。

Claude CodeのCLIはハーネス内部でmessages配列を組み立てて送信するため、利用者が経過時間の行を直接挿入する余地はありません。フックのadditionalContextで近い情報をClaudeのコンテキストへ渡せるかどうかは、別途の検証が必要です。

複数のサブエージェントを束ねる設計自体は、Claude Codeのサブエージェント機能とも共通する発想です。Claude Codeサブエージェントのモデル配分設計では役割ごとのモデル選びを扱っています。時間予算はそこに重ねられる追加のシグナルで、役割設計そのものの代わりにはなりません。

時間予算とeffort引き下げの違い

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

effortをリクエストの都度変えたい場合は、トップレベルのeffortは使いません。キャッシュを保てるmid-conversation effortの切り替えを使います。時間予算のclear_atとは役割が違いますが、どちらも「毎ターン変わる指示をキャッシュを壊さず送る」という同じ課題への答えです。

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

時間予算を足しても、effort自体の設定は変わりません。xhighやmaxで動かす長いエージェントターンでは、思考トークン分の余裕を持たせるためmax_tokensを128,000程度まで引き上げておきます。時間予算の有無にかかわらず、この設定は別に必要になります。

運用上の注意点

予算の上限でモデルが自動的に止まるか

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

時間圧力で検証が甘くならないか

なる可能性があります。時間圧力の下では、モデルが調べ物や確認を少し省くことがあります。本番投入の前に、自分のタスクで品質を確認します。

会話途中システムメッセージはどこにでも置けるか

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

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

防げません。Opus 5.5はテキストだけでend_turnし、タスクが未完了のまま止まることがあります。これは時間予算とは別の問題で、対策はTODOリストなどで残項目を追跡し、未完了なら続行を促すことです。

進捗表示と時間予算は組み合わせられるか

組み合わせられます。Opus 5.5はツール呼び出しの合間に短い進捗更新を書きますが、既定のthinking.displayでは中身が空のブロックとして返り、テキストだけを描画するクライアントでは何も表示されないように見えます。display: "updates"を設定すると、この進捗更新の要約を受け取れます。

経過時間の行と進捗更新は別々の仕組みですが、組み合わせて使えます。経過時間でペース配分を促しつつ、進捗更新でユーザーには「今どこまで進んだか」を見せ続けられます。

秒以外の単位でもよいか

示されている例はいずれも秒単位です(elapsed 340s / 1200s)。分やトークン数に置き換えた場合の効果は検証されていません。まずは秒単位のまま試し、必要なら自分のタスクで比較します。

Anthropicの評価結果

小規模なエージェントチームによる調査タスクの評価では、この2つのシグナルを比較しています。経過時間だけを見せた場合と時間予算を与えた場合のどちらも、シグナルなしの単一エージェントより早くタスクを終えました。

時間予算を与えたチームは、単一エージェントと同等の回答品質を保ちながら、かなり早く完了しました。具体的な短縮率や成功率の数値は公開されていません。効果の大きさは自分のタスクセットで測り直す必要があります。

まとめ

Claude Opus 5.5でマルチエージェントのハーネスを組むなら、経過時間を伝える一手間で完了を早められます。目安時間を見積もれるならelapsed 340s / 1200s形式の時間予算を、見積もれないなら経過時間だけと一文の指示を送ります。どちらもclear_at: "next_user_message"の会話途中システムメッセージで毎ターン送ります。

思考量そのものを削りたいなら、これはeffortを下げる代わりにはなりません。時間予算は並列に動くサブエージェントの数を保つための助言だと捉えて使います。

判断のおおまかな目安は次のとおりです。

• タスクの目安時間が見積もれる → elapsed行と予算(実装1)
• 見積もれない → 経過時間だけと一文の指示(実装2)
• 思考量そのものを減らしたい → effortを下げる(時間予算とは別の手段)
• ハード停止が必要 → 自前のタイムアウトを別途用意する