Claude CodeからローカルLLMに仕事を委譲するとトークンは本当に節約できるのか

なぜローカルLLMへの移譲を考えたのか

00:19 から再生する

今回のテーマは、Claude Codeなどのコーディングエージェントから、ローカルLLMにコーディングタスクを移譲するツールを作り、それを検証したという話です。

発想はシンプルです。Claude CodeやCodexはAPIの課金が上がっているので、できるだけ節約したいという背景があります。

そこで、機械的で検証しやすい簡単なタスクだけをローカルLLMに投げれば、Claude Code側のトークンを減らせるのではないかと考えたそうです。

イメージとしてはサブエージェントのような使い方です。従来はHaikuなどの軽量モデルが担う部分を、ローカルLLMに投げられないかという発想でした。

対象となるタスクは、大量のファイルのリネームやREADMEの同期といったシンプルな作業です。こうした作業をフロンティアモデルに全部やらせるのはもったいない、という問題意識がありました。

そこで、これをローカルLLMに逃がすCLIを自作し、実際どのくらい安くなるのかを測定しました。

先に結論を言うと、条件付きではあるものの、一応節約はできるという結果になっています。

ただし、全部ローカルLLMに投げれば安いという単純な話ではありません。移譲にはオーケストレートの固定費がかかるため、軽いタスクだと逆に高くなることもあったそうです。

自作ツール「LocalRig」とは

02:00 から再生する

今回作ったのは、手元で動く「LocalRig」というコーディングエージェントです。

Ollama上のQwen3.6の27ビリオンモデルを、Claude Codeのようなコーディングエージェントのサブエージェントとして動かすためのツールになっています。

単にモデルを呼ぶだけでは、Claude CodeのようにはローカルLLMは動きません。そこでツールコールを使えるようにしたり、編集するファイルをうまく扱えるようにしたそうです。

さらに最近のローカルLLMは、ThinkingやChain-of-Thoughtのような思考を行う部分があります。ここが異常に長くなって空転することがあるため、それを制御するハーネスを作ったとのことです。

こうした制御を入れた上で、CLIにしました。最終的な名前はLocalRigですが、最初はLocalHarnessという名前だった名残で、CLIのコマンド名は「LH」になっています。

このLHをClaude Codeからサブエージェントのように呼び、実際にタスクへ適用するとどうなるかを試したのが、今回の実験の土台です。

LocalRig単体でどこまで解けるのか

03:36 から再生する

移譲の話に行く前に、まずLocalRig単体でどのくらいタスクを解けるのかを測りました。

対象は、Claude Codeが日常的にやる小さなタスクです。バグ修正、簡単な機能追加、リファクタリング、複雑なマルチファイル修正、エラー診断、プロジェクト規約の検証などが含まれます。

これらを自分の業務からClaude Codeと壁打ちしながら考え、最終的にユニットテストのような20タスクを用意しました。

結果として、LocalRigは20分の20、すべてパスするところまで実装できたそうです。もちろん、この20タスクはClaude Codeなら100パーセント解けるものです。

一方で、速度はかなり遅くなりました。マルチファイルなどの複雑なタスクだと、Claude Codeの5倍ほどかかることもあったそうです。

この時点では、品質はそこそこ出るが速くはない、という感想でした。裏を返せば、トークンを削減するという意味では使えるツールになりそうだ、というのがこの時の見立てでした。

タスクによって結果は分かれた

05:22 から再生する

次に、20タスクの中から移譲できそうなユースケースを6つ選びました。READMEの同期、型エラーの修正、簡単なテスト作成などです。

Claude CodeのClaude.mdに「実装はLHに移譲してください」と指示しておきます。そして、LHの存在を知らせない全く同じ指示のバージョンと比較しました。

結果はタスクによって分かれました。多めのファイルを横断するリネーム処理では、はっきりとした効果が出ました。

ファイルは多岐にわたるものの、機械的な作業なので、実装トークンをローカルLLMに逃がせたのだろうと話されています。ここは期待通りの結果でした。

一方でREADMEの同期は逆でした。Claude Code単独では0.08ドルだったのに、移譲すると0.12ドルほどに上がってしまったのです。

つまり今回の移譲は、実装コストをゼロにするわけではなく、タスク規模に比例するオーケストレーション費がかかることが分かりました。

数ターンで終わる軽いタスクだと、この固定費が逆に効いてしまいます。簡単そうなタスクだからOK、という単純な問題でもないわけです。

簡単すぎず、かといって難しすぎるとローカルLLMが解けなくなる。そのいい塩梅を任せる難しさがあった、と振り返っています。

移譲で起きた品質リスクと二重払い問題

08:29 から再生する

6タスクのうち、Claude Code単体なら6分の6解けるのに、LocalRigへ移譲すると6分の5になり、1つミスが出ました。

そのミスり方が面白いものでした。問題は、偽のバグ報告を見抜けるかというタスクで、偽なら特定の文言を一行目に入れる、という内容でした。

ローカルLLMは偽の報告だと見抜き、特定の文言も入れたものの、その文言を若干ミスしてしまいました。

ところが、呼び出し元のClaude Codeが、文字面が似ていたために「OKだろう」と判断し、本当は良くないのにパスさせてしまったのです。

ここで、これが自作ハーネスやQwen固有の問題なのか、それとも移譲という構造そのものの問題なのかを切り分けたくなったそうです。

そこで、移譲の構造はそのままに、移譲先だけをClaudeの軽量モデルHaikuに差し替えた対照実験を行いました。

結果、Haikuは6分の6すべてパスし、品質は良好でした。ただしコストはベースラインより16パーセント高くなってしまいました。

つまり、Claude Code側のオーケストレーション費に、さらにHaikuというワーカーの課金が乗る、いわば二重払いになるわけです。

重いタスクなら勝てるはずが、上限もあった

11:06 から再生する

次に、シンプルだけど作業がいっぱいある重いタスクなら、ローカルLLMのメリットをより享受できるのではと考えました。

12ファイルのリネームがうまくいったので、40ファイル規模の移行ならもっと大きく勝てるのではないか、という期待です。

ところが結果は逆でした。Claude Code単体で約1.1ドルだったところ、LocalRigを使わせると約1.5ドルまで上がってしまったのです。

原因を探るため、途中のログを見ました。すると、Claude Codeが編集箇所を手動で指示するのではなく、正規表現などで機械抽出するPythonスクリプトを書いて一括で書き換えていたことが分かりました。

ここから、移譲でコストをうまく削減できる範囲には下限と上限があると分かりました。

さらに、難しすぎるタスクはそもそもローカルLLMが解けなくなる恐れもあります。任せる範囲の見極めがかなり難しい、という印象でした。

うまくいかなかった非同期モードと実運用の判断

13:41 から再生する

せっかくなので、試したがうまくいかなかった機能も紹介されています。ローカルLLMが作業している間にClaude Codeが別作業をできる、非同期処理モードです。

狙いは時間短縮でしたが、同期版と非同期版でほぼ速度が変わらず、むしろ非同期版の方が少し遅くなってしまいました。

原因は、ローカルLLMの待ち時間が非常に長いことです。同期を取るためのウェイト処理などで、かえって時間がかかることもありました。削減できても数十秒程度で、ほぼ誤差だと話されています。

最後に、実運用での判断基準が整理されました。移譲してよさそうなのは、ターンが多くて機械的な作業です。複数ファイルのリネームや、まとまったテスト作成などが挙げられます。

ただし、シンプルなタスクほどスクリプト化できてしまうので、その場合はスクリプトを書いた方が安く済むこともあります。もう少し複雑な、まとまったテスト作成のようなタスクにこそ価値がありそうだ、とまとめられています。

それでも、Claude Code自身がサブエージェントの受け入れ判断を間違える挙動を確認できるなど、いろいろ試す中で知見があったと振り返っています。

まとめ

Claude CodeからローカルLLMへタスクを移譲すれば、リネームのような機械的作業では確かにコストを削減できました。ただし固定費やスクリプト化の壁があり、任せる範囲の見極めが難しいという、条件付きの結果になりました。