Claude Code 2.1.292のAgent effortを作業別に決める

結論：effortは品質保証ではなく配分ルール

実務で困るのは、簡単なファイル探索にも重い設定を使って待ち時間と費用が増えること、逆に設計レビューへ低い設定を使い結論の根拠が薄くなることです。既存のsubagent model優先順位記事はモデル選択が主題で、本稿は同じAgent呼び出しの作業深度をどう割り当てるかに限定します。

探索・実装・レビューを比較する

作業	最初のeffort判断	合格条件
ファイル探索・候補収集	低〜標準。対象と出力形式を狭くする	参照したpathと未確認範囲が残る
局所的な実装・テスト	標準。変更範囲とtestを先に指定	diff、test結果、未対応が返る
設計比較・セキュリティレビュー	標準〜高。反証と停止条件を要求	根拠、代替案、human reviewが残る

effortの値を「賢さ」と呼ぶと誤運用になります。タスク分類、モデル、権限、context、並列数、timeoutのどれを変えた結果かを分け、同じ種類の仕事で測ります。Agentが返した要約だけでなく、実際の変更とテストを正本にします。

8手順で作業別の基準を作る

1. Agentを使う仕事を探索、実装、レビュー、外部連携の4種類に分けます。
2. 各仕事の失敗を、時間損失、品質低下、情報漏えい、副作用の4軸で書きます。
3. 低・標準・高の3段階で、必要な根拠、許可tool、最大時間を仮置きします。
4. 2.1.292以降でAgent toolのeffortを明示し、versionと実行面をログへ記録します。
5. 検証用repositoryで同じ入力を複数回実行し、出力、tool call、待ち時間、token・費用の見える範囲を比較します。
6. 低設定で不十分だった場合に、同じpromptを無制限に再試行せず、なぜ不足したかを「情報不足・権限不足・深度不足」へ分類します。
7. 高設定のAgentにも、破壊的操作、公開、権限変更、外部送信は人間承認を残します。
8. 週次で成功率だけでなく、再試行率、レビュー差戻し、時間、費用、停止件数を見て基準を更新します。

model・effort・権限を混同しない

effortを変更する実験では、同じ入力を保存し、返答の長さだけでなく、要求したtoolが使われたか、根拠が抜けていないか、未完了を明示したかを見ます。設計レビューなら反対意見を一つ要求し、探索なら対象外のpathを報告させるなど、作業に合う観測項目を決めます。これをしないと、高設定の長い文章を品質向上と誤認します。

同じeffortでも、モデルの能力、入力context、利用できるtoolが違えば結果は変わります。たとえば探索AgentにWriteを許可していないなら、effortを上げても実装は完了しません。反対に広い権限を与えて「高effortだから安全」と判断すると、失敗の影響だけが大きくなります。

症状	疑う場所	判断
回答が浅い	入力、参照path、task定義	effort変更前に情報を補う
時間だけ延びる	scope、timeout、重複探索	対象と終了条件を狭める
変更が危険	permission、hook、review	effortではなく権限を止める
費用が読めない	Agent回数、model、context	job IDと実績をまとめる

並列化やforkを使う場合はsubagent forkの使い分けを参照します。並列数を増やすこととeffortを高くすることは別の判断なので、同時実行の上限と費用上限を別欄で管理します。

運用開始前チェックリスト

測定期間は同じ種類の仕事を十分に含めます。探索だけで決めたeffortをコード変更へ流用せず、レビュー差戻しや人間の確認時間も含めて比較します。高設定へ切り替えた結果、差戻しが減ったのか、単に返答が長くなったのかを分けるため、合格条件を先に定義します。判断できない場合は高設定へ固定せず、人間レビューを追加します。

基準表には、担当者が例外を承認する欄も置きます。たとえば通常の探索は低設定でも、公開前の依存関係確認だけ標準以上にする、といった変更理由をjob IDと一緒に残します。後から費用だけを見て設定を下げると、レビュー不足や差戻しのコストが別の場所へ移るため、品質指標と費用指標を同じ期間で比べます。

• Agentの仕事を4種類以上に分類した
• effortの段階ごとに合格条件がある
• model、effort、context、権限を別々に記録する
• 2.1.292以上と実行面をログへ残す
• 低設定から高設定へ切り替える条件がある
• 変更・公開・外部送信には人間確認がある
• 再試行率、時間、費用、差戻しを週次で確認する

費用管理はClaude Codeのコスト管理と接続し、Agentごとの推測値を請求確定値のように扱わないことが重要です。無料のAI導入・運用の無料診断（60秒）では、業務分類と承認条件を一枚の運用表へ落とし込めます。

実測結果を判断へ変える

記録する最小単位は、taskの種類、入力サイズ、model、effort、実行時間、tool利用、終了理由、レビュー結果です。費用を直接取得できない面では、利用量を推測値として別欄に置き、請求情報と混ぜません。高設定へ変えても失敗の種類が変わらないなら、promptの不足や権限設計を先に直します。逆にレビューの差戻しが減り、時間と費用が許容範囲なら、その仕事だけ標準を上げる根拠になります。

運用責任者は、effortの変更を「モデルを賢くする操作」と説明せず、仕事ごとのリスクに対する計算資源の配分として説明します。これなら予算・品質・承認の議論を同じ表で行え、担当者が勝手に全Agentを高設定へすることも防げます。

例外を承認する条件

高いeffortを例外扱いにする条件は、重要度だけでなく、失敗を検出できるかで決めます。結果をテストや差分で検証できる仕事なら標準設定を試しやすく、検証できない判断や外部影響の大きい仕事なら、人間承認と記録を先に置きます。設定名だけを根拠に無人化しないことが境界です。

判断を記録して再利用する

一度決めた基準を固定しすぎる必要はありませんが、変更日、変更者、根拠となる実測を残します。新しいモデルやCLI更新で結果が変わった時に、effortだけの問題なのか、入力や権限の変化なのかを追跡できます。再利用できる判断票を作ることで、担当者ごとに高設定へ寄るばらつきも抑えられます。

FAQ

effortを高くすれば常に正確になりますか？

いいえ。推論の深さを指定するパラメータであり、入力、権限、テスト、レビューの代わりではありません。

全Agentをhighにしてもよいですか？

費用と待ち時間が増えるため、作業別の基準を作り、例外だけ高くします。

Agent運用の費用設計を相談できますか？

できます。task分類、model、effort、停止条件、実績を無料診断（60秒）で整理します。