【悲報】ローカルでコーディングAI、20分待っても終わらない理由が「モデルの馬鹿さ」ではなかった
【悲報】ローカルでコーディングAI、20分待っても終わらない理由が「モデルの馬鹿さ」ではなかった
おしゃべりするAIは自分のパソコンでサクサク動いたのに、コードを書かせるAIだけが使い物にならない。ファイルを1つ直すよう頼んだだけで20分たっても終わらず、途中で括弧だらけの謎の文字列を吐いて黙り込む。日本語圏でも英語圏でも、ローカル環境でコーディングAIに挑戦した人々が同じ場所で挫折する様子が、解説記事やブログ投稿として各地に蓄積されている。
原因はモデルの知能ではなかった。ローカルLLMによるコーディングエージェント運用をめぐる議論から、「チャットとコーディングでは同じモデルでも使われ方が根本的に違う」という構造的な問題が浮かび上がりつつある。さらに2026年8月には、この構造そのものを直そうという動きとして、DeepSeekによるオープンソースツールの公開が大きな注目を集めた。
1つの仕事で何十回も呼ばれるモデル
チャット型AIは、質問して答えが返ってきたら終わり。往復はたった1回である。一方コーディングAIは違う。ファイルを1つ直させるだけでも、AIはまずどのファイルを見るべきか自分で探し、見つけたら中身を読み、修正箇所を決め、書き換え、動くか試しに走らせ、エラーを読み、また直し、また走らせる。この一連のステップの一つひとつがすべてモデルの呼び出しなのだ。
1回あたり30秒の処理でも40回呼べば20分になる。遅かったのではなく、単純に回数が多かったのである。しかもこの裏側の呼び出し回数は画面に表示されないため、ユーザーは「最後の結果が出てくるまでずっと待たされる」という現象としてしか体感できない。
「毎秒何トークン」は書くほうの速さでしかない
ここで重要になるのが、AIの文章生成処理が2段階に分かれているという事実だ。前半は渡された文章を読み込む工程で「プリフィル」と呼ばれる。日本語でいえば下読みだ。後半が1文字ずつ答えを吐き出す「デコード」であり、実際に書いている時間に相当する。
世間で語られる「毎秒○トークン」という数字は、ほぼすべて後半のデコード速度を指している。ところがコーディングエージェントでは時間の大半をプリフィルが占める。プロンプトが巨大で返事が短い――道具の呼び出し命令は1〜2行程度だからだ。つまりベンチマークで盛んに語られる速さの数字が、エージェント運用ではほとんど役に立たない。下読みの速さはほとんど公開されていないままなのである。
実際の測定例を見ると、Mac mini M1（メモリ16GB）でコーダー向け14Bモデルが毎秒6.71トークン、同7Bモデルが毎秒12.67トークンという数字がある。チャット用途なら人が文章を読む速さと同程度なので我慢できる水準だ。それでもコーディングでは使い物にならない。同じ速さでも勝負の場が違うのだ。
なぜ渡す山は巨大になり、なぜ毎回読み直すのか
コーディングエージェントが毎回巨大な文章をモデルへ渡す理由は明快だ。システム指示書があり、使える道具の一覧と使い方の説明があり、ファイルの中身があり、これまでの会話履歴が全部乗る。特に道具の定義だけで1リクエスト数万トークンに達することもある。便利にすればするほど道具が増え、説明文が膨らんでいく仕組みだ。
そして決定的なのが、モデル自身には記憶の仕組みがないことである。モデルは1回ごとに渡された文章だけを見て考える。前回何を渡されたかは原理的に知らない。毎回「初めまして」なのだ。だから履歴を全部つけ直して渡すしかなく、40回呼ぶなら40回とも山を読み直す。しかも会話が進むほど山は高くなり、後半の1回は最初の何倍にもなる。冒頭は順調に見えていたのに途中から急に止まったように感じるのは、まさにこの積み上がりのせいだ。
クラウド側が下読みを高速にこなせるのは、演算力の桁が違い、大勢のリクエストをまとめて処理しているからである。ここは正面から勝負できない領域だ。
賢さではなく書式で転ぶ 7B〜9Bの壁
失敗率の問題もある。小さいモデルは、JSONという括弧と引用符だらけの決まった形式で道具呼び出しを書かなければならない場面で形式を守り切れず、受け取り側が読めない出力を返して停止する。「括弧だらけの文字列を吐いて黙り込む」という症状の正体はこれだ。海外の解説記事の観察によれば、信頼できる道具呼び出しが安定して出てくるのはパラメータ7B〜9Bあたりからとされる（公式測定値ではなく筆者の観察に基づく目安）。
しかし大きいモデルを選べば次はメモリの壁だ。9Bを4ビット量子化なら6〜8GB、27B〜35Bクラスなら20〜24GB、80B級のMoEアーキテクチャでも35〜48GBの置き場所が必要になる。24GB級のグラボは決して安くない。
さらにコンテキスト長の壁もある。ローカル運用ではメモリ節約のため32K程度に設定しがちだが、クラウド側は200Kが標準的。道具の説明だけで数万トークン食う世界では、入り口で満員になって肝心の仕事の中身が入らない事態すら起こる。満員のまま押し込むと古い情報から捨てられ、直したはずの場所をまた直し始める。加えて道具側には30秒で打ち切るタイムアウトがあり、下読みが遅いローカル環境はこの締め切りに負けてしまう。
ハーネスという概念 DeepSeekのMITライセンス公開
こうした問題の多くは、実はモデルではなく「ハーネス」――モデルの外側で仕事を回す仕掛け全体――の責任だと整理され始めている。どのファイルを読ませるか、履歴をどう詰めるか、道具の説明をどこまで渡すか。往復の回数も山の高さもハーネスが決めている。
そして2026年8月13日、DeepSeekがそのハーネス自体をMITライセンスでオープンソース公開した。「DeepSeek Harness」のGitHubスター数は8月24日時点でおよそ19万。公開から10日余りとしては異常な速さだ。特徴は「全てはプラグイン」という設計思想で、モデル・道具・記憶・画面がすべて部品扱い。接続先にはOpenAI互換のURLを指定でき、理屈の上では自宅PC内のローカルモデルにも繋げられる。道具を絞った最小構成では、命令実行と文字置換のわずか2つにまで削れる。道具が減れば説明文も短くなり、これはそのまま速さの対策になる。
ただし接続できることと実用的に動くことは別物であり、往復回数や下読みの遅さといった4つの壁が消えるわけではない。効く対策は限定的だ。（1）下読み結果のKVキャッシュを使い回す――Xでの個人運用報告ながら98.2%の再利用率という数字も上がっている。（2）投機的デコード――小さいモデルに先に書かせて大きいモデルで答え合わせし、デコードを1.5〜3倍化する。（3）KVキャッシュを8ビット化して占有を約半分に圧縮する。いずれも条件次第の部分が残る。
クラウドに払うか自前で買うか 持ち帰るべき三つ
お金の話も現実的だ。ある実践者はClaude Pro（3000円）、GitHub Copilot（1500円）、ChatGPT（1400円）、Gemini（3000円）の合計月9000円を払っていたという。年間10万円強ならグラボが買えてしまう計算だ。自前派の言い分は回数制限がないこと、外に出せない仕事を扱えること、ネットなしで動くこと。クラウド派の反論は、ハードウェアは買った日から古くなり、モデルは半年で入れ替わるがグラボは残る、そして待ち時間も人間のコストである、というもの。論争は決着していない。
実務上は「補完はエディタ機能に任せる、調べ物はローカルモデルで外に出さず済ませる、重い往復仕事はクラウドへ」という三本立てに落ち着く例が多いが、外に一切出せない仕事なら成立しない。万人向けの正解はない。
それでも持ち帰るべき教訓は三つに絞られる。第一に、速さの数字を鵜呑みにしないこと。第二に、モデルの大きさは賢さよりも「組織」として効くこと。小さすぎると道具呼び出しの書式で転び、やり直しの往復が増える。括弧だらけの出力を見たらモデルサイズを疑うといい。第三に、コンテキストをむやみに削らないこと。節約のつもりが入り口で満員になり逆効果になり得る。困ったらまず長さを見直すのが定石だ。
ネットの反応
ローカルLLMでしかできないことがある。……高すぎてまともに動くマシンが買えないけど！
20分待ったのは遅かったからじゃなくて回数だったのか。当たり前すぎて気づかなかったわ
毎秒トークンの数字が全部補完側の指標だったって衝撃。ベンチマークの意味変わってきたな
括弧だらけの文字列で止まる症状、うちでも再現してたけど7B以下じゃ道具呼び出し無理って話で納得
クラウド月9000円は年間でグラボ1枚買える計算か。悩むわけだ
AIの所感
この議論の本質は、「ローカルLLMが弱い」という個人の体験談が、実は構造的な工学的課題の集合体だったという点にあると思う。プリフィルとデコードの支配関係がタスクによって反転すること、そして市販のベンチマーク指標がその反転を一切反映していないことは、ユーザー側の期待値設定そのものを歪めてきた。特に「モデルには記憶がないから毎回初めまして」という整理は、エージェントのコスト構造を理解する上で最も重要な洞察だろう。DeepSeek Harnessの急速な普及は、この構造理解がコミュニティ全体に浸透していた証拠とも言える。注目したいのは、改善の矛先が「より賢いモデル」ではなく「より良い道具立て」に向いたことだ。モデル性能の競争が頭打ちになり始めた領域では、往復回数と失敗率を削るハーネス側の工夫の方が体感速度に効く。7B〜9Bという道具呼び出しの安定線やKVキャッシュの8ビット化といった具体的な知見が共有され続ければ、ローカル運用は「趣味の実験」から「特定用途での実用」へ一歩近づくだろう。ただし下読みの物理的制約はハードウェアの演算力に根差しており、そこを正面突破するには結局、電力と冷却と予算の問題に戻る。分かってから買うのと分からずに買うのとは大違い――この締めの言葉通り、数字の意味を正しく理解した上で投資判断をする時代になったということだ。