サブエージェントだけエフォートをlowに：Claude Codeで時間と費用を実測

エフォートの使い分けの記事では、セッション全体のエフォートを/effortで切り替える方法を書きました。ただ、調べものをサブエージェントに任せる作業では、ファイルを探す役まで、まとめて判断する本体と同じ深さで考える必要はなさそうです。

Claude Code v2.1.292から、サブエージェントを起動するたびにエフォートを決められるようになりました。検索役だけをlowにすると、どれだけ速く安くなるのか、答えは変わらないのかを測りました。

何が変わったか#

v2.1.292の変更履歴には、Agentツールにeffortの引数を加え、頼んだエフォートでサブエージェントを動かせるようにした、とあります。AgentツールはClaudeがサブエージェントを起動するときに使う道具です。

それまでサブエージェントごとにエフォートを決める方法は、定義ファイルのeffortの項目だけでした。サブエージェントの公式ドキュメントによると、今は次の順に効きます。

1. 環境変数CLAUDE_CODE_EFFORT_LEVEL（設定されていれば、ほかの指定より優先）
2. 起動のたびのeffortの引数（プロンプトで頼むと、Claudeが付ける）
3. サブエージェントの定義ファイルのeffort

起動のたびの指定はそのサブエージェントを再開したときにも引き継がれます。会話を引き継ぐ「フォーク」のサブエージェントには使えません。選べるレベルはモデルによって違います。

プロンプトの1文で本当にlowになるか#

手元のリポジトリ（このブログのソース）で、次の3つを別々のサブエージェントに並列で調べさせ、本体がまとめる作業を用意しました。

1. scripts/にあるcheck-*.mjsの本数と、ビルドから呼ばれていないものの一覧
2. .github/workflows/の各ファイルの起動条件
3. 記事のfrontmatterで必須の項目

正解は先に数えておきました。check-*.mjsは38本（テストを除くと23本）で、ビルドから呼ばれていないのは9本です。ワークフローは10本、必須の項目は5つです。

本体は--effort highで起動し、プロンプトの末尾に次の1文を足すかどうかで比べました。

サブエージェントは3つとも、エフォート low で動かしてください。

claude -pを--output-format stream-jsonで動かすと、Claudeが呼んだツールの引数がそのまま記録されます。1文を足した回では3つのAgentツールの呼び出しに"effort": "low"が付いていました。足さなかった回にはeffortがなく、サブエージェントは本体と同じhighで動きます。

{"subagent_type": "general-purpose", "effort": "low", "run_in_background": false}

3つの調べものを並列に任せたときの時間と費用#

ヘッドレスの公式ドキュメントによると、claude -pをJSONで出力すると、結果に推定費用のtotal_cost_usdが入ります。stream-jsonでも最後の結果の行に同じ項目が入っていました。プロジェクトのフックが時間に混ざらないよう、--setting-sources localでユーザーとプロジェクトの設定を読まずに動かしました。時間はコマンドを始めてから終わるまでの実時間で、各条件1回ずつの結果です。

条件	時間	推定費用	出力トークン
指定なし（サブエージェントもhigh）	54.3秒	0.58ドル	11,474
サブエージェントをlow	36.0秒	0.38ドル	6,158
「時間が大事」の1文を足す	37.4秒	0.36ドル	5,493
lowと「時間が大事」の両方	41.3秒	0.41ドル	5,786

4つの条件とも9本の一覧、10本のワークフロー、5つの必須項目を正しく答えました。出力トークンと推定費用は、サブエージェントの分も含めたOpus 5.5の合計です。推定費用はトークン数から定価で計算した値で、コストの公式ドキュメントが書くとおり請求額ではありません。ProやMaxのプランでは、この分がプランの利用枠から引かれます。

サブエージェント1つの単位で2回ずつ測る#

上の表は1回ずつなので、ばらつきが読めません。そこで、1つ目の調べもの（ビルドから呼ばれていないcheck-*.mjs）だけを、サブエージェント1つに任せて2回ずつ測りました。時間とツールの呼び出し回数は、サブエージェントが終わったときにClaude Codeが返す記録の値です。

条件	時間（1回目・2回目）	ツールの呼び出し
high	19.2秒・18.0秒	4回・3回
low	12.3秒・10.9秒	3回・2回
high＋「時間が大事」	18.3秒・23.6秒	3回・4回
low＋「時間が大事」	11.6秒・14.3秒	2回・3回

8回とも9本の一覧は正解でした。lowはhighよりおよそ4割短く、ツールの呼び出しも1回ほど少なくなりました。highの回の答えには、ビルドが呼ぶスクリプトの中から間接的に呼ばれていないかをgrepで確かめた、という補足が付くことが多く、その分の手間が時間の差になったとみられます。

「時間が大事」の1文は何に効くのか#

Opus 5.5のプロンプトの公式ドキュメントは、本体がサブエージェントに仕事を振る構成に向けた書き方を載せています。時間の予算が決められないときは、経過時間だけを表示し、システムプロンプトに次の1文を足します。

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

同じドキュメントによると、Anthropicの評価では、予算と経過時間を示す方法も、経過時間とこの1文を組み合わせる方法も、少人数のエージェントのチームを、時間の指示のない1つのエージェントより早く終わらせました。エフォートを下げると作業そのものが減り、時間の予算を示すと、主に並列で動くエージェントが増える、という違いの説明もあります。時間に追われると調べる量や確かめる手間が少し減るかもしれないので、自分の作業で答えの質を確かめるように、とも書いています。

今回の計測は経過時間をメッセージに表示せず、プロンプトにこの1文だけを足したもので、公式ドキュメントの方法そのものではありません。その条件で、サブエージェント1つの作業では時間は縮みませんでした。もともと2〜4回のツール呼び出しで終わる作業で、並列にする余地がないためとみられます。3つを並列に振った作業では、1文を足した回の本体がサブエージェントをバックグラウンドで起動し、時間はlowを指定した回とほぼ同じでした。1回ずつの結果なので、差がこの1文によるものかまでは言えません。

正解が決まった調べものはlow、深く確かめるならhigh#

ファイルを探して一覧にするような、正解が決まっている調べものは、サブエージェントだけlowにしてよさそうです。本体はhighのままなので、まとめる側のエフォートは変わりません。

毎回同じ役割のサブエージェントを使うなら、定義ファイルにeffort: lowを書いておく方が、頼み忘れがありません。逆に、間接的な呼び出しまで確かめてほしい調べものでは、highの方が深く見ていました。「時間が大事」の1文は、エージェントを何本も並列に動かす長い作業で試す方がよさそうです。