ローカルLLMでのコーディング利用はもうやめた

Reddit r/LocalLLaMA / 2026/4/28

💬 オピニオンDeveloper Stack & InfrastructureTools & Practical Usage

要点

  • 著者は数週間にわたって、ローカルLLM(Qwen 27BやGemma 4 31Bなど)をコーディングやDevOps系タスクに使い、仕事で使っているClaude Codeと比較した。
  • その結果、判断の一貫性やツール利用の信頼性が欠ける場面が多く、生産性の低下がメリットを上回るとして、ローカルモデルの利用をやめる結論に至った。
  • 重要な失敗パターンとして、長時間のDockerコマンドの実行結果を確認せずに「失敗したはずだ」と決めつけ、実際の出力を見ずに推測で対処を進めてしまう点が挙げられている。
  • AGENTS.mdでサブエージェントの使用やビルド出力のログ出力(tail/grepで参照)などの手順を示しても、Docker build/composeの大量出力を読み込んでトークン枯渇に至る“壊れたセッション”が繰り返されたという。
  • さらに、応答が遅いだけでなく、プロンプトキャッシュが頻繁に壊れて何も起きないような長い待ち時間が発生するなど、性能面の問題も報告されている。

ここ数週間で、それなりに公平に試したと思います。仕事以外の技術的な依頼に対して、無理やりローカルモデルを使うようにしてみました。職場ではClaude Codeを使っているので、それと比較しています。

私はQwen 27BとGemma 4 31Bを使いました。これらは、マルチハンドレッド(数百)規模のLLMの中では最高峰のローカルモデルとされています。さらに、複数のエージェント型アプリも試しました。結論としては、生産性の低下は、その利点に見合いません。

主な問題点を簡単にまとめます。

クソみたいな意思決定とツール呼び出し

これは大きなポイントです。Claudeはたいていの場合、私の考えていることを読んでいるように感じますが、Qwen 27Bは、少なくとも大抵の場合は、カルロ・アンチェロッティの眉みたいに「なんでそうなるの?」を出させられます。LLMが進め方を、私が進めたい形では進めてくれません。

私は主に、OS/DockerのタスクでローカルLLMを使っていました。これは、コーディングや何かと比べてかなり難しい部類なのでしょうか?

例を挙げると、「ここにGitHubのリポジトリがある。Docker化してほしい」 みたいなタスクでは、私はダミーでもREADMEの指示に従って実行するはずだと期待します。(編集:完全なプロンプトはこちら:https://reddit.com/r/LocalLLaMA/comments/1sxqa2c/im_done_with_using_local_llms_for_coding/oiowcxe/

たとえば、「docker build」がデフォルトのタイムアウトより長くかかり、そのせいでタスクが失敗したかのように、無関係な追従タスクへ分岐してしまう問題があります。本来は、まだ実行中かどうかを確認すべきです。私はQwenに、ホスト側(こちらもUbuntu)でインストールコマンドを繰り返させて、何が起きるかを試しました。結果は、出力を確認することもなく、突然「たぶんtorchcodecのせいで失敗したんだ」と決めつけて、完全にその場しのぎの推測で進め始めました。

モデルに合わせることも試しました。AGENTS.mdにこう書いています。「Docker buildコマンドを実行する場合、またはデバッグ出力が多く出ると考える他のコマンドを実行する場合は、以下を行ってください:1. メインのコンテキストを汚さないように、サブエージェントで実行する。2. 出力を一時ファイルにパイプして、あとでtailやgrepを使って参照できるようにする。」 それでも連続して2回、LLMが「docker build」や「docker compose up」の出力を全部読んでしまうせいで、入力トークン25万の壊れたセッションに戻ってきました。

LLMをプログラマブルなロボットのように扱い、自己誘導がまともにできるとは期待していないので、長く複雑なプロトコルを与えるような巨大なAGENTS.mdを使っている人たちがいるのは知っています。正直、そういうのは試しませんでした。あと正直、どれも「docker buildの出力を読まない」といった細かい点には踏み込んでいません。私は、私が使っていたエージェント型アプリのデフォルトプロンプトに絞り、AGENTS.mdにいくつかのガイドラインを追加するにとどめました。

パフォーマンス

LLMが遅いだけでなく、どのアプリを使っていても、プロンプトキャッシュが頻繁に壊れるように見えます。要するに、何も起きていないように見える長い待ち時間が発生します。

Claude Codeに関しては、さらに状況が悪化しています。ユーザーにLLMの出力を表示しないからです。だから私は、Qwen Codeをよく選ぶようになっていました。結果が良くないだけでなく、素早いフィードバックも得られないのはとてもつらいです。

学べていない

Chat CompletionsサーバーのURLを変更する以外に、ローカルLLMを使うのとクラウドLLMを使うのとの差はなく、ただ面倒が増えるだけです。

LLMへのプロンプトの仕方を学ぶことで得られることは確実にあります。でも、コーディングのタスクは小さめのものだと難しすぎると思っています。Hardcoreモードでゲームをしているみたいな感じです。学習曲線の「ちょうど良い甘いところ」を探しているのですが、これは割に合いません。

今後どうするか

私のコーディングやOSまわりの作業では、OpenRouterに少し賭けて、Kimiのような大きいモデルだけを使います。あるモデルが私をイラつかせたら、次のモデルに移ります。もしお気に入りが見つかったら、お金を節約するために年払いプランに登録します。

自動化、基礎的な調査、言語タスクでは、引き続き小さめのローカルモデルを使います。自分のPCで動く基本的な自動化スキル/ボットを書いているのは楽しかったし、これらは常に役に立つはずです。

また、文章を書く用途やテキストゲームでローカルLLMを使うのが大好きです。ここでは速度は問題になりませんし、プロンプトキャッシュは常にヒットします。技術的にはクラウドのモデルを使うこともできますが、その場合は大変な金額を払うことになります。しばらくすると、毎回の新しいターンが約10万トークンを送るようになるからです。

ブログを読んでくれてありがとうございます。

submitted by /u/dtdisapointingresult
[link] [comments]