結論：環境変数は既定値、明示指定を例外にする
Claude Code 2.1.251以降では、CLAUDE_CODE_SUBAGENT_MODELをsubagentの既定モデルとして設定し、agent定義のmodel:またはspawn時の明示モデルを、品質要件があるtaskだけに使います。公式CHANGELOGは、環境変数がすべてを上書きする動作から、明示指定を優先する既定値へ変更されたと説明しています。
具体的な困りごとは、費用を抑えるための環境変数が高精度agentまで同じmodelへ変えてしまったり、逆に複数箇所の指定が競合して実際のmodelが分からなくなったりすることです。読了後には、組織既定、agent固有、単発taskのどこへmodelを置くか判断できます。次の行動は、稼働中のagentを「定型」「専門」「例外」の3群へ棚卸しすることです。
model名、提供plan、料金、rate limitは変わるため、固定価格を推測しません。実際に利用できるmodelと費用は契約、provider、地域、Claude Codeのmodel selector、Anthropic公式pricingで公開直前に確認します。モデル指定は権限を変えませんが、強いmodelへ変えるほど自動的に安全になるわけでもありません。tool permission、人間承認、停止条件は別に設計します。
3つの指定場所を比較する
- 環境変数：多くのsubagentへ共通の既定値を配る場所です。明示指定がないtaskへ適用します。
- agent定義のmodel：review、security、翻訳など、役割ごとに再現可能な品質基準を固定します。
- spawn時の明示指定：一回だけ高難度、低latency、検証用へ切り替える例外に使います。
運用しやすい順序は「組織既定を環境変数、恒久例外をagent定義、単発例外をspawn」です。すべてをspawn側に寄せると呼出元ごとに指定漏れが生まれ、すべてを環境変数へ寄せると役割固有の品質条件が消えます。agent定義には目的、入力、出力、検証方法、modelを一緒にversion管理し、modelだけを根拠なく固定しません。
比較軸は品質risk、context量、応答速度、単価、利用上限、結果の検証可能性です。定型format変換は軽いmodel候補、security reviewや曖昧な仕様統合は強いmodel候補ですが、名称だけで決めず代表datasetで評価します。provider経由では同じ表示名でもmodel IDや提供条件が異なる可能性があるため、実環境のstatusとrequest記録を残します。
優先順位を安全に導入する8手順
- 利用中のClaude Code versionと公式CHANGELOGを確認します。
- 契約planで利用可能な正式model名と料金を確認します。
- 全subagentを役割、owner、呼出元、頻度で一覧化します。
- 品質risk、速度、費用、検証可能性を各3段階で評価します。
- 大多数に合うmodelを環境変数の既定値候補にします。
- 恒久的な例外だけagent定義の
model:へ明示します。 - 単発例外はspawn時に指定し、理由と期限をlogへ残します。
- 代表taskで品質、時間、usage、実modelをreadbackします。
切替testでは同じ入力、同じtool、同じ完了条件を使います。正答率だけでなく、不要なtool call、retry、context消費、人間修正時間も測ります。安価なmodelでretryが増えれば総費用は下がらないため、token単価だけで決めません。反対に高精度modelを全taskへ固定しても、定型処理の待ち時間と利用枠を浪費します。
変更は一度に一scopeだけ行います。まず既定値をtest環境で変え、agent定義の明示指定が維持されることを確認します。次に単発spawnで例外を確認し、最後にteamへ配布します。実際のmodelをstatus、telemetry、gateway logなど利用可能な公式surfaceで確認できない場合は、本番自動化へ進めません。
model policyには変更日と再評価日を置きます。新modelが追加されても即時に全agentを切り替えず、同じ代表taskで現行modelと比較します。文章品質、codeのtest通過率、誤ったtool call、security指摘の見逃し、処理時間、総利用量を表にし、一つの点数へ潰さず判断材料を残します。
障害時のfallbackも優先順位へ含めます。希望modelがrate limitやprovider障害で使えないとき、別modelへ自動移行するのか、人間確認で停止するのかをtask riskごとに決めます。顧客送信、production変更、security判定では黙ったfallbackを避け、実行modelが変わった時点で再reviewします。
複数providerではprovider固有ID、data location、logging、利用上限、契約条件を記録します。同じmodel familyでも提供時期や機能が一致するとは限りません。model切替時にはprompt cacheのmissやcontext再構築も費用へ含めます。
運用担当者を明確に決め、、正式な提供状況はClaude Platform公式release notesでも確認します。
運用チェックリストとHOLD条件
- versionを確認した
- 正式model名を確認した
- planの提供条件を確認した
- 料金を公式で確認した
- agent一覧がある
- 既定値を一つ決めた
- 恒久例外に理由がある
- 単発例外に期限がある
- 代表datasetがある
- usageを比較した
- 実modelをreadbackした
- rollback手順がある
HOLD条件は、正式model名が確認できない、利用planで提供されない、実際のmodelを観測できない、評価datasetがない、agent定義とspawn指定のownerが不明、費用上限がない場合です。fallbackが起きる環境では、希望modelだけでなく実行modelを記録し、品質低下時の停止条件を定めます。
よくある質問と次の行動
環境変数だけで運用できますか？
全agentの品質要件が同じ小規模運用なら可能ですが、専門agentは定義側へ明示した方が変更影響を限定できます。
spawn指定を常用してよいですか？
単発例外には適します。繰り返すならagent定義へ昇格し、理由と評価結果を正本化します。
費用削減の成否は何で判断しますか？
token費用だけでなくretry、処理時間、人間修正、失敗率を同じ期間で比較します。
一次情報はClaude Code公式CHANGELOGとClaude Code公式subagents文書です。関連する既定modelの統一、subagent forkの使い分け、費用管理も確認してください。Miraigentの無料診断では、agentごとのmodel選定を60秒で整理します。