結論。機械的に検証できるタスクに絞っても、この構成では委譲は節約になりませんでした。
節約できたぶんより、ローカルLLMの出力を検証する側のコストが上回るのが原因です。 しかもその検証は軽い突き合わせでは済まず、実質的な計算のやり直しになります。 (数値の裏付けがあるのはフェーズ2の6試行です。詳細は下記)
試したこと
Claude Code に「単純作業はローカルLLMへ委譲してよい」というプロジェクトルールを与え、 委譲なしの場合と比べました。タスクごとに指示するのではなく、 モデル自身が委譲すべきかを都度判断する形にしています(実運用に近い形にするため)。
フェーズ2の題材は「8つの純粋関数に対するユニットテストを書く」。 採点は変異テストで、隠した14種類のバグをテストが何個検出できるかで測ります。 人の主観が入らず、品質を数値で固定できるタスクを選びました。 フェーズ1は題材が異なり(「全文を読ませる系のタスク」)、本記事で数値を示す対象には含めていません。
結果
品質はフェーズ2の全6試行とも変異体スコア1.00(14/14検出)で同点でした。 つまり以下は、品質を固定した上での純粋なコストと時間の比較になります。
| 条件 | 時間(平均) | トークン合計(平均) | 費用(CLI自己申告・平均) |
|---|---|---|---|
sonnet 委譲なし |
57.5s | 200,738 | $0.316 |
sonnet_qwen 委譲あり |
167.5s (2.9x) | 951,171 (4.7x) | $0.738 (2.3x) |
opus_qwen 参考値 |
487.5s | 1,144,537 | $2.049 |
n=2 の両試行で一貫して同じ方向に振れました。 先行して行ったフェーズ1(全文を読ませる系のタスク、18試行)でも同じ向きの悪化を確認していますが、 フェーズ1の個別試行ごとの数値ログは今回の執筆環境では確認できておらず、「近い規模の悪化」という定量的な比較は本記事では行いません。 方向が一致したという限定的な傍証として扱ってください。数値で検証したい場合はフェーズ1の生ログの所在を別途確認する必要があります。
なぜ高くつくのか
フェーズ2の4回の委譲試行(sonnet_qwenとopus_qwen、各n=2)すべてで、qwen2.5-coder:7b の出力に具体的な計算間違いが入っていました。 Luhnチェックサム、割引額の四捨五入、境界値、存在しない例外の幻覚——いずれもテストの期待値そのものが誤っているケースです。
ここが厄介なところで、委譲ルールに入れていた「機械検証(テストを実行して通るか見る)」は この失敗モードには効きません。 期待値が間違ったテストは、実装がその間違いに合っていなければ落ちますし、 たまたま合っていれば通ってしまう。 期待値が正しいかを確かめるには、結局 Claude自身が正解を計算し直す必要があります。
つまり「検証」の中身が軽い突き合わせではなく実質的な再計算になり、 委譲で浮かせたはずのぶんを検証側で使い切ってしまう。 これが2.3倍という数字の正体です。
これは委譲ルールの書き方の問題というより、 qwen2.5-coder:7b(Q4_K_M量子化)が、正確な数値計算を伴うコード生成を安定してこなせない というモデル能力の限界を示しています。 フォーマットを守る・既存パターンを反復する、といった作業とは要求される能力が違いました。
この結果が言っていないこと
- すべてのローカルLLM委譲が損だ、とは言えません。測ったのは qwen2.5-coder:7b(Q4_K_M)の1モデルです。
- 時間は実行環境に強く依存します。このマシンではローカル推論が短い応答でも約6.6秒かかりました。
- 数値で示せるのはフェーズ2の各条件 n=2 のみです。方向は両試行で一致していますが、精密な倍率として扱うには足りません。
- フェーズ1(18試行)は個別ログが今回の執筆環境で確認できず、「同じ方向の悪化」という傾向の傍証以上の主張はしていません。定量比較が必要な場合は生ログの所在確認が前提になります。
- タスクは「正確な計算を伴うテスト生成」1種類(フェーズ2)です。翻訳や定型フォーマット変換のような、検証が目視で済む作業では違う結果になり得ます。
- 費用の数値はClaude Code CLIが自己申告する
total_cost_usdであり、Anthropicの請求書と突き合わせて確認した実際の請求額ではありません。 トークン数と単価表から算出される見積もりで、契約プランや単価改定によって実際の請求額とは乖離することがあります。
では、何なら効いたのか
同じ「AIに渡すトークンを減らす」でも、生成を任せるのではなく 観測する量を絞る方向は素直に効きました。
AIエージェントにWindowsを操作させるとき、一般的なMCPサーバーは画面全体(タスクバーも背面の全ウィンドウも含む)を 毎回走査して返します。これを「対象ウィンドウ1つだけ」に絞り、コンパクトなテキスト形式にしたところ、 同じ電卓ウィンドウの取得で**応答の文字数が5,630字 → 678字(88%削減)**になりました(実測は電卓アプリ1回のみ。生の応答と詳細は別記事を参照)。
違いは検証コストです。observationの絞り込みは、返ってきた内容が正しいかを別途計算し直す必要がありません。 一方、生成の委譲は必ず検証がついてきます。検証が要らない削減から先に取るべき、 というのが今回の実測から得た一番実用的な教訓でした。