複数プロジェクトを並行運用していると、AIへの委任は増える一方でトークン消費もじわじわ膨らむ。効いたのは複雑な最適化ではなく、タスクの性質でモデルの単価を変えるという一段の判断ルールだけだった。
「探す・数える・集める・要約する」と「書く・直す・文脈の濃い判断をする」を分け、サブエージェント起動のたびにモデルを明示指定するという運用ルールと、それでも量が多い独立実装をどこへ逃がすかの判断。
複数の副業プロジェクトを1つのAIエージェントに並行運用させていると、日々の委任の大半は「記事のネタを探す」「ログの件数を数える」「複数ファイルの状態を集めて要約する」といった、調べ物・下ごしらえの仕事だと気づいた。
ところが最初は、これらのサブタスクも親セッションと同じ高性能モデルにそのまま継承させていた。文章を書くわけでも、設計判断をするわけでもない「探す・数える」作業に、いちばん高いモデルの単価を払っていたことになる。最大の定常消費源は、実は一番地味な下ごしらえの部分だった。
難しい判定を毎回しない。動詞で機械的に振り分ける。
複数フォルダのファイル数を数える、リポジトリ横断で該当箇所を探す、巨大なログファイルを要約する——こうした読んで拾うだけのタスクは、軽量モデルで十分な精度が出る。ここに高性能モデルを使うのが最大の無駄だった。
記事本文を書く、コードを直す、複数の情報を突き合わせて矛盾を判断する——こうした生成・判断を伴うタスクは既定の中位モデルに残す。ここを削ると品質が落ちて、結局書き直しのコストで相殺される。
1つのタスクとして完結し、会話の文脈を必要としない量産作業（例: 定型ツールの複数個同時実装）は、そもそも同じ課金枠に乗せず、別契約のエージェント環境に丸ごと委任する。自己完結したプロンプト1本で1往復完了を狙う設計にすると、枠を分けた効果がそのまま出る。
ここが核心。「賢いモデルほど安全」という直感を捨て、タスクの動詞（探す/書く/量産する）だけを見て単価を機械的に決める。判断に迷う時間そのものが最初の無駄になる。
この判断を毎回頭でやり直さないために、運用ルールをCLAUDE.md（および対になる指示ファイル）に一度だけ書いた。サブエージェントを起動するときは、親モデルをそのまま継承させず、必ずモデルを明示指定する——というだけの1行ルールだが、これが実質的に強制力を持つ。
概念としてはこう書ける（実際のモデル名は使っているサービスに合わせて置き換える）。
# 探す・数える・集める・要約する
agent(task="queueフォルダの数を数える", model="軽量モデル")
# 書く・直す・濃い検証
agent(task="記事本文を執筆する", model="既定モデル")ポイントは「指定なしの継承を避ける」こと。指定を省略すると、軽い下ごしらえタスクまで気づかないうちに高単価モデルへ流れてしまう。呼び出しのたびに明示させることで、判断そのものを仕組みに埋め込む。
この方針にも失敗のパターンがある。毎日自動生成しているタスク（記事の自動執筆など、最大の定常消費源）を既定モデルより下げると、生成物の品質が落ちることがある。品質劣化に気づいたときは、迷わず対話生成（人が確認しながら進める形）に切り戻す——安さのために検品を省略しないのがルールだ。
枠が逼迫したときの最後の砦も決めてある。品質を落とすより先に、生産量そのものを絞る（例: 自動生成を2本/日→1本/日に減らす）。モデルのランクを落とす前に、まず量を落とす方を選ぶ。
複数のAIエージェントを並行運用しているなら、同じ無駄が起きている可能性が高い。