「読む仕事」に高いモデルを使わない

最大の消費源は「書く仕事」ではなかった

複数の副業プロジェクトを1つのAIエージェントに並行運用させていると、日々の委任の大半は「記事のネタを探す」「ログの件数を数える」「複数ファイルの状態を集めて要約する」といった、調べ物・下ごしらえの仕事だと気づいた。

ところが最初は、これらのサブタスクも親セッションと同じ高性能モデルにそのまま継承させていた。文章を書くわけでも、設計判断をするわけでもない「探す・数える」作業に、いちばん高いモデルの単価を払っていたことになる。最大の定常消費源は、実は一番地味な下ごしらえの部分だった。

タスクの性質で、単価を3段に分ける

難しい判定を毎回しない。動詞で機械的に振り分ける。

※ 運用ルールは2026年10月時点のもの。モデル名・単価・上限は頻繁に変わるため、この記事では特定モデルの価格は書かず、「どのタスクにどの段を使うか」という判断だけを扱う。軽量モデルで足りるという判断も、一般論ではなく自分の運用での経験則であり、定量比較をしたものではない。

サブエージェントを呼ぶたびに、モデルを明示する

この判断を毎回頭でやり直さないために、運用ルールをCLAUDE.md（および対になる指示ファイル）に一度だけ書いた。サブエージェントを起動するときは、親モデルをそのまま継承させず、必ずモデルを明示指定する——というだけの1行ルールだが、これが実質的に強制力を持つ。

概念としてはこう書ける（実際のモデル名は使っているサービスに合わせて置き換える）。

# 探す・数える・集める・要約する
agent(task="queueフォルダの数を数える", model="軽量モデル")

# 書く・直す・濃い検証
agent(task="記事本文を執筆する", model="既定モデル")

ポイントは「指定なしの継承を避ける」こと。指定を省略すると、軽い下ごしらえタスクまで気づかないうちに高単価モデルへ流れてしまう。呼び出しのたびに明示させることで、判断そのものを仕組みに埋め込む。

「読む仕事は別エージェントへ」が、総量では逆効果になりかけた

モデルの単価を下げる話とは別に、読む仕事そのものをAIに任せないという選択肢もある。実際の運用で、週の途中に行うポートフォリオ点検（複数プロジェクトの状態を集めて異常を拾う定期タスク）を設計したとき、構成を同日中に3回変えた。

• 最初は、メインのモデルが必要なファイルを直接読む設計。
• 次に、読み込み専用のサブエージェント2体に並列で読ませ、要約だけをメインへ返す設計に変えた。メインの文脈は守れるが、指示・読み込み・要約が重なって総トークンはむしろ増える可能性に気づいた。
• 最終的に、AIを使わないスクリプトで差分スナップショットを作り、メインにはそれだけを渡す設計にした。初回の試験では、参照元ファイル5本・合計約52KBが、約5,000文字のスナップショットに収まった。

注意: ファイル容量とモデルの実入力トークン数は別物。ここから「料金が何割下がった」とは言えない。実トークンを取得できた回だけ金額に言及し、取れない間は入力規模と取りこぼしの有無で評価する運用にしている。

この例が示すのは、3段の仕分けの手前にもう一段あるということだ。「探す・数える・集める」の中には、モデルより安いもの（スクリプト）で済む仕事が含まれる。まず機械的に集められないかを考え、判断が要る部分だけをモデルに渡す。一般的なコンテキスト設計の観点はClaude Codeは会話を始める前に3万3000トークン消費している、という実測、長いコンテキストの費用感は1Mコンテキストに全部突っ込むといくらかかるのか、電卓を叩いたに詳しい。

安さを追って品質を犠牲にしない

この方針にも失敗のパターンがある。毎日自動生成しているタスク（記事の自動執筆など、最大の定常消費源）を既定モデルより下げると、生成物の品質が落ちることがある。品質劣化に気づいたときは、迷わず対話生成（人が確認しながら進める形）に切り戻す——安さのために検品を省略しないのがルールだ。

枠が逼迫したときの最後の砦も決めてある。品質を落とすより先に、生産量そのものを絞る（例: 自動生成を2本/日→1本/日に減らす）。モデルのランクを落とす前に、まず量を落とす方を選ぶ。

持ち帰れる3点

複数のAIエージェントを並行運用しているなら、同じ無駄が起きている可能性が高い。