エージェントへ任せる作業を完了条件と判断負荷で分ける
今回やったこと
エージェントへ作業を渡すときの判断軸を、タスクの大きさだけでなく、完了条件の明確さ、設計判断の必要性、モデル指定の継承先、確認の往復まで含めて整理する。これは運用方針の記録であり、特定のモデルや料金の比較実測を示すものではない。
実装ステータス
運用方針記録あり。素材にある判断基準を説明し、費用や性能に関する根拠のない数値は加えない。
作業の性質で委譲先を決める
小さく機械的で、完了条件がはっきりしている変更は、指定したモデルのAgentへ委譲する。こうした作業は、求める変更と終わりの状態を明確に書きやすい。依頼を受けた側が広い設計判断をしなくても進められるため、作業を切り出す単位として扱いやすい。
一方、課題の分割や設計判断そのものが必要な場合は、spawn_task で別の作業単位に切り出す。素材に記録された注意点は、spawn_task が起動元モデルを引き継ぐことだ。AgentにはSonnet相当のモデルを明示する運用でも、起動元のモデルが別の仕組みで選ばれるなら、指定場所を取り違える可能性がある。モデル選定は依頼文だけで完結せず、どの起動経路が設定を受け取るのかまで確認する必要がある。
| 作業の特徴 | 記録された使い分け |
|---|---|
| 小さく機械的で、完了条件が明確 | 指定モデルのAgentへ委譲 |
| 分割や設計判断が必要 | spawn_task で別タスク化 |
| 継続的に軽くしたい定型作業 | エージェント定義へモデル指定を固定 |
単価だけでなく往復も見る
モデルを選ぶときは、単価だけでなく指示と確認の往復回数を含めた実効コストで判断する。素材には具体的な単価や削減額は記録されていないため、ここで金額の比較はできない。確認できるのは、最初の実行単価だけを見ても、依頼の書き直しや結果確認に必要な手間を評価できないという方針である。
依頼の完了条件が曖昧なら、結果を確認して追加指示を出す往復が増える可能性がある。反対に、単純な作業でも、起動経路が意図したモデルを使っているか分からなければ、動作の確認が必要になる。従って、タスクを小さく分けるだけでなく、「何をもって完了か」「設計判断を誰がするか」「モデル指定はどこで有効になるか」を依頼前に揃えることが判断の基準になる。
運用に落とすときの確認項目
作業内容を定義 → 完了条件を決める → 設計判断の要否を確認 → 起動経路とモデル指定を確認
委譲前には、まず作業の終点を一文で表せるか確認する。次に、その終点へ進むのに設計判断が必要かを見て、必要ならタスク分割を検討する。モデル指定が起動元から継承される仕組みか、Agent側へ明示する仕組みかも分けて確認する。最後に、実行単価だけではなく、結果の確認や追加指示を含む作業全体で選択が適切かを振り返る。
この考え方は、常に高性能なモデルを選ぶ、あるいは常に低コストなモデルを選ぶという規則ではない。素材が示すのは、作業の性質と必要な判断に応じて委譲方法を分け、往復を含む実効コストで考えるという運用方針である。
更新履歴
- 2026-09-26: 初稿を作成。