📰 海外事例
元記事：Can a local LLM replace Claude Code? The benchmark everyone quotes is the wrong one.（dev.to）
Rudratoshさんは、Claude CodeやCodexの頭脳をローカルLLM（自分のPCで動かすAIモデル）に差し替えて実務で試し、「よく引用されるSWE-bench（バグ修正の正答率を測るベンチマーク）の点数では、乗り換えられるかは判断できない」と指摘しています。
2026年に急に現実的になった理由
- MoE（混合エキスパート）モデルの普及：全体のパラメータは大きくても、1語ごとに動くのは一部だけ。たとえばQwenの35B-A3Bは動くのが約30億。必要なメモリは読み込むファイルの大きさで決まり、速さは動く部分で決まるため、以前はサーバーが要ったモデルがゲーム用GPUやノートPCで動く。
- エージェント側がローカルに直接つながるように：2026年1月にOllamaがAnthropic Messages APIに対応し、LM Studioやllama.cppも続いた。中継ソフトなしで、環境変数を1つ向けるだけでClaude Codeがローカルモデルを使える。
点数が教えてくれないこと
24GBのGPU 1枚で動くモデルがSWE-bench Verifiedで約77%と、クラウドの最先端にほぼ並ぶ数字が出ています。ただしこれは「正しい修正を書けるか」の試験です。エージェントとして任せるときに壊れるのは別の4点だ、と著者は言います。
- ツール呼び出し（ファイル編集やコマンド実行の指示）を、毎回正しい形式で出せるか
- 11回目の呼び出しでも、2回目に立てた計画を覚えているか
- 実際のリポジトリ4万トークン分を読ませても品質が保てるか
- 「テストには触るな」のような指示を守れるか
また、同じモデルでもガイドによって点数が大きく違うのは、Verified・Pro・Terminal-Benchを断りなく混ぜているせいが多く、数字はすべて開発元の自己申告として扱い、公式の順位表で確かめるよう注意しています。
モデルの系統と、ハードの目安
著者は単体のモデルではなく系統で考えるよう勧め、7系統を整理しています。要点は次のとおりです。
- Qwen 3.x：コーディングとツール呼び出しの両方で公開モデルの先頭。迷ったらこれ。Qwen 3.6 27Bは量子化で約22GB、24GB GPUやMシリーズのMacで動き、約77%。35B-A3Bは4ビット量子化で8GBでも動く。
- GLM-4.x：長い多段のエージェント作業で安定。Flash版は5〜8GBのノートで動く（約59%）。
- DeepSeek V4-Pro：公開モデル最高の約80.6%だが、80GB以上のサーバー級が必要。
- Devstral Small 2：Apache-2.0で商用利用の権利関係が明快。12〜16GBで約68%。
- Kimi K2.x：長時間の自律作業向けだが、個人のGPUでは厳しい。
-
GPT-OSS：Codex CLIに
--ossでそのままつながる。 - Gemma 4：コード専用ではない、軽い万能型。
性能をGPUメモリと並べると、24GBまでは急に伸び、その先は頭打ちになります。著者の結論は「24GB GPU 1枚でQwen 3.6 27B」が個人の自前運用の最適点。
本当の壁はツール呼び出し
ツール呼び出しはコードを書く力とは別に訓練される技能で、次の傾向が見えたといいます。
- 約40億パラメータ未満では信頼性が急落し、7B未満は包むエージェントが何であれ形式の崩れた呼び出しを出す
- 後付けの出力制約より、ツール用の書式で訓練されたモデルの方が安定する
- Claude Code・OpenCode・Codexのどれを使うかより、モデルの差の方が大きい
- 1回なら平気でも、前の結果に依存する呼び出しが5回続くと、存在しない関数を呼ぶなどして再試行の堂々巡りになる
エージェント用途なら、ツール訓練のある系統の14B〜32Bを選ぶのが現実的な線です。
つなぎ方と、はまりどころ
Ollamaでモデルを取得し、ANTHROPIC_BASE_URL を http://localhost:11434 に、ANTHROPIC_AUTH_TOKEN をダミー値にして claude を起動するだけ。Codexは --oss でOllamaに、LM Studioなら :1234/v1 につながります。注意点は2つ。文脈の長さ（コンテキストウィンドウ）を32K以上、できれば64K以上に明示すること（既定値は小さすぎる一方、公称の半分あたりから品質が落ち、メモリも食う）。そしてクラウドに戻すときに ANTHROPIC_BASE_URL を消し忘れないこと。
実際の使い心地とお金
1週間の実務では、単一ファイルの定型作業ならクラウドのClaudeの7割ほど。複数ファイルにまたがる変更では3ファイル目あたりで迷い、再試行のたびに全文を生成し直すので、クラウドで数秒の作業が数分かかることもあります。
費用面では、ローカルは無料ではなく「前払い」。中古の24GB GPUが数百ドル、電気代は個人なら月に数ドル程度。対してClaude Codeを重く使う人は月に数百ドル払うこともあります。それでも個人の普段使いでは、機材と調整の手間で元を取りにくい。逆転するのは、大量・反復・機密の作業、特に多数のエージェントを走らせる場合で、簡単な8割をローカルへ、難しい2割だけを最先端モデルへ回す振り分けが2026年の本当の勝ち筋だ、と著者は言います。
結論
難しく長い多段の作業を任せる相棒としては、まだ代わりにならない。足を引っ張っているのは点数ではなく、長時間のツール呼び出しの信頼性。一方、機密や大量処理や単一ファイルの作業を担う安くていつでも使える働き手としては、24GB GPU 1枚で今日から十分。「置き換える」ではなく、2つのモデルを使い分けるのが答えだ、というまとめです。
この記事はほんとに実用的。特にモデルの使い分けの話で、新しいのが出るたびに乗り換えるんじゃなく、高性能モデルと下請けモデルを使い分けるのが、最近ほんとに大事になってきてます。軽量モデルの単価は以前の10分の1ぐらいまで下がったし、無料モデルも出てきた。Opencodeあたりなら、機微情報さえ入れなければ（学習に使われる前提なので）、タダでかなり賢いエージェントを動かせます。
記事が挙げてる「サーバーなしでも動く」「エージェントのツールがローカルにつながる」に加えて、コーディング用のハーネスソフト自体が何個も出てきて、それに簡単につなげるようになったのも大きいかなと。
僕はローカルLLMを実際に使ったことがないので、Qwen・GLM・DeepSeekの体感ははっきり言ってよくわかりません。でも、こういう感想こそベンチマークでは得られない一次情報なので、本気で使う人には参考になると思うし、自分の体感と比べてどうか聞いてみたい。「24GBまでは急に伸びて、その先は頭打ち」って話もすごくいい情報です。
ベンチマークが良くても実用に耐えるかは怪しい、というのも実感通り。小さく切り出したタスクならそんなに問題は起きないんだろうけど、文脈が長くなったり、あちこちのファイルを探したりするたびに迷う。トークン代はかからないにしても、ただでさえ速くないローカルで余計に時間を食うことになります。
今は全知全能を目指したような万能AIばっかりですけど、これから用途ごとに多角化して、小さくなって、ローカルでもスマホでも動くようになっていくはず。そう考えると、今あえて24GBのGPUを買う価値があるかは、解釈の分かれるところだと思います。これから技術の進歩で、動かせるAIの性能は上がっていくだろうから、今買えばしばらくガシガシ使えるのも確か。一方で、数年経てばロースペックでも必要な機能は十分確保できるようになってくる気がします。
いずれにしても、大手のAIサービスに頼らずにある程度のことができるようになってきてるのは、ほんとに未来を感じます。
出典
- Rudratosh「Can a local LLM replace Claude Code? The benchmark everyone quotes is the wrong one.」（DEV Community）https://dev.to/rudratosh/can-a-local-llm-replace-claude-code-the-benchmark-everyone-quotes-is-the-wrong-one-2kna