AI開発の半分をローカルLLMへ。大きいモデルを選ばず、役割で振り分けた話
上原正吉（EarthLink Network Co., Ltd.）。Claude Codeを開発の主体に据え、20を超えるプロダクトを1人で同時に開発・運用しています。これは、その現場の実測記です。
2026年7月30日、社内のAI開発を動かしている統制盤で、ローカルLLMの処理比率が50.3%、クラウド側が48.2%になりました。
これは「請求額が正確に半分になった」という意味ではありません。transcriptを含む実行量の分担が、ほぼ半分ずつになったという観測です。それでも、開発タスクのすべてを高性能なクラウドモデルへ送っていた状態から考えると、大きな変化でした。
ここまで来るのに有効だったのは、巨大なローカルモデルを1台置くことではありませんでした。
有効だったのは、タスクを分け、役割ごとにモデルを選び、危険な処理だけは決定的なルールと人間の判断へ戻すことでした。
最初の考え: 大きいモデルを載せればよい
Local Commanderは、開発タスクを受け取り、分類し、必要ならClaude CodeやCodexなどの外部エージェントへ渡すために作り始めました。
最初の設計判断は単純です。
- 実行順序はTypeScriptで固定する
- 分類やbrief作成などの判断はローカルLLMへ任せる
- ローカルで難しいと判断した時だけクラウドへ送る
- DB、認証、権限、課金、本番、デプロイは人間承認へ上げる
この時点では、DGX Sparkの大きなメモリへ70B級モデルを載せれば、より良い司令塔になるように見えました。
しかし、実機ベンチマークは逆の結果を出しました。
分類では14Bと72Bが同点だった
2026年7月10日、16件の分類ケースで14B、32B、72Bを比較しました。
| モデル | 最終分類一致 | 危険側誤り | 平均応答時間 |
|---|---|---|---|
| qwen2.5-coder:14b | 100% | 0 | 4.4秒 |
| qwen2.5-coder:32b | 88% | 0 | 9.8秒 |
| qwen2.5:72b | 100% | 0 | 22.8秒 |
14Bと72Bの分類精度は同じでした。一方、72Bは約5倍遅い。32BはJSON整形が崩れたケースがあり、サイズの順に安定性が上がるわけでもありませんでした。
分類は、長いコードを書き切る仕事ではありません。危険度、必要な仕様、外部モデルへ送るべきかを、速く安全に判断する仕事です。この役割では14Bですでに精度が飽和していました。
「一番大きなモデルを使う」ではなく、「その仕事に十分な最小モデルを使う」が最初の転換点でした。
コード生成でも72Bは勝たなかった
翌日には、分類ではなくコード生成を比較しました。
各モデルに変更を作らせ、生成したdiffをfixtureへ適用し、TypeScriptの型検査と受け入れテストまで通しました（7ケース、n=7）。
| モデル | テスト成功率 | 既存ファイル編集 | 新規ファイル作成 | 平均応答時間 |
|---|---|---|---|---|
| qwen2.5-coder:14b | 57% | 40% | 100% | 11.2秒 |
| qwen2.5-coder:32b | 29% | 0% | 100% | 15.9秒 |
| qwen2.5:72b | 57% | 40% | 100% | 64.3秒 |
ここでも14Bと72Bは同じ57%でした。72Bは約6倍遅いのに、品質の優位はありません。
さらに重要だったのは、全モデルが新規ファイル作成には成功し、既存ファイル編集で失敗していたことです。主な失敗は、diffの行数や文脈が合わず、git applyを通せないことでした。
つまり、ボトルネックはモデルサイズではなく、モデルへ変更を表現させるインターフェースでした。
実機試験でも、既存READMEの編集は2回失敗し、新しいファイルの作成は成功しました。失敗時にworktreeをクリーンへ戻す仕組みは動いていました。モデルを巨大化する前に、whole-file更新やfuzzy applyなど、変更の渡し方を改善すべきだと分かりました。
メモリ計算でも一度間違えた
次は、分類用14Bと作業用72Bを同じDGXへ常駐させ、複数タスクを並列で動かす試みでした。
モデル本体だけを見ると、14Bが約9GB、72Bが約90GB。合計99GBなので、121GBの統合メモリへ載る計算でした。
実際には、モデルが交互に追い出され、分類が約4.5分止まることがありました。
最初はkeep_alive設定の問題だと考えました。しかし実測すると、32k contextを含む実使用量は次の状態でした。
- 14B @ 32k context: 34GB
- 72B @ 32k context: 90GB
- 合計: 124GB
- DGXの利用可能量: 121GB
モデル本体の足し算では収まっていても、contextを含めると物理的に同居できません。72Bは重み（約90GB）が支配的で、32k contextを載せても約90GBのまま大きく変わりません。一方14Bは9GBから34GBへ増えます。小さいモデルほど、context の相対的な重さが効いてきます。
そこで分類器だけを8k contextへ落としたvariantを作りました。分類器は15GBになり、72Bとの合計は105GB。両方を常駐できるようになり、投入から実行開始までの停滞は約4.5分から約12秒へ短縮しました。
この失敗から得た教訓は、ローカルLLMの容量計画ではパラメータ数や量子化後サイズだけを見てはいけない、ということです。context、KV cache、並列数を含む実使用量を測る必要があります。
役割分担を設計する
現在目指しているのは、モデルの順位表ではなく、タスク種別ごとの役割分担です。
画像は、タスク種別ごとに成功率、コスト、時間を比較し、最適な実行者を選ぶための設計モックです。数値はダミーですが、考え方は実運用と同じです。
処理の流れは次のようになります。
- 小さな判断用LLMがタスクを分類する。
- タスクを、仕様、実装、テスト、レビューなどへ分解する。
- 分解後の仕事ごとに、ローカル14B、ローカル作業モデル、Claude Code、Codexなどを選ぶ。
- DB、認証、課金、本番変更などは、モデルの回答に関係なく安全側へ上書きする。
- ローカルモデルの成果物も、クラウドモデルと同じテスト、独立レビュー、人間承認を通す。
- 成功率、所要時間、実コストを記録し、次のルーティング判断へ戻す。
大切なのは、タスクを分解する前に「このモデルへ全部任せる」と決めないことです。
一つの依頼の中にも、軽い分類、仕様の曖昧さの解消、コード変更、テスト、危険な本番操作が混ざっています。依頼全体を最高性能モデルへ送ると高くなり、依頼全体をローカルへ送ると品質や安全性が不安定になります。
分解した後なら、簡単な部分だけをローカルへ移せます。
小さなモデルを使うために、安全をモデルの外へ出す
ローカルLLMを使う時に最も避けたいのは、危険なタスクを「安全」と誤分類することです。
Local Commanderでは、LLMの分類結果を最終決定にしていません。DB、認証、権限、課金、本番、デプロイなどの語を、後段の決定的な処理で検査します。該当すれば、LLMが何と答えてもクラウド側と人間承認へ上げます。
この方式には過検出があります。「DBには触れない」という否定文でも、安全側へ上がる可能性があります。ただし、小さなモデルを安く使いながら危険側の見逃しを防ぐには、説明可能で検証しやすい境界です。
また、ローカルモデルが生成したコードだからといってレビューを軽くしません。テスト、独立レビュー、cross review、人間のmerge承認は同じです。
モデルの能力を上げることと、安全をモデル任せにすることは別の話です。
50.3%が意味するもの
冒頭の50.3%は、2026年7月30日時点の統制盤スナップショットで、transcriptを含むtoken/実行量ベースで推定したローカル処理の割合です（コストの実額とは分けています）。クラウド側は48.2%でした。
この数字から言えるのは、「AI開発の処理量の約半分をローカルへ移せた」ということです。
まだ「総コストが半額になった」とは断定できません。
- クラウドには固定契約と従量課金が混在する
- ローカルにはDGXの購入費、電力、保守がある
- token数とタスク価値は同じではない
- ローカル失敗後にクラウドへ上げると二重コストになる
- モデルごとに生成速度と成功率が違う
次に必要なのは、token比率ではなく、成功したタスク1単位あたりの総コストと時間です。
今の結論
この開発で得た結論は、ローカルLLMがクラウドLLMを置き換える、というものではありません。
ローカルLLMは、すべてを任せる代替品ではなく、分類、定型処理、低リスク作業を高速に引き受ける実行レーンです。クラウドモデルは、複雑な仕様解釈、広い変更、難しいレビューへ集中させます。
そして人間は、安全境界と最終判断を持ちます。
大きいモデルを1台置くより、仕事を分け、実測し、失敗した時に上げられる仕組みを作る。その方が、コストだけでなく、速度と安全性にも効きました。
筆者について
上原正吉。EarthLink Network Co., Ltd. でAI開発をしています。2025年からClaude Codeを開発の主体に据え、今は20を超えるプロダクトを1人で同時に開発・運用しています。この連載では、その現場で実際に起きたこと（うまくいったことも、失敗も）を、数字と一緒に書いていきます。